SlideShare a Scribd company logo
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	
  
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	
  
Context	
  :	
  So4ware	
  Architectures
                                                     	
  
                                                                        	
  
      IEEE/ISO/IEC	
  Standard	
  1471-­‐2000:	
  Recommended	
  Prac,ce	
  




      Component	
  &	
  
        connector	
  
                                                                   4	
  
        viewpoint	
  
Université de Mons
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	
  
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	
  
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	
  
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	
  
Goal	
  :	
  Architecture	
  restructuring	
  
    Example:	
  from	
  monolithic	
  to	
  client-­‐server
                                                          	
  
   •  Original	
  C&C	
  architecture	
  
    	
        	
  e-­‐shop	
  expressed	
  using	
  COSA	
  ADL	
  




                                                                      10	
  
Université de Mons
Goal	
  :	
  Architecture	
  restructuring	
  
    Example:	
  from	
  monolithic	
  to	
  client-­‐server
                                                          	
  




                                                                 11	
  
Université de Mons
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	
  
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	
  
Evolu,on	
  pa/ern	
  
                      mandatory	
  phase	
  




Université de Mons
Evolu,on	
  pa/ern	
  
                        manual	
  phase	
  




Université de Mons
Formal	
  Valida,on	
  
•  Use	
  transformaMon	
  analysis	
  to	
  detect	
  
   potenMal	
  problems	
  
   •  Based	
  on	
  criMcal	
  pair	
  analysis	
  of	
  parallel	
  conflicts	
  and	
  
      sequenMal	
  dependencies	
  




                                                                                            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	
  
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)
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	
  
Future	
  Work	
  con,nued	
  
•  Dealing	
  with	
  co-­‐evoluMon	
  


                 http://
                 ComputingNow.computer.org.




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

More Related Content

Viewers also liked

Stakeholder Driven EA
Stakeholder Driven EAStakeholder Driven EA
Stakeholder Driven EA
Real IRM
 
4+1 View Model of Software Architecture
4+1 View Model of Software Architecture4+1 View Model of Software Architecture
4+1 View Model of Software Architecture
bashcode
 
Software Architecture Reconstruction: Why What and How
Software Architecture Reconstruction:  Why What and HowSoftware Architecture Reconstruction:  Why What and How
Software Architecture Reconstruction: Why What and How
Mehdi Mirakhorli
 
A Software Architect's View On Diagramming
A Software Architect's View On DiagrammingA Software Architect's View On Diagramming
A Software Architect's View On Diagramming
meghantaylor
 
Documenting Software Architectures
Documenting Software ArchitecturesDocumenting Software Architectures
Documenting Software Architectures
Paulo Gandra de Sousa
 
An introduction to fundamental architecture concepts
An introduction to fundamental architecture conceptsAn introduction to fundamental architecture concepts
An introduction to fundamental architecture concepts
wweinmeyer79
 

Viewers also liked (6)

Stakeholder Driven EA
Stakeholder Driven EAStakeholder Driven EA
Stakeholder Driven EA
 
4+1 View Model of Software Architecture
4+1 View Model of Software Architecture4+1 View Model of Software Architecture
4+1 View Model of Software Architecture
 
Software Architecture Reconstruction: Why What and How
Software Architecture Reconstruction:  Why What and HowSoftware Architecture Reconstruction:  Why What and How
Software Architecture Reconstruction: Why What and How
 
A Software Architect's View On Diagramming
A Software Architect's View On DiagrammingA Software Architect's View On Diagramming
A Software Architect's View On Diagramming
 
Documenting Software Architectures
Documenting Software ArchitecturesDocumenting Software Architectures
Documenting Software Architectures
 
An introduction to fundamental architecture concepts
An introduction to fundamental architecture conceptsAn introduction to fundamental architecture concepts
An introduction to fundamental architecture concepts
 

Similar to Using Evolution Patterns to Evolve Software Architectures

Show Some Spine!
Show Some Spine!Show Some Spine!
Show Some Spine!
Geoff Gerrietts
 
Clean architecture
Clean architectureClean architecture
Clean architecture
Travis Frisinger
 
Mobile App Architectures & Coding guidelines
Mobile App Architectures & Coding guidelinesMobile App Architectures & Coding guidelines
Mobile App Architectures & Coding guidelines
Qamar Abbas
 
Project P erts2012
Project P erts2012Project P erts2012
Project P erts2012
AdaCore
 
11 topic 9 ooa
11 topic 9 ooa11 topic 9 ooa
11 topic 9 ooa
Ayesha Bhatti
 
Gof design patterns
Gof design patternsGof design patterns
Gof design patterns
Srikanth R Vaka
 
[2016/2017] Modern development paradigms
[2016/2017] Modern development paradigms [2016/2017] Modern development paradigms
[2016/2017] Modern development paradigms
Ivano Malavolta
 
Slicing Models of Real-time Embedded Systems (MDOELS2018)
Slicing Models of Real-time Embedded Systems (MDOELS2018)Slicing Models of Real-time Embedded Systems (MDOELS2018)
Slicing Models of Real-time Embedded Systems (MDOELS2018)
Reza Ahmadi, PhD
 
REST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical LookREST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical Look
Nordic APIs
 
Software is not a Building - Designing Technical Architecture for Change
Software is not a Building - Designing Technical Architecture for ChangeSoftware is not a Building - Designing Technical Architecture for Change
Software is not a Building - Designing Technical Architecture for Change
Cantina
 
Refactoring Legacy Web Forms for Test Automation
Refactoring Legacy Web Forms for Test AutomationRefactoring Legacy Web Forms for Test Automation
Refactoring Legacy Web Forms for Test Automation
Stephen Fuqua
 
IT Software Development Life Cycle
IT Software Development Life CycleIT Software Development Life Cycle
IT Software Development Life Cycle
Preshita Chaurasiya
 
DDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichDDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan Paulovich
Ivan Paulovich
 
Microservices.pdf
Microservices.pdfMicroservices.pdf
Microservices.pdf
SelmaJelovac1
 
Scala in Model-Driven development for Apparel Cloud Platform
Scala in Model-Driven development for Apparel Cloud PlatformScala in Model-Driven development for Apparel Cloud Platform
Scala in Model-Driven development for Apparel Cloud Platform
Tomoharu ASAMI
 
SE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.pptSE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.ppt
MahiDivya
 
Training: MVVM Pattern
Training: MVVM PatternTraining: MVVM Pattern
Training: MVVM Pattern
Betclic Everest Group Tech Team
 
Design Pattern lecture 2
Design Pattern lecture 2Design Pattern lecture 2
Design Pattern lecture 2
Julie Iskander
 
JavaScript - Kristiansand PHP
JavaScript - Kristiansand PHPJavaScript - Kristiansand PHP
JavaScript - Kristiansand PHP
holeedave
 
Think Cloud, Develop Locally
Think Cloud, Develop LocallyThink Cloud, Develop Locally
Think Cloud, Develop Locally
All Things Open
 

Similar to Using Evolution Patterns to Evolve Software Architectures (20)

Show Some Spine!
Show Some Spine!Show Some Spine!
Show Some Spine!
 
Clean architecture
Clean architectureClean architecture
Clean architecture
 
Mobile App Architectures & Coding guidelines
Mobile App Architectures & Coding guidelinesMobile App Architectures & Coding guidelines
Mobile App Architectures & Coding guidelines
 
Project P erts2012
Project P erts2012Project P erts2012
Project P erts2012
 
11 topic 9 ooa
11 topic 9 ooa11 topic 9 ooa
11 topic 9 ooa
 
Gof design patterns
Gof design patternsGof design patterns
Gof design patterns
 
[2016/2017] Modern development paradigms
[2016/2017] Modern development paradigms [2016/2017] Modern development paradigms
[2016/2017] Modern development paradigms
 
Slicing Models of Real-time Embedded Systems (MDOELS2018)
Slicing Models of Real-time Embedded Systems (MDOELS2018)Slicing Models of Real-time Embedded Systems (MDOELS2018)
Slicing Models of Real-time Embedded Systems (MDOELS2018)
 
REST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical LookREST vs. GraphQL: Critical Look
REST vs. GraphQL: Critical Look
 
Software is not a Building - Designing Technical Architecture for Change
Software is not a Building - Designing Technical Architecture for ChangeSoftware is not a Building - Designing Technical Architecture for Change
Software is not a Building - Designing Technical Architecture for Change
 
Refactoring Legacy Web Forms for Test Automation
Refactoring Legacy Web Forms for Test AutomationRefactoring Legacy Web Forms for Test Automation
Refactoring Legacy Web Forms for Test Automation
 
IT Software Development Life Cycle
IT Software Development Life CycleIT Software Development Life Cycle
IT Software Development Life Cycle
 
DDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichDDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan Paulovich
 
Microservices.pdf
Microservices.pdfMicroservices.pdf
Microservices.pdf
 
Scala in Model-Driven development for Apparel Cloud Platform
Scala in Model-Driven development for Apparel Cloud PlatformScala in Model-Driven development for Apparel Cloud Platform
Scala in Model-Driven development for Apparel Cloud Platform
 
SE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.pptSE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.ppt
 
Training: MVVM Pattern
Training: MVVM PatternTraining: MVVM Pattern
Training: MVVM Pattern
 
Design Pattern lecture 2
Design Pattern lecture 2Design Pattern lecture 2
Design Pattern lecture 2
 
JavaScript - Kristiansand PHP
JavaScript - Kristiansand PHPJavaScript - Kristiansand PHP
JavaScript - Kristiansand PHP
 
Think Cloud, Develop Locally
Think Cloud, Develop LocallyThink Cloud, Develop Locally
Think Cloud, Develop Locally
 

More from Tom Mens

How to be(come) a successful PhD student
How to be(come) a successful PhD studentHow to be(come) a successful PhD student
How to be(come) a successful PhD student
Tom Mens
 
Recognising bot activity in collaborative software development
Recognising bot activity in collaborative software developmentRecognising bot activity in collaborative software development
Recognising bot activity in collaborative software development
Tom Mens
 
A Dataset of Bot and Human Activities in GitHub
A Dataset of Bot and Human Activities in GitHubA Dataset of Bot and Human Activities in GitHub
A Dataset of Bot and Human Activities in GitHub
Tom Mens
 
The (r)evolution of CI/CD on GitHub
 The (r)evolution of CI/CD on GitHub The (r)evolution of CI/CD on GitHub
The (r)evolution of CI/CD on GitHub
Tom Mens
 
Nurturing the Software Ecosystems of the Future
Nurturing the Software Ecosystems of the FutureNurturing the Software Ecosystems of the Future
Nurturing the Software Ecosystems of the Future
Tom Mens
 
Comment programmer un robot en 30 minutes?
Comment programmer un robot en 30 minutes?Comment programmer un robot en 30 minutes?
Comment programmer un robot en 30 minutes?
Tom Mens
 
On the rise and fall of CI services in GitHub
On the rise and fall of CI services in GitHubOn the rise and fall of CI services in GitHub
On the rise and fall of CI services in GitHub
Tom Mens
 
On backporting practices in package dependency networks
On backporting practices in package dependency networksOn backporting practices in package dependency networks
On backporting practices in package dependency networks
Tom Mens
 
Comparing semantic versioning practices in Cargo, npm, Packagist and Rubygems
Comparing semantic versioning practices in Cargo, npm, Packagist and RubygemsComparing semantic versioning practices in Cargo, npm, Packagist and Rubygems
Comparing semantic versioning practices in Cargo, npm, Packagist and Rubygems
Tom Mens
 
Lost in Zero Space
Lost in Zero SpaceLost in Zero Space
Lost in Zero Space
Tom Mens
 
Evaluating a bot detection model on git commit messages
Evaluating a bot detection model on git commit messagesEvaluating a bot detection model on git commit messages
Evaluating a bot detection model on git commit messages
Tom Mens
 
Is my software ecosystem healthy? It depends!
Is my software ecosystem healthy? It depends!Is my software ecosystem healthy? It depends!
Is my software ecosystem healthy? It depends!
Tom Mens
 
Bot or not? Detecting bots in GitHub pull request activity based on comment s...
Bot or not? Detecting bots in GitHub pull request activity based on comment s...Bot or not? Detecting bots in GitHub pull request activity based on comment s...
Bot or not? Detecting bots in GitHub pull request activity based on comment s...
Tom Mens
 
On the fragility of open source software packaging ecosystems
On the fragility of open source software packaging ecosystemsOn the fragility of open source software packaging ecosystems
On the fragility of open source software packaging ecosystems
Tom Mens
 
How magic is zero? An Empirical Analysis of Initial Development Releases in S...
How magic is zero? An Empirical Analysis of Initial Development Releases in S...How magic is zero? An Empirical Analysis of Initial Development Releases in S...
How magic is zero? An Empirical Analysis of Initial Development Releases in S...
Tom Mens
 
Comparing dependency issues across software package distributions (FOSDEM 2020)
Comparing dependency issues across software package distributions (FOSDEM 2020)Comparing dependency issues across software package distributions (FOSDEM 2020)
Comparing dependency issues across software package distributions (FOSDEM 2020)
Tom Mens
 
Measuring Technical Lag in Software Deployments (CHAOSScon 2020)
Measuring Technical Lag in Software Deployments (CHAOSScon 2020)Measuring Technical Lag in Software Deployments (CHAOSScon 2020)
Measuring Technical Lag in Software Deployments (CHAOSScon 2020)
Tom Mens
 
SecoHealth 2019 Research Achievements
SecoHealth 2019 Research AchievementsSecoHealth 2019 Research Achievements
SecoHealth 2019 Research Achievements
Tom Mens
 
SECO-Assist 2019 research seminar
SECO-Assist 2019 research seminarSECO-Assist 2019 research seminar
SECO-Assist 2019 research seminar
Tom Mens
 
Empirically Analysing the Socio-Technical Health of Software Package Managers
Empirically Analysing the Socio-Technical Health of Software Package ManagersEmpirically Analysing the Socio-Technical Health of Software Package Managers
Empirically Analysing the Socio-Technical Health of Software Package Managers
Tom Mens
 

More from Tom Mens (20)

How to be(come) a successful PhD student
How to be(come) a successful PhD studentHow to be(come) a successful PhD student
How to be(come) a successful PhD student
 
Recognising bot activity in collaborative software development
Recognising bot activity in collaborative software developmentRecognising bot activity in collaborative software development
Recognising bot activity in collaborative software development
 
A Dataset of Bot and Human Activities in GitHub
A Dataset of Bot and Human Activities in GitHubA Dataset of Bot and Human Activities in GitHub
A Dataset of Bot and Human Activities in GitHub
 
The (r)evolution of CI/CD on GitHub
 The (r)evolution of CI/CD on GitHub The (r)evolution of CI/CD on GitHub
The (r)evolution of CI/CD on GitHub
 
Nurturing the Software Ecosystems of the Future
Nurturing the Software Ecosystems of the FutureNurturing the Software Ecosystems of the Future
Nurturing the Software Ecosystems of the Future
 
Comment programmer un robot en 30 minutes?
Comment programmer un robot en 30 minutes?Comment programmer un robot en 30 minutes?
Comment programmer un robot en 30 minutes?
 
On the rise and fall of CI services in GitHub
On the rise and fall of CI services in GitHubOn the rise and fall of CI services in GitHub
On the rise and fall of CI services in GitHub
 
On backporting practices in package dependency networks
On backporting practices in package dependency networksOn backporting practices in package dependency networks
On backporting practices in package dependency networks
 
Comparing semantic versioning practices in Cargo, npm, Packagist and Rubygems
Comparing semantic versioning practices in Cargo, npm, Packagist and RubygemsComparing semantic versioning practices in Cargo, npm, Packagist and Rubygems
Comparing semantic versioning practices in Cargo, npm, Packagist and Rubygems
 
Lost in Zero Space
Lost in Zero SpaceLost in Zero Space
Lost in Zero Space
 
Evaluating a bot detection model on git commit messages
Evaluating a bot detection model on git commit messagesEvaluating a bot detection model on git commit messages
Evaluating a bot detection model on git commit messages
 
Is my software ecosystem healthy? It depends!
Is my software ecosystem healthy? It depends!Is my software ecosystem healthy? It depends!
Is my software ecosystem healthy? It depends!
 
Bot or not? Detecting bots in GitHub pull request activity based on comment s...
Bot or not? Detecting bots in GitHub pull request activity based on comment s...Bot or not? Detecting bots in GitHub pull request activity based on comment s...
Bot or not? Detecting bots in GitHub pull request activity based on comment s...
 
On the fragility of open source software packaging ecosystems
On the fragility of open source software packaging ecosystemsOn the fragility of open source software packaging ecosystems
On the fragility of open source software packaging ecosystems
 
How magic is zero? An Empirical Analysis of Initial Development Releases in S...
How magic is zero? An Empirical Analysis of Initial Development Releases in S...How magic is zero? An Empirical Analysis of Initial Development Releases in S...
How magic is zero? An Empirical Analysis of Initial Development Releases in S...
 
Comparing dependency issues across software package distributions (FOSDEM 2020)
Comparing dependency issues across software package distributions (FOSDEM 2020)Comparing dependency issues across software package distributions (FOSDEM 2020)
Comparing dependency issues across software package distributions (FOSDEM 2020)
 
Measuring Technical Lag in Software Deployments (CHAOSScon 2020)
Measuring Technical Lag in Software Deployments (CHAOSScon 2020)Measuring Technical Lag in Software Deployments (CHAOSScon 2020)
Measuring Technical Lag in Software Deployments (CHAOSScon 2020)
 
SecoHealth 2019 Research Achievements
SecoHealth 2019 Research AchievementsSecoHealth 2019 Research Achievements
SecoHealth 2019 Research Achievements
 
SECO-Assist 2019 research seminar
SECO-Assist 2019 research seminarSECO-Assist 2019 research seminar
SECO-Assist 2019 research seminar
 
Empirically Analysing the Socio-Technical Health of Software Package Managers
Empirically Analysing the Socio-Technical Health of Software Package ManagersEmpirically Analysing the Socio-Technical Health of Software Package Managers
Empirically Analysing the Socio-Technical Health of Software Package Managers
 

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