An introduction to structure diagrams in UML 2
This is the next installment in a series of articles about the essential diagrams used within the Unified Modeling Language, or UML. In my previous article on sequence diagrams, I shifted focus away from the UML 1.4 spec to OMG’s Adopted 2.0 Draft Specification of UML (a.k.a. UML 2). In this article, I will discuss Structure Diagrams, which is a new diagram category that has been introduced in UML 2. Because the purpose of this series is to educate people about the notation elements and their meanings, this article focuses mainly on the class diagram. The reason for this will soon become clear. Subsequent articles will cover other diagrams included in the structure category.
The yin and yang of UML 2
Structure diagrams in general
The class diagram in particular
The basics
- a class
- an interface
- a data type
- a component.
Class name
Figure 1: Class diagram for the class Flight
Class attribute list
Continuing with our Flight class example, we can describe the class’s attributes with the attribute type information, as shown in Table 1.
Table 1: The Flight class’s attribute names with their associated types
Attribute Name | Attribute Type |
---|---|
flightNumber | Integer |
departureTime | Date |
flightDuration | Minutes |
For example:
Showing a default value for attributes is optional; Figure 2 shows a Bank Account class with an attribute called balance, which has a default value of 0.
Figure 2: A Bank Account class diagram showing the balance attribute’s value defaulted to zero dollars
Class operations list
The Flight class’s operations are mapped in Table 2 below.
Table 2: Flight class’s operations mapped from Figure 3
Operation Name | Parameters Return | Value Type |
---|---|---|
delayFlight | N/A | |
getArrivalTime | N/A | Date |
delayFlight(numberOfMinutes : Minutes) : Date.
] When an operation has parameters, they are put inside the operation’s parentheses; each parameter uses the format “parameter name : parameter type”.Figure 3: The Flight class operations parameters include the optional “in” marking
Inheritance
Figure 4: Inheritance is indicated by a solid line with a closed, unfilled arrowhead pointing at the super class
Figure 5: An example of inheritance using tree notation
Abstract classes and operations
Associations
Bi-directional (standard) association
Figure 6: An example of a bi-directional association between a Flight class and a Plane class
Table 3: Multiplicity values and their indicators
Indicator | Meaning |
---|---|
0..1 | Zero or one |
1 | One only |
0.. | Zero or more |
Zero or more | |
1..* | One or more |
3 | Three only |
0..5 | Zero to Five |
5..15 | Five to Fifteen |
Uni-directional association
Figure 7: An example of a uni-directional association: The OverdrawnAccountsReport class knows about the BankAccount class, but the BankAccount class does not know about the association
Packages
- If the modeler decides to show the package’s members within the large rectangle, then all those members need to be placed within the rectangle. [Note: It’s important to understand that when I say “all those members,” I mean only the classes that the current diagram is going to show. A diagram showing a package with contents does not need to show all its contents; it can show a subset of the contained elements according to some criterion, which is not necessarily all the package’s classifiers.] Also the package’s name needs to be placed in the package’s smaller rectangle (as show n in Figure 8).
- If the modeler decides to show the package’s members outside the large rectangle then all the members that will be shown on the diagram need to be placed outside the rectangle. To show what classifiers belong to the package, a line is drawn from each classifier to a circle that has a plus sign inside the circle attached to the package (Figure 9).
Figure 8: An example package element that shows its members inside the package’s rectangle boundaries
Figure 9: An example package element showing its membership via connected lines
Importance of understanding the basics
Beyond the basics
Interfaces
Figure 10: Example of a class diagram in which the Professor and Student classes implement the Person interface
More associations
Association class
Figure 11: Adding the association class MileageCredit
Aggregation
An association with an aggregation relationship indicates that one class is a part of another class. In an aggregation relationship, the child class instance can outlive its parent class. To represent an aggregation relationship, you draw a solid line from the parent class to the part class, and draw an unfilled diamond shape on the parent class’s association end. Figure 12 shows an example of an aggregation relationship between a Car and a Wheel.
Figure 12: Example of an aggregation association
The composition aggregation relationship is just another form of the aggregation relationship, but the child class’s instance lifecycle is dependent on the parent class’s instance lifecycle. In Figure 13, which shows a composition relationship between a Company class and a Department class, notice that the composition relationship is drawn like the aggregation relationship, but this time the diamond shape is filled.
Figure 13: Example of a composition relationship
Reflexive associations
Figure 14: Example of a reflexive association relationship
Visibility
Table 4: Marks for UML-supported visibility types
Mark | Visibility type |
---|---|
Public | |
# | Protected |
– | Private |
~ | Package |
Figure 15: A BankAccount class that shows the visibility of its attributes and operations
UML 2 additions
Instances
For example:
Because the purpose of showing instances is to show interesting or relevant information, it is not necessary to include in your model the entire instance’s attributes and operations. Instead it is completely appropriate to show only the attributes and their values that are interesting as depicted in Figure 16.
Figure 16: An example instance of a Plane class (only the interesting attribute values are shown)
Figure 17: An example of Figure 6 using instances instead of classes
Roles
Figure 18: A class diagram showing the class in Figure 14 in its different roles
Internal Structures
Figure 19: A class diagram that only shows relationships between the objects
Figure 20: An example internal structure of a Plane class
Conclusion
UML diagram types |
---|
Structural UML diagrams |
Behavioral UML diagrams |
Diagram building blocks[edit]
References[edit]
- ^OMG (2011). OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1, p. 507.
- ^OMG (2008). OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, p. 485.
- ^OMG (2007). OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2. p. 467.
External links[edit]
Wikimedia Commons has media related to Sequence diagrams. |
- UML Distilled by Martin Fowler
- Current UML Specification by Object Management Group (OMG)
- Introduction to UML 2 Sequence Diagrams by Scott W. Ambler.
- A Quick Introduction to UML Sequence Diagrams by Yanic Inghelbrecht