Pattern-oriented software architecture (Q2757272)
From MaRDI portal
| This is the item page for this Wikibase entity, intended for internal use and editing purposes. Please use this page instead for the normal view: Pattern-oriented software architecture |
scientific article; zbMATH DE number 1676730
| Language | Label | Description | Also known as |
|---|---|---|---|
| English | Pattern-oriented software architecture |
scientific article; zbMATH DE number 1676730 |
Statements
26 November 2001
0 references
software reuse
0 references
configuration patterns
0 references
service access
0 references
Pattern-oriented software architecture (English)
0 references
This is the second volume of the monograph entitled ``Pattern-Oriented Software Architecture'' (known under acronym POSA). This volume is devoted to concurrent and networked objects patterns. The beginners are encouraged to read the first volume presenting patterns in general. Patterns support reuse of software architecture and design.NEWLINENEWLINENEWLINEBenefits of software reuse include: increased productivity and reduced expenses during development and testing, improved system quality and reliability, reduced cost because of continued software component reuse, improved focus on core business not on software development, increased software interoperability.NEWLINENEWLINENEWLINEPatterns capture the static and dynamic structures and collaborations of successful solutions to problems that arise when building applications in a particular domain. Patterns are first of all related to middleware although they also may be used in operating systems and virtual machines. This volume is however not a handbook on middleware design but rather focuses on methodology and language for description of patterns. The emphasis is on practical solutions and examples. The volume describes comprehensively 16 patterns classified in four groups. Patterns are described according to the following schema: synonyms (if any), general characteristics, structure, examples, classes used, calling method, relations to operating systems and programming methodologies, implementations in C (C++), class, collaborator, responsibility and state transition diagram. Short descriptions of patterns given below have been taken from http://www.posa.uci.edu website, where also some additional materials may be found.NEWLINENEWLINENEWLINEService access and configuration patterns are the following: wrapper-facade, component configurator, interceptor and extension interface. The Wrapper Facade design pattern encapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces. The Component Configurator design pattern allows an application to link and unlink its component implementations at run-time without having to modify, recompile, or statically relink the application. Component Configurator further supports the reconfiguration of components into different application processes without having to shut down and re-start running processes. The Interceptor architectural pattern allows services to be added transparently to a framework and triggered automatically when certain events occur. The Extension interface design pattern allows multiple interfaces to be exported by a component, to prevent bloating of interfaces and breaking of client code when developers extend or modify the functionality of the component.NEWLINENEWLINENEWLINEThe event handling patterns are the following: reactor, proactor, asynchronous completion token and acceptor-connector. The Reactor architectural pattern allows event-driven applications to demultiplex and dispatch service requests that are delivered to an application from one or more clients. The Proactor architectural pattern allows event-driven applications to efficiently demultiplex and dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities. The Asynchronous Completion Token design pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services. The Acceptor-Connector design pattern decouples the connection and initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected and initialized.NEWLINENEWLINENEWLINEThe synchronization (or coordination) patterns are the following: scoped locking (this is an idiom included additionally), strategized locking, thread-safe interface and double checked locking optimization. The Scoped Locking C++ idiom ensures that a lock is acquired when control enters a scope and released automatically when control leaves the scope, regardless of the return path from the scope. The Strategized Locking design pattern parameterizes synchronization mechanisms that protect a component's critical sections from concurrent access. The Thread-Safe Interface design pattern minimizes locking overhead and ensures that intra-component method calls do not incur `self-deadlock' by trying to reacquire a lock that is held by the component already. The Double-Checked Locking Optimization design pattern reduces contention and synchronization overhead whenever critical sections of code must acquire locks in a thread-safe manner just once during program execution.NEWLINENEWLINENEWLINEThe concurrency patterns are the following: active object, monitor object, half-sync/half-async, leaders/followers and thread specific storage. The Active Object design pattern decouples method execution from method invocation to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control. The Monitor Object design pattern synchronizes concurrent method execution to ensure that only one method at a time runs within an object. It also allows an object's methods to cooperatively schedule their execution sequences. the Half-Sync/Half-Async architectural pattern decouples asynchronous and synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous and one for synchronous service processing. The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, and process service requests that occur on the event sources. The Thread-Specific Storage design pattern allows multiple threads to use one `logically global' access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.NEWLINENEWLINENEWLINEAfter presenting individual patterns, the relations between patterns are analyzed. Key role plays here language for patterns description. The volume includes also some remarks on organizational aspects of work on pattern development. To conlude this book is an important contribution to modern software development especially in the area of web services and e-commerce applications as well as COTS (Commercial-Of-The-Shelf) software.
0 references