Chapter Two

Software architecture

1
 What Is Design?

Requirements specification was about the WHAT the

system will do
Design is about the HOW the system will perform its
functions provides the overall decomposition of the
system
Allows splitting the work among a team of developers
also lays down the groundwork for achieving non-
functional requirements (Performance, maintainability,
reusability, etc.)
Takes target technology into account (e.g., kind of
2
middleware, database design, etc.)
 Levels of Design

Architectural design (also: high-level design)

Architecture - the overall structure: main modules and
their connections
 Design that covers the main use-cases of the system
Addresses the main non-functional requirements (e.g.,
throughput, reliability) hard to change
Detailed design (also: low-level design)
The inner structure of the main modules
May take the target programming language into
account
Detailed enough to be implemented in the
3
programming language
 Introduction to software architecture
 Basic Idea about Software Architecture
 Software Architecture is the way of decomposing
complex system into many sub problems or
subsystem.
The Institute of Electrical and Electronic
Engineers (IEEE) recently issued a recommended
practice regarding Software Architecture: IEEE
1471.
 These include definitions of system, stakeholder,
architect, architecture, architectural views and
4
architectural viewpoints.
IEEE 1471 defines the following key terms:
 Cont..
 System is a set of components that accomplishes a specific
function or set of functions.
Architecture is the fundamental organization of a system
embodied in its components, their relationships to each
other, and to the environment, and the principles guiding its
design and evolution’.
Architectural Description is a set of products that
document the architecture.
Architectural View is a representation of a particular
system or part of a system from a particular perspective.
Architectural Viewpoint is a template that describes how to
create and use an architectural view.
A viewpoint includes a name, stakeholders, concerns
addressed by the viewpoint, and the modeling and analytic
5
 Architectural design
An early stage of the software design process
Represents the link between specification and
design processes
Often carried out in parallel with some specification
activities
It involves identifying major system components
and their communications
May be seen as a blueprint
Nonfunctional decisions are cast and separated by
the functional requirements
All architecture is design but not all design is
6
architecture
 Cont…
A software architecture is defined as follows:
Software architecture- A model that describes the structure of a
software system in terms of computational components, the
relationships among components, and the constraints for
assembling the components.
That is, a software architecture can be defined in terms of the
following elements:
Software architecture = {components, relationships,
constraints}
These elements are defined as follows:
Components- Components are the computational elements
which collectively constitute architecture. Software
architecture is typically decomposed into subsystems, which in
7 turn may be decomposed into modules.
 Cont…
Further decomposition is also possible. (For example in an
object-oriented design, modules may be decomposed into
classes.) Examples of components include clients, services,
and persistent stores.
Relationships- Relationships are the logical connections
between architectural components. Examples of abstract
component relationships include dependency, Aggregation,
and Composition. Examples of concrete component
relationships include client-server protocols and database
protocols.
Constraints- Constraints provide conditions and restrictions for
component relationships. They connect the architecture to
system requirements. Examples of constraints include
restrictions on parameters types for communication protocols
8
and high availability requirements for fault tolerance.
 Design in Software Architecture

9
 Architectural Drivers

Design purpose
Quality attributes
Primary functionality
Architectural concerns
Constraints

10
 Design purpose

First, you need to be clear about the purpose of the

design that you want to achieve
When and why are you doing this architecture
design?
Which business goals is the organization most
concerned about at this time?
Quality attributes
Measurable or testable properties of a system that
are used to indicate how well the system satisfies
the needs of its stakeholders.
11
 Cont…
Primary functionality
Functionality is the ability of the system to do the
work for which it was intended.
Architectural concerns
Architectural concerns encompass additional
aspects that need to be considered as part of
architectural design but that are not expressed as
traditional requirements.
Constraints
A constraint is a decision over which you have
12 little or no control as an architect.
 Design Concepts
They are the building blocks from which the
structures that make up the architecture are
created.
Some of the most commonly used include
– Reference architectures
– Deployment patterns
– Architectural patterns
– Tactics
– Externally developed components

13
 Reference architectures
Some architecture are anchored on the idea of the
reference architecture, defined as follows.
Reference architecture is the set of principal design
decisions that are simultaneously applicable to multiple
related systems, typically within an application
domain, with explicitly defined points of variation.
Blueprints that provide an overall logical structure for
particular types of applications.
– Web application
– Mobile application
– Lambda architecture
14
15
Example reference architecture
for the development of web
applications from the Microsoft
Application Architecture Guide
(Key: UML)
Reference architectures
 Architectural Design Patterns
Design patterns are conceptual solutions to
recurring design problems that exist in a
defined context.
There are catalogs with patterns that
address
– Decisions at varying levels of granularity.
– Quality attributes such as security or
integration
16
 Pattern example: Layers

17
 Deployment Patterns

They provide models on how to physically structure

the system to deploy it.

Four tier deployment architecture

Microsoft Application Architecture Guide
(Key: UML)
18
 Tactics
They are techniques that architects have been using
for years to manage quality attribute response goals.
They are design decisions that influence the control
of a quality attribute response.
Externally developed components
Patterns and tactics are abstract in nature, they need
to be implemented. There are two ways to achieve
this
– code the elements obtained from tactics and patterns
– associate technologies with one or more of these
elements in the architecture.
19
 Cont…
We consider technologies to be externally developed
components, because they are not created as part of
the development project.
Products. A product (or software package) refers to a
self-contained functional piece of software that can be
integrated into the system that is being designed and
that requires only minor configuration or coding.
Example: MySQL
Application frameworks. An application framework
(or just framework) is a reusable software element,
constructed out of patterns and tactics, that provides
generic functionality addressing recurring domain and
20
quality attribute concerns across a broad range of
applications. Example: Hibernate
 Architecture Design Decisions
Platforms. A platform provides a complete
infrastructure upon which to build and execute
applications. Example: Google Cloud
Architecture Design Decisions
 Design is the process of making decisions
Experienced architects, when faced with a design
challenge, typically entertain a set of “candidate”
decisions; from this set, they choose a best candidate
and instantiate that.
 In the early stages of design, decisions focus on the
biggest, most critical choices that will have substantial
21
downstream consequences
 Cont…
Design decisions encompass every aspect of the system
under development, including:
Design decision related to system Structure-for example,
“The architectural elements should be organized and
composed exactly like this”
Design decision related to functional Behavior-for
example, “Data processing, storage, and visualization will
be performed in strict sequence.”
Design decision related to system Interaction-for example,
”Communication among all system elements will occur
only using event notifications.”
Design decision related to system’s Non-functional
properties-for example, “The system’s dependability will
be ensured by replicated processing modules.”
22
 Design decision related to system’s implementation-for
 Cont…
What is Principal?
“Principal” implies a degree of importance that
grants a design decision “architectural status”
 It implies that not all design decisions are
architectural
That is, they do not necessarily impact a system’s
architecture
How one defines “principal” will depend on what
the stakeholders define as the system goals

23
 Analogy: Architecture of Buildings

We all live in them

(We think) We know how they are built
 Requirements
 Design (blueprints)
 Construction
 Use
This is similar (though not identical) to how we
build software.

24
 Architectures in Context
Fundamental Understanding
Architecture is a set of principal design decisions about a
software system
 Three fundamental understandings of software architecture,
the recognition of which helps situate architecture with respect
to the software engineering:
 Every application has an architecture
 Every application has at least one architect
 Architecture is not a phase of development
Wrong View: Architecture as a Phase
Treating architecture as a phase denies its foundational role in
software development
More than “high-level design”
Architecture is also represented, e.g., by object code, source
25
code, …
 Software Architecture’s Elements
A software system’s architecture typically is not (and should
not be) a uniform monolith
A software system’s architecture should be a composition and
interplay of different elements
Processing
Data, also referred as information or state
 Interaction
Software architectures have 3 types of elements
Components
Connectors
Configuration

26
 Components
Elements that encapsulate processing and data in a
system’s architecture are referred to as software
components
A software component is an architectural entity that
 encapsulates a subset of the system’s functionality and/or
data
 restricts access to that subset via an explicitly defined
interface
 has explicitly defined dependencies on its required
execution context
Components typically provide application-specific
services.
 Put another way, a software component is a locus of
27
computation and state in a system.
 Cont..
The key aspect of any component is that it can be
“seen” by its users, whether human or software, from
the outside only, and via the interface it has chosen to
make public.
Software components are thus embodiments of the
software engineering principles of encapsulation,
abstraction, and modularity.
In turn, this has a number of positive implications on a
component’s composability, reusability, and
evolvability.
Components are often targeted at be the processing and
data capture needs of a particular application; that is,
28 they are said to be application-specific.
 Cont..
 Sometimes components are designed to address the
needs of multiple applications or problem domain.
For example, web servers are an integral part of any
Web-based system; one will probably download,
install, and configure an existing Web server rather
than develop one’s own.
Finally, certain software components are utilities that
are needed and can be reused across numerous
applications, without regard for the specific
application characteristics or domain. Common
examples of reusable utility components are math
29 libraries and GUI toolkits, such as Java’s Swing
 Connector
Another fundamentals aspect of software systems is
interaction among the system’s building blocks.
Software connectors are the architectural abstraction tasked
with managing component interaction.
A software connector is an architectural element tasked
with effecting and regulating interaction among
components.
 In traditional desktop software system, connectors usually
have manifest themselves as simple procedure calla or
shared data access.
Simple connectors are usually restricted to enabling the
interaction of pairs of components.
 However, as software system has become more complex,
30 so have connectors, with their own separate identities,
 Cont..
Connectors typically provide application-independent
interaction facilities
Examples:
Procedure call connectors
Shared memory connectors
Message passing connectors
Streaming connectors
Distribution connectors
Wrapper/adaptor connectors

31
 Configuration
Components and connectors are composed in a
specific way in a given system’s architecture to
accomplish that system’s objective. That composition
represents the system’s configuration, also referred as
topology
An architectural configuration, or topology, is a set of
specific associations between the components and
connectors of a software system’s architecture
A configuration may be represented as a graph
wherein nodes represent components and connectors,
and whose edges represent their associations.
32
 Why do we need software architecture?
Applications are becoming larger, more
integrated, and are implemented using a
wide variety of technologies.
The various technologies and disciplines
need to be orchestrated to ensure product
quality.
Quality attributes like reliability or usability
cannot be analyzed at the code level, but
they can be analyzed at the software
33 architectural level.
 Cont..
Software architecture has several functions, which
we describe below.
Software architecture as a means for
communication
Software architecture as a representation of early
design decisions
Software architecture as a basis for work-
breakdown structure
Software architecture as a means to evaluate
quality attributes
34
Software architecture as a unit of reuse
 Cont..
These decisions comprise of:
Selection of structural elements and their
interfaces by which the system is composed.
Behavior as specified in collaborations among
those elements.
Composition of these structural and behavioral
elements into large subsystem.
Architectural decisions align with business
objectives.
Architectural styles that guide the organization.
35
 Software Design vs. Software Architecture
Software design is a plan that gives enough detail to
implement software.
Software design emphasizes on module / component /
class level.
Software Architecture is a plan that constrains software
design to avoid known mistakes and achieve an
organization's business and technology strategy.
Software architecture is more about the design of the
entire system
Design decisions reflects the architecture of the system
that shape the system
All architecture is design, but not all design is
36
architecture.
 Architectural Pattern vs Design Pattern
Architectural Pattern „
An architectural Pattern expresses a fundamental
structural organization schema for software systems „
It provides a set of predefined subsystems, their
responsibilities, and includes rules and guidelines for
organizing the relationships between them
Design Pattern „
A design pattern provides a scheme for refining the
subsystems or components of a software system, or the
relation ships between them „
It describes a commonly-recurring structure of

37
communicating components that solves a general design
problem within a particular context
 Components of software architecture
The software architecture provides the high-level view of the
system you’re building and must cover the following aspects:
✓ Goals and philosophy of the system: The architecture
explains the goals and describes the purpose of the system, as
well as who uses it and what problem it solves.
✓Architectural assumptions and dependencies: The
architecture explains the assumption made about the
environment and about the system itself. The architecture also
explains any dependencies on other systems or on the builders
of the system.
✓Architecturally significant requirements: The architecture
points to the most significant requirements that shaped it.
✓ Key scenarios that describe critical behavior of the
system: The architecture explains the most important
38
 Cont..
✓ Packaging instructions for subsystems and
components: The architecture explains how the parts of
the system are deployed on computing platforms and how
the parts must be combined for proper functioning. The
subsystems and components are the building blocks of the
architecture.
✓ Critical subsystems and layers: The architecture
explains the different views and parts of the system and
how they relate. It also explains the most critical
subsystems in detail.
✓ References to architecturally significant design
elements: The architecture describes the most prominent
and significant parts of the design.
✓ Critical system interfaces: The architecture describes
39
 Features
Every System has its own architecture but
they are not identical.
Software architecture and its description are
different.
The different stakeholders are     
 Users of the System     
Acquirers of the System     
Developers of the System     
Maintainers of the System

40
 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
Some of the other goals are as follows:
Expose the structure of the system, but hide its
implementation.
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.
41Improve quality and functionality offered by the 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
42 and poor communication among stakeholders.
 The Role of the Architect
The Role of the Architect

requirements solutions
client,
architect developers
users

assess creates assess

visualises prescribes

appearance, architectural construction,

behaviour design co-operation

43
 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
44
tradeoffs among them.
 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
Expert on available technologies that helps in the
implementation of the system.
Coordinate the selection of programming
language, framework, platforms, databases, etc.
45
 Cont..
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.
46  Protect the team members from external forces that
 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
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
47
 Quality Attributes
Quality is a measure of excellence or the state of being
free from deficiencies or defects.
Quality attributes are system properties that are separate
from the functionality of the system.
Implementing quality attributes makes it is 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 follows:
Static Quality Attributes
48
Dynamic Quality Attributes
 Cont..
Static Quality Attributes
Reflect the structure of system and organization, directly
related to architecture, design, 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 and also the configuration, deployment
parameters, environment, and platform.
They are visible to the end-user and exist at runtime, e.g.:
49 throughput, robustness, scalability, etc.
Common Quality Attributes

Design Qualities
Conceptual Integrity :-Defines the consistency and
coherence of the overall design. This includes the way
components or modules are designed
Maintainability :-Ability of the system to undergo
changes with a degree of ease.
Reusability:-Defines the capability for components and
subsystems to be suitable for use in other applications
Interoperability:-Ability of a system or different
systems to operate successfully by communicating and
exchanging
50
 Run-time Qualities
Interoperability:-Ability of a system or different systems
to operate successfully by communicating and
exchanging information
Manageability :-Defines how easy it is for system
administrators to manage the application
Reliability :-Ability of a system to remain operational
over time
Scalability :-Ability of a system to either handle increases
in load without impact on the performance of the system
Security:- Capability of a system to prevent malicious or
accidental actions outside of the designed usages
Performance:-Indication of the responsiveness of a
system to execute any action within a given time interval.
51
 Cont..
System Qualities
Supportability:-Ability of the system to provide
information 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
User Qualities
Usability :-Defines how well the application meets the
requirements of the user and consumer by being intuitive
Architecture Quality
Correctness:-Accountability for satisfying all the

52
requirements of the system.
 Cont..
Non-runtime Quality
Portability:-Ability of the system to run under different
computing environment.
Integrality:-Ability to make separately developed
components of the system work correctly together.
Modifiability:-Ease with which each software system can
accommodate changes to its software.
Business quality attributes
Cost and schedule:-Cost of the system with respect to
time to market, expected project lifetime & utilization of
legacy
Marketability:-Use of system with respect to market
competition.
53
 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 generates 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 channel, persistent storage,
processes etc.
Response:- An activity undertaken after the arrival of stimulus
54 such as detect faults, recover from fault, disable event source
 Thank You!
Q?

55
END