Software Architecture

Alan Kelon Oliveira de Moraesakom@cin.ufpe.br

Feb 12, 2006 – Recife

Motivation

● Size and complexity of software systems increases

● Problems of developing large-scale software systems

● Patterns have emerged informally over time● People recognize the need for a more disciplined

approach

History: Pre-1990

● Dijkstra published the first paper to document the design of a software system using hierarchical layers [Dijkstra, 1968]

● The first reference to “Software Architecture” [NATO, 1969]

● Parnas described the use of modularization and information hiding [Parnas, 1972]

● Stevens et al introduced the notions of module coupling and cohesion [Stevens, 1974]

History: 1990-1998

● Software Architecture as distinct discipline

● The 1990s is the decade of software architecture [Perry and Wolf, 1992]

● The first book on software architecture [Witt, 1994].

● The first method of a SEI series was Software Architecture Analysis Method

(SAAM) [Kazman et al., 1994].

● The 4+1 Model View Is published as architecture method of RUP [Kruchten,

1995]

● Another book, The Art of System Architecting, nicely filled the gap between

system and software [Rechtin, 1997]

● Software architecture really started to bloom!

History: 1990-2006

● First IFIP Conference on Software Architecture (1999)

● Software Architecture has emerged as apropriate level to deal software quality [Dobrica et al., 2002]

● New methods such as SAAM [Kazman et al., 1994], BAPO [Obbink et al., 2000] and ATAM [Clements et al., 2002] emerged or consolidated

● From basic research to an essential element of software system design and construction [Shaw and Clements, 2006]

Definition

● Consist of two parts: Macroarchitecture and microarchitecture [Dobrica et al., 2002]

● [Perry and Wolf, 1992 ][Shaw and Garlan, 1996]

The structure of components in a program or system, their interrelationships, and the principles and guides that control the design and evolution in time.

● See http://www.sei.cmu.edu/architecture/definitions.html for 60 more definitions...

Definition

● [Clements et al., 1998]

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

Software architecture

● Most definitions indicate that an architecture [Eeles]– is concerned with both structure and behavior

– is concerned with significant decisions only

– may conform to an architectural style

– is influenced by its stakeholders and its environment,

– embodies decisions based on rationale.

Roles of a SA

● Communication among stakeholders● Early design decisions● Reuse on several levels● First approach to achieving quality attributes● Basis for system analysis

An architecture defines structure

● Defines the composition of structural elements, their relationships, their interfaces, and their partitioning.

An architecture defines structure

● A structural element may be – a subsystem

– a process

– a library

– a database

– a computational node

– a legacy system

– an off-the-shelf product

An architecture defines behavior

● An architecture defines the interactions between these structural elements

● These interactions that provide the desired system behavior

An architecture focuses on significant elements

● It is not concerned with defining all of the structure and all of the behavior

● Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability

● An architecture is an abstraction of the system that helps an architect manage complexity.

Architecture vs. Design

● Architecture– Specify the properties of components and their

interactions● Design

– Involves algorithm, data structures, and realization

An architecture embodies decisions based on rationale

● An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is.

● Document the decisions that have led to this architecture and the rationale for those decisions.

An architecture may conform to an architectural style

● Many systems have a similar solution structure– This similarity can be described as an architectural

style, which can be thought of as a particular kind of pattern

● Problems in practice already solved● Like a pattern, an architectural style represents a

codification of experience, and it is good practice for architects to look for opportunities to reuse such experience.

A style consists of:

● a set of component types (e.g., process, procedure) that perform some function at runtime

● a topological layout of the components showing their runtime relationships

● a set of semantic constraints● a set of connectors (e.g., data streams, sockets)

that mediate communication among components

Styles [Garlan and Shaw, 1994]

● Pipes and Filters● Data Abstraction and Object-Oriented

Organization● Event-based, Implicit Invocation● Layered Systems● Repositories● Table Driven Interpreters● Heterogeneous Style

● Pipes and Filters● Advantages

– understand the overall input/output behavior– reuse– systems can be easily maintained

● Disadvantages– batch organization of processing– performance

An architecture balances stakeholder needs

● Created to ultimately address a set of stakeholder needs

– The end user is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security.

– The system administrator is concerned with intuitive behavior, administration, and tools to aid monitoring.

– The marketer is concerned with competitive features, time to market, positioning with other products, and cost.

– The customer is concerned with cost, stability, and schedule.

– The developer is concerned with clear requirements, and a simple and consistent design approach.

– The project manager is concerned with predictability in the tracking of the project, schedule, productive use of resources, and budget.

– The maintainer is concerned with a comprehensible, consistent, and documented design approach, and the ease with which modifications can be made.

● Software architecture as a bridge [Garlan, 2000]

An architecture influences team structure

● Conway’s Law (1968)– Organizations which design systems are constrained

to produce designs which are copies of the communication structures of these organizations.

– If you have four groups working on a compiler, you'll get a 4-pass compiler.

● Ovaska et al., 2003 – Architecture as a Coordination Tool in Multi-site

Software Development

Characteristics of a software architect

● He is a technical leader– The architect role may be fulfilled by a team

● Understands the software development process● Has knowledge of the business domain● Has technology knowledge

– However, architects do not need to be technology experts

Characteristics of a software architect

● Has design skills● Has programming skills● Is a good communicator● Is a negotiator● Makes decisions

Architectual Design Activities

Attribute-Based Design

RiSE’s SeminarsBass’s book :: Chapter 07

Eduardo Cruz

Summary Designing the Architecture (Chapter 7)

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

Evolutionary Delivery Life Cycle

Software

Concept

Preliminary

Requirements

AnalysisDesign of

Architecture

and System

CoreDevelop a

Version

Incorporate

Customer

Feedback

Elicit

Customer

Feedback

Deliver the

Version

Deliver

Final

Version

Evolutionary Delivery Life Cycle Goal

To get user and customer feedback

Microsoft strategy

Skeletal system

Early

Low-fidelity

Updates

Designing the Architecture :: Chapter 7

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

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

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

Constraints

Quality attributes scenarios

ADD Steps (p. 157)

1. Choose the module to decompose Module: the system

Inputs: requirements, quality attributes, constraints

Quality attributes scenarios

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

3. Repeat the steps above for every module that needs further

decomposition

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

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

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

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

References L. Bass, P. C. Clements, R. Kazman. Software

Architecture in Practice. Second Edition, Addison-Wesley, 2003.