Software Engineering OO Analysis (Object-Behaviour Models)

Objectives 1.To show the object-behaviour design process 2.To introduce the UML interaction and state diagram notations

Analysis = Process + Models ProcessModel Output 1. Elicit customer requirements and identify use-cases Use-Case Diagrams 2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy Class Responsibility Collaborator (CRC) Cards 3. Build an object-relationship model (structural) Conceptual Class Diagram 4. Build an object-behaviour model (dynamic) Interaction and State Diagrams

Object-Behavioural Modelling lCRC and object-relationship model  static lObject-behaviour model  dynamic (function of specific events and time) lProcess: 1.Evaluate use-cases 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 the system 5.Review model to verify accuracy and consistency

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

Example: Event Identification lUse-Case Narrative:  The homeowner observes the control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close window/doors so that the ready indicator is present [a not ready indicator implies that a sensor is open].  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. lTypical Event:  homeowner uses the keypad to key in a four-digit password.  Event “password entered” transmitted between homeowner and control panel  Does not alter flow of control (but “password compared” does)

Interaction Diagrams lA model that describes how groups of objects collaborate in some behaviour lCaptures interaction in a single use case lTo look at a single object across many use cases employ state diagrams lWorks for a sequential process without conditional or looping behaviour lTwo flavours:  Sequence (emphasise the sequence of events)  Collaboration (use layout to indicate how objects are statically connected)

Sequence Diagrams lSequence 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 thin rectangle in an object lifeline represents the time when the object is the controlling object in the system

Example: Sequence Diagram Homeowner Control Panel System system ready enters password ready for activation/deactivation selects stay or away ready for next action initiates beep activate/deactivate sensors red light on request Object Life Line Active Event

Further Notation Further Notation ConstructDescriptionSyntax DeletionIndicates that an object has been terminated  Asynchronous Message Message that does not block the caller (which carries on with its own prcoessing) Return MessageReturn from a previous message (can be omitted) Self-CallA message that an object sends to itself

Control Information lOnly use these if they help with clarity lExamples: ConstructDescriptionSyntax ConditionA message is sent only when the condition is satisfied [condition] Iteration markerMessage is sent many times to multiple receiving objects *[iteration control] [sensor active] deactivate *[for all items] add

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

Collaboration Diagrams lObjects are shown as icons, arrows indicate messages and sequence is indicated by a decimal numbering scheme. lOtherwise similar to sequence diagrams lExample: Homeowner Control Panel System 1: enters password 1.2: ready for (de)activation 2: selects stay or away 2.3: ready for next action 1.1: initiates beep 2.1: activate/deactivate sensors 2.2: red light on request

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

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

State Components lTransitions:  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 lStates:  Two parts, label and activity  Activity (with syntax do/activity) represents a process which is longer than a transition action and can be interupted Label do/activity

Example: Control Panel State At Rest Comparing Reenter Selecting Password entered [Compare password = correct] [Compare password = incorrect] activation successful [Compare password = correct]

Superstates lIf several states have the same transition (e.g. cancel) then a superstate can enclose them with a single transition lSubstates inherit the transitions of the superstate DispatchingWaitingChecking Cancelled Active

Static Conditional Branching lA graphical shortcut for convenient rendering of decision trees /sell [(value >= 100) & (value < 200)] /sell /sell [value >= 200] /sell /reject [value < 100] /rejectSellingSellingUnhappyUnhappy HappyHappy bid bid

Summary lState diagrams good at describing the behaviour of an object across several use-cases lInteraction diagrams useful for describing the behaviour of several objects in a single use case lUse each in situations for which it is most appropriate

Analysis the problem requirements elicitation build a prototype create analysis models develop Specification Review