Anda di halaman 1dari 47

Architectural Patterns (Styles),

Frameworks, and Tactics


Week 3
M. Ali Babar
Practicalities actca tes
Guidelines for assignments released
First set of assignments (individuals and group) g ( g p)
released
Start working on them and ask questions if not sure
Everyone in a group by now?
Today, we will have the first group paper presentation
in the exercise class actively participate!!!
Lecture Outline ectu e Out e
Software patterns and their origin
Architectural patterns and styles what is the p y
difference?
Some common architectural patterns and their
benefits, drawbacks, and usage
Frameworks and their usage in architectural design
Architectural Tactics and their relations with patterns
Software Patterns So t a e atte s
What is a pattern?
A pattern is a solution to a problem
A pattern is an abstraction from a concrete form which keeps
recurring in specific non arbitrary contexts recurring in specific non-arbitrary contexts
From "Understanding and Using Patterns in Software
Development" Dirk Riehle and Heinz Zullighoven Development , Dirk Riehle and Heinz Zullighoven
Patterns are ways to describe best practices, good design,
and capture experience in a way that it is possible for others
hi i to reuse this experience
The goal of patterns is to create a body of literature to help
software developers resolve recurring problems encountered p g p
throughout the software development.
Driving Patterns from Core Solutions g atte s o Co e Souto s
Patterns is about core solutions
different singular solutions which look completely different on
the surface, yet have a deeper similarity
intellectual challenges of patterns is finding and isolating this intellectual challenges of patterns is finding and isolating this
core amongst all the surrounding stuff that's needed on real
projects
Patterns should have recurrence
Tried and tested
h l i b li bl i l f diff i i the solution must be applicable in lots of different situations
A well-known pattern is in the vocabulary of the profession
Pattern Origins atte O g s
Software patterns first became popular with the work
published in the book Design Patterns: Elements of published in the book Design Patterns: Elements of
Reusable Object-Oriented Software by GoF
Pattern-Oriented Software Architecture: A System of y
Patterns (also called the POSA book)
A system of patterns
Patterns for concurrent and networked objects atte s o co cu e t a d et o ed objects
Patterns for resource management
Patterns of Enterprise Software Architecture
Technology specific patterns e g J 2EE core patterns Technology specific patterns, e.g. J 2EE core patterns,
Microsoft patterns, integration patterns
Patterns for Domain Specific Applications
E b dd d li ti ft d t li fi i l Embedded applications, software product line, financial
applications
Pattern Documentation atte ocu e tato
A pattern language is a structured method of
d ibi d d i i i hi i l describing good design practices within a particular
domain (from Wikipedia)
Noticing and naming the common problems in a field Noticing and naming the common problems in a field
Describing the key characteristics of effective solutions for
meeting some stated goal
Helping the designer move fromproblemto solution in a Helping the designer move from problem to solution in a
logical way and
Allowing for many different paths through the design process
The documentation for a design pattern contains
problem that the pattern addresses, the context in which the
patternis used the suggested solution additional sections to pattern is used, the suggested solution additional sections to
provide more information, e.g. the strength and weakness of
the pattern
Patterns provide a good way of documenting design Patterns provide a good way of documenting design
Pattern Description in Pattern Repository atte esc pto atte epos to y
Observer pattern Observer pattern
Using Patterns for Quality Attributes Us g atte s o Qua ty tt butes
Single Sign On (SSO) is a typical scenario for
bili usability
SSO components observer changes to the session state
Using Observer Design Pattern to implement SSO Using Observer Design Pattern to implement SSO
Tomcats solution:
Session defines a Session creation and Session destruction
events
Single Sign On Valve component registers a
SessionListener interface with the Session
Session is the Subject and SingleSignOn is an Observer
When the session is destroyed, this session event listener is
called back The Single Sign on component can decide to called back. The Single Sign on component can decide to
log off the user from its web application
Tool Support oo Suppo t
Software Architecture Style So t a e c tectu e Stye
Architectural style is a way of classifying architecture
largely by morphological characteristics - in terms of
form, techniques, materials, etc. However it is not a
h li ti f d t di hit t l k holistic way of understanding architectural works
because of its emphasis on style.
fromWikipedia from Wikipedia
Software Architecture Style So t a e c tectu e Stye
Software architectural style (also called architectural
pattern) refers to a set of design rules that identify the
kinds of components and connectors that may be
d t t b t t th used to compose a system or subsystem, together
with local or global constraints on the way the
composition is done composition is done
M. Shaw and P. Clements
Patterns vs. Architecture Styles atte s s c tectu e Styes
GoF design patterns describe the implementation of
micro architectures micro architectures
small-scale object interactions
Architecture styles are high level structure for y g
software systems
concerned with the construction context of a whole system,
rather than just some part of a system j p y
understanding of software architecture styles allows an
engineer to make principled choices among design
alternatives
An architectural system representation is often essential to
the analysis and description of the high level properties of a
complex system
Ad ti f tt hit t t l d d Adoption of patterns vs. architecture styles depends on
an architects point of view and the scale of a system
Some Architecture Patterns (Styles) So e c tectu e atte s (Styes)
Layered Systems
Pipes and Filters
Model View Control
Data Abstraction
Blackboard
E t b d I li it I ti Event-based, Implicit Invocation
Repositories
Other Familiar Architectures Other Familiar Architectures
Distributed processes: client-server
Domain specific architecture: software product line
Layered Systems (1/2) aye ed Syste s ( / )
Context
A large system requires decomposition
A layered system is organized hierarchically, each layer
providing service to the layer above it and serving as a client providing service to the layer above it and serving as a client
to the layer below.
Layers is an architectural style that structures applications so
they can be decomposed into groups of subtasks
Benefits
D i b d i i l l f b i Design based on increasing levels of abstraction
Modularity and encapsulation
Reusability Reusability
Maintainability, changes to the function of one layer affect at
most two other layers
Layered Systems (2/2) aye ed Syste s ( / )
Drawbacks
A layering violation leads to changes to one layer resulting
in changes to every other layer, which is an expensive and
error prone proposition error prone proposition
Layering can incur overhead of performance.
Known uses
J 2EE, .Net
MySQL
Hibernate
Multi-tier internet-based applications
TCP/IP network protocol implementation TCP/IP network protocol implementation
X Window System protocols
Layered J 2EE Architecture aye ed J c tectu e
http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet_p.html
Layered .Net Architecture aye ed et c tectu e
http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet_p.html
Pipeline and Filters (1/4) pe e a d te s ( / )
Context
programs that process streams of data
each component has a set of inputs and a set of outputs.
The filters are components that processing inputs of The filters are components that processing inputs of
the pipeline
A filter may enrich, refine, or transform its input data
The pipes are the connectors
between a data source and the first filter, between filters,
and between the last filter and a data sink and between the last filter and a data sink
Pipeline and Filters (2/4) pe e a d te s ( / )
Implementation tips
Divide the functionality of the problem into a sequence of
processing steps
Define the type and format of the data to be passed along Define the type and format of the data to be passed along
each pipe
Determine how to implement each pipe connection.
Design and implement the filters
Design for robust handling of errors
Pipeline and Filters (3/4) pe e a d te s (3/ )
Benefits
Simplifies the composition of the behaviors of the individual
filters through data streams as inputs and outputs
Reusability: any two filters can be hooked together, provided y y g , p
they agree on the data that is being transmitted between
them
Maintainability: newfilters can be added to existing systems Maintainability: new filters can be added to existing systems
and old filters can be replaced by improved ones
Concurrency: Each filter can be implemented as a separate
task and potentially executed in parallel with other filters task and potentially executed in parallel with other filters
Pipeline and Filters (4/4) pe e a d te s ( / )
Drawbacks
pipe and filter systems are typically not good at handling
interactive applications
have to maintain correspondences between two separate have to maintain correspondences between two separate,
but related streams
added work for each filter to parse and unparse its data
Known uses
Unix shell
Tomcat, J Boss, Axis, Axis2 request handler/interceptor
ASP.Net
Language parser Language parser
MySQL query processor
Architecture Styles in J Boss c tectu e Styes J oss
Invocations are processed in Pipeline and Filter style
htt // d / li /jb /jB ht http://www.cse.unsw.edu.au/~yliu/jboss/jBoss.htm
Model View Controller (MVC) ode e Co t o e ( C)
What is Framework? at s a e o
A software framework is a reusable design for a
f ( b ) software system (or subsystem)
a reusable, semi-complete application that can be
specialized to produce custom applications. p p pp
Frameworks are larger modeling constructs than
architectural patterns
they are used to model the entire application or a subsystem
of the application
a mature framework contains recurring design structures that
demonstrates properties e.g. extensibility, decoupling, and
elegance
A software framework can support alternative A software framework can support alternative
architecture patterns to solve the same problem
Example Frameworks a pe a e o s
Apache Struts is an open-source framework for
developing J 2EE web applications developing J 2EE web applications.
Hibernate is an Object-relational mapping (ORM)
solution for the J ava language. g g
J avaServer Faces (J SF) is a J ava-based Web
application framework that simplifies the development
of user interfaces for J 2EE applications of user interfaces for J 2EE applications.
Eclipse is a free software / open source platform -
independent software framework for delivering IDE
environment environment
J ava Native Interface (J NI) allows J ava code running
in the J ava virtual machine (VM) to call and be called
by native applications and libraries written in other
languages, such as C, C++ and assembly.
Eclipse Plug-in Architecture c pse ug c tectu e
A plug-in in Eclipse is a component that provides a
certain type of service within the context of the Eclipse certain type of service within the context of the Eclipse
workbench
Architectural Tactics c tectu a actcs
Achievement of quality attributes relies on decisions
called tactics; Styles or pattern applies tactics called tactics; Styles or pattern applies tactics
For example, redundancy, that influences a quality For example, redundancy, that influences a quality
attribute
D i i t f ll ti f d i i d Design consists of a collection of decisions and a
collection of tactics is called an architectural strategy
Tactics may also be composed of other tactics, e.g.,
redundancy = data or computation redundancy
Patterns package tactics: a pattern that support
availability is likely using both redundancy and y y g y
synchronization tactics.
Ensuring Availability su g a ab ty
A failure occurs when a system cannot deliver a
service that is expected of that system service that is expected of that system.
A failure is an observable property of a systems A failure is an observable property of a systems
state.
A f lt i t f t h t ti l t A fault in any part of a system has a potential to
cause a failure; a system can be repaired or
recovered from a failure.
Approaches to ensuring availability may be:
Fault detection Fault detection
Fault recovery
Fault prevention
Availability Tactics a ab ty actcs
Fault Detection aut etecto
Ping/Echo
One component issues a ping and expects an echo from
another component within a predefined time
Heartbeat (dead man timer)
One component emits a heartbeat message (can also carry
data) periodically and another component listens for it
If the heartbeat fails, the originating component is assumed
to have failed and a fault correction component is notified p
Exception
One method for recognising faults is to encounter an
exception.
The exception handler typically executes in the same p yp y
process that introduces the exception
Recovery Preparation and Repair eco e y epa ato a d epa
Voting
P i d d t d i l Processes running on redundant processors send a simple
value to voter who decides about the deviant behavior
Active redundancy
All redundant components respond to events in parallel all
back ups are current switching time is the recovery time p g y
Passive redundancy
O t d t t d i f th th One component responds to events and informs the others
of state updates to be made backup may not be updated
Spare
A standby spare computing platform is configured to replace
many different failed components y p
Recovery - Reintroduction eco e y e t oducto
Shadow operation
A previously failed component may be run in shadow mode
for a short time to make sure that it mimics the behaviour of
the working components before restoring it to service the working components before restoring it to service
State resynchronisation State resynchronisation
The passive and active redundancy tactics require the
component being restored to have its state upgraded before
its return to service
Ch k i t/ llb k Checkpoint/ rollback
A checkpoint is recording of a consistent state created either
periodically or in response to specific events periodically or in response to specific events
Fault Prevention aut e e to
Removal from service
This tactic removes a component of the system from
operation to undergo some activities to prevent anticipated
failure failure
Transaction Transaction
A transaction is the bundling of several sequential steps
such that the entire bundle can be undone at once
Process monitor
Once a fault in a process has been detected, a monitoring
process can detect the non-performing process and create a
newinstance of it, initialised to some appropriate state as in new instance of it, initialised to some appropriate state as in
the spare tactic
Modifiability Tactics od ab ty actcs
Localize Change oca e C a ge
Maintain semantic coherence
R f t l ti hi ibiliti i d l Refers to relationships among responsibilities in a module
Anticipate expected changes Anticipate expected changes
Considering a set of possible future changes helps
G li th d l Generalize the module
Adjusting the input rather than the module
Limit possible options
Reduced options will reduce the effect of these modifications
Abstract common services
Prevent Ripple Effects e e t ppe ects
Hide information
D idi b t th bli & i t i f ti Deciding about the public & private information
Maintain existing interfaces Maintain existing interfaces
Adding interfaces, adding adapter, providing stubs
R t i t i ti th Restrict communication paths
Reduce the number of modules that consumes data
produced by a given modules, and reduce the number of
d t d i d l data producing modules
Use an intermediary Use an intermediary
Defer Binding Time e e d g e
Runtime registration
S t l d l P bli h/ b ib i t ti Support plug-and-play or Publish/subscribe registration
Configuration files Configuration files
Intended to set parameter at start up
P l hi Polymorphism
Allow late binding of the method calls
Component replacement
Allow load time binding
Adherence to defined protocols
Allowruntime binding of independent processes Allow runtime binding of independent processes
Performance Tactics e o a ce actcs
Resource Demand esou ce e a d
Increase computation efficiency
Improving algorithms to decrease latency
Reduce computational overhead
Remove intermediaries J ava classes instead of RMI
Manage event rate
Reduce sampling frequency for monitoring events
Control frequency of sampling
Lower frequency of requesting samples, loss of requests
Resource Management esou ce a age e t
Introduce concurrency
Concurrency can reduce blocked time for processes
Maintain multiple copies
Computations transfer computation to clients, which are
replicas of the comp tation replicas of the computation
Data Caching data: System is responsible for
synchronization of data y
Increase available resources
Faster or additional processors
Additional memory
Faster networks
Resource Arbitration esou ce bt ato
Scheduling processes, buffers, and networks
First-in/First-out or Fixed-priority scheduling
Dynamic priority scheduling
Round robin: Orders the requests and then assigns
reso rces to the ne t req est in the order resources to the next request in the order
Earliest deadline first
Static scheduling
Architectural Patterns and Tactics c tectu a atte s a d actcs
Summary Su a y
We know what are software patterns and their origin
Architectural patterns and styles had different p y
definitions but lost the distinctions
Layered, Pipe & Filter, MVC architectural patterns
Frameworks can be leveraged for rapidly building
complex and large applications
Architectural tactics are design decisions
References e e e ces
Chapter 5 of book by Bass, L., et al.
Selected material on three architectural patterns from book by
Buschman, F., et al. Buschman, F., et al.
Design Patterns (From Wikipedia)
htt // iki di / iki/D i tt %28 t i %2 http://en.wikipedia.org/wiki/Design_pattern_%28computer_scien%2
9
C 2 Core J 2EE Design Pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
Microsoft Patterns and Practices
http://msdn.microsoft.com/practices/topics/patterns/