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

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.

FraSCAti Extensible Architecture in SCA (excerpt)

Variability

VariabilityVariability

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

“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

Managing variability of software systems

modeling the variability and managing its evolution

sound basisautomated techniques

tool support

Variability Model

How to reverse engineer the variability model of an architecture?

Architecture

increasing needse.g., SAVA, VASAR international workshops

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

FraSCAti Architecture

Defacto standard for modeling variabilityFormal semantics, reasoning techniques, tools

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

Set of Configurations

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints

Feature Model

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints

Configuration Derived FraSCAti Architecture

Feature Model

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints

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 ;

Illegal Variant

Feature Model

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints

Set of Safe Variants

authorized by FraSCAti

Scope is too

narrow

Unused flexibility

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

Safe composition (Batory et al., 2007, Metzger et al. 2007)

Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10)

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

Variability Modeling:

Human Vs Machine?

Extraction Process

Software Artefacts

Variability Modeling

Automatic Extraction

Software Architect View

Philippe Merle,software architect of FraSCAti Automated Extraction

Extraction Process

Software Artefacts

Automated Extraction

Mapping

Aggregation

Software Artefacts

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

Projection by Example

Ar3 => Pl1Pl2 => Ar5

FtAggregation

Ar5 Ar6

Ar3 Ar4

ArchFMArch

FMFull

Projection (Π) onto Arch, Ar1, …, Ar6

Ar5 Ar6

Ar3 Ar4

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

Architectural 150% FM: 50 features, 1011 configurations

Plugin FM: 41 features

Mapping: 158 constraints

Reinforced Architectural FM: 106 configurations

Extraction Process

Software Artefacts

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

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’FMArch’

FMArch

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

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

Practical Solution: FAMILIARhttps://nyx.unice.fr/projects/familiar/

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

Current and ongoing work

• Feature Model Differences

• Evolution of Feature Models and FraSCAti

• Applicability to other software projects– Eclipse

Feature Model Differences

Syntactic differences do not scale

Submitted to CAiSE’12

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

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints

FraSCAti

SCAParser

Java Compiler

JDK6 JDT

Optional

Mandatory

Alternative-Group

Or-Group

Assembly Factory

resthttp

Binding

MMFrascati

Component Factory

Metamodel

MMTuscany

constraints

Version 1.3

Version 1.4...

Version 2.x

http://frascati.ow2.org

Managing variability of software systems

modeling the variability and managing its evolution

sound basisautomated techniques

tool support

?http://frascati.ow2.orghttps://nyx.unice.fr/projects/familiar/

benevol'11 - reverse engineering architectural feature models

Technology

reverse engineering archeology: reverse engineering

wa-ii-756 · 2020. 3. 5. · wa-ii-756 architectural survey...

f-5-161 - maryland historical trust · f-5-161...

b-4316 · 2020. 3. 6. · b-4316 architectural survey file...

ct-13 mills housect-13 mills house architectural survey file...

sm-431 hazelhurst - maryland historical trust · hazelhurst...

architectural engineering - amie registration … … ·...

a case study in architectural analysis: the evolution of...

44con london 2015 - reverse reverse engineering

benevol 2010

benevol 2012

architectural design architectural design

best reverse mortgages - z reverse mortgage

so, you are saying that our software quality was screwed up...

lookbook the wrap 2019 - anton dell€¦ · reverse!...

benevol keynote: telling stories about software developers

carr-4 weaver-fox house...carr-4 weaver-fox house...

architectural precasters’ design assist role ·...

tejjy inc ppt 10€¦ · architectural & engineering...

curaviva schweiz | gazette dezember 2018...thomas hauser...