Introduction to Unified Modeling Language UML By Mercer

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

Models Use Case: Process Sale Dice Game. . . Main Success Scenario 1. Customer arrives with … 2. Cashier … 3. … play() roll() fv 1: =get. Face. Value() fv 2: =get. Face. Value() roll() 4. Extensions: 5. 3 a. … 2

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 3

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 4

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 5

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 6

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 7

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 8

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 class name in a rectangle - or like the general form shown on the next slide 9

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

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 = initial. Value <<sterotype>> (see slide 16 for <<stereotype>>) 11

Methods/Operations ¨ Set and get methods for attributes ¨ Methods often have input arguments ¨ Communicate with other objects ¨ Notation for methods: visibility name(param 1: type 1, …) : return. Type <<stereotype>> 12

Attributes and Methods ¨ Visibility: + public, # protected, - private, ~ package AClass + public. Attr: Class 1 # protected. Attr: Class 2 - private. Attr: Class 3 ~ package. Attr: Class 4 ¨ Class attributes and methods + public. Operation() # protected. Operation() - private. Operation() ~ package. Operation() 13

Software Specification (Class Name) attribute : type = initial value class. Attribute derived. Attribute. . . method 1() method 2(parameter : Type) : return type abstract. Method() +public. Method() -private. Method() #protected. Method() class. Method(). . . 14

Account. Collection - all. Accounts : Hash. Map +Account. Collection () +get. Account. With. ID (ID: String) : Account +add(account. To. Add: Account) : boolean +iterator() : Iterator Note: iterator is needed by the bank manager 15

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 <<interface>> Iterator +has. Next(): boolean +next(): Object +remove(): void 16

UML Stereotype vs. UML property ¨ Stereotype, e. g. , <<utility>> - 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 << utility >> Symbol. Table Polygon {abstract} 17

Parameterized Classes (Templates) Set T T Set <<bind>> <car> Set<Car> Fleet= Set<Car> Fleet 18

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 19

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

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 Card. Reader CDCollection Song. Selector 21

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 association Jukebox get. Account. With. ID 1 1 Jukebox. Account. Collection 22

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 Account. Collection need to remember Accounts? Account. Collection Stores 1 1. . * Account 23

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

Multiplicity ¨ Multiplicity defines how many instances of type A can be associated with one instance of type B at some point can differ Game Mother Actor 1 2. . 6 1 1+ performs-in * can label associations * Player Child Film Actor is associated with 0 to many films. A film is associated with 0 to many actors 25

Depends on Context ¨ Are all three associations possible? Car Car 1 1 1 4 5 3 Wheel 26

Association Names Upcase / hyphenate ¨ Read this Type-Verb. Phrase-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 27

Class Diagrams ¨ Static structure of the classes of objects ¨ Three important OO constructs - Inheritance - Association - Part/whole structure 28

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

Subclass Partitioning, Examples Powered. Vehicle Airplane Car Employee Manager Disjoint (No airplane can be a car), incomplete (Trucks are powered vehicles too) hierarchy Non-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 30

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

Class Diagrams enrolled Student Name Address Phone Number Email Address Student Number Average Grade Is Eligible To Enroll Provide Seminars Taken 1 Enrollment 1. . * Marks Received Provide Avg to Date Provide Final Grade 0. . * on waiting list 1. . * 1 in Seminar Name Seminar Number Fees Add Student 0. . * Delete Student - name: string - phone. Number: Phone. Number … +is. Eligible(name: string, student. Number: Student. Number): bool +Student(student. Number: Student. Number): Student <<constructor>> +get. Average. Grage(): long +provide. Seminars. Taken(): Vector 32

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 33

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 34

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 35

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 Hash. Map of Students School 1. . * * Student 36

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. School 1. . * 1 1. . * Department * Student - Model aggregation or composition? When in doubt, use association (just a simple line) 37

Composition/Aggregation Notations (UML 1. x) 38

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? 39

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? 40

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 41

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

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! 43

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 44

Sequence Diagrams ¨ Objects are lined up on top in rectangles ¨ Object names : the. Jukebox ¨ 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 45

46

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