BENEVOL'11 - Reverse Engineering Architectural Feature Models

Reverse Engineering Architectural Feature Models Case Study: software architect FraSCAti 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• 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 Sec. log Tran s. Network• 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 2

FraSCAti Extensible Architecture in SCA (excerpt) 3

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 4

“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) 5

Managing variability of software systemsmodeling the variability and managing its evolution sound basis automated techniques tool support 6

How to reverse engineer the variability model of an architecture?Variability Model Architecture 7

Defacto standard for modeling variabilityFormal semantics, reasoning techniques, tools FraSCAti Architecture Feature Model FM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java Compiler MMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany explicit representation of legal variants authorized by FraSCati 8

Feature Model• Hiearchy of Features + Variability (incl. constraints)• Compact representation of a set of configurations – Scope: restrict legal variants authorized by FraSCati FM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java Compiler Set of Configurations MMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 9

Feature Model FraSCAti Architecture FM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java Compiler MMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany Configuration Derived FraSCAti ArchitectureFM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java CompilerMMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 10

Set of Safe Scope is Variants authorized by FraSCAti too largeFeature Model FraSCAti ArchitectureFM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java CompilerMMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 11

Illegal Variant 12

Set of Safe Scope is Variants too authorized by narrow FraSCAtiFeature Model FraSCAti ArchitectureFM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java CompilerMMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 13

Unused flexibility 14

How to obtain the Feature Model of FraSCAti Architecture? FM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java Compiler MMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany Safe composition (Batory et al., 2007, Metzger et al. 2007) Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10) 15

Variability Modeling: Pros and Cons - Error-prone - Documentation of Software Artefacts - Time Consuming - Reliability of the Procedure? + Architecture Knowledge + Scoping Decisions + Automation Philippe Merle,software architect of FraSCAti Automated Extraction 16

Variability Modeling:Human Vs Machine? 17

Extraction Process Software Artefacts Variability Modeling 1 Software Architect View 2 Automatic Extraction ? Philippe Merle, Automated Extractionsoftware architect of FraSCAti 18

Extraction Process Software Artefacts Variability Modeling 1 SoftwareArchitect View 2 Automatic Extraction ? 19

Automated Extraction150%: rough over Software Mapping betweenapproximation of legal Artefacts architectural elementsconfigurations 1 3 2 and plugins FMArch 150 FMPlug Mapping <<requires>> 150% Architectural FM Plugin Dependencies Aggregation FMFullProjectionon <<requires>>architecturalelements Projection (Π) FMArch Enforced Architectural FM 20

Projection by Example FMFull FMArch150 FtAggregation FMPlug Arch Plugin Ar1 Ar2 Pl1 Pl2 Pl3 Pl1 => Pl2 Ar3 Ar4 Ar5 Ar6 Ar3 => Pl1 Pl2 => Ar5 Projection (Π) onto Arch, Ar1, …, Ar6 FMArch Optional Alternative -Group Arch Mandatory Or-Group Ar1 Ar2 Ar3 => Ar5 Ar4 => Ar6 Ar3 Ar4 Ar5 Ar6Formal semantics and automation details in the papersee also “Acher et al., Slicing Feature Models”, ASE’11 21

Extraction Process Software Artefacts Variability Modeling 1 SoftwareArchitect View 2 Automatic Extraction ? 23

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 Loop Software Automatic Architect View Extraction 24

FMArch Enforced FMSA Software Architectural FM Architect View Reconciling renaming, Feature Models renaming, projection, projection, (e.g., vocabulary and removal removal granularity alignment) Aligned Aligned Architectural FM Software Architect ViewFMArch’ FMSA’ Comparison Refined More Archiectural FM refinement 25

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 26

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 27

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

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 29

Current and ongoing work• Feature Model Differences• Evolution of Feature Models and FraSCAti• Applicability to other software projects – Eclipse 30

Feature Model Differences Submitted to CAiSE’12 Syntactic differences do not scale 31

Evolution of Feature Models and FraSCAti http://frascati.ow2.org FM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Java Compiler MMFrascati MMTuscany constraints http rest requires MMFrascati rest JDK6 Optional JDT Alternative- Group Version 1.3 Mandatory Or-Group http requires MMTuscany Diff FM1 FraSCAti SCAParser Assembly Factory Component Factory Version 1.4 Metamodel Binding Java Compiler MMFrascati MMTuscany http rest JDK6 JDT constraints rest requires MMFrascati Optional Mandatory Alternative- Group Or-Group . http requires MMTuscany . Diff .FM1 FraSCAti SCAParser Assembly Factory Component Factory Metamodel Binding Version 2.x Java CompilerMMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 32

Managing variability of software systemsmodeling the variability and managing its evolution sound basis automated techniques tool support 33

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

BENEVOL'11 - Reverse Engineering Architectural Feature Models

by Acher

Accessibility

Categories

Upload Details

Usage Rights

Statistics