Using Evolution Patterns to Evolve Software Architectures

7,768 views

Published on

This presentation explains a theoretical approach and associated tool support to evolve software architecture descriptions expressed in an architectural description language.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,768
On SlideShare
0
From Embeds
0
Number of Embeds
4,537
Actions
Shares
0
Downloads
43
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Using Evolution Patterns to Evolve Software Architectures

  1. 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. 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. 3. Context  :  So4ware  Architectures     IEEE/ISO/IEC  Standard  1471-­‐2000:  Recommended  Prac,ce   Component  &   connector   4   viewpoint   Université de Mons
  4. 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. 5. Context  :  Architectural  Styles   •  An  architectural  style  captures  recurring   architectural  paZerns   •  Examples   •  Pipe&Filter,  Publish-­‐Subscribe,  Peer-­‐to-­‐peer,  n-­‐Mered,  …   6  
  6. 6. Context  :  Architectural  Styles   •  An  architectural  style  captures  recurring   architectural  paZerns   •  Examples   •  Client-­‐Server   7  
  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. 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. 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. 10. Goal  :  Architecture  restructuring   Example:  from  monolithic  to  client-­‐server   11   Université de Mons
  11. 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. 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. 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. 14. Formal  Valida,on   •  Represent  architecture  as  a  graph  conform  to   this  type  graph     15  
  15. 15. Formal  Valida,on   •  Represent  (part  of  )  COSA  ADL  metamodel  as  a   type  graph   •  Derived  edge  types:  connectsTo  and  connector     16  
  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. 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. 18. Formal  Valida,on   •  Represent  evoluMon  operaMons  as  graph   transformaMon  rules   19  
  19. 19. Formal  Valida,on   •  Represent  evoluMon  operaMons  as  graph   transformaMon  rules   20  
  20. 20. Formal  Valida,on   •  Ensure  preservaMon  of  internal  structural   dependencies   21  
  21. 21. Evolu,on  pa/ern   mandatory  phase   Université de Mons
  22. 22. Evolu,on  pa/ern   manual  phase   Université de Mons
  23. 23. Formal  Valida,on   •  Use  transformaMon  analysis  to  detect   potenMal  problems   •  Based  on  criMcal  pair  analysis  of  parallel  conflicts  and   sequenMal  dependencies   24  
  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. 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. 26. Prac,cal  Valida,on   •  Applying  an  evoluMon  operaMon  (part  1)  
  27. 27. Prac,cal  Valida,on   •  Applying  an  evoluMon  operaMon  (part  2)  
  28. 28. Prac,cal  Valida,on   •  Applying  an  evoluMon  paZern  to  introduce  the   Client-­‐Server  architectural  style  
  29. 29. Prac,cal  Valida,on   •  Verifiying  conformance  of  an  architecture  to   the  Client-­‐Server  architectural  style   (1) (2)
  30. 30. Prac,cal  Valida,on   •  Verifiying  conformance  of  an  architecture  to   the  Client-­‐Server  architectural  style   (1) (2)
  31. 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. 32. Future  Work  con,nued   •  Dealing  with  co-­‐evoluMon   http:// ComputingNow.computer.org. •  But  also  with  requirements,  run-­‐Mme,  language  evoluMon   33  

×