Unified Modeling Language (UML)

Transcription

1 1 / 45 Unified Modeling Language (UML) Miaoqing Huang University of Arkansas

2 2 / 45 Outline 1 Introduction 2 Use Case Diagram 3 Class Diagram 4 Sequence Diagram

3 3 / 45 Outline 1 Introduction 2 Use Case Diagram 3 Class Diagram 4 Sequence Diagram

4 4 / 45 What is UML? UML is a modeling language A model is an abstraction describing a system Modeling language is used to express design Use notation for depicting models UML is the de facto modeling language in software engineering Created and managed by the Object Management Group, now at version (August 2011) Key persons: (three amigos) James Rumbaugh, Grady Booch, Ivar Jacobson UML includes a set of graphical notation techniques to create visual models of software-intensive systems 14 diagrams 7 structural diagrams 7 behavior diagrams

5 5 / 45 UML Diagrams

6 6 / 45 UML Diagrams Example use case diagram class diagram sequence diagram

7 7 / 45 UML Diagrams Example Use case diagram Describe the functional behavior of the system as seen by the user Class diagram Describe the static structure of the system: Objects, attributes, associations Sequence diagram Describe the dynamic behavior between objects of the system State machine diagram Describe the dynamic behavior of an individual object

8 8 / 45 UML Core Conventions All UML Diagrams denote graphs of nodes and edges Nodes are entities and drawn as rectangles or ovals Rectangles denote classes or instances Ovals denote functions Names of Classes are not underlined SimpleWatch Firefighter Names of Instances are underlined mywatch:simplewatch Joe:Firefighter An edge between two nodes denotes a relationship between the corresponding entities

9 9 / 45 Use Case Diagram Use case diagrams represent the functionality of the system from user s point of view Use case Actor ReadTime WatchUser SetTime WatchRepairPerson ChangeBattery

10 10 / 45 Class Diagram Class diagrams represent the structure of the system Association Class Multiplicity 2 PushButton state push() release() Attribute 1 1 LCDDisplay blinkidx blinkseconds() blinkminutes() blinkhours() stopblinking() referesh() Watch Battery Load 1 Time Now Operations

11 11 / 45 Sequence Diagram Sequence diagrams represent the behavior of a system as messages ( interactions ) between different objects Actor :WatchUser Message pressbutton1() pressbutton1() pressbutton2() Object :Watch blinkhours() Lifeline blinkminutes() :LCDDisplay incrementminutes() pressbutton1and2() commitnewtime() refresh() :Time Activation stopblinking()

12 12 / 45 State Machine Diagram State machine diagrams represents behavior of a single object with interesting dynamic behavior Event Initial state button1&2pressed Blink Hours button2pressed Increment Hours Transition button1pressed State button1&2pressed Blink Minutes button2pressed Increment Minutes button1pressed Stop Blinking Blink Seconds button2pressed Increment Seconds Final state

13 13 / 45 Outline 1 Introduction 2 Use Case Diagram 3 Class Diagram 4 Sequence Diagram

14 14 / 45 What is a use case? Scenario A sequence of steps describing an interaction between a user and a system The customer browse the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up . Use case A use case is a set of scenarios tied together by a common user goal Buy a Product use case: a successful purchase or authorization failure

15 15 / 45 Describe a use case A set of scenarios in the Use Case Buy a product online : 1. Customer browses through catalog and selects items to buy 2. Customer goes to check out 3. Customer fills in shipping information 4. System presents full pricing information, including shipping 5. Customer fills in credit card information 6. System authorizes purchase 7. System confirms sale immediately 8. System sends confirming to customer

16 16 / 45 An Example uc Use Cases System Boundary Waiter receive order place order Order Food <<extend>> confirm order Order Wine Serve Food <<extend>> Serve Wine Cook Food {if wine was ordered} Chef Client Eat Food facilitate payment <<extend>> {if wine was served} Drink Wine Cashier accept payment pay Pay for Food <<extend>> {if wine was consumed} Pay for Wine

17 Actor and Use Case An actor is a role that a user play with respect to the system Actors are connected to the use cases by a line A single actor may perform many use cases A use case may have several actors performing it Four types of relationships in use case diagram Generalization between use cases Generalization between actors Include relationship between use cases Extend relationship between use cases 17 / 45

18 18 / 45 Generalization between use cases Different versions of a use case share some actions in common and have some that are unique to each one Generalized use case: abstract use case It may never exist in a real system Specialized use case: concrete use case Pay utility bill

19 19 / 45 Generalization between Actors Specialized actor can do everything the general actor can do, and more

20 20 / 45 Generalization between Actors Specialized actor can do everything the general actor can do, and more

21 21 / 45 Generalization between Actors Specialized actor can do everything the general actor can do, and more

22 22 / 45 Include Relationship between Use Cases One use case includes the functionality of another use case Invocation of one use case by another one e.g., calling a function or invoking an operation within source code

23 23 / 45 Extend Relationship between Use Cases One use case may be extended by the functionality in another use case

24 24 / 45 Include, Generalization, Extend Include Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition Generalization Use Generalization when you are describing a variation on normal behavior and you wish to describe it casually Extend Use extend when you are describing a variation on normal behavior and you wish to use the more controlled form, declaring your extension points in your base use case

25 25 / 45 Outline 1 Introduction 2 Use Case Diagram 3 Class Diagram 4 Sequence Diagram

26 26 / 45 Class Diagram Class diagrams show the static structure of the classes that make up a system or subsystem Use case diagrams show the functional requirements of a system (or subsystem) from the perspective of the end-user of a system

27 27 / 45 Classes Classes are shown as rectangles Class name Other compartments Attributes Operations Other predefined compartments Name convention Class name Have no space between multiple words Capitalize the first letter in each subsequent world Name of features in compartments Have no space between multiple words Capitalize the first letter in each subsequent world except the first world

28 Associations among classes Associations represent relationships between (instances of) classes Classes collaborate with each other by passing messages and receiving responses Association name Indicates the nature of the association Associate name should begin with a capital letter Navigability: use arrow to indicate how to interpret the association Unidirectional association Bidirectional association: without arrow Role name Indicate the role played by a class in an association Attached to the corresponding association end Can use the same rule of naming features to name the role, i.e., low case the very first letter and capitalize the first letter of subsequent word 28 / 45

29 29 / 45 Multiplicity Multiplicity indicates how many objects may participate in the given relationship (during the run-time of your software system) *: 0..infinity 1: 1..1 n..m: low_bound..up_bound Multiplicity of an association end is not shown The multiplicity is not known The multiplicity is not specified

30 30 / 45 Aggregation Aggregation symbol. Assembly consists of components. Component is part of an assembly Aggregation association An instance of one class may consist of instances of another class whole-part association whole is made up of parts Use a solid line with an unfilled diamond shape at the end Diamond is connected to the class that is the aggregate A part is capable of existing outside of whole-part association

31 31 / 45 Composition Document Document FrontMatter 1 1..* 0..1 Section 1..* 0..1 Index FrontMatter [1] Section [1..*] Index [0..1] Composition association whole-part association The life-cycle of the part cannot extend beyond the life-cycle of the whole Two different notations Filled diamond notation Graphical containment 1..* 0..1

32 32 / 45 Generalization Generalization relationship is (sometimes) described as being a kind of relationship Generalized class: superclass (supertype) Specialization: subclass (subtype) Generalization allows the inheritance of the attributes and operations of a superclass by its subclasses Subclass can override the operations in the superclass

33 33 / 45 More on attribute and operation Attribute and Operation Types feature-name : type Attribute and Operation Visibility private (-) The feature is available only within the class that owns the feature public (+) The feature is available to any class associated with the class that owns the feature protected (#) The feature is available within the class that owns that feature and any subtype of that class package ( ) The feature is available only to other classes in the same package

34 34 / 45 Outline 1 Introduction 2 Use Case Diagram 3 Class Diagram 4 Sequence Diagram

35 35 / 45 Purpose of Sequence Diagram Static diagram Use case diagrams show the static relationship between actors and use cases Class diagrams show the static relationship between classes or instances A program is a sequence of interactions among objects (i.e., instances of classes) Difficult to understand a program only with static diagrams Purpose of sequence diagram Model the high-level interactions between active objects in a system Model the high-level interactions between subsystems

36 36 / 45 Sequence Diagram Example sd Create new agreement CarMatch Administrator new agreement :RecordAgreement UI details set :RecordAgreement Control create sharing agreement :SharingAgreement first:carsharer :Journey loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged

37 37 / 45 Notation Frame sd Create new agreement :RecordAgreement UI :RecordAgreement Control first:carsharer :Journey CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged Sequence diagrams are drawn in frames New in UML 2.0 Time runs vertically Lifelines are arranged horizontally Represent object instances

38 38 / 45 Notation Frame sd Create new agreement :RecordAgreement UI :RecordAgreement Control first:carsharer :Journey CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged Sequence diagrams are drawn in frames New in UML 2.0 Time runs vertically Lifelines are arranged horizontally Represent object instances

39 39 / 45 Notation Lifeline Participating instances are represented by lifelines Dashed vertical line Rectangle representing an object Syntax Explanation o An object named o o : C An object named o of class C :C An anonymous object of class C

40 40 / 45 Notation Messages and Activation box A message is shown using an arrow going from the sender to the receiver

41 41 / 45 Notation Messages and Activation box A message is shown using an arrow going from the sender to the receiver Different types of messages Synchronous The sender waits until the reply is received Asynchronous The sender does not wait for the reply; instead, it carries on the next step in its own sequence Creation A message causes the creation of an object instance to which the message is sent Reply

42 42 / 45 Sequence Diagram Example with Explicit Reply sd Create new agreement CarMatch Administrator new agreement :RecordAgreement UI details set :RecordAgreement Control create sharing agreement :SharingAgreement first:carsharer :Journey loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged

43 43 / 45 Notation Combined Fragments A sequence of messages can be combined into a fragment Loop, branches,... sd Create new agreement :RecordAgreement UI :RecordAgreement Control first:carsharer :Journey CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged

44 44 / 45 Notation Combined Fragments :Order :ReliableDistributor :NormalDistributor loop [ for each item ] alt [ value > $10,000 ] dispatch [ else ] dispatch

45 45 / 45 Exercise Lay out the lifelines for instances of the classes Student, EnrollInSeminar, SecurityLogon, StudentDatabase, and Seminar. Add the following messages to the diagram. Note, keep the order of the messages. 1 Request to enroll to seminar A 2 Create an instance of SecurityLogon class 3 Provide name 4 Provide student number 5 Provide password 6 Verify the student (name, number, password) 7 Return verification result 8 Return the student information 9 Add the student into the seminar A 10 Confirmation of enrollment of seminar A 11 Display the confirmation to student Note: EnrollInSeminar class is both the main control and the main interface with the student