1. Introduction to Unified Modeling Language (UML) By Mercer & Milanova, updated by Professor Spiegel, with help from The Unified Modeling Language User Guide, Grady Booch, James Rumbaugh, Ivar Jacobsen, Addison Wesley, 1999, ISBN 0-201-57168-4

2. 2 Models Use Case: Process Sale Main Success Scenario 1.Customer arrives with … 2.Cashier … 3.… Extensions: 3a. … roll() fv1:=getFaceValue() fv2:=getFaceValue() play() Dice Game...

3. 3 UML  UML - Unified Modeling Language  Standard for diagramming notation  Just a notation, not a methodology or process  Important  …but not as important as analysis and design patterns

4. 4 The Unified Modeling Language (UML)  UML or Unified Modeling Language comes from Rumbaugh, Booch, and Jacobson, who combined efforts to standardize on one modeling language  This is primarily a graphical communication mechanism for developers and customers

5. 5 UML  The main purpose of UML is to  support communication about the analysis and design of the system being developed  support the movement from the problem domain in the "world" to the solution domain in the machine  two views of the same system one view has diagrams source code is another view

6. 6 UML Defined by the Authors The Unified Modeling Language User Guide, Booch, Rumbaugh, Jacobson states: The UML is a language for  visualizing  specifying  constructing  documenting the artifacts of a software intensive system

7. 7 UML is a Modeling Language  UML  graphical notation to describe software design  has rules on how to draw models of  classes  associations between classes  message sends between objects  has become the de facto industry standard  Not official, but everyone uses it  Like a blueprint to show what is going on during analysis, design and implementation  Some Projects require UML documentation

8. 8 Designer Goals 1.Simpler UML within general comprehensive UML 2.Usefulness in several modeling perspectives - design, analysis, etc. 3.Correspondence to code 4.Computer aided as well as manual usage

9. 9 Class Diagrams  A class diagram  expresses class definitions to be implemented  lists name, attributes, and methods for each class  shows how instances will connect to others  UML allows different levels of detail on both the attributes and the methods of one class  could be just the the class name in a rectangle  or like the general form shown on the next slide

10. 10 Classes, Attributes and Operations AClass attributes operations AClass Obj : AClass

11. 11 Attributes  Information about the object  Is it synonymous with a variable?  Yes, most of the time  Sometimes needs manipulation  Derived from other attributes  Gettable and settable  Read-only  Notation for attributes: visibility name: type = initialValue > (see slide 16 for >)

12. 12 Methods/Operations  Set and get methods for attributes  Methods often have input arguments  Communicate with other objects  Notation for methods: visibility name(param1: type1,…) : returnType >

13. 13 Attributes and Methods  Visibility: + public, # protected, - private, ~ package AClass + publicAttr: Class1 # protectedAttr: Class2 - privateAttr: Class3 ~ packageAttr: Class4 + publicOperation() # protectedOperation() - privateOperation() ~ packageOperation()  Class attributes and methods

14. 14 Software Specification (Class Name) attribute attribute : type attribute : type = initial value classAttribute derivedAttribute... method1() method2(parameter : Type) : return type abstractMethod() +publicMethod() -privateMethod() #protectedMethod() classMethod()...

15. 15 AccountCollection - allAccounts : HashMap +AccountCollection () +getAccountWithID (ID: String) : Account +add(accountToAdd: Account) : boolean +iterator() : Iterator Note: iterator is needed by the bank manager

16. 16 Sterotypes  Stereotype is a UML element that allows designers to extend the UML vocabulary  Often used to distinguish an abstract class name from an interface, both of which are written in italic > Iterator +hasNext(): boolean +next(): Object +remove(): void

17. 17 UML Stereotype vs. UML property  Stereotype, e.g., >  Represents a new modeling construct  Property, e.g., {abstract}  Represents a characteristic of an existing UML construct, for example a class can be abstract, or immutable  E.g., characteristics of classes > SymbolTable Polygon {abstract}

18. 18 Parameterized Classes (Templates) T Set Fleet= Set Fleet > Set T

19. 19 Different levels of detail  Tips for modeling  Express as much or as little detail as needed  Often, a rectangle with a name is enough  perhaps a method or an attribute clarifies  Simple is good  Sketches on paper or white board are effective

20. 20 Relationships  Three Relationships in UML 1) Dependency 2) Association 3) Generalization  Understanding these relationships is more important than the lines that UML uses

21. 21 1) Dependency: A Uses Relationship  Dependencies  occurs when one object depends on another  if you change one object's interface, you need to change the dependent object  arrow points from dependent to needed objects Jukebox CardReader CDCollection SongSelector

22. 22 2)Association: Structural Relationship  Association  a relationship between classes indicates some meaningful and interesting connection  Can label associations with a hyphen connected verb phrase which reads well between concepts JukeboxAccountCollectionJukebox getAccountWithID 11 association

23. 23 Associations  Associations imply  our knowledge that a relationship must be preserved for some time (1 ns to forever?)  Between what objects do we need to remember a relationship? Does a Transaction need to remember Account? Would AccountCollection need to remember Accounts? Account AccountCollection Stores 11..*

24. 24 Notation and Multiplicity Adornments  UML Association:  a line between two concepts and a name  they are bi-directional  can have a multiplicity  exist in class diagrams zero or more; "many" one or more one to fifty two exactly five T T T T * 1.. * 1..52 5 T 3, 5, 8 exactly three, five or eight Multiplicity adornments

25. 25 Multiplicity  Multiplicity defines how many instances of type A can be associated with one instance of type B at some point can differ MotherChild 11+ ActorFilm ** performs-in GamePlayer 12..6 can label associations Actor is associated with 0 to many films. A film is associated with 0 to many actors

26. 26 Depends on Context  Are all three associations possible? CarWheel 4 CarWheel 5 CarWheel 3 1 1 1

27. 27 Association Names Upcase / hyphenate  Read this Type-VerbPhrase-Type (POST is a Point of Sale Terminal)  Not yet worrying about messages, instance variables, data flow, or classes yet  Just shows which objects have associations

28. 28 Class Diagrams  Static structure of the classes of objects  Three important OO constructs  Inheritance  Association  Part/whole structure

29. 29 Inheritance: is-a  The generalization construct A BC {disjoint,complete}  Subclass partitioning  Disjoint vs. overlapping  Disjoint – single member cannot belong to both B and C  Incomplete vs. complete  Incomplete – there are members of A that are not members of either B or C  Dynamic vs. static  Dynamic – over time a member of B can become a member of C

30. 30 Subclass Partitioning, Examples PoweredVehicle AirplaneCar Disjoint (No airplane can be a car), incomplete (Trucks are powered vehicles too) hierarchy Employee ManagerNon-Manager Disjoint (No employee can be a manager and non-manager at the same time), complete (There are no other kinds of employees), and dynamic (a non-manager can become a manager and vice versa) hierarchy

31. 31 More Associations  Varying populations of relationships between instances of classes  Navigability  Multiplicity Person Dog Dog ownership 1* MultiplicitiesMeaning 0..1 zero or one instance. The notation n.. m indicates n to m instances. 0..* or *no limit on the number of instances (including none). 1exactly one instance 1..*at least one instance

32. 32 Class Diagrams Student Name Address Phone Number Email Address Student Number Average Grade Is Eligible To Enroll Provide Seminars Taken Seminar Name Seminar Number Fees Add Student Delete Student Enrollment Marks Received Provide Avg to Date Provide Final Grade 1 1..*1 0..* enrolled in on waiting list Student - name: string - phoneNumber: PhoneNumber … +isEligible(name:string, studentNumber: StudentNumber): bool +Student(studentNumber: StudentNumber):Student > +getAverageGrage():long +provideSeminarsTaken():Vector

33. 33 Some Problems: Modeling Whole/Part Associations  Composition  E.g., Glider has a component Tail  Composite object is the whole  Component is the part  Composite cannot exist without component  A component part of only one composite  Stronger: composite should create component  Stronger: if delete component, composite goes away too, i.e., cascading delete  Typically components of different kinds

34. 34 Whole/Part Associations  Aggregation, weaker than composition  E.g., City is an aggregate of houses  Aggregate is the whole  Constituent is the part  Aggregate may exist without constituents  Each object may be part of more than one aggregate  Typically, constituents are of same class

35. 35 Composition vs. Aggregation  In real world there are 7 or 8 varieties of whole/part relationships, but UML has only two constructs – composition and aggregation  Can be very difficult, and confusing to choose one

36. 36 Aggregation: A Special Association  Aggregation: whole/part relationships  An association that models HAS-A relationships  The objects can exist independently or each other  No one object is more important than the other  Place an open diamond on the whole  Could mean School has a HashMap of Students SchoolStudent 1..**

37. 37 Composition: A Special Association  Composition: Stronger relationship  One can not exist without the other  If the school folds, students live on  but the departments go away also  If a department closes, the school can go on AIC e.g.  Model aggregation or composition? When in doubt, use association (just a simple line) SchoolDepartment 11..* Student 1..* *

38. 38 Composition/Aggregation Notations (UML 1.x)

39. 39 Composition vs. Aggregation Examples  Class and students  Class is whole, students are parts  The class can exist without students (e.g., a class with 0 enrollment)  A student may be part of more than one class  Parts are of same kind (students)  What is it?

40. 40 Examples, cont.  Sliced bread and loafs  Sliced bread is whole, loafs are parts  Bread cannot exist without loafs  A loaf is part of only one sliced bread  What is it?

41. 41 Examples, cont.  A classroom and equipment (chairs, projectors, desks)  The classroom is the whole, equipment is part  Remove the equipment, not a classroom anymore.  Each chair, desk can be part of only one classroom  Parts are of different kinds

42. 42 Examples, cont.  Chair and parts  Chair cannot exist without parts  Each part can belong to exactly one chair  Parts are of different kinds

43. 43 Composition vs. Aggregation  So confusing, that UML 2.0 drops the aggregation notation! Is this a good thing?  What to do?  Model composition if  Clearly, a whole/part association  Clearly, the component is part of only one composite at a time (i.e., composite sort of manages component)  If in doubt leave it as an association!

44. 44 Sequence Diagrams  A class diagram shows a fixed (static) view of a system  A sequence diagram represents a dynamic view of a system by attempting to capture messages sends over time  Can document a scenario such as  User Selects Song

45. 45 Sequence Diagrams  Objects are lined up on top in rectangles  Object names :theJukebox  Dashed lines represent lifetime of objects  Rectangles are activation lines  When the object has control  Activation bar of the receivers of the message is smaller than the sender's activation bar  Not much detail written

46. 46

47. 47 A Sequence diagram is a model that describes how groups of objects collaborate in some behavior over time and capturing the behavior of a single use case. It shows the objects and the messages that are passed between these objects in the use case.