Reverse Engineering Architectural Feature Models
Mathieu Acher1, Anthony Cleve1 , Philippe Collet2, Philippe Merle3, Laurence Duchien3, Philippe Lahire2
1 PReCISE Research Centre, University of Namur, Belgium2 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory)
3 INRIA Lille-Nord Europe, Univ. Lille 1 - CNRS UMR 8022, France
Case Study: FraSCAti software architect
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
• 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
Network
Sec. Trans.
log
3
FraSCAti Extensible Architecture in SCA (excerpt)
Variability
Variability
Variability
Variability
VariabilityVariability
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
Variability
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)
Variability
6
Managing variability of software systems
modeling the variability and managing its evolution
sound basisautomated techniques
tool support
7
Variability Model
How to reverse engineer the variability model of an architecture?
Architecture
increasing needse.g., SAVA, VASAR international workshops
8
explicit representation of legal variants authorized by FraSCati
Feature Model
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
FraSCAti Architecture
Defacto standard for modeling variabilityFormal semantics, reasoning techniques, tools
9
Feature Model• Hiearchy of Features + Variability (incl. constraints)• Compact representation of a set of configurations– Scope: restrict legal variants authorized by FraSCati
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
Set of Configurations
10
FraSCAti Architecture
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
Feature Model
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
Configuration Derived FraSCAti Architecture
11
Feature Model
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
FraSCAti Architecture
Set of Safe Variants
authorized by FraSCAti
Scope is too large
Not all combinations of architectural elements are valid
Implementation_BPEL “requires” Interface_WSDL ;Implementation_Spring “requires” MM_SCA ;
12
Illegal Variant
13
Feature Model
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
FraSCAti Architecture
Set of Safe Variants
authorized by FraSCAti
Scope is too
narrow
14
Unused flexibility
15
How to obtain the Feature Model of FraSCAti Architecture?
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
Safe composition (Batory et al., 2007, Metzger et al. 2007)
Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10)
16
Philippe Merle,software architect of FraSCAti
Variability Modeling: Pros and Cons
- Error-prone- Time Consuming
+ Architecture Knowledge+ Scoping Decisions
- Documentation of Software Artefacts- Reliability of the Procedure?
+ Automation
Automated Extraction
17
Variability Modeling:
Human Vs Machine?
18
Extraction Process
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
12
Philippe Merle,software architect of FraSCAti Automated Extraction
19
Extraction Process
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
1
2
20
Automated Extraction
1 2
Mapping
Aggregation
Software Artefacts
3
Plugin Dependencies
<<requires>>
FMPlug
150% Architectural FM
FMArch150
<<requires>>
Enforced Architectural FM
FMFull
Projection (Π)
FMArch
150%: rough over approximation of legal configurations
Mapping between architectural elements and plugins
Projection on architectural elements
21
Projection by Example
Ar3 => Pl1Pl2 => Ar5
FtAggregation
Ar2
Ar5 Ar6
Ar1
Ar3 Ar4
ArchFMArch
FMFull
Projection (Π) onto Arch, Ar1, …, Ar6
Ar2
Ar5 Ar6
Ar1
Ar3 Ar4
Arch
FMArch
Ar3 => Ar5Ar4 => Ar6
Pl3Pl2Pl1
Plugin
Pl1 => Pl2
FMPlug150
Optional
Mandatory
Alternative-Group
Or-Group
Formal semantics and automation details in the papersee also “Acher et al., Slicing Feature Models”, ASE’11
22
Architectural 150% FM: 50 features, 1011 configurations
Plugin FM: 41 features
Mapping: 158 constraints
Reinforced Architectural FM: 106 configurations
23
Extraction Process
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
2
1
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 LoopAutomatic Extraction
Software Architect View
25
Software Architect View
Reconciling Feature Models
(e.g., vocabulary and granularity alignment)
Comparison
renaming,projection,
removal
Aligned Software Architect View
Enforced Architectural FM
Aligned Architectural FM
renaming,projection,
removal
More refinement
Refined Archiectural FM
FMSA
FMSA’FMArch’
FMArch
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
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
28
Practical Solution: FAMILIARhttps://nyx.unice.fr/projects/familiar/
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
30
Current and ongoing work
• Feature Model Differences
• Evolution of Feature Models and FraSCAti
• Applicability to other software projects– Eclipse
31
Feature Model Differences
Syntactic differences do not scale
Submitted to CAiSE’12
32
Evolution of Feature Models and FraSCAtiFraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
FraSCAti
SCAParser
Java Compiler
JDK6 JDT
Optional
Mandatory
Alternative-Group
Or-Group
Assembly Factory
resthttp
Binding
MMFrascati
Component Factory
Metamodel
MMTuscany
constraints
rest requires MMFrascatihttp requires MMTuscany
FM1
Version 1.3
Version 1.4...
Version 2.x
http://frascati.ow2.org
Diff
Diff
33
Managing variability of software systems
modeling the variability and managing its evolution
sound basisautomated techniques
tool support
34
?http://frascati.ow2.orghttps://nyx.unice.fr/projects/familiar/