Specifying Adaptation Semantics - Semantic Scholar

7 downloads 340606 Views 180KB Size Report
May 17, 2005 - ing the adaptive software development process. Furthermore, the ... show that during and after an adaptation, the adaptive system is always in ...
Specifying Adaptation 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 {zhangji9,

chengb}@cse.msu.edu

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. Neighborhood composition and sequential composition techniques are developed and applied to A-LTL to construct the specification of an adaptive system. We introduce adaptation semantics graphs to visually present the adaptation semantics. Specifications for adaptive systems can be automatically generated from adaptation semantics graphs.

Categories and Subject Descriptors

F.3.1 [LOGICS AND MEANINGS OF PROGRAMS]: Specifying and Verifying and Reasoning about Programs—Logics of programs, Specification techniques; D.2.1 [SOFTWARE ENGINEERING]: Requirements/Specifications—Languages

General Terms Theory

∗Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WADS’05, May 17, 2005, St. Louis, MO, USA. Copyright 2005 ACM 1-59593-124-4/05/0005...$5.00. †This work has been supported in part by NSF grants EIA0000433, EIA-0130724, ITR-0313142, and CCR-9901017, and the Department of the Navy, Office of Naval Research under Grant No. N00014-01-1-0744.

Keywords

temporal logic, adaptive software, autonomic computing

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 systems 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 systems cannot be properly addressed without precisely specifying the requirements for the adaptive systems. 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 system. Numerous techniques have been proposed to address the correctness of adaptations. Kulkarni et al. [2] introduced a transitionalinvariant lattice approach that uses theorem proving techniques to show that during and after an adaptation, the adaptive system is always in correct states with respect to satisfying the transitionalinvariants. Some approaches [3–5] use formal languages to describe the structural changes of the software at the design and implementation levels. Other approaches [6–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. [10] introduced a hot-swapping 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. [9] 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 overlooked. We believe that the semantics for adaptive software should be explicitly captured at the requirements level. The correctness of adaptive software can then be evaluated with respect to its adaptation requirements specification. This paper focuses on the specification of requirements of adaptations. We model an adaptive system as

the composition of a finite number of systems and the adaptations among these system. We assume that the properties of each system have already been specified with a Linear Temporal Logic (LTL) formula [14]. To specify an adaptation from one system to another, we introduce the Adapt operator-extended LTL (A-LTL), an extension to LTL. We introduce three commonly used adaptation semantics and use A-LTL to formally specify their semantics. We then compose the specifications of each system and each adaptation with two types of compositional procedures: neighborhood compositions and sequential compositions. We introduce adaptation semantics graphs, a graph-based representation of adaptive systems semantics, which can be automatically processed to generate adaptive system specifications. The formal specifications for adaptive systems precisely describe the objectives for adaptive systems, 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 system. The temporal specifications also enable us to perform numerous automated analyses of the adaptive system, 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 prototype adaptive systems, including MetaSockets [15]. The remainder of this paper is organized as follows. In Section 2, we introduce A-LTL and describe three commonly used 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

We model an adaptive system with a state machine. An adaptive system changes its behavior during its execution. The state space describing each different kind of behavior is a non-adaptive system, or briefly a system. The state space describing the change of behavior from one system (source system) to another (target system) is a simple adaptive system, which can be identified by the source and target system pair.

2.1 Adapt Operator-Extended LTL

LTL is a temporal extension to propositional logic [14]. 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), ↔ (coimply), ♦ (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 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 the suffixes of σ starting from all the states before a certain state. However, adaptation semantics usually only require φ to hold for a given interval of σ. To specify adaptation behavior, we adopt the chop operator (“;”) [16].

Informally, a system satisfies “φ;ψ” means that the system initially satisfies φ, and at a certain state, it stops satisfying φ and starts to satisfy ψ, where φ and ψ are two temporal logic formulae. We define A-LTL as follows: (1) Any LTL formula is an A-LTL formula. (2) If φ and ψ are two A-LTL formulae, then φ;ψ, φ∧ψ, φ→ψ, ¬φ, φ, and φ U ψ are A-LTL formulae. We use σ |=c φ to denote that a state sequence σ satisfies an A-LTL formula φ. We define the A-LTL semantics as follows. • If σ is an infinite state sequence and φ does not include a chop operator, then σ |=c φ iff σ |= φ. • σ |=c φ;ψ iff there exists a sequence σ 00 and a finite state sequence σ 0 s.t. σ = σ 0 ◦ σ 00 , σ 0 |=c φ, and σ 00 |=c ψ, where “◦” represents a sequence fusion operation [16]. 1 • Other operators (∧, →, ∨, , and U ) are defined similarly as those used in LTL. BP

We define an additional adapt operator: φ*ψ, (read as φ adapts to ψ with V base atomic propositions BP), as an abbreviation for φ; ψ∧ {α ∈ BP•α↔ α}, where BP is a set of atomic propositions. This formula states that if a state sequence s1 , s2 , · · · , sk , BP sk+1 , sk+2 , · · · satisfies φ*ψ, then there exists (k ≥ 1), such that s1 , s2 , · · · , sk |=c φ and sk+1 , sk+2 , · · · |=c ψ, and sk and sk+1 agree on all atomic propositions in BP, i.e., if an atomic proposition α ∈ BP is true in sk , then it is true in sk+1 , and vice-versa. The adapt operator will be extensively used in our adaptation specifications. We separate the behavior of an adaptive system into adaptation invariants, the part of behavior that holds consistently during an execution of the system, and adaptation variants, the part of behavior that changes during the system’s execution. We first introduce three adaptation semantics specifications in A-LTL. These semantics are used to specify the adaptation variants of simple adaptive systems. Then we introduce composition techniques to handle general adaptive systems. Finally, we compose adaptation invariants with adaptation variants to specify the complete adaptive system behavior.

2.2 Semantics for Adaptation Variants

Several questions have to be answered before designing an adaptive system: (1) What is the expected behavior after adaptation? (2) Are there any constraints upon when the adaptation may occur, and what are the constraints? (3) Are the source system behavior and the target system behavior allowed to overlap? (4) Should the source/target system behavior be restricted during an adaptation, and what are the restrictions? An adaptation specification should precisely answer 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 system and the target system have been both specified in LTL, named base specifications. We specify the adaptation from the source system to the target system with A-LTL by extending the base specifications of the source and the target systems. For some adaptations, the source/target system behavior may 1 0 σ ◦ σ 00 = s1 , · · · sk , sk+1 , · · · where σ 0 = s1 , · · · sk , and σ 00 = sk , · · ·

need to be constrained during the adaptation. We use an LTL formula to specify the restriction condition as well. We use the term base atomic propositions (denoted as Ω) to refer to the set of atomic propositions used by base specifications and restriction conditions. We define a meta atomic proposition to be an atomic proposition other than base atomic propositions. We assume that the program is aware of adaptations, i.e., it knows when an adaptation starts and when it completes. We associate a meta atomic proposition, flag proposition, with each base specification formula or restriction condition formula to indicate the interval of states in which the system exhibits the behavior specified by the formula. When the system starts (stops) satisfying a base specification (or a restriction condition), the corresponding flag proposition should change from false (true) to true (false). To simplify the specifications, we define the EXclusive-True function ExT , to be applied to a set of flag propositions. Informally, ExT(α) is true if and only if all flag propositions in α are true, and all flag propositions not in α are false. We use another meta atomic proposition AREQ to indicate the receipt of an adaptation request to a target system. In this section, we introduce three commonly occurring adaptation semantics interpretations 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 system base specifications as SSPEC and TSPEC , respectively. If applicable, the restriction condition during adaptation is RCOND . The flag propositions for the two systems are SFL and TFL , respectively. The flag proposition for the restriction condition is RFL , if applicable. We use the term safe states to indicate the states where all the obligations of the source system are fulfilled, and thus it is safe to terminate the source behavior.

2.2.1 One-point adaptation

Under one-point adaptation semantics, after receiving an adaptation request, the system adapts to the target system at certain points during its execution. The prerequisite is that the source system should always eventually reach a safe state during its execution.



2ExT({SFL })∧SSPEC ∧♦AREQ *2ExT({TFL })∧TSPEC

(1)

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. The formula states that the system initially satisfies SSPEC . When the system reaches a safe state, i.e., all obligations generated by SSPEC are satisfied, indicated by SFL becoming false and TFL becoming true, the system stops satisfying SSPEC and starts to satisfy TSPEC .

2.2.2 Guided adaptation

Under guided adaptation semantics (visually depicted in Figure 1(b)), after receiving an adaptation request, the system first restrains its source system behavior by a restriction condition, and then adapts to the target system when it reaches a safe state. This semantics is suitable for adaptations whose source systems do not guarantee reaching a safe state within a given amount of time. The restriction condition should ensure that the source system will reach a safe state.



(SSPEC ∧(2ExT({SFL })∧♦AREQ *2ExT({RFL })∧RCOND )

(2)



*2ExT({TFL })∧TSPEC

This formula states that initially SSPEC is satisfied. After an adaptation request, AREQ is received, the system should satisfy a restriction condition, RCOND . When the system reaches a safe state of the source, indicated by TFL becoming true, the system stops satisfying the SSPEC , indicated by RFL becoming false, and starts to satisfy TSPEC . The hot-swapping [10] introduced in K42 uses the guided adaptation semantics.

2.2.3 Overlap adaptation

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



(SSPEC ∧(2ExT({SFL })∧♦AREQ *ExT({SFL , TFL })∧RCOND ) Ω

(3)



*ExT({TFL }))∧2ExT({SFL })*ExT({TFL })∧TSPEC

This formula states that initially SSPEC is satisfied. After an adaptation request, AREQ , is received, the system should start to satisfy TSPEC and also satisfy a restriction condition, RCOND . When the system reaches a safe state of the source system, indicated by SFL becoming false, the system stops satisfying SSPEC and RCOND . The graceful adaptation protocol [9] introduced in Cactus uses the overlap adaptation semantics.

3. SPECIFICATION COMPOSITIONS

Thus far, we have described how to specify each simple adaptive system. In this section, we introduce how we compose the simple adaptive system specifications to construct the adaptation variants of an overall adaptive system.

3.1 Neighborhood Composition

A simple adaptive system starts from one system and may adapt to only one target system. A more complex adaptive system may adapt to different target systems in response to different adaptation requests. We define the neighborhood adaptive system (or briefly neighborhood) of a system S to be the composition of all the simple adaptive systems that share the same source system S. The neighborhood of S can either adapt to a target system if a corresponding adaptation request is received, or remain in S if no adaptation request is received. Assume for all target systems, the properties of the simple adaptive system from S to the i th target system Ti is specified with an A-LTL formula SPEC STi , and the properties of S is specified with SPEC S . We can construct the specification for the neighborhood of S (or briefly the neighborhood specification of S), by the disjunction of SPEC S and SPECSTi . Let SPECNS be the neighborhood specification of S, we have

S FL ∧ S SPEC

TFL ∧ TSPEC

tial composition also handles circular adaptations, where the initial and the final systems are the same system.

AREQ

3.3 General Adaptive System Composition

A general adaptive system (or briefly adaptive system) should be able to operate under a number of different conditions, and therefore, it contains a number of different systems and adaptations. Before specifying an adaptive system, we should first analyze the different conditions and the different types of behavior. Then for each different behavior, we should identify all the possible adaptations from the behavior. We use an LTL formula to specify the properties of the system corresponding to each different behavior, and use an A-LTL formula to specify each different adaptation according to the desired adaptation semantics. Then we apply neighborhood composition to construct the A-LTL formula of the neighborhood specification for each system. Finally, we sequentially compose these neighborhood specifications to construct the specification of the adaptive system.

RFL ∧ RCOND

S FL ∧ S SPEC

TFL ∧ TSPEC

AREQ

RCOND S FL ∧ S SPEC

TFL ∧ TSPEC

AREQ

3.4 Composing Invariants with Variants

We use an LTL formula INV to specify adaptation invariants of the system to ensure the properties that should be held throughout the execution of an adaptive system. We name the adaptation variant derived from the neighborhood and sequential compositions as AdaptVar, which we compose with the invariant INV using conjunction to obtain the overall system specification Systemspec .

Figure 1: Adaptation semantics

SPECNS =

k _

Systemspec = AdaptVar ∧ INV SPECSTi ∨ SPECS

(4)

i=0

where k is the number of simple adaptive systems sharing the same source system S.

3.2 Sequential Composition

A complex adaptive system may sequentially perform adaptations more than once during a single execution. For example, an adaptive system may start from a system A, then sequentially perform adaptations A → B to system B, and B → C to system C. Assume the properties of A → B is specified with SPEC AB , and B → C is specified with SPEC BC . Let the flag proposition corresponding to system B be BFL . We use sequential composition to construct the specification for the properties of adaptation A → B → C, SPECABC .

SPECABC = (SPECAB ;true)∧2((¬BFL ∧ BFL )→ SPECBC )

(5)

This formula contains two parts. The first part “SPEC AB ; true” states that the system initially satisfies “SPEC AB ”. The suffix “; true” allows unrestricted future adaptations, which is constrained by the second part of the formula. The second part states that when the flag proposition of B changes from false to true, the system should begin to satisfy SPEC BC . Similarly, a finite number of simple adaptive system specifications can be sequentially composed to construct the specification of more complex adaptive systems. With simple modification, the sequen-

3.5 Automatic Specification Generation

An adaptive system can be visually represented as a graph, where systems 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 systems in an adaptive system. S0 is an initial vertex, representing the initial system of the adaptive system. Function Φ, (Φ : S → LTL), maps each system to the base specification for the system. Function Ξ, (Ξ : S → Π (set of atomic propositions)), maps each system to its flag proposition. A, (A : S × S), is a set of arcs representing adaptation sets. Function P, (P : A → semantics name), maps an adaptation to one of the semantics names {one-point, guided, overlap}. Function Θ, (Θ : A → 7 Π), is a partial function that maps each guided adaptation to its flag proposition. Ψ (Ψ : A → 7 LTL) is a partial function that maps guided or overlap adaptation to their associated base specifications. INV is the adaptation invariant temporal logic specification. We have implemented a prototype, AS PEC G EN, to automate this process. The complexity of the algorithm is linear to the number of adaptations. The detailed algorithm to generate specifications from an adaptation graph is available elsewhere [17].

4. CASE STUDY

In this section we use MetaSockets [15] 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

4.1 MetaSocket Specifications

The specifications of the systems are described as follows: • DES64 system:

SPEC-DES64 = 2(DES64Input(x) → ♦DES64Output(x))2

This formula states that under the DES64 configuration, for every input packet to be encoded by the DES64 filter, the MetaSocket should eventually output a DES64 encoded packet. • DES128 system: SPEC-DES6128 = 2(DES128Input(x) → ♦DES128Output(x))

• DES64COM system: SPEC-DES64COM = 2(DES64COMInput(x) → ♦DES64COMOutput(x))

• DES128COM system:

overlap

overlap

overlap

overlap

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 filters 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 system. The adaptive system is initially running in the DES64 system.

DES128

overlap

overlap

DES64

that manipulate the data stream. For example, filters can perform encryption, decryption, forward error correction, compression, and so forth.

overlap DES64COM

overlap

DES128COM

Figure 2: Visual representation of MetaSocket adaptation semantics graph

We use the DES64 to DES128 adaptation as an example to demonstrate the simple adaptive system specification construction. In order to use overlap semantics, we have to define restriction conditions to prevent overlap of the source and target system input and the overlap of the source and target system output. Therefore, we define the restriction conditions to be RCOND (DES64-DES128) = 2(¬DES64Input(x)∧¬DES128Output(x)). Given the source and target system specifications, the overlap semantics, and the restriction condition, we apply Formula 3 to derive the following specification:

SPEC-DES64-DES128=

(6)

(SPEC-DES64∧(2ExT({DES64FL })∧♦AREQ (DES128) Ω

*2ExT({DES64FL , DES128FL })∧RCOND (DES64-DES128)) Ω

*2ExT({DES128FL })) Ω

∧(2ExT({DES64FL })*2ExT(DES128FL )∧SPEC-DES128)

SPEC-DES6128COM = 2(DES128COMInput(x) → ♦DES128COMOutput(x))

where DES64Input (DES64Output) are events indicating the input (output) of a packet to (from) the MetaSocket under DES64 configuration. DES128Input, DES128Output, DES64COMInput, DES64-COMOutput, DES128COMInput, and DES128COMOutput are defined similarly. To determine the semantics of each adaptation, we consider the following factors: (1) The MetaSocket component is usually applied to 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 systems to input simultaneously because that will cause ambiguity in the input. (3) We should not allow the target system to output data before any output produced from the source system, otherwise, it will complicate the logic on the receiver. Based on the above considerations, we decide to apply the overlap semantics with conditions prohibiting the types of overlap discussed above. The adaptation semantics graph is visually presented in Figure 2. We assign each system a flag proposition: DES64FL , DES128FL , DES64COMFL , DES128COMFL , respectively. 2 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 [18], which converts predicates to propositions by using constant values to represent arbitrary values.

Formula (6) states that after the system receives an adaptation request to the DES128 system (AREQ (DES128)), it should adapt to the DES128 system. Furthermore, the behavior of DES64 and DES128 may overlap, and during the overlapped period, the system should satisfy the restriction condition RCOND (DES64-DES128). With the same approach, we specify other simple adaptive systems in the adaptive system.

4.2 Composing Adaptive System Specifications

To demonstrate the neighborhood composition, we use the neighborhood specification of the DES64 system as an example. It includes two simple adaptive systems: (DES64,DES128) and (DES64, DES64COM). Assume the two simple adaptive systems are specified as SPEC-DES64-DES128 and SPEC-DES64-DES64COM , respectively, then AS PEC G EN generates the neighborhood specification of DES64 as follows:

SPEC-DES64-NEIGHBOR =

(7)

SPEC-DES64 ∧ 2 (NREQ ∧ ExT(DES64)) ∨ SPEC-DES64-DES128 ∨ SPEC-DES64-DES64COM

where NREQ is a proposition that represents “no adaptation request is received”. Likewise, the neighborhood specification for other

systems can be derived. Thus we have four neighborhood specifications: SPEC-DES128-NEIGHBOR, SPEC-DES64-NEIGHBOR, SPEC-DES64COM-NEIGHBOR, and SPEC-DES128COM-NEIGHBOR. Then AS PEC G EN sequentially composes the neighborhood specifications as follows to construct the adaptation variants for the adaptive system.

the adaptive system. 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.

AdaptVar =

The A-LTL introduced in this paper can be considered an extension to the choppy logic [16]. Although we are not aware of existing tools that perform model checking for choppy logic, a tableaubased satisfiability verification approach had been introduced by Rosner and Pnueli [16] with exponential complexity (The exponent is proportional to the number of nested chop operators in the formula). Although A-LTL has worst-case exponential complexity, all three adaptation semantics introduced in this paper have maximum 2 nested adapt (chop) operators in each formula. Furthermore, our approach uses flag propositions to identify the start and the end of each system behavior, making it free from the worst-case scenario. Our preliminary results indicate that the model checking for the specifications generated with our approach should be no more complex than that of LTL. As pointed out by Pnueli et al, most interesting properties are expressible by temporal formulae of small size [19], we believe the real obstacle to A-LTL model checking is the size of the program model being checked, rather than the size of the specification. The model checking of our logic, along with many other model checking techniques, will suffer the state explosion of model checking. We are investigating optimization techniques, such as the on-the-fly model checking proposed by Gerth et al [20].

(8)

SPEC-DES64-NEIGHBOR ∧2(¬DES64FL ∧ DES64FL → (SPEC-DES64-NEIGHBOR)) ∧2(¬DES128FL ∧ DES128FL → (SPEC-DES128-NEIGHBOR)) ∧2(¬DES64COMFL ∧ DES64COMFL → (SPEC-DES64COM-NEIGHBOR)) ∧2(¬DES128COMFL ∧ DES128COMFL → (SPEC-DES128COM-NEIGHBOR))

This formula states that the system originally satisfies the neighborhood specification of DES64. When a flag proposition changes from false to true, the system starts to satisfy the neighborhood specification of the system indicated by the corresponding flag proposition. In addition to the adaptation variants, the system should 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: INV1 = 2¬insecureOutput(x)

• QoS invariant: During system execution, the MetaSocket should not lose any packets, i.e., all input packets should be output: INV2 = 2(Input(x) → ♦Output(x))

• Precedence invariant: The MetaSocket should not output a packet before the corresponding input has been received: INV3 = 2(¬Output(x) U Input(x))

The adaptive system specification is the conjunction of the adaptation variants with the adaptation invariants:

MetaSocketspec = AdaptVar ∧ INV1 ∧ INV2 ∧ INV3 The adaptive system specification MetaSocketspec not only serves as guidance for the developers to design and implement the MetaSocket, it also enables us to perform verification of the adaptive system.

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 systems specified in terms of A-LTL. After an adaptation temporal specification is generated, it may serve as guidance for the adaptation developers to clarify the intent for

Our future work includes automatically generating program models and code based on a given adaptation semantics, developing model checking tools to verify the correctness of adaptive systems, and theorem proving techniques to ensure the correctness of existing safe adaptation protocols.

6. REFERENCES

[1] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and B. H. C. Cheng, “Composing adaptive software,” IEEE Computer, vol. 37, no. 7, pp. 56–64, 2004. [2] S. Kulkarni and K. Biyani, “Correctness of component-based adaptation,” in Proceedings of International Symposium on Component-based Software Engineering, May 2004. [3] R. Milner, J. Parrow, and D. Walker, “A calculus of mobile processes, I,” Information and Computation, vol. 100, no. 1, pp. 1–40, 1992. [4] J. Kramer, J. Magee, and M. Sloman, “Configuring distributed systems,” in Proceedings of the 5th workshop on ACM SIGOPS European workshop, pp. 1–5, ACM Press, 1992. [5] C. E. Cuesta, P. de la Fuente, and M. Barrio-Sol´arzano, “Dynamic coordination architecture through the use of reflection,” in Proceedings of the 2001 ACM symposium on Applied computing, pp. 134–140, ACM Press, 2001.

[6] S. S. Kulkarni, K. N. Biyani, and U. Arumugam, “Composing distributed fault-tolerance components,” in Proccedings of the International Conference on Dependable Systems and Networks (DSN), Supplemental Volume,

Workshop on Principles of Dependable Systems, pp. W127–W136, June 2003. [7] J. Kramer and J. Magee, “The evolving philosophers problem: Dynamic change management,” IEEE Trans. Softw. Eng., vol. 16, no. 11, pp. 1293–1306, 1990. [8] P. Oreizy, N. Medvidovic, and R. N. Taylor, “Architecture-based runtime software evolution,” in Proceedings of the 20th international conference on Software engineering, pp. 177–186, IEEE Computer Society, 1998. [9] W.-K. Chen, M. A. Hiltunen, and R. D. Schlichting, “Constructing adaptive software in distributed systems,” in Proc. of the 21st International Conference on Distributed Computing Systems, (Mesa, AZ), April 16 - 19 2001. [10] J. Appavoo, K. Hui, C. A. N. Soules, et al., “Enabling autonomic behavior in systems software with hot swapping,” IBM System Journal, vol. 42, no. 1, p. 60, 2003. [11] N. Amano and 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, pp. 57–61, ACM Press, 2002. [12] J. Zhang, Z. Yang, B. H. Cheng, and P. K. McKinley, “Adding safeness to dynamic adaptation techniques,” in Proceedings of ICSE 2004 Workshop on Architecting Dependable Systems, (Edinburgh, Scotland, UK), May 2004. [13] J. Zhang, B. H. Cheng, Z. Yang, and P. K. McKinley, “Enabling safe dynamic component-based software adaptation,” Architecting Dependable Systems, Lecture Notes in Computer Science, 2005. Accepted for publication. [14] A. Pnueli, “The temporal logic of programs,” in Proceedings of the 18th IEEE Symposium on Foundations of Computer Science, pp. 46–57, 1977. [15] S. M. Sadjadi, P. K. McKinley, and 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), pp. 46–55, May 2003. [16] R. Rosner and A. Pnueli, “A choppy logic,” in 1st IEEE Symposium on Logic in Computer Science, pp. 306–313, 1986. [17] J. Zhang and B. H. Cheng, “Adaptation semantics,” Tech. Rep. MSU-CSE-05-7, Computer Science and Engineering, Michigan State University, East Lansing, Michigan, February 2005. [18] M. B. Dwyer and 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, pp. 189–202, ACM Press, 1998. [19] O. Lichtenstein and A. Pnueli, “Checking that finite state concurrent programs satisfy their linear specification,” in Proceedings of the 12th ACM SIGACT-SIGPLAN symposium on Principles of programming languages, pp. 97–107, ACM Press, 1985.

[20] R. Gerth, D. Peled, M. Vardi, and 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), June 1995.