ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework Component-Based Specification of Software Product Line Architecture Amina Guendouz Djamal Bennouar CS Department, Saad Dahlab University CS Department, Akli Mohand OulHadj University Blida, Algeria Bouira Algeria guendouz.amina@yahoo.fr dbennouar@gmail.com Abstract – Software product lines have known an increasing use over the last years, taking advantage from the important benefits they may bring to software development in terms of time, cost and effort. However, product line approaches remain immature owing to the fact that they still base on traditional design concepts of software engineering which are not adequate to the basic principles of software product lines engineering. Considering that software product lines are inspired by industry where production activity is based on assembling certified components, and in light of the recent progress in Component-based development field, we believe that integrating these two approaches will bring significant benefits to software development. This paper describes a new approach for Component- Based Product Lines engineering focusing on the Component-Based specification of the Product Line architecture. The aim is to overcome the shortcomings of traditional product lines by unifying the strengths of two complementary approaches, and to facilitate the derivation process since applications will be produced by the simple composition of existing components. Keywords – Software Product Lines, Component-Based Development, Reuse, Components, Variability, IASA. Software Product Line approach intends to 1. INTRODUCTION adapt to the software development, the principles that we find in the automotive, Software Product Lines are emerging as a aeronautics and electronics industries. viable and important development paradigm Production in these industries is organized into allowing companies to realize order-of- ranges with similar parts and offering a magnitude improvements in time to market, number of options. For example, in automotive cost, productivity, quality, and other business industry, various car models come out the drivers. A software product line (SPL) is “A set same assembling chains using the same of software-intensive systems sharing a chassis, the same engines and the same test common, managed set of features1 that satisfy plans. The aim is to improve productivity, the specific needs of a particular market decrease time to market, and reduce segment or mission and that are developed production, maintenance and test costs. The from a common set of core assets 2 in a idea is to transpose the principles of prescribed way” [1]. manufacturing of these industries in software development, to benefit from the before- 1 mentioned advantages. A feature is an end-user visible characteristic of a system [4]. Although, the principles of software product 2 lines are inspired by industry where production A reusable artifact or resource that is used in the activity is based on assembling certified production of more than one product in a software components, most of software product lines product line. A core asset may be an architecture, a today are based on traditional design concepts software component, a domain model, a of software engineering such as modular requirements statement or specification, a document, a plan, a test case, a process design and object-oriented design. These description, or any other useful element of a design concepts are not able to support the software production process [1]. assembly of certified components which International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 100 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework makes the derivation and maintenance while maintaining diversity between products. processes difficult to perform. Furthermore, This is ensured by involving “Variability both of software product lines and component management” activity along all the software based development promote reuse; putting development process. them together will bring significant benefits to Introducing a new CBPL approach must take software development. into account these two aspects. It must be SPL improve reuse while maintain diversity able to reconcile between the two between products. In most cases, software development processes (component-based components intended for reuse must be process and SPL process) on the one hand, adapted to meet specific requirements of and enable the effective management of customers. If flexibility is not considered since variability on the other hand. In next the early development process phases, subsections we present how our approach developers will meet lot of difficulties in considers these two aspects. adaptation step, which lead them to leave these components even they will have to 2.1. COMPONENT BASED PRODUCT LINE redevelop components from scratch. SPL ENGINEERING simplify adaptation phase by involving Software product line engineering relies on a “Variability management” activity along all the fundamental distinction of development for software development process. reuse and development with reuse [3], [4]. However, traditional component-based Development for reuse or “Domain approaches do not support variability engineering” consists in developing core management. It becomes necessary to assets through the domain analysis, domain establish new approaches or enhance existing design and domain implementation processes. component-based approaches in order to Development with reuse or Application allow an effective variability management. In engineering consists in developing the final this paper, we propose an approach that products, using the core assets and the integrates SPL engineering and component- specific requirements expressed by the based engineering, aiming to unify the power customers. of these two approaches. Firstly, we will The development process of CBPL we present the development process of propose (figure 1) is an integration of the component-based SPL (CBPL). Then, we will development process of SPLs [4] and the show the extension of a component-based component-based development process [5]. approach (IASA [11]) in order to allow the modeling of variability in CBPL. The proposed Unlike to the traditional SPL engineering, the approach is, afterward, supported by a case base of core assets obtained from CBPL study. engineering relies mainly on software architecture (reference architecture, The remainder of this paper is organized as refinement of components and reusable follows: Section 2 introduces the proposed components...). While, its difference compared approach. Section 3 shows the specification of to the traditional Component-based a CBPL for e-Meeting applications. Section 4 development is the introduction of variability reports the related work and comments on it, management activity. Since variability is while Section 5 summarizes the paper and handled from the early stages of development, outlines future work. reusable components obtained from domain engineering process do not have to be 2. COMPONENT BASED PRODUCT LINES adapted to the specific needs of final applications, which make the step of The crucial aim of introducing product line application assembly easier and faster. approach in software engineering is to improve reuse. SPL differs from traditional reusing Domain engineering consists of three activities approaches in two ways: the first one is that that are Domain analysis, Product-line SPL approach systematizes reuse throughout architecture design and Components all the software development process: from implementation (Figure 1). The purpose of this requirements engineering to the final code and sub-process is to produce the reusable core test plans, in contrast of traditional software assets and to provide the effective means that reuse approaches which exploit reuse only at help in using these core assets to build new design and coding phases [2]. The SPL products within the SPL. The main outputs of engineering process is thus decomposed into this process are: reference requirements, two sub-processes (section 2.1): development reference architecture and reusable for reuse and development with reuse [3], [4]. components. The second one is that, SPL improve reuse International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 101 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework Figure 1: Component-Based Product Line engineering. Application engineering consists in developing main objectives are: to make the variability the final products, using the core assets and explicit in the early stages of the project, and the specific requirements expressed by to reduce the complexity related to variability customers. This sub-process consists of three management throughout the development steps: Application analysis, Application process [2],[10]. architecture design for the specific application and finally Application assembling. Each step For the modeling of variability in the is facilitated by the reuse of the outputs from architecture view, we have chosen to extend the previous process. The result of application the component-based model IASA (Integrated engineering is an application ready to be used. Approach to Software Architecture) [11]. IASA was used to realize complex e-Government 2.2. VARIABILITY MODELING IN CBPLs software system, and was proved as a clear and easy specification language to design at a Variability management is a key activity that high level of abstraction using Aspect Oriented usually affects the degree to which a SPL is approach [12] [13]. successful [6]. Variability refers to the ability of an artefact to be configured, customized, 2.2.1. Architecture design with IASA extended, or changed for use in a specific The design according to IASA approach uses context [7], [8], [9]. This variability must be a component-oriented process which proceeds identified, represented, exploited, implemented, evolved, etc. – in one word by successive refinement. An IASA component is seen from the outside as a managed – throughout software product line engineering [3]. black-box that communicates with the external world through Ports [14], which define the After being identified, variability must be services it can provide or require. The internal represented. The second step in managing view of a primitive component is inaccessible, variability is to model it in all software while the structure of a composite component artefacts. Modeling variability is a technique is well defined, it consists of three parts: used firstly to document the variability and Operative Part, Aspect Part, and Control Part. secondly to reason about the variability. Its Figure 2 sets out the basic notations of IASA. International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 102 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework Figure 2: Basic notations of IASA. 2.2.2. Variability modeling with IASA Since IASA have not been developed to capture all types of variability explicitly, we propose to extend it in order to meet the needs of SPL engineering. We define three types of variability in architecture: Mandatory, Optional and choice. Mandatory and Optional elements: Each element in the architecture can be mandatory or optional according to the context in which it will be used. In order to represent explicitly Figure 3: Component choice. these types of variation, Components and Connectors are annotated by: «Mdr» and The number of components that can be «Opt» which means respectively: Mandatory supported by the connector is expressed by a and Optional. cardinality [n..m], such as: Considering that interfaces in the same  n=m if the type of the relation is AND; component can be optional if they are not  m>=n if the type of the relation is OR; needed in some contexts, variability in  n=m=1 if the type of the relation is XOR or interfaces is represented as follow: Alternative. Mandatory provided interface Mandatory required interface Optional provided interface Optional required interface Choices: We distinguish between two types of choices: 1. Component choice: When there are a variety of implementations for the same component, the variable component is annotated by: «Choice» and related through the same interface to all its variants as shown in figure 3. 2. Connector choice: When a component is related to a variable set of components, the relation between these components becomes a connector annotated by: Figure 4: Connector choice. «Choice» and related with different interfaces to each variant as shown in figure 4. International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 103 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework Figure 5: Business feature diagram for e-Meeting product line. between the SPL members. To document the 3. CASE STUDY: E-MEETING CBPL common and variable features of our product line, we have used the Feature Model. The In this section we apply our approach in a Feature Model is the first language dedicated specific domain which is: E-Meeting to the modeling of variability; it was first applications. E-meeting applications exhibit an introduced in the Feature-Oriented Domain excellent solution to overcome the problems Analysis (FODA) method [15]. It has known a that can occur when organizing a face to face broad use in the field of SPLE, since it is a meeting namely: distance, costs and simple and easy to use language in availability. Using online meeting technologies comparison with other more complex modeling allow us to simplify the meeting organization languages such as: UML and BPMN. The processes, save time and displacement feature model is generally described by a expenses. hierarchy of the set of features of a system or The concept of meeting can be found in what is called feature tree [4]. Figures 5 and 6 various fields. For instance: meetings for year- show a part of the feature model of our CBPL. end deliberation, meetings of a Scientific For the notation, we must note that all of AND, OR, XOR variability types are expressed Council, meetings of elected members of an APC3, APW 4 or APN5, meetings of business through cardinality (as shown in section 2) to leader, etc. E-meeting applications designed avoid cluttering the diagram with more for these various types of meetings share notations, for us cardinality is sufficient to many similarities and are distinguished by represent all kinds of choices. some particular aspects. It becomes very The constructed feature model is divided into important to take advantage of similarities three diagrams according to the type of between these applications to develop a family features it includes: Business features, of e-meeting applications. This family of technical features, and implementation product (SPL) once implemented is able to features. Features in the first diagram called produce for each meeting type, the appropriate Business features (Figure 5), represent the software in a very short time. In this case study Business functionalities provided by the we will focus on the component-based system. This diagram shows that the main specification of the e-Meeting SPL. Next sub- features of an e-Meeting application are sections describe the artefacts obtained from “Create meeting” and “Manage meeting”. Domain analysis and Product-line architecture design steps. Each e-Meeting application must allow at least the planning of a meeting and the generation 3.1. Domain analysis of reports. However, in some cases a prior step can be needed before performing a The goal of domain analysis is to extract and meeting which is: the discussion of the document the similarities and variations meeting item, modeled by “Request for meeting” in the Feature diagram. 3 An APC is the elected assembly which governs a “Management of recurring items” feature can commune (baladiyah). be included if the customer is interested to the 4 An APW is the elected assembly which governs a history of previously treated items, there wilaya (province). 5 An APN is the national elected assembly. results, statistics about them and so on. International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 104 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework Figure 6: Technical feature diagram for e-Meeting product line. “Configuring” a Meeting is an optional feature “Meeting tools” might include “Attendance that consist in preparing the application by management”, “Participation management”, fixing the meeting type (video, audio, chat...), “Schedule manage”… the application can in addition to the needed tools to run a eventually be extended by new tools if meeting according to the user’s requirements. required. Figure 7: Reference architecture of e-Meeting product line. International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 105 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework The second diagram Figure 6 represents the and audio files). Those features could be technical features; it means features that do found in any e-Meeting application, but not all not reflect the business aspect of e-Meeting of them are mandatory. applications. Technical features encompass features related to the application The third diagram represents the implementation features of the system it (configuration, UI management), features means implementation details at lower levels. related to users (Accounts management, Roles management, Authentication), and We do not show this diagram in the paper owing to space reasons. features related to files (including: text, video Figure 8: Variability model for “Meeting_Configuration” component. 3.2. Product-line architecture design assembly, configuration or might be delayed until runtime, this leads developers to have The purpose of Product-line architecture more flexible applications and thus better design is to establish the generic software customer satisfaction. architecture of the product line. Variability identified during domain analysis must be explicitly specified in the product-line 4. RELATED WORK architecture. To design the reference The most known approaches that integrate architecture of our composite SPL we have Software Product Line engineering and used the notation presented in section 2. The Component-based engineering are: Kobra [17] reference architecture of our e-Meeting and Koala [18] [19]. The basic goal of Kobra is product line is reported in figure 7. The to provide a systematic approach to the mandatory components that must be included development of component-based application in each member of the SPL are annotated by frameworks. Nevertheless, Kobra approach «Mdr»(Meeting_Management,Meeting_Planni interest to the internal structure of components ng, Roles_Management…), while those which for which it uses UML modeling. Therefore, are optional are annotated by «Opt» this approach cannot be compared to ours. (Items_Management, Meeting_Configuration…). Koala is a component model based on an architectural description language used to Figure 8 shows the refinement of the build a large diversity of products from a “Meeting_Configuration_Cmp”. This latter can repository of components. Its aim is to manage be connected to (can use) no or many tools the growing complexity and diversity of components(Attendance_Cmp,Participation_C software in consumer electronics products. mp, Schedule_Cmp, FilesManage_Cmp). The Various concepts are used in the koala choice connector “Meeting_tools_Cnt” allows components models, like interfaces, us to represent this type of variability. The connectors, subcomponents and compound binding time 6 of this variability can be: design, 6 Is an attribute of variation points and/or variability decisions to later stages in the software technique used to delay the architectural design development process [16]. International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 106 ICAASE'2014 Dealing with Deviations on Software Process Enactment : Comparison Framework components. Koala allows the modeling of [4] P. Klaus, B. Günter and F. van der Linden, variability related to interfaces (optional Software Product Line Engineering: interfaces) and connections between Foundations, Principles, and Techniques, interfaces (switch). However, the model Springer, 2005. proposed by Koala does not cover all types of [5] S. Roger Pressman, “Software engineering: variability that can be found and must be a practitioner’s approach”, Edition: 5, explicitly defined in a SPL, such as: mandatory McGraw-Hill Higher Education, June 2000. or optional components, AND, OR, XOR [6] L. Chen, M.A. Babar, A. Nour, “Variability Management in Software Product Lines: A relations… Furthermore, Koala consider Systematic Review,” SPLC, San Francisco, variability binding only at configuration time, California, 2009. while SPL engineering allows several binding [7] B. Felix and C.C. Paul, “Variability in times, according to the context, ranging from Software Product Lines”, technical report design to configuration and runtime [16]. CMU/SEI, 2005. [8] G. Jilles van, B. Jan, S. Mikael , “On the Notion of Variability in Software Product 5. CONCLUSION Lines”, WICSA, 2001. The work presented in this paper aims to [9] S. Mikael, G. Jilles van, and B. Jan, “A reach a high level of reuse that can be taxonomy of variability realization obtained through the integration of two techniques”, Software Practice and approaches: Software product lines and Experience, 2005. [10] M. Andreas, P. Klaus, H. Patrick, S. Pierre- Component-based development. Each of Yves, S. Germain, “Disambiguating the these approaches promotes reuse at different Documentation of Variability in Software granularity levels. Component-based Product Lines: A Separation of Concerns, development supplies technologies for reuse Formalization and Automated Analysis”, in the small, while Software product line 15th IEEE International In Requirements approach intends reuse in the large. Putting Engineering Conference, 2007. them together allow us to reach large scale [11] B. Djamal, “The Integrated Approach to reuse and flexibility at the same time. Software Architecture”, Ph.D. Thesis, Ecole Moreover, Component-based development Supérieure d’Informatique, Oued Smar, can overcome the lack of maturity in SPL Algiers (in French), 2009. engineering by providing efficient technologies [12] B. Djamal, S. Abdelfettah, “The Design of of development. an eGovernment Application Using an Aspect Oriented Software Architecture Since our approach needs more space to be Approach”, AOSA conference, 2009. well define, this paper presented the outlines [13] B. Djamal, H. Abderrezak, S. Abdelfettah, of the proposed approach, mainly: the “The Design of A Complex Software System development process and the Component- Using A Software Architecture Approach”, based model. The paper presents also a case ACIT, 2008. study for an ambitious field (e-Meeting) aiming [14] B. Djamal, T. Khammaci, H. Abderrezak, “A to validate the proposed approach. The new approach for component’s port designed e-Meeting reference architecture modeling in software architecture”, In: represents a framework for all foreseeable e- Journal of System and Software, Elsevier, Meeting applications and can be extended to Volume 83 Issue 8, August, 2010. cover specific requirements if needed. Since, [15] K. Kang, S. Cohen, J. Hess, W. Nowak, and software can be quickly derived from a CBPL S. Peterson, “Feature- Oriented Domain by the simple composition of existing Analysis (FODA) Feasibility Study,” components; the activity of deriving new Technical Report CMU/SEI-90-TR-21, 1990. members in a CBPL can be greatly automated. [16] C. Rafael, B. Jan, “Binding Time and Evolution, Systems and Software Variability The automation of applications derivation step Management”, pp 57-73, Springer, 2013. is an important perspective of our work. [17] A. Colin, B. Joachim, M. Dirk, “Component- Based Product Line Development: The KobrA Approach”, software Product Line 6. REFERENCES Conference, 2000. [1] M. N. Linda, C. C. Paul, “A Framework for [18] O. Rob van, “The Koala component model Software Product Line Practice”, Version for consumer electronics software”, Philips 5.0 (online), http://www.sei.cmu.edu/. Research Eindhoven, IEEE Computer [2] C. Jean, “Les lignes de produits logiciels 33(3), MAR 2000. Réutilisation et variabilité ”, Publication [19] A. Timo, S. Timo, and M. Tomi, “A Koala- périodique de Smals, Juin 2009. Based Approach for Modelling and [3] F. van der Linden, S. Klaus, R. Eelco, Deploying Configurable Software Product “Software Product Lines in Action: The Best Families”, PFE-5, 2004. Industrial Practice in Product Line Engineering”, Springer, 2007. International Conference on Advanced Aspects of Software Engineering ICAASE, November, 2-4, 2014, Constantine, Algeria. 107