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.

Topics

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
Tweet

More Decks by Arie van Deursen

Other Decks in Technology

Transcript

  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. 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  
  4. 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  
  5. Power/Interest  Grid  for     Stakeholder  Priori3za3on   10  

    hLps://www.mindtools.com/pages/ar3cle/newPPM_07.htm  
  6. ISO  25010     So#ware  Quality  Characteris3cs   13  

    Functional Suitability Performance Efficiency Compatibility Reliability Portability Maintainability Security Usability ISO 25010
  7. 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  
  8. 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  
  9. 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  
  10. 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.  
  11. Reconstruc3on  Execu3on   25   Arie  van  Deursen,  Chris3ne  Hofmeister,

     Rainer  Koschke,  Leon  Moonen,  Claudio  Riva   Symphony:  View-­‐Driven  So#ware  Architecture  Reconstruc3on.  WICSA,  2004.  
  12. 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)  
  13. Alterna3ve  Catalogs     “View  types”   •  Module  

    •  Component  &  Connector   •  Alloca3on     Component  &  connectors:   •  Pipe  and  filter,  shared   data,  publish  subscribe,   client-­‐server,  p2p,  …   29  
  14. 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  
  15. 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  
  16. 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  
  17. 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  
  18. Network-­‐Based  Proper3es   •  Performance  (network,  user-­‐perceived)   •  Scalability

      •  Simplicity  (separa3on  of  concerns)   •  Modifiability  (evolvability,  configurability)     •  Visibility  (monitoring)   •  Portability   •  Reliability  (resilience  to  component  failures)   37  
  19. 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  
  20. Representa3onal  State  Transfer   •  Collec3on  of  resources  iden3fied  by

     URI   •  Components  exchange  representa@ons  of   these  resources   •  Over  connectors  between  the  components   41  
  21. 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  
  22. 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  
  23. Microservices:  Key  Benefits   •  Technology  heterogeneity   •  Resilience

      •  Scaling   •  Ease  of  deployment   •  Organiza3onal  alignment   •  Composability   •  Op3mizing  for  replaceability   44  
  24. 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  
  25. 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  
  26. 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  
  27. 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  
  28. 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  
  29. 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  
  30. 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  
  31. 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  
  32. 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  
  33. Summary:  Stakeholders   So#ware  architecture  is  about   mee3ng  stakeholder

     needs   and  balancing  tradeoffs  between   conflic3ng  needs   60   Image  credit:   Wikipedia  
  34. 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  
  35. Summary:  Architectural  Styles   So#ware  architecture  is  about   adop3ng

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

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