Architectural Patterns Architectural Patterns The fundamental - PowerPoint PPT Presentation

Architectural Patterns Architectural Patterns The fundamental problem to be solved with a large system is how to break it into chunks manageable for human programmers to understand, implement, and maintain. Dr. James A. Bednar Large-scale patterns for this purpose are called jbednar@inf.ed.ac.uk architectural patterns . Architectural patterns are related to http://homepages.inf.ed.ac.uk/jbednar design patterns, but higher level and larger scale. Dr. David Robertson See Buschmann et al. (1996), chapter 2 for more details. dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm SAPM Spring 2006: Architecture 1 SAPM Spring 2006: Architecture 2 Layers: Pattern Architectural Pattern Examples High level decompositions: Layer 3 • Layers • Pipes and filters Component 3.1 • Blackboard Distributed systems: Layer 2 • Broker Interactive systems: Component 2.1 Component 2.2 • Model-view-controller • Presentation-abstraction-control Layer 1 Adaptable/reusable systems: • Microkernel Component 1.1 Component 1.2 • Scripted components SAPM Spring 2006: Architecture 3 SAPM Spring 2006: Architecture 4

Layers: Problem Layers: Solution • Start with the lowest level • System has different levels of abstraction • Build higher layers on top • Typical: Requests go down, notification goes back up • Same level of abstraction within a layer • It is possible to define stable interfaces between layers • No component spreads over two layers • Want to be able to change or add layers over time • Try to keep lower layers leaner • Specify interfaces for each layer • Try to handle errors at lowest layer possible SAPM Spring 2006: Architecture 5 SAPM Spring 2006: Architecture 6 Layers: Advantages Layers: Example (TCP/IP) • Reuse of layers FTP FTP • Standardization of tasks and interfaces TCP TCP • Only local dependencies between layers • Programmers and users can ignore other layers IP IP • Different programming teams can handle each layer Ethernet Ethernet physical connection SAPM Spring 2006: Architecture 7 SAPM Spring 2006: Architecture 8

Layers: Liabilities Pipes and Filters: Pattern • Cascades of changing behavior • Lower efficiency of data transfer When processing a stream of data, each processing step is done by a filter and the filters are connected by pipes • Difficult to choose granularity of layers carrying data. • Difficult to understand entire system Connecting filters in different combinations gives different ways of processing the data streams. SAPM Spring 2006: Architecture 9 SAPM Spring 2006: Architecture 10 Pipes and Filters: Problem Pipes and Filters: Solution • Data stream processing which naturally subdivides • Filter may consume/deliver data incrementally into stages • Filters may be parameterisable (e.g. UNIX filters) • May want to recombine stages • Input from data source (e.g. a fil e) • Non-adjacent stages don’t share information • Output to a data sink • May desire different stages to be on different • Sequence of filters from source to sink gives a processors processing pipeline • Helpful: Standardized data structure between stages SAPM Spring 2006: Architecture 11 SAPM Spring 2006: Architecture 12

Pipes and Filters: Example Pipes and Filters: Advantages • Pipes remove need for intermediate files Lexical analysis • Can replace filters easily Symbol table • Can achieve different effects by recombination Syntax analysis (increases long-term usefulness) • If data stream has a standard format, Semantics analysis filters can be developed independently • Incremental filters allow parallelization Intermediate code generation SAPM Spring 2006: Architecture 13 SAPM Spring 2006: Architecture 14 Blackboard: Pattern Pipes and Filters: Liabilities A central, “blackboard” data store is used to describe a • Difficult to share global data partial solution to a problem. • Parallelization is less useful than may seem A variety of knowledge sources are available to work on • Expensive if there are many small filters and a high parts of the problem and these may communicate only data transfer cost with the blackboard, reading the current partial solution or suggesting modifications to it via a control component. • Difficult to know what to do with errors (especially if filters are incremental) SAPM Spring 2006: Architecture 15 SAPM Spring 2006: Architecture 16

Blackboard: Problem Blackboard: Solution • Problem solvers work independently (and • Immature or poorly specified domain opportunistically) on parts of the problem • No deterministic or optimal solution known for problem • Share a common data structure (the blackboard) • Solutions to different parts of problem may require • A central controller manages access to the blackboard different representational paradigms • The blackboard may be structured (e.g. into levels of • May be no fix ed strategy for combining contributions abstraction) so problem solvers may work at different of different problem solvers levels • May need to work with uncertain knowledge • Blackboard contains original input and/or partial solutions SAPM Spring 2006: Architecture 17 SAPM Spring 2006: Architecture 18 Blackboard: Example Blackboard: Advantages • Allows problem solvers to be developed independently Phrase Word Segmentation creation creation • Easy (within limits) to experiment with different Controller problem solvers and control heuristics Blackboard Phrase1...Phrase2... • System may (within limits) be tolerant to broken problem solvers, which result in incorrect partial Word1...Word2...Word3...Word4... solutions S1...S2...S3...S4...S5...S6...S7...S8...S9... SAPM Spring 2006: Architecture 19 SAPM Spring 2006: Architecture 20

Blackboard: Liabilities Broker: Pattern Decoupled components interact through remote service • Difficult to test invocations. • Difficult to guarantee an optimum solution Communication is coordinated by a broker component • Control strategy often heuristic which does things like forwarding requests and relaying • May be computationally expensive results. • Parallelism possible but in practice we need much synchronization SAPM Spring 2006: Architecture 21 SAPM Spring 2006: Architecture 22 Broker: Problem Broker: Solution • Large scale system where scaling to many • Use brokers to mediate between clients and servers components is an issue • Clients send requests to a broker • Components must be decoupled and distributed • Brokers locate appropriate servers; forward requests; • Services required for adding, removing, activating, and relay results back to clients locating components at run time • May have client-side and/or server-side proxies • Designers of individual components should not need to know about the others SAPM Spring 2006: Architecture 23 SAPM Spring 2006: Architecture 24

Broker: Example Broker: Advantages CORBA: Common Object Request Broker Architecture • Components can be developed independently (e.g. JADE) • Location transparency OLE/DCOM/Active X • Components easily adapted Multi-agent systems are often coordinated through • Broker easily adapted brokers such as JADE that provide a standard mechanism for relaying messages, based on a high-level communication protocol. Individual agents may be implemented in any language as long as they can input/output according to the protocol. SAPM Spring 2006: Architecture 25 SAPM Spring 2006: Architecture 26 Broker: Liabilities Model-View-Controller: Pattern Interactive system arranged around a model of the core • Low fault tolerance functionality and data. • Limited efficiency (high communications cost) View components present views of the model to the user. • Difficult to test Controller components accept user input events and translate these to appropriate requests to views and/or model. A change propagation mechanism takes care of propagation of changes to the model. SAPM Spring 2006: Architecture 27 SAPM Spring 2006: Architecture 28

M-V-C: Problem M-V-C: Solution • Develop a core model which is independent of style of • User interfaces attract many change requests over input/output time • Define different views needed for parts/whole model • Different users ask for different changes • Each view component retrieves data from the model • User interface technologies change rapidly and displays it • You may want to support different “look and feel” • Each view component has an associated controller standards component to handle events from users • Important core code can be separated from the • The model component notifie s all appropriate view interfaces components whenever its data changes SAPM Spring 2006: Architecture 29 SAPM Spring 2006: Architecture 30 M-V-C: Example M-V-C: Advantages Spreadsheet • Multiple views of the same model Controller • View synchronization • View components can be plugged in Labour: 60% Model • Changes to interfaces without touching the model Tory: 30% Lib.Dem: 10% Views Pie chart Bar chart SAPM Spring 2006: Architecture 31 SAPM Spring 2006: Architecture 32