uml activity diagrams and modelingcs.uwindsor.ca/60-322/lectures/statechart_activity... · 2014. 4....

35
UML Activity Diagrams and Modeling Chap 28, 29 of textbook Activity diagram shows sequential and parallel activities in a process. Activity diagrams are useful for modeling business processes, workflows and complex algorithms. UML state diagrams shows interesting events and states of an object. It shows how the object behaves in response to events.

Upload: others

Post on 04-Feb-2021

8 views

Category:

Documents


0 download

TRANSCRIPT

  • UML Activity Diagrams and

    Modeling • Chap 28, 29 of textbook

    • Activity diagram shows sequential and parallel

    activities in a process.

    • Activity diagrams are useful for modeling

    business processes, workflows and complex

    algorithms.

    • UML state diagrams shows interesting events

    and states of an object. It shows how the object

    behaves in response to events.

  • A Typical UML Activity diagram

  • Activity diagram

    • Rich notation to show a sequence of

    activities including parallel activities

    • Useful for visualizing business workflows

    and processes.

    • Often better that a fully dressed use case

    for depicting complex activities.

    • Partitions are useful in seeing multiple

    parties and parallel actions

  • More UML Activity Diagram notation

    I could not find the Rake symbol

    in MagicDraw. Use the word

    (RAKE) for now.

    This defines

    the sub-

    activity

    “deliver

    order”

  • Signals – useful to handle events

    Activity diagram is

    useful in depicting

    very complex

    processes.

    The Rake symbol

    and sub activity is

    useful for an overall

    view

  • Specifying Behaviour

    • Interaction diagrams

    – show how object behave in particular

    interactions

    – do not specify all the possible behaviours of

    objects

    • Different notation is needed to summarize

    the overall behaviour of objects

    • UML defines statecharts for this purpose

  • State machine diagrams and modeling

    • Illustrates the interesting events and states of

    an object.

    • State independent objects always responds

    the same way with respect to an event.

    • A state dependent object reacts differently to

    events based on their state or mode,

    determined by the values of some internal

    variables.

    • A phone is a state dependent object.

    • A state machine diagram is useful to depict

    state dependent objects.

  • State-dependent Behaviour

    • If an object responds differently to the

    same stimulus at different times, this is

    modelled by defining a set of states

    – an object can be in one state at any time

    – the state it is in determines how it responds to

    events detected or messages received

    – in particular, an event can cause the object to

    move from one state to another (a transition)

  • A simplified view of a simple CD player

    • Our CD player has

    – A place to hold a CD (which may be empty or have

    a CD)

    – User interface consisting of

    – A load button (opening /closing the place to hold

    CD)

    – A play button (play a CD – after closing place to

    hold CD)

    – A stop button (Stop playing)

    • This may be modeled by having three states

    – The machine is “closed”, “open” or “playing”

  • States, Events and Transitions

    • A simple statechart for a CD player:

  • Statechart Semantics

    • A statechart defines the behaviour of

    instances of a given class

    • An object is in one active state at a time

    • Events may be received at any time

    • An event can trigger a transition

    – a transition from the active state will fire if it is

    labelled with the event just received

    • The transition leads to the next active

    state

  • Initial and final states

    • Generally we use an initial state (a special

    state) that the machine is initially in.

    • When the machine stops it is in a final

    state (also a special state).

    When the machine enters the final state it no

    longer responds to any trigger.

  • Initial and Final States using

    magicdraw

    • Model the creation and destruction of

    objects To put a label

    on an arrow,

    just select the

    label and

    start typing

    the label.

  • Non-determinism – avoid using

    guard • Sometimes there are two transitions with the

    same event label leaving a state. What if there is no CD in the machine and we press play? Nothing should happen. You may show this as follows:

    • This is called non-deterministic behaviour – but usually the non-determinism can be removed

    by adding more information

  • Guard Conditions

    • Conditions added to events indicate when

    a transition can fire For

    conditions,

    use textbox in

    magicdraw

  • Actions

    • Actions are performed when a transition

    fires Actions are short self-

    contained

    processing,

    written in plain

    English or

    pseudo-code,

    after the

    transition name

    with a /. Be

    brief!

    For actions, use textbox in magicdraw

  • Entry and exit actions

    • Entry and exit actions are properties of

    states

    – they are performed whenever an object

    arrives at or leaves the state, respectively

    For each state there

    may be an entry

    condition, and exit

    condition

  • Activities

    • Extended operations that take time to

    complete is shown as an activity.

    • Activities are performed while the object

    is in a state

    • unlike actions, they can be interrupted

    by new events

  • Completion Transitions

    • If an activity completes uninterrupted it can

    trigger a completion transaction

    – these are transitions without event labels

  • Internal Transitions

    • Internal transitions do not change state

    – and so do not execute entry and exit actions

  • Creating a Statechart

    • It can be hard to identify all necessary

    states

    • Statecharts can be developed

    incrementally

    – consider individual sequences of events

    received by an object

    – these might be specified on interaction

    diagrams

    – start with a statechart for one interaction

    – add states as required by additional

    interactions

  • Ticket Machine

    • Consider a ticket machine with two events

    – select a ticket type

    – enter a coin

    • Basic interaction is to select a ticket and

    then enter coins

    – model this as a ‘linear’ statechart

  • Refining the Statechart

    • This can be improved by adding ‘loops’

    – the number of coins entered will vary: entry

    will continue until the ticket is paid for

    – the whole transaction can be repeated

  • Adding Another Interaction

    • Suppose the user could also enter a coin

    before selecting a ticket

    • A ‘coin’ transition from the ‘Idle’ state is

    needed to handle this event

    – this transition can’t go to the ‘Paying for

    Ticket’ state as the ticket is not yet selected

    – so a new state ‘Inserting Coins’ is required

    • The statechart is thus built up step-by-step

  • Adding a Second Interaction

    • If all coins are entered before ticket

    selected:

  • Integrating the Interactions

    • In fact, events can occur in any sequence:

  • Time Events

    • Suppose the ticket machine times out after

    30 seconds

    – we need to fire a transition that is not

    triggered by a user-generated event

    – UML define time events to handle these

    cases For time

    events, use

    textbox in

    magicdraw

  • Activity States

    • Activity states defines periods of time

    when the object is carrying out internal

    processing

    – unlike normal activities, these cannot be

    interrupted by external events

    – only completion transitions leading from them

    – useful for simplifying the structure of complex

    statecharts

  • Returning Change

    • Use an activity state to calculate change

  • Ticket Machine Statechart

  • A problem to solve

    A simple digital watch consists of a display showing hors and minutes

    separated by a flashing colon and provides two buttons (A and B) which

    enable the display to be updated.

    a) To add two to the number of hours displayed, the following actions should

    be performed, where button B increments the hours display:

    Press A; press B; press B; press A; pressA.

    Draw a simple statechart showing precisely this sequence of events.

    b) In the above interactions, the hours displayed could be incremented by any

    required number and the whole interaction could be repeated as often as

    required. Redraw the statechart to incorporate these generalizations.

    c) To increment the number of minutes displayed by the watch, button A can

    be pressed twice, followed by repeated presses of button B, each of which

    increases the minutes displayed by 1. Draw a complete statechart for the

    watch, incorporating updates to both hours and minutes displayed.. Give

    the states in your statechart meaningful names and add appropriate

    actions to any action to any transition labelled ‘press B’.

  • A problem to solve The watch is subsequently enhanced to incorporate an alarm and the following

    interaction sets the time of the alarm:

    Press A; press A; press B (repeatedly); press A; press B (repeatedly); press A;

    The intention is that the user presses button A in quick succession, (like a double

    click with a mouse) to move to the “alarm setting” mode.

  • A problem to solve

    What does this mean?

    What does this do?

  • A problem to solve

    Can you read the above diagram ?

  • A problem to solve