Using Evolution Patterns to Evolve Software Architectures

Joint work with Dalila Tamzalit, Université de Nantes, France

Using Evolu,on Pa/erns to Evolve So4ware Architectures

Published in IEEE ECBS 2010, Oxford

With help of Aurélien Lansmanne for the implementaMon

3

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

Université de Mons 4

Context : So4ware Architectures IEEE/ISO/IEC Standard 1471-‐2000: Recommended Prac,ce

Component & connector viewpoint

5

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

Context : Architectural Styles

•  An architectural style captures recurring architectural paZerns

•  Examples •  Pipe&Filter, Publish-‐Subscribe, Peer-‐to-‐peer, n-‐Mered, …

6

Context : Architectural Styles

•  An architectural style captures recurring architectural paZerns

•  Examples •  Client-‐Server

7

8

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

9

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

Université de Mons

•  Original C&C architecture e-‐shop expressed using COSA ADL

Goal : Architecture restructuring Example: from monolithic to client-‐server

10

Université de Mons

Goal : Architecture restructuring Example: from monolithic to client-‐server

11

12

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

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

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

Formal Valida,on

•  Represent architecture as a graph conform to this type graph

15

Formal Valida,on

•  Represent (part of ) COSA ADL metamodel as a type graph •  Derived edge types: connectsTo and connector

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

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

Formal Valida,on •  Represent evoluMon operaMons as graph transformaMon rules

19

Formal Valida,on •  Represent evoluMon operaMons as graph transformaMon rules

20

Formal Valida,on •  Ensure preservaMon of internal structural dependencies

21

Université de Mons

Evolu,on pa/ern mandatory phase

Université de Mons

Evolu,on pa/ern manual phase

24

Formal Valida,on

•  Use transformaMon analysis to detect potenMal problems •  Based on criMcal pair analysis of parallel conflicts and sequenMal dependencies

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

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

Prac,cal Valida,on

•  Applying an evoluMon operaMon (part 1)

Prac,cal Valida,on

•  Applying an evoluMon operaMon (part 2)

Prac,cal Valida,on

•  Applying an evoluMon paZern to introduce the Client-‐Server architectural style

Prac,cal Valida,on

•  Verifiying conformance of an architecture to the Client-‐Server architectural style

(1)

(2)

32

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

33

Future Work con,nued

•  Dealing with co-‐evoluMon

•  But also with requirements, run-‐Mme, language evoluMon

http://ComputingNow.computer.org.

Using Evolution Patterns to Evolve Software Architectures

Documents

Transcript of Using Evolution Patterns to Evolve Software Architectures