Blackboard " Elke Knowledge Source is verdeeld in een condition-deel en een action-deel. adhv de condition beslist de KS of een contribution aan het blackboard wordt gemaakt. " Control component heeft een loop die changes op het blackboard monitort en beslist wat de volgende actie is volgens een Strategy. Strategy can steunen op control knowledge sources. " Control Knowledge Sources dragen niet direct bij tot oplossingen op het Blackboard maar doen berekeningen waarmee de control decisions gemaakt worden. ∘ schatting op de kans op vooruitgang ∘ berekening van de kost voor het uitvoeren van Knowledge Sources ∘ Beslissing tot halten " Blackboard: ∘ .inspect() ∘ .update() Implementation 1) Define the problem 2) Define the solution space for the problem " intermediate <-> top-level " partial <-> complete 3) Divide the solution process into steps 4) Divide the knowledge into specialised knowledge sources with certain subtasks 5) Define the vocabulary of the blackboard 6) Specify the control of the system (Strategy pattern is hier nuttig om meerdere control strategies te testen) 7) Implement the knowledge sources Varianten " Production System (beperkter) " Repository (generieker), bvb database Pros " Experimentation " Support for changeability and maintainability: modules communiceren enkel via blackboard -> MODIFIABILITY " reusable knowledge sources -> MODIFIABILITY " support for fault tolerance and robustness Cons " Difficulty of testing -> TESTING " No good solution is guaranteed " Difficulty of establishing a good control strategy (requires an experimental approach) -> PERFORMANCE
" Low efficiency -> PERFORMANCE " High development effort " No support for parallelism -> PERFORMANCE
Broker Clients, servers, brokers, bridges, cliend-side proxies, server-side proxies Broker laat toe services toe te voegen of te veranderen terwijl het systeem aan het draaien is. Implementation 1) Define an object model 2) Decide which kind of component-interoperability the system should offer. (Binary of IDL) 3) Specify the APIs the broker component provides for collaborating with clients and servers. 4) Use proxy objects to hide implementation details from clients and servers (Note that proxies are always part of the corresponding client or server process.) 5) Design the broker component (parallel with 3 and 4) Itereren: 5.1) Specify a detailed on-the-wire protocol 5.2) A local broker must be available for every participating machine in the network. Bridges for inter-broker communication abstraction. Also repositories for remote brokers and routing info. 5.3) Broker must remember which result is for which client. 5.4) If proxies do not (un)marshal, the broker must do so. 5.5) Message buffers when supporting asynchronous communication. 5.6) Directory service (used to associate local server id's with the physucal location of the corresponding servers in the broker) 5.7) Name service for instantiating system-unique id's during server registration (if required). 5.8) If dynamic method invocation is supported, the broker must maintain type info about the existing server and the client must be able to retrieve this information. (Reflection) 5.9) Two levels of errors: normal errors, and communication errors (when distributed). Plan the broker's actions when a communication error occurs. 6) Develop IDL compilers. Variants " Direct Communication Broker System. Broker vertelt de client waar de server te vinden is. Vanaf dan komt de broker niet meer tussen. De proxies zorgen dan voor de communicatie. Kan ook dat local clients remote brokers zelf contacteren, eventueel met bridges etc. " Message Passing Broker System. For systems with a focus on the transmission of data. Message = type,structure,... + raw data " Trader system. Service-based ipv Server-based. Clients use service-id's. " Adapter Broker System. Adapter tussen broker en servers. Adapter zorgt voor speciaal gedrag. Bvb shortcuts (rechtstreekse library-aanspreking). " Callback Broker System. Reactive, event-driven, no distinction between clients and servers. Events
trigger callbacks. " Combinations of the above. Pros " Location Transparency " Changeability and extensibility of components " Portability of a Broker system. Enkel de broker porten en de clients en servers recompilen. Broker in layers structureren is recommended. " Interoperability between different Broker systems. (Common protocol) " Reusability Cons " Restricted efficiency " Lower fault tolerance. (distributed, als broker of server failt, failt de rest die erop depend) Reliability kan verhoogd worden door replicatie van de componenten. Pros én Cons " Testing and debugging: een client app die ontwikkeld werd met goed geteste services is robuuster en zelf makkelijker te testen. Maar een Broker is moeilijk te testen doordat er 2 foutclasses zijn (zie hoger).
"""For more information on pipeline architectures, refer to the Pipes and Filters pattern (53) where we explain in more detail why building compilers according to Pipes and Filters is usually not a good idea."""
Publisher Subscriber Helpt om de status van samenwerkende componenten in sync te houden. Laat daarvoor een eenwegspropagatie van veranderingen toe: 1 publisher verwittigt een willekeurig aantal subscribers van wijzigingen aan zijn status. " 'polling' voldoet niet " Geen sterke binding tusssen publisher en dependents Oplossing Publisher en Subscribers Publisher houdt een register bij van currently-subscribed componenten. Wanneer een component een subscriber wil worden gebruikt die de subscribe interface aangeboden door de publisher. Analoog voor unsubscriben. Bij een statusverandering in de publisher stuurt deze een notification naar alle subscribers. Deze krijgen dan de veranderde data. flexibiliteit:
" abstract publisher/subscriber base classes " publisher kan state changes queuen en pas later notify() callen " object kan subscriber zijn bij meerdere publishers " object kan publisher én subscriber zijn tegelijk " differentiatie per event type " data change zenden vs enkel notification Uit dit laatste: push <-> pull model. push " very rigid dynamic behaviour " slechte keuze voor complexe dataveranderingen, zeker wanneer publ een compex pakket verzendt naar een subscr die er niet in geïnteresseerd is, dan beter pull model pull " meer flexibiliteit, maar meer berichten tussen publishers en subscribers Algemeen: push beter als subscribers meestal de gepubliceerde informatie nodig hebben. Varianten Gatekeeper Gedistribueerd. Kan 2 processen, het ene zend messages, het andere (singleton gatekeeper) demultiplext de messages en verwittigt de juiste subscribers. Event Channel Gedistribueerd. Sterke ontkoppeling tussen publishers en subscribers: er kan meer dan 1 publisher zijn en de subscribers willen enkel de changes weten, niet de publisher. Publishers zijn niet geïnteresseerd in wie juist subscribet. Voor publishers is event channel een subscriber, voor subscribers is het een publisher. 'proxypublisher' 'proxy-subscriber' zorgen voor eventuele procesgrensmogelijkheden. Ook mogelijkheid tot een buffer in het event channel -> verdere ontkoppeling. Chains van event channels mogelijk (meerdere filters, QoS) Producer-Consumer Meestal 1:1, sterke ontkoppeling. Buffer tussen de twee. Producer producet altijd verder, tenzij buffer vol. Consumer consumet constant, tenzij buffer leeg.
Layers The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction. Example
Networking protocols, voordeel van layers " laat toe in teams te developen " ondersteunt incremental coding en testing " makkelijk uitwisselen van delen van de stack Context A large system that requires decomposition Problem Mix van low en high level issues, high-level steunen op low-level. Volgende forces balanceren: " Geen ripple effect " Stabiele interfaces " Delen van systeem moeten verwisselbaar zijn. (design for change, graceful system evolution) " low-level hergebruikt mogelijk " gelijkaardige verantwoordelijkheden moeten gegroepeerd worden om begrijpbaarheid en onderhoudsgemak te vergroten " There is no standard component granularity. " Complexe componenten moeten verder worden opgebroken. " componentgrenzen overschrijden kan een effect hebben op performance... " werk moet kunnen opgedeeld worden bij duidelijke grenzen Oplossing Vooral essentieel dat binnen een layer alle componenten op hetzelfde abstractieniveau werken. Services die layer J levert bestaan uit services die layer J-1 levert. Structure Class: Layer J Collaborator: Layer J-1 Responsibility: " provides services used by Layer J+1 " Delegates subtasks to Layer J-1 Verschil tussen componenten in layer J-1 direct aanspreken en een unified interface aanspreken. Dynamics 5 scenario's Implementation 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
-> inverted pyramid of reuse: meer services in hogere lagen dan in lagere lagen 5) Refine the layering, yo-yo 6) Specify an interface for each layer; black of white box, gray box 7) Structure individual layers 8) Specify the communication between adjacent layers (push-model) 9) Decouple adjacent layers 10) Design an error-handling strategy (regel: errors afhandelen in de laagst mogelijke laag, desnoods veralgemenen voor doorgeven naar hogerhand) Variants " Relaxed layered system " Layering through inheritance (fragile base class problem) Known uses " Virtual machines " API's " Information Systems " Windows NT Benefits " Reuse of layers " Support for standardization (POSIX) " Dependencies are kept local (max 2 layers) " Exchangeability (soms ten koste van extra programmeereffort en verlaagde run-time performance) Liabilities " Cascades of changing behaviour " Lower efficiency " Unnecessary work " Difficulty of establishing the correct granularity of layers
MVC The Model-View-Controller architectural pattern (MVC) divides an interactive application into three components. 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. A change-propagation mechanism ensures consistency between the user interface and the model. Context Interactive applications with a flexible human-computer interface.
Problem User interfaces are especially prone to change requests, different users place conflicting requirements on the user interface. Forces: " The same information is presented differently in different windows, for example, in a bar or pie chart. " The display and behavior of the application must reflect data manipulations immediately. " Change to the user interface should be easy, and even possible at runtime. " Supporting different look and feel standards or porting the user interface should not affect code in the core of the application. Solution Processing, output en input. Model: core data and functionality View: display information to the user Controller: each view has an associated controller component. Receive input. Vertaalt inputevents naar service request voor model of view. Structure Model Change interface voor controllers, access interface voor views. Change propagation mechanism. Class: Model Responsibility: " Provides functional core of the application " Registers dependent views and controllers " Notifies dependent components about data changes Collaborators: " View " Controller View Each view defines an update procedure that is activated by the change-propagation mechanism. 1:1 tussen views en controllers Class: View Responsibility: " Creates and initializes its associated controller " Displays information to the user " Implements the update procedure " Retrieves data from the model Collaborators: " Controller " Model
Controller Accept user input as events. Implements update procedure. Stuurt events door als messages. Class: Controller Responsibility: " Accepts user input as events. " Translates events to service requests for the model or display requests for the view. " Implements the update procedure, if required. Collaborators: " View " Model Kan MVC ook als framework gebruiken. Dynamics meh. Implementation 1) Separate human computer interaction from core functionality 2) Implement the change-propagation mechanism 3) Design and implement the views 4) Design and implement the controllers 5) Design and implement the view-controller relationship 6) Implement the set-up of MVC 7) Dynamic view creation 8) 'Pluggable' controllers 9) Infrastructure for hierarchical and controllers 10) Further decoupling from system dependencies Variants " Document-View Known Uses " Smalltalk " MFC " ET++ Benefits " Multiple views of the same model " Synchronised views " 'Pluggable' views and controllers " Exchangeability of 'look and feel'
" Framework potential Liabilities " Increased complexity " Potential for excessive number of updates " Intimate connection between view and controller " Close coupling of views and controllers to a model " Inefficiency of data access in view " Inevitability of change to view and controller when porting " Difficulty of using MVC with modern user-interface tools
Pipes and Filters The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems. Example: compiler Context: processing data streams Problem System that must process or transform a stream of input data. Single component not feasible: several devs. Forces: " Future system enhancements should be possible by exchanging processing steps or by recombination of steps, even by users " Small processing steps are easier to reuse in different contexts than large components " Non-adjacent processing steps do not share information " Different sources of input data exist, such as a network connection or a hardware sensor providing temperature readings, for example " It should be possible to present or store final results in various ways " Explicit storage of intermediate results for further processing in files clutters directories and is error-prone, if done by users " You may not want to rule out multi-processing the steps, for example running them in parallel or quasi-parallel Solution PF archtitectural pattern verdeelt de taak van een systeem op in meerdere sequentiele verwerkingsstappen. filter = processing pipe = connecties tussen data source, filters en data sink
processing pipeline = filters + pipes Structure Filter Filter verrijkt, verfijnt of transformeert. Activiteit van een filter kan getriggerd worden door meerdere events: " Het er op volgende pipeline element pullt output data uit de filter " Het vorige pipeline element pusht nieuwe input data in de filter " Meestal: filter is actief in een loop, trekt z'n eigen data binnen en duwt de output verder door de pijplijn 2 eerste: passive filter, laatste: active filter. Class: Filter Responsibility: " Gets input data " Performs a function on its input data " Supplies output data Collaborators " Pipe Pipes FIFO Class: Pipe Responsibility: " Transfers data " Buffers data " Synchronizes active neighbors Collaborators: " Data Source " Data Sink " Filter Data Source Input to the system. Provides sequence of data values of the same structure or type. Class: Data Source Responsibility: " Delivers input to processing pipeline Collaborators: " Pipe Data Sink
Collects the results from the end of the pipeline. Active data sink pulls, passive data sink allows preceding filter to push or write the results into it. Class: Data Sink Responsibility: " Consumes output Collaborators: " Pipe Dynamics Implementation 1) Divide the system's task into a sequence of processing stages 2) Define the data format to be passed along each pipe (uniform data format geeft hoogste flexibiliteit) 3) Decide how to implement each pipe connection (active/passive) 4) Design and implement the filters (overhead wanneer data moet worden overgekopieerd tussen address spaces) 5) Design the error handling 6) Set up processing pipeline Variants Tee and join pipeline systems. Filters with mre than one input and/or output. Known uses " Unix " CMS Pipelines " LASSPTools Benefits " No intermediate files necessary " Flexibility by filter exchange " Flexibility by recombination " Reuse of filter components " Rapid prototyping of pipelines " Efficiency by parallel processing Liabilities " Sharing state information is expensive or inflexible " Efficiency gain by parallel processing is often an illusion " Data transformation overhead " Error handling
Microkernel The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration. Context The development of several applications that use similar programming interfaces that build on the same core functionality. Problem Forces: " The application platform must cope with continuous hardware and software evolution " The application platform should be portable, extensible and adaptable to allow easy integration of emerging technologies Solution Encapsulate the fundamental services of your application platform in a microkernel component. The microkernel includes functionality that enables other components running in separate processes to communicate with each other. In addition, it provides interfaces that enable other components to access its functionality. Internal servers bevatten core functionality die niet binnen de microkernel kan worden geïmplementeerd zonder onnodig de grootte of complexiteit ervan te vergroten. External servers implement their own view of the underlying microkernel. Separate process that itself represents an application platform. Clients communicate with external servers using the communication facilities provided by the microkernel. Structure Microkernel communication facilities, resource handling Atomic services (mechanisms), worden gebruikt om meer complexe functionaliteit (policies) te bouwen Class: Microkernel Responsibility: " Provides core mechanisms " Offers communication facilities " Encapsulates system dependencies " Manages and controls resources
Collaborators " Internal Server Internal Server aka Subsystem, extends the functionality provided by the microkernel. Only accessible by the microkernel component. Class: Internal Server Responsibility: " Implements additional services " Encapsulates some system specifics Collaborators: " Microkernel External Server aka Personality, uses the microkernel for implementing its own view of the underlying application domain. External servers expose their functionality by exporting interfaces in the same way as the microkernel itself does. Separate process. Receives service requests from client application using the communication facilities provided by the microkernel, interprets, executes appr services and returns the results to its clients. Class: External Server Responsibility: " Provides programming interfaces for its clients Collaborators: " Microkernel Adapter aka Emulators Interfaces between clients and their external servers, and allow clients to access the services of their external server in a portable way. Part of the client's address space. Class: Adapter Responsibility: " Hides system dependencies such as communication facilities from the client " Invokes methods of external servers on behalf of clients. Collaborators: " External server " Microkernel Client A client is an application that is associated with exactly one external server. It only accesses the
programming interfaces provided by the external server. Class: Client Responsibility: " Represents an application Collaborators: " Adapter Dynamics Implementation 1) Analyse the application domain 2) Analyse external servers 3) Categorise the services 4) Partition the categories 5) Find a consistent and complete set of operations and abstractions 6) Determine strategies for request transmission and retrieval 7) Structure the microkernel component 8) Specify the programming interfaces of the microkernel 9) Microkernel is responsible for managing all system resources 10) Design and implement the internal servers as separate processes (active) or shared libs (passive). (parallel with 7-9) 11) Implement the external servers 12) Implement the adapters 13) Develop client applications Variants " Microkernel System with indirect Client-Server connections " Distributed Microkernel System Known Uses " Mach " Amoeba " Chorus " Windows NT " MKDE Benefits " Portability " Flexibility and extensibility " Separation of policy and mechanism Distributed: " Scaleability " Reliability
" Transparency Liabilities " Performance " Complexity of design and implementation
