1 Design Methods for Reactive Systems, R.J. Wieringa Part IV: Behavior Notations Jens Bæk Jørgensen, University of Aarhus

2 Behaviour descriptions – in context

3 Behaviour descriptions – road map

4 behaviour descriptions – basics zRoadmap: Find required system behaviour by yAnalyzing required system services or yModeling desired environment behavior zMake behaviour descriptions of yDesired behaviour of composite system yDesired behaviour of SuD itself yAssumed behaviour of environment zFormat of behaviour descriptions yLists and tables yDiagrams (Mealy diagrams and statecharts)

5 State transitions lists and tables – basics zRange from informal to formal zCan be used at system level down to component or software object level z Different kinds of lists and tables yEvent lists yStimulus-response lists yState transition tables yDecision tables

6 State transitions lists and tables – event lists zList of event descriptions and, for each event, a description of its effect zExample: Assumed device behaviour in environment of elevator controller yLight on(b): If b is not already in state On(b), then it enters state On(b); otherwise, nothing changes yLight off(b): If b is not already in state Off(b), then it enters state Off(b); otherwise, nothing changes

7 State transitions lists and tables – event list for desired subject domain behaviour for an elevator cage zEvent: A passenger pushes a destination button in cage c zDesired effect yThe request is confirmed to the passenger by lighting up the button yIf c is idle at another floor, its motor starts in the direction of the requested floor. While c moves, its location indicator is set to the current floor. When c arrives at the requested floor, it stops and its doors open yIf c is idle at the requested floor, its doors are opened yWhen no one has passed the doors for some time, the doors close zCompare with a corresponding service description

8 State transitions lists and tables – effect descriptions zTransactional yDescription of one state transition yIntermediate states abstracted away (i.e., atomic) yPassage of time abstracted away (instantaneous) z Scenario yDescription of several state transitions yWith intermediate states (i.e. not atomic) yProgress of time zTo transform a scenario description into a transactional list, we introduce states

9 State transitions lists and tables – state transition table (STT) for elevator controller General format of STT entry: (event, current state, actions, next state)

10 State transitions lists and tables – transformation table for elevator controller

11 State transitions lists and tables – decision table for elevator controller

12 State transition diagrams – Mealy diagram for desired behaviour of heating tank controller

13 State transition diagrams – Mealy diagram for desired behaviour of heating tank controller; with variables and interface description

14 State transition diagrams – Mealy diagram constructs

15 State transition diagrams – statecharts zExtends Mealy diagrams with yState reactions yState hierarchy yParallelism zHarel, 1987 zPart of UML yUML state machines yUML activity diagrams zExecution and code generation supported by tools, e.g. yStatemate yRhapsody yIBM Rational Rose Real Time

16 State transition diagrams – statecharts: state reaction example

17 State transition diagrams – statecharts: state reaction with entry and exit events

18 State transition diagrams – statecharts: state reaction with semantic ambiguity

19 State transition diagrams – statecharts: state hierarchy example

20 State transition diagrams – statecharts: parallelism example

21 State transition diagrams – statecharts: example using broadcasting

22 Guidelines – training information system example: goal tree of training department

23 Guidelines – training information system example: workflow at the registration desk

24 Guidelines – training information system example: desired emergent behaviour

25 Guidelines – training information system example: embedding the system in its environment

26 Guidelines – training information system example: desired stimulus-response behaviour of the system Assumptions? How to make the system engineering argument?

27 Guidelines – finding states and events zFinding states yLook for states in which the behaviour is waiting for something to occur yLook for modes of behaviour (e.g. normal-standby- emergency etc.) zFinding events yLook for named events, condition changes, temporal events to which the system must respond yLook for desired effects of the system. What triggers the system to produce such an effect? zDeal with parallelism and hierarchy …

28 Guidelines – find desired system behaviour via road map

29 Guidelines – through desired causality to system transactions: steps in the road map zIdentify business solution goals zIdentify solution activities in subject domain and user workflow zIdentify desired event-action pairs in subject domain and user workflow zMap to stimulus-response pairs of SuD; introduce connection domain if necessary zRefine to transactions by introducing SuD states

30 Summary zEvent lists zState transition tables zMealy diagrams zStatecharts zGuidelines for behaviour modelling and system design