Software Engineering. Page 1. Objectives. Object-Behavioural Modelling. Analysis = Process + Models. Case Study: Event Identification

Transcription

1 Software Engineering Object-Oriented Analysis (State and Interaction Diagrams) James Gain 1. Show the object-behaviour design process Objectives 2. Introduce the UML interaction and state diagram notations 3. Provide case study interaction and state diagrams 4. Do an exercise on interaction diagrams Process 1. Elicit customer requirements and identify use-cases 2. Extract candidate classes, Identify attributes and methods 3. Build an object-relationship model (structural) 4. Build an object-behaviour model (dynamic) Analysis = Process + Models Model Output Use-Case Diagrams Class Responsibility Collaborator (CRC) Cards Conceptual Class Diagram Interaction and State Diagrams Object-Behavioural Modelling CRC and object-relationship model static Object-behaviour model dynamic (function of specific events and time) Process: 1. Evaluate use-case narratives to understand the sequence of system interaction 2. Identify events that drive the interaction sequence and relate these to specific objects 3. Create an interaction diagram for each use-case 4. Build a state diagram for important parts of the system 5. Review model to verify accuracy and consistency 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 Use-Case Narrative: Case Study: Event Identification 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: 1. placed over provides event place overlay transmitted between reference picture and overlay. DOES NOT alter flow of control. 2. draws provides event draw between draftsman and edge. DOES NOT alter flow of control. 3. onto overlay provides event store edge between edge and overlay. DOES NOT alter flow of control. Page 1

2 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 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: 1. key in provides event password entered transmitted between homeowner and control panel. Does NOT alter flow of control. 2. password is compared provides event password compared transmitted between system and control panel. DOES alter flow of control. 3. will beep provides event panel beeps between control panel and homeowner. Does NOT alter flow of control. 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) 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 Object Case Study: Sequence Diagram Event Notation Construct Deletion Asynchronous Message Return Message Self-Call Description Indicates that an object has been terminated Message that does not block the caller (which carries on with its own processing) Return from a previous message (can be omitted) A message that an object sends to itself Syntax Active Life Line Page 2

3 Control Information Further Example Construct Description Syntax Condition Iteration marker A message is sent only when the condition is satisfied Message is sent many times to multiple receiving objects [condition] *[iteration control] Coordinator Checker #1 Checker #2 Only use these if they help with clarity Examples: [sensor active] deactivate fail Kill checker *[all particles] Generate beinvalid Kill Collaboration Diagrams State 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: Voronoi Diagram 1 Initiate Designer 1.1 Generate 1.2 Render 1.3 Revise Position Get Direction Particle Direction Field Return Direction 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 Initial Pseudostate Transition Final State Basic UML State Diagram Ready Done stop [user quits] /ctr := 0 stop Event Guard State Action 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 Label States: do/activity Two parts, label and activity Activity represents a process which is longer than a transition action and can be interupted Page 3

4 Case Study: Voronoi Diagram State Exercise: Control Panel State Initiating Generate Particles [no. particles = n] [no. iterations <= m] Rendering Project Particles Projection complete Centering Find Centroids 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. [password = incorrect] / beep & reset [no. iterations > m] Repositioning Alter Positions Centroids calculated Awaiting Input Password entered Validating Compare Password [password = correct] 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 Static Conditional Branching A graphical shortcut for convenient rendering of decision trees Selling Happy Active [value < 100] / reject bid Checking Waiting Dispatching Cancelled [(value >= 100) & (value < 200)] / sell [value >= 200] / sell Unhappy 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 the problem requirements elicitation Summary: Analysis build a prototype create analysis models develop Specification Review Page 4

5 Process 1. Elicit customer requirements and identify use-cases 2. Extract candidate classes, Identify attributes and methods 3. Build an object-relationship model (structural) Summary: Process + Models Model Output Use-Case Diagrams Class Responsibility Collaborator (CRC) Cards Conceptual Class Diagram 4. Build an object-behaviour model (dynamic) Interaction and State Diagrams Page 5

6 This document was created with Win2PDF available at The unregistered version of Win2PDF is for evaluation or non-commercial use only.