UML First Pass Use Case Diagrams Package Simple

UML First Pass: Use Case Diagrams Package Simple. Watch Actor Read. Time Watch. User Use case Set. Time Watch. Repair. Person Change. Battery Use case diagrams represent the functionality of the system from user’s point of view Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16

UML First Pass: Class Diagrams Class Multiplicity 1 2 Push. Button state push() release() Association Simple. Watch 1 LCDDisplay blink. Idx blink. Seconds() blink. Minutes() blink. Hours() stop. Blinking() referesh() 1 1 1 2 1 Battery load() Time now() Attributes Operations Class diagrams represent the structure of the system Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17

UML First Pass: Sequence Diagram Object : Watch. User : Simple. Watch : LCDDisplay press. Button 1() blink. Hours() press. Button 1() blink. Minutes() press. Button 2() : Time increment. Minutes() refresh() press. Buttons 1 And 2() commit. New. Time() stop. Blinking() Activation Message Sequence diagrams represent the behavior as interactions Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18

UML First Pass: Statechart Diagrams Initial state Event button 1&2 Pressed Blink Hours button 2 Pressed State Increment Hours button 1 Pressed Transition button 1&2 Pressed Blink Minutes button 2 Pressed Increment Minutes button 1 Pressed Stop Blinking Blink Seconds button 2 Pressed Increment Seconds button 1&2 Pressed Final state Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19

UML Second Pass: Use Case Diagrams Used during requirements elicitation to represent external behavior ¨ Passenger ¨ ¨ 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 Purchase. Ticket Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22

Use Case A use case represents a class of functionality provided by the system as an event flow. Purchase. Ticket Bernd Bruegge & Allen Dutoit A use case consists of: ¨ Unique name ¨ Participating actors ¨ Entry conditions ¨ Flow of events ¨ Exit conditions ¨ Special requirements Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24

Use Case Example Name: Purchase ticket Participating actor: Passenger Entry condition: ¨ Passenger standing in front of ticket distributor. ¨ Passenger has sufficient money to purchase ticket. Anything missing? Exit condition: ¨ Passenger has ticket. Bernd Bruegge & Allen Dutoit 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 cases! Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25

The <<extend>> Relationship ¨ ¨ Passenger ¨ Purchase. Ticket ¨ <<extend>> Out. Of. Order 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 <<extend>> relationship is to the extended use case <<extend>> Cancel Bernd Bruegge & Allen Dutoit <<extend>> relationships represent Time. Out No. Change Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26

The <<include>> Relationship ¨ Passenger ¨ Purchase. Multi. Card Purchase. Single. Ticket <<include>> ¨ <<include>> <<extend>> No. Change Bernd Bruegge & Allen Dutoit An <<include>> relationship represents behavior that is factored out of the use case. An <<include>> represents behavior that is factored out for reuse, not because it is an exception. The direction of a <<include>> relationship is to the using use case (unlike <<extend>> relationships). Collect. Money <<extend>> Cancel Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27

Classes Name Tariff. Schedule zone 2 price get. Zones() get. Price() ¨ ¨ ¨ Attributes Operations Tariff. Schedule Table zone 2 price Enumeration get. Zones() Price get. Price(Zone) Signature Tariff. Schedule A class represent a concept. A class encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature. The class name is the only mandatory information. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29

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. Exhaust System 1 Muffler Bernd Bruegge & Allen Dutoit 0. . 2 Tailpipe Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34

Composition ¨ A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate. Ticket. Machine 3 Bernd Bruegge & Allen Dutoit Zone. Button Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35

Generalization Button Cancel. Button ¨ ¨ ¨ Zone. Button Generalization relationships denote inheritance between classes. The children classes inherit the attributes and operations of the parent class. Generalization simplifies the model by eliminating redundancy. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36

UML Sequence Diagrams ¨ Passenger Used during requirements analysis w To refine use case descriptions w to find additional objects (“participating objects”) Ticket. Machine select. Zone() ¨ Used during system design w to refine subsystem interfaces insert. Coins() ¨ ¨ pickup. Change() pick. Up. Ticket() Bernd Bruegge & Allen Dutoit ¨ ¨ Classes are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38

UML Sequence Diagrams: Nested Messages Passenger Zone. Button select. Zone() Tarif. Schedule Display lookup. Price(selection) price Dataflow display. Price(price) …to be continued. . . ¨ ¨ The source of an arrow indicates the activation which sent the message An activation is as long as all nested activations Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39