diagrams were then aggregated using known design patterns to generate the architecture in question. Key words: pervasive, architectural features, reference.
An Approach for Generating Architectures for Pervasive Systems from Selected Features Mostafa Hamza, Sherif G. Aly, Hoda Hosny Department of Computer Science and Engineering The American University in Cairo, Cairo, Egypt {hamza, sgamal, hhosny}@aucegypt.edu
Abstract - In this paper, we present a feature-driven approach for generating pervasive systems architectures. Our approach is based on the methodology for automatic generation of pervasive systems architectures from a predetermined architectural feature set. A set of pervasive systems architectural features relevant to such kinds of systems was researched, and a mapping between such features and relevant component diagrams was established. Based on the selection of features, an automatically generated architecture is constructed through the aggregation of various kinds of components relevant to the selected features. This effort is a first attempt towards the creation of a configurable reference architecture for pervasive systems, and the subsequent specification of a product line supporting the rapid development of such types of systems. Using the Feature Modeling Plug-in (FMP) with Eclipse and the Visual Paradigm for UML, we developed a program in C# that generates pervasive systems architectures. We used FMP with Eclipse in order to generate a feature model for pervasive systems under design. Visual Paradigm for UML was then used to map the different selected features to component diagrams. The component diagrams were then aggregated using known design patterns to generate the architecture in question. Key words: pervasive, architectural features, reference architecture, component-based architecture.
1. Introduction Pervasive systems are thought to be the third wave of computing, interbreeding many disciplines in the computing domain. In specific, it is signified by the merger between mobile and distributed systems. The main aim of pervasive systems is to provide services invisibly by being aware of the surrounding context and retaining the ability for subsequent reaction. Such systems are characterized by their heterogeneity, observed in the diversity of software and hardware involved. They are also characterized by the abundance of small scattered devices, limited network facilities, and high mobility. As research in pervasive systems evolved, many useful applications emerged. As the need for ubiquitous development and deployment of such systems became stronger, relevant software engineering
practices specific to such types of systems had to be developed. One of the big challenges herein includes the design of such systems, and in this paper we present an approach for generating architectures for pervasive systems based on the selection of features specified by system designers. The rest of the paper is organized as follows: In section 2, we cite some related research work. In section 3, we explain how we categorized the architectural features that we collected by studying over fifty pervasive systems architectures. Section 4 explains how we automatically generate architectures by selecting a set of desired features, section 5 presents two case studies and finally section 6 concludes the paper.
2. Related Work During our research, we came across different software product lines (SPL) that target distributed, embedded, adaptive, pervasive, and data-intensive systems. For example, a software product line that targets distributed and embedded systems is proposed by Scheidemann [4]. The SPL is designed for configuring a vehicle control system by exploiting the commonalities and variability in the requirements and the features that could be found in a car. The approach presented by Schmoelzer et. al. in [7] describes the application of component based and model driven development in building product lines for dataintensive systems. Data intensive systems handle data processing, visualization and storage, and are usually architected through the application of multiple tiers in their relevant architectures. In Hallsteinsen et. al’s [6] work, product line techniques are used to build adaptive systems which adjust their properties and resources according to user needs and resource constraints at runtime. The approach presented by Cetina et. al [1], is based on Model Driven Development (MDD) and the variability modeling principle. It utilizes variability modeling and the available resources to get the most efficient reconfiguration of the software system to match users’ goals. No significant effort has however been made to create reference architectures for pervasive systems with sufficient embodiment of the required commonality and variability amongst such types of systems.
Our study of a plethora of pervasive systems architectures led us to the exploration of commonalities and variability in such kinds of architectures. A set of architectural features common to these types of systems was specified and mapped to a given set of software components [3], which are subsequently aggregated to build an automatically generated architecture for a system comprised of a subset of the selected features.
3.
Pervasive Systems Categorization
Our first attempt to automatically generate architectures was to study over fifty different architectures built for pervasive systems, and to capture the features inherent in such architectures. The outcome of the study we presented in [5] is visualized in Figure 1, and shows the various architectural features we found and subsequently categorized. We used the Feature Model Plug-in (FMP), developed by the Generative Software Development Lab at Waterloo University, and Eclipse to represent the categories [2] and inherent features. We found the natural interaction and sensor and actuator networks to be common features for all the pervasive system architectures that we have seen so far. However, the rest of the features, organized in thirteen different categories, are considered to be variables and could be selectively chosen according to the requirements put forth for new systems. For each of the indicated features, we designed relevant architectures that could eventually be aggregated together based on a designer’s choice for the incorporation of certain features required in a new architecture under development. Figure 2 and Figure 3 are samples of architectures we designed or extracted from the literature for the “natural interaction” and “sensor network” component features, respectively. We found these two components to be common to all pervasive systems that we have seen so far.
Figure 1: Pervasive Categorization using Eclipse and FMP
Figure 2: Natural Interaction Component Diagram
1. Maps the generated XML diagrams to the XML document converted from the features. This is done by mapping each feature to the corresponding component or set of components. 2. Adds these components to the generated component diagram. 3. Performs a second iteration over the generated component diagram in order to remove the unnecessary connections and to glue together the unconnected components that come from different categories according to a pre-defined lookup table.
Figure 3: Sensor Network Component Diagram
4. The Architecture-Generation Process We had to choose between creating a huge reference architecture that incorporates all the indicated architectural features with variability versus having smaller architectures and selectively aggregating their components together according to designer preference of selected features. We compared the two approaches and decided that it is more lucrative to adopt the latter approach. Having smaller architectures for the various features is better in our opinion for the following reasons: 1. Expandability for new features and architecture scalability: The generated architecture can be modified easily by adding new components from different categories. 2. Easier to automate changes: Applying or changing the connections among the components will be easier than in the bigger reference architecture, where it would be more difficult to trace and apply connections. 3. Loosely coupled: Architectures that are loosely coupled and can be replaced easily. The RAs for each category can be modified or replaced by another component diagram. The process of generating architectures is shown in Figure 4. The needed features are first selected using the Feature Modeling plug-in (FMP) [2] with Eclipse by the system designer. Visual Paradigm for UML [7] was used to represent the component architectures. The selected features and the architecture diagrams are then exported in the form of XML documents. If any modification is done in the component architectures through Visual Paradigm after exportation, the XML document must be re-exported to reflect the updates. The reason behind using XML during the generation of the architectures is that XML is easier and better for standardizing the processing among the different tools used in our approach. By using Visual Studio 2008, we developed a program in C# and Windows Forms that:
The lookup table is manually pre-built before running the C# program. It is developed by collecting the matching components together from the different categories and checking if there could be any dependency among them. A dependency is identified if a component reads/writes/uses another one. In other words, if interactions are found by the designer between components, they are appended to the lookup table. For the lookup table structure, as shown in Figure 5, each line expresses a connection between 2 components by declaring the component names separated by a comma ‘,’. For example, the “Shopping Cart” component, which is used in retail systems, has a connection to the “Application Tier Subsystem”, which is a component of the actor. The “Shopping Cart” utilizes the “Application Tier Subsystem” by accessing the different retail applications that the actor is using. In other words, if the actor has a retail application tha he/she uses in setting preferences and compiling the shopping list, “The Application Tier subsystem” will act as the bridge between the “Actor” and the “Shopping Cart” with the correct wrappers to ensure they understand each other. The final generated XML document is readable through Visual Paradigm for UML and the component diagram can be viewed from there. The generated architecture is still a first increment. More software engineering intervention is needed after generating the architecture to verify the architecture and make sure that it does not have blackouts or unnecessary components.
5. The Case Studies We devised two scenarios for generating architectures. The first one is a combination of retail and context awareness while the other is a combination of retail and health.
Transcoder Context Management o Model o Context Repository o Context Reasoner Situation Repository Preference Repository
Figure 6 shows how the features are selected from within our tool.
Figure 4: The Architecture Generation Process
Figure 5: Lookup table Sample
5.1
Retail and Context-Awareness
Scenario: While walking in a mall or a supermarket, one should be notified whether co-located entities have common interests. The system should detect if a person is shopping alone or with others, and accordingly, it notifies him/her with the common interests among the group. According to the above scenario, we selected the features needed in order to generate the system as shown in Figure 6. The selected features are: Actors Sensors Network Shopping cart o Screen o Internet Bar Code Reader RFID Reader
Figure 6: Configuration of Retail with Context-awareness
By applying the feature-driven approach and the architecture genration process described above, the resulting architecture is as shown in Figure 7. The subsystems included in the architecture are natural interaction, as well as sensor networks as described earlier in Figure 2 and Figure 3, respectively. Other subsystems are mapped from the selected features as shown in Figure 6. According to the lookup table, the “Application Tier Subsystem” is connected to the “Shopping Cart” and the “Application Tier Subsystem” is connected to the “Devices Interaction Subsystem”. The “Application Tier Subsystem” is
considered a focal component that enables the system users to customize and personalize the system to their preferences.
5.2
Retail and Health
Scenario: While walking in a store or a mall; a need might arise to monitor a health condition. If a person is suddenly faced with a certain health condition, he/she should be notified with the nearest pharmacy, clinic or hospital according to the situation. The needed features that we selected according to the discussed scenario are: Actors Sensors Network Shopping cart o Screen o Internet Bar Code Reader RFID Reader Transcoder Drug Management Health Monitoring Network From the above scenario, the generated architecture is shown in Figure 8. The following categories were covered by the scenario: natural interaction: sensor network, context-awareness, retail, and health. The lookup table connected the “Application Tier Subsystem” to the “Drug Manager”, and the “Actor” to the “Health Sensors”. The “Drug Manager” component gets orders from the “Application Tier Subsystem” according to the
customizations order. The “Actor” subsystem sends and receives data from the “Health Sensors” subsystem about the current situation of the person’s health condition. We selected the above two simple architectures to demonstrate the capability of the tool and the research done in generating architectures as well as to show that the architectures are loosely coupled. By changing some of the features, the final architecture and its functionality could totally change into a new architecture.
6. Conclusion In this paper, we discussed our feature-driven approach for generating pervasive system architectures based on selected features that are desired in a particular system. The selected features are mapped to predetermined component diagrams which are glued together according to a lookup table to generate the desired architecture. We showed two case studies with their requirements, and indicated how our approach can be used to generate a pervasive architecture. The generated architecture must be subsequently verified through human intervention. Our work in progress includes refining a metric suite using the work in [9], [10], [11], [12], [13], [14], [15] and [16] to be used in evaluating the generated architecture in comparison to the architectures generated by human subjects for the same scenarios.
st
Figure 7: 1 Iteration of Retail and Context-awareness Architecture
st
Figure 8: 1 Iteration for Retail and Health Architecture [9]
REFERENCES [1]
[2] [3]
[4]
[5]
[6]
[7]
[8]
Carlos Cetina, Joan Fons, Vicente Pelechano, "Applying Software Product Lines to Build Autonomic Pervasive Systems" 12th International Software Product Line Conference (SPLC 2008), pp. 117-126. Feature Modeling Plug-in (FMP). An Eclipse plug-in for editing and configuring feature models. http://gsd.uwaterloo.ca/fmp George T. Heineman, William T. Councill, Component-based software engineering: putting the pieces together, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 2001. Kathrin D. Scheidemann. "Optimizing the Selection of Representative Configurations in Verification of Evolving Product Lines of Distributed Embedded Systems." 10th International Software Product Line Conference (SPLC'06). splc, 2006. Pages: 75-84. Mostafa Hamza, Sherif G. Aly. “A Study and Categorization of Pervasive Systems Architectures: Towards Specifying a Software Product Line”. In WorldComp 2010: World Congress in Computer Science, Computer Engineering, and Applied Computing. S. Hallsteinsen, E. Stav, A. Solberg, and J. Floch. "Using Product Line Techniques to Build Adaptive Systems". In SPLC’06: 10th Int. Software Product Line Conference, pages 141–150, Washington, DC, USA, 2006. IEEE Computer Society. Schmoelzer, G., C. Kreiner and M. Thonhauser. "Platform Design for Software Product Lines of Data-intensive Systems." Proceedings of the 33rd EUROMICRO Conference on Software Engineering and Advanced Applications. 2007. Pages: 109 - 120. Visual Paradigm for UML. http://www.visualparadigm.com/product/vpuml/
[10]
[11]
[12]
[13]
[14]
[15] [16]
SDMetrics. The Software Design Metrics tool for UML. http://www.sdmetrics.com/ L. Briand, S. Morasca, V. Basili. "Property-based Software Engineering Measurement", IEEE Transactions on Software Engineering, 1996. M. Hitz and B. Montazeri, "Measuring Coupling and Cohesion In Object-Oriented Systems," Proc. Int'l Symp. Applied Corporate Computing (ISACC '95),Monterrey, Mexico, Oct.25-27, 1995. Edward B. Allen , Sampath Gottipati , Rajiv Govindarajan, Measuring size, complexity, and coupling of hypergraph abstractions of software: An information-theory approach, Software Quality Control, v.15 n.2, p.179-212, June 2007. Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, fifth edition. The McGraw-Hill Companies, Inc., New York “Can we measure architecture? ” interview with Anja Fiegler. Enterprise and Solution Architect Certification & Resources. http://grahamberrisford.com/15%20Scale%20and%20Change/Can%2 0we%20measure%20architecture.htm Judith Barnard, A new reusability metric for object-oriented software, Software Quality Control, v.7 n.1, p.35-50, 1998. Xia Liu, Qing Wang, "Study on Application of a Quantitative Evaluation Approach for Software Architecture Adaptability," qsic, pp.265-272, Fifth International Conference on Quality Software (QSIC'05), 2005.
