Architectural Design

By – Er. Suraj Awal

 What is Architectural Design?
• According to IEEE, "Architectural design is the process of
defining collection of hardware and software components and their
interfaces to establish the framework for the development of computer
system."
• Represents structure of the data and components that are required to build a
computer system
 Importance of Architectural Design
1. Communication among stakeholders
2. Early design decisions
3. Transferable abstraction of the system
 1. Communication among Stakeholders
• Software architecture represents a common abstraction that all the
stakeholders can use as a basis for mutual understanding, negotiation,
consensus and communication.
• Each stakeholder of the system is concerned about some characteristics of
the system. The user is concerned if the system is reliable and available, the
customer is concerned whether the system can be implemented on schedule
and to budget, the manager is concerned whether the team can work
independently and so on.
 1. Communication among Stakeholders
• Architectural design provides a common method to express and resolve the
concerns of the stakeholders that can be intellectually managed even for the
larger and complex projects.
• If there is no architectural design, it would be very difficult to understand
complex system to make early decisions that influence both quality and
usefulness.
 2. Early Design Decisions
• Architectural design represents the earliest set of design decisions.
• Such early decisions are the most difficult to get correct and the hardest to
change later and have the most far reaching effects.
• It defines the constraints imposed on implementation such as resource
allocation and computational complexity.
• It dictates how to engrave the organizational structure such as labor division,
work breakdown structure that helps in planning for schedule and budget.
 2. Early Design Decisions
• It enables to define the quality attributes based on the architecture. For e.g.:
if your system requires high performance, you need to manage time-based
behavior of ifQBejQ4s5DpUvp
the elements; if your system needs scaling, you must carefully
localize the use of resources to facilitate introduction of high capacity
replacements; if your system must be highly secure, you need to manage and
protect inter-element communication and manage access control of
information for each element.
 3. Transferable Abstraction of the System
• Architectural design provides the model for how a system is structured and
how its elements work together.
• Such models are transferable across system exhibiting similar quality
attributes and functional requirements.
 Architectural Design Decisions
• Is there a generic application architecture that can be used ?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?
 System Organization
• It reflects the basic strategy that is used to structure the system.
• Types of organizational styles are:
1. Shared data repository style
2. Shared services and servers style
3. Abstract machine or layered style
 System Organization (Data Repository Style)

• The sub systems must exchange data.

• Such model is used when large amount of data are to be shared.
• Two ways:
1. Shared data in central database that can be accessed by all sub systems.
2. Each sub system with its own database and passes the data explicitly to other
sub systems.
 System Organization (Data Repository Style)

Advantages:
• Efficient way to share large amount of data
• Sub systems not concerned on how data is produced
Disadvantages:
• Data evolution is difficult and expensive
• No scope for specific management policy
• Difficult to distribute efficiently
 System Organization (Shared Services Style)

• Data and processing are shared across a range of components

• Servers provide specific services and are shared
• Set of clients call these services
System Organization (Abstract Machine Model)

• It is used to model the interfacing of the sub systems.

• It organizes the system into set of layers or abstract machines, each of which
provides a set of services.
• Such model supports the incremental development of sub systems in
different layers. When a layer interface changes, only the adjacent layer is
affected.
• Generally, it is virtual in real practice.
System Organization (Abstract Machine Model)

• For eg: Version Management System

• The different layers are:
1. Configuration management system layer
2. Object management system layer
3. Database system layer
4. Operating system layer
 Modular Decomposition Styles
• Modular decomposition refers to decomposing sub systems into modules.
• A sub system is a system whose operation is independent of the services provided
by other sub systems.
• A module is a system component that provides services to other components but
would not be considered as a separate system.
• Two styles for modular decomposition:
1. Object model
2. Pipeline or Data-flow model
 Modular
Decomposition Styles
(Object Model)

• The object model

indicating the class,
their attributes and
possible operations for
a invoice processing
system.
Modular Decomposition Styles (Object Model)

• Objects are basically loosely coupled so their implementation can be

modified without affecting other objects.
• Such model reflects real world entities.
• Object oriented implementation are widely used.
• Complex entities are hard to represent as objects and object interface
changes may cause serious problems.
 Modular Decomposition Styles (Data-flow
Model)
• It is concerned with functional transformations that processes their inputs to
produce outputs.
• Also called as pipe or filter model.
• When transformations are sequential, it is called batch sequential model
which is extremely used in data processing system.
• Not suitable for interactive systems.
 Modular
Decomposition Styles
(Data-flow Model)

• The data flow model

for invoice processing
system.
 Modular Decomposition Styles (Data-flow
Model)
• It supports transformation reuse.
• It helps to understand the underlying concept by the stakeholders.
• It is easy to add new transformations.
• It is simple to implement as concurrent or sequential system.
• It requires a common format for data transfer along the pipeline and difficult
to support event based interaction.
 Control Styles
• It is concerned with the control flow between sub systems.
• Two types of control styles:
1. Centralized control
2. Event-based control
 Control Styles (Centralized Control)
• One sub system is responsible for managing the control flow of overall
system.
• Call Return Model (Top down model where control starts at the top of
subroutine hierarchy and moves downward. Applicable for sequential
system.)
• Manager Model (One system component controls stopping, starting and
coordinating other processes. Applicable for concurrent systems as well.)
 Control Styles
(Centralized Control)

• Demonstration of Call
Return Model
 Control Styles
(Centralized Control)

• Demonstration of
Manager Model
 Control Styles (Event Driven Control)
• In event driven control, the control of sub system is controlled by the
externally generated events.
• The event driven control styles includes:
1. Broadcast Model (Sub system register for interest in an event and then
control is transferred for processing the event)
2. Interrupt Driven Model (Consist of known interrupt types with handler that
allows fast response and is used in real time systems)
Control Styles (Event Driven Control)
 Client Server Architecture
• Common architecture that decomposes system into two logical subsystems :
client and server.
• Client is the process that issues a request to the server to perform some
service.
• Server is the process that receives the request, executes the required service
and sends a reply to the client.
 Client Server Architecture
Thin Client Model :
• All application processing and data management is done in server.
• Client is responsible for presentation of user interface only.
• A major drawback is it places a heavy processing overhead or load on both
server and network.
 Client Server Architecture
Thick Client Model
• The server is only responsible for data management.
• The client imposes application logic and user interactions.
• Complex to implement the management strategy.
Client Server Architecture
 Client Server Architecture (Advantage)
• Separation of responsibilities such as user interaction and logical processing.
• Reusability of server components and concurrent processing.
• Simple design and implementation.
• Easy migration or integration of existing applications.
• Effective use of resources when the server is highly efficient.
 Client Server Architecture (Disadvantage)
• Limited server availability and reliability.
• Limited scalability.
• Single point of failure.
 Peer to Peer Model
• Also known as Distributed Object Architecture.
• There is no central control.
• Each node can either be a client or a server at a given time.
• If any node made a request, it is called client.
• If any node serves the request, it is called server.
• In general, each node is referred to as a peer.
Peer to Peer Model
 Client server Vs. Peer to peer
Client Server Architecture Peer to Peer Architecture
There is specific server and specific Each node acts as both client and
clients connected to server. server.
Client requests for service and server Each node can request service and
provides service. provide service.
Focuses on information sharing. Focuses on connectivity.
Data stored in centralized server. Each peer has its own data.
Expensive to implement Cheap to implement.
 Client server Vs. Peer to peer
Client Server Architecture Peer to Peer Architecture
More stable and scalable. Suffers if the number of peers
increases.
When several clients request for the A server does not get bottlenecked as
services simultaneously, a server can the services are provided by several
get bottlenecked. servers distributed in the peer to peer
system.
 Multiprocessor Architecture
• It is a system composed on multiple processes which may execute on
different processors.
• Distribution of processes to processor may be pre-ordered or may be under
the control of a dispatcher.
Multiprocessor Architecture
 Reference Architecture
• A software architecture that provides a template solution for an achitecture
for a particular domain.
• Also provides a common standard for which to discuss implementations.
• It is an architecture where the structures and respective elements and
relations provide templates for concrete architectures in a particular domain
or in a family of software systems.
Reference Architecture
 Reference Architecture
• OSI model is a 7 layer model for open system interconnection.
• The lower layers are concerned with physical interconnection, the middle
layers with data transfer and the upper layers with transfer of semantically
meaningful application information.
• Its objective is to define an implementational standard so that conformant
systems could communicate with each other.
• Each layer should only depend on the layer beneath it.
Thank You !