Introduction to Software Architecture · 2012. 9. 18. · Introduction to Software Architecture George Fairbanks 18 September 2012 Rhino Research Software Architecture Consulting

Introduction to Software Architecture

George Fairbanks

18 September 2012

Rhino ResearchSoftware Architecture Consulting and Training

Copyright 2007-2012 George Fairbanks, Rhino Research

A tale of two systems

Plain Old Telephone System

• Feature: ß Call subscriber

• Architecture:ß Centralized hardware switch

• Good qualitiesß Works during power outagesß Reliableß Emergency calls get location

information

Skype

• Feature: ß Call subscriber

• Architecture:ß Peer-to-peer software

• Good qualitiesß Scales without central

hardware changesß Easy to add new features

(e.g., video calling)

2

Architects pay more attention to qualitiesthat arise from architecture choices.

Same featureSame feature


Let’s design a system!

• Here’s the situationß You are a hosting providerß You rent mail serversß Customers have problemsß You use the mail log files to

diagnose their problems

• The big question: ß How would you build it?

• Let’s assume you can build itß … but different architectures

yield different qualities

• Why is this hard?ß You have hundreds of serversß You generate GBs of logs dailyß Collecting logs takes timeß Searching logs takes time

• Hints and optionsß Central collection of logs?ß Distributed searching of logs?ß Can you pre-process logs to

speed up queries?

3


Surprise! The system is real: Rackspace

• Exercise based on real experienceß Rackspace is a hosting providerß Huge growth in customers, mail servers – and problemsß Re-designs: 3 major versions (6 total versions)

• Let’s review the 3 systems they builtß All 3 had the same functionality (!)ß … but different architectures

• Why this is so coolß Very expensive to build the same system 3 timesß The only big change was the architectureß So, we can see the effect of architectureß … especially on quality attributes

4

Source: http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoop-query-terabytes-data

http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoop-query-terabytes-data

Copyright 2007-2012 George Fairbanks, Rhino Research5

Rackspace: Architecture 1

• Hosting provider of email service• Email log files

• Task: debug user problem

• Architectureß CSR desktop computerß ssh connections to serversß Servers with local log files

• Procedureß Write query as grep expressionß Script runs via ssh on every serverß Results aggregated

…

CSR desktop

ssh

Logdata

EmailServers

CSR





• Architectureß CSR desktop computerß Web applicationß MySQL databaseß scp log transfer ß Servers with local log files

• Procedureß Every 10 minutes, send log files to

MySQL server; delete originalß Parse and load logs into MySQL ß Combine new logs with oldß Send query to MySQL server;

answered from DB data …

CSR

CSR desktop

scp

EmailServers

Logdata

MySQL

Web / http

Web app

SQL

DB





• Architectureß CSR desktop computerß Web applicationß Distributed filesystemß Map-Reduce job clusterß Servers with local log files

• Procedureß Log data continuously streamed

from email servers to distributed filesystem (HDFS)

ß Every 10 minutes, Map-Reduce job runs to process log files, create index

ß Web app queries index

…

CSR

CSR desktop

scp

EmailServers

Map-ReduceJob

Web / http

Web app

DistributedFilesystem


Rackspace: Quality attribute tradeoffs

• Tradeoff: Data freshnessß V1: Queries run on current dataß V2: Queries run on 10 minute old dataß V3: Queries run on 10-20 minute old data

• Tradeoff: Scalabilityß V1: Noticeable email server slowdown (dozens of servers)ß V2: MySQL speed/stability problems (hundreds of servers)ß V3: No problems yet

• Tradeoff: Ad hoc query easeß V1: Regular expressionß V2: SQL expressionß V3: Map-Reduce program


What is software architecture?

• In loose language: ß It’s the “big picture” or “macroscopic” organization of the system

• Problem with these definitionsß Why are some detailed designs architectural, others not?ß Architecture includes whatever architects say it does

The software architecture of a computing system is the set of structuresneeded to reason about the system, which comprise software elements, relations among them, and properties of both. [Documenting Software Architectures (SEI) 2010]

Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. [IEEE 2000]


All programs have an architecture

• Every program has an architecture• … but not every architecture suits the program

• System requirementsß Functional needsß Quality needs (e.g., performance, security)

• Alignment*ß Different architectures support different requirementsß E.g., supporting high throughput vs. interactivityß Right: Suitable vs. unsuitable

• Wrong: Good vs. bad

• Hard to change architecture laterß Does not mean BDUFß But, need to think “enough”

* Generally, this word is overused by consultants


What if you don’t think architecturally?

• Developers optimize locally, miss the big pictureß Lousy choice of frameworks, languages, …

• Project success depends on having virtuosos in the teamß But how many James Goslings and Jeff Deans are there?

• Poor communicationß Idiosyncratic notations, fuzzy semantics

• Shallow (or no) analysis of design optionsß Ad hoc; no use of best practicesß From first principles, therefore high effortß Little attention to tradeoffs and rationale

• Architectural patterns ignoredß … or incorrectly chosenß Squandering known-good designs

11


Virtuosos and Roman engineers

• Life is unfairß Mozart was a virtuoso composerß Some of you are virtuoso software designers

• Today, every civil engineer is better than Roman engineersß Virtuosos invent cement – the rest of us can use itß And you are a 99th percentile mathematician – for the 17th centuryß We can teach engineering and math

• Can we teach software architecture?ß Yep, we’re getting pretty good at itß Sorry, we can’t make you Mozart

12


Overview

• Architecture, architecting, architects• Views• Quality attributes• Analysis• Standard notations• Guiderails• Architectural styles• Conceptual model• Engineering with models• Canonical model structure• Models and code• Process and risk

13

Desi

gn

Domain model

Boundary model

designation

Internals model

refinement

Code model

designation

ViewMaster model

Real-world problem Real-world solution

Model problem

Model solution

solve

solve

abstract concretize


Architecture vs. architecting vs. architect

• Must keep these ideas separate:ß The job title/role “architect”ß The process of architecting/designing (also: when)ß The engineering artifact called the architecture

• Course focus: architecture (the engineering artifact)

• Every system has an architectureß Identify it by looking back (avoids tangling with process & roles)ß E.g., “Aha, I see it is a 3-tier architecture”

• Help disentanglingß Car architecturesß Rackspace architectures

14See: Just Enough Software Architecture, Ch 1 Sec 5


Views


Views

• Definitionß A view is a projection of a model

showing a subset of its detailsß A view is a relationship between

two models

• Views: the modeling workhorse

• Projections from master modelß Master model has all details

• I.e., THE designß Views are projections of the

master model• Subsets of its information

• Master model may not concretely existß E.g., build top-down 2D view of

house, imagine 3D modelß Imagine 3D house modeling

software• Can project any cross-section

(view)• Ignore concrete representation of

3D model (arbitrary choice)

ViewMaster model

Has all details

Subset of details

See: Just Enough Software Architecture, Ch 13


Multiple views

• Example house views:ß 2D view of floor planß Electric wiring circuitsß CAT5 wiring and routingß HVAC distributionß Plumbingß Landscapingß Inventory of windowsß Taxationß Zoning

2D Floor plan View

Windows:ß 3 in frontß 4 in back

Window View

…HVAC View

…Electric View

Master model



Architectural viewtypes

• Definition:ß A viewtype is a category of views that are easy to reconcile with

each other.• E.g., physical, political views of a house

• Reconciling views in a viewtypeß Easy within viewtype

• E.g., electrical and floorplan = easyß Hard between viewtypes

• E.g., taxation and roofing = hard

• Standard architectural viewtypesß Module viewtype

• Source code, config files, module dependenciesß Runtime viewtype (aka component and connector, C&C viewtype)

• Components, connectors, portsß Allocation viewtype

• Servers, geography



Quality Attributes


Quality attributes (QA’s)

• Definition: A quality attribute is a dimension of quality used to evaluate a software system.ß E.g., performance, scalability, modularity, usability, securityß A.k.a., non-functional qualities, extra-functional qualities, the “ities”

• Generally, any architecture can achieve any featureß BUT: qualities will suffer or be harder to achieve

• Why study QA’s?ß Significant failure risks from QA’sß Intersection of business & technology

• Software architecture & QA’sß Architecture decides range of QA possibilitiesß Architectures evaluated w.r.t. QA’s

See: Just Enough Software Architecture, Ch 12 Sec 10


QA's as independent dimensions

• Optimizing one QAß Architecture, design changes to maximize a QAß Generally, 1 QA is easy

• Optimizing across many QA’sß Cannot maximize all QA’s at onceß Tradeoffs

• E.g., most usable UI might be less secure• E.g., highest throughput is batch mode UI

ß “Design space” – choosing is hard

• Consequence: Must prioritize QA’s

throughput

security

usability

Your system will live at a point in the

Design Space


Analysis


Trade-offs

• Tradeoff: More of this ‡ less of that

• Examples

ß Portability vs. playback efficiency. Platform-specific resources (e.g., dedicated hardware) often provide media playback benefits, including efficiency, yet using these resources ties the software to that platform

ß Weight vs. speed. The heavier a car is, the slower it accelerates.

• Everything trades off against cost



Architecture drivers

Architecture drivers

• Template: stimulus and responseß Stimulus: agent or situation that

triggers scenarioß Response: reaction to stimulus

• Each QA scenario can be graded by:ß Importance to stakeholder

(high, medium, low)ß Difficulty to implement

(high, medium, low)

• Architecture drivers are ß QA scenarios ß or functional scenarios (eg use

cases) ß that are rated (H,H)

Examples

• S1 (H,H): ß When a librarian scans a book

copy for checkout, the system updates its records and is ready to scan the next one within 0.25 seconds.

• S2 (M,H): ß When librarian station cannot

contact the main system, librarians can continue to check books in and out.

24

QA scenarios and drivers from Bass et al., Software Architecture in Practice, 2003See: Just Enough Software Architecture, Ch 12 Sec 11


Rational architecture decisions

• Design rationales explain why• They should align with your quality attribute priorities

is a priority, so we chose design , accepting downside .

• An example:

ß Since avoiding vendor lock-in is a high priority, we choose to use a standard industry framework with multiple vendor implementations, even though using vendor-specific extensions would give us greater performance.

• But: Good intentions can go awryß E.g., performance optimization hindering modifiability



Analyzing views

• Views make analysis easierß Choice of view essential

• Some views have custom visualizationsß Usually improve analysis or comprehension

• Which view makes the question easy?ß What is shortest path?ß Estimated temperature?ß Impact of short in bathroom?ß Good afternoon reading light?ß Tax burden of new wing?

2D Floor plan View

…HVAC View

…Electric View



Standard Notations


Standard notation (UML)

• “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.” – Alfred Whitehead, 1911

• Clear, consistent notationß Aids communicationß Aids analysis

• UMLß Not perfect for architectureß One size fits all

28

From UML 2.1.2 specification


Guiderails


Guiderails (constraints)

• Developers voluntarily constrain systemsß Counter-intuitiveß Ensures what a system does not doß I.e., guiderails

• Constraints help ensure outcomesß E.g., ensure quality attributes are metß No constraints = no analysis

• Examples of architectures ‡ QA’sß Plugins must use cross-platform API to read files ‡ portabilityß EJBeans must not start own threads ‡ manageabilityß EJBeans must not write local files ‡ distribution



Architectural Styles


Architectural styles

• Examplesß Big ball of mudß Client-serverß Pipe-and-filterß Map-reduceß N-tierß Layeredß …

• Each predefinesß Elements (e.g., pipes, map functions)ß Constraints, …

• Benefitsß Known tradeoffsß Known suitabilityß Compact terminology for communication

32See: Just Enough Software Architecture, Ch 14


Conceptual Model


What is a conceptual model?

• What is a conceptual model?ß A conceptual model is a set of concepts that can be imposed on raw

events to provide meaning and structure.

• It organizes chaosß Enables intellectual understandingß Fits big problems into our finite minds

• Synonyms: ß Conceptual frameworkß Mental model



Examples of conceptual models

Physics: Free Bodies

Econ: Supply & demandEnergy cycle Accounting: Debits & credits

Sports: Plays, strategies, assignments


Conceptual model of software architecture

• Model relationshipsß Views & viewtypesß Designationß Refinement

• Canonical model structureß Domain modelß Design model

• Internals model• Boundary model

ß Code model

• Quality attributes

• Design decisions

• Tradeoffs

• Responsibilities

• Constraints (guide rails)

• Viewtypesß Moduleß Runtimeß Allocation

• Module viewtypeß Modulesß Dependenciesß Nesting

• Runtime viewtypeß Componentsß Connectorsß Ports

• Allocation viewtypeß Environmental elementß Communication channels



Engineering with Models


Why use models?

• We battle complexity and scale with modelsß Models fit in our headsß Models help us analyze the problem

• So, what kinds of (meta) models?ß Enterprise Architecture: many competing (meta) modelsß Application Architecture: general consensus

• Use != Buildß How much you write down is a choiceß But you need a (meta) model



Commuting diagram

Mary Shaw's commuting diagram:


Model problem

Model solution

“A train is traveling south at 10m/s. Another departs 30 minutes later at 15m/s. When do

they meet?”

solve

solve

abstract concretize



Canonical model structure


Canonical model structure (1)

• A domain model expresses the intentions, concepts, and workings of the domain.ß Omits references to the system to be builtß Is a bridge between engineers and domain experts

• A boundary model expresses the capabilities of the system.ß Centerpiece is the system to be builtß Focus on system capabilities, not designß There is a single top-level boundary model

• An internals model expresses the design of the system.ß Refines a boundary modelß Describes assembly of components that conform to

boundary specification

• A code model expresses the solution, either as source code or an equivalent diagramß Some design intent lost in code model

Des

ign

Domain model

Boundary model

designation

Internals model

refinement

Code model

designation

Q: What does a box labeled “customer” represent in each of these models?



Canonical model structure (2)

• The “canonical stack” of modelsß May not build all on every project

• Each folderß Contains models (documents)ß A single level of abstraction (detail)

• Artifacts != sequenceß Our models are related via refinementß We rarely build top-down

• Design modelß Boundary + Internalsß Nest recursively

Des

ign

Domain model

Boundary model

designation

Internals model

refinement

Code model

designation

Each component in an internals model is

itself a boundary model

Can continuerefining, showmore details


Models and Code


Architecture vs code – different things easy to see

• When reading code, want to know:ß Who talks to whoß Invariants and constraintsß Messages sent and receivedß Styles and patternsß Performance requirements or guaranteesß Data structures used for communicationß Etc.

• Easy to see in architecture model, hard to see in code

• Why?ß A single object rarely has a big impact on QA’sß Cannot infer design from code

• e.g., “never call A from B”, “always do X before Y”• Yetß Code-level decisions “bubble up” into QA’sß Architecture decisions directly influence QA’s



Architecturally evident coding style

• Current practiceß Provide hints useful to humansß Use “totalExpenses” instead of just “t” variableß Intention revealing method names

• Idea: Express architectural ideasß Provide hints about architectureß Do more than is necessary for program to compileß Preserve design intent

• Benefitsß Avoid future code evolution problemsß Improve developer efficiency

• Reduce time spent inferring from codeß Lower documentation burdenß Improve new developer ramp-up



Process & Risk


Engineering failures

Required• Considering failures• Analyzing options• Designing a solution

You can choose• When design happens• Which analyses• Formality / precision• Depth

The concept of failure is central to the design process, and it is by thinking in terms of obviating failure that successful designs are achieved. ... Although often an implicit and tacit part of the methodology of design, failure considerations and proactive failure analysis are essential for achieving success. And it is precisely when such considerations and analyses are incorrect or incomplete that design errors are introduced and actual failures occur. [Henry Petroski, Design Paradigms, 1994]



Inspiration: Dad vs. mailbox

• My Dadß Mechanical engineerß Capable of analyzing stresses and strains

• The problemß Install new mailbox

• His solutionß Dig holeß Stick in postß Fill with concrete

• Q: Why no mechanical engineering analyses?

• A: Riskß He just wasn’t worried enough



Insight #1: Decide effort using risks

• At any given moment, you have worries and non-worriesß Worry: Will the server scale up?ß Worry: Will bad guys steal customer data?ß Response time will be easy to achieveß We have plenty of RAM

• Cast these worries as engineering risksß Focus on highest priority risks

• Good news: prioritizing risks is easy for developersß They can tell you what they are most worried aboutß I.e., possible failures



Insight #2: Techniques mitigate risks

• Many architecture techniques existß Protocol analysisß Component and connector modelingß Queuing theoryß Schedulability analysisß Threat modelingß …

• Techniques are not interchangeableß E.g., cannot use threat modeling on latency risks

• So, must match risks with techniquesß I.e., mapping from risks ‡ techniquesß Inspired by Attribute Driven Design (ADD)



Risk-Driven Model

• The Risk-Driven Model:1. Identify and prioritize risks2. Apply relevant architecture activities3. Re-evaluate

• Must balanceß Wasting time on low-impact techniquesß Ignoring project-threatening risks

Ron ArmsCtrong, CC



Process, risk, and Rackspace example

• Agile/lean architectureß Agile processes: few design techniquesß Architecture: many design techniquesß Use the risk-driven model to combine

• Rackspace: Did they proceed rationally?ß Should they have done Big Design Up Front (BDUF)?ß Should they have evolved the architecture?ß What risks did they face?

52

Version 1 Version 2 Version 3

…

CSR desktop

ssh

Logdata

EmailServers

CSR

…

CSR

CSR desktop

scp

EmailServers

Logdata

MySQL

Web / http

Web app

SQL

DB

…

CSR

CSR desktop

scp

EmailServers

Map-ReduceJob

Web / http

Web app

DistributedFilesystem


Summary

• Architecture, architecting, architects• Views• Quality attributes• Analysis• Standard notations• Guiderails• Architectural styles• Conceptual model• Engineering with models• Canonical model structure• Models and code• Process and risk

53

Desi

gn

Domain model

Boundary model

designation

Internals model

refinement

Code model

designation

ViewMaster model


Model problem

Model solution

solve

solve

abstract concretize

Documents

Introduction to Software Architecture · 2012. 9. 18. · Introduction to Software Architecture George Fairbanks 18 September 2012 Rhino Research Software Architecture Consulting