SOFTWARE ARCHITECTURE AND DESIGN PATTERNS

UNIT-I
UNIT-I:
Envisioning Architecture: The Architecture Business Cycle, What is Software Architecture,
Architectural patterns, reference models, reference architectures, architectural structures and views

Envisioning Architecture:
1. The Architecture Business Cycle
1.1 Where Do Architectures Come From?
Architecture is the result of a set of business and technical decisions. There are many influences at work
in its design, and the realization of these influences will change depending on the environment in which
the architecture is required to perform.
An architect designing a system for which the real-time deadlines are believed to be tight will make one
set of design choices; the same architect, designing a similar system in which the deadlines can be easily
satisfied, will make different choices.

ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS

Many people and organizations are interested in the construction of a software system. We call these
stakeholders: The customer, the end users, the developers, the project manager, the maintainers, and even
those who market the system are a few examples. Stakeholders have different concerns that they wish the
system to guarantee or optimize, including things as diverse as providing a certain behavior at runtime,
performing well on a particular piece of hardware, being easy to customize, achieving short time to
market or low cost of development, gainfully employing programmers who have a particular specialty, or
providing a broad range of functions. Figure.1 shows the architect receiving helpful stakeholder
"suggestions."

Figure 1.Influence of stakeholders on the architect

IV B. Tech I Semester (R16) 2019-20 1

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I

ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION

In addition to the organizational goals expressed through requirements, architecture is influenced by the
structure or nature of the development organization. For example, if the organization has an abundance of
idle programmers skilled in client-server communications, then client-server architecture might be the
approach supported by management. If not, it may well be rejected. Staff skills are one additional
influence, but so are the development schedule and budget.

There are three classes of influence that come from the developing organization: immediate business,
long-term business, and organizational structure.

ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE OF

THE ARCHITECTS
If the architects for a system have had good results using a particular architectural approach, such as
distributed objects or implicit invocation, chances are that they will try that same approach on a new
development effort. Conversely, if their prior experience with this approach was disastrous, the architects
may be reluctant to try it again. Architectural choices may also come from an architect's education and
training, exposure to successful architectural patterns, or exposure to systems that have worked
particularly poorly or particularly well. The architects may also wish to experiment with an architectural
pattern or technique learned from a book (such as this one) or a course.

ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT

A special case of the architect's background and experience is reflected by the technical environment. The
environment that is current when architecture is designed will influence that architecture. It might include
standard industry practices or software engineering techniques prevalent in the architect's professional
community. It is a brave architect who, in today's environment, does not at least consider a Web-based,
object-oriented, middleware-supported design for an information system.

RAMIFICATIONS OF INFLUENCES ON ARCHITECTURE

Influences on architecture come from a wide variety of sources. Some are only implied, while others are
explicitly in conflict. Almost never are the properties required by the business and organizational goals
consciously understood, let alone fully articulated. Indeed, even customer requirements are seldom
documented completely, which means that the inevitable conflict among different stakeholders' goals has
not been resolved.

A business manages this cycle to handle growth, to expand its enterprise area, and to take advantage of
previous investments in architecture and system building. Figure 2 shows the feedback loops. Some of the
feedback comes from the architecture itself, and some comes from the system built from it. The
architecture affects the structure of the developing organization. An architecture prescribes a structure for
a system; as we will see, it particularly prescribes the units of software that must be implemented (or
otherwise obtained) and integrated to form the system. These units are the basis for the development
project's structure. Teams are formed for individual software units; and the development, test, and
integration activities all revolve around the units. Likewise, schedules and budgets allocate resources in
chunks corresponding to the units. If a company becomes adept at building families of similar systems, it
will tend to invest in each team by nurturing each area of expertise. Teams become embedded in the
organization's structure. This is feedback from the architecture to the developing organization.

IV B. Tech I Semester (R16) 2019-20 2

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I

Figure 2. The Architecture Business Cycle

1.2 Software Processes and the Architecture Business Cycle

Software process is the term given to the organization, reutilization, and management of software
development activities. What activities are involved in creating software architecture, using that
architecture to realize a design, and then implementing or managing the evolution of a target system or
application? These activities include the following:

 Creating the business case for the system

 Understanding the requirements
 Creating or selecting the architecture
 Documenting and communicating the architecture
 Analyzing or evaluating the architecture
 Implementing the system based on the architecture
 Ensuring that the implementation conforms to the architecture

ARCHITECTURE ACTIVITIES
As indicated in the structure of the ABC, architecture activities have comprehensive feedback
relationships with each other. We will briefly introduce each activity in the following subsections.
Creating the Business Case for the System

Creating a business case: is broader than simply assessing the market need for a system. It is an
important step in creating and constraining any future requirements. How much should the product cost?
What is its targeted market? What is its targeted time to market? These are all questions that must involve
the system's architects.
Understanding the Requirements: There are a variety of techniques for eliciting requirements from the
stakeholders. For example, object-oriented analysis uses scenarios, or "use cases" to embody
requirements. Safety-critical systems use more rigorous approaches, such as finite-state-machine models
or formal specification languages.

IV B. Tech I Semester (R16) 2019-20 3

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
Communicating the Architecture
For the architecture to be effective as the backbone of the project's design, it must be communicated
clearly and unambiguously to all of the stakeholders. Developers must understand the work assignments it
requires of them, testers must understand the task structure it imposes on them, management must
understand the scheduling implications it suggests, and so forth. Toward this end, the architecture's
documentation should be informative, unambiguous, and readable by many people with varied
backgrounds.
Analyzing or Evaluating the Architecture
In any design process there will be multiple candidate designs considered. Some will be rejected
immediately. Others will contend for primacy. Choosing among these competing designs in a rational
way is one of the architect's greatest challenges.

1.3 What Makes a 'Good' Architecture?

If it is true that, given the same technical requirements for a system, two different architects in different
organizations will produce different architectures, how can we determine if either one of them is the right
one? We divide our observations into two clusters: process recommendations and product (or structural)
recommendations. Our process recommendations are as follows:

 The architecture should be the product of a single architect or a small group of architects with
an identified leader. The architect (or architecture team) should have the functional
requirements for the system and an articulated, prioritized list of quality attributes (such as
security or modifiability) that the architecture is expected to satisfy.
 The architecture should be well documented, with at least one static view and one dynamic
view, using an agreed-on notation that all stakeholders can understand with a minimum of
effort.
 The architecture should be circulated to the system's stakeholders, who should be actively
involved in its review.
 The architecture should be analyzed for applicable quantitative measures (such as maximum
throughput) and formally evaluated for quality attributes before it is too late to make changes
to it.
 The architecture should lend itself to incremental implementation via the creation of a
"skeletal" system in which the communication paths are exercised but which at first has
minimal functionality.

2. What is Software Architecture?

The system consists of four elements, Prop Loss Model (MODP), Reverb Model (MODR), and Noise
Model (MODN)?might have more in common with each other than with the fourth model, Control
Process (CP). All of the elements apparently have some sort of relationship with each other, since the
diagram is fully connected. The models are described in figure 3.

Figure 3: Typical, but uninformative, presentation of software architecture

IV B. Tech I Semester (R16) 2019-20 4

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
3. Architectural patterns, Reference models and Reference architectures
An architectural pattern is a description of element and relation types together with a set of constraints
on how they may be used. A pattern can be thought of as a set of constraints on architecture? On the
element types and their patterns of interaction? And these constraints define a set or family of
architectures that satisfy them. For example, client-server is a common architectural pattern. Client and
server are two element types, and their coordination is described in terms of the protocol that the server
uses to communicate with each of its clients. Use of the term client-server implies only that multiple
clients exist; the clients themselves are not identified, and there is no discussion of what functionality,
other than implementation of the protocols, has been assigned to any of the clients or to the server.

A reference model is a division of functionality together with data flow between the pieces. A reference
model is a standard decomposition of a known problem into parts that cooperatively solve the problem.

Reference architecture is a reference model mapped onto software elements (that cooperatively
implement the functionality defined in the reference model) and the data flows between them. Whereas a
reference model divides the functionality, reference architecture is the mapping of that functionality onto
system decomposition. The relationship among these design elements is shown in Figure 4.

Figure 4: The relationships of design elements

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.

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, as documented by and used by some system stakeholders. These
terms are often used interchangeably, but we will adhere to these definitions.

Architectural structures can by and large be divided into three groups, depending on the broad nature of
the elements they show.

Module structures: Here the elements are modules, which are units of implementation. Modules
represent a code-based way of considering the system. They are assigned areas of functional
responsibility. There is less emphasis on how the resulting software manifests itself at runtime.

Component-and-connector structures: Here the elements are runtime components (which are the
principal units of computation) and connectors (which are the communication vehicles among
components). Component-and-connector structures help answer questions such as what are the major
executing components and how do they interact? What are the major shared data stores?

IV B. Tech I Semester (R16) 2019-20 5

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
Allocation structures: Allocation structures show the relationship between the software elements and
the elements in one or more external environments in which the software is created and executed. They
answer questions such as what processor does each software element execute on? These three structures
correspond to the three broad types of decision that architectural design involves:

 How is the system to be structured as a set of code units (modules)?

 How is the system to be structured as a set of elements that have runtime behavior
(components) and interactions (connectors)?
 How is the system to relate to non-software structures in its environment (i.e., CPUs, file
systems, networks, development teams, etc.)?

SOFTWARE STRUCTURES
Some of the most common and useful software structures are shown in Figure 5. These are described in
the following sections.

Figure 5: Common software architecture structures

The units are modules related to each other by the "is a sub module of
Decomposition " relation, showing how larger modules are decomposed into smaller
ones recursively until they are small enough to be easily understood
The units of this important but overlooked structure are also modules,
Uses
or procedures or resources on the interfaces of modules.
Module
When the uses relations in this structure are carefully controlled in a
Layered particular way, a system of layers emerges, in which a layer is a
coherent set of related functionality.
The module units in this structure are called classes. The relation is
Class
"inherits-from" or "is-an-instance-of."
If the system is built as a group of cooperating clients and servers, this
Client-server
is a good component-and-connector structure to illuminate.
Component- This component-and-connector structure allows the architect to
and- Concurrency determine opportunities for parallelism and the locations where
Connector resource contention may occur.
Like all component-and-connector structures, this one is orthogonal to
Process
the module-based structures and deals with the dynamic aspects of a

IV B. Tech I Semester (R16) 2019-20 6

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
running system.
This structure comprises components and connectors that create, store,
Shared data
and access persistent data.
Work This structure assigns responsibility for implementing and integrating
assignment the modules to the appropriate development teams.
The deployment structure shows how software is assigned to
Allocation Deployment
hardware-processing and communication elements.
This structure shows how software elements (usually modules) are
Implementation mapped to the file structure(s) in the system's development,
integration, or configuration control environments.

IV B. Tech I Semester (R16) 2019-20 7

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
Creating Architecture: Quality Attributes, Achieving qualities, Architectural styles and patterns,
designing the Architecture, Documenting software architectures, Reconstructing Software Architecture

4. Quality Attributes

Architecture and Quality Attributes

Achieving quality attributes must be considered throughout design, implementation, and deployment. No
quality attribute is entirely dependent on design, nor is it entirely dependent on implementation or
deployment. Satisfactory results are a matter of getting the big picture (architecture) as well as the details
(implementation) correct.

Architecture is critical to the realization of many qualities of interest in a system, and these qualities
should be designed in and can be evaluated at the architectural level. Architecture, by itself, is unable to
achieve qualities. It provides the foundation for achieving quality, but this foundation will be to no avail if
attention is not paid to the details. We will examine the following three classes:

 Qualities of the system. We will focus on availability, modifiability, performance, security,

testability, and usability.
 Business qualities (such as time to market) that are affected by the architecture.
 Qualities, such as conceptual integrity, that is about the architecture itself although they indirectly
affect other qualities, such as modifiability.

Quality Attributes Scenarios

A quality attribute scenario is a quality-attribute-specific requirement. It consists of six parts.
 Source of stimulus: This is some entity (a human, a computer system, or any other actuator) that
generated the stimulus.
 Stimulus: The stimulus is a condition that needs to be considered when it arrives at a system.
 Environment: The stimulus occurs within certain conditions. The system may be in an overload
condition or may be running when the stimulus occurs, or some other condition may be true.
 Artifact: Some artifact is stimulated. This may be the whole system or some pieces of it.
 Response: The response is the activity undertaken after the arrival of the stimulus.
 Response measure: When the response occurs, it should be measurable in some fashion so that
the requirement can be tested.

Figure 6: shows the parts of a quality attribute scenario.

IV B. Tech I Semester (R16) 2019-20 8

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
Availability Scenario
A general scenario for the quality attribute of availability, for example, is shown in Figure 4.2. Its six
parts are shown, indicating the range of values they can take. From this we can derive concrete, system-
specific, scenarios. Not every system-specific scenario has all of the six parts. The parts that are necessary
are the result of the application of the scenario and the types of testing that will be performed to determine
whether the scenario has been achieved.

Figure 7: Availability general scenarios

Modifiability Scenario
A sample modifiability scenario is "A developer wishes to change the user interface to make a
screen's background color blue. This change will be made to the code at design time. It will take
less than three hours to make and test the change and no side effect changes will occur in the
behavior." Figure 8 illustrates this sample scenario.

Figure 8: Sample modifiability scenario

IV B. Tech I Semester (R16) 2019-20 9

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
5. Achieving qualities
The achievement of these qualities relies on fundamental design decisions. We will examine these design
decisions, which we call tactics. A tactic is a design decision that influences the control of a quality
attribute response. A system design consists of a collection of decisions. Some of these decisions help
control the quality attribute responses; others ensure achievement of system functionality.

Figure 9: Tactics are intended to control responses to stimuli

We organize the tactics for each system quality attribute as a hierarchy, but it is important to understand
that each hierarchy is intended only to demonstrate some of the tactics, and that any list of tactics is
necessarily incomplete.

5.1 Availability Tactics: A failure occurs when the system no longer delivers a service that is consistent
with its specification; this failure is observable by the system's users. A fault (or combination of faults)
has the potential to cause a failure. Recall also that recovery or repair is an important aspect of
availability. We first consider fault detection. We then consider fault recovery and finally, briefly, fault
prevention.

Figure 10: Goal of availability tactics

Figure 11: Summary of availability tactics

IV B. Tech I Semester (R16) 2019-20 10

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I

5.2 Modifiability Tactics: We organize the tactics for modifiability in sets according to their goals. One
set has as its goal reducing the number of modules that are directly affected by a change. We call this set
"localize modifications." A second set has as its goal limiting modifications to the localized modules.
We use this set of tactics to "prevent the ripple effect." Implicit in this distinction is that there are
modules directly affected (those whose responsibilities are adjusted to accomplish the change) and
modules indirectly affected by a change (those whose responsibilities remain unchanged but whose
implementation must be changed to accommodate the directly affected modules). A third set of tactics has
as its goal controlling deployment time and cost. We call this set "defer binding time."

Figure 12: Goal of modifiability tactics

Figure 13: Summary of modifiability tactics

IV B. Tech I Semester (R16) 2019-20 11

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
5.3 Performance Tactics: The event can be single or a stream and is the trigger for a request to perform
computation. It can be the arrival of a message, the expiration of a time interval, the detection of a
significant change of state in the system's environment, and so forth. The system processes the events and
generates a response. Performance tactics control the time within which a response is generated.

Figure 14: Goal of performance tactics

Figure 15: Summary of performance tactics

IV B. Tech I Semester (R16) 2019-20 12

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
5.4 Security Tactics: Tactics for achieving security can be divided into those concerned with resisting
attacks, those concerned with detecting attacks, and those concerned with recovering from attacks. All
three categories are important. Using a familiar analogy, putting a lock on your door is a form of resisting
an attack, having a motion sensor inside of your house is a form of detecting an attack, and having
insurance is a form of recovering from an attack.

Figure 16: Goal of security tactics

Figure 17: Summary of tactics for security

IV B. Tech I Semester (R16) 2019-20 13

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
5.5 Testability Tactics: The goal of tactics for testability is to allow for easier testing when an increment
of software development is completed.

Figure 18: Goal of testability tactics

Figure 19: Summary of testability tactics

IV B. Tech I Semester (R16) 2019-20 14

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
5.6 Usability Tactics: Two types of tactics support usability, each intended for two categories of "users."
The first category, runtime, includes those that support the user during system execution. The second
category is based on the iterative nature of user interface design and supports the interface developer at
design time. It is strongly related to the modifiability tactics already presented.

Figure 20: Goal of runtime usability tactics

Figure 21: Summary of runtime usability tactics

IV B. Tech I Semester (R16) 2019-20 15

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
6. Architectural styles and patterns,
An architectural pattern in software, also known as an architectural style, is analogous to an architectural
style in buildings, such as Gothic or Greek revival or Queen Anne. It consists of a few key features and
rules for combining them so that architectural integrity is preserved. An architectural pattern is
determined by:

 A set of element types (such as a data repository or a component that computes a mathematical
function).
 A topological layout of the elements indicating their interrelation-ships.
 A set of semantic constraints
 A set of interaction mechanisms

In response, a number of recurring architectural patterns, their properties, and their benefits have been
cataloged. One such catalog is illustrated in Figure 5.22

.
Figure 22: A small catalog of architectural patterns, organized by is-a relations

IV B. Tech I Semester (R16) 2019-20 16

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
7. Designing the Architecture,
7.1 Architecture in the Life Cycle: Any organization that embraces architecture as a foundation for its
software development processes needs to understand its place in the life cycle. Several life-cycle models
exist in the literature, but one that puts architecture squarely in the middle of things is the Evolutionary
Delivery Life Cycle model shown in Figure 23. The intent of this model is to get user and customer
feedback and iterate through several releases before the final release. The model also allows the adding of
functionality with each iteration and the delivery of a limited version once a sufficient set of features has
been developed.

Figure 23: Evolutionary Delivery Life Cycle

.

7.2 Designing the Architecture: In this section we describe a method for designing architecture to satisfy
both quality requirements and functional requirements. We call this method Attribute-Driven Design
(ADD). ADD takes as input a set of quality attribute scenarios and employs knowledge about the relation
between qualities attribute achievement and architecture in order to design the architecture. The ADD
method can be viewed as an extension to most other development methods, such as the Rational Unified
Process. The Rational Unified Process has several steps that result in the high-level design of an
architecture but then proceeds to detailed design and implementation. Incorporating ADD into it involves
modifying the steps dealing with the high-level design of the architecture and then following the process
as described by Rational.

ADD is an approach to defining a software architecture that bases the decomposition process on the
quality attributes the software has to fulfill. It is a recursive decomposition process where, at each stage,
tactics and architectural patterns are chosen to satisfy a set of quality scenarios and then functionality is

IV B. Tech I Semester (R16) 2019-20 17

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
allocated to instantiate the module types provided by the pattern. ADD is positioned in the life cycle after
requirements analysis and, as we have said, can begin when the architectural drivers are known with some
confidence.

The output of ADD is the first several levels of a module decomposition view of architecture and other
views as appropriate. Not all details of the views result from an application of ADD; the system is
described as a set of containers for functionality and the interactions among them. This is the first
articulation of architecture during the design process and is therefore necessarily coarse grained.
Nevertheless, it is critical for achieving the desired qualities, and it provides a framework for achieving
the functionality. The difference between an architecture resulting from ADD and one ready for
implementation rests in the more detailed design decisions that need to be made. These could be, for
example, the decision to use specific object-oriented design patterns or a specific piece of middleware that
brings with it many architectural constraints. The architecture designed by ADD may have intentionally
deferred this decision to be more flexible.

8. Documenting software architectures: Documenting the architecture is the crowning step to crafting
it. Even a perfect architecture is useless if no one understands it or (perhaps worse) if key stakeholders
misunderstand it. If you go to the trouble of creating a strong architecture, you must describe it in
sufficient detail, without ambiguity, and organized in such a way that others can quickly find needed
information. Otherwise, your effort will have been wasted because the architecture will be unusable.

This principle is useful because it breaks the problem of architecture documentation into more tractable
parts, which provide the structure for the remainder of this chapter:

 Choosing the relevant views

 Documenting a view
 Documenting information that applies to more than one view

Software architecture views are divided views into these three groups: module, component-and-connector
(C&C), and allocation. This three-way categorization reflects the fact that architects need to think about
their software in at least three ways at once:

 How it is structured as a set of implementation units

 How it is structured as a set of elements that have runtime behavior and interactions
 How it relates to non-software structures in its environment

There is no industry-standard template for documenting a view, but the seven-part standard organization
that we suggest in this section has worked well in practice.
1. Primary presentation
2. Element catalog
3. Context diagram
4. Variability guide
5. Architecture background
6. Glossary of terms
7. Other information

IV B. Tech I Semester (R16) 2019-20 18

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I

Figure 24: The seven parts of a documented view

IV B. Tech I Semester (R16) 2019-20 19

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I
9. Reconstructing Software Architecture: Architecture reconstruction has been used in a variety of
projects ranging from MRI scanners to public telephone switches and from helicopter guidance systems to
classified NASA systems. It has been used

 To redocument architectures for physics simulation systems.

 To understand architectural dependencies in embedded control software for mining machinery.
 To evaluate the conformance of a satellite ground system's implementation to its reference
architecture.
 To understand different systems in the automotive industry.

Reconstruction Activities
Software architecture reconstruction comprises the following activities, carried out iteratively:

 Information extraction. The purpose of this activity is to extract information from various
sources.
 Database construction. Database construction involves converting this information into a standard
form such as the Rigi Standard Form (a tuple-based data format in the form of relationship
<entity1> <entity2>) and an SQL-based database format from which the database is created.
 View fusion. View fusion combines information in the database to produce a coherent view of the
architecture.
 Reconstruction. The reconstruction activity is where the main work of building abstractions and
various representations of the data to generate an architecture representation takes place.

Figure 25: Architecture reconstruction activities.

IV B. Tech I Semester (R16) 2019-20 20

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-I

Frequently Asked Questions

1. Write a short note on Architecture Business Cycle (ABC)?

2. Explain in detail about software processes used in ABC, and explain what makes a good
architecture?
3. Define reference model, reference architecture and architectural patterns, views?
4. Briefly discuss about the list of quality attributes using quality attribute scenarios with
examples?
5. Explain how to achieve qualities in attributes using Tactics; explain about any two
attributes with examples?
6. Write a short note on architectural styles and patterns?
7. What are the phases of architectures in life cycle?
8. What are the parts of documentation, and how to reconstruct software architecture?

IV B. Tech I Semester (R16) 2019-20 21