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/