UML

From CS371p

The Unified Modeling Language (UML) is a system of graphical notation used for modeling software systems.

UML contains two categories of diagrams: structure diagrams and behavior diagrams. Naturally, structure diagrams represent the static structure of a system, and behavior diagrams represent how the elements of the system behave and interact with each other.

This particular article focuses on notation of the class diagram, which is an important subset of structure diagrams.

Contents 1 The Basics 1.1 Class Diagram 1.2 Inheritance 1.3 Associations 1.3.1 Bi-directional association 1.3.2 Uni-directional association 1.4 Packages 2 Beyond the Basics 2.1 Interfaces 2.2 More Associations 2.2.1 Association class 2.2.2 Aggregation 2.2.3 Reflexive associations 2.3 Visibility 3 UML 2 Additions 3.1 Instances 3.2 Roles 3.3 Internal Structures 4 Conclusions/Thoughts 5 References

The Basics

Class Diagram

The purpose of the class diagram is to show the types of classifiers, or data, being represented in the system. In UML, classifiers include the following data types:

• a class,
• an interface,
• a data type, or
• a component.

In UML notation, a class diagram is represented by a group of up to three boxes, or containers, stacked on top of each other:

• The top container shows the name of the class, and is the only required container.
• The middle container lists the attributes of the class, and is optional.

Valid notation formats for an attribute entry:

name : attribute type

name : attribute type = default value

• The bottom container lists the operations of the class, and is also optional.

The notation format for an operation entry is:

name(parameter list) : type of value returned

When an operation has parameters, the notation format for each parameter is

parameter name : parameter type

See Figure 1 for an example of a basic class diagram.

Inheritance

An essential concept of object-oriented programming and design, inheritance allows one (child) class to inherit the functionality of another class (its parent or super class), and add new functionality of its own.

UML notation for inheritance in a class diagram is a solid line drawn from the child class to the parent class, with a closed, unfilled arrow head pointing towards the parent class. See Figure 4 for an example of this notation.

An alternative notation in UML is the tree notation. Tree notation is essentially the same as basic inheritance notation, except that all the lines drawn to a parent class from its child classes merge together, somewhat like a tree branch. See Figure 5 for an example of tree notation inheritance.

Abstract classes and operations are indicated by italicizing the name of the class or operation.

Associations

Some objects in a system can be related to each other in one of five different ways, and UML provides notation for modeling these associations.

Bi-directional association

Both classes are aware of each other and their association. This is the default association type, and is modeled simply with a solid line drawn between the two classes. At either end of the line is a role name and multiplicity value. (see Figure 6)

Multiplicity values and their indicators:

• 0..1   Zero or one
• 1       One only
• 0..*    Zero or more
• *        Zero or more
• 0..5   Zero to five

Uni-directional association

Two classes are related, but only one is aware of the relationship. This relationship is modeled using a solid line drawn between the two classes, with an open arrowhead pointing to the known class. (see Figure 7)

Packages

UML provides an organizing element called packages that can be used to organize a model's classifiers into namespaces. There are two ways of representing packages:

• Draw a large rectangular container around the members of the package. The package's name is placed in a small rectangular "tab" atop the enclosing container. (see Figure 8)
• Draw a rectangle representing the package, with its members outside of the container. The name should now be placed inside the container, and the smaller rectangular "tab" remains on top to maintain consistency. The members of the package should have solid lines drawn to a small circle tangent to the package, which has a "+" symbol in it. (see Figure 9)

Beyond the Basics

Interfaces

While a class can have an actual instance of its type, an interface must have at least one class to implement it. An interface is drawn just the same as a class, but it also includes the text "<<interface>>" directly above the name in the top compartment. (see Figure 10)

Realizations/implementations of interfaces are shown, very similarly to inheritance, by the notation of a dotted line (rather than solid) with a closed, open arrowhead pointing towards the interface.

More Associations

Association class

If you need a class to store information about a relationship (association) between two classes, an association class can be used by connecting a dotted line from the solid association line to the association class. (see Figure 11)

Aggregation

An aggregation association can be used to model a "whole to its parts" relationship. Aggregation comes in two forms:

• Basic aggregation: used when the life-cycle of a part is independent of the whole class's life-cycle. Notation for a basic aggregation association is shown with a solid line drawn from the whole class to the part class, with an unfilled diamond on the whole class's end. (see Figure 12)

• Composition aggregation: used when the life-cycle of a part is dependent of the whole class's life-cycle. Notation is the same as a basic aggregation association except that the diamond is filled in. (see Figure 13)

Reflexive associations

A class can be associated with itself using a reflexive association. This does not mean that a class's instance is related to itself, but that its instance is related to another instance of the same class. A reflexive association is naturally represented the same as a normal association between two classes, except that the association line is drawn in a loop, from the side of the class container to the bottom. (see Figure 14)

Visibility

UML defines four types of visibility for class attributes and operations:

• + public
• # protected
• - private
• ~ package

These optional symbols should be placed to the immediate left of any attribute or operation names that you wish to specify visibility for in your system model. (see Figure 15)

UML 2 Additions

Instances

Sometimes it is useful to show actual (or example) instances of your classes in your system model. To represent an instance, use the following notation in the top compartment of a class container to notate that it is an instance:

Instance Name : Class Name

This line should be underlined as well. It is not necessary to include all of an instance's attributes and operations - only interesting/informational attributes and operations should be listed. (see Figure 16) UML also allows for the modeling of relationships between instances as well, as long as they are identical to those defined by the class diagram (in association relationships and association role names). (see Figure 17)

Roles

As instances can sometimes provide too much information, roles allow definition details at a more generic level. Role notation is very similar to instance notation, but you do not underline the words. In addition, role notation cannot be used in a class diagram, but only within the Internal Structure notation.

Internal Structures

The new notation of internal structure allows you to represent how the internal parts of a classifier relate to each other. To represent an internal structure, draw a large rectangular container that will house the internal structure diagram. On top of this large rectangle should be a shorter one (not a "tab" as used for packages, but a full-width rectangle) that contains the class name. (see Figure 20)

Conclusions/Thoughts

The UML system of graphical notation presented in the article allows software developers, business analysts, and other team members to gain a wide view of the project at hand, without having to sift through the details of the actual code base. This can be very useful to maintain an object-oriented perspective, and communicate design ideas within the team.

Remember, this is only part of the structure diagrams offered by UML. If this notational method interests you, be sure to check out the rest of UML (like behavior diagrams) via the links offered at the end of the article.

Alternatively, if you would like to read about criticisms and history of the UML and UML 2 systems, take a look at the Wikipedia article on UML.

References

[1] http://www.cs.utexas.edu/users/downing/papers/UML.pdf
[2] Wikipedia page on UML

Written by Michael Conlon!