Class Diagram
Purpose
The Class Diagram (CD) is the heart of any UML modelling activity. CDs are used to identify classes, to characterise these classes, and to define the relationships between them.
Example
Here is an example Class Diagram.
Description
Each CD is likely to start in a relatively superficial way, and acquires additional detail as its classes are fully elaborated in appropriate cycles of the development process.
A CD contains classes which have a name and are defined by Process Specifications (PSpec). The PSpec for a class is mandatory, because Cradle stores the set of class attributes and operations not within the CD(s) in which the class is shown, but within frames of the PSpecs, which are called:
On the Class Diagram, the ATTRIBUTES and OPERATIONS frames are displayed in the class symbols.
These frames are only displayed when the Definitions DISPLAY MODE has been selected.
Each instance of a class on a CD may have a different symbolic representation, in that a per-instance filter is used by the user to specify which (if any) of the attributes and operations are to be shown, and how much of each is to be shown.
A class may appear on one or more CDs, and potentially more than once on any such CD if desired. A class is said to be defined in the package that contains it, but may be declared within (i.e. used within) any other package that the designer requires. It is usual for the definition of the class to show its attributes and operations in full details, whereas uses of the class in other packages do not show the full detail.
A class may be an instance of a stereotype such as:
- Entity
- Boundary
- Control
- Template
- Utility
The CDs will initially show only terse details of classes, but as the iterative development progresses, the contents of the CDs will become increasingly detailed including, for example, full signatures (including data types and default values) of each class attribute, and full signatures (similar to procedure/function call interfaces) of all class operations. Because Cradle allows CDs in both its analysis and design models, it is expected that users will exploit this flexibility, and will not elaborate Essential Model CDs to a greater extent than is consistent with the scope of analysis work.
Classes exhibit relationships with other classes. These relationships range from a simple association, through a part-of aggregation or composition relationships, to kind-of inheritance relationships. These relationships are shown in CDs by appropriate types of connection symbol, linking the classes together. However, unlike other connection symbols, these class relationships have 5 parts to their text notation:
- A name for the relationship
|
- A source label, which contains the cardinality of that class in the relationship, as an expression of the form:
|
| quantity [.. quantity ] |
| where: |
|
| quantity |
is either a number, such as 0, 1 or 26. or * for any number |
| ... quantity |
can optionally be used to specify a range and an upper bound |
| For example: |
|
| 1 |
means exactly 1 |
| 6 |
means exactly 6 |
| 0..1 |
means zero or 1 |
| 1..* |
means any number but at least 1 |
| 0..* |
means any number including zero |
| The source label (source class cardinality) is drawn next to the source class and either below or to the left of the relationship. |
- A destination label, which contains the cardinality of the destination class is the relationship, as an expression of the form:
|
| quantity [.. quantity ] |
| The destination label (destination class cardinality) is drawn next to the destination class and either below, or to the left of, the relationship |
- A source role, which identifies the role that the source class plays in the relationship with a meaningful name. It is drawn next to the source class and either above, or to the right of, the relationship.
|
- A destination role, which identifies the role that the desination class plays in the relationship with a meaningful name. It is drawn next to the destination class and either above, or to the right of, the relationship.
|
As the elaboration of CDs evolves, navigation can be added to the relationships, by replacing them by corresponding symbols that include arrowheads. The navigation for a relationship indicates the direction in which it can be queried. By default, relationships are bidirectional.
Strengths
Able to clearly depict all forms of inter-relationships between classes.
Weaknesses
Does not allow decomposition of data elements, all attributes in a class are assumed to be atomic, and the diagram does not explicitly link these attributes to the Data Dictionary.
Characteristics
APPEARS IN MODELS |
Essential and Implementation |
NUMBERING |
A CD is the expansion of a package. A CD has a name and a number which are both the same as the name of this package. CDs are essentially separate from, and shared by, all of the OO models in a Cradle modelling domain. A CD may be shared between OO models by including a package with the CD's package name in the Logical View Package Diagram (PD) hierarchy of more than one OO model. |
HIERARCHICAL |
Yes |
Linkage
Symbols
| Symbol |
Name |
Description |
Definition |
Expansion |
 |
Comment |
Makes a note anywhere in the diagram. Are always surrounded by * characters. |
None |
None |
 |
Class |
A set of objects with similar structure, behaviour, and relationships. |
PSpec |
SCD
ACD |
 |
Boundary class |
A class whose primary role is to interface with the system environment, a stereotype of class. |
PSpec |
SCD
ACD |
 |
Control class |
A class whose primary role is to co-ordinate and manage the system behaviour, a stereotype of class. |
PSpec |
SCD
ACD |
 |
Entity class |
A class whose primary role is to manage a set of data objects, a stereotype of class. |
PSpec |
SCD
ACD |
 |
Template class |
A class with one or more unbound formal parameters. |
PSpec |
SCD
ACD |
 |
Utility class |
A class that supplies utility behaviour, a stereotype of class. |
PSpec |
SCD
ACD |
 |
Picture |
Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol. |
None |
None |
 |
Relationship node |
A symbol used to join classes in tertiary or higher relationships, in particular for association classes. |
None |
None |
 |
Bidirectional association |
A bidirectional relationship between classes that involves connections among their instances. Associations may have names, source and destination labels, and source and destination roles. |
None |
None |
 |
Directional association |
A unidirectional association between classes. |
None |
None |
 |
Bidirectional aggregation |
A special form of bidirectional association that specifies a whole-part relationship between the aggregate (whole) and a component part. |
None |
None |
 |
Directional aggregation |
A unidirectional aggregation. |
None |
None |
 |
Bidirectional composition |
A form of aggregation with strong ownership and coincident lifetime as part of the whole. |
None |
None |
 |
Directional composition |
A unidirectional composition. |
None |
None |
 |
Inheritance relationship |
The mechanism by which more specific elements incorporate structure and behaviour of more general elements related by behaviour. |
None |
None |
 |
Class dependency |
A relationship between classes. |
None |
None |
 |
Association class link |
A link that joins an association class to a relationship node used to create associative relationships between the association class and two or more other classes. |
None |
None |
|
