04-creating an architecture

8/2/2019 04-Creating an Architecture

1/44

Creating an

Architecture

Software Architecture Spring 2006


2/44

Spring 2006 Software Architecture 2


Outline Understanding Quality Attributes (Ch. 4)

Achieving Qualities (Ch. 5)

Designing the Architecture (Ch. 7)


3/44



Chapter 4.

Understanding Quality Attributes


4/44



Functionality and Architecture

Functionality:

The ability of the system to do the work for whichit was intended

Functionality and quality attributes areorthogonal

If functionality is the only requirement

A single monolithic module works!


5/44



Quality and Architecture Quality and phases of development

All phases must be considered

Architecture is often critical

Attributes have effects on each other

positive and negative


6/44



A Tour of Quality Attributes System Qualities

Business Qualities

Architecture Qualities


7/44



System Quality Attributes Traditional definitions and taxonomies

Problems

Not operational Difficult classification

Diverse vocabulary


8/44



Definitions are not operational

Example:

"The system should be modifiable"

With respect to which set of changes?


9/44



Difficult to classify Example:

Is a system failure

an aspect ofAvailability? an aspect ofSecurity?

an aspect ofUsability?


10/44



Diverse Vocabulary Example:

Performance: event

Security:

attack

Availability:

failure Usability

user input


11/44



Quality Attribute Scenarios A means of characterizing quality

attributes


12/44



Two Kinds of Scenarios General Scenarios

System independent

Concrete Scenarios Specific to the system under consideration


13/44



Usage of Scenarios

Genral Scenarios

Attribute characterizations Requirements for aparticular system

Concrete Scenarios


14/44



Availability General Scenarios


15/44



Sample Availability Scenario


16/44



Specifying RequirementsFunctional Requirements

Use Cases

Quality Attributes Requirements

Concrete Scenarios


17/44



Modifiability General Scenarios

Cost in terms of number of elements affected, effort, money;

extent to which this affects other functions or quality attributesResponse

Measure

Locates places in architecture to be modified; makes

modification without affecting other functionality; testsmodification; deploys modification

Response

At runtime, compile time, build time, design timeEnvironment

System user interface, platform, environment; system that

interoperates with target systemArtifact

Wishes to add/delete/modify/vary functionality, quality

attribute, capacityStimulus

End user, developer, system administratorSource

Possible ValuesPortion ofScenario


18/44



Quality Aspects Covered Availability

Modifiability

Performance

Security Testability

Usability See "Useability Mea Culpa" Sidebar!


19/44



Communicating Concepts Eliminating miscommunication between

stakeholders


20/44



Business Qualities

Time to market

Cost and benefit

Projected lifetime of the system

Targeted markets Rollout schedule

Integration with legacy systems


21/44



Architecture Quality

Conceptual integrity

Correctness and completeness

Buildability


22/44



Chapter 5.

Achieving Quality


23/44



System Design

A Set of Decisions

Ensuring achievementof system functionality

Controlling qualityattribute responses


24/44



Tactics

A tactic is a design decision that

influences the control of a qualityattribute response.


25/44



Example

Introduce redundancy to increase the

availability of the system

Consequence: the need forsynchronization


26/44



Organizing Tactics

Tactics can refine other tactics

Hierarchical structure

Patterns package tactics


27/44



Modifiability Tactics

Three Categories:

1. Localize modifications

2. Prevent ripple effects

3. Defer binding time


28/44



Localize Modifications

Maintian Semantic Coherence

Anticipate Expected Changes Generalize the Module

Limit Possible Options


29/44



Ripple Effects

Dependencies between modules

1. Syntax (of data or service)2. Semantics (of data or service)

3. Sequence (of data or service)

4. Identity of an interface5. Location

6. Quality of service/data

7. Existence8. Resource behavior


30/44



Preventing Ripple Effects

Hide information

Maintain existing interfaces Restrict communication paths

Use an intermediary


31/44



Defer Binding Time

Rutime registration

Configuration files Polymorphism

Component replacement

Adherence to defined protocols


32/44



Hierarchy of Modifiability Tactics


33/44



Availability Tactics


34/44



Availability Tactics


35/44



Performance Tactics


36/44



Performance Tactics


37/44



Security Tactics


38/44



Security Tactics


39/44



Testability Tactics


40/44



Testability Tactics


41/44



Usability Tactics


42/44



Usability Tactics


43/44



Tactics and Arch. Patterns

Active Object Pattern


44/44



Tactics Used in Active Object

Main Purpose:

Introduce Concurrency (Performance) Other Tactics:

Information hiding (modifiability)

Intermediary (modifiability)

Binding time (modifiability)

Scheduling policy (performance)

04-creating an architecture

Documents