Sage Journals: Discover world-class research

Abstract

Understanding the user's demands and intentions is essential when developing pervasive applications. It ensures proactive decisions and improves usability. However, due to a lack of conceptual development methodology and supporting tools, it is difficult to orient the designs towards user's needs. To make the developer's task feasible, we present a development environment, called PerDE, which supports a novel design method. Our approach combines the notion of the situation with an application model and provides a domain-specific design language and a set of graphical toolkits covering the development life cycle of a pervasive application. We validate our approach on developing a realistic situation and describe the results from a user study that illustrates the expressiveness and usability of PerDE.

1. Introduction

The widespread availability of mobile computing devices and hardware and/or software infrastructure enables the vision of pervasive computing to become realistic for the public. An increasing demand for “value for end-user” [1, 2] has changed our attitude towards the application. Determining which system actions will help rather than hinder the user is an important issue when designing an application. Many pervasive computing projects have emerged to begin the quest by capturing a user's intent, such as CMU's Aura, O2S, and the work of Henricksen and Indulska [3] and Heider and Kirste [4]. Many of the previous works make effort to strike the balance between “annoying proactivity” and “inscrutable transparency” [5] by dynamically assembling a set of generic components at runtime. They usually suggest a “corrective” action to the user at design time and wait for the user to act on this suggestion. However, is adaptation using corrective actions practically feasible? Would the user like to perform such an action under real situations? It is hard to give a definite answer in advance due to the complicated environment. We adopt a view from user-centered design (UCD): the users should be focused on within early stages of application development, which is not merely a factor causing adaptation. A new development methodology is thus needed to support the vision.

In prior work, we analyzed the obstacles to developing pervasive applications [6]. In a nutshell, we identified the lack of development methodology in general, specifically the gap between design time and runtime, as hindering aspects. Different users expect applications to behave differently in a given situation. We proposed a design method that allows developers to model the application behavior depending on the situation in the physical world and the user's expectation.

We argue that user requirements on the interactions vary from one situation to another. In addition, an activity can be observed only when it is carried out in a particular situation. Therefore, understanding the context of the user's situation can be an important way in application development. On the other hand, the unique features (such as embracing the contextual changes, the implicit interaction) of pervasive application make the traditional desktop-based technologies ill-suited for development. Taking the location-aware application as an illustration, a clear mapping from these user's locations to how developers conceive functions is necessary. However, by using existing approaches in UCD for a desktop computing environment, it does not do a very good job of anticipating the user's needs from a constrained set of raw information. In addition, the developers will spend much time and effort in the context analysis, what makes deploying and field testing prohibitively expensive. The brand-new challenges in developing pervasive applications are then put forward. (i)

The understanding of the users’ situations becomes a more major concern for the development of pervasive application. Previous work typically considered a simple application environment, where the hardware and infrastructure were fixed, and the interaction was straightforward. For example, an electronic calendar alert could punctually remind the user of any subsequent task, regardless of whether the user was available or not. Due to attaching the computation to the user and his surrounding, the complex application environment often includes hardware, software, and rich human factors that consist of many attributes. User analysis should, therefore, consider how deeply integrated the user is into his diverse situations.

(ii)

Task analysis aims at figuring out what tasks are involved in the problem(s) being addressed. An application should be divided into a set of subtasks, each of which can be expressed as a goal that helps to identify the specific application requirements and the technical features needed to fulfill the subtasks. Analysis of the tasks in pervasive computing environment is still very challenging, where sensing, decision, actuation, computation, networking, and physical processes are mixed, and these subtasks function in a context-aware manner.

(iii)

Prototyping technologies are concerned with providing an interesting programming platform or toolkit for creativity. Although more promising technologies can provide the effective means for extracting the core design problems and evaluating the solutions, it is still a critical task to choose the right kind of prototypes to serve a particular purpose in a pervasive environment. The implicit inputs, as well as the distributed logic in applications, must be considered when creating an appropriate prototype.

(iv)

Using the results of the evaluation, we can redesign the application with a better understanding of the users’ needs. We now test the user experience and the technical features by building multipurpose prototypes, focusing on the actual objectives of the applications. This is particularly pronounced in the design of pervasive applications because it is not easy to validly test user acceptance with a functional but incomplete prototype.

To this end, we provide the methodology and apply it to the entire design process: from drafting the concept early with a low-fidelity prototype and validating it against the user's need, to deploying a high-fidelity prototype and testing it in a simulated environment. This methodology would allow a developer to build an application by: (i)

focusing on the human situations evolved into the physical surroundings, rather than the user's interaction with an interface on a specific device in a specific environment;

(ii)

characterizing the application along with attributes of a new application model by representing the intentions as the task requirements, specifying the services, and the instantiation of services on devices in an abstract manner;

(iii)

specifying a flexible programming structure that takes a form of a negotiation between the function requirement and device capability;

(iv)

rapid prototyping with a development environment that offers the GUI toolkits for design, a language for modeling, and a virtual pervasive environment for testing.

The rest of the paper is organized as follows. First, we discuss different efforts that would be valuable to make and compare our work with related work. Next, we investigate the challenges of building pervasive applications, and then give the unique requirements. Our work is based on a set of novel conceptual foundations, including application model, situation modeling, and model-checking technologies. We then detail these features and describe the infrastructure integrating the models as well as the development process based on the infrastructure. We validate how our approach works in practice and give a conclusion and a final outlook.

2. Related Work

As a major evolutionary step in a line of work, pervasive computing arose at the intersection of distributed system and mobile computing. Currently, the technical features for building pervasive applications are visible, due to the existing sensing, data processing, and context-recognizing technologies. It enables us to conceive a new way of thinking about Weiser's vision; that is, we should focus more on the “value for end-users” than on the “core technical workability.” In order to support the acceptable user experiences, developers have to construct the complete scenarios to understand the everyday practices of their users. This brings new challenges to the development of pervasive applications. Today, there is still a need to assist developers in envisioning everyday situations and determining the technical and users’ motivated features easily, without setting up an entire infrastructure and without writing any code. We reviewed the related research works from the major journals and conferences over the last five years and found that there were three kinds of support for developing pervasive application, where system support which focuses on building pervasive application by improving the development of appropriate protocols and techniques is not our concern.

2.1. Methodology Support

Application development is able to benefit from an ideal methodology, because it allows taking developer through a step-by-step process. Due to the loose coupling between a user's personal computing space and his or her surroundings, pervasive applications not only adapt their behaviors to the dynamic contexts, but also positively influence the environment, especially the users’ behaviors. This makes the prediction-based design approach complex and in many cases ineffective because the well-established data for modeling human cognitive is often not available when physical contexts change.

A number of different approaches to engineering ubiquitous computing exist. UCD offers an attractive way to manage the inherent risk of loosening the link to the user in pervasive application design and has been experimentally introduced into the application development [7]. However, very little research conceived UCD technologies to evolve with the design process. So developers tend to utilize user studies once (or perhaps twice) during an application's evolution, for example, focusing on the early stage for analyzing technical requirement. One exception is the work of Davies et al. [8], which explores the integration of user-driven approach into an e-health application. This work involves a series of three phases to derive the area of interest that can be improved through iterative development, along with a number of prototypes for testing. This work appears as a part of the COGKNOW project that aims to provide people with mild dementia with a cognitive solution. Due to the time-consuming and prohibitively expensive evaluation in field evaluation, there have been efforts to discuss how to adapt to the need of testing pervasive application. Abowd et al. [9] extended the concept of UCD in the design of a mobile application. In their Personal Audio Loop diary study, designers use diaries as an experience prototype, to record the reflections of participants in a simulated interaction which makes it clear in understanding the specific design issues (e.g., “how, when, and where people would use the application”) and identifying the appropriate interruption of activity flow. However, similar to the work from [10], the user studies conducted currently give only a set of qualitative data by observing or interviewing users. Thus, we argue that an approach which supports the integration of user and task analysis into the design stage is desirable, in order to help identify design considerations. Additionally, a development environment that supports a new methodology is also required for building an application.

2.2. Tool Support

Recently, several tool supports have also appeared to move prototyping activities on to building pervasive applications. They are concerned with providing an interesting platform for designing, prototyping, and evaluating ideas. Furthermore, they usually offer a large number of reusable components for describing the programming logic at a higher abstraction level.

The Context Toolkit leverages the notion of widgets, to create reusable components by abstracting contextual information, to adapt the expected needs of applications. VisualRDK [11] is developed as a high-level programming language that encapsulates the location contexts as different components. In this way, the developer can demonstrate the application logic by orchestrating the combinations with events triggering. It also enables the developer to generate the different implementations and monitor the control and data flows that are hosted on distributed platforms. Similar to PCOM, Hess et al. [12] presented a framework that enables the functional flows to be described as separated components among distributed devices and to adapt as demanded by users and their environment. The iCAP project [13] allows the end-users to configure the context-aware applications in their instrumented environments. It encapsulates the user-defined entities as separate builders and enables constructing a rule rapidly. As a good try involving the end users in the deployment process, FedNet [14] exposes the contextual changes as the functionalities of some instrumented artifacts and enables the applications to be developed in a user-centric way.

Another example with underlying notion of UCD is ActivityDesigner [15] that models the activity contexts as several independent scenes and allows the developer to create the stream-based application behaviors by customizing the transitions using different scenes. Testing in the simulated environment allows designers to assess objectively the rough prototypes. One toolkit that simulates the physical environment surrounding wireless devices and users for pervasive applications is described in UbiWise [16]. When testing with UbiWise, all events are encapsulated as the messages to communicate between the environmental and device views for simulating the devices’ actions.

The previous works have made different efforts to address application development [17]. However, they have trouble with the design of application structure. Furthermore, they have poor ability to be integrated into an iterative development process and adapt their capabilities to a particular purpose at each phase. Our approach differs from these efforts in that we advocate a novel methodology based on a user-centric application model. Specifically, it thinks at the situation level for handing contexts easily, demonstrates the programming logic which enables the control flows to jump among distributed devices by matching the required functions and device capabilities, and supports the application adaptation with a set of customized components.

3. Requirement of Developing Pervasive Applications

Meeting people's expectations whenever and wherever they are is the key challenge for any developer wanting to build a pervasive application. The unavailability of resources and the users’ movements are so frequent that the application should continuously adapt. However, existing approaches are ill-suited to meet this challenge. How can we offer the development support (including methodology and tools) for pervasive applications? To get a better understanding, we identify five unique requirements.

Requirement 1: Embrace Distributed Logic. As a user performs his/her task by using different objects in different locations, the environment which hosts the application logic changing over from a sensor to any other kind of networking appliance. It is impractical to make any assumptions about the device capabilities and treat the required resources to be available all the time. Instead, a mechanism that abstracts the logics away from the differences in the devices and makes them call each other using the event-based notification is more suitable.

Requirement 2: Employ Contexts Easily. Pervasive applications are inherently context-aware. Developers need to represent and exploit the context for a specific application. However, there is a tremendous variety in what can be considered context, and it would be a time-consuming and long-term process to handle all the low- or high-level contexts. Furthermore, most of these contexts could be shared among different situations. There may even be possible conflicts within a situation [18]. As a result, structuring the raw contextual information as a specific kind such as location, activity, and situation [19] is a popular way to provide a high level of abstraction for simplifying the development.

Requirement 3: Compose Functional Units. Mobile devices such as laptops and PDAs have emerged to assist a user to perform ad hoc tasks. From an application's viewpoint, the control flows executed on these pervasive devices act as interdependent functional units. Composing these units enables the developer to more easily overcome the limitations due to the ever-changing execution environments. As a result, an application with a flexible architecture could adapt to the spontaneously networked pervasive computing environments. Such architecture consists of functional components and can be executed by composing the available units dynamically. This is particularly useful for developing complex and reusable application behaviors, such as redirecting to a new device.

Requirement 4: Deploy Functional Implementation Rapidly. Before testing, it is necessary to transfer the laboratory prototypes into the real world or simulated experiments. In order to fulfill the deployment, developers have to consider how to map the application logics described in prototypes to the devices. Rapid implementation is a major concern that mainly depends on the better understanding of devices and network capabilities. Due to the diverse hardware and available communication modes in pervasive computing, it is impractical to leave developers to deal with all implementations by themselves. Besides, the realistic changes and feedback from environments are unpredictable, which makes the code-based deployment impossible. A flexible deployment model that abstracts the capability of real entities and matches the prototypes’ functions could be promising. In addition, guidance for finding out the mapping between the prototype and devices as soon as possible, as well as the code-generated mechanism that can be integrated into the tools support, is also pretty useful.

Requirement 5: Test Low-Fidelity Prototype Early. Low-fidelity prototypes are usually used to draft how developers conceive applications. Testing early helps in orienting the designs towards user's needs. Such prototypes may bring certain constraints to the usability testing that will adversely affect the evaluation of any design concept [20]. As a promising field of study, the simulated testing environment, where the changes in the simulated context as well as application behavior can be marked, enables developers to assess objectively the rough prototypes as early as possible.

4. Methodology for Developing Pervasive Applications

In accordance with the development requirements discussed before, we present a novel methodology to help developers realize pervasive application through a step-by-step process. Situation, “a description of the states of relevant entities” [21], might be thought as a higher level of abstraction related to the user's intent. So, the user interactions could be decomposed as the transfer between different specific situations. Therefore, situation abstraction is useful in the software engineering process of pervasive application. Furthermore, based on the application model proposed, it is practical to utilize the situation as a programming abstraction to compose more complex applications.

4.1. User-Centric Application Model

As Banavar et al. described in [5], an application model needs to characterize the pervasive applications and also to lead a rapid design cycle. Given a model that structures the application, it should capture a user's intent, represent it as the task requirements, specify the instantiation of services on devices, and make the application adaptable. Furthermore, it should allow the contexts to keep coming and change due to the behavior of the application.

We present a novel application model that bridges the gap between the design time and an application's runtime. It requires a user-centric description which captures the purpose of user interaction at a high level and specifies the application in terms of its required functionality of devices based on their capabilities. Figure 1 depicts the general application model meeting the aforementioned requirements. It allows developers to specify the user's intentions and services in an abstract manner, so that it enables the available services required by the tasks to be discovered in the environment and be implemented on the suitable devices.

Figure 1

Illustration of partial application model that structures an application with four interdependent parts: task, service, device, and environment.

The application model is composed of four elements. The task-oriented model describes the abstract user interactions, including the goal, the flows through the tasks, and the necessary information that user needs to perform the task. The “task-service” field identifies the expected functions for each (sub)task. In addition, the service-oriented model specifies the expected devices’ capability with the “service-device” field. By linking it with the environment-oriented model, the application is structured in order to become context-aware. In particular, the “service precondition” and “service effect” fields describe the fact that once the context changes, the application behavior changes, and vice versa. Furthermore, the “context change” field allows the developer to define the changes happening in the physical environment. The device-oriented model abstracts from the differences in the device with “device-service” and “device-interaction” fields.

As shown in Figure 1, the four elements involving the application's runtime can be modeled in a pervasive design language (PerDL) [22]. Table 1 further gives examples to show how the “ULS” (User Location Service) and “Location” context involved in a navigation application are described in PerDL.

Table 1

A PerDL description of services and contexts involved in a navigation application.

Case: navigation application
Service Type ULS	Service implementation ULS.implementation
Access	Logic
Service-Task: provides task access Locate(visitor, exhibit)	Sequence
Service-Device: requires device access Sense	Subservices (receive event, obtain location)
end ULS	Effect: Update(“location”, “?exhibit_ID”)
	end ULS.implementation

Environment Location
user context
dynamic <Context type=“Location”><Change type>“in”, “out”, “stay”<Change>
{iterative (sequence(“in”, “stay”),sequence(“stay”, “ out”)} <Context>
Properties
Allow_Service_Binding=>reference ULS applies to Location
Allow_Environment_Binding=>reference Location_transition applies to ULS.implementation

With the application model, the development will be directed at the level of specifying the abstract functions and connecting it with the available devices. It also suggests that requirements 1 and 3 mentioned can be met.

4.2. Situation Model

There are many ways to describe a situation, ranging from ontology, first-order logic theories, to the logic programming language. In our approach, the notion of situation is presented to direct the developer in building a pervasive application with a better understanding of user's intent and the definition of the application behavior. Therefore, as a way to encapsulate the underlying contexts as the user-specific knowledge, the description of situation should expose the critical information of a user to the developer, such as what the user is paying attention to and what is important to the user. Furthermore, such knowledge should be shared, combined, and reused, for example, if other applications for the same user or a group with similar preferences are developed. Our working hypothesis on the situation is similar to that proposed by Li and Landay [15] but is more systematic. We define a situation as a set of user tasks performed under certain circumstances, where a task will be performed by a set of interactions between the user and devices. In other words, it needs a set of user actions and interactive device actions for accomplishing the task goal. For example, there is “medication-taking task” involved in the health care situation where the actions (e.g., to select and take the medicine) will be performed by the elderly, and a system will deliver the time-based prompting. Due to the need for the descriptions of context-awareness, the term of “Action” is considered as a definition of its preconditions and effects related to the context.

The ontology conception is employed for the situation model, as shown in Figure 2(a). It is a two-layered structure where the specific domain-related knowledge can be easily extended as the upper situation ontology. It describes the knowledge shown as ellipses, their properties shown as boxes, and the dependencies amongst different knowledge shown as arrows with mark. At the context level, the description of situation can be considered as a set of knowledge bound by the semantic relations. For example, the conception of “user action” is regarded as a description where there is an associative relationship between the ontology “person” and “action.” Figure 2(b) shows an example of modeling the conception of “action” in OWL. According to the situation model, the “action” ontology has its own properties, such as the “hasSuccessor” field, and can act as the constituent elements of other ontologies.

Figure 2

(a) Ontology-based situation model. (b) A part of situation model in OWL description.

As an extension of Yau and Liu's work [23], we divide the description of situation into two major categories: atom_Situation and comp_Situation. The atom_Situation ontology represents all the basic situations whose value is directly defined from the value of a set of tasks. The comp_Situation ontology represents the complicated situations that come from the temporal composition only over other atomic situations, such as the meeting situation is comprised of the presentation and discussion situation. This kind of ontology also can be regarded as a composition using a set of task and other situations; for example, the shopping situation is made up of food-picking situation, including browsing food, deciding the category, comparing price, and the task of payment.

Our model of situation differs from others [20] in that the definition aims at demonstrating how a human perceives the world and himself. With our model, the situation can expose the user-specific information that is usually described as “what happens to who” and “when, where, and why it happens” in natural language. In addition, the model also gives a way to define how the user's task is done. Therefore, it is possible to extract the functions required rapidly, as well as to make the end-user understand the design better by showing the information to them.

4.3. Application Development with Situation Model

The situation-based design (SBD) proposed aims to provide a systematic methodology and adequate tool support for rapid prototyping. Figure 3 illustrates the framework of SBD which covers the phases of application development, including the application analysis, function design, and implementation.

Figure 3

Framework of the SBD.

Initially, the contextual knowledge is identified and structured as the situation model. Then the templates related to user action, task, and situation are derived from the model. In the second phase, a set of the functional and conditional components are identified within the available templates, defining where the template is used to initiate the changes on the programming logic, which enables the application to behave context-aware. As a result, a platform-independent application model which is described in PerDL is generated. The design validation is then conducted by employing such a model generated in context to verify the proposed programming logic. In the application implementation phase, the transformation accepts the proven model as input and produces a target model in JAVA. The final phase is model-to-code generation, where the implementation is created via a code generator and the application code can be deployed and executed in a testing environment.

4.4. Design Validation to PerDL-Based Model

As laid out by Tuttlies et al., “the execution of an application in pervasive computing may affect its physical environment,” what brings the conflicts for the application [18]. They made a good try for conflict avoidance at runtime. Somewhat differently, we concentrate on how to avoid the conflicts during design time by validating the proposed programming logic, which is described as event-condition-action (ECA) rules in PerDL-based model. ECA rules have been applied to build the reactive systems, where the condition is verified if and only if an event can occur, and the action can execute in context [24].

In this paper, we denote a conflict as follows: a conflict occurs for an application if a set condition at design-time is inadmissible in the environment. Therefore, for conflict avoidance, it is necessary to satisfy the developer in terms of the suitability and adequacy of the design. To understand the issue better, the concept of proposition is introduced to identify the precondition (i.e., event) and postcondition (i.e., action). For example, there is a statement of a condition that is “when user goes out of the room, stop playing the media file.” The proposition, thus, of a statement related to the event (i.e., “the user leaves the RoomA currently”) can be denoted as “ $U . location \to NotRoomA$ .” This way, we identify if indeed a specific condition can be met at runtime, just by finding out a set of states relevant to the execution of the application for a proposition and proving that it can be assigned as true.

The construction of the state space model clarifies for us the execution of the application. Kripke structure is then used to characterize the state space model and the change of states involved over time. Taking the navigation application as an example, the model can be considered as a 4-tuple $K = (I, S, R, L)$ , which consists of (i)

a finite set of states $S = {S_{0}, S_{1}, S_{2}, \dots, S_{25}}$ ,

(ii)

a set of initial states $I = {S_{0}}$ ,

(iii)

a transition relation $R \subseteq S \times S$ , $R = {(S_{0}, S_{1}), (S_{1}, S_{1}), (S_{0}, S_{2}), \dots, (S_{24}, S_{2}), (S_{2}, S_{0})}$ ,

(iv)

a labeling function $L : S \to 2^{P}$ , where P is a set of propositions, and there are four kinds of propositions in our example.

Based on the state space model, the line time temporal logic (LTL) is then introduced to prove the statements related to the propositions for the adequacy of programming logic proposed. In particular, there are two properties for these propositions that need to be met.

Property 1.

To $(S_{n}, S_{0}) \in R (n = 1,2, \dots, N)$ , given a condition C set in the design, $P_{i}$ and $P_{j}$ are the propositions that identify the precondition and postcondition of C, respectively. $P_{i} \in L (S_{k})$ which means $P_{i}$ can be assigned as true when the state for an application is $S_{k}$ . Therefore, if $F (S_{k} \to F (S_{n}))$ , then $F (P_{j} \in L (S_{n}))$ .

Property 2.

To $P_{i} \in L (S_{k + 1})$ , $L (S_{k})$ , $P_{i} \notin L (S_{k - 1})$ , if $G ((S_{k + 1}, S_{k + 1}) \in R)$ where $S_{k + 1}$ will be kept for a while, then $P_{i}$ will be assigned as true at this moment.

Property 1 reveals that a desired condition is dependent on a fact, where its postcondition will be met during the state transition from the input state of its precondition to the initial state $S_{0}$ . In addition, Property 2 assures the completeness of design by avoiding the conflicts when the application is stuck in a state.

Therefore, we can conclude that the procedure of design validation where the input state of each condition extracted from the PerDL-based model can be obtained to construct the state transition. The properties proposed are then used to discover the conflicts. Finally, the conditions will be corrected, and the programming logic will be validated.

Taking the statement of condition above as an illustration, its precondition can be revised as “ $\forall U, U . location \to NotRoomA$ ” according to Property 2. It means that the condition will be verified when all the users leave the room. Furthermore, by being validated with Property 1, an unverified condition, that is, to play the media file when the environmental noise is at a low level, can be attached with a new event as its precondition, that is, “ $(P . noise \to low) \land (U . location \to RoomA)$ .” Therefore, a modified condition can be produced as “play the media file when the environmental noise is at a low level, and the user is located in the room.”

The proposed approach starts with a user-centric description where the decomposition of user's needs is driven by the definition and structure of the tasks. It allows the creation of a task-based model for building the application whose structure should be delineated into tasks and subtasks. As a result, the expected function of a service is expressed towards user's requirements. We can conclude that the approach can be aware of the user's needs and reflect the needs into the application development.

5. PerDE Framework-Design Decisions

This chapter presents the design and functionality of PerDE which will serve as the development environment of the design methodology. It should provide the graphical toolsets to ease the creation of pervasive applications by dragging and combining the required modules. These observations lead us to a number of design decisions.

(i) Integrating the Development Process. It is necessary to support the whole process within a development environment, where the lifecycle of an application should be considered. Based on the application and situation model, the PerDE provides a set of toolkits, which enable the developer to make his way to designing, realizing, field deploying, and testing the prototype step by step. Furthermore, the PerDE lowers the barrier to start a user-centric design. That is, to focus on how the user's task can be performed from the beginning, rather than which of the given devices will be used to interact with the user in a specific environment.

(ii) Infrastructure for Rapid Deployment. It is difficult to transfer the functional prototypes into the field experiments rapidly due to the complex real world. To make rapid deployment possible, an infrastructure that enables the applications to interact with the available resources discovered in the environment is necessary. We have addressed the challenges by extending the BASE middleware as the basis of a generic access mechanism of PerDE. Furthermore, the programming logic proposed can be directed to the devices using the event communications.

(iii) Visual Development Tools. Often, it is easy for application development if the interface provided is the mouse-driven and simple drag-and-drop mode without memorizing or typing complicated commands. The PerDE allows the developer to select required components within a fixed set of categories and drag them to fulfill each development task easily.

5.1. Architecture

With the three decisions in place, the architecture of PerDE is structured as shown in Figure 4. The basic idea of PerDE is to design an application with PerDL using graphical toolkits and to complement it with the separated functional components that can be deployed into the testing environment.

Figure 4

System architecture.

The design in the development framework starts with the PerEditor which acts as the ContextEditor and the LogicEditor shown in Figure 3. The ModelCreator which implements the OWLEditor shown in Figure 3 is responsible for building the situation model, while the converter is used in the phase of the application implementation. Based on this component-based prototype, a mapping by using the code generator to the simulation environment, that we named PerVE (pronounced Pe-Ve), will support the rapid deployment and simulation testing. The environment is realized as a virtual 3D world, where the entities are represented as plug-in modules of the OpenSim server. The BASE middleware provides supports for executing the application, including discovering the available services and accessing the device capabilities by allowing the entities to communicate with the aggregators. Furthermore, it enables the functional components to be composed easily and adapt to new changes. The PerDE system also enables a rapid access to all the templates housed in the PerDataBase, such as the PerDL description of the logic as well as the code templates for the transformation.

5.2. Design Time

The PerDE provides the tool supports involved in the entire lifecycle of an application. By referring to Banavar et al.'s work [5], design time, load time, and runtime are selected as the major stages. In terms of design time where the applications will be created and maintained in a user-specific way, the PerDE serves as the guide for representing the structure and creating a rapid functional prototype.

5.3. PerEditor: A Situation-Based Prototyping Tool

With a graphical user interface, the PerEditor enables the functional prototypes to be set up rapidly, without writing any code. There are two steps for interacting with the PerEditor.

(1) Creating the Situation-Based Templates. The PerDE provides the reusable templates used as mediators between the user-specified situation model and the step-by-step development methodology. They are divided into three categories, namely, action, task, and situation, which are described in PerDL. The developer can simply drag the required icons from the tool panel onto the PerEditor and define the corresponding properties. The action template is realized as illustrated in Figure 5, where the precondition and effect of each action will be defined as a description relevant to the contexts which are extracted from the situation model.

Figure 5

Creating the templates using PerEditor.

(2) Constructing the Programming Logic in PerDL. In our approach, the programming logic will be described as a composition of different services in conjunction with the situation-based templates. In order to specify the services abstractly, the PerEditor provides a way to express the expected functions of a service by using a set of components and conditions. A default programming structure for the navigation design is provided. In particular, the situation-based templates are organized as a tree-based model which can be used as the alternatives of transition conditions involved in the logics. Figure 6(a) gives an example where the developer can structure the functions as a set of components, in our case “Detect” and “Show.” And the developer can use the “walking” template as the condition for the transition (Figure 6(a)). Thus, if the effect (i.e., “Position is changed”) introduced by the template is detected at runtime, it will then execute the “Show” component.

Figure 6

Prototyping the programming logic (i.e., the device will start a show when user is near it) using PerEditor.

In order to realize the interactions between the services and instantiate these services on the devices, the device's actions are considered as abstract capabilities. The developer can connect the functional components required and device's capabilities in order to specify what kind of devices each component needs. Figure 6(b) shows an example where a device having the ability to play can execute the “Show” component required by the “DisplayService” service.

(3) Validating the PerDL-Based Prototype. The PerEditor also serves as a support for the design validation. The developer can extract the conditions that will be verified from the PerDL-based prototype and obtain the amended design based on the paths over the state space model. Figure 7 shows the procedure of design validation, which consists of building the KS-based model, discovering the available paths for execution, and correcting the design.

Figure 7

Design validation using PerEditor. The Chinese texts shown are “the state $S_{11}$ is the key state” and “the result of corrected condition,” respectively.

5.4. Load Time

At load time, the PerDE realizes the translation from the PerDL-based prototype to the actual implementation in JAVA.

(1) Creating a Component-Based Prototype Using Convertor. The prototype is created based on a template for the transformation. The template defines the rules to parse the concepts involved in the PerDL-based model, for example, “subcomponent,” “precondition,” and “dependency.” Each component is represented by some code template conforming to the target language.

In particular, a component introduces a set of events and commands that are used to offer the services of a device. The output prototype includes the implementation of specific details which conform to the operational semantics of JAVA. It consists of class definitions, class instances, and the control flows. There are two kinds of classes, that is, “component” and “context”, as well as two kinds of events. The “send_event” is responsible for the communication between the components and devices, while the “receive_event” received from the “EventListener” function is used for the specification of flows between different components. The main part of the prototype is shown in Algorithm 1.

Algorithm 1: The output prototype generated in JAVA.

public interface Display{

public abstract Display();

}

public class DisplayServiceImpl implements Display{

public Display(){

//class instance

Position context1=new Position();

State context2=new State();

Detect comp1=new Detect();

Show comp2=new Show();

//flows

comp1.SentEvent(comp1.sent_event);

while(true){

comp2.EventListener(e);

if(e.equals(context1.event))

break;

}

comp2.SentEvent(comp2.sent_event);

comp2.ContextChange(State,=,OPEN){

context2.refreshValue();}

}

//class definition

class Position extends Context{

interface event=“Position.changed”;

void refreshValue();

void getCurrentValue();

}

class Show extends Component{

interface deviceType= actuator;

interface send_event=“Request.start.got”;

void ContextChange(State,=,OPEN);

void EventListener(event e);

void SendEvent(event e);

}

class State extends Context{

interface event =“State= OPEN”;

void refreshValue();

void getCurrentValue();

}

class Detect extends Component{

interface deviceType= sensor;

interface send_event=“Request.start.got”;

void EventListener(event e);

void SendEvent(event e);

}

(2) Generating an Aggregator-Based Prototype for Deployment. In order to simulate an application in our evaluation system, the output prototype has to be deployed and executed in the simulation environment. The code generator constructs the so-called aggregators that enable a tree-based mapping from the output prototype shown as “script” in Figure 8. The aggregators also employ the message subscription for receiving the sensor data (from simulated as well as from manually activated sensors) and sending the corresponding action commands to the virtual entities. There are two kinds of messages involved in the resulting implementation. The “outgoing” message is responsible for specifying the action, for example, to change the color, and the “incoming” one is used to specify the type of data detected, for example, user's location.

Figure 8

Definition of the aggregators, including the name and the corresponding message. In this case, an instance of “Detect” by defining what kind of sensor data the component can detect and an instance of “Show” by defining which action command the component needs to execute are identified. As a result, a new tree-based model is generated.

5.5. Runtime

At runtime, the developer invokes the prototype and tests its functionality. Therefore, a testing environment in which the application can run and adapt to the variations is necessary.

PerVE: A Testing Environment for Pervasive Computing. In order to allow for the simulated testing, the PerVE emulates the computing and communication capabilities of a real pervasive computing environment. Furthermore, it implements the context awareness by allowing the virtual entities to react to the emulated contexts. Based on the OpenDynamicsEngine, it is possible to simulate the context input. Algorithm 2 illustrates the implementation of simulating the changes over the light intensity, where a command described in Linden Scripting Language (LSL) is given. Algorithm 2 emulates a position sensor where with a timer the distance between the virtual user and device is detected continuously and sent as the message over HTTP. Algorithm 2 is an example where the virtual device reacts to the command (i.e., “to move to a defined spot”) and moves as it could in the real world. By replaying context traces, the experiments can be repeated and the comparison of approaches can be carried out based on the same data or context set.

Algorithm 2

It simulates a contextual input of the light intensity

float_Cycle = 0.5;

float intensity = 0.2;

timer(){

float now = llGetTime();

if ((now−lastCaculate) >= _Cycle)

{

caculate();

lastCaculate = now;

send(“OnLightChanged”,

“ caculate()”);

}

default

{

state_entry()

{

lastCaculate = llGetTime();

llListen(0, “”, “”, “”);

llSetTimerEvent(_Cycle);

timer(); } }

A position sensor is emulated

scan(){

if(scanning != TRUE) {

scanning = TRUE;

llSensor(“”, NULL_KEY, AGENT, _scanRange, PI);}

}

state sensorState{

⋯⋯

timer() {

float now = llGetTime();

if ((now−lastKeepAlive) >= _keepAliveCycle)

⋯⋯

scan();

}

sensor(integer total_number){

integer i;

sensorData = $[]$ ;

for (i = 0; i < total_number; i++){

sensorData = sensorData + $[$ “DETECTEDNAME” + llDetectedName(i)

+ “%%DETECTEDPOSITION” + (string)llDetectedPos(i) $]$ ;}

scanning = FALSE;

}

http_request(key id, string method, string body){

⋯⋯

if (method == “GET”){

writeStandardMsgData();

if (llGetListLength(sensorData) == 0)

msgData += “% $[$ DeviceData $]$ %NODETECT” + “∖r∖n”;

else for (i = 0; i < llGetListLength(sensorData); i++)

msgData += “% $[$ DeviceData $]$ %” + llList2String(sensorData, i) + “∖r∖n”;

llHTTPResponse(id, 200, msgData);}

}

A movement is simulated when the device reacts to a command

integer executeAction(list l){

integer change = FALSE;

string command =

llStringTrim(llToLower(llList2String(l,0)), 1);

if (command == “llmovetotarget”){

change = TRUE;

llMoveToTarget(llList2Vector(l,1),

llList2Integer(l,1));

}

return change;

}

Figure 9 illustrates the simplified infrastructure of PerVE and the way it works. The underlying simulation environment is realized by the OpenSim server as a platform for hosting a virtual world. This world allows the creation and programmability of virtual entities which provide the sensor functionality or acting capabilities of entities, such as the users or devices. The BASE middleware is extended to support the execution of the pervasive applications for rapid testing. (1) It enables the applications to be formed as the services that can abstract the device's communication capabilities; (2) it implements the communication protocols allowing the remote devices to be accessed; (3) it supports the discovery of available services through its own plugins, as well as the redistribution of the communication path to reach the new services.

Figure 9

Infrastructure of the PerVE, where VA, VS, A, and M denote the virtual actuator, virtual sensor, aggregator, and message, respectively.

We developed three additional services to structure the communications between the devices and the applications. The communication service is responsible for the connections to the virtual sensors and actuators, as well as for communicating with them in order to receive the data and send the commands over HTTP. The local management service realizes the subscriptions of an interest in receiving data and stores the data, including the “IncomingMessages.” Furthermore, the service updates the “CapabilitiesRegistry” and distributes the data to other services. The global management service enables the subscriptions of the requirements from the application and forwards them to other services.

6. Evaluation

We evaluate the PerDE in two ways. First, we describe the results of a user study in order to investigate the usability of PerDE based on a health care application. Second, we show how the PerDE enables the developer to build an application rapidly based on complexity measurements using the navigation application discussed in our earlier work [22].

6.1. User Study

To understand the usability of the PerDE better, we had ten experienced programmers use the system and give us their feedback. Most users were slightly familiar with the notion of situation, but none had ever built a situation-based application or a similar approach before. They were asked to build a (simple) smart healthcare application where a proactive reminder is delivered when a defined situation occurs; that is, a medication has to be taken. Figure 10 shows the expected solution for rapid development given by ten participants before proceeding with this test. It reveals that the PerDE is consistent with the requirement of the development of pervasive applications.

Figure 10

Survey on the expectations of system's usability.

Table 2 shows the averaged scores of a small questionnaire after completing the development. The user study shows that the approach is effective and confirms that the PerDE is a usable system. Beyond this success, there were two noticeable cases in the user studies. First, it took quite a long time to introduce the idea of the situation to the users. Most users had no idea of user-centric design. They had no experience in analyzing users and their tasks, and that is why we got 3.8 points in Table 2. But the users showed an improved performance in completing the second template. Second, they requested the changes in the PerVE, for example, a functionality to configure the contexts in the physical world. Two users claimed that to test in PerVE successfully requires experience and intimate familiarity with OpenSim. Therefore, they gave us 4 points.

Table 2

Average score. 5 = accredit strongly; 4 = accredit; 3 = neutral; 2 = deny; 1 = deny strongly.

	Questions	Score
Design approach and tools	I'm interested in the approach	3.8
	No need to care about the underlying data	5.0
	I'm satisfied with rapid development	4.8

Evaluation tools	It is useful to simulation testing	4.0

All	It is easy to use the PerDE	4.6
All	I will use it again	4.8

In addition, the ease of construction of the PerVE was mentioned. In particular, it can be done by simply recompiling the “configuration” module, without configuring the BASE middleware manually.

6.2. Performance Analysis

To validate the supports in rapid development, a CCCC tool, C and C++ Code Counter [25], is introduced to analyze the performance in the reduction of time and efforts on the development. The CCCC tool is a tool which analyzes C++ and Java files and generates a report on various metrics of the code. Two metrics, that is, the lines of code (LOC) and cyclomatic complexity (CycloC), are used to conduct the testing on different implementations of the navigation application in JAVA and J2ME. Table 3 shows the results, where 84.9% and 73% codes can be generated automatically, according to the evaluation with LOC. Furthermore, the results of a comparison of the CycloC illustrate that the prototype generated carries a low complexity. However, this can mainly be attributed to the fact that the generated code is rather simple.

Table 3

Effectiveness of the PerDE system.

	Metrics	Code generated automatically		All code
	Metrics	Overall	Per module	Overall	Per module
JAVA	LOC	4096	146.285	4820	155.484
	CycloC number	45	1.607	61	1.968
	Module number	28	/	31	/

J2ME	LOC	4683	114.220	6413	128.260
	CycloC number	117	2.857	148	2.960
	Module number	41	/	50	/

The PerDE provides two kinds of communication modes, that is, XML-RPCs and HTTP, for enabling the applications to be executed in the simulator. It is crucial that the interaction between the functional components and simulation environment is not delayed to allow the proper tests.

Two experiments were conducted by running the application with two modes, and the results were calculated from 100 samples. With the optimization of some setting, the average response time lies within 24 ms for the XML-RPC and 23 ms for the HTTP-based communication. For most interactions in the distributed pervasive applications, this is a tolerable overhead.

6.3. Scalability

The PerDE can be integrated into an existing development environment, such as the plugins in Eclipse, that enables it to work with other toolkits. It is necessary to extend the testing system for simulating the more complex, powerful features. To the best of our knowledge, very little research has been done about the scalability of a simulated testing system. One exception is the work of Barton and his colleagues [16], which argues that it will take a programmer familiar with the system a day to tailor the existing virtual entities to new requirements. However, the PerDE enables the developer to visualize the construction of new sensors and actuators that will help in keeping the development cost down.

7. Conclusion

The design methodology is presented as a guide for pervasive application development. It provides a means to structure the application and allows the developer to leverage the notion of a situation as a way for constructing the programming logic. The PerDE, a novel development environment, provides the method and tools to support the whole process, from design, validation, field deployment, and prototype testing.

In the future, we are going to provide more evidence to show the usability of PerDE. We also want to integrate the suggestions from the user study and work on a broader set of templates, along with employing the approach and tools to more complex applications. We desire to carry out the additional design validation studies with actual customer's requirements.

Footnotes

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgments

This work is partially funded by National Natural Science Foundation of China (no. 61303041, 61222209, 61332013, 61332005), the Scientific Research Foundation for the Returned Overseas Chinese Scholars in Shaanxi Province of China, and the Specialized Research Fund for the Doctoral Program of Higher Education (no. 20126102110043).

References

Edwards

W. K.

Bellotti

Dey

A. K.

Newman

M. W.

Stuck in the middle: the challenges of user-centered design and evaluation for infrastructure

Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ′03)

April 2003

ACM

297 304

2-s2.0-0038375555

Lugmayr

Serral

Scherp

Pogorelc

Mustaquim

Ambient media today and tomorrow

Multimedia Tools and Applications 2013 1 31

10.1007/s11042-012-1346-z

Henricksen

Indulska

Developing context-aware pervasive computing applications: models and approach

Pervasive and Mobile Computing 2006 2 1 37 64

2-s2.0-32044450086

10.1016/j.pmcj.2005.07.003

Heider

Kirste

Smart environments and self-organizing appliance ensembles

Mobile Computing and Ambient Intelligence 2005

New York, NY, USA

Springer

Banavar

Beck

Gluzberg

Munson

Sussman

Zukowski

Challenges: an application model for pervasive computing

Proceedings of the 6th Annual International Conference on Mobile Computing and Networking (MobiCom ′00)

August 2000

ACM

266 274

2-s2.0-0034539097

Tang

Zhou

Wang

Becker

Supporting rapid design and evaluation of pervasive applications: challenges and solutions

Personal and Ubiquitous Computing 2011 15 3 253 269

2-s2.0-79956139832

10.1007/s00779-010-0332-6

Schmidt

Terrenghi

Holleis

Methods and guidelines for the design and development of domestic ubiquitous computing applications

Pervasive and Mobile Computing 2007 3 6 721 738

2-s2.0-35649021680

10.1016/j.pmcj.2007.07.002

Davies

R. J.

Nugent

C. D.

Donnelly

M. P.

Hettinga

Meiland

F. J.

Moelaert

Mulvenna

M. D.

Bengtsson

J. E.

Craig

Dröes

R.-M.

A user driven approach to develop a cognitive prosthetic to address the unmet needs of people with mild dementia

Pervasive and Mobile Computing 2009 5 3 253 267

2-s2.0-67349167073

10.1016/j.pmcj.2008.07.002

Abowd

G. D.

Hayes

G. R.

Iachello

Kientz

J. A.

Patel

S. N.

Stevens

M. M.

Truong

K. N.

Prototypes and paratypes: designing mobile and ubiquitous computing applications

IEEE Pervasive Computing 2005 4 4 67 73

2-s2.0-30344440798

10.1109/MPRV.2005.83

10.

Fitton

Cheverst

Kray

Dix

Rouncefield

Saslis-Lagoudakis

Rapid prototyping and user-centered design of interactive display-based systems

IEEE Pervasive Computing 2005 4 4 58 66

2-s2.0-30344478816

10.1109/MPRV.2005.85

11.

Weis

Knoll

Ulbrich

Mühl

Brändie

Rapid prototyping for pervasive applications

IEEE Pervasive Computing 2007 6 2 76 84

2-s2.0-34247338508

10.1109/MPRV.2007.41

12.

Hess

C. K.

Romàn

Campbell

R. H.

Building applications for ubiquitous computing environments

Pervasive Computing 2002 2414

New York, NY, USA

Springer

16 29 Lecture Notes in Computer Science

10.1007/3-540-45866-2_3

13.

Dey

A. K.

Sohn

Streng

Kodama

iCAP: interactive prototyping of context-aware applications

Pervasive Computing 2006 3968 254 271 Lecture Notes in Computer Science

10.1007/11748625_16

14.

Kawsar

Nakajima

Fujinami

Deploy spontaneously: supporting end-users in building and enhancing a smart home

Proceedings of the 10th International Conference on Ubiquitous Computing (UbiComp ′08)

September 2008

ACM

282 291

2-s2.0-59249104629

10.1145/1409635.1409673

15.

Landay

J. A.

Activity-based prototyping of ubicomp applications for long-lived, everyday human activities

Proceedings of the 26th Annual CHI Conference on Human Factors in Computing Systems (CHI ′08)

April 2008

ACM

1303 1312

2-s2.0-57649146799

10.1145/1357054.1357259

16.

Barton

J. J.

Vijayaraghavan

UBIWISE, a Simulator for Ubiquitous Computing Systems Design 2002

HP Laboratories

17.

Lugmayr

Zou

Stockleben

Lindfors

Melakoski

Categorization of ambient media projects on their business models, innovativeness, and characteristics—evaluation of Nokia Ubimedia MindTrek Award Projects of 2010

Multimedia Tools and Applications 2013 66 1 33 57

10.1007/s11042-012-1143-8

18.

Tuttlies

Schiele

Becker

Comity-conflict avoidance in pervasive computing environments

On the Move to Meaningful Internet Systems 2007: OTM 2007 Workshops 2007 4806 763 772 Lecture Notes in Computer Science

10.1007/978-3-540-76890-6_2

19.

Reymann

Alves

D. S.

Lugmayr

Personalized social networking: an applied scenario in a portable personality environment

Proceedings of the 12th International MindTrek Conference: Entertainment and Media in the Ubiquitous Era (MindTrek '08)

October 2008

ACM

172 176

2-s2.0-70450277454

10.1145/1457199.1457237

20.

Bruegger

Lalanne

Lisowska

Hirsbrunner

Tools for designing and prototyping activity-based pervasive applications

Proceedings of the 7th International Conference on Advances in Mobile Computing and Multimedia (MoMM ′09)

December 2009

ACM

129 136

2-s2.0-77955111669

10.1145/1821748.1821778

21.

Dey

A. K.

Understanding and using context

Personal and Ubiquitous Computing 2001 5 1 4 7

22.

Tang

Zhou

Becker

Situation-based design: a rapid approach for pervasive application development. Ubiquitous intelligence

Proceedings of the Ubiquitous Intelligence & Computing and 9th International Conference on Autonomic & Trusted Computing (UIC/ATC ′12)

September 2012

Fukuoka, Japan

IEEE

128 1135

10.1109/UIC-ATC.2012.58

23.

Yau

S. S.

Liu

Hierarchical situation modeling and reasoning for pervasive computing

Proceedings of the 4th IEEE Workshop on Software Technologies for Future Embedded and Ubiquitous Systems, SEUS 2006 and the 2nd International Workshop on Collaborative Computing, Integration, and Assurance (WSTFEUS ′06)

April 2006

Gyeongju, Korea

2-s2.0-33750922895

10.1109/SEUS-WCCIA.2006.25

24.

Vanderhulst

Development and deployment of interactive pervasive applications for ambient intelligent environments [Ph.D. thesis] 2010

Hasselt, Belgium

Hasselt University

25.

Achilleos

Yang

Georgalas

Context modelling and a context-aware framework for pervasive service creation: a model-driven approach

Pervasive and Mobile Computing 2010 6 2 281 296

2-s2.0-77950187601

10.1016/j.pmcj.2009.07.014

Methodology and Tools for Pervasive Application Development

Abstract

1. Introduction

2. Related Work

2.1. Methodology Support

2.2. Tool Support

3. Requirement of Developing Pervasive Applications

4. Methodology for Developing Pervasive Applications

4.1. User-Centric Application Model

4.2. Situation Model

4.3. Application Development with Situation Model

4.4. Design Validation to PerDL-Based Model

Property 1.

Property 2.

5. PerDE Framework-Design Decisions

5.1. Architecture

5.2. Design Time

5.3. PerEditor: A Situation-Based Prototyping Tool

5.4. Load Time

Algorithm 1: The output prototype generated in JAVA.

5.5. Runtime

Algorithm 2

6. Evaluation

6.1. User Study

6.2. Performance Analysis

6.3. Scalability

7. Conclusion

Footnotes

Conflict of Interests

Acknowledgments

References