2012 International Conference on Innovations in Information Technology (IIT)
From Intentions to Software Design using an Intentional Software Product Line Meta-Model Sami OUALI, Naoufel KRAIEM, Henda BEN GHEZALA RIADI Lab ENSI, Campus of Manouba Manouba, Tunisia
[email protected],
[email protected],
[email protected]
Abstract—Software Product Line Engineering is a paradigm to develop software which allows the reducing of development costs for each individual product. In this kind of engineering, a family of related products is built out of a common set of core assets. The common characteristics and differences between products are managed in a systematic way. These differences are called variabilities. The variations analysis and the impact of the choices made for a required product are the reason of the main effort to design a product from the product line. In this paper, we try to argue that it is difficult to fully benefit of the SPL if it remains at the software level. The paper proposes a move towards a description of software product line in intentional terms, i.e. intentions and strategies to achieve business goals. We present ISPL, the model to describe intentional Software Product Line. We try through this Meta-models to present the different concepts which we will use in our approach. Thereafter, we propose our process to show how to use this model. This process combines the use of maps, visual techniques for the modeling of product lines, specially features diagrams and Meta-models.
use in a particular context [2]. Variability management in Software Product Lines concerns the expression of common and variable features and to develop applications using these features. Product line variability describes the variation between systems from a product line [3] [4] [5] in terms of properties and qualities, like features that are provided or requirements that are fulfilled. Defining product line variability concerns the determination of what should vary between the systems in a product line. In Software Product Line Engineering, single system can be built rapidly from reusable assets, such as a set of components. We have proposed in our previous work [8] a comparison framework analysis which allows us to identify drawbacks of some existing SPL construction methods. In these methods, apart requirement approaches ones, the problem is the matching between users’ needs and the product offered by developers. Many writers have observed that there is a "conceptual mismatch" [6] [7]. This conceptual mismatch in software product line context concerns the gap between users needs and the variety proposed. We try throwing this paper to suggest a move to intention-driven SPL to bridge the gap between high level users’ goals and low level software product line obtained. We present in this paper a model for intentional Software Product Line modeling.
Keywords- Software Product Line; variability; intentional level; comparison framework; features modeling; metamodels.
I.
INTRODUCTION
Advances in information technologies and constant change in business requirements have transformed software development into a complex task. To avoid this truth, many proposals have merged, always aiming at producing higher software quality and better productivity of development teams. Software product line is one of these proposals. It is based on the reuse of components. Software product lines development approach allows the creation of new products by reusing a set of components called core assets. A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission [16].
We are interested in using our Intentional Metamodel to develop generic software solutions. These solutions try to accommodate the possible functionalities that fulfill stakeholder intentions. Our process is based on goal modeling, feature modeling and metamodels. Goal models model stakeholder intentions to fulfill the system-to-be. We use the map concept to try to model goals with an intentional view. Feature modeling allows us to model the common and variable properties of product-line members throughout all stages of product-line engineering. Metamodels allow the expression of common and variable characteristics of a set of applications. A metamodel represents the concepts, relationships, and semantics of a domain.
Software Product Line Engineering is emerging as a viable and important development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality and flexibility [16]. Software product line engineering optimizes the development of individual systems by leveraging their common characteristics and managing their differences in a systematic way [1]. Differences between the products are called variabilities. Software variability refers to the ability of a software system to be efficiently extended, changed, customized or configured for
978-1-4673-1101-4/12/$31.00 ©2012 IEEE
This paper is organized as follows. A brief description of different concept concerning software product line and variability is presented in the next section. Our previous work, which is the comparison framework, is described in Section 3. An intentional software product line model is presented in Section 4. In Section 5 we present our proposed process. Our
66
Domain Engineering corresponds to the study of the area of product line, identifying commonalities and variabilities among products, the establishment of a generic software architecture and the implementation of this architecture. Indeed, the domain engineering consists on the construction of reusable components known as asset which will be reused for the products building.
case of study is presented in Section 6 which is an example of an Airline Travel Agency process. In Section 7, we try to present the related works. The Section 8 concludes this work with our contribution and research perspectives. II.
SOFTWARE PRODUCT LINE AND VARIABILITY CONCEPTS
Application Engineering is used to find the optimal use for the development of a new product from a product line by reducing costs and development time and improve the quality. At this level, the results of the domain engineering are used for the derivation of a particular product. This derivation corresponds to the decision-making towards the variation points.
The notion of Product Line is inspired from the industrial process and has emerged to the world of software engineering. Software product lines are recognized as a successful approach to reuse in software development [1] [11]. The idea behind software product line is to economically exploit the commonalities between software products, but also to preserve the ability to vary the functionality between these products. These differences refer to the variability which is a key success factor in product lines and reuse. This approach is based on the undertaking of the development of a set of products as a single, coherent development activity. Indeed, products are built from a collection of artifacts from a core asset base that have been specifically designed for use. Core assets include not only the architecture and its documentation but also specifications, software components, tools…
III.
COMPARISON FRAMEWORK
In our previous work, we have elaborated a framework to compare different approaches for the construction of SPL. This framework tries to consider a central concept (SPL) on four different points of view. These views try to respond to some major questions (what, why, how and in what way). Defining a comparison framework has proved its effectiveness in improving the understanding of various engineering disciplines (process, requirements, information systems…) [9] [10]. Therefore, it can be helpful for the better understanding of the field of engineering Software Product Lines. As a result, our framework (Figure 2) is presented in [8].
Variability is the ability of a system to be efficiently extended, changed, customized or configured for use in a particular context [12]. Another definition presents variability as the ability of a system, an asset, or a development environment to support the production of a set of artifacts that differ from each other in a preplanned fashion [13]. In this definition variability means the ability of a core asset to adapt to usages in the different product contexts that are within the product line scope. Indeed, variations in a product line context must be anticipated.
The purpose of the framework analysis is allowing us the identification of the main drawbacks of existing SPL construction methods. We realize that we have a lack of sufficient tool support which covers all the step of SPL engineering. The SPL approaches themselves are not enough automated for deriving automatically a product from a SPL. In addition, these methods didn’t cover all aspects of SPL engineering. Indeed, every method tries to focus on a particular part of SPL construction process. Finally, in these methods, the problem is the matching between users’ needs and the product offered by developers. Many writers have observed that there is a "conceptual mismatch" [6] [7].
The purpose of Variability modeling is to present an overview of a product line's commonality and variability. Variability modeling terms concerns also commonality modeling. The content of a variability model serves as a basis for defining variability within the artifacts that make up the product-line infrastructure as well as for configuring individual product instances and deriving them from the infrastructure.
Figure 1. SPL Engineering levels Figure 2. Software Product Line comparison framework evolution
We try in the next section of this paper to resolve this last drawback by the proposal of a model for intentional SPL modeling. We try to establish the matching between users’ needs and the product offered by developers by the expression
Two levels of engineering: Domain Engineering and Application Engineering define the SPL engineering [13] as presented in Figure 1.
67
of users’ needs in an intentional way. The position adopted in this paper is to suggest a move from the function-driven Software Product Line to intention-driven SPL, i.e. from a functional view of SPL to the intention behind the features of an SPL. IV.
V.
PROPOSED PROCESS
To avoid the drawbacks of the existing methods, we try to propose a new process for the construction of SPL. This process is a flexible approach for automatically building SPL based on variability models. This process is based basically on goal modeling, features modeling, metamodels, constraints…
INTENTIONAL SOFTWARE PRODUCT LINE META-MODEL A. Map representation formalism In our process, we try to cover domain engineering and application engineering. The domain engineering process involves the creation of core assets. In this process, our interest concerns the elicitation of intentions and strategies using the MAP for the design of users’ requirements. A map is a process model expressed in a goal driven perspective which can provides a process representation system based on goals and strategies. The directed nature of the graph shows which goals can follow which one. MAP is considered as Intention-oriented process modeling which follows the human intention of achieving a goal as a force which drives the process [15]. Having represented software product line features intentionality as maps, we will proceed in our process to determine features and their composition according to the Intentional Software Product line.
This section describes a meta-model synthesizing the different interesting points that we previously identified after a state-of-the-art (software product line, intention, feature…). We chose to transform this meta-model into a UML profile to facilitate the integration into UML models and to use it in our MDA approach. We are interested in using our Intentional Metamodel to develop generic software solutions. These solutions try to accommodate the possible functionalities that fulfill stakeholder intentions. A. Meta-model Description As depicted in Figure 6 (cf. Appendix), a product line contains features. A product belongs to one product line and is composed of features. These features associated to a product must check some constraints (mutual exclusion and require relation) throw the conflict and require relationships. The recommends relationship concerns another feature that could be pertinent.
An intention is a goal [17] that expresses what is wanted i.e. a state that is expected to be reached or maintained. Make Room or Flight or Car Booking is an intention to make a reservation for rooms, flights or cars. The accomplishment of this intention leaves the system in the state, booking made.
An intentional software product line is a set of features captured at the business level, in business comprehensible terms and described in an intentional perspective. In this perspective, we focus on the intention it allows to achieve rather than on the functionality it performs. A feature is a set of related requirements that allows the user to satisfy an intention. We have two specializations of features which are MandatoryFeature and VariantFeature. Mandatory features are features which must be present in every configuration of a product from the product line. A variant feature is modeled as a set of variation point. The metamodel allows atomic variation points (Variant) or composite ones (CompositeVariationPoint) for a variant feature. We use the composite pattern to compose a variation point.
Figure 3. Domain Level Engineering using Intentional Software Product Line Model
In our meta-model, we use a part of an existing meta-model map [14] which is a Process Model in which a nondeterministic ordering of intentions and strategies has been included. Map is a labeled directed graph with intentions as nodes and strategies as edges between intentions. A map consists of a number of sections. Each section is a triplet formed by a source intention, a target intention and a strategy. A strategy is a manner to achieve an intention.
This approach is presented in Figure 3. Users’ intentions are captured and modeled using Map Model to obtain an SPL Model. This model contains an intentional view. Variability in intentional software product line modeling is mandatory and due to the need to introduce flexibility in intention achievement.
Figure 7 presents the different concepts of feature Model. The possible relationships between features are presented by FeatureRelationship. The relationships between a parent feature and its child features are categorized as Mandatory features and Optional features. We can find other relationships between features which are And, Xor and Or.
B. Feature Model Feature Models represents all possible products in a Software Product Line in terms of features. This notation allows the description of the features which are present in all the products of the product line and which are considered variable features or which do not appear in all the products.
68
A feature model is a hierarchically arranged set of features. The relationships between a parent feature and its child features (or subfeatures) are categorized as Mandatory features that required, and Optional features that are optional. We can find other relationships between features which are And (all subfeatures must be selected), Alternative (only one subfeature can be selected) and Or (one or more can be selected). A compatibility rules are allowed in features Models. These rules refer to constraints which restrict feature combinations. A feature X excludes Y means that if X appears then Y should not appear and vice versa. A feature X requires Y means that if X appears then Y should appear but not vice versa. Figure 4 presents the different concepts: relationships and compatibility rules between features.
called a multi-path. A map from its Start to its Stop intentions is a multi-path and may contain multi-threads.
Figure 5. The Map of “Make Confirmed Flight Booking”
Three ways are possible to reach the Accept Payment intention allowing a customer to make the payment: By Credit Card Strategy or By Money Order Strategy or By Cash Strategy. Two way are possible to reach the Stop intention either because a customer retracts from making the booking (By customer retraction Strategy) or after payment (Normally). VII. RELATED WORK A number of approaches address in constructing Software Product Line are available in the literature. In the literature, the majority of variability research concerns requirements and architecture. But some works deals with implementation, verification and validation, traceability and software product line management. The literature basically proposes methods or techniques that address only a specific portion of SPL development.
Figure 4. Feature Model Concepts
We use features diagrams to model variability in software product line. We try to capture commonality and variability of domain and to reuse it for the derivation of a specific requirement model in application Level.
There are a number of approaches that ease the product derivation process [21] [22] like product configuration or software mass customization. These approaches are based on the parameterization and composition of the SPL core assets. Its avoid focusing on how the individual products can be obtained. Most of these approaches base their decision models on feature models originally proposed by Kang et al. [23]. Some approaches try to automate the reasoning on feature models [18] [19]. These approaches try to guide stakeholders through the selection of features. However, these approaches concentrate only on functional properties of a product and their dependencies.
We try to manage variability in SPL construction process (functions, structures, behaviors, technologies). Our strategy follows feature modeling approach, MD approach and the managing of the constraints. We base our work on the creation of features models representing the SPL structure. We use state machine to model the behavior in the SPL. This process is based on the automatic transformation of models until obtaining executable applications. The process is flexible because SPL developer has a lot of possibilities for the creation of SPL and its constraints. It permits the generation of a flexible SPL suitable to the users’ requirements elicited in the beginning of the creation process and new ones. VI.
Other approaches are interested on Derivation by transformation. Using Model Driven Engineering (MDE) techniques has played a major role in SPL engineering, for supporting product derivation. A first approach [24] puts the emphasis on product derivation at the design level both for static and behavioral aspects. Static models are described in terms of UML class diagrams. The derivation process uses a decision model to display the variants available for each product. In [25], the authors proposed a product derivation (PD) process which is a tradeoff between automation and flexibility. They try to combine PD approaches by the providing of a tool support automating a significant part of the process.
CASE STUDY: AIRLINE TRAVEL AGENCY
Our case study is an airline travel agency reservation system. It has been taken for defining a hotel, plane and transport booking process. It has been used for illustrating our approach. We use this example to illustrate how we can use Maps to obtain feature model using our approach and some rules and patterns to automate transformations. Figure 5 shows the entire map with the purpose to Make Confirmed Flight Booking. An intention can be achieved by several combinations of sections. These combinations are
The ISPL shares with these approaches the need to describe SPL assets and to retrieve their function driven perspective. It
69
[4]
tries to propose an intention driven description for these assets. As a consequence, ISPL descriptions will bring out the business intention that the SPL assets allows to fulfill. We believe that this contribute to avoid the current mismatch of languages between low level descriptions and business perceived ones.
[5] [6]
VIII. CONCLUSION AND FUTURE WORK
[7]
In this paper, our contribution was the proposal of a model combining software product line, variability, requirements and intentions. This suggested model clarifies the notion of an intentional software product line to model SPL in intentional context. It was build to respond to the following purpose: to focus on the intention it allows to achieve rather than on the functionality it performs. An intentional software product line is captured at the business level, in business comprehensible terms and described in an intentional perspective. This model will be useful to improve the method used for software product line construction by avoiding the conceptual mismatch. We try to establish the matching between users’ needs and the product offered by developers by the expression of users’ needs in an intentional way.
[8]
[9]
[10]
[11]
[12]
In this paper, we have presented a proposal to manage variability during the SPLs construction process using a MAP for goals modeling, features diagrams allows us to model the common and variable properties of product-line members throughout all stages of product-line engineering, metamodels allow the expression of common and variable characteristics of a set of applications.
[13]
Our future work will be the proposal of a tool support to improve interactivity with users and to cover the overall lifecycle of SPL. The tool support will be based on Eclipse plug-in for feature modeling using the Eclipse Modeling Framework (EMF) and Graphical Modeling Framework (GMF), which significantly reduced our development effort. We try throwing this tool to integrate OCL constraints to allow us the verification of models. Using Kermeta [20], a metamodelling environment, allows us to implement the derivation process of models (model composition and model transformation. Our tool support is based on generative development for goal modeling, feature modeling and metamodels. Integrating goals modeling, feature modeling and metamodels as part of a development environment helps to optimally support modeling variability in different artifacts including implementation code, models, documentation, development process guidance... This tool support is a solution to automate the transformations between the different models which we consider in our search.
[16] [17]
[14]
[15]
[18]
[19]
[20]
[21]
[22] [23]
[24]
REFERENCES [1] [2]
[3]
P. Clements and L. Northrop, “Software Product Lines: Practices and Patterns”. Addison-Wesley, Boston, MA, 2000. M. Svahnberg , J. Van Gurp and J. Bosch, “A taxonomy of variability realization techniques”, In: Software Practice & Experience, Vol. 35, No. 8, pp. 705–754, 2005. J. Coplien, D. Hoffman and D. Weiss, “Commonality and variability in software engineering”. In: IEEE Software, Vol. 15, No. 6, pp. 37 – 45, 1998.
[25]
70
K. Pohl, G. Böckle, F. Van der Linden, “Software Product Line Engineering: Foundations, Principles and Techniques”, Springer, 2005. K. C. Kang, J. Lee and P. Donohoe, “Feature-oriented project line engineering”. In: IEEE Software, Vol. 19, No. 4, pp. 58–65, 2002. S. N. Woodfield, “The Impedance Mismatch between Conceptual Models and Implementation Environments”, ER’97 Workshop on Behavioral Models and Design Transformations: Issues and Opportunities in Conceptual Modeling, UCLA, Los Angeles, California, 1997. R. Kaabi, “Une Approche Méthodologique pour la Modélisation Intentionnelle des Services et leur Opérationnalisation” (Thèse de doctorat). Sorbonne: Université de Paris I, 2007. S. Ouali, N. Kraïem and H. Ben Ghezala, “A Flexible Process for SPL construction”. Journal of Computer Science and Engineering (JCSE), Volume 8, Issue 1, July 2011. C. Rolland, “A Comprehensive View of Process Engineering”, Proceeding of the 10th International Conference CAiSE'98, LNCS 1413, Springer Verlag Pernici, C. Thanos (Eds), Pisa, Italie, p. 1-24, 1998. M. Jarke and K. Pohl, “Requirements Engineering: An Integrated View of Representation, Process and Domain”, in Procedings 4th Euro. Software Conf., Springer Verlag, 1993. J. Bosch, “Design & Use of Software Architectures, Adopting and Evolving a product-line approach”, Addison-Wesley, ISBN 0-20167494-7, 2000. J. Van Grup, “Variability in Software Systems, the key to software reuse” (Thesis). Sweden: University of Groningem, 2000. K. Czarnecki and W. Eisenecker, “Generative Programming: Methods, Tools, and Applications”. Addison-Wesley, 2000. C. Rolland, N. Prakash and A. Benjamen, “A Multi-Model View of Process Modelling”, Requirements Engineering Journal, 4:4, 169-187, 1999c. P. Soffer and C. Rolland, “Combining Intention-Oriented and StateBased Process Modelling”, Proceedings of the International Conference on ER’05, LNCS, pp47-62, 2005. http://www.sei.cmu.edu/productlines/ M. Jackson, “Software Requirements & Specifications – a Lexicon of Practice, Principles and Prejudices”. ACM Press. Addison-Wesley, 1995. D. Benavides et al. “FAMA: Tooling a Framework for the Automated Analysis of Feature Models”. In Workshop on Variability Modelling of Software-intensive Systems, 2007. D. Benavides, A. Ruiz-Cort´es, and P. Trinidad. “Automated Reasoning on Feature Models”. Proc. Int’l Conf. on Advanced Information Systems Engineering, 2005. P.-A. Muller, F. Fleurey, J.-M. Jézéquel, “Weaving Executability into Object-Oriented Meta-Languages”, Proc. of MODELS/UML’2005, LNCS, Springer, Jamaica, 2005. C. W. Krueger. “Easing the Transition to Software Mass Customization”. In Workshop on Software Product-Family Engineering (PFE), pages 282–293, London, UK, 2002. Springer-Verlag. C. W. Krueger. “New Methods in Software Product Line Development”. In SPLC, pages 95–102. IEEE, 2006. K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson. “FeatureOriented Domain Analysis (FODA) Feasibility Study”. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Nov. 1990. T. ZIADI AND J.-M. JEZEQUEL, “Software product line engineering with the uml: Deriving products”. In Software Product Lines. pp. 557– 588, 2006. G. PERROUIN, J. KLEIN, N. GUELFI AND J.-M. JEZEQUEL, “Reconciling automation and flexibility in product derivation”. In SPLC ’08: Proceedings of the 2008 12th International Software Product Line Conference (Washington, DC, USA), IEEE Computer Society, pp. 339– 348, 2008.
Figure 6. Intentional Software Product Line Meta-Model.
Figure 7. Feature Concepts Meta-Model
71
