Model Checking Aspectual Pervasive Software Services

Model Checking Aspectual Pervasive Software Services

Dhaminda B. Abeywickrama, Sita RamakrishnanClayton School of Information Technology

Monash University, Clayton CampusVictoria 3800, Australia

[email protected], [email protected]

Abstract—Context-dependent information is tightly couplingor crosscutting the core functionality of a service at the serviceinterface level. This results in a complex design, which isdifficult to implement and maintain. The crosscutting context-dependent functionality of interacting pervasive services canbe modeled as aspect-oriented models in UML. However, thishas two challenges: the semi-formal nature of UML notations,and the expressive power of aspects. This paper exploresmodel checking as a solution for modeling aspectual perva-sive software services and their compositions, and rigorouslyverifying the process behavior of these models against specifiedsystem properties. Model checking is applied, first to check thebehavior of the individual pervasive aspects and components,and second to verify the overall behavior of the woven modeleven if no errors are found in the individual pervasive aspectsand components. These verification stages have been usedto gain confidence before the complex pervasive services areactually implemented. The approach is explored using a real-world case study in intelligent transport with more than 30properties formalized to provide a comprehensive coverage ofthe system requirements. An evaluation framework has beenestablished to validate the main methods and tools employedin the study.

Keywords-pervasive services; model checking; aspect-oriented modeling; model-driven development;

I. INTRODUCTION

A pervasive Web service is a special type of servicethat adapts its behavior or the content it processes to thecontext of one or several parameters of a target entity ina transparent way (e.g. restaurant finder services, attractionsand activities recommendation services, navigation and real-time traffic services, and dating services) [1]. With the pro-liferation of ubiquitous computing devices and the Internet,pervasive services continue to evolve from simple proofof concept implementations created in the laboratory tolarge and complex real-world services developed in industry.Context-awareness capabilities in service interfaces intro-duce additional challenges to the software engineer. Contextinformation is characterized by several qualities that makepervasive services challenging compared to conventionalWeb services, such as a highly dynamic nature, real-timerequirements, quality of context information and automation.The additional complexities associated with these specialservices necessitate the use of solid software engineeringmethodologies during their development and execution, such

as model-driven architecture, aspect-oriented modeling andformal model checking.

Context-dependent information is tightly coupling orcrosscutting the core functionality of a service at serviceinterface level. This results in a complex design, whichis difficult to implement and maintain. The crosscuttingcontext-dependent functionality of interacting pervasive ser-vices can be modeled as aspect-oriented models in UML.However, this has two challenges: the semi-formal nature ofUML notations, and the expressive power of aspects. First,one of the main limitations of UML is its lack of supportfor rigorous verification due to its informal or semi-formalnature. Second, the expressive power of aspects in designspecifications can be potentially harmful. The crosscuttingnature and the obliviousness principle of aspects are twomain issues that can introduce an additional correctnessproblem in an aspect-oriented design specification. In gen-eral, the crosscutting effect and oblivious principle of aspectscan create several issues such as partial weaving, unknownaspect assumptions, unintended aspect effects, arbitrary as-pect precedence, failure to preserve state invariants, andincorrect changes in control dependencies [2], [3]. Thus,the need for a more formal, rigorous specification andverification method for context-dependent adaptive behaviorin service specifications is clear, such as model checking.

This paper explores model checking as a solution formodeling aspectual pervasive software services and theircompositions, and verifying the process behavior of thesemodels against specified system properties [4]. Model check-ing is applied, first to check the behavior of the individualpervasive aspects and components, and second to verify theoverall behavior of the woven model even if no errors arefound in the individual pervasive aspects and components.These verification stages can be used to gain confidencebefore the complex pervasive services are actually imple-mented. The approach is explored using a real-world casestudy in intelligent transport with more than 30 propertiesformalized to provide a comprehensive coverage of thesystem requirements. While several researchers [2], [3] haveemphasized the challenges associated with the expressivepower of aspects in design specifications, to the best of ourknowledge there is no work that explores model checking asa solution to the crosscutting effects of pervasive aspects at

2011 35th IEEE Annual Computer Software and Applications Conference

0730-3157/11 $26.00 © 2011 IEEE

DOI 10.1109/COMPSAC.2011.41

262


0730-3157/11 $26.00 © 2011 IEEE

DOI 10.1109/COMPSAC.2011.41

263


0730-3157/11 $26.00 © 2011 IEEE

DOI 10.1109/COMPSAC.2011.41

253

the service interface level. This verification approach is novelin this respect. An evaluation framework is established tovalidate the main methods and tools employed in the study.

The rest of the paper is organized as follows. SectionII provides background information on the tools and tech-niques, the overall research methodology, the case study, andthe context-dependent adaptive behavior generation processapplied in this study. An overview of this authors’ modelchecking process is provided in Section III. Sections IVand V discuss the aspect-oriented pervasive models createdand concurrency modeling performed on the services. InSection VI the properties specification and verification of themodels are elaborated. The evaluation framework establishedto validate the main methods and tools used is providedin Section VII. Section VIII summarizes related work, andSection IX concludes the paper.

II. BACKGROUND

This section provides background information on (A) thetools and techniques, (B) the overall research methodology,(C) the case study, and (D) the adaptive behavior generationprocess applied in this study [4].

A. Tools and Techniques usedModel checking is an automatic technique for verifying

finite state concurrent systems [5]. The Labeled TransitionSystem Analyzer (LTSA) is a model checking tool forconcurrency modeling, model animation and model propertychecking [6]. Finite State Processes (FSP) is a processcalculus provided by the LTSA for concisely describing andreasoning about concurrent programs. In FSP, processes canbe defined by using one or more auxiliary processes sepa-rated by commas and terminated by a full stop. Processescan be composed using the parallel composition operatorand interactions can be modeled using shared actions, the re-naming operator and the hiding operator. System propertiescan be defined using safety and progress property processesand fluent linear temporal logic (FLTL) assertions. TheLTSA-MSC tool is an extension of the LTSA, which allowsdocumenting scenarios in the form of graphical messagesequence charts and generating a behavioral model in FSP.

B. Engineering Aspectual Pervasive ServicesThe overall pervasive service-oriented development pro-

cess of this study is divided into three stages (Fig. 1) [4].First, using the case study we extract use cases and definea service specification for the system under considerationusing message sequence charts. Second, the architecturefor the system is defined using a component configurationand an architecture model in FSP using the LTSA-MSCtool. Third, the architecture model synthesized from theprevious step is modularized with aspect-oriented modelsin UML called the contextual-FSP aspects (c-FSPaspects), and automatically transformed into FSP beforeapplying model checking using the LTSA tool.

��

��

��

��

�� !

��"��

��!

��"��

��

��#��

��

��

��

Figure 1: Pervasive services engineering.

C. Case Study: Awareness Monitoring and Notification

The research approach is explored using a real-worldcase study in intelligent tagging for transport known asthe ParcelCall project [7]. ParcelCall [7] is a EuropeanUnion project within the Information Society Technologiesprogram. The case study describes a scalable, real-time,intelligent, end-to-end tracking and tracing system usingradio frequency identification (RFID), sensor networks, andservices for transport and logistics. This case study isparticularly appealing to the current research as it pro-vides several scenarios for representing software servicesthat interoperate in a pervasive, mobile and distributedenvironment. A significant subset of the ParcelCall casestudy is exception handling that needs to be enforcedwhen a transport item’s context information violates accept-able threshold values. The reference scenario used in thisresearch describes an awareness monitoring andnotification pervasive service, which alertswith regards to any exceptional situations that may ariseon transport items, primarily to the vehicle driver of thetransport unit. The threshold values for environment status(e.g., temperature, pressure, acceleration) of transport itemsand route (location) for the vehicle are set by the carrierorganization in advance. The service alerts if items’ envi-ronment status exceeds acceptable levels or if an item islost or stolen during transport. The primary context param-eters modeled in the study include item identity, location,temperature, pressure and acceleration.

D. Context-Dependent Adaptive Behavior Generation

The notion of context used in this research is based ona definition provided by Analyti et al. [8] for context ininformation modeling. They describe context as a set ofobjects, each of which is associated with a set of namesand another context called its reference. Furthermore, theyenhance the definition for context by stating that each objectof a context is either a simple object or a link object(attribute, instance-of, ISA) and each object can be relatedto other objects through attribute, instance-of or ISA links.Analyti et al. [8] use traditional object-oriented abstractionmechanisms of attribution, classification, generalization andencapsulation to structure the contents of a context.

263264254

The model transformation tool created in our study iscalled the Aspectual FSP Generation tool [4].The transformations have been applied to the reference sce-nario in intelligent transport. We use model transformationsto automate the application of design patterns and generateinfrastructure code for the c-FSP aspects using FSPsemantics. The current study explores the strengths of bothsemi-formal UML meta-level extensions and formal finitestate machines for representing the context-dependent be-havior of software services, and model transformation tech-niques are applied as a bridge to enforce correct separationof concerns between these two design abstractions. Themain benefits of this approach are: improving the qualityand productivity of service development; easing systemmaintenance and evolution; and increasing the portabilityof the service design for the pervasive services engineer.

This approach focuses on the application of model-drivendevelopment for engineering pervasive services at finitestate machine level. An aspect in FSP can be identifiedas an independent finite state machine that executes con-currently and synchronizes with its base state machine. Ingeneral, an aspect in FSP needs to contain synchroniza-tion events (transitions) to coordinate with its base statemachine and other aspects. Also, each aspect type (e.g.context, trigger and recovery) contains its uniqueconstructs which can be generated automatically usingmodel transformation techniques. For example, a triggeraspect requires constructs to alert and send notificationswhile a recovery aspect needs constructs to recoverfrom exception-handling situations. On the other hand, acontext aspect has attribution, instance-of, ISA, andreference constructs from the notion of context applied inthis research.

In Fig. 2, the models and activities of the developmentprocess are represented as ellipses and square boxes re-spectively. The development process is structured into threemain flows of activities. Flow 1 and Flow 2 extensivelyapply model transformations where Flow 1 uses a model-to-text JET transformation and Flow 2 applies an effectivepipeline of model-to-model and model-to-text JET trans-formations. Both Flow 1 and Flow 2 originate from thec-FSP-UML profile. This profile describes our concep-tual model to decouple crosscutting context-dependent infor-mation of a service from the core service behavior at serviceinterface level. Flow 3 represents activities involved forrigorously verifying the context-dependent adaptive behaviorand the core service behavior of the pervasive softwareservices using formal model checking, which is the focusof this paper.

III. MODEL CHECKING ASPECTUAL PERVASIVESOFTWARE SERVICES

In this section, we provide an overview of the activitiesinvolved in rigorously verifying the models generated for

��

��

��

��

��

�� !��

� ��

�� "��

"��#��$� ��

�� !��%��

�� &�� '��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figure 2: Adaptive behavior generation process.

��

��

�� !

��

!��"��

#�"��

��$%��!��&��

��'��

��(��)*��

#�"��

��!��(��&��

��!��+��

!��"��

��$%��$%��!��&��!��&��

��'��

��(��)*��(��)*��(��)*��

!��*��(#��)*��

��

��

��"��!��

��

��

��

Figure 3: Model checking aspectual pervasive services.

the context-dependent adaptive behavior and the core servicebehavior using formal model checking [4]. This is shown byFlow 3 in Fig. 2, and further elaborated in Fig. 3.

• Modeling: The modeling step involves two main tasks.They are performed to obtain the context-dependentadaptive behavior and the core service model of thesoftware services. In this study, the Aspectual FSPGeneration tool is used to generate the context-dependent behavioral code in formal FSP (Fig. 2). TheLTSA-MSC tool is used to generate the architecturemodel for the service specification in FSP, which isused to extract the core service model of the services(Fig. 2, Fig. 3). All service components and aspectsare modeled as processes represented as finite statemachines in FSP. To verify the pervasive service speci-fication, first the aspects are woven into their base statemachines in FSP using an explicit weaving mechanism.Then concurrency and distributed notions are added tothe service specification to facilitate reasoning by theLTSA tool. Abstraction mechanisms are introduced toreduce the size of the woven model.

• Specification: The properties to be verified are formal-ized according to the system requirements, which are

264265255

Figure 4: ACA TEMP aspect and the label literals created for the attribution construct.

expressed as property processes (safety and progress)and FLTL assertions. According to the system require-ments from the case study subset, more than 30 prop-erties have been formalized focusing on the requiredbehavior from both service components and aspects inthe specification.

• Verification: Finally, all behavior and property pro-cesses are composed into a system-level process andthis process is fed to the LTSA. The LTSA toolverifies whether any properties are violated and if soit reports a trace to the property violation known asa counterexample. Also, the use of FLTL assertionsprovides the opportunity to generate examples of modelexecutions or traces (witness executions) which satisfythe property. The use of counterexamples and witnessexecutions is exploited to identify and track any errorsand their sources in the specification, which consistsof several distributed service components and aspectscollaborating with each other. Thus, this helps to itera-tively improve the state models or the system propertiesfor the aspectual pervasive services.

IV. PERVASIVE ASPECT-ORIENTED STATE MODELS

In this study an aspect is modeled as an indepen-dent state machine that synchronizes with the base statemachine at specific synchronization points [4]. An as-pect is defined as a modular encapsulation or unit forthe crosscutting context-dependent behavior at the serviceinterface level. The context procurement and contextual-ization activities of the awareness monitoring andnotification pervasive service are driven bythe c-FSP aspects. The current study identifies threetypes of aspects, which are collectively referred to asthe c-FSP aspects. They are: context aspects,trigger aspects and recovery aspects.

There are two types of context aspects: atomiccontext aspects and composite contextaspects. Atomic context aspects model

low-level context readings from the context sources(e.g. temperature) while composite contextaspects encapsulate high-level derived contextinformation (e.g. isAdverseStatus). Also, the currentresearch applies the notions of attribution, classification,generalization and encapsulation from the context definition[8] to structure and link the objects defined in a contextaspect. The notion of context identifies that each objectof a context can be a simple object or a link object (i.e.attribute, instance-of and ISA). Also, each object can berelated to other objects through attribute, instance-of andISA links. The notion of context defines three predicates tospecify the link object, the source object and the destinationobject: attr(attr obj, from, to), in(in obj, from, to) andisa(isa obj, from, to). The present study models theseobjects as label literal variables or boolean variables inFSP as required in the scenario. Variables in FSP maytake an integer value or a label value. Label literals canbe formed by preceding an action label with a quote(e.g. ’labelname). For example, the Atomic ContextAspect Temperature aspect (ACA_TEMP) containsthree label literals for modeling attr obj, from and toobjects of the attribution construct. Furthermore, the processdefinition for this aspect includes transitions which read andwrite to these variables (Fig. 4). Composite ContextAspect Adverse Environment Status aspectincludes an object to represent the high-level derivedcontext information (isAdverseState). This object hasbeen modeled using a boolean variable in FSP. The processdefinition for the aspect includes transitions for reading andwriting from this boolean variable.Trigger aspect (e.g. Trigger Aspect

Adverse Environment Status) models thecontextual adaptation where the service is automaticallyexecuted or modified based on context information.In general, a trigger aspect has a contextconstraint and an action. Context constraintof the trigger aspect is modeled as a conditional

265266256

transition or a guarded transition in FSP. Action ofthe trigger aspect is modeled as a transition inFSP, which instructs the Notifier component to sendan SMS to the vehicle driver. Recovery aspect(e.g. Recovery Aspect Adverse EnvironmentStatus) models recovery actions that follow after anexceptional situation is raised by a trigger aspect.The execution of this aspect is dependent on the existenceof the trigger aspect. For example, it may includetransitions that control the refrigerator’s temperature in thetransport unit.

A. Joinpoint Model applied

In this subsection, the joinpoint model applied in this re-search for the pervasive aspect-oriented state models in FSPis discussed. A main element in the design of any aspect-oriented language is the notion of the joinpoint model. Thejoinpoint model of our approach is used to facilitate thecorrect coordination of a base state machine and an aspectualstate machine in FSP. Also, it is applied for weaving an as-pectual state machine to its non-aspectual base state machineat specific synchronization points or joinpoints. This studyconcentrates only on dynamic crosscutting of the context-dependent adaptive behavior at the service interface level.Therefore, the specification of inter-type declarations hasnot been considered. The main crosscutting elements of thejoinpoint model are:

• Joinpoints or synchronization events: A joinpoint isa transition in the base state machine where context-dependent adaptive behavior crosscuts the base statemachine. It is effectively a transition in the base statemachine which acts as a synchronization point with theaspectual state machine in FSP.

• Transition pointcuts: A pointcut in this study denotesa sequence of joinpoints.

• Advice state models: In general, an advice providesthe actual crosscutting behavior which is defined interms of pointcuts. In this study, an advice is specifiedusing a finite state machine that describes the controllogic or behavior applied to each joinpoint picked outby the pointcut. How an advice is executed dependson the type of advice used. This study models thearound advice type in FSP, which comprises threeparts: before actions, proceed actions and after actions.Proceed actions are compulsory control events whilebefore and after actions can be optional.

• Aspects state models: In the study, an aspect canbe identified as a modular encapsulation or unit forcrosscutting context-dependent adaptive behavior atthe service interface level. It effectively modifies theexecution of the base state machine by adding newbehavior. The notion of aspect applied here is state-ful. An aspect state model contains an advice statemodel and pointcuts. The present research applies the

notions of attribution, instance-of and ISA to formalizeand modularize context information within an aspect.However, as our pointcut model defines a sequence ofjoinpoints as opposed to pairs of pointcuts and advice,in this respect this study’s aspects state models can beconsidered much richer.

B. Pervasive Service Composition through Weaving

Weaving of an aspect to its base state machine is importantin order to analyze the overall system behavior. An explicitweaving mechanism is used here, where an aspect is woveninto its base state machine using the parallel compositionoperator and shared actions in FSP. The main elements ofthe weaving process are the base program and an aspectualstate machine (aspect). In general, the base program is not asingle process but it is a combination of several processes. Abase program (core service model) is specified as the parallelcomposition of the constituent base state machines in themodel. In order to support explicit parallel composition,the current study injects synchronization events in boththe aspectual state machine and the base state machine.These events provide an effective mechanism to control thecoordination between an aspectual state machine and a basestate machine. The advice of an aspect contains three logi-cal parts: before advice events, proceed events andafter advice events. By using synchronization eventsthe correct execution of these three sequences of actionswith the base program can be ensured. Also, weaving ofmore than one aspect at the same joinpoint is possible usingthese explicit synchronization events.

The crosscutting elements of the joinpoint model andthe weaving process followed are discussed next using acase study example. Fig. 5a shows LTSs for three pro-cesses. The RFID Tag (RFID_TAG) and the ContextInterpreter (CONTEXT_INTERPRETER) componentsare the base state machines while the Atomic ContextAspect Temperature (ACA_TEMP) is an aspectualstate machine. The joinpoints of the base program arespecified using the following synchronization events: bf_a(before advice), pr_s (proceed start), pr_e(proceed end), af_a (after advice). A pointcutis a sequence of joinpoints; thus, the sequence of bf_a,pr_s, pr_e and af_a constitutes the pointcut for thisaspect. The execution and coordination of the base programand the aspect (Fig. 5b) can be explained as follows.The base program (RFID_TAG) emits the bf_a event tothe aspect. The aspect performs an initialization operation(initializeACATEMP), which is a before advice event.The base program waits for a control event from the aspect,which is a proceed event (pr_s) in this example. The baseprogram performs the measureTemperature event andthen emits pr_e to return the control back to the aspect.The aspect performs receiving of temperature readings usingmessage passing, which is its after advice events. Finally,

266267257

(a) Weaving illustrated using LTSs.

��

��

��

��

��

��

��

(b) Synchronization events.

Figure 5: Weaving performed.

the base program (Context_Interpreter) waits for theend of advice event (af_a) from the aspect, and performsthe storeContextInformation action. The wovenprogram is modeled as the parallel composition of the basestate machines and the aspect.

V. CONCURRENCY MODELING BETWEEN PERVASIVEASPECTS AND COMPONENTS

After weaving aspects into their base state machines theconcurrency and distributed notions of the interacting per-vasive software services are modeled to facilitate reasoningby the LTSA tool, such as message passing, shared objectsand mutual exclusion (Fig. 6) [4]. The pervasive servicespecification includes several distributed service componentsand aspects collaborating with each other. These componentsand aspects encompass the active entities of the specification.It also includes shared objects and semaphores, which actas passive entities. All active and passive entities of thespecification have been modeled as processes represented asfinite state machines in FSP. In the specification, concurrencyhas been modeled using action interleaving. Actions a and bare concurrent if they can occur in the order of a -> b or b-> a. Concurrency has been modeled using an interleaved

� ��

��

��

��

��

��

��

��

��

��

!��

��

��

��

� �

� �

� �

� �

� ��

� �

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

�

��

��

� ��

��

� � ��

�

�

�

��

�

��

��

��

��

��

��

� �

��

��

��

��

��

��

��

��

�

� �

� �

�

Figure 6: Concurrency modeling.

model of concurrent execution.This study models the awareness monitoring

and notification service as a process-orientedcontext value chain. This value chain contains several stages:sensing, refinement, aggregation and contextualization. Thecontext procurement and contextualization tasks of thepervasive service are driven by the c-FSP aspects. Thecommunication between the distributed service componentsand aspects (e.g. between RFID Tag and AtomicContext Aspect Temperature) has been modeledusing the synchronous message passing technique. Theenvironmental readings (e.g. temperature, pressure) from theRFID Tag are sent using a single channel to the receiver(e.g. Atomic Context Aspect Temperature,Atomic Context Aspect Pressure) and thecommunication is one to one. In addition to using themessage passing technique, shared objects have been usedto model inter-process communication between the service

267268258

components and the aspects. The problem of interferencehas been solved by enforcing mutually exclusive access tothe shared objects. This has been modeled using binarysemaphores, which is a mechanism for dealing withinter-process synchronization problems. For example, theAtomic Context Aspect Temperature aspect andthe Context Interpreter component interact usinga shared object for communicating temperature valuesused in the refinement stage of the context value chain ofthe pervasive service. The mutually exclusive access tothis shared object has been enforced using a semaphore,thus only one process can access it at a given time. TheContext Database process has been modeled as ashared resource where the Context Interpreter andthe Context Aggregator service components writeto it (writers) and the Composite Context AspectRoute Status and the Composite ContextAspect Adverse Environment Status aspectsread from it (readers). This scenario has been modeled asa readers-writers problem with writers priority. The readersare denied access if there are writers waiting to acquireaccess and if a writer is not accessing the database anynumber of readers can access the database concurrently.Abstraction Mechanisms applied in the models: These areneeded as a woven program may have too many states tobe analyzed by the LTSA. One of the main challenges asso-ciated with the model checking technique is the state spaceexplosion problem. In the present study, action hiding andminimization features available in FSP are used to reducethe size of the woven model before analyzing using theLTSA tool. For example, the actions or events modeled in theContext Interpreter and Context Aggregatorcomponents for enforcing mutually exclusive access to theirshared variables are not required when modeling the readers-writers problem with writers priority, which involves thesame components collaborating with aspects. Also, whenexecuting the entire specification model, the partial orderreduction feature has been used to reduce the size of thestate space searched by the LTSA model checker.

VI. PROPERTIES SPECIFICATION AND VERIFICATION OFASPECTUAL PERVASIVE SOFTWARE SERVICES

This section discusses the properties specification andverification stages of the model checking process [4].

A. Safety Requirements of the Study

Safety properties are used in a concurrent programto assert that nothing bad happens during the executionof the program. In the case study subset, several safetyproperties have been specified for verifying the behav-ior of the individual aspects and the components, andthe behavior of a woven model. As for safety prop-erties defined at the individual components and aspectslevel, a safety property (S_TA_ADENST) has been defined

Figure 7: A safety property to verify weaving between baseprogram and aspects.

for the Trigger Aspect Adverse EnvironmentStatus aspect to verify whether a notification is sentonly when environment status is adverse. A safety property(S_CONTEXT_INTERPRETER) has been defined for theContext Interpreter component to verify whetherthe refinement stage of the pervasive service is performedas expected.

In addition to performing safety analysis on individ-ual components and aspects, this research performs safetyanalysis on a woven model level to verify its behavior.Safety properties have been defined to ensure the correctweaving of the base state machines and the aspectualstate machines in the specification. For example, a safetyproperty (S_WEAVING) has been defined to ensure thecorrect weaving between the following components and as-pects in the specification: RFID Tag, Atomic ContextAspect Temperature, Atomic Context AspectPressure and Context Interpreter (Fig. 7). In thisexample, the RFID Tag and Context Interpretercomponents constitute the base program of the model.Synchronization events essentially represent the joinpointswhere a base program is woven to the aspects. Synchro-nization events provide an effective mechanism to controlthe coordination between an aspectual state machine anda base state machine. S_WEAVING property ensures thatthe ordering of the synchronization events is correct in thecomponents and aspects of the woven model, thus ensuringthe correct weaving of the components and the aspects at thejoinpoints in the specification. The S_WEAVING propertyis composed with the woven process before performinganalysis using the LTSA. Analysis of this system using theLTSA shows that there are no deadlocks or safety violations.

Mutually exclusive access to shared variables betweenthe components and the aspects have been modeled usingsemaphores in FSP. Safety properties can be createdto verify whether the mutually exclusive access to theshared variables is enforced properly. For example, theAtomic Context Aspect Temperature aspect(ACA_TEMP) and the Context Interpreter

268269259

component (CONTEXT_INTERPRETER) processesshare temperature values using the VAR_ATCI sharedvariable. In the same manner, the Atomic ContextAspect Pressure aspect (ACA_PRESS) and theCONTEXT_INTERPRETER component processes sharepressure values using the VAR_APCI shared variable. Twomutual exclusion safety properties (S_AT_CI_MUTEX_Tand S_AP_CI_MUTEX_P) have been created to ensure thatwhen a process enters the critical section that process needsto exit before another process can enter it. Although LTSAanalysis of this system shows that there are no deadlocks orsafety violations, if the value of the semaphore is changedfrom one to two then the model produces a safety violation.This is clearly a violation of the mutual exclusion propertyas two processes have entered the critical section.

B. Progress Requirements of the Study

Unlike safety properties, which are concerned witha program not reaching a bad state, liveness propertiesare concerned with a program eventually reachinga good state [6]. In the case study subset, progressproperties have been specified for the readers-writersproblem. To this end, two progress properties (P_READ,P_WRITE) have been defined to ensure that both readers(i.e. Composite Context Aspect AdverseEnvironment Status, Composite ContextAspect Route Status aspects) and writers (i.e.Context Interpreter, Context Aggregatorservice components) will eventually gain access to thelock to access the Context Database component.A progress analysis for this problem using the LTSAshows no errors. However, in order to find how the systemperforms when loaded, the action priority operator in FSPcan be used to specify adverse scheduling conditions. Inthis example, this heavy loading has been modeled bymaking the release events lower priority. Analysis ofthis system using the LTSA reveals a P_READ progressviolation (Fig. 8), which indicates that if a writer processis waiting to acquire the lock a reader process will nevergain access to it. However, this P_READ progress violationcan be disregarded as usually the number of write accessesto a database is less compared to the number of readaccesses. Thus, the importance of preserving writer priorityin acquiring the lock is clear as modeled in this example.The progress property P_REFRIG_CTRLUNIT ensuresthat the Refrigerator Control Unit component(REFRIG_CTRLUNIT) will eventually be enabled for itto receive any messages from the Recovery componentusing the synchronous message passing technique. Aprogress property (P_MOBILE_DEVICE) has been definedto ensure that the Mobile Device component willeventually receive reception for its correct operation.

Figure 8: Counterexample for P READ progress violation.

C. FLTL Requirements of the Study

In addition to safety and progress property processes,properties can be defined as state-based logical propositionsin FSP. Fluents in FSP allow the expression of propertiesabout the abstract state of a system at a particular pointin time [6]. The current study employs FLTL assertionsas a method for specifying system requirements of thecase study subset. Fluents provide several benefits over theproperty processes (i.e. safety and progress). First, fluentsprovide a more concise description of the required propertiescompared to property processes. Second, they express therequired properties more directly compared to the propertyprocesses. Third, fluents facilitate the generation of witnessexecutions to identify and locate potential errors in the spec-ification. With property processes if a property is satisfied bythe model, the LTSA does not return any further information.By contrast, FLTL properties provide the opportunity togenerate traces or examples of model execution that satisfythe property which are referred to as witness executions.

Several FLTL properties have been defined for thecase study subset. For example, two FLTL assertions(F_CI_CA_MUTEX_T, F_CI_CA_MUTEX_P) have beendefined to ensure mutually exclusive access to theshared variables (valueTempCICA, valuePressCICA)by the Context Interpreter and the ContextAggregator service components (Fig. 9). These proper-ties ensure the required mutual exclusion safety property,and an additional liveness property, which asserts that ifa process (i.e. Context Interpreter or ContextAggregator) enters the critical section that process shouldeventually exit before another process can enter. Verificationperformed for this logical property shows that there are noviolations. This research applies witness executions as ameans of identifying potential errors in the specification. AFLTL property (F_WEAVING) has been defined to verify theweaving of the base state machines and aspectual state ma-chines in the specification. The same property was definedas a safety property previously (S_WEAVING). The negationof the F_WEAVING assertion generates a counterexam-ple, which was not possible with the S_WEAVING safetyproperty process. By using counterexamples and witnessexecutions, the state models and system properties for the

269270260

Figure 9: FLTL properties to ensure mutual exclusion.

aspectual pervasive services are iteratively improved.

VII. EVALUATION FRAMEWORK

We have established an evaluation framework to validatethe main methods and tools employed in the study. Theresults are addressed in detail in [9]. The method of eval-uation used here is based on key features comparison. Theevaluation consists of a horizontal view and a vertical view(dimension) (Fig. 10). The horizontal evaluation view wasdesigned to validate several desired key features requiredmainly at the platform-specific model (PSM) level (i.e. FSP)of the aspectual pervasive software services specification.These evaluation criteria mainly cover two aspects employedin the study. They are the formal methods and tools em-ployed in the study, and the context and adaptation dimen-sions of the customization approach used in the pervasiveservices. In the vertical view, four research tools ([10],[11], [12], [13]) were compared to the Aspectual FSPGeneration tool developed in this research. Like theAspectual FSP Generation tool, these tools havebeen developed using commercially available toolchains ofsimilar area of application. The tools were compared acrossthe platform-independent model (PIM) and PSM levels ofthe model-driven architecture stack. This evaluation wasbased on several criteria: context-dependent behavioral mod-eling at the PIM level, explicit joinpoint model of aspect-oriented modeling at the PIM level, weaving performed atPIM or PSM levels, and context-dependent behavioral codegeneration from PIM to the PSM level.

The results of the evaluation are assuring. The hori-zontal evaluation of the approach has shown that the for-mal methods and tools employed in the research, and thecustomization approach used in the services are indeedeffective towards the overall objectives of this research. Thevertical evaluation has demonstrated that the AspectualFSP Generation tool has unique features in context-dependent behavioral modeling and context-dependent be-

��

��

��

��

��

��

Figure 10: Evaluation framework: vertical, horizontal views.

havioral code generation. Like the Aspectual FSPGeneration tool, [10], [12] and [13] support an ex-plicit joinpoint model of aspect-oriented modeling at PIMlevel. Also, all the compared approaches support PIM orPSM level weaving of aspects.

VIII. RELATED WORK

Douence et al. [14] propose a model for concurrentaspects which handles coordination issues between aspectsand the base program and other aspects. Their approach issimilar to our approach as both approaches use models ofconcurrently executing aspects and base state machines us-ing FSP semantics of the LTSA. In [15], the authors presentan approach to model checking state-based specification ofaspect-oriented design. However, similar to [14], their ap-proach is also not based on pervasive services. Furthermore,both these approaches do not use model transformationsin their work as done in our research. A similar approachto ours, where pervasive services have been created usingmodel-driven development is provided in [16]. However, in[16] validation of services is provided using petri nets. Also,

270271261

aspect-oriented modeling is not utilized in their approach formodularizing crosscutting context concerns.

From the analysis of related work, it is clear that thereis very little work which applies model checking to verifycontext-dependent adaptive behavior at the service inter-face level. Also, to the best of our knowledge none ofthe approaches applies the software engineering techniquesof model-driven architecture, aspect-oriented modeling andformal model checking, in the same approach. The inte-gration or the synergy of these sound software engineeringtechniques would mutually complement and augment eachother if used in a single approach. While the application ofthese techniques in isolation can be found in existing workin service engineering, however, an integrated architecture-centric solution aimed at managing the complexities associ-ated with pervasive services is novel, as performed here.

IX. CONCLUSION

This paper has explored model checking to address twochallenges in context-dependent aspect-oriented UML mod-els: the semi-formal nature of UML notations, and theexpressive power of aspects. Model checking has beenapplied for modeling aspectual pervasive software servicesand their compositions, and rigorously verifying the processbehavior of these models against specified system properties.The approach has been explored using a real-world casestudy in intelligent transport, and an evaluation frameworkhas been developed to validate the main methods and toolsemployed. While several researchers have emphasized thechallenges associated with the expressive power of aspectsin design specifications, to the best of our knowledge thereis no work that explores model checking as a solution tothe crosscutting effects of pervasive aspects at the serviceinterface level. This approach is novel in this respect. As forfuture work, the model checked pervasive software servicesspecification, which is free of erroneous behavior, can be fedinto a model-to-text transformation tool created to automatethe generation of executable service implementation.

REFERENCES

[1] H.-G. Hegering, A. Kupper, C. Linnhoff-Popien, andH. Reiser, “Management Challenges of Context-Aware Ser-vices in Ubiquitous Environments,” in Self-Managing Dis-tributed Systems, ser. Lecture Notes in Computer Science,vol. 2867. Springer Berlin / Heidelberg, 2003, pp. 321–339.

[2] N. McEachen and R. T. Alexander, “Distributing Classeswith Woven Concerns: An Exploration of Potential FaultScenarios,” in Proc. 4th International Conference on Aspect-Oriented Software Development (AOSD’05). Chicago, USA:ACM, Mar. 14–18, 2005, pp. 192–200.

[3] M. A. Perez-Toledano, A. Navasa, J. M. Murillo, andC. Canal, “TITAN: a Framework for Aspect Oriented Sys-tem Evolution,” in Proc. 2007 International Conference onSoftware Engineering Advances (ICSEA’07). Cap Esterel,France: IEEE, Aug. 25–31, 2007, pp. 23–30.

[4] D. B. Abeywickrama, “Pervasive Services Engineering forSOAs,” Ph.D. dissertation, Faculty of IT, Clayton Campus,Monash University, Australia, May 2010.

[5] E. M. Clarke, O. Grumberg, and D. A. Peled, Model Check-ing. Cambridge, UK: The MIT Press, Dec. 1999.

[6] J. Magee and J. Kramer, Concurrency: State Models and JavaPrograms, 2nd ed. John Wiley and Sons, Apr. 2006.

[7] A. Davie, “Intelligent Tagging for Transport and Logistics:The ParcelCall Approach,” Electronics & CommunicationEngineering Journal, vol. 14, no. 3, pp. 122–128, Jun. 2002,Institution of Electrical Engineers, London, UK.

[8] A. Analyti, M. Theodorakis, N. Spyratos, and P. Constan-topoulos, “Contextualization as an Independent AbstractionMechanism for Conceptual Modeling,” Information SystemsJournal, vol. 32, no. 1, pp. 24–60, Mar. 2007, Elsevier.

[9] D. B. Abeywickrama and S. Ramakrishnan, “An EvaluationFramework for Validating Aspectual Pervasive Software Ser-vices (Accepted for Publication),” in Proc. 6th InternationalConference on Evaluation of Novel Approaches to SoftwareEngineering, Beijing, China, Jun. 8–11, 2011.

[10] I. Groher and S. Schulze, “Generating Aspect Code fromUML Models,” in Proc. 3rd International Workshop onAspect-Oriented Modeling co-located with 2nd Interna-tional Conference on Aspect-Oriented Software Development(AOSD’03), Boston, USA, Mar. 18, 2003.

[11] J. Whittle and P. Jayaraman, “MATA: A Tool for Aspect-Oriented Modeling based on Graph Transformation,” in Mod-els in Software Engineering, ser. Lecture Notes in ComputerScience, vol. 5002. Springer, 2008, pp. 16–27.

[12] T. Cottenier, A. van den Berg, and T. Elrad, “MotorolaWEAVR: Aspect Orientation and Model-Driven Engineer-ing,” Journal of Object Technology, vol. 6, no. 7, pp. 51–88,Aug. 2007, Chair of Software Engineering, ETH Zurich.

[13] L. Fuentes, N. Gamez, and P. Sanchez, “Aspect-OrientedExecutable UML Models for Context-Aware Pervasive Appli-cations,” in Proc. 2008 5th International Workshop on Model-Based Methodologies for Pervasive and Embedded Software.Budapest, Hungary: IEEE, Apr. 5, 2008, pp. 34–43.

[14] R. Douence, D. L. Botlan, J. Noye, and M. Sudholt, “Concur-rent Aspects,” in Proc. 5th International Conference on Gen-erative Programming and Component Engineering. Portland,USA: ACM, Oct. 22-26, 2006, pp. 79–88.

[15] D. Xu, I. Alsmadi, and W. Xu, “Model Checking Aspect-Oriented Design Specification,” in Proc. 31st Annual Inter-national Computer Software and Applications Conference.Beijing, China: IEEE, Jul. 23-27, 2007, pp. 491–500.

[16] A. Achilleos, K. Yang, N. Georgalas, and M. Azmoodech,“Pervasive Service Creation using a Model Driven PetriNet Based Approach,” in Proc. 2008 International WirelessCommunications and Mobile Computing Conference. CreteIsland, Greece: IEEE, Aug. 6-8, 2008, pp. 309–314.

271272262

Model Checking Aspectual Pervasive Software Services

Documents

Transcript of Model Checking Aspectual Pervasive Software Services