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

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

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. Get help Motorist Operator Mechanic Use Case Diagram

15. Motorist Operator Mechanic Call for help Request member info Member info Check member Request location & problem Location and problem Select appropriate vehicle Request OK and ETA OK and ETA ETA Vehicle proceeds to location 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 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

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

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

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

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

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

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