An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications

Transcription

1 An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications Germán Harvey Alférez Salinas Department of Computer Information Systems, Mission College, Thailand and Poonphon Suesaowaluk School of Information Technology, Assumption University, Thailand Abstract Web applications are a key element in the eworld because of the ubiquity and flexibility they provide. As a result, it is necessary to find new ways to develop software product lines (SPLs) of Web applications in order to improve important factors such as time-tomarket and product quality. This paper presents an aspect-oriented product line framework to support the development of SPLs of Web applications. It is enclosed in the Core Asset Development and Product Development activities in product line development proposed by the Software Engineering Institute (SEI) of the Carnegie Mellon University, and it can be used for identifying, specifying, and managing variability from requirements to implementation. 1. Introduction Software Product Line (SPL) engineering is about exploiting commonalities among a set of systems while managing the variabilities among them in order to improve time to market, achieve systematic reuse goals, and improve product quality. Aspect-oriented software development (AOSD) is a paradigm that has a direct relationship to SPLs because one of its main objectives is to separate concerns to promote flexibility and configurability; these two goals are also vital when constructing SPLs. Also, AOSD can improve the way in which software is modularized with the encapsulation of variabilities in aspects. The contribution of this paper is to present a framework that uses AOSD in order to manage variability from the early stages of the SPL lifecycle and also improves the traceability of variations throughout every phase in the development of SPLs of Web applications. The framework is enclosed in the Core Asset Development and Product Development activities in product line development proposed by SEI. Besides, it is designed as a process description and recommendation to use specific existing Unified Modeling Language (UML) models with their extension mechanisms. Finally, this research is focused on SPLs of Web applications because of their key role 13.1

2 Germán Harvey Alférez Salinas, and Poonphon Suesaowaluk to provide ubiquity and flexibility in the eworld. Specifically, the analysis of the proposed framework is driven by a simplified SPL of help desks. The remainder of this paper is structured as follows. Section 2 describes the case study that was used to apply and evaluate the framework. Section 3 explains the aspectoriented framework for SPLs. Section 4 presents related work. Section 5 gives the conclusion and outlines areas of future work. 2. Description of the Case Study The framework was applied on a simplified SPL of help desks. There are three roles: Director, Operator, and Solicitant. Some products of the SPL measure the performance of the list requests, input request, and input service operations (this is a non-functional requirement). In order to take this measure, products calculate the response to external events or estimate the execution time of the operations. Finally, some products notify by to the solicitant when a new request or service has been input. These s can be generated in plain text or HTML format. 3. Aspect-Oriented Framework to Manage Variability in Software Product Lines Fig. 1 shows the two main activities of the proposed framework, Domain Engineering and Application Engineering, and their mapping with the SEI s activities. Each activity has its own development cycle. The bidirectional rows indicate that it is an iterative process and that traceability can be done between any stage and between the two development cycles. Figure 1. Aspect-Oriented Product Line Framework. Domain Engineering is the process of SPL engineering in which the commonality and the variability of the product line are created. Application Engineering is the process of SPL engineering in which the applications of the product line are built by reusing artifacts. The remainder of this chapter presents the two activities of the proposed framework. 3.1 Domain Engineering: The goal of this activity is to establish a production capability for products [1]. The framework sets up this capability with the following phases: - Domain Requirements Engineering: Functional and non-functional requirements common to the entire product line are represented through use cases with variation points that can be used to create productspecific requirements employing extensions and extension points. With the purpose of capturing the commonality and variability in use cases, the framework uses the approach of [2] where use cases are categorized as kernel, optional, or variant. - Evolution and Refinement to Analysis: In this phase, mapping rules are used to establish relationships between kernel, optional, and variant use cases, and concerns. Special Issue of the International Journal of the Computer, the Internet and Management, Vol.15 No. SP4, November,

3 The first step to do this mapping is the creation of Table 1. Table 1. Kernel concerns vs. crosscutting concerns with variants. Crosscutting Concerns Kernel Concerns Optional and Variants Kernel Kernel Kernel Non-Functional concern 1 concern 2 concern n Requirements Optional use Variant 1 X case 1 Variant 2 X Non-functional X X requirement 1 Non-functional requirement n X X X Table 1 works as a production plan because it describes how the products can be created from the core assets. This table also helps to do forward and backward traceability among stages of the software lifecycle because it shows in an easy way which concerns are involved in the architecture. After discovering crosscutting concerns in Table 1, the next step consists on defining aspects from the established crosscutting concerns and to create a refined use case diagram with them. To do this, the following mapping rules are proposed: - If an optional use case crosscuts several kernel use cases, then an aspectual functional case is defined. - If a non-functional requirement crosscuts several kernel use cases, then an aspectual non-functional case is defined. - A <<variant>> use case continues using its representation as <<variant>>. - When there is a relationship between a <<non-functional aspect>> with a <<kernel>> use case, or between a <<functional aspect>> with a <<kernel>> use case, it is represented with the stereotype <<crosscut>> in the refined use-case model. When there is a relationship between a <<variant>> with a <<non-functional aspect>> or <<functional aspect>>, this relationship keeps the <<extend>> relationship. - Domain Analysis: In this phase, the feature, class, and sequence diagrams are created. Here again, we use the stereotype <<crosscut>> to indicate crosscutting relationships. Fig. 2 shows a fragment of the sequence diagram for the use case Input Service. The stereotype <<pointcut>> taken from AspectJ [3] is used in order to define the points where the aspects crosscut the execution of the program. - Evolution and Refinement to Design: To facilitate the reuse and understanding of core assets in different products, kernel classes and aspects are grouped in different packages depending on their stereotypes and preserving the relationships that were created in the class diagram at the Domain Analysis phase. Figure 2. Fragment of the sequence diagram for the use case Input Service. - Domain Design: The refined class model is created here. It addresses the design of classes and aspects by determining their operations and attributes. - Domain Implementation: In this phase, software components and aspects are developed for systematic reuse across the 13.3

4 Germán Harvey Alférez Salinas, and Poonphon Suesaowaluk product line. AspectJ [3] was used in the construction of the case study. 3.2 Application Engineering: In the Application Engineering activity, the product builders instantiate the production plan, recognizing the variation points being selected for the given product depending on the variabilities that were discovered and defined as functional and non-functional aspects in every stage of the Domain Engineering activity. 4. Related Work Even when [4] presents variability management using four steps, they are not deeply explained in order to be considered a framework. COVAMOF is presented in [5]. It is a variability modeling approach that uniformly models the variability in all abstraction layers of the SPL. However, the graphical notations of the main entities in the COVAMOF Variability View do not use a standardized modeling language such as the UML; it makes its implementation more difficult. Heo and Man [6] use Aspect-Oriented Programming (AOP) as a method for improving the assembling process in SPL. Although they analyze a mini-system that adapts AOP, their research is focused only on the implementation phase. Pohl, et al [7] show a framework for SPL engineering that is based on the differentiation between the Domain and Application Engineering processes. They propose a new graphical notation for variability models that, in contradiction to the use of the UML in our aspect-oriented framework, complicates its adoption in the industry. Finally, even when [8] describes a SPL approach called NAPLES which uses natural language processing and aspect-oriented techniques, it does not apply UML models. 5. Conclusion and Future Work Eleven metrics were applied on the SPL of help desks in order to measure the effectiveness of the proposed framework in the development of SPLs of Web applications. These are the conclusions: the aspect-oriented framework to manage variability in SPLs provides a high support in each one of its stages, a high-level traceability of variability in every stage of the lifecycle, facility to analyze and modularize crosscutting concerns, and high reuse flexibility. Besides, the coupling between object classes can be dramatically decreased, the average number of methods and methods called by local methods can decrease, and cohesion is improved with the use of aspects. There are two areas of future work in order to extend this research: the first one is about working on extending the framework to support the testing of SPLs. The second area is about implementing the framework in a group of software companies in order to get more quantitative and qualitative results. References [1] P. Clements and L. Northrop (2002),. Software Product Lines: Practices and Patterns. Addison-Wesley. [2] H. Gomaa and M. Shin (2002),. Multiple-View Meta-Modeling of Software Product Lines. In Proceedings of the 8 th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 02), Special Issue of the International Journal of the Computer, the Internet and Management, Vol.15 No. SP4, November,

5 [3] G. Kiczales, et al. (2001), An Overview of AspectJ. In Proceedings of the 15 th European Conference on Object Oriented Programming, (ECOOP 2001). [4] J. Gurp, J. Bosch, and M. Svahnberg (2001),. On the Notion of Variability in Software Product Lines. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA 2001), [5] M. Sinnema, et al. (2004), COVAMOF: A Framework for Modeling Variability in Software Product Families. Lecture Notes in Computer Science, Springer Berlin / Heidelberg, vol. 3154/2004, pp [6] S. Heo and E. Man. (2006), Representation of Variability in Software Product Line Using Aspect-Oriented Programming. In Proceedings of the 4 th International Conference on Software Engineering Research, Management and Applications (SERA 06), IEEE Computer Society. [7] K. Pohl, G. Böckle, and F. Van der Linden. (2005), Software Product Line Engineering, Foundations, Principles, and Techniques. Springer. [8] N. Loughran, A. Sampaio and A. Rashid (2005), From Requirements Documents to Feature Models for Aspect Oriented Product Line Implementation. In Proceedings of the Workshop on MDD in Product Lines (held with MODELS 2005) 13.5