Architectural Styles

SWE 3633-Software Design &

Architecture
 Architectural Styles

• An Architectural Style defines a set of rules

that describe

1. the properties of and constraints on its

components and

2. The way in which the components interact

 Architectural Styles (Patterns)
• Architectural Styles may be viewed as a
set of Architectural Design solutions
that have been used successfully
before.

A software design pattern is a model for a class of solutions to a software

design problem. At high level we call these patterns architectural styles.
• These styles (or patterns) offer multiple
benefits:
– Promote communications among the
designers because the pattern names are
used as a shorthand for a lengthy
description

– Streamline documentation for the same

reason above
– Support high level of reuse if the pattern is
applicable

– Provide a starting point for additional and

new design ideas.

– Improve development efficiency and

productivity for above reasons and not
having to profile or prototype all the
existing patterns
 Software Design Patterns

• Software Design Pattern is a recent

event, although programming level
patterns have been studied in our
industry such as Sorts, Search, Access
Methods, etc.
Design Patterns come in different levels

1. - the high level architecture is not

detailed enough and should only serve
as a guideline pattern for further
refining
2. - the middle level ones is where the
current work is focused on and may be
domain dependent
3. – The low level ones (e.g. data
structures and algorithms) have been
employed relatively successfully via
provided libraries
• A building architect named Christopher
Alexander introduced building designs
based on “patterns” in the 1970’s and
catalogued these designs in a book.
– Has not been widely accepted by building
architects
– But has influenced the software design
community in the last 15 years in terms of
cataloguing and using design patterns
 Major Architectural Styles (Patterns)

1. Layered Architecture
2. Pipe and Filter
3. Shared (Central) Data Store
4. Event Driven
5. Model-View-Controller (MVC)
 Layered architecture

Screen 1. If any layer only uses the layer directly below

Presentation layer
it, then it is a Strict Layered Style.
Logic layer
2. If a layer may use any of the layers below it,
File layer then it is a Relaxed Layer Style

Problems that seem to fit this architecture include op-sys

 Layered architecture

• The high level design solution is

decomposed into Layers:

– Structurally, each layer provides a related

set of services
– Dynamically, each layer may only use the
layers below it
• Using and evoking is not necessarily the same

– Layer A may use layer B because it depends on

something B does (e.g. data written to a db by B to
be used by A), but never call upon it.

– Layer A calls layer B says Layer A passes control or

data or both directly to B.
 Simple Example with “Mailing Address”
Processing

Country

State

City

Street

Recipient Name

Mail processing to establish which delivery plane/truck to distribute the US Postal mail
The sequence is from top layer to the lower layer.
 A Simplified “Experiential” Discussion

cust info in ord. info in prod info in Information i/o Layer

customer order product
info valid. info valid. info valid. Cust. Info
validation
... product Info
validation

add add add Information validation Layer

Add, Delete, and Update
delete delete delete
Info Processing Layer
update update update
Viewing from internal structure
Viewing and designing directly from
functional requirements Ending up with layered architecture
 Sample Layered Architecture for OS
Utilities (editors, sys commands,
compilers, internet
access, libraries, etc.)
Resource (I/O, page,
network, file, etc.)
management

kernel (Device & memory

Processing) drivers Process (classification &
management)
Sample Layered Communications Architecture

Application layer

Presentation layer

Session layer

Transport layer

Network layer

Data Link layer

Physical layer
Advantages and Disadvantages of
Layered Architecture
 Advantages

– Each layer is selected to be a set of related

services; thus the architecture provides high
degree of cohesion within the layer.
– Each layer may hide private information from
other layers
– Layers may use only lower layers, constraining
the amount of coupling.
– Each layer, being cohesive and is coupled only to
lower layers, makes it easier for reuse by others.
 Disadvantages

– Strict Layered Style may cause

performance problem depending on
the number of layers
– Debugging in Strict Layered Style
may be complex (questionable?)
– May be difficult to decide on the
number of layers
 Pipe and Filter Architecture

• Main components:

– Filter: process a stream of input data to some out put data

– Pipe: a mechanism that allows the flow of data

read input file process file

filter This architecture style focuses

on the dynamic (interaction)
rather than the structural
pipe
 Pipe-Filter architecture
• The high level design solution is decomposed into 2
parts (filters and pipes):
– Filter is a service that transforms a stream of input data into
a stream of output data

– Pipe is a mechanism or conduit through which the data

flows from one filter to another

Input Prepare for

Process Checks
time cards Check processing

Problems that require batch file processing seem to fit this: payroll and
compilers
 Pipe – Filter with error processing

• Even though interactive error processing is difficult, but batch

error processing can be done with pipe and filter architecture

Input
time cards
Splitting the good time
cards from the bad ones
Validate for
payroll processing

Manually Reprocess Automatically

Card and Cut Check Process Checks

Payroll report
Advantages and Disadvantages of
Pipe-Filter
 Advantages
– Filters are self containing processing
service that performs a specific function
thus it is fairly cohesive

– Filters communicate (pass data most of

the time) through pipes only, thus it is
constrained in coupling
 Disadvantages

– Filters processes and sends streams of data over

pipes is a solution that fits well with heavy batch
processing, but may not do well with any kind of
user-interaction.
– Anything that requires quick and short error
processing is still restricted to sending data
through the pipes, possibly making it difficult to
interactively react to error-events.
 Shared Data
• The high level design solution is based on a
shared data-store which acts as the “central
command” with 2 variations:

– Blackboard style

– Repository style
Blackboard style:
the data-store alerts the participating
parties whenever there is a data-store
change

Repository style:
the participating parties check the data-
store for changes
 Shared Data

physician Lab testing

diagnosis
Very
Patient Common
database accounting In
pharmacy & & administration Business
drug processing where
Data is
central
 Shared Data
• Problems that fit this style such as patient
processing, tax processing system, inventory
control system; etc. have the following properties:

1. All the functionalities work off a single data-store.

2, Any change to the data-store may affect all or some

of the functions

3. All the functionalities need the information from the

data-store
 Blackboard Style & DB triggers
• In database management system we can set up a trigger which
has 3 parts:
1) Event
change to the database that alerts or activates the trigger
2) Condition
a test that is true when the trigger is activated
3) Action
a procedure which is executed when the trigger is activated
and the condition is true.
1) A trigger may be thought as a monitor of the
database for changes to the database that matches
the event specification (e.g. deletion of record) .
2) Then the condition is checked to see if it is true (e.g.
deleted record has negative accnt amount).
3) If the deleted record has a negative accnt amount,
then kick off a procedure to send error message
out and delay the execution of record deletion.
Advantages and Disadvantages of
Shared Data
 Advantages

– The independent functions are cohesive

within itself and the coupling is restricted
to the shared data

– Single data-store makes the maintenance

of data in terms of back-up recovery and
security easier to manage
 Disadvantages

– (common and control coupling) Any data format change in

the shared data requires agreement and, potentially,
changes in all or some the functional areas - - this becomes
a bigger problem as more functionalities are introduced that
have dependency on the shared data.

– If the data-store fails, all parties are affected and possibly all
functions have to stop (may need to have redundant db for
this architecture style; also, should have good back up- and
recovery procedures.)
 Event-Driven
• The high level design solution is based on an event dispatcher
which manages events and the functionalities which depend on
those events. These have the following characteristics:
– Events may be a simple notification or may include associated
data (from the event announcer to the event responder)
– Events may be prioritized or be based on constraints such as time
(honored by the event dispatcher)
– Events may require synchronous or asynchronous processing
(The dispatcher may wait for the operation it invokes to return or
execute them without waiting for them to return)
– Events may be “registered” or “unregistered”
(with the event dispatcher – either arbitrary during execution or
decided when the program is coded)
 Event-Driven

voice Phone
call processing
text Personal (device)
msg dispatcher Txt
processing
Image
Image
keypad processing

Problems that fit this architecture includes real-time systems such as: airplane
control, medical equipment monitor, home monitor, embedded device controller
Advantages and Disadvantages of
Event-Driven
 Advantages

– The event sensors and the event processors are

separate, providing decoupled and individual
functionalities.
– The replacement and additions are independent
and thus easier to perform
– Any sensor or processing malfunction will not
affect the other sensors and processors
 Disadvantages

– It is difficult for the dispatcher to react to a

myriad of sensor inputs and respond in
time (especially on simultaneous inputs)
– The dispatcher is the “single grand
connector”
– A dispatcher malfunction will bring the
whole system down
 Model-View-Controller (MVC)

• The high level design solution is based

on 3 main components:
– Models
– View
– Controller
 Model-View-Controller (MVC)
– Models
the portion that handles the data model and the
logic related to the application functions
– View
the component that handles the displaying of
information to the users
– Controller
the component that handles the users needs in
terms of accepting the requests and responding
to the requests
 Model-View-Controller (MVC)

<< user interface >> << app and db>>

<<use>>
View controller model

<< user interface>> << app and db>>

<<use>>
vew model
controller

Problems that fit this architecture includes most of the interactive web-applications.
Advantages and Disadvantages of
MVC
 Advantages

– Views, controller, and model are separate

components that allow modification and change
in each “layer” without significantly disturbing
the other
– The view component, which often needs changes
and updates to keep the users continued
interests, is separate
 Disadvantages

– Heavily dependent on the development

and production system environment and
tools that match the MVC architecture
 Heterogeneous Architectures
• An architecture that employs two or
more architectural styles
Questions