Software Architecturein Practice

RiSE’s SeminarsBass’s book :: Chapters 07

Eduardo Santana de Almeida

2

Summary

Designing the Architecture (Chapter 7) Evolutionary Delivery Life Cycle When Can I begin Designing? How to identify the architectural drivers? Attribute-Driven Design

3

Evolutionary Delivery Life Cycle

SoftwareConcept

PreliminaryRequirements

Analysis

Design ofArchitectureand System

Core

Develop aVersion

IncorporateCustomerFeedback

ElicitCustomerFeedback

Deliver theVersion

Deliver Final

Version

4

Evolutionary Delivery Life Cycle

Goal

To get user and customer feedback

Microsoft strategy

Skeletal system

Early

Low-fidelity

Updates

Designing the Architecture :: Chapter 7

5

When Can I begin Designing?

Architecture

Shape

Functionality

Quality

Business requirements

Examples

Avionic system

Availability, Performance, Security...

COMPGOV

Availability, Performance, Security...

Designing the Architecture :: Chapter 7

Architectural drivers

6

How to identify the architectural drivers?

Designing the Architecture :: Chapter 7

To priorize business goals {few}

To put these business goals into quality scenarios or

use cases

Scenary’s template

To choose the most importants

Impact on the architecture

7

Attribute-Driven Design

Designing the Architecture :: Chapter 7

Approach to define a software architecture that bases the

decomposition process on the quality attributes the software has to

fulfill

Recursive decomposition process

Use

Tatics

Architectural Patterns

Systematic approach

8

Attribute-Driven Design (cont.)

Designing the Architecture :: Chapter 7

To satisfy quality attributes and functional requirements

RUP’s extension

High-level design

Detailed design and implementation

ADD

Detailed {high-level} + Rational

Input

Functional requirements (expressed as use cases)

Constraints

Quality attributes scenarios

9

ADD Steps (p. 157)

Choose the module to decompose Module: the system

Inputs: requirements, quality attributes, constraints

Quality attributes scenarios

Refine the module Choose the architectural drivers from the set of concrete quality scenarios and functional

requirements

Choose an architectural pattern that satisfies the architectural drivers

Instantiate modules and allocate functionality from the use cases

Define interfaces of the child modules

Verify and refine use cases and quality scenaries

Repeat the steps above for every module that needs further decomposition

10

ADD Steps

Choose the module to decompose System

Subsystem

Submodules

Choose the architectural drivers Combination of functional and quality requirements that “shape” the architecture or the

particular module under considerations

It is not always a top-down process

Prototype

Decomposition criterias

Based on architectural drivers

Requirements priorization

System

Subsystem

Subsystem

11

ADD Steps (cont.)

Choose an Architectural Pattern Goal: To establish an overall architectural pattern consisting of module types

Quality attributes -> Tatics -> Patterns

Instantiate Modules and Allocate Functionality using Multiple Views Instantiate module

Use of responsability

Allocate functionality

Based on Use cases

Represent the architecture with views (flexibility)

Iterative process

One view is normally sufficient

Module decomposition

Concurrency

Deployment

Others aspects can be used

12

ADD Steps (cont.)

Define Interfaces of the Child Modules Documentation aspects

Verify and Refine Use cases and Quality Scenarios as Constraints for the

Child Modules Functional requirements

Requirements + use cases -> module

Constraints

The decomposition satisfies the constraint

The constraint is satisfied by a single child module

The constraint is satisfied by multiple child module

13

ADD Steps (cont.)

Quality scenarios A quality scenario may be completely satisfied by the decomposition without any additional impact

A quality scenario may be satisfied by the current decomposition with constraints on child modules

The decomposition may be neutral with respect to a quality scenario

A quality scenario may not be satisfiable with the current decompostion

Result Child module

Responsability

Use cases

Interfaces

Quality scenario

Constraints

14

References

L. Bass, P. C. Clements, R. Kazman. Software Architecture in Practice. Second Edition, Addison-Wesley, 2003.