A Temporal Logic for Dynamic Systems and its Application to SDL Seung Mo Cho, Hyung Ho Kim, Sung Deok Cha, and Doo Hwan Bae Department of Computer Science and AITrc, KAIST 373-1, Kusong-dong, Yusong-gu Taejon, Korea fseung, hhkim, cha,
[email protected] Abstract
While the behavioral specifications explain how the system works, the property specifications represent what the system should fulfill. It is a common practice to describe the system requirements in a property specification language, and use it to validate behavioral models or implemented systems. Temporal logics[3] are often used as a property specification language in case of reactive or concurrent systems. They are logics equipped with the temporal operators for specifying the ordering of events or conditions. For example, we can represent with temporal logics the properties like “the warning must be raised after the elevator door opens”. Attempt to apply temporal logics to complex systems raises problems when we are to specify dynamic systems. In dynamic systems, the constituents are created and/or removed during run-time. In many cases, they are instantiated from templates, which are sometimes called as types or classes. The first problem comes from the fact that a system consists of instances of templates and there are interactions/dependencies among them. Classical temporal logics cannot properly handle the instances. They assume that a system is a collection of distinct subcomponents. Therefore, the interactions among the instances of same type are generally neglected when the analysis is done using temporal logics. Examples are the interactions of players in a multi-party game. The second is that process instantiation arises at runtime dynamically, but the specification of properties should be done statically, i.e. before runtime. Therefore, we cannot determine which instances are participating the events because they may vary time after time. First-order temporal logic, not propositional one, is the intuitive solution to these problems. Indeed, we can specify the properties of dynamic systems with first-order temporal logic properly in most cases. However, we encounter difficulties when we want to analyze with the properties specified using first-order temporal logic. First-order temporal logic is mainly used in the field of reasoning, but few tech-
Many modern complex systems have dynamic characteristics that their components are dynamically configured during run-time. However, few analysis techniques are available that consider the dynamic nature explicitly. We design a new temporal logic, called HDTL, to specify the properties of dynamically evolving systems, and develop an analysis method for this logic. Using them, we can specify the correctness requirements of a system and validate whether the system actually agrees with the requirements. The logic itself is rather an abstract one in that it can be used in connection with any operational language. As a concrete application, we present a combined use of HDTL with SDL. The experiment shows that HDTL is suitable for specifying dynamic properties and the analysis technique works well. Keywords : temporal logic, dynamic systems, requirement specification, validation, SDL
1 Introduction Most of computer scientists today agree that formal specification plays an important role in software development. At the early stage of development, specifying requirements formally can prevent many errors that are consequences of ambiguity. Moreover, the formal specification is crucial when it is needed to validate whether the resulting system is consistent with the requirements. It increases the confidence about the system correctness. Specification languages can be classified into two categories. One is for the specification of behaviors, and the other for the specification of properties. There exist many behavioral specification languages, most of which have their semantic basis in automata, Petri-nets, process algebra theories. On the other hand, property specification languages are needed to describe a system at higher abstraction level. 1
2p : p is always true from now on. pU q 2: From now, p remains true until q becomes true. pP q : p always precedes q.
niques are available about how to use it with automatic analyses, such as model checking or testing. We argue that classical first order quantifiers, such as 8 and 9, are the sources of complexity that make it difficult to deal with formalism algorithmically: the semantics of classical quantifiers are defined in terms of sets for characterizing meanings of variables. In general, we cannot characterize fixed sets for the valuation of the variables when verifying dynamic systems because the configuration of system components is evolving over time. Instead, we adopt the freeze quantifier proposed in TPTL(Timed Propositional Temporal Logic)[1]: the freeze quantifier is defined in terms of traces only. That is, the semantic definition of the freeze quantifier permits evaluation of a temporal formula including variables over a trace, without the notion of sets. Employing the concept of the freeze quantifier from TPTL, we designed a new temporal logic, called Half-order Dynamic Temporal Logic (HDTL) to specify and verify dynamic systems. Then we revise the existing tableau method[2] for verification of temporal logic, and suggest a dynamic analysis1 technique. Our formalism can be used in connection with most languages that support communication by message passing and dynamic configuration. As an example, we apply our formalism to the behavior specification language SDL[7], an international standard language for telecommunication systems. This illustrates how to combine a behavioral modeling language with HDTL. This paper is organized as follows. In Section 2, we present the related work of our research. HDTL is defined in Section 3, and the analysis using it is presented in Section 4. Section 5 is devoted to the application of HDTL to SDL. We give concluding remarks in Section 6.
where, p and q represent the propositions that have the truth values true or false depending on the state of systems. The name PTL (Propositional Temporal Logic) indicates that it has the semantic basis on the propositional logic. The tableau method plays an important role in algorithmic analysis of temporal logic. The key idea behind the tableau method is that any temporal formula can be split into two conditions: a non-temporal condition on the current state and a temporal condition on the next states, called a present condition and a future condition, respectively. For example, a formula 2f can be split into f on the current state and 2f on next states. There are a set of such splitting rules for each temporal operators[2]. Since, given a PTL formula, the number of conditions generated in this way is finite, we can construct a finite structure, called the initial tableau. It is an automaton that accepts precisely the set of strings satisfying the PTL formula. It is used in model checking[5] and testing[2]. Figure 1 is the initial tableau for 2(p ! 3q ). true (p
q)
p, q p, q
(p q q, (p
q) true q)
true
2 Background 2.1 Propositional Temporal Tableau Method
Figure 1. Initial tableau for 2(p ! 3q )
Logic
and
the 2.2 Timed Propositional Temporal Logic There are several temporal logics for specification of real-time systems. Most of them employ the first-order logic. They include a state variable representing time and the first-order quantifiers, such as 8 and 9, to quantify the time variable. Alur and Henzinger[1] suggested another form of quantification, called freeze quantification, in which every variable is bound to the time of a particular state. For instance, the typical time-bounded response requirement that every request p be followed by a response q within 10 time units, can be asserted by the formula
Temporal logic has been one of the most widely used formalisms for the specification of concurrent and/or reactive systems. Due to their declarative style of specification, they are regarded as especially suitable for the property specification. Frequently used temporal operators are as follows:
J p : p will be true at next instant. p : p will be true at next instant, or the current instant
is the final. p will eventually become true sometime in the future.
3p :
2x:(p ! 3y:(q ^ y x + 10))
1 Dynamic analyses are the analyses that are conducted with actual executions of a system. Testing and run-time monitoring can be regarded as most famous dynamic analyses.
2 This
2
is defined mainly to provide the dual operator of
U.
(read “whenever there is a request p, and the variable x is frozen to the current time, the request is followed by a response q , at time y , such that y is at most x + 10”). The key idea behind our work is that there exists a similarity between the real-time systems and the dynamic systems. Both of them require the notion of variables to represent the requirements specification; a variable representing time and variables representing the communicating components, i.e., the process identities for the sender and the receiver of messages. The variables, in both cases, may range over an infinite domain. The problem is to determine the proper quantification that is readable and enables the algorithmic analysis. We found that the freeze quantification is suitable for the specification of dynamic systems, also. We adopt the notation of the freeze quantification and suggest an analysis technique that is able to deal with dynamism.
clear that the lost information may be valuable in some applications. Especially, dynamic analyses can be benefited by it. Some properties can be specified only when we take the information about instances into account. We give such examples in Section 4 and 5.
3 Half-order Dynamic Temporal Logic
where x 2 V and l
3.2 Syntax and Semantics of HDTL Assume that there is a set V for variables x; y; z; : : :. The formulas of HDTL are built from proposition symbols by boolean connectives, temporal operators, and freeze quantifiers. Definition 1 (Syntax of HDTL) Term and formula of HDTL are inductively defined as follows:
3.1 Dynamic Systems and their Behavior
:= snd(x) j r v (x) j label(x) j l := 1 = 2 j false j 1 ! 2 1 U 2 j 1 U 2 j x:
j j
J j
2 L.
Two kinds of Until operators are needed when we consider finite traces. Additional operators are defined as usual. For example, : = ! false and 3 = true U . In x: , the variable x is bound by the freeze quantifier “x:” to the given event in which x: is evaluated. For example, consider an HDTL formula as follows:
To define a property specification language precisely, we develop the formal definition of the behavior of systems. We view the behavior of a system under analysis as a set of sequences of events, called traces, where each event denotes the occurrence of a message. Assume that there are an infinite set O and a finite set L for participating components and labels of messages, respectively. Note that the number of components is infinite because of dynamic instantiation. Formally, an event e 2 E is a triple hsender; re eiver; labeli where label 2 L is the label of the occurred message, denoted by label(e), and sender 2 O and re eiver 2 O are its sender and receiver, denoted by snd(e) and r v (e), respectively. Throughout this paper, given a trace = h0 ; 1 ; : : : n i, 0 denotes the first element of the trace and i denotes the trace that results from by deleting the first i elements. The juxtaposition 0 of two traces and 0 means successively followed by 0 . It looks interesting to compare our definition of the behavior of dynamic systems with other models, such as [4]. They build a precise execution model of object-oriented systems, with explicit consideration for the dynamic creation and removal of objects. However, their final definition of the language of a system (section 2.8, pp. 15, in [4]) does not include the information about the instances. Only the class names and the message names constitute the alphabet of the language. We think this simplification is inevitable, because their goal is to check whether there exists an inheritance relation between two classes. Including the information about instances certainly increase the complexity of the algorithm. However, at the same time, it is also
f1 : x:(label(x) = msg1 ) A trace satisfies this assertion if the first event 0 is of the form hs0 ; r0 ; l0 i, and l0 = msg1 . The variable x is bound to the current event, and referred in the remaining formula. We can extend this formula by adding a temporal operator like this.
f2 : 3x:(label(x) = msg1 ) Then, f2 is the formula asserting that the formula f1 should hold in the future, i.e., it requires that the trace should include an event i = hsi ; ri ; li i, such that li = msg1 . Another example concerning the dynamic aspect of a system will be given later in Section 4. Definition 2 (Semantics of HDTL) Let be a trace and E : V ! E an environment for variables. The pair (; E ) satisfies the HDTL formula if and only if j=E , where the satisfaction relation j= is inductively defined as follows:
3
j=E 1 = 2 iff E (1 ) = E (2 ) 2E false j=E 1 ! 2 iff j=E 1 ! j=E 2 j=E iff j j> 1 ! 1 j=E j=E iff j j> 1 ^ 1 j=E j=E 1 U 2 iff
J
– i
j=E
– j
j=E j=E
2 for some i 1 for all j, s.t., 0 j < i j=E 1 U 2 iff – i
1
for all j
0; or
2 for some i 1 for all j, s.t., 0 j < i j=E x: iff j=E [x:=0 ℄
0;
and j
j=E
0;
and j
j=E
in a formula. It should be noted that only the rule [rfrz℄ for freeze quantifiers changes the environment. It requires an event i to discharge a quantifier because the binding to the variable is dependent to the value of the current event. This motivates us to design a deferred representation called a flow tree. Formally, a flow tree G with respect to an HDTL formula ' is a labeled tree with the following components:
where E (f (x)) = f (E (x)), E (l) = l and E [x := i ℄ denotes the environment that maps x to i and the others to the same values as E . Note that the meaning of a freeze quantifier is defined in terms of a trace only. Thus, when a formula is closed, that is, all occurrences of variables are within the scopes of corresponding freeze quantifiers, its truth value is completely determined by a trace.
4 Dynamic Analysis
^ _ r)
[
2 3
℄
[r ℄ [r ℄
U
[r ℄ [r P℄
[r U℄ [r ℄
P
[r frz℄
^ f2 E _ f2 E f 1 ) f2 E 2f E 3f E f 1 U f2 E f 1 P f2 E f 1 U f2 E f 1 P f2 E x:f E
(
(f1 (f1
) ) )
( (
) )
( (
) )
( (
) )
(
)
! ! ! ! ! ! ! ! ! !
hff1 E ; f2 Egi hff1 Eg; ff2 Egi hf :f1 Eg; ff2Egi hff E ; J 2f Egi hff Eg; f 3fJEgi hff2 Eg; ff1E ; f1 U f2 Egi hff1 E ; :f2 Eg; f :f2 E ; f1 Pf2 Egi hff2 Eg; ff1E ; f1 Uf2 Egi hff1 E ; :fJ Eg; f :f2 E ; 2 f1 Pf2 Egi hff E x 0 gi (
)
(
)
(
)
(
(
(
(
( ) ) ( (
(
(
[
:=
))
)
( ) ) ( (
L
where Env is the set of all possible binding environments for the variables and l(') is the set of all subformulas of ' and their negations. Subformulas of ' are inductively obtained through its syntactic structure. For a location l 2 L, let Out(l) and In(l) denote the set of outgoing and incoming transitions, respectively. We say that for l 2 L, ht; l0 i is a branch of l when t 2 Out(l) and F (t; l0 ). It is worth noting that locations and transitions in G correspond to nodes and edges, respectively, in PTL tableau explained in Section 2.1. Similarly, a flow tree is constructed by applying the splitting rules in Table 1. All formulas of M(t) have no temporal operators, i.e. they represent present conditions. For l 2 L, M(l) denotes a set of hf; Ei pairs that are expected to hold in all descendants of l. This expectation can be checked inductively: M(l) holds over h0 ; 1 ; : : : ; n i when there is at least one branch ht; l0 i of l such that M(t) is evaluated true with 0 , and when M(l0 ) holds over h1 ; : : : ; n i. We proceed to define this notion formally. Let l and l0 be locations of G, t a transition of G, and e an event in E . We say that e enables t if for each pair hfi ; Ei i 2 M(t), hei j=Ei fi evaluates true. And we say that hl; e; t; l0i is a
In Section 2.1, we briefly introduced the tableau method for propositional temporal logic. The automatic validation procedure suggested in this section is a revised version of the tableau method[2]. Most notable difference between our method and the original one is that the tableau is not built before the analysis starts. It is incrementally constructed during the analysis. The tableau for a propositional temporal logic formula is statically generated using the splitting rules[2]. However, tableaus for HDTL formulas can not be defined solely by the formulas. Actual executions are required also. To overcome this problem, we decided to adopt a dynamic strategy, i.e. constructing tableau incrementally. [r ℄ [r ℄
Locations : An infinite set L of locations. Transitions : An infinite set T of transitions. Labeling function : A function M that maps each location and transition to the set of pairs of a formula and an environment. M : (L [ T ) ! 2h l(')Envi Flow relation : A relation F representing the edges of the flow tree. F (L T ) [ (T L) Initial locations : A set I of initial locations. I L Final locations : A set A of accepting locations. A
))
he;ti
he;ti
move of G, and write l ! l0 . A move l ! l0 is said to be legal iff t 2 Out(l) \ In(l0 ) and e enables t. Suppose = h0 ; 1 ; :::; n 1 i 2 E is a trace with length n. Then has a run of G, a sequence of locations hl0 ; l1 ; : : : ; ln i with length n + 1, when there is a transition
)
℄
Table 1. Splitting Rules
hi ;ti i
! li+1 is legal for 0 i n 1. We say that the flow tree G accepts the trace iff there is a run hl0 ; l1 ; : : : ; ln i of G on such that l0 2 I and ln 2 A. Now we develop a validation technique using the defined flow tree. As opposed to the usual tableau method, we construct a flow tree dynamically since its size may be infinite. ti such that li
Table 1 shows the splitting rules we use for HDTL. We interprete a set of formulas ( f: : :g ) as a conjunction of them, and a list of sets (hf: : :g; : : : ; f: : :gi) as a disjunction of conjunctions. The entities that the rules are applied to are the pairs (f E ) of a formula and an environment. The environment is used to keep the bindings for the variables 4
function monitor(: event, B : location) begin redu ed := ; B 0 := ; forall bj B begin redu ed := redu ed apply rules(bj , ) end; forall disjunct reduced begin a := atomic-part(disjunct); n := next-part(disjunct); if evaluate(a, ) then B 0 := B 0 remove next(n) ; end; return B 0 end
;
2
;
2
[
[
Let us give the concrete visualization of the flow tree with an example.
Figure 2. Dynamic Analysis Algorithm
f0 =2x:(label(x) = msg1 ! 3y:(label(y) = msg2 ^ r v(x) = snd(y)))
Main idea behind the deferred representation of flow trees is that it is enough to keep the leaf locations only: when an event, say i , is given, it is possible to determine whether or not each branch of the current leaf locations is legal with respect to i . At this point, we expand all branches of the current leaf locations and prune back illegal branches. Note that previous locations and transitions are unnecessary for determining the acceptance of the remaining trace. Thus, we can safely remove them and only maintain the new leaf locations. Let Bi be a set of leaf locations for processing the event i . Then Bi = fbi;1 ; bi;2 ; : : : bi;m g where M(bi;j ) = fhf1; E1 i; hf2 ; E2 i; : : :g represents the label of each leaf locations. The meaning of bi;j is characterized by the conjunction of its elements. Analogously, the meaning of Bi is characterized by the disjunction of meanings of its elements. We design a function monitor that implements the deferred representation explained above (Figure 2). We use some functions whose definitions are informally given below.
= ;. This means that the current event i enables no transitions, and thus the failure of validation. The analysis tool reports the occurrence of the inconsistency between the specification and the execution trace. Bi+1 \ A 6= ;. This means that there exist the accepting locations in Bi+1 . We can conclude that the trace so far conforms to the specification. Bi+1 \ A = ;. This means that the remaining trace should include some events to satisfy the specification. Thus, in the current position, the trace does not conform to the specification.
Bi+1
(1)
The above formula states that whenever a component sends a message msg1 to another component, the message msg2 should be returned eventually from the receiver of msg1 . At first, the flow tree of level 1 is generated as shown in Figure 3. Locations are shown as ellipses and transitions are denoted by rectangles. Duble ellipses designate the final locations. L0
T1
T2
T3
L1
L2
L3
Pruned
fh ;ig fh ;i h f 7! gig fh ;i h ^ f 7! gig fh 6 ^ fh fh ;ig
L0 := L1 := L2 := f0 ; L3 := f0 ; ; f1 ; x 0 := f0 ; ; 3y:(label(y ) = msg2 r v(x) = snd(y)); x T 1 := label(x) = msg1 ; x 0 T 2 := label(x) = msg2 r v(x) = snd(x); x 0 T 3 := true;
apply rules : applies the splitting rules in Table 1. atomic-parts : extracts the atomic formulas, i.e. ones whose truth value is determined by the current event. next-parts : extracts the next formulas, i.e. ones with outermost next temporal operators ( ; ). remove next : removes the outermost next operators. evaluate : evaluates an atomic formula using an event.
J
f 7! 0 gig
f 7! gig
Figure 3. Flow tree of level 1 for the formula 1 Then the function monitor reads the value of the first event 0 from the environment. It determines the leaf nodes that can be pruned out. If the label of the first event 0 is msg1 (i.e. label(0 ) = msg1 ), then only the condition assigned in the transition T 3 is evaluated true. The locations L1 and L2 are pruned off, and the analysis proceeds with the location L3. The flow tree of level 2 is shown in Figure 43 .
The input of monitor is the pair of an event i and Bi constructed with current leaf locations. When i and Bi are given, monitor generates all branches of B using the rules in Table 1, prunes back illegal branches with respect to i , and outputs the new set of leaf locations Bi+1 . Then the consistency between the HDTL specification and the trace monitored so far is determined by Bi+1 and the set A. We can list the possible cases as below:
3 The
5
labels of T4-T8 and L4-L8 are omitted due to space limitation.
be defined by means of a type. If the system has several instances with the same behavior, a type is defined, and instances are created according to this type. Each process instance is assigned a unique process identity (PID), which is a combination of the process type name and an integer. Processes interact with sending and receiving signals. In order for processes to interact by means of signals, they have to be connected by signal routes. Communication is asynchronous: the sending process does not wait until the signal is handled by the receiver, and the receiving process will keep signals in its queue until it reaches a state in which it is prepared to handle it.
L3
T4
T5
T6
T7
T8
T9
L4
L5
L6
L7
L8
L9
Pruned
::: T 9 := true; L9 := f0 ; ; ; 3y:(label(y) = msg2 3y:(label(y) = msg2
fh ;ig fh ; i h h
^ r v x ^ r v x
( )= ( )=
f !7 1gi; f !7 0gig
snd(y); x snd(y); x
5.2 Connection between SDL and HDTL We regard the behavior of an SDL system as a set of traces of signals that are communicated between the processes. To apply our method to SDL systems, we need a CASE tool which supports the execution of models. Using the tool, we can collect the behaviors of an SDL system in terms of traces. We use Telelogic Tau/SDL suit[8]. It provides powerful simulation and validation features. Simulation is done interactively via GUI. Users can control the execution at various levels, and monitor the effects through SDL diagrams or MSC diagrams. Validation in Tau/SDL may be characterized as state space exploration with rule checking. State space exploration is performed with various levels of completeness, from simple random walk execution to exhaustive exploration of system states. During exploration, a set of rules are checked to validate the execution. They consist of the predefined rules such as deadlock, and the user-specified rules which, in general, are the negations of state invariants. If the validator finds a state that satisfies a rule, it generates a report and the user can trace the path from the initial state to the satisfying state. We use the validator and, especially, the random walk facility to collect the behaviors (traces) of SDL models. We implemented a post-processor that translates a path information generated by the validator into a sequence of messages exchanged among the SDL processes. The sequence, in turn, is then checked against HDTL specifications using the monitor described in Section 4.
Figure 4. Flow tree of level 2 for the formula 1
Then, again, the second event 1 is used to expand the flow tree. If the label of 1 is also msg1 , the tree is pruned back as in Figure 4. We can see at L9 that, to satisfy the specification, there should be two more distinct events whose labels are the same (msg2 ), but senders are different. In this way, the analysis proceeds with the evolution of the flow tree. We emphasize again that the whole nodes of the trees need not to be stored during the analysis. Only the set of leaf nodes are managed during the analysis.
5 Application to SDL Suggested framework is rather an abstract one in that it can be applied to any operational language that supports dynamic and multiple instance creation. We make a behavior model of a system with an operational language. Then using HDTL, we specify the crucial properties that the system should obey, and analyze to examine whether the actual executions satisfy the specification. In this section, we present a combined use of HDTL with SDL[7]. Executions of an SDL model are tested against HDTL formulas. It can reveal the inconsistency between the execution traces and HDTL specification.
5.1 Basics of SDL 5.3 Example: A Conference Model Specification and Description Language (SDL) is an ITU-T standard language for modeling and implementing reactive, discrete systems. It has long history of application in the field of telecommunication systems. An SDL system can be considered as a collection of process instances. They may be of different entity kinds, and their behaviors may either be directly defined or they may
As an example, we apply the proposed technique to the analysis of a conference model originally suggested in [6]. The system consists of four kinds of objects, representing the conference chair, the sessions, the session chairs, and the participants. The typical scenarios of the system can be listed up as follows: 6
them. The behavior of “ConferenceChair” process is defined directly, but others are defined indirectly by the process type definition. For example, “Session(0,): Session” represents the process instances of type “Session”. We specify the lower bound (0) of instances only, which states that initially there are no instances and the process creation is not limited by an upper bound. Double-lined rectangles below are the references to the type definitions. Figure 6 is the SDL behavior diagram for Session type definition. Other diagrams are omitted due to space limitation.
A conference chair manages the global procedure of the conference events, for example, the opening and closing of sessions. A participant registers for a conference, and joins one of currently progressing sessions. After the session is over, all of the participants will leave it. A session chair initiates a session, and then allows the speakers to make their presentations in order. After each presentation is over, the chair allows the participants to discuss about the presentation. When the chair notice the end of the discussion, he initiates the next presentation or finish the session.
process type Session
1(1)
Timer T; DCL Plist PIDlist;
C9
DCL Pchair PId;
In the initial setting, the system consists of only one conference chair object. It initiates session chair objects on the request of NewSession from the environment. Then, they initiate the session objects. New participant objects are created and register for the conference during the system runs. That is, this system is dynamic. block ConfSystem
opened, closed
C4 PresOver EndPresentation, EndDiscussion, SessionIdle
NewPerson, NewSession
C8
C3
Plist
Discussing
KickOut to First(Plist)
else
Initial
StartPresentation
C5 set (Now + 3, T);
SessionChair(0,) :SessionChair
ConferenceChair
EndSession
set (Now + 1, T);
Plist := Substring(Plist, 2, Length(Plist) - 1);
T
KickOut
JoinSession
C1
opened
SessionIdle to Pchair
SIGNAL ReqSessions, SessionsOpen(PIDlist, integer), opened, closed, EndPresentation, EndDiscussion, SessionIdle, StartPresentation, StartDiscussion, EndSession, JoinSession, KickOut;
R8
StartDiscussion
Emptystring StartPresentation, StartDiscussion, EndSession
1(1)
Newtype PIDlist String (PId, Emptystring) EndNewtype;
Pchair := parent
C1
*
Presenting
C2
T
EndDiscussion to Pchair
Initial
*
closed
sink
JoinSession
R5 opened, closed
R7 ReqSessions
R1 EndPresentation, EndDiscussion, SessionIdle
R6 SessionsOpen
C11
C4
C10 C6
R3
JoinSession
C5
Participant(0,) :Participant
StartPresentation, StartDiscussion, EndSession
PresOver
R4
KickOut
Session
Plist := Plist // Mkstring(sender);
sink
-
C1
C9
Figure 6. SDL behavior diagram: Session
Session(0,) :Session C7
Participant
EndPresentation to Pchair
R2
C8
We have identified a set of properties the system must obey. The direction of each message is depicted in Figure 5, and its meaning is intuitive. Below is the property saying that a participant cannot join two sessions simultaneously.
SessionChair
2x:(label(x) = JoinSession !
(:y:(label(y) = JoinSession ^ snd(y) = snd(x)) Uz:(label(z ) = EndSession ^ r v (z ) = r v (x)))) Roughly speaking, this asserts that, once an event JoinSession happens, it cannot occur again until the event EndSession happens. In traditional linear temporal logic, they might be expressed as 2(JoinSession !
(:JoinSession U EndSession). However, in the case of dynamic systems, we should take the instance information into account also. The requirement
Figure 5. SDL System Diagram - ConferenceSystem
Figure 5 is the SDL system diagram that depicts the structure of the system. It shows the process instances which exist during the runtime, and the signal routes among 7
prohibits the second occurring of JoinSession, only when the instance sending the signal is the same one that has sent the signal JoinSession. Note that we can’t specify these properties with the traditional temporal logic. HDTL incorporating variables and freeze quantifier makes the specification and the analysis of these properties possible.
E1:
Participant:16
JoinSession
Session:7
E2:
SessionChair:5
EndSession
Session:5
E3:
SessionChair:6
EndSession
Session:6
E4:
Participant:16
JoinSession
Session:5
E5:
SessionChair:7
EndSession
and the system behavior can be tested against the specification. We defined the syntax and semantics of HDTL, and implemented the analyzer. To show the usability of our framework, We applied HDTL to SDL. Combined use of Tau/SDL validator and HDTL provides an advantage, over using the validator alone, that more complicated specifications can be examined. Tau/SDL validator permits users to describe specifications only in terms of state invariants. However, some complex specifications require the expressiveness of temporal logics that permits properties about the sequence of states. HDTL can fulfill this needs. There are some issues that are worth further research. We believe that there are possibilities of tuning up the analysis algorithm for efficiency. Using HDTL with other kinds of analyses, such as model checking, would be very fruitful. We are currently working to combine HDTL with SPIN[5].
error
Session:7
References
Figure 7. A violation
[1] R. Alur and T. A. Henzinger, “A Really Temporal Logic,” The Journal of the ACM, Vol 41, pp. 181-204, 1994. [2] L. K. Dillon and Y. S. Ramakrishna, “Generating Oracles from Your Favorite Temporal Logic Specifications, ” Proc. 4th ACM SIGSOFT Symp. Foundations of Software Engineering, San Francisco, pp. 106-117, October 1996. [3] E. A. Emerson, “Temporal and Model Logic,” Handbook of Theoretical Computer Science, Chap 16, edited by J. van Leeuwen, Elesevier Science Publishers, 1990. [4] D. Harel and O. Kupferman, “On the Inheritance of State-Based Object-Behavior,” TR. MCS99-12, Faculty of Mathematics and Computer Science, The Weizmann Institute of Science, June 1999. [5] G. Holzmann, “The model checker SPIN,” IEEE Transactions on Software Engineering, vol. 23, no. 5, pp. 279-295, May 1997. [6] J.S. Lee, S. Y. Min, D. H. Bae, “Aspect-Oriented Design (AOD) technique for Developing Distributed Object-Oriented Systems Over the Internet,” in Proc. of 5th International Computer Science Conference, Springer-Verlag, 1999. [7] A. Olsen et al., System Engineering Using SDL-92, Elsevier Science, North-Holland, 1997. [8] Telelogic, “Telelogic Home Page,” http://www.telelogic.com/
At the first experiment, we found a violation of this HDTL formula. Part of the sequence of events leading to the violation is depicted in Figure 7. It shows that the participant-16 joins another session (session-5), even though currently attending session (session-7) isn’t over yet. However, careful investigation has revealed that the cause of inconsistency is not a modeling error. It is because Tau/SDL reuses the PIDs. When a process instance is removed, other instances whose PIDs are larger than the removed one are assigned new PIDs. In this case, “Session:5” is removed after receiving the signal EndSession (E2). Then, “Session:6” at E3 is actually the same one as “Session:7” at E1. Thus, “Participant:16” is not attending any sessions at E4 Reusing PIDs is a good idea at some purpose, of course. Users can easily see how many instances of each type exist during simulation. However, it brings about some problems, also. First, it doesn’t match with how actual systems behave. Second, it makes difficult to analyze systems with complex dynamic instantiation. Extracting and analyzing only the relevant events is not easy with this scheme. We modified the model to evade this problem. When a process instance is to be removed, it goes to a special state sink, instead of being deleted actually. After this modification, we can observe that the executions of the model obey the HDTL specifications.
6 Conclusion In this paper, we suggested a framework which enables the analysis of dynamic systems. The specification involving complex dynamic process creation can be expressed, 8
