Unified Modeling Language (UML)

(Chapter 6)

Unified Modeling Language

UML October 1994 Three Amigos

Grady Booch (Rational Software) [Booch] James Rumbaugh (Objectory) [OMT] Ivar Jacobson (General Electric) [OOSE]

Modeling language = mainly graphical notation that a modeling process uses to express designs

Why Model?

Simplification of reality

Better understand a complex system visualization of the system specification of structure or behavior of the system implementational template documentation

Facilitate finding the "best" solution

Communication tool

UML is a:

Language for visualization graphical representation (static and dynamic)

Language for specifying precise, unambiguous, and complete

Language for constructing mapping from UML to OO programming language

Language for documenting requirements, architecture, design, source code, plans,

testing, prototypes, releases

Static Models in the UML(Class Diagrams)

Purpose To depict classes and their attributes (data members),

operations (methods) and relationships to other classes

Primary diagram structure Class icon: rectangle divided into three compartments

Name, attributes, operations

Various types of connecting lines depict various types of relationships with other classes

The Class Icon

ClassName

Attribute : Type

Operation() : returnType

Example: Simplest Class Diagram

Circle

radius : doublecenter : Point

setCenter(Point)setRadius(double)area() : doublecircumference() : double

An Attribute is followed by acolon and its type

An Operation is followed by acolon and its return type

Parameters are types only orname : type

This typing convention is used to create separation between the design and an implementational language.

Relationships between Classes

Where the power in a static diagram resides Association - an object of one class is connected

to objects of another class Class roles Aggregation - a "whole" object of one class is made up of

"parts," which are other objects Composition - stronger form of aggregation

Relationships between Classes (cont)

Generalization - an object of one class is a kind of object of another class Inheritance

Dependency - an object of one class uses the services of (and therefore depends on) another object of a different class

Association Represents a relationship between instances of

two classes Each association has two association ends,

attached to one of the classes in the association An end can be explicitly named with a label, or

role name.

Class A Class Brole A

role B

Roles

A role name becomes a data field name in the associated class definition

For example, role B becomes a data field name in the definition of class A

In the absence of a role name, the association end name is derived from the class attached to that end

Association and Navigability

An arrowhead on an association end indicates navigability; the target class is known about by the other class

Lack of arrowheads on an association indicates that the relationship is bidirectional

Additional notations indicate multiplicities

Multiplicities

Class1 exactly one

Class* many (zero or more)

Class0..1 optional (zero or one)

Classm..n numerically specified

Example of Associational Relationship

Game

playAgain : bool

promptPlayAgain():boolnewBoard() : Board

Board

state : long integer

update(Move)display()

0..11

board

This diagram depicts one Game being associated with zero or one Boards. The arrowhead creates a directional relationship, meaning the Game knows about the Board, but not vice versa. The name on the arrow is called a role. The numbers are called multiplicities.

Classes can be Self-Associated

data : someType

setData(someType)getData() : someType

next1Linked_List

The members of a linked-list may have differing lifetimes and their children may change. Therefore, the nodes of a linked-list have relatively weak relationships.

1

Composition: A Strong Relationship

``Has-a'' relationship When one class of object is composed of at least

one instance of another class, we say that class "is made of" or "is composed of" (at least partially) the second class

An object can be part of only one other object The multiplicity of the composing object is

always 1

Composition and Lifetimes

The composition relationship implies that the life span of the second class is coincident with that of the first class:

The constructor and destructor of the second class are called in constructor and destructor of the first class

Diagram of Compositional Relationship

Circle

radius : doublecenter : Point

setCenter(Point)setRadius(double)area() : doublecircumference():double

Point

x : doubley : double

setX(double)setY(double)getX() : doublegetY() : double

The blackened diamond represents composition. The arrowheadimplies that the Point does not know about the Circle. The rolerelationship is to provide a center point for Circle objects.Note the unnecessary redundancy in the Circle attribute box, andthe unnecessary multiplicity on the diamond.

center

1 1

More on Composition

Arrowheads restrict the directionality of relationships, like in all classes of associations

If the arrowhead had been missing in the last diagram, the implementational implication would have been that

#include "circle.H"

is withinpoint.H

so arrowheads tend to be the norm

Implementation of Composition

class Point{public:

void setX(double);void setY(double);double getX(void) const;double getY(void) const;

private:double x;double y;

};

Notice that Point knows nothing about Circles

Implementation of Composition (cont'd)

class Circle{public:

void setCenter(const Point&);void setRadius(const double);double area(void) const;double circumference(void) const;

private:double radius;Point center;

};

Here it is obvious that the Point data member lives and dies with the Circle. The Point could be implemented using a pointer, in which case it would have to be deleted in the Circle destructor.

Another Composition Example

Square Point2uLeft

lRight

setCorners(Point,Point)area() : double

class Square{public:

void setCorners(const Point&, const Point&);double area(void) const;

private:Point uLeft;Point lRight;

};

1

Aggregation

Indicated with a non-blackened diamond

Weaker than composition regarding object lifetimes

Can be represented simply through multiplicities

Aggregation Example

BinaryTree

leftChild() : BinaryTreerightChild() : BinaryTree

rChild

lChild

0..2

1

A binary tree would not be a tree, if it were not for its containing (aggregating) two of its own type. A node may contain zero to two children.

Example Structural Relationship Diagram

* *

1..*

Instructor

School Department

Student Course

11..*

1..*

* 1..*

1..*

* 1..*

1..*

0..1chairperson

0..1

Generalization Diagrams

Shows the "is-a" relationship between a general class of objects (superclass or parent) and their specializations (subclass, child or derived class)

Implies the child objects can be used in place of a parent, but not vice versa

Inherited attributes and/or operations are not repeated in the subclasses, unless they are polymorphic (virtual)

Generalization Diagrams (cont'd)

Abstract classes have names Italic font {Abstract} label next to name

Virtual operations Italic font Can also be labeled with {Abstract}

Example Generalization Diagram

Queue

maxSize: Integerfront: Integerrear: Integer

display(): voidadd(Item): voidremove(): Itemempty(): Booleanfull(): Boolean

FrontQueue FrontQueue

Item

*items

1

Example Multiple Inheritance Diagram

InterestBearing Insurable

Asset

Bank Account Real Estate Security

Checking Savings Stock Bond

Dependency

Represents a "using" relationship

Implies a change in an object of one class may effect an object in another class which uses that object

The reverse is not necessarily true

The object depended on is not contained in the depending class object

Usually implemented as member function arguments

Dependency Diagram

Board

state : Integer

updateBoard(m : Move)

Move

dir : Direction

nextMove() : Move

or

Board

state : Integer

updateBoard()

Move

dir : Direction

nextMove() : Move