arch-haiku-2010-09-07.ppt [Compatibility Mode]

Architecture Haiku

George Fairbanks

7 September 2010

Rhino Research

Software Architecture Consulting and Training

http://RhinoResearch.com

7 September 2010 George Fairbanks –RhinoResearch.com 2

Talk overview

• Architecture descriptions tend to be verbose

• E.g.: Documentation package

• Complete, rather than suggestive

• Problem: We have caviar taste; McDonald’s budget

• Q: What if we only use one page?

• Must use concise language

• High power-to-weight ideas

• A: Architecture Haiku

• Tradeoffs, quality attribute priorities, drivers, design rationales,

constraints, architectural styles

• Future

• Requires shared knowledge: terms, styles

• Will Haiku help architecture education?

7 September 2010 George Fairbanks –RhinoResearch.com 3

Talk outline

• Introduction

• About me, software architecture, documentation packages, agile,

forces, concision

• Haiku How-To

• Haiku Example: Apache

• Group exercise

• Future

7 September 2010 George Fairbanks –RhinoResearch.com 4

What is software architecture?

• In loose language:

• It’s the macroscopic organization of the system

• Must keep these ideas separate:

• The job title/role “architect”

• The process of architecting/designing (also: when)

• The engineering artifact called the architecture

• 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”

The software architecture of a computing system is the set of

structures needed to reason about the system, which comprise

software elements, relations among them, and properties of both.

[Clements et al., DSA2, 2010]

7 September 201021 July 2010 George Fairbanks –RhinoResearch.com 5

Architecture as skeleton

• An animal’s skeleton:

• Provides its overall structure

• Influences what it can do

• Examples

• Birds fly better because of wings and light bones

• Kangaroos jump because of leg structure

• Convergent evolution: Bat skeletons have wings

• Tradeoffs

• 4 legs faster vs. 2 legs easier to use tools

• Software skeleton examples

• 3-tier: localize changes, concurrent transactions

• Cooperating processes: isolate faults

• Peer-to-peer: no central point of failure

7 September 2010 George Fairbanks –RhinoResearch.com 6

Architecture influences quality attributes

• Function: Carrying apples to market

• Solution 1: Use humans

• Solution 2: Use horses

• Both solutions work

• Yet differ in their quality attributes

• Quality attributes

• A.k.a. extra-functional requirements, the “ities”

• E.g., latency, modifiability, usability, testability

• Architecture influences the system’s quality attributes

• E.g., pipe and filter is reconfigurable

• E.g., map-reduce is scalable

7 September 2010 George Fairbanks –RhinoResearch.com 7

Architecture orthogonal to functionality

• Architecture orthogonal to functionality

• Can mix-and-match architecture and functionality

• Can (mostly) build any system with any architecture

• Shift in thinking

• No: good or bad architectures

• Yes: suitable or unsuitable to supporting the functions

• Architecture can help or hurt w.r.t. functionality

• Help example: use horses to transport apples

• Hurt example: use horses to stack apples

7 September 2010 George Fairbanks –RhinoResearch.com 8

Documentation packages

• What is a documentation package?

• Complete architecture description

• See Documenting Software Architectures, 2nd Ed, 2010

• But:

• Hard to reconcile with Agile processes

• Expensive

• Not terse examples

Image CC license Indogen Jonesfr

7 September 2010

Architecture presentations: Traditional advice

• You’ve got 60 minutes to give an architecture presentation. What do

you present?

• This will get you started:

•Module view(s)

• Code organization, layers, DB schemas

•Runtime view(s)

• Running system + collaborating systems

• Connections and properties

•Deployment view(s)

• Hardware, network, topology, etc.

Viewtype Contents

Module Modules, Dependencies, Layers

Runtime Components, Connectors, Ports

Allocation Servers, Communication channels

7 September 2010 George Fairbanks –RhinoResearch.com 10

Talk outline

• Introduction

• Haiku How-To

• Tradeoffs, quality attribute priorities, drivers, design decisions,

constraints, architectural styles

• Haiku Example: Apache

• Group exercise

• Future

7 September 2010 George Fairbanks –RhinoResearch.com 11

Idea: Architecture Haiku

• Goal: Best 1-page architecture description

• What to include?

• High power-to-weight items

• Items that promote insight, not comprehensiveness

• Techniques

• Concise language (e.g., technical terms)

• Document differences

• Hints at critical junctions

• Implications (i.e., who can read the haiku?)

• Need shared technical terms

• Need shared conceptual model

7 September 2010 George Fairbanks –RhinoResearch.com 12

Haiku Contents

• Solution description

• Tradeoffs

• Quality attribute priorities

• Architecture drivers (QA scenarios)

• Design rationales

• Constraints

• Architecture styles

• Diagrams

7 September 2010 George Fairbanks –RhinoResearch.com 13

1. Solution description

• Simple text describing the system

• Good to include:

• Most important functions

• Goals

• Challenges

• Verbosity

• Examples

• XBMC is a cross-platform music and video player that supports

every major media format.

• LyX is a structured document processor, suitable for technical

writing, that uses LaTeX to render professional-quality PDFs.

7 September 2010 George Fairbanks –RhinoResearch.com 14

2. Tradeoffs

• 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

7 September 2010 George Fairbanks –RhinoResearch.com 15

QA tradeoffs

• Domain tradeoffs or system-specific tradeoffs

• Arise from domain quirk, or particular design

• Generic quality attribute tradeoffs

• E.g., generally efficiency trades off against maintainability

Table from Wiegers, Software Requirements, 2003, via Morgan “Implementing System Quality Attributes”, 2007.

7 September 2010 George Fairbanks –RhinoResearch.com 16

3. Quality attribute priorities

• Goal: Prioritized list of quality attributes

• Some QA's likely not relevant, or very low priority

• Some QA's critical to project success

• For credit card processing:

• Security > latency > throughput

• For an MP3 player:

• Usability > audio fidelity > extensibility

• Make an argument for different prioritizations

• What factors influence the prioritization?

7 September 2010 George Fairbanks –RhinoResearch.com 17

4. QA scenario structure

QA Scenario Templates

•Basic template: stimulus and response

• Stimulus: agent or situation that

triggers scenario

• Response: reaction to stimulus

•Ideal template: Add source, environment,

response measure

• Stimulus: as above

• Response: as above

• Source: Who/what creates stimulus

• Environment: mode of the system.

E.g., normal or low demand.

• Response measure: testable response

(e.g., “happens in 2ms”)

QA Scenario Examples

•Basic scenario: System allows

rapid scanning of book copies.

•Ideal scenario: Under normal

conditions, 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.

QA scenarios from Bass et al., Software Architecture in Practice, 2003

7 September 2010 George Fairbanks –RhinoResearch.com 18

Architecture drivers

Architecture Drivers

• 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.

• S3 (H,M): The system can be

modified to use a different source of

borrower entitlements within 1

programmer week of effort.

7 September 2010 George Fairbanks –RhinoResearch.com 19

5. Design rationales

• Design rationales explain why

• They should align with your quality attribute priorities

<x> is a priority, so we chose design <y>, accepting

downside <z>.

• 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

7 September 2010 George Fairbanks –RhinoResearch.com 20

6. Constraints (Guiderails)

• 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

• Plugins must use cross-platform API to read files à portability

• EJBeans must not start own threads à manageability

• EJBeans must not write local files à distribution

7 September 2010 George Fairbanks –RhinoResearch.com 21

7. 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 term for communication

See more architectural styles in

my book or wikipedia

7 September 2010 George Fairbanks –RhinoResearch.com 22

8. Diagrams

• Three primary viewtypes: Module, Runtime, Allocation

• Many views within a viewtype

• View suitability

• Challenge

• Remember: Just one page!

• Small diagrams only

Viewtype Contents

Module Modules, Dependencies, Layers

Runtime Components, Connectors, Ports

Allocation Servers, Communication channels

7 September 2010 George Fairbanks –RhinoResearch.com 23

Talk outline

• Introduction

• Haiku How-To

• Haiku Example: Apache

• Group exercise

• Future

7 September 2010 George Fairbanks –RhinoResearch.com 24

The Apache Web Server

• History

• Evolved from UIUC NCSA server

• Users

• From Hosting providers to mom-and-pop

• Notable characteristics

• Cross-platform (via Apache Portable Runtime layer)

• Extensible (via pluggable modules)

• Configurable (via text files)

• Interoperable (e.g., with app servers)

7 September 2010 George Fairbanks –RhinoResearch.com 25

Apache as a Haiku

1. Description

• The Apache HTTP Server serves web pages/requests, is

extensible by third parties, and integrates with procedural code

(e.g. CGI scripts, app servers)

2. Tradeoffs

• Textual over GUI config: sshaccess; scriptability

• Configurability over usability: for professional sysadmins;

expert over casual use

• Extensibility over performance: distributed OSS creation of new

modules

3. Top 3 quality attributes, prioritized

• Extensibility > Configurability > Performance

4. Architecture drivers

• Third party writes a new extension module in 1 week

• ISP configures new virtual host via script

• Server ported to new operating system in 1 month

7 September 2010 George Fairbanks –RhinoResearch.com 26

Apache as a Haiku

5. Design rationales

• Since extensibility is more important than performance, modules

are dynamically configured to process requests, potentially

increasing latency

6. Constraints (guide rails)

• All OS calls must go through Apache Portable Runtime layer

7. Architectural styles

• Client-server: Browsers to main web server

• Pipe-and-filter: Requests and responses processed through

network of filter modules (e.g., URL rewrite, compress)

8. Diagrams

• Next pages

7 September 2010 George Fairbanks –RhinoResearch.com 27

Client-server diagram

• Apache, with clients and

administration

• Runtime viewtype

• Diagram not surprising

enough to include

Diagram from: Apache Modeling Project:

Bernhard Gröne, Andreas Knöpfel, Rudolf Kugel, Oliver Schmidt

http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html

7 September 2010 George Fairbanks –RhinoResearch.com 28

Pipe-and-filter diagram

• Request processing

• Apache (dynamically) processes requests

• Input pipeline

• Output pipeline

• Note: Runtime viewtype

• Perhaps worthy to include

Diagram from: Apache Modeling Project:

Bernhard Gröne, Andreas Knöpfel, Rudolf Kugel, Oliver Schmidt

http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html

7 September 2010 George Fairbanks –RhinoResearch.com 29

Talk outline

• Introduction

• Haiku How-To

• Haiku Example: Apache

• Group exercise

• Airport screening

• Future

7 September 2010

Airport screening exercise

• Choose your descriptions from this list:

1. Solution description

2. Tradeoffs

3. Quality attribute priorities

4. Architecture drivers (QA scenarios)

5. Design rationales

6. Constraints (guide rails)

7. Architecture styles

8. Diagrams

• Tips

• Incomplete descriptions

• Suggestive, not comprehensive

• Hints at critical junctions

George Fairbanks –RhinoResearch.com 30

7 September 2010 George Fairbanks –RhinoResearch.com 31

Talk outline

• Introduction

• Haiku How-To

• Haiku Example: Apache

• Group exercise

• Future

• Role of architecture, terminology, learn from (Haiku) examples,

7 September 2010 George Fairbanks –RhinoResearch.com 32

Implications & future

• Role of architecture

• Acts as skeleton

• Makes QA’s easy or hard to achieve

• Today, often ignored

• Assumed architectural knowledge

• Terminology (style names, components, connectors, …)

• Deltas

• Learning from (Haiku) examples

• Imagine a book of Haiku examples

• OSS rarely documents architecture

• Let’s build a catalog (email me)

• Candidate agile technical practice

7 September 2010 George Fairbanks –RhinoResearch.com 33

Conclusion

• 3 distinct ideas:

• The job title/role “architect”

• The process of architecting/designing

• The engineering artifact called the architecture

• Architecture Haiku: 1-page description

• Incomplete, document deltas, hints at critical junctions

• High power-to-weight items that yield insight

• Contents

• Tradeoffs, QA priorities, drivers, rationales, constraints, styles,

and maybe diagrams

7 September 2010

Shameless plugging

• E-book

• One price, 3 formats

• PDF, ePub, Mobi

• No DRM

• RhinoResearch.com $25

• Hardback

• Amazon.com $39.75

George Fairbanks –RhinoResearch.com 34

7 September 2010

CompArch / WICSA 2011

• Boulder, CO June 20-24

, 2011 CU Campus

• Approx. $500 for whole conference

• Working International Conference on Software Engineering

• Component-based software engineering + quality attributes

• Weds 23

is Industry Day

• Panels, case studies, keynotes, tutorials

• Networking, dinner

• Approx. $200

• Looking for:

• Paper submissions

• Attendees

• Sponsors

• Meet people like: Philippe Kruchten, Rich Hilliard, David Garlan, Len

Bass, Paul Clements, Grady Booch, Rick Kazman, Nick Rosanski, Eoin

Woods, Jan Bosch, Christine Hofmeister, Rod Nord, …

George Fairbanks –RhinoResearch.com

http://comparch2011.archspot.com