Presentation at ECSA'11 conference (Essen, Germany). Reverse engineering the variability of an existing system is a challenging activity. The architect knowledge is essential to identify variation points and explicit constraints between features, for instance in feature models (FMs), but the manual creation of FMs is both time-consuming and error-prone. On a large scale, it is very difficult for an architect to guarantee that the resulting FM ensures a safe composition of the architectural elements when some features are selected. In this paper, we present a comprehensive, tool supported process for reverse engineering architectural FMs. We develop automated techniques to extract and combine different variability descriptions of an architecture. Then, alignment and reasoning techniques are applied to integrate the architect knowledge and reinforce the extracted FM. We illustrate the reverse engineering process when applied to a representative software system, FraSCAti, and we report on our experience in this context.

1. Reverse Engineering Architectural Feature Models Case Study: FraSCAti software architect Mathieu Acher1, Anthony Cleve2 ,Philippe Collet1, Philippe Merle3, Laurence Duchien3, Philippe Lahire1 1 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory) 2 PReCISEResearch Centre, University of Namur, Belgium 3 INRIA Lille-Nord Europe, Univ. Lille 1 - CNRS UMR 8022, France

3. An OASIS’s standard programming model for SOA

4. http://frascati.ow2.org

5. Large software project with an increasing number of extensions since 2008

7. FraSCAti Extensible Architecture in SCA (excerpt) Variability Variability Variability Variability Variability Variability 3

9. 40Mb All FraSCAti 1.3 features4 Variability

10. Variability “the ability of a system to be efficiently extended, changed, customized or configured for use in a particular context” MikaelSvahnberg, Jilles van Gurp, and Jan Bosch (2005) 5

11. FraSCAtias a Software Product Line Variability 6

12. Challenge: Modeling Variability “central to the software product line paradigm is the modeling and management of variability, that is, the commonalities and differences in the applications” Klaus Pohl (2005) 7

13. 8 Variability Model How to reverse engineer the variability model of an architecture? Architecture e.g., see discussions at SAVA workshop

14. 9 Variability Model FraSCAti Architecture

15. 10 Defacto standard for modeling variability Formal semantics, reasoning techniques, tools Feature Model FraSCAti Architecture explicit representation of legal variants authorized by FraSCati

16. Feature Model Hiearchyof Features + Variability (incl. constraints) Compact representation of a set of configurations Scope: restrict legal variants authorized by FraSCati 11 Set of Configurations

17. 12 FraSCAti Architecture Feature Model Configuration Derived FraSCAti Architecture

18. 13 Not all combinations of architectural elements are valid Implementation_BPEL “requires” Interface_WSDL ; Implementation_Spring “requires” MM_SCA ; Set of Safe Variants authorized by FraSCAti Scope is too large Feature Model FraSCAti Architecture

19. Illegal Variant 14

20. 15 Set of Safe Variants authorized by FraSCAti Scope is too narrow Feature Model FraSCAti Architecture

21. 16 Unused flexibility

22. How to obtain theFeature Model of FraSCAti Architecture? 17 Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10)

25. Extraction Process 20 1 2

26. Automated Extraction 21 150%: rough over approximation of legal configurations Mapping between architectural elements and plugins Projection on architectural elements

27. Projection by Example Formal semantics and automation details in the paper see also “Acher et al., Slicing Feature Models”, ASE’11 22

28. 23 Architectural 150% FM: 50 features, 1011 configurations Plugin FM: 41 features Mapping: 158 constraints Reinforced Architectural FM: 106 configurations

29. Extraction Process 24 1 2

30. Consistency of the Extracted Feature Model? 50 features, more than 106 configurationsWe need (1) automated reasoning techniques(2) to put the Software Architect in the Loop 25

31. 26

32. Reconciliation of Feature Models Vocabulary differs 32 “common” features automatically detected 5 manual correspondences specified Granularity differs (more or less details) Not detected by the automated procedure for 2 features Intentionally forget by the software architect (or not) for 13 features Basic edit techniques are not sufficient to reconcile feature models Extensive use of slicing operator Once reconciled, techniques needed to understand “differences” between the two feature models 27

34. Summary Reverse Engineering the Variability Model of An Architecture Reverse Engineering the Feature Model of FraSCAti Automated Procedure Extracting and Combining Variability Sources (incl. software architect knowledge) Advanced feature modeling techniques have been developed (tool supported with FAMILIAR) Lessons Learned Extraction procedure yields promising results Essential role of software architect To validate the extracted feature model To integrate knowledge 29

35. Operational Solution: FAMILIAR 30 https://nyx.unice.fr/projects/familiar/

36. Future Work Reiterate the Process Architecture Derivation Applicability of the procedure to other architectures 31 http://frascati.ow2.org Version 1.3 Version 1.4 . . . Version 2.x

37. 32 ? http://frascati.ow2.org https://nyx.unice.fr/projects/familiar/

39. Add new application-specificFraSCAtifeatures

40. Generating tailor-made variants for the needs of particular customers or environmentsVariability 33

41. Various Features in OW2 FraSCAti 33 for SCA developers <implementation.bpel>, … <interface.wsdl>, … <binding.ws>, … Property XML, … 5 for SCA users Compiler/launcher Tools: Explorer, Fscript, JMX, Remote Management 25 internals to FraSCAti Supported metamodels Membrane generators Supported Java compilers Membrane factories 34

42. Java JAR Spring OSGi C++ JBI WSDL WAR Large scale software architectures, such as FraSCAti, need... Interoperability Support of different interface/implementation languages, binding protocols, etc. Configuration/Reconfiguration Customizable software for specific requirements Deployment Different target systems For more flexibility Management of variants and variability 35 Variability