Formal Models for Encapsulation, Structure and Hierarchy in Distributed Systems

Transcription

1 Formal Models for Encapsulation, Structure and Hierarchy in Distributed Systems M.C.W. Geilen Section of Information and Communication Systems, Faculty of Electrical Engineering, Eindhoven University of Technology, P.O.Box 513, 5600 MB Eindhoven, The Netherlands. Abstract In order to deal with the complexity of hardware / software designs, design methodologies are applied, many of which are based on objectoriented design concepts, for example UML. Using such a methodology one can create executable models of the system to be designed. These models can be used to verify that the system displays the desired behaviour. Automated verification tools allow the designer to express wanted or unwanted behaviour of the system and search for satisfaction or violation of these behaviours. It is the state-space-explosion problem that makes that verification tools are typically applied to small models and that careful modelling is required to keep the number of reachable states small. For this reason, current languages and logics often operate on a low level of abstraction, offering little structuring and abstraction concepts. It is possible to use verification methods in other stages of the design process as well. Properties can be monitored during simulations of a system model. One would like to be able to use these logical properties in the same design framework, using such concepts as structuring and hierarchy, encapsulation, inheritance and so forth. In this paper we will investigate the use of formal models offering these concepts in the context of the design methodology SHE and its formal specification language POOSL. A calculus supporting structural hierarchy and encapsulation will be introduced with suitable equivalences. Furthermore temporal logics will be defined that fit to this calculus and it will be shown that such logics can be used to specify properties of hierarchical systems. Keywords formal verification, CCS, temporal logic, distribution, object-oriented methods I. INTRODUCTION Designing distributed concurrent real-time systems is a difficult task. Good design methodologies and good tool support are indispensable. In order to deal with the complexity of the system one often uses hierarchical decomposition techniques and modularity. Components interact through simple and well defined interfaces and should not depend on the internal structure of components it interacts with or of its subcomponents. Automatic analysis tools can be used to support system design, by analysing aspects of a design such as performance properties or correctness with respect to certain logical properties. The well-known state space explosion problem of concurrent systems make that such automatic analysis methods are often applied to small systems or severe abstractions of complex systems only. Moreover, one often likes to keep formalisms used in such methods as small and simple as possible. In order to scale up such formalisms to larger models however a need arises for the same concepts such as hierarchy, modularity and encapsulation. This may become necessary because formal techniques may eventually scale up to larger system, but in particular because it is also possible to perform (formal) nonexhaustive analysis on larger models, such as verifying temporal logic properties during simulations [9] or estimating performance figures from random state space traversals [23]. The developments in this paper are inspired by the use of the formal specification language POOSL ([22]) (Parallel Object-Oriented Specification Language) and its supporting tools. POOSL is a formal specification language for complex real-time distributed systems. It is especially suited to model systems having a static hierarchical structure of dynamic communicating processes in an object-oriented fashion. To analyse POOSL models and formalise their properties, formalism are required that suit to such concepts as encapsulation and structure and topology. In this paper we will introduce a calculus and temporal logics for modular and hierarchical systems, to serve as a basis for verification and analysis of POOSL models. In section II we will introduce CCCS ( Component-based CCS ), a calculus similar to Milner s CCS, with the ability to explicitly specify a static hierarchical structure of components. Its syntax and semantics will be introduced and we will discuss equivalence relations for the calculus and its relationship to pure CCS. Section III introduces methods to deal with the component structure of a system. It will be possible to derive CCCS expressions for individual components and to break up an execution trace of a system into contributing execution traces of its components. Extensions to temporal logics will be introduced in section IV, that can exploit the hierarchical structure of the system which results in some interesting possibilities such as a compositional use of the next operator in LTL. An example of a system specified in CCCS will be shown in section V. A component based version of Milner s jobshop is shown and some examples of logical properties are discussed. Incorporating the discussed concepts in the formal specification language POOSL will be the topic of section VI. We will finish with a discussion of related work, conclusions and future work. II. A CALCULUS OF COMPONENTS In this section we will introduce a calculus that serves as a formal model for hierarchically structured systems such as POOSL. We will use it as a simplified model of such languages. Because we want to deal with the structure and topology of a system, we assume that every system is built from a static part, which will not change during execution and dynamic parts that may change their structure. The static components will represent the static structure and topology of the system. The dynamic parts represent the dynamic behaviour of components, such as methods that are being executed by individual process objects in POOSL. Static components will have identifiers, allowing one to refer to parts of the hierarchical system.

2 A. Syntax of CCCS The syntax of our calculus will be close to CCS syntax, with the only differences being the separation of dynamic and static parts and the introduction of identified components and component definitions. The component definitions are a set of finitely recursive definitions of the form X def = R, where X is an identifier and R is an expression describing the behaviour of the component that will be referred to by the identifier X. By finitely recursive we mean that a definition of component X may not be defined in terms of itself neither directly nor indirectly via other component definitions. Furthermore the expression R may not (directly) refer to the same component twice (for example X def = Y Y ). This way the component structure will be a finite tree and every (sub) component can be uniquely identified. As a process expression executes, the structure and the identifiers will remain apparent from the syntactic structure. The dynamic part can have infinitely recursive definitions, by means of agent equations as in CCS. These dynamic parts model the (dynamic) internal behaviour of processes. We will refer to this calculus as CCCS, Component based CCS. Formally the syntax of CCCS is defined in two parts as follows. We assume as in CCS the sets A of names, Ā = {a a A} of co-names, L = A Ā of labels and Act = L {τ} of actions. We will use a to denote an element of A, a for an element of Ā, l ranges over L and α over Act. Let furthermore ID be a set of component identifiers and let X, Y,... range over ID. DP, the set of dynamic process expressions is defined inductively by the grammar: P ::= 0 a P P + Q fix j ({A i = E i i I}) P, Q DP. 0, prefixing, the + operator and recursion are the same as in CCS and are considered dynamic, since the operators can change or disappear after a transition (for example a P + b Q a P ). The static process expressions P are defined by: R ::= P R S X [R] X R[f] R\L P DP, R, S P, X ID, f : A A, L A. Note the resemblance to basic CCS, with the exception that we have separated the operators into static and dynamic operators and require that a process is two-layered, consisting of a static part, that combines purely dynamic parts. Furthermore there is an extra operator [R] X, allowing a process to carry an identifier which can be used to refer to that part if it is part of a larger process. The concepts of our calculus originate from the formal specification language POOSL, which is part of the Software Hardware Engineering methodology [22]. The language can describe complex concurrent real-time distributed systems. A POOSL model has a static hierarchy of interconnected process objects that operate concurrently. This structure is statically fixed, but the internal behaviour of processes can be dynamic. The formal semantics of POOSL are based on CCS extended with real-time [22], [10]. Our calculus closely resembles the syntax of POOSL and is a simplified version of it. We will not consider data and real-time, both of which are present in the POOSL language. Neither of these would be interesting to the topic of this paper and adding the latter to the calculus would be straightforward. There exists a modelling and simulation tool for the SHE method and POOSL, called SHESim [11]. This tool allows the naming of components, so they can be identified while visualising the model and its behaviour. The naming of components is not yet present in the formal semantics of POOSL and we are investigating the possibilities of adding it to the language. This allows one to make (formal) statements about the model that can be automatically analysed by software tools as will be shown in section IV. B. Semantics of CCCS The semantics of our calculus are similar to standard CCS semantics and will be defined in terms of a labelled transition system. Transitions in the calculus will also be labelled with actions, we will however decorate these action labels in such a way that it will be possible to determine not only what action has taken place, but also what component has performed the action. For this we extend the set L of labels as follows. Definition II.1: Let L e be the smallest set such that L L e l X,λ L e if λ L e, l L and X ID. We will use λ to denote elements of L e. Labels in L e can be decorated with an identifier indicating the component that originated the label and the label as it was issued by this component (it may have been relabelled in the meantime). The silent transition τ of CCS will now also be labelled such that one can reconstruct the way the internal action was produced (for example a communication). This gives rise to a set Silent of silent actions. Definition II.2: Define a set Silent of silent actions, ranged over by θ, as the smallest set such that τ Silent τ(λ 1, λ 2 ) Silent if λ 1, λ 2 L e τ X,θ Silent if θ Silent and X ID. The silent actions are decorated such that one is able to tell precisely (up to identified components) what caused the internal action. Let furthermore Act e = L e Silent and let γ range over Act e. Sometimes one would like to get rid of all decorations of an action. The function ACT abstracts all decorations from an action. Definition II.3: The function ACT : Act e Act is defined as γ if γ Act ACT (γ) = l if γ = l X,β τ if γ Silent The labelled transition system of our calculus can now be defined using these decorated labels as the triple ( ) P, Act e, { γ γ Act e }.

3 The semantics are defined as the smallest relations satisfying a certain set of axioms and rules. The dynamic operators are defined by the same rules as in CCS and generate only undecorated transitions. The inference rules for the component definition X are the following. X def = R, R γ R X ACT (γ) X,γ [R ] X [R] X R γ R ACT (γ) X,γ [R ] X Once component X starts executing, its identifier is remembered by the enclosing brackets. Whenever the component performs some action γ, the action is decorated with the identifier X and with γ itself, in order to be able to tell that the action originates from component X in the form of action γ. The communication rule of parallel composition ( ) is defined as P λ1 P Q λ2 Q ACT (λ 1 ) = ACT (λ 2 ) P Q τ(λ 1,λ 2 ) P Q When a communication takes place, the resulting action is a silent action, but it is decorated by the individual actions from which it originates. The relabelling rule R[f] R γ R f(γ) f f(a) X,β (γ) = f(a) X,β γ f (γ) R [f] if γ Act if γ = a X,β if γ = a X,β if γ Silent relabels the action, but leaves the decoration as it is and thus, the original action name is remembered in this decoration. We have thus introduced the syntax and semantics of our component calculus and will now take a look at suitable equivalences. C. Equivalence Relations for Components We have defined our labelled transition system to contain as much information as possible. Actions are decorated with identified components and other actions. One can define equivalence relations in terms of these actions in the normal way [16]. This yields an equivalence relation that assumes that an observer can see from which components the actions originate. It can see the names of the components and the names of actions as they were produced by the components. One might argue about the validity of this notion of observation. It is however in certain cases desirable to assume that an external observer is able to detect the distributed nature of the system [4] and the identity of the interacting components [19]. We will define the equivalences on abstracted actions without specifying the nature of the abstraction, resulting in equivalences that range from the traditional equivalences for CCS to equivalences that observe the entire component structure. Let f be an abstraction function on Act e. Now we can define strong bisimulation equivalence with respect to abstracted actions produced by f. Definition II.4: Let f be an abstraction function on Act e. A symmetric relation S P P is a strong bisimulation w.r.t. observability f if for any (P, Q) S and γ Act e, if P γ P, then for some Q and γ, f(γ) = f(γ ), Q γ Q and (P, Q ) S. Expressions P and Q are called strongly equivalent w.r.t. observability f (P f Q) iff there is a strong bisimulation w.r.t. observability f called S, such that (P, Q) S. We will write P Q if P and Q are strongly equivalent without abstracting information from the actions, if they are strongly equivalent w.r.t. the identity function. Correspondingly we define weak bisimulations, but first we will give some definitions (analogous to [16]). Definition II.5: Let t Act e, then t L e is the sequence gained by deleting all occurrences of symbols in Silent from t. Definition II.6: Let t Act e and t = γ 1 γ 2... γ n, then P t Q iff there exist P 1,..., P n+1 such that P 1 = P, γ i P n+1 = Q and for all 1 i n, P i Pi+1. Definition II.7: Let t L e then P = t Q iff there is some s Act e such that t = ŝ and P s Q. Weak bisimulation can now be defined as follows. Definition II.8: A symmetric relation S P P is a weak bisimulation w.r.t. observability f if for any (P, Q) S, if bγ P = P, then for some Q and γ, f(γ) = f(γ γ ), Q = b Q and (P, Q ) S. Expressions P and Q are called observation equivalent w.r.t. observability f (P f Q) iff there is a weak bisimulation w.r.t. observability f called S, such that (P, Q) S. Again we will write P Q if P and Q are observation equivalent without abstraction. It is obvious that greater abstraction leads to weaker equivalences. Definition II.9: Let f and g be abstraction functions, we will say that f is less abstract than g (f g) if for all γ 1, γ 2 Act e, f(γ 1 ) = f(γ 2 ) g(γ 1 ) = g(γ 2 ). Then the following is easy to verify. Proposition II.1: Let f and g be abstraction functions on Act e, then f g f g. Along the lines of [4], we will define a function pure : P P that removes all identification from a CCCS process and thus returns a pure CCS process. Definition II.10: Let P P then pure(p) is the pure CCS expression obtained by abstracting from component information. The precise definition of pure is straightforward; for example if P = X and X def = R then pure(p) = pure(r) and if P = [Q] X then pure(p) = pure(q). It will be shown in propositions II.2 and II.3 that abstracting CCCS processes that are equivalent w.r.t. abstraction function f ACT to pure CCS yields equivalent pure CCS processes; equivalence with respect to observability ACT corresponds to traditional equivalence of the corresponding pure CCS processes.

4 Proposition II.2: Let P, Q P and f ACT then P f Q pure(p) pure(q). Proof: This is easy to prove using the following lemmas. Lemma II.1: If P γ P ACT (γ) then pure(p) pure(p ). Lemma II.2: If P α P and P = pure(q) then there exist Q P and γ Act e such that Q γ Q, ACT (γ) = α and P = pure(q ). Moreover, both lemmas can be extended to sequences of symbols and to = transitions. Both lemmas can be proved by structural induction on process expressions. Similarly if we restrict the observability to external actions only, then the observer does not see the structure of the system and equivalence corresponds exactly to equivalence of the corresponding unstructured systems; the observation equivalence ACT corresponds to the traditional observation equivalence of CCS. Proposition II.3: Let P, Q P, then P ACT Q pure(p) pure(q). Proof: The direction ( ) follows immediately from proposition II.2. The other direction can be proved (using lemmas II.1 and II.2) by constructing a bisimulation for (P, Q) by adding the appropriate component definitions to all pairs of pure CCS process in the bisimulation of (pure(p), pure(q)). We have shown that it is possible to define equivalences for our calculus that allow an observer to detect the component structure and distributed nature of a CCCS process, depending on the level of abstraction we apply to the observable action. It has been shown that as long as this abstraction does not abstract away any of the externally observable actions, then the resulting equivalence is at least as strong as traditional observation equivalence of CCS and that taking ACT as the abstraction function makes the equivalences coincide. III. REDUCTIONS THROUGH HIERARCHY The extensions to the calculus allow us to view a system as a static structure of collaborating components. From this hierarchical structure, any of its identified components can be extracted again. Moreover, we can obtain from an execution trace of the entire system, the constituting execution traces of any of its components. A. Reduction of Process Expressions CCCS processes have structure that remains intact during transitions from state to state. At any given moment any component of the system can be identified in its defining expression. We will define a function that does exactly this, it reduces an expression to one of its identified components. R X will denote the expression R reduced to component named X. is a function : P ID P as defined inductively by table I. For example (let R X1.X 2.X 3 be an abbreviation of ((R X1 ) X2 ) X3 ): [([R] X [a/m] [S] Y [a/n]) \{a}] Z Z.X = R 0 TABLE I MODULE REDUCTION R R X P 0 R S R X S X Y R if Y X and X def = R 0 if X Y [R] Y R if X Y 0 if X Y R[f] R X R\L R X P DP; R, S P; X, Y ID; f : Act Act; L A In order to simplify the definition, components outside of the identified component are abstracted to the inactive agent 0. They could have been removed completely. The reduction function allows us to refer to the behaviour of a specific component of the system, even if the process expression is the result of taking an arbitrary number of transitions. B. Reduction of Traces When dealing with the execution of a system, one would like to be able to refer to the contributing executions of components of this system. We will formalise the notion of an execution of a system as a sequence of states and actions that are performed in the transition from one state to another, according to the labelled transition system of its semantics. Such a sequence will be called an (execution) trace. We will assume that such traces can be finite or infinite. Definition III.1: A trace s is a (possibly infinite) sequence such that (R 1, γ 1 ) (R 2, γ 2 ) (R 3, γ 3 )... if the trace is finite then s = (R 1, γ 1 ) (R 2, γ 2 )... (R n, ) and γ 1 γ 2 γ n 1 R 1 R2... Rn the symbol is used just to indicate the end of the trace; if the trace is infinite then for every m N: (R 1, γ 1 ) (R 2, γ 2 )... (R m, ) is a trace. We will say that the trace s is a trace of R if R is the starting process of the trace, i.e. if s = (R, δ) s (where s is either a trace or δ = and s is the empty sequence). We will use δ to range over Act e { } and s k will be used to refer to the trace (R k, γ k ) (R k+1, γ k+1 ).... In order to define the reduced trace s X, we first need to define reduction of actions as a function : Act e ID Act e { }, where γ X will be the action as it was issued by X (provided that the action originated from X) and if it did not originate from X.

5 Definition III.2: Let γ Act e, X ID then γ if γ = a X,γ if γ = a Y,γ, Y X γ X = if γ Act λ 1 X if γ = τ(λ 1, λ 2 ), λ 2 X = λ 2 X if γ = τ(λ 1, λ 2 ), λ 1 X = We will now define a reduced trace s X. Definition III.3: Let s be a trace, X ID and s = (R 1, δ 1 ) (R 2, δ 2 )... then (R 1 X, ) if δ 1 = or δ n X = for all n 1 s X = s 2 X if δ 1 X = (R 1 X, δ 1 X ) s 2 X otherwise One can show that if γ X =, then component X can not have changed by any transition labelled γ. This is expressed by the following lemma. Lemma III.1: If R γ R and γ X = then R X = R X. Proof: If γ X = then either (i) γ = l Y,δ and Y X, (ii) γ Act or (iii) γ = τ(γ 1, γ 2 ), γ 1 X = and γ 2 X =. These three cases can be proved separately by transition induction. Proposition III.1: If s is a trace, then so is s X. Proof: This can be proved for any prefix of s by induction on the length of the prefix and thus it holds for both finite and γ n infinite traces. The key is that one can show that if R n R n+1 is a step of the trace s, then if γ n X =, then by lemma III.1, R n+1 X = R n X if γ n X, then one can show by transition induction that γ X R n X Rn+1 X. Note that if s is an infinite trace, then s X is not necessarily infinite. We have shown that one can view the execution of a CCCS expression as a static structure of components. During the execution of the system one is able to identify the individual components and one can relate global execution traces and traces of constituting components. In the following section we will discuss temporal logics to express properties of CCCS systems that are able to observe and refer to identified system components. IV. TEMPORAL LOGICS FOR COMPONENTS Temporal logic is a popular technique to express dynamic properties of a system formally and can be used to automatically analyse CCCS or POOSL models for the satisfaction of such properties. There exist several varieties of temporal logics. One such variety are branching time temporal logics such as CTL/CTL [7] or Hennessy-Milner logic [13]. These logics are typically used to express properties of all of a system s behaviours and its branching structure at once. Linear time temporal logics on the other hand such as LTL [14] and Interval Temporal Logic (ITL) [17] typically express properties of the executions of a system, where LTL can express properties of infinite executions and ITL of finite ones. Apart from the differentiation between linear and branching logics, there is also choice between action based and state based logics. An action based logic views the behaviour as a system performing actions during transitions from state to state. Hennessy-Milner logic for example is often used to describe properties of CCS processes. The CCS process defines a labelled transition system (LTS) having transitions that are labelled by actions. States of a CCS agent do not have any properties (except for the absence or presence of outgoing transitions). Other logics are used in a state based way. The execution of a system is viewed as a sequence of states rather than a sequence of actions. It is assumed that there is a set of boolean properties, atomic propositions, that can be evaluated in every state of the system. Although the semantics of the POOSL language are based on CCS, particularly the use of data makes that there is a lot more to be said about the state of a POOSL model than of a CCS process. For a logic to be useful for the POOSL language, it is desirable that the logic be able to refer to both state properties and actions. The basic temporal logics view the execution of a system as a discrete sequence of actions or states. There exist extensions to calculi such as CCS with a notion of time (e.g., [15], [20], [24]) as well as extensions to temporal logic with quantitative real-time (e.g., [2], [12], [21]). Since the POOSL language is able to express real-time behaviour, it would be desirable to use logics that have this ability. We will however not discuss such logics here, since that would make the topic a lot more involved. A. Linear time logic We will define an action based variant of Manna and Pnueli s LTL [14], that is able to explicitly refer to the components of the system. The reasons that make this useful are the following. It will allow a better use of the next operator; this will be discussed later. It allows one to explicitly express the location of actions. One can express local action based properties, instead of only external actions, making it possible to express properties of closed systems as well, for example the composition of a system model and an environment model. It will enable a mechanism for encapsulating the internals of components. The syntax of the action based linear temporal logic is inductively defined by the grammar ϕ ::= α ϕ ϕ ϕ ϕ ϕuϕ X.ϕ X.χ α Act, X ID, χ PID The formulas that differ from standard LTL are X.ϕ, expressing that property ϕ holds for the execution reduced to the component called X and the formula X.χ which means the same, but allows one to use an identifier χ to refer to a property that is defined for the component X by a set of property definitions of the form X.χ def = ϕ. The semantics of the logic will now be defined. Let s = (R 1, γ 1 ) (R 2, γ 2 )... be a trace.

6 s = α iff α = ACT (γ 1 ) s = ϕ iff s = ϕ s = ϕ 1 ϕ 2 iff s = ϕ 1 or s = ϕ 2 s = ϕ iff s 2 = ϕ s = ϕ 1 Uϕ 2 iff there is some n 1 such that s n = ϕ 2 and for all 1 m < n, s m = ϕ 1 s = X.ϕ iff s X = ϕ s = X.χ iff s = X.ϕ where X.χ def = ϕ Other operators can be introduced in terms of these operators: true p p for some p Prop false true conjunction, ϕ 1 ϕ 2 ( ϕ 1 ϕ 2 ) the eventually operator ϕ trueuϕ the always operator ϕ ϕ as the dual of. Often the next operator ( ) is left out of the logic, because it can be used to express properties that are not stutter closed. When composing a system with another system using interleaving concurrency, the local part of the system can remain in the same state, while some other part makes a transition. This results in a repetition of the local state ( stuttering ). Since the next operator in standard temporal logic refers to a global next state, this makes the property sensitive to stuttering and thus makes the logic non-compositional. A property that holds for a certain system might no longer hold if the system is composed with another system. In this logic however one can write for example the property X. ϕ, because of the reduction to X, the next operator will refer to the local next state and not to the global next state. One can thus compose a component X with other components without disturbing any of its local properties. Action based logic usually only refer to external actions only. Internal actions are consumed and turned into unobservable silent transitions. Reduction allows one reason about internal actions as well, since one can express properties of the external behaviour of a component X inside a system P. B. Branching Time Logic We can also define an extension to a branching time temporal logic. We will extend Hennessy Milner Logic (HML) [13], with the ability to refer to identified components. The syntax of the logic is ϕ ::= true ϕ ϕ ϕ [A]ϕ µψ.ϕ(ψ) X.ϕ X.χ A Act, X ID. Intuitively, the meaning of these formulas is the following: true, negation and disjunction are obvious. The formula [A] ϕ states about a process that every transition labelled by an action in A will lead to a process that satisfies ϕ. µψ.ϕ(ψ) denotes the least fixed point operator as in HML and X.ϕ and X.χ state that the property ϕ respectively the property named χ holds for component X. Formally, the semantics can be defined as (let P P): P = true P = ϕ iff P = ϕ P = ϕ 1 ϕ 2 iff P = ϕ 1 or P = ϕ 2 P = [A]ϕ iff P P, γ Act e : P γ P ACT (γ) A P = ϕ P = X.ϕ iff R X = ϕ The semantics of the property µψ.ϕ(ψ) is defined formally as the smallest fixed point of the equation ψ = ϕ(ψ). Such a solution exists if every occurrence of ψ in ϕ(ψ) occurs within the scope of an even number of negations, so this is required for the formula µψ.ϕ(ψ). Furthermore, the recursion ψ should not occur behind any component identifier. For example the property in every execution the system will eventually be able to produce an a action can be expressed as the formula µψ. {a} true [Act] ψ. In this formula A ϕ is used as the dual of [A] ϕ, namely A ϕ ([A] ϕ), it is true if there exists a transition labelled by an action from A such that the resulting process satisfies ϕ. Other derived operators can be introduced in terms of these operators false true; conjunction, ϕ 1 ϕ 2 ( ϕ 1 ϕ 2 ); universal next operator (borrowing syntax from CTL), AXϕ [Act] ϕ meaning any possible next state must satisfy ϕ; the largest fixed point, νψ.ϕ(ψ) (µψ. ϕ( ψ)); always (at any time in any execution), AGϕ νψ.ϕ AXψ; etcetera. A simple yet interesting property that can be expressed by the formula [Act] false is deadlock ( every possible transition labelled by some action in Act leads to false can only be true if there is no transition at all). A property involving components is AG (X. {a} true Y. {b} true) expressing the fact that at any given moment in any given execution of the system, whenever component X is able to produce an action a, component Y is able to produce an action b. V. EXAMPLE As a small example we will look at the classical jobshop model [16]. Here we have a fixed structure consisting of a hammer, a mallet and two jobbers. We will construct a model that identifies these components as Hammer, Mallet, Jobber1 and Jobber2. The common behaviour of hammer and mallet can be defined by the set of equations for agent Tool: {Tool = get BusyTool BusyTool = put Tool} The Hammer component s behaviour is defined by: Hammer def = Tool[geth/get, puth/put] and the Mallet component by: Mallet def = Tool[getm/get, putm/put] We define two properties isused and isavailable of the hammer as (in HML): Hammer.isUsed def = {puth} true Hammer.isAvailable def = {geth} true

7 > I D F E - = I O E H = E 0 = > > A H C A J F K J F K J D C A J D K J - = I O K J H = K J 0 = For the component identified as Jobshop it always holds that whenever a message inhard is accepted, then eventually the hammer will be used. An example of a linear time property is (assuming Hammer.isUsed and Hammer.isAvailable have appropriate linear definitions) E - = I O K J - = I O Jobshop = Jobshop. (Hammer.isUsed Hammer.isAvailable). C A J C A J D E H = E 0 = = A J E - = I O C A J F K J F K J D C A J D E H = F K J F K J D 0 = A H K J - = I O K J H = K J H = K J 0 = It expresses that it holds for any execution of the jobshop that whenever the hammer is being used, then it will eventually become available again. The third example Jobshop = Jobshop. [{inhard}] (([ {outhard} ] false ) AUHammer.isUsed) E 0 = > > A H K J 0 = where AU is short for Fig. 1 THE COMPONENT STRUCTURE OF THE JOBSHOP The hammer is being used whenever it is able to accept a puth action and available whenever it is able to accept a geth action. We can do the same thing for the mallet. The definitions of the jobbers are Jobber1 def = JobberAgent Jobber2 def = JobberAgent where JobberAgent is defined by the equations {JobberAgent = ineasy outeasy JobberAgent +inhard UsehammerHard +innormal Usetool Usetool = UsehammerNormal + Usemallet UsehammerNormal = geth puth outnormal JobberAgent UsehammerHard = geth puth outhard JobberAgent Usemallet = getm putm outnormal JobberAgent} The entire jobshop system identified as Jobshop is defined by: Jobshop def = (Jobber1 Jobber2 Hammer Mallet) \{geth, puth, getm, putm} The component structure of the jobshop is visualised in figure 1. The following properties can be expressed (we will leave aside whether these properties are actually true or not). Jobshop = Jobshop.AG ( {inhard} AFHammer.isUsed) ϕ 1 AUϕ 2 µψ.ϕ 2 (ϕ 1 AXψ) and is an until operator that is universality quantified over execution paths. The property states that if a message inhard is accepted by the jobshop (from the initial state), then it will not be able to produce an outhard message before the hammer is being used. We have seen in this example how components in calculus and logics can be used to explicitly identify components of a larger system and their properties. We have furthermore shown how one can use logical properties to abstract from the internal structure of a component. This can be useful in compositional specification, in POOSL for example where classes encapsulate their internal structure and behaviour as we will see in the following section. VI. INCORPORATION IN POOSL We have introduced a calculus and temporal logics that support static structure and encapsulation. The basic motivation for this was to support system design using the formal language POOSL and its accompanying tools. The presented calculus is an abstract version of the POOSL language itself. Components correspond to POOSL s static structure of clusters, processes and channels. The dynamic expressions correspond to the internal behaviour of process objects. POOSL models also have data objects, ways to manipulate data and the ability to send or receive data over channels. This makes the semantics of POOSL too involved to discuss in the limited space of this paper (the semantics of POOSL can be found in [22] and its real-time extension in [8]). If one wants to introduce a logic to express properties of POOSL models, it should somehow be able to refer to data. Moreover, POOSL can express real-time behaviour. Adding time to the presented calculus is rather straightforward and orthogonal to the notion of components (see for example [10], [20], [24]). It is therefore left out of this paper. Logics that address quantitative timing properties also exist, but their use in the context of the POOSL language remains to be investigated. A logic for POOSL should be able to refer both to actions and transitions and to state based

8 properties. The definition of a property language for POOSL is future work. The object-oriented paradigm embraced by POOSL, suggests that internal structure and behaviour should be encapsulated and hidden from the outside. In order to express logical properties of such components it should not be required to mention aspects internal to the component. Component definitions and property definition are the interfaces that a class offers to users of the component. In our calculus we have combined component identifiers and component definitions. In POOSL there will be a class defining the internal structure or behaviour of a component and the actual creation of the component determines its identification. A class will also offer a number of logical properties to its user. So users of class can refer to these properties by name (Hammer.isUsed) rather than having to refer to its internal state variables for example. A. Related Work VII. CONCLUDING REMARKS There have been several approaches to make distribution more explicit in process calculi. This is usually supported by the idea that it can be convenient to say that communicating with a process reveals its internal distributed structure. Most calculi assume that it is the distributed nature that is observed and not the actual (names of) components or locations. To achieve this, location names are assigned dynamically while interacting with the system (e.g., [4]). Other approaches statically assign locations giving them observable names (e.g., [6], [19]). A good overview on distributed process algebra and distributed bisimulations can be found in [6]. Distributed bisimulations were introduced by Castellani in [5]. In [3], [4] a distributed semantics for CCS was given using dynamic locations. A corresponding equivalence relation called location equivalence was given that equates two processes only if they have the same distribution structure. In [6], based on [1], Castellani proposes an extension of CCS allowing static allocation of locations, although the equivalence is still insensitive to the actual names that were given. A similar approach is taken in [18]. Furthermore every operator in a process has to specify two location names for its two parameters. In our calculus operators can be left unidentified. Murphy proposes in [19] a different restriction / extension to CCS in which locations with names are given statically and considered to be observable by his notion of distributed bisimulation. Murphy has a layered approach in which local processes are given locations and composed in parallel. Nesting of locations however is not supported. Furthermore, communication between different locations is restricted. Equivalences are considered that are parameterised by a topology on the locations, that describes which locations are distinguishable by the observer and which locations are not. These topologies can be captured in our calculus by an appropriate abstraction function and nested locations. Murphy furthermore extends the communication with the ability to explicitly request a communication with a certain location. We did not use this extension for the reason that POOSL does not have such a construct (although the same result can easily be achieved in POOSL by using data and a concept called conditional message reception). Moreover, this addition no longer extends only the observability, but also the behaviour of a model. It will no longer be possible to abstract to a pure CCS process having the same behaviour ([19]). A temporal logic with locations was given in [3], [4] in the form of a logical characterisation in Hennessy-Milner style for their location equivalence. It uses formulas such as a l ϕ to express that a process can perform an action labelled a at location l and furthermore quantification over location variables to achieve the insensitivity to specific location names. Papers that employ a decomposition of execution traces in the way we have done in this paper, have not been found. This is probably due to the fact that CCS-like processes typically express externally observable behaviour, rather than the internal states of a system. In the context of the POOSL language this is more natural however, since in POOSL a process expression explicitly defines the hierarchical structure and states of the system components. B. Conclusions and Future Work In this paper we have introduced a calculus CCCS and temporal logics for hierarchical systems. We have introduced syntax, semantics and equivalences for the calculus. It is shown that the extension preserves equivalence if one abstracts from components. Other equivalences can be expressed as well by allowing an observer to see the location from which a message originates. We have introduced possible temporal logics for components and shown how they can be useful to specify properties of hierarchical systems. It has been shown that the logics offer a usable tool to deal with encapsulation of a component s internals. The reduction interpretation leads to a compositional next operator in the case of linear time temporal logic. Future work includes the extension of the syntax and semantics of POOSL with object identifiers. Furthermore the definition of a property language for POOSL is required, giving not only syntax for the temporal logic itself, but also for specifying the atomic propositions. Tools need to be developed or extended for automatically analysing properties. The temporal logics should also be extended with real-time features in order to be useful for POOSL. REFERENCES [1] L. Aceto. A static view of localities. Technical Report N 1483, INRIA Sophia-Antipolis, [2] R. Alur and T.A. Henzinger. Real-Time logics: Complexity and expressiveness. In Proc. Of the Fifth Annual Symposium on Logic in Computer Science, pages IEEE Computer Society Press, [3] G. Boudol, I. Castellani, M. Hennessy, and A. Kiehn. A theory of processes with locality. Technical Report Nr 1632, INRIA Sophia-Antipolis, [4] G. Boudol, I. Castellani, M. Hennessy, and A. Kiehn. Observing localities. Theoretical Computer Science, 114:31 61, [5] I. Castellani. Bisimulations for Concurrency. PhD thesis, University of Edinburgh, [6] I. Castellani. Observing distribution in processes: Static and dynamic localities. Technical Report N 2276, INRIA Sophia-Antipolis, May [7] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Automatic verification of finite state concurrent systems using temporal logic specifications. ACM Transactions on Programming Languages and Systems, 8(2): , [8] M.C.W. Geilen. Real-Time concepts for Software/Hardware engineering. Master s thesis, Faculty of Electrical Engineering, Eindhoven University of Technology, Eindhoven, The Netherlands, [9] M.C.W. Geilen, D.R. Dams, and J.P.M. Voeten. Applying verification methods to Non-Exhaustive verification of Software/Hardware systems.

9 In J. Veen, editor, Proceedings of CSSP-98, 9th Annual ProRISC/IEEE Workshop on Circuits, Systems and Signal Processing Mierlo, Netherlands, November 25-27, 1998, pages , Utrecht, The Netherlands, STW, Technology Foundation. [10] M.C.W. Geilen and J.P.M. Voeten. Real-Time concepts for a formal specification language for software / hardware systems. In Proceedings of ProR- ISC 1997, Utrecht, STW, Technology Foundation. [11] M.C.W. Geilen and J.P.M. Voeten. Object-Oriented modelling and specification using SHE. In R.C. Backhouse and J.C.M. Baeten, editors, Proceedings of the First International Symposium on Visual Formal Methods VFM 99, pages Computing Science Reports 99/08 Department of Mathematics and Computer Science, Eindhoven University of Technology, [12] T. Henzinger. It s about time: Real-Time logics reviewed. In D. Sangiorgi and R. de Simone, editors, Proceedings of the 9th International Conference on Concurrency Theory (CONCUR 1998), pages , Berlin, Springer Verlag. [13] D. Kozen. Results on the propositional µ-calculus. Theoretical Computer Science, 27: , [14] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems. Springer Verlag, New York, [15] G.J. Milne. CIRCAL and the representation of communication, concurrency and time. ACM Transactions on Programming Languages and Systems, 7(2): , april [16] R. Milner. Communication and Concurrency. Prentice Hall, Englewood Cliffs, New Jersey, [17] B. Moskowski. Executing Temporal Logic. Cambridge University Press, [18] M. Mukund and M. Nielsen. CCS, locations and asynchronous transition systems. In Proceedings of Foundations of Software Technology and Theoretical Computer Science FSTTCS 92, LNCS 652, pages Springer Verlag, [19] D. Murphy. Observing located concurrency. In Proceedings of Mathematical Foundations of Computer Science MFCS 93, LNCS 711, pages Springer Verlag, [20] X. Nicollin and J. Sifakis. An overview and synthesis on timed process algebras. In K. Larsen and A. Skou, editors, Proc. CAV 91 3rd International Workshop Computer Aided Verification, Ålborg, Denmark, July 1991 (LNCS 575), pages , Berlin, Springer Verlag. [21] J.S. Ostroff. Temporal Logic of Real-Time Systems. Research Studies Press, [22] P.H.A. van der Putten and J.P.M. Voeten. Specification of Reactive Hardware / Software Systems. PhD thesis, Eindhoven University of Technology, Department of Electrical Engineering, [23] J.P.M. Voeten, M.C.W. Geilen, L.J. van Bokhoven, P.H.A. van der Putten, and M.P.J. Stevens. A probabilistic real-time calculus for performance evaluation. In G. Horton, D. Möller, and U. Rüde, editors, Proceedings of the 11th European Simulation Symposium 1999, Erlangen, Germany, pages , Delft, The Netherlands, SCS. [24] W. Yi. CCS+Time = an interleaving model for real time systems. In J.L. Albert, B. Monien, and M.R. Artalejo, editors, Automata Languages and Programming. 18th Int.Coll.Proc. Madrid Spain, 8-12 July 1991, pages , Berlin, Springer Verlag.

10 This page was intentionally left blank