Behaviour Modelling

1
Behaviour Modelling
2

• Focus and Scope
• Large scale issues emergence
• UML
• Use cases in requirements and design
• Statecharts

3
situation

• GetUHome is a company which provides a breakdown
  service to its members nationwide. Members pay a
  yearly subscription to the company.
• In the event of a breakdown, the distressed
  motorist phones the call centre where an
  available operator takes the call. The operator
  checks that the caller is a paid-up member. If he
  is, the operator obtains details of the
  motorists problems and location. He then finds
  the most appropriate mechanic to deal with the
  problem and calls the mechanic with the new task.
  The mechanic proceeds to the location of the
  motorist while the operator reports the expected
  arrival time to the motorist.

4
Focus GetUHome

• Individual
• What happens to a member as they progress from
  registration, renewal, breakdowns through to
  death or cancellation a whole life view
• Small Group
• How the member, the call-centre operator and the
  mechanic collaborate to assist in a breakdown
• Organisation
• How the organisation is structured to respond to
  changing needs..
• Society
• How to predict demand for resources such
  call-centre operators, mechanics and server
  power under varying conditions of weather and
  other circumstances

5
Models by focus

• Focus on an individual and what happens to it
  over the whole life time
• Entity Life History, State Chart
• Focus on a small group of interacting individuals
  over the period of an incident
• Scenarios, Use cases, Interaction Diagrams,
  Activity Diagrams, RAD (Role Activity Diagram)
• Focus on the massed behaviour of the society
• System Dynamics (equational), Discrete Simulation
  models (probabilistic)

6
Three levels of abstraction in Behaviour modelling

• Mission statements, goals and targets
• The abstract goals of an organisation,
  independent of methods and plans to achieve those
  goals
• Logical Processes
• Logical descriptions of methods and plans to
  achieve goals, independent of their realisation
  in physical entities and hence of such physical
  constraints
• Business Process Modelling, Rule-based models
• Physical Processes
• the domain of people, communication services,
  data flows and programs
• Roles assigned to individuals, processes located
  on processors

7
Scope

• What is the scope of the system
• The Rescue organization
• The operator and mechanic are inside this system
  boundary
• The Computer System
• The operator and mechanic are outside this system
  boundary
• Under different circumstances either may be
  appropriate but the boundary must be defined
• The essence of an information system is that it
  contains a computer-based representation of the
  domain (the Rescue Organization)
• Mechanic in the Real world are represented by
  mechanic-objects in the computer system
• So many UML diagrams can be used to model
• The computer system (individuals are objects)
• The business system (individuals are people..)

8
Emergent Issues

• As humans we find this layering of focus and
  scope useful but the fallacy of misplaced
  concreteness stalks us
• Emergence
• Layers are generally not independent
• Scarce resources (time, people, processing power)
  in the physical layer cause behavioural
  disturbances to percolate up the layers,
  generating unpredictable consequences
• Knowledge is not bounded by layers, so a persons
  knowledge of a goal allows the person both to
  extemporise new plans when pre-conditions fail,
  or find ways to execute the plan but thwart the
  goal
• Many-many mapping
• A process may support several goals, a goal
  require multiple processes to realise it
• A person may carry out many roles, a process
  require many people and other resources whose
  schedules may conflict
• 8 neighbours

9
Background to UML

• UML (Unified Modelling Language) has emerged as
  the dominant set of graphical notations for use
  in Object-oriented Software Development
• Current version is UML 2.0 with 14 different
  diagram types
• UML is unavoidable - widely used and written
  about
• UML is enthusiastically being extended into
  non-software domains business processes and
  systems engineering (SysML)
• Whilst UML is just a set of notations, it is
  linked to a software development approach
  (life-cycle) called RUP (Rational Unified
  Approach) which is also being extended into other
  areas (RUP SE)
• There are dissenting voices.

10
UML Notations

• Use case Diagram
• Showing the actors involved in a use case
• Interaction Diagram
• Showing the sequence of steps in the interaction
  between actors and the system
• Activity Diagram
• Showing how data flows from one process to
  another
• Class Diagram
• Showing the classes in the system
• State Chart
• Showing how an object changes over time as a
  result of events
• others

11
Use-cases and scenarios

• Classification
• Focus small group
• Level of abstraction conceptual
• Prescriptive/graphical-textual/early analysis
• Use cases include the actions of users as part of
  that interaction
• Use cases set requirements into context of use
• Use cases also point to requirements on users
  for using the system systems knowledge,
  training, level of education

12
General to Specific

• A generalised use-case
• Is described in terms of roles 'an operator
• Covers a number of possible paths.
• Danger that the reader will import their own
  stereotype white, male, English first language
• A specific, concrete scenario or story
• Is described in terms of specific instances
• 'Paul the operator, a 2nd Year business studies
  student from London who works part time at
  GetUHome to finance his studies and clubbing'.
• The story describes exactly what happened, not
  several possible outcomes.
• Stories favour insight into the problem situation
  and may reveal unanticipated assumptions about
  the situation and the nature of the actors.
• Use cases provide grounds for formal requirements
  for the system but also informal requirements for
  the knowledge and capabilities of the actors

13
Use case

• Uses a template to structure the information
• Is named for the goal of the principal actor
• Name Get help
• Primary Actor Motorist
• Describes normal use case (good day) and
  alternative situations arising from normal
  variations
• Supported by a Use-case diagram showing one or
  more use cases
• May be elaborated into an interaction diagram

14
Use Case Diagram
15
Sequence diagram
16
Use cases in problem analysis

• Information Requirements
•         What information is required to identify
  a member?
•         What information is required to identify
  the problem and location?
•         How do we choose the most appropriate
  vehicle to send?
•         Who provides the ETA? The operator, the
  rescue driver or both in consultation? How is
  it calculated?
• Variations
•         What happens if the membership has
  expired?
•         What happens if the motorist cant
  remember his id?
•         What if the motorist has borrowed
  someone elses id?
•         What if the motorist doesnt know where
  they are?
•         How does the rescue driver find the
  motorist?
• Performance
•         What is an acceptable time to wait for
  an operator?
•         What is an acceptable time to wait for a
  rescue vehicle

17
Mis-use and abuse cases

• Identify
• Treats and attacks
• Attempt to acquire customer list
• Deliberate misuse by humans
• Use of a stolen membership card
• System failure
• Loss of telephone lines
• Loss of communication channel to mechanic

18
Use-cases and Design

• Concrete Scenarios
• Write a concrete scenario for each use case to
  flesh it out
• Brain storming
• One group identify problems with scenario
• Other group suggest solutions
• Role playing
• Testing out a proposed solution using role playing

19
Use cases in ..

• Testing
• Use cases generate test situations
• Tests can be written in advance for use in
  test-driven development
• Training
• Use cases are the scenarios in which users will
  need to be educated or trained to use the system

20
Dissenting Voices

• Uncertainly about what a use case is, how big,
  how general, what boundary, when to stop finding
  use cases.
• A project may have many hundreds of use case so
  computer support necessary to manage and to
  restructure ( find all for an actor), trace
  requirement to use cases.
• Relationship between use-case and requirements is
  many-many so mapping requires additional work and
  traceability.
• Uses case may be poor at surfacing so-called
  non-functional requirements .
• Scope of use-case is too narrow often at the
  level of an interaction over a small period of
  time what about the long-running processes with
  the scope of the whole period of membership?
• Focus is on system boundary, not directly on the
  problem domain.

21
Statemate

• A state machine design tool based on David
  Harels state charts (incorporated into UML)
• Allows
• Simulation what would happen if the following
  sequence of events occurred.
• Analysis prove that the system can never lock
  up
• Code generation to C for loading into embedded
  processors

22
Basic State Machine

• The basic concepts in this notation are
• state
• A mode of the object/component/sub-system
• transition
• A change of state caused by an event or input,
  perhaps back to the same state
• event
• the input which causes a transition to occur
• action
• An action which occurs when a transition is made

23
(No Transcript)
24
Exercise

• 1.1. What sequence of noises does it make when
  the sequence ABACAC is in put?
• 1.2 What about BABAAC?
• 1.3 What kind of error in the machine does the
  sequence ACCBA reveal?
• 1.4 What kind error in the machine does the
  input BABC reveal?
• 1.5 What kind of error does the sequence
  ABAXAC reveal?
• 1.6 Give other examples of good and bad input.

25
State tables
States ? Inputs ? A B C
initial 1 2 3 4
2 1 3 2
3 2 - - -
final 4 - - -
26
JavaScript Simulator

• Local Simulator
• Web Simulator

27
Another Simulator

• This simulator takes an XML definition of a
  statechart and builds a model which can be
  executed or visualized.
• Web Simulator

28
Noise machine model
ltstm name"Noise Machine"gt ltinitialState id"1"
/gt ltfinalState id"4"/gt ltstate id"1"/gt ltstate
id"2"/gt ltstate id"3"/gt ltstate id"4"/gt ltevent
id"A"/gt ltevent id"B"/gt ltevent
id"C"/gt lttransition from"1" to"2" input"A"gt
ltactiongt print "boing" lt/actiongt
lt/transitiongt lttransition from"1" to"3"
input"B"gt ltactiongt print "clack" lt/actiongt
lt/transitiongt lttransition from"1" to"4"
input"C"gt ltactiongt print "clang" lt/actiongt
lt/transitiongt lttransition from"2" to"1"
input"A"gt ltactiongt print "hiss" lt/actiongt
lt/transitiongt lttransition from"2" to"3"
input"B"gt ltactiongt print "bang" lt/actiongt
lt/transitiongt lttransition from"2" to"2"
input"C"gt ltactiongt print "pong" lt/actiongt
lt/transitiongt lttransition from"3" to"2"
input"A"gt ltactiongt print "ping" lt/actiongt
lt/transitiongt lt/stmgt
29
Physical devices

• Mechanical devices can be modelled with FSMs too

30
Exercise 3

• A vending machine can accept 5, 10 and 20p coins
  up to a total value of 30p. There is one dispense
  button. When pressed, the machine issues a cold
  drink can and pockets the 30p.
• Define a suitable state machine. Note that the
  amount entered so far must be described only in
  the state of the machine, not in a separate
  counter.

31
Harel Statecharts
guards pre-conditions on transitions
nested states one state may be composed of many substates. The superstate defines common behaviour such as transitions which are the same for all sub-states.
entry and exit actions which occur on state entry and exit.
activity on-going activities in a state
event signalling causing an internal event to be sent to another object
concurrent states parallel states in which state changes occur independently
synchronisation and splitting to define the flow of control within parallel states
timeout transition triggered by a timeout counter set on state entry
32
Chinese clock

• Operating for clock
• Time display-
• The normal display of Hour Minute and Month day
  are alternate move.
• Time setting-
• 1) push S1 once, display shows MONTH, push S2 to
  advance month
• 2) push S1 twice, display shows DAY of MONTH,
  push S2 to advance DAY
• 3) push S1 third, display shows hour and AM/PM
  indicator. Push S2 to advance hour
• 4) push S1 fourth time, display shows MINUTES.
  Push S2 to advance MINUTES
• 5) push S1 fifth time, display shows normal
  running mode
• 6) push S1 One more time, display will alternate
  TIME and DATE each 2 seconds

33
Statecharts and ELHs

• Entity Life History models serve a similar
  purpose to statecharts
• Higher order constructs sequence, iteration
  selection in ELH, goto in statecharts
• Nodes are states in Statechart, Events in ELH
• Equivalent, but some ELHs are more complex as a
  statechart

34
ELH versus StateChart
35
Enactable Processes

• State charts as the basis for enactable process
  model
• Analyst defines the model
• General process support environment executes the
  program
• Describing academic processes
• e.g. the process of exam moderation
• Web Simulator