Abstract Using Temporal Logic to Specify Adaptive Program Semantics

Using Temporal Logic to SpecifyAdaptive Program Semantics∗Ji Zhang and Betty H.C.ChengSoftware Engineering and Network Systems LaboratoryDepartment of Computer Science and EngineeringMichigan State UniversityEast Lansing,Michigan48824tted:{zh1IntroductionIncreasingly,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 im-precise 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 correct-ness 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 adap-tations.Kulkarni et al.(2)introduced a transitional-invariant lattice approach that uses theorem proving techniques to show that during and after an adapta-tion,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 implemen-tation 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 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.(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 im-plementation of achieving adaptability,while the requirements for adaptation are largely assumed or ambiguous.We believe that the semantics for adaptive software should be explicitly cap-tured 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 Lan-guage(ADL)-based approaches model adaptive programs with connection andreconnection 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 afinite 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 Tempo-ral 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 for-mally 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 adap-tive programs semantics,which can be automatically processed to generate adaptive program specifications.The formal specifications for adaptive programs precisely describe the objec-tives for adaptive programs,which facilitate rigorous software requirements specifications,and thus improves the assurance of the software.The adap-tation 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 nu-merous 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 adap-tive mobile computing applications,including MetaSockets(24).The remain-der of this paper is organized as follows.In Section2,we introduce A-LTL and describe three basic adaptation semantics.Section3describes neighborhood specification compositions,sequential specification compositions,and adapta-tion semantics graphs.Section4illustrates our approach with a MetaSockets example.Section5concludes the paper and discusses future directions.2Adaptation SemanticsIn 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,orbriefly 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.1Adapt Operator-Extended LTLLTL 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 be-havior 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 incon-venient 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 tem-poral 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 afinite state sequence andφis an A-LTL formula,thenσ|=fφiffσ |=φ,whereσ is an infinite state sequence constructed by repeating thelast state ofσ.•σ|=φΩ ψiffthere exist afinite state sequenceσ =(s0,s1,···s k)and an infinite state sequenceσ =(s k+1,s k+2,···),such thatσ=σ σ ,σ |=fφ,σ |=ψ,and(s k,s k+1)|=fΩ,whereφ,ψ,andΩare A-LTL formulae.A sequence satisfyingφΩ ψcan be considered the concatenation of two subsequences,where thefirst subsequence satisfiesφ,the second subse-quence 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 execu-tion.Wefirst 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 com-pose adaptation invariants with adaptation variants to specify the overall adaptive program behavior.2.2Semantics for Adaptation VariantsSeveral 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 re-strictions,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 spec-ified 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 trans-lates 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 A REQ 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 se-mantics 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 appli-cable,the restriction condition during adaptation is R COND.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.1One-point adaptation.Under one-point adaptation semantics,after receiving an adaptation requestA REQ,the program adapts to the target program T SPEC at a certain pointduring 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∧♦A REQ)Ω T SPEC(1) The formula states that the program initially satisfies S SPEC.After receiving an adaptation request,A REQ,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 isvisually presented in Figure1(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 ex-plicitly 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.2Guided adaptation.Under guided adaptation semantics(visually depicted in Figure1(b)),after receiving an adaptation request,the programfirst restrains its source pro-gram behavior by a restriction condition,R COND,and then adapts to the target program when it reaches a safe state.This semantics is suitable for adapta-tions 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 willfinally reach a safe state.S SPEC∧(♦A REQΩ1 R COND) Ω2 T SPEC(2) This formula states that initially S SPEC is satisfied.After an adaptation re-quest,A REQ,is received,the program should satisfy a restriction conditionRCOND(marked withΩ1 ).When the program reaches a safe state of the source,the program stops being constrained by S SPEC,and starts to satisfy T SPEC (marked withΩ2 ).The hot-swapping technique introduced by Appavoo et al(12)and the safe adaptation protocol(6)introduced in our previous work use the guided adaptation semantics.2.2.3Overlap adaptation.Under overlap adaptation semantics(visually depicted in Figure1(c)),the tar-get 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 se-mantics 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.S SPEC∧(♦A REQΩ1 R COND) Ω2 true ∧ ♦A REQΩ1 T SPEC∧(R CONDΩ2 true) (3)This formula states that initially S SPEC is satisfied.After an adaptation re-quest,A REQ ,is received,the program should start to satisfy T SPEC and alsosatisfy a restriction condition,R COND (marked with Ω1 ).When the programreaches a safe state of the source program,the program stops being obliged by S SPEC and R COND (marked with Ω2 ).The graceful adaptation protocol in-troduced by Chen et al (11)and the distributed reset protocol introduced by Kulkarni et al (8)use the overlap adaptationsemantics.SPEC S SPECTSPEC S SPECT REQRSPEC S SPECTREQCONDFig.1.Adaptation semantics2.2.4Safety 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 hap-pens,while a liveness property asserts something good will eventually hap-pen (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 pointliveness 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.LEMMA1: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.ProofLet the adaptation specificationξbe(Formula1)ξ=(S∧♦A REQ)Ω T SPECSPECFor an arbitrary sequenceσ|=ξ,∃σ |=S SPEC∧♦A REQ andσ |=T SPEC, andσ=σ σ .Since(S SPEC∨T SPEC)→2¬η,σ |=2¬η,andσ |=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.LEMMA2: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(Formula1)∧♦A REQ)Ω T SPECξ=(SSPECFor an arbitrary sequence s0,s1,···|=ξ,∃i,such that s0,s1,···s i|=S SPEC∧♦A REQ and s i+1,s i+2,···|=T SPEC.Since(S SPEC∨T SPEC)→2(α→♦β),we have s0,s1,···s i|=2(α→♦β),and s i+1,s i+2,···|=2(α→♦β).For an arbitrary state s j,if s j|=α,then we have•if j≤i,then there exists k(j<k≤i)such that s k|=β;•if j>i,then there exists k(j<k)such that s k|=β.That is,s0,s1,···|=2(α→♦β)Therefore,we haveξ→2(α→♦β).3Specification CompositionsThus 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 spec-ifications together to describe the behavior of executions with multiple adap-tation occurrences.3.1Neighborhood CompositionA 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 T i is specified with an A-LTL formula STi SPEC,and the properties of S are specified withS SPEC.We can construct the specification for the neighborhood of S by thedisjunction of S SPEC and STi SPEC.Let N SPEC be the neighborhood specification of S,we haveN SPEC=ki=1STiSPEC∨S SPEC(4)where k is the number of simple adaptive programs sharing the same source program S.3.2Sequential CompositionA complex adaptive program may sequentially perform adaptations more than once during a single execution.For example,an adaptive program may startfrom 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 ofA,B,and C are specified with ASPEC,B SPEC,and C SPEC,respectively.The A toB adaptation specification under a given adaptation semantics is a function ofASPEC and B SPEC:AB SPEC=ADAPT1(A SPEC,B SPEC).The B to C adaptationspecification under a given adaptation semantics is a function of B SPEC andC SPEC:BC SPEC=ADAPT2(B SPEC,C SPEC).The specification of A to B to Cmay be constructed by substituting AB SPEC for the B SPEC in BC SPEC.ABCSPEC=ADAPT2(ADAPT1(A SPEC,B SPEC),C SPEC)(5)Similarly,afinite 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 adap-tation semantics and the two types of compositions.Proof outline:This theorem can be proved by applying Lemma1and Lemma2.•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 states0-step sequential composition preserves pointsafety and liveness properties.This has been proved by Lemma1and Lemma2.(2)Then we assume any n-step sequential composition preserves pointsafety and liveness properties.An n+1-step sequential composition can be considered as an n-stepsequential composition composed with a base specification.Then wecan apply Lemma1and Lemma2to the n-step adaptation compo-sition case and claim that all n+1-step sequential compositions alsopreserve point safety and liveness properties.3.3Adaptation InvariantsIn 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 adap-tation invariants of the program to ensure the properties that should be held throughout the execution of an adaptive program.3.4Adaptation Specification Visualization and Automatic GenerationAn 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,repre-senting 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→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.4Case StudyIn this section we use MetaSockets(24)as an illustrative example to demon-strate our adaptation specification approach.MetaSockets are constructed from the regular Java Socket and MulticastSocket classes;however,their inter-nal structure and behavior can be modified at run time in response to external conditions.MetaSocket behavior can be adapted through the insertion and removal offilters 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 differentfilters:a data com-pressionfilter(COM),a DES64-bit encryptionfilter(DES64),and a DES 128-bit encryptionfilter(DES128).The available adaptations are data com-pressionfilter insertion and removal,and DESfilter replacement.Note that to enforce security,the DESfilters can only be replaced by other DESfilters, but cannot be removed.Thesefilters can be combined in four different config-urations:DES64,DES128,DES64with COM(DES64COM),and DES128with COM(DES128COM).We consider the MetaSocket under each configuration a program.The adaptive program is initially running in the DES64program.4.1MetaSocket SpecificationsThe specifications of the programs are described as follows:•DES64program:DES64SPEC =(2DES64FL)∧2(DES64Input(x)→♦DES64Output(x))The DES64Input(DES64Output)are events indicating the input(output) of a packet to(from)the MetaSocket under DES64configuration.1The flag proposition DES64FLindicates that the program is running under the DES64configuration.The formula states that under this configuration,for every input packet to be encoded by the DES64filter,the MetaSocket should eventually output a DES64encoded packet.The following program aspects can be interpreted in a similar way.•DES128program:DES128SPEC=(2DES128FL)∧(2(DES128Input(x)→♦DES128Output(x)))•DES64COM program:DES64COMSPEC=(2DES64COMFL)∧(2(DES64COMInput(x)→♦DES64COMOutput(x)))•DES128COM program:=DES128COMSPEC(2DES128COM FL)∧(2(DES128COMInput(x)→♦DES128COMOutput(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.2.The adaptation semantics graph is visually presented in FigureFig.2.Visual representation of MetaSocket adaptation semantics graphWe use the DES64to DES128adaptation 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 beR(DES64-DES128)=2(¬DES64Input(x)∧¬DES128Output(x)).(6) CONDThe intuition for this restriction condition is that it should not accept any more DES64inputs and will not produce any DES128outputs until all DES64out-puts have been produced.Given the source and target program specifications, the overlap semantics,and the restriction condition,we apply Formula3toderive the following specification:DES64-DES128SPEC =(7)DES64SPEC∧ ♦A REQ(DES128)true R COND(DES64-DES128) true true ∧ A REQ(DES128)true DES128SPEC∧(R COND(DES64-DES128)true true) Formula(7)states that after the program receives an adaptation request to the DES128program(A REQ(DES128)),it should adapt to the DES128program. Furthermore,the behavior of DES64and DES128may overlap,and during the overlapping period,the program should satisfy the restriction conditionR COND(DES64-DES128).In this example,theΩnotation of the adaptationoperators 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 Lemma2,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:During program execution,the sender MetaSocket should not cause any loss of packets,i.e.,all input packets should be output:INV2=2(Input(x)→♦Output(x))Note,this invariant is already guaranteed by the point liveness preservation property of the adaptation semantics.(Formula8.)。