Using Evolution Patterns to Evolve Software Architectures
1 like3,920 views
The document discusses the evolution of software architectures and the necessity for automated support in architectural restructuring to manage complexity in large systems. It covers the use of component and connector views in architectural descriptions, along with goals and methodologies for evolving architectures, such as transforming monolithic systems to client-server models. The practical validation involves a tool called Cosabuilder that integrates with the Cosa ADL to facilitate these architectural evolution processes.
Using Evolution Patterns to Evolve Software Architectures
- 1. Using Evolu,on Pa/erns to Evolve So4ware Architectures Joint work with Dalila Tamzalit, Université de Nantes, France Published in IEEE ECBS 2010, Oxford With help of Aurélien Lansmanne for the implementaMon
- 2. Context : So4ware Architectures SoOware development process – Requirements – Architecture – Design – ImplementaMon Architectural descripMons – Capture strategic decisions and raMonale at a high-‐level of abstracMon – Provide a basis for detailed design – Are essenMal for expressing and constraining large-‐scale and criMcal systems 3
- 3. Context : So4ware Architectures IEEE/ISO/IEC Standard 1471-‐2000: Recommended Prac,ce Component & connector 4 viewpoint Université de Mons
- 4. Context : So4ware Architectures • C&C viewpoint • Expresses the system structure in terms of components (with ports) related by connectors (with roles) • Architectural DescripMon Language (ADL) • Provides the syntax and semanMcs for the C&C viewpoint • Example • e-‐shop expressed in COSA ADL 5
- 5. Context : Architectural Styles • An architectural style captures recurring architectural paZerns • Examples • Pipe&Filter, Publish-‐Subscribe, Peer-‐to-‐peer, n-‐Mered, … 6
- 6. Context : Architectural Styles • An architectural style captures recurring architectural paZerns • Examples • Client-‐Server 7
- 7. Goal : Architectural Evolu,on • SoOware evoluMon – Is inevitable: Perpetual challenge for large-‐scale systems – Is difficult and expensive • Systems tend to increase in complexity • Several stakeholders, several representaMons • Difficult to manage, lack of abstracMon – Needs to be liOed • Support for evoluMon at architectural level – Needs to be automated • Needs to be built in the language (ADL) and its supporMng tools 8
- 8. Goal : Architecture restructuring • Apply ideas of “program refactoring” at architectural level • Improve architectural structure by automated transformaMons • Examples • Transform legacy systems to client-‐server systems, to N-‐Mered systems, to SOA, … • Introducing an architectural style to an exisMng architecture – Goal • Impose addiMonal structural constraints • While preserving the exisMng funcMonality 9
- 9. Goal : Architecture restructuring Example: from monolithic to client-‐server • Original C&C architecture e-‐shop expressed using COSA ADL 10 Université de Mons
- 10. Goal : Architecture restructuring Example: from monolithic to client-‐server 11 Université de Mons
- 11. Approach Formal valida,on – Assess feasibility using graph transformaMon theory – Provide proof-‐of-‐concept using AGG tool Prac,cal valida,on – Extend exisMng ADL (COSA) with support for evoluMon – Implement the formal ideas in COSABuilder tool Case study – Convert a monolithic architecture (E-‐shop) in a client-‐ server architecture by introducing architectural style 12
- 12. Formal valida,on • Use graph transformaMon theory • Specify proof-‐of-‐concept in AGG tool • Represent ADL metamodel as a type graph • Represent addiMonal constraints as graph invariants • Represent architecture as a graph conforming to this type graph • Represent architectural style • Represent architectural evoluMon steps as graph transforma1on rules • Use formal analysis capabiliMes of AGG 13
- 13. Formal Valida,on • Represent (part of ) COSA ADL metamodel as a type graph • Architectural concepts: component, configuraMon, (provided or required) port or role, connector, binding, aZachment 14
- 14. Formal Valida,on • Represent architecture as a graph conform to this type graph 15
- 15. Formal Valida,on • Represent (part of ) COSA ADL metamodel as a type graph • Derived edge types: connectsTo and connector 16
- 16. Formal Valida,on • Represent (part of ) COSA ADL metamodel as a type graph • Graph invariants • A component cannot be connected to, or contained in, itself. • A uses dependency is only allowed between different ports belonging to the same component. • Two components cannot be at the same Mme connected to, and contained, in one another. • A binding is only allowed between ports of the same type belonging to a component and one of its subcomponents. 17
- 17. Formal Valida,on • Express the architectural style as extension of type graph • with addiMonal graph constraints – Only Client and Server are allowed as top-‐level components – A Client component must always be connected to Server via a connectsTo-‐link 18
- 18. Formal Valida,on • Represent evoluMon operaMons as graph transformaMon rules 19
- 19. Formal Valida,on • Represent evoluMon operaMons as graph transformaMon rules 20
- 20. Formal Valida,on • Ensure preservaMon of internal structural dependencies 21
- 21. Evolu,on pa/ern mandatory phase Université de Mons
- 22. Evolu,on pa/ern manual phase Université de Mons
- 23. Formal Valida,on • Use transformaMon analysis to detect potenMal problems • Based on criMcal pair analysis of parallel conflicts and sequenMal dependencies 24
- 24. Prac,cal Valida,on • COSABuilder • Eclipse plug-‐in supporMng the COSA ADL • Developed @ Modal team -‐ University of Nantes • Object-‐oriented framework, extensible with new concepts • Extend COSABuilder with automated support for evoluMon • Masters thesis of Aurélien Lansmanne
- 25. Prac,cal Valida,on • Extend COSABuilder with evoluMon support • All architectural evoluMon operaMons are reified in the ADL • EvoluMon paZerns expressed in terms of primiMve operaMons • GUI support for selecMng and applying evoluMon paZerns and operaMons • Support for verifying • the contraints imposed by an architectural style • that internal dependencies are preserved by evoluMon
- 26. Prac,cal Valida,on • Applying an evoluMon operaMon (part 1)
- 27. Prac,cal Valida,on • Applying an evoluMon operaMon (part 2)
- 28. Prac,cal Valida,on • Applying an evoluMon paZern to introduce the Client-‐Server architectural style
- 29. Prac,cal Valida,on • Verifiying conformance of an architecture to the Client-‐Server architectural style (1) (2)
- 30. Prac,cal Valida,on • Verifiying conformance of an architecture to the Client-‐Server architectural style (1) (2)
- 31. Future Work • SupporMng mutlipe ADLs, mulMple viewpoints, mulMple styles • Carrying out more case studies • Expressing non-‐structural aspects of an architectural descripMon • Considering other evoluMon scenarios • E.g. changing a style to another one • Extending ADLs with first-‐class support for evoluMon 32
- 32. Future Work con,nued • Dealing with co-‐evoluMon http:// ComputingNow.computer.org. • But also with requirements, run-‐Mme, language evoluMon 33