Evaluating Software Architecture Styles
In a scenario where three vendors submit bids for a project, understanding and comparing their proposed architectures is essential. This involves evaluating functional relationships, data flow, control flow, event handling, fault-tolerance, operational capabilities, and more. To make an informed decision, a formal way of describing and evaluating architectures is crucial.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Simple Case Study Three vendors have been asked to submit bids for work that tracks student credentials All vendors supply demonstration systems that: Seem to meet the requirements Are all within similar cost estimates. All other things being equal Who do you pick ? You ask them to come in and describe their architecture so as to get a better understanding of the long term costs to maintain and adapt the system to your planned expansions. 2
The Vendors The We Know Better. Com An medium to large experienced company that has developed a wide range of similar products over several years for a variety of customers. -> TheWKB.com The Minority Owned Business. Com -> TheMob.com A small company that has developed a similar product and is looking to expand their business The Wet Behind the Ears. Com -> TheWBTE.com A grad students run venture that is looking to capture the contract in order to acquire start up funding. 3
The Proposed Architectures TheWKB.com depicts what they call an architecture by showing the allocation of functional pieces to hardware. WS (1) WS (n) WS ( ) UI UI UI Functions.. Functions.. DBMS TheMob.com depicts what they call an architecture by showing a functional block diagram. The System UI Functions.. DBMS TheWBTE.com depict what they call an architecture by showing a logical view of the functional elements and their interconnection dependencies. UI Functions.. These depictions and others have been used to describe architectures So who is correct ? What s missing ? DBMS 4
So how do you even start to evaluate and compare the architectures against each other ? How do determine (measure) which one is better at capturing: Functional relationships ? Data Flow ? Control Flow ? Event Handling ? Fault-Tolerance ? WS (1) WS (n) WS ( ) UI UI UI Functions.. Functions.. DBMS Do the boxes and lines have the same meaning both internal to an architecture and across competing architectures ? The System Operational capabilities: How do measure which one is better at addressing the issues wrt.: Homogenous vs. Heterogeneous systems? Expandability ? Interoperability ? Maintainability ? Upgradeability ? Responsiveness ? etc.. UI Functions.. DBMS UI Functions.. DBMS Who do you give the contract to? It should be obvious then that there needs to be a better (more formal) way of describing and evaluating an architecture ! 5
What You Should Learn Understand the essential features of a given problem and then make the most appropriate architectural choices. How we are going to do this Recognize major architecture styles (paradigms) in existing software systems. Understand and evaluate existing software designs from an architectural perspective Generate reasonable architecture alternatives Understand how formal notations and models can characterize and reason about a formal design Describe an architecture adequately Present examples of architectures that serve as models for new designs. Understand how to use domain knowledge to specialize an architecture. Construct a medium sized architecture that satisfies an architectural perspective 6
What is a Software Architecture? Paulisch, Frances. "Software Architecture and Reuse- An Inherent Conflict?" 214. Proceedings of the 3rd International Conference on Software Reuse. Rio de Janeiro, Brazil, November 1-4, 1994. Los Alamitos, CA: IEEE Computer Society Press, 1994 Architecture of the system An architecture is considered to consist of components and the connectors (interactions) between them Definitions of architecture, component, and connector (protocols) vary among researchers, this definition of architecture serves as a baseline for this technology description. Design vs Architecture Design explicitly addresses functional requirements Architecture explicitly addresses functional and non-functional requirements such as: reusability, maintainability, portability, interoperability, testability, efficiency, and fault-tolerance and the other Quality Attributes 7
The Goal of SW Architecture Enable the construction of very large system architectures. Many, many connections Dynamic creation of components and dynamically de-selectable connections. Support for a Hierarchical design Process So we can gradually introduce the ranked ordered set of quality attributes (QA) we care about. Test & Validate partially instantiated architectures Especially true in large systems (Q A: subsetability) Flexibility in allowing modules to be assigned to interfaces (Q A: Interoperability) So How do we do this ? 8
Architecture Design or Selection: Initial Rules on Selecting An Architecture If the problems is decomposable into sequential stages: Then consider data Flow (batch sequential or pipeline) If your problem involves passing rich data representations,: Then avoid pipelines restricted to ASCII. If in addition each stage is incremental, so that later stages can begin before earlier stages finish: Then consider a pipeline architecture. Else If the problem involves transformations on continuous streams of data (or on very long streams): Then consider a pipeline architecture. If a central issue is understanding the data of the application, its management, and its representation: Then consider a repository or abstract data type architecture. If the data is long-lived: THEN focus on repositories. If the representation of data is likely to change over the lifetime of the program then define abstract data types in order to confine changes to particular components. If the input data is noisy (low signal-to-noise ratio) and the execution order cannot be predetermined Then consider a blackboard (We will add to this as the blackboard is probably the best place to start for real-time architecture with distributed data) If the execution order is determined by a stream of incoming requests and the data is highly structured Then consider a database management system. 9
Architecture Design or Selection: Initial Rules on Selecting An Architecture If your system involves controlling continuing action, is embedded in a physical system, and is subject to unpredictable external perturbation so that preset algorithms go awry: Then consider a closed loop control architecture If you have designed a computation but have no machine on which you can execute it Then consider an interpreter architecture. If your task requires a high degree of flexibility, configurability, loose coupling between tasks, and reactive tasks, Then consider interacting processes. If you have reason not to bind the recipients of signals from their originators: Then consider an event architecture. If the tasks are of a hierarchical nature: Then consider replicated worker or heartbeat style. If the tasks are divided between producers and consumers: Then consider client/server. If it makes sense for all of the tasks to communicate with each other in a fully connected graph: Then consider a token passing style. 10
Architecture Representation Concepts Component: An object with independent Existence, i.g. A module, process, procedure, or variable Interface: A typed object that denotes a logical point of interaction between a component and its environment. Connector: A typed Object relating interface points, components, or both Configuration: A collection of Constraints that wire the objects into a specific architecture Mapping: A relationship that defines a syntactical translation from the language of an abstract architecture to the language of a concrete architecture Architectural Style: A vocabulary of design elements, constraints that determine how they are to be used and a semantic definition of the connectors associated with this style. 11
Architecture Representations: Static View vs. Dynamic View Current software architecture research assumes a system's architecture is static, it does not evolve during execution. Architectures must be able to evolve during execution. First, the architectures of many existing systems change during execution, and are poorly modeled using existing techniques. Examples include systems built using OLE, OpenDOC, or CORBA, in which new components may be loaded and unloaded during execution. Second, many systems would benefit from the dynamism afforded by a dynamic architecture. Examples include systems characterized as long running and mission critical since the delays and risks associated with shutting down these systems for upgrades may be expensive. 12
Industry Concerns Industry - We need to be able to: Construct the Best Architecture to meet the requirements Evaluate Competing ProductArchitectures Share methods, techniques, patterns, idioms for structuring complex systems Exploit commonalities in specific domains to provide a reusable framework for product families. Educate ourselves on technique and formal methods 14
What is a Software Architecture? Architecture of the system There is no standard, universally-accepted definition of the term, for software architecture is a field in its infancy, although its roots run deep in software engineering An architecture is considered to consist of components and the connectors (interactions) between them. Architecture explicitly addresses functional and non-functional requirements such as: reusability, maintainability, portability, interoperability, testability, efficiency, and fault-tolerance and the other Quality Attributes Design vs Architecture Design explicitly addresses functional requirements 15
Issues in Software Architecture Architecture representation: (this session) How does one communicate an architecture? How does one represent an architectures? How does one select the set of information represented with a language. Architecture design or selection: How does one create or select an architecture based on a set of functional, performance, and quality requirements? Architecture evaluation and analysis: How does one analyze an architecture to predict qualities about the systems How does one compare and choose between competing architectures Architecture-based development and evolution: How does one build and maintain a system where components may not exist or are incompatible Architecture recovery: How does one evolve a legacy system when changes may affects its architecture? How does one extract architecture from supplied documentation. Architecture: Static vs Dynamic View 16
Architecture Representation Concepts Component: An object with independent Existence, i.g. A module, process, procedure, or variable Interface: A typed object that denotes a logical point of interaction between a component and its environment. Connector: A typed Object relating interface points, components, or both Configuration: A collection of Constraints that wire the objects into a specific architecture Mapping: A relationship that defines a syntactical translation from the language of an abstract architecture to the language of a concrete architecture Architectural Style: A vocabulary of design elements, constraints that determine how they are to be used and a semantic definition of the connectors associated with this style. The differences in the considerations for a local vs distributed homogeneous vs distributed heterogeneous system drive the definition of the particular architecture style. 17
Architectural Style An architectural style is a description of component types and their topology. It also includes a description of the pattern of data and control interaction among the components and an informal description of the benefits and drawbacks of using that style. Architectural styles define classes of designs along with their associated known properties. They offer experience-based evidence of how each class has been used historically, along with qualitative reasoning to explain why each class has its specific properties. (patterns) 18
Architecture Styles Looking for a Uniform Description of an Architecture Which kinds of Components and connectors are used in the style Examples: programs, objects, processes, filters The allowable kinds of components and connectors are primary discriminants among the styles, however the following four items also contribute to defining the particular style How is control shared, allocated m and transferred among the components Topology : ? Linear (non-branching) , ? A cyclical, ? Hierarchical, ? Star , ? Arbitrary, ? Static or Dynamic Synchronicity: ? Lockstep (sequential or parallel depending on the threads of control) , ? Synchronous, ? Asynchronous How is data communicated through the system Data Flow Topology as above for control Continuity: Continuous Flow: fresh data available at all times, Sporadic Flow, High-Volume vs Low Volume (see USB) (? How much network band-with is / can be dedicated to data synchronization) Mode: Describes how data is made available throughout the system Object style: data is passed from component to component Shared data style: data is made available in a place accessible to all Copy out- Copy In mode, vs. broadcast or multicast, How do Data and control interact (data flow & topology vs. control flow & topology) Pipe & Filter (data & control pass together) vs. Client-Server control flows into the servers and data flows in to the clients. What type of reasoning (analysis) is compatible with the style Asynchronously operating components (Non-deterministic) vs. fixed sequence of atomic steps, 19
A View of Architecture Styles Data Flow (1) Batch Sequential (traditional systems) & Pipeline Systems (2) Pipes & Filters (Linked Stream transformers) Call & return (3) Main Program & Subroutine (4) OO Systems (5) Hierarchical Layers Independent Components (6) Communicating Processes (7) Event Systems Virtual Machines (8) Interpreters (9) Rule-Base systems Data-Centered Systems (Repository) (10) Databases (11) Hypertext Systems (12) Blackboards (13) Distributed Processing Styles (14) Process Control Style 20
Batch Sequential General Constructs: Processing Steps are independent programs Each steps runs to completion before the next program starts Data is transmitted in complete data sets between programs Historically used in Data processing Needs a scheduler to submit the jobs Advantages: Allows the designer to understand the system in terms of business process steps. Easy to maintain (supposedly) and add new or replace programs. However experience has shown that program and data stores are really tied to the business process. Disadvantages: Not good at interactive applications Limited Support for concurrent execution as each program needs ALL the data before it starts. Need to get ALL the data through the system before we can really see results. Not responsive to changes, No Event Handling, No Fault Tolerance, Many problems if tapes are run out of sequence. 21
Suggested Batch Sequential Style Scheduler Data Store (1) Data Store (2) Program 1 Program (n) Program 2 Components are the Programs and Data stores. Connectors are one way pipes that transfer bulk data sets. 22
Pipe & Filter (Pipeline)Architecture Styles General Constructs: Pipes move data between filters. The Filters must be independent entities and do NOT share state with other filters. Filters Do NOT know their sources and sinks of data. The correctness of the output of a pipe & filter network should not depend on the order in which the filters preformed their processing. Examples: Image Processing, Unix pipe shell programs, Compilers Advantages: Allow the designer to to understand the system in terms of composition of filters. Support Re-Use Easy to maintain and add new or replace old filters. Permit specialized analyses: (Throughput & deadlock) Each filter can be implemented as a separate task and executed in parallel with other filters. Disadvantages: Not good at interactive applications, incremental display updates May need to maintain connections between separate yet related streams. Different filters types may therefore require a common representation (packing & unpacking costs) Each event handled from font to back. Program 1 Program 2 Program (n) 23
One way Data Flow Through a Network of Filters Filters can be interconnected in different ways As long as the input assumptions and output behaviors are the same, one filter process or a network of filters can be replaced by a different implementation of a filter process or network that accomplish the same tasks. What does this impose on the rest of the filters if they are written in a different language or have a different implementation? The output of a filter process is a function of its input This specification relates the value of messages sent on output channels to the values of messages received on input channels. The actions a filter takes in response to receiving input must ensure this relation every time the filter sends output. Requires us to understand and specify our communication and underlying data assumptions. The output produced by one filter meet the input assumptions of another. 24
Call & Return Style: Mainframe General Constructs: All intelligence is within the central host computer. Users interact with the host through a terminal that captures keystrokes and sends that information to the host. Advantages: Mainframe software architectures are not tied to a hardware platform. User interaction performed with workstations. Disadvantages: A limitation of mainframe software architectures is that they do not easily support graphical user interfaces or access to multiple databases from geographically dispersed sites. Mainframes have found a use as a server in distributed client/server architectures UI Note the connectors may be two-way as contrasted with the dataflow style as we have control from UI to Mainframe and Data from the Mainframe to UI Main Frame 25
Call & Return Style: File Sharing http://www.dafscollaborative.org/press/whitepaper.pdf General Constructs: The original PC networks were based on file sharing architectures, where the server downloads files from the shared location to the desktop environment. The requested user job is then run (including logic and data) in the desktop environment. Advantages: File sharing architectures work if shared usage is low, update contention is low, and the volume of data to be transferred is low. Disadvantages: In the 1990s, PC LAN (local area network) computing changed because the capacity of the file sharing was strained as the number of online user grew (it can only satisfy about 12 users simultaneously) and graphical user interfaces (GUIs) became popular (making mainframe and terminal displays appear out of date). Addendum: PCs are now being used in client/server architectures. 26
Suggested File Sharing Architecture Application Buffer Application (n) Buffer : Data Control Buffer : Buffer : File File (n) Main frame 27
Data Abstraction & OO Architecture General Constructs: Data representations and their associated operations encapsulated in an abstract data type. The components are the objects and connectors operate through procedure calls (methods). Objects maintain the integrity of a resource and the representation is hidden from others. Advantages: Server is able to change an implementation without affecting the client. Grouping of methods with objects allows for more modular design and therefore decomposes the problems into a series of collections of interacting agents. Disadvantages: For one object to interact with another, the client object must know how to interact with the server object and therefore must know the identity of the server. If the server changes its interface ALL interacting clients must also change. Services declared as PUBLIC and IMPORTED into the CLIENT Also need to consider side affects, A uses B , B uses C and we mod C 28
Hierarchical Layered Architecture Styles Layered Systems General Constructs A layered system is organized hierarchically with each layer providing service to the layer above it and serving as a client to the layer below. In some systems inner layers are hidden from all except the adjacent outer layer. Connectors are defined by the protocols that determine how layers will interact. Constraints include limiting interactions to adjacent layers. The best known example of this style appears in layered communication protocols OSI-ISO (Open Systems Interconnection - International Standards Organization) communication system. Lower levels describe hardware connections and higher levels describe application. GUI Application Layer DBMS OS Layer 29
Hierarchical Layered Architecture Styles Issues: No one agrees exactly on what a 'layer' is. For example, some layering schemes have very little relationship to the runtime. Others confuse layers with a 'tiered' runtime architecture where the various layers are not only split by build-time packaging, but by running in different processes and possibly different nodes at run time. Clearly separate the idea of 'tiers' from layers'. A tier is a structure for runtime component interaction that implies nothing about the construction of the build time. For example, a 3 tier system may be composed of a web browser, web server/asp pages, and database. Note that each tier runs in a different process and possibly many different system nodes. 30
Hierarchical Layered Architecture Styles Layers is a pattern for 'application architectures'. Layers are normally thought of as a build-time structuring technique for building an application or service that will execute in a single process. There are many variations on the layers pattern. Four-layer architecture (analysis) Layered and sectioned architecture Layered architecture Layers (from POSA1) Patterns for generating a layered architecture Relational database access layer Secure access layer (analysis) GUI Application Layer DBMS OS Layer 31
Hierarchical Layered Architecture Styles Layered Systems Advantages: Layered systems support designs based on increasing levels of abstraction. Complex problems may be partitioned into a series of steps. Enhancement is supported through limiting the number of other layers with which communication occurs. Disadvantages: Disadvantages include the difficulty in structuring some systems into a layers. Performance considerations may not be well served by layered systems especially when high level functions require close coupling to low level implementations. It may be difficult to find the right level of abstraction especially if existing systems cross several layers. 32
Communicating Processes Each component has it's own thread of execution. The Provider/Observer Role Pattern Push and Pull Interaction Patterns Opaque Interaction Patterns Synchronous Opaque Interaction Patterns Asynchronous Opaque Interaction Patterns Monitorable Interaction Patterns Pull-Monitorable Interaction Patterns Push-Monitorable Interaction Patterns Abortable Interaction Patterns Abortable Async Opaque Interaction Patterns Abortable Pull-Monitorable Interaction Patterns Abortable Push-Monitorable Interactions Patterns Handshaking Patterns Combining Patterns The components are the objects and connectors operate through message passing. Components are often in separate process spaces Object 1 Object 2 33
Independent Components:Event Based Architecture Styles Event-Based Implicit Invocation (Look at Jini) General Constructs: A component announces (broadcasts) one or more events. System Components register interest in an event by associating a procedure with it. The system invokes all events which have registered with it. Event announcement ``implicitly'' causes the invocation of procedures in other models. This style originates in constraint satisfaction (Planning), daemons, and packet-switched networks. Used in Planning Domains Architectural components are modules whose interface provides both a collection of procedures and a set of events. Procedures may be called normally or be registered with events in the system. Implicit invocation systems are used in: programming environments to integrate tools database management systems to ensure consistency constraints user interfaces to separate data from representation 34
Event Based Architecture Styles Event-Based Implicit Invocation Advantages: Allows any component to register for events Eases system evolution by allowing components to be replaced without affecting the interfaces of other components in the system. Disadvantages: Components relinquish control over the computation performed by the system. A component cannot assume that other components will respond to its requests A component does not know in which order events will be processed. In systems with a shared repository of data the performance and accuracy of the resource manager can become critical. Reasoning about correctness can be difficult because the meaning of a procedure that announces events will depend on the context in which it was invoked. 35
Interpreter Architecture Styles Interpreters Interpreters create a virtual machine in software. There are generally four components to an interpreter, the program being interpreted, the state of the program, the state of the interpreter, and the interpreter itself. This style is used to narrow the gap between the computing engine in hardware and the semantics of a program. Programming languages that provide a virtual language machine include: Pascal, Java, BASIC. 36
Data Repository Architecture Styles Repositories General Constructs: Repository style systems have two distinct components: A central data structure which represents the current state, and A collection of independent components which operate on the data-store. Two methods of control exist for these systems. If input transactions select the processes to execute then a traditional database can be used as a repository. (Client-Server) If the state of the data-store is the main trigger for selecting processes then the repository can be a blackboard. 37
Client-Server: Continued Client/server architecture. C/S architecture emerged due to file sharing architectures limitations This approach introduced a database server to replace the file server. Using a relational database management system (DBMS), user queries could be answered directly. The C/S architecture reduced network traffic by providing a query response rather than total file transfer. C/S improves multi-user updating through a GUI front end to a shared database. C/S architectures, use (RPCs) or standard query language (SQL) statements to communicate between the client and server. 38
Repository: Client-Server Cont. The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The client/server model started gaining acceptance in the late 1980s. The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralized, mainframe, time sharing computing A client is defined as a requester of services and a server is defined as the provider of services. A single machine can be both a client and a server depending on the software configuration. 39
Client Server Architecture Types Two Tiered Three components distributed in two tiers: User System Interface Processing Management process development, process enactment, process monitoring, and process resource services) Database Management (such as data and file services) Three Tiered Three tier with transaction processing monitor technology Three tier with message server. Three tier with an application server. Three tier with an ORB architecture. Distributed/collaborative enterprise architecture. 40
Two Tiered Client-Server Architectures General The user system interface is usually located in the user's desktop environment in two tier client/server architectures. The database management services are usually in a server that is a more powerful machine that services many clients. Processing management is split between the user system interface environment and the database management server environment. The database management server provides stored procedures and triggers. Software vendors provide tools to simplify development of applications for the two tier client/server architecture. GUI DBMS Engine Data Store 41
Two Tiered Client-Server Architectures Advantages: Good solution for distributed computing when work groups are defined as a dozen to 100 people interacting on a LAN simultaneously. Disadvantages: Server performance deteriorates as number of clients increases as a result of maintaining a connection with each client (even when no work is being done) Vendor proprietary database implementations restricts flexibility and choice of DBMS for applications. Current implementations provide limited flexibility in repartitioning program functionality from one server to another without manually regenerating procedural code. 42
Two Tiered VS Three Tiered C/S Thin Clients Middle Tier Fat Clients DBMS Engine DBMS Engine Data Store Data Store 43
Three Tiered Client-Server Architectures Proposed to overcome two tier architecture limitations A middle tier added between the UI client environment and the DBMS. There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers. Middle tier performs queuing, application execution, and DB staging. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. Middle layer adds scheduling and prioritization for work in progress. The three tier client/server architecture improves performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach. Flexibility in partitioning can be a simple as "dragging and dropping" application code modules onto different computers in some three tier architectures. Difficult Development environments 44
Three tier with message server Messaging is a way to implement three tier architectures. Messages are prioritized and processed asynchronously. Messages consist of headers that contain priority information, and the address and identification number. The message server connects to the relational DBMS and other data sources. The difference between TP monitor technology and message server is that: the message server architecture focuses on intelligent messages, TP Monitor environment has the intelligence in the monitor, and treats transactions as dumb data packets. Messaging systems are good solutions for wireless infrastructures. 45
Blackboard Style BB Metaphor: A group of specialists work cooperatively to solve a problem, using a blackboard as the workplace for developing the solution. The problem and initial data are written on the blackboard. The specialists watch the blackboard, and when a specialist finds sufficient information on the board to make a contribution, he records his contribution on the blackboard. 46
BB Architecture Overview Penny Nii, Blackboard Systems at the Architecture Level, Expert Systems with Applications, Vol 7, pp43-54, 1994 Blackboard Layers KS KS consist of a Condition (Trigger) Section and the Body KS Essentially what happens is: An event has occurred that has resulted in the BB state changing. If am registered to Accept events on that level of the BB and if the event satisfies my curiosity and any constraints (Trigger conditions), then I will apply the KS body to evaluate the Event and perform the requested operation KS KS KS Controller Control Data 47
Repository Architecture Styles: Blackboard A blackboard model usually has three components: General Constructs The knowledge source: independent pieces of application specific knowledge. Interaction between knowledge sources takes place only through the blackboard. The blackboard data structure: state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem. Control: driven by the state of the blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable. General Operation Invocation of a knowledge source is dependent upon the state of the blackboard. Control can be implemented in the knowledge source, the blackboard, externally, or a combination of these. Blackboard systems have traditionally been used for applications requiring requiring complex interpretations of signal processing. Programming environments can be considered as having a shared repository of programs and program fragments. 48
Repository Architecture Styles: Blackboard http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm Independence of Expertise Each knowledge source is a specialist at solving certain aspects of the problem. No KS requires other KSs in making its contribution. Once it finds the information it needs on the blackboard, it can proceed without any assistance from other KSs. KSs can be added, removed, and changed without affecting other KSs. (Actually A Primary key to evolving a product s functionality and architecture) Diversity in Problem Solving Techniques Internal KS representation and inference machinery is hidden from view. Flexible Representation of Blackboard Information The blackboard model does not place any prior restrictions on what information can be placed on the blackboard. One blackboard application might require consistency, another might allow incompatible alternatives. Common Interaction Language There must be a common understanding of the representation of the information on the blackboard, understood by all KSs. There's a tradeoff between representational expressiveness of a specialized representation shared by only a few KSs and a representation understood by all. 49
Repository Architecture Styles: Blackboard http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm Positioning Metrics When the blackboard gets full, we must still have a way for the KSs to immediately see the information important to them. Often we have multiple or subdivided blackboards, or information is sorted alphabetically or by reference. Efficient retrieval is also important. Event Based Activation KSs are triggered in response to events (they don't actively watch the blackboard). The board knows what kind of event each KS is looking for, and considers it for activation whenever that kind of event occurs. Need for Control A control component separate from the individual KSs is responsible for managing the course of problem solving. The control component doesn't share the specialties of the KS's, but looks at each KSs evaluation of its own contribution to decide which one gets to go. 50
