Unified Modeling Language (UML) is an object modeling specification language that uses graphical notation to create an abstract model of a system. The Object Management Group governs UML. This modeling language can be applied to Java programs to help graphically depict such things as class relationships and sequence diagrams. The latest specifications for UML can be found at the OMG website. An informative book on UML is UML Distilled, Third Edition, by Martin Fowler (Addison-Wesley, 2003).
A class diagram represents the static structure of a system, displaying information for classes and relationships between them. The individual class diagram is divided into three compartments: name, attributes (optional), and operations (optional); see Figure C-1 and the example that follows it.
// Corresponding code segment
class
Orchestra
{
// Class Name
// Attributes
private
String
orch
Name
;
private
Integer
instrCount
=
7
;
// Operations
public
void
setOrchName
(
String
name
)
{...}
public
Boolean
play
(
Score
s
)
{...}
}
The attributes compartment is optional and includes member variables that represent the state of the object. The complete UML usage is as follows:
visibility
name
:
type
[
multiplicity
]
=
defaultValue
{
property
-
string
}
Typically, only the attribute names and types are represented.
The operations compartment is optional and includes member functions that represent the system’s behavior. The complete UML usage for operations is as follows:
visibility
name
(
parameter
-
list
)
:
return
-
type
-
expression
{
property
-
string
}
Typically, only the operation names and parameter lists are represented.
Visibility indicators (prefix symbols) can be optionally defined for access modifiers. The indicators can be applied to the member variables and member functions of a class diagram; see Table C-1.
Object diagrams are differentiated from class diagrams by underlining the text in the object’s name compartment. The text can be represented three different ways; see Table C-2.
| Class name only |
| Object name only |
| Object and class name |
Object diagrams are not frequently used, but they can be helpful when detailing information, as shown in Figure C-2.
Graphical icons are the main building blocks in UML diagrams; see Figure C-3.
Classes, abstract classes, and interfaces are all represented with their names in boldface within a rectangle. Abstract classes are additionally italicized. Interfaces are prefaced with the word interface enclosed in guillemet characters. Guillemets house stereotypes and in the interface case, a classifier.
Notes are comments in a rectangle with a folded corner. They can be represented alone, or they can be connected to another icon by a dashed line.
A package is represented with an icon that resembles a file folder. The package name is inside the larger compartment unless the larger compartment is occupied by other graphical elements (i.e., class icons). In the latter case, the package name would be in the smaller compartment. An open arrowhead with a dashed line shows package dependencies.
The arrow always points in the direction of the package that is required to satisfy the dependency. Package diagrams are shown in Figure C-4.
Connectors are the graphical images that show associations between classes. Connectors are detailed in Class Relationships.
Multiplicity indicators represent how many objects are participating in an association; see Table C-3. These indicators are typically included next to a connector and can also be used as part of a member variable in the attributes compartment.
Role names are utilized when the relationships between classes need to be further clarified. Role names are often seen with multiplicity indicators. Figure C-5 shows Orchestra where it performs one or more Scores.
Class relationships are represented by the use of connectors and class diagrams; see Figure C-6. Graphical icons, multiplicity indicators, and role names may also be used in depicting relationships.
An association denotes a relationship between classes and can be bidirectionally implied. Class attributes and multiplicities can be included at the target end(s).
Direct association, also known as navigability, is a relationship directing the source class to the target class. This relationship may be read Orchestra “has-a” Clarinet. Class attributes and multiplicities can be included at the target end. Navigability can be bidirectional between classes.
Composition association, also known as containment, models a whole-part relationship, where the whole governs the lifetime of the parts. The parts cannot exist except as components of the whole. This is a stronger form of association than aggregation. You could say a Score is “composed-of” one or more part(s).
Aggregation association models a whole-part relationship where the parts may exist independently of the whole. The whole does not govern the existence of the parts. You could say Orchestra is the whole and Clarinet is “part-of” Orchestra.
Temporary association, better known as dependency, is represented where one class requires the existence of another class. It’s also seen in cases where an object is used as a local variable, return value, or a member function argument. Passing a frequency to a tune method of class Clarinet
can be read as class Clarinet
depends on class Frequency
, or Clarinet “uses-a” Frequency.
UML sequence diagrams are used to show dynamic interaction between objects; see Figure C-7. The collaboration starts at the top of the diagram and works its way toward the bottom.
A found message is one in which the caller is not represented in the diagram. This means that the sender is not known, or does not need to be shown in the given diagram.
A synchronous message is used when the source waits until the target has finished processing the message.
The return call can optionally depict the return value and is typically excluded from sequence diagrams.
An asynchronous message is used when the source does not wait for the target to finish processing the message.
A message to self, or self-call, is defined by a message that stays within the object.
3.145.188.160