Topic 2: Software Architecture

Introduction
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.
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.

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
Design Qualities Maintainability
a 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
Interoperability
exchanging information with other external
systems written and run by external parties.
Defines how easy it is for system
Manageability
administrators to manage the application.
Ability of a system to remain operational over
Reliability
Run-time Qualities time.
Ability of a system to either handle the load
increase without impacting the performance
Scalability
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
Performance to execute any action within a given time
interval.
Defines the proportion of time that the system
is functional and working. It can be measured
Availability
as a percentage of the total system downtime
over a predefined period.
Ability of the system to provide information
Supportability helpful for identifying and resolving issues
System Qualities when it fails to work correctly.
Measure of how easy it is to create test criteria
Testability
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
Architecture Quality Correctness
requirements of the system.
Ability of the system to run under different
Portability
computing environment.
Ability to make separately developed
Non-runtime Quality Integrality components 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
Cost and schedule market, expected project lifetime &
Business quality attributes utilization of legacy.
Use of system with respect to market
Marketability
competition.

Key Principles
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.

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.

Architecture Models
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.