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)

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.