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

2. Case Study: FraSCAti
• Open source implementation of Service Component Architecture (SCA)
• An OASIS’s standard programming model for SOA
• http://frascati.ow2.org
• Large software project with an increasing number of extensions since 2008
Sec. log Tran
s.
Network
• Technology-agnostic, adaptability, variants
– Interface languages (Java, WSDL, OMG IDL, etc.)
– Implementation languages (Java, Spring, OSGi, BPEL, C/C++, etc.)
– Binding protocols (WS, REST, JSON-RPC, Java RMI, CORBA, etc.)
– Non functional aspects, aka SCA intents and policies
– Packaging formats and deployment targets (JAR, JBI, WAR, OSGi, etc.)
• FraSCAti architecture is itself implemented in SCA
2

3. FraSCAti Extensible Architecture in SCA (excerpt)
3

4. What we want : FraSCAti « à la carte »
• 256Kb FraSCAti reflective kernel
• API + membrane controllers
• 2,4Mb + minimal FraSCAti architecture
• Around 2Mb for EMF & SCA MM
• 2,9Mb + capabilities on the fly
• Using JDK6 compiler
• … + FraSCAti features you need
• 40Mb All FraSCAti 1.3 features
4

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

6. Managing variability
of software systems
modeling the variability and
managing its evolution
sound basis
automated techniques
tool support
6

7. How to reverse engineer the variability
model of an architecture?
Variability Model Architecture
7

8. Defacto standard for modeling variability
Formal semantics, reasoning techniques, tools
FraSCAti Architecture
Feature Model
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
explicit representation of legal
variants authorized by FraSCati
8

9. Feature Model
• Hiearchy of Features + Variability (incl. constraints)
• Compact representation of a set of configurations
– Scope: restrict legal variants authorized by FraSCati
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler Set of
Configurations
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany 9

10. Feature Model FraSCAti Architecture
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
Configuration Derived FraSCAti Architecture
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
10

11. Set of Safe
Scope is Variants
authorized by
FraSCAti
too large
Feature Model FraSCAti Architecture
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
11

12. Illegal Variant
12

13. Set of Safe
Scope is Variants
too authorized by
narrow FraSCAti
Feature Model FraSCAti Architecture
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
13

14. Unused flexibility
14

15. How to obtain the Feature Model
of FraSCAti Architecture?
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
Safe composition (Batory et al., 2007, Metzger et al. 2007)
Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10) 15

16. Variability Modeling: Pros and Cons
- Error-prone - Documentation of Software Artefacts
- Time Consuming - Reliability of the Procedure?
+ Architecture Knowledge
+ Scoping Decisions + Automation
Philippe Merle,
software architect of FraSCAti Automated Extraction
16

17. Variability Modeling:
Human Vs Machine?
17

18. Extraction Process
Software
Artefacts
Variability
Modeling
1
Software
Architect View 2 Automatic
Extraction
?
Philippe Merle,
Automated Extraction
software architect of FraSCAti 18

19. Extraction Process
Software
Artefacts
Variability
Modeling 1
Software
Architect View 2 Automatic
Extraction
?
19

20. Automated Extraction
150%: rough over Software Mapping between
approximation of legal Artefacts architectural elements
configurations 1 3 2 and plugins
FMArch 150 FMPlug
Mapping <<requires>>
150% Architectural FM
Plugin Dependencies
Aggregation
FMFull
Projection
on <<requires>>
architectural
elements Projection (Π)
FMArch
Enforced
Architectural FM
20

21. Projection by Example
FMFull
FMArch150 FtAggregation FMPlug
Arch Plugin
Ar1 Ar2 Pl1 Pl2 Pl3
Pl1 => Pl2
Ar3 Ar4 Ar5 Ar6 Ar3 => Pl1
Pl2 => Ar5
Projection (Π) onto Arch, Ar1, …, Ar6
FMArch Optional
Alternative
-Group
Arch Mandatory Or-Group
Ar1 Ar2 Ar3 => Ar5
Ar4 => Ar6
Ar3 Ar4 Ar5 Ar6
Formal semantics and automation details in the paper
see also “Acher et al., Slicing Feature Models”, ASE’11
21

22. 22

23. Extraction Process
Software
Artefacts
Variability
Modeling 1
Software
Architect View 2 Automatic
Extraction
?
23

24. Consistency of the Extracted Feature Model?
50 features,
more than 106 configurations
We need
(1) automated reasoning techniques
(2) to put the Software Architect in the Loop
Software
Automatic
Architect View
Extraction
24

25. FMArch Enforced FMSA Software
Architectural FM Architect View
Reconciling
renaming, Feature Models renaming,
projection, projection,
(e.g., vocabulary and
removal removal
granularity alignment)
Aligned Aligned
Architectural FM Software Architect View
FMArch’ FMSA’
Comparison
Refined More
Archiectural FM refinement
25

26. 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
• Once reconciled, techniques needed to understand
differences between the two feature models
26

27. Lessons Learned
• The gap between the two feature models is
manageable but reconciliation is time consuming
• Extraction procedure yields promising results
– Recovers most of the variability
– Encourage the software architect to correct his initial
feature model
• Software Architect knowledge is required
– To control the accuracy of the automated procedure
– For scoping decisions
27

28. Practical Solution: FAMILIAR
https://nyx.unice.fr/projects/familiar/
28

29. 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

30. Current and ongoing work
• Feature Model Differences
• Evolution of Feature Models and FraSCAti
• Applicability to other software projects
– Eclipse
30

31. Feature Model Differences
Submitted to CAiSE’12
Syntactic differences do not scale
31

32. Evolution of Feature Models and FraSCAti
http://frascati.ow2.org
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding Java Compiler
MMFrascati MMTuscany
constraints
http
rest requires MMFrascati
rest JDK6
Optional
JDT
Alternative-
Group
Version 1.3
Mandatory Or-Group
http requires MMTuscany
Diff
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Version 1.4
Metamodel Binding Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints
rest requires MMFrascati
Optional
Mandatory
Alternative-
Group
Or-Group
.
http requires MMTuscany
.
Diff .
FM1
FraSCAti
SCAParser Assembly Factory Component Factory
Metamodel Binding
Version 2.x
Java Compiler
MMFrascati MMTuscany http rest JDK6 JDT
constraints Alternative-
Optional Group
rest requires MMFrascati Or-Group
Mandatory
http requires MMTuscany
32

33. Managing variability
of software systems
modeling the variability and
managing its evolution
sound basis
automated techniques
tool support
33

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