Software Architecture typically refers to the bigger structures of a

software system, and it deals with how multiple software processes

cooperate to carry out their tasks. Software Design refers to the
smaller structures and it deals with the internal design of a single
software process. By the end of this tutorial, the readers will
develop a sound understanding of the concepts of software
architecture and design concepts and will be in a position to choose
and follow the right model for a given software project.

The architecture of a system describes its major components, their

relationships (structures), and how they interact with each other.
Software architecture and design includes several contributory
factors such as Business strategy, quality attributes, human
dynamics, design, and IT environment.

We can segregate Software Architecture and Design into two

distinct phases: Software Architecture and Software Design.
In Architecture, nonfunctional decisions are cast and separated by
the functional requirements. In Design, functional requirements are
accomplished.

Software Architecture
Architecture serves as a blueprint for a system. It provides an
abstraction to manage the system complexity and establish a
communication and coordination mechanism among components.

 It defines a structured solution to meet all the technical and

operational requirements, while optimizing the common quality
attributes like performance and security.
 Further, it involves a set of significant decisions about the
organization related to software development and each of
these decisions can have a considerable impact on quality,
maintainability, performance, and the overall success of the
final product. These decisions comprise of −
o Selection of structural elements and their interfaces by
which the system is composed.
o Behavior as specified in collaborations among those
elements.
o Composition of these structural and behavioral elements
into large subsystem.
o Architectural decisions align with business objectives.
o Architectural styles guide the organization.

Software Design
Software design provides a design plan that describes the elements of
a system, how they fit, and work together to fulfill the requirement
of the system. The objectives of having a design plan are as follows
−

 To negotiate system requirements, and to set expectations

with customers, marketing, and management personnel.
 Act as a blueprint during the development process.
 Guide the implementation tasks, including detailed design,
coding, integration, and testing.

It comes before the detailed design, coding, integration, and testing

and after the domain analysis, requirements analysis, and risk
analysis.
Goals of Architecture
The primary goal of the architecture is to identify requirements that
affect the structure of the application. A well-laid architecture
reduces the business risks associated with building a technical
solution and builds a bridge between business and technical
requirements.

Some of the other goals are as follows −

 Expose the structure of the system, but hide its

implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s
market position.
 Improve quality and functionality offered by the system.
 Improve external confidence in either the organization or
system.

Limitations

Software architecture is still an emerging discipline within software

engineering. It has the following limitations −

 Lack of tools and standardized ways to represent architecture.

  Lack of analysis methods to predict whether architecture will
result in an implementation that meets the requirements.
 Lack of awareness of the importance of architectural design to
software development.
 Lack of understanding of the role of software architect and
poor communication among stakeholders.
 Lack of understanding of the design process, design
experience and evaluation of design.

Role of Software Architect

A Software Architect provides a solution that the technical team can
create and design for the entire application. A software architect
should have expertise in the following areas −

Design Expertise

 Expert in software design, including diverse methods and

approaches such as object-oriented design, event-driven
design, etc.
 Lead the development team and coordinate the development
efforts for the integrity of the design.
 Should be able to review design proposals and tradeoff among
themselves.

Domain Expertise

 Expert on the system being developed and plan for software

evolution.
 Assist in the requirement investigation process, assuring
completeness and consistency.
 Coordinate the definition of domain model for the system
being developed.

Technology Expertise

 Expert on available technologies that helps in the

implementation of the system.
 Coordinate the selection of programming language,
framework, platforms, databases, etc.
Methodological Expertise

 Expert on software development methodologies that may be

adopted during SDLC (Software Development Life Cycle).
 Choose the appropriate approaches for development that helps
the entire team.

Hidden Role of Software Architect

 Facilitates the technical work among team members and

reinforcing the trust relationship in the team.
 Information specialist who shares knowledge and has vast
experience.
 Protect the team members from external forces that would
distract them and bring less value to the project.

Deliverables of the Architect

 A clear, complete, consistent, and achievable set of functional

goals
 A functional description of the system, with at least two layers
of decomposition
 A concept for the system
 A design in the form of the system, with at least two layers of
decomposition
 A notion of the timing, operator attributes, and the
implementation and operation plans
 A document or process which ensures functional decomposition
is followed, and the form of interfaces is controlled

Quality Attributes
Quality is a measure of excellence or the state of being free from
deficiencies or defects. Quality attributes are the system properties
that are separate from the functionality of the system.

Implementing quality attributes makes it easier to differentiate a

good system from a bad one. Attributes are overall factors that
affect runtime behavior, system design, and user experience.
They can be classified as −

Static Quality Attributes

Reflect the structure of a system and organization, directly related

to architecture, design, and source code. They are invisible to end-
user, but affect the development and maintenance cost, e.g.:
modularity, testability, maintainability, etc.

Dynamic Quality Attributes

Reflect the behavior of the system during its execution. They are
directly related to system’s architecture, design, source code,
configuration, deployment parameters, environment, and platform.

They are visible to the end-user and exist at runtime, e.g.

throughput, robustness, scalability, etc.

Quality Scenarios
Quality scenarios specify how to prevent a fault from becoming a
failure. They can be divided into six parts based on their attribute
specifications −

 Source − An internal or external entity such as people,

hardware, software, or physical infrastructure that generate
the stimulus.
 Stimulus − A condition that needs to be considered when it
arrives on a system.
 Environment − The stimulus occurs within certain conditions.
 Artifact − A whole system or some part of it such as
processors, communication channels, persistent storage,
processes etc.
 Response − An activity undertaken after the arrival of stimulus
such as detect faults, recover from fault, disable event source
etc.
 Response measure − Should measure the occurred responses so
that the requirements can be tested.

Common Quality Attributes

The following table lists the common quality attributes a software
architecture must have −

Category Quality Attribute Description

Defines the consistency and coherence of the

Conceptual Integrity overall design. This includes the way components
or modules are designed.

Ability of the system to undergo changes with a

Design Qualities Maintainability
degree of ease.

Defines the capability for components and

Reusability subsystems to be suitable for use in other
applications.

Ability of a system or different systems to operate

successfully by communicating and exchanging
Interoperability
information with other external systems written
and run by external parties.

Defines how easy it is for system administrators

Manageability
to manage the application.

Ability of a system to remain operational over

Reliability
time.

Ability of a system to either handle the load

Run-time Qualities Scalability increase without impacting the performance of the
system or the ability to be readily enlarged.

Capability of a system to prevent malicious or

Security
accidental actions outside of the designed usages.

Indication of the responsiveness of a system to

Performance
execute any action within a given time interval.

Defines the proportion of time that the system is

functional and working. It can be measured as a
Availability
percentage of the total system downtime over a
predefined period.

System Qualities Ability of the system to provide information

Supportability helpful for identifying and resolving issues when
it fails to work correctly.

Testability Measure of how easy it is to create test criteria for

 the system and its components.

Defines how well the application meets the

User Qualities Usability requirements of the user and consumer by being
intuitive.

Accountability for satisfying all the requirements

Architecture Quality Correctness
of the system.

Ability of the system to run under different

Portability
computing environment.

Ability to make separately developed components

Non-runtime Quality Integrality
of the system work correctly together.

Ease with which each software system can

Modifiability
accommodate changes to its software.

Cost of the system with respect to time to market,

Cost and schedule
expected project lifetime & utilization of legacy.
Business quality attributes
Marketability Use of system with respect to market competition.

Software architecture is described as the organization of a system,

where the system represents a set of components that accomplish
the defined functions.

Architectural Style
The architectural style, also called as architectural pattern, is a set of
principles which shapes an application. It defines an abstract
framework for a family of system in terms of the pattern of
structural organization.

The architectural style is responsible to −

 Provide a lexicon of components and connectors with rules on

how they can be combined.
 Improve partitioning and allow the reuse of design by giving
solutions to frequently occurring problems.
 Describe a particular way to configure a collection of
components (a module with well-defined interfaces, reusable,
 and replaceable) and connectors (communication link between
modules).

The software that is built for computer-based systems exhibit one of

many architectural styles. Each style describes a system category
that encompasses −

 A set of component types which perform a required function by

the system.
 A set of connectors (subroutine call, remote procedure call,
data stream, and socket) that enable communication,
coordination, and cooperation among different components.
 Semantic constraints which define how components can be
integrated to form the system.
 A topological layout of the components indicating their runtime
interrelationships.

Common Architectural Design

The following table lists architectural styles that can be organized by
their key focus area −

Category Architectural Design Description

Prescribes use of a software system that can

Message bus receive and send messages using one or more
communication channels.
Communication
Defines the applications that expose and
Service–Oriented Architecture
consume functionality as a service using
(SOA)
contracts and messages.

Separate the system into two applications,

Client/server
where the client makes requests to the server.
Deployment Separates the functionality into separate
3-tier or N-tier segments with each segment being a tier
located on a physically separate computer.

Focused on modeling a business domain and

Domain Domain Driven Design defining business objects based on entities
within the business domain.
 Breakdown the application design into reusable
Component Based functional or logical components that expose
well-defined communication interfaces.

Divide the concerns of the application into

Layered
Structure stacked groups (layers).

Based on the division of responsibilities of an

application or system into objects, each
Object oriented
containing the data and the behavior relevant to
the object.

Types of Architecture
There are four types of architecture from the viewpoint of an
enterprise and collectively, these architectures are referred to
as enterprise architecture.

 Business architecture − Defines the strategy of business,

governance, organization, and key business processes within
an enterprise and focuses on the analysis and design of
business processes.
 Application (software) architecture − Serves as the blueprint for
individual application systems, their interactions, and their
relationships to the business processes of the organization.
 Information architecture − Defines the logical and physical data
assets and data management resources.
 Information technology (IT) architecture − Defines the hardware
and software building blocks that make up the overall
information system of the organization.

Architecture Design Process

The architecture design process focuses on the decomposition of a
system into different components and their interactions to satisfy
functional and nonfunctional requirements. The key inputs to
software architecture design are −

 The requirements produced by the analysis tasks.

  The hardware architecture (the software architect in turn
provides requirements to the system architect, who configures
the hardware architecture).

The result or output of the architecture design process is

an architectural description. The basic architecture design process is
composed of the following steps −

Understand the Problem

 This is the most crucial step because it affects the quality of

the design that follows.
 Without a clear understanding of the problem, it is not possible
to create an effective solution.
 Many software projects and products are considered failures
because they did not actually solve a valid business problem or
have a recognizable return on investment (ROI).

Identify Design Elements and their Relationships

 In this phase, build a baseline for defining the boundaries and

context of the system.
 Decomposition of the system into its main components based
on functional requirements. The decomposition can be
modeled using a design structure matrix (DSM), which shows
the dependencies between design elements without specifying
the granularity of the elements.
 In this step, the first validation of the architecture is done by
describing a number of system instances and this step is
referred as functionality based architectural design.

Evaluate the Architecture Design

 Each quality attribute is given an estimate so in order to

gather qualitative measures or quantitative data, the design is
evaluated.
 It involves evaluating the architecture for conformance to
architectural quality attributes requirements.
 If all estimated quality attributes are as per the required
standard, the architectural design process is finished.
  If not, the third phase of software architecture design is
entered: architecture transformation. If the observed quality
attribute does not meet its requirements, then a new design
must be created.

Transform the Architecture Design

 This step is performed after an evaluation of the architectural

design. The architectural design must be changed until it
completely satisfies the quality attribute requirements.
 It is concerned with selecting design solutions to improve the
quality attributes while preserving the domain functionality.
 A design is transformed by applying design operators, styles,
or patterns. For transformation, take the existing design and
apply design operator such as decomposition, replication,
compression, abstraction, and resource sharing.
 The design is again evaluated and the same process is
repeated multiple times if necessary and even performed
recursively.
 The transformations (i.e. quality attribute optimizing solutions)
generally improve one or some quality attributes while they
affect others negatively

Key Architecture Principles

Following are the key principles to be considered while designing an
architecture −

Build to Change Instead of Building to Last

Consider how the application may need to change over time to

address new requirements and challenges, and build in the flexibility
to support this.

Reduce Risk and Model to Analyze

Use design tools, visualizations, modeling systems such as UML to

capture requirements and design decisions. The impacts can also be
analyzed. Do not formalize the model to the extent that it
suppresses the capability to iterate and adapt the design easily.
Use Models and Visualizations as a Communication and
Collaboration Tool

Efficient communication of the design, the decisions, and ongoing

changes to the design is critical to good architecture. Use models,
views, and other visualizations of the architecture to communicate
and share the design efficiently with all the stakeholders. This
enables rapid communication of changes to the design.

Identify and understand key engineering decisions and areas where

mistakes are most often made. Invest in getting key decisions right
the first time to make the design more flexible and less likely to be
broken by changes.

Use an Incremental and Iterative Approach

Start with baseline architecture and then evolve candidate

architectures by iterative testing to improve the architecture.
Iteratively add details to the design over multiple passes to get the
big or right picture and then focus on the details.

Key Design Principles

Following are the design principles to be considered for minimizing
cost, maintenance requirements, and maximizing extendibility,
usability of architecture −

Separation of Concerns

Divide the components of system into specific features so that there

is no overlapping among the components functionality. This will
provide high cohesion and low coupling. This approach avoids the
interdependency among components of system which helps in
maintaining the system easy.

Single Responsibility Principle

Each and every module of a system should have one specific

responsibility, which helps the user to clearly understand the
system. It should also help with integration of the component with
other components.

Principle of Least Knowledge

Any component or object should not have the knowledge about

internal details of other components. This approach avoids
interdependency and helps maintainability.

Minimize Large Design Upfront

Minimize large design upfront if the requirements of an application

are unclear. If there is a possibility of modifying requirements, then
avoid making a large design for whole system.

Do not Repeat the Functionality

Do not repeat functionality specifies that functionality of

components should not to be repeated and hence a piece of code
should be implemented in one component only. Duplication of
functionality within an application can make it difficult to implement
changes, decrease clarity, and introduce potential inconsistencies.

Prefer Composition over Inheritance while Reusing the

Functionality

Inheritance creates dependency between children and parent

classes and hence it blocks the free use of the child classes. In
contrast, the composition provides a great level of freedom and
reduces the inheritance hierarchies.

Identify Components and Group them in Logical Layers

Identity components and the area of concern that are needed in

system to satisfy the requirements. Then group these related
components in a logical layer, which will help the user to understand
the structure of the system at a high level. Avoid mixing
components of different type of concerns in same layer.

Define the Communication Protocol between Layers

Understand how components will communicate with each other
which requires a complete knowledge of deployment scenarios and
the production environment.

Define Data Format for a Layer

Various components will interact with each other through data

format. Do not mix the data formats so that applications are easy to
implement, extend, and maintain. Try to keep data format same for
a layer, so that various components need not code/decode the data
while communicating with each other. It reduces a processing
overhead.

System Service Components should be Abstract

Code related to security, communications, or system services like

logging, profiling, and configuration should be abstracted in the
separate components. Do not mix this code with business logic, as it
is easy to extend design and maintain it.

Design Exceptions and Exception Handling Mechanism

Defining exceptions in advance, helps the components to manage

errors or unwanted situation in an elegant manner. The exception
management will be same throughout the system.

Naming Conventions

Naming conventions should be defined in advance. They provide a

consistent model that helps the users to understand the system
easily. It is easier for team members to validate code written by
others, and hence will increase the maintainability.

Software architecture involves the high level structure of software

system abstraction, by using decomposition and composition, with
architectural style and quality attributes. A software architecture
design must conform to the major functionality and performance
requirements of the system, as well as satisfy the non-functional
requirements such as reliability, scalability, portability, and
availability.
A software architecture must describe its group of components,
their connections, interactions among them and deployment
configuration of all components.

A software architecture can be defined in many ways −

 UML (Unified Modeling Language) − UML is one of object-oriented

solutions used in software modeling and design.
 Architecture View Model (4+1 view model) − Architecture view
model represents the functional and non-functional
requirements of software application.
 ADL (Architecture Description Language) − ADL defines the
software architecture formally and semantically.

UML
UML stands for Unified Modeling Language. It is a pictorial language
used to make software blueprints. UML was created by Object
Management Group (OMG). The UML 1.0 specification draft was
proposed to the OMG in January 1997. It serves as a standard for
software requirement analysis and design documents which are the
basis for developing a software.

UML can be described as a general purpose visual modeling

language to visualize, specify, construct, and document a software
system. Although UML is generally used to model software system,
it is not limited within this boundary. It is also used to model non
software systems such as process flows in a manufacturing unit.

The elements are like components which can be associated in

different ways to make a complete UML picture, which is known as
a diagram. So, it is very important to understand the different
diagrams to implement the knowledge in real-life systems. We have
two broad categories of diagrams and they are further divided into
sub-categories i.e. Structural Diagrams and Behavioral Diagrams.

Structural Diagrams
Structural diagrams represent the static aspects of a system. These
static aspects represent those parts of a diagram which forms the
main structure and is therefore stable.

These static parts are represented by classes, interfaces, objects,

components and nodes. Structural diagrams can be sub-divided as
follows −

 Class diagram
 Object diagram
 Component diagram
 Deployment diagram
 Package diagram
 Composite structure

The following table provides a brief description of these diagrams −

Sr.No
Diagram & Description
.

Class
1
Represents the object orientation of a system. Shows how classes are statically related.

Object
2 Represents a set of objects and their relationships at runtime and also represent the static view of the
system.

Component
3
Describes all the components, their interrelationship, interactions and interface of the system.

Composite structure
4
Describes inner structure of component including all classes, interfaces of the component, etc.

Package
5 Describes the package structure and organization. Covers classes in the package and packages
within another package.

Deployment
6 Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities
where the components are deployed.

Behavioral Diagrams
Behavioral diagrams basically capture the dynamic aspect of a
system. Dynamic aspects are basically the changing/moving parts of
a system. UML has the following types of behavioral diagrams −

 Use case diagram

 Sequence diagram
 Communication diagram
 State chart diagram
 Activity diagram
 Interaction overview
 Time sequence diagram

The following table provides a brief description of these diagram −

Sr.No
Diagram & Description
.

Use case
1 Describes the relationships among the functionalities and their internal/external controllers. These
controllers are known as actors.

Activity
2 Describes the flow of control in a system. It consists of activities and links. The flow can be
sequential, concurrent, or branched.

State Machine/state chart

3 Represents the event driven state change of a system. It basically describes the state change of a
class, interface, etc. Used to visualize the reaction of a system by internal/external factors.

Sequence
4
Visualizes the sequence of calls in a system to perform a specific functionality.

Interaction Overview
5 Combines activity and sequence diagrams to provide a control flow overview of system and
business process.

Communication
6 Same as sequence diagram, except that it focuses on the object’s role. Each communication is
associated with a sequence order, number plus the past messages.

Time Sequenced
7
Describes the changes by messages in state, condition and events.

Architecture View Model

A model is a complete, basic, and simplified description of software
architecture which is composed of multiple views from a particular
perspective or viewpoint.

A view is a representation of an entire system from the perspective

of a related set of concerns. It is used to describe the system from
the viewpoint of different stakeholders such as end-users,
developers, project managers, and testers.

4+1 View Model

The 4+1 View Model was designed by Philippe Kruchten to describe

the architecture of a software–intensive system based on the use of
multiple and concurrent views. It is a multiple view model that
addresses different features and concerns of the system. It
standardizes the software design documents and makes the design
easy to understand by all stakeholders.

It is an architecture verification method for studying and

documenting software architecture design and covers all the aspects
of software architecture for all stakeholders. It provides four
essential views −

 The logical view or conceptual view − It describes the object model

of the design.
 The process view − It describes the activities of the system,
captures the concurrency and synchronization aspects of the
design.
 The physical view − It describes the mapping of software onto
hardware and reflects its distributed aspect.
 The development view − It describes the static organization or
structure of the software in its development of environment.

This view model can be extended by adding one more view

called scenario view or use case view for end-users or customers of
software systems. It is coherent with other four views and are
utilized to illustrate the architecture serving as “plus one” view,
(4+1) view model. The following figure describes the software
architecture using five concurrent views (4+1) model.
Why is it called 4+1 instead of 5?

The use case view has a special significance as it details the high level
requirement of a system while other views details — how those
requirements are realized. When all other four views are completed,
it’s effectively redundant. However, all other views would not be
possible without it. The following image and table shows the 4+1
view in detail −

Logical Process Development Physical Scenario

Shows the processes / Gives building block Shows the design is

Shows the installation,
Shows the component Workflow rules of system views of system and complete by
configuration and
Description (Object) of system as and how those processes describe static performing
deployment of software
well as their interaction communicate, focuses on organization of the validation and
application
dynamic view of system system modules illustration

System engineer,
Programmer and All the views of
Viewer / End-User, Analysts and operators, system
Integrators & developers software project their views and
Stake holder Designer administrators and
managers evaluators
system installers

Software Module
Nonfunctional
Functional Non Functional organization (Software System Consistency
Consider requirement regarding
requirements Requirements management reuse, and validity
to underlying hardware
constraint of tools)

Class, State, Object,

UML – sequence, Component, Package
Activity Diagram Deployment diagram Use case diagram
Diagram Communication diagram
Diagram

Architecture Description Languages (ADLs)

An ADL is a language that provides syntax and semantics for
defining a software architecture. It is a notation specification which
provides features for modeling a software system’s conceptual
architecture, distinguished from the system’s implementation.

ADLs must support the architecture components, their connections,

interfaces, and configurations which are the building block of
architecture description. It is a form of expression for use in
architecture descriptions and provides the ability to decompose
components, combine the components, and define the interfaces of
components.

An architecture description language is a formal specification

language, which describes the software features such as processes,
threads, data, and sub-programs as well as hardware component
such as processors, devices, buses, and memory.

It is hard to classify or differentiate an ADL and a programming

language or a modeling language. However, there are following
requirements for a language to be classified as an ADL −

 It should be appropriate for communicating the architecture to

all concerned parties.
 It should be suitable for tasks of architecture creation,
refinement, and validation.
 It should provide a basis for further implementation, so it must
be able to add information to the ADL specification to enable
the final system specification to be derived from the ADL.
 It should have the ability to represent most of the common
architectural styles.
 It should support analytical capabilities or provide quick
generating prototype implementations.