Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development...

Copyright 1999, 2003G.v. Bochmann CN-FM ch.2 1

Course Notes on Formal Methods for the Development of Distributed Real-Time ApplicationsCourse Notes on Formal Methods for the Development of Distributed Real-Time ApplicationsGregor v. Bochmann

School of Information Technology and Engineering

University of Ottawa, Canada

Chapter 2

Basic system modeling concepts: transition systems and properties

first version: Jan. 1999, revised Jan. 2000, Sept. 2003, Febr. 2007


Chapter 2: Basic system modeling concepts: transition systems

and properties

Chapter 2: Basic system modeling concepts: transition systems

and properties

Objective: To introduce the basic concepts used for modeling systems in the context of a very simple specification formalism: transition systems

Contents and main ideas1. The formalism of labeled transition systems

2. Rendezvous interactions in various modeling techniques

3. Composition and reachability analysis

4. Comparison of specifications

5. Temporal logic and model checking

6. The distinction of input and output

7. Specifications including assumptions and guarantees

8. Approaches to specifying real-time properties


Section 1: Labeled transitions systemsSection 1: Labeled transitions systems

• This is a very simple specification formalism for describing the behavior of a system component.

– A (finite) labeled transition system (LTS) can be used to represent the behavior of a component which has a finite number of possible values for its internal state and a finite number of operations. No operation parameters are considered. Only the possible orderings of operations is specified.

– A (finite) LTS is usually represented by a state diagram (showing the states as circles and possible state transitions as arrows). Each transition is labeled by the name of the operation which is associated with the state transition.

» Undefined transitions: If for a given state, there is no outgoing transition labeled with a given operation o, this means that this operation is not possible in this state. (Often this is interpreted by saying that the component blocks for that operation).

» If there is a transition labeled o leading from state S1 to the state S2, this means that in state S1 the operation o may be executed and the state of the object is S2 after the execution of the operation. The specification may be nondeterministic: two transitions from a given state S1 labeled o and leading to different states, which means that the new state of the object will be in one of these states. We call this form on non-determinism state non-determinism because it is the next state which is not determined.


Labeled transitions systems (ii)Labeled transitions systems (ii)

• Formally, an LTS is a tuplet S, A, , s0 where S is a set of states, s0 is the initial state

A is the alphabet, i.e. a set of labels (representing operations)

is a (partial) transition function : S A S

• Infinite transition systems– Often one considers infinite LTSs, where usually the sets S and A are

infinite. A finite LTS is often too a restrictive model, especially when the behavior of an object, which is to be described by the model, is characterized by operations that have parameters.

– Consider for example a stack of integers. The operation push(x) will lead to a different state of the object depending on the value of the parameter x which represents the integer to be pushed onto the stack. In this case, we can model the stack by an LTS where the alphabet consists of push(i) and pop(i) for all integers i, and the set of states is isomorphic to the set of finite sequences of integers (representing the integers pushed onto the stack).


Example: Resource (using blocking to represent refusal of operations)

Example: Resource (using blocking to represent refusal of operations)

Resource = S, I, O, , Free where

S = {Free, R, RR, W }

A = {RReq, WReq, RRel, Wrel}

and is represented by the following diagram.

Free R RR

W

RRel

RReq

RRel

WRel

RReq

WReq


An infinitie-state system: a Resource (using blocking to represent refusal of operations)

An infinitie-state system: a Resource (using blocking to represent refusal of operations)

Resource = S, I, O, , Free x 0 whereS = State x N where

• State is of type {Free, R, RR, W }

• N is a variable of type Integer (representing number of active readers)

A = {RReq, WReq, RRel, Wrel}and is represented by the following diagram and enabling

conditions and actions of transitions given below

Free R

W

RRel

RReq

WRelWReq

RReq: action N := 1

RRel: condition N = 1; action N := 0

RReq’: action N := N + 1

RRel’: condition N > 1; action N := N - 1

RReq’

RRel’


Operation sequences vs. StatesOperation sequences vs. States

• Some opposing views on the nature of specifications:– Specifying object behavior without mentioning states: These schools stress

the point that a functional specification should only describe the externally visible behavior of an object, and not its internal states. Assuming that an object executes at most one operation at a time, we can characterize its behavior by the sequences of operations that may be executed by the object.

– Model-based specifications: These schools say that the behavior is best defined by providing a “model” of the object, including its internal state variables and components.

– The LTS specification formalism supports both views relatively directly:

– internal states are directly modeled

– the possible sequences of operations are determined in a straightforward manner from the state-transition model

• Note: There is no way of specifying operation sequences without (at least indirectly) talking about states.


Operation sequences vs. States (ii)Operation sequences vs. States (ii)

Formal correspondence between executed operation sequences and states

• Definition: A given initial execution sequence of operations (executed after the initialization of the object) leads the object into a state which is characterized by the future behavior of the object, i.e. the possible operation sequences that may be executed after the initial sequence of operations.

• If the state (i.e. the future behavior) of an object is not uniquely determined by the initial execution sequence, the behavior is called state non-deterministic.


Representation of execution sequencesRepresentation of execution sequences

Example of an (finite) execution history of a Queue of integers:

» Enq(0); Enq(5); Deq(0); Enq(3)

Notes: This is in fact a black-box view of the object behavior.

We assume that the execution of operations by a single object is sequential (only one operation at a time).

• Each execution of an operation represents a state transition of the object (possibly leading back to the same state).

• The sequence of states (si) and operations (opi) can be represented as follows:

timeso s1 s2 s3 s4 s5

op1 op2 op3 op4op5


(suite)(suite)

• Sometimes one represents not only the externally visible operations in the execution trace, but also internal (invisible) operations which, in some cases, may change the state of the object.

• Examples: reorganization of some internal data structures (should normally not have an impact on the logical state of the object); making a back-up copy of some file; etc.

• Sometimes, the visible operations are interleaved with an arbitrary number of idle (no-op) operations which leave the object in the same state. This is useful when a sequence of clock ticks are given and a transition from each time instance to the next one is considered. In this case, a given object may not do any real transition for a number of time steps; in this case, one says that it does idle transitions at these instants. This formalism is sometimes useful for modeling the interleaving of the operations of the different objects (that is, at each time interval, only a single operation of a single object may be executed; all other objects perform an idle operation)


Safeness and liveness propertiesSafeness and liveness properties

It can be useful to make the following distinction [Alpe 87] about properties of behaviors:

– Safeness property: whatever happens is “good” (meaning that each finite execution sequence will satisfy that property; nothing “bad” will happen, e.g. no deadlock, no erroneous result, etc.)

– Liveness property: something “good” will eventually happen (the liveness property may not be satisfied for a given finite execution history; however, if we extend the given history sufficiently far, there should be a point where the property will hold). Typical kinds of liveness properties are

» termination of a sequential program

» assurance that a request will be followed by a response, that a message will be delivered, etc.

» Fairness properties, concerning the progress of several parallel processes/users, stating that liveness (in the sense of the two points above) applies to each process separately

• weak fairness: if some action (e.g. progress of one of the processes) is always possible then it will eventually happen

• strong fairness: if some action (e.g. progress of one of the processes) is possible in an infinite number of states of the execution history then it will eventually happen


(suite)(suite)

• The LTS formalism, basically, only defines safeness properties (any execution sequence is such that it can be generated by the LTS model). Liveness and timing properties may be added by extending the LTS model.

• Liveness properties are a very weak form of timing properties– One is only concerned with en eventual response (no real-time value specified) and

the fact that the ratio between the speeds of different is some finite value (which, by the way, may tend to zero or infinite).

– This is its advantage: properties hold independent of the speed of execution of different system components. It is also a disadvantage: no real-time properties are specified.

• Timing properties may be specified at two levels:– (statistical) performance properties (usually mean value, deviation, 95% lower than

such value, etc.)

– strict real-time bounds

» Note: strict real-time bounds represent safeness properties, since they can be checked for finite execution sequences (including the clock ticks).


CompositionComposition

• The importance of composition for system development– A good specification formalism must allow for the composition of several

separately specified system components to be combined to form a composite system; and the behavior of the composite system must be easily derived from the behaviors of the components and the interactions defined among the components.

– Composition implies interactions between components (Note: If there are no interactions, the components evolve independently from one another; this case is easy to model.)

– In the context of LTS, one considers rendezvous interactions (see below)

• Considering closed systems:– Each specified component may be considered in the context where it interacts

with its environment; the environment can be considered to be another system component which, in a sense, is the user of the specified component.

– The given component together with its environment form a closed system (that is, a system with no interactions with the external world).

– In the case of component testing, the environment will be the test system.


Section 2: Rendezvous interactionsSection 2: Rendezvous interactions

• Definition:– A rendezvous interaction consists of a set of (at least two) operations, each

belonging to a different component. The rendezvous interaction can only be executed if all constituent operations are possible, and its execution is the parallel execution of the constituent operations.

– Example: (in this example, the rendezvous interactions are associated with interfaces)

C1operationso1i, o1ii, ...

I1

I2

I3

I4C2operationso2i, o2ii, ...


rendezvous: o1i - o2ii

rendezvous: o1ii - o2i - o3iI5


Rendezvous interactions (ii)Rendezvous interactions (ii)• In addition to the aspect of synchronization, there may be the

exchange of parameter values. – For instance, the value of a parameter of the first operation may be defined to

be equal to the value of a parameter of the second operation (in other words, the parameter of the first operation is an input parameter of the operation which is assigned the value of the second parameter, which is an output or result parameter). Normally, the second operation guarantees that the value of its output parameter satisfies the pre-condition of the input parameter of the first operation.

– Note: LOTOS also allows for not specifying which side determines the value (only equality of values is specified; the interaction will magically select a value which is acceptable to the conditions of both sides).

– Example: Two concatenated queues (see diagram below): At the interface I2, the two operations Deq and Enq of the two queues, respectively, are executed jointly. The output parameter of Deq is passed as input parameter to Enq.

Q1I2I1 I3

Q2

Enq EnqDeqDeq


Notations for specifying interactionsNotations for specifying interactions

• There are different approaches to defining which operations of different objects must be executed as rendezvous interactions:

– Explicit rendezvous definition (as in the examples above): The list of rendezvous interactions is given explicitly (including the participating operations).

– Implicit definition:

» rendezvous for identical operation names

» rendezvous for complementary operation names (e.g. op1- and op1+; only suitable for two-way rendezvous)

• Hiding: A given rendezvous interaction (or an operation of a single component) may be part of a larger rendezvous interaction, unless it is hidden. A hidden interaction may be executed when all participating operations are possible.


The LOTOS composition operatorsThe LOTOS composition operatorsOne can introduce operators for the composition of transition systems. In the

following we use the notation of LOTOS, where the names of operations are gates, and rendezvous can be defined for identical gates.

• Parallel execution without interactions (no dependency)– The operator ||| : e.g. A[a, b, c] ||| B[a, b, d]

» In LOTOS, the expression "A[a, b, c] " represents a transition system A with externally visible operations called a, b and c.

• Parallel execution with maximum coupling– The operator || : e.g. A[a, b, c] || B[a, b, d]

» all operations which are in the alphabet of both transition systems can only be executed in rendezvous (in the above case: a and b)

• Parallel execution with partial coupling– The operator |[ {e2, e2, ...}]| : e.g. A[a, b, c] |[a]| B[a, b, d]

» the operations mentioned in the operator can only be executed in rendezvous (in the above case: a only)

• Hide operations– The operator hide : e.g. hide a in A[a, b, c] |[a]| B[a, b, d]

» in this case, the interaction a is hidden and may proceed independently of the environment of the composition of the two components A and B


Rendezvous in various modeling techniques

Rendezvous in various modeling techniques

• Rendezvous interactions are to be distinguished from other interaction primitives, such as message passing or procedure calls. Rendezvous interactions are used by various modeling techniques, such as the following:


Rendezvous: some characteristicsRendezvous: some characteristics

• The concept of rendezvous is the basis for a large number of specification paradigms for distributed and parallel systems.

– Usually, one considers that during the execution of a rendezvous involving several sub-components, these sub-components do not execute any other operation (mutual exclusion per sub-component). Thus, each rendezvous can be seen as a transition of the system, involving several sub-components. Two transitions involving two disjoint sets of sub-components may, in principle, proceed in parallel. However, if the execution time can be ignored, one usually assumes the interleaving model in which such transitions are executed sequentially (in arbitrary order, since their relative order has not impact on the state of the system which is attained after both transitions have been executed)

– Note: At this level, one does not distinguishe which of the participating sub-components takes the initiative for executing a joint action, i.e. it is not clear who is responsible. The initiative is shared. This is the main difference to specification paradigms which introduce such responsibility, such as in case of procedure call or output of a message.


Rendezvous: Different formalizationsRendezvous: Different formalizations

• There exist a large number of formalisms and languages that use the concept of rendezvous for defining the interactions between objects:

– LTSs: the labels are operations, interactions are joint transitions of different LTSs which have the same or complementary labels.

– Object-Z (see separate documentation)– LOTOS, a specification language using rendezvous communication– Petri nets: dependencies between different nets may be introduced by

defining that certain transitions of different nets should be executed jointly– “joint actions” between communicating objects [Boch 93b] and [Jarv 90]– Use Case Maps, an informal notation, proposed extension to UML

• These concepts are useful for a large range of applications– business transactions and business rules [Kilov]– workflow in business and manufacturing – process control– composition of software modules, abstract interfaces– composition of hardware modules


Section 3: Composition, reachability analysis, hiding and elimination of non-determinism

Section 3: Composition, reachability analysis, hiding and elimination of non-determinism

• Now we consider a system component which is built out of a number of sub-components, and the behavior of the component is given by certain operations of the sub-components that are visible to the environment. In addition, there are interactions between the sub-components, involving other (hidden) operations.


Example of a compositionExample of a composition

composition : this module C consists of three components, two external interfaces and two internal interfaces


I1I2

I3

I4

C



Note: Usually, each operation is assigned to a specific interface


Reachability analysisReachability analysis

• The basic principle of reachability analysis is to consider all possible execution sequences of the involved components in the context of their possible interactions and to build a global specification which is equivalent to the composed system.

– Here we consider the case of LTSs communicating with rendezvous; but the same principle can be applied to other more complex specification paradigms (e.g. for the message passing paradigm, see chapter on FSMs).

• Now we would like to find a single LTS which has the same behavior as two given coupled LTSs.

– How can such an LTS be obtained ?

– We consider two LTSs T1 = S1, A1, 1, s10 and T2 = S2, A2, 2, s2

0 which are coupled for the interactions in the set A12 , a subset of A1 A2 . In LOTOS notation, this is written T1 |[A12]| T2 . We call this a partially coupled product.


Construction of a product LTSConstruction of a product LTS

• A state of the product LTS can be represented by a pair of states s1, s2 belonging to the two given LTSs, respectively (s1 S1 et s2 S2 ).

• In such a state, the following transitions are possible:– s, t --a s’, t’ iff s --a s’ 1 and t --a t’ 1 and a A12

(the case of rendezvous)

– s, t --a s’, t iff s --a s’ 1 and a A12 (the case where only T1 does a transition)

– s, t --a s, t’ iff t --a t’ 2 and a A12 (the case where only T2 does a transition)

• Accessibility (or reachability) analysis explores all states that are accessible from the initial state of the global system.

• Example: see Concordia Tutorial slides


HidingHiding

• Definition: We say that an LTS M’ = S, A’, ’, s0 is obtained from a given LTS M = S, A, , s0 by hiding a subset of the alphabet H in A, if the alphabet A’ of M’ contains the internal action, written i, and ’, except that each transition s --a s’ with a is replaced in M’ by the transition s --i s’ ’.

• An LTS like M’ above is in general called a non-deterministic LTS because after a given externally visible trace of interactions, that is, with labels in (A minus H), the LTS may do some internal actions and may therefore enter different states (which can not be determined from an external observer that only sees the visible actions).


Elimination of non-determinismElimination of non-determinism

• The concept of accepting automaton is well-known. It is defined as an LTS with, in addition, a set of accepting states F in S (sometimes called “final” states).

• A trace of interactions is said to be accepted by an accepting automaton if there is a sequence of transitions in the automaton that leads to the given (externally visible) trace and leads the automaton into an accepting state.

• We can say that an LTS is an accepting automaton where all states are accepting.

• There is a well-known algorithm of transforming a non-deterministic accepting automaton into an equivalent deterministic automaton. (Note: equivalent, here, means that they accept the same set of interaction sequences).

• Unfortunately, the worst-case complexity of this problem is exponential in the size of the automaton.

• For a simple example, see Concordia Tutorial slides


Section 4: Comparison of specificationsSection 4: Comparison of specifications

In contrast to the “general properties” (discussed in more detail in the context of reachability analysis for FSMs) which should be satisfied by any specification or design, each system specification or design should normally also satisfy certain “specific properties” which represent the requirements. It is therefore necessary to check that the behavior of the specification or design is conform to the requirements. Similarly, the behavior of an implementation is checked against the requirements defined by the design or specification.

We assume in the following that these requirements are also given in the form of a (global) transition system.

We assume that the behavior of the more detailed specification (design or implementation) is given in the form of a single (global) transition system, or in the form of a set of interacting transition systems. In the latter case, we can use reachability analysis (see below) to obtain a single (global) transition system which represents the resulting global behavior of the system design.

The question we discuss in this subsection is: Does the detailed specification conform to the more abstract specification (the requirements) ?

We can distinguish the following categories of comparisons (see also [Boch 91])):– comparison of operation signatures (type verification, see Chapt. 5)– comparison of functions (see Chapt. 5) – comparison of traces– comparison of traces including blocking possibilities (in the case of state-

nondeterministic specifications, see below)


Comparison based on tracesComparison based on traces

• The simplest comparison of reactive behavior based on rendezvous communication is to consider the possible traces of execution of operations. The behavior of a system is defined to be the set of possible sequences of operation executions. This approach is sometimes called “trace semantics”.

• For a state-deterministic system, each finite trace t corresponds to a specific state s in which the system is after the execution of this trace.

– This state determines the possible operations which are possible in this state (operations for which there exists a transition from state s). For these operations o, there is an extension t.o of the trace t in the set of possible traces. For the other operations, there is no extension, and the system blocks.


Comparison based on refusal semanticsComparison based on refusal semantics

• In the case of state-nondeterministic systems, trace semantics does not provide a detailed view of the possibilities of blocking, as shown in the following example:

– Both diagrams (a) and (b) give rise to the same traces: x, xy and xz.

– Diagram (a) is state-deterministic, (b) is not. The two intermediate states of diagram (b) can be distinguished by their blocking behavior.

• “Failure semantics” (as proposed in CCS and CSP, sometimes also called refusal semantics) considers, in addition to traces, also the possibilities of blocking for characterizing the behavior of systems.

free choice nondet. choice

(a) (b)

x x xy y zz


Comparison based on refusal semantics (ii)Comparison based on refusal semantics (ii)• In the case of rendezvous interactions, one can not only observe

possible traces, but one can also make experiments to find out whether a given components accepts certain actions in its present state.

• Definition: A set of actions is a refusal set for a given state of a component if none of these actions can be accepted as rendezvous when the component is in the given state.

– Note: the set of actions that can not be accepted as rendezvous in a given state is the maximum refusal set of this state.

• Refusal experiment: After a given trace t of interactions has been observed for a given component, to offer a set of actions A for rendezvous with the component

– if A is included in the maximum refusal set of the state in which the component is after the trace t, i.e. A is a refusal set of this state, then the experiment leads to blocking

– otherwise (assuming basic liveness, i. e. if a transition is possible one of the possible transitions will be eventually executed), one of the actions in A that are not refused will be executed (a transition takes place) and the component will be in a new state.


Comparison based on refusal semantics (iii)Comparison based on refusal semantics (iii)

• Important note: In the case of state-deterministic systems, refusal experiments do not provide more information about the behavior than can be obtained by considering possible traces

– The refusal experiments allow to determine which actions may be refused after a given trace of interactions executed. For state-deterministic systems, given a trace t which leads to state s, one knows that all possible extensions of this trace involve exactly those next interactions which are not in the maximum refusal set of s. The possible refusals can be deduced from the set of possible extended traces.

– In the case of state-nondeterministic systems, the component may be in several different states after a given observed trace and the blocking properties may be different for these states.

• One way to represent these blocking possibilities is through a refusal graph. This is a trace-equivalent deterministic LTS which has associated with each state a set of associated possible maximum refusals.

– Each of these maximum refusals corresponds to a state in which the system may be after the observation of the trace which leads the refusal graph into the state in question.


Different semantics for comparisonsDifferent semantics for comparisons

• Several different “semantics” have been proposed to compare specifications of state-nondeterministic systems:

– trace semantics (as discussed earlier): one ignores the state-nondeterminism and considers solely the set of possible traces to characterize and compare systems. The following relations are important:

» trace equivalence: same set of possible traces» trace inclusion: traces of system A are included in traces of system B

– failure semantics: behavior characterization based on refusal experiments where each experiment terminates as soon as a blocking situation has been encountered. Different relations have been defined:

» failure preorder: its definition is based on pairs <t, R>, also called “refusals”, where t is a trace and R is a refusal set which may be observed after the execution of the trace t. A specification S2 satisfies the failure preorder relation in respect to a specification S1 iff the refusals of S2 are included in the refusals of S1. This means “ S2 has less (or equal) blockings than S1”

» reduction: same set of traces und failure preorder satisfied» extension: more traces and failure preorder satisfied» testing equivalence: same set of refusals


Different semantics for comparisons (ii)Different semantics for comparisons (ii)

– failure-trace semantics: as above, but the experiment can be continued after a failure by presenting another set of operations for rendezvous. Example: If the coke machine blocks after the coin interaction, we give it a kick (and sometimes this changes its state and it may give a coke)

– simulation semantics: one considers the internal states; one state s in system A simulates a state s’ in system B if all operation sequences that are possible from s’ are also possible from s. One often considers the following relations:

» simulation: A simulates B, i.e. each state of B is simulated by a state of A

» bi-simulation equivalence: A simulates B and B simulates A

» Note: This semantics is not based on experiments, but on an inspection of the structure of the specification (or the design, implementation) of the system.


Implications among equivalence relations Implications among equivalence relations

The equivalence relations have the following properties:

S' bi-simulation equivalent to S

S' testing equivalent to S

S' trace equivalent to S

where an arrow means “implies”; for instance, bi-simulation equivalence implies testing equivalence

=B

=Te

=Tr


ExamplesExamples

One notes that:

- (a) =Tr (b) and (c) =Tr (d) =Tr (e)

- (a) x (b) and (c) x (d) for x = Te and B

- (d) =Te (e) and (d) B (e)

free choice nondet. choice

(a) (b) (c) (d) (e)

x x x x x x x

y y z y y y

u v

z

u uv v

y y


Example with internal (hidden) transitions, noted iExample with internal (hidden) transitions, noted i

One notes that:

- For (f) and (g), y is always possible after x

- For (f), z is always possible after x, but for (g) it could block (if the internal transition is executed)

- Both system have the same traces

x

y z

x

i z

y(f) (g)


Verification of “specific properties”Practical approaches

Verification of “specific properties”Practical approaches

(a) The case of finite-state systems

A number of tools exist for the comparison of specifications, given in the form of transition graphs, according to the different relations discussed above.

One assumes normally that the visible interactions are the same for the systems to be compared. However, often one of the specifications is more detailed and contains interactions which are not visible by the other specification. For instance, in the case of the verification of a communication protocol, the messages exchanged between the protocol entities are not considered in the service specification in respect to which the protocol specification is verified (see for instance [Boch 78]).

In order to compare such specifications, the additional interactions of one of the specifications are “hidden” before the comparison. This corresponds to projecting the traces onto the interactions which are not hidden. For the specification, it means replacing the transitions to be hidden by an internal spontaneous transition and then simplifying the specification in order to eliminate the internal transitions as far as possible. Again, these operations can be performed by tools.


5. Temporal logic5. Temporal logic

While propositional logic and first-order logic are often used to describe properties of object states or state pairs (such as pre- and post-conditions of operations, see later chapter), it would be nice to talk more generally about properties of (finite and/or infinite) state sequences (or sequences of operation executions). This is where temporal logic helps.

• In my opinion, temporal logic is mainly useful to describe liveness properties. Safeness properties can be described by the basic LTS model or by invariants on state variables (in more complex specification paradigms). (Note: Temporal logic has a specific notation for saying that a property is invariant, that is, always holds).

• For more details, see copy of slides by Cerny and Song, and reading material by Emerson.


Some examplesSome examples

Basic temporal operations for linear time temporal logic:– P holds always : □ P

– P will hold eventually : P

Examples of properties for an execution sequence s:

– “ P holds infinitely often”: □P(s)

– "from some time on, P always holds”: □P(s)

– "strong fairness for action x": □x-is-possible(s) implies x-was-last-operation-executed (s)

– "weak fairness for action x": □x-is-possible(s) implies x-was-last-operation-executed (s)

– Note: In the last two cases, we assume a history sequence including subsequent object states and the operations making the state transitions


SuiteSuite

For infinite execution sequences, we clearly have:

□ state-is-Q(s) and □ state-is-R(s) (where state-is-X is a predicate which is true when the state is equal to X)

But we do not necessarily have

□state-is-P(s)

since the automata could, after a certain number of loops, always pass by state P’. The last property becomes true if we introduce a fair choice between the two transitions labeled “a” in the diagram (one needs strong fairness here, since the transitions will never be possible in all consecutive states of an infinite sequence).

Certain authors use the convention of Büchi automata (see ***) to represent liveness properties. One designates certain states (or a transitions) “live” which means that any infinite execution sequence will reach this state (or execute this transition) infinitely often.

a

c

P

Q R

i

Example: aP' i


6. The distinction of input and output6. The distinction of input and output

• Notes– Up to this point, we have considered “pure” rendezvous interactions: For

such an interaction to occur, it is necessary that all participating processes are ready to do so. There may be value parameters associated with such an interaction (e.g. as in LOTOS); if one process allows only a single value for such a parameter and the other processes allow for many values, this parameter is an output parameter for the former process and an input parameter for the latter. However, this distinction of input and output parameters of interactions is different from the distinction of input and output interactions which we consider in the following.

– In the process control area, one often distinguishes interactions by the question which process can “control” them. One could consider two types of control:

» active control: A process p has active control over an interaction o if p can force the occurrence of o independently of the other processes.

» preventive control: A process p has preventive control over an interaction o if the interaction cannot occur if p is not ready to accept it.


Notes (suite)Notes (suite)

– In the case of rendezvous, all participating processes have preventive control on the interactions.

– In the context of process control, one usually distinguishes between interactions that are controlable or non-controlable by the controller. For instance, a power failure cannot be prevented, is non-controlable).

– In the following, we classify the interactions in which a given process participates into the following categories (from the point of view of this process):

» input (the process has no control)

» output (the process has active control)


I/O Automata (IOA)I/O Automata (IOA)

An IOA is a labelled transition system for which the alphabet is partitioned into input and output interactions. Interactions with other IOAs are performed in synchrony (rendezvous); a given interaction is output for only one process, it may be input for several other processes. There are two schools:

– Basic LTS semantics: A process has preventive control for input interactions (“pure” rendezvous interactions; the process cannot have full active control on output interactions because the other processes may exercise their preventive control on the same interaction).

– Assumption-guarantee semantics: A process has no control for input, and active control for output. If, for a given state of the IOA, there is no transition specified for a given input interaction i, this means that the assumption is made that this input will never be generated by the environment of the IOA when it is in the given state. If such an input does arrive, this is called an unspecified reception. The occurrence of an unspecified reception is considered a design error.


Example: Resource (with "input" and "output" transitions)

Example: Resource (with "input" and "output" transitions)

Resource = S, I, O, , Free where

S = {Free, R, RR, W, R*, RR*, W*, x1, x2, x3 }

A = {RReq, WReq, RRel, Wrel, yes, no}

and is represented by the following diagram.Important note: input and output is not formally distinguished

in the LTS model

Free R RR

W

RRel

RReq

RRel

WRel

RReq

WReqRReqWReq

WReq

yes yes

yesno no

RReqWReq

no

R* RR*

W*

x1

x2 x3

Note: the labels yes and no represent outputs

while the other labels represent inputs

(although such a distinction is not formally made)


Introducing a “fail” stateIntroducing a “fail” state

• An IOA which has in each state transitions for all inputs of its alphabet is called completely specified, otherwise it is called partially specified.

• Sometimes, one completes the specification of a partially specified IOA by introducing an additional state called fail and additional transitions for all unspecified receptions which lead into the fail state (including from the fail state itself), thus obtaining a completely specified machine.

• Reachability analysis for a system of IOAs can be performed similarly as for a system of LTSs. If the state of one of the IOAs becomes the fail state, there is an unspecified reception, i.e. a design error.


7. Specifications with assumptions and guarantees (in general)

7. Specifications with assumptions and guarantees (in general)

• A system component functions within an environment of other components; the component specification must take this environment into account

• Normally, the properties specified for a component should (only) be satisfied when certain other properties are satisfied by the components in the environment.

• Examples:– operating temperature should be within a given (for a computer, or a

component thereof)

» electrical power supply must be given (idem)

» disk must be formatted the right way (for a disk unit)

» line length within some bound (test processor)


Components, interfaces, architecturesComponents, interfaces, architectures

• Example: Electricity counter– I1: electricity input (assumption: less than 100 Amps, less than 300 Volts)

– I2: electricity output (guarantee: same current and voltage as at I1)

– I3: read-out interface (guarantee: the value provided is equal to the energy (i.e. product of current*voltage*time) that passed through the interface I2)

specified component

component of environment

interfaceE1

E2CI1I3

I2

component of environment


Specification formalism A/GSpecification formalism A/G

• Form of a specification of a component C: If the environment satisfies the assumption AC then the component C will guarantee the property GC

Note: For the case that the assumption is not satisfied, the specification does not say anything about the desired behavior

• In first-order logic: the specification of C has the form “AC implies GC “ (or “AC => GC “ )

• Assuming that the components in the environment have specifications of the same form, the properties of the example system above are those that can be derived from the specifications of all the components, that is

P = (AC => GC) and (AE1 => GE1 ) and (AE2 => GE2) Note: Let us hope that the assumptions made by E1 and E2 are small enough to be able to obtain interesting system properties.


Conforming specializations Conforming specializations

Definition: Given two specifications SC and SC’ of two components C and C’, respectively, we say that SC’ conforms to SC if SC’ implies SC (which means that all properties specified for SC are implied by the properties specified for SC’). We also say in this case that SC’ is specialization of SC .

Note: SC’ => SC

is equivalent to (AC’ => GC’) => (AC => GC )

and this is implied by [ ( GC’ => GC) and (AC => AC’ ) ]

If X => Y we also say that X is stronger than Y or that Y is weaker than X.Therfore “SC’ conforms to SC “ if the guarantees of SC’ are stronger than those of SC and the assumptions of SC’ are weaker than

those of SC , which means [ ( GC’ => GC) and (AC => AC’ ) ]


Conforming implementations, possibilities of replacement and reuse

Conforming implementations, possibilities of replacement and reuse

• We say that an implementation conforms to a given specification SC if the properties of the implementation imply the specified properties. Assuming that the properties of the implementation can be characterized in the same form, namely by (AI => GI), then a conforming implementation must satisfy (AI => GI) => (AC => GC ) .

– Note: this is the same form of comparison as between specifications

• Important fact: If SC’ conforms to SC then an implementation conforming to SC’ could be used at any place in a system where a component satisfying the specification SC is foreseen by the system specification.

– Therefore the conforming specialization defined above should be used as the relation which determines, within object-oriented systems, whether a given type (or class) of object is a “specialization” (or is a “subtype” of, or “inherits” from) another type of object.


Different kinds of refinementDifferent kinds of refinement• What is a “refinement”?

– The system development process usually leads from an abstract specification of the requirements to detailed design specifications and finally to an implementation. Each step within this process starts with a given specification Si and leads to a “refinement” Si+1 of this specification.

– Since we want that the implementation conforms to the original requirement specification, one usually asks that Si+1 should conform to Si . Therefore one needs a conforming refinement.

• Special classes of refinements:Reductions: Si+1 conforms to Si and Gi+1 is stronger than (not equal to) Gi

this is usually a reduction of nondeterminism, e.g. reduction of possible outputs (or possible next states in state-nondeterministic systems); in the extreme, this may lead to blocking (no output is possible, or no transition possible)

Extensions: Si+1 conforms to Si and Ai+1 is weaker than (not equal to) Ai

Si+1 is defined for situations where Si was not defined, e.g. new allowed input and corresponding output, function defined for input values for which S i is undefined, etc.

Structural refinements: see next slide


Composition: Structural refinement (an example)

Composition: Structural refinement (an example)

C1I1I2

I3

I4

C3

C2

specified component

composition : this module C consists of three components, two external interfaces and two internal interfaces

C

specified component

specified component


Composition: structural refinement (the formalism)

Composition: structural refinement (the formalism)

• (Abstract) specification of component C: (AC => GC)

• The refinement of the component in terms of three sub-components C1, C2 and C3 is given by the specifications (ACi => GCi) , i = 1, 2, 3, respectively.

The properties of this structural refinement are given by

(AC1 => GC1) and (AC2 => GC2 ) and (AC3 => GC3)

If one wants that this refinement conforms to the original specification (AC => GC) of the component C, one has to verify that

[ (AC1 => GC1) and (AC2 => GC2 ) and (AC3 => GC3) ]

=> (AC => GC)


8. Real-time constraints8. Real-time constraints

There are different formalisms which represent extensions of state transition models (LTS, IOA, FSM, Petri nets) in order to characterize the real-time properties of systems. Among them the following:

• Transitions take time (minimum and maximum bounds), no waiting in states.

• Transitions are immediate (take no time), but the system may remain in a state for some time– minimum and maximum bounds for remaining in a given state, possibly transition

probabilities in case on nondeterminism.

– Markov model: each transition has a given probability of being selected within the next unit of time; each transition has a fixed transition rate (the probability of remaining within the present state after t seconds decreases exponentially with t)

– Timed Automata: LTS with one or more clocks (which always run). Each transition may reset some clocks to zero, and may also have an associated condition that the values of certain clocks must be between certain bounds; otherwise the transition blocks. A further extension of Timed Automata foresees that a state may have an invariant condition; a transition must fire before the invariant becomes false. This allows the specification that certain transition must take place (sometimes called “urgent” transitions).


Example systems with real-time properties

Example systems with real-time properties

a [1,4]

d [1,1]

P

Q R

c [0, 2]

a [2,5] P' b [0,2]

with minimum and maximum execution times for transitions

a (1/3)

d (1000)

P

Q R

c (1/10)

a (1/3) P' b (1)

Markov model (with fixed transition probabilities, leading to exponentially distributed transition delays)

Alternative:Model with fixed delays in states (and possibly transition probabilities if there is nondeterminism)


suitesuite

a; t1=1

d; t2<1; reset t1

P

Q

c t1<5; reset t2

a; t1>2 P' b, t1<10

a timed automatonthere are two design errors in this specification

a (1/3)

d (1000)

P

Q R

c (1/10)

a (1/3) P' b (1)

R

failedfailure (1/1000000 )

Markov chain: example of a“hierarchical state diagram”à la StateCharts


Example: protocol (see Exercise B.2)Example: protocol (see Exercise B.2)

Sender Receiver

1

3

+E[0.1]

-ack[1]

4

2

-nack [1]

+d[2]

3-use [2]

1

3

+new [2]

+ack [0.1]

2

3

+nack[0.1]

-d[3]; set T1 to X

+E[0.1]when timeout T1

1

+d

2

loss

-d

Medium

delay in state 2and probabilistic choice

Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development...

Documents

Transcript of Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development...