Party of five 1996
(New page: == Pattern-oriented software architecture: A system of patterns == by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal. This is perhaps the second most i...) |
|||
| Line 1: | Line 1: | ||
| − | |||
== Pattern-oriented software architecture: A system of patterns == | == Pattern-oriented software architecture: A system of patterns == | ||
| Line 8: | Line 7: | ||
Its main contribution was to widen the DesignPatterns field, by adding higher level architectural patterns and lower level idioms. (Their contribution to idioms is a token effort, though.) | Its main contribution was to widen the DesignPatterns field, by adding higher level architectural patterns and lower level idioms. (Their contribution to idioms is a token effort, though.) | ||
| − | |||
| − | |||
This book is on reserve in the PSL. WalsLibrary has a copy too. | This book is on reserve in the PSL. WalsLibrary has a copy too. | ||
| + | |||
| + | === The patterns === | ||
| + | The patterns broaden the approach of [[Gang of four 1995]] by including different levels of abstraction: | ||
| + | * Architectural Patterns | ||
| + | * Design Patterns | ||
| + | * Idioms | ||
| + | |||
| + | They don't say much under the idioms category, though. | ||
| + | |||
| + | ==== PoV architectural patterns ==== | ||
| + | |||
| + | These express the basic structural organisation of a software system, by defining the subsystems into which the system is divided, their relationships and responsibilities. | ||
| + | |||
| + | || PresentationAbstractionControlPattern || This is applicable to interactive software systems, and separates the system into a hierarchy of cooperating agents. There should be one top-level PAC agent, several intermediate agents, and more bottom-level agents. The ''presentation'' element of an agent is where it displays its visible behaviour. ''Abstraction'' refers to the particular data model of this agent and the functionality which acts on it. The ''control'' component allows it to connect these other components and to communicate with other PAC agents. Different agents provide their own user interface, and have different functionality and data depending on their targetted user. || | ||
| + | || ModelViewControllerPattern || Everyone is probably familiar with this, something stressed in previous courses here at Canterbury when there has been development of systems with a GUI. The model contains the core of the system in both data and functionality terms, the view displays information, and the controllers are provided with which the user can interact. The GUI is generally composed of the view and controllers. || | ||
| + | || BlackboardPattern || A collection of independent components working on some data, and then pooling their collective knowledge to reach a best solution. An example of this could be a speech recognition system. || | ||
| + | || BrokerPattern || The broker component coordinates communication between decoupled components, something particularly relevant for distributed software systems. This is used by such platforms as Microsoft OLE and CORBA. || | ||
| + | || PipesAndFiltersPattern || This applies to systems processing a stream of data. An example of this might be how some text is parsed (tokenised, stopwords removed, maybe some noun stemming etc) for indexing. Each step takes place in a separate component (filter), and a pipe is used to pass the data along. || | ||
| + | || MicrokernelPattern || This is used for systems that have to be adaptable, by separating a minimal core with the basic functionality from extended functionality and parts that are specific to a particular customer's requirements. The core also coordinates the extensions. || | ||
| + | || LayersPattern || This is a way in which to structure software applications that can be decomposed into subtasks of different levels of abstraction.The OSI 7-Layer network model is probably the most famous example. || | ||
| + | || ReflectionPattern || This is designed to make software open to modification. It consists of two major parts: a meta level, and a base level. The meta level allows the application to know about itself, encapsulating any part of the system internals, such as data structures, that may change. The base level uses the information provided by the metal level to implement the application logic. || | ||
| + | |||
| + | ==== PoV design patterns ==== | ||
| + | |||
| + | These refine the subsystems of the software system. They are supposed to be independent of a particular programming language or paradigm. Typically tehy provide structures for decomposing complex services, or facilitate cooperation between them. | ||
| + | |||
| + | || ForwarderReceiverPattern || This assists with communication between peers. It consists of forwarders and receivers (as well as the peers, which carry out application tasks), which act to separate peers from worrying about the mechanisms of communication. || | ||
| + | || WholePartPattern || This is for the aggregation of a set of components that form one semantic unit. This might be the case where one main object is acted upon or given instructions, and has to relay these to its constiuent parts. These parts cannot be directly manipulated. || | ||
| + | || ProxyPattern || This introduces a representative to interact with clients on behalf of a server, database or system. This offers greater security, and possibly easier access and efficiency. || | ||
| + | || ViewHandlerPattern || This manages all the views of the system. Clients can open, close, and change views. Dependencies and coordination are also the responsibility of the view handler. || | ||
| + | || MasterSlavePattern || This is designed to facilitate parallel computation and fault tolerance. It consists of a master component that distributes work to identical slave components and collates their results to reach an answer. This allows a 'divide-and-conquer' approach to large computational problems.|| | ||
| + | || ClientServerDispatcherPattern || Similar to the ProxyPattern, but from a medium-level design rather than a large-scale architectural point of view, this introduces aan intermediate layer between clients and servers known as the dispatcher component. It establishes communication channels and allows clients to talk to servers by names rather than locations. || | ||
| + | || CommandProcessorPattern || This is a management pattern which sees requests upon a service separated from its actual execution. A command processor coordinates requesting objects, scheduling execution of tasks and can even provide other services, such as the storage of requests so they can be reversed later in the case of an undo action for example. || | ||
| + | || PublisherSubscriberPattern || This is based on the ObserverPattern and therefore is used when one needs to keep the state of interacting components synchronised. A publisher can tell some number of subscribers of a change of state, and they can then act on it. A subscriber can subscribe to many publishers. There is also a variant known as GateKeeper where it is applied to distributed systems. || | ||
| + | |||
| + | ==== PoV idioms ==== | ||
| + | |||
| + | These are low-level patterns that are specific to a particular programming language to address implementation issues. | ||
| + | |||
| + | || CountedPointerPattern || This is for C++, and is supposed to make memory management of dynamically-allocated shared objects easier. There is a reference counter which extends the class of some shared object, known as Body. A second class, Handle, is the only way in which clients can access body class objects. || | ||
== See also == | == See also == | ||
| − | |||
* [[Programming idioms]] | * [[Programming idioms]] | ||
* [[Gang of four 1995]] | * [[Gang of four 1995]] | ||
* [[Design patterns]] | * [[Design patterns]] | ||
Revision as of 04:50, 23 September 2008
Contents |
Pattern-oriented software architecture: A system of patterns
by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal.
This is perhaps the second most important book in the patterns field, after the GangOfFour1995.
Its main contribution was to widen the DesignPatterns field, by adding higher level architectural patterns and lower level idioms. (Their contribution to idioms is a token effort, though.)
This book is on reserve in the PSL. WalsLibrary has a copy too.
The patterns
The patterns broaden the approach of Gang of four 1995 by including different levels of abstraction:
- Architectural Patterns
- Design Patterns
- Idioms
They don't say much under the idioms category, though.
PoV architectural patterns
These express the basic structural organisation of a software system, by defining the subsystems into which the system is divided, their relationships and responsibilities.
|| PresentationAbstractionControlPattern || This is applicable to interactive software systems, and separates the system into a hierarchy of cooperating agents. There should be one top-level PAC agent, several intermediate agents, and more bottom-level agents. The presentation element of an agent is where it displays its visible behaviour. Abstraction refers to the particular data model of this agent and the functionality which acts on it. The control component allows it to connect these other components and to communicate with other PAC agents. Different agents provide their own user interface, and have different functionality and data depending on their targetted user. || || ModelViewControllerPattern || Everyone is probably familiar with this, something stressed in previous courses here at Canterbury when there has been development of systems with a GUI. The model contains the core of the system in both data and functionality terms, the view displays information, and the controllers are provided with which the user can interact. The GUI is generally composed of the view and controllers. || || BlackboardPattern || A collection of independent components working on some data, and then pooling their collective knowledge to reach a best solution. An example of this could be a speech recognition system. || || BrokerPattern || The broker component coordinates communication between decoupled components, something particularly relevant for distributed software systems. This is used by such platforms as Microsoft OLE and CORBA. || || PipesAndFiltersPattern || This applies to systems processing a stream of data. An example of this might be how some text is parsed (tokenised, stopwords removed, maybe some noun stemming etc) for indexing. Each step takes place in a separate component (filter), and a pipe is used to pass the data along. || || MicrokernelPattern || This is used for systems that have to be adaptable, by separating a minimal core with the basic functionality from extended functionality and parts that are specific to a particular customer's requirements. The core also coordinates the extensions. || || LayersPattern || This is a way in which to structure software applications that can be decomposed into subtasks of different levels of abstraction.The OSI 7-Layer network model is probably the most famous example. || || ReflectionPattern || This is designed to make software open to modification. It consists of two major parts: a meta level, and a base level. The meta level allows the application to know about itself, encapsulating any part of the system internals, such as data structures, that may change. The base level uses the information provided by the metal level to implement the application logic. ||
PoV design patterns
These refine the subsystems of the software system. They are supposed to be independent of a particular programming language or paradigm. Typically tehy provide structures for decomposing complex services, or facilitate cooperation between them.
|| ForwarderReceiverPattern || This assists with communication between peers. It consists of forwarders and receivers (as well as the peers, which carry out application tasks), which act to separate peers from worrying about the mechanisms of communication. || || WholePartPattern || This is for the aggregation of a set of components that form one semantic unit. This might be the case where one main object is acted upon or given instructions, and has to relay these to its constiuent parts. These parts cannot be directly manipulated. || || ProxyPattern || This introduces a representative to interact with clients on behalf of a server, database or system. This offers greater security, and possibly easier access and efficiency. || || ViewHandlerPattern || This manages all the views of the system. Clients can open, close, and change views. Dependencies and coordination are also the responsibility of the view handler. || || MasterSlavePattern || This is designed to facilitate parallel computation and fault tolerance. It consists of a master component that distributes work to identical slave components and collates their results to reach an answer. This allows a 'divide-and-conquer' approach to large computational problems.|| || ClientServerDispatcherPattern || Similar to the ProxyPattern, but from a medium-level design rather than a large-scale architectural point of view, this introduces aan intermediate layer between clients and servers known as the dispatcher component. It establishes communication channels and allows clients to talk to servers by names rather than locations. || || CommandProcessorPattern || This is a management pattern which sees requests upon a service separated from its actual execution. A command processor coordinates requesting objects, scheduling execution of tasks and can even provide other services, such as the storage of requests so they can be reversed later in the case of an undo action for example. || || PublisherSubscriberPattern || This is based on the ObserverPattern and therefore is used when one needs to keep the state of interacting components synchronised. A publisher can tell some number of subscribers of a change of state, and they can then act on it. A subscriber can subscribe to many publishers. There is also a variant known as GateKeeper where it is applied to distributed systems. ||
PoV idioms
These are low-level patterns that are specific to a particular programming language to address implementation issues.
|| CountedPointerPattern || This is for C++, and is supposed to make memory management of dynamically-allocated shared objects easier. There is a reference counter which extends the class of some shared object, known as Body. A second class, Handle, is the only way in which clients can access body class objects. ||
See also
* Programming idioms * Gang of four 1995 * Design patterns
