Week 5. Behavioural design and State Machine Diagrams

Behavioural Models

Behavioural models are models of the dynamic behaviour of a system as it is executing. They show what happens or is supposed to happen when a system is responds to stimulus from its environment. There are two different types of stimuli that a model can receive:

• Data: some data arrives that has to be processed by the system.
• Events: some event happens that triggers system processing. Events may have associated data.

Link to original

State Machine Models

State Machine Models model the behaviour of the system in response to external and internal events. They show the system’s responses to stimuli so are often used for modelling real-time systems. They show system states as nodes and events as arcs between nodes. When an event occurs, the system moves from one state to another.

Link to original

UML State Machine Diagram

State Machine Diagram (UML)

A state machine diagram is used to:

• Model the possible states of a system or object
• Show how the state transitions occur as a consequence of events
• Show what behaviour the system or object exhibits in each state

There are multiple components to a state machine diagram:

• State (UML State Machine)

  State is the nodes of the state diagram.

  • When a state is active, the object is in that state.
  • All internal activities specified in the current state can be executed.
  • An activity can consist of multiple actions.

  Activity specifications:

  • entry / Activity(...): executed when the object enters the state
  • exit / Activity(...): executed when the object exits the state
  • do / Activity(...): executed while the object remains in this state

  

  

  Link to original

• Transition (UML State Machine)

  A transition changes from one state to another.

  

  The syntax used is as follows:

  1. Event (trigger): exogenous stimulus, can trigger state transition
  2. Guard (condition): boolean expression
     • if the event occurs, guard is checked
     • if guard is true:
       • any activities in current state are terminated
       • relevant exit activity is executed
       • transition takes place
     • if guard is false:
       • no state transition takes place, event is discarded
  3. Activity (effect): sequence of actions executed during the state transition

  There are two types of transition:

  Link to original

• Event (UML State Machine)

  There are different types of events we need to handle in a state diagram:

  • Signal event: receipt of a signal e.g. rightmousedown, sendSMS(message)

  • Call event: operation call e.g. occupy(user, lectureHall), register(exam)

  • Time event: time-based state transition e.g. after(5 seconds) or when(time==16:00)

  • Any receive event: occurs when any event occurs that does not trigger another transition from the active state e.g. keyword = all

  • Completion event: generated automatically when everything to be done in the current state is completed

  • Change event: permanently checking whether a condition becomes true e.g. when(x,y), after(90min)

    Below is a comparison between a change event and a guard:

  Link to original

• Initial State (UML State Machine)

  The initial state is the start of a state machine diagram.

  • It is a pseudo-state.
  • No incoming edges.
  • If there is more than 1 outgoing edge, guards must be mutually exclusive and cover all possible cases to ensure that exactly one target state is reached.
  • If initial state becomes active, the object immediately switches to the next state.
  • No events allowed on the outgoing edges.

  

  Link to original

• Final State (UML State Machine)

  The final state is a real state and marks the end of the sequence of states. Object can remain in a final state forever.

  

  Link to original

• Terminate Node (UML State Machine)

  The terminate node is a pseudo-state that terminates the state machine. The modelled object ceases to exist.

  

  Link to original

• Decision Node (UML State Machine)

  A decision node is a pseudo-state and is used to model alternative transitions.

  

  Link to original

• Parallelisation Node (UML State Machine)

  A parallelisation node is a pseudo-state that splits control flow into multiple concurrent flows. There is one incoming edge and one or more outgoing.

  

  Link to original

• Synchronisation Node (UML State Machine)

  A synchronisation node is a pseudo-state that merges multiple concurrent flows. There is one or more incoming edge and one outgoing edge.

  

  Link to original

Link to original

Example: Lecture Hall with Details

Example: Digital Clock

UML Best Practices

1. Avoid crossing lines
2. Depict crossing lines as a jump
3. Avoid diagonal or curved lines
4. Apply consistent sized symbols
5. Align labels horizontally
6. Arrange symbols symmetrically
7. Organise diagrams left to right, top to bottom
8. Show only what you have to show
9. Re-organise large diagrams into several smaller ones
10. Prefer single-page diagrams
11. Apply language naming conventions on design diagrams
12. Name common elements consistently across diagrams
13. Indicate unknowns with a question mark
14. Begin use-case names with a strong verb
15. Imply timing consideration by stacking use cases
16. Place your primary actor(s) in the top left corner of the diagram
17. Name actors with a singular, domain-relevant name
18. Associate each actor with one or more use case
19. Name actor to model roles, not job titles
20. Use < to Indicate System Actors
21. Don’t allow actors to interact with one another
22. Avoid more than two levels of use-case associations
23. Place an included use case to the right of the invoking use case
24. Place an extending use case below the parent use case
25. Identify responsibilities on domain class models
26. Indicate visibility only on design models
27. Indicate types on analysis models only when the type is an actual requirement
28. Be consistent with attribute names and types
29. Do not name associations that have association classes
30. Prefer complete single nouns for class names
31. Name operations with strong verbs
32. Name attributes with domain-based nouns
33. Always indicate the multiplicity
34. Avoid a multiplicity of ”*”
35. Indicate role names on recursive associations
36. Create a state machine diagram when behaviour differs based on state
37. Question “black-hole” states: a black-hole state is one that has transitions into it but not out of it, something that should only be true of a final state
38. Question “miracle” states: a miracle state is one that has transitions out of it but not into it, should only be true of a start state