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 : double center : Point setCenter(Point) setRadius(double) area() : double circumference() : double An Attribute is followed by a colon and its type An Operation is followed by a colon and its return type Parameters are types only or name : 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 AClass B role 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 Class 1 exactly one Class * many (zero or more) Class 0..1 optional (zero or one) Class m..n numerically specified

Example of Associational Relationship Game playAgain : bool promptPlayAgain():bool newBoard() : Board Board state : long integer update(Move) display() 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 next1 Linked_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 : double center : Point setCenter(Point) setRadius(double) area() : double circumference():double Point x : double y : double setX(double) setY(double) getX() : double getY() : double The blackened diamond represents composition. The arrowhead implies that the Point does not know about the Circle. The role relationship is to provide a center point for Circle objects. Note the unnecessary redundancy in the Circle attribute box, and the 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 within point.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 SquarePoint 2uLeft 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() : BinaryTree rightChild() : BinaryTree rChild lChild 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 SchoolDepartment StudentCourse 1 1..* * * 0..1 chairperson 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: Integer front: Integer rear: Integer display(): void add(Item): void remove(): Item empty(): Boolean full(): Boolean FrontQueue Item * items 1

Example Multiple Inheritance Diagram InterestBearingInsurable Asset Bank AccountReal EstateSecurity CheckingSavingsStockBond

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