modelling iii - uio

Technology for a better society 1

Ketil StølenBased on slides prepared by Prof. Øystein Haugen, HiØ & SINTEF

Modelling III

State Machines

Technology for a better society

Overview of lecture

State Machines for what kind of systems?State Machine – a concept not found in JavaThe History LessonConsistency

– Design time consistency– Runtime consistency

2


Systems suitable for communicating set of state machines

• reactive• concurrent• real‐time• distributed• heterogeneous• complex

3


Finite State Machines

Finite– a finite number of states– [here] a small number of named states

State– a stable situation where the process awaits stimuli– a state in a state machine represents the history of the execution

Machine– that only a stimulus (signal, message) triggers behavior– the behavior consists of executing transitions– may also have local data

4


Exercise

What is a state in an imperative programming language?

What is a machine in an imperative programming language?

5


Concurrent Components that Communicate via Ports (slide by Edward A. Lee)

The use of the term “actors” for this dates back at least to the 1970s [Hewitt, Agha, Dennis, Kahn, etc.]

6


Examples of Actor‐Oriented Modeling Frameworks & Languages from Outside the UML Community

ASCET (time periods, interrupts, priorities, preemption, shared variables )Autosar (software components w/ sender/receiver interfaces)CORBA event service (distributed push‐pull)Dataflow languages (many variants over the years)LabVIEW (structured dataflow, National Instruments)Modelica (continuous time, constraint‐based, Linkoping)MPI (message passing interface, parallel programming)Occam (rendezvous)OPNET (discrete events, Opnet Technologies)SCADE (synchronous, based on Lustre and Esterel)SDL (process networks)Simulink (continuous time, The MathWorks)SPW (synchronous dataflow, Cadence, CoWare)VHDL, Verilog (discrete events, Cadence, Synopsys, ...)…

The semantics of these differ considerably in theirapproaches to concurrency and time. Some are loose (ambiguous) and some rigorous. Some are strongly actor-oriented, while some retain much of the flavor (and flaws) of threads.

7


First(?) Executable Actor‐Oriented Modeling LanguageThe On‐Line Graphical Specification of Computer ProceduresW. R. Sutherland, Ph.D. Thesis, MIT, 1966

MIT Lincoln Labs TX‐2 Computer

Bert Sutherland with a light pen

Partially constructed iterative square-root program with a class definition (top) and instance (below).

Bert Sutherland used one of the first acknowledged object-oriented frameworks (Sketchpad, created by his brother, Ivan Sutherland) to create the first actor-oriented modeling language (which had a visual syntax and a stream-based semantics).

8


A very brief history of State Machines

Finite State Machines, or automata, originated in computational theory and mathematical models in support of various fields of bioscience.Pioneering efforts of George H. Mealy and Edward F. Moore performed at Bell Labs and IBM (circa 1960s).

– Mealy and Moore's Finite State Machine concepts proved valuable in language parsing (compilers) and sequential circuit design.

SDL (ITU recommendation Z.100) from 1980ies– Telecom systems were the biggest software of that time

David Harel published Statecharts: A Visual Formalism for Complex Systems. Harel embellished the Mealy and Moore paradigm with the concept of hierarchical finite state machines (1987).

9


Our example today

10


An Access Control System

A set of Access Points are established to control the access to an areaThe Access Points controls the locking of a door

– in a more abstract sense, access control systems may control bank accounts or any other asset that one wants to protect

The Access Point access is granted when two pieces of correct identification is presented

– A card– A PIN (Personal Identification Number)

The access rights are awarded by a central Authentication service

11


The architecture in a composite structure

12

Property (part)

Port

Multiplicity

Connector


The concepts in a class diagram

13

Property (part)

Multiplicity


Happy Day Scenario

14


Exercise: Describe the set of traces representing thesemantics of access

15


The behavior of the AccessPoint

16

State Machine

State

Transition

Trigger Effect

Initial (pseudo)state


Exercise: Make a state machine for the Authenticator

17


Design time consistency

• Can be checked at design time• Represents structural constraints• Typically type consistency

– integer variables can be added, but Boolean variables cannot

18

Part

Lifeline

represents

owns


Runtime consistency – behaviors corresponding

19


Let's execute the state machine according to the sequence diagram

20


Play it again Sam

21


Access granted (one out of two alternatives)

22


User opens the door

23


User closes the door again

24


Access not granted (second of two alternatives)

25


Concluding the runtime consistency check

The APbehavior state machine satisfies all traces of the sequence diagram accessThus these behaviors are consistent

26


Exercise: Are we then perfectly happy?

27


Exercise: Describe a trace of the state machine that is not in the semantics of the sequence diagram

28


Another attempt to define the state machine

29


Exercise: Are these behaviors consistent?

30


Exercise: Which state machine is the better description?

31

and why?


What if the user started keying the PIN at once?

32

APbehaviormay spot the problemAPbehaviorOneState will go on in error


Why using different states?

Several different states distinguishes between different situationsIn different situations, different reactions may be desirable to the same triggerA specific state represents in a compact way the whole history of behavior that led to reaching that state

33


Exercise: Explain the difference between the two machines in terms of an imperative programming language

34


Guidelines and Reminders

Even though the state machine was consistent with the sequence diagram, the state machine was flawed

– The reason was that sequence diagrams are only partial descriptions of the whole, while state machines are complete descriptions of a part of the whole

Use several states if you can– Each state representing a stable, recognizable situation

We should supplement our state machine with all the possible different transitions– This would help us consider and handle most error situations

35


What if we need to modify a state machine?

Our access control system should possibly be acting differently during working hours than at other timesHow well do state machines cope with modifications?

36


Enhancing the state machine

37

Choice

Guard


Summarizing

State machines describe behavior of independently acting componentsReactive systems are suitable for state machinesConsistency checks between sequence diagrams and state machines are very useful

– but not sufficient

State machines are robust in as much as additional functionality can often be included without ripple effects on other parts of the behavior

38

modelling iii - uio

Documents