Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reverse Engineering Architectural Feature Models

Presentation at ECSA'11 conference (Essen, Germany).
Reverse engineering the variability of an existing system is a challenging activity. The architect knowledge is essential to identify variation points and explicit constraints between features, for instance in feature models (FMs), but the manual creation of FMs is both time-consuming and error-prone. On a large scale, it is very difficult for an architect to guarantee that the resulting FM ensures a safe composition of the architectural elements when some features are selected. In this paper, we present a comprehensive, tool supported process for reverse engineering architectural FMs. We develop automated techniques to extract and combine different variability descriptions of an architecture. Then, alignment and reasoning techniques are applied to integrate the architect knowledge and reinforce the extracted FM. We illustrate the reverse engineering process when applied to a representative software system, FraSCAti, and we report on our experience in this context.

  • Login to see the comments

  • Be the first to like this

Reverse Engineering Architectural Feature Models

  1. 1. Reverse Engineering Architectural Feature Models<br />Case Study: FraSCAti<br />software architect<br />Mathieu Acher1, Anthony Cleve2 ,Philippe Collet1, Philippe Merle3, Laurence Duchien3, Philippe Lahire1<br />1 University of Nice Sophia Antipolis (France), MODALIS team (CNRS, I3S Laboratory)<br />2 PReCISEResearch Centre, University of Namur, Belgium<br />3 INRIA Lille-Nord Europe, Univ. Lille 1 - CNRS UMR 8022, France<br />
  2. 2. Case Study: FraSCAti<br /><ul><li>Open source implementation of Service Component Architecture (SCA)
  3. 3. An OASIS’s standard programming model for SOA
  4. 4.
  5. 5. Large software project with an increasing number of extensions since 2008
  6. 6. Technology-agnostic, adaptability, variants</li></ul>Interface languages (Java, WSDL, OMG IDL, etc.)<br />Implementation languages (Java, Spring, OSGi, BPEL, C/C++, etc.)<br />Binding protocols (WS, REST, JSON-RPC, Java RMI, CORBA, etc.)<br />Non functional aspects, aka SCA intents and policies<br />Packaging formats and deployment targets (JAR, JBI, WAR, OSGi, etc.)<br /><ul><li>FraSCAti architecture is itself implemented in SCA</li></ul>Trans.<br />Sec.<br />log<br />Network<br />2<br />
  7. 7. FraSCAti Extensible Architecture in SCA (excerpt)<br />Variability<br />Variability<br />Variability<br />Variability<br />Variability<br />Variability<br />3<br />
  8. 8. Whatwewant : FraSCAti« à la carte »<br /><ul><li>256Kb FraSCAtireflectivekernel</li></ul>API + membrane controllers<br /><ul><li>2,4Mb + minimal FraSCAti architecture</li></ul>Around 2Mb for EMF & SCA MM<br /><ul><li>2,9Mb + capabilities on the fly</li></ul>Using JDK6 compiler<br /><ul><li>… + FraSCAtifeaturesyouneed
  9. 9. 40Mb All FraSCAti 1.3 features</li></ul>4<br />Variability<br />
  10. 10. Variability<br />“the ability of a system to be efficiently extended, changed, customized or configured for use in a particular context” <br />MikaelSvahnberg, Jilles van Gurp, and Jan Bosch (2005)<br />5<br />
  11. 11. FraSCAtias a Software Product Line<br />Variability<br />6<br />
  12. 12. Challenge: Modeling Variability<br />“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)<br />7<br />
  13. 13. 8<br />Variability Model<br />How to reverse engineer the variability model of an architecture?<br />Architecture<br />e.g., see discussions at SAVA workshop<br />
  14. 14. 9<br />Variability Model<br />FraSCAti Architecture<br />
  15. 15. 10<br />Defacto standard for modeling variability<br />Formal semantics, reasoning techniques, tools<br />Feature Model<br />FraSCAti Architecture<br />explicit representation of legal variants authorized by FraSCati<br />
  16. 16. Feature Model<br />Hiearchyof Features + Variability (incl. constraints)<br />Compact representation of a set of configurations<br />Scope: restrict legal variants authorized by FraSCati<br />11<br />Set of Configurations<br />
  17. 17. 12<br />FraSCAti Architecture<br />Feature Model<br />Configuration<br />Derived FraSCAti Architecture<br />
  18. 18. 13<br />Not all combinations of architectural elements are valid<br />Implementation_BPEL “requires” Interface_WSDL ;<br />Implementation_Spring “requires” MM_SCA ;<br />Set of Safe Variants authorized by FraSCAti<br />Scope is too large<br />Feature Model<br />FraSCAti Architecture<br />
  19. 19. Illegal Variant <br />14<br />
  20. 20. 15<br />Set of Safe Variants authorized by FraSCAti<br />Scope is too narrow<br />Feature Model<br />FraSCAti Architecture<br />
  21. 21. 16<br />Unused flexibility<br />
  22. 22. How to obtain theFeature Model of FraSCAti Architecture?<br />17<br />Lopez et al., On the Need of Safe Software Product Line Architectures. (ECSA’10)<br />
  23. 23. 18<br />- Error-prone<br /><ul><li> Time Consuming</li></ul>+ Architecture Knowledge<br />+ Scoping Decisions <br />Philippe Merle,<br />software architect of FraSCAti<br />
  24. 24. Extraction Process<br />- Error-prone<br /><ul><li> Time Consuming</li></ul>+ Architecture Knowledge<br />+ Scoping Decisions <br />19<br />1<br />2<br />- Documentation of Software Artefacts<br /><ul><li> Reliability of the Procedure?</li></ul>+ Automation <br />
  25. 25. Extraction Process<br />20<br />1<br />2<br />
  26. 26. Automated Extraction<br />21<br />150%: rough over approximation of legal configurations<br />Mapping between architectural elements and plugins<br />Projection on architectural elements<br />
  27. 27. Projection by Example<br />Formal semantics and automation details in the paper<br />see also “Acher et al., Slicing Feature Models”, ASE’11<br />22<br />
  28. 28. 23<br />Architectural 150% FM: 50 features, 1011 configurations<br />Plugin FM: 41 features<br />Mapping: 158 constraints<br />Reinforced Architectural FM: 106 configurations<br />
  29. 29. Extraction Process<br />24<br />1<br />2<br />
  30. 30. Consistency of the Extracted Feature Model? 50 features, more than 106 configurationsWe need (1) automated reasoning techniques(2) to put the Software Architect in the Loop<br />25<br />
  31. 31. 26<br />
  32. 32. Reconciliation of Feature Models<br />Vocabulary differs<br />32 “common” features automatically detected <br />5 manual correspondences specified<br />Granularity differs (more or less details)<br />Not detected by the automated procedure for 2 features<br />Intentionally forget by the software architect (or not) for 13 features<br />Basic edit techniques are not sufficient to reconcile feature models<br />Extensive use of slicing operator<br />Once reconciled, techniques needed to understand “differences” between the two feature models <br />27<br />
  33. 33. Lessons Learned<br /><ul><li>The gap between the two feature models is manageable but reconciliation is time consuming</li></ul>Extraction procedure yields promising results<br />Recovers most of the variability<br />Encourage the software architect to correct his initial feature model<br />Software Architect knowledge is required<br />To control the accuracy of the automated procedure<br />For scoping decisions<br />28<br />
  34. 34. Summary<br />Reverse Engineering the Variability Model of An Architecture <br />Reverse Engineering the Feature Model of FraSCAti<br />Automated Procedure<br />Extracting and Combining Variability Sources<br />(incl. software architect knowledge)<br />Advanced feature modeling techniques have been developed (tool supported with FAMILIAR)<br />Lessons Learned<br />Extraction procedure yields promising results<br />Essential role of software architect <br />To validate the extracted feature model<br />To integrate knowledge<br />29<br />
  35. 35. Operational Solution: FAMILIAR<br />30<br /><br />
  36. 36. Future Work<br />Reiterate the Process<br />Architecture Derivation<br />Applicability of the procedure to other architectures<br />31<br /><br />Version 1.3<br />Version 1.4<br />.<br />.<br />.<br />Version 2.x<br />
  37. 37. 32<br />?<br /><br /><br />
  38. 38. Whatwewant: FraSCAti « à la carte »<br /><ul><li>Support the extensiblenature of SCA</li></ul><sca:implementation><br /><sca:interface><br /><sca:binding><br /><ul><li>Select the right subsetof FraSCAtifeatures to meet application requirements and system constraints
  39. 39. Add new application-specificFraSCAtifeatures
  40. 40. Generating tailor-made variants for the needs of particular customers or environments</li></ul>Variability<br />33<br />
  41. 41. Various Features in OW2 FraSCAti<br />33 for SCA developers<br /><implementation.bpel>, …<br /><interface.wsdl>, …<br /><>, …<br />Property XML, …<br />5 for SCA users<br />Compiler/launcher<br />Tools: Explorer, Fscript, JMX, Remote Management<br />25 internals to FraSCAti<br />Supported metamodels<br />Membrane generators<br />Supported Java compilers<br />Membrane factories<br />34<br />
  42. 42. Java<br />JAR<br />Spring<br />OSGi<br />C++<br />JBI<br />WSDL<br />WAR<br />Large scale software architectures, such as FraSCAti, need...<br />Interoperability<br />Support of different interface/implementation languages, binding protocols, etc.<br />Configuration/Reconfiguration<br />Customizable software for specific requirements<br />Deployment<br />Different target systems <br />For more flexibility<br />Management of variants and variability<br />35<br />Variability<br />