Reverse Engineering Architectural Feature Models Mathieu Acher 1 , Anthony Cleve 2 , Philippe Collet 1 , Philippe Merle 3 , Laurence Duchien 3 , Philippe Lahire 1 1 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory) 2 PReCISE Research Centre, University of Namur, Belgium 3 INRIA Lille-Nord Europe, Univ. Lille 1 - CNRS UMR 8022, France Case Study: FraSCAti software architect
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.
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 Cleve2 , Philippe Collet1, Philippe Merle3, Laurence Duchien3, Philippe Lahire1
1 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory)2 PReCISE Research Centre, University of Namur, Belgium
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
FraSCAti as a Software Product Line
Variability
7
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)
8
Variability Model
How to reverse engineer the variability model of an architecture?
Architecture
e.g., see discussions at SAVA workshop
9
Variability Model
FraSCAti Architecture
10
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
11
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
12
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
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 large
Not all combinations of architectural elements are valid
(2) to put the Software Architect in the LoopAutomatic Extraction
Software Architect View
26
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
27
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
28
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
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