Using Temporal Logic to Specify Adaptive ... - Semantic Scholar

Using Temporal Logic to Specify ∗ Adaptive Program Semantics

Ji Zhang and Betty H.C. Cheng Software Engineering and Network Systems Laboratory Department of Computer Science and Engineering Michigan State University East Lansing, Michigan 48824

Abstract Computer software must dynamically adapt to changing conditions. In order to fully realize the benefit of dynamic adaptation, it must be performed correctly. The correctness of adaptation cannot be properly addressed without precisely specifying the requirements for adaptation. This paper introduces an approach to formally specifying adaptation requirements in temporal logic. We introduce A-LTL, an adaptation-based extension to linear temporal logic, and use this logic to specify three commonly used adaptation semantics. Composition techniques are developed and applied to A-LTL to construct the specification of an adaptive program. We introduce adaptation semantics graphs to visually represent the adaptation semantics, which can also be used to automatically generate specification for adaptive programs. Key words: Keywords: dynamic adaptation, temporal logic, specification, model checking, autonomic computing

∗

This work has been supported in part by NSF grants EIA-0000433, EIA-0130724, ITR-0313142, and CCR-9901017, the Department of the Navy, Office of Naval Research under Grant No. N00014-01-1-0744, and a grant from the Michigan State University Quality Fund program. Email address: {zhangji9,chengb}@cse.msu.edu (Ji Zhang and Betty H.C. Cheng).

Preprint submitted to Elsevier Science

7 February 2006

1

Introduction

Increasingly, computer software must adapt to changing conditions in both the supporting computing and communication infrastructure, as well as in the surrounding physical environment (1). However, adaptive programs may be prone to errant behavior due to its innate high complexity and possibly imprecise requirements. The benefit expected from adaptations, such as higher reliability and higher availability, may be countered by the errors introduced during the adaptive software development process. Furthermore, the correctness of adaptation becomes most crucial when the adaptive software is applied in a safety-critical domain, such as the control software for medical devices, etc. Correctness of adaptive programs cannot be properly addressed without precisely specifying the requirements for the adaptive programs. This paper introduces specifications for three commonly used adaptation semantics and two composition techniques to be used for constructing the temporal logic specification of an adaptive program. Numerous techniques have been proposed to address the correctness of adaptations. Kulkarni et al. (2) introduced a transitional-invariant lattice approach that uses theorem proving techniques to show that during and after an adaptation, the adaptive program is always in correct states with respect to satisfying the transitional-invariants. Some approaches (3; 4; 5) use formal languages to describe the structural changes of the software at the design and implementation levels. Other approaches (6; 7; 8; 9; 10; 11; 12; 13) design adaptation protocols or algorithms to be used during component replacement to achieve a rigorous and safe adaptation procedure. Different approaches assume different adaptation semantics. For example, Appavoo et al. (12) introduced a hotswapping technique, which does not allow the old and the new components to execute simultaneously to achieve strict sequential semantics. In contrast, in order to improve performance, Chen et al. (11) proposed a graceful adaptation process, which allows the old component and the new component to overlap their executions. These different semantics are implied by their designs and implementations. All of the above techniques focus on the design and the implementation of achieving adaptability, while the requirements for adaptation are largely assumed or ambiguous. We believe that the semantics for adaptive software should be explicitly captured at the requirements level (14). The correctness of adaptive software can then be evaluated with respect to its adaptation requirements specification. A recent survey (15) describes numerous research efforts that have proposed ways to formally specify dynamically adaptive programs in the past several years. Graph-based approaches model the dynamic architectures of adaptive programs as graph transformations (16; 17; 18). Architecture Description Language (ADL)-based approaches model adaptive programs with connection and

reconnection of connectors (10; 19; 4). A few efforts have formally specified the behavioral changes of adaptive programs, including those that use process algebras to specify the behavior of adaptive programs (20; 21; 22). This paper focuses on the specification of requirements of adaptations with temporal logics. We model an adaptive program as the composition of a finite number of steady-state programs (20) (briefly programs) and the adaptations among these programs. We assume that the properties (e.g. liveness and safety properties) of each program have already been specified with a Linear Temporal Logic (LTL) formula (23). To specify an adaptation from one program to another, we introduce the Adapt operator-extended LTL (A-LTL), an extension to LTL. We introduce three basic adaptation semantics and use A-LTL to formally specify their semantics. We can compose the basic adaptation semantics with two types of compositional procedures: neighborhood compositions and sequential compositions to derive more complex adaptation semantics. We introduce adaptation semantics graphs, a graph-based representation of adaptive programs semantics, which can be automatically processed to generate adaptive program specifications. The formal specifications for adaptive programs precisely describe the objectives for adaptive programs, which facilitate rigorous software requirements specifications, and thus improves the assurance of the software. The adaptation semantics graphs and the generated temporal logic specifications may serve as guidance for the adaptation developers to clarify the intent for the adaptive program. The temporal specifications also enable us to perform numerous automated analyses of the adaptive program, such as specification consistency, model checking to verify the correctness of a program model, dynamic insertion of adaptation logic code into the program, etc. We have successfully applied our specification technique to a number of adaptive mobile computing applications, including MetaSockets (24). The remainder of this paper is organized as follows. In Section 2, we introduce A-LTL and describe three basic adaptation semantics. Section 3 describes neighborhood specification compositions, sequential specification compositions, and adaptation semantics graphs. Section 4 illustrates our approach with a MetaSockets example. Section 5 concludes the paper and discusses future directions.

2

Adaptation Semantics

In this paper, we take a most general view of programs, i.e., all programs and adaptive programs are considered as state machines (FSAs). An adaptive program changes its behavior during its execution. The state space describing each different kind of steady-state (20) behavior is a non-adaptive program, or

briefly a program. The state space describing the change of behavior from one program (source program) to another (target program) is a simple adaptive program, which can be identified by the source and target program pair. 2.1 Adapt Operator-Extended LTL LTL is a temporal extension to propositional logic (23). An LTL formula is constructed over a set of atomic propositions (Π), using ¬ (not) and ∧ (and ) boolean operators, and (next) and U (until ) temporal connectives. Other operators are defined as abbreviations over the above basic operators, such as ∨ (or), → (imply), ↔ (co-imply), ♦ (eventually), 2 (always), etc. Existing LTL operators are insufficient for specifying adaptation behavior. In LTL, the operator closest to capturing the meaning of adaptation is the until ( U ) operator. However, we cannot express an adaptation from the behavior specified with φ to the behavior specified with ψ using φ U ψ for the following reason: If a state sequence σ = s0 , s1 , · · · satisfies φ U ψ (denoted as σ |= φ U ψ), then φ should hold for all suffixes of σ starting from all the states before a certain state. However, adaptation semantics usually only require φ to hold for a given interval of σ. Several temporal logics,including the choppy logic (25), the Propositional Interval Temporal Logic (PITL) (26; 27; 28; 29; 30), and the Interval Temporal Logic (ITL) (31), are capable of expressing adaptation behavior. However, these logics are both too complex and inconvenient for our adaptation specification purposes. By “inconvenient” we mean that they do not have direct notation support. To specify adaptation behavior, we extend LTL with the adapt operator Ω Ω (“*”). Informally, a program satisfies “φ*ψ” (φ, ψ, and Ω are three temporal logic formulae) means that the program initially satisfies φ. In a certain state A, it stops being constrained by φ, and in the next state B , it starts to satisfy ψ. We formally define A-LTL as follows: • If φ is an LTL formula, then φ is also an A-LTL formula. Ω • If φ and ψ are both A-LTL formulae, then ξ = φ*ψ is an A-LTL formula. • If φ and ψ are both A-LTL formulae, then ¬φ, φ∧ψ, φ∨ψ, and φ U ψ are all A-LTL formulae. We define the A-LTL semantics as follows. • If σ is an infinite state sequence and φ is an LTL formula, then σ satisfies φ in A-LTL if and only if σ satisfies φ in LTL. Formally, σ |= φ iff σ |= φ in LTL. • If σ is a finite state sequence and φ is an A-LTL formula, then σ |=f φ iff σ 0 |= φ, where σ 0 is an infinite state sequence constructed by repeating the

last state of σ. Ω • σ |= φ*ψ iff there exist a finite state sequence σ 0 = (s0 , s1 , · · · sk ) and an infinite state sequence σ 00 = (sk +1 , sk +2 , · · · ), such that σ = σ 0 _ σ 00 , σ 0 |=f φ, σ 00 |= ψ, and (sk , sk +1 ) |=f Ω, where φ, ψ, and Ω are A-LTL formulae. Ω A sequence satisfying φ*ψ can be considered the concatenation of two subsequences, where the first subsequence satisfies φ, the second subsequence satisfies ψ, and the two states connecting the two subsequences satisfy Ω. • Other operators (→, ∧, ∨, U , ¬,etc) are defined similarly as those used in LTL. The Ω notation of an adapt operator can be used for specifying additional safe conditions for the state in which the adaptation occurs and logical connections between the behavior before and after adaptation. Although in some cases, the extra constraints are not used (where we simply set Ω to be true), we find this notation to be useful in many other cases. For example, we can use Ω = buffer-empty to constrain that the buffer must be empty when the adaptation occurs. We separate the behavior of an adaptive program into adaptation invariants, the properties that hold continuously during an execution of the program, and adaptation variants, the properties that change during the program’s execution. We first introduce three adaptation semantics specifications in A-LTL. These semantics are used to specify the adaptation variants of adaptations from a given source program to a given target program. Then we introduce composition techniques to handle general adaptive programs. Finally, we compose adaptation invariants with adaptation variants to specify the overall adaptive program behavior.

2.2 Semantics for Adaptation Variants

Several questions have to be answered before designing an adaptive program: (1) What is the expected behavior after adaptation? (2) What constraints, if any, exist for adaptations to occur? (3) Are the source program behavior and the target program behavior allowed to overlap? (4) Should the source/target program behavior be restricted during an adaptation, and what are the restrictions, if any? An adaptation specification should precisely address all of the above questions. Based on results presented in the literature and our own experience, we summarize three commonly used semantics for adaptation. By formally specifying these semantics, we are able to precisely answer the above questions.

We assume the source program and the target program have both been specified in LTL, named base specifications. We specify the adaptation from the source program to the target program with A-LTL by extending the base specifications of the source and the target programs. For some adaptations, the source/target program behavior may need to be constrained during the adaptation. These constraints, termed restriction conditions, are specified in LTL. We assume the adaptive program has moderate computational reflection (32) capability, i.e., it is conscious about its adaptation and the currently running steady-state program. This capability can be achieved by simply introducing flag propositions in the program to identify its current steady-state program or adaptation status. We assume that a decision-making procedure that translates environment changes into specific adaptation requests is available. Our specification technique describes the expected program behavior in response to these requests. We use an atomic proposition AREQ to indicate the receipt of an adaptation request to a target program from the decision making procedure. In this section, we summarize three commonly occurring basic adaptation semantics interpretations from the literature (12; 11; 6; 8) specified in terms of A-LTL. There are potentially many other possible adaptation semantics. In all three adaptation specification semantics, we denote the source and the target program base specifications as S SPEC and T SPEC , respectively. If applicable, the restriction condition during adaptation is RCOND . We assume the flag propositions are already parts of the specifications. We use the term safe states to indicate the states where all the obligations of the source program are fulfilled, thus making it safe to terminate the source behavior.

2.2.1 One-point adaptation. Under one-point adaptation semantics, after receiving an adaptation request AREQ , the program adapts to the target program T SPEC at a certain point during its execution. The prerequisite for one-point adaptation is that the source program S SPEC should always eventually reach a safe state during its execution. Ω

(S SPEC ∧♦AREQ )*T SPEC

(1)

The formula states that the program initially satisfies S SPEC . After receiving an adaptation request, AREQ , it waits until the program reaches a safe state, i.e., all obligations generated by S SPEC are satisfied. Then the program stops being obligated to satisfy S SPEC and starts to satisfy T SPEC . This semantics is

visually presented in Figure 1(a), where circles represent a sequence of states. Solid lines represent state intervals and the label of each solid line represents the property that is held by the interval. The arrow points to the states when an adaptation request is received. This semantics is straightforward and is explicitly or implicitly applied by many approaches (e.g., (12; 11; 6)) to deal with simple cases that do not require restraining the source behavior or overlapping the source and the target behavior.

2.2.2 Guided adaptation. Under guided adaptation semantics (visually depicted in Figure 1(b)), after receiving an adaptation request, the program first restrains its source program behavior by a restriction condition,RCOND , and then adapts to the target program when it reaches a safe state. This semantics is suitable for adaptations whose source programs do not guarantee reaching a safe state within a given amount of time. The restriction condition should ensure that the source program will finally reach a safe state.
Ω2 Ω1 S SPEC ∧(♦AREQ *R COND ) *T SPEC

(2)

This formula states that initially S SPEC is satisfied. After an adaptation request, AREQ , is received, the program should satisfy a restriction condition Ω1 When the program reaches a safe state of the source, RCOND (marked with *). the program stops being constrained by S SPEC , and starts to satisfy T SPEC Ω2 The hot-swapping technique introduced by Appavoo et (marked with *). al (12) and the safe adaptation protocol (6) introduced in our previous work use the guided adaptation semantics.

2.2.3 Overlap adaptation. Under overlap adaptation semantics (visually depicted in Figure 1(c)), the target program behavior starts before the source program behavior stops. During the overlap of the source and the target behavior, a restriction condition is applied to safeguard the correct behavior of the program. This adaptation semantics is appropriate for the case when continuous service from the adaptive program is required. The restriction condition should ensure that the source program reaches a safe state.



 

Ω2 Ω2 Ω1 Ω1 *true) * T ∧(R ) *true ∧ ♦A S SPEC ∧(♦AREQ *R SPEC COND COND REQ

(3)

This formula states that initially S SPEC is satisfied. After an adaptation request, AREQ , is received, the program should start to satisfy T SPEC and also Ω1 satisfy a restriction condition, RCOND (marked with *). When the program reaches a safe state of the source program, the program stops being obliged Ω2 by S SPEC and RCOND (marked with *). The graceful adaptation protocol introduced by Chen et al (11) and the distributed reset protocol introduced by Kulkarni et al (8) use the overlap adaptation semantics. TSPEC

S SPEC

AREQ

RCOND S SPEC

TSPEC

AREQ

RCOND S SPEC

TSPEC

AREQ

Fig. 1. Adaptation semantics

2.2.4 Safety and Liveness Properties. Temporal logics are often applied to the specifications of safety and liveness properties of a program. A safety property asserts something bad never happens, while a liveness property asserts something good will eventually happen (33). Although general forms of safety and liveness properties are not preserved by the adaptation semantics defined above, some common forms of safety and liveness properties are preserved. We define a formula  to be a point safety property if and only if  = 2¬η (read as η never holds during execution), where η is a point formula (a formula that does not contain temporal operators). We define a formula  to be point

liveness property if and only if  = 2(α→♦β) (read as it is always the case that if α holds at some point, then β will eventually hold at a point after that point), where both α and β are point formulae. LEMMA 1: All three adaptation semantics preserve point safety properties. That is, if (S SPEC ∨T SPEC ) → 2¬η , where η is a point property, then ξ → 2¬η , where ξ is the adaptation specification based on either semantics. We only provide the proof for the one-point adaptation case. Other cases can be proved similarly. Proof Let the adaptation specification ξ be (Formula 1) Ω

ξ = (S SPEC ∧♦AREQ )*T SPEC

For an arbitrary sequence σ |= ξ , ∃ σ 0 |= S SPEC ∧♦AREQ and σ 00 |= T SPEC , and σ = σ 0 _ σ 00 . Since (S SPEC ∨T SPEC ) → 2¬η , σ 0 |= 2¬η , and σ 00 |= 2¬η . Therefore, σ |= 2¬η .  This lemma implies that if a propositional invariant (such as a variable is never greater than a given value) should be held in both the source and the target subprograms, then the invariant is also held by a simple adaptive program under all three adaptation semantics. This conclusion does not apply to general temporal properties. LEMMA 2: Point liveness properties are preserved by all three adaptation semantics. That is, if (S SPEC ∨T SPEC ) → 2(α → ♦β), then ξ → 2(α → ♦β), where ξ is the adaptation specification based on either semantics. Also, we only provide the proof for the one-point adaptation case. Other cases can be proved similarly. Proof: Let the adaptation specification ξ be (Formula 1) Ω

ξ = (S SPEC ∧♦AREQ )*T SPEC

For an arbitrary sequence s0 , s1 , · · · |= ξ , ∃ i, such that s0 , s1 , · · · si |= S SPEC ∧♦AREQ and si+1 , si+2 , · · · |= T SPEC . Since (S SPEC ∨T SPEC ) → 2(α → ♦β), we have s0 , s1 , · · · si |= 2(α → ♦β), and si+1 , si+2 , · · · |= 2(α → ♦β). For an arbitrary state sj , if sj |= α, then we have • if j ≤ i , then there exists k (j < k ≤ i ) such that sk |= β; • if j > i , then there exists k (j < k ) such that sk |= β.

That is, s0 , s1 , · · · |= 2(α → ♦β) Therefore, we have ξ → 2(α → ♦β). 

3

Specification Compositions

Thus far, we have described how to specify simple adaptive programs. These specifications can be composed to describe multiple adaptation options from a single steady-state program. We can also link a sequence of adaptation specifications together to describe the behavior of executions with multiple adaptation occurrences. 3.1 Neighborhood Composition A simple adaptive program starts from one program and may adapt to only one target program. A more complex adaptive program may adapt to different target programs in response to different adaptation requests. The neighborhood composition is proposed to specify multiple adaptation options from a single program. We define the neighborhood adaptive program of a program S to be the composition of all the simple adaptive programs that share the same source program S . An execution starting from S can either adapt to a target program if a corresponding adaptation request is received, or remain in S if no adaptation request is received. Assume for all target programs, the properties of the simple adaptive program from S to the i th target program Ti is specified with an A-LTL formula STi SPEC , and the properties of S are specified with S SPEC . We can construct the specification for the neighborhood of S by the disjunction of S SPEC and STi SPEC . Let N SPEC be the neighborhood specification of S , we have

N SPEC =

k _

STi SPEC ∨ S SPEC

(4)

i=1

where k is the number of simple adaptive programs sharing the same source program S . 3.2 Sequential Composition A complex adaptive program may sequentially perform adaptations more than once during a single execution. For example, an adaptive program may start

from a program A, then sequentially perform adaptations from A to B to obtain program B , and B to C to obtain program C . Assume the properties of A, B , and C are specified with ASPEC , B SPEC , and C SPEC , respectively. The A to B adaptation specification under a given adaptation semantics is a function of ASPEC and B SPEC : AB SPEC = ADAPT 1(ASPEC , B SPEC ). The B to C adaptation specification under a given adaptation semantics is a function of B SPEC and C SPEC : BC SPEC = ADAPT 2(B SPEC , C SPEC ). The specification of A to B to C may be constructed by substituting AB SPEC for the B SPEC in BC SPEC .

ABC SPEC = ADAPT 2(ADAPT 1(ASPEC , B SPEC ), C SPEC )

(5)

Similarly, a finite number of simple adaptive program specifications can be sequentially composed to construct the specification of more complex adaptive programs. THEOREM: Both point safety and point liveness properties are preserved by the adaptation semantics and the two types of compositions. Proof outline: This theorem can be proved by applying Lemma 1 and Lemma 2. • For neighborhood compositions, from the lemmas, we know that if all base specifications imply a point safety (liveness) property φ, then all the disjuncts imply φ as well. Then the disjunction (the neighborhood composition) also implies φ. • For sequential composition, we can prove the conclusion inductively. (1) The base case states 0-step sequential composition preserves point safety and liveness properties. This has been proved by Lemma 1 and Lemma 2. (2) Then we assume any n-step sequential composition preserves point safety and liveness properties. An n+1 -step sequential composition can be considered as an n-step sequential composition composed with a base specification. Then we can apply Lemma 1 and Lemma 2 to the n-step adaptation composition case and claim that all n+1 -step sequential compositions also preserve point safety and liveness properties. 

3.3 Adaptation Invariants

In spite of adaptations of a program, some properties should be held true throughout its execution. This type of properties, such as safety and liveness properties, are adaptation invariants. We use LTL formulae to specify adaptation invariants of the program to ensure the properties that should be held throughout the execution of an adaptive program.

3.4 Adaptation Specification Visualization and Automatic Generation

An adaptive program can be visually represented as a graph, where programs are vertices and adaptations are arcs. We add temporal logic information to the graph so that we are able to derive the adaptation temporal logic specification automatically from the graph. We define an adaptation semantics graph to be a tuple (S , S0 , A, P , Φ, Ψ, INV ), where S is a set of vertices representing the set of programs in an adaptive program. S0 ⊆ S is a set of initial vertices, representing the initial programs of the adaptive program. Function Φ : S → LTL maps each program to the base specification for the program. A ⊆ S × S is a set of arcs representing adaptations. Function P : A → semantics name maps an adaptation to one of the semantics names {one-point , guided, overlap}. Ψ:A→ 7 LTL is a partial function that maps guided or overlap adaptation to their associated restriction conditions. INV is the set of adaptation invariants. The adaptation specifications can be derived from the adaptation semantics graph. We have implemented a prototype, ASpecGen, which uses simple edge traversal to automate this process. The complexity of the algorithm is linear to the number of adaptations.

4

Case Study

In this section we use MetaSockets (24) as an illustrative example to demonstrate our adaptation specification approach. MetaSockets are constructed from the regular Java Socket and MulticastSocket classes; however, their internal structure and behavior can be modified at run time in response to external conditions. MetaSocket behavior can be adapted through the insertion and removal of filters that manipulate the data stream. For example, filters can perform encryption, decryption, forward error correction, compression, and so forth.

We consider a sender’s MetaSocket with three different filters: a data compression filter (COM), a DES 64-bit encryption filter (DES64), and a DES 128-bit encryption filter (DES128). The available adaptations are data compression filter insertion and removal, and DES filter replacement. Note that to enforce security, the DES filters can only be replaced by other DES filters, but cannot be removed. These filters can be combined in four different configurations: DES64, DES128, DES64 with COM (DES64COM), and DES128 with COM (DES128COM). We consider the MetaSocket under each configuration a program. The adaptive program is initially running in the DES64 program. 4.1 MetaSocket Specifications The specifications of the programs are described as follows: • DES64 program:

DES64 SPEC = (2 DES64 FL )∧2(DES 64Input(x ) → ♦DES 64Output(x ))

The DES 64Input (DES 64Output) are events indicating the input (output) of a packet to (from) the MetaSocket under DES64 configuration. 1 The flag proposition DES64 FL indicates that the program is running under the DES64 configuration. The formula states that under this configuration, for every input packet to be encoded by the DES64 filter, the MetaSocket should eventually output a DES64 encoded packet. The following program aspects can be interpreted in a similar way. • DES128 program:

DES128 SPEC = (2 DES128 FL )∧(2(DES 128Input(x ) → ♦DES 128Output(x )))

• DES64COM program:

DES64COM SPEC = (2 DES64COM FL )∧(2(DES 64COMInput(x ) → ♦DES 64COMOutput(x ))) 1

Strictly speaking, the notation of DES64Input(x) is a predicate. However, LTL requires the underlying logic to be propositional. Here we implicitly employ the 2-order data abstraction introduced by Dwyer and Pasareanu (34), which converts predicates to propositions by using constant values to represent arbitrary values.

• DES128COM program:

DES128COM SPEC = (2 DES128COM FL )∧(2(DES 128COMInput(x ) → ♦DES 128COMOutput(x )))

To determine the semantics of each adaptation, we consider the following factors: (1) The MetaSocket component is designed for the transmission of real-time video and audio data. Therefore, we should minimize data blocking. (2) We should not allow both the source and the target programs to input simultaneously because that will cause ambiguity in the input. (3) We should not allow the target program to output data before any output is produced from the source program, otherwise, it will complicate the logic on the receiver. Based on the above considerations, it is appropriate to apply the overlap semantics with conditions prohibiting the types of overlap discussed above. The adaptation semantics graph is visually presented in Figure 2.

overlap

overlap

overlap

DES128

overlap overlap

overlap

DES64

overlap DES64COM

overlap

DES128COM

Fig. 2. Visual representation of MetaSocket adaptation semantics graph

We use the DES64 to DES128 adaptation as an example to demonstrate the simple adaptive program specification construction. In order to use overlap semantics, we have to define restriction conditions to prevent overlap of the source and target programs input and the overlap of the source and target programs output. Therefore, we define the restriction conditions to be RCOND (DES64-DES128 ) = 2(¬DES 64Input(x )∧¬DES 128Output(x )).

(6)

The intuition for this restriction condition is that it should not accept any more DES64 inputs and will not produce any DES128 outputs until all DES64 outputs have been produced. Given the source and target program specifications, the overlap semantics, and the restriction condition, we apply Formula 3 to

derive the following specification:

DES64-DES128 SPEC = (7)   
true true DES64 SPEC ∧ ♦AREQ (DES 128) * RCOND (DES64-DES128 ) * true ∧ 
 true true AREQ (DES 128) * DES128 SPEC ∧(RCOND (DES64-DES128 ) * true)

Formula (7) states that after the program receives an adaptation request to the DES128 program (AREQ (DES 128)), it should adapt to the DES128 program. Furthermore, the behavior of DES64 and DES128 may overlap, and during the overlapping period, the program should satisfy the restriction condition RCOND (DES64-DES128 ). In this example, the Ω notation of the adaptation operators are not used. We simply assign true to Ω in the four adapt operator locations. With the same approach, we specify other simple adaptive programs in the adaptive program. Further, both the source and the target specifications are point liveness properties. We can unify them with the following formula by disregarding the type of inputs and outputs.

2(Input(x ) → ♦Output(x ))

(8)

According to Lemma 2, we can conclude that the adaptation also satisfies the point liveness property. In addition to the specification for adaptation behavior, the program should also satisfy a set of adaptation invariants to maintain its integrity. • Security invariant: At any time during execution, insecure output should not be produced, i.e., all output packets should be encoded by a DES filter: INV 1 = 2¬insecureOutput(x ) • QoS invariant: During program execution, the sender MetaSocket should not cause any loss of packets, i.e., all input packets should be output: INV 2 = 2(Input(x ) → ♦Output(x )) Note, this invariant is already guaranteed by the point liveness preservation property of the adaptation semantics. (Formula 8.)

• Precedence invariant: The MetaSocket should not output a packet before the corresponding input has been received:

INV 3 = 2(¬Output(x ) U Input(x ))

5

Discussion and Conclusions

Adaptation semantics should be precisely specified at the requirements level so that they can be well understood and correctly implemented in later phases of the software development process. This paper introduced a compositional approach to the specification of adaptive programs specified in terms of ALTL. After an adaptation temporal specification is generated, it may serve as guidance for the adaptation developers to clarify the intent for the adaptive program. It also enables us to check for consistency in the temporal logic specifications. By using run-time verification techniques, we may also automatically identify the safe states for an adaptation and insert adaptation logic at appropriate points in the program. If a program model is available, then we may even perform model checking to verify the correctness of the program model against the temporal logic specifications. Our technique is intended to be applied to specify adaptation behavior of autonomic computing systems to achieve self-healing, self-protecting, selfmanaging, etc (35; 36; 37). Autonomic computing usually comprises four major modules (6; 7): Enabling adaptation makes a program adapt-ready, i.e., capable of run-time reconfiguration. Program monitoring instruments the program and monitors condition changes in the execution environment. Decisionmaking maps detected environment changes to adaptation requests, and determines when and how the program should be modified. Process management manages the adaptation steps to ensure critical properties. Although environment changes such as failures are unexpected after the decision making module has translated the changes into adaptation requests, the program behavior in response to the requests is generally deterministic. Our technique can be applied to describe the expected program behavior of adaptive programs in response to these adaptation requests. We chose to use the A-LTL to specify adaptation semantics due to two major considerations: effectiveness and simplicity. A-LTL formulae are generally not expressible in LTL. Even for those expressions for which we can find equivalent LTL formulae, we find A-LTL formulae to be more intuitive to understand. Some other logics, including the choppy logic (25), the propositional interval

temporal logic (PITL) (26; 27; 28; 29; 30), and the interval temporal logic (ITL) (31), are also sufficient to specify adaptation behavior. However, they are generally too complex, and therefore suffer from non-elementary complexity in their decision procedure (25; 26; 27; 28). We find the A-LTL to be simple and sufficiently effective to specify adaptation behavior, given that the logic was designed to support adaptation explicitly. We have developed an A-LTL model checking algorithm under the assumption that the formulae on the two sides of an adapt operator are distinguished by a proposition. This assumption is ensured by the flag propositions in our specification technique. Our procedure is a variant of the automata-theoretic model checking algorithm introduced by Vardi et al (38; 39; 40) and Bowman and Thompson (27; 28). The model checking algorithm has complexity exponential to the length of the formula and linear to the size of the program. Note that LTL model checking is in the same complexity class, and A-LTL is a superset of LTL. Therefore, it is unlikely for us to find a polynomial model checking algorithm. We are currently investigating optimization techniques, such as on-the-fly model checking proposed by Gerth et al (38). Our future work includes automatically generating program models and code based on a given adaptation semantics, as well as developing efficient model checking tools to verify the correctness of adaptive programs.

References [1] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, B. H. C. Cheng, Composing adaptive software, IEEE Computer 37 (7) (2004) 56–64. [2] S. Kulkarni, K. Biyani, Correctness of component-based adaptation, in: Proceedings of International Symposium on Component-based Software Engineering, 2004. [3] R. Milner, J. Parrow, D. Walker, A calculus of mobile processes, I, Information and Computation 100 (1) (1992) 1–40. [4] J. Kramer, J. Magee, M. Sloman, Configuring distributed systems, in: Proceedings of the 5th workshop on ACM SIGOPS European workshop, ACM Press, 1992, pp. 1–5. [5] C. E. Cuesta, P. de la Fuente, M. Barrio-Sol´arzano, Dynamic coordination architecture through the use of reflection, in: Proceedings of the 2001 ACM symposium on Applied computing, ACM Press, 2001, pp. 134–140. [6] J. Zhang, Z. Yang, B. H. Cheng, P. K. McKinley, Adding safeness to dynamic adaptation techniques, in: Proceedings of ICSE 2004 Workshop on Architecting Dependable Systems, Edinburgh, Scotland, UK, 2004. [7] J. Zhang, B. H. Cheng, Z. Yang, P. K. McKinley, Enabling safe dynamic component-based software adaptation, Architecting Dependable Systems, Lecture Notes in Computer Science, Spring-Verlag, 2005.

[8] S. S. Kulkarni, K. N. Biyani, U. Arumugam, Composing distributed faulttolerance components, in: Proccedings of the International Conference on Dependable Systems and Networks (DSN), Supplemental Volume, Workshop on Principles of Dependable Systems, 2003, pp. W127–W136. [9] J. Kramer, J. Magee, The evolving philosophers problem: Dynamic change management, IEEE Trans. Softw. Eng. 16 (11) (1990) 1293–1306. [10] P. Oreizy, N. Medvidovic, R. N. Taylor, Architecture-based runtime software evolution, in: Proceedings of the 20th international conference on Software engineering, IEEE Computer Society, 1998, pp. 177–186. [11] W.-K. Chen, M. A. Hiltunen, R. D. Schlichting, Constructing adaptive software in distributed systems, in: Proc. of the 21st International Conference on Distributed Computing Systems, Mesa, AZ, 2001. [12] J. Appavoo, K. Hui, C. A. N. Soules, et al., Enabling autonomic behavior in systems software with hot swapping, IBM System Journal 42 (1) (2003) 60. [13] N. Amano, T. Watanabe, A software model for flexible and safe adaptation of mobile code programs, in: Proceedings of the international workshop on Principles of software evolution, ACM Press, 2002, pp. 57–61. [14] D. M. Berry, B. H. Cheng, J. Zhang, The four levels of requirements engineering for and in dynamic adaptive systems, in: Proc. of 11th International Workshop on Requirements Engineering: Foundation for Software Quality, Porto, Portugal, 2005. [15] J. Bradbury, J. Cordy, J. Dingel, M. Wermelinger, A survey of self management in dynamic software architecture specifications, in: Proc. of the ACM SIGSOFT International Workshop on Self-Managed Systems (WOSS’04), Newport Beach, California, 2004, pp. 28–33. [16] D. L. M´etayer, Software architecture styles as graph grammars, in: Proceedings of the 4th ACM SIGSOFT symposium on Foundations of software engineering, ACM Press, 1996, pp. 15–23. [17] G. Taentzer, M. Goedicke, T. Meyer, Dynamic change management by distributed graph transformation: Towards configurable distributed systems, in: Selected papers from the 6th International Workshop on Theory and Application of Graph Transformations, Springer-Verlag, 2000, pp. 179–193. [18] D. Hirsch, P. Inverardi, U. Montanari, Graph grammars and constraint solving for software architecture styles, in: Proceedings of the third international workshop on Software architecture, ACM Press, 1998, pp. 69–72. [19] R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. Whitehead, Jr., J. E. Robbins, A component- and message-based architectural style for GUI software, in: Proceedings of the 17th international conference on Software engineering, ACM Press, 1995, pp. 295–304. [20] R. Allen, R. Douence, D. Garlan, Specifying and analyzing dynamic software architectures, in: Proceedings of the 1998 Conference on Fundamental Approaches to Software Engineering (FASE’98), Lisbon, Portugal, 1998.

[21] J. Kramer, J. Magee, Analysing dynamic change in software architectures: a case study, in: Proc. of 4th IEEE international conference on configuratble distributed systems, Annapolis, 1998. [22] C. Canal, E. Pimentel, J. M. Troya, Specification and refinement of dynamic software architectures, in: Proceedings of the TC2 First Working IFIP Conference on Software Architecture (WICSA1), Kluwer, B.V., 1999, pp. 107–126. [23] A. Pnueli, The temporal logic of programs, in: Proceedings of the 18th IEEE Symposium on Foundations of Computer Science, 1977, pp. 46–57. [24] S. M. Sadjadi, P. K. McKinley, E. P. Kasten, Architecture and operation of an adaptable communication substrate, in: Proceedings of the Ninth IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS’03), San Juan, Puerto Rico, 2003, pp. 46–55. URL ftp://ftp.cse.msu.edu/pub/crg/PAPERS/ftdcs-03.pdf [25] R. Rosner, A. Pnueli, A choppy logic, in: 1st IEEE Symposium on Logic in Computer Science, 1986, pp. 306–313. [26] R. Gomez, H. Bowman, PITL2MONA: Implementing a decision procedure for propositional interval temporal logic, Journal of Applied NonClassical Logics 14 (1-2) (2004) 105–148. URL http://www.cs.kent.ac.uk/pubs/2004/1891 [27] H. Bowman, S. Thompson, A tableau method for Interval Temporal Logic, Technical Report 12-97, Computing Laboratory, University of Kent (November 1997). URL http://www.cs.ukc.ac.uk/pubs/1997/461 [28] H. Bowman, S. J. Thompson, A tableaux method for Interval Temporal Logic with projection, in: TABLEAUX’98, International Conference on Analytic Tableaux and Related Methods, no. 1397 in Lecture Notes in AI, Springer-Verlag, 1998, pp. 108–123. URL http://www.cs.ukc.ac.uk/pubs/1998/528 [29] B. Moszkowski, A hierarchical completeness proof for Propositional Interval Temporal Logic with finite time, Journal of Applied Non-Classical Logics 14 (1–2) (2004) 55–104, special issue on Interval Temporal Logics and Duration Calculi. [30] B. Moszkowski, A hierarchical analysis of propositional temporal logic based on intervals, in: S. Artemov, H. Barringer, A. S. d’Avila Garcez, L. C. Lamb, J. Woods (Eds.), We Will Show Them: Essays in Honour of Dov Gabbay, Vol. 2, College Publications, 2005, pp. 371–440. [31] A. Cau, B. Moszkowski, H. Zedan, Interval temporal logic, Internet (Sep 2002). URL http://www.cse.dmu.ac.uk/ cau/itlhomepage/ [32] P. Maes, Concepts and experiments in computational reflection, in: Conference proceedings on Object-oriented programming systems, languages and applications, ACM Press, 1987, pp. 147–155. [33] A. P. Sistla, On characterization of safety and liveness properties in temporal logic, in: PODC ’85: Proceedings of the Fourth Annual ACM Sym-

[34]

[35] [36] [37]

[38]

[39]

[40]

posium on Principles of Distributed Computing, ACM Press, 1985, pp. 39–48. M. B. Dwyer, C. S. Pasareanu, Filter-based model checking of partial systems, in: SIGSOFT ’98/FSE-6: Proceedings of the 6th ACM SIGSOFT International Symposium on Foundations of Software Engineering, ACM Press, 1998, pp. 189–202. A. G. Ganek, T. A. Corbi, The dawning of the autonomic computing era, IBM System Journal 42 (1) (2003) 5. D. M. Chess, C. Palmer, S. R. White, Security in an autonomic computing environment, IBM System Journal 42 (1) (2003) 107–118. E. M. Dashofy, A. van der Hoek, R. N. Taylor, Towards architecture-based self-healing systems, in: Proceedings of the first workshop on Self-healing systems, ACM Press, 2002, pp. 21–26. R. Gerth, D. Peled, M. Vardi, P. Wolper, Simple on-the-fly automatic verification of linear temporal logic, in: Proceedings of the Fifteenth IFIP WG6.1 International Symposium on Protocol Specification, Testing and Verification (PSTV95), Warsaw, Poland, 1995. M.Y.Vardi, P. Wolper, An automata-theoretic approach to automatic program verification, in: Proceedings of the 1st Symposium on Logic in Computer Science, Cambridge, England, 1986, pp. 322–331. M. Y. Vardi, P. Wolper, Reasoning about infinite computations, Inf. Comput. 115 (1) (1994) 1–37.