Software Architecture

1.ABSTRACT

Software architecture is about making fundamental structural choices which are costly to
change once implemented. Software architecture choices include specific structural options
from possibilities in the design of software. For example, the systems that controlled the
space shuttle launch vehicle had the requirement of being very fast and very reliable.
Therefore, an appropriate real-time computing language would need to be chosen.
Additionally, to satisfy the need for reliability the choice could be made to have multiple
redundant and independently produced copies of the program, and to run these copies on
independent hardware while cross-checking results.
Documenting software architecture facilitates communication between stakeholders, captures
early decisions about the high-level design, and allows reuse of design components between
projects.

Dept. of Computer Science and Engineering Page 1

 Software Architecture

2. INTRODUCTION

Software architecture refers to the high level structures of a software system and the
discipline of creating such structures and systems. Each structure comprises software
elements, relations among them, and properties of both elements and relations. The
architecture of a software system is a metaphor, analogous to the architecture of a building.
It functions as a blueprint for the system and the developing project, laying out the tasks
necessary to be executed by the design teams.

Software architecture is about making fundamental structural choices which are costly to
change once implemented. Software architecture choices include specific structural options
from possibilities in the design of software. For example, the systems that controlled the
space shuttle +launch vehicle had the requirement of being very fast and very reliable.
Therefore, an appropriate real-time computing language would need to be chosen.
Additionally, to satisfy the need for reliability the choice could be made to have multiple
redundant and independently produced copies of the program, and to run these copies on
independent hardware while cross-checking results.

Software systems have to cater to a variety of stakeholders such as business managers,

owners, users, and operators. These stakeholders all have their own concerns with respect to
the system. Balancing these concerns and demonstrating how they are addressed is part of
designing the system. This implies that architecture involves dealing with a broad variety of
concerns and stakeholders, and has a multidisciplinary nature.

Dept. of Computer Science and Engineering Page 2

 Software Architecture

3. OBJECTIVES

 This course introduces the concepts and the methods required for the construction
of large software intensive systems. It aims to develop a broad understanding of
the discipline of software engineering.
 It seeks to complement this with a detailed knowledge of techniques for the
analysis and design of complex software intensive systems. It aims to set these
techniques in an appropriate engineering and management context.
 It provides a brief account of associated professional and legal issues.

Dept. of Computer Science and Engineering Page 3

 Software Architecture

4.SALIENT FEATURES OF EACH UNIT

4.1 Introduction of Software architecture

Software architecture has emerged as an important sub-discipline of software engineering.

Architecture is roughly the prudent partitioning of a whole into parts, with specific relations
among the parts. This partitioning is what allows groups of people—often separated by
organizational, geographical, and even time-zone boundaries—to work cooperatively and
productively together to solve a much larger problem than any of them could solve
individually.

Each group writes software that interacts with the other groups’ software through carefully
crafted interfaces that reveal the minimal and most stable information necessary for
interaction. From that interaction emerges the functionality and quality attributes—security,
modifiability, performance, and so forth—that the system’s stakeholders demand.

The larger and more complex the system, the more critical is this partitioning—and hence,
architecture.
And as we will see, the more demanding those quality attributes are, the more critical the
architecture is.
A single system is almost inevitably partitioned simultaneously in a number of different
ways. Each partitioning results in the creation of an architectural structure: different sets of
parts and different relations among the parts. Each is the result of careful design, carried out
to satisfy the driving
quality attribute requirements and the most important business goals behind the system.

Architecture is what makes the sets of parts work together as a coherent and successful
whole. Architecture documentation help architects make the right decisions; it tells
developers how

Dept. of Computer Science and Engineering Page 4

 Software Architecture

to carry them out; and it records those decisions to give a system’s future caretakers insight
into the architect’s solution.

4.2 Architectural Styles And Case Studies.

An architectural style defines the vocabulary of components and connectors types and a set
of constraints on how they can be combined.
Lists of common Architectural Styles,
 Pipes and filters
 Objects.
 Implicit invocation.
 Layered.
 Interpreters.
 Repositories.
 Process control.

Pipes and filters.

 Each component has a set of inputs and outputs.
 A component(Filters) reads streams of data on its inputs and produces streams of data
on its outputs.
 Connectors(Pipes) are responsible for data transmission from output of one filters to
input of another filters.
 Components are called filters because output begins before the entire input is
consumed.
 Connectors are called pipes they allow to transmit the data.

Dept. of Computer Science and Engineering Page 5

 Software Architecture

Data abstraction and Object Oriented Organization.

 Data representation and associated operations are encapsulated in abstract data type
object.
 Components in this type are instance of abstract data types.
 Objects preserves the integrity of representation.
 Representation is hidden from object.
 Object interact through function and procedure invocations.

Dept. of Computer Science and Engineering Page 6

 Software Architecture

Interpreters.

 An interpreter includes the pseudo-program being interpreted and the interpretation

engine.
 Pseudo-program includes the program and activation record.
 Interpretation engine includes definition of interpreter and current state of its
execution.
 Interpreter engine includes:
o An interpretation engine to do work.
o Memory contains the pseudocode.

Dept. of Computer Science and Engineering Page 7

 Software Architecture

Heterogeneous Architecture.
Architectural style can be combined in several ways,
 Hierarchical.
A component of a system organized in one architectural style may
have different internal structure.
Example: Unix Pipeline
 Combining styles to permit a single component may use mixture of
architectural connectors.
Example: A component might access a repository through part of its
interface, but interacts through pipes.

Dept. of Computer Science and Engineering Page 8

 Software Architecture

4.3 Quality

Software quality is the degree to which software possesses a desired combination of

attributes.
 Functionality and quality attributes are orthogonal.
 Overall factors that affects run-time behavior, system design, and user
experience.
 Architecture, by itself, is unable to achieve qualities.
 Architecture should include the factors of interest for each attribute.

Quality attributes scenario.

 Is a quality-attribute-specific requirement.
 It consists of six parts:

Business Quality Attributes.

1) Cost and schedule:
Cost of the system with respect to time to market, expected project lifetime, and
utilization of legacy and COTS systems.
2) Marketability:
Use of the system with respect to market completion.

Dept. of Computer Science and Engineering Page 9

 Software Architecture

4.4 Architectural Patterns.

An architectural Pattern expresses a fundamental structural organization schema for software

systems. It provides a set of predefined subsystems, their responsibilities and includes rules
and guidelines for organizing the relationships between them.

Layers helps the structure an application that can be decomposed into groups of subtasks in
which each group of subtasks is at a particular level of abstraction.

Dept. of Computer Science and Engineering Page 10

 Software Architecture

Architectural Style.

Architectural styles tell us, in very broad strokes, how to organize our code. It’s the highest
level of granularity and it specifies layers, high-level modules of the application and how
those modules and layers interact with each other, the relations between them. Examples of
Architectural Styles:

 Component-based
 Monolithic application
 Layered
 Pipes and filters
 Event-driven
 Publish-subscribe
 Plug-ins
 Client-server
 Service-oriented

An Architectural Style can be implemented in various ways, with a specific technical

environment, specific policies, frameworks or practices.

Dept. of Computer Science and Engineering Page 11

 Software Architecture

Blackboard.
The blackboard model is usually presented with 3 major parts,
 The knowledge sources: Separate, independent parts of application
dependent knowledge.
 The blackboard data structure: Application dependent, problem
solving state data. Knowledge sources can make changes to the
blackboard that lead incrementally to a solution to the problem.
 Control: It is driven by the state of blackboard.

Dept. of Computer Science and Engineering Page 12

 Software Architecture

Broker.

A broker is used to structure distributed software systems with decoupled components that
interact by remote service invocation. A broker component is responsible for coordinating
communication, such as forwarding request, as well as for transmitting result and exception.

Dept. of Computer Science and Engineering Page 13

 Software Architecture

4.5 Interactive System.

Presentation-Abstraction-Control.

Presentation–abstraction–control (PAC) is a software architectural pattern. It is an

interaction-oriented software architecture, and is somewhat similar to model–view–
controller (MVC) in that it separates an interactive system into three types of components
responsible for specific aspects of the application's functionality. The abstraction component
retrieves and processes the data, the presentation component formats the visual and audio
presentation of data, and the control component handles things such as the flow of control
and communication between the other two components.
In contrast to MVC, PAC is used as a hierarchical structure of agents, each consisting of a
triad of presentation, abstraction and control parts. The agents (or triads) communicate with
each other only through the control part of each triad. It also differs from MVC in that within
each triad, it completely insulates the presentation (view in MVC) and the abstraction (model
in MVC). This provides the option to separately multithread the model and view which can
give the user experience of very short program start times, as the user interface (presentation)
can be shown before the abstraction has fully initialized.

Dept. of Computer Science and Engineering Page 14

 Software Architecture

Microkernel.

The microkernel architecture pattern (sometimes referred to as the plug-in architecture

pattern) is a natural pattern for implementing product-based applications. A product-based
application is one that is packaged and made available for download in versions as a typical
third-party product. However, many companies also develop and release their internal
business applications like software products, complete with versions, release notes, and
pluggable features. These are also a natural fit for this pattern. The microkernel architecture
pattern allows you to add additional application features as plug-ins to the core application,
providing extensibility as well as feature separation and isolation.

Dept. of Computer Science and Engineering Page 15

 Software Architecture

Dept. of Computer Science and Engineering Page 16

 Software Architecture

5. CONCLUSION

Every software-intensive system has an architecture. In some cases that architecture is

intentional, while in others it is accidental. Most of the time it is both, born of the
consequences of a myriad of design decisions made by its architects and its developers over
the lifetime of a system, from its inception through its evolution. In that sense, the
architecture of a system is the naming of the most significant design decisions that shape a
system, where we measure significant by cost of change and by impact upon use. As such, all
architecture is design, but not all design is architecture. Furthermore, while the code of a
software-intensive system is the truth, it is not the whole truth: architectural decisions are
often asserted as patterns that weave through the abstractions in a system, giving rise to
textures that transcend raw executable code. At the highest level of abstraction, we can
discern patterns that give each system a particular architectural style. For all systems of
sufficient complexity, we can only understand and reason about a system’s architecture from
multiple points of view, each view representing the concerns of a particular set of
stakeholders. The challenge of the engineering process that makes any software-intensive
system manifest is therefore to grow a set of architectural decisions that yield an optimal
balance of the functional and non-functional forces that weigh upon each and every one of
these views.

Dept. of Computer Science and Engineering Page 17

 Software Architecture

6. REFERENCES

 Software Architecture in Practice by Len Bass, Paul Clements, and Rick Kazman
 Documenting Software Architectures: Views and Beyond Book by Paul Clements
 https://en.wikipedia.org/wiki/Software_architecture

Dept. of Computer Science and Engineering Page 18