PATTERN ORIENTED SOFTWARE

ARCHITECTURE - VOLUME1Chapter 1 - Patterns

Pattern Categories

• To refine our classification, we group patterns into three categories:o Architectural patternso Design patternso Idioms

• Each category consists of patterns having a similar range of scale or abstraction.

1/18/2011

Architectural Patterns

• An architectural pattern expresses a fundamental structural organization schema for software systems.

• It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

1/18/2011

Design Patterns

• A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them.

• It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context

1/18/2011

Design Patterns

• Design patterns are medium-scale patterns. • They are smaller in scale than architectural

patterns, but tend to be independent of a particular programming language or programming paradigm

1/18/2011

Idioms

• An idiom is a low-level pattern specific to a programming language.

• An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

• Idioms represent the lowest-level patterns. They address aspects of both design and implementation.

1/18/2011

Integration with S/w Development

• Architectural patterns can be used at the beginning of coarse-grained design

• Design patterns during the whole design phase• Idioms during the implementation phase.

1/18/2011

Relationships between Patterns

• A close look at many patterns reveals that, despite initial impressions, their components and relationships are not always as 'atomic' as they first appear to be.

• A pattern solves a particular problem, but its application may raise new problems.

• Single components or relationships inside a particular pattern may therefore be described by smaller patterns, all of them integrated by the larger pattern in which they are contained.

1/18/2011

SOFTWARE ARCHITECTURE IN

PRACTICE Part 3 -

Analyzing Architecture

1/18/2011

Overview

• What, why, when• Architecture analysis (ATAM –

Architecture Tradeoff Analysis Merhod)• Software Architecture Analysis

Method (SAAM)

1/18/2011

Architecture evaluation / analysis

• Assess whether architecture meets certain quality goals, such as those w.r.t. maintainability, modifiability, reliability, performance

• Mind: the architecture is assessed, while we hope the results will hold for a system yet to be built

1/18/2011

Two kinds of questions

• Is this architecture suitable?• Which of two or more architectures is the

most suitable?

1/18/2011

Alice in Wonderland analogy

• Alice meets the Cheshire Cat and asks for directions. • The cat responds: it depends on where you want to

go. • Alice says she doesn’t know. • The cat tells her it doesn’t matter which way she

walks.

• If the stakeholders cannot articulate their quality goals, any architecture will do

1/18/2011

Software Architecture Analysis

1/18/2011

Analysis techniques

• Questioning techniques: how does the system react to various situations; often make use of scenarios

• Measuring techniques: rely on quantitative measures; architecture metrics, simulation, etc

1/18/2011

Scenarios in Architecture Analysis

• Different types of scenarios, e.g. use-cases, likely changes, stress situations, risks, far into the future scenarios

• Which stakeholders to ask for scenarios?• When do you have enough scenarios?

1/18/2011

Preconditions for successful assessment

• Clear goals and requirements for the Architecture

• Controlled scope• Cost-effectiveness• Key personnel availability• Competent evaluation team• Managed expectations

1/18/2011

Architecture Tradeoff Analysis Method (ATAM)

• Reveals how well architecture satisfies quality goals, how well quality attributes interact, i.e. how they trade off

• Elicits business goals for system and its Architecture

• Uses those goals and stakeholder participation to focus attention to key portions of the architecture

1/18/2011

Benefits

• Financial gains• Forced preparation• Captured rationale• Early detection of problems• Validation of requirements• Improved architecture

1/18/2011

Participants in ATAM

• Evaluation team• Decision makers• Architecture stakeholders

1/18/2011

Phases of ATAM

• Present method to stakeholders• Present business drivers (by project manager of

system)• Present architecture (by lead architect)• Identify architectural approaches/styles• Generate quality attribute utility tree• Analyze architectural approaches• Brainstorm and prioritize scenarios• Analyze architectural approaches• Present results

1/18/2011

Example Utility tree

1/18/2011

Outputs of ATAM

• Concise presentation of the architecture• Articulation of business goals• Quality requirements expressed as set of

scenarios• Mapping of architectural decisions to quality

requirements• Set of sensitivity points and tradeoff points• Set of risks, nonrisks, risk themes

1/18/2011

Important concepts in ATAM

• Sensitivity point: property critical for certain quality attribute

• Tradeoff point: property that affects more than one quality attribute

• Risk: potential problem• These concepts are overlapping

1/18/2011

Software Architecture AnalysisMethod (SAAM)• Develop scenarios for

o kinds of activities the system must supporto kinds of changes anticipated

• Describe architecture(s)• Classify scenarios

o direct -- use requires no changeo indirect -- use requires change

• Evaluate indirect scenarios: changes and cost• Reveal scenario interaction• Overall evaluation

1/18/2011

Scenario interaction in SAAM

• Two (indirect) scenarios interact if they require changes to the same component

• Scenario interaction is important for two reasons:o Exposes allocation of functionality to the designo Architecture might not be at right level of detail

1/18/2011

Summary

• At architecture time, 90% of the cost is determined in 10% of the time

• Architecture analysis, with a broad range of stakeholders, is extremely valuable

1/18/2011

5:24 AM SEPS ZG651 Software Architectures