Software Architecture
Prof.Dr.ir. F. Gielen
Architectural Patterns
Vakgroep Informatietechnologie – IBCN
What is a Pattern?
“ Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core
of the solution to that problem, in such a
way that you can use this solution a
million times over, without ever doing it
the same way twice …”

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Christopher Alexander
p. 2
Taxonomy of Patterns & Idioms
Type
Description
Examples
Idioms
Restricted to a particular language,
system, or tool
C++ list and array
processing.
Design
patterns
Capture the static & dynamic roles &
relationships in solutions that occur
repeatedly
Active Object,
Bridge, Proxy,
Façade, Visitor,
Factory,…
Architectural
patterns
Express a fundamental structural
organization for software systems that
provide a set of predefined subsystems,
specify their relationships, & include the
rules & guidelines for organizing the
relationships between them
Layers, PipeFilter, Blackboard,
MVC, Client
Server, Broker,
Dataflow, Rule
Based system,…
Optimization
principle
patterns
Document rules for avoiding common
design & implementation mistakes that
degrade performance
Avoid memory
leaks with
counting pointers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 3
C++ idioms:
Array - Tabel



Find an element in a list
C++ idiom:
for(int i = 0; i < N; i++)
Typical mistake: array index overrun
Linked List



Add or delete an element to a list.
C++ idiom: for(link t=x; t !=0; t=t->next)
Typical mistake : null pointers, memory leaks.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 4
Design Patterns

Design Patterns

Elements of Reusable
Object-Oriented Software

E. Gamma, R. Helm,
R. Johnson, J. Vlissides
(the “Gang of Four”)


Addison-Wesley, 1995
ISBN: 0-201-63361-2
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 5
Design Patterns …
“Design patterns are descriptions of
communicating objects and classes that
are customized to solve a general design
problem in a particular context”

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Gang of Four
p. 6
Design Pattern example :
Strategy
TextProcessor
searcher
text
1
search(String)

SearchAlgorithm
searchFor(String, Text)
SearchAlgorithm1
SearchAlgorithm2
searchFor(String, Text)
searchFor(String, Text)
Use the Strategy pattern when




Many related classes that differ only in their behaviour
You need different variants of an algorithm
An algorithm uses data that clients should not know about
A class defines many behaviours
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 7
From Mud to Structure
Architectural
Design
Layers
Design patterns are
applicable towards the end of
coarse-grained design when
refining and extending the
fundamental architecture of a
software system. Design
patterns are also applicable in
the detailed design stage for
specifying local design
aspects (e.g. multiple
implementations of a
component)
Pipes and filters
Blackboard
Broker
Distributed systems
Pipes and filters
Microkernel
Interactive systems
MVC
PAC
Adaptable systems
Microkernel
Reflection
Structural decomposition
Architectural patterns
Organization of work
can be used at the
beginning of coarse
Access control
grained design, when
Management
specifying the
fundamental structure of
an application (cf. first
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Communication
iteration(s) of the ADD
whole-part
master-slave
proxy
command processor
view handler
p. 8
Publisher-subscriber
Architectural patterns & ADD
1. Choose the module to decompose


Start with entire system
Inputs for this module need to be available

Constraints, functional and quality requirements
2. Refine the module





Choose architectural drivers relevant to this decomposition
Choose the architectural patterns that satisfies these drivers
Instantiate modules and allocate functionality from use cases
representing using multiple views.
Define interfaces of child modules.
Verify and refine use cases and quality scenarios.
3. Repeat for every module that needs further
decomposition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 9
Architectural Style and Patterns
Architectural Styles are recurring organisational
patterns and idioms. A style consists of key
features and rules for combining those features so
that the architectural integrity is maintained.
Benefits of Style:



Reuse: well understood solutions applied to new
problems
Common vocabulary leads to understandability
of organisation. (e.g. Client Server,broker,…)
Style specific analysis.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 10
Architectural Integrity
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 11
What Makes a Architectural Pattern?
Context

Problems
Solution
Context
A situation giving rise to a problem


General context : developing software with a
flexible human-computer interface
Specific context : managing the changepropagation in a flight simulator or avionics
system
Specifying the correct context for a pattern is difficult :
• Impossible to determine all situations
• List known context situations for a pattern can give valuable
guidance
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 12
What Makes a Architectural Pattern?
Context Problems

Solution
Problem
The recurring problem arising in that context



Requirements the solution must fulfill : e.g. Peer-to-peer interprocess communication must be efficient
Constraints you must consider : e.g. That inter-process
communication must follow a particular protocol, client has to
run on smart phones
Desirable properties the solution should have : e.g. changing
software should be easy
In the context of ADD these are quality requirements.
Constraints can be found in the feature description
Desirable properties are almost always related to modifiability and
reuse
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 13
What Makes a Architectural Pattern?

Solution
Structure with components and relationships
Run-time behavior
A pattern is a mental building block.
After applying a pattern architectures should include a particular structure
that provides for the roles specified by the pattern,
but adjusted and tailored to the specific needs of the problem at hand.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 14
Software Architecture Pattern is:

A set of component types


Topological layout of the components


configuration rules, relations
A set of semantic rules and constraints:


process, data repository, procedure
compositions have well defined meanings
A set of connectors for communication , coordination and co-operation between
components

subroutine call, sockets, message queues
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 15
Architectural Style Catalogue
Data Flow
Pipes &
Filters
Data Centered
Batch
Sequential
Blackboard
Repository
Call & Return
Independent
Components
Communicating
Processes
Layered
Object Oriented
Virtual Machines
Event Based
Systems
Interpreter
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Rule based
p. 16
Data Flow Architectures
Key

Dominated by motion of data through the system


feature:
datastreams
Pipes and Filters



Filters are independent entities (components)
incremental: output begins before input is consumed
example : Unix shell programs, compiler
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 17
Architectural Pattern: Pipes and Filters (Data Flow)
Context
•
•
Processin
g data
streams
Motion of
data
through
the
system
Problems
•
Future system enhancements should be possible
•
Small processing steps
•
Non-adjacent processing steps do not share
information
•
Different sources of input data exist
•
Present or store final results in various ways
•
Explicit storage of intermediate results for further
processing
•
You may not want to rule out multi-processing the
steps
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Solution
•
Apply the Pipes
and Filters
architectural
pattern: the tasks
of a system are
divided into
several sequential
processing steps,
connected by the
data flow through
the system
p. 18
Example : Multimedia
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 19
Architectural Style Catalogue
Data Flow
Pipes &
Filters
Data Centered
Batch
Sequential
Blackboard
Repository
Call & Return
Independent
Components
Communicating
Processes
Layered
Object Oriented
Virtual Machines
Event Based
Systems
Interpreter
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Rule based
p. 20
Data-Centered Architectures
Key Feature:


Dominated by a complex central data store,
manipulated by independent components.
Repository


Passive data store: file, database
Blackboard

Active data store: sends events to the
subscribers
–
–
Artificial Intelligence
Speech and Pattern recognition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 21
Architectural Pattern: Blackboard (Data Centered)
Context
•
Experimental domain in
which no closed
approach to a solution is
known or feasible,
different approaches for
the problem are
opportune
Problems
•
There are different algorithms
that solve partial problems
•
Employing disjoint algorithms
induces potential parallelism. If
possible you should avoid a
strictly sequential solution
Blackboard
(shared data)
•Vocabulary
Solution
•
Apply the Blackboard
architectural pattern: a
collection of independent
programs that work
cooperatively on a common
data structure
Knowledge
Knowledge
Knowledge
Source
Source
Source
•Hypothesis
•Abstraction level
Control
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 22
Architectural Pattern: Blackboard
1.
Define the problem
2.
Define the solution space for the
problem
3.
Divide the solution process into steps
4.
Divide the knowledge into specialized
knowledge sources with certain
subtasks
5.
Define the vocabulary of the blackboard
6.
Specify the control of the system
7.
Implement the knowledge sources
Example
HEARSAY II used a blackboard architecture to recognize human speech. In this case
the raw data was acoustical data which was to be transformed into a database query.
Contributors/knowledge sources existed for transforming acoustical data (level 0, wave
forms) into phonetic data (level 1, phonemes), phonetic data into lexical data (level 2,
words), lexical data into syntactical data (level 3, phrases), and syntactical data into
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 23
queries (level 4).
Architectural Pattern: Blackboard
+

Modifiability
•Individual
knowledge sources,
the control algorithm and the
central data structure are strictly
separated
•Reusable knowledge sources
•The
blackboard provides
tolerance of noisy and uncertain
conclusions as all results are just
hypotheses

Testability
•Hypotheses
are part of the
solution process

Performance
•Computational overhead
•No support for parallelism
•Difficult to establish a good
control strategy
Experimentation
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 24
Architectural Style Catalogue
Data Flow
Pipes &
Filters
Data Centered
Batch
Sequential
Blackboard
Repository
Call & Return
Independent
Components
Communicating
Processes
Layered
Object Oriented
Virtual Machines
Event Based
Systems
Interpreter
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Rule based
p. 25
Call and Return Architectures
Key

Feature
Dominated by order of computation
Examples




Abstract data types
Object Oriented
Layered
Call based Client/Server
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 26
The Evolution of Middleware
Applications
Domain-Specific
Services
Common
Middleware Services
Distribution
Middleware
Host Infrastructure
Middleware
Operating Systems
& Protocols
Hardware
Historically, mission-critical apps were
built directly atop hardware & OS
• Tedious, error-prone, & costly over
lifecycles
There are layers of middleware,
just like there are layers of
networking protocols
Standards-based COTS middleware
helps:
• Control end-to-end resources & QoS
• Leverage hardware & software technology
advances
• Evolve to new environments & requirements
• Provide a wide array of reusable, off-theshelf developer-oriented services
There are multiple COTS
middleware layers &
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
research/business
opportunities
p. 27
Architectural Pattern: Layers
Context
•
Large system
that requires
decomposition
Problems
Solution
•
Parts of the system should be exchangeable
•
Reuse low-level issues
•
No standard component granularity
•
Group similar responsibilities
•
System will be build by separated teams of
programmers
Structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
•
Layered
architectural
pattern: structure
your system into an
appropriate number
of layers and place
them on top of each
other
Dynamics
p. 28
Architectural Pattern: Layers
1.
Define the abstraction criterion
Communication protocols
2.
Determine the number of abstraction levels
3.
Name the layers and assign tasks to each of them
4.
Specify the services
5.
Refine the layering
6.
Specify the interfaces for each layer
7.
Structure individual layers
8.
Specify the communication between adjacent layers
9.
Decouple adjacent layers
FTP
TCP
IP
Ethernet
Class
Collaborator
Layer J
Layer J-1
Responsibility
Provides services used by Layer
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
J+1
p. 29
Architectural Pattern: Layers
+
-
Modifiability
Localize changes
 Prevention of ripple effect
 Defer binding time

Testability

•Unnecessary
work
•Lower efficiency
Manage input/output
Usability

Performance
Separate user interface
Reuse
of layers
Support for standardization
Dependencies are kept local
Exchangeability
Modifiability
•Cascades
of changing behavior
Difficulty of establishing the
correct granularity of layers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 30
Model-View-Controller
Context
•
Interactive
applicatio
ns with
flexible
humancomputer
interface
Problems
•
The same information is presented
differently
•
Display and behavior of the application
must reflect data manipulations
immediately
Solution
•
Apply the Model-ViewController architectural
pattern:
•
The Model contains the
core functionality and data.
•
Changes to the user interface should be
easy, and even possible at run-time
•
Views display information to
the user,
•
Supporting different ‘look and feel’
standards or porting the user interface
should not affect code in the core
application
•
Controllers handle user
input. Views and controllers
together comprise the user
interface.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 31
MVC structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 32
Architectural Pattern: Model-View-Controller
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 33
MVC analysis
+

Modifiability
•‘Pluggable’ views and controllers
•Exchangeability of ‘look and feel’

Usability
•Separate user interface
•‘Pluggable’ views
•Multiple
synchronized views of the
same model
•Framework
potential

Performance
•Inefficiency of data access in view
•Potential excessive number of
updates
•Increased complexity, sometimes
without gaining much flexibility:
 Modifiability
•An additional encapsulation of
platform dependencies may be
required
•Close coupling of views and
controllers to a model
•Difficulty of using MVC with
modern user-interface tools
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 34
Architectural Style Catalogue
Data Flow
Pipes &
Filters
Data Centered
Batch
Sequential
Blackboard
Repository
Call & Return
Independent
Components
Communicating
Processes
Layered
Object Oriented
Virtual Machines
Event Based
Systems
Interpreter
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Rule based
p. 35
Independent Components
Key


Features
Dominated by communication patterns.
Components communicate through messages.

They send data; not control.
Examples

Event systems



Implicit invocation
Announcers of events do not know which
components will be affected by the event
Communicating processes
Shaw and Garlan
Software Architecture in Practice
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 36
Broker: Broker Forwarding Pattern
Context
•
Distributed
and possible
heterogeneo
us system
with
independent
cooperating
components
Problems
Solution
•
Components should be able to access
services provided by others through
remote, location-transparent service
invocations
•
Need to exchange, add, or remove
components at run-time
•
The architecture should hide systemand implementation-specific details from
the user of components and services
•
Apply the Broker
architectural pattern: an
intermediate component
that is responsible for
coordination
communication, such as
forwarding requests, as
well as for transmitting
results and exceptions
Broker
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Client
p. 37
Server
Broker Components: CRC
Broker
Client
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Server
p. 38
Architectural Pattern: Broker
1.
Define an object model
2.
Decide which kind of
component-interoperability the
system should offer
3.
Specify the API’s the broker
component provides for
collaborating with client and
server
4.
Use proxy objects to hide
implementation details from
clients and servers
5.
CORBA
Design the broker component in
parallel with steps 3 and 4
IBM SOM/DSOM
•
Microsoft’s OLE 2.x
Specify protocol, message
buffers, directory service,
dynamic method invocation,
IDL compiler…
World Wide Web: hypertext browers such as
Netscape act as brokers and WWW servers
Vakgroep Informatietechnologie – Onderzoeksgroep
IBCNthe role of service providers
p. 39
play
Architectural Pattern: Broker
+

Modifiability
•Location
transparency
•Changeability and extensibility of
components
•Portability of a broker system (in
combination with proxy/bridge)
•Interoperability between different
broker systems
•Reusability
Testability
Performance
•Restricted
efficiency
Availability
•Lower
fault tolerance

Testability
•Many components involved
•An
application developed from
tested services is more robust and
easier to test
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 40
Broker Handle Pattern
Broker
Direct
communication: same
protocol or proxy
B3: clientServiceRequest
Client
B4: serverReply
Server
Here the proxy takes some of the broker’s responsibilities
for handling most of the communication activities
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 41
Design Pattern: Proxy
Context
•
Problems
The
configuration of
components in
distributed
systems is often
subject to
change as
requirements
evolve
Solution
•
Low-level message passing (e.g., using
sockets) is error-prone & fraught with
accidental complexity
•
Remote components should look like local
components from an application
perspective
•
i.e., ideally clients & servers should be
oblivious to communication mechanisms &
locations
Structure
Client
•
Apply the Proxy
design pattern:
provide an OO
surrogate through
which clients can
access remote
objects
Dynamics
AbstractService
service
: Client
: Proxy
: Service
service
pre-processing:
e.g.,marshaling
service
Proxy
1
1
Service
serviceInformatietechnologieservice
Vakgroep
– Onderzoeksgroep IBCN
post-processing:
p. 42
e.g., unmarshaling
Design Pattern: Proxy
+

Performance
•Enhanced efficiency and lower
cost
Modifiability
•Decoupling clients from the
location of server components
•Separation of housekeeping
code from functionality

Performance
•Less
efficiency due to indirection
(additional layer of indirection, usually
negligible compared with the cleaner
structure of clients and the gain of
efficiency through caching or lazy
construction…)
•Overkill via sophisticated strategies,
they do not always pay
Examples:
Firewall proxy, cache proxy, …
World Wide Web proxy describes aspects of the CERN HTTP server that typically runs
on a firewall machine. It gives people inside the firewall concurrent access to the outside
world.Vakgroep
Efficiency
is increased by caching recently transferred files (combination of p. 43
Informatietechnologie – Onderzoeksgroep IBCN
different proxy types!!!)
Example: Java RMI


Remote Method Invocation (RMI) is a Java
mechanism similar to RPCs.
RMI allows a Java program on one machine to
invoke a method on a remote object.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 44
Stub &skeleton implementation.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 45
Broker Proxies
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 46
Broker Pattern Revisited: Proxy
Server Proxy
Client Proxy
marshal
unmarhal
receive_result
service_p
* calls
1
Client
Structure
*
1
Broker
message main_loop
exchange srv_registration
srv_lookup
xmit_message
manage_QoS
call_service_p
start_task
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
marshal
unmarshal
dispatch
receive_request
1
*
* calls
message
exchange
1
Server
start_up
main_loop
service_i
p. 47
Broker Pattern Revisited: Proxy
: Client
: Client Proxy
operation (params)
: Server Proxy
: Server
register_service
connect
marshal
Dynamics
: Broker
start_up
assigned
port
send_request
unmarshal
dispatch
operation (params)
receive_reply
result
marshal
unmarshal
result
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 48
Event Based Systems




Individual components announce data that they wish to
share with other components: Publish.
Other components can register an interest in a class of
data: Subscribe.
Typically involves a message manager that controls
communication between components
Example: debuggers, databases, brokers
Subscribe
Message
Manager
Publish
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 49
Publisher-Subscriber
Context
•
Problems
I/O driven message
based application
•
Complex
dependencies
•
Real-time constraints
Solution
•
Hard to schedule
•
Expensive to evolve
•
Scalability
•
Apply the PublisherSubscriber pattern to
distribute periodic, I/O-driven
data from a single point of
source to a collection of
consumers
Structure
Publisher
produce
Event Channel
attachPublisher
detachPublisher
attachSubscriber
detachSubscriber
pushEvent
creates
*
Event
Dynamics
Subscriber
: Publisher
: Event Channel
: Subscriber
attachSubscriber
consume
produce
: Event
pushEvent
event
pushEvent
event
receives
consume
Filter
filterEvent
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
detachSubscriber
p. 50
Publisher-Subscriber: Avionics example
Considerations for implementing the Publisher-Subscriber
pattern for mission computing applications include:
•
Event notification model
•
Push control vs. pull data interactions
•
Scheduling & synchronization strategies
e.g., priority-based dispatching & preemption
•
Event dependency management
e.g.,filtering & correlation mechanisms
Airforce fighter jet uses the Publisher-Subscriber pattern to
decouple sensor processing from mission computing operations
• Anonymous publisher & subscriber relationships
• Group communication
• Asynchrony
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 51
Publisher-Subscriber: example
Subscribers
HUD
WTS
Air
Frame
NAV
5: Subscribers
perform
avionics
operations
push(event)
4: Event Channel
pushes events
to subscribers(s)
Event
Channel
push(event)
Publishers
GPS
IFF
FLIR
3: Sensor
publishers
push events
to event
channel
2: I/O via
interrupts
Board 1
1553
Board 2
VME
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
1: Sensors
generate
data
p. 52
Architectural Style Catalogue
Data Flow
Pipes &
Filters
Data Centered
Batch
Sequential
Blackboard
Repository
Call & Return
Independent
Components
Communicating
Processes
Layered
Object Oriented
Virtual Machines
Event Based
Systems
Interpreter
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Rule based
p. 53
Virtual Machine
Key Features

Characterized by translation of one instruction
set into another.
Examples

Interpreters


Style that simulates functionality that is not native
to the hardware.
Rule based systems

A means of codifying problem solving know-how of
human experts.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 54
Interpreter




Components are the interpretation engine, memory
that contains the program, the control state of the
engine and state of the program.
Example : Java Virtual Machine
GOAL: achieve portability
Performance cost due to additional computations
Input
Data
Program
(program state)
Data
Output
State Data
Program Instruction
Updates
Interpretation
Engine
(being interpreted)
Selected Instruction
Selected Data
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Internal
State
p. 55
Rule Based Architecture




Components are essential the same as in the
interpreter style.
Execution and sequence of rules is not predetermined
but condition driven -> interpreter.
Makes heavy use of pattern matching.
Example: Flight simulator
Knowledge Base
Inputs
Working
Memory
Data
Outputs
State Data
Rule
Base
Fact
Memory
Updates
Rule
Interpreter
Selected Rule
Selected Data
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Rule and Data
Selection
p. 56
Exercise: Medical Imaging
Context
In large-scale electronic
medical imaging systems,
radiologists may share “work
lists” of patient images to
balance workloads effectively
Radiology
Client
Radiology
Client
Problem
•Having each client call a specific server is
inefficient & non-scalable
• A “polling” strategy leads to performance
bottlenecks
• Work lists could be spread across
different servers
• More than one client may be interested
in work list content
Radiology
Client
Image
Database
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Radiology
Client
Radiology
Client
p. 57
Decoupling Suppliers & Consumers
Solution
•Apply the Publisher-Subscriber architectural pattern
(P1) to decouple image suppliers from consumers
Decouple suppliers (publishers) &
consumers (subscribers) of events:
Publisher
produce
Event Channel
attachPublisher
detachPublisher
attachSubscriber
detachSubscriber
pushEvent
creates
*
Event
Subscriber
• An Event Channel stores/forwards events
consume
• Publishers create events & store them in a
queue maintained by the Event Channel
• Consumers register with event queues,
from which they retrieve events
• Events are used to transmit state change
info from publishers to consumers
receives
Filter
filter
• For event transmission push-models & pullmodels are possible
• Filters can filter events for consumers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 58
Applying the Publisher-Subscriber Pattern
• Radiologists can subscribe to an
event channel to receive
notifications produced when
modalities publish events
indicating the arrival of new
images & studies
Modality
produce
• This design enables a group of
distributed radiologists to
collaborate effectively in a
networked environment
Radiology
Event Channel
attachPublisher
detachPublisher
attachSubscriber
detachSubscriber
pushEvent
creates
*
Event
Radiologist
consume
receives
Filter
filter
Client
Radiology
Client
Radiology
Client
Event
Channel
Image
Database
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Radiology
Client
Radiology
Client
p. 59
Pattern: Inter-relationships

In many cases patterns are NOT atomic




Applying a pattern creates new contexts
Applying a pattern creates new problems and trade-offs
Applying a pattern creates new solutions
In many cases several patterns need to
collaborate in order to solve a problem

E.g. the broker pattern (distributed system) typically leads to
the introduction of the proxy pattern (access control) and
bridge pattern (service variation)
If the ADD method is applied appropriately it should be clear which pattern to
use when and where:
System  subsystem  module  submodule
e.g. Broker  proxy/bridge …
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 60
Pattern Systems – No Pattern is an Island
Patterns have to be organized in patterns
systems




Patterns exist in mane ranges of scales and abstraction
Can be applied in different phases of software development
Address a variety of different problems
Exhibit different relationships with each other
A patterns system is an organized set of
patterns





Describes all patterns uniformly
Supports a useful overview
Supports selection by means of appropriate search strategy
Provides a set of guidelines
Supports its own evolution
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 61
Heterogeneous Architecture Style
Layered
Component
Objects
Method Call
Pipe
Filter
Pipe
Filter
Filter
RPC
Subscribe
RDBMS
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 62
From Mud to Structure
Architectural
Design
Layers
Design patterns are
applicable towards the end of
coarse-grained design when
refining and extending the
fundamental architecture of a
software system. Design
patterns are also applicable in
the detailed design stage for
specifying local design
aspects (e.g. multiple
implementations of a
component)
Pipes and filters
Blackboard
Broker
Distributed systems
Pipes and filters
Microkernel
Interactive systems
MVC
PAC
Adaptable systems
Microkernel
Reflection
Structural decomposition
Architectural patterns
Organization of work
can be used at the
beginning of coarse
Access control
grained design, when
Management
specifying the
fundamental structure of
an application (cf. first
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Communication
iteration(s) of the ADD
whole-part
master-slave
proxy
command processor
view handler
p. 63
Publisher-subscriber
Pattern Systems: The architect’s toolbox !
The architecture – design pattern system is
useful in the context of ADD



Even the most comprehensive pattern system will not
cover every problem area of a software architecture
Pattern systems evolve constantly, based on the
experience of the architect
The pattern system for a software architect, active in
concurrent and networked systems will be totally different
(e.g. half-sync/half-async or leader/followers concurrency
patterns aren’t mentioned here…)
The pattern system should be a toolbox in function of the
application domain that the architect is working in
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 64