Reverse Engineering Architectural Feature Models Mathieu Acher 1 , Anthony Cleve 1 , Philippe Collet 2 , Philippe Merle 3 , Laurence Duchien 3 , Philippe Lahire 2 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 Case Study: FraSCAti software architect
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
• 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
(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
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