Applying Architectural Styles and Patterns

Outline Defining Architectural Patterns and Style The activation model Styles and Quality Attributes Common Architectural Styles Dataflow systems Call-and-return systems Independent components Virtual machines Repositories

Introduction Relying solely on design operators to design an architecture can be a slow process. By utilizing existing design experience from the software engineering community design productivity can be improved. There are two types of reusable architectural products: Product families Architectural styles and patterns

Architectural Style It is a type of metamodel that prescribes a set of elements and their relationships that characterize a system based on the style. These elements are expressed as components and connectors. Their relationships are the constraints on how components and connectors may be combined.

Architectural Patterns A pattern is a solution that strikes some balance between competing forces. However, what makes it a pattern is the fact that it is recurring. If a design solution in its essential distilled form is found in multiple systems and is a successful design, then this solution is a pattern.

Architectural Patterns (Cont’d) A pattern language is a set of patterns, together with the rules for describing how patterns are created and how they must be arranged with respect to other patterns. The patterns are the vocabulary of the language, and the rules for their implementation and combination are the grammar. Patterns in a pattern language can be constructed from other patterns.

Architectural Styles An architectural style is a framework for a solution and not really a solution itself. The selection of a style limits the scope of the solution space. According to Ivar Jacobson, the architectural style of a system is “the denotation of the modeling languages used when modeling the system.” It includes the guiding principles and prescriptions that the other development model elements must satisfy.

Architectural Styles (Cont’d) It is the foundation of a philosophy of building. An architectural style defines a vocabulary of components and connector types and a set of constraints on how they can be combined. Most applications, however, are a combination of styles, i.e., they have a heterogeneous architectural style. There are many parameters that we can use to characterize software architecture: The way in which control is passed between components (activation model) The quality attribute emphasis (e.g., maintainability and performance)

Activation Model This model describes how components are activated and how information is passed between them (the control principle of the architecture). In classic procedural languages and their object-oriented derivatives, method invocation and method execution are bound, i.e., method execution follows immediately from method invocation. In languages like Smalltalk method invocation and method execution are decoupled.

Activation Model (Cont’d) At the design level you can simulate these activation models in the language level. Synchronous communication means that the client component activates a server component and then waits for a response. A variation of this is the balking model in which a component may reject a request for any reason.

Activation Model (Cont’d) Another variation is the timeout in which a client component assumes that the server has failed to complete a request after a certain amount of time. Asynchronous communication means that the client doesn’t wait on a response from the server before continuing. In the delegating pattern, a client component invokes a server component and provides an address to which the response is to be sent.

Activation Model – Patterns of Information Passing Data elements can be passed directly between processing elements (pipes and filters). Data elements may also be shared in a central store and accessed by different processing elements (repository).

Uses of the Activation Model To compare different architectural styles. To identify the appropriate architectural style for the entire system or the best combination of architectural styles.

Styles and Quality Attributes Each style emphasizes a set of quality attributes while de-emphasizing another set. Pipes and filters emphasizes reusability and adaptability but sacrifices maintainability with respect to changes in data representation. Object-oriented systems emphasize maintainability but are not easily reused

Styles and Quality Attributes (Cont’d) Repository-based systems emphasize adaptability and performance but are not highly reusable or maintainable in terms of changes to algorithms or data representations Styles can be combined in order to exhibit different quality attributes.

Common Architectural Styles (Adapted from Shaw and Garlan) Dataflow systems Batch sequential Process control Pipes and filters Call-and-return systems Main program and subroutine Object-oriented systems Hierarchical layers

Common Architectural Styles (Cont’d) Independent components Communicating processes Event systems Virtual machines Interpreters Rule-based systems Repositories Databases Hypertext systems Blackboards

How can we study Architectural Styles How can we study Architectural Styles? (Perry James – Concordia University) By examining the following for each: Connectors, components Key characteristics Strengths & weaknesses Variants & specializations Examples

Dataflow Systems

Style – Process Control Stolen from Dan

Process Control: Components & Connectors The following slides offer only an introduction to the process control style. The process control style is modeled on the process control systems that are common in other engineering disciplines (e.g. chemical engineering). Motivating example: furnace Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

Process Control: Example Open-loop temperature control.

Process Control: Example Closed-loop temperature control.

Process Control: Example Applied to software

Process Control: Components & Connectors   Process Input variables Controlled variables Changes to manipulated variables Controller Set point (Feedback control) (Feed-forward control) Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

Process Control: Key Characteristics Organization: Computational elements (important separation) Process definition. Control algorithm. Data elements: Process variables. Set point. Control algorithm uses information about actual system state to tune the process, driving the actual state towards the intended state.

Process Control: Strengths Well suited for the control of continuous processes particularly where the control algorithm is subject to change (possibly even at run-time).

Process Control: Weaknesses Not easily applicable when multiple interacting processes (and controls) are needed.

Process Control: Examples Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

Process Control: Examples Cruise control system Heating system Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

Style – Pipes and Filters: Components & Connectors Components: Filter Completely independent entities Consume streams of inputs and produce streams of outputs Context independent (do not know what produced the input or will consume the output) Output starts before input is (entirely) consumed (incremental transformation of data) Connectors: Pipes Carrier of data streams Binding between component ports Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

Pipes and Filters: Key Characteristics Data Flow Architecture Model assumes concurrent processing. Filters are independent. Do not share data. Do not know identity of neighbors. Individual filter behavior: simple I/O relation System behavior = simple composition of individual filter behaviors. Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

Pipes and Filters: Strengths System easy to understand System = simple composition of individual filters No complex interaction between components Reuse, Enhancement & Maintainability Easy to add filters & replace existing ones (why?) Concurrency can be easily exploited.

Pipes and Filters: Weaknesses Can lead to batch sequential processing Not well suited to interactive applications Use of this style may Force least common denominator in data format Can lead to extra work for filters to assemble and organize data Can lead to decreased performance and increased filter complexity

Pipes and Filters: Variations Pipelines Linear sequences of filters Batch Sequential Systems Pipeline; but each step runs to completion before the next starts Bounded pipes Restriction on the amount of data that can temporarily reside/buffered on/in a pipe Typed pipes Restricts the data passed between two filters to a well-defined type “UI pipes” Each filter is associated with UI to allow the user to set parameters of operation Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

Pipes and Filters: Examples

Pipes and Filters: Examples Unix shell: e.g. ls | grep “my” | wc –l Traditional view of compilers Also has applications in Signal processing Parallel programming Functional programming Distributed systems

Style – Object-Oriented Systems: Components & Connectors Components: Classes & Objects Connectors: Method calls Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

Object-Oriented Systems: Key Characteristics Call and return architecture Interaction through method invocation Based on data abstraction: Encapsulation Information hiding Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

Object-Oriented Systems: Encapsulation A packaging / scoping mechanism for names Names can refer to data, types, … Especially, a means of packaging data Access points at interface

Object-Oriented Systems: Information Hiding Design principle A module has a “secret”, usually a design decision makes particular design choice “invisible” to clients E.g. Choice of algorithm Data structure

Object-Oriented Systems: Strengths Naturally supports information hiding, which shields implementation changes from clients Encapsulation and information hiding reduce coupling => Enhances maintainability Allows systems to be modeled as collections of collaborating objects => can be an effective means of managing system complexity

Object-Oriented Systems: Weaknesses Object identity must be known for method invocation => Identity change of an object affects all calling objects Contrast this to pipe-and-filter … Concurrency problems through concurrent access

Object-Oriented Systems: Variations Active classes When instantiated, control their own execution Can operate standalone (rather than being invoked by other classes) Own thread Other OO variants such as support (or not) of multiple inheritance, interfaces, static typing, etc. although most OOPL have compromised security—information hiding—for sake of efficiency

Object-Oriented Systems: Examples

Object-Oriented Systems: Examples Object-oriented systems can be seen as an evolution of ADTs

Style: Hierarchically Layered Systems 3-Tiered Enterprise Applications Presentation Domain Logic Technical Services

Hierarchically Layered Systems: Components & Connectors Components: Layers Connectors: Protocols that define how layers interact Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

Hierarchically Layered Systems: Key Characteristics Hierarchical organization Only adjacent layers communicate Each layer provides services to the level above and serves as a client to the layer below Lower layer is unaware of higher layer Each layer hides its lower layers from the layers above Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

Hierarchically Layered Systems: Strengths A single layer acts as a coherent whole No need to know much about other layers Portability: Easy to replace a layer with another implementation of its services Maintainability: Each layer’s role is well defined Minimized dependencies Supports design based on increasing levels of abstraction

Hierarchically Layered Systems: Weaknesses Performance High-level functions only indirectly access low-level functions -> must go through the various layers Difficult to find the right abstractions (especially with many layers involved) Risk of abstracting the wrong thing Not all systems fit into the layered style The scope of one component may overlap several layers

Hierarchically Layered Systems: Variations Layer may accesses other lower level layers than just the layer below Less pure Increased performance although most OOPL have compromised security—information hiding—for sake of efficiency

Hierarchically Layered Systems: Examples

Hierarchically Layered Systems: Examples Protocols TCP/IP OSI ISO model X Window system Enterprise Applications Presentation layer Domain logic layer Data source layer

Style: Event Systems: Components & Connectors Component: (active or passive) object, capsule, module Can be an instance of a class, an active class, or simply a module. Interface provides methods and ports. Publisher: individual components announce data that they wish to share with their subscribers. Subscriber: individual components register their interest for published data. Connector: “connector”, channel, binding, callback. Offers one-to-one, one-to-many, many-to-one connections; Asynchronous event broadcast. Synchronous event broadcast & await reply (call-and-return) Like an assembly line, each filter does what it can and (from Dan – who got it from Patrice)

Event Systems: Key Characteristics Components do not explicitly invoke each other. Components generate signals, also called events. To receive events, objects can Receive events at ports (statically or dynamically bound). Register for event notification (e.g. via callback). Announcers do not know which components will be affected by thrown events System framework implements signal propagation Correctness of P&F system should not depend on order of data processing (by various filters). (I.e. filters are independent).

Event Systems: Strengths Supports reuse Only little coupling Easy system evolution Introduction of new component simply by registering Well suited for asynchronous communication

Event Systems: Weaknesses Components don’t have control over computation since they can only generate events; the run-time system handles event dispatching. Thus responses to events are not ordered. Exchange of data can require use of global variables or shared repository => resource management can become a challenge. Global system analysis is more challenging. Asynchronous event handling Contrast to explicit call & use of pre-, post-conditions. (E.g., how to ensure that at least one object has processed an event.

Event Systems: Variations Pure implicit invocation systems are quite rare. At some point explicit invocation is used among objects. Pipeline – 1-to-1, bounded -> producer/consumer problem, all pipes are typed (even if only to char streams)

Event Systems: Examples

Event Systems: Examples UIs Macintosh computers popularized the “main event loop” approach for UI applications. Other examples include Constraint satisfaction systems (e.g. some database systems). Daemons. S/W environments that make use of multiple tools: e.g. text editor registers for events from debugger.

Style – Repository

Repository: Components & Connectors Data store, Clients, that interact with the store Connectors Queries

Repository: Key Characteristics The Architecture is centered on a widely accessed data store Data store & clients. Two main variants: Database Passive data store, active clients that poll the database. Blackboard Active data store that notifies each client of data changes of interest to the client. (Clients also called knowledge sources.)

Repository: Strengths Clients are relatively independent of each other. Data store is independent of the clients. Scalable (i.e., new clients can be easily added) Modifiable

Repository: Weaknesses Strong dependence on data store…

Repository: Variants There are several variants of DB systems including the main distinction between traditional databases vs. object-oriented databases. Distributed DB.

Repository: Examples

Repository: Examples Programming environments (IDEs) All applications that use global databases Modern Compilers

Summary Architectural styles allow us to reason about the high-level design of a system before we start to implement it. They are applied early in the architectural process. Architectural styles address many nonfunctional quality characteristics such as performance, reliability, and modifiability. They help us to decompose our system more effectively.