Unified Modeling Language (UML)
The Unified Modeling Language (UML) is a notation for expressing object-oriented designs. The notation, which is mainly graphical, comprises various kinds of diagrams for presenting different views of a design. UML diagrams are useful for understanding, implementing, communicating, and documenting a design -- they serve as a blueprint for the system. Since being adopted in 1997 as a standard by the Object Management Group (OMG), a consortium of companies promoting the use of standardized object systems, UML is gaining broad acceptance as the modeling language of choice.
UML tools such as Rational Rose are widely used.
We will use only a small subset of the UML to illustrate system designs. Class diagrams will be used to show the static structure of systems. A class diagram identifies classes and shows how they are related. Objects that exist while the system executes are instances of these classes, and the links between objects correspond to associations between their respective classes.
A class diagram shows the classes relevant to a portion of a system, as well as the relationships between the classes. A class is represented most simply as a box that encloses the class name. For more detail, the box may include a compartment for key attributes and a compartment for key methods. The attributes and methods may be typed if desired. Some or all of the attributes or methods may be omitted in order to highlight the remaining members and/or class relationships. Three consecutive dots are sometimes included to indicate that some attributes or methods have been omitted.
The class name may be preceded with a stereotype that further characterizes the class; examples include abstract or interface. Elements that are abstract (including the names of abstract classes and interfaces) appear in italics.
Each attribute is specified on a separate line with its type followed by its name. An alternative notation is to specify the attribute name, followed by a colon, followed by the type.
Each method is specified on a separate line with its return type, followed by its name, followed by a parameter list. Constructor methods have no return type. Parameters are specified by their type, but may not be named. An alternative notation is to list the return type at the end, preceded by a colon.
Every attribute and method is optionally preceded by a symbol to indicate its scope. The appropriate symbols are public (+), private (-), and protected (#). Methods can be grouped into categories that are preceded by notations like constructor, query (accessor), or update (mutator).
The UML notation for an object consists of a rectangle with the object name, followed by a colon, followed by the class name.
A second compartment can be added to specify the attribute values for that object, and lists the attribute name followed by an equals sign and the value.
There is an association between two classes if it is possible for instances of one of the classes to create or send messages to instances of the second class. An association is shown by a line that connects the two class boxes.
One-way navigability may be shown by attaching an arrow to one end of the line; messages may be sent only in the direction indicated by the arrow. The next diagram indicates that instances of
Source may send messages to instances of Target, but not the reverse. If the arrows are omitted, navigability is either two-way -- instances of either class can send messages to instances of the other class -- or left unspecified.
Multiplicity values (also called cardinality constraints) may be included at either or both ends of a line linking two class boxes. The multiplicity values indicate the number of objects involved in the relationship. The variables that appear in the following notation represent non negative
The next diagram shows that an instance of Class A is associated with between four and seven instances of Class B, and that an instance of Class B is associated with exactly one instance of Class A.
Composition is a kind of association (and is sometimes referred to as an association) that models the whole-part relationship between classes. Objects of one class (the composite) own, or interact with, instances of the second class. Composition is shown by including a filled diamond on the composite's end.
In the following diagram, a Class
A object owns one or more instances of Class B.
Aggregation is another kind of association that models the whole-part relationship between classes.
Also known as containment, aggregation expresses a "has a"
relationship in which objects of one class (the composite), are made up of instances of the second class (its components).
In aggregation, a class object has as attributes one or more objects of other
classes. Aggregation is shown by including a hollow diamond on the whole's end.
The class diagram below shows that a Class A object contains two Class B objects. The multiplicity values also indicate that a Class B object may be shared by any number of Class A objects.
Inheritance is shown by including a hollow triangle on the parent class end of the line joining two classes. A solid line is used to show extension and a dashed line to show implementation of an interface. Inheritance expresses an "is a" relationship.
In following diagram, classes Subtype 1 and Subtype 2 both extend Supertype, and Subtype 2 implements Interface 1.
Additional UML graphical notation