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?
(Perry James – Concordia University)
By examining the following for each:
 Connectors, components
 Key characteristics
 Strengths & weaknesses
 Variants & specializations
 Examples
Dataflow Systems
Style – Process Control
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
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 Controlled variables
Set point Changes to
manipulated
variables

(Feedback control)
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
Process Control:
Examples

 Cruise control system

 Heating system
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
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.
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
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

Object-Oriented Systems:
Key Characteristics
 Call and return architecture
 Interaction through method invocation
 Based on data abstraction:
 Encapsulation
 Information hiding
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
Data
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.
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
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
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
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)
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
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.
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
 Components
 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.