Architectural Styles Patterns Definitions of Style F Architectural

Architectural Styles & Patterns

Definitions of Style F Architectural styles are recurring organizational patterns and idioms. - Shaw & Garlan F Established, shared understanding of common design forms is a mark of a mature engineering field. - Shaw & Garlan F Architectural style is an abstraction of recurring composition and interaction characteristics of a set of architectures. - Taylor F Styles are key design idioms that enable exploitation of suitable structural and evolution patterns and facilitate component, connector, and process reuse. - Medvidovic

Architectural Styles and Patterns F An architectural style defines a family of architectures constrained by ü Component/connector vocabulary, e. g. , û layers and calls between them ü Topology, e. g. , û stack of layers ü Semantic constraints, e. g. , û a layer may only talk to its adjacent layers F For each architectural style, an architectural pattern can be defined ü It’s basically the architectural style cast into the pattern form ü The pattern form focuses on identifying the a problem, context of a problem with its forces, and a solution with its consequences and tradeoffs; it also explicitly highlights the composition of patterns

Basic Properties of Styles F A vocabulary of design elements ü component and connector types ü e. g. , pipes, filters, objects, servers F A set of configuration rules ü topological constraints that determine allowed compositions of elements û e. g. , a component may be connected to at most two other components F A semantic interpretation ü compositions of design elements have well-defined meanings F Possible analyses of systems built in a style ü code generation is a special kind of analysis

Benefits of Styles F Design reuse ü well-understood solutions applied to new problems F Code reuse ü shared implementations of invariant aspects of a style F Understandability of system organization ü a phrase such as “client-server” conveys a lot of information F Interoperability ü supported by style standardization ü e. g. , CORBA, Java. Beans F Style-specific analyses ü enabled by the constrained design space F Visualizations ü style-specific depictions matching engineers’ mental models

Describing an Architectural Style F Software architectures are represented as graphs where ü nodes represent components, û procedures û modules û processes û tools û databases û … ü and edges represent connectors. û procedure calls û event broadcasts û database queries û pipes û …

Determining an Architectural Style F What is the design vocabulary? F What are the allowable structural patterns? F What is the underlying computational model? F What are the essential invariants of the style? F What are common examples of its use? F What are the (dis)advantages of using the style? F What are the style’s specializations?

Architectural Styles and Patterns F Architectural styles and patterns ü ü ü ü ü Data flow Call-and-return Interacting processes Data-oriented repository Data-sharing Hierarchical Process control systems Table-driven Other F Heterogeneous architectures

“Pure” Form of Styles F When we introduce a new style, we will typically first examine its “pure” form. ü Pure architectural style are rarely found in practice ü Systems in practice û Regularly deviate from the academic definitions of these systems û Typically feature many architectural styles simultaneously ü As an architect you must understand the “pure” styles to understand the strength and weaknesses of the style as well as the consequences of deviating from the style

Observations F Different styles result in ü different architectures ü architectures with greatly differing properties F A style does not fully influence the resulting architecture ü ü a single style can result in different architectures considerable room for individual judgments variations among architects different emphases û e. g. , imposed by the customer F A style defines a domain of discourse ü about a problem (domain) ü about the resulting system ü different architectures lead architects to ask different questions

Data Flow F A data flow system is one in which: ü The availability of data controls the computation ü The structure of the design is determined by the orderly motion of data from component to component ü The pattern of data flow is explicit ü This is the only form of communication between components F There are variety of variations on this general theme: ü How control is exerted (e. g. , push versus pull) ü Degree of concurrency between processes ü Topology

Data Flow F Patterns of Data Flow in Systems ü Data can flow in arbitrary patterns ü Primarily we are interested in linear data flow patterns ü. . . or in simple, constrained cyclical patterns. . .

Data Flow F Kinds of Data Flow Architectures ü Batch sequential ü Dataflow network (pipes&filters) û acyclic, fanout, pipeline, Unix, etc. ü Closed loop control F Components: Data Flow Components ü Interfaces are input ports and output ports û Input ports read data; û output ports write data. ü Computational model: û read data from input ports, compute, write data to output ports

Data Flow F Connectors: Data Streams ü Uni-directional û Usually asynchronous, buffered ü Interfaces are reader and writer roles ü Computational model: transport data from writer roles to reader roles F Systems ü Arbitrary graphs ü Computational model: functional composition

Push-Based Style F Distinguished from pull-based (e. g. , the Web)

Push-Based Style F Components ü producer ü receiver F Connectors ü ü channel broadcaster transport system repeater, cache, proxy F Asymmetric communication model ü producers ≠ receivers ü fewer producers but more receivers per producer than eventbased style F Relatively tight coupling between source and receiver via subscribed channels

Batch Sequential Systems F Components (processing steps) are independent programs F Connectors are some type of media - traditionally magnetic tape F Each step runs to completion before the next step begins

Batch Sequential Systems F History ü Mainframes and magnetic tape ü Limited disk space ü Block scheduling of CPU processing time F Business data processing ü Discrete transactions of predetermined type and occurring at periodic intervals ü Creation of periodic reports based on data periodic data updates

Batch Sequential Systems F Transformational data analysis ü Raw data is gathered analyzed in a stepwise, batchoriented fashion F Typical applications: non real-time, batch oriented computations such as: ü Payroll computations ü IRS tax return computations

Pipes and Filters F It 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.

Pipes and Filters F The tape of the batch sequential system, morphed into a language and operating system construct F Compared to the batch-sequential style, data in the pipe&filter style is processed incrementally. F Components (Filters) ü Read streams of data on input producing streams of data on output ü Local incremental transformation to input stream (e. g. , filter, enrich, change representation, etc. ) ü Data is processed as it arrives, not gathered then processed ü Output usually begins before input is consumed F Connectors (Pipes) ü Conduits for streams, e. g. , first-in-first-out buffer ü Transmit outputs from one filter to input of other

Pipes and Filters F Invariants ü Filters must be independent, no shared state ü Filters don’t know upstream or downstream filter identity ü Correctness of output from network must not depend on order in which individual filters provide their incremental processing F Common specialisations ü pipelines - linear sequences of filters ü bounded pipes - limited amount of data on a pipe ü typed pipes - data strongly typed

Pipes and Filters F Examples ü Unix pipes allow for connecting Unix processes û cat file | grep Erroll | wc -l ü lex/yacc-based compiler û Scanning->parsing->semantic analysis->code generation ü Image processing û Application of various filters ü Signal processing ü Voice and video streaming ü …

Data Pulling and Data Pushing F What is the force that makes the data flow? F Four choices: ü Push: data source pushes data in a downstream direction ü Pull: data sink pulls data from an upstream direction ü Push/pull: a filter is actively pulling data from a stream, performing computations, and pushing the data downstream ü Passive: don’t do either, act as a sink or source for data F Combinations may be complex and may make the “plumber’s” job more difficult ü if more than one filter is pushing/pulling, synchronization is needed

Data Pulling and Data Pushing F A Push Pipeline With an Active Source

Data Pulling and Data Pushing F A Pull Pipeline With an Active Sink

Data Pulling and Data Pushing F A Mixed Push-pull Pipeline With Passive Source and Sink

Data Pulling and Data Pushing F A Pipeline With Active Filters and Synchronizing Buffering Pipes

Pipes and Filters F Strengths ü Easy to understand - overall behaviour is a simple ü ü ü composition of behaviour of individual filters. Reuse - any two filters can be connected if they agree on that data format that is transmitted. Ease of maintenance - filters can be added or replaced. Prototyping e. g. Unix shell scripts are famously powerful and flexible, using filters such as sed and awk. Architecture supports formal analysis - throughput and deadlock detection. Potential for parallelism - filters implemented as separate tasks, consuming and producing data incrementally.

Pipes and Filters F Weaknesses ü Can degenerate to ‘batch processing’ - filter processes all of its data before passing on (rather than incrementally). ü Often poor inherent performance – e. g. , parsing/unparsing in each filter & sharing global data is expensive or limiting. ü Can be difficult to design incremental filters. ü Not appropriate for interactive applications - doesn’t split into sequential stages. û Model-View-Controller is a specific styles for interactive systems.

Pipes and Filters F Weaknesses ü Synchronization of streams will constrain architecture. ü Error handling is Achilles heel û e. g. filter has consumed three quarters of its input and produced half its output and some intermediate filter crashes! û Restart or resynchronize pipeline. ü Implementation may force lowest common denominator on data transmission û e. g. Unix scripts everything is ASCII.

Pipe-and-Filter vs. Batch Sequential F Both decompose the task into a fixed sequence of computations (components) interacting only through data passed from one to another Batch Sequential Pipe-and-Filter course grained fine grained high latency results starts processing external access to input localized input no concurrency possible non-interactive awkward but possible

Call-and-return F Main Program + Subroutine Architecture ü Classic style since 60 s - pre-OO. ü Hierarchical decomposition into subroutines (Components) each solving a well defined task/function. ü Data passed around as parameters. ü Main driver provides a control loop for sequencing through subroutines. F Information hiding ü ADT, object, naive client/server

Data Abstraction/Object Oriented F Widely used architectural style ü Components: û Objects or abstract data types (data and associated operations) ü Connections: û Messages or function/procedure invocations ü Key aspects: û Object preserves integrity of representation - no direct access û Representation is hidden from objects

Data Abstraction/Object Oriented F Widely used architectural style ü Variations: û û Objects as concurrent tasks Multiple interfaces for objects (Java !) Objects are responsible for their internal representation integrity Internal representation is hidden from other objects ü Note that Data Abstraction is different from Object. Oriented - no inheritance.

Object-Oriented Strengths/Weaknesses F Strengths: ü Change implementation without affecting clients (assuming interface doesn’t change) ü Can break problems into interacting agents (distributed across multiple machine / networks). F Weaknesses: ü To interact objects must know each other’s identity (in contrast to Pipe-and-Filter). ü When identity changes, objects that explicitly invoke it must change (Java interfaces help though). ü Side effect problems in object method invocations û if A uses B and C uses B, then C effects on B can be unexpected to A (and vice-versa) ü Complex dynamic interactions – distributed functionality.

Interacting processes F Communicating processes ü Distributed objects, LW processes, … F Event systems ü implicit invocation, pure events, …

Event-Based, Implicit Invocation F This architectural style (pattern) is characterised by the style of communication between components: ü Rather than invoking a procedure directly or sending a message a component announces, or broadcasts, one or more events. F Basically, components communicate using a generalised Observer Design Pattern style of communication. F BUT this is a different architectural style from OO style ü Communications are broadcast-based and components are not necessarily objects.

Implicit Invocation F Components ü Modules whose interfaces provide a collection of procedures/methods and a set of events that it may announce F Connectors ü Bindings between event announcements (explicit or implicit in response to events) and procedure/method calls ü Traditional procedure/method calls (to bypass implicit invocation)

Implicit Invocation F Invariants ü Announcers of events do not know which components will be affected by those events ü Components cannot make assumptions about ordering of processing, or what processing will occur as a result of their events F Common Examples ü Programming environment tool integration ü User interfaces - Model-View-Controller ü Syntax-directed editors to support incremental semantic checking

Implicit Invocation F Strengths ü Strong support for reuse - plug in new components by registering it for events ü Maintenance û add and replace components with minimum affect on other components in the system.

Implicit Invocation F Weaknesses ü Loss of control û when a component announces an event, it has no idea what components will respond to it û cannot rely on order that these components will be invoked û cannot tell when they are finished ü Ensuring correctness is difficult because it depends on context in which invoked. û Unpredictable interactions. ü Sharing data û Hence explicit invocation is usually provided as well as implicit invocation. û the Observer Design Pattern

Model-View-Controller F A decomposition of an interactive system into three components: ü A model containing the core functionality and data, ü One or more views displaying information to the user, and ü One or more controllers that handle user input. F A change-propagation mechanism (i. e. , observer) ensures consistency between user interface and model, e. g. , ü If the user changes the model through the controller of one view, the other views will be updated automatically F Sometimes the need for the controller to operate in the context of a given view may mandate combining the view and the controller into one component F The division into the MVC components improves maintainability

Model-View-Controller

Model-View-Controller F Example:

Data-Oriented Repository F Transactional databases ü – True client/server F Blackboard F Modern compiler

Repositories / Data Centred F Characterized by a central data store component representing systems state and a collection of independent components that operate on the data store. F Connections between data store and external components vary considerably in this style: ü Transactional databases: û Incoming stream of transactions trigger processes to act on data store. û Passive. ü Blackboard architecture: û Current state of data store triggers processes. û Active.

Repository Architectures: Examples F Information systems F Programming environments F Graphical editors F AI knowledge bases F Reverse engineering systems F Variations: ü Data structure in memory or on disk, concurrency, triggering

Blackboard F Characteristics: ü Cooperating ‘partial solution solvers’ collaborating but not following a pre-defined strategy.

Blackboard F Current state of the solution stored in the blackboard. ü System control is entirely driven by the blackboard state F Two kinds of components ü central data structure — blackboard ü components operating on the blackboard F Examples: ü Problems for which no deterministic solution strategy is known, but many different approaches (often alternative ones) exist and are used to build a partial or approximate solution. û AI: vision, speech and pattern recognition û Modern compilers act on shared data: symbol table, abstract syntax tree

Characteristics of Repositories F Advantages ü Efficient way to store large amounts of data. ü Sharing model is published as the repository schema. ü Centralized management for û backup, û security and û concurrency control F Disadvantages ü Must agree on a data model a priori ü Data evolution is expensive ü Difficult to distribute data

Hierarchical F Hierarchical systems can be tree-like in general ü Connectors are protocols of interaction

Hierarchical F Layered systems ü Hierarchical system organization û “multi-level client-server” û each layer exports an “API” to be used by above layers ü Each layer acts as a û server: service provider to layers “above” û client: service consumer from layers “below” ü Each layer collects services at a particular level of generality / application specificity. ü In a pure layered system: û Layers are hidden to all except adjacent layers. ü Types: û Interpreter û Tiered

Layered Systems F Corresponds to a stack of layers. F “Onion Skin” model…

Layered Systems F Components within same layer interact F Components within different layers might call each other directly

Layered Systems F Applicability ü A large system that is characterized by a mix of high and low level issues, where high level issues depend on lower level ones. F Components ü Group of subtasks which implement a ‘virtual machine’ at some layer in the hierarchy û e. g. , a set of functions or classes F Connectors ü Protocols / interface that define how the layers will interact û e. g. , function calls or event sends according to some protocol

Layered Systems F Invariants ü Limit layer (component) interactions to adjacent layers û in practice this may be relaxed for efficiency reasons a layer may talk directly to some non-adjacent layers (“layer bridging”) F Typical variant relaxing the pure style ü A layer may access services of all layers below it F Common Examples ü Communication protocols: each level supports communication at a level of abstraction, lower levels provide lower levels of communication, the lowest level being hardware communications.

Designing Error Handling Strategies F Error can be handled in layer in which it occurred, or passed to next higher level F Do not swamp upper layers with different error handling and many errors ü Condense several error types into a general error type ü Upper layers may be confronted with error they do not understand F May require error to be transformed into an error that the upper layer understands [portability issues? ] F Best to handle errors in layers they occur

Layered Systems: Examples

Layered Systems: Examples

Layered Systems F Strengths ü Increasing levels of abstraction as we move up through layers û partitions complex problems ü Maintenance û in theory, a layer only interacts with layers above and below. Change has minimum effect. ü Reuse û different implementations of the same level can be interchanged ü Standardization based on layers e. g. OSI

Layered Systems F Weaknesses ü Not all systems are easily structured in layers (e. g. , mobile robotics) ü Performance - communicating down through layers and back up, hence bypassing may occur for efficiency reasons. F Similar strengths to data abstraction / OO but with multiple levels of abstraction (e. g. well-defined interfaces, implementation hidden). F Similar to pipelines, e. g. , communication with at most one component at either side, but with richer form of communication. F A layer can be viewed as “virtual machine” providing a standardized interface to the one above it

Interpreter F Architecture is based on a virtual machine produced in software. F Special kind of a layered architecture where a layer is implemented as a true language interpreter. F Components are ‘program’ being executed, its data, the interpretation engine and its state. F Example: ü Java Virtual Machine. û Java code translated to platform independent bytecodes. û JVM is platform specific and interprets (or compiles - JIT) the bytecodes.

Interpreter

Interpreter F Examples: ü Programming and scripting languages û Awk, Perl, … ü Rule-based systems û Prolog, Coral, … ü Micro-coded machine û Implement machine code in software ü Presentation package û Display a graph, by operating on the graph

Tiered Architectures F Special kind of layered architecture for enterprise applications F Evolution ü Two Tier ü Three Tier ü Multi Tier

Two Tier Client-Server Architecture Design F Developed in the 1980 s to decouple (typically form/based) user interface from the storage of data. F Improved maintainability ü Changes to UI and database can be made independently ü Scales up to 100 users ü Client tier û User System Interface û Some Processing Management ü Server tier û Database Management û Some Processing Management

Three Tier Client Server Architecture Design F Emerged in the 1990 s to overcome the limitations of the two tier architecture by adding an additional middle tier. F This middle tier provides process management: ü business logic and rules are executed ü can accommodate hundreds of users by providing generic services such as queuing, application execution, and database staging. F An effective distributed client/server design that provides increased performance, flexibility, maintainability, reusability, and scalability, while hiding the complexity of distributed processing from the user.

Three Tier Client Server Architecture Design

Example of a Multi Tier Architecture: J 2 EE

Process-Control Architecture Style F Suitable for applications whose purpose is to maintain specified properties of the outputs of the process at sufficiently near given reference values. F Components ü Process definition includes mechanisms for manipulating some process variables. ü Control algorithm for deciding how to manipulate process variables.

Process-Control Architecture Style F Connectors are the data flow relations for ü Process Variables û Controlled variable whose value the system is intended to control. û Input variable that measures an input to the process. û Manipulated variable whose value can be changed by the controller. ü Set Point is the desired value for a controlled variable. ü Sensors to obtain values of process variables pertinent to control.

Feed-Back Control System F The controlled variable is measured and the result is used to manipulate one or more of the process variables.

Open-Loop Control System F Information about process variables is not used to adjust the system.

Process Control: Examples F Real-time system software to control: ü Automobile anti-lock brakes. ü Nuclear power plants ü Automobile cruise-control

Other Architectures F Distributed Systems: ü Common organizations for multi-process systems characterized either by topological organization (e. g. ring or star), and inter-process protocols (e. g. Client-Server architectures). ü Broker pattern: û An arrangement where decoupled components interact by remote service invocations. û A broker component is responsible for coordinating communication and for transmitting results and exceptions.

Heterogeneous Architectures F In practice the architecture of large-scale system is a combination of architectural styles. This leads to: ü Hierarchical heterogeneous, ü Locational heterogeneous, or ü Perspective heterogeneous

Heterogeneous Architectures F Hierarchical heterogeneous ü A Component in one style may have an internal style developed in a completely different style (e. g, pipe component developed in OO style, implicit invocation module with a layered internal structure, etc. ) F Locational heterogeneous ü Overall architecture at same level is a combination of different styles (e. g. , repository (database) and main-program subroutine, etc. ) ü Here individual components may connect using a mixture of architectural connectors - message invocation and implicit invocation. F Perspective heterogeneous ü Different architecture in different perspectives (e. g. , structure of the logical view, structure of the physical view, etc. )

Heterogeneous Architectures: Example F Enterprise Architectures

Questions ?