Towards A Futuristic Pervasive Computing Reference Architecture: The Vision and Approach Osama M. Khaled1, Hoda M. Hosny2, and Mohamed Shalan3 123
Computer Science and Engineering Department, The American University in Cairo, Egypt 1
[email protected], 2
[email protected], 3
[email protected]
Abstract— In this paper we present our research approach to generate a futuristic pervasive computing reference architecture (FPCRA). It embodies an innovative approach to resolve most of the domain’s current challenging problems. A business reference architecture, a technical reference architecture, and an evaluation method are the main outcomes of the research phases. We completed the business reference architecture and are currently working on the remaining phases. (Abstract) Software Architecture; Reference Architecture; Pervasive Computing; Ubiquitous Computing (key words)
I.
A
INTRODUCTION
good software architecture is one of the most difficult tasks to achieve when building a pervasive computing system. A pervasive system is inherently challenging by nature as it faces, almost, all kinds of challenges. The high level of intelligence, volatility, mobility, context-awareness, adaptable behavior, security, and privacy are some of these challenges. A unified and common architecture can pave the road for quick and mature implementations. It is widely known as a reference architecture, which provides a basic architecture skeleton for building a robust system. Given the dozens of challenges in this domain, generating this kind of architecture is considered one of the most difficult tasks. The next sections will give a high level briefing about our vision to build a reference architecture for pervasive computing. Section II explains the research problem that we address. Sections III, IV, and V present our approach towards building a futuristic reference architecture. The conclusion summarizes our research progress so far and our future plans. II.
RESEARCH QUESTION
The literature includes definitions for a Practice Reference Architecture (PRA) and a Futuristic Reference Architecture (FRA) [1]. A PRA tries to capture the best practices from existing architectures along with architecture patterns in order to facilitate the implementation of concrete architectures. Its intent is to resolve time-to-market and standardization problems. On the other hand, a FRA is built to become the first type. It must be based on research and it has to introduce innovative ideas [1]. Once an FRA is implemented as a concrete architecture it becomes an immature PRA, which
encourages others to adapt it and make more implementations to transform it finally into a PRA. In this research work, our aim is to create a Futuristic Reference Architecture that captures best practices and that introduces innovative architectural solutions. The FRA that we intend to build will have a vision about the expected systems that could be built using this RA. Hence, the focal point that this research addresses may be summarized as follows: With the fast spread of pervasive systems there is a strong need for a futuristic reference architecture for pervasive computing systems that encompasses all architectural challenges and that can be applied/adapted in different business contexts as a generic model with innovative and clear understanding about their relative priorities. III.
THE BUSINESS REFERENCE ARCHITECTURE
In order to achieve our goal, we will start by building the business architecture. The business architecture will include a basic requirements model based on our research which covered 11 cross-cutting quality features and 3 business domains. The eleven quality features are adapted from [2] and they are : 1) Adaptive behavior 2) context sensitivity 3) experience capture 4) fault tolerance 5) heterogeneity of devices 6) invisibility 7) privacy and trust 8) quality of service 9) safety 10) security and 11) service omnipresence. The three business domains are adapted from [3] and they are: i) learning ii) emergency and iii) retail. The first issue that we will consider in our business architecture is the quality attributes and their values. Then we will analyze them deeply enough to get into their essence. We will then address the above mentioned business domains with different use cases. After that we will conduct a trade-off analysis study among the quality features and between the quality features and the business domains. We will finally generate a conceptual model for pervasive systems. The business architecture will be represented using the SysML modelling language [4]. IV.
THE TECHNICAL REFERENCE ARCHITECTURE
We shall proceed after that to perceive how the business architecture can lead to different architectural decisions. The guidelines will give directions for architecture patterns, design
patterns, deployment topologies, technology and most importantly explaining the reasoning for selecting these architectural solutions. Our perception of these elements is as follows: 1) Architecture Patterns: a collection of high-level architectural patterns that can help system engineers or software engineers build a robust pervasive system architecture. 2) Design Patterns: design patterns are more useful for the software model part. They capture important knowledge that should be useful for the software design. 3) Deployment Topologies: a computing system is composed of scattered devices connected through a network. We will study the different network topologies and address architectural constraints that could be found in different contexts. 4) Technology: it is only logical to touch on different technologies since they define an important part of the architectural design decisions. These technologies will include, but are not limited to, smart objects, passive objects, and communication media 5) Design Decision Guidelines: the high level guidelines for the target users to select the most appropriate solution based on the context of the problem. At the end, we will propose a base-line architecture that contains basic design blocks which are essential for building pervasive computing systems. It should also be a good starting point for any architect willing to build a new concrete architecture for specific business problems. Architectural elements will be linked with the business architecture elements. V.
EVALUATION
There are different approaches to evaluate a reference architecture or a concrete architecture. Since we are going to produce documents and technical architectural models then we need to adopt a hybrid approach that combines between subjective and quantitative evaluation techniques. The evaluation cycle, should answer the following questions: 1) Is it an acceptable FPCRA by the software development community? To answer this question, some of the development community from different backgrounds and different experience levels will need to be involved in a subjective evaluation cycle for the RA. Architects, business analysts, designers, developers, and testers will be asked to go through the RA, give their comments, and answer a survey that assesses the satisfactory levels about the artifacts. 2) Is it a complete FPCRA? We will map design elements to the requirements model to ensure that what is required is satisfied by the technical architecture. 3) Is it a good FPCRA? To answer this question, a quantitative evaluation of the baseline architecture will be conducted to evaluate the architecture’s quality metrics. These include: a) Coupling: It measures the relationship of dependency between two interacting modules. b) Cohesion: It evaluates the tightness between the linked features composing a system or module.
c) Complexity: It is used as a metric to evaluate how the system or module is complex. d) Modifiability: It evaluates to what extent the components could withstand changes without affecting the whole system. e) Modularity: It evaluates whether the system is built on modular basis or not. f) Reusability: It evaluates if the components in the system can be used in another system without major changes. 4) How good is the technical architecture compared to similar ones generated by experts? A group of architects with different experience levels will be invited to generate architectural baseline models based on the business reference architecture. The generated architectures will be evaluated quantitatively. 5) Will it be a good technical architecture as expected during the runtime trials? We will assess the architecture’s quality during runtime by running simulation experiments to analyze the quality of the architecture and its impact on desired pervasive computing desired features as defined in the business architecture. We will initially adopt the same conceptual model mentioned in [5]. The results of the simulation will be used to enhance the baseline architecture, if required. VI.
CONCLUSION
We have so far completed the business reference architecture study and results conform to our understanding that it is an essential step towards building a full-fledged FPCRA. We built an innovative and flexible list of priorities for the quality features using a statistical approach based on the relationships defined in the requirements model. We are now building the artifacts of the first phase to arrive at the technical reference architecture. We completed a variability analysis study to discover the possible design decisions. We still need to fully define the technical reference architecture before we begin the challenging and difficult phase of evaluating the reference architecture. References [1] Samuil Angelov, Jos J. Trienekens, and Paul Grefen. “Towards a Method for the Evaluation of Reference Architectures: Experiences from a Case”, in Proceedings of the 2nd European conference on Software Architecture (ECSA '08), Ron Morrison, Dharini Balasubramaniam, and Katrina Falkner (Eds.). Springer-Verlag, Berlin, Heidelberg, 225-240. [2] R. Spínola, and G. Travassos. “Towards a framework to characterize ubiquitous software projects”, Information and Software Technology, v. 54, 2012, pp. 759-785. [3] M. Hamza and S. Aly. “A Study and Categorization of Pervasive Systems Architectures Towards Specifying a Software Product Line”, In Proceedings of Software Engineering Research and Practice. 2010, 635641. [4] OMG Systems Modeling Language (OMG SysML) version 1.3. http://www.omg.org/spec/SysML/1.3/. Date: 01-06-2012. [5] Verónica Bogado, Silvio Gonnet, and Horacio Leone (2011). “A Discrete Event Simulation Model for the Analysis of Software Quality Attributes”, CLEI Electronic Journal, vol. 14, Number 3, paper 3, December 2011.
