Specifications and notations

Introduction
Classification
Finite State Machines
 Specification

• An overloaded term
– Although we all agree that "specification must precede
implementation"
• (e.g. specification for functional abstractions and data abstractions =
pre/post conditions on the operations, etc.)
• In general
– specification = definition of a contract between a producer
and a consumer of a service

Specification Notations: FSM 2

 Examples

• In requirements engineering ® software specification

(specification for the "solution")
– consumer = customer
– specification in terms of shared phenomena
• In design: interface specification
– consumer = implementer

Specification Notations: FSM 3

 Specification vs. implementation
• The distinction is relative
informal
• what vs. how product
requirements

– Sometimes we define what has to be

done by giving an example of how to
do it
– In the software development process, the
process
how can become what in the next
phase

product

Specification Notations: FSM 4

 Properties of a specification
• Clear, precise, non ambiguous, understandable,
consistent, complete (internal, external), incremental
– Selecting is the process for designating areas of your
document that you want to work on. Most editing and
formatting actions require two steps: first you select what you
want to work on, such as text or graphics; then you initiate
the appropriate action.
– The whole text should be kept in lines of equal length. The
length is specified by the user;… Unless the user gives an
explicit hyphenation command, a carriage return should occur
only at the end of a word.

Specification Notations: FSM 5

 Notations

• Informal, semi-formal, formal

• Operational
– Behavior specification in terms of some abstract machine
• Descriptive
– Behavior described via properties

Specification Notations: FSM 6

 An example
“Let a be an array of n elements. The result of its sorting is an array b of n
elements that is built as follows:
1. Find the smallest element of a, and assign it to the first element of b (if
several elements of a have the same value, any one of them is acceptable);
2. remove the element found in step 1 from a; find the smallest of the
remaining elements and assign it to the second element of b;
3. repeat steps 1 and 2 until all elements of a have been removed.”

“The result of sorting a is an array b which is a permutation of a and is

sorted.”

Specification Notations: FSM 7

 How to verify a specification?

• "Observe" dynamic behavior of specified system

(simulation, prototyping, "testing" specs)
• Analyze properties of the specified system
• Analogy with traditional engineering
– physical model of a bridge
– mathematical model of a bridge

Specification Notations: FSM 8

 Finite state machines

• They are the typical example of an operational

specification notation
– a finite set of states, S
– a finite set of inputs, I
– a state transition function, d: S ´ I ® S
• Appealing graphical representation
• "Animation" straightforward

Specification Notations: FSM 9

 An example

• Behavior of a lamp

Push switch

On Off

Push switch

Specification Notations: FSM 10

Another example: a plant control system

High-pressure alarm

High-temperature alarm

On Off

Restart

Specification Notations: FSM 11

 A refinement
Pressure signal Temperature signal
Pressure
action

Successful Unsuccessful
recovery recovery
Normal Off
Successful Unsuccessful
recovery recovery

Temperature
Temperature signal action Pressure signal

Specification Notations: FSM 12

 Classes of FSMs

• FSM as recognizers
– introduce the notion of final state and of acceptance of a
string
• FSM as transducers
– introduce the notion of output
• Deterministic/nondeterministic

Specification Notations: FSM 13

 FSMs as recognizers

<digit>
<letter>

<letter>
q0 q1 q2
_

<letter> <digit>

Legend:

<letter> is an abbreviation for a <digit> is an abbreviation for a

set of arrows labeled set of arrows labeled
a, b,..., z, A,..., Z, 0, 1,..., 9, respectively
respectively
Specification Notations: FSM 14
 Nondeterminism

• Nondeterminism: given a certain state and event (input

symbol), the transition to be taken is not uniquely
defined
– the automaton has to "choose" which is the next state
– e.g. (a fragment of a nondeterministic automaton)

a q2
q1
a
q3

Specification Notations: FSM 15

 Nondeterminism (cont.)
• A sequence is accepted if there exists at least a way to
arrive in a final state
• Example:

a, b, # # # a, b, #
q0 q1 q2 q3 qF

a, b, #

Specification Notations: FSM 16

 Why nondeterminism
• Nondeterminism is the most natural way of describing
concurrent (parallel) systems
– independent components evolve separately, nondeterminism
avoids having to establish an order in which they execute
transitions (unrealistic)
• In fact, complex systems (FMSs, industrial plants) have
components that evolve concurrently, which are more
naturally described by nondeterministic models
– we will often employ nondeterministic models
– we will soon see a formalism that is nondeterministic by
design: Petri Nets

Specification Notations: FSM 17

 Limitations of FSM

• Finite memory
• State explosion
– Given a number of FSMs with k1, k2, … kn states, their
composition is a FSM with k1 * k2 *… * kn.
This growth is exponential with the number of FSMs, not
linear (we would like it to be k1 + k2 +… + kn )

Specification Notations: FSM 18

 State explosion: an example
Producer produce Consumer get

p1 p2 c1 c2

deposit consume

Storage deposit deposit

0 1 2

get get
Specification Notations: FSM 19
 How to combine them into an FSM?
States = Cartesian product of states

0,p1,c1 1,p1,c1 2,p1,c1

deposit
produce produce
produce deposit

consume 0,p2,c1 consume 1,p2,c1 consume 2,p2,c1

get get

get
0,p1,c2 1,p1,c2 2,p1,c2
get
consume produce
produce produce

deposit deposit
0,p2,c2 consume 1,p2,c2 consume 2,p2,c2

Specification Notations: FSM 20

 How to solve these problems?

• Statecharts
– cooperating finite state machines
– used in UML as state diagrams
• Petri nets
– Suitable for modeling concurrent systems

Specification Notations: FSM 21

 Statecharts

• A modular hierarchical notation for automata

• Key concepts to achieve modularity:
– Superstates
– State decomposition

Specification Notations: FSM 22

 Plant control system
Normal

RecoverySuccess AnomalyDetection

Recovery
Recovery
Identification
Press Temp
Done Done
RecoveryFailure
Pressure Temperature
Action Action

Specification Notations: FSM 23

 History states

GenSwitchOn

Command Lamp H

push
On Off
GenSwitchOff push

Specification Notations: FSM 24

 Concurrent substates
Idle

start stop
ConcurrentWork

deposit 1
P1 deposit C1
get
produce 0 get
deposit get consume

P2 2 C2

Producer Buffer Consumer

Specification Notations: FSM 25
 Linking class diagrams and statecharts

State Machine of Producer State Machine of Consumer

Specification Notations: FSM 26

Class and State diagrams (cont.)

State Machine of Buffer

Specification Notations: FSM 27