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.

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. 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   hLps://www.mindtools.com/pages/ar3cle/newPPM_07.htm  
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   33  
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  
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  
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  
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