Software Design & Architecture

By
Khansa Saleem
 Software Design and Architecture

Books
 Software architecture in practice (3rd Edition) By Len Bass,
Paul Clements, Rick Kazman
 Software architecture in practice (2nd Edition) By Len Bass,
Paul Clements, Rick Kazman
 Chapter 1
What is software architecture?

 The architecture is a bridge between those (often abstract)

business goals and the final (concrete) resulting system.
 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.
 Software architectures can be designed, analyzed,
documented, and implemented using known techniques
that will support the achievement of these business and
mission goals. The complexity can be tamed, made
tractable.
 Implications of our definition

Software systems are composed of many structures,

and no single structure holds claim to being the
architecture.
There are three categories of architectural structures,
which will play an important role in the design,
documentation, and analysis of architectures:
 1. Architecture Is a Set of Software Structures

1. First, some structures partition systems into

implementation units, which in this book we call modules.
 In large projects, these elements (modules) are subdivided
for assignment to sub teams. The structure that captures
that type of decomposition is a kind of module structure,
the module decomposition structure.
 Another kind of module structure emerges as an output of
object-oriented analysis and design—class diagrams.
 Module structures are static structures, in that they focus
on the way the system’s functionality is divided up and
assigned to implementation teams.
 1. Architecture Is a Set of Software Structures

2. Other structures are dynamic, meaning that they

focus on the way the elements interact with each
other at runtime to carry out the system’s functions.
 In this book we will call runtime structures
component-and-connector (C&C) structures.
 The term component is overloaded in software
engineering. In our use, a component is always a runtime
entity.
 1. Architecture Is a Set of Software Structures

3. A third kind of structure describes the mapping

from software structures to the system’s
organizational, developmental, installation, and
execution environments.
For example, modules are assigned to teams to
develop, and assigned to places in a file structure for
implementation, integration, and testing.
Components are deployed onto hardware in order to
execute. These mappings are called allocation
structures.
 2. Architecture Is an Abstraction

Architecture consists of structures and structures consist of

elements and relations, it follows that an architecture comprises
software elements and how the elements relate to each other.
This means that architecture specifically omits certain
information about elements that is not useful for reasoning about
the system. Thus, an architecture is foremost an abstraction of a
system that selects certain details and suppresses others.
In all modern systems, elements interact with each other by
means of interfaces that partition details about an element into
public and private parts. Architecture is concerned with the public
side of this division; private details of elements—details having to
do solely with internal implementation—are not architectural.
3. Every Software System Has a Software Architecture

Every system can be shown to comprise elements

and relations among them to support some type of
reasoning. In the most trivial case, a system is itself a
single element, Even though every system has an
architecture.
An architecture can exist independently of its
description or specification, this raises the
importance of architecture documentation
 4. Architecture Includes Behavior

The behavior of each element is part of the

architecture in so far as that behavior can be used to
reason about the system. This behavior embodies
how elements interact with each other, which is
clearly part of our definition of architecture.
An element’s behavior influences another element or
influences the acceptability of the system as a whole,
this behavior must be considered, and should be
documented, as part of the software architecture.
 5. Not All Architectures Are Good Architectures

An architecture may permit a system’s achievement

of its behavioral, quality attribute, and life-cycle
requirements.
Assuming that we do not accept trial and error as the
best way to choose an architecture for a system—
that is, picking an architecture at random, building
the system from it, and then hacking away and
hoping for the best—this raises the importance of
architecture design.
 System and Enterprise Architecture

1. System Architecture:
A system’s architecture is a representation of a system in which
there is a mapping of functionality onto hardware and software
components, a mapping of the software architecture onto the
hardware architecture, and a concern for the human interaction
with these components. That is, system architecture is concerned
with a total system, including hardware, software, and humans.
A system architecture will determine, for example, the
functionality that is assigned to different processors and the type
of network that connects those processors. The software
architecture on each of those processors will determine how this
functionality is implemented and how the various processors
interact through the exchange of messages on the network
 System and Enterprise Architecture

2. Enterprise Architecture:
Enterprise architecture is a description of the structure and behavior of
an organization’s processes, information flow, personnel, and
organizational subunits, aligned with the organization’s core goals and
strategic direction.
A modern enterprise architecture is concerned with how an enterprise’s
software systems support the business processes and goals of the
enterprise.
Typically included in this set of concerns is a process for deciding which
systems with which functionality should be supported by an enterprise.
An enterprise architecture will specify the data model that various
systems use to interact, for example. It will specify rules for how the
enterprise’s systems interact with external systems.
 Architectural Structures and Views

A view is 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.
A structure is the set of elements itself, as they exist in software or
hardware.
In short, a view is a representation of a structure. For example,
A module structure is the set of the system’s modules and their
organization.
A module view is the representation of that structure, documented
according to a template in a chosen notation, and used by some
system stakeholders.
So: Architects design structures. They document views of those
structures.
 Three Kinds of Structures

1. Module Structure
2. Component-and-connector structure
3. Allocation structures
 1. Module Structure

Module structures embody decisions as to how the system is to be

structured as a set of code or data units that have to be constructed or
procured.

Module structures allow us to answer questions such as these:

What is the primary functional responsibility assigned to each module?
What other software elements is a module allowed to use?
What other software does it actually use and depend on?
What modules are related to other modules by generalization or
specialization (i.e., inheritance) relationships?
In other words, examining a system’s module structures—that is, looking
at its module views—is an excellent way to reason about a system’s
modifiability.
 2. Component-and-connector structures

Component-and-connector structures embody decisions as to how the

system is to be structured as a set of elements that have runtime behavior
(components) and interactions (connectors).
Component-and-connector views help us answer questions such as these:
What are the major executing components and how do they interact at
runtime?
What are the major shared data stores?
Which parts of the system are replicated?
How does data progress through the system?
What parts of the system can run in parallel?
Can the system’s structure change as it executes and, if so, how?
By extension, component-and-connector views are crucially important for
asking questions about the system’s runtime properties such as
performance, security, availability, and more.
 3. Allocation structures

Allocation structures embody decisions as to how the system

will relate to non software structures in its environment (such as
CPUs, file systems, networks, development teams, etc.).
These structures show the relationship between the software
elements and elements in one or more external environments in
which the software is created and executed.
Allocation views help us answer questions such as these:
What processor does each software element execute on?
In what directories or files is each element stored during
development, testing, and system building?
What is the assignment of each software element to
development teams?
 Structure Provide insight

Each structure provides a perspective for reasoning about

some of the relevant quality attributes.
For example:
The module “uses” structure, which embodies what modules
use what other modules, is strongly tied to the ease with
which a system can be extended or contracted.
The concurrency structure, which embodies parallelism
within the system, is strongly tied to the ease with which a
system can be made free of deadlock and performance
bottlenecks.
The deployment structure is strongly tied to the achievement
of performance, availability, and security goals.
 1. Some Useful Module Structures

i. Decomposition structure
ii. Uses structure
iii. Layer structure
iv. Class (or generalization) structure
v. Data model
 i. Decomposition structure

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.
This structure is often used as the basis for the
development project’s organization, including the
structure of the documentation, and the project’s
integration and test plans. The units in this structure
tend to have names that are organization-specific such
as “segment” or “subsystem.”
 ii. Uses structure

In this important but overlooked structure, the units

here are also modules, perhaps classes. The units are
related by the uses relation, a specialized form of
dependency.
The uses structure is used to engineer systems that
can be extended to add functionality, or from which
useful functional subsets can be extracted. The
ability to easily create a subset of a system allows for
incremental development.
 iii. Layer structure

The modules in this structure are called layers.

A layer is an abstract “virtual machine” that provides a
cohesive set of services through a managed interface.
Layers are allowed to use other layers in a strictly
managed fashion; in strictly layered systems, a layer
is only allowed to use the layer immediately below.
This structure is used to diffuse a system with
portability, the ability to change the underlying
computing platform.
 iv. Class (or generalization) structure

The module units in this structure are called classes.

The relation is inherits from or is an instance of. This
view supports reasoning about collections of similar
behavior or capability (e.g., the classes that other
classes inherit from) and parameterized differences.
The class structure allows one to reason about reuse
and the incremental addition of functionality. If any
documentation exists for a project that has followed
an object-oriented analysis and design process, it is
typically this structure.
 v. Data model

The data model describes the static information

structure in terms of data entities and their
relationships.
For example, in a banking system, entities will typically
include Account, Customer, and Loan.
Account has several attributes, such as account number,
type (savings or checking), status, and current balance.
A relationship may dictate that one customer can have
one or more accounts, and one account is associated to
one or two customers.
 2. Some Useful C&C Structures

Component-and-connector structures show a

runtime view of the system. In these structures the
modules described above have all been compiled
into executable forms. It has two types,
i. Service structure
ii. Concurrency structure
 i. Service structure

The units here are services that interoperate with

each other by service coordination mechanisms such
as SOAP (see Chapter 6).
The service structure is an important structure to
help engineer a system composed of components
that may have been developed anonymously and
independently of each other.
 ii. Concurrency structure

This component-and-connector structure allows the

architect to determine opportunities for parallelism and
the locations where resource contention may occur. The
units are components and the connectors are their
communication mechanisms.
The components are arranged into logical threads; a
logical thread is a sequence of computations that could
be allocated to a separate physical thread later in the
design process. The concurrency structure is used early
in the design process to identify the requirements to
manage the issues associated with concurrent execution.
 3. Some Useful Allocation Structures

i. Deployment structure
ii. Implementation structure
iii. Work assignment structure
 i. Deployment structure

The deployment structure shows how software is

assigned to hardware processing and communication
elements.
The elements are software elements (usually a process
from a C&C view), hardware entities (processors), and
communication pathways.
This structure can be used to reason about
performance, data integrity, security, and availability.
It is of particular interest in distributed and parallel
systems.
 ii. Implementation structure

This structure shows how software elements (usually

modules) are mapped to the file structure(s) in the
system’s development, integration, or configuration
control environments.
This is critical for the management of development
activities and build processes.
 iii. Work assignment structure

This structure assigns responsibility for implementing and

integrating the modules to the teams who will carry it out.
Having a work assignment structure be part of the architecture
makes it clear that the decision about who does the work has
architectural as well as management implications.
The architect will know the expertise required on each team. Also,
on large multi-sourced distributed development projects, the work
assignment structure is the means for calling out units of functional
commonality and assigning those to a single team, rather than
having them implemented by everyone who needs them.
This structure will also determine the major communication
pathways among the teams: regular teleconferences, wikis, email
lists, and so forth
Useful Architectural Structure
 Which Structure to choose?

In 1995, Philippe Kruchten [Kruchten 95] published a

very influential paper in which he described the
concept of architecture comprising separate structures
and advised concentrating on four.
To validate that the structures were not in conflict with
each other and together did infact describe a system
meeting its requirements, Kruchten advised using key
use cases as a check. This so-called "Four Plus One"
approach became popular and has now been
institutionalized as the conceptual basis of the
Rational Unified Process.
 The “4+1” view model

Kruchten's four views follow:

Logical. The elements are "key abstractions," which are
manifested in the object-oriented world as objects or object
classes. This is a module view.
It is the object model of the design (when an object-oriented design
method is used)
Process. This view addresses concurrency and distribution of
functionality. It is a component-and-connector view.
Development. This view shows the organization of software
modules, libraries, subsystems, and units of development. It is
an allocation view, mapping software to the development
environment.
 The “4+1” view model

Physical. This view maps other elements onto processing and

communication nodes and is also an allocation view (which
others call the deployment view).
It describes the mapping(s) of the software onto the
hardware and reflects its distributed aspect,
At essentially the same time that Kruchten published his work,
Soni, Nord, and Hofmeister [Soni 95] published an
influential paper in which they reported the structures put
into use across many projects by the software architects in
their organization. Their views were conceptual, module
interconnection, execution, and code. Once again, these map
clearly to the module, component-and-connector, and
allocation models.
The “4+1” view model
 Architectural pattern

An architectural pattern describes the element types and their

forms of interaction used in solving the problem. Patterns
can be characterized according to the type of architectural
elements they use. For example,
A common module type pattern is this:
Layered pattern. When the uses relation among software
elements is strictly unidirectional, a system of layers
emerges. A layer is a coherent set of related functionality. In
a strictly layered structure, a layer can only use the services
of the layer immediately below it. Layers are often designed
as abstractions (virtual machines) that hide implementation
specifics below from the layers above.
Layered Pattern
 Architectural pattern

Common component-and-connector type patterns are

these:
Shared-data (or repository) pattern. This pattern
comprises components and connectors that create, store,
and access persistent data. The repository usually takes
the form of a (commercial) database. The connectors are
protocols for managing the data, such as SQL.
Client-server pattern. The components are the clients
and the servers, and the connectors are protocols and
messages they share among each other to carry out the
system’s work.
 Architectural pattern

Common allocation patterns include the following:

 Multi-tier pattern, which describes how to distribute and allocate the
components of a system in distinct subsets of hardware and software,
connected by some communication medium. This pattern specializes
the generic deployment (software-to-hardware allocation) structure.
Competence center and platform, which are patterns that specialize a
software system’s work assignment structure. In competence center,
work is allocated to sites depending on the technical or domain
expertise located at a site. For example, user-interface design is done
at a site where usability engineering experts are located. In platform,
one site is tasked with developing reusable core assets of a software
product line (see Chapter 25), and other sites develop applications
that use the core assets.
 What Makes a “Good” Architecture?

We divide our observations into two clusters: process

recommendations and product (or structural) recommendations.
Our process recommendations are the following:
The architecture should be the product of a single architect or a
small group of architects with an identified technical leader.
The architect (or architecture team) should, on an ongoing basis,
base the architecture on a prioritized list of well-specified quality
attribute requirements.
The architecture should be documented using views. The views
should address the concerns of the most important stakeholders
in support of the project timeline. This might mean minimal
documentation at first, elaborated later. Concerns usually are
related to construction, analysis, and maintenance of the system,
as well as education of new stakeholders about the system.
 What Makes a “Good” Architecture?

The architecture should be evaluated for its ability to

deliver the system’s important quality attributes.
The architecture should lend itself to incremental
implementation, to avoid having to integrate
everything at once (which almost never works) as
well as to discover problems early.
 What Makes a “Good” Architecture?

Our structural rules of thumb are as follows:

1. The architecture should feature well-defined modules
whose functional responsibilities are assigned on the
principles of information hiding and separation of
concerns.
2. Unless your requirements are unprecedented—possible,
but unlikely—your quality attributes should be achieved
using well-known architectural patterns and tactics.
3. The architecture should never depend on a particular
version of a commercial product or tool. If it must, it
should be structured so that changing to a different
version is straightforward and inexpensive.
 What Makes a “Good” Architecture?

4. Modules that produce data should be separate from modules

that consume data. This tends to increase modifiability because
changes are frequently confined to either the production or the
consumption side of data. If new data is added, both sides will
have to change, but the separation allows for a staged
(incremental) upgrade.
5. Don’t expect a one-to-one correspondence between modules and
components. For example, in systems with concurrency, there
may be multiple instances of a component running in parallel,
where each component is built from the same module. For
systems with multiple threads of concurrency, each thread may
use services from several components, each of which was built
from a different module.
 What Makes a “Good” Architecture?

6. Every process should be written so that its assignment to a

specific processor can be easily changed, perhaps even at runtime.
7. The architecture should feature a small number of ways for
components to interact. This will aid in understandability, reduce
development time, increase reliability, and enhance modifiability.
8. The architecture should contain a specific (and small) set of
resource contention areas, the resolution of which is clearly
specified and maintained. For example, if network utilization is an
area of concern, the architect should produce (and enforce) for
each development team guidelines that will result in a minimum of
network traffic. If performance is a concern, the architect should
produce (and enforce) time budgets for the major threads.