Topics in Software

Architecture

Len Bass
Paul Clements
Rick Kazman
Introductions

Instructors
 Len Bass
 Paul Clements
 Rick Kazman

Students?
Course Week 1 Why is each topic
important?

Monday
What is Architecture - Len Bass
The architecture business cycle - Paul Clements

Tuesday
Understanding quality attributes - Len Bass
Principles of architecture design - Len Bass

Wednesday
Achieving quality attributes through tactics and patterns - Rick
Kazman

Thursday
Architectural decisions and making them - Rick Kazman
Recovering architecture - Rick Kazman

Friday
Modeling and evaluating architectures - Rick Kazman
Economic analysis related to software architectures - Rick
Kazman
Course Week 2 Why is each topic
important?

Monday
Gathering architecturally significant requirements -
Paul Clements
The Attribute Driven Design Method - Len Bass

Tuesday
Documenting Software Architecture - Paul
Clements

Wednesday
Product Lines - Paul Clements
Management and Governance - Len Bass

Thursday
Architectural Competence - Paul Clements

Friday
Examination
Module 1
What is Software Architecture?
Outline of Module

What software architecture is and what it isn't

Why is software architecture important

Important concepts
 Architecture structures and views

relating structures to each other

which structures to choose
 Architectural styles and patterns

Different kinds (genres) of architecture.

Role of architect
What does this picture tell us and what is
left out?

Control
Process

Prop Loss Reverb Noise

Model Model Model
The picture is a view of an architecture

A view of an architecture is a projection of the
architecture that emphasizes certain
properties and hides other properties.

There are a number of standard views that
we will get to later.

For now, the view we have seen hides more
than it emphasizes
Our definition of software architecture

The software architecture of a system is the
set of structures needed to reason about the
system, which comprise software elements,
relations among them, and properties of
both

Key concepts to unpack from the definition
 Reasoning about the system
 Software elements
 Relations among software elements
 Properties of software elements and the relations
among them
 Structures
Reasoning

Software elements and their relations are
architectural if they let you reason about
systemwide behavior that is important to some
stakeholder

Span of impact systemwide vs local is
important in this assertion.
 A data structure, for example, is architectural if its use
spans multiple components and is not architectural if
its use is local.

Reasoning about behavior is also important. E.g.
the set of variables that begin with A are not
architectural since these variables do not help
reason about systemwide behavior.
Software elements

Three states of software
 Code. Units of implementation, e.g. modules,
classes
 Execution. Units of execution, e.g. processes,
tasks
 Allocated. Location where software has been
allocated. Hardware for execution or teams for
development.
Relations among software elements

Possible relations depend on type of element.

Code elements
 Decomposition
 Uses

Execution
 Message passing
 Synchronizes with
Properties of software elements and the
relations among them

Properties of element
 Responsibilities - for code elements
 Execution time for execution elements

Properties of relations
 Allowed to use
 Message multicast
Structures

A structure is a defined set of software types, properties,
and relations.

Code based structures are different types of module based
structures. E.g.
 Decomposition
 layered

Execution based structures are different types of
component and connector structures. E.g.
 Process
 Repository

In addition, software is allocated to hardware in order to
execute and to teams in order to develop. Allocation
structures discuss various allocations of the software.

We will pursue this in more detail later.
Architectural Patterns

Collection of modules or components and
their interactions

General purpose without specific application
functionality

E.g.
 Layered pattern
 Model View Controller Pattern
 Publish/Subscribe Pattern

We will discuss Patterns in more detail later
in this course
Exercise Layered View

What is it?

What is it good for?

What properties of the elements allow one to
reason about the layered view.
Other definitions of architecture

Our definition is structural structures and
relations

Other definitions
 Including process. E.g. ISO 42010 defines
software architecture as including the principles
guiding its design and evolution.
 As a set of decisions. .e.g A software systems
architecture is the set of principal design decisions
about the system
Why is Architecture important - 1

Communication among stakeholders.
 To developers what to build
 To interacting systems how does one
interact with this system
 To management these are the big pieces
and

this is the progress being made on those pieces

These are the resources needed for these pieces
Why is Architecture important - 2

Transferable abstraction of a system.
 Software architecture constitutes a relatively
small, intellectually graspable model that
describes

How the system is structured

How its elements work together;
 this model is transferable across systems and
can promote large scale reuse.
Why is Architecture important - 3

Early design decisions.
 Software architecture is the earliest design
decisions about a system,
 It is the earliest point at which design
decisions governing the system to be built can
be analyzed.
Architectural Design Decisions

Architectural design decisions have great impact
on how well the system achieves its quality
attribute requirements (the ilities).

Categories of architectural design decisions are
 Allocation of Functionality
 Coordination Model
 Data and object Model
 Management of Resources
 Mapping Among Architectural Elements
 Binding Time Decisions
 Choice of Technology
Allocation of Functionality

identifying the important responsibilities
and their abstractions, and the operations
that they provide

determining how these responsibilities are
allocated to hardware and software,
runtime and non runtime elements
(components and modules).

identifying the major modes of operation
and determining how they are realized.
Coordination Model

identifying the elements of the system that must coordinate
directly or indirectlyand the properties of that coordination, such
as timeliness, currency, completeness, correctness, and consistency

choosing the coordination model (between systems, between our
system and external entities, between elements of our system) and
the communication mechanisms that realize this model

understanding the information that system and external entities
share and how consistent this information needs to be over time

deciding the properties of the communication mechanisms, for
example, stateful, stateless, synchronous, asynchronous,
guaranteed delivery, throughput, and latency
Data and object Model

choosing the major data abstractions, their operations,
and their properties

determining how the data items are created, initialized,
persisted, manipulated, translated, and destroyed
Management of Resources

identifying the resources that must be managed:
hard resources (e.g., CPU, memory, battery,
hardware buffers, system clock, I/O ports.) and
soft resources (e.g., system locks, software
buffers, and thread pools

determining the resource limits

determining which system element(s) manage
each resource

determining which resources are shared and how
these are arbitrated (e.g., the process/thread
models employed or the scheduling strategies
employed)
Mapping Among Architectural Elements

the mapping of modules and runtime
elements to each otherthat is, the runtime
elements that are created from each module;
the modules that contain the code for each
runtime element

the assignment of runtime elements to
processors

the assignment of items in the data model to
data stores

the mapping of modules and runtime
elements to units of delivery
Binding Time Decisions

compile time (e.g., compiler switches)

build time (e.g., replace modules, pick
from library)

load time (e.g., dynamic link libraries [dlls])

initialization time (e.g., resource files)

runtime (e.g., load balancing)
Choice of Technology

knowing which technologies are available to
realize the decisions made in the other
models

investigating the available tools to support
this technology choice (IDEs, testing tools,
etc.)

knowing what external support is available for
the technology, such as courses, tutorials,
examples, internal familiarity, and availability
of contractors who can provide expertise in a
crunch
Structure - analogy

There are different ways to look at a body
 Circulation
 Nerve structure
 Muscle structure
 .

Each way of looking at a body exposes some
aspects
Structure - software

There are multiple different ways to look at a software
system

Based on different fundamental types of software
elements
 Code units

 Execution units

Each structure definition consists of

 software element types,

 properties of those types,

 allowable relations and

 properties of those relations

Terminology structure and view

View - a representation of a coherent set of
architectural elements, as written by and
read by system stakeholders. It consists of
a representation of a set of elements and
the relations among them.

Structure - the set of elements itself

These terms are frequently used
interchangeably but we will adhere to
these definitions
Architectural structures

Modules based on code units

Component and connectors based on
execution units

Allocation based on mapping of software
units to non software units.

Different structures are used to enable
reasoning about different properties of the
system.
Module structures

Modules are assigned responsibilities. A
responsibility is something the module must do,
must remember or must decide. E.g. A cash
machine includes responsibilities
 Identify user
 Determine action user wishes
 Dispense money

Responsibilities can be decomposed.
 Identify user involves reading card, checking PIN.

Allows reasoning about
 function
 Change
 Reuse
Some module structures

Decomposition structure. The units are modules that
are related to each other by the is a submodule of
relation, showing how modules are decomposed into
smaller modules recursively until the modules are
small enough to be easily understood.

Uses structure. the units of this structure are also
modulesThe units are related by the uses relation.

Class structure, or generalization. The module units in
this structure are called classes. The relation is
inherits-from or is-an-instance-of.

Data model. The data model describes the static
information structure in terms of data entities and their
relationships.
Component and Connector Structures

Components are run time units e.g. processes

Connectors are how the components
communicate, e.g. message bus

Allows reasoning about
 The major executing components and how they
interact
 The major shared data stores
 Replication
 How data progresses through the system
 What parts of the system can run in parallel
 How the systems structure changes as it
executes
Some Component and Connector
Structures

Process structure, or coordinating processes. This
structure deals with the dynamic aspects of a
running system.
 Processes or threads connected to each other by
communication, synchronization, or exclusion

Concurrency structure. An early and abstract
version of the process structure. Used for
determining opportunities for parallelism and the
locations where resource contention may occur.
Allocation Structure

Elements are software elements and
elements in one or more external
environments in which the software is
created and executed.

Allows reasoning about hardware acquisition
and performance or team structures
Some Allocation Structures

Deployment structure. The deployment structure
shows how software is assigned to hardware
processing and communication elements. This
view allows reasoning about
 performance,
 availability, and
 security.

Implementation structure. The implementation
structure shows how software elements (usually
modules) are mapped to the file structure(s) in the
systems development, integration, or
configuration control environments.
Architecture patterns

Example MVC

Definition

Use
Structure of the Model View Controller

View Model
Command Command
Command Command
Processor Processor
Input device Processor Processor

Output
device Controller
Command
Command
Processor
Processor
Suns characterization of the components of the
MVC

Model - Encapsulated application state

- Responds to state queries

- Exposes application functionality

- Notifies views of changes

View - Renders the models

- Requests updates from models

- Sends user gestures to controller

- Allows controller to select view

Controller - Defined application behavior

- Maps user actions to model updates

- Select view for response

- One for each functionality
The responsibilities within MVC

A responsibility does something, remembers
something, or makes a decision (Wirfs-Brock, et. al.,
1990)

Model - Encapsulated application state
 Responds to state queries
 Exposes application functionality
 Notifies views of changes

View - Renders the models
 Requests updates from models
 Sends user gestures to controller
 Allows controller to select view

Controller - Defined application behavior
 Maps user actions to model updates
 Select view for response
 One for each functionality
What can we tell or not tell from this
description of the MVC pattern?

EXERCISE
Use of Patterns

Patterns represent codified solutions to
common problems

Patterns are used during the design process

Patterns provide the basis for tools

Patterns are used during the evaluation
process
Other forms of architecture and types of
systems

System Architecture

Enterprise Architecture

System of Systems/Ultra Large Scale
Systems
System Architecture

System architecture is concerned with a total
system including hardware, software and
humans

Software is mapped onto hardware,
frequently embedded into hardware.

Quality attributes such as power, weight,
footprint are important when reasoning about
systems.
Enterprise Architecture

Enterprise Architecture is the description
 current and/or future structure and behavior of
an organization's processes,
 information systems,
 personnel and organizational sub-units,

aligned with the organization's core goals
and strategic direction.

Enterprise architecture sets constraints for
software applications.
System of Systems/Ultra Large Scale
Systems

Some systems have no central organization
with control over whole system
 Internet
 Telephone system
 Electric System

Techniques for designing and analyzing such
systems are much more organization
centered than designing and analyzing
systems with overall oversight.
Architects and architecting

Architects exist in an organizational context

They need multiple different skills
 Technical
 Communication
 Leadership
Summary - 1

Software architecture is primarily concerned
with structure of system

Architecture is used for
 Communication
 Basis for analysis
 Transferable abstraction

Multiple views of a system are important
 Module
 Component and connector
 Allocation
Summary 2

Architectural patterns are codified solutions to
common problems.
Questions?