Java 8 Pocket Guide (2014)

Part III. Appendixes

Appendix C. UML Basics

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).

Class Diagrams

A class diagram represents the static structure of a system, displaying information about classes and the 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.

Figure C-1. Class diagram

// 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) {...}

}

Name

The name compartment is required and includes the class or interface name typed in boldface.

Attributes

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.

Operations

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.

TIP

{property-string} can be any of several properties such as {ordered} or {read-only}.

Visibility

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.

Table C-1. Visibility indicators

Object Diagrams

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.

Table C-2. Object names

Object diagrams are not frequently used, but they can be helpful when detailing information, as shown in Figure C-2.

Figure C-2. Object diagram

Graphical Icon Representation

Graphical icons are the main building blocks in UML diagrams; see Figure C-3.

Figure C-3. Graphical icon representation

Classes, Abstract Classes, and Interfaces

Classes, abstract classes, and interfaces are all represented with their names in boldface within a rectangle. Abstract classes are also italicized. Interfaces are prefaced with the word interface enclosed in guillemet characters. Guillemets house stereotypes and in the interface case, a classifier.

Notes

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.

Packages

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.

Figure C-4. Package diagrams

Connectors

Connectors are the graphical images that show associations between classes. Connectors are detailed in Class Relationships.

Multiplicity Indicators

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.

Table C-3. Multiplicity indicators

Role Names

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.

Figure C-5. Role names

Class Relationships

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.

Association

An association denotes a relationship between classes and can be bidirectionally implied. Class attributes and multiplicities can be included at the target end(s).

Figure C-6. Class relationships

Direct Association

Direct association, also known as navigability, is a relationship directing the source class to the target class. This relationship can be read as “Orchestra has a Clarinet.” Class attributes and multiplicities can be included at the target end. Navigability can be bidirectional between classes.

Composition Association

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. This can be read as “Score is composed of” one or more parts.

Aggregation Association

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. This can be read as “Orchestra is the whole and Clarinet is part of Orchestra.”

Temporary Association

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 Clarinetcan be read as class Clarinet depends on class Frequency, or “Clarinet use a Frequency.”

Generalization

Generalization is where a specialized class inherits elements of a more general class. In Java, we know this as inheritance, such as class extends class Woodwind, or “Clarinet is a Woodwind.”

Realization

Realization models a class implementing an interface, such as class Clarinet implements interface Instrument.

Sequence Diagrams

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.

Figure C-7. Sequence diagrams

Participant (1)

The participants are considered objects.

Found Message (2)

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.

Synchronous Message (3)

A synchronous message is used when the source waits until the target has finished processing the message.

Return Call (4)

The return call can optionally depict the return value and is typically excluded from sequence diagrams.

Asynchronous Message (5)

An asynchronous message is used when the source does not wait for the target to finish processing the message.

Message to Self (6)

A message to self, or self-call, is defined by a message that stays within the object.

Lifeline (7)

Lifelines are associated with each object and are oriented vertically. They are related to time and are read downward, with the earliest event at the top of the page.

Activation Bar (8)

The activation bar is represented on the lifeline or another activation bar. The bar shows when the participant (object) is active in the collaboration.