Book contents
- Frontmatter
- Contents
- Preface
- 1 Introduction
- 2 General Diagramming Guidelines
- 3 Guidelines for Common UML Modeling Elements
- 4 UML Use-Case Diagrams
- 5 UML Class Diagrams
- 6 UML Package Diagrams
- 7 UML Sequence Diagrams
- 8 UML Communication Diagrams
- 9 UML State Machine Diagrams
- 10 UML Activity Diagrams
- 11 UML Component Diagrams
- 12 UML Deployment Diagrams
- 13 UML Object Diagrams
- 14 UML Composite Structure Diagrams
- 15 UML Interaction Overview Diagrams
- 16 UML Timing Diagrams
- 17 Agile Modeling
- Bibliography
- Index
5 - UML Class Diagrams
Published online by Cambridge University Press: 17 December 2010
- Frontmatter
- Contents
- Preface
- 1 Introduction
- 2 General Diagramming Guidelines
- 3 Guidelines for Common UML Modeling Elements
- 4 UML Use-Case Diagrams
- 5 UML Class Diagrams
- 6 UML Package Diagrams
- 7 UML Sequence Diagrams
- 8 UML Communication Diagrams
- 9 UML State Machine Diagrams
- 10 UML Activity Diagrams
- 11 UML Component Diagrams
- 12 UML Deployment Diagrams
- 13 UML Object Diagrams
- 14 UML Composite Structure Diagrams
- 15 UML Interaction Overview Diagrams
- 16 UML Timing Diagrams
- 17 Agile Modeling
- Bibliography
- Index
Summary
UML class diagrams show the classes of a system, their interrelationships, and the operations and attributes of the classes. They are used to
■ explore domain concepts in the form of a domain model,
■ analyze requirements in the form of a conceptual/analysis model,
■ depict the detailed design of object-oriented or object-based software.
A class model comprises one or more class diagrams and the supporting specifications that describe model elements, including classes, relationships between classes, and interfaces.
General Guidelines
Because UML class diagrams are used for a variety of purposes—from understanding your requirements to describing your detailed design—you will need to apply a different style in each circumstance. This section describes style guidelines pertaining to different types of class diagrams.
Identify Responsibilities on Domain Class Models
When creating a domain class diagram, often as part of your requirements modeling efforts, focus on identifying responsibilities for classes instead of on specific attributes or operations. For example, the Invoice class is responsible for providing its total, but whether it maintains this as an attribute or simply calculates it at request time is a design decision that you'll make later.
There is some disagreement about this guideline because it implies that you should be taking a responsibility-driven approach to development. Craig Larman (2002) suggests a data-driven approach, where you start domain models by identifying only data attributes, resulting in a model that is little different from a logical data model.
- Type
- Chapter
- Information
- The Elements of UML™ 2.0 Style , pp. 47 - 72Publisher: Cambridge University PressPrint publication year: 2005