Introduction to Software Engineering

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 Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

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) • Resulting design is huge • Many features • Many loosely unrelated styles under one roof • Could be called “union of all modeling languages”! Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

8. 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 Use Case Diagrams Communicate Introduction to Software Engineering – ECSE321

9. 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 Actors Introduction to Software Engineering – ECSE321

10. 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 Use Case Introduction to Software Engineering – ECSE321

11. Use Case Diagram Example Package SimpleWatch Actor ReadTime SetTime WatchUser WatchRepairPerson Use case ChangeBattery Functionality of the system from user’s point of view Introduction to Software Engineering – ECSE321

12. Name:PurchaseTicket Participating actor:Passenger Entry condition: Passengerstanding in front of ticket distributor. Passengerhas sufficient money to purchase ticket. Exit condition: Passengerhas ticket. Event flow: Passenger selects the destination to be traveled. Distributor displays the amount due. Passenger inserts money, of at least the amount due. Distributor returns change. Distributor issues ticket. Use Case Example Introduction to Software Engineering – ECSE321

13. Scenarios Name:purchaseTicketCCDeclined Participating actor:mike:Passenger Flow of events: Mike stands in front of ticket machine and selects Toronto as destination Distributor displays amount due Mike inserts credit card Distributor checks credit card validity with company. Credit card is declined. Distributor ask for cash Mike pays cash Ticket is issued to Mike • An instance of a use case • Concrete (names, actions) • All names are specific and underlined • Flow of events is step by step Introduction to Software Engineering – ECSE321

14. Passenger PurchaseTicket OutOfOrder TimeOut Cancel NoChange The <<extend>> Relationship <<extend>> <<extend>> <<extend>> <<extend>> Introduction to Software Engineering – ECSE321

15. Extend • Models optional behavior in the system • new functionality to the customer • functionality for a future iteration • The direction of the <<extend>> 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) Introduction to Software Engineering – ECSE321

16. Passenger PurchaseSingleTicket CollectMoney The <<include>> Relationship (re-use) PurchaseMonthlyPass <<include>> <<include>> Introduction to Software Engineering – ECSE321

17. Include • An <<include>> relationship represents behavior that is factored out of the use case. • An <<include>> represents behavior that is factored outfor reuse • The direction of a <<include>> relationship is to the included use case (unlike <<extend>> relationships). Introduction to Software Engineering – ECSE321

18. CollectMoneyWithCard CollectMoneyWithVISA CollectMoneyWithAMEX 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 <<extend>> which describes a different flow of events Introduction to Software Engineering – ECSE321

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 Train lastStop nextStop velocity doorsOpen? addStop (stop) startTrain(velocity) stopTrain() openDoors() closeDoors() Introduction to Software Engineering – ECSE321

20. TariffSchedule Table zone2price Enumeration getZones() Price getPrice(Zone) TariffSchedule zone2price getZones() getPrice() TariffSchedule Classes Type Name Signature Attributes Operations • 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. Introduction to Software Engineering – ECSE321

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 Enumeration getZones() Price getPrice(Zone) price: Price zone: Zone * * Introduction to Software Engineering – ECSE321

22. Objects (instances) tariff_1372:TarifSchedule zone2price = { {‘1’, 20},{‘2’, 40}, {‘3’, 60}} underlined • 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 Introduction to Software Engineering – ECSE321

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”) Introduction to Software Engineering – ECSE321

24. TripLeg pricezone Associations TarifSchedule Enumeration getZones() Price getPrice(Zone) * * • 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 Introduction to Software Engineering – ECSE321

25. Country City 1 1 Has-capital name:String name:String 1-to-1 and 1-to-Many Associations 1-to-1 association Polygon Point 1 * x:Integer y:Integer draw() 1-to-many association Introduction to Software Engineering – ECSE321

26. Many-to-Many and Navigational Associations Polygon Point * * x:Integer y:Integer draw() many-to-many association Polygon Point 1 * x:Integer y:Integer draw() 1-to-many association with navigation – direction of usage Introduction to Software Engineering – ECSE321

27. Engine Wheels VIN Car Aggregation 1 1 • 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 1 3..6 1 Introduction to Software Engineering – ECSE321

28. TicketMachine ZoneButton Composition • A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate. 1 3 Introduction to Software Engineering – ECSE321

29. Dependency • “I need your services, but I don’t know that you exist” (client-supplier). Dashed line from client to supplier • Other examples? 3DShadingAlgorithm Polygon draw() Introduction to Software Engineering – ECSE321

30. Button CancelButton ZoneButton 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 Abstract classes are italicized Introduction to Software Engineering – ECSE321

31. A File System Example Standard FS * FileSystemElement 1 Directory File * Non hierarchical FS FileSystemElement * Directory File Introduction to Software Engineering – ECSE321

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

33. Example - ATM • What are the actors? • Use cases? • Relationship between actors and use cases Introduction to Software Engineering – ECSE321

34. Introduction to Software Engineering – ECSE321

35. Introduction to Software Engineering – ECSE321

36. 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) TicketMachine Passenger selectZone () insertCoins() pickupChange() pickUpTicket() UML Sequence Diagrams Introduction to Software Engineering – ECSE321

37. TarifSchedule Display Passenger selectZone() lookupPrice(selection) price displayPrice(price) UML Sequence Diagrams: Nested Messages ZoneButton Nested Activation Dataflow return …to be continued... • 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 Introduction to Software Engineering – ECSE321

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) Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

41. Activity Diagram: Modeling Decisions Branch Handle incident Introduction to Software Engineering – ECSE321

42. Allocate Resources Open Coordinate Archive Incident Resources Incident Document Incident Activity Diagrams: Modeling Concurrency • Splitting the flow of control into multiple threads • Synchronization of multiple activities Splitting Synchronization Introduction to Software Engineering – ECSE321

43. Allocate Resources Open Coordinate Archive Incident Resources Incident Document Incident 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 Dispatcher FieldOfficer Introduction to Software Engineering – ECSE321

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 Introduction to Software Engineering – ECSE321

45. Use Case Diagram for Simple Watch Package SimpleWatch Actor ReadTime SetTime WatchUser WatchRepairPerson Use case ChangeBattery Functionality of the system from user’s point of view Introduction to Software Engineering – ECSE321

46. Class Diagrams for Simple Watch Class Multiplicity Association SimpleWatch 1 1 1 1 1 2 1 2 PushButton state push()release() LCDDisplay Battery load() Time now() blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() Attributes Operations The structure of the system Introduction to Software Engineering – ECSE321

47. :SimpleWatch :LCDDisplay :Time :WatchUser pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() Interaction Diagrams for Simple Watch Object time Message Activation The system behavior as interactions Introduction to Software Engineering – ECSE321

48. Increment Hours button2Pressed button1&2Pressed Blink Hours button1Pressed Increment Minutes button2Pressed button1&2Pressed Blink Minutes button1Pressed Increment Seconds button2Pressed Blink Stop Seconds Blinking Statechart for SimpleWatch State Initial state Event Transition button1&2Pressed Final state Introduction to Software Engineering – ECSE321