Behaviour Modelling

• Focus and Scope

• Large scale issues – emergence

• UML

• Use cases in requirements and design

• Statecharts

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 motorist’s 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.

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

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)

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

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..)

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 person’s 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

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.

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

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…

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

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

Use Case Diagram

Get help

Motorist Operator

Mechanic

Sequence diagram

Motorist Operator Mechanic

Call for help

Request member info

Member info

Check member

Request location & problem

Location and problem

Request OK and ETA

OK and ETA

ETA

Vehicle proceeds to location

Select appropriate vehicle

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 can’t remember his id?• ·        What if the motorist has ‘borrowed’ someone else’s id?• ·        What if the motorist doesn’t 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

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

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

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

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.

Statemate

• A state machine design tool based on David Harel’s 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

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

example

s1

S2S3

A

boingB

clack

B

bang

A

ping

C

clang

C

pong

initial s tate

final s tate

event-------action

transition

A

hiss

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.

State tables

States ↓

Inputs → A B C

initial 1 2 3 4

2 1 3 2

3 2 - --

final 4 - - -

JavaScript Simulator

• Local Simulator

• Web Simulator

Another Simulator

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

• Web Simulator

Noise machine model<stm name="Noise Machine"><initialState id="1" /><finalState id="4"/><state id="1"/><state id="2"/><state id="3"/><state id="4"/><event id="A"/><event id="B"/><event id="C"/>

<transition from="1" to="2" input="A"> <action> print "boing" </action> </transition><transition from="1" to="3" input="B"> <action> print "clack" </action> </transition><transition from="1" to="4" input="C"> <action> print "clang" </action> </transition><transition from="2" to="1" input="A"> <action> print "hiss" </action> </transition><transition from="2" to="3" input="B"> <action> print "bang" </action> </transition><transition from="2" to="2" input="C"> <action> print "pong" </action> </transition><transition from="3" to="2" input="A"> <action> print "ping" </action> </transition></stm>

Physical devices

• Mechanical devices can be modelled with FSMs too

Bathroom switch

off on

pull

switch on

pull

switch off

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.

Harel Statechartsguards 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

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

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

ELH versus StateChart

File

Header Trailer

Batch*

Body

BatchHeader

BatchBody

Record*

Debit Credito o

BatchTrailer

header

batch header

debit credit

trailer

batch trailer

S1

S2

S0

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