Classical Architectural Styles
Classical Architectural Styles
Common architectural idioms, taxonomies,
and patterns
Issues
Detailed look at specific architectural styles
Pure forms first, later heterogeneous systems
Distinguishing characteristics and specialisation
Heuristics for choosing a style
Implementation techniques
Formal models and analysis
Case studies
Subtopics
Dataflow systems
Batch sequential, pipe & filter
Procedure call systems
Information hiding, ADTs, objects
Event-based systems
Multicast organisation, implicit invocation
Subtopics con’t
Repository-oriented systems
Blackboards, databases, client-servers
Processes
Communicating processes, message
passing
Others
Interpreters and other virtual machines,
process control, layers
Architecture in Systems
Architecture:
“the underlying structure of things”
Not just “what”, but “why”
Good architecture (like much good design):
Result of a consistent set of principles and
techniques, applied consistently through all
phases of a project
Resilient in the face of (inevitable) changes
Source of guidance throughout the product lifetime
Elements of Architectural
Descriptions
The architectural definition of a system
selects
Components: define the locus of computation
Examples: filters, databases, objects, ADTs
Connectors: mediate interactions of components
Examples: procedure calls, pipes, event broadcast
Properties: specify info for construction & analysis
Examples: signatures, pre/post conds, RT specs
Elements of Architectural
Descriptions con’t
An architectural style defines a family of
architectures constrained by
Component/connector vocabulary
Topology rules
Semantic constraints
Common Architectural Idioms
Data flow systems
Batch sequential Pipes and filters
Call-and-return systems
Main program & subroutines
Hierarchical layers OO systems
Virtual machines
Interpreters Rule-based systems
Independent components
Communicating processes Event systems
Data-centered systems (repositories)
Databases Blackboards
Batch Sequential Systems
Processing steps are independent programs
Each step runs to completion before next step
starts
Data transmitted as a whole between steps
Typical applications
Classical data processing
Program developments
Pipes and Filters
Filter
Incrementally transform some amount of
the data at inputs to data at outputs
Stream-to-stream transformations
Use little local context in processing stream
Preserve no state between instantiations
Pipes and Filters con’t
Pipe
Move data from a filter output to a filter
input
Pipes form data transmission graphs
Overall computation
Run pipes and filters (non-deterministically)
until no more computations are possible
Main Program and
Subroutines
Hierarchical decomposition
Based on definition-use relationship
Single thread of control
Supported directly by programming languages
Subsystem structure implicit
Subroutines typically aggregated to modules
Hierarchical reasoning
Correctness of a subroutine depends on the
correctness of the subroutines it calls
Object architectures
Encapsulation
Restrict access to certain information
Inheritance
Share one definition of shared functionality
Dynamic binding
Determine actual operation to call at runtime
Management of many objects
Provide structure on large set of definitions
Reuse and maintenance
Exploit encapsulation and locality
Layered Patterns
Each layer provides certain facilities
Hides part of lower layer
Provides well-defined interfaces
Serves various functions
Kernels: provide core capability, often set of
procedures
Shells, virtual machines: support for portability
Various scoping regimes
Opaque versus translucent layers
Interpreters
Execution engine simulated in software
Data
Representation of program being interpreted
Data (program state) of program being interpreted
Internal state of interpreter
Control resides in “execution cycle” of
interpreter
But simulated control flow in interpreted program
resides in internal interpreter state
Syntax-driven design
Communicating Processes
Components: independent processes
Typically implemented as separate tasks
Connectors: message passing
Point-to-point
Asynchronous and synchronous
RPC and other protocols can be layered on
top
Event Systems
Components: objects or processes
Interface defines a set of incoming procedure calls
Interface also defines a set of outgoing events
Connectors: event-procedure bindings
Procedures are registered with events
Components communicate by announcing events
at “appropriate” times
When an event is announce the associated
procedures are (implicitly invoked)
Order of invocation is non-deterministic
In some treatments connectors are event-event
bindings
Classical Databases
Central data repository
Schemas designed specifically for application
Independent operators
Operations on database implemented
independently, one per transaction type
Interact with database by queries and updates
Control
Transaction stream drives operation
Operations selected on basis of transaction type
The Blackboard Model
Knowledge sources
World and domain knowledge partitioned into
separate, independent computations
Respond to changes in blackboard
Blackboard data structure
Entire state of problem solution
Hierarchical, nonhomogeneous
Only means by which knowledge sources interact
to yield solutions
Control
In model, knowledge sources self-activating
Important ideas
Common patterns for system structure
Pure type form, allowing variation
Identifiable types of subsystems and interaction
Decomposition and heterogeneity
Pattern also describe subsystem structure
Subsystem pattern o system pattern
Independence
System patterns and subsystem functions do not
depend on application
Fit to problem
Problem characteristics guide choice of structure
Case studies: 1. KWIC
In his paper of 1972 Parnas proposed the
following problem [Parnas72]
The KWIC (Key Word in Context) index system
accepts an ordered set of lines; each line is an
ordered set of words, and each word is an ordered
set of characters. Any line may be “circularly
shifted” by repeatedly removing the first word and
appending it at the end of the line. The KWIC
index system outputs a listing of all circular shifts
of all lines in alphabetical order.
KWIC con’t
Four solutions:
Shared data
ADT
Implicit invocation
Pipe-and-filter
KWIC con’t
Consider following changes:
Changes in the processing algorithm
Changes in the data representation
Enhancement to system function
Performance
Reuse
2. Instrumentation software
Develop a reusable system architecture for
oscilloscopes
Rely on digital technology and
Have quite complex software
Reuse across different oscilloscope products
Tailor a general-purpose instrument to a specific
set of users
Performance important
Rapid configuration of software within the
instrument
=> Domain specific software architecture
Instrumentation software con’t
Object-oriented model of software domain
Clarified the data types used for oscilloscopes
Waveforms, signals, measurement, trigger modes, …
No overall model to explain how the types fit
together
Confusion about partitioning of functionality
Should measurements be associated with types of data
being measured or represented externally?
Which objects should the user interface interact with?
Instrumentation software con’t
Layered model
Well-defined grouping of functions
Wrong model for the application domain
Layer boundaries conflicted with the needs of
the interaction among functions
The model suggest user interaction only via
Visualization, but in practice this interaction affects all
layers (setting parameters, etc)
Instrumentation software con’t
Pipe-and-filter model
Functions were viewed as incremental
transformers of data
Corresponds well with the engineers’ view
of signal processing as a dataflow problem
Main problem:
How should the user interact?
Instrumentation software con’t
Modified pipe-and-filter model
Each filter was associated with a control interface
Provides a collection of settings to be modified
dynamically by the user
Explains how the user can make incremental
adjustments to the software
Decouples signal-processing from user interface
Signal-processing software and hardware can be
changed without affecting the user interface as
long as the control interface remains the same
Instrumentation software con’t
Further specialisation
Pipe-and-filter lead to poor performance
Problems with internal storage and data
exchange between filters
Filters may run at radically different speeds
Instrumentation software con’t
Summary
Software must be typically adapted from
pure forms to specialised styles (domain
specific)
Here the result depended on properties of
pipe-and-filter architecture adapted to
satisfy the needs of the product family
