Unified Modeling Language (UML)

1. (Chapter 6) Unified Modeling Language (UML)

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

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

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

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

6. ClassName Attribute : Type Operation() : returnType The Class Icon

7. Example: Simplest Class Diagram 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 Circle radius : double center : Point setCenter(Point) setRadius(double) area() : double circumference() : double This typing convention is used to create separation between the design and an implementational language.

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

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

10. 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 B role B role A

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

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

13. Multiplicities Class 1 exactly one Class * many (zero or more) Class 0..1 optional (zero or one) Class m..n numerically specified

14. Example of Associational Relationship Game Board 1 0..1 state : long integer playAgain : bool board promptPlayAgain():bool newBoard() : Board update(Move) display() 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.

15. Classes can be Self-Associated Linked_List 1 next data : someType setData(someType) getData() : someType 1 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.

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

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

18. Diagram of Compositional Relationship Circle Point 1 1 center x : double y : double radius : double center : Point setCenter(Point) setRadius(double) area() : double circumference():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.

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

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

21. 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. Implementation of Composition (cont'd)

22. Another Composition Example Square 1 uLeft 2 Point lRight setCorners(Point,Point) area() : double class Square{ public: void setCorners(const Point&, const Point&); double area(void) const; private: Point uLeft; Point lRight; };

23. Aggregation • Indicated with a non-blackened diamond • Weaker than composition regarding object lifetimes • Can be represented simply through multiplicities

24. Aggregation Example lChild BinaryTree 0..2 rChild leftChild() : BinaryTree rightChild() : BinaryTree 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.

25. Example Structural Relationship Diagram 0..1 School Department 1..* 1 1..* 1..* 1..* 0..1 chairperson * 1..* 1..* Student Course Instructor * * * 1..*

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

27. 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}

28. Example Generalization Diagram Queue Item 1 maxSize: Integer front: Integer rear: Integer * items display(): void add(Item): void remove(): Item empty(): Boolean full(): Boolean FrontQueue FrontQueue

29. Example Multiple Inheritance Diagram InterestBearing Insurable Asset Bank Account Real Estate Security Checking Savings Stock Bond

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

31. Dependency Diagram Board Move state : Integer dir : Direction updateBoard(m : Move) nextMove() : Move or Board Move state : Integer dir : Direction updateBoard() nextMove() : Move