software engineering
Post on 06-Jan-2016
29 Views
Preview:
DESCRIPTION
TRANSCRIPT
Software EngineeringSoftware Engineering
Object-Oriented Analysis (State and Interaction Diagrams)
James Gain
(jgain@cs.uct.ac.za)
http://people.cs.uct.ac.za/~jgain
ObjectivesObjectives
1. Show the object-behaviour design process
2. Introduce the UML interaction and state diagram notations
3. Provide case study interaction and state diagrams
4. Do an exercise on interaction diagrams
Analysis = Process + ModelsAnalysis = Process + Models
Process Model Output
1. Elicit customer requirements and identify use-cases
Use-Case Diagrams
2. Extract candidate classes, Identify attributes and methods
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 ModellingObject-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 IdentificationEvent 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
Case Study: Event IdentificationCase 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:
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.
Exercise: Event IdentificationExercise: 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 IdentificationSolution: 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 DiagramsInteraction 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 DiagramsSequence 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
Case Study: Sequence DiagramCase Study: Sequence DiagramObject
Life LineActive
Event
NotationNotation
Construct Description Syntax
Deletion Indicates that an object has been terminated
Asynchronous Message
Message that does not block the caller (which carries on with its own processing)
Return Message Return from a previous message (can be omitted)
Self-Call A message that an object sends to itself
Control InformationControl Information
Only use these if they help with clarity
Examples:
Construct Description Syntax
Condition A message is sent only when the condition is satisfied
[condition]
Iteration marker Message is sent many times to multiple receiving objects
*[iteration control]
[sensor active] deactivate
*[all particles] Generate
Further ExampleFurther Example
Transaction
Transaction Coordinator
new
beInvalid
new
new
new
Transaction Checker #1
Transaction Checker #2
fail
Kill checker
Kill
Collaboration DiagramsCollaboration 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 Particle
Designer Direction Field
1.1 Generate
1.2 Render
1.3 Revise Position
1.1.1 Get Direction
1.1.2 Return Direction
1 Initiate
State DiagramsState 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
Basic UML State DiagramBasic UML State Diagram
stop
/ctr := 0stop [user quits]
Final State
Done
Ready
Transition
Initial Pseudostate
Action
Event
State
Guard
State ComponentsState 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
Case Study: Voronoi Diagram StateCase Study: Voronoi Diagram State
Initiating[no. particles = n]
Generate Particles
Rendering
Project Particles
Repositioning
[no. iterations <= m]
Centering
Find Centroids
[no. iterations > m]
Projection complete
Centroids calculated
Alter Positions
Exercise: Control Panel StateExercise: 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.
Awaiting Input
ValidatingPassword entered
[password = correct]
[password = incorrect] / beep & reset
Compare Password
SuperstatesSuperstates
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
DispatchingWaitingChecking
Cancelled
Active
Static Conditional BranchingStatic Conditional Branching
A graphical shortcut for convenient rendering of decision trees
Selling Happy
Unhappy
bid
[value >= 200] / sell
[(value >= 100) & (value < 200)] / sell
[value < 100] / reject
Summary: Object-Behavioural Summary: Object-Behavioural ModelsModels
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
Summary: AnalysisSummary: Analysis
the problemrequirements
elicitation
build aprototype
createanalysismodels
developSpecification Review
Summary: Process + ModelsSummary: Process + Models
Process Model Output1. Elicit customer
requirements and identify use-cases
Use-Case Diagrams
2. Extract candidate classes, Identify attributes and methods
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
top related