Party of five 1996
From CSSEMediaWiki
(Difference between revisions)
(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...) |
Joey Scarr (Talk | contribs) (→Pattern-oriented software architecture: A system of patterns) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | |||
== Pattern-oriented software architecture: A system of patterns == | == Pattern-oriented software architecture: A system of patterns == | ||
by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal. | 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 | + | This is perhaps the second most important book in the patterns field, after the [[Gang of Four 1995]]. |
| + | |||
| + | Its main contribution was to widen the field of [[design patterns]], 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. [[Wals library]] 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. | ||
| + | |||
| + | {| | ||
| + | | [[Presentation abstraction control pattern]] || 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. | ||
| + | |- | ||
| + | | [[Model view controller pattern]] || 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. | ||
| + | |- | ||
| + | | [[Blackboard pattern]] || 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. | ||
| + | |- | ||
| + | | [[Broker pattern]] || 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. | ||
| + | |- | ||
| + | | [[Pipes and filters pattern]] || 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. | ||
| + | |- | ||
| + | | [[Microkernel pattern]] || 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. | ||
| + | |- | ||
| + | | [[Layers pattern]] || 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. | ||
| + | |- | ||
| + | | [[Reflection pattern]] || 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. | ||
| + | |||
| + | {| | ||
| + | | [[Forwarder receiver pattern]] || 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. | ||
| + | |- | ||
| + | | [[Whole part pattern]] || 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. | ||
| + | |- | ||
| + | | [[Proxy pattern]] || 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. | ||
| + | |- | ||
| + | | [[View handler pattern]] || 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. | ||
| + | |- | ||
| + | | [[Master slave pattern]] || 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. | ||
| + | |- | ||
| + | | [[Client server dispatcher pattern]] || 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. | ||
| + | |- | ||
| + | | [[Command processor pattern]] || 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. | ||
| + | |- | ||
| + | | [[Publisher subscriber pattern]] || 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. | |
| − | This | + | {| |
| + | |- | ||
| + | | [[Counted pointer pattern]] || 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]] | |
| − | + | * [[Gang of four 1995]] | |
| − | + | * [[Design patterns]] | |
| − | + | ||
Latest revision as of 03:29, 19 October 2010
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 Gang of Four 1995.
Its main contribution was to widen the field of design patterns, 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. Wals library 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.
| Presentation abstraction control pattern | 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. |
| Model view controller pattern | 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. |
| Blackboard pattern | 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. |
| Broker pattern | 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. |
| Pipes and filters pattern | 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. |
| Microkernel pattern | 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. |
| Layers pattern | 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. |
| Reflection pattern | 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.
| Forwarder receiver pattern | 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. |
| Whole part pattern | 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. |
| Proxy pattern | 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. |
| View handler pattern | 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. |
| Master slave pattern | 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. |
| Client server dispatcher pattern | 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. |
| Command processor pattern | 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. |
| Publisher subscriber pattern | 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.
| Counted pointer pattern | 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. |
