Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development of Distributed Real-Time Applications Gregor v. Bochmann.

Similar presentations

Presentation on theme: "Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development of Distributed Real-Time Applications Gregor v. Bochmann."— Presentation transcript:

1 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development of Distributed Real-Time Applications Gregor 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

2 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 2 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 ideas 1. 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

3 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 3 Section 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.

4 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 4 Labeled transitions systems (ii) Formally, an LTS is a tuplet  S, A, , s 0  where S is a set of states, s 0 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).

5 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 5 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 RRR W RRel RReq RRel WRel RReq WReq

6 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 6 An infinitie-state system: a Resource (using blocking to represent refusal of operations) Resource =  S, I, O, , Free x 0  where S = 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 WRel WReq 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’

7 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 7 Operation 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.

8 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 8 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.

9 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 9 Representation 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 (s i ) and operations (op i ) can be represented as follows: time soso s1s1 s2s2 s3s3 s4s4 s5s5 op 1 op 2 op 3 op 4 op 5

10 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 10 (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)

11 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 11 Safeness 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

12 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 12 (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).

13 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 13 Composition 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.

14 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 14 Section 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) C1 operations o1i, o1ii,... I1 I2 I3 I4 C2 operations o2i, o2ii,... C3 operations o3i, o3ii,... rendezvous: o1i - o2ii rendezvous: o1ii - o2i - o3i I5

15 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 15 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. Q1 I2 I1I3 Q2 Enq Deq

16 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 16 Notations 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.

17 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 17 The LOTOS composition operators One 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

18 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 18 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:

19 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 19 Rendezvous: 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.

20 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 20 Rendezvous: 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

21 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 21 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.

22 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 22 Example of a composition composition : this module C consists of three components, two external interfaces and two internal interfaces C1 operations o1i, o1ii,... I1 I2 I3 I4 C C2 operations o2i, o2ii,... C3 operations o3i, o3ii,... Note: Usually, each operation is assigned to a specific interface

23 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 23 Reachability 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 T 1 =  S 1, A 1,  1, s 1 0  and T 2 =  S 2, A 2,  2, s 2 0  which are coupled for the interactions in the set A 12, a subset of A 1  A 2. In LOTOS notation, this is written T 1 |[A 12 ]| T 2. We call this a partially coupled product.

24 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 24 Construction of a product LTS A state of the product LTS can be represented by a pair of states  s 1, s 2  belonging to the two given LTSs, respectively (s 1  S 1 et s 2  S 2 ). 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  A 12 (the case of rendezvous) –  s, t  --a   s’, t  iff s --a  s’   1 and a  A 12 (the case where only T 1 does a transition) –  s, t  --a   s, t’  iff t --a  t’   2 and a  A 12 (the case where only T 2 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

25 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 25 Hiding Definition: We say that an LTS M’ =  S, A’,  ’, s 0  is obtained from a given LTS M =  S, A, , s 0  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).

26 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 26 Elimination 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

27 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 27 Section 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)

28 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 28 Comparison 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.

29 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 29 Comparison 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 choicenondet. choice (a)(b) x x x y y z z

30 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 30 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.

31 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 31 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.

32 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 32 Different 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, 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

33 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 33 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.

34 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 34 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=B = Te = Tr

35 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 35 Examples 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 choicenondet. choice (a)(b) (c)(d) (e) x x x x x x x y y z y y y u v z uu v v y y

36 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 36 Example 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)

37 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 37 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.

38 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 38 5. 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.

39 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 39 Some 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

40 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 40 Suite 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: a P' i

41 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 41 6. 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.

42 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 42 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)

43 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 43 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.

44 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 44 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 RRR W RRel RReq RRel WRel RReq WReq RReq WReq yes no RReq WReq no R*RR* W* x1 x2x3 Note: the labels yes and no represent outputs while the other labels represent inputs (although such a distinction is not formally made)

45 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 45 Introducing 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.

46 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 46 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)

47 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 47 Components, 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 interface E1 E2C I1 I3 I2 component of environment

48 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 48 Specification formalism A/G Form of a specification of a component C: If the environment satisfies the assumption A C then the component C will guarantee the property G C 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 “A C implies G C “ (or “A C => G C “ ) 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 = (A C => G C ) and (A E1 => G E1 ) and (A E2 => G E2 ) Note: Let us hope that the assumptions made by E1 and E2 are small enough to be able to obtain interesting system properties.

49 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 49 Conforming specializations Definition: Given two specifications S C and S C’ of two components C and C’, respectively, we say that S C’ conforms to S C if S C’ implies S C (which means that all properties specified for S C are implied by the properties specified for S C’ ). We also say in this case that S C’ is specialization of S C. Note: S C’ => S C is equivalent to (A C’ => G C’ ) => (A C => G C ) and this is implied by [ ( G C’ => G C ) and (A C => A C’ ) ] If X => Y we also say that X is stronger than Y or that Y is weaker than X. Therfore “S C’ conforms to S C “ if the guarantees of S C’ are stronger than those of S C and the assumptions of S C’ are weaker than those of S C, which means [ ( G C’ => G C ) and (A C => A C’ ) ]

50 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 50 Conforming implementations, possibilities of replacement and reuse We say that an implementation conforms to a given specification S C 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 (A I => G I ), then a conforming implementation must satisfy (A I => G I ) => (A C => G C ). –Note: this is the same form of comparison as between specifications Important fact: If S C’ conforms to S C then an implementation conforming to S C’ could be used at any place in a system where a component satisfying the specification S C 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.

51 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 51 Different 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 S i and leads to a “refinement” S i+1 of this specification. – Since we want that the implementation conforms to the original requirement specification, one usually asks that S i+1 should conform to S i. Therefore one needs a conforming refinement. Special classes of refinements: Reductions: S i+1 conforms to S i and G i+1 is stronger than (not equal to) G i 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: S i+1 conforms to S i and A i+1 is weaker than (not equal to) A i S i+1 is defined for situations where S i 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

52 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 52 Composition: Structural refinement (an example) C1 I1 I2 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

53 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 53 Composition: structural refinement (the formalism) (Abstract) specification of component C: (A C => G C ) The refinement of the component in terms of three sub- components C1, C2 and C3 is given by the specifications (A Ci => G Ci ), i = 1, 2, 3, respectively. The properties of this structural refinement are given by (A C1 => G C1 ) and (A C2 => G C2 ) and (A C3 => G C3 ) If one wants that this refinement conforms to the original specification (A C => G C ) of the component C, one has to verify that [ (A C1 => G C1 ) and (A C2 => G C2 ) and (A C3 => G C3 ) ] => (A C => G C )

54 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 54 8. 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).

55 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 55 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)

56 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 56 suite a; t1=1 d; t2<1; reset t1 P Q c t1<5; reset t2 a; t1>2 P' b, t1<10 a timed automaton there 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 failed failure (1/1000000 ) Markov chain: example of a “hierarchical state diagram” à la StateCharts

57 Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 57 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 2 and probabilistic choice

Download ppt "Copyright 1999, 2003 G.v. Bochmann CN-FM ch.2 1 Course Notes on Formal Methods for the Development of Distributed Real-Time Applications Gregor v. Bochmann."

Similar presentations

Ads by Google