Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software Architecture: An Introduction

Software Architecture: An Introduction

Lecture on software architecture taught within the 2nd year "Software Engineering and Methods" course at Delft University of Technology.


Architecture in context: Stakeholders, quality attributes, tradeoffs

Architectural Views: Development, Deployment, Concurrency, ...

Architectural Styles: Constraints, REST, microservices

The role of the Architect: Conceptual integrity, keeper of the vision

Take away:

Software architecture is about meeting stakeholder needs and balancing tradeoffs between conflicting needs.

Software architecture is about using different architectural view to reason about different properties of the software system.

Software architecture is about adopting established architectural styles that constrain the architectural elements and their interactions.

Being a software architect is about ensuring conceptual integrity while allowing for change.


Arie van Deursen

October 14, 2015

More Decks by Arie van Deursen

Other Decks in Technology


  1. So#ware  Architecture:   An  Introduc3on   Arie  van  Deursen  

    Del#  University  of  Technology   Image  credit:   Wikipedia   1   So#ware  Engineering  Methods,  October  2015  
  2. Main  Topics  Today   •  Architecture  in  context   – Stakeholders,

     quality  aLributes,  tradeoffs   •  Architectural  Views   – Development,  Deployment,  Concurrency,  ...   •   Architectural  Styles   – Constraints,  REST,  micro-­‐services   •  The  role  of  the  Architect   – Conceptual  integrity,  keeper  of  the  vision   2  
  3. Learning  From  Experts:  aosabook.org   3  

  4. Learning  From  Students:  del#swa.io   4  

  5. The  Architecture  of  a  System   •  The  set  of

     fundamental  concepts  or  proper3es   of  the  system  in  its  environment,     •  embodied  in  its  elements  and  rela3onships,     •  and  the  principles  of  its  design  and  evolu3on.   5  
  6. Stakeholder  Principle:       Architectures  are  created   solely

     to  meet   stakeholder  needs   6  
  7. Stakeholders   •  A  stakeholder   –   in  the  architecture

     of  a  system     – is  an  individual,  team,  organiza3on,  or  classes   thereof,   – having  an  interest  in  the  realiza3on  of  the  system.   •  Users,  administrators,  testers,  developers,   deployers,  maintainers,  sponsors,  …   7  
  8. Joomla  Stakeholders   del#swa.io   8  

  9. del#swa.io   9  

  10. Power/Interest  Grid  for     Stakeholder  Priori3za3on   10  

  11. Playframework  Power/Interest  Grid   del#swa.io   11  

  12. Jekyll   del#swa.io   12  

  13. ISO  25010     So#ware  Quality  Characteris3cs   13  

    Functional Suitability Performance Efficiency Compatibility Reliability Portability Maintainability Security Usability ISO 25010
  14. Realizing  Quality  ALributes   •  An  architecture  must  realize  the

     required   quality  aLributes   •  Models  required  that  permit  reasoning  over   quality  aLributes   •  Architectural  decisions  may  have  to  tradeoff   between  conflic3ng  quality  aLributes     14  
  15. Architectural  Views:   Bones,  Muscles,  Nerves   15   credit:

     Henry  Muccini  
  16. Kruchten’s  “4+1  Views”   16   IEEE  So#ware,  November  1995

  17. Architectural  Views     A  view  is  a  representa3on  of

        one  or  more  structural  aspects     of  an  architecture     that  illustrates  how  the  architecture  addresses   one  or  more  concerns     held  by  one  or  more  of  its  stakeholders   17  
  18. Jekyll  Context  View   18   del#swa.io  

  19. Puppet     Deployment   View   19  

  20. Neo4J  Development  View   20  

  21. Jekyll  Development  View   21   del#swa.io  

  22. 22   Credit:  Alberto  Bacchelli  

  23. Development  View     Describes  the  architecture  that  supports  the

      so9ware  development  process.         Communicates  the  aspects  of  the  architecture  of   interest  to  stakeholders  involved  in  building,   tes@ng,  maintaining,  and  enhancing  the  system.   23  
  24. So#ware  Architecture  Reconstruc3on   24   Arie  van  Deursen,  Chris3ne

     Hofmeister,  Rainer  Koschke,  Leon  Moonen,  Claudio  Riva   Symphony:  View-­‐Driven  So#ware  Architecture  Reconstruc3on.  WICSA,  2004.  
  25. Reconstruc3on  Execu3on   25   Arie  van  Deursen,  Chris3ne  Hofmeister,

     Rainer  Koschke,  Leon  Moonen,  Claudio  Riva   Symphony:  View-­‐Driven  So#ware  Architecture  Reconstruc3on.  WICSA,  2004.  
  26. 26   del#swa.io   Docker   Module   Dependencies  

  27. Hierarchical  Edge  Bundles   Danny  Holten:  Hierarchical  Edge  Bundles:  Visualiza3on

     of  Adjacency  Rela3ons  in   Hierarchical  Data.  IEEE  Trans.  Vis.  Comput.  Graph.  12(5):  741-­‐748  (2006)  
  28. A  Viewpoint  Taxonomy   28  

  29. Alterna3ve  Catalogs     “View  types”   •  Module  

    •  Component  &  Connector   •  Alloca3on     Component  &  connectors:   •  Pipe  and  filter,  shared   data,  publish  subscribe,   client-­‐server,  p2p,  …   29  
  30. Architectural  Style   Fundamental  organiza@on  schema     for  so9ware

     systems.     Set  of  predefined  element  types,     with  specified  responsibili@es,   and  rules  and  guidelines  for  organizing  the   rela@onships  between  them   30  
  31. Example:  Pipes  &  Filter   31  

  32. Exampe:  (OSI)  Layering   32  

  33. Styles  to     the  Max   hLps://www.ics.uci.edu/~fielding/pubs/ disserta3on/fielding_disserta3on.pdf  

  34. Representa3onal  State  Transfer  (REST)   •  A  set  of  architectural

     constraints  that,     when  applied  as  a  whole,  emphasizes     –  scalability  of  component  interac3ons,   –  generality  of  interfaces   –  independent  deployment  of  components,   –  and  intermediary  components     •  In  order  to   –   reduce  interac3on  latency,     –  enforce  security,  and   –  encapsulate  legacy  systems   34  
  35. Architecture  Defined   •  A  configura3on  of  architectural  elements  

    (components,  connectors,  and  data)   •  constrained  in  their  rela3onships   •  in  order  to  achieve  a  desired  set  of   architectural  proper3es.   Constraints:  Focus  on  what  is  and  is  not  allowed   35  
  36. 36   Architectural  Styles   A  set  of  architectural  constraints

     restric3ng     the  roles      of  architectural  elements     and  inducing  the  architectural  proper3es    desired  of  a  system,     when  given  a  name,     becomes  an  architectural  style.     Architectural   Style  X   Constraints   Proper3es   Elements  
  37. Network-­‐Based  Proper3es   •  Performance  (network,  user-­‐perceived)   •  Scalability

      •  Simplicity  (separa3on  of  concerns)   •  Modifiability  (evolvability,  configurability)     •  Visibility  (monitoring)   •  Portability   •  Reliability  (resilience  to  component  failures)   37  
  38. Network-­‐Based  Architectural  Styles   •  Pipe  and  filter   • 

    Replicated  repository   •  Cache   •  Client  server   •  Layered  System   •  Layered-­‐Client-­‐Server   •  Client-­‐Stateless-­‐Server   •  Client-­‐Cache-­‐Stateless-­‐ Server   •  Remote  Session   •  Remote  Data  Access   •  Virtual  Machine   •  Remote  Evalua3on   •  Code  on  Demand   •  Event-­‐Based  Integra3on   •  (Brokered)  Distributed   Objects   38  
  39. 39  

  40. REST  Deriva3on  by  Style  Constraints   40  

  41. Representa3onal  State  Transfer   •  Collec3on  of  resources  iden3fied  by

     URI   •  Components  exchange  representa@ons  of   these  resources   •  Over  connectors  between  the  components   41  
  42. HTTP-­‐based  RESTful  Web  API   •  Base  URI,  such  as

        hLp://example.com/resources/   •  Internet  media  type  for  the  data  (e.g.  json)   •  Standard  HTTP  methods     (e.g.,  GET,  PUT,  POST,  or  DELETE)   •  Hypertext  links  to  reference  state   •  Hypertext  links  to  reference  resources   42  
  43. Microservices   •  Small,  autonomous  services     that  work

     together   •  Single  Responsibility  Principle:   – Gather  together  those  things  that     change  for  the  same  reason   •  Strong  cohesion  within  the  service   •  Loose  coupling  among  services   43  
  44. Microservices:  Key  Benefits   •  Technology  heterogeneity   •  Resilience

      •  Scaling   •  Ease  of  deployment   •  Organiza3onal  alignment   •  Composability   •  Op3mizing  for  replaceability   44  
  45. Resilience:  Monitoring   45  

  46. Traceability  Using     Correla3on  IDs   46  

  47. 47  

  48. 48  

  49. The  Role  of  the  Architect     The  architect  is

     responsible  for  designing,   documen@ng,  and  leading  the  construc@on  of  a   system  that  meets  the  needs  of  all  its   stakeholders.   49  
  50. Fred  Brooks:  Conceptual  Integrity   The  quality  of  a  system

     where  all  the  concepts  and   their  rela3onships  with  each  other  are  applied  in  a   consistent  way  throughout  the  system.     Conceptual  Integrity  is  the  most  important   considera@on  in  system  design.       It  is  beIer  to  have  […]  one  set  of  design  ideas,       than  [...]  many  good  but  independent  and   uncoordinated  ideas.   50  
  51. A  Team  of  Architects?     Conceptual  integrity  in  turn

     dictates     that  the  design  must  proceed  from  one  mind,  or   from  a  very  small  number     of  agreeing  resonant  minds   51  
  52. Conway’s  Law       “Organiza@ons  which  design  systems  ...

        are  constrained  to  produce  designs     which  are     copies  of  the  communica@on  structures     of  these  organiza@ons”     Melvin  Conway,  1968   52  
  53. 53  

  54. Socio-­‐ Technical   Congruence   54  

  55. Role  of  the  Architect   •  Project  Nestor   – Outline

     solu3on,  select  approach,  outline  solu3on   •  Keeper  of  the  Vision   – Keep  project  on  track,  win  customer  confidence   •  Quality  Guardian   – Set  quality  standards,  monitor  product  quality   •  Ini;ator  of  Change   – Iden3fy  where  project  fails,  and  act  on  it.   55  
  56. The  Evolu3onary  Architect     “architects  need  to  shi9  their

     thinking  away   from  crea@ng  the  perfect  end  product,       and  instead  focus  on  helping  create  a  framework   in  which  the  right  systems  can  emerge,     and  con@nue  to  grow  as  we  learn  more.”   56  
  57. So#ware  Architect  =  Town  Planner   •  ALempt  to  op3mize

     the  layout  of  a  city     – to  best  suit  the  needs  of  the  ci3zens  today,     – taking  into  account  future  use     •  Cannot  foresee  everything  that  will  happen.   – Don’t  plan  for  any  eventuality,     – Plan  to  allow  for  change   57  
  58. The  Coding  Architect?   •  Architects  must  ensure  that  

      systems  are  ‘habitable’  for  developers  too.   •  Architects  must  spend  3me  with  the  team   •  Architects  must  spend  3me  coding   – Pair  with  a  developer   – Beyond  code  review   •  This  should  be  a  rou@ne  ac3vity   58  
  59. Suggested  Reading   1.  Amy  Brown  and  Greg  Wilson  (eds).

     The  Architecture  of  Open  Source   Applica3ons.  aosabook.org,  2012.   2.  Arie  van  Deursen  and  Rogier  Slag  (eds).  Del#  Students  on  So#ware   Architecture  (DESOSA).  del#swa.io,  2015.   3.  Greg  Rozanski  and  Eoin  Woods.  So#ware  Systems  Architecture.  Addison-­‐ Wesley,  2012.   4.  Philippe  Kruchten.  The  4+1  View  Model  of  Architecture.  IEEE  So#ware,   1995.   5.  Frederic  Brooks.  The  Mythical  Man  Month.  Addison-­‐Wesley,  1975   6.  Roy  Fielding.  Architectural  Styles  and  the  Design  of  Network-­‐based   So#ware  architectures.  PhD  Thesis,  UC  Irvine,  2000.   7.  Sam  Newman.  Building  Micro  Services.  O’Reilly,  2015.   59  
  60. Summary:  Stakeholders   So#ware  architecture  is  about   mee3ng  stakeholder

     needs   and  balancing  tradeoffs  between   conflic3ng  needs   60   Image  credit:   Wikipedia  
  61. Summary:  Architectural  Views   So#ware  architecture  is  about   using

     different  architectural  view   to  reason  about  different   proper3es  of  the  so#ware  system   61   Image  credit:   Wikipedia  
  62. Summary:  Architectural  Styles   So#ware  architecture  is  about   adop3ng

     established  architectural  styles   that  constrain  the  architectural   elements  and  their  interac3ons   62   Image  credit:   Wikipedia  
  63. Summary:  The  Architect   Being  a  so#ware  architect  is  about

      ensuring  conceptual  integrity   while  allowing  for  change   63   Image  credit:   Wikipedia