Applying Architectural Styles and Patterns Outline n Defining

Applying Architectural Styles and Patterns

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

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

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

Architectural Patterns n A pattern is a solution that strikes some balance between competing forces. n However, what makes it a pattern is the fact that it is recurring. n 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) n 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. n The patterns are the vocabulary of the language, and the rules for their implementation and combination are the grammar. n Patterns in a pattern language can be constructed from other patterns.

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

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

Activation Model n This model describes how components are activated and how information is passed between them (the control principle of the architecture). n 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. n In languages like Smalltalk method invocation and method execution are decoupled.

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

Activation Model (Cont’d) n 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. n Asynchronous communication means that the client doesn’t wait on a response from the server before continuing. n 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 n Data elements can be passed directly between processing elements (pipes and filters). n Data elements may also be shared in a central store and accessed by different processing elements (repository).

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

Styles and Quality Attributes n 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. n Object-oriented systems emphasize maintainability but are not easily reused n

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

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

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

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

Dataflow Systems

Style – Process Control

Process Control: Components & Connectors n The following slides offer only an introduction to the process control style. n The process control style is modeled on the process control systems that are common in other engineering disciplines (e. g. chemical engineering). n Motivating example: furnace

Process Control: Example Open-loop temperature control.

Process Control: Example Closed-loop temperature control.

Process Control: Example Applied to software

Process Control: Components & Connectors Input variables (Feed-forward control) Process Controller Set point Changes to manipulated variables (Feedback control) Controlled variables

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

Process Control: Strengths n 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 n Not easily applicable when multiple interacting processes (and controls) are needed.

Process Control: Examples

Process Control: Examples n Cruise control system n Heating system

Style – Pipes and Filters: Components & Connectors n Components: Filter n Completely independent entities n Consume streams of inputs and produce streams of outputs n Context independent (do not know what produced the input or will consume the output) n Output starts before input is (entirely) consumed (incremental transformation of data) n Connectors: Pipes n Carrier of data streams n Binding between component ports

Pipes and Filters: Key Characteristics n Data Flow Architecture n Model assumes concurrent processing. n Filters are independent. n Do not share data. n Do not know identity of neighbors. n Individual filter behavior: simple I/O relation n System behavior = simple composition of individual filter behaviors.

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

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

Pipes and Filters: Variations n Pipelines Linear sequences of filters Batch Sequential Systems n Pipeline; but each step runs to completion before the next starts Bounded pipes n Restriction on the amount of data that can temporarily reside/buffered on/in a pipe Typed pipes n Restricts the data passed between two filters to a welldefined type “UI pipes” n Each filter is associated with UI to allow the user to set parameters of operation n n

Pipes and Filters: Examples

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

Style – Object-Oriented Systems: Components & Connectors n Components: Classes & Objects n Connectors: Method calls

Object-Oriented Systems: Key Characteristics n Call and return architecture n Interaction through method invocation n Based on data abstraction: n Encapsulation n Information hiding

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

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

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

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

Object-Oriented Systems: Variations n Active classes n When instantiated, control their own execution n Can operate standalone (rather than being invoked by other classes) n Own thread n Other OO variants such as support (or not) of multiple inheritance, interfaces, static typing, etc.

Object-Oriented Systems: Examples

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

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

Hierarchically Layered Systems: Components & Connectors n Components: Layers n Connectors: Protocols that define how layers interact

Hierarchically Layered Systems: Key Characteristics n Hierarchical organization n Only adjacent layers communicate n Each layer provides services to the level above and serves as a client to the layer below n Lower layer is unaware of higher layer n Each layer hides its lower layers from the layers above

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

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

Hierarchically Layered Systems: Variations n Layer may accesses other lower level layers than just the layer below Less pure n Increased performance n

Hierarchically Layered Systems: Examples

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

Style: Event Systems: Components & Connectors n Component: (active or passive) object, capsule, module Can be an instance of a class, an active class, or simply a module. n Interface provides methods and ports. n Publisher: individual components announce data that they wish to share with their subscribers. n Subscriber: individual components register their interest for published data. n Connector: “connector”, channel, binding, callback. n Offers one-to-one, one-to-many, many-to-one connections; n Asynchronous event broadcast. n Synchronous event broadcast & await reply (call-andreturn) n

Event Systems: Key Characteristics n Components do not explicitly invoke each other. n Components generate signals, also called events. n To receive events, objects can n Receive events at ports (statically or dynamically bound). n Register for event notification (e. g. via callback). n Announcers do not know which components will be affected by thrown events n System framework implements signal propagation

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

Event Systems: Weaknesses n 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. n Exchange of data can require use of global variables or shared repository => resource management can become a challenge. n Global system analysis is more challenging. n n 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 n Pure implicit invocation systems are quite rare. n At some point explicit invocation is used among objects.

Event Systems: Examples

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

Style – Repository

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

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

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

Repository: Weaknesses n Strong dependence on data store…

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

Repository: Examples

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

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