Changing Behaviour With Time

1
Changing Behaviour With Time

• Draw State Transition Diagrams
• With without Harel Statechart Extensions
• Explain need for Harel Statechart Extensions
• Interpret and draw simple Activity Diagrams
• http//www.sparxsystems.com.au/resources/uml2_tut
  orial/uml2_statediagram.html
• http//www.sparxsystems.com.au/resources/uml2_tut
  orial/uml2_activitydiagram.html

2
State Activity Diagrams

• State Transition diagrams
• Identify different states of an object
• An object behaves differently in different states
• Different 'modes'
• Show how events trigger state changes
• Events cause transition between modes
• Activity Diagrams
• Treat activities as states
• Transitions caused only when activity ends

3
State Transition Diagrams

• An object may respond differently to the same
  message
• History-dependant behaviour
• e.g. Vending machine as coins inserted or if
  resources run out.
• e.g. Word Processor insert mode / overwrite mode
• Analyse behaviour into states
• In a single state, the system responds
  consistently to a message
• Different arrangements possible
• Important to break down at the right level
• e.g. a WP is in a different state each time you
  type a different letter
• State Transition Diagrams can become complex
• UML Harel StateChart Notation to reduce
  complexity
• Choose level of abstraction to be most useful

4
Example State Transition Diagram

• class Copy
• Bool onShelf
• Book copyOf
• void return()
• void borrow() //accepts message borrow
• void discard()
• Bool canBeBorrowed()
• The state is defined by onShelf
• Messages return() borrow() cause a transition
• Behaviour of canBeBorrowed() depends on state.
• Start Marker
• Shows the state a new object starts in
• Start markers are optional.
• If a constructor has parameters, an object may
  start in different states, don't use start marker.

5
State Diagrams

• state
• a "mode" - the system responds in the same way to
  a message
• transition
• a change from one state to another
• event
• an external incident (trigger) that might cause a
  transition.
• shown by annotating the transition arrow
• start marker
• shows the initial state of the object
• end marker
• marks a final state - the end of the object's
  life

6
Unexpected messages

• Normally borrow() should not be received in state
  on loan
• The code should do something if wrong messages
  arrive.
• Document response once, not for every such event
• An architectural decision
• Possible solutions
• Ignore
• Make no response, stay in same state
• Report
• Have a single, global Error object, responsible
  for reporting errors. An object which gets an
  unexpected message calls the Error object

7
Conventions

• Convention 1
• Do not show unexpected messages
• Show error transitions only if special action is
  required.
• Simpler diagrams
• Convention 2
• All messages should be shown
• Can detect potential omissions

8
Level of abstraction

• States are due to different values of attributes,
  
• but not every different value represents a
  different state
• e.g. The state diagram for Copy showed only two
  states
• i.e. state depends on onShelf not on copyOf
• Most attribute settings are equivalent
• for our current purposes
• e.g. behaviour of a Copy independent of original
  Book.
• Can show the range of attribute values on the
  state
• e.g. add the constraint onshelf false to on
  loan state.

9
Actions

• An event is done to the object,
• e.g. it is sent a message. (input)
• An action is done by the object,
• e.g. it sends a message. (output)
• State diagram of class Copy, with actions
• Show the action after the event on the transition
• Separated by /
• The caret () shows that the action is the
  sending of a message.

10
Reducing Diagram Complexity

• Can write actions inside the state if appropriate
• action done trigger
• by every input transition on entry event
• by every output transition on exit event
• constantly while in a state during
• State diagram of class Copy, with entry actions
• State diagram of class Copy with exit actions

11
Recording actions on a state
State Name
entry / entry-action
do activity
event 1 / action 1
....
exit / exit action
Actions and Activity in State
12
Guards Conditional Transitions

• Deterministic diagrams -
• Always a unique next state when an event occurs.
• Non-determinisitic diagrams -
• Same event in same state may cause different
  transition
• Usually we want to clarify why make it
  deterministic
• Find hidden information that explains different
  behaviour
• Resolve by
• Introducing new states
• Using the conditional notation to "guard"
  transitions.

13
State diagram for class Book

• A Book is borrowable if theres at least 1 copy
  on the shelf.

Non-deterministic
Information about number of copies shown by extra
states poor approach here
Information shown using guards
14
Using Guards

• A guard is a condition
• Here conditions are mutually exclusive
• last copy and not last copy
• numCopies 1 and numCopies gt 1
• A condition can be expressed in
• English
• a programming language,
• OCL (Object Constraint Language), or another
  formal notation.
• A return() event always makes the Book borrowable

15
Super States

• To reduce complexity
• Hierarchically group states which respond
  similarly to some events.
• Outer outward transitions end the active inner
  state
• Outer inward transitions activate the inner state
  indicated by a start state.

16
Concurrent States

• A system may contain independent components

History State state will be restored when
machine entered. Shows default (first-time) state
SuperState
H
State 1
State 3
Event 1
State 2
State 4
Event 2
17
Concurrent States 2
event 2
State 1
State 2
event 4
event 1
event 3
event 5
State 3
State 4
Splitting of Control
Synchronisation of Control
18
Example STD
19
Activity diagrams

• A variation of state diagrams
• Shows paths between activities making up complex
  behaviour.
• Entities flow through various activities
• Can represent an activity by a state
• Completion of activity is the event triggering a
  transition

20
Activity Diagram Example
The librarians swim lane
Swim Lane This involves a single
entity In this case, a library user

• Business levelactivity diagramof the library

21
Activity Diagram

• Activities
• A state which is left, not in response to an
  outside event, but when the activity it
  represents is finished.
• Transitions
• not labelled - triggered by completion of the
  previous activity.
• Synchronisation bars
• Describe co-ordination of activities
• When all activities with transitions leading into
  the bar finish, the bar can be passed.
• Decision diamonds
• Selection - a shorthand for guards on all
  transitions leaving a state.
• Start and stop markers
• Show the initial and final activities

22
Activity Diagrams

• Describe how activities are co-ordinated.
• e.g. to show how a transaction could be
  implemented.
• Model dependencies when a transaction involves
  several activities.
• Activity diagrams can describe how individual use
  cases unfold and depend on other use cases.
• Use cases may not occur in an arbitrary order but
  as part of the overall workflow of an area of the
  customers activities.
• e.g. the updating of data in one use case must be
  finished before another use case to read the data
  can start.
• Activity diagrams can model workflow
• This is only part of business modelling.
• There are extensions to UML for business
  modelling but UML has been criticised for being
  weak in this area.

23
Summary

• State Transition Diagrams
• Show dynamic behaviour
• Change over time
• Draw for a class, if necessary
• Must pick the appropriate level
• Activity Diagrams
• Show flow of activities
• Can show dependency between use cases