UNIT-1

THE ARCHITECTURE BUSINESS CYCLE

Software architecture is a result of technical, business and social influences. Its existence in
turn affects the technical, business and social environments that subsequently influence
future architectures. We call this cycle of influences, from environment to the architecture
and back to the environment, the Architecture Business Cycle (ABC).

Some of the feedback comes from the architecture itself, and some comes from the system
built from it. Working of architecture business cycle:

1) The architecture affects the structure of the developing organization.

Teams are formed for individual software units; and the development, test, and integration
activities around the units. Teams become embedded in the organization’s structure. This is
feedback from the architecture to the developing organization.

2) The architecture can affect the goals of the developing organization.

The architecture can provide opportunities for the efficient production and deployment of
the similar systems, and the organization may adjust its goals to take advantage of its
newfound expertise to plumb the market. This is feedback from the system to the
developing organization and the systems it builds.

3) The architecture can affect customer requirements

Giving the customer the opportunity to receive a system in a more reliable, timely and
economical manner than if the subsequent system were to be built from scratch.

4) The process of system building will affect the architect’s experience with subsequent
systems by adding to the corporate experience base.

5) A few systems will influence and actually change the software engineering culture. i.e,
The technical environment in which system builders operate and learn.

Rajasekhar, SEAT Page 1

SOFTWARE PROCESSES AND THE ARCHITECTURE BUSINESS CYCLE /ARCHITECTURAL
ACTIVITIES:
Software process is the term given to the organization, ritualization, and management of
software development activities.
The various activities involved in creating software architecture are:
1. Creating the business case for the system

o How much should the product cost?

o What is its targeted market?
o What is its targeted time to market?
o Will it need to interface with other systems?

2. Understanding the requirements

There are a variety of techniques for eliciting requirements from the stakeholders.
For ex:
 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.
 Another technique that helps us understand requirements is the creation of
prototypes.

3. Creating or selecting the architecture

 In the landmark book The Mythical Man-Month, Fred Brooks argues forcefully and
eloquently that conceptual integrity is the key to sound system design and that
conceptual integrity can only be had by a small number of minds coming together
to design the system's architecture.

4. Documenting and communicating the architecture

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

5. Analyzing or evaluating the architecture

 Choosing among multiple competing designs in a rational way is one of the

architect’s greatest challenges.
 Use scenario-based techniques or architecture tradeoff analysis method (ATAM)
or cost benefit analysis method (CBAM).

6. Implementing the system based on the architecture

 This activity is concerned with keeping the developers faithful to the

structures and interaction protocols constrained by the architecture.

7. Ensuring that the implementation conforms to the architecture

 Finally, when an architecture is created and used, it goes into a maintenance
phase.

Rajasekhar, SEAT Page 2

WHAT MAKES A “GOOD” ARCHITECTURE?
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.
1. Process recommendations are as follows:
 The architecture should be the product of a single architect or a small group of
architects
 The architect (or architecture team) should have the functional requirements for the
system and an articulated.
 The architecture should be well documented.
 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).
 The architecture should lend itself to incremental implementation via the creation of
a “skeletal”.
 The architecture should result in a specific (and small) set of resource contention
areas.
2. Product (structural) recommendations are as follows:
 The architecture should feature well-defined modules whose functional
responsibilities are allocated on the principles of information hiding and separation
of concerns.
 Each module should have a well-defined interface that encapsulates or “hides”
changeable aspects from other software that uses its facilities.
 Quality attributes should be achieved using well-known architectural tactics specific
to each attribute.
 The architecture should never depend on a particular version of a commercial
product or tool.
 Modules that produce data should be separate from modules that consume data.
This tends to increase modifiability.
 For parallel processing systems, the architecture should feature well-defined
processors .
 The architecture should feature a small number of simple interaction patterns.
ARCHITECUTURAL INFLUENCES (Influence Of Software Architecture On Organization)
Architecture is the result of a set of business and technical decisions. There are many
influences at work in its design.
Architectures are influenced by:
1.Stackholders : Each stakeholder has different concerns and goals
2. Development organization: Immediate business, long-term business, and organizational
3. Architects experience and background: Repeat good results, avoid duplicating

Rajasekhar, SEAT Page 3

4. The technical environment: Standard industry practices or common Software Engineering
techniques.

1.ARCHITECTURES ARE INFLUENCED BY SYSTEM STAKEHOLDERS

 Many people and organizations interested in the construction of a software system
are referred to as stakeholders. E.g. customers, end users, developers, project
manager etc.
 Figure below shows the architect receiving helpful stakeholder “suggestions”.
 The underlying problem, of course, is that each stakeholder has different concerns
and goals, some of which may be contradictory.
 The reality is that the architect often has to fill in the blanks and mediate the
conflicts.

Figure-1
2.ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATIONS.
 Architecture is influenced by the structure or nature of the development
organization.
 There are three classes of influence that come from the developing organizations:
immediate business, long-term business and organizational structure.
 An organization may have an immediate business investment in certain assets, such
as existing architectures and the products based on them.
 An organization may wish to make a long-term business investment in an
infrastructure to pursue strategic goals and may review the proposed system as one
means of financing and extending that infrastructure.
 The organizational structure can shape the software architecture.

3.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.
 Architectural choices may also come from an architect’s education and training.
 The architects may also wish to experiment with an architectural pattern or
technique learned from a book or a course.

4.ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT

Rajasekhar, SEAT Page 4

  A special case of the architect’s background and experience is reflected by the
technical environment.
 The environment that is current when an architecture is designed will influence that
architecture.
 It might include standard industry practices or software engineering prevalent in the
architect’s professional community.
Consequences Of The Various Influences On Architecture:
 Architects need to know and understand the nature and sources of the project. Architect
should also consider the priority of constraints on the project.
 Customer requirements are often not complete or well documented. The below figure
(Figure-1)shows influences on the architecture:
 Influences on architecture come from a wide variety of sources. Some are only
implied, while others are explicitly in conflict.
 Architects need to know and understand the nature, source, and priority of
constraints on the project as early as possible.
 Therefore, they must identify and actively engage the stakeholders to solicit their
needs and expectations.
 Architects are influenced by the requirements for the product as derived from its
stakeholders, the structure and goals of the developing organization, the available
technical environment, and their own background and experience.

ARCHITECTURES AFFECT THE FACTORS THAT INFLUENCE THEM:

1. The architecture affects the structure of the developing organization.
2. The architecture can affect the goals of the developing organization. A successful
system is built from it.
3. The architecture can affect customer requirements.
4. The architecture will affect the architectures of future systems.
5. The architecture may affect the software engineering culture.

WHAT IS SOFTWARE ARCHITECTURE AND WHAT IT ISN'T ?

Figure-2 , taken from a system description for an underwater acoustic simulation,

purports to describe that system's "top-level architecture" and is precisely the kind of
diagram most often displayed to help explain an architecture. Exactly what can we tell
from it?

The system consists of four elements:

Rajasekhar, SEAT Page 5
  Three of the elements— Prop Loss Model (MODP), Reverb Model (MODR), and Noise
Model (MODN)— might have more in common with each other than with the fourth
—Control Process (CP).
 All of the elements apparently have some sort of relationship with each other, since
the diagram is fully connected.
The above diagram does not show a software architecture. We now define what does
constitute a software architecture:
Def: The software architecture of a program or computing system is the structure or
structures of the system, which comprise software elements, the externally visible
properties of those elements, and the relationships among them.
Let's look at some of the implications of this definition in more detail:
 Architecture defines software elements
 The definition makes clear that systems can and do comprise more than one
structure and that no one structure can irrefutably claim to be the architecture.
 The definition implies that every computing system with software has a software
architecture.
 The behavior of each element is part of the architecture . Such behavior is what
allows elements to interact with each other, which is clearly part of the
architecture.
 The definition is indifferent as to whether the architecture for a system is a good one
or a bad one.
NOTE: Is this an architecture? What can we not tell from the diagram?
 What is the nature of the elements?
What is the significance of their separation? Do they run on separate processors? Do
they run at separate times? Do the elements consist of processes, programs, or both? Do
they represent ways in which the project labor will be divided, or do they convey a
sense of runtime separation? Are they objects, tasks, functions, processes, distributed
programs, or something else?
 What are the responsibilities of the elements?
What is it they do? What is their function in the system?
 What is the significance of the connections?
Do the connections mean that the elements communicate with each other, control each
other, send data to each other, use each other, invoke each other, synchronize with each
other, share some information-hiding secret with each other, or some combination of
these or other relations? What are the mechanisms for the communication? What
information flows across the mechanisms, whatever they may be?
 What is the significance of the layout?
Why is CP on a separate level? Does it call the other three elements, and are the others not
allowed to call it? Does it contain the other three in an implementation unit sense? Or is
there simply no room to put all four elements on the same row in the diagram?

OTHER POINTS OF VIEW

The study of software architecture is an attempt to abstract the commonalities inherent
in system design, and as such it must account for a wide range of activities, concepts,
methods, approaches, and results.
Architecture is high-level design. Other tasks associated with design are not
architectural, such as deciding on important data structures that will be encapsulated.

Architecture is the overall structure of the system. The different structures provide
the critical engineering leverage points to imbue a system with the quality attributes
Rajasekhar, SEAT Page 6
that will render it a success or failure. The multiplicity of structures in an architecture
lies at the heart of the concept.
Architecture is the structure of the components of a program or system, their
interrelationships, and the principles and guidelines governing their design and
evolution over time. Any system has an architecture that can be discovered and
analyzed independently of any knowledge of the process by which the architecture was
designed or evolved.
Architecture is components and connectors. Connectors imply a runtime mechanism
for transferring control and data around a system. When we speak of "relationships"
among elements, we intend to capture both runtime and non-runtime relationships.

ARCHITECTURAL PATTERNS, REFERENCE MODELS & 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.
For ex: 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.
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.
A reference architecture is a reference model mapped onto software elements and the
data flows between them.

Relationship 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.
 Module structures allow us to answer questions such as :

Rajasekhar, SEAT Page 7

  What is the primary functional responsibility assigned to each module?
 What other software elements is a module allowed to use?
 What other software does it actually use?
 What modules are related to other modules by generalization or specialization (i.e.,
inheritance) relationships?

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
 What are the major executing components and how do they interact?
 What are the major shared data stores?
 Which parts of the system are replicated?
 How does data progress through the system?
 What parts of the system can run in parallel?
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:
 what processor does each software element execute on?
 What is the assignment of software elements to development teams?
The above 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.)?

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

Allocation
Allocation structures include the following structures
1. Deployment:
This view allows an engineer to reason about performance, data integrity,
availability, and security .
2. Implementation:
This is critical for the management of development activities and builds processes.
3. Work assignment:
This structure assigns responsibility for implementing and integrating the modules to
the appropriate development teams.
RELATING STRUCTURES TO EACH OTHER
Each of these structures provides a different perspective and design handle on a system,
and each is valid and useful in its own right. In general, mappings between structures
are many to many. Individual structures bring with them the power to manipulate one
or more quality attributes. They represent a powerful separation-of-concerns approach
for creating the architecture.
WHICH STRUCTURES TO CHOOSE?
Kruchten's four views follow:
Logical. The elements are "key abstractions," which are manifested in the object-
oriented world as objects or object classes. This is a module view. 
Process. This view addresses concurrency and distribution of functionality. It is a
component-and-connector view. 
Development. This view shows the organization of software modules, libraries,
subsystems, and units of development. It is an allocation view, mapping software to the
development environment. 
Physical. This view maps other elements onto processing and communication nodes
and is also an allocation vi

WHY IS SOFTWARE ARCHITECTURE IMPORTANT?

There are fundamentally three reasons for software architecture’s importance from a
technical perspective.
Communication among stakeholders: software architecture represents a common
abstraction of a system that most if not all of the system’s stakeholders can use as a
basis for mutual understanding, negotiation, consensus and communication. 
Early design decisions: Software architecture manifests the earliest design
decisions about a system with respect to the system's remaining development. It is the
earliest point at which design decisions governing the system to be built can be
analyzed. 

Rajasekhar, SEAT Page 9

Transferable abstraction of a system: software architecture model is transferable
across systems. It can be applied to other systems exhibiting similar quality attribute .

We will address each of these points in turn:

1. ARCHITECTURE IS THE VEHICLE FOR STAKEHOLDER COMMUNICATION
 Each stakeholder of a software system – customer, user, project manager, coder,
tester and so on - is concerned with different system characteristics that are
affected by the architecture.
For ex. The user is concerned that the system is reliable and available when needed; the
customer is concerned that the architecture can be implemented on schedule and to
budget; the manager is worried that the architecture will allow teams to work largely
independently, interacting in disciplined and controlled ways.
 Architecture provides a common language in which different concerns can be
expressed, negotiated, and resolved at a level that is intellectually manageable
even for large, complex systems.

2. ARCHITECTURE MANIFESTS THE EARLIEST SET OF DESIGN DECISIONS

Software architecture represents a system’s earliest set of design decisions.
 The architecture defines constraints on implementation :
This means that the implementation must be divided into the prescribed elements, the
elements must interact with each other in the prescribed fashion.
 The architecture dictates organizational structure :
The normal method for dividing up the labour in a large system is to assign different
groups different portions of the system to construct. This is called the work breakdown
structure of a system.
 The architecture inhibits or enables a system’s quality attributes :
Whether a system will be able to exhibit its desired (or required) quality attributes is
substantially determined by its architecture
 Predicting system qualities by studying the architecture
 The architecture makes it easier to reason about and manage change
 Software systems change over their lifetimes:
Every architecture partitions possible changes into three categories: local, nonlocal,
and architectural.
 The architecture helps in evolutionary prototyping :
The system is executable early in the product's life cycle. Its fidelity increases as
prototype parts are replaced by complete versions of the software.
 The architecture enables more accurate cost and schedule estimates :
Cost and schedule estimates are an important management tool to enable the manager
to acquire the necessary resources and to understand whether a project is in trouble.
3. ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL
 Software product lines share a common architecture
Systems can be built using large. Externally developed elements :
 Less is more: it pays to restrict the vocabulary of design alternatives
We wish to minimize the design complexity of the system we are building. Advantages
to this approach include enhanced re-use more regular and simpler designs that are
more easily understood and communicated.
 An architecture permits template-based development :
Templates can be used to capture in one place the inter-element interaction
mechanisms.
 An architecture can be the basis for training :
The architecture, including a description of how elements interact to carry out the
required behavior, can serve as the introduction to the system for new project
members.

Rajasekhar, SEAT Page 10

 1) What is a architecture business cycle?
2) Why is software architecture important?
3) List all the common software architecture structures. Explain the component
connector structure.
4) Define software architecture. Explain the common software architecture structures.
5) Explain how the architecture business cycle works, with a neat diagram
6) Explain how the software architectures affect the factors of influence. Hence or
otherwise explain ABC.
7) Briefly explain the technical importance of software architectures. Further elaborate
on the fact that architecture is the vehicle for stakeholder communication.
8) What is an allocation structure as applied to software architectures? Explain the
three allocation structures in practice.
9) With the help of a neat block diagram of ABC, explain in detail the different activities
which are involved in creating a software architecture
10) Enumerate and explain in detail the different groups software architecture structures
are categorized into with the help of appropriate pictorial descriptions
11) Define software architecture. Discuss in detail, the implications of the definition
12) Define the following terms:
i)architectural model
ii)reference model
iii)reference architecture
13) Explain the module based structures
14) Define software architecture. What is a architecture business cycle? Explain with a
neat diagram
15) Define architectural model, reference model, reference architecture and bring out
the relationship between them
16) Explain the various process recommendations as used by an architect while
developing software architectures

Rajasekhar, SEAT Page 11

Introduction to quality attributes:
 It is important to consider quality issues during architectural design.
 It cannot give the guarantee to success the system.
 It is like good design and code for well architected system.
 A quality attribute is a property of a process or product that can have some
qualitative or quantitative value and can be measured or observed.
 General software quality attributes include scalability, security, performance and
readability.
 Quality attribute requirements are part of an application’s non-functional
requirements.
 Software quality is the degree to which software possesses a desired combination of
attributes.
 Achieving quality attributes must be considered throughout design, implementation,
and deployment.

Scenarios:
 The quality attribute must be described in terms of scenarios.
 Scenarios provide a simple yet powerful means for bridging the gap between
requirements and architecture.
 A scenario is a short statement describing an interaction of one of the stakeholders
with the system.
 A scenario is an instance of a use case.
 An architectural scenario is a crisp, concise description of a situation that the system
is likely to face in its production environment, along with the definition of the
response required of the system.
 A scenario defines the source of stimulus, the actual stimulus, the artefact affected,
the environment in which it exists, the effect of the action and the response
measure.
Why are quality attributes challenging?
1. Quality attributes often impact the system as a whole.
2. Quality attributes interrelate with functionality.
3. Quality attributes are often in conflict with each other.
4. It is often a practical challenge to define quality attribute requirements.
Introduction to Quality Attribute Workshop:
 QAWs provide a method for identifying a system’s architecture critical quality
attributes, such as availability, performance, security, interoperability, and
modifiability.
 The QAW does not assume the existence of software architecture.
 It was developed to complement the SEI Architecture Tradeoff Analysis
Method(ATAM).
 QAW defines two kinds of architectures:
1. System architecture : The fundamental system structure defined in terms of
system elements, interfaces, constraints and behaviors.
2. Software architecture: The structure or structures of the system.
 The QAW is system-centric and stakeholder focused.
 QAW involves these steps:
1. QAW presentation and introduction
2. Business presentation
3. Architectural plan presentation
4. Identification of architectural derivers

Rajasekhar, SEAT Page 12

 5. Scenario brainstorming
6. Scenario consolidation
7. Scenario prioritization
8. Scenario refinement
QAW Roles:

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.

Figure 4: 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.

(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 5: Goal of availability tactics

FAULT DETECTION
 Ping/echo. One component issues a ping and expects to receive back an echo,
within a predefined time, from the component under scrutiny.
 Heartbeat (dead man timer). In this case one component emits a heartbeat
message periodically and another component listens for it. If the heartbeat fails,
the originating component is assumed to have failed and a fault correction
component is notified.
 Exceptions. The exception handler typically executes in the same process that
introduced the exception.
FAULT RECOVERY
 Voting. Processes running on redundant processors each take equivalent input
and compute a simple output value that is sent to a voter. If the voter detects
deviant behavior from a single processor, it fails it.

Rajasekhar, SEAT Page 13

  Active redundancy (hot restart). All redundant components respond to events
in parallel. The response from only one component is used (usually the first to
respond), and the rest are discarded.
 Passive redundancy (warm restart/dual redundancy/triple redundancy).
One component (the primary) responds to events and informs the other
components (the standbys) of state updates they must make. When a fault
occurs, the system must first ensure that the backup state is sufficiently fresh
before resuming services.
 Spare. A standby spare computing platform is configured to replace many
different failed components.
 Shadow operation. A previously failed component may be run in "shadow
mode" for a short time to make sure that it mimics the behavior of the working
components before restoring it to service.
 State resynchronization. The passive and active redundancy tactics require the
component being restored to have its state upgraded before its return to service.
 Checkpoint/rollback. A checkpoint is a recording of a consistent state created
either periodically or in response to specific events.
FAULT PREVENTION
 Removal from service. This tactic removes a component of the system from
operation to undergo some activities to prevent anticipated failures.
 Transactions. Transactions are used to prevent any data from being affected if one
step in a process fails and also to prevent collisions among several simultaneous
threads accessing the same data.

Figure 6: Summary of availability tactics

(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."
 A third set of tactics has as its goal controlling deployment time and cost. We call this set
"defer binding time."

Rajasekhar, SEAT Page 14

 Figure 7: Goal of modifiability tactics
LOCALIZE MODIFICATIONS
 Maintain semantic coherence. Semantic coherence refers to the relationships
among responsibilities in a module. The goal is to ensure that all of these
responsibilities work together without excessive reliance on other modules.
 Anticipate expected changes. Considering the set of envisioned changes
provides a way to evaluate a particular assignment of responsibilities. In reality
this tactic is difficult to use by itself since it is not possible to anticipate all
changes.
 Generalize the module. Making a module more general allows it to compute a
broader range of functions based on input
 Limit possible options. Modifications, especially within a product line, may be
far ranging and hence affect many modules. Restricting the possible options will
reduce the effect of these modifications
PREVENT RIPPLE EFFECTS
We begin our discussion of the ripple effect by discussing the various types of
dependencies that one module can have on another. We identify eight types:
1. Syntax of
- data. - service.
2. Semantics of
- data. - service.
3. Prepared Sequence of
- data. - control.
4. Identity of an interface of A
5. Location of A (runtime).
6. Quality of service/data provided by A.
7. Existence of A
8. Resource behaviour of A.
With this understanding of dependency types, we can now discuss tactics available to
the architect for preventing the ripple effect for certain types.
 Hide information. Information hiding is the decomposition of the
responsibilities for an entity into smaller pieces and choosing which information
to make private and which to make public.
 Maintain existing interfaces. Interface stability can also be achieved by
separating the interface from the implementation. This allows the creation of
abstract interfaces that mask variations.
 Restrict communication paths. This will reduce the ripple effect since data
production/consumption introduces dependencies that cause ripples.
 Use an intermediary If B has any type of dependency on A other than semantic, it is
possible to insert an intermediary between B and A that manages activities
associated with the dependency.
DEFER BINDING TIME
Many tactics are intended to have impact at loadtime or runtime, such as the following.
 Runtime registration supports plug-and-play operation at the cost of additional
overhead to manage the registration.
 Configuration files are intended to set parameters at startup.

Rajasekhar, SEAT Page 15

  Polymorphism allows late binding of method calls.
 Component replacement allows load time binding.
 Adherence to defined protocols allows runtime binding of independent processes.

Figure 8: Summary of modifiability tactics

(3)Performance Tactics: Performance tactics control the time within which a response is
generated.

Figure 9: Goal of performance tactics

After an event arrives, either the system is processing on that event or the processing is
blocked for some reason. This leads to the two basic contributors to the response time:
resource consumption and blocked time.
Resource consumption. For example, a message is generated by one component, is
placed on the network, and arrives at another component. Each of these phases
contributes to the overall latency of the processing of that event.
Blocked time. A computation can be blocked from using a resource because of
contention for it, because the resource is unavailable, or because the computation
depends on the result of other computations that are not yet available.
- Contention for resources
- Availability of resources
- Dependency on other computation.

RESOURCE DEMAND
One tactic for reducing latency is to reduce the resources required for processing an
event stream.
 Increase computational efficiency. Improving the algorithms used in critical
areas will decrease latency. This tactic is usually applied to the processor but is
also effective when applied to other resources such as a disk.
 Reduce computational overhead. If there is no request for a resource,
processing needs are reduced. The use of intermediaries increases the resources

Rajasekhar, SEAT Page 16

 consumed in processing an event stream, and so removing them improves
latency.
 Another tactic for reducing latency is to reduce the number of events processed.
This can be done in one of two fashions;
 Manage event rate. If it is possible to reduce the sampling frequency at which
environmental variables are monitored, demand can be reduced.
 Control frequency of sampling.
 Other tactics for reducing or managing demand involve controlling the use of
resources;
 Bound execution times. Place a limit on how much execution time is used to
respond to an event. Sometimes this makes sense and sometimes it does not.
 Bound queue sizes. This controls the maximum number of queued arrivals and
consequently the resources used to process the arrivals.
RESOURCE MANAGEMENT
 Introduce concurrency. If requests can be processed in parallel, the blocked
time can be reduced.
 Maintain multiple copies of either data or computations
 Increase available resources. Faster processors, additional processors,
additional memory.
RESOURCE ARBITRATION
 First-in/First-out. FIFO queues treat all requests for resources as equals and satisfy
them in turn.
 Fixed-priority scheduling. Fixed-priority scheduling assigns each source of resource
requests a particular priority and assigns the resources in that priority order. Three
common prioritization strategies are
 Dynamic priority scheduling:
o round robin. Round robin is a scheduling strategy that orders the requests and then,
at every assignment possibility, assigns the resource to the next request in that order.
o earliest deadline first. Earliest deadline first assigns priorities based on the pending
requests with the earliest deadline.
 Static scheduling. A cyclic executive schedule is a scheduling strategy where the pre-
emption points and the sequence of assignment to the resource are determined offline.

Figure 10: Summary of performance tactics

(4) Security Tactics:

Tactics for achieving security can be divided into :
 those concerned with resisting attacks,

Rajasekhar, SEAT Page 17

  those concerned with detecting attacks, and
 those concerned with recovering from attacks.

Figure 11: Goal of security tactics

RESISTING ATTACKS
 Authenticate users. Authentication is ensuring that a user or remote computer
is actually who it purports to be. Passwords, one-time passwords, digital
certificates, and biometric identifications provide authentication.
 Authorize users. Authorization is ensuring that an authenticated user has the
rights to access and modify either data or services. Access control can be by user
or by user class.
 Maintain data confidentiality. Data should be protected from unauthorized
access. Confidentiality is usually achieved by applying some form of encryption
to data and to communication links. Encryption provides extra protection to
persistently maintained data beyond that available from authorization.
 Maintain integrity. Data should be delivered as intended. It can have redundant
information encoded in it, such as checksums or hash results, which can be
encrypted either along with or independently from the original data.
DETECTING ATTACKS
 The detection of an attack is usually through an intrusion detection system.
 Such systems work by comparing network traffic patterns to a database.
 In the case of misuse detection, the traffic pattern is compared to historic
patterns of known attacks.
 In the case of anomaly detection, the traffic pattern is compared to a historical
baseline of itself. Frequently, the packets must be filtered in order to make
comparisons.
 Filtering can be on the basis of protocol, TCP flags, payload sizes, source or
destination address, or port number.
RECOVERING FROM ATTACKS
 Tactics involved in recovering from an attack can be divided into those
concerned with restoring state and those concerned with attacker identification
(for either preventive or punitive purposes).
 The tactics used in restoring the system or data to a correct state overlap with
those used for availability since they are both concerned with recovering a
consistent state from an inconsistent state.
 One difference is that special attention is paid to maintaining redundant copies
of system administrative data such as passwords, access control lists, domain
name services, and user profile data.
 The tactic for identifying an attacker is to maintain an audit trail.
 An audit trail is a copy of each transaction applied to the data in the system
together with identifying information.

Rajasekhar, SEAT Page 18

 Figure 12: Summary of tactics for security

(5)Testability Tactics:
The goal of tactics for testability is to allow for easier testing when an increment of software
development is completed.

Figure 13: Goal of testability tactics

INPUT/OUTPUT
 Record/playback. Record/playback refers to both capturing information
crossing an interface and using it as input into the test harness.
 Separate interface from implementation. Separating the interface from the
implementation allows substitution of implementations for various testing
purposes.
 Specialize access routes/interfaces. Having specialized testing interfaces allows
the capturing or specification of variable values for a component through a test
harness as well as independently from its normal execution.
INTERNAL MONITORING
Built-in monitors. The component can maintain state, performance load, capacity, security,
or other information accessible through an interface. This interface can be a permanent
interface of the component or it can be introduced temporarily.

Rajasekhar, SEAT Page 19

 Figure 14: Summary of testability tactics
(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 15: Goal of runtime usability tactics

RUNTIME TACTICS
 Maintain a model of the task. In this case, the model maintained is that of the task.
The task model is used to determine context so the system can have some idea of
what the user is attempting and provide various kinds of assistance. For example,
knowing that sentences usually start with capital letters would allow an application
to correct a lower-case letter in that position.
 Maintain a model of the user. In this case, the model maintained is of the user. It
determines the user's knowledge of the system, the user's behavior in terms of
expected response time, and other aspects specific to a user or a class of users.
For example, maintaining a user model allows the system to pace scrolling so
that pages do not fly past faster than they can be read.
 Maintain a model of the system. In this case, the model maintained is that of the
system. It determines the expected system behavior so that appropriate feedback
can be given to the user. The system model predicts items such as the time needed
to complete current activity.
DESIGN-TIME TACTICS
Separate the user interface from the rest of the application. Localizing expected changes is
the rationale for semantic coherence. The software architecture patterns developed to
implement this tactic and to support the modification of the user interface are:
 Model-View-Controller
 Presentation-Abstraction-Control
 Seeheim
 Arch/Slinky

Rajasekhar, SEAT Page 20

 Figure 16: Summary of runtime usability tactics
UNIT II: DESIGNING THE ARCHITECTURE WITH STYLES

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 2.3

Figure 2.3: Evolutionary Delivery Life Cycle

Designing the Architecture:

 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.
 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
allocated to instantiate the module types provided by the pattern.
 The output of ADD is the first several levels of a module decomposition view of
architecture and other views as appropriate.

Rajasekhar, SEAT Page 21