UML Review of diagram types

2 Unified Modeling Language The Unified Modeling Language™ (UML) was developed jointly by Grady Booch, Ivar Jacobson, and Jim Rumbaugh and is promotted by The Object Management Group (OMG). UML provides the application modeling language for: Business process modeling/ Requirement Analysis with use cases. Static Design with Class modeling and object modeling. Dynamic Design with sequence, collaboration and activity diagrams. Component modeling. Distribution and deployment modeling. See

3 Phases of System Development Requirement Analysis Functionality users require from the system Use case model OO Analysis Discovering classes and relationships UML class diagram OO Design Result of Analysis expanded into technical solution Sequence diagram, state diagram, etc. Results in detailed specs for the coding phase Implementation (Programming/coding) Models are converted into code Testing Unit tests, integration tests, system tests and acceptance tests.

4 UML Diagrams Use case diagrams Describe the functional behavior of the system as seen by the user. Sequence diagrams Describe the dynamic behavior between actors and the system and between objects of the system. Class diagrams Describe the static structure of the system: Objects, Attributes, and Associations.

5 UML: Use Case Diagrams WatchUserWatchRepairPerson ReadTime SetTime ChangeBattery Actor Use case System SimpleWatch Use case diagrams represent the functionality of the system from user’s point of view.

6 Use-Case Modeling In use-case modeling, the system is looked upon as a black box whose boundaries are defined by its functionality to external stimulus. The actual description of the use-case is usually given in plain text. A popular notation promoted by UML is the stick figure notation. Both visual and text representation are needed for a complete view. A use-case model represents the use-case view of the system. A use- case view of a system may consist of many use case diagrams. An use-case diagram shows (the system), the actors, the use-cases and the relationship among them.

7 Components of Use Case Model The components of a use case model are: Use cases Actors System Modeled Stimulus Example: Consider a train ticket booking system System Name name Use-case

8 System As a part of the use-case modeling, the boundaries of the system are developed. System in the use-case diagram is a box with the name appearing on the top. Defining a system is an attempt to define the catalog of terms and definitions at an early stage of the development of a business model.

9 Actors An actor is something or someone that interacts with the system. Actor communicates with the system by sending and receiving messages. An actor provides the stimulus to activate an use case. Message sent by an actor may result in more messages to actors and to use cases. Actors can be ranked: primary and secondary; passive and active. Actor is a role not an individual instance.

10 Finding Actors The actors of a system can be identified by answering a number of questions: Who will use the functionality of the system? Who will maintain the system? What devices does the system need to handle? What other system does this system need to interact? Who or what has interest in the results of this system?

11 UML: Use Case Diagrams Used during requirements elicitation to represent external behavior Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment Passenger PurchaseTicket

12 Actors An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates Passenger

13 Use Case A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements PurchaseTicket

14 The > Relationship Passenger PurchaseTicketTimeOut > NoChange > OutOfOrder > Cancel > > relationships represent exceptional or seldom invoked cases. The exceptional event flows are factored out of the main event flow for clarity. Use cases representing exceptional flows can extend more than one use case. The direction of a > relationship is to the extended use case

15 Passenger PurchaseSingleTicketPurchaseMultiCardNoChange > Cancel > CollectMoney > The > Relationship An > relationship represents behavior that is factored out of the use case. An > represents behavior that is factored out for reuse, not because it is an exception. The direction of a > relationship is to the using use case (unlike > relationships).

16 Use Case Description Example Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Exit condition: Passenger has ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Exceptional conditions: Exercise

17 Sequence Diagram UML sequence diagram represent behavior in terms of interactions. Complement the class diagrams which represent structure. Useful to find participating objects. Worth using even outside of full UML process

18 UML Sequence Diagrams Used during requirements analysis To refine use case descriptions to find additional objects (“participating objects”) Used during system design to refine subsystem interfaces Classes are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines selectZone() pickupChange() pickUpTicket() insertCoins() Passenger TicketMachine Activation Message Lifelines Object

19 UML: Sequence Diagram Sequence diagrams represent the behavior as interactions blinkHours() blinkMinutes() incrementMinutes() refresh() commitNewTime() stopBlinking() pressButton1() pressButton2() pressButtons1And2() pressButton1() :WatchUser :Time:LCDDisplay:SimpleWatch

20 UML Sequence Diagrams II The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations selectZone() Passenger ZoneButton TarifScheduleDisplay lookupPrice(selection) displayPrice(price) price Dataflow