IS Architectural Paradigms
What is a Paradigm?
• A Paradigm, refers to a design solution that is
considered by a community as being
successful and influential.
• Or:
• It is a constellation of beliefs, rules,
knowledge, etc. that is valid for a particular
design community.
• When applied to software development, a
paradigm guides the way that developers view
a given problem and organize the solution.
• Historically, Software developers have
experimented with three major software
development paradigms: procedural, data
driven, and object-oriented.
• Procedural
• The procedural paradigm focuses on the
algorithms or steps necessary to solve a
problem. It decomposes the problem into
more simple sub-problems represented by
procedures, functions, or methods.
Data Driven
• Data driven paradigms follow the data as it
enters the system, passes through processes
that transform the data, and continue to
follow the data until it leaves the system
Object-Oriented
• The object-oriented paradigm encapsulates
data and the procedures or operations that
may access and operate on that data into an
entity called an object. A group of similar
objects are described by a class.
What is an Architecture?
• An architecture is "the fundamental
organization of a system, embodied in its
components, their relationships to each other
and the environment, and the principles
governing its design and evolution
Architecture design document
• An architecture design document is the key
technical document used to determine whether
the critical system requirements are met.
• This is the immediate step after the
requirements engineering phase in the life-cycle
Categorizing Architectures
• In development, it is useful to organize
architectures into families and associate
families with typical applications: This will help
reduce the overall development time
A description of an architecture consists of three basic elements:
• A processing element or component is a
structure that transforms its inputs into required
outputs.
• A data element consists of information needed
for processing or information to be processed by
a processing element.
• Connecting elements are the “glue” that hold
different pieces of an architecture together.
Basic Elements of an Architecture
Architecture style
• An architecture style is a pattern of structural organization in an architecture.
• Characteristics:
• Types of components: Processing elements used to transform data
• Types of connectors: Control and data paths between components
• Constraints: Restrictions on processing, data, and allowable ways to “wire”
components together.
Architectural styles provide four things:
• Vocabulary: A set of design elements such as pipes, filters,
client, servers, parsers, databases, etc.
• Design rules: These are the set of constraints that dictates
how the processing elements should be connected.
• Semantic interpretation: An architectural style provides a
well-defined meaning of the connected design elements.
• Analyses: Many styles provide analyses that can be
performed on systems built in that style, i.e., deadlock
detection, scheduling, etc.
ARCHITECTURAL CATEGORIES
1 Data Flow Systems
1.1 Pipelines
• This architecture style is modeled after assembly lines in
manufacturing plants.
• The pipe consists of stages. When one stage completes
its processing its outputs become the inputs of the
following stage.
• In software engineering, pipeline architectures consist of
a set of connected processing elements called filters.
• A filter transforms its inputs and its results
become inputs to the pipe connected to the
next filter.
• The data element in a pipe is usually called a
stream.
• The connecting elements between filters are
called pipes
Example:
2.Call & return Systems
• Synchronous execution on component
• A component: calls another component
Ceases execution and waits until the other
component is ready
• May get a return values then Continues
execution
• Is used when the order of computation is fixed
Common forms
• Main program and subroutine
• Client -Server Systems
• Object Oriented Systems
• Hierarchical layers
2.1Main Program and Subroutines
• A main program acts as the controller.
• One or more Subroutines perform specific
functions when called by the main program.
• A single thread of control.
• The correctness of execution is dependent on
the correctness of the main program and all
subroutines that are called.
Main Program and Subroutines
• Hierarchical decomposition
• Single thread of control
• Subroutines typically aggregated into
subsystems
• Hierarchical reasoning
• Old-fashioned, popular in the 1970s to 90s:
Jackson Structured Programming, (JSP!)
Main Program and Subroutines
• Advantages:
• Simple to learn and understand.
• Disadvantages:
• Correctness depends on the subroutines that are
called
• Tends to have different subroutines doing the same
thing, “spaghetti code”.
• Does not scale easy to bigger systems.
2.2 Object-Oriented Systems
• Special case of Main Program and
Subroutines.
• Implements Encapsulation
Has Restricted access to information.
• This is the most important quality of O-O!
• Uses Structures that follows the Problem
Domain.
• Hence Natural understanding of the system.
Object-Oriented Systems
• Advantages
• 1-1 mapping of the problem domain makes
the system easier to understand.
• Encapsulation
2.3 Layered Style
• Implements Dividing into modules that are
layers.
• Topology constraint:
The layers are partly ordered, If A is above
B, B cannot be above A.
Hierarchical layers
• A hierarchically layered system is partitioned into
layers that are put above each other.
• Each layer act as
- a virtual machine for the layers above it
-a client to the layers below it
• Communication between the layers occurs
through well-defined APIs.
• Specially useful for Large Systems that can have
several layers
Hierarchical layers
Advantages:
• The Layered architecture provides an
incremental approach to designing a complex
system.
• Maintainability: Layers can be easily
maintained and even replaced.
• Extendibility: new services (layers) can be
easily added.
• Examples include Operating Systems
Difference Between a Tier and Layer
• A Tier is a physical unit, where the
code/processes run.E.g client, application
server, database server .
• A Layer is a logical unit, how to organize the
code. E.g presentation(view), controller,
models, repository , data access
2.4 N-Tier Architecture
• In a multi-tier environment, the client
implements the presentation logic (thin
client).
• The business logic is implemented on an
application server(s) and the data resides on
database server(s).
Components of an N-tier Architecture
• A Multi-tier architecture is thus defined by the
following three component layers:
1. A front-end component, which is responsible for
providing portable presentation logic;
2. A back-end component, which provides access
to dedicated services, such as a database server.
3. A middle-tier component, which allows users to
share and control business logic by isolating it from
the actual application;
Example:
Motivations
• N-Tier applications mean using whatever mix of
Computer Hardware and/or Software Layers you need, in
order to build a modular information system.
• What does N-tier mean?
N-Tier means "Any Number of Tiers"
~ No Limits ~ on:
Levels/Layers/Tiers
Clients & Customers
Objects & Components
Servers & Services
Benefits of N-tier
• Programs partitioned into Tiers allow each layer or
component part to be developed, managed, deployed
and enhanced independently.
• The N-Tier model of computing enables the overall
performance and maintainability of Client/Server
systems to be substantially improved.
• This layered environment also simplifies code
distribution, since most of the business logic has been
moved from the client to the server.
Benefits of N-tier
• Changes to the user interface or to the
application logic are largely independent from
one another, allowing the application to evolve
easily to meet new requirements.
• The client is insulated from database and
network operations. The client can access data
easily and quickly without having to know
where data is or how many servers are on the
system.
3.Independent Processes
3.1 Communicating Processes:
• A communicating process is an object with input and output ports.
• A port is an identifiable means of “wiring” process together. Ports are connected
by input and output channels.
• Processes are connected together to form different topology, i.e., mesh, tree, etc.
• A communicating process form of architecture includes: Processes and channels
to communicate these processes.
• Examples: Pipeline, Mesh, Tree
• Process-based architecture can be described
using Communicating Sequential Processes
(CSP) specification language. CSP was
introduced by Hoare (1978).
• The following table gives the notation used by
CSP:
The following table gives the notation used by CSP:
Figure 1
Using Figure 1
• Let P be the name of a process that supplies the input to the
pipeline, and out is the process that output the final result of the
pipeline.
• F1 be filters of the pipe.
• Message msg is received by the left channel, output by the right
channel, and then the process reverts back to pipe (waiting for the
next message).
• Steps:
• 1. Label all the pipelines.
• 2. Describe the overall topology of the architecture.
• 3. Give the details of individual pipelines.
• 1. Labels the pipelines:
• Pipe0, pipe1, etc.
• 2. Topology:
• Pipeline =
*(P;pipe0;F1;pipe1;F2;pipe2;F3;pipe3;out)
3. Details:
Each pipe is described as follows:
• Pipe0 = (P ? msg -> (F1 ! msg -> pipe0) // input
from P sent to filter F1
• Pipe1 = (F1 ? msg1 -> (F2 ! msg1 -> pipe1) //
input from F1 sent to filter F2
• Pipe2 = (F2 ? msg2 -> (F3 ! msg2 -> pipe2) //
input from F2 sent to filter F3
• Pipe3 = (F3 ? msg3 -> (out ! msg3 -> pipe3) //
input from F3 sent to filter out
• Example 3: a T pipe
