Usually software system variants, developed by Clone-and-own approach, form

Transcription

1

2 ABSTRACT Usually software system variants, developed by Clone-and-own approach, form a starting point for building Software Product Line. To migrate software systems which are deemed similar to a product line, it is necessary to detect the common features and variations between a set of product variants. Reverse engineering the feature model of an existing system is a challenging activity.

3 ABSTRACT In recent years, a lot of work in reverse engineering has addressed the extraction of feature models from different artifacts. Little work addressed extraction of feature model from object-oriented source code.

4 ABSTRACT We proposes a general approach to extract a feature model from objectoriented source code for a set of product variants to support the migration process from conventional software development to software product line engineering.

5 ABSTRACT Two steps of our approach are implemented. The first one is done by extraction of all source code construction primitives for each product variant while the second one is implemented by extraction of commonalties and variations for these product variants using Formal Concept Analysis. We have tested them on some standard case study and obtained promising results and are still working on next steps to extract initial feature model for these product variants.

6 INTRODUCTION Many companies at first develop a number of similar software products without explicitly planning for strategic reuse. Once released, if the product is successful and meets the market, similar products are to be developed [JOH 09]. SPLs are often set up after the implementation of a number of product variants using ad hoc techniques such as copy / paste / modify.

7 INTRODUCTION Creating manually a feature model for an existing system is time-consuming, error-prone, and requires substantial effort from a modeler [SHE 11]. Reverse engineering feature models from source code would improve product maintenance, ease system migration, and the extracted feature model may lead to the production of new products [CHI 90].

8 INTRODUCTION In recent years, a lot of work on reverse engineering has addressed the extraction of feature models from different artifacts but not from source code for a set of software product variants except [ZIA 12]. so, we present an approach to extract a feature model from O.O. source code for a set of product variants to support the migration process from conventional software development to SPLE.

9 Software Product Line Engineering Several definitions of SPLs can be found in the literature: SPL 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 and are developed from a common set of core assets in a prescribed way" [CLE 12].

10 Software Product Line Engineering SPLE focuses on capturing the commonalities and variations between several software products that belong to the same domain. Capturing the variations is the key activity that distinguishes SPLE from other software development approaches: it is called variability management.

11 Software Product Line Engineering In SPL, variability refers to commonalities (assumptions true for each family member) and variations (assumptions about how individual family members differ). In other words it refers to the system properties that make software products similar or different.

12 Software Product Line Engineering SPLE consists in two major steps: domain engineering and application engineering. Domain engineering consists in the development of both the core assets and the feature model for the whole software product family. Application engineering consists in product configuration based on the models from the previous step (Domain Engineering) [CLE 12].

13 Figure 1. SPLE Steps. SPLE Steps

14 SPLE Steps SPLs are usually characterized by two distinct concepts: a set of core assets or reusable components used for the development of new products (core asset model) and a means to represent the commonalities and variations between software products (feature model).

15 Feature Model Variations among software families are modeled and variability managed in most cases using a de facto standard formalism called feature models [ACH 12]. A feature model represents a set of configurations where each valid configuration represents a specific product.

16 Feature Model A Feature Model is "a graphical tree-like notation depicting the hierarchical organization of high level product functionalities represented as features, whereas root of the tree refers to the complete system" [IST 11]. A Feature is "a system property relevant to some stakeholder used to capture commonalities or discriminate among systems in a family and organized in feature Model" [CZA00].

17 Figure 2. Feature Model. Feature Model

18 Figure 3. Valid Product Configurations. Feature Model

19 Feature Model Feature model can be used to represent variability in the following levels [POH05]: (1) Requirement Level (3) Components Level (2) Architectural Level (4) Test artifacts Level: Figure 3. Variability Levels.

20 Related Work In recent years a lot of work has addressed extraction feature model from different artifacts [YAN 09, LOE 07, ALV 08, SHE 11, DUS 11, ACH 11, RYS 11, ZIA 12, ACH 12].

21 Related Work Ryssel et al. [RYS 11] propose an approach to extract feature diagrams using FCA from incidence matrix that contain matching relation as input. It shows the parts of a set of function- block oriented models that describe different controllers of a DC motor.

22 Related Work Alves et al. [ALV 08] take as input textual requirements from which they extract a feature model. They investigate the suitability of information retrieval techniques to identify commonalities and variations in requirement specifications.

23 Related Work Ziadi et al. [ZIA 12] propose an automatic approach for feature identification from source code for a set of product variants. This approach assumes that the product variants use the same vocabulary to name packages, classes, attributes and methods in its source code. They do not consider the linguistic factor, in cases where, for instance, there are two product variants that use two different vocabularies.

24 Related Work Their approach only investigates products in which the variability is represented in the name of classes, methods and attributes, without considering a product lines in which the variability is mainly represented in the body of methods.

25 Related Work

26 Related Work Our approach considers variation in both names and contents, and we use FCA to extract commonalities and variations from product variants.

27 Related Work Acher et al. [ACH 12] take as input product description to extract feature model. Products are described by characteristics (language, license, etc.) with different patterns on values (many-valued, one-valued, etc.). The main contribution of this approach is to extract the variability model of the family of products by an automated technique to synthesize a feature model for a set of products description.

28 Related Work Tabular Data for Wiki Engines Comparison Extracted Feature Model

29 Overview of The Approach

30 Source Code Variation

31 Mapping Model: Variation vs. Feature

32 Example:

33 Formal Concept Analysis FCA is a mathematical method that provides a way to identify meaningful groupings of objects that have common attributes [5].

34 Formal Concept Analysis A formal context describing bank systems (8 systems)by source code elements:

35 Formal Concept Analysis

36 Conclusion & Perspectives We propose an approach to reverse engineering feature model form objectoriented source code for a set of product variants. As future work, we will apply a clustering algorithm on the commonality and variability blocks to determine more precisely each feature implementation. Also we will try to organize the extracted features as a feature model including all cross-tree constraints.

37 References [IST11] ISTOAN, P., J. Klein, G. Perrouin, and J.-M. Jezequel, "Survey and Classification of Software Product Line Variability Modeling Techniques". In IEEE Transactions on Software Engineering, [CZA00] CZARNECKI., K.., and U. Eisenecker. "Generative Programming: Methods, Tools, and Applications". Addison-Wesley, [POB05] POHL, G. Bockle, and F. J. van der Linden, "Software Product Line Engineering: Foundations, Principles and Techniques". Secaucus, NJ, USA: Springer-Verlag New York, Inc., [ACH 11] ACHER M., CLEVE A., COLLET P., MERLE P., DUCHIEN L., LAHIRE P., Reverse Engineering Architectural Feature Models, CRNKOVIC I., GRUHN V., BOOK M., Eds., ECSA, vol of Lecture Notes in Computer Science, Springer, 2011, p [ACH 12] ACHER M., CLEVE A., PERROUIN G., HEYMANS P., VANBENEDEN C., COLLETP., LAHIRE P., On extracting feature models from product descriptions, EISENECKER U. W., APEL S., GNESI S., Eds., VaMoS, ACM, 2012, p [ACH 12] ACHER, M., HEYMANS, P., MICHEL, R., Next-generation model-based variability management: languages and tools, SPLC '12, ACM, 2012, p [ALV 08] ALVES V., SCHWANNINGER C., BARBOSA L., RASHID A., SAWYER P., RAYSONP., POHL C., RUMMLER A., An Exploratory Study of Information Retrieval Techniques in Domain Analysis, SPLC, IEEE Computer Society, 2008, p [CHI 90] CHIKOFSKY, J., CROSS, H., Reverse Engineering and Design Recovery: A Taxonomy, IEEE Softw. 7, 1 (January 1990), p [CLE 12] CLEMENTS, P., NORTHROP, L. M., Software Product lines: Practices and Patterns, Addison-WESLEY, 2001, p.9, p.10, and p.12. [DUS 11] DUSZYNSKI, S., A scalable goal-oriented approach to software variability recovery, Schaefer et al. [SCH 11], 8 pages. [JOH 09] John, S., Eisenbarth, A decade of scoping: a survey, SPLC 09, Carnegie Mellon University, Pittsburgh, PA, USA, 2009, p [LOE 07] LOESCH F., PLOEDEREDER E., Restructuring Variability in Software Product Lines using Concept Analysis of Product Configurations, KRIKHAAR R. L., VERHOEF C., LUCCA G. A. D., Eds., CSMR, IEEE Computer Society, 2007, p [RYS 11] RYSSEL U., PLOENNIGS J., KABITZSCH K., Extraction of feature models from formal contexts. In Proceedings of SPLC Workshops. 2011, p [SHE 11] SHE S., LOTUFO R., BERGER T., WASOWSKI A., CZARNECKI K., Reverse engineering feature models, TAYLOR R. N., GALL H., MEDVIDOVIC N., Eds., ICSE, ACM, 2011, p [TIZ 08] TIZZEI, L., DIAS, M., RUBIRA, C., GARCIA, A., LEE, J Components meet aspects: assessing design stability of a software product line, Journal of Information and Software Technology, 2011, p [YAN 09] YANG Y., PENG X., ZHAO W., Domain Feature Model Recovery from Multiple Applications Using Data Access Semantics and Formal Concept Analysis, ZAIDMAN A., ANTONIOL G., DUCASSE S., Eds., WCRE, IEEE Computer Society, 2009, p [ZIA 12] ZIADI T., FRIAS L., DA SILVA M. A. A., ZIANE M., Feature Identification from the Source Code of Product Variants, MENS T., CLEVE A., FERENC R., Eds., CSMR, IEEE, 2012, p

38