Context-aware services engineering: Models ... - ACM Digital Library

Context-Aware Services Engineering: Models, Transformations, and Verification DHAMINDA B. ABEYWICKRAMA and SITA RAMAKRISHNAN, Monash University

Context-aware Web services are identified as an important technology to support new applications on the future Internet. Context information has several qualities that make the development of these services challenging, compared to conventional, Web services. Therefore, sound software engineering practices are needed during their development and execution. This article discusses a novel software engineering-based approach, which leverages the benefits of model-driven architecture, aspect-oriented modeling, and formal model checking, for modeling and verifying context-aware services. The approach is explored using a realworld case study in intelligent transport. An evaluation framework is established to validate the main methods and tools employed. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifications—Methodologies General Terms: Design, Verification Additional Key Words and Phrases: Aspect-oriented modeling, context-aware services, model checking, model-driven development, software architecture, software engineering ACM Reference Format: Abeywickrama, D. B., and Ramakrishnan, S. 2012. Context-aware services engineering: Models, transformations, and verification. ACM Trans. Internet Technol. 11, 3, Article 10 (January 2012), 28 pages. DOI = 10.1145/2078316.2078318 http://doi.acm.org/10.1145/2078316.2078318

1. INTRODUCTION

The Internet was introduced to exchange data between machines. Since then, society has undergone a paradigm shift, and there are opportunities enabled by new technological advances in devices [Papadimitriou 2009]. Today, the Internet has grown into a collaborative network with more than 1.5 billion users [ITU-T 2009]. To meet the demands of new applications, services, and users, the Internet is continually evolving. In general, the future Internet encompasses worldwide research activities dedicated to the further development of the Internet. There are several research areas that can be seen as components of the future Internet. Context-awareness, ubiquity (device independence, mobility, wireless support), quality of service provisioning, seamless discovery of services and content, and enhanced user control and effective delivery are identified as important requirements of the future Internet [Papadimitriou 2009]. Context-aware Web services have been identified as an important technology to support new applications on the future Internet. A context-aware Web service is a special type of service that adapts its behavior or the content it processes to the context of one or several parameters of a target entity in a transparent way (e.g. restaurant-finder D. B. Abeywickrama is currently affiliated with the University of Modena and Reggio Emilia, Italy. Authors’ address: Faculty of Information Technology, Monash University, Clayton Campus, Australia; email: [email protected]; [email protected]. Permission to make digital or hard copies of part or all 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 show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or [email protected]. c 2012 ACM 1533-5399/2012/01-ART10 $10.00 DOI 10.1145/2078316.2078318 http://doi.acm.org/10.1145/2078316.2078318 ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10

10:2

D. B. Abeywickrama and S. Ramakrishnan

services, attractions and activities recommendation services, navigation and real-time traffic services, and dating services) [Hegering et al. 2003]. With the proliferation of ubiquitous computing devices and the Internet, context-aware services continue to evolve from simple proof of concept implementations created in the laboratory to large and complex real-world services developed in industry. Context-awareness capabilities in service interfaces introduce additional challenges to software engineers. Context information is characterized by several qualities that make the development of contextaware services challenging, compared to conventional Web services, such as a highly dynamic nature, real-time requirements, quality of context information, and automation. The additional complexities associated with these special services necessitate the use of solid software engineering methodologies during their development and execution. Most state-of-the-art approaches to context-aware services relate to the detailed design or implementation stages [Mandato et al. 2002; Mostefaoui and Hirsbrunner 2004] of the software life-cycle, such as context-aware Web services. Little work focuses on the early phase of design, such as the software architectural level. This article discusses a novel approach for modeling and verifying context-aware services at the software architectural level. The approach effectively leverages benefits of several software engineering principles such as model-driven architecture, separation of concerns through aspect-oriented modeling, and formal verification using model checking, to facilitate context-aware services engineering. The approach leverages the two design abstractions—semi-formal UML metalevel extensions and formal finite state machines. This research adopts model-driven development to represent complex crosscutting, context-dependent functionality in service interfaces in a modular manner, and to automate the generation of state machine-based adaptive behavior. The crosscutting context-dependent information of the interacting pervasive services is modeled as aspect-oriented models in UML. Using automated model transformations, we ensure the correct separation of concerns of the crosscutting context-dependent functionality at both semi-formal UML modeling and formal behavioral specification levels. A prototype tool—Aspectual FSP Generation—applying an effective pipeline of model-to-model and model-to-text transformations has been built. The generated context-dependent adaptive behavior and the core service behavior for the pervasive services are rigorously verified using formal model checking against specified system properties. Model checking is applied, first to check the behavior of the individual pervasive aspects and components, and second, to verify the overall behavior of the woven model, even if no errors are found in the individual pervasive aspects and components. More than 30 properties have been formalized to provide a comprehensive coverage of the system requirements. These verification stages can be used to gain confidence before the complex pervasive services are actually implemented. The approach is explored using a real-world case study in intelligent transport. An evaluation framework is established to validate the prototype tool developed, the context and adaptation dimensions of the customization approach used in the services, and the formal methods employed in this study. Preliminary results of our research were published in Abeywickrama and Ramakrishnan [2008a, 2008b, and 2010]. This article sequentially discusses our overall pervasive service engineering process covering four major areas: software engineering process, models and transformations, verification activities, and evaluation framework. Section 2 presents a brief analysis of the related work and establishes the motivation for the current study. The case study, the notion of context, and the main tools and techniques used in this study are described in Section 3. In Section 4, a highlevel description of the methodology proposed for engineering context-aware services is provided. Section 5 (models and transformations) and Section 6 (verification using model checking) address this process in detail. An evaluation framework to validate the ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

Context-Aware Services Engineering: Models, Transformations, and Verification

10:3

main methods and tools used is established in Section 7, and Section 8 concludes the article. 2. RELATED WORK AND MOTIVATION

The motivation and rationale for an integrated architecture-centric approach for engineering context-aware services is addressed in this section. This research relates to multiple research areas of existing literature such as model-driven architecture, aspect-oriented modeling, and model checking. ContextUML metamodel [Sheng and Benatallah 2005] is an UML-based modeling language proposed for model-driven development of context-aware Web services. Sheng and Benatallah demonstrate how UML can be used to specify information related to the design of context-aware services in which context-handling information is separated from the core service logic at the service interface level. However, there are two main differences between their approach and the approach of this research. First, they have taken no account of concurrency and distributed notions in their design or any formal verification aspects through techniques, such as model checking. Second, there is no application of aspect-oriented modeling in their profile, as in the approach of this research. Aspect-oriented modeling (AOM) is an aspect-oriented software development extension applied to the early stages of the software life-cycle, which supports separation of concerns at the modeling level. The PLASTIC initiative [Autili et al. 2009] describes a development process model for self-adapting context-aware services that relies on model-based solutions. Autili et al. provide methodologies to generate qualityof-service models and adaptable code from UML service models, which are supported by an integrated framework based on a UML profile. Like the present study, in general their framework adheres to the model-driven development approach. However, they have not applied aspect-oriented modeling or any concrete formal verification methods such as model checking in their work. Douence et al. [2006] propose a model for concurrent aspects which handles coordination issues between aspects and the base program and other aspects. Their approach is similar to our approach as both approaches use models of concurrently executing aspects and base state machines using Finite State Processes (FSP) semantics of the Labeled Transition System Analyzer (LTSA). However, the present research is significantly different as it is based on pervasive services and extensively adopts model-driven development for modularizing and generating context-dependent adaptive behavior. In Xu et al. [2007], the authors present an approach for model checking state-based specifications of aspect-oriented design. However, similar to Douence et al., their approach is not based on pervasive services. Furthermore, both these approaches do not use model transformations in their work, as performed in the current study. Colombo et al. [2005] discuss an approach in which model checking is used to verify context-aware composition of services during the requirements engineering process. However, their approach is based on the SPIN model checker and the Promela language. The authors have not used aspect-orientation to decouple contextual information, as in the current study. Also, their approach is not based on model-driven development. A similar approach to ours, where pervasive services have been created using model-driven development, is provided in Achilleos et al. [2008]. However, their validation of services is provided using petri nets. Model transformations have been employed to generate source code and not behavioral code at the architectural level, as in the current study. Also, aspect-oriented modeling is not utilized in their approach for modularizing complex crosscutting context concerns, as in the present research. Previous approaches to the development of context-aware services have largely been at the detailed design or implementation stages [Mandato et al. 2002; Mostefaoui and Hirsbrunner 2004] of the software life-cycle. Mandato et al. present their modular ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:4


Fig. 1. Research objectives.

Internet portal enhanced with context-awareness features called CAMP, which is based on JDK 1.2, XML/XSLT, Java Servlets, and Java Server Pages technologies. Mostefaoui and Hirsbrunner discuss a generic approach that integrates context-aware computing and Web services in order to provide more tailored composite services in pervasive computing environments. To this effect, a proof-of-concept tool has been implemented called the Context-based Smart Reminder, which uses Sun’s Java Web Services Developer Pack 1.2 for building, testing, and deploying the context-aware services. However, the approach taken in the current research is clearly distinctive from the approaches just discussed as it is based at the software architectural level. Two main limitations can be identified from this survey on state-of-the-art approaches on context-aware services development. First, most existing approaches to representing context-aware services focus on the detailed design or implementation phases of the software life-cycle, such as context-aware Web services. Little attention has been given to the early phase of design, such as the software architectural level. Building software architectural models of pervasive services provides engineers with a better understanding of how these complex services interoperate and helps uncover any errors during the early stages of the software life-cycle. Second, most of the existing work applies the software engineering techniques of model-driven architecture, aspect-oriented modeling, and formal model checking in isolation, and does not explore the combination of these technologies in the same approach. For example, Sheng and Benatallah [2005] have taken no account of any formal verification aspects through techniques, such as model checking, nor have they applied aspect-oriented modeling in their UML profile. The integration or the synergy of these sound software engineering techniques would mutually complement and augment each other if used in a single approach. While the application of these techniques in isolation can be found in existing work in service engineering, an integrated architecture-centric solution illustrated in Figure 1, aimed at managing the complexities associated with context-aware services is novel, as proposed in this article. 3. PRELIMINARIES

This section describes the case study and reference scenario, the notion of context, and the main tools and techniques used in this study. 3.1. Case Study and Reference Scenario

The research approach is explored using a real-world case study in intelligent tagging for transport known as the ParcelCall project [Davie 2002]. ParcelCall is a European Union project within the Information Society Technologies program. The case study describes a scalable, real-time, intelligent, end-to-end tracking and tracing system using radio frequency identification (RFID), sensor networks, and services for transport ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:5

Fig. 2. Case study system architecture.

and logistics. This case study is particularly appealing to the current research as it provides several scenarios for representing software services that interoperate in a pervasive, mobile, and distributed environment. The system architecture of ParcelCall consists of four main components, shown in Figure 2: RFID tags, the Mobile Logistic Server (MLS), the Goods Tracing Server (GTS), and the Goods Information Server (GIS) [Davie 2002]. Each transport item in the truck or container is identified by a RFID tag developed by the ParcelCall project. RFID tags are used for item-level identification and provide seamless end-to-end surveillance of status, location, and environmental data, such as temperature, pressure, acceleration, humidity, and shock. The MLS is an onboard computer that keeps track of transport items within the transport unit. By using a combination of public and wireless data communication networks, the MLS relays information about the transport items to a network of GTSs at different locations. The GIS acts as a gateway between the GTS systems and a large number of mobile and fixed end-user devices, such as mobile phones, PDAs, or PCs. A significant subset of the ParcelCall case study is exception handling that needs to be enforced when a transport item’s context information violates acceptable threshold values. The current study is focused on this subset. The reference scenario used in this research describes an awareness monitoring and notification pervasive service, which alerts with regards to any exceptional situations that may arise on transport items, primarily to the vehicle driver of the transport unit. The threshold values for environment status (e.g., temperature, pressure, acceleration) of transport items and route (location) for the vehicle are set by the carrier organization in advance. The service alerts if items’ environment status exceeds acceptable levels or if an item is lost or stolen during transport. The primary context parameters modeled in the study include item identity, location, temperature, pressure, and acceleration. Figure 3 illustrates a process-oriented context value chain derived for the awareness monitoring and notification pervasive service. In the context value chain, the context information of the items in transport is gathered mainly using the sensors of the RFID tags and the Global Positioning System (GPS). The step involved in capturing data from these context sources is called sensing. However, sensing only provides the raw material of context, which is referred to as low-level context information. This information is often not used by the requesting pervasive service as it is not interpretable. Therefore, one or more steps of refinement need to be performed to derive more meaningful high-level context information, as required by the pervasive service. Refinement can be performed using several methods, such as transformation between different formats of representation, the extension of context information with attributes, or the ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:6


Fig. 3. Context value chain for the pervasive service.

combination of context information to derive another context. In this study, this refinement can be, for example, interpreting temperature and pressure readings as “cool” and “low”. Another example can be formalization of the current street address of the transport items using GPS coordinates. After refinement, all the required context information of a particular entity that is important for a particular pervasive service needs to be allocated (aggregation) (Figure 3). Finally, the aggregated context is used to contextualize the service. In the case study subset, the pervasive service is used to alert any exception-handling situations on the transport items primarily to the vehicle driver, and any recovery operations that can follow, such as controlling the refrigerator’s temperature. A value chain may comprise, several sequences of the sensing, refinement, aggregation, and contextualization steps. The current research identifies a software service as the interaction pattern or the ¨ interplay of several components collaborating to complete a desired task [Kruger et al. 2006]. Furthermore, services are identified as first-class modeling elements, as opposed to first-class implementation elements, such as Web services. The service specification derived for the case study subset has several software services interacting with each other, such as interpret context, aggregate context, update database, observe events, broadcast, recovery, and awareness monitoring and notification pervasive service (composed service). 3.2. Notion of Context

The notion of context used in this article is based on a definition provided by Analyti et al. [2007] for context in information modeling. They describe context as a set of objects—each of which is associated with a set of names—and another context called its reference. Furthermore, the authors enhance the definition for context by stating that each object of a context is either a simple object or a link object (attribute, instanceof, ISA) and each object can be related to other objects through attribute, instance-of, or ISA links. The authors use traditional object-oriented abstraction mechanisms of attribution, classification, generalization, and encapsulation to structure the contents of a context. Next, an example is discussed regarding the application of the context definition used in this study to the reference scenario, illustrated in Figure 4. Assume that a context has been defined to represent the adverse environment status of the transport items in the case study subset (Figure 4(a)). This context is represented by the context identifier c0 and it is associated with the name isAdverseStatus. Adverse environment status is derived using temperature and pressure information of the transport items. Temperature information is represented using the object identifier o1 and is associated with the name “temperature”. However, object o1 is a higher-level object ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:7

Fig. 4. Context structures for environmental status and route status.

that collectively represents all temperature information. Object o1 collectively represents the contents of context c2. In other words, in order to see what o1 means at a finer level of detail, the contents of c2 needs to be looked into. Therefore, context c2 is called the reference of object o1. The notion of reference provides encapsulation of information, thus improving modularity. The temperature and pressure information can be grouped to form the context c1. In a similar manner, the construction of the contexts co, c1, and c4 of Figure 4(b) can be explained. This definition can be applied to structure the objects of a context using the notions of attribution, classification, and generalization. For example, in context c1 of Figure 4(b), location is represented by the object o3. More information about location can be found in context c4, which contains information about Country, Area, City, and Address. Country, Area, City, and Address are represented by the objects o14, o15, o16, and o17 respectively. These objects are of type String. The fact that a location has an address is represented by object o24. An individual City is represented by object o19, which is associated with the name “Melbourne”. Object o19 is an instance of City. In a similar manner, the contents of contexts c2 and c3 of Figure 4(a) can be described. 3.3. Tools and Techniques

The current approach particularly is based on the model-driven development techniques provided by the IBM Rational Software Architect [DeCarlo et al. 2008], the formal verification techniques provided by the model checker LTSA [Magee and Kramer 2006] and its process calculus FSP, and the LTSA tool’s message-sequence charts extension (LTSA-MSC). This research applies both model-to-model and model-to-text transformations to automate the translation of aspect-oriented models in UML into textual FSP. Java Emitter Templates (JET) is an opensource technology developed by IBM, which is typically used in the implementation of a code generator. 4. ADAPTIVE-BEHAVIOR GENERATION: SOFTWARE ENGINEERING PROCESS

In this section, we discuss the software engineering process followed for generating context-dependent adaptive behavior for pervasive services, shown in Figure 5 ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:8


Fig. 5. Adaptive-behavior generation: software engineering process.

[Abeywickrama and Ramakrishnan 2010]. Section 5 (models and transformations) and Section 6 (verification) address this process in detail. The model transformation tool created in this study for adaptive-behavior generation is called the Aspectual FSP Generation tool. The crosscutting context-dependent information of the interacting pervasive services is modeled as aspect-oriented models in UML (contextual-FSP aspects or c-FSP aspects). We use model transformations to automate the application of design patterns and generate infrastructure code for the c-FSP aspects using FSP semantics. The current study explores the strengths of both semi-formal UML metalevel extensions and formal finite state machines for representing the context-dependent behavior of software services; model transformation techniques are applied as a bridge to enforce correct separation of concerns between these two design abstractions. The main benefits of this approach are improving the quality and productivity of service development; easing system maintenance and evolution; and increasing the portability of the service design for the pervasive services engineer. This approach focuses on the application of model-driven development for engineering pervasive services at finite state machine level. An aspect in FSP can be identified as an independent finite state machine that executes concurrently and synchronizes with its base state machine. In general, an aspect in FSP needs to contain synchronization events (transitions) to coordinate with its base state machine and other aspects. Also, each aspect type (e.g. context, trigger, and recovery) contains its unique constructs which can be generated automatically using model transformation techniques. For example, a trigger aspect requires constructs to alert and send notifications, while a recovery aspect needs constructs to recover from exception-handling situations. On the other hand, a context aspect has attribution, instance-of, ISA, and reference constructs from the notion of context applied in this research. In Figure 5, the models and activities of the engineering process are represented as ellipses and square boxes, respectively. The engineering process is structured into three main flows of activities. Flow 1 and Flow 2 extensively apply model transformations: Flow 1 uses a model-to-text JET transformation and Flow 2 applies an effective pipeline of model-to-model and model-to-text JET transformations. Both Flow 1 and Flow 2 originate from the c-FSP-UML profile. Flow 3 represents activities involved for rigorously verifying the context-dependent adaptive behavior and the core service behavior of the pervasive services, using formal model checking. We present a custom UML profile referred to as the c-FSP-UML profile to decouple crosscutting contextdependent information of a service from the core service behavior at service interface level. The profile effectively describes our conceptual model for context-dependent ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:9

Fig. 6. c-FSP-UML profile.

adaptive behavior using the aspect-oriented modeling paradigm. Using the profile we derive a UML model template and a UML class model to be used in the transformations, which are elaborated upon in Section 5.1. Two variations of the Aspectual FSP Generation tool have been built, which are represented using Flow 1 and Flow 2 in Figure 5. Initially, a model-to-text JET transformation (Flow 1) was implemented with XPath expressions to navigate the UML class model for the c-FSP aspects and extract model information dynamically to the transformation. However, JET’s support for UML models has several limitations. Therefore, a more effective solution was implemented, as shown by Flow 2, which contains an effective pipeline of model-to-model and model-to-text JET transformations. In this solution, we first create a model-to-model mapping transformation which extracts relevant information from the UML model elements and stereotypes, and builds a codegenerator specific intermediate Eclipse Modeling Framework (EMF) model which only contains information required for the back-end model-to-text JET transformation. The details of this transformation and its benefits are discussed in Section 5.2. Flow 3 contains activities for rigorously verifying the models generated for the core service behavior and the context-dependent adaptive behavior using formal model checking, which is addressed in Section 6. 5. MODELS AND TRANSFORMATIONS 5.1. c-FSP-UML Profile and c-FSP Aspects

This section elaborates on the c-FSP-UML profile, illustrated in Figure 6, and the UML class model created with c-FSP aspects to modularize the service architecture [Abeywickrama and Ramakrishnan 2010], shown in Figure 7. Using the c-FSP-UML profile, we model the core service logic and the context-dependent behavior of a service as two separate concerns within the same model, allowing the modification of the context-dependent behavior without affecting the main functionality. The core service logic of a service is represented by the State, Transition, FiniteStateProcess, Service, and ServiceSpecification classes while the rest of the classes represent the context-dependent functionality. The c-FSP-UML profile encompasses constructs of both aspect-orientation and object-orientation aimed at modularizing and reducing the complexity of context-dependent behavior at the service interface level. The use of aspect-oriented modeling in the profile further extends the UML model [Abeywickrama ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:10


Fig. 7. UML class model derived from the profile with c-FSP aspects.

and Ramakrishnan 2008a] created previously, which was originally motivated by the ContextUML metamodel. After creating the c-FSP-UML profile, a UML model template and a UML class model are derived based on the profile for the pervasive software services. The UML model template created provides textual advice on applying the profile and deriving an aspect-oriented UML class model from the profile to the pervasive services engineer, thus simplifying the task at hand. Also, the template is used to specify any architecturally significant structures that need to be included in the class models created using this template. For example, the profile and the stereotypes that are applied to the UML model template are enforced automatically when a class model is created using the template. The aspect-oriented UML class model, in Figure 7 contains several classes on the case study with stereotypes applied from the c-FSP-UML profile. As in the profile, this UML class model contains several constructs for representing the core service behavior, the context-dependent adaptive behavior, and the dependencies between the core service model and the contextdependent model. The core service behavior of the model is represented by classes such as, ParcelCall, InterpretContext, Broadcast, Recovery, ObserveEvents, the FiniteStateProcess classes, and the Transition classes. The c-FSP aspects of the UML class model are represented by several classes, such as Temperature, Pressure, IsAdverseStatus, AdverseStatusTrigger, and AdverseStatusRecovery. The different constructs of the profile and the UML class model are described next with examples from the case study. —Aspect class encapsulates several advices and pointcuts. The Advice specifies the crosscutting behavior of the aspect while the Pointcut encapsulates a set of joinpoints. A joinpoint is the location (transition) where the crosscutting behavior emerges in the service model. Three types of c-FSP aspects are identified: context, trigger, and recovery. —Two types of context aspects are identified: atomic and composite. AtomicContextAspect class models low-level context readings from the context sources (e.g. Location or Temperature in Figure 7) while CompositeContextAspect class encapsulates high-level derived context information (e.g. IsAdverseStatus or ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:11

RouteStatus). Also, the notions of attribution, classification, generalization, and encapsulation from the context definition are applied to structure and link the objects defined in the aspects. Thus, both object-oriented and aspect-oriented notions are used to represent the complex context-dependent functionality of the services. —ContextSource class represents the resource from which context information is obtained, for example, RFID Tag or GPS. —The TriggerAspect class models the contextual adaptation where the service is automatically executed or modified, based on context information. For example, if isAdverseStatus is true then send an SMS to vehicle driver (AdverseStatusTrigger). —The RecoveryAspect class models recovery actions that follow after an exception situation is raised by the trigger aspect. For example, control the refrigerator’s temperature in the vehicle unit (“AdverseStatusRecovery” in Figure 7). The execution of this aspect is dependent on the existence of the trigger aspect. —Dependency Relationships classes essentially associate the core service classes (service elements of the profile) with the context elements of the profile, or the context elements with their respective context sources. There are three types of dependency relationships. SourceAssignment associates the context attributes of a ContextAspect class with their respective context sources, which provides values for these attributes. For example, the SourceAssignment relationship associates the Location aspect and the GPS, which provides GPS coordinates to the aspect. ContextBinding models the automatic binding of service elements with context attributes of the ContextAspect class. ContextTriggering provides an association between service elements and triggering operations that may affect the service elements, depending on context. In the case study, this can be, for example, the association between the NewRoute transition of the core service model and the RouteStatusRecovery aspect of the context model. Both ContextBinding and ContextTriggering dependency relationships essentially represent the binding of an aspect to its base class. —Precedence Relationships classes explicitly specify how aspect precedence can be enforced at the modeling level to reduce the aspect-interference problem. There are two types of precedence relationships. Precedes is used to indicate the precedence order for the aspects at a single joinpoint, while DependentOn is used to specify that an aspect will only be matched on the existence of both aspects at the joinpoint. For example, as shown in Figure 7, the AdverseStatusRecovery aspect is executed following the AdverseStatusTrigger aspect (Precedes), and the existence of both these aspects are required at the joinpoint (DependentOn).

5.2. Transformations

The previous subsection discussed the c-FSP-UML profile and aspect-oriented models in UML (c-FSP aspects) derived to modularize the service architecture. The current subsection provides the model transformations created to automate the transformation of those UML models to formal behavioral specifications in FSP. This multi-stage transformation chain describes an effective pipeline of model-to-model and model-to-text JET transformations (Figure 5, Flow 2) [Abeywickrama and Ramakrishnan 2010]. In this solution, first a model-to-model mapping transformation is created which extracts relevant information from the UML model elements and stereotypes, and then a code generator-specific EMF intermediate model is built which contains only information required for the back-end model-to-text JET transformation. The frontend model-tomodel transformation automatically invokes the back-end JET transformation, with the following benefits. ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:12


—As the JET transformation is independent of UML, UML expertise is no longer a requirement for the transformations [DeCarlo et al. 2008]. This effective multi-stage transformation approach permits the development and validation of pattern implementations independent of any complexities associated with the UML metamodel. —The JET transformation can be automatically invoked by the front-end model-tomodel transformation. Therefore, the software engineer does not have to see or be aware of the back-end JET transformation. These factors can make the pattern-implementation process a more accessible solution to the software engineer. As a result, this multi-stage transformation approach has been employed in the current research to transform the c-FSP aspects into formal FSP code. The transformation chain created has several steps. —Build an Intermediate EMF Model. In this study, an EMF project is created as the intermediate model to be used in the transformations. The intermediate model can be based on EMF or XML. However, EMF has a rich metamodel, and with EMF a Java API for the model can be generated. —Build a UML Profile. The c-FSP-UML profile discussed earlier is used to augment the standard UML with information that is necessary for generation of aspects in FSP. This profile defines stereotypes identifying core service elements, context-dependent information, and dependencies for the pervasive software services. Stereotypes provide an efficient mechanism for extending the information that is stored on UML model elements. As any changes to the stereotypes in the profile affect the underlying UML model elements, it is important to track the profile version. To this effect, the c-FSP-UML profile is released. The profile can be distributed by creating an Eclipse plug-in that publishes the profile. To this end, the existing c-FSP-UML profile project is converted into a plug-in project. By publishing the profile as an Eclipse plug-in, any Eclipse-based product that installs this plug-in has access to the c-FSP-UML profile and its stereotypes. —Build a Model-to-Model Mapping Transformation. After creating the c-FSP-UML profile and the intermediate EMF model, next we create a model-to-model mapping transformation (aspectsFrontendMap) that effectively maps the profile-applied UML class model for the c-FSP aspects with the EMF intermediate model. This mapping transformation essentially associates elements of the input model (UML class model with the c-FSP aspects) with elements of the output model, which is the EMF intermediate model (aspectsEMFModel). To this end, several types of maps have been created. A map defines how data from an input type (e.g. a UML class) are copied to an output model type (e.g. an aspect). A map can move data from a source element to a target element using three methods: move transformations, custom transformations, and submap transformations. This study uses a combination of move and submap transformations to associate elements of the UML class model created for c-FSP aspects with the elements of the EMF intermediate model (aspectsEMFModel). In this study, the following maps have been created: (i) UML Model elements to Root elements; (ii) UML Package elements to AspectPackage elements; (iii) UML Class elements to Aspect elements; (iv) UML Operation elements to aspect’s Operation elements; and (v) UML Property elements to aspect’s Property elements. The back-end JET transformation accepts an XML model as input. After creating the mappings, the transformation source code is generated and customized to invoke the back-end model-to-text JET transformation automatically from the front-end, model-to-model transformation. To link the model-to-model transformation’s output to the back-end, model-to-text JET transformation, the TransformationProvider Java file needs to be edited with the ID of the transformation to invoke. ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:13

—Debug and Test. Finally, we test the transformations created to verify that they are correct and function as required. This involves setting up a test environment in which the plug-ins created are installed. A test configuration of this nature is referred to as a runtime workbench. Testing using a runtime workbench effectively launches a second copy of the Eclipse-based product. Testing the transformations involves building the UML class model with c-FSP aspects and applying the c-FSP-UML profile to it; then creating a transformation configuration and executing the transformation configuration. In the transformations created in this study, the aspect name in UML becomes the process (state machine) name in FSP, while operations and properties for the aspect in UML are used for generating states and transitions of the aspectual state machine in FSP. This represents the variable nature (point of variability) of the transformations. Other than that, as stated previously, the transformations generate infrastructure (skeleton) code for the aspects. Next, the generated context-dependent adaptive behavior and the core service behavior for the pervasive services are rigorously verified using formal model checking against specified system properties. This process is discussed in the next section. 6. VERIFICATION USING MODEL CHECKING

As discussed in Section 5.1, the crosscutting context-dependent behavior in service interfaces has been modeled using aspect-oriented UML models. To this effect, a custom UML profile (c-FSP-UML profile), a UML model template and UML class models (c-FSP aspects) have been created to modularize context information with several stereotypes representing the core service behavior, the context-dependent behavior, and the context dependencies. UML has been a widely applied technique for modeling object-oriented design or core design of a software specification. Also, exploring the metalevel notation of UML or extending the UML notation has been a popular approach used by many researchers for specifying crosscutting concerns. However, as applied in the approach of this research, one of the main limitations of UML is its lack of support for rigorous verification, due to its informal or semiformal nature. The expressive power of aspects in design specifications can be potentially harmful. The crosscutting nature and the obliviousness principle of aspects are two main issues that can introduce an additional correctness problem in an aspect-oriented design specification. The crosscutting nature of aspects creates the potential for aspects-to-aspects and aspects-to-components interactions [Pang and Blair 2002]. As a consequence, any resulting property violations can be subtle, making their identification difficult. The behavioral modifications by aspects can cut across the entire system or model. As a result, it is very difficult to understand an aspect-oriented design in a modular manner [Xu et al. 2004]. Obliviousness and quantification are desirable principles in the aspect-oriented paradigm. Obliviousness implies that the core or base system has no knowledge of what aspects modify it, where or when. Obliviousness is clearly important in dynamically adaptive systems in which aspects are not even considered when the original system was created. However, pure obliviousness can be potentially harmful, as aspects can inadvertently or maliciously invalidate the behavior of the core system [Perez-Toledano et al. 2007]. In general, the crosscutting effect and oblivious principle of aspects can create several problems or risks, such as partial weaving, unknown aspect assumptions, unintended aspect effects, arbitrary aspect precedence, failure to preserve state invariants, and incorrect changes in control dependencies [McEachen and Alexander 2005; Perez-Toledano et al. 2007]. In summary, the main challenges associated with aspect-oriented modeling in software specifications are twofold: the informal or semiformal nature of UML notations, and the expressive power of aspects, ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:14


Fig. 8. Model checking aspectual pervasive software services.

which can be potentially harmful. Therefore, tool support automatic if possible, (e.g. model checking) is highly desirable to ensure the correctness of the specification. 6.1. Model Checking Aspectual Pervasive Software Services

In this subsection, we provide an overview of our approach for rigorously verifying the models generated for the context-dependent adaptive behavior and the core service behavior, using formal model checking [Abeywickrama 2010]. This is shown by Flow 3 in Figure 5, and further elaborated on in Figure 8. The model-checking process can be divided into three main tasks: modeling, specification, and verification. Modeling is the task of converting the design into a formalism accepted by a model-checking tool [Clarke et al. 1999]. Specification is the stating of the properties that the design needs to satisfy, and verification is the actual validation of the models. The modeling stage is discussed in Sections 6.2 and 6.3, while properties specification and verification stages are addressed in Section 6.4. —Modeling. The modeling step involves two main tasks that, are performed to obtain the context-dependent adaptive behavior and the core service model of the software services. In this study, the Aspectual FSP Generation tool is used to generate the context-dependent behavioral code in formal FSP (Figure 5). The LTSA-MSC tool is used to generate the architecture model for the service specification in FSP, which is used to extract the core service model of the services (Figure 5; Figure 8). All service components and aspects are modeled as processes represented as finite state machines in FSP. To verify the pervasive service specification, first the aspects are woven into their base state machines in FSP using an explicit weaving mechanism. Then concurrency and distributed notions are added to the service specification to facilitate reasoning by the LTSA tool. Abstraction mechanisms are introduced to reduce the size of the woven model. —Specification. Properties provide a way of formalizing and verifying system requirements. Here the properties focus on the required effects of the pervasive aspects, service components, and the woven model. Rigorous modeling and specification of properties are very important to identify any defects (property violations) in the pervasive services, early in the software life-cycle before these complex services are actually implemented. Although there can be a modeling overhead, it is essential ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:15

to assure the correctness and quality of the pervasive services design. According to the system requirements from the case study subset, more than 30 properties have been formalized focusing on the required behavior from both service components and aspects in the entire specification. These properties have been expressed as property processes (safety and progress) and fluent linear temporal logic (FLTL) assertions. —Verification. Finally, all behavior and property processes are composed into a systemlevel process, and this process is fed to the LTSA. The LTSA verifies whether any properties are violated, and if so, it reports a trace to the property violation known as a counterexample. Also, the use of FLTL assertions provides the opportunity to generate examples of traces (witness executions), which satisfy the property. The use of counterexamples and witness executions is exploited to identify and track any errors and their sources in the specification, which consists of several distributed service components and aspects collaborating with each other. Thus, this helps to iteratively improve the state models or the system properties for the aspectual pervasive software services (Figure 8). 6.2. Pervasive Service Composition through Weaving

Weaving of an aspect to its base state machine is important in order to analyze the overall system behavior. An explicit weaving mechanism is used here, where an aspect is woven into its base state machine using the parallel composition operator and shared actions in FSP. The main elements of the weaving process are the base program and an aspectual state machine (aspect). In general, the base program is not a single process but a combination of several processes. A base program (core service model) is specified as the parallel composition of the constituent base state machines in the model. In order to support explicit parallel composition, the current study injects synchronization events in both the aspectual state machine and the base state machine, providing an effective mechanism to control the coordination between the two. The advice of an aspect contains three logical parts: before advice events, proceed events, and after advice events. By using synchronization events, the correct execution of these three sequences of actions with the base program can be ensured. Also, weaving of more than one aspect at the same joinpoint is possible using these explicit synchronization events. The crosscutting elements of the joinpoint model and the weaving process followed are discussed next using a case study example. Figure 9(a) shows LTSs for three processes. The RFID Tag (RFID TAG) and the Context Interpreter (CONTEXT INTERPRETER) components are the base state machines while the Atomic Context Aspect Temperature (ACA TEMP) is an aspectual state machine. The joinpoints of the base program are specified using the following synchronization events: bf a (before advice), pr s (proceed start), pr e (proceed end), af a (after advice). A pointcut is a sequence of joinpoints; thus, the sequence of bf a, pr s, pr e, and af a constitutes the pointcut for this aspect. The execution and coordination of the base program and the aspect can be explained using Figure 9(b). The base program (RFID TAG) emits the bf a event to the 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 base program performs the measureTemperature event and then emits pr e to return the control back to the aspect. The aspect performs receiving-of-temperature readings using message passing, which is its after-advice events. Finally, the base program (CONTEXT INTERPRETER) waits for the end-of-advice event (af a) from the aspect, and performs the storeContextInformation action. The woven program is modeled as the parallel composition of the base state machines and the aspect. ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:16


Fig. 9. Weaving performed.

6.3. Concurrency Modeling between Pervasive Aspects and Components

After weaving aspects into their base state machines, the concurrency and distributed notions of the interacting pervasive software services are modeled to facilitate reasoning by the LTSA tool, such as message passing, shared objects, and mutual exclusion, as shown in Figure 10. This subsection describes these notions for the case study subset. The pervasive service specification includes several distributed service components and aspects collaborating with each other. These components and aspects encompass the active entities of the specification. It also includes shared objects and semaphores, which act as passive entities. All active and passive entities of the specification have been modeled as processes represented as finite state machines in FSP. In the specification, concurrency has been modeled using action interleaving. Actions a and b are concurrent if they can occur in the order of a -> b or b -> a. This study models the awareness monitoring and notification service as a process-oriented context value chain. This value chain contains several stages: sensing, refinement, aggregation, and contextualization. The context procurement and contextualization tasks of the pervasive service are driven by the c-FSP aspects. The communication between the distributed service components and aspects (e.g. between RFID Tag and Atomic Context Aspect Temperature) has been modeled using the synchronous message-passing technique. The environmental readings (e.g. temperature, pressure) from the RFID Tag are sent using a single channel to the receiver (e.g. Atomic Context Aspect Temperature, Atomic Context Aspect Pressure) and the communication is one-to-one. In addition to using the message-passing technique, shared objects have been used to model interprocess communication between the service components and the aspects. The problem of interference has been solved by enforcing mutually exclusive access to the shared objects. This has been modeled using binary semaphores, which is a mechanism for dealing with interprocess synchronization problems. For example, the Atomic Context Aspect Temperature aspect and the Context Interpreter ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:17

Fig. 10. Concurrency modeling between pervasive aspects and components.

component interact using a shared object for communicating temperature values used in the refinement stage of the context value chain of the pervasive service. The mutually exclusive access to this shared object has been enforced using a semaphore, thus only one process can access it at a given time. The Context Database process has been modeled as a shared resource where the Context Interpreter and the Context Aggregator service components write to it (writers), and the Composite Context Aspect Route Status and the Composite Context Aspect Adverse Environment Status aspects read from it (readers). This scenario has been modeled as a readers-writers problem with writers having priority. The readers are denied access if there are writers waiting to acquire access, and if a writer is not accessing the database, any number of readers can access the database concurrently. Abstraction Mechanisms applied in the models. These are needed as a woven program may have too many states to be analyzed by the LTSA. One of the main challenges associated with the model checking technique is the state space-explosion problem. In the present study, action-hiding and minimization features available in FSP are used to reduce the size of the woven model before analyzing using the LTSA tool. For example, ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:18


Fig. 11. A safety property to verify weaving between base program and aspects.

the actions or events modeled in the Context Interpreter and Context Aggregator components for enforcing mutually exclusive access to their shared variables are not required when modeling the readers-writers problem with writers’ priority, which involves the same components collaborating with aspects. Also, when executing the entire specification model, the partial-order reduction feature has been used to reduce the size of the state space searched by the LTSA model checker. 6.4. Properties Specification and Verification of Aspectual Pervasive Software Services

Having discussed the modeling stage of the model-checking process applied in the research, the properties specification and verification stages are addressed next. This discussion is broadly categorized into safety, progress, and FLTL requirements of this study. 6.4.1. Safety Requirements of the Study. Safety properties are used in a concurrent program to assert that nothing bad happens during the execution of the program [Magee and Kramer 2006]. In the case study subset, several safety properties have been specified for verifying the behavior of the individual aspects and their components, and the behavior of a woven model. As for safety properties defined at the individual components and aspects level, a safety property (S TA ADENST) has been defined for the Trigger Aspect Adverse Environment Status aspect to verify whether a notification is sent only when environment status is adverse. A safety property (S CONTEXT INTERPRETER) has been defined for the Context Interpreter component to verify whether the refinement stage of the pervasive service is performed as expected. In addition to performing safety analysis on individual components and aspects, this research performs safety analysis on a woven-model level to verify its behavior. Safety properties have been defined to ensure the correct weaving of the base state machines and the aspectual state machines. For example, a safety property (S WEAVING), shown in Figure 11, has been defined to ensure the correct weaving between the following components and aspects in the specification: RFID Tag, Atomic Context Aspect Temperature, Atomic Context Aspect Pressure, and Context Interpreter. In this example, the RFID Tag and Context Interpreter components constitute the base program of the model. Synchronization events essentially represent the joinpoints where a base program is woven to the aspects. Synchronization events provide an effective mechanism to control the coordination between an aspectual state machine and a base state machine. S WEAVING property ensures that the ordering of the synchronization events is correct in the components and aspects of the woven model, thus ensuring the correct ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:19

Fig. 12. Counterexample trace for the P READ progress violation.

weaving of the components and the aspects at the joinpoints. The S WEAVING property is composed with the woven process before performing analysis using the LTSA. Analysis of this system using the LTSA shows that there are no deadlocks or safety violations. Mutually exclusive access to shared variables between the components and the aspects have been modeled using semaphores in FSP. Safety properties can be created to verify whether the mutually exclusive access to the shared variables is enforced properly. For example, the Atomic Context Aspect Temperature aspect (ACA TEMP) and the Context Interpreter component (CONTEXT INTERPRETER) processes share temperature values using the VAR ATCI shared variable. In the same manner, the Atomic Context Aspect Pressure aspect (ACA PRESS) and the Context Interpreter component processes share pressure values using the VAR APCI shared variable. Two mutual-exclusion safety properties (S AT CI MUTEX T and S AP CI MUTEX P) have been created to ensure that when a process enters the critical section, that process needs to exit before another process can enter it. Although LTSA analysis of this system shows that there are no deadlocks or safety violations, if the value of the semaphore is changed from one to two then, the model produces a safety violation. This is clearly a violation of the mutual exclusion property, as two processes have entered the critical section. 6.4.2. Progress Requirements of the Study. Unlike safety properties, which are concerned with preventing a program from reaching a bad state, liveness properties are concerned with a program eventually reaching a good state [Magee and Kramer 2006]. In the case study subset, progress properties have been specified for the readers-writers problem. To this end, two progress properties (P READ, P WRITE) have been defined to ensure that both readers (i.e. Composite Context Aspect Adverse Environment Status, Composite Context Aspect Route Status aspects) and writers (i.e. Context Interpreter, Context Aggregator service components) will eventually gain access to the lock to access the Context Database component. A progress analysis for this problem using the LTSA shows no errors. However, in order to find how the system performs when loaded, the action priority operator in FSP can be used to specify adverse scheduling conditions. In this example, this heavy loading has been modeled by making the release events lower priorities. Analysis of this system using the LTSA reveals a P READ progress violation, which indicates that if a writer process is waiting to acquire the lock, a reader process will never gain access to it, as demonstrated in Figure 12. However, this P READ progress violation can be disregarded, as usually the number of write accesses to a database is less than the number of read accesses. Thus, the importance of preserving writer priority in acquiring the lock is clear, as modeled in this example. The progress property P REFRIG CTRLUNIT ensures that the Refrigerator Control Unit component (REFRIG CTRLUNIT) will eventually be enabled for it to receive any messages from the Recovery component using the synchronous message-passing ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:20


Fig. 13. FLTL properties to ensure mutual exclusion.

technique. A progress property (P MOBILE DEVICE) has been defined to ensure that the Mobile Device component will eventually receive reception for its correct operation. 6.4.3. FLTL Requirements of the Study. In addition to safety and progress property processes, properties can be defined as state-based logical propositions in FSP. Fluents in FSP allow the expression of properties about the abstract state of a system at a particular point in time [Magee and Kramer 2006]. The current study employs FLTL assertions as a method for specifying system requirements of the case study subset. Fluents provide several benefits over the property processes (i.e. safety and progress). First, fluents provide a more concise description of the required properties compared to property processes. Second, they express the required properties more directly compared to the property processes. Third, fluents facilitate the generation of witness executions to identify and locate potential errors in the specification. With property processes, if a property is satisfied by the model, the LTSA does not return any further information. By contrast, FLTL properties provide the opportunity to generate traces or examples of model execution that satisfy the property, which are referred to as witness executions. Several FLTL properties have been defined for the case study subset. For example, two FLTL assertions (F CI CA MUTEX T, F CI CA MUTEX P) have been defined to ensure mutually exclusive access to the shared variables (valueTempCICA, valuePressCICA) by the Context Interpreter and the Context Aggregator service components, illustrated in Figure 13. These properties ensure the required mutual-exclusion safety property and an additional liveness property, which asserts that if a process (i.e., Context Interpreter or Context Aggregator) enters the critical section, that process should eventually exit before another process can enter. Verification performed for this logical property shows that there are no violations. This research applies witness executions as a means of identifying potential errors in the specification. An FLTL property (F WEAVING) has been defined to verify the weaving of the base state machines and aspectual state machines in the specification. The same property was defined as a safety property previously (S WEAVING). The negation of the F WEAVING assertion generates a counterexample, which was not possible with the S WEAVING safety property process. By using counterexamples and witness executions, the state models and system properties for the aspectual pervasive services are iteratively improved. The next section establishes an evaluation framework to validate the research approach. ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:21

Fig. 14. Evaluation framework: vertical and horizontal views.

7. EVALUATION FRAMEWORK

This evaluation framework [Abeywickrama and Ramakrishnan 2011; Abeywickrama 2010] mainly validates the main contributions or deliverables of this study against several key evaluation criteria. The main tools used in this study include the Aspectual FSP Generation tool created in this research, the LTSA model checker, and the LTSAMSC tool. The method of evaluation is based on key feature comparison. Key feature comparison is used as a credible method for evaluating software engineering-based approaches [VIDE 2009]. The evaluation framework developed here does not produce additions to the research methodology, but instead validates the methods and tools used in the research as a whole. The framework comprises a set of detailed criteria for two dimensions or views, vertical and horizontal, as depicted in Figure 14. The notions of vertical and horizontal views were motivated by page 14 of VIDE [2009], which also uses a two-dimensional evaluation approach. 7.1. Vertical Evaluation of the Research

This evaluation focuses on comparing four tools across the modeling layers of platformindependent model (PIM) and platform-specific model (PSM) against the Aspectual FSP Generation tool. Like the Aspectual FSP Generation tool, these tools have been developed using commercially available toolchains of similar areas of application, such as IBM Rational Software Modeler, Borland Together, Telelogic Modeller, and Topcased [VIDE 2009]. This evaluation is based on the following criteria: context-dependent behavioral modeling at the PIM level, explicit joinpoint model of aspect-oriented modeling at the PIM level, weaving performed at the PIM or PSM level, and context-dependent behavioral-code generation from the PIM to PSM level. A particular evaluation criterion can be fully satisfied (complete cover), partly satisfied (partial cover), or not supported at all (no cover). Groher and Schulze [2003] present an approach for specifying crosscutting concerns using aspect-oriented modeling, and discuss the seamless integration of those models to implementation. In their approach, UML has been customized for supporting aspect-oriented modeling using UML’s standard extension mechanisms, such as stereotypes, tagged values, and constraints. Their design notation for aspect-oriented modeling provides a base package for modeling the business logic, an aspect package for modeling the crosscutting concerns, and a connector (weaving rules) for linking the aspect and the base elements. The weaving in their approach is essentially performed ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:22


at the PIM level, and not at the PSM level as in the current study. The authors have implemented an AspectJ code generator using the CASE tool Together from Borland. Groher and Schulze’s work is not based on pervasive services, which is a key difference to the current research. Also, the code generation is at the implementation level with AspectJ, whereas in the current research it is at the software architectural level with FSP. Whittle and Jayaraman [2008] present a UML-based aspect-oriented modeling tool called MATA that applies graph transformations for specifying and composing aspect models. Their work is different to most other approaches on aspect-oriented modeling in three respects. First, there is no support for explicit joinpoints, and composition is considered a special form of model transformations. Second, the use of graph transformations for aspect composition, and third, support for statically analyzing aspect interactions using critical pair analysis makes their approach different to other approaches. The composition of a base model and an aspect model (weaving) is specified using a graph rule. The authors use a cell phone example to demonstrate the validity of their method and tool. Tool support for MATA has been built using IBM Rational Software Modeler. The tool uses graph transformation as its underlying theory for aspect composition. Similar to Groher and Schulze’s approach, MATA is not based on pervasive services. Whittle and Jayaraman’s work does not support explicit joinpoints, as provided in the current research. Also, they do not provide code generation of the models. Cottenier et al. [2007] present Motorola WEAVR, which provides aspect-oriented weaving for UML state charts that include action semantics. Motorola WEAVR is an industrial-strength aspect weaver for UML 2.0, which is implemented as an add-in to the Telelogic TAU G2. The authors have provided several UML stereotype classes for identifying various constructs of an aspect at the PIM level. Motorola WEAVR introduces two fundamental language constructs to support aspect-oriented modeling. First, the authors provide constructs to specify the locations or joinpoints in the models where crosscutting behavior emerges. Second, the authors provide constructs to specify the actual behavior of the crosscutting concerns using the connector stereotype. Weaving process consists of two phases: advice instantiation and advice instance binding. As weaving is performed at the PIM level with aspects woven into executable UML models, it allows PSMs and source code to be generated automatically. Several examples on exception handling and recovery have been developed by the authors to demonstrate the validity of their approach. However, Cottenier et al.’s work is not in the pervasive computing domain, as is the current research, and, their PSMs are not at the formal behavioral specification level, as in our study. Fuentes et al. [2008] present an aspect-oriented executable modeling UML 2.0 profile called AOEM for designing pervasive applications. Using the AOEM profile, they demonstrate how aspect-oriented executable design models for context-aware pervasive applications can be constructed and executed. These models are run and tested using Populo, which is an eclipse plug-in created by the authors for interpreting executable UML models. The AOEM profile aims at addressing two challenges in pervasive applications: the crosscutting nature of context-awareness, and the complexity associated with reasoning about the correctness of the design model. In their approach, weaving of aspects to core components is performed at the PIM level. Special composition rules expressed as pointcuts in the AOEM profile describe how aspects are applied to the core components. An aspect-oriented model weaver, which is a type of compiler or preprocessor, has been developed for weaving. The weaver essentially creates the design model by injecting the crosscutting behavior of the aspects into the core modules that the aspects crosscut. The authors illustrate their approach using a location-aware intelligent transportation system. Although Fuentes et al. provide for modeling of adaptive ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:23

Table I. Comparison Matrix for Vertical Evaluation Evaluation Criteria PIM-level support for context-dependent behavioral modeling PIM-level support for explicit joinpoint model of AOM PIM- or PSM- level support for weaving PIM- and PSM- level support for context-dependent behavioral code generation

Groher and Schulze

Whittle and Jayaraman

Cottenier et al.

Fuentes et al.

Aspectual FSP Generation tool

.8

Complete cover of a criterion Partial cover of a criterion No cover of a criterion

behavior at the PIM level, they do not provide any model transformations to generate PSMs. As in our study, the authors support context modeling; however, it is at the application and middleware levels and not at the state machine level. Therefore, the criterion is only partially supported. The results, summed up in Table I, of the evaluation are assuring. Like the Aspectual FSP Generation tool, Groher and Schulze, Cottenier et al., and Fuentes et al. support an explicit joinpoint model of aspect-oriented modeling at PIM level. Also, all the compared approaches support PIM- or PSM-level weaving of aspects. The vertical evaluation has demonstrated that the Aspectual FSP Generation tool has unique features on context-dependent behavioral modeling and context-dependent behavioral code generation. Table I shows that the Aspectual FSP Generation tool satisfies all the criteria, as opposed to the other tools which satisfy only some criteria. 7.2. Horizontal Evaluation of the Research

In contrast to the vertical evaluation discussed, the horizontal evaluation is aimed at investigating particular features of our approach at a single modeling level (i.e. the PSM level). These evaluation criteria cover two aspects of the study: the formal methods and tools employed in the study, and the context and adaptation dimensions of the customization approach used in the services. 7.2.1. Formal Methods and Tools Used in the Approach. Clarke et al. [1996] provide several criteria that formal methods-based approaches and tools need to support. According to Clarke et al., although some of these criteria are ideals, it is still considered good to aim for them. The criteria are early payback, incremental gain for incremental effort, multiple use, integrated use, ease of use, efficiency, ease of learning, orientation toward error detection, focused analysis, and evolutionary development. The research methodology of the current study contains three stages: service specification, architecture definition, and architecture modularization. In the present study, formal methods and tools (LTSA tool and LTSA-MSC tool) have been applied during the service-specification and architecture-definition stages of the research methodology, and finally, for model checking the aspectual pervasive software services specification. This evaluates the application of the aforementioned formal methods and tools used in the current research against the criteria provided by Clarke et al. Our approach has been evaluated using all the criteria provided by them (refer to Abeywickrama and Ramakrishnan [2011]). However, due to space limitations this article discusses one key criterion, early payback. This study is focused on the architectural level of ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:24

D. B. Abeywickrama and S. Ramakrishnan Table II. Current Study’s Context Characteristics

push

pull

Mechanism (C.M.)

Access of Context

Dynamicity (C.D.) dynamic

static

automatic

manual

semi-automatic Automation (C.Au.)

Acquisition of Context

Abstraction (C.Ab.)

Reusability (C.R.)

Validity (C.V.)

Chronology (C.C.) future

history

application

user

network

Property (C.P.) device

time

pressure

temperature

location

Representation of Context Extensibility (C.E.)

Scope of Context

Explicitly supported Not explicitly supported Not applicable

the software life-cycle. This architecture-centric approach builds models of pervasive software services and their compositions and verifies their behavior against specified system properties. Building architectural models of pervasive software services allows the software engineers to validate the actual correctness of the services before the services are implemented later in the software life-cycle. Thus, it provides early payback or feedback to the service engineer on the validity of the services. 7.2.2. Context and Adaptation of the Customization Approach. Kappel et al. [2003] and Schwinger et al. [2005] present a comprehensive and uniform evaluation framework, which can be used to compare customization capabilities of approaches originating from the mobile computing and personalization domains. The notion of customization refers to the adaptation of an application’s services toward the current context. Their framework has two orthogonal dimensions, which are context and adaptation, and the mapping between context and adaptation represented by the notion of customization. Kappel et al. and Schwinger et al. provide detailed criteria for both the context and adaptation dimensions of the framework. The context and adaptation dimensions of the customization approach used in the pervasive services of the current research are evaluated using those criteria. The results of this evaluation are summarized in two tables, respectively: Table II and Table III. This evaluation is part of the horizontal evaluation dimension of the framework, and mainly covers the PSM level of the modeldriven architecture. However, several examples on the PIM level are also provided. This evaluation is presented in three logical sections as suggested by Kappel et al. and Schwinger et al. First, general details of the customization approach are provided, covering issues on origin, major focus, technology, architecture and implementation (if applicable) of the customization approach. Second, the context dimension of the approach is described, and third, the adaptation dimension of the approach is discussed. The current research originates from the pervasive computing domain in general, and specifically from the pervasive services domain. This research is at the software architectural level, and no implementation of services, such as pervasive Web services, has been considered in the study. The main focus of the awareness monitoring and notification pervasive service explored in this research is to alert on any exceptional situations that may arise on transport items primarily to the vehicle driver of the transport unit. The component configuration of the architecture defined for the pervasive software services specification is based on an event-control-action architecture pattern. The research approach has been applied to a modified subset of a real-world case study in intelligent transport called the ParcelCall project. As stated previously, ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:25

Table III. Current Study’s Adaptation Characteristics Incrementality (A.I.)

Dynamicity (A.D.) dynamic

static

manual

semi-automatic Automation (A.A.)

automatic

macro

micro

others

link

Tasks (A.T.)

Granularity (A.G.)

Process of Adaptation

Element (A.El.) video

image

audio

text

others

presentation

hyperbase

content

Level (A.L.)

Complexity (A.C.)

Subject of Adaptation

complex

simple

transform

remove

add

Effect (A.Ef.)

Extensibility (A.Ex.)

Operation (A.O.)

Kind of Adaptation

in this paper, three automated tools have been used in the research: LTSA-MSC tool, Aspectual FSP Generation tool, and the LTSA model checker. The customization of the architecture can be considered internal, as the system is not aware of the customization in terms of knowing about context or adaptation. The context dimension of the customization approach is described next, illustrated in Table II. The primary context parameters modeled at the PIM level of abstraction comprise location, temperature, and pressure. However, at the PSM level, only temperature and pressure-primary-context properties have been modeled (C.P.). Nevertheless, at the PSM level, other context properties such as item identity, location, and acceleration can be supported (C.E.). These context parameters as a whole, constitute the physical context of the study. Context modeling at the PIM level is provided by the c-FSP-UML profile and the c-FSP aspects. The profile essentially provides several stereotypes to represent the core service behavior, the context-dependent behavior, and the dependencies between the core service and the context-dependent models, at the service interface level. The use of stereotypes essentially supports the notion of extensibility (C.E.). The object-oriented notions used in the profile, such as generalization, further support the notion of extensibility. At the PSM level, the notions of attribution, classification, generalization, and encapsulation from the context definition have been modeled to structure and link the objects defined in the aspects (C.E.). In the study, validity period (C.V.), chronology (C.C.), or availability (C.Av.) of context are not supported, as the time dimension of the context properties have not been considered. The explicit support provided for attribution, instance-of, and ISA notions at the PSM level, facilitates reusability of context (C.R.). The approach provides a high-level inference mechanism to automatically derive higher-level logical context (C.Ab.). Both primary and logical context are modularized into aspects as atomic context aspects and composite context aspects, respectively. Thus, the study supports an explicit separation between physical and logical context (C.Ab). For example, low-level temperature readings from the RFID Tags are inferred as low or high temperature during the refinement step of the pervasive service. At the PIM level, the profile is maintained manually by the service engineer (C.Au.). At the PSM level, both physical and logical context information are acquired automatically (C.Au.) and at runtime (C.D.). The pervasive service engineer using the LTSA animator can select values for the temperature or pressure readings from a range of values at runtime. The mechanism (C.M.) used to acquire context and made accessible to the pervasive service can be considered push-based as context readings from the RFID Tags are provided based on context changes and not on requests. The second dimension of the customization approach is provided by the notion of adaptation, illustrated in Table III. In this study, there are two types of adaptation ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:26


operations: triggering and recovery operations (A.O.). At the PSM level, both these operations have been supported by the trigger and recovery c-FSP aspects (A.O.). Trigger aspects, for example, Trigger Aspect Adverse Environment Status, effectively sending notifications or alert messages to the vehicle driver when a transport item’s context information violates acceptable levels. Recovery aspects, for example, Recovery Aspect Adverse Environment Status, model any recovery actions that need to be enforced after an exception situation is raised by a trigger aspect. Both these aspects have been modeled as independent state machines at PSM level, which synchronize with their base state machines, using explicit synchronization events. The adaptation operations provided by the aspects are associated with the core service model through weaving, and the behavior of these aspects can affect the core service behavior depending on the context information (A.Ef.). This can be, for example, executing or modifying a service based on context information (A.Ef.). At the PIM level, adaptation operations are specified using the stereotypes TriggerAspect and RecoveryAspect. As the adaptation process contains a series of stages, it can be considered a complex process (A.C.). Also, a distinct separation can be identified between the different tasks of the adaptation process (A.T.). When an item’s context information is violated, first, the pervasive service alerts the vehicle driver by sending an SMS. Second, the service can perform any appropriate recovery actions to remedy the situation, such as control the refrigerator’s temperature (A.C.). Third, the service adaptation can be extended (A.Ex.) as follows: If the environment status of items is critical, the service can alert the Goods Tracing Server and eventually the customer being affected through the Goods Information Server (A.Ex.). In the current study, context information is represented at the service interface level (A.L.) that essentially consists of operation invocations and the exchange of respective input/output parameters. The core service elements represented at the modeling level include states, transitions, processes, and services (A.El.). Any adaptation operation, which can be a triggering operation or a recovery operation, is bound to the transitions of the core service model. Therefore, the adaptation level and adaptation elements of this study are the service interface level (A.L.) and transitions (A.El.), respectively. As a result, different Web application levels, such as content, hyperbase, and presentation are not applicable in this study, nor the Web adaptation elements of text, audio, image, video, and link provided in Kappel et al. [2003] and Schwinger et al. [2005]. The adaptation granularity (A.G.) can be considered micro, considering the number of elements affected by the adaptation process. Also, it is performed automatically (A.A.) and at runtime (A.D.). The adaptation process can be considered incremental (A.I.) as recovery operations are dependent on triggering operations at both PIM and PSM levels. The horizontal evaluation of the approach has shown that the formal methods and tools employed in the research, and the customization approach used in the services, are effective toward the overall objectives of this research. One of the limitations of the current study is efficiency in terms of execution time and memory allocation. This is mainly attributed to the formal model checking technique used for verifying the pervasive services. One of the main challenges associated with traditional model checking techniques is the state space explosion problem. Nevertheless, by using action hiding and minimization features of the LTSA model checker, the present study has proven sufficiently efficient in modeling and verifying the case study subset of this research. Also, more recently researchers [Filieri et al. 2011] have produced results which show how the limitations of traditional model checking can be addressed. 8. CONCLUSION

Context-aware Web services have been identified as an important technology to support new applications on the future Internet. With the proliferation of ubiquitous ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.


10:27

computing devices and the Internet, context-aware Web services continue to evolve from simple proof of concept implementations created in the laboratory to large and complex real-world services developed in industry. Context-awareness capabilities in service interfaces introduce additional challenges to the software engineer. The additional complexities associated with these special services necessitate the use of solid software engineering methodologies during their development and execution. To this end, this article has proposed a novel approach which integrates the benefits of solid software engineering principles of model-driven architecture, aspect-oriented modeling, and formal behavioral modeling and analysis techniques using model checking. A prototype tool—Aspectual FSP Generation—applying an effective pipeline of modelto-model and model-to-text transformations, has been built. This tool ensures the correct separation of concerns of the crosscutting context-dependent functionality at both semiformal UML modeling and formal behavioral specification levels. The generated formal behavioral models for context-dependent behavior, and the core service behavior have been rigorously verified using model checking against desired system properties. The approach has been explored using a real-world case study in intelligent transport, and an evaluation framework has been developed to validate the main methods and tools employed in the study. In summary, the primary contribution of this article is a novel, systematic, architecture-centric approach for engineering context-aware services at the software architectural level.

REFERENCES ASPECT-ORIENTED MODELING. http://www.aspect-modeling.org/. (Last accessed 12/11.) ABEYWICKRAMA, D. B. 2010. Pervasive services engineering for SOAs. Ph.D., Faculty of IT, Monash University, Australia. ABEYWICKRAMA, D. B. AND RAMAKRISHNAN, S. 2008a. A model-based approach for engineering pervasive services in SOAs. In Proceedings of the 5th International Conference on Pervasive Services. 57–60. ABEYWICKRAMA, D. B. AND RAMAKRISHNAN, S. 2008b. Towards engineering models of aspectual pervasive software services. In Proceedings of the 3rd Workshop on Software Engineering for Pervasive Services. 3–8. ABEYWICKRAMA, D. B. AND RAMAKRISHNAN, S. 2010. Model-driven development of aspectual pervasive software services. In Proceedings of the 14th IEEE International Enterprise Distributed Object Computing Conference Workshops. 49–59. ABEYWICKRAMA, D. B. AND RAMAKRISHNAN, S. 2011. A framework for aspectual pervasive software services evaluation. In L. A. Maciaszek and K. Zhang Eds., Evaluation of Novel Approaches to Software Engineering, CCIS 275, 98–113. ACHILLEOS, A., YANG, K., GEORGALAS, N., AND AZMOODECH, M. 2008. Pervasive service creation using a model driven petri net based approach. In Proceedings of the International Wireless Communications and Mobile Computing Conference. 309–314. ANALYTI, A., THEODORAKIS, M., SPYRATOS, N., AND CONSTANTOPOULOS, P. 2007. Contextualization as an independent abstraction mechanism for conceptual modeling. Info. Sys. J. 32, 1, 24–60. AUTILI, M., BERARDINELLI, L., CORTELLESSA, V., MARCO, A. D., RUSCIO, D. D., INVERARDI, P., AND TIVOLI, M. 2009. A development process for self-adapting service-oriented applications. In Proceedings of the International Conference on Service-Oriented Computing. Lecture Notes in Computer Science Series, vol. 4749, Springer, Berlin, 442–448. CLARKE, E. M., GRUMBERG, O., AND PELED, D. A. 1999. Model Checking. The MIT Press, Cambridge, MA. CLARKE, E. M., WING, J. M., AND ALUR, R. 1996. Formal methods: State of the art and future directions. ACM Comp. Sur. 28, 4, 626–643. COLOMBO, E., MYLOPOULOS, J., AND SPOLETINI, P. 2005. Modeling and analyzing context-aware composition of services. In Proceedings of the International Conference on Service Oriented Computing. Lecture Notes in Computer Science Series, vol. 3826, Springer, Berlin, 198–213. COTTENIER, T., VAN DEN BERG, A., AND ELRAD, T. 2007. Motorola WEAVR: Aspect orientation and model-driven engineering. J. Obj. Tech. 6, 7, 51–88. DAVIE, A. 2002. Intelligent tagging for transport and logistics: The ParcelCall approach. IEE Elec. & Comm. Eng. J. 14, 3, 122–128.

ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

10:28


DECARLO, J., ACKERMAN, L., ELDER, P., BUSCH, C., LOPEZ-MANCISIDOR, A., KIMURA, J., AND BALAJI, R. S. 2008. Strategic Reuse with Asset-Based Development. IBM Corporation. DOUENCE, R., BOTLAN, D. L., NOYE, J., AND SUDHOLT, M. 2006. Concurrent aspects. In Proceedings of the 5th International Conference on Generative Programming and Component Engineering. 79–88. FILIERI, A., GHEZZI, C., AND TAMBURRELLI, G. 2011. Run-time efficient probabilistic model checking. In Proceedings of the 33rd International Conference on Software Engineering. 341–350. FUENTES, L., GAMEZ, N., AND SANCHEZ, P. 2008. Aspect-oriented executable UML models for context-aware pervasive applications. In Proceedings of the 5th International Workshop on Model-Based Methodologies for Pervasive and Embedded Software. 34–43. GROHER, I. AND SCHULZE, S. 2003. Generating aspect code from UML models. In Proceedings of the 3rd International Workshop on Aspect-Oriented Modeling. ¨ , A., LINNHOFF-POPIEN, C., AND REISER, H. 2003. Management challenges of contextHEGERING, H.-G., KUPPER aware services in ubiquitous environments. In Self-Managing Distributed Systems, Lecture Notes in Computer Science Series, vol. 2867, Springer, Berlin, 321–339. ITU-T. 2009. The Future Internet: ITU-T Technology Watch Report 10. http://www.itu.int/dms pub/itut/oth/23/01/T230100000A0001PDFE.pdf. (Last accessed 12/11). KAPPEL, G., PROLL, B., RETSCHITZEGGER, W., AND SCHWINGER, W. 2003. Customization for ubiquitous web applications: A comparison of approaches. Inter. J. Web Eng. Tech. 1, 1, 79–111. Inderscience Publishers, Geneva, Switzerland. ¨ KRUGER , I. H., MATHEW, R., AND MEISINGER, M. 2006. Efficient exploration of service-oriented architectures using aspects. In Proceedings of the 28th International Conference on Software Engineering. 62–71. MAGEE, J. AND KRAMER, J. 2006. Concurrency: State Models and Java Programs 2nd Ed. John Wiley and Sons. MANDATO, D., KOVACS, E., HOHL, F., AND AMIR-ALIKHANI, H. 2002. CAMP: A context-aware mobile portal. IEEE Comm. Mag. 40, 1, 90–97. MCEACHEN, N. AND ALEXANDER, R. T. 2005. Distributing classes with woven concerns: An exploration of potential fault scenarios. In Proceedings of the 4th International Conference on Aspect-Oriented Software Development. ACM, 192–200. MOSTEFAOUI, S. K. AND HIRSBRUNNER, B. 2004. Context-aware service provisioning. In Proceedings of the IEEE/ACS International Conference on Pervasive Services. 71–80. PANG, J. AND BLAIR, L. 2002. An adaptive runtime manager for the dynamic integration and interaction resolution of features. In Proceedings of the 22nd International Conference on Distributed Computing Systems Workshops. 445–450. PAPADIMITRIOU, D. 2009. Future Internet: The Cross-ETP Vision Document (Version 1.0). http://www.futureinternet.eu/fileadmin/documents/reports/Cross-ETPs FI Vision Document v1 0.pdf. (Last accessed 12/11). PEREZ-TOLEDANO, M. A., NAVASA, A., MURILLO, J. M., AND CANAL, C. 2007. TITAN: A framework for aspect oriented system evolution. In Proceedings of the International Conference on Software Engineering Advances. 23–30. ¨ , C., PROLL ¨ , B., RETSCHITZEGGER, W., AND SCHAUERHUBER, A. 2005. Context-awareness in SCHWINGER, W., GRUN mobile tourism guides—a comprehensive survey. Tech. rep., Johannes Kepler University, Linz, Austria. SHENG, Q. Z. AND BENATALLAH, B. 2005. ContextUML: A UML-based modeling language for model-driven development of context-aware web services. In Proceedings of the International Conference on Mobile Business. 206–212. VIDE. 2009. VIsualize all moDel drivEn programming. Report WP11: Deliverable number D11.3. PolishJapanese Institute of Information Technology. http://www.vide-ist.eu/download/VIDE D11.3.pdf. (Last accessed 12/11.) WHITTLE, J. AND JAYARAMAN, P. 2008. MATA: A tool for aspect-oriented modeling based on graph transformation. In Models in Software Engineering, Lecture Notes in Computer Science Series, vol. 5002, Springer, Berlin, 16–27. XU, D., ALSMADI, I., AND XU, W. 2007. Model checking aspect-oriented design specification. In Proceedings of the 31st Annual IEEE International Computer Software and Applications Conference. 491–500. XU, J., RAJAN, H., AND SULLIVAN, K. 2004. Aspect reasoning by reduction to implicit invocation. In Proceedings of the Foundations of Aspect Oriented Languages. 31–36. Received December 2010; revised April, July 2011; accepted September 2011

ACM Transactions on Internet Technology, Vol. 11, No. 3, Article 10, Publication date: January 2012.

Context-aware services engineering: Models ... - ACM Digital Library

Context-aware services engineering: Models ... - ACM Digital Library

Suggest Documents

NMC: Models of collaboration - ACM Digital Library

Cloud services certification - ACM Digital Library

Proportional Differentiated Services: Delay ... - ACM Digital Library

Personalised Continuous Software Engineering - ACM Digital Library

Software development lifecycle models - ACM Digital Library

design - ACM Digital Library

crpit - ACM Digital Library

Conversations - ACM Digital Library

Incentives - ACM Digital Library

Gunrock - ACM Digital Library

Abstract - ACM Digital Library

AdaGIDE - ACM Digital Library

MOVELETS - ACM Digital Library

P10 - ACM Digital Library

2PXMiner - ACM Digital Library

feature - ACM Digital Library

C++ ... - ACM Digital Library

practice - ACM Digital Library

Evaluation Measures for Business Process Models - ACM Digital Library

Preference Networks: Probabilistic Models for ... - ACM Digital Library

Augmented enterprise models as a foundation ... - ACM Digital Library

A manifesto for effective process models - ACM Digital Library

A Study of Terrain Coverage Models - ACM Digital Library

25 Classification Models for RFID-Based Real ... - ACM Digital Library