Upload
tracy
View
36
Download
0
Embed Size (px)
DESCRIPTION
Software Architecture Prof.Dr.ir. F. Gielen. Architectural Patterns. What is a Pattern?. - PowerPoint PPT Presentation
Citation preview
Vakgroep Informatietechnologie – IBCN
Software ArchitectureProf.Dr.ir. F. Gielen
Architectural Patterns
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
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 …”
Christopher Alexander
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
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, Pipe-Filter, 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. 4
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. 5
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. 6
Design Patterns …
“Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context”
Gang of Four
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
Design Pattern example : Strategy
searcherSearchAlgorithm
searchFor(String, Text)
SearchAlgorithm2
searchFor(String, Text)
SearchAlgorithm1
searchFor(String, Text)
TextProcessor
text
search(String)1
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. 8
Architectural Design
From Mud to Structure Layers
Pipes and filters
Blackboard
Broker
Distributed systems Pipes and filters
Microkernel
Interactive systems MVC
PAC
Adaptable systems Microkernel
Reflection
Structural decomposition whole-part
Organization of work master-slave
Access control proxy
Management command processor
view handler
Communication Publisher-subscriber
Forwarder-Receiver
Architectural patterns can be used at the beginning of coarse grained design, when specifying the fundamental structure of an application (cf. first iteration(s) of the ADD method)
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)
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
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. 10
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. 11
Architectural Integrity
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
What Makes a Architectural Pattern?
ContextA situation giving rise to a problem
General context : developing software with a flexible human-computer interface
Specific context : managing the change-propagation 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
Context Problems Solution
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
What Makes a Architectural Pattern?
ProblemThe recurring problem arising in that context
Requirements the solution must fulfill : e.g. Peer-to-peer inter-process 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
Context Problems Solution
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14
What Makes a Architectural Pattern?
SolutionStructure 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. 15
Software Architecture Pattern is:
A set of componentcomponent types process, data repository, procedure
TopologicalTopological layout of the components configuration rules, relations
A set of semanticsemantic rules and constraints: compositions have well defined meanings
A set of connectorsconnectors for communication , co-ordination and co-operation between components
subroutine call, sockets, message queues
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
Architectural Style Catalogue
Data Centered
Blackboard Repository
Independent
Components
Communicating
Processes
Event Based
Systems
Call & Return
Layered Object Oriented
Virtual Machines
Interpreter Rule based
Data Flow
Pipes &
Filters
Batch
Sequential
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
Data Flow Architectures
Key feature: Dominated by motion of data through the system
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. 18
Architectural Pattern: Pipes and Filters (Data Flow)
Context Problems Solution• Processin
g data streams
• Motion of data through the system
• 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
• 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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
Example : Multimedia
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
Architectural Style Catalogue
Data Centered
Blackboard Repository
Independent
Components
Communicating
Processes
Event Based
Systems
Call & Return
Layered Object Oriented
Virtual Machines
Interpreter Rule based
Data Flow
Pipes &
Filters
Batch
Sequential
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21
Data-Centered Architectures
Key Feature: Dominated by a complex central data store,
manipulated by independent components. RepositoryRepository
Passive data store: file, database
BlackboardBlackboard Active data store: sends events to the
subscribers– Artificial Intelligence
– Speech and Pattern recognition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
Architectural Pattern: Blackboard (Data Centered)
Context Problems Solution• Experimental domain in
which no closed approach to a solution is known or feasible, different approaches for the problem are opportune
• There are different algorithms that solve partial problems
• Employing disjoint algorithms induces potential parallelism. If possible you should avoid a strictly sequential solution
• Apply the Blackboard architectural pattern: a collection of independent programs that work cooperatively on a common data structure
Blackboard
(shared data)•Vocabulary
•Hypothesis
•Abstraction level
Control
Knowledge
Source
Knowledge
SourceKnowledge
Source
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
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 sourcesExample
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 queries (level 4).
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
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
Experimentation
- Testability•Hypotheses are part of the solution process
Performance•Computational overhead•No support for parallelism•Difficult to establish a good control strategy
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25
Architectural Style Catalogue
Data Centered
Blackboard Repository
Independent
Components
Communicating
Processes
Event Based
Systems
Call & Return
Layered Object Oriented
Virtual Machines
Interpreter Rule based
Data Flow
Pipes &
Filters
Batch
Sequential
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
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. 27
The Evolution of Middleware
There are multiple COTS middleware layers & research/business
opportunities
Historically, mission-critical apps were built directly atop hardware• Tedious, error-prone, & costly over lifecycles
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-the-shelf developer-oriented services
There are layers of middleware, just like there are layers of networking protocols
Hardware
Domain-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
& OS
Operating Systems & Protocols
Applications
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
Architectural Pattern: LayersContext Problems Solution• Large system
that requires decomposition
• 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
• Layered architectural pattern: structure your system into an appropriate number of layers and place them on top of each other
Structure Dynamics
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29
Architectural Pattern: Layers
Communication protocols
Ethernet
IP
TCP
FTP
Class Collaborator
Layer J Layer J-1
Responsibility
Provides services used by Layer J+1
Delegates subtasks to Layer J-1
1. Define the abstraction criterion
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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30
Architectural Pattern: Layers
+Modifiability Localize changes Prevention of ripple effect Defer binding time
Testability Manage input/output
Usability Separate user interface
Reuse of layersSupport for standardizationDependencies are kept localExchangeability
-
Performance•Unnecessary work•Lower efficiency
Modifiability •Cascades of changing behaviorDifficulty of establishing the correct granularity of layers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 31
Model-View-Controller
Context Problems Solution
• Interactive applications with flexible human-computer interface
• The same information is presented differently
• Display and behavior of the application must reflect data manipulations immediately
• Changes to the user interface should be easy, and even possible at run-time
• Supporting different ‘look and feel’ standards or porting the user interface should not affect code in the core application
• Apply the Model-View-Controller architectural pattern:
• The Model contains the core functionality and data.
• Views display information to the user,
• Controllers handle user input. Views and controllers together comprise the user interface.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32
MVC structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33
Architectural Pattern: Model-View-Controller
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 34
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. 35
Architectural Style Catalogue
Data Centered
Blackboard Repository
Independent
Components
Communicating
Processes
Event Based
Systems
Call & Return
Layered Object Oriented
Virtual Machines
Interpreter Rule based
Data Flow
Pipes &
Filters
Batch
Sequential
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 36
Independent Components
Key Features Dominated by communication patterns. Components communicate through messages.
They send data; notnot control.
Examples Event systems
Implicit invocation Announcers of events do not know which
components will be affected by the event
Communicating processes
Shaw and GarlanSoftware Architecture in Practice
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 37
Broker: Broker Forwarding PatternContext Problems Solution
• Distributed and possible heterogeneous system with independent cooperating components
• 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 system- and 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
Client Server
1: clientRequest
4: forw
ardedReply
2: forwardedRequest3: serverReply
BrokerBroker
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 38
Broker Components: CRC
Client Server
BrokerBroker
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 39
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. Design the broker component in parallel with steps 3 and 4
• Specify protocol, message buffers, directory service, dynamic method invocation, IDL compiler…
CORBA
IBM SOM/DSOM
Microsoft’s OLE 2.x
World Wide Web: hypertext browers such as Netscape act as brokers and WWW servers play the role of service providers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 40
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•An application developed from tested services is more robust and
easier to test
-Performance•Restricted efficiency
Availability•Lower fault tolerance
Testability•Many components involved
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 41
Broker Handle Pattern
B2: serviceH
andle
Client Server
B1: clientBrokerRequest
R2: registrationAckR1: registerService
B3: clientServiceRequest
B4: serverReply
Direct communication: same
protocol or proxy
Here the proxy takes some of the broker’s responsibilities for handling most of the communication activities
BrokerBroker
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 42
Design Pattern: Proxy
Context Problems Solution
• The configuration of components in distributed systems is often subject to change as requirements evolve
• 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
• Apply the Proxy design pattern: provide an OO surrogate through which clients can access remote objects
Proxy
service
Client
Service
service1 1
AbstractService
service: Service: Proxy: Client
service
service
pre-processing: e.g.,marshaling
post-processing: e.g., unmarshaling
Structure Dynamics
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 43
Design Pattern: Proxy
+ Performance•Enhanced efficiency and lower costModifiability•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. Efficiency is increased by caching recently transferred files (combination of different proxy types!!!)
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 44
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. 45
Stub &skeleton implementation.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 46
Broker Proxies
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 47
Broker Pattern Revisited: Proxy
message exchange
message exchange
*
marshalunmarhalreceive_resultservice_p
Client Proxy
calls*
*
call_service_pstart_task
Client
1
marshalunmarshaldispatchreceive_request
Server Proxy
calls*
start_upmain_loopservice_i
Server
1
1
main_loopsrv_registrationsrv_lookupxmit_messagemanage_QoS
Broker1
Structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 48
Broker Pattern Revisited: Proxy
Dynamics
operation (params)connect
send_requestmarshal
unmarshal
dispatchoperation (params)
result
marshalreceive_reply
unmarshal
result
start_upregister_service
assigned port
: Broker: Client Proxy : Server Proxy: Client : Server
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 49
Event Based Systems
Individual components announce data that they wish to
share with other components: PublishPublish. Other components can register an interest in a class of
data: SubscribeSubscribe. Typically involves a message manager that controls
communication between components Example: debuggers, databases, brokers
MessageMessage
ManagerManager
Publish
Subscribe
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 50
Context Problems Solution
• I/O driven message based application
• Complex dependencies
• Real-time constraints
• Hard to schedule
• Expensive to evolve
• Scalability
• Apply the Publisher-Subscriber pattern to distribute periodic, I/O-driven data from a single point of source to a collection of consumers
Publisher-Subscriber
attachSubscriber
produce
pushEventevent
eventpushEvent
consume
detachSubscriber
: Event
: Subscriber: Event Channel: Publisher
Dynamics
Event*
Subscriber
consume
creates receives
Event Channel
attachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent
Filter
filterEvent
Publisher
produce
Structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 51
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. 52
Publisher-Subscriber: example
VME
1553
1: Sensors generate data
Board 2
2: I/O via interrupts
4: Event Channel pushes events to subscribers(s)
5: Subscribers perform avionics operations
GPS IFF FLIR
HUD
NAV
WTS
Air Frame
Publishers
Subscribers
push(event)
push(event)
Event Channel
3: Sensor publishers push events to event channel
Board 1
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 53
Architectural Style Catalogue
Data Centered
Blackboard Repository
Independent
Components
Communicating
Processes
Event Based
Systems
Call & Return
Layered Object Oriented
Virtual Machines
Interpreter Rule based
Data Flow
Pipes &
Filters
Batch
Sequential
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 54
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. 55
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 portabilityportability Performance cost due to additional computations
Interpretation
Engine
Data(program state)
Program(being interpreted)
Internal
State
Input
Output
Program Instruction
Selected Instruction
Selected Data
State Data
Data Updates
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 56
Rule Based Architecture
RuleRule
InterpreterInterpreter
Working
Memory
Rule
Base
Rule and Data
Selection
Inputs
Outputs
Knowledge BaseKnowledge Base
Selected Rule
Selected Data
State Data
Data Updates
Fact
Memory
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
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 57
Exercise: Medical ImagingProblem• 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
ContextIn large-scale electronic medical imaging systems, radiologists may share “work lists” of patient images to balance workloads effectively
ImageDatabase
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient Radiology
ClientRadiology
Client
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 58
Decoupling Suppliers & Consumers
Decouple suppliers (publishers) & consumers (subscribers) of events:
• An Event Channel stores/forwards events
• 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
• For event transmission push-models & pull-models are possible
• Filters can filter events for consumers
Event
*
Subscriber
consume
creates receives
Event Channel
attachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent
Filter
filter
Publisher
produce
Solution• Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers
Solution• Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 59
Applying the Publisher-Subscriber Pattern
Event
*
Radiologist
consume
creates receives
Event ChannelattachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent
Filter
filter
Modality
produce
ImageDatabase
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
RadiologyClient
EventChannelEvent
Channel
• Radiologists can subscribe to an event channel to receive notifications produced when modalities publish events indicating the arrival of new images & studies
• This design enables a group of distributed radiologists to collaborate effectively in a networked environment
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 60
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. 61
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. 62
Heterogeneous Architecture Style
Filter Filter FilterPipe Pipe
Subscribe
RDBMS
RPC
Objects
Method Call
Layered
Component
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 63
Architectural Design
From Mud to Structure Layers
Pipes and filters
Blackboard
Broker
Distributed systems Pipes and filters
Microkernel
Interactive systems MVC
PAC
Adaptable systems Microkernel
Reflection
Structural decomposition whole-part
Organization of work master-slave
Access control proxy
Management command processor
view handler
Communication Publisher-subscriber
Forwarder-Receiver
Architectural patterns can be used at the beginning of coarse grained design, when specifying the fundamental structure of an application (cf. first iteration(s) of the ADD method)
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)
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 64
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