Reverse Engineering     Architectural Feature Models                            Case Study:      software architect       ...
Case Study: FraSCAti• Open source implementation of Service Component Architecture (SCA)    •   An OASIS’s standard progra...
FraSCAti Extensible Architecture in SCA (excerpt)                                              3
What we want : FraSCAti « à la carte »• 256Kb   FraSCAti reflective kernel            • API + membrane controllers• 2,4Mb ...
“the ability of a system to be  efficiently  extended, changed, customized  or configured for use in a  particular context...
Managing variability   of software systemsmodeling the variability and managing its evolution        sound basis    automa...
How to reverse engineer the variability       model of an architecture?Variability Model          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  ...
Feature Model                                                             FraSCAti Architecture FM1                       ...
Set of Safe               Scope is                                                              Variants                  ...
Illegal Variant                  12
Set of Safe                  Scope is                                                           Variants                  ...
Unused flexibility                     14
How to obtain the Feature Model   of FraSCAti Architecture?            FM1                                   FraSCAti     ...
Variability Modeling: Pros and Cons  - Error-prone                     - Documentation of Software Artefacts  - Time Consu...
Variability Modeling:Human Vs Machine?                        17
Extraction Process                          Software                          Artefacts                                   ...
Extraction Process                 Software                 Artefacts                             Variability             ...
Automated Extraction150%: rough over                  Software                                    Mapping betweenapproxima...
Projection by Example  FMFull     FMArch150                            FtAggregation                                FMPlug...
22
Extraction Process                 Software                 Artefacts                             Variability             ...
Consistency of the Extracted Feature Model?                              50 features,                      more than 106 c...
FMArch Enforced                                                                 FMSA            Software      Architectura...
Reconciliation of Feature Models• Vocabulary differs  – 32 “common” features automatically detected  – 5 manual correspond...
Lessons Learned• The gap between the two feature models is  manageable but reconciliation is time consuming• Extraction pr...
Practical Solution: FAMILIARhttps://nyx.unice.fr/projects/familiar/                                          28
Summary• Reverse Engineering the Variability Model of An  Architecture   – Reverse Engineering the Feature Model of FraSCA...
Current and ongoing work• Feature Model Differences• Evolution of Feature Models and FraSCAti• Applicability to other soft...
Feature Model Differences           Submitted to CAiSE’12     Syntactic differences do not scale                          ...
Evolution of Feature Models and FraSCAti                                                                                  ...
Managing variability   of software systemsmodeling the variability and managing its evolution        sound basis    automa...
?http://frascati.ow2.orghttps://nyx.unice.fr/projects/familiar/   34
Upcoming SlideShare
Loading in …5
×

BENEVOL'11 - Reverse Engineering Architectural Feature Models

1,007 views
842 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,007
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

BENEVOL'11 - Reverse Engineering Architectural Feature Models

  1. 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, Belgium2 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory) 3 INRIA Lille-Nord Europe, Univ. Lille 1 - CNRS UMR 8022, France
  2. 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. 3. FraSCAti Extensible Architecture in SCA (excerpt) 3
  4. 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. 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. 6. Managing variability of software systemsmodeling the variability and managing its evolution sound basis automated techniques tool support 6
  7. 7. How to reverse engineer the variability model of an architecture?Variability Model Architecture 7
  8. 8. 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
  9. 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. 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 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
  11. 11. 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
  12. 12. Illegal Variant 12
  13. 13. 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
  14. 14. Unused flexibility 14
  15. 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. 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. 17. Variability Modeling:Human Vs Machine? 17
  18. 18. Extraction Process Software Artefacts Variability Modeling 1 Software Architect View 2 Automatic Extraction ? Philippe Merle, Automated Extractionsoftware architect of FraSCAti 18
  19. 19. Extraction Process Software Artefacts Variability Modeling 1 SoftwareArchitect View 2 Automatic Extraction ? 19
  20. 20. 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
  21. 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 Ar6Formal semantics and automation details in the papersee also “Acher et al., Slicing Feature Models”, ASE’11 21
  22. 22. 22
  23. 23. Extraction Process Software Artefacts Variability Modeling 1 SoftwareArchitect View 2 Automatic Extraction ? 23
  24. 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. 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 ViewFMArch’ FMSA’ Comparison Refined More Archiectural FM refinement 25
  26. 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. 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
  28. 28. Practical Solution: FAMILIARhttps://nyx.unice.fr/projects/familiar/ 28
  29. 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. 30. Current and ongoing work• Feature Model Differences• Evolution of Feature Models and FraSCAti• Applicability to other software projects – Eclipse 30
  31. 31. Feature Model Differences Submitted to CAiSE’12 Syntactic differences do not scale 31
  32. 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 CompilerMMFrascati MMTuscany http rest JDK6 JDT constraints Alternative- Optional Group rest requires MMFrascati Or-Group Mandatory http requires MMTuscany 32
  33. 33. Managing variability of software systemsmodeling the variability and managing its evolution sound basis automated techniques tool support 33
  34. 34. ?http://frascati.ow2.orghttps://nyx.unice.fr/projects/familiar/ 34

×