Software Architecture: Architectural Styles Faculty:Prof:S.Sree Dharinya

SOFTWARE ARCHITECTURE
Architectural Styles
Faculty:Prof:S.Sree Dharinya
Module 4
SWE2004 Faculty:S.SreeDharinya
Architectural Design
Architectural design process
1. System structuring
2. Control modelling
3. Modular decomposition
4. Domain specific architecture
1.System structuring
a) Context level diagram
b) The Repository Model
c) Client server model
d) Abstract machine model(layered model)
a.Packing robot control system
Vision
system
Object Arm Gripper

identification controller controller
system
Packaging
selection
system
Packing Conveyor
system controller
b.The repository model
• Sub-systems must exchange data. This may be
done in two ways:
– Shared data is held in a central database
– Each sub-system maintains its own database
• When large amounts of data are to be shared,
the repository model of sharing is most
commonly used
CASE toolset architecture
Design Code
editor generator
Design Project Program

translator repository editor
Design Report
analyser generator
c.Client-server architecture
• Set of stand-alone servers which provide
specific services such as printing, data
management, etc.
• Set of clients which call on these services
• Network which allows clients to access
servers
Film and picture library
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
Catalogue Video Picture Hypertext

server server server server
Catalogue Film clip Digitiz ed Hypertext

files photographs web
d. Abstract machine model
• Used to model the interfacing of sub-systems
• Organises the system into a set of layers (or abstract
machines) each of which provide a set of services
• When a layer interface changes, only the adjacent layer is
affected
• However, often difficult to structure systems in this way
Version management system
Version management
Object management
Database system
Operating
system
2.Control models
a.Centralised control
– One sub-system has overall responsibility for
control and starts and stops other sub-systems
b.Event-based control
– Each sub-system can respond to externally
generated events from other sub-systems or the
system’s environment
a.Centralised control
1.Call-return model
– Top-down subroutine model where control starts
at the top of a subroutine hierarchy and moves
downwards.
2.Manager model
– Applicable to concurrent systems. One system
component controls the stopping, starting and
coordination of other system processes.
1.Call-return model
Main
program
Routine 1 Routine 2 Routine 3
Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2
2.Manager model-Real-time system control
Sensor Actuator
processes processes
System
contr oller
Computation User Fault

processes interface handler
b. Event-driven systems
• Driven by externally generated events
• Two principal event-driven models
– 1.Broadcast models.
– 2.Interrupt-driven models.
1.Selective broadcasting
Sub-system Sub-system Sub-system Sub-system

1 2 3 4
Event and messa ge handler
2.Interrupt-driven systems
• Used in real-time systems where fast response
to an event is essential
• There are known interrupt types with a
handler defined for each type
• Each type is associated with a memory
location and a hardware switch causes
transfer to its handler
• Allows fast response but complex to program
and difficult to validate
Interrupt-driven control
Interrupts
Interrupt
vector
Handler Handler Handler Handler

1 2 3 4
Process Process Process Process

1 2 3 4
3.Modular decomposition
• Two modular decomposition models covered
– An object model where the system is decomposed
into interacting objects
– A data-flow model
• If possible, decisions about concurrency
should be delayed until modules are
implemented
Invoice processing system
Customer Receipt
customer# invoice#
name date
address Invoice amount
credit period customer#
invoice#
date
amount
customer
Payment issue ()
invoice# sendR eminder ()
date acceptPayment ()
amount sendR eceipt ()
customer#
4.Domain-specific architectures
• Two types of domain-specific model
– Generic models
– Reference models
Generic models
• Compiler model is a well-known example although other
models exist in more specialised application domains
– Lexical analyser
– Symbol table
– Syntax analyser
– Syntax tree
– Semantic analyser
– Code generator
• Generic compiler model may be organised according to
different architectural models
Compiler model
Symbol
table
Lexical Syntactic Semantic Code

analysis analysis analysis generation
OSI reference model
7 Application
Application Application
6 Presentation Presentation
5 Session Session
4 Transport Transport
3 Network Network Network
2 Data link Data link Data link
1 Physical Physical Physical

Communications medium
Architectural styles
Architectural Styles and Patterns
• An architectural style defines a family of architectures constrained by

– Component/connector vocabulary, e.g.,
• layers and calls between them
– Topology, e.g.,
• stack of layers
– Semantic constraints, e.g.,
• a layer may only talk to its adjacent layers
• For each architectural style, an architectural pattern can be defined
– It’s basically the architectural style cast into the pattern form
• – The pattern form focuses on identifying the a problem, context of a
problem with its forces, and a solution with its consequences and
tradeoffs; it also explicitly highlights the composition of patterns
Describing an Architectural Style
• Software architectures are represented as

graphs where nodes represent components
• procedures
• modules
• processes
• tools
• databases
Describing an Architectural Style
and edges represent connectors.

• procedure calls
• event broadcasts
• database queries
• pipes
“Pure” Form of Styles
– Pure data flow styles (or any other architectural style) are
rarely found in practice
--Systems in practice
• There are many architectural styles which function
simultaneously.
• As an architect you must understand the “pure” styles to
understand the strength and weaknesses of the style
as well as the consequences of deviating from the style.
Common Architectural Styles
• Common Framework is required to understand
differences between styles
• Framework: A specific system is a collection of
components (computational) together with a description
of the interactions between these components
(connectors).
– It is like a Graph.
– Nodes represent components
– Arcs represent connectors (interaction)
• Style: Defines a family of such systems in terms of a
pattern of structural organization.
– Determines vocabulary and set of constraints.
List of Common Architectural styles
Questions to understand a Style
• What is the structural pattern—the components,

connectors, and constraints?
• 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
that style?
• What are some of the common specializations?
7 Commonly used styles
• Pipes and filters
• Objects
• Implicit invocation
• Layering
• Repositories
• Interpreters
• Process control
Data Flow System:Architectural style
• A data flow system is one in which:

– The availability of data controls the computation
– The structure of the design is determined by the orderly
motion of data from component to component
– The pattern of data flow is explicit
– This is the only form of communication between
components
Data Flow
There are variations on this general theme:

– How control is exerted (e.g., push versus pull)
– Degree of concurrency between processes
– Topology
Data Flow-Architecture
Components: Data Flow Components
– Interfaces are input ports and output ports
– Input ports read data; output ports write data
– Computational model: read data from input ports, compute, write data to
output ports.
Connectors: Data Streams
– Uni-directional
• Usually asynchronous, buffered
– Interfaces are reader and writer roles
– Computational model: transport data from writer roles to reader
roles
• Systems
– Arbitrary graphs
– Computational model: functional composition
Patterns of Data Flow in Systems
Kinds of Data Flow Architecture styles
• Batch sequential
• Dataflow network (pipes & filters)
• Closed loop control
Characteristics of Batch Sequential Systems
• Components (processing steps) are

independent programs.
• Connectors are some type of media -
traditionally magnetic tape.
• Each step runs to completion before the next
step begins.
Characteristics of Batch Sequential Systems
• Historical origins
– Mainframes and magnetic tape
– Limited disk space
– Block scheduling of CPU processing time
Examples
– Payroll computations
Characteristics of Batch Sequential
Systems
Pipe and Filter Style
• Type of Data Flow Architecture
• Filter is a component and pipe is a connector
• Filter has interfaces from which a set of inputs can flow
in and a set of outputs can flow out.
• Incremental transformation of data by successive
components.
• All data does not need to be processed for next filter to
start working.
• Any set of filters may be combined in any order,
although reasonable semantics are not guaranteed by
this style.
Pipe and Filter Style
Filter
• Independent entities
• Does not share state with other filters.
• No do not know the identity to upstream and
downstream filters.
Pipes
• Stateless data stream
• Source feeds filter input and sink receives output.
Pipes and Filters
Pipeline Architecture
• Common specialization of pipe and filter style
is pipeline architecture
• This architecture restricts the topologies to
linear sequences of filters.
Pipe and Filter Style:
Advantages and Disadvantages
Advantages:
• Simplicity – Allows designer to understand overall
input/output behavior of a system in terms of individual
filters.
• Maintenance and reuse
• Concurrent Execution –Each filter can be implemented as a
separate task and be executed in parallel with other filters.
Pipe and Filter Style:
Advantages and Disadvantages
Disadvantages:
• Interactive transformations are difficult – Filters being
independent entities designer has to think of each filter as
providing a complete transformation of input data to output
data.
• No filter cooperation.
• Performance – may force a lowest common denominator on
data transmission.
Advantages
• First, they allow the designer to understand the overall
input/output behavior of a system as a simple composition of the
behaviors of the individual filters.
• Second, they support reuse: any two filters can be hooked together,
provided they agree on the data that is being transmitted between
them.
• Third, systems can be easily maintained and enhanced: new filters
can be added to existing systems and old filters can be replaced by
improved ones.
• Fourth, they permit certain kinds of specialized analysis, such as
throughput and deadlock analysis.
• Finally, they naturally support concurrent execution. Each filter can
be implemented as a separate task and potentially executed in
parallel with other filters
Disadvantages
• First, pipe and filter systems often lead to a batch
organization of processing
– Not good at handling interactive operations
• Second, they may be hampered by having to
maintain correspondences between two
separate, but related streams
• Third, depending on the implementation, they
may force a lowest common denominator on
data transmission
– Parsing and unparsing of data
– Loss of performance, increased complexity
Example
• Compiler (Example of pipeline architecture)
Stages: Lexical analysis,parsing,semantic analysis,
code generation
• Programs written in Unix shell (Example of pipeline architecture)
ls –l *.java | grep “foobar” | lpr –P gaston
• Functional programming
Kahn’s example. 3 models –each goes through 3 kinds of
algebraic operations
• Distributed systems.
CORBA components : Push and pull model.
Data Abstraction & OO Organization
• Data representation and operations are encapsulated in
object (components)
• Objects interact through functions and procedure calls.
• Type of call and return style
Object-Oriented Style
• Components are objects
– Data and associated operations
• Connectors are messages and method
invocations
• Style invariants
– Objects are responsible for their internal
representation integrity
– Internal representation is hidden from
other objects
Advantages
• An object hides its representation from its
clients, it is possible to change the
implementation without affecting those
clients.
– “Infinite malleability” of object internals
• System decomposition into sets of interacting
agents
– Additionally, the bundling of a set of accessing
routines with the data
Disadvantages
• The most significant is that in order for one
object to interact with another (via procedure
call) it must know the identity of that other
object.
• Further there can be side effect problems: if A
uses object B and C also uses B, then C's
effects on B look like unexpected side effects
to A, and vice versa.
Example
• Compiler (Example of pipeline architecture)
Stages: Lexical analysis,parsing,semantic analysis,
code generation
• Programs written in Unix shell (Example of pipeline architecture)
*.java | grep “foobar”
• Functional programming
Kahn’s example. 3 models –each goes through 3 kinds
of algebraic operations
• Distributed systems.
CORBA components : Push and pull model.
Properties for
Pipes and Filters
1. They allow the designer to understand the overall input/output
behavior of a system as a simple composition of the behaviors of the
individual filters.
2. They support reuse: any two filters can be hooked together, provided
they agree on the data that is being transmitted between them.
3. systems can be easily maintained and enhanced: new filters can be
added to existing systems and old filters can be replaced by
improved ones.
4. They permit certain kinds of specialized analysis, such as
throughput and deadlock analysis.
5. They naturally support concurrent execution. Each filter can be
implemented as a separate task and potentially executed in parallel
with other filters.
INTRODUCTION
• An Architectural style defines a family of systems.
• It defines the vocabulary of components and
connectors that can be used in instance of a
particular style.
• For example if we are using a pipeline Architecture
model then there are certain rules as to how data
will flow between various components making up
the system. Now this will be different in a Peer to
Peer Architecture.
Architectural Styles
• “A set of design rules that identify the kinds of
components and connectors that may be used to
compose a system or subsystem, together with
local or global constraints on the way the
composition is done” (Shaw & Clements, 1996)
• A set of constraints you put on your development
to elicit desirable properties from your software
architecture.
– Constraints may be:
• Topological
• Behavioral
• Communication-oriented
• etc. etc.
Architectural Styles vs.
Design Patterns
• Many similarities between patterns and styles
– Goal: packaged engineering experience
– Formulation: organization and interaction among
“key” components
• But they have come from different communities
– Many architectural styles have been well known for a
long time in the software engineering community
– PatternsArchitectural
are a relatively
Styles
recent development
Design Patterns
in OO
design
• Differences
Few Many
Large-scale system Localized, small-scale

organization SWE2004 design solutions
Faculty:S.SreeDharinya
Characterizing Architectural
Styles
• Component and Connector characteristics
• Allowed configurations
• Underlying computational model
• Stylistic invariants
• Common examples of its use
• Advantages and disadvantages
• Common specializations
The Pipe-and-Filter Style
The primary architectural style supported by UNIX
• Components
– Individual programs transforming input data to output
data
• Connectors
– Unidirectional or bidirectional data streams
• Configurations
– Parallel linear composition of program invocations
– Sequential data flow and transformation
– Every component has one input predecessor and one
output successor
• Common specializations
– Pipelines: single linear composition of pipes and filters
– Bounded pipes, typed pipes
Pipe-and-Filter Example:
UNIX Text Processing
pic eqn tbl troff lpr
% pic mydoc.t | eqn | tbl | troff | lpr
Legend: Component Connector
Pipe-and-Filter Advantages
and Disadvantages
• Advantages
– Simplicity: Simple, intuitive, efficient composition of components
– Reusability: High potential for reuse of components
– Evolvability: Changing architectures is trivial
– Efficiency: Limited amount of concurrency (contrast batch-sequential)
– Consistency: All components have the same interfaces, only one type
of connector
– Distributability: Byte streams can be sent across networks
• Disadvantages
– Batch-oriented processing
– Must agree on lowest-common-denominator data format
– Does not guarantee semantics
– Limited application domain: stateless data transformation
Client/Server Systems
• Client/Server systems are the most common
specialization (restriction) of the peer-to-peer style
• One component is a server offering a service
• The other components are clients using the service
• Server implementation is transparent but can be
centralized or distributed, single-threaded or multi-
threaded
– Single interface point with physically distributed
implementation
– Dynamic, transparent selection from among multiple
interface points
Client/Server Example:
The World Wide Web
Browser Web
Clients Servers
Netscape
Navigator
HTTP
www.ics.uci.edu
(asynchronous RPC)
Microsoft
IE
3-Tier Client/Server Systems
• 3-Tier Client/Server systems are a common class
of distributed business systems
– Increasing competition requires business to find new
ways of exploiting legacy information assets
• First tier: Client (user interface) tier
• Second (middle, “business logic”) tier: Servers
acting as “business objects”, encapsulating
abstract, integrated models of multiple, disparate
data sources
• Third (back-end, database) tier: Legacy business
applications providing data services
3-Tier System Example:
Marketing at a TelCo
Client Tier Server Tier Legacy Tier
Telemarketing
Agent (CA) Customer
Billing System
Client/
Customer Loss
Server
Analysis
Middleware
Network Services
Telemarketing Provisioning System
Agent (NY)
Legacy Wrappers
Peer-to-Peer Advantages and
Disadvantages
• Advantages
– Interoperability
– A natural high-level architectural style for heterogeneous distributed systems
– Understandability: Small number of tiers, similar to layered-system properties
– Reusability: Especially with regard to legacy applications
– Scalability: Powerful enough server tiers can accommodate many clients
– Distributability: Components communicate over a network, generally
• Disadvantages
– Visibility, Maintainability: Difficult to analyze and debug
• Distributed state
• Potential for deadlock, starvation, race conditions, service outages
– Simplicity: Require sophisticated interoperability mechanisms
• Data marshalling and unmarshalling
• Proxies and stubs for RPC
• Legacy wrappers
Some Criteria for Selecting
and Comparing Styles
• Control flow
• Data flow
• Application
• Distribution
• Scalability
• What else?
What other styles can you think of?
Current Operation
• In Traditional Systems where Component Interfaces interact

with each other, the interaction is through invocation
procedures and functions when required.
• Now usually a Component calls procedures and functions of
other components to perform certain actions depending on
certain events occurring.
• Consider an example where a customer
authenticates himself to the bank. Now After
the customer logs in , the verification system
verifies the user and then calls procedures
such as account status, balance etc.
Event Based Implicit Invocation
• The Main Idea behind implicit invocation is that
instead of components invoking procedures of other
components , a component announces one or more
events.
• The other components if they want to act on a
particular event they can register the appropriate
methods with that event.
• When that particular event is announced the system
invokes all the procedures registered with that event.
• Now here many different procedures can be invoked
thus giving a parallel look to it.
Diagrammatic View
• Overview
Subject
Observer
StateChange 1
Overall Implicit
Opfor Event1(.) Statechange 2
Invocation
Opfor Event2(.) ……………
1 1
n n
n 1
Event Stub State Change
Forward(..)
Announce(..)
Operation Register()
Observer Deregister()
Event-Based Systems and the
Implicit Invocation Style
• Components
– Programs or program entities that announce and/or
register interest in events
• Connectors
– Event broadcast and registration infrastructure
• Configurations
– Implicit dependencies arising from event announcements
and registrations
1. Event announcement is broadcast
2. Procedures associated with registrations (if any) are
invoked
Example
• The Example presented in the documents is that of a
debugger. When we stop a debugger at a break point
the debugger announces an event. Corresponding to
this event various procedures are called which might
record the value of a specified variable or scroll an
editor to an appropriate line.
• Now here all the debugger does is announce an
event. It is not concerned as to which procedures
might be invoked and in what order the procedures
may be executed if there are more than one
procedures called
Implicit Invocation Example:
Program Debugging (1)
Set breakpoint line 10

Debug events
Interactive Application
Program Program
Debugger
Breakpoint
Routine
Debug events
line 10
Program Program
Debugger
Breakpoint
Routine
Line 8 reached
Debug events
line 10
Program Program
Debugger
Breakpoint
Routine
Line 10 reached
Debug events
line 10
Program Program
Debugger
Breakpoint
Routine
Implicit
Invocation!
Implicit Invocation
Advantages & Disadvantages
• Advantages
– Reusability: Components can be put in almost any context
– Distributability: Events are independent and can travel across the network
– Interoperability: Components may be very heterogeneous
– Visibility: Events are a verified form of communication that can be logged and
viewed
– Robustness: Components in this style generally have to be written to tolerate
failure or unexpected circumstances well
• Disadvantages
– Reliability: Components announcing events have no guarantee of getting a
response
– Simplicity: Components announcing events have no control over the order of
responses, so they must be robust enough to handle this
– Understandability: Difficult to reason about the behavior of an announcing
component independently of the components that register for its events
– Event abstraction does not cleanly lend itself to data exchange
Model-View-Controller-Framework
The MVC paradigm is a way of breaking an

application, or even just a piece of an
application's interface, into three parts: the
model, the view, and the controller.
MVC was originally developed to map the
traditional input, processing, output roles into
the GUI realm:
Input  Processing  Output
Controller  Model  View
model-view-controller
The pattern isolates business logic from input and

presentation, permitting independent
development, testing and maintenance of each.
MVC Model
• It is the domain-specific representation of the data on
which the application operates.
• Domain logic adds meaning to raw data (for example,
calculating whether today is the user's birthday, or the
totals, taxes, and shipping charges for shopping cart
items).
• When a model changes its state, it notifies its associated
views so they can refresh.
Many applications use a persistent storage mechanism
(such as a database) to store data. MVC does not
specifically mention the data access layer because it is
understood to be underneath or encapsulated by the
model.
mvc fat v. thin controllers
ruby on rails ‘fat’ model, ‘thin’ controller approach
watch: http://www.youtube.com/watch?v=91C7ax0UAAc
mvc advantages:
The main objective of the MVC design pattern is separation of
concerns.
It provides an isolation of the application’s presentation layer that
displays the data in the user interface, from the way the data is
actually processed.
In other words, it isolates the application’s data from how the data is
actually processed by the application’s business logic layer.
The biggest advantage of the MVC design pattern is that you have a
nice isolation of these components/layers and you can change any
one of them without the rest being affected.
Here is the list of the major advantages of this pattern.
• It provides a clean separation of concerns.

• It is easier to test code that implements this pattern.
• It promotes better code organization, extensibility, scalability and
code re-use.
• It facilitates de-coupling theFaculty:S.SreeDharinya
SWE2004 application's layers.
Distributed Peer-to-Peer
Systems
• Components
– Independently developed objects and programs offering public
operations or services
• Connectors
– Remote procedure call (RPC) over computer networks
• Configurations
– Transient or persistent connections between cooperating
components
– Synchronous or asynchronous invocation of operations or
services
– Communications are point-to-point
Example continued
• Subject: Defines an abstract state
• State Change:
• - Represents a possible state change
• - Offers operation for the subject to trigger event
notification
• - Offers operations to register and unregister
observers via event stub Object.
• Observer : Provides event stub with an operation
reference to be called incase of invocation.
Continued
• Event Stub : Knows which operation of its owner an
observer) is to be called in case of invocation.
• Collaborations:
• If a subject changes its state , it triggers the
corresponding state change object.
• A state change object distributes the notification to
all its event stubs.
• An Event Stub forwards a notification to its owner
(an observer).
Components and Connectors
• Components in an implicit invocation style are
modules whose interface provide both a collection of
procedure and a set of events.
• Procedures may be called normally and in addition
some procedures may be registered with a particular
event.
• The Connectors include traditional procedure calls as
well as binding between event announcement and
procedure calls.
Benefits
• Strong support for Reuse.
• A component can be introduced into a system simply by
registering it for events of that system.
• Another benefit is that it eases out system evolution.
• Components may be replaced by other components without
affecting the interfaces of other components in the system.
• In contrary to this is explicit based system whenever the
identity of a component that provides some system function
is changed, all modules that import that module must also be
changed.
Disadvantages
• Component does not have control over
computations performed in the system.
• Component has no idea what other components will
respond to against an event.
• In what order operations take place is also not
known to the component and when is the operation
done with. To overcome this explicit invocation is
also included in systems.
• Global Performance and Resource Management
become a serious issue since all components share a
common repository.
Example
• One example could be the java awt package.
In these when we design buttons we associate
event handlers for that button. Whenever that
button is clicked all the event handlers are
executed.
A Layered System
The Layered System Style
• Components
– Programs or subprograms
• Connectors
– Procedure calls or system calls
• Configurations
– “Onion” or “stovepipe” structure, possibly replicated
– Procedure call/return
– Each layer provides a service only to the immediate layer
“above” (at the next higher level of abstraction) and uses the
service only of the immediate layer “below” (at the next lower
level of abstraction)
Layered Virtual Machine
Example: Java
Java
Java
Operating
Java Virtual Machine
Processor
(Virtual Machine Style)
System
Virtual Machine
Application
Layered System Example:
OSI Protocol Stack
Application Application
Presentation Presentation
Session Session
Transport Transport
Network Network Network Network
Data Link Data Link Data Link Data Link
Physical Physical Physical Physical
Layered System Advantages
and Disadvantages
• Advantages
– Decomposability: Effective separation of concerns
– Maintainability: Changes that do not affect layer interfaces are
easy to make
– Evolvability: Potential for adding layers
– Adaptability/Portability: Can replace inner layers as long as
interfaces remain the same (consider swapping out a Solaris
JVM for a Linux one)
– Understandability: Strict set of dependencies allow you to
ignore outer layers
• Disadvantages
– Performance degrades with too many layers
– Can be difficult to cleanly assign functionality to the “right”
layer
The Hypertext Style
• Components
– “Documents” and document parts
• Connectors
– Unidirectional hyperlinks between document parts
• Configurations
– Arbitrary topology of linked documents
– Bidirectional hyperlink traversal
– Adherence to standardized document formats
Hypertext Example:
The World Wide Web
HTML Document
Java Applet HTML Document GIF Image
Text Document
Hypertext Advantages and
Disadvantages
• Advantages
– Efficiency: Can organize large amounts of non-uniform data
– Adaptability: New types of applications and data can be
integrated
– Distributability: Well-suited to wide-area distributed application
– Scalability: Lack of centralization allows millions of clients (cf.
the Web)
– Flexibility: Few constraints on topology, organization
• Disadvantages
– Reliability (consider broken links)
– Somewhat difficult to maintain context
– Need for sophisticated indexing mechanisms
– Need for sophisticated version control
Repositories
Repositories
• Two kinds of components:
– a central data structure represents the current
state,
– and a collection of independent components
operate on the central data store.
• When data repository is an active repository
that notifies registered components of
changes in it then-blackboard style
• System control is entirely driven by the
blackboard state
• Examples
– Typically used for AI systems
– Integrated software environments (e.g., Interlisp)
– Compiler architecture
• Advantages:
– Less overhead vs. F&P
– Actor (component) does not depend on each other and it
is easy to add new actor.
– Actor concurrent access consistent data
• Disadvantages:
– More overhead in distributed application
– Need to be scalable
– Security issue
– Availability issue
– Change Repository, evolution is difficult
– Potential slow problem
Properties :-
• Interactions between the repository and its
external components can vary significantly
between systems.
• The choice of control discipline leads to major
subcategories.
choice of control :-
• If the types of transactions in an input stream
of transactions 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 of selecting
processes to execute, the repository can be a
blackboard.
The Blackboard Style
• Components
– Blackboard client programs
• Connector
– Blackboard: shared data repository, possibly with finite
capacity
• Configurations
– Multiple clients sharing single blackboard
– Synchronized, shared data transactions, with control
driven entirely by blackboard state
– All clients see all transactions in the same order
Blackboard Example:
A Chat Room
Chat Participant Chat Participant
Chat Participant Chat Transcript Chat Participant
Chat Participant
Blackboard Advantages and
Disadvantages
• Advantages
– Simplicity: Only one connector (the blackboard) that
everyone uses
– Evolvability: New types of components can be added easily
– Reliability(?): Concurrency controls of information,
traditionally a tricky problem, can be largely addressed in
the blackboard
• Disadvantages
– Blackboard becomes a bottleneck with too many clients
– Implicit “partitions” of information on the blackboard may
cause confusion, reduce understandability
The blackboard model :-
The blackboard :-
• The blackboard model is usually presented
with three major parts:
• 1.) The knowledge sources.

• 2.) The blackboard data structure.
• 3.) Control.
1.) The knowledge sources.
• Separate, independent parcels of application

dependent knowledge.
• Interaction among knowledge sources takes
place solely through the blackboard.
2.) The blackboard data structure.
• Problem-solving state data, organized into an

application-dependent hierarchy.
• Knowledge sources make changes to the
blackboard that lead incrementally to a
solution to the problem.
3.) Control.
• Driven entirely by state of blackboard.

• Knowledge sources respond opportunitically
when changes in the blackboard make them
applicable.
USES :-
• Blackboard systems have traditionally been
used for applications requiring complex
interpretations of signal processing,
such as speech and pattern recognition.
• Involves shared access to data with loosely
coupled agents
Table Driven Interpreters
• Interpreter parses and executes input commands,
updating the state maintained by the interpreter
 Interpreter Engine
◦ receives input and generates output
 Interpreter State
◦ state of interpreter engine
 Program State
◦ progress of code interpreted
 Data Store Field
◦ source code
• Examples:
– Java, Java Virtual Machine (JVM)
– Python-based applications
– Lisp
• Components: Command interpreter,
program/interpreter state, user interface.
• Connectors: Typically very closely bound with direct
procedure calls and shared state.
• Advantages:
– Highly dynamic behavior possible, where the set of
commands is dynamically modified.
– System architecture may remain constant while new
capabilities are created based upon existing primitives.
– supports dynamically changing set of capabilities
• Disadvantages
– Slow
– Hard to design and test
– Cannot generate all possible programs to be executed
Process Control
Process Control Style
• Process variable: Properties of the process that can
be measured; several specific kinds are often
distinguished.
• Controlled variable: Process variable whose value the
system is intended to control.
• Input variable: Process variable that measures an
input to the process.
• Manipulated variable: Process variable whose value
can be changed by the controller.
• Set point: The desired value for a controlled variable.
• Open-loop system: System in which information
about process variables is not used to adjust the
system.
Process Control Style
• Closed-loop system: System in which information
about process variables is used to manipulate a
process variable to compensate.
• Feedback control system: The controlled variable is
measured, and the result is used to manipulate one
or more of the process variables.
• Feed forward control system: Some of the process
variables are measured, and anticipated disturbances
are compensated for without waiting for changes in
the controlled variable to be visible.
Process Control:
Components & Connectors
• 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
Example
Open-loop temperature control.
Example
Closed-loop temperature control.
Process Control:
Example
Applied to software
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.
• Strengths
– Well suited for the control of continuous
processes particularly where the control
algorithm is subject to change (possibly even at
run-time).
– Weakness:
• Not easily applicable when multiple interacting
processes (and controls) are needed.

Software Architecture: Architectural Styles Faculty:Prof:S.Sree Dharinya

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architecture: Architectural Styles Faculty:Prof:S.Sree Dharinya

Uploaded by

Copyright:

Available Formats

SOFTWARE ARCHITECTURE

Object Arm Gripper

Design Project Program

Catalogue Video Picture Hypertext

Catalogue Film clip Digitiz ed Hypertext

Routine 1 Routine 2 Routine 3

Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

Computation User Fault

Sub-system Sub-system Sub-system Sub-system

Event and messa ge handler

Handler Handler Handler Handler

Process Process Process Process

Lexical Syntactic Semantic Code

3 Network Network Network

2 Data link Data link Data link

1 Physical Physical Physical

• An architectural style defines a family of architectures constrained by

• Software architectures are represented as

and edges represent connectors.

• What is the structural pattern—the components,

• A data flow system is one in which:

There are variations on this general theme:

• Components (processing steps) are

Large-scale system Localized, small-scale

pic eqn tbl troff lpr

% pic mydoc.t | eqn | tbl | troff | lpr

Legend: Component Connector

• In Traditional Systems where Component Interfaces interact

Set breakpoint line 10

The MVC paradigm is a way of breaking an

The pattern isolates business logic from input and

ruby on rails ‘fat’ model, ‘thin’ controller approach

• It provides a clean separation of concerns.

Java Applet HTML Document GIF Image

• If the current state of the central data

Chat Participant Chat Participant

Chat Participant Chat Transcript Chat Participant

• 1.) The knowledge sources.

• Separate, independent parcels of application

• Problem-solving state data, organized into an

• Driven entirely by state of blackboard.

You might also like