Sa 008 patterns
•Als PPT, PDF herunterladen•
2 gefällt mir•944 views
The document discusses architectural patterns. It defines what patterns are and provides a taxonomy of patterns including idioms, design patterns, and architectural patterns. Architectural patterns express fundamental structural organizations for software systems and include patterns like layers, pipes and filters, and blackboard. The rest of the document describes various architectural styles and provides examples of architectural patterns within each style.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Sa 008 patterns
Ähnlich wie Sa 008 patterns (20)
Mehr von Frank Gielen
Mehr von Frank Gielen (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Sa 008 patterns
- 1. Software Architecture Architectural Patterns Vakgroep Informatietechnologie – IBCN
- 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. 2
- 3. Taxonomy of Patterns & Idioms Type Description Examples Idioms Restricted to a particular language, C++ list and array system, or tool processing. Design Capture the static & dynamic roles & Active Object, patterns relationships in solutions that occur Bridge, Proxy, repeatedly in a design context. Façade, Visitor, Factory,… Architectural Express a fundamental structural Layers, Pipe- patterns organization for software systems that Filter, Blackboard, provide a set of predefined subsystems, MVC, Broker, specify their relationships, & include the Microkernel, rules & guidelines for organizing the Reflection… relationships between them Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
- 4. Architectural Design From Mud to Structure Layers Design patterns are applicable Pipes and filters towards the end of coarse- Blackboard grained design when refining and extending the fundamental Broker architecture of a software Distributed systems Pipes and filters system. Design patterns are also applicable in the detailed Microkernel design stage for specifying Interactive systems MVC local design aspects (e.g. PAC multiple implementations of a component) Adaptable systems Microkernel Reflection Structural decomposition Architectural patterns Whole-part Organization of work can be used at the Master-Slave beginning of coarse Access control grained design, when Proxy Management specifying the Command processor fundamental structure of View handler an application (cf. first Communication Informatietechnologie – Onderzoeksgroepof the ADD Vakgroep iteration(s) IBCN Publisher-subscriberp. 4 method) Forwarder-Receiver
- 5. What Makes a Architectural Pattern? Context Problems Solution Context A situation giving rise to a problem Developing software systems with a flexible user interface Transforming data flows in real time Processing events in sensornetworks Specifying the correct context for a pattern is difficult : • Impossible to determine all situations • Known context situations for a pattern give valuable guidance Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
- 6. What Makes a Architectural Pattern? Context Problems Solution Problem The recurring problem arising in that context Requirements the solution must fulfill Constraints you must consider : e.g. Use a particular communication middleware: Corba Need to run on specific OS: Linux. Desirable properties the solution should have : e.g. changing software should be easy In the context of ADD these are -Functional requirements -Quality Requirements. -Design Constraints Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
- 7. What Makes a Architectural Pattern? Context Problems Solution Solution Structure with components and relationships Run-time behavior Tactics 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. 7
- 8. Architectural Style Catalogue Data Flow Data Centered Blackboard Repository Pipes & Batch Filters Sequential Call & Return Independent Components Layered Object Oriented Communicating Event Based Virtual Machines Processes Systems Interpreter Rule based Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
- 9. Data Flow Architectures Key feature: Dominated by motion of data through the system Data streams Processing & transformations on the streams Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
- 10. Architectural Pattern: Pipes and Filters (Data Flow) Context Problems Solution • Processing • Future system enhancements should be • Apply the Pipes data possible and Filters streams architectural • Small processing steps • Motion of pattern: the tasks • Non-adjacent processing steps do not share data of a system are through the information divided into system • Different sources of input data exist several sequential • Present or store final results in various ways processing steps, • Explicit storage of intermediate results for further connected by the processing data flow through • You may not want to rule out multi-processing the system the steps Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
- 11. Example: Compilers 1. Divide the system’s task into a sequence of processing stages 2. Define the data format to be passed along each pipe 3. Decide how to implement each pipe connection 4. Design and implement the filters 5. Design the error handling 6. Set up the processing pipeline Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11
- 12. Architectural Style Catalogue Data Flow Data Centered Blackboard Repository Pipes & Batch Filters Sequential Call & Return Independent Components Layered Object Oriented Communicating Event Based Virtual Machines Processes Systems Interpreter Rule based Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
- 13. Data-Centered Architectures Key Feature: Dominated by a complex central data store, manipulated by independent components. Repository Passive data store: file, database – Data mining, Recommendation Engines, – Route planner Blackboard Active data store: sends events to the subscribers – Artificial Intelligence – Speech and Pattern recognition Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
- 14. Architectural Pattern: Blackboard (Data Centered) Context Problems Solution • Experimental domain in • There are different algorithms • Apply the Blackboard which no closed that solve partial problems architectural pattern: a approach to a solution is • Employing disjoint algorithms collection of independent known or feasible, induces potential parallelism. If programs that work different approaches for possible you should avoid a cooperatively on a common the problem are strictly sequential solution data structure opportune p. 14
- 15. Blackboard : Instantiation 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 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 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15 (level 3, phrases), and syntactical data into queries (level 4).
- 16. Architectural Pattern: Blackboard + - ⇒ Modifiability ⇒ Testability • Individual knowledge sources, the •Hypotheses are part of the solution control algorithm and the central process data structure are strictly separated • Reusable knowledge sources ⇒ Performance • Computational overhead •The blackboard provides tolerance • No support for parallelism of noisy and uncertain conclusions • Difficult to establish a good control as all results are just hypotheses strategy Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
- 17. Architectural Style Catalogue Data Flow Data Centered Blackboard Repository Pipes & Batch Filters Sequential Call & Return Independent Components Layered Object Oriented Communicating Event Based Virtual Machines Processes Systems Interpreter Rule based Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
- 18. Call and Return Architectures Key Feature Dominated by order of computation Examples 2-Layered or Call based Client/Server N-Layered Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
- 19. Architectural Pattern: Layers Context Problems Solution • Large system • Parts of the system should be exchangeable • Layered that requires • Reuse low-level issues architectural decomposition pattern: structure • No standard component granularity your system into an • Group similar responsibilities appropriate number • System will be build by separated teams of of layers and place programmers them on top of each other Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
- 20. Architectural Pattern: Layers Structure Dynamics p. 20 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
- 21. Layers : Instantiation 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. 21
- 22. N-layered architecture Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
- 23. Architectural Pattern: Layers + - ⇒Modifiability ⇒Performance • Localize changes • Unnecessary work • Prevention of ripple effect • Lower efficiency • Defer binding time ⇒Testability ⇒Modifiability • Manage input/output • Cascades of changing behavior ⇒Usability •Difficulty of establishing the correct • Separate user interface granularity of layers •Reuse of layers •Support for standardization •Dependencies are kept local •Exchangeability Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
- 24. Model-View-Controller Context Problems Solution • Interactive • The same information is presented • Apply the Model-View- applicatio differently Controller architectural n with • Display and behavior of the application pattern: flexible must reflect data manipulations • The Model contains the human- immediately core functionality and data. computer • Changes to the user interface should be • Views display information to interface easy, and even possible at run-time the user, • Supporting different ‘look and feel’ • Controllers handle user standards or porting the user interface input and control the flow. should not affect code in the core Views and controllers application together comprise the user interface. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
- 25. Design Pattern: Model-View-Controller Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 25
- 26. MVC for web applications Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
- 27. MVC analysis + - ⇒ Modifiability Performance ⇒ •‘Pluggable’ views and controllers •Inefficiency of data access in view •Exchangeability of ‘look and feel’ •Potential excessive number of updates ⇒ Usability •Increased complexity, sometimes •Separate user interface without gaining much flexibility. ⇒ Modifiability •‘Pluggable’ views •Close coupling of views and •Multiple synchronized views of the controllers to a model same model •Difficulty of using MVC with •Framework potential modern user-interface tools Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27
- 28. Architectural Style Catalogue Data Flow Data Centered Blackboard Repository Pipes & Batch Filters Sequential Call & Return Independent Components Layered Object Oriented Communicating Event Based Virtual Machines Processes Systems Interpreter Rule based Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
- 29. 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. 29
- 30. Broker: Broker Forwarding Pattern Context Problems Solution • Distributed • Components should be able to access • Apply the Broker and possible services provided by others through architectural pattern: an heterogeneo remote, location-transparent service intermediate component us system invocations that is responsible for with • Need to exchange, add, or remove coordination independent components at run-time communication, such as cooperating forwarding requests, as • The architecture should hide system- components well as for transmitting and implementation-specific details from results and exceptions the user of components and services Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30
- 31. Broker Components: CRC p. 31
- 32. Broker : Instantiation 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… Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32
- 33. Architectural Pattern: Broker + - ⇒ Modifiability ⇒Performance •Location transparency •Restricted efficiency •Changeability and extensibility of components •Portability of a broker system (in ⇒Availability combination with proxy/bridge) •Lower fault tolerance •Interoperability between different broker systems •Reusability ⇒ Testability ⇒Testability •Many components involved •An application developed from tested services is more robust and easier to test Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33
- 34. Broker Handle Pattern Direct communication: same protocol or proxy Here the proxy takes some of the broker’s responsibilities for handling most of the communication activities Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 34
- 35. Design Pattern: Proxy Context Problems Solution • The configuration • Low-level message passing (e.g., using • Apply the Proxy of components in sockets) is error-prone & fraught with pattern: provide a distributed accidental complexity surrogate through systems is often • Remote components should look like local which clients can subject to change components from an application perspective access remote as requirements objects • i.e., ideally clients & servers should be evolve oblivious to communication mechanisms & locations Structure Dynamics p. 35
- 36. Design Pattern: Proxy + - ⇒ Modifiability ⇒ Performance •Decoupling clients from the •Less efficiency due to indirection location of server components (additional layer of indirection, usually negligible compared with the cleaner •Separation of housekeeping structure of clients and the gain of code from functionality efficiency through caching or lazy construction…) •Overkill via sophisticated strategies, they do not always pay Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 36
- 37. Broker Proxies Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 37
- 38. Broker Pattern Revisited: Proxy Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 38
- 39. Broker Pattern Revisited: Proxy Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 39
- 40. Event Based Systems Individual components announce data that they wish to share with other components: Publishers Other components can register an interest in a class of data: Subscribers Typically involves a message manager that controls communication between components Example: debuggers, databases, brokers Subscribe Message Manager Publish Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 40
- 41. Publisher-Subscriber Context Problems Solution • I/O driven message • Hard to schedule • Apply the Publisher- based application • Expensive to evolve Subscriber pattern to • Complex distribute periodic, I/O-driven • Scalability dependencies data from a single point of source to a collection of • Real-time constraints consumers Structure Dynamics p. 41
- 42. 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. 42
- 43. Publisher-Subscriber: example Subscribers HUD WTS 5: Subscribers perform Air NAV Frame avionics operations push(event) 4: Event Channel Event pushes events Channel to subscribers(s) push(event) 3: Sensor publishers Publishers GPS IFF FLIR push events to event channel 2: I/O via Board 1 interrupts 1553 1: Sensors VME generate Board 2 data p. 43
- 44. Pattern: Inter-relationships • 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 • Patterns need to collaborate 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. 44
Hinweis der Redaktion
- Geschreven door Christopher Alexander, maar dan in de context van gebouwen en steden. Wat hij zegt geldt ook voor OO design. Hij wordt min of meer beschouwd als de grondlegger van de design pattern idee … In SE spreken we over objecten en interfaces in plaats van over muren En deuren (zoals C. Alexander). Maar kern van de zaak is dat beide Soorten patterns een oplossingen bieden voor een probleem in een context. Design Patterns in OO
- Presentation-abstraction-control (PAC) is a software architectural pattern, somewhat similar to model-view-controller (MVC). PAC is used as a hierarchical structure of agents, each consisting of a triad of presentation, abstraction and control parts. The agents (or triads) communicate with each other only through the control part of each triad. It also differs from MVC in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC), this provides the option to separately multithread the model and view which can give the user experience of very short program start times, as the user interface (presentation) can be shown before the abstraction has fully initialized.
- Filters must be independent entities: in particular, they should not share state with other filters. Another important invariant is that filters do not know the identity of their upstream and downstream filters. Their specifications might restrict what appears on the input pipes or make guarantees about what appears on the output pipes, but they may not identify the components at the ends of those pipes. Furthermore, the correctness of the output of a pipe and filter network should not depend on the order in which the filters perform their incremental processing—although fair scheduling can be assumed.
- Advantages: First , they allow the designer to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters. Second , they support reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them. Third , systems can be easily maintained and enhanced: new filters can be added to existing systems and old filters can be replaced by improved ones. Fourth , they permit certain kinds of specialized analysis, such as throughput and deadlock analysis. Finally , they naturally support concurrent execution. Each filter can be implemented as a separate task and potentially executed in parallel with other filters.
- In a repository style there are two quite distinct kinds of components: a central data structure represents the current state, and a collection of independent components operate on the central data store. Interactions between the repository and its external components can vary significantly between systems. The choice of control discipline leads to major subcategories. A) Database systems: If the types of transactions in an input stream of transactions trigger selection of processes to execute, the repository can be a traditional database. B) Blackboard: If the current state of the central data structure is the main trigger of selecting processes to execute, the repository can be a blackboard.
- This figure illustrates a simple view of a blackboard architecture. The blackboard model is usually presented with three major parts: 1) The knowledge sources: separate, independent parcels of application dependent knowledge. Interaction among knowledge sources takes place solely through the blackboard. 2) The blackboard data structure: problem-solving state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem. 3) Control: driven entirely by state of blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable. Invocation of a knowledge source is triggered by the state of the blackboard. The actual locus of control, and hence its implementation, can be in the knowledge sources, the blackboard, a separate module, or some combination of these. Blackboard systems have traditionally been used for applications requiring complex interpretations of signal processing, such as speech and pattern recognition. They have also appeared in other kinds of systems that involve shared access to data with loosely coupled agents .
- A layered system is organized hierarchically, each layer providing service to the layer above it and serving as a client to the layer below. In some layered systems inner layers are hidden from all except the adjacent outer layer, except for certain functions carefully selected for export. Thus in these systems the components implement a virtual machine at some layer in the hierarchy. (In other layered systems the layers may be only partially opaque.) The connectors are defined by the protocols that determine how the layers will interact. Topological constraints include limiting interactions to adjacent layers. The most widely known examples of this kind of architectural style are layered communication protocols. In this application area each layer provides a substrate for communication at some level of abstraction. Lower levels define lower levels of interaction, the lowest typically being defined by hardware connections. Other application areas for this style include database systems and operating systems
- Layered systems have several desirable properties. First , they support design based on increasing levels of abstraction. This allows implementers to partition a complex problem into a sequence of incremental steps. Second , they support enhancement. Like pipelines, because each layer interacts with at most the layers below and above, changes to the function of one layer affect at most two other layers. Third , they support reuse. Like abstract data types, different implementations of the same layer can be used interchangeably, provided they support the same interfaces to their adjacent layers. This leads to the possibility of defining standard layer interfaces to which different implementors can build.
- Layered systems have several desirable properties. First , they support design based on increasing levels of abstraction. This allows implementers to partition a complex problem into a sequence of incremental steps. Second , they support enhancement. Like pipelines, because each layer interacts with at most the layers below and above, changes to the function of one layer affect at most two other layers. Third , they support reuse. Like abstract data types, different implementations of the same layer can be used interchangeably, provided they support the same interfaces to their adjacent layers. This leads to the possibility of defining standard layer interfaces to which different implementors can build.
- But layered systems also have disadvantages : Not all systems are easily structured in a layered fashion. And even if a system can logically be structured as layers, considerations of performance may require closer coupling between logically high-level functions and their lower-level implementations. Additionally, it can be quite difficult to find the right levels of abstraction. This is particularly true for standardized layered models. One notes that the communications community has had some difficulty mapping existing protocols into the ISO framework: many of those protocols bridge several layers.
- MVC encompasses more of the architecture of an application than is typical for a design pattern. When considered as a design pattern, MVC is semantically similar to the Observer pattern. The Model is the domain-specific representation of the data on which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the encapsulated by the model. Example: representations of a table in a database. Java observable class But Java provides the Observable/Observer classes as built-in support for the Observer pattern . The java.util.Observable class is the base Subject class. Any class that wants to be observed extends this class.
- Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data. Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
- The idea behind event based systems is that instead of invoking a procedure directly, a component can announce (or broadcast) one or more events. Other components in the system can register an interest in an event by associating a procedure with the event. When the event is announced the system itself invokes all of the procedures that have been registered for the event. The main invariant of this style is that announcers of events do not know which components will be affected by those events. Thus components cannot make assumptions about order of processing, or even about what processing, will occur as a result of their events.
- Example: find the cheapest fight ticket
- One important benefit of event based systems is that they provides strong support for reuse. Any component can be introduced into a system simply by registering it for the events of that system. A second benefit is that implicit invocation eases system evolution. Components may be replaced by other components without affecting the interfaces of other components in the system. In contrast, in a system based on explicit invocation, whenever the identity of a that provides some system function is changed, all other modules that import that module must also be changed. The primary disadvantage of implicit invocation is that components relinquish control over the computation performed by the system. When a component announces an event, it has no idea what other components will respond to it. Worse, even if it does know what other components are interested in the events it announces, it cannot rely on the order in which they are invoked.
- HUD: Headup display WTS : Weapons target system IFF: Identification friend or foo FLIR: sees through smoke screens -: thermal visioning