Software Architecture &

Design (CSC-323)
Lecture 4: Architectural Styles
Reminder (see previous lecture for details)
OPEN SOURCE SOFTWARE PROJECTS
SHORTLIST TUESDAY 13TH FEBRUARY –
PRESENT IN CLASS
REVIEW OF ARCHITECTURAL
STYLES & SELECTION TRADE-OFFS
 Architectural Styles
• Use of patterns and styles pervasive in
engineering disciplines
 Architectural Styles
• Architectural level
– Client-server system, pipe-filter design,
layered architecture
• Associated with design methods e.g.
object oriented
• With specific classes of systems e.g.,
traditional organization of a compiler
 Architectural Styles
• No comprehensive taxonomy as yet, but is
beginning to emerge
 Evaluation Framework
• Common framework needed to evaluate
and compare
– Treat architecture as a collection of
components
• Clients, servers, filters, layers, databases
– Description of interaction among these
components – connectors
• Procedure call, event broadcast, database
protocols and pipes
 Framework
• Styles defines a family of such systems in
terms of a pattern of structural
organization
• Define a vocabulary of components and
connector types, and a set of constraints
on how they can be combined
 Framework
• Determine and assess architectural styles in terms
of these questions
– What is the design vocabulary – the types of
components and connectors
– What are the allowable structural patterns
– What is the underlying computational model
– What are the essential invariants of the style
– What are some common examples of its use
– What are the advantages and disadvantages of using it
– What are some of the common specializations
 Seven Commonly Used Styles
• Pipes and filters
• Objects
• Implicit invocation
• Layering
• Repositories
• Interpreters
• Process control
 Pipes and Filters
• Each component has a set of inputs and a set
of outputs
• Components read streams of data on their
inputs and produce streams of data on outputs
• Usually accomplished by applying a
transformation to the input streams and
computing incrementally so output begins
before input is consumed
• Components are therefore termed filters
 Pipes and Filters
• Connectors serve as conduits for the
streams
• Transmit outputs of one filter to inputs of
another
• Hence named pipes
 Pipes and Filters
• Key invariant
– Filters must be independent entities
– In particular they should not share state with
other filters
 Pipes and Filters
• Key invariant
– Filters do not know the identity of their
upstream and downstream filters
– Specification can restrict what appears on the
input pipes and ensure what appears on the
output pipes, but they may not identify the
components at the ends of the pipes
 Pipes and Filters
• Key invariant
– Correctness of output of pipe-and-filter
network should not depend on the order in
which they perform their incremental
processing
Pipes and Filters
 Pipes and Filters
• Specializations
– Pipelines which restrict the topology to linear
sequences of filters
– Bounded pipes which restrict the amount of
data that can reside on a pipe
– Typed pipes which require data passed
between the pipes to have a well defined type
 Pipes and Filters
• Degenerate case
– When each filter processes all of its input data
as a single entity
– The architecture becomes a batch sequential
system
– Pipes no longer serve the function of providing
a stream of data and are largely vestigial
– Such systems are treated as instances of a
separate style
 Pipes and Filters
• Example
– Programs written in the Unix shell
• Provides notation for connecting components
(represented as Unix processes)
• Provides run time mechanisms for implementing
pipes
 Pipes and Filters
• Example
– Compilers, although the phases are not often
incremental
– Stages: Lexical analysis, parsing, semantic
analysis, and code generation
 Pipes and Filters
• Advantages
– Allow designer to understand the overall
input/output behavior of a system as a simple
composition of the behaviors of the individual
filters
– Support reuse
– Easy to maintain and enhance
– Permit specialized analysis (throughput, deadlock
analysis etc.)
– Naturally support concurrent execution
 Pipes and Filters
• Disadvantages
– Often lead to batch organization of processing
– Can process data incrementally but inherently
independent, so designer must think of each
filter as providing complete transformation of
input data to output data
– Not good at handling interactive applications
• Problem with incremental display updates
 Data Abstraction & Object Oriented
Organization
• Data representations and their associated
primitive operations are encapsulated in an
abstract data type or object
• Object (instances of abstract data types) are the
components
• This type of component is referred to as a
manager because it is responsible for
maintaining the integrity of a resource
• Objects interact through function and procedure
invocations
 Data Abstraction & Object Oriented
Organization
• Key Invariant
– An object is responsible for preserving the
integrity of its representation
– Representation is hidden from other objects
Data Abstraction & Object Oriented
Organization
 Data Abstraction & Object Oriented
Organization
• Use is widespread
• Variants include
– Some systems allow objects to be concurrent
tasks
– Allow objects to have multiple interfaces
 Data Abstraction & Object Oriented
Organization
• Advantages
– Object hides representation from clients, so
possible to change implementation without
affecting clients
 Data Abstraction & Object Oriented
Organization
• Disadvantages
– For one object to interact with another via
procedure call, it must know the identity of the
other object (in contrast to pipe-and-filter)
Event-Based, Implicit Invocation
• Explicit invocation
– When component interfaces provide a collection of
procedures and functions (e.g., object oriented systems)
• Implicit invocation / Reactive integration / Selective
broadcast
– Instead of direct procedure invocation, the component
announces one or more events
– Other components can register an interest in an event by
associating a procedure with it
– When the event is announced the system itself invokes all
of the procedures that have been registered for the event
Event-Based, Implicit Invocation
• Components
– Modules whose interfaces provide both a
collection of procedures and a set of events
– Procedures may be called in the usual way
– But components can also register the
procedures with system events
Event-Based, Implicit Invocation
• Invariant
– Announcers do not know which components
will be affected
• Components therefore cannot make assumptions
about the type or order of processing after an
event
• So most systems do include explicit invocation
(normal procedure call) as a complementary form
of interaction
Event-Based, Implicit Invocation
• Examples
– Tools such as editors and variable monitors register
for a debugger’s breakpoint events
– When a debugger stops at a breakpoint, it
announces an event that allows the system to
automatically invoke procedures of those registered
tools
– E.g., scroll editor to appropriate source line, redisplay
value of monitored variables
– The debugger simply announces the event but does
not know what reactions will take place
Event-Based, Implicit Invocation
• Examples
– Tool integration for programming
environments
– Database management to ensure consistency
constraints
– In UIs to separate presentation of data from
applications that manage the data
Event-Based, Implicit Invocation
• Benefit
– Provides strong support for reuse
– Any component can be introduced in a
system by simply registering it for the events
of the system
– Eases system evolution, improved versions of
components can be plugged in without
worrying about interfaces
Event-Based, Implicit Invocation
• Disadvantages
– Components relinquish control over the computation
performed by the system
– When a component announces an event, it cannot
assume other components will respond to it
• And if it somehow can, it cannot know the order in which they
will be invoked
– Exchange of data
• Can sometimes be passed with an event
• In many cases the system has to rely on a shared repository
• Performance and resource management can then become
issues
Event-Based, Implicit Invocation
• Disadvantages
– Reasoning about the correctness can be
problematic
• Meaning of event will depend on the context of
bindings in which it is invoked
• Traditional reasoning only needs to consider a
procedure’s pre- and post-conditions
 Layered Systems
• Organized hierarchically
• Each layer provides service to the layer
above it
• Acts as a client to the layer below it
 Layered Systems
• In some systems inner layers are hidden
from all except the adjacent outer layer
(except for certain functions carefully
selected for export)
 Layered Systems
• Components are layers
• Connectors are defined by the protocols
that determine how the layers will interact
 Layered Systems
• Constraints
– Limiting interactions to adjacent layers
Layered Systems
 Layered Systems
• Examples
– Layered communication protocols
• Lower levels define lower levels of interaction the
lowest typically being defined by hardware
connections
– Database systems
– Operating systems
 Layered Systems
• Benefits
– Support designs based on increasing levels of
abstractness
• Allows implementers to partition a complex problem into a
sequence of incremental steps
– Support enhancements (similar to pipelines)
• Changes to functions of one layer affect at most two other layers
– Support reuse
• Different implementations of the same layer can be used
interchangeably provided they support the same interfaces to
adjacent layers
• Possible to define standard layer interfaces to leverage this style
 Layered Systems
• Disadvantages
– Not all systems can be easily structured into layers
– Even in cases where this can be done logically,
performance considerations may require closer
coupling between high level functions and their low
level implementations
– Difficult to find the right levels of abstraction
• Problems mapping existing communication protocols
into the ISO framework because many of the protocols
bridge several layers
 Repositories
• Two distinct types of components
– Central data structure representing the
current state
– Collection of independent components
operating on the central data store
• Interactions between the repository and its
external components can vary significantly
among systems
 Repositories
• Two major subcategories
– If the types of transactions in an input stream
trigger selection of processes to execute the
repository can be a traditional database
– If the current state of the central data
structure is the main trigger for selecting
processes to execute the repository can be a
blackboard
 Blackboard

ks: Knowledge source

 Blackboard
• Knowledge sources
– Independent parcels of application dependent knowledge;
interaction is solely through the blackboard
• Blackboard
– Problem solving, state data organized into an application
dependent hierarchy
– Knowledge sources make changes to the blackboard which
incrementally lead to a solution
• Control
– Driven by state of blackboard; knowledge sources respond
opportunistically when changes in the blackboard make them
applicable
 Blackboard
• Examples
– Traditionally in application requiring complex
interpretations of signal processing such as
speech and pattern recognition
 Interpreters
• Virtual machine produced in software
• Interpreter
– Pseudoprogram being interpreted
– Interpretation engine itself
 Interpreters
• Pseudoprogram
– Program
– Interpreters analog of its interpretation state
(activation record)
• Interpretation engine
– Definition of the interpreter
– Current state of its execution
 Interpreters
• Four components
– Interpretation engine to do the work
– A memory that contains the pseudocode to be
interpreted
– A representation of the control state of the
interpretation engine
– Representation of the current state of the
program being simulated
Interpreter
 Process Control
• Based on process control loops
• Not widely recognized in software
community
• Characterized by the types of components
involved and the special relations that
must hold between them
 Process Control
• Continuous processes of many kinds
convert input materials to products with
specific properties by performing
operations on the inputs and on
intermediate products
Process Control Terminology
Open Loop Temperature Control
Closed Loop Temperature Control
Feedback Control
Feedforward Control
 Other Familiar Architectures
• Distributed processes (e.g., client server
organizations)
• Main program/subroutine organizations
• Domain specific software architectures
• State transition systems
 Heterogeneous Architectures
• “Pure” architectural styles presented
• Needed to understand individual nature
• Practically most systems involve
combinations of several styles
 Heterogeneous Architectures
• Combine through hierarchy
– Component of a system that uses one style can
have its internal organization planned through a
different style
– E.g., filter in pipe-and-filter can use any other
architectural style or another level of pipe-and-
filter itself
• Even connectors can be decomposed, e.g.,
pipe connector can be implemented as a
FIFO queue
 Heterogeneous Architectures
• Combine by allowing a single component
to use different types of connectors
– Active database which activates external
components through implicit invocation
Chapter 2. Software Architecture: Perspectives on an Emerging
Discipline. Mary Shaw & David Garlan.