SA/NH/CS'A'/2010 1

WHAT IS SOFTWARE
ARCHITECTURE?

Chapter 2,
Authors: Len Bass, Paul, Rick
Page Numbers: 19-45

02/08/2010
 System description of Acoustic Simulation
2 of 50

SA/NH/CS'A'/2010 02/08/2010
 What Software Architecture Is and
What It Isn't
3 of 50

 What is the nature of the elements?

 What is the significance of separation?
 Do they run on separate processors?
 Do they run at separate times?
 Do the elements consist of processes, programs or both?
 Are they objects, task, functions, processes, distributed programs, …
 What are the responsibilities of the elements?
 What is it they do?
 What is their function in the system?
 What is the significance of the connections?
 Do the connections mean that the elements communicate with each other , control each other , send
data to each other , use each other, invoke each other, share some information hiding secret with each
other,
 What information flows across the mechanism?
 What is the significance of the layout?
 Why is CP on a separate level?
 Does it call the other three?
 Are others not allowed to call?

SA/NH/CS'A'/2010 02/08/2010
 Architecture: Definition
4 of 50

The Software Architecture is a structure or

structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships between them

SA/NH/CS'A'/2010 02/08/2010
 Architecture Definition
5 of 50

externally visible properties -

assumptions other elements can make of an
element, such as its provided services,
performance characteristics, fault handling,
shared resources usage

SA/NH/CS'A'/2010 02/08/2010
 Architecture: Definition – observation
6 of 50

Architecture defines software elements

embody
 The architecture represents information about how the elements relate to
each other

 An architecture is foremost an abstraction of a system that suppresses details

of elements that do not affect how they use, are used by, relate to, or interact
with other elements.

 Architecture is concerned with the public side of this division

SA/NH/CS'A'/2010 02/08/2010
 Architecture: Definition – observation
7 of 50

Systems can and do comprise more than one structure

 All nontrivial projects are partitioned into implementation

units; these units are given specific responsibilities and are
frequently the basis of work assignments for programming
teams.

SA/NH/CS'A'/2010 02/08/2010
 Architecture: Definition – observation

Every computing system with software has a software architecture

 Every system can be shown to comprise elements and the relations among
them.

 Unfortunately, an architecture can exist independently of its description or

specification, which raises the importance of architecture documentation and
architecture reconstruction

SA/NH/CS'A'/2010 02/08/2010 8 of
50
 Architecture: Definition – observation
9 of 50

the behavior of each element is part of the

architecture

 behavior can be observed from the point of view of

another element.

SA/NH/CS'A'/2010 02/08/2010
 Architecture: Definition – observation
10 of 50

the definition is indifferent as to whether the

architecture for a system is a good one or a bad
one
 meaning that it will allow or prevent the system
from meeting its behavioral, performance, and life-
cycle requirements.
 We do not accept trial and error as the best way to
choose an architecture for a system

SA/NH/CS'A'/2010 02/08/2010
 Other Points of View
11 of 50

 Architecture is high-level design

 Architecture is the overall structure of the system

 Architecture is the structure of the components of a

program or system, their interrelationships, and the
principles and guidelines governing their design and
evolution over time

 Architecture is components and connectors

SA/NH/CS'A'/2010 02/08/2010
 Architectural Patterns
12 of 50

An architectural pattern is a description of element

and relation types together with a set of
constraints on how they may be used

Set of constraints on an architecture

Example-C/S architecture.

SA/NH/CS'A'/2010 02/08/2010
 Reference Models
13 of 50

 A reference model is a division of functionality

together with data flow between the pieces.
 It is standard decomposition of a known problem into
parts that solves problem cooperatively
 Ex: OSI reference model..

SA/NH/CS'A'/2010 02/08/2010
 Reference Architectures
14 of 50

 A reference architecture is a reference model

mapped onto software elements (that cooperatively
implement the functionality defined in the
reference model) and the data flows between them
 ----
 Reference model divides the functionality.
 A reference architecture is the mapping of that
functionality on to a system decomposition

SA/NH/CS'A'/2010 02/08/2010
 Architecture: useful concepts
15 of 50

Reference
model

Reference Software
architecture architecture

Architectural
pattern

SA/NH/CS'A'/2010 02/08/2010
 Why is Software Architecture Important?
16 of 50

1. Communication among stakeholders

-used as a basis for mutual understanding,
negotiation, compromise, and communication.

SA/NH/CS'A'/2010 02/08/2010
 Why is Software Architecture Important?
17 of 50

2. Early design decisions

Architecture represents earliest set of decisions

about system, they are most difficult to get correct
and the hardest to change the earliest point at which
design decisions can be analyzed

SA/NH/CS'A'/2010 02/08/2010
 Why is Software Architecture Important?
18 of 50

3. Transferable abstractions of a system

Architecture is a relatively small model for how a
system is structured and how its elements work
together – and this is transferable across systems.

SA/NH/CS'A'/2010 02/08/2010
 ARCHITECTURE IS THE VEHICLE FOR STAKEHOLDER
COMMUNICATION
19 of 50

 Each stakeholder of a software system is concerned

with different system characteristics that are
affected by the architecture.

 Architecture provides a common language in which

different concerns can be expressed, negotiated,
and resolved at a level that is intellectually
manageable even for large, complex systems
SA/NH/CS'A'/2010 02/08/2010
ARCHITECTURE MANIFESTS THE EARLIEST SET OF
DESIGN DECISIONS
20 of 50

 Software architecture represents a system's earliest

set of design decisions.

 These early decisions are the most difficult to get

correct and the hardest to change later in the
development process, and they have the most far-
reaching effects.

SA/NH/CS'A'/2010 02/08/2010
 ARCHITECTURE MANIFESTS THE EARLIEST
SET OF DESIGN DECISIONS contd
21 of 50

 The Architecture Defines Constraints on Implementation

 The Architecture Dictates Organizational Structure
 The Architecture Inhibits or Enables a System's Quality Attributes
 Performance, Modifiability, Security, Scalability, Reusability
 Predicting System Qualities by Studying the Architecture
 The Architecture Makes It Easier to Reason about and Manage Change
 The Architecture Helps in Evolutionary Prototyping
 The Architecture Enables More Accurate Cost and Schedule Estimates

SA/NH/CS'A'/2010 02/08/2010
 ARCHITECTURE AS A TRANSFERABLE, RE-
USABLE MODEL
22 of 50

 The earlier in the life cycle re-use is applied, the

greater the benefit that can be achieved

 When architectural decisions can be re-used across

multiple systems, all of the early decision
consequences we just described are also
transferred.

SA/NH/CS'A'/2010 02/08/2010
 ARCHITECTURE AS A TRANSFERABLE, RE-
USABLE MODEL contd..
23 of 50

 Software Product Lines Share a Common

Architecture
 Systems Can Be Built Using Large, Externally
Developed Elements
 Less Is More: It Pays to Restrict the Vocabulary
of Design Alternatives
 An Architecture Permits Template-Based
Development
 An Architecture Can Be the Basis for Training
SA/NH/CS'A'/2010 02/08/2010
 Architectural Structures and Views
24 of 50

A structure is the set of elements structure-set of

elements.

view – It is a representation of logical set of

architecture elements, as written by and read by
system stakeholder.
It consist of representation of a set of elements and
the relations among them

SA/NH/CS'A'/2010 02/08/2010
 Architectural Structures
25 of 50

- module structures
basic elements are modules, they are assigned areas of
functional responsibility, less emphasis on runtime issues

- component-and-connector structures
elements are run-time components (units of computation) and connectors (communication
vehicles)

- allocation structures
shows the relationship between the software elements and the elements in
one or more external environments in which software is created and
executed

SA/NH/CS'A'/2010 02/08/2010
 Architectural Structures: Module
26 of 50

module

decomposition uses class

layered

SA/NH/CS'A'/2010 02/08/2010
 Architectural Structures: Component-and-
Connector
27 of 50

component-and-connector

client-server shared data

concurrency process

SA/NH/CS'A'/2010 02/08/2010
 Architectural Structures: Allocation
28 of 50

allocation

Work assignment implementation

deployment

SA/NH/CS'A'/2010 02/08/2010
 Architectural Structures: Module
Software Relations Useful For Reason About
structure
decomposition is a submodule, shares resource allocation, project structuring
secrets with and planning, information hiding,
encapsulation, configuration control
Uses requires the correct extension or extraction of functionality
presence of
layered requires the correct incremental development,
presence of, uses the implementing systems on top of
services of, provides “virtual machines”
abstraction to
class is an instance of, shares in OO – producing rapid almost-alike
access methods of implementations from a common
template

29 of
02/08/2010 SA/NH/CS'A'/2010 50
 Architectural Structures: Component-Connector

Software Relations Useful For Reason About

structure
client-server communicates with, distributed operation,
depends on separation of concerns,
performance, load
balancing
process runs concurrently with, may run scheduling, performance
concurrently with, excludes, precedes

concurrency runs on the same logical thread locations where resource

contention exists, where
threads may fork, join,
be created or killed
shared data produces data, consumes data performance, data
integrity, modifiability
30 of
02/08/2010 SA/NH/CS'A'/2010 50
 Architectural Structures: Allocation

Software structure Relations Useful For Reason About

deployment allocated to, performance, availability,

migrated to security

implementation stored in configuration control,

integration, test activities

work assignment assigned to project management,

best use of expertise,
management of
commonality

31 of
02/08/2010 SA/NH/CS'A'/2010 50
 Architectural Structures: which one to choose

32 of 50

Philippe Krutchten (1995): “four plus one” approach

1. Logical : Elements are key abstractions.
This is module structure.
2. Process : Addresses concurrency and distribution of functionality
It is a component-and-connector structure.
3. Development : This shows the organization of software modules, libraries,
subsystems, and units of development.
- It is allocation structure.
4. Physical : This maps other elements onto processing and communication nodes.
It is an allocation structure.

SA/NH/CS'A'/2010 02/08/2010