Software Engineering

1. Software Engineering Object-Oriented Analysis (State and Interaction Diagrams) James Gain (jgain@cs.uct.ac.za) http://people.cs.uct.ac.za/~jgain

2. Objectives • Show the object-behaviour design process • Introduce the UML interaction and state diagram notations • Provide case study interaction and state diagrams • Do an exercise on interaction diagrams

3. Analysis = Process + Models

4. Object-Behavioural Modelling • CRC and object-relationship model  static • Object-behaviour model  dynamic (function of specific events and time) • Process: • Evaluate use-case narratives to understand the sequence of system interaction • Identify events that drive the interaction sequence and relate these to specific objects • Create an interaction diagram for each use-case • Build a state diagram for important parts of the system • Review model to verify accuracy and consistency

5. Event Identification • Events occur whenever the system and an actor exchange information • Events are boolean: not the information but the fact that information is or is not exchanged • Examine the use-case narratives for points of information exchange • Some events have an impact on the flow of control • Next allocate events to objects. Some will generate and other recognize events

6. Case Study: Event Identification • Use-Case Narrative: • A transparent overlay image is placed over the original reference picture. • The draftsman draws black edges of a consistent thickness onto the overlay using the mouse. • The draftsman is also able to erase edges that are incorrect from the overlay. • The draftsman can save the overlay as a black and white image with the same resolution as the reference picture. • Sample Events: • “placed over” provides event “place overlay” transmitted between reference picture and overlay. DOES NOT alter flow of control. • “draws” provides event “draw” between draftsman and edge. DOES NOT alter flow of control. • “onto overlay” provides event “store edge” between edge and overlay. DOES NOT alter flow of control.

7. Exercise: Event Identification • Use-Case Narrative: • The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. • Exercise: • Identify the events • Determine the parties involved in the event • Determine if the event will alter the flow of control

8. Solution: Event Identification • Use-Case Narrative: • The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. • Events: • “key in” provides event “password entered” transmitted between homeowner and control panel. Does NOT alter flow of control. • “password is compared” provides event “password compared” transmitted between system and control panel. DOES alter flow of control. • “will beep” provides event “panel beeps” between control panel and homeowner. Does NOT alter flow of control.

9. Interaction Diagrams • A model that describes how groups of objects collaborate in some behaviour • Captures interaction in a single use case • To look at a single object across many use cases employ state diagrams • Works for a sequential process without conditional or looping behaviour • Two flavours: • Sequence (emphasise the sequence of events) • Collaboration (use layout to indicate how objects are statically connected)

10. Sequence Diagrams • Sequence models show the sequence of object interactions that take place • Objects are arranged horizontally across the top • Time is represented vertically so models are read top to bottom • Each object has a vertical life-line representing its period of existence • Interactions (events) are represented by labelled arrows. Different styles of arrow represent different types of interaction • A rectangle in an object lifeline represents the time when the object is active

11. Case Study: Sequence Diagram Event Object Active Life Line

12. Notation

13. Control Information • Only use these if they help with clarity • Examples: [sensor active] deactivate *[all particles] Generate

14. Transaction new new Further Example new Transaction Coordinator Transaction Checker #1 new Transaction Checker #2 fail  Kill checker  Kill beInvalid 

15. Collaboration Diagrams • Objects are shown as icons, arrows indicate messages and sequence is indicated by a decimal numbering scheme. • Otherwise similar to sequence diagrams • Case Study: 1.1 Generate Voronoi Diagram Particle 1.2 Render 1.3 Revise Position 1.1.2 Return Direction 1.1.1 Get Direction 1 Initiate Direction Field Designer

16. State Diagrams • Objects can be either: • Passive (current status of attributes) • Active (status as it undergoes a continuous transformation) • State diagrams concentrate on the active states of a single event-driven object • An event occurs to force an object to make a transition from one active state to another • Events must be discrete rather than continuous • Begin with externally observable states. Later, you can refine these states into behaviours that are not evident from outside the system • State diagrams owe much to the theory of finite automota

17. Basic UML State Diagram State Ready Event Initial Pseudostate stop [user quits] /ctr := 0 Transition Done Guard Action stop Final State

18. State Components • Transitions: • Three parts, all optional Event [Guard] / Action • Events (or triggers) • Guard is a logical condition returning “true” or “false”. Transition occurs only if the condition is true. Guards exiting a state must be mutually exclusive • Action represents a processes which occurs quickly and is not interruptible • States: • Two parts, label and activity • Activity represents a process which is longer than a transition action and can be interupted Label do/activity

19. Case Study: Voronoi Diagram State Rendering Initiating [no. particles = n] Generate Particles Project Particles Projection complete Centering [no. iterations <= m] Find Centroids Centroids calculated Repositioning [no. iterations > m] Alter Positions

20. [password = incorrect] / beep & reset Password entered [password = correct] Awaiting Input Validating Compare Password Exercise: Control Panel State • Create a state diagram from the following narrative: • The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

21. Superstates • If several states have the same transition (e.g. cancel) then a superstate can enclose them with a single transition • Substates inherit the transitions of the superstate Active Cancelled Checking Waiting Dispatching

22. Static Conditional Branching • A graphical shortcut for convenient rendering of decision trees Selling Happy [value < 100] / reject bid [value >= 200] / sell [(value >= 100) & (value < 200)] / sell Unhappy

23. Summary: Object-Behavioural Models • State diagrams are good at describing the behaviour of a single object across several use-cases • Interaction diagrams useful for describing the behaviour of several objects in a single use case • Two flavours of interaction diagrams: • Sequence Diagrams: Objects in the horizontal, time in the vertical • Collaboration Diagrams: Objects connected by numbered events • Roughly equivalent • Use each object-behaviour diagram in the situation for which it is most appropriate

24. build a prototype requirements elicitation develop Specification the problem Review create analysis models Summary: Analysis

25. Summary: Process + Models