UML (Unified Modeling Language )

1. UML(Unified Modeling Language) Prof Hyoung-Joo Kim OOPSLA Lab. School of Computer Science and Engineering Seoul National University

2. Contents • Introduction • Software Development • Object-Oriented Analysis • Object-Oriented Design • Summary

3. Introduction • UML? • The successor to the wave of OOA&D methods that appeared in the late ’80s and early ’90s • Unification of the methods of Booch, Rumbaugh, and Jacobson • The standard of OMG (Object Management Group)

4. History(1/2) • UML motivation • To create a set of semantics and notation that can adequately address all scales of architectural complexity across all domains • Each of OO methods were recognized as having certain strengths • Base methods • Booch, Rumbaugh(OMT), Jacobson(OOSE)

5. History(2/2) Standard Object Modeling Language by OMG, Sep ‘97 Industrialization Publication of UML 1.0, Jan ‘97 Standardization UML 1.0 Jun ‘96 & Oct ‘96 UML Partner s’ Expertise UML 0.9 & 0.91 Unification OOPSLA ‘95 Unified Method 0.8 Booch ’93 OMT-2 Fragmentation other methods Booch ‘91 OMT-1 OOSE

6. Scope of the UML(1/2) • Language for specifying constructing, visualizing, and documenting the artifacts of a software-intensive system • Fusing the concepts of Booch, OMT, and OOSE • Envelop of what can be done with existing methods • Standard object modeling language adopted by OMG, Sep., 1997

7. Scope of the UML(2/2) • Object-Oriented Analysis • Use Case diagram • Object interaction diagram • Class diagram • State diagram • Activity diagram • Object-Oriented Design • Process diagram • Architecture diagram • Deployment diagram

8. Comparing to Others(1/2) • Not a radical departure from Booch, OMT, and OOSE • Legitimate successor to all three methods • More expressive yet cleaner and more uniform • Value in moving to the UML • It will allow projects to model things they could not have done before • It removes the unnecessary differences in notation and terminology

9. Comparing to Others(2/2) Class Diagram Terminology UML Class Association Generalization Aggregation Booch Class Uses Inherits Containing Coad Class & Object Instance Connection Gen-Spec Part-Whole Jacobson Object Acquaintance Association Inherits Consists of Odell Object type Relationship Subtype Composition OMT Class Association Generalization Aggregation Shlaer/Mellor Object Relationship Subtype N/A

10. Contents • Introduction • Software Development • Object-Oriented Analysis • Object-Oriented Design • Summary

11. Phases of a Development Cycle 0. Requirement analysis Use Case analysis Requirement specification 1. Analysis UML diagram 4. Test 2. Design 3. Code UML diagram

12. Phase of Development • Requirement Analysis • Analysis • Design • Code • Test

13. Contents • Introduction • Software Development • Object-Oriented Analysis • Object-Oriented Design • Summary

14. OO Analysis Phase 1. Use Case Modeling Phase 2. Class Finding & Refinement Phase 3. Object Finding Phase 4. Class Relationship Phase 5. Class Specification Phase 6. Analysis Refinement

15. OOA Phase 1. Use Case Modeling • Introduced by Jacobson(1994) • Use Case modeling by user requirement • Relationship among actors and Use Cases • Actors carry out Use Cases • Use Case is a typical interaction between a user and a computer system • <<extends>> relationship : similar but do a bit more • <<uses>> relationship : a chunk of behavior similar across more than one use case

16. Use Case for a financial trading system Update Accounts Set Limits Trading Manager Trader Salesperson Accounting System Analyze Risk <<uses>> Actor <<uses>> Valuation Price Deal Capture Deal <<extends>> Use Case Limits Exceeded Use Case Diagram

17. OOA Phase 2. Class Finding & Refinement • For each Use Case, finding classes • Class Finding • Class Diagram • Class Refinement • Remove redundant • Name same, semantics different

18. Class • The name of a class has scope within the package in which it is declared and the name must be unique (among class names) within its package • References • Show a reference to a class defined in another package • Package-name::class-name aaa

19. Class Diagram • Showing the static structure of the system • A graph of modeling elements shown on a two-dimensional surface • A collection of (static) declarative model elements, such as classes, types, and their relationships, connected as a graph to each other and to their contents

20. Type • A type is descriptor for objects with abstract state, concrete external operation specification, and no operation implementations • Classes implement types • Shown as a stereotype of a class symbol with the stereotype <<type>> • May contain lists of abstract attributes and of operations • May contain a context and specifications of its operations accordingly

21. Examples of Class Diagram Windows Windows {abstract, author = Joe, status=tested} +size: Area=(100,100) #visible: Boolean=invisible +default-size: Rectangle #maximum-size: Rectangle -xptr: Xwindow* class name Windows attributes size: Area visibility: Boolean +display ( ) +hide ( ) +create ( ) -attachXWindow(xwin:Xwin*) display ( ) hide ( ) methods

22. << controller >> PenTracker { abstract } Name Compartment • Displays the name of the class and other properties in up to 3 sections • An optional stereotype keyword, the name, a property list

23. OOA Phase 3. Object Finding • For each class, finding objects, and making object interaction diagram • Sequence Diagram • Collaboration Diagram • Finding messages within objects

24. Object Diagram • A graph of instances • Static object diagram is an instance of a class diagram • Dynamic object diagram shows the detailed state of a system over some period of time • Class diagrams can contain objects, so a class diagram with objects and no classes is an “object diagram”

25. Sequence Diagram(1/2) • Showing an interaction arranged in time sequence • Showing the explicit sequence of messages • Better for real-time specifications and for complex scenarios

26. The horizontal dimension represents different objects :caller :exchange :receiver lift receiver a {b-a < 1 sec.} dial tone b {c-b < 10 sec.} dial digit c .... The call is routed through the network {d’-d < 5 sec.} d route d’ ringing tone phone rings answer phone At this point the parties can talk stop tone stop ringing • The vertical dimension represents time Sequence Diagram(2/2) Sequence diagram for concurrent objects

27. Collaboration Diagram(1/2) • Showing the relationships among objects • Better for understanding all of the effects on a given object and for procedural design • Showing an interaction organized around the objects in the interaction and their links to each other • Not showing time as a separate dimension

28. Collaboration Diagram(2/2) Self-Delegation Object : Order Entry Window 1: prepare() Message Sequence number : Order 5 : needToReOrder() 3: check() 4: [check == true] remove() 2* : prepare() Macallan line : Order Line Macallan stock : Stock Item 7: [check == true] new 6: new : Delivery Item : Reorder Item

29. OOA Phase 4. Class Relationship • Finding class relationships from Object Diagrams • Is-A • Aggregation • Link • Relationship which is not Is-A, nor Aggregation • Between classes that exchange messages

30. Association Relationship • Association relationship is drawn as a solid path connecting two class symbols • OR-association • Only one of several potential associations may be instantiated at one time for any single object • Works-for 1..* * Company Person Person employer employee Account {or} Job salary boss Corporation 0..1 worker * • Manages

31. Aggregation & Composition • Aggregation • Part of relationship • Composition Relationship • Form of aggregation with strong ownership and coincident lifetime of part with the whole • The multiplicity of the aggregate end may not exceed one

32. Example of Aggregation and Composition Aggregation and Composition Graphics Bundle color texture 1 Composition relationship Polygon 1 1 Aggregation relationship {ordered} 3..* Point

33. Shape Shape {overlapping} {overlapping} Polygon Ellipse Spline Polygon Ellipse Spline Generalization • Taxonomic relationship between a more general element and a more specific element

34. OOA Phase 5. Class Specification • Attribute • Behavior • By object interaction diagrams • Operation

35. Attribute • A text string that can be parsed into the various properties of an attribute model element • The default syntax • Visibility name:type-expression=initial-value{property-string} • Visibility • + public • # protected • - private • A class-scope attribute is shown by underlining the entire string

36. Operation • A text string that can be parsed into the various properties of an operation model element • Visibility name (parameter-list): return-type-expressoin=initial-value{property-string} • Visibility • + public • # protected • - private • Parameter-list • name: : type-expression = default-value

37. Examples of Attributes and Operations Windows Windows {abstract, author = Joe, status=tested} +size: Area=(100,100) #visible: Boolean=invisible +default-size: Rectangle #maximum-size: Rectangle -xptr: Xwindow* class name Windows attributes size: Area visibility: Boolean +display ( ) +hide ( ) +create ( ) -attachXWindow(xwin:Xwin*) display ( ) hide ( ) methods

38. OOA Phase 6. Analysis Refinement • Review all processes of analysis

39. Other UML Diagrams • By user needs • State Diagram • Activity Diagram

40. State Diagram(1/2) • A familiar technique to describe the behavior of a system • Describe all the possible states a particular object can get into and how the object’s state changes as a result of events • Drawn for a single class to show the lifetime behavior of a single object

41. transition Active phone# Timeout do/play message lift receiver /get dial tone dial digit(n) [incomplete] 15 sec. 15 sec. Idle guard dial digit(n) DialTone do/play dial tone Dialing start dial digit(n)[invalid] dial digit(n)[valid] /connect state caller hangs up /disconnect Invalid do/play message Connecting transition : event[guard(logical condition)]/action State Diagram(2/2)

42. Activity Diagram(1/2) • A special case of a state diagram in which all of the states are action states and in which all of the transitions are triggered by completion of the actions in the source states • Use activity diagrams in situations where all or most of the events represent the completion of internally-generated actions • Use ordinary state diagrams in situations where asynchronous events occur

43. Activity Diagram(2/2) [no cola] [no coffee] Find Beverage [found coffee] [found cola] Add Water to Reservoir Put Coffee in Filter Get Cups Put Filter in Machine Get cans of cola Turn on Machine ^coffeePot.turnOn Brew coffee light goes out Drink Pour Coffee

44. Contents • Introduction • Software Development • Object-Oriented Analysis • Object-Oriented Design • Summary

45. OO Design • Add implementation classes (DLL, …) • Process • Consider the performance • Deployment Diagram • Architecture diagram • System placement • Component Diagram • Interface

46. Hashable String HashTable ..... * isEqual(String):Boolean contents hash():Integer Comparable <<uses>> <<interface>> Comparable isEqual(String) : Boolean hash():Integer Interface • The use of type to describe the externally-visible behavior of a class component, or other entity

47. <<implementation class>> HashTableSet elements : Collection addElement(Object) removeElement(Object) testElement(Object) : Boolean setTableSize(Integer) <<type>> Set elements : Collection addElement(Object) removeElement(Object) testElement(Object) : Boolean Types and Implementation Class <<type>> Collection <<implementation class>> HashTable Realize relationship

48. Implementation Diagram • Show aspects of implementation, including source code structure and run-time implementation structure • Component Diagrams • Show the structure of the code itself • Deployment Diagrams • Show the structure of the runtime system

49. Deployment Diagram Scheduler AdminServer:HostMachine <<database>> meetingsDB reservations Scheduler reservations Planner update GUI Joe’sMachine:PC Planner

50. Summary • UML is a standard for OOA&D • Software Development • Requirement Analysis • Object-Oriented Analysis • Object-Oriented Design • Code • Test