A Context-Driven Development Methodology for Context-Aware Systems Jongmyung Choi1, Rosa I. Arriaga2, Hyun-Joo Moon3, and Eun-Ser Lee4,* 1
Computer Engineering, Mokpo National University, 61 Cheonggye, Muangun, Jeonnam, 534-729, Korea
[email protected] 2 School of Interactive Computing, Georgia Institute of Technology, 85 5th Street NW, Atlanta, GA 30332, USA
[email protected] 3 Cultural Contents, Hankuk University of Foreign Studies, 270 Imun-Dong, Dongdaemun-Gu, Seoul, 130-791, Korea
[email protected] 4 Computer Engineering, Andong National University, 388 Songcheon-dong, Andong-city, Gyeongsangbuk-do, 760-749, Korea
[email protected]
Abstract. Context-aware systems demand a customized development methodology because they have their own features such as ambiguous system scope, context modeling, and implementing context-dependent services. Furthermore, it has been known that these systems are more complex than traditional systems. In this paper, we meet this challenge by extending the unified process (UP), and add three workflows: context requirements, context modeling, and context testing. At each workflow, stakeholders analyze, model, and test for the perspective context. We also provide guidelines for task performance, artifact production and development specifications for each stage of the context. Our methodology supports the full development process and the best practice technologies including OOP, UML, and UP. Keywords: Context-aware system, Development Methodology, Unified Process (UP).
1 Introduction A context-aware system perceives the context and provides services that are adapted to the context. The context includes variables such as location, time, user inputs, sensed values from the external environment, or the internal states. These systems are receiving increased attention from academia to industry because of their ability to provide smart and value-added services. Context-aware systems are inherently complex. If a context-aware system has N variation points and M different contexts, then the system will have N x M more modules for developers to implement. Furthermore, these systems have additional *
Eun-Ser Lee is the corresponding author of this paper.
G. Lee, D. Howard, and D. Ślęzak (Eds.): ICHIT 2011, LNCS 6935, pp. 429–436, 2011. © Springer-Verlag Berlin Heidelberg 2011
430
J. Choi et al.
modules including sensor modules and context inference modules. The complexity makes it more difficult to analyze requirements and to design solutions. There have been a few researchers that have attempted to develop systematic approaches (i.e., methodology) to solving these software engineering problems [1-4]. These methodologies, however, have two main limitations. First, they do not provide detailed information such as artifact list, usage guidelines, advices, and tips for system development. Second, they do not support the unified process (UP), which is widely used in industry [5]. In order to address these problems, we extend our previous work [2-4] and develop a methodology that includes process, artifact list, advice, and techniques for software development tasks [6]. Our context-driven methodology follows an extension of the unified process by adding context requirement, context modeling, and context testing workflows. We add context related workflows because the context influences all the phases of the software development process [8]. In addition, the context is an important factor in producing artifacts at each stage in the process. Our proposed workflows proceed as follow. At the context requirements workflow, analysts gather context information from business requirements and identify candidates for context-aware services from business use cases. At the context modeling workflow, designers model context from the context information to meet system requirements. Finally, in context testing workflow, testers checks whether the system works properly according to context changes. This paper has three main contributions to the field of context awareness research. First, we highlight the importance of the context in system development; so that we make it sure stakeholders take care of context in requirement elicitation and system design. Second, we introduce a context-driven methodology which can be applied to the whole development phase. Third, we show how to apply the unified process to context-aware system development. The remainder of the paper is organized as follows. In Section 2, we discuss relevant research. Then we introduce the development process in Section 3. After that we explain the details of the development process in Section 4, and evaluate our proposal in Section 5. Finally, we present our conclusion in Section 6.
2 Related Work We classify existing related researches into two groups: software engineering related researches and development methodology related researches. The first group is about software engineering topics for context-aware systems including requirements elicitation [7], software architecture [9, 10], context modeling [11, 12], toolkit or middleware [13, 14], programming [15], and testing [16]. Even though there have been many researches on software engineering topics, they only provide information piece by piece, so developers have difficulties in applying the information to the real system development. In contrast, our work discusses important issues occurred during the whole development process. There have been not many researches of the second group. Karen’s work [1] and our previous work [2-4] are representative. Karen shows the development process and the tasks to be done at each stage. Our previous work shows also the development process and the detailed tasks to do at each stage. However, these works do not support the unified process.
A Context-Driven Development Methodology for Context-Aware Systems
431
3 Introduction to Context-Driven Methodology 3.1 Needs for a New Methodology In software system practice, a good development methodology is essential to successful and cost efficient development of good quality products. Context-aware systems have their own features [8], and they are much more complex than the traditional systems. Furthermore, domain specific development methodologies are getting popular. To meet these trends and needs, we need a new development methodology for context-aware systems. In contrast to the traditional services, a context-aware service has multiple implementations because it should provide different services according to the contexts.
Fig. 1. Traditional Service
Fig. 2. Context-aware Service
Fig. 2 shows a depiction of the context-aware service. It has two components: commonality and variation [17]. The commonality part is context independent, but the variation part is context dependent, so there are multiple implementations for the , , and represent the context specific service variation part. In Fig. 2, implementations, and they are branched at variation points according to the context. For context-aware systems to grow as industry-wide applications from prototype systems in the laboratories, developers should have software engineering methodologies that are specific to context-aware systems. The methodologies should be suitable for context-aware systems and they should also be similar to the existing methodologies to reduce learning costs. 3.2 Development Process The process of our methodology is an extension of the unified process and it is twodimensional. Our process is based on the unified process because it is widely accepted
Fig. 3. Context-Driven Development Process
432
J. Choi et al.
and is the industry standard. We extend it by adding some tasks to the unified process as shown in Fig. 3. In the figure, the X-axis means the time sequence and the Y-axis means the workflow (or disciplines) to be done. We add context requirements analysis, context modeling, and context testing tasks to the original unified process.
4 Context-Driven Methodology 4.1 Inception Phase Overview. At the inception phase, stakeholders define the project’s scope and estimate overall costs and major risks. They also determine the contexts that they care about by analyzing business model and business requirements. Business Modeling. The first tasks are to understand the business process and rules and to gather business information. This activity is the same as the traditional business modeling because it is about the existing business. Business Requirements. Analysts gather requirements from stakeholders, make a list of use cases, and document them in detail. Use-cases should be chosen in order of importance. The important ones include use cases that are context-sensitive, of high risk, and of high priority in business. During this phase they identify candidates for context-aware services from the use cases. The main artifacts of business requirements are a business use case diagram, detailed use cases, a list of candidates for context-aware services, and nonfunctional requirements. Context Requirements. Context requirements workflow is a new activity proposed in our methodology. The main purpose of this workflow is for business analysts to gather context information from previously identified context-sensitive use cases. They also classify and group context information into context, and model context. The main artifacts of this workflow are the terminology of context information and the relationship between context information and the context-sensitive use cases that are specific to the business. Analysis. In analysis activity, analysts consider system use cases and the draft solutions. Analysts perform two main tasks: determining the system platform and making context-aware use cases. Based on the main service scenario and context information, stakeholders determine the system’s main platform and the contextaware service scope. The main artifact of this step is the context-aware use case diagram that is a use case diagram with context information [7]. Fig. 4 shows an example of context-aware use case diagram. It shows use case, platform, context information, and context-aware service types.
Fig. 4. Context-aware Use Case Diagram
Fig. 5. Context Diagram
A Context-Driven Development Methodology for Context-Aware Systems
433
Implementation. In inception phase, developers need to implement a prototype system for concept proof. For context-aware systems, developers need to implement context-aware services. Test. Testers need to establish test cases for acceptance tests. For context-aware services, they need to test a service for each context and a seamless switch among multiple contexts. Tip. First, gather critical business use cases and find out whether they are contextsensitive or not by applying context-aware service patterns [4, 7]. For contextsensitive use cases, make scenario for context-aware services and gather context information. Artifacts. The main artifacts of this phase include vision document for the project, use case list, domain model, context-aware use case diagrams, and context information. 4.2 Elaboration Phase Overview. At the elaboration phase, stakeholders analyze the problem, define system architecture, and implement core architecture. Business Modeling. Analysts capture business process and rules and finish the business modeling. Business Requirements. In elaboration phase, analysts also gather more business requirements in detail and specify them using use cases, use case diagram, and other specification method. Context Requirements. In elaboration phase, context requirements workflow has two main tasks. The first one is to gather context information and group the information into similar groups preparing context modeling. The second one is to elicit context requirements [8]. Context requirements are similar to nonfunctional requirements; however they are closely related to context. Context extensibility, context openness, and context reasoning are typical examples of context requirements. These context requirements influence to determine the system architecture, context modeling, and implementation. The main artifacts of this workflow are context information group, the relationship between context information and use cases, and context requirements. Context Modeling. In elaboration phase, context designers determine the context model. The context model should be designed to meet functional/nonfunctional requirements. For example, the system needs inference feature and extensibility nonfunctional requirements; Designers should consider an ontology model or a predicate logic model for context modeling. The main artifact of this workflow is a context diagram [7]. Fig. 5 shows an example of a context diagram. It is a context diagram for the smart phone. In the figure, context set, C, for a smart phone is defined as C= {normal, busy}. “Normal” and “Busy” are two contexts of the phone, and they are instances of a context type, i.e. User State. A context may have several implementations because of its context attribute set. In the figure, “Sensor A type” and “Sensor B type” implement the “Normal” context. Analysis. At the analysis workflow, two tasks should be performed. The first one is for architects to determine the system architecture. The architecture should meet not only functional/nonfunctional requirements but also context requirements. Context
434
J. Choi et al.
requirements influence system architecture and there is research on context-aware system architectures [9, 10]. The second one is for designers to perform system design including preliminary class design and ER modeling for database design. The main artifacts of this workflow are the system architecture, preliminary class diagram, and preliminary ER model. Design. In the elaboration phase, designers make systems designs in detail. They define classes and class diagram for static view and interaction diagram for dynamic view. They also define ER diagram for database. From the context-aware systems’ view, designers should consider how to realize context diagram using possible solutions: classes, aspects, ontology, value sets, and other techniques. This is related to the implementation of the variation points. When they adopt classes for context, they can utilize design pattern of object-oriented technology [18]. Similarly, when they adopt aspect, they can utilize inter-weaving technology of aspect-oriented technology [15]. However, when they adopt value set, they may use if-then rules for variation points. In the design workflow, the relationship among the context, contextaware service, and context-specific service should be clearly defined and the framework for their co-working mechanism is designed. It means that the interaction mechanism and APIs should be defined. The main artifacts are detailed class diagram, ER diagram, and other detailed designs. Implementation. In the elaboration phase, the implementation is performed base on the architecture and context model. The first step is to implement the basic architecture framework. If the framework is built, the context and context-specific services can be implemented in the same way as traditional systems. Test. Intensive testing is performed for the architecture and framework. Tip. In the elaboration phase, the system architecture and the frameworks for contextaware services should be determined and their core parts should be implemented. Furthermore, designers should determine context model and its realization methods. For simple system, name-value pair modeling is enough. However, for systems with massive context information, ontology model is suitable. Artifacts. The main artifacts of elaboration phase are use cases, context model, architecture, class diagram, ER diagram, and subversion systems. 4.3 Construction Phase Overview. At construction phase, programmers implement modules, test them, and integrate them into the whole system. They release beta versions and evaluate whether they meet the acceptance test. Implementation. In the construction phase, developers finish the framework implementation and implement subcomponents and detailed services. The implementation task in context-aware system is very similar to that of traditional systems. Test. In the construction phase, testing is mainly focused on unit testing and integrated testing. In unit testing, context-aware service module should be tested to check that the module operates correctly for a given context. In integrated testing, the integrated subsystem should be tested to check that it operates correctly for the given contexts. Tester should check the context switch and the context-aware service switch.
A Context-Driven Development Methodology for Context-Aware Systems
435
5 Evaluation Our methodology provides good quality assurance measures for context-aware systems, but we don’t have yet practical or quantitative evaluations of this methodology. We have plans to apply this methodology to practical system development in the future. Our context-driven methodology however can be evaluated from the perspective of practical development technologies. Table 1 presents the evaluation result of our methodology compared to other approaches. It shows that our methodology supports object-oriented techniques, UML, full development process, and the unified process, and context modeling. Table 1. Evaluation of Methodologies for Context-aware Systems
◎: Support, O: Partially Support, X: Not Support Items OOP UML Full Process UP Context Model
Our Proposal
◎ ◎ ◎ ◎ ◎
Karen’s work O X O X
◎
Previous Work
◎ ◎ O X
◎
6 Conclusions Context-aware systems are becoming more prominent but until now developers have not paid much attention to the context in the perspective of software engineering. However, development methodology for context-aware systems is necessary for costefficient development with good quality. In this paper, we introduced a context-driven development methodology. With this methodology, analysts capture critical business use cases and identify contextsensitive use cases from them at the inception phase. During the elaboration phase, analysts gather context information and context designers develop context modeling to meet functional/nonfunctional requirements. On the construction phase, programmers implements context-sensitive services and performs unit testing. At the transition phase, testers perform testing whether the context-aware services perform well according to the context and the context switch. Our context-driven methodology provides the full process of UP extension and object-orientation approach.
References 1. Henricksen, K., Indulska, J.: Developing Context-Aware Pervasive Computing Applications: Models and Approach. Pervasive and Mobile Computing 2(1), 37–64 (2006) 2. Choi, J., Moon, H.-J.: Software Engineering Issues in Developing a Context-aware Exhibition Guide System. In: Proc. of SNPD (2008)
436
J. Choi et al.
3. Choi, J., Moon, H.-J., Cho, S.-U.: A Development Methodology for Context-aware Systems. In: Proc. of ICUT (2008) 4. Choi, J.: A Case Study of Applying Software Engineering Development Methodology to a Context-aware System. Journal of KIISE (2009) 5. Jacobson, I., Bylund, S.: The road to the unified software development process. Cambridge University Press, Cambridge (2000) 6. O’Docherty, M.: Object-Oriented Analysis and Design, p. 100. John Wiley & Sons, Chichester (2005) 7. Choi, J.: Context-driven Requirements Analysis. In: Gervasi, O., Gavrilova, M.L. (eds.) ICCSA 2007, Part III. LNCS, vol. 4707, pp. 739–748. Springer, Heidelberg (2007) 8. Choi, J.: Context: From Birth to Design. In: Proc. of ALPIT, pp. 347–352. IEEE, Los Alamitos (2008) 9. Dockhorn Costa, P., et al.: Architectural Patterns for Context-Aware Services Platforms. In: Proc. of 2nd Int’l Workshop on Ubiquitous Computing (2005) 10. Choi, J.: Software Architecture for Extensible Context-Aware Systems. In: Proc. of ICHIT, pp. 811–816. IEEE, Los Alamitos (2008) 11. Sheng, Q.Z., Benatallah, B.: ContextUML: A UML-Based Modeling Language for ModelDriven Development of Context-Aware Web Services. In: Proc. of ICMB (2005) 12. Hendricksen, K., Indulska, J., Rakotonirainy, A.: Generating context management infrastructure from high-level context models. MSM, 1–6 (2003) 13. Salber, D., Dey, A.K., Abowd, G.D.: The Context Toolkit: Aiding the Development of Context-Enabled Applications. In: CHI 1999, pp. 15–20 (1999) 14. Roman, M., et al.: Gaia: A Middleware Infrastructure to Enable Active Spaces. IEEE Pervasive Computing, 74–83 (October-December 2002) 15. Francisco, D., Thais, B., Nelio, C.: Towards Aspect-Oriented Programming for ContextAware Systems: A Comparative Study. In: Proc. of SEPCASE (2007) 16. Flores, A., Augusto, J.C., Polo, M., Varea, M.: Towards Context-aware Testing for Semantic Interoperability on PvC Environments. In: Proc. of SMC (2004) 17. Capilla, R.: Context-aware architectures for building service-oriented systems. In: Proc. of Software Maintenance and Reengineering (CSMR), pp. 300–303. IEEE, Los Alamitos (2006) 18. Rossi, G., Gordillo, S., Lyardet, F.: Design Patterns for Context-Aware Adaptation. In: Proc. of Applications and the Internet Workshops, pp. 170–173 (2005)
