Introduction to Software

Architecture

Venu Madhava Gunda

Contents
1 Introduction .......................................................................................................................................... 3
2 Architectural Elements/principles ........................................................................................................ 3
3 Architectural Description Language ...................................................................................................... 3
4 Designing the Architecture ................................................................................................................... 4
5 Architectural view of software development ....................................................................................... 4
6 Basic Architecture Design Process ........................................................................................................ 4
6.1 Architectural View......................................................................................................................... 5
6.2 Architectural Styles/Pattern ......................................................................................................... 5
6.2.1 Pipe and Filter ....................................................................................................................... 7
6.2.2 Object Oriented Organization ............................................................................................... 7
6.2.3 Layer Architecture................................................................................................................. 8
6.2.4 Three tier Architecture.......................................................................................................... 8
6.2.5 Service Orient Architecture: ................................................................................................. 9
6.2.6 Resource Oriented Architecture ......................................................................................... 11
6.3 Difference between OOA, SOA and ROA .................................................................................... 11
1 Introduction
Software architecture is an abstraction of the run time elements of a software system during
some phase of its operation. A system may be composed of many levels of abstraction and
many phases of operation, each with its own software architecture.

Software architecture is gives the well understanding of behavior of System in abstract level.

Monolithic Object Service Resource

Application Oriented Oriented Oriented
(Module Approach Approach Architecture
Architecture) (Classes) (Components) (Resources)

2 Architectural Elements/principles
Architectural Elements is defined by configuration of architectural elements – components,
connectors, and data constrained in their relationships in order to achieve a desired set of
architectural properties.

Component: An abstract unit of software instructions and internal state that provides a
transformation of data via its interface.

Connectors: It is an abstract mechanism that mediates communication, co ordination or co

operation among components.

Data: It is an element of information that is transferred from component, or received by a

component, via connector.

3 Architectural Description Language

It is a language used to describe the Architectural Description Languages. An ADL is a Languages
that provides features for the explicit specification and modeling of a software System’s conceptual
architecture, including minimum: components, component interfaces, connectors and architectural
configurations. Some ADLs

Darwin
Unicon
AADL
Wright
Acme
xADL
DAOP-ADL
4 Designing the Architecture
While developing/designing architecture, we need to consider following Principles

Data
Architectural Interface boundaries
Focus on Transactions
Design the concurrency, multiplicity and channelization

5 Architectural view of software development

It composed of 4 phases

Pre Design Phase: The architect is concerned mostly with forming and understanding the
enterprise context in which an application will exist. This is represented by a model that
depicts the system as an entity within a community of other entities, such as other
software systems and human users.
A domain analysis Phase: The application requirements are analyzed and structured. In
particular, the requirements are those around the problem domain but not specific to the
domain of software itself, such as user interface or HCI-related requirements
A schematic design Phase: The architect begins to develop the solution models such as
identifying the modules of the system and the design rules that establish the boundaries
between modules. Modules are discrete units of design work that rely on shared
information and also have hidden information.
A Design Development Phase: The design development phase focuses on refining the
architectural description and selecting among alternative designs.

6 Basic Architecture Design Process

It contains four steps

Understand the problem: The first step is arguably the most crucial because it affects the
quality of the design that follows. Without a clear understanding of the problem, it is not
possible to create an effective solution
Identify design elements and their relationships: In this step, we identify design elements
and their interdependencies. In the early phases of the design project, we perform a naive
functional decomposition of the application, which establishes a baseline for future design
tasks and design transformation
Evaluate the architecture design: This step involves assessing the architecture for
conformance to architectural quality attribute requirements. The functional behavior of the
application cannot be ideally tested from an architectural decomposition. However, many
other quality attributes can be assessed by inspecting the design or by implementing
prototypes of the architecturally significant component interactions.
Transform the architecture design: This step involves the application of design operations
to transform the architecture design into a new design that addresses the quality attribute
 requirements better than the previous design. The phase may be repeated multiple times
and even performed recursively.

6.1 Architectural View

Software architecture is commonly organized in views, which are analogous to different types of
blueprints made in building architecture. Views are instance of View Points, where view point
exists to describe the architecture in question from the perspective of a given set of stake holders
and their concerns.

Kruchten defined the software architecture into a model. It is called 4+1 model. It comprises the

Logical View: It is an object model of the design. Ex: UML Use Case Diagram
Development View: It describes the static organization of the software in its development
environment
Process view: It captures the concurrency and synchronization aspects of design.
Physical view: It describes the mapping of the software onto the hardware and
distributed aspects.

6.2 Architectural Styles/Pattern

An architectural style is a coordinated set of architectural constraints that restricts the roles/
features of a architectural elements and the allowed relationships among those elements within
any architecture that conforms to that style

Application is broadly divided into three categories:

Standalone/Software Application
Distributed Software Application
While using the Architectural Styles you have to first determine what type of application you are
going to design.

Here List of important Architectural Styles that everybody follows:

Pipes and Filters

Monolithic (Based on Modules)
Object Oriented Architecture (Slightly less to Monolithic
Layered Architecture (Three tier model architecture)
Black Board
Client – Server
Service Oriented Architecture
Resource Orient Architecture (REST :Representational State Transfer)

Other Architectural Styles:

Data Base Centric Architecture

Distributed Computing
Event Driver Architecture
Front End and back end
Implicit invocation
Peer to Peer
Plugins
Structured (Module based)
Software component
Space Based architecture
Shared nothing architecture
Rule Evaluation
6.2.1 Pipe and Filter
In a Pipe and Filter style each component has a set of inputs and a set of outputs. A component
reads streams of data on its inputs and produces streams of data on its outputs, delivering a
complete instance of the result in standard order.

6.2.2 Object Oriented Organization

In this style data representations and their associated primitive operations are encapsulated in
abstract data type or objects. Component of this model this style are objects, instance of Object
types.

Two important aspects of this style are

1. That an object is responsible for preserving the integrity of its representation

2. That representation is hidden from other objects.
6.2.3 Layer Architecture
A layered system is organized hierarchically, each layer providing service the layer above it and
serving as a client to the layer below. In these systems the components implement a virtual
machine at some layer in a hierarchy.

6.2.4 Three tier Architecture

Three tier architecture is a client Server architecture in which the user interface, functional
process logic, computer data storage and data access are developed and maintained independent
modules, most probably separate platforms

(UI Layer) Presentation Tier: This is the top most level of the application. The presentation tier
displays information related to such services as browsing, purchasing etc.,

(Middle Layer) Application Tier (Business Logic/Logic Tier): The logic tier is pulled out from the
presentation tier and, as its own layer. It controls an application’s functionality by performing
detailed processing.

(Lowe Layer) Data Tier: This tier consists of Database Servers. Here information is stored and
retrieved. This tier keeps data neutral and independent from application servers or business logic.
Giving data its own tier also improves scalability and performance.
 Difference between the 3 –Tier Architecture and Model View Control Architecture:

3- Tier Architecture Model View Control Architecture

Pattern
Client never communicates Client communicates directly
directly with the data tier with the data tier
It is a linear It is Triangular

6.2.5 Service Orient Architecture:

Web services are software systems designed to support interoperable machine-to-machine
interaction over a network. This interoperability is gained through a set of XML-based open
standards, such as WSDL (Web Services Description Language), SOAP (Simple Object access
Protocol), and UDDI (Universal Description Discovery and Integration). These standards provide
a common approach for defining, publishing, and using web services.

SOA is an architectural style for building software applications that use services available in a
network such as the web. It promotes loose coupling between software components so that
they can be reused.

Service Oriented Architecture as a group of services that communicate with each other. The
process of communication involves either simple data passing or two or more services
coordinating some activity. Intercommunication implies the need for some means of connecting
two or more services each other.

The World Wide Web Consortium (W3C) for example refers to SOA as 'A set of components
which can be invoked, and whose interface descriptions can be published and discovered'.
The first service-oriented architecture for many people in the past was with the use DCOM or
Object Request Brokers (ORBs) based on the CORBA specification.

SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service
providers register their service in a public registry. This registry is used by consumers to find
services that match certain criteria. If the registry has such a service, it provides the consumer
with a contract and an endpoint address for that service.

Figure 1: SOA's Find-Bind-Execute Paradigm

SOA-based applications are distributed multi-tier applications that have presentation, business
logic, and persistence layers. Services are the building blocks of SOA applications. While any
functionality can be made into a service, the challenge is to define a service interface that is at
the right level of abstraction. Services should provide coarse-grained functionality.

Component Based Architecture: A component is a software object, meant to interact with other
components, encapsulating certain functionality or a set of functionalities. A component has a
clearly defined interface and conforms to a prescribed behavior common to all components
within an architecture.
The goal of CBA is to increase the productivity, quality, and time to market in software
development

Example: eBay web service.

6.2.6 Resource Oriented Architecture
Now a day’s plug & Play (PNP) important role etc., plug and play of drivers, components etc., so
Service Oriented operation mainly consider the service point which decides how to go. As
complexity of plug and play increases it is difficult maintain by Service Point (End Point).

Here it starts the Resource oriented architecture. Main focus is on Resource.

Resource is anything that is important enough to be referenced as a anything in itself. A

resource is something that can be stored on a computer and represented as a stream of
bits, a document, a row of database, or the result of running algorithm.
URI (universal Resource Identifier or Address) is a name and address of a resource. If a
piece of information it is not a resource.
Stateless means second request never relies on the information of first request. If
second request requires the information what client got from first request it ask once
again in the second request.
Verbs are actions/messages that performed by the client. So, client only perform these
operation.

Example: MSDN, where you can access the data through the address.

6.3 Difference between OOA, SOA and ROA

Attribute OOA ROA SOA

Granularity Object Instance Resource Instance Service Instance
Main Focus Marshalling Parameter Request addressing Creation of request
values (URLs) Payloads
Addressing/ Request Routed Unique Object Unique address per One endpoint address
Focusing instance resource per service
Are replies No Yes Yes
cacheable?
Application Interface Specific to this Object/Class
Generic to the request Specific to this service
description is middleware
mechanism description is protocol
specific (Ex: IDL) (ex: HTTP verbs) specific
(ex: WSDL)
Payload / data Yes – Usually middleware No – nothing directly Yes – Part of service
format description specific linked to address / description (ex: XML
(ex: IDL) URL Schema in WSDL)

Coupling Tightly Coupling Loosely Coupling Loosely Coupling

State Stateful Stateless Stateless