Software Architecture: An Introduction

Slide 1

Slide 1 text

So#ware Architecture: An Introduc3on Arie van Deursen Del# University of Technology Image credit: Wikipedia 1 So#ware Engineering Methods, October 2015

Slide 2

Slide 2 text

Main Topics Today •  Architecture in context – Stakeholders, quality aLributes, tradeoﬀs •  Architectural Views – Development, Deployment, Concurrency, ... •  Architectural Styles – Constraints, REST, micro-‐services •  The role of the Architect – Conceptual integrity, keeper of the vision 2

Slide 3

Slide 3 text

Learning From Experts: aosabook.org 3

Slide 4

Slide 4 text

Learning From Students: del#swa.io 4

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Stakeholder Principle: Architectures are created solely to meet stakeholder needs 6

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Joomla Stakeholders del#swa.io 8

Slide 9

Slide 9 text

del#swa.io 9

Slide 10

Slide 10 text

Power/Interest Grid for Stakeholder Priori3za3on 10 hLps://www.mindtools.com/pages/ar3cle/newPPM_07.htm

Slide 11

Slide 11 text

Playframework Power/Interest Grid del#swa.io 11

Slide 12

Slide 12 text

Jekyll del#swa.io 12

Slide 13

Slide 13 text

ISO 25010 So#ware Quality Characteris3cs 13 Functional Suitability Performance Efficiency Compatibility Reliability Portability Maintainability Security Usability ISO 25010

Slide 14

Slide 14 text

Realizing Quality ALributes •  An architecture must realize the required quality aLributes •  Models required that permit reasoning over quality aLributes •  Architectural decisions may have to tradeoﬀ between conﬂic3ng quality aLributes 14

Slide 15

Slide 15 text

Architectural Views: Bones, Muscles, Nerves 15 credit: Henry Muccini

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Jekyll Context View 18 del#swa.io

Slide 19

Slide 19 text

Puppet Deployment View 19

Slide 20

Slide 20 text

Neo4J Development View 20

Slide 21

Slide 21 text

Jekyll Development View 21 del#swa.io

Slide 22

Slide 22 text

22 Credit: Alberto Bacchelli

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

26 del#swa.io Docker Module Dependencies

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

A Viewpoint Taxonomy 28

Slide 29

Slide 29 text

Alterna3ve Catalogs “View types” •  Module •  Component & Connector •  Alloca3on Component & connectors: •  Pipe and ﬁlter, shared data, publish subscribe, client-‐server, p2p, … 29

Slide 30

Slide 30 text

Architectural Style Fundamental organiza@on schema for so9ware systems. Set of predeﬁned element types, with speciﬁed responsibili@es, and rules and guidelines for organizing the rela@onships between them 30

Slide 31

Slide 31 text

Example: Pipes & Filter 31

Slide 32

Slide 32 text

Exampe: (OSI) Layering 32

Slide 33

Slide 33 text

Styles to the Max hLps://www.ics.uci.edu/~ﬁelding/pubs/ disserta3on/ﬁelding_disserta3on.pdf 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Architecture Deﬁned •  A conﬁgura3on 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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Network-‐Based Proper3es •  Performance (network, user-‐perceived) •  Scalability •  Simplicity (separa3on of concerns) •  Modiﬁability (evolvability, conﬁgurability) •  Visibility (monitoring) •  Portability •  Reliability (resilience to component failures) 37

Slide 38

Slide 38 text

Network-‐Based Architectural Styles •  Pipe and ﬁlter •  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

Slide 39

Slide 39 text

Slide 40

Slide 40 text

REST Deriva3on by Style Constraints 40

Slide 41

Slide 41 text

Representa3onal State Transfer •  Collec3on of resources iden3ﬁed by URI •  Components exchange representa@ons of these resources •  Over connectors between the components 41

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Microservices: Key Beneﬁts •  Technology heterogeneity •  Resilience •  Scaling •  Ease of deployment •  Organiza3onal alignment •  Composability •  Op3mizing for replaceability 44

Slide 45

Slide 45 text

Resilience: Monitoring 45

Slide 46

Slide 46 text

Traceability Using Correla3on IDs 46

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Socio-‐ Technical Congruence 54

Slide 55

Slide 55 text

Role of the Architect •  Project Nestor – Outline solu3on, select approach, outline solu3on •  Keeper of the Vision – Keep project on track, win customer conﬁdence •  Quality Guardian – Set quality standards, monitor product quality •  Ini;ator of Change – Iden3fy where project fails, and act on it. 55

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Summary: Stakeholders So#ware architecture is about mee3ng stakeholder needs and balancing tradeoﬀs between conﬂic3ng needs 60 Image credit: Wikipedia

Slide 61

Slide 61 text

Summary: Architectural Views So#ware architecture is about using diﬀerent architectural view to reason about diﬀerent proper3es of the so#ware system 61 Image credit: Wikipedia

Slide 62

Slide 62 text

Summary: Architectural Styles So#ware architecture is about adop3ng established architectural styles that constrain the architectural elements and their interac3ons 62 Image credit: Wikipedia

Slide 63

Slide 63 text

Summary: The Architect Being a so#ware architect is about ensuring conceptual integrity while allowing for change 63 Image credit: Wikipedia