BENEVOL'11 - Reverse Engineering Architectural Feature Models
Report
Share
•1 like•1,402 views
BENEVOL'11 - Reverse Engineering Architectural Feature Models
•1 like•1,402 views
Report
Share
Download to read offline
More Related Content
Similar to BENEVOL'11 - Reverse Engineering Architectural Feature Models
Similar to BENEVOL'11 - Reverse Engineering Architectural Feature Models(20)
More from University of Rennes, INSA Rennes, Inria/IRISA, CNRS
More from University of Rennes, INSA Rennes, Inria/IRISA, CNRS(20)
Recently uploaded
Recently uploaded(20)
BENEVOL'11 - Reverse Engineering Architectural Feature Models
- 1. 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, Belgium 2 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory) 3 INRIA Lille-Nord Europe, Univ. Lille 1 - CNRS UMR 8022, France
- 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 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
- 3. FraSCAti Extensible Architecture in SCA (excerpt) 3
- 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 4
- 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) 5
- 6. Managing variability of software systems modeling the variability and managing its evolution sound basis automated techniques tool support 6
- 7. How to reverse engineer the variability model of an architecture? Variability Model Architecture 7
- 8. Defacto standard for modeling variability Formal 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
- 9. 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
- 10. 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 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 10
- 11. Set of Safe Scope is Variants authorized by FraSCAti too large 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 11
- 12. Illegal Variant 12
- 13. Set of Safe Scope is Variants too authorized by narrow FraSCAti 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 13
- 14. Unused flexibility 14
- 15. 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
- 16. 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
- 17. Variability Modeling: Human Vs Machine? 17
- 18. Extraction Process Software Artefacts Variability Modeling 1 Software Architect View 2 Automatic Extraction ? Philippe Merle, Automated Extraction software architect of FraSCAti 18
- 19. Extraction Process Software Artefacts Variability Modeling 1 Software Architect View 2 Automatic Extraction ? 19
- 20. Automated Extraction 150%: rough over Software Mapping between approximation of legal Artefacts architectural elements configurations 1 3 2 and plugins FMArch 150 FMPlug Mapping <<requires>> 150% Architectural FM Plugin Dependencies Aggregation FMFull Projection on <<requires>> architectural elements Projection (Π) FMArch Enforced Architectural FM 20
- 21. 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 Ar6 Formal semantics and automation details in the paper see also “Acher et al., Slicing Feature Models”, ASE’11 21
- 22. 22
- 23. Extraction Process Software Artefacts Variability Modeling 1 Software Architect View 2 Automatic Extraction ? 23
- 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 Loop Software Automatic Architect View Extraction 24
- 25. 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 View FMArch’ FMSA’ Comparison Refined More Archiectural FM refinement 25
- 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 26
- 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 27
- 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 29
- 30. Current and ongoing work • Feature Model Differences • Evolution of Feature Models and FraSCAti • Applicability to other software projects – Eclipse 30
- 31. Feature Model Differences Submitted to CAiSE’12 Syntactic differences do not scale 31
- 32. 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 Compiler MMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 32
- 33. Managing variability of software systems modeling the variability and managing its evolution sound basis automated techniques tool support 33