1. Introduction to Software Engineering ECSE-321 Unit 5 – Modeling with UML

2. Modeling Describing a system at a high level of abstraction ●A model of the system ●Used for requirements and specification Many notations over time ●State machines ●Entity-relationship diagrams ●Dataflow diagrams Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 5 – Modeling in UML /2

3. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 5 – Modeling in UML /3 Why model software? Software is already an abstraction: why model software? Software is getting larger, not smaller ●Firefox ~ 2 MLOC ●Windows XP ~ 40 MLOC (Vista ~ 50 MLOC) ●Mac OS X ~ 86 MLOC ●Adobe CS ~ 100 MLOC ●A single programmer cannot manage this amount of code in its entirety. Code is often not directly understandable by developers (who did not participate in the development) We need simpler representations for complex systems

4. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /4 Systems, Models, and Views A system is an organized set of communicating parts A model is an abstraction describing a system or a subset of a system A view depicts selected aspects of a model A notation is a set of graphical or textual rules for representing views

5. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /5 What is UML? UML (Unified Modeling Language) – a notation ●A standard for modeling object-oriented software Specifying Visualizing Constructing Documenting ●Language independent (OO) ●Designed by a committee Reference: “The Unified Modeling Language User Guide”, Addison Wesley, 1999. www.uml.org

6. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /6 What is UML? Resulted from the convergence of notations from three leading object-oriented methods: OMT (James Rumbaugh), OOSE (Ivar Jacobson), Booch (Grady Booch), etc. First edition: 1995, belongs to the Object Management Group (www.omg.org)www.omg.org Resulting design is huge ●Many features ●Many loosely unrelated styles under one roof Could be called “union of all modeling languages”!

7. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /7 UML Aspects Covered Here Functional models (functional behavior of the system as seen by the user) ●Use case diagrams Structural models (static structure of the system: Objects, Attributes, and Associations) ●Class diagrams ●Object diagrams Dynamic models (dynamic behavior between actors and the system and between objects of the system) ●Sequence diagrams ●Activity diagrams ●State diagrams

8. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /8 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 A solid line represents communications between actors and use cases Passenger PurchaseTicket Communicate

9. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /9 Actors An actor models an external entity which communicates with the system: ●User ●External system ●Physical environment An actor has a unique name and a description Examples: ●Passenger: A person in the train ●GPS satellite: Provides the system with GPS coordinates ●External database Passenger

10. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /10 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 Normal Flow of events Alternate Flow of Events Exit conditions Special requirements (e.g., quality requirements) PurchaseTicket

11. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /11 Use Case Diagram Example WatchUserWatchRepairPerson ReadTime SetTime ChangeBattery Actor Use case Package SimpleWatch Functionality of the system from user’s point of view

12. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /12 Use Case Example Name: PurchaseTicket 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 destination 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.

13. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /13 Scenarios An instance of a use case ●Concrete (names, actions) ●All names are specific and underlined ●Flow of events is step by step Name: purchaseTicketCCDeclined Participating actor: mike:Passenger Flow of events: 1.Mike stands in front of ticket machine and selects Toronto as destination 2.Distributor displays amount due 3.Mike inserts credit card 4.Distributor checks credit card validity with company. Credit card is declined. 5.Distributor ask for cash 6.Mike pays cash 7.Ticket is issued to Mike

14. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /14 The > Relationship Passenger PurchaseTicketTimeOut > NoChange > OutOfOrder > Cancel >

15. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /15 Extend Models optional behavior in the system ●new functionality to the customer ●functionality for a future iteration The direction of the > relationship is to the extended use case Use cases representing exceptional flows can extend more than one use case If it is removed or not implemented, there is no impact on the system (the related use case does not know about the extension)

16. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /16 Passenger PurchaseSingleTicket PurchaseMonthlyPass > CollectMoney > The > Relationship (re-use)

17. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /17 Include An > relationship represents behavior that is factored out of the use case. An > represents behavior that is factored out for reuse The direction of a > relationship is to the included use case (unlike > relationships).

18. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /18 Inheritance Relationship Refinement of one use case by another (“kind of” relationship) A solid line with triangle pointing to the basic use case Different from > which describes a different flow of events CollectMoneyWithCardCollectMoneyWithVISACollectMoneyWithAMEX

19. Class Diagrams Describe classes – in the OO sense Class diagrams are static – they display what interacts but not what happens when they do interact Each box is a class ●list of fields ●list of methods Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 5 – Modeling in UML /19 Train addStop (stop) startTrain(velocity) stopTrain() openDoors() closeDoors() lastStop nextStop velocity doorsOpen?

20. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /20 Classes A class represent a concept ●Attribute and behavior of a set of objects Each attribute has a type Each operation may have a signature The class name is the only mandatory information. zone2price getZones() getPrice() TariffSchedule Table zone2price Enumeration getZones() Price getPrice(Zone) TariffSchedule Name Attributes Operations Signature TariffSchedule Type

21. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /21 Class Diagrams Class diagrams are used ●during requirements analysis to model problem domain concepts ●during system design to model subsystems and interfaces ●during object design to model classes. Different kinds of edges to show relationships between classes TariffSchedule * * TripLeg price: Price zone: Zone Enumeration getZones() Price getPrice(Zone)

22. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /22 Objects (instances) An object encapsulates state and behavior An object has an indistinguishable identity An object represents a phenomenon The name of an instance is underlined and can contain the class of the instance The attributes are represented with their values zone2price = { {‘1’, 20}, {‘2’, 40}, {‘3’, 60}} tariff_1372:TarifSchedule underlined

23. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /23 Actor vs. Instances What is the difference between an actor and a class and an instance? Actor: ●An entity outside the system to be modeled, interacting with the system (“Ticker Purchaser”) Class: ●An abstraction modeling an entity in the problem domain, inside the system to be modeled (“Tariff Database”) Object: ●A specific instance of a class (“Joe, the traveler”, “The Tariff Database from Montreal to Quebec City”)

24. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /24 Associations Associations denote relationships between classes (“know of”) Typically implemented by pointers The multiplicity of an association end denotes how many objects the source object can legitimately reference Usually bi-directional – both classes “know of” each other Enumeration getZones() Price getPrice(Zone) TarifSchedule * price zone TripLeg *

25. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /25 1-to-1 and 1-to-Many Associations 1-to-1 association 1-to-many association * draw() Polygon x:Integer y:Integer Point 1 Has-capital name:String Country name:String City 11

26. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /26 Many-to-Many and Navigational Associations many-to-many association * draw() Polygon x:Integer y:Integer Point * 1-to-many association with navigation – direction of usage * draw() Polygon x:Integer y:Integer Point 1

27. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /27 Aggregation An aggregation is a special case of association denoting a “consists of” hierarchy The aggregate is the parent class, the components are the children class 1 CarEngineWheels 3..6 VIN 11 1 1

28. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /28 Composition A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate. 3 TicketMachineZoneButton 1

29. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /29 Dependency “I need your services, but I don’t know that you exist” (client-supplier). Dashed line from client to supplier Other examples? draw() Polygon 3DShadingAlgorithm

30. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /30 Generalization Generalization relationships denote inheritance between classes (“a type of”) The children classes inherit the attributes and operations of the parent class Generalization simplifies the model by eliminating redundancy Button ZoneButtonCancelButton Abstract classes are italicized

31. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /31 A File System Example FileSystemElement FileDirectory * 1 FileSystemElement FileDirectory * * Standard FS Non hierarchical FS

32. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /32 From Problem Statement to Code Problem Statement A stock exchange lists many companies. Each company is identified by a ticker symbol Class Diagram Java Code public class StockExchange { public Vector Companies = new Vector(); }; public class Company { public string tickerSymbol; public Vector stockExchanges = new Vector(); }; * StockExchange tickerSymbol Company * lists

33. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /33 Example - ATM What are the actors? Use cases? Relationship between actors and use cases

34. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 5 – Modeling in UML /34

35. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 5 – Modeling in UML /35

36. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /36 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 (parallel to activations) selectZone () pickupChange() pickUpTicket() insertCoins() Passenger TicketMachine

37. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /37 UML Sequence Diagrams: Nested Messages The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations Dashed line denoted return of data flow selectZone() Passenger ZoneButton TarifScheduleDisplay lookupPrice(selection) displayPrice(price) price Dataflow return …to be continued... Nested Activation

38. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /38 Sequence Diagram Observations UML sequence diagrams represent behavior in terms of interactions Complement the class diagrams which represent structure Help refine use cases Useful to find participating objects Time consuming to build but worth the investment Other types of interaction diagrams exist (see UML guide)

39. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /39 State charts Represent state machines Moore (output per state) or Mealy (output per transition) Nested state charts Focus on the behavior of a single object Used for analysis and design

40. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /40 Activity Diagrams An activity diagram shows flow control within a system A special case of a state chart diagram in which states are activities (“functions”) Two types of states: ●Action state: Cannot be decomposed any further Happens “instantaneously” with respect to the level of abstraction used in the model ●Activity state: Can be decomposed further The activity is modeled by another activity diagram

41. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /41 Activity Diagram: Modeling Decisions Branch Handle incident

42. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /42 Activity Diagrams: Modeling Concurrency Splitting the flow of control into multiple threads Synchronization of multiple activities Synchronization Splitting Archive Incident Open Incident Document Incident Allocate Resources Coordinate Resources

43. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /43 Activity Diagrams: Swimlanes Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions. In this course we use activity diagrams mostly for development management Archive Incident Dispatcher FieldOfficer Open Incident Document Incident Allocate Resources Coordinate Resources

44. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /44 Summary UML provides a wide variety of notations for representing many aspects of software development ●Powerful, but complex language ●Can be misused to generate unreadable models ●Can be misunderstood when using too many exotic features We concentrate only on a few notations: ●Functional model: use case diagram ●Object model: class diagram ●Dynamic model: sequence diagrams, state chart and activity diagrams

45. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /45 Use Case Diagram for Simple Watch WatchUserWatchRepairPerson ReadTime SetTime ChangeBattery Actor Use case Package SimpleWatch Functionality of the system from user’s point of view

46. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /46 Class Diagrams for Simple Watch Battery load() 1 2 Time now() PushButton state push() release() 1 1 1 1 1 2 blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() LCDDisplay SimpleWatch Class Association Multiplicity Attributes Operations The structure of the system

47. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /47 Interaction Diagrams for Simple Watch Object Message Activation The system behavior as interactions blinkHours() blinkMinutes() incrementMinutes() refresh() commitNewTime() stopBlinking() pressButton1() pressButton2() pressButtons1And2() pressButton1() :WatchUser :Time:LCDDisplay:SimpleWatch time

48. Winter 2009, MaheswaranIntroduction to Software Engineering – ECSE321 Unit 4 – Modeling in UML /48 button1&2Pressed button1Pressed button2Pressed button1Pressed button1&2Pressed Increment Minutes Increment Hours Blink Hours Blink Seconds Blink Minutes Increment Seconds Stop Blinking Statechart for SimpleWatch State Initial state Final state Transition Event