Unit I : INTRODUCTION 9

Basic concepts of software architecture – Context of Software Architecture – ABC cycle

– What software architecture is and what it isn’t – Architectural patterns – Good
Architecture- Reference models – Architectural structures and views- Introduction to
styles – Decentralized Architectures

Unit I INTRODUCTION

1.Basic concepts of software architecture

software architecture, which distills the experience of many people,

Having a software architecture is important to the successful development of a software

system.

Software systems are constructed to satisfy organizations' business goals.

The architecture is a bridge between those (often abstract) business goals and the final
(concrete) resulting system.

The software architectures can be designed, analyzed, documented, and implemented

using known techniques that will support the achievement of these business and mission
goals. The complexity can be tamed, made tractable.

2..Context of Software Architecture

As the architect begins creating— envisioning—the central artifact of a system whose

influences persist beyond the lifetime of the system . The design as taking the right
steps to ensure that the system will perform as expected—produce the correct answer or
provide the expected functionality—architecture is additionally concerned with much
longer-range issues.

The architect is faced with a swarm of competing, if not conflicting, influences and
demands, surprisingly few of which are concerned with getting the system to work
correctly.

The organizational and technical environment brings to bear a weighty set of sometimes
implicit demands, and in practice these are as important as any of the explicit requirements
for the software.
 Unit I INTRODUCTION

Where does architecture come from

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

A same architect, designing a non-real-time system, is likely to make quite different

choices still.

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”.
 Unit I INTRODUCTION

Having an acceptable system involves properties such as performance, reliability,

availability, platform compatibility, memory utilization, network usage, security,
modifiability, usability, and interoperability with other systems as well as behavior.

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 conflict

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.

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,
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 or a course.
 Unit I INTRODUCTION

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 prevalent in

the architect’s professional community.

Ramifications of Influences on Architecture:

The influences on the architect, and hence on the architecture, are shown in Figure

 Influences on an 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.
 Unit I INTRODUCTION
3. Software Processes and The Architecture Business Cycle :

Software designers have been taught to build systems based exclusively on the technical
requirements. Modern software development methods recognize the fault of this model
and provide all sorts of feedback loops from designer to analyst. But they still make the
implicit assumption that design is a product of the system's technical requirements, period.

Architecture has emerged as a crucial part of the design process ,architecture encompasses
the structures of large software systems. The architectural view of asystem is
abstract, distilling away details of implementation, algorithm, and data representation and
concentrating on the behavior and interaction of "black box" elements. A software
architecture is developed as the first step toward designing a system that has a collection
of desired properties

The software architecture of a program or computing system is the structure or structures

of the system, which comprise software elements, the externally visibleproperties of those
elements, and the relationships among them.

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:

The various activities involved in creating software architecture are:

• Creating the business case for the 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?
• Will it need to interface with other systems?
• Are there system limitations that it must work within?
• These are all the questions that must involve the system’s architects.
• They cannot be decided solely by an architect, but if an architect is not consulted in
the
creation of the business case, it may be impossible to achieve the
business goals
 Unit I INTRODUCTION
ARCHITECTURE ACTIVITIES

The structure of the ABC, architecture activities have comprehensive feedback relationships
with each other.

We will introduce each activity in the following subsections.

I) 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?
Will it need to interface with other systems? Are there system limitations that it must work
within?

These are all questions that must involve the system's architects. They cannot be decided
solely by an architect, but if an architect is not consulted in the creation of the business
case, it may be impossible to achieve the business goals.
II) 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.

III) Creating or Selecting the Architecture

The coceptnual 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.

IV) Communicating the Architecture

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.
 Unit I INTRODUCTION

The architecture's documentation should be informative, unambiguous, and readable

by many people with varied backgrounds
V) Analyzing or Evaluating the Architecture

Evaluating an architecture for the qualities that it supports is essential to ensuring that
the system constructed from that architecture satisfies its stakeholders' needs.
Becoming more widespread are analysis techniques to evaluate the quality attributes
that an architecture imparts to a system. Scenario-based techniques provide one of
the most general and effective approaches for evaluating an architecture. The most
mature methodological approach is found in the Architecture Tradeoff AnalysisMethod
(ATAM) , while the Cost Benefit Analysis Method (CBAM) provides the critical link to
the economic implications of architectural decisions.

VI) Implementing based on the Architecture

This activity is concerned with keeping the developers faithful to the structures and
interaction protocols constrained by the architecture. Having an explicit and well-
communicated architecture is the first step toward ensuring architectural
conformance. Having an environment or infrastructure that actively assists developers
in creating and maintaining the architecture (as opposed to just thecode) is better

VII) Ensuring that the implementation conforms to the architecture

 Finally, when an architecture is created and used, it goes into a maintenance

phase

 Constant vigilance is required to ensure that the actual architecture and its
representation remain to each other during this phase.
 Unit I INTRODUCTION

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.

i) 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 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. This skeletal system can then be used to “grow” the system

incrementally, easing the integration and testing efforts

 Unit I INTRODUCTION

 The architecture should result in a specific (and small) set of resource contention areas,
the resolution of which is clearly specified, circulated and maintained.

ii) 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. These interfaces should allow their
respective development teams to work largely independent of each other.

 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
or tasks that do not necessarily mirror the module decomposition structure.

 Every task or process should be written so that its assignment to a specific processor can
be easily changed, perhaps even at runtime.

 The architecture should feature a small number of simple interaction patterns

 Unit I INTRODUCTION

4. What software architecture is and what it isn’t:

Figure 4.1 Typical, but uninformative,

presentation of a software architecture
The system consists of four elements.
 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)—because they are positioned next to each other.
 All of the elements apparently have some sort of relationship with each other, since the
diagram is fully connected.
 Is this an architecture? What can we not tell from the diagram?
1.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?
2. What are the responsibilities of the elements?
 What is it they do? What is their function in the system?
3. What is the significance of the connections?
 Unit I INTRODUCTION

 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? Whatinformation
flows across the mechanisms, whatever they may be?

4. 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?

This diagram does not show a software architecture. We now define what does
constitute a software architecture: 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 because every system can be shown to comprise elements and the relations
among them.

 The behavior of each element is part of the architecture insofar as that behavior can be
observed or discerned from the point of view of another element. Such behavior is what
allows elements to interact with each other, which is clearly part of the architecture
 Unit I INTRODUCTION

Others point 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 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 relationship

5.Architectural Patterns, Reference Models, and Reference Architectures

Between box-and-line sketches that are the barest of starting points and full-fledged
architectures, with all of the appropriate information about a system filled in, lie a host of
intermediate stages. Each stage represents the outcome of a set of architectural decisions
Before discussing architectural structures, we define three of them.
 Unit I INTRODUCTION

1. 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 an 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. Countless architectures are of the client-server pattern under this
(informal) definition, but they are different from each other. An architectural pattern is not
an architecture, then, but it still conveys a useful image of the system—it imposes useful
constraints on the architecture and, i n turn, on the system.

2. 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. Arising from experience, reference models are a
characteristic of mature domains. Can you name the standard parts of a compiler or a
database management system? Can you explain in broad terms how the parts worktogether
to accomplish their collective purpose? If so, it is because you have been taught a reference
model of these applications.

3. A 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, a reference architecture
is the mapping of that functionality onto a system decomposition. The mapping may be, but
by no means necessarily is, one to one. A software element may implement part of a function
or several functions.
 Unit I INTRODUCTION

The relationships of reference models, architectural patterns, reference architectures, and

software architectures. (The arrows indicate that subsequent concepts contain more design
elements.)

Why Is Software Architecture Important?

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

2. Early design decisions. Software architecture manifests the earliest design decisions
about a system, and these early bindings carry weight far out of proportion to their individual
gravity with respect to the system's remaining development, its deployment, and its
maintenance life. It is also the earliest point at which design decisions governing the system
to be built can be analyzed.

3. Transferable abstraction of a system. Software architecture constitutes a relatively

small, intellectually graspable model for how a system is structured and how its elements
work together, and this model is transferable across systems. In particular, it can be applied
to other systems exhibiting similar quality attribute and functional requirements and can
promote large-scale re-use.

 Architecture Is the Vehicle for Stakeholder Communication

1. 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 team
 Unit I INTRODUCTION

to work largely independently, interacting in disciplined and controlled ways.

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

 Architecture Manifests The Earliest Set Of Design Decision

Software architecture represents a system’s earliest set of design decisions. These early
decisions are the most difficult to get correct and the hardest to change later in the
development process, and they have the most far-reaching effects.

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, and each element

must fulfill its responsibility to the others as dictated by the architecture.

The architecture dictates organizational structure

The normal method for dividing up the labor 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

o Whether a system will be able to exhibit its desired (or required) quality attributes is

substantially determined by its architecture.

o However, the architecture alone cannot guarantee functionality or quality.

o Decisions at all stages of the life cycle—from high-level design to coding and

implementation—affect system quality.

o Quality is not completely a function of architectural design. To ensure quality, a good

architecture is necessary, but not sufficient.

 Unit I INTRODUCTION

 Predicting system qualities by studying the architecture

o Architecture evaluation techniques such as the architecture tradeoff analysis method

support top-down insight into the attributes of software product quality that is made

possible (and constrained) by software architectures.

The architecture makes it easier to reason about and manage change

o Software systems change over their lifetimes.

o Every architecture partitions possible changes into three categories: local, nonlocal,

And architectural.

o A local change can be accomplished by modifying a single element. A nonlocal change

requires multiple element modifications but leaves the underlying architectural approach
intact.

The architecture helps in evolutionary prototyping

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

o A special case of having the system executable early is that potential performance

problems can be identified early in the product’s life cycle.

The architecture enables more accurate cost and schedule estimates

o 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
 Unit I INTRODUCTION

5.2 ARCHITECTURE AS A TRANSFERABLE, RE-USABLE MODEL

The earlier in the life cycle re-use is applied, the greater the benefit that can be achieved.
While code reuse is beneficial, re-use at the architectural level provides tremendous leverage
for systems with similar requirements.

Software product lines share a common architecture

o A software product line or family is a set of software-intensive systems sharing a

common, managed set of features that satisfy the specific needs of a particular market

segment or mission and that are developed from a common set of core assets in a

prescribed way.

Systems can be built using large. Externally developed elements

o Whereas earlier software paradigms focused on programming as the prime activity,

with progress measured in lines of code, architecture-based development often focuses

on composing or assembling elements that are likely to have been developed

separately, even independently, from each other.

Less is more: it pays to restrict the vocabulary of design alternatives

o 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, more capable analysis, shorter selection

time, and greater interoperability.

An architecture permits template-based development

o An architecture embodies design decisions about how elements interact that, while
reflected in each element's implementation, can be localized and written just once.

Templates can be used to capture in one place the inter-element interaction mechanisms.
 Unit I INTRODUCTION

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.

5.3 Architectural Structures And Views

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 softwaremanifests itself at
runtime. Module structures allow us to answer questions such as what is the primary
functional responsibility assigned to each module?

What other software elements is a module allowed to use? What other softwaredoes
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 such as
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? How can the system's structure change as it executes
 Unit I INTRODUCTION

 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? In what files is each element stored during development, testing, and
system building? What is the assignment of software elements to development teams?

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

Module

Module-based structures include the following.

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.

Uses: The units are related by the uses relation. One unit uses another if the correctness
of the first requires the presence of a correct version

(as opposed to a stub) of the second.

 Unit I INTRODUCTION

Layered: Layers are often designed as abstractions (virtual machines) that hide
implementation specifics below from the layers above, engendering portability.

Class or generalization: The class structure allows us to reason about re-use and the
incremental addition of functionality.

Component-and-Connector

These structures include the following

 Process, or communicating processes.:Like all component-and-connector structures,

this one is orthogonal to the module-based structures and deals with the dynamic
aspects of a running system. The units here are processes or threads that are connected
with each other by communication, synchronization, and/or exclusion operations. The
relation in this (and in all component-and-connector structures) is attachment, showing
how the components and connectors are hooked together. The process structure is
important in helping to engineer a system's execution performance and availability

 Concurrency. This component-and-connector structure allows the architect todetermine

opportunities for parallelism and the locations where resource contention may occur. The
units are components and the connectors are "logical threads." A logical thread is a
sequence of computation that can be allocated to a separate physical thread later in the
design process. The concurrency structure is used early in design to identify the
requirements for managing the issues associated with concurrent execution.

 Shared data, or repository: This structure comprises components and connectors that
create, store, and access persistent data. If the system is in fact structured around one
or more shared data repositories, this structure is a good one to illuminate. It shows how
data is produced and consumed by runtime software elements, and it can be used to
ensure good performance and data integrity.

 Client-server: This is useful for separation of concerns (supporting modifiability), for

physical distribution, and for load balancing (supporting runtime performance).
 Unit I INTRODUCTION

Allocation

Allocation structures include the following structures

 Deployment: This view allows an engineer to reason about performance, data integrity,
availability, and security

 Implementation: This is critical for the management of development activities and builds
processes.

 Work assignment: This structure assigns responsibility for implementing and integrating
the modules to the appropriate development teams.
 Unit I INTRODUCTION

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 view.
 Unit I INTRODUCTION

6.Introduction to styles

Architecture Styles:

1. Dataflow :

Data flow is a software architectural style that is widely used in various application
domains where data processing plays a significant role. The pipe-and-filter architectural
style is a special case of data flow style

The general data flow style

A. Computational model

The computational model of an architectural style is the overall mechanism that a system
in the style works. The data flow style is characterised by viewing the system as a series
of transformations on successive pieces of input data. Data enter the system and then flow
through the components one at a time until they are assigned to some final destination
(output or data store). The structure of the design is dominated by orderly motion of data
from component to component. The availability of data controls computation.

B. Design vocabulary

Associated to each architectural style is a set of design vocabulary about the specific types
of components and connectors that can be used in the systems of the style, the particular
design considerations often concerned the designers of such a system, and so on.
 Unit I INTRODUCTION

C. Structural pattern

Systems of a particular style often have a specific topologic structure in which components
are connected together. A data flow system can be viewed as a directed graph, where nodes
are processing elements and arcs are data flows between the elements. The below Figure
illustrates the data flow style

D. Essential invariants

Systems of a style may be different from each other on a number of features. It is important
to understand what features are variable so that different systems can be different but still
regarded as in the same style, as well as what are the essential features that all systems of
the style must have. One of the essential invariants for data flow systems is that there is no
interaction between processing elements other than data flows. Moreover, each processing
element must be on a path from the input to an output
 Unit I INTRODUCTION

i) Pipes and Filters

Each components has set of inputs and set of outputs

A component reads streams of data on its input and produces streams of data on its
output.

By applying local transformation to the input streams and computing incrementally, so that
output begins before input is consumed. Hence, components are termed as filters.

Connectors of this style serve as conducts for the streams transmitting outputs of one
filter to inputs of another. Hence, connectors are termed pipes.

Filters must be independent entities.

They should not share state with other filter

Filters do not know the identity of their upstream and downstream filters.

Specification might restrict what appears on input pipes and the result that appears on
the output pipes.

Correctness of the output of a pipe-and-filter network should not depend on the order in
which filter perform their processing
 Unit I INTRODUCTION

Common specialization of this style includes:

Pipelines:

o Restrict the topologies to linear sequences of filters.

Bounded pipes:

o Restrict the amount of data that can reside on pipe.

Typed pipe

o Requires that the data passed between two filters have a well-defined type.

A degenerate case of pipeline architecture occurs when each filter processes all of its
input data as a single entity. In these systems pipes no longer serve the function of
providing a stream of data and are largely vestigial.

ii) The batch sequential processing sub-style

A. Computational model

Batch sequential processing is also a sub-type of data flow architectural style. In addition to
the common features of the data flow architectural style’s computational model, in the
batch sequential style, components are independent programs. They are executed
sequentially, i.e. one component runs to completion before the next starts. The data is
transmitted between components as a whole batch rather than a stream of data
elements.

B. Design vocabulary

The computational components in a batch sequential processing architecture are

often called processing steps or phases.

C. Structural pattern

Batch sequential processing architectures usually consist of a finite number of steps

linearly connected.
 Unit I INTRODUCTION
However, some batch sequential processing systems contain loops that repeat some
processing steps for a finite number of times.

E. Properties derived from the architecture

Batch sequential processing architectures inherit almost all advantages of the data flow
architectural style, especially the reusability and modifiability. It avoids complicated issues
related to the synchronisation between components by executing them one after another.
On the other hand, because the components do not execute concurrently, the performance
of the system may be less satisfactory than other data flow systems. In particular, it usually
cannot deal with continuous streams of inputs with unbounded length

2. INDEPENDENT COMPONENTS

The architectural style of independent components has attracted increasing interest recently
for its strong support to software reuse and evolution due to its ease of integration of
components into a system. It has a number of sub-types of style including communicating
processes, event-based implicit invocation and multiagent systems.

The general independent components style

A. Computational model

Independent component architecture consists of a number of components thatcommunicate

through messages. They send data to each other but typically do not directly control each
other. The message may be passed to named participants or passed among unnamed
participants in case of using the publish/subscribe paradigm.

B. Design vocabulary

All components of a system in the independent component style must be executable. They
are often called processes if the component is active. Otherwise, they are often just called
modules. However, each specific sub-type of the architectural style.
 Unit I INTRODUCTION

C. Structural pattern

There is no general pattern of system structure for the whole class of independent component
architectural style with regard to the topological structures of the systems.

D. Essential invariants

The essential invariant of all sub-types of the independent component style is that the only
means of information exchange among the components is message passing. There is no
shared state variable or data between the components.

Components are autonomous in the sense that they are not controlling each other in the
sense that one component cannot decide whether the receiver of a message will take an
action accordingly or which action is to be taken if any. In case of morethan one component
receiving a message, the sender cannot even decide which of the receivers will react on the
message first

E. Properties derived from the architecture

Independent component architectures achieve modifiability by decoupling various portions of

the computation. It enables concurrent executions of the components, even parallel
executions of components on various computers over a network. Scalability of the system
can be achieved through balancing the load of clients and the servers, which is usually
running on more powerful hardware systems.

Another advantage of decoupling computation into independent components is that it eases

component integration. It strongly supports system evolution at two levels. At the component
level, a component can be replaced by a revised one without affecting the interfaces of other
components in the system. At the systems level, new components canbe easily integrated
into the system, say, simply by registering it for the events of the system
 Unit I INTRODUCTION

F. Sub-types of the style

There are a number of sub-types of independent component architectural styles
including the communicating process systems and the event-based implicit
invocation systems, These sub-types, there are also interrupt-driven process systems and
multicast message with dynamic binding systems. Multi-agent systems are also a sub- type
of the independent component style. They emerged from artificial intelligence research
and attracted considerable attention recently.
G. Examples
A typical example of independent component architecture is the client-server
architecture, which, in fact, can be considered as a sub-type of the architectural
style. A client-server system usually consists of a number of clients and one or
more servers; as shown in Figure .

A client component sends messages to a server to request the execution of a

certain computational task to be performed by the server. Upon receiving such a
request, the server decides whether to perform the requested task, and if it decides
to do so, the outcome or the result of the task is fed back to the client by sending a
message
i). The event based implicit invocation systems sub-style
Event-based systems are a sub-type of independent component architectures in
which control is part of the model.
 Unit I INTRODUCTION

A. Computational model

Individual components in an event-based implicit invocation system announce data that

they wish to share with their environment – a set of unnamed components. These other
components may register an interest in this class of data. If they do so,when the data
appears, they are invoked and receive the data.

B. Design vocabulary

A component’s announcement of data is usually called publishing the data. Such an

announcement is also called an event. A component’s registration of its interests in certain
data is called subscription. A message manager in an event-based implicit invocation system
is also often called event handler.

C. Structural pattern

The general structural pattern of event-based implicit invocation systems is shown. The
interface of a component in event-based implicit invocation systems usually contains a
collection of events that it can raise and a collection of procedures or functions that other
components can call directly. Therefore, in addition to message passing through the event
handler, components may communicate with each other directly through procedure/function
calls.
 Unit I INTRODUCTION
D. Properties derived from the architecture

As a sub-type of independent components architectural style, event-based implicit

invocation style inherits all the advantages and disadvantages of independent components
architectures. The implicit invocation architecture strongly supports reuse and software
evolution. A new component can be integrated into the system while the system is
executing simply by registering it for the events of that system.

One component can be replaced by another component or components without affecting

the interfaces of other components of the system. Such replacement can be done without
stopping the execution of the system. This property is of particular importance for
systems that must run uninterrupted continuously for a long period of time such as
continuous process control systems.

ii). The communicating processes sub-style

Another sub-type of independent component architectures is the architectural style of

communicating processes. These are

A. Computational model

The components of a system in the communicating processes style are active processes.
They communicate with each other through fixed channels of communications. They
pass messages to each other to synchronise their executions and to achieve mutual
exclusion in accessing shared resources. the classic multi-process systems.

B. Design vocabulary

The components in a communicating processes system are called processes and they
communicate with each other through communication channels and ports, where
messages are sent and received.

C. Structural pattern

The general structure of communicating processes systems is a network of processes

connected by communication channels. It differs from event-based implicit invocation in
that there is no event handler that is responsible for redistribution of the messages among
the processes
 Unit I INTRODUCTION

D. Sub-types of the style

Client-server architecture is a well-known sub-type of communicating processes. A server
exists to serve data to one or more clients, which are typically located across a network.
The client originates a call to the server, which works, synchronously or asynchronously,
to service the client’s request.
3. CALL AND RETURN
The general call and return style
A. Computational model
A software system in call and return style is essentially decomposed into smaller pieces
to deal with complexity and to help achieve modifiability. There is typically a single
thread of control. Each component executes only when it gets this control from another
component and returns the control to that component when it terminates execution. During
its execution, it may pass the control along to other components. Each component usually
has a fixed entry where the executions of the components start. A component also has
some fixed locations called exits where executions terminate. Such components are called
subroutines. The passes of control from one component toanother are called subroutine
calls or invocations, which are often combined with passing data as the parameters. The
component that has the entrance to the whole program is usually called the main program.
It controls the executions of subroutines.
B. Structural pattern
As illustrated a system in the call and return style can have any topological structure that
links subroutines by subroutine calls. However, a common practice is to organise the
connections between subroutines in certain patterns and to pack a number of interrelated
subroutines into program units. This results in a number of sub-types of the style.
 Unit I INTRODUCTION
C. Design vocabulary

A common practice in the design of a call and return system is to organize subroutines into
a hierarchy . A call and return architecture with a hierarchical structure is often called the
main-program-and-subroutine with shared data.

In a call and return system, a group of subroutines that share a common data store can be
grouped together to form a module. The module facility in almost all high level programming
languages supports flexible control over the visibility of variables and procedures and
functions defined in a module so that accesses to these entities are restricted and
implementation details can be hidden from the users of the module

i)The layered systems sub-style

Layered systems form a sub-type of the call and return style. They are commonly seen in
system software as well as application systems.

A. Computational model:

The computational model of layered systems is the same as that of call and return systems.
The main characteristic of the style is its way of organising subroutines into a simple
topological structure.

B. Structural pattern and design vocabulary

In a layered system, subroutines are organised into a number of groups, which are called
layers. Each layer contains a collection of subroutines that provide services at a certain
abstract level to the layer or layers above it. At the same time, the implementation of the
subroutines of the layer depends on calls to the subroutines in the lower layers. In some
layered systems, an inner layer is hidden from all outer layers except the adjacent one, while
in other systems certain functions are carefully selected for export to all outer layers.

C. Properties derived from the architecture

Layered systems have several desirable properties. First, they support designs based on
increasing levels of abstraction. This allows implementers to partition a complex problem into
a sequence of incremental steps. Second, they support enhancement
 Unit I INTRODUCTION

4. Data Centered:

A. Computational model and design vocabulary

The term data-centred architecture refers to systems in which the access and update of a
widely accessed data-store is an apt description. There are two types of components in a
data centred system. One is a data store, which stores the data that other components can
access. It is called shared data. The other components are active and run on independent
threads of control. They access the shared data to fulfil their functionality and to
collaborate with each other. These components are usually called clients. The shared data is
the central means of communications among the clients.

B. Structural pattern

A sketch of this style

C. Sub-types of the style

The shared data that all clients access and update may be a passive repository such as a
file or an active repository such as a blackboard. The means of communication (sometimes
called the coordination model) distinguishes two sub-types: repository (which is shown in the
figure above) and blackboard. A blackboard sends notification to subscribers when data of
interest changes, and thus is active.

i
 Unit I INTRODUCTION
D. Properties derived from the architecture

The data-centred style offers a structural solution to integrability especially when building
from existing systems. They have the advantages that the clients are relatively independent
of each other, and the data store is independent of the clients. Thus the system is scalable
because new clients can be easily added. It is also modifiable with respect to changing the
functionality of any client because other clients will not be affected. Coupling among clients
will lessen this benefit but may occur to enhance performance

5. IRTUAL MACHINE

A. Structural pattern :

A software system of virtual machine architecture usually consists of 4 components

interconnected as follows shown in figure

Virtual Machine Achitecture

B. Computational model and design vocabulary

Virtual machines are software systems that simulate a computer system, but with some
functionality that is not native to the hardware and/or software on which it is implemented.

Their functions are as follows.

(a) The program component stores the ‘program’ being interpreted, which is an abstract
representation of the process of data. It is usually in the form of a sequence of
structured data elements.
 Unit I INTRODUCTION
Each element represents an ‘instruction’ or ‘statement’ for how to process the data.
It is analogous to the program instructions run on the hardware computer system,
hence called ‘program.

(b) The data component stores the information to be processed. Such information is
analogous to the values assigned to variables in the execution of a program. The data
component is analogou to the memory of computer hardware.

(c) The interpretation engine is the active component in the system. It selects an
instruction from the ‘program’ being interpreted, updates the program’s data
according to the instruction, and updates its internal state. It is analogous to the

CPU in computer hardware.

(d) The internal state stores the current state of the interpretation engine. It is

analogous to the registers or the instruction count in computer hardware.

C. Properties derived from the architecture

Virtual machine architectures have the goal of achieving the quality of portability.
Executing a program via an interpreter also adds flexibility through the ability to
interrupt and query the program and introduce modifications at run-time, but there
is a performance cost. This can be useful in a number of ways. It can allow one to
simulate and test platforms that have not yet been built such as new hardware, and
it can simulate ‘disaster’ mode that would be too complex, costly or dangerous to
test with the real system.

D. Examples

Common examples of virtual machines are interpreters, rule-based systems, syntactic

shells, and command language processors. For example, the Java language is built to
run on top of the Java virtual machine, which allows the Java programs to be platform
independent. A Java program can therefore be executed on all computerplatforms that
have an implementation of Java virtual machine.
 Unit I INTRODUCTION

7.Decentralised Architecture:
A decentralised system, on the other hand, is one in which complex behaviour
emerges through the work of lower level components operating on local information,
not the instructions of any commanding influence.

This form of control is known as distributed control, or control in which each

component of the system is equally responsible for contributing to the global,
complex behaviour by acting on local information in the appropriate manner.

• The lower level components are implicitly aware of these appropriate responses
through mechanisms that are based on the component's interaction with the
environment, including other components in that environment.

• Decentralized simply means not centralized. The control, as opposed to with a single
entity, lies with the end users. BitTorrent a peer to peer network is an ideal example
of this.

• A decentralized network is controlled by a cluster of domain controllers that share

the network load and provide redundancy if one server goes down.

• Decentralized systems just like the distributed architecture have no single points of
failure. Even if several nodes go down, the network as a whole is still up.

• There is no single entity control, so there is zero possibility of the network going
down anytime unless all the nodes go down simultaneously which is a rare possibility
when we have systems connected all over the globe.

• This kind of architecture is almost infinitely scalable, unlike a centralized system in

which scalability depends upon the resources of the organization in charge.
 Unit I INTRODUCTION

Benefits of decentralization
Provides a trustless environment In a decentralized blockchain network, no one has
to know or trust anyone else. Each member in the network has a copy of the exact
same data in the form of a distributed ledger. If a member’s ledger is altered or
corrupted in any way, it will be rejected by the majority of the members in the network.

 Improves data reconciliation

Companies often exchange data with their partners. This data, in turn, is typically
transformed and stored in each party’s data silos, only to resurface when it needs to
be passed downstream. Each time the data is transformed, it opens up opportunities
for data loss or incorrect data to enter the workstream. By having a decentralized data
store, every entity has access to a real-time, shared view of the data.

 Reduces points of weakness

Decentralization can reduce points of weakness in systems where there may be too
much reliance on specific actors. These weak points could lead to systemic failures,
including failure to provide promised services or inefficient service due to the
exhaustion of resources, periodic outages, bottlenecks, lack of sufficient incentives for
good service, or corruption.

 Optimizes resource distribution

Decentralization can also help optimize the distribution of resources so that promised
services are provided with better performance and consistency, as well as a reduced

likelihood of catastrophic failure

 PART - A Questions
1.What is software architecture? (CO1,K1)
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.”

2.What is architectural pattern? (CO1,K1)

An architectural pattern is a description of element and relation types together with a set of
constraints on how they may be used.

3.Compare System Architecture and Software Architecture.? (CO1,K1)

• Software architecture focuses on the implementation that will solve a specific problem.
• Systems architecture focuses on the underlying servers (physical or virtual) and server
software (web servers, database et cetera) that the software will utilize. Systems architecture
is largely focused on scaling with high availability, fault tolerance and redundancy to avoid
data loss.

4. What is reference model? (CO1,K1)

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.

5.What is reference architecture? (CO1,K1)

A 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, A reference architecture
is the mapping of that functionality onto a system decomposition.

6. Why is software architecture important? (CO1,K1)

• Architecture is the vehicle for stakeholder communication
• Architecture manifests the earliest set of design decisions
• Architecture as a transferable, re-usable model
These are the reasons for the importance of software architecture from the technical
perspective.
7.What is Architecture Business Cycle? (CO1,K1)
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 the
environment to the architecture and back to the environment, the Architecture
Business Cycle (ABC).

8. List out the requirements for Architecture Business Cycle. (CO1,K1)

• Case studies
• Methods
• Techniques

9.What are the three classes of influence that come from the developing
organization? (CO1,K1)
Three classes of influence that come from the developing organization:
• Immediate business
• Long-term business
• Organizational structure.

10. What activities are involved in creating software architecture? (CO1,K1)

• 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

11. What are Quality attribute scenarios? (CO1,K1)

Quality attribute scenarios are the means by which quality moves from the eye of
the beholder to a more objective basis.
12. What is a variety of techniques for understanding requirements from the stakeholders?
There are a variety of techniques for eliciting requirements from the stakeholders:
 Object-oriented analysis uses scenarios, or "use cases" to represent requirements.
 Safety-critical systems use more rigorous approaches , such as finite -state- machine
models or formal specification languages.
 Collection of quality attributes scenarios that support the capture of quality
requirements for a system.
 Another technique that helps us understand requirements is the creation of prototypes.

13. What is an architectural structures and its types? (CO1,K1)

A structure is the set of elements itself, as they exist in software or hardware. The types of
architectural structures are
• Module structures
• Component-and-connector structures
• Allocation structures

14. Define functional requirements and list its 2 characteristics. (MAY/JUNE 2016)
• A functional requirement defines a function of a system or its component. A function is
described as a set of inputs, the behavior, and outputs.
• Functional requirements may be calculations, technical details, data manipulation and
processing and other specific functionality that define what a system is supposed to
accomplish.
• A functional requirement describes what a software system should do.

Some of the characteristics of functional requirements are:

• Business Rules
• Transaction corrections, adjustments and cancellations
• Administrative functions
• Authentication
• Authorization levels
• Audit Tracking
• External Interfaces

15. Write various technical constraints and business constraints. (MAY/JUNE 2016) Technical
Constraints in Software Architecture
Technical constraints are fixed technical design decisions that absolutely cannot be
changed.
• Programming language
• Operating system or platforms supported
• Use of a specific library or framework

Business Constraints
Business constraints are unchangeable business decisions that in some way restrict the
software architecture design.
• Schedule
• Budget
• Team composition and make-up
• Software licensing restrictions or requirements
 Part-B Questions

Q. Questions
No.
What makes a good architectural process? Givevarious process recommendations
1 and product recommendations

Explain how the software architectures affect the factors of influence. Hence or
2
otherwise explain ABC
Explain in detail about the basics of software architecture?
3

Discuss about the characteristics of goodarchitecture?

4

Narrate why software architecture is important?

5

Discuss in detail about the architecture structure and views?

6