benevol'11 - reverse engineering architectural feature models

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

http://frascati.ow2.org/

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


FM1

Set of Configurations

10


FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints


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


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


FM1


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


FM1


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


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




?

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




?

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


25


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


FM1

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints


FM1

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints


FM1

Version 1.3

Version 1.4...

Version 2.x

http://frascati.ow2.org

Diff

Diff

http://frascati.ow2.org/

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/