Upload
acher
View
1.209
Download
7
Tags:
Embed Size (px)
DESCRIPTION
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.
Citation preview
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
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
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
Implementation_BPEL “requires” Interface_WSDL ;Implementation_Spring “requires” MM_SCA ;
14
Illegal Variant
15
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
16
Unused flexibility
17
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
Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10)
18
Software Artefacts
Variability Modeling
Software Architect View
Philippe Merle,software architect of FraSCAti
- Error-prone- Time Consuming
+ Architecture Knowledge+ Scoping Decisions
19
Extraction Process
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
- Error-prone- Time Consuming
+ Architecture Knowledge+ Scoping Decisions
- Documentation of Software Artefacts- Reliability of the Procedure?
+ Automation
12
20
Extraction Process
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
1
2
21
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
22
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
23
Architectural 150% FM: 50 features, 1011 configurations
Plugin FM: 41 features
Mapping: 158 constraints
Reinforced Architectural FM: 106 configurations
24
Extraction Process
Software Artefacts
Variability Modeling
Automatic Extraction
Software Architect View
?
2
1
25
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
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
30
Operational Solution: FAMILIARhttps://nyx.unice.fr/projects/familiar/
31
Future Work• Reiterate the Process
• Architecture Derivation
• Applicability of the procedure to other architectures
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
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
32
?http://frascati.ow2.orghttps://nyx.unice.fr/projects/familiar/