Software Architecture Styles (Patterns)- (chapter 15)

advertisement
Architecture
•
Architecture is a high level description of a
solution to a problem
•
Recall architecture (high level design) includes:
1. Main Components
–
functionalities (responsibilities) and properties of
components
2. Major Relations
–
–
components collaborating among the components
sometimes include the interface
Architectural Style
•
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 Style” is a High Level Design Pattern
Architectural Styles (Patterns)
•
Architectural Styles may be viewed as a set of
Architectural Design “solutions” that have been
used successfully before.
•
These styles (or patterns) offer multiple benefits:
1.
2.
3.
4.
5.
Promotes communications among the designers because
the pattern names are used as a shorthand for a lengthy
description
Streamlines documentation for the same reason above
Supports high level of reuse if the pattern is applicable
Improves development efficiency and productivity for
above reasons and not having to profile or prototype all
the existing patterns
Provide a starting point for additional and new design
ideas.
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.
Software Design Patterns
• Software Design Patterns is a recent event, although
programming level “patterns” have been studied in our industry
such as Sorts, Search, Access Methods, etc.
• 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.
My personal thoughts:
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 refinement
2. - the middle level ones is where the current work is focused on
and may be domain dependent
3. - low level ones (e.g. data structures and algorithms) have been
employed relatively successful via provided code libraries
Major Architectural Styles (Patterns)
1.
2.
3.
4.
5.
Layered Architecture
Pipe and Filter
Shared (Central) Data Store
Event Driven
Model-View-Controller (MVC)
6. “Distributed & Emerging” Service Oriented
Architecture (SOA)
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 (evoke) the layers
below it
• Using and evoking is not necessarily the same
(subtle difference))
– 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 evokes layer B says Layer A passes control or data or
both directly to B.
Screen
Presentation layer
1. If any layer only uses the layer directly below
it, then it is a Strict Layered Style.
Logic layer
File layer
2. If a layer may use any of the layers below it,
then it is a Relaxed Layer Style
Problems that seem to fit this architecture include tele-comm and op-sys
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.
This same scheme is often used in communications protocol architecture
“Sample” Layered Communications Architecture
Application layer
Presentation layer
Session layer
Transport layer
Network layer
Data Link layer
Physical layer
A Simplified “Experiential” Discussion
cust info I/O
customer
info valid.
ord. info I/O prod info I/O
order
product
info valid.
info valid.
add
delete
update
add
delete
update
add
delete
update
Viewing and designing directly from
functional requirements
Information I/o Layer
Cust. Info
validation
...
product Info
validation
Information validation Layer
Add, Delete, and Update
Info Processing Layer
Viewing from internal structure
and form; then designing with
“commonality” in mind
Ending up with layered architecture
Discuss - - Pros and Cons in class:
modularity; coupling; cohesion
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)
How many of the layers would we need to worry about
---- for the currently popular “security” issue ?
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 and easier to be replaced or
interchanged (change of DB touches only the data store/access layer,
change of browser only changes the presentation layer of the previous
slide) ---- good for component design
• 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
I beg to differ
Pipe and Filter Architecture
• Main components:
– Filter: process the a stream of input data and turn into some
output data
– Pipe: a conduit that allows the flow of data
read input file
process file
filter
pipe
This architecture style also focuses
on the “flow” (dynamics)
rather than just the structural
Pipe and Filter : UNIX Influence
• UNIX command line processing of the pipe symbol, l
- the output from the command to the left of the symbol, l, is
to be sent as input to the command to the right of the pipe;
- this mechanism got rid of specifying a file as std output of a
command and then specifying that same file as the std input
to another command, including possibly removing this
intermediate file afterwards
Example ( UNIX commands) :
Example :
Assume that in the file called my.txt is
the following:
I live in
the city
of Atlanta
$ cat my.txt
I live in
the city
of Atlanta
$ cat my.txt I sed “s/i/o/g”
I love on
the coty
of Atlanta
$
Note the pipe
symbol, l
First cat command outputs my.txt to screen. The second cat command reads my.txt and
sends it to sed command which “search” for “i’ and “globally” replace it with “o.”
More Modern Version of Pipe-filter
• Consider the MS Office Product
• Specifically --- think about how the
component called “copy” works in
conjunction with the component called
“paste” across office product (e.g. spread
sheet to word document )
How may this be extended to the way e-mail with file attachment work?
Pipe-Filter architecture & Batch Processing
• 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
time cards
Prepare for
Check processing
Process Checks
Problems that require batch file processing seem to fit this architecture:
e. g. 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
Input Validation
[invalid]
[valid]
Manually Reprocess
Card and Cut Check
Automatically
Process Checks
Payroll report
Do the data streams
need to be synchronized
here for 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 “somewhat” 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: the data-store alerts the participating
parties whenever there is a data-store change (trigger)
– Repository style: the participating parties check the datastore for changes
Lab testing
physician
diagnosis
Patient
database
pharmacy &
drug processing
accounting
& administration
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
** Very
Common
In
Business
where
Data is
Central **
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. debit of bank cust. accnt)
2) Then the “condition” is checked to see if it is true (e.g. debited cust account
results in negative bank accnt amount).
3) If the debited account has a negative accnt amount, then kick off a procedure
to send error message out and delay the execution of cust account debiting.
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 through data) 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. (e.g. popular commercial
product such as CRM or ERP)
– ** If the data-store fails, all parties are affected and possibly all
functions have to stop** (may need to have 1) redundant db for
this architecture style; also, should have 2) good back up- and
recovery procedures.)
Event-Driven (Realtime)
• The high level design solution is based on an event dispatcher
which manages events and the functionalities which depends
on those events. These have the following characteristics:
– Events may be a simple notification or may include associated
data
– Events may be prioritized or be based on constraints such as time
– Events may require synchronous or asynchronous processing
– Events may be “registered” or “unregistered” by components
Phone
processing
voice
call
text
msg
Personal (device)
dispatcher
Txt
processing
Image
keypad
Image
processing
Problems that fit this architecture includes real-time systems such as: aviation control;
medical equipment monitor; home monitor; embedded device controller; game; etc.
- - - try a commercial flight control system - - -
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 !!
– Dispatcher is very much performance gated (must be fast --may be able to use a queue in some cases)
Model-View-Controller (MVC)
• The high level design solution is based on 3 main components:
– Models: the portion that handles the data model and the data 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
<< app>>
<< user interface >>
controller
View
<< user interface>>
vew
<< db>>
model
<< app and db>>
controller
model
Problems that fit this architecture includes most of the inter-active web-applications.
--Discuss how this can be “adapted” to be shared data, event-driven or layered architecture--
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 (UI
technology improvement) and updates to keep the users
continued interests, is separate
– The View-Controller can keep on partially functioning even if
the model component is down.
• Disadvantages:
– Heavily dependent on the development and production
system environment and tools that match the MVC
architecture (e.g. TomCat, .Net, Rail, etc.)
Further Discussion on Software Architecture
We have introduced 5 different software architectural style which described
- the layout of the major components
- the interaction among the components
How do you decide on what should be your major components and the layout?
Who provides the mechanisms for the component interactions?
Software Connectors for networked services
• Software connectors form a discrete architectural
element that represent a set of mechanisms that
enable & mediate component interactions:
– Communications: support transmission of data among
components
– Coordination: support transfer of control among
components
– Conversion: converts the interaction interface required by
one component to that provided by another component
– Facilitation: manage the interaction among the components
from deadlocking, from overflow, from unauthorized access,
etc.
This is a relatively new field and these definitions are still under study
A Sample High Level Component Architecture
App
Comp
App
Comp
...
App
Comp
...
App
Comp
Component Framework
Component Framework
The component framework and the arrows
in this diagram represent the functionalities
of software connectors.
Examples: DCOM (Microsoft), CORBA (OMG),
.NET (Microsoft), etc.
Service Oriented Architecture (SOA)
“currently (~ 2010) popular & emerging”
•
An architecture that is composed mainly of three
“layers”:
1.
2.
3.
Networked IT infrastructure (bottom layer)
Independently developed software & services (middle
layer)
Coordinated business processes (top layer)
•
A distributed architecture based on
http/SOAP/WSDL networked services.
•
The services are described using XML language to
ensure that:
–
–
The business process and procedures match
The exchange of data and the format of the data match
SOAP – Simple Object Access Protocol for exchanges of structured info
WSDL – Web Service Definition Language for defining web services
Download