Software Architecture

DATA FLOW STYLES

The Data-Flow architectures have the goal of achieving the quality of reuse and modifiability.
The data-flow style is characterized by viewing the system as a series of transformations on
successive pieces of input data. Data enter the system and then flows through the components
one at a time until, finally, the data is assigned to some final destination (output or a data store).

Data-flow architectures can be classified into batch-sequential architectures and pipe and filters.
In the batch sequential style each step runs to completion before the next step starts. E.g. UNIX
command line pipes. In pipe and filters style steps might run concurrently processing parts of
data incrementally.

Dataflow Styles (Styles dominated by motion of data through system)

Dataflow network
Component : Transducer
Connectors : Data stream
Control Topology : Arbitrary
Control Synchronicity : Asynchronous
Binding time : Run time
Data Topology : Arbitrary
Data Continuity : Continuous, low or high volume
Data Mode : Passed
Data binding time : Run time
Control/Data Interaction : isomorphic shape
Flow Direction : Same
Type of Reasoning : Functional composition

Batch Sequential

In the batch sequential style, processing steps, or components, are independent programs, and
the assumption is that each step runs to completion before the next step starts. Each batch of data
is transmitted as a whole between the steps. The typical application for this style is classical data
processing.

Batch sequential is a classical data processing model, in which a data transformation subsystem
can initiate its process only after its previous subsystem.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 1

 Software Architecture

The flow of data carries a batch of data as a whole from one subsystem to another.
The communications between the modules are conducted through temporary intermediate
files which can be removed by successive subsystems.
It is applicable for those applications where data is batched, and each subsystem reads
related input files and writes output files.
Typical application of this architecture includes business data processing such as banking
and utility billing.

Separate programs are executed in order; data is passed as an aggregate from one
program to the next.
Connectors: The human hand carrying tapes between the programs, also known as.
sneaker-net
Data Elements: Explicit, aggregate elements passed from one component to the next
upon completion of the producing programs execution.
Typical uses: Transaction processing in financial systems.

Frequent architecture in scientific computing and business data processing

Components are independent programs
Connectors are media, typically files

Batch Sequential : A Financial Application

Batch Sequential

Examples
Payroll computations
Tax reports

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 2

 Software Architecture

Processing steps are independent programs

Each step runs to completion before next step starts Atomic computations
Data transmitted as a whole between steps
Typical applications
o Classical data processing
o Program developments

Summary:

Separate programs executed one at a time, till completion

Design elements
o Components: independent programs
o Connectors: the human hand carrying tapes between the programs, a.k.a.
sneaker-net
o Data: aggregated on tapes
Topology
o Linear
What are common examples of its use?
o Transaction processing in financial systems

Pipe and Filter Style

The Pipe-and-Filter style emphasizes the incremental transformation of data by successive

components. This is a typical style in the UNIX family of operating systems. Filters are stream
transducers. They incrementally transform data (stream to stream), use little contextual
information, and retain no state information between instantiations. Pipes are stateless and
simply exist to move data between filters. Both pipes and filters are run non-deterministically
until no more computations or transmissions are possible. Constraints on the pipe-and-filter style
indicate the ways in which pipes and alters can be joined.

This approach lays emphasis on the incremental transformation of data by successive

component. In this approach, the flow of data is driven by data and the whole system is
decomposed into components of data source, filters, pipes, and data sinks.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 3

 Software Architecture

A pipe has a source end that can only be connected to a filter's output port and a sink end that can
only be connected to a filter's input port.

The connections between modules are data stream which is first-in/first-out buffer that can be
stream of bytes, characters, or any other type of such kind. The main feature of this architecture
is its concurrent and incremented execution.

In a pipe and filter style each component has a set of inputs (read) and a set of outputs (write).
A component reads streams of data on its inputs and produces streams of data on its outputs,
delivering a complete instance of the result in a standard order. This is usually accomplished by
applying a local transformation to the input streams and computing incrementally so output
begins before input is consumed. Hence components are termed filters. The connectors of this
style serve as conduits (channel for conveying water or fluid) for the streams, transmitting
outputs of one filter to inputs of another. Hence the connectors are termed pipes.

A filter is an independent data stream transformer or stream transducers. It transforms the data of
the input data stream, processes it, and writes the transformed data stream over a pipe for the
next filter to process. It works in an incremental mode, in which it starts working as soon as data
arrives through connected pipe. There are two types of filters active filter/ and passive filter.

Active filter: Active filter lets connected pipes to pull data in and push out the
transformed data. It operates with passive pipe, which provides read/write mechanisms
for pulling and pushing. This mode is used in UNIX pipe and filter mechanism.
Passive filter: Passive filter lets connected pipes to push data in and pull data out. It
operates with active pipe, which pulls data from a filter and pushes data into the next
filter. It must provide read/write mechanism.

Among the important invariants of the style, filters must be independent entities: in particular,
they should not share state with other filters. Another important invariant is that filters do not
know the identity of their upstream and downstream filters.

Their specifications might restrict what appears on the input pipes or make guarantees about
what appears on the output pipes, but they may not identify the components at the ends of those
pipes. Furthermore, the correctness of the output of a pipe and filter network should not depend
on the order in which the filters perform their incremental processingalthough fair scheduling
can be assumed.

Figure 1 illustrates this style. Common specializations of this style include pipelines, which
restrict the topologies to linear sequences of filters; bounded pipes, which restrict the amount of
data that can reside on a pipe; and typed pipes, which require that the data passed between two
filters, have a well-defined type.

Pipes form data transmission graphs. Overall computation Run pipes and filters (non-
deterministically) until no more computations are possible. Correctness of pipes and filters
networks output should not depend on ordering (invariant).

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 4

 Software Architecture

Components are filters

Individual programs transform input data streams into output data streams
Possibly incremental production of output
Connectors are pipes
Unidirectional or bidirectional data streams
Style invariants
Filters are independent (no shared state)
Filter has no knowledge of up- or down-stream filters
Every component has one input predecessor connector and one output successor
connector
Configurations
Parallel linear composition of program invocations
Underlying computational model
Sequential data flow and transformation
Common specializations
Pipelines: single linear composition of pipes and filters
Bounded pipes limited amount of data on a pipe
Typed pipes data strongly typed

Examples
1. Programs written in Unix shells Filters: Unix processes. Unix supports this style by providing
a notation for connecting components (represented as Unix processes) and by providing
run time mechanisms for implementing pipes.
2. Pipes: runtime mechanisms for implementing them.
3. Compilers (exp of pipeline) (phases often not incremental). Lexical analysis, parsing, semantic
analysis, code generation. Example: ls invoices | grep -e August | sort
4. Signal processing domains
5. Parallel programming
6. Distributed programming

Advantages
Simplicity: Simple, intuitive, efficient composition of components
Reusability: High potential for reuse of components; any two filters can be
connected if they agree on data format
Evolvability: Changing architectures is trivial
Efficiency: Limited amount of concurrency (contrast batch-sequential)

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 5

 Software Architecture

Consistency: All components have the same interfaces, only one type of
connector
Distributability: Byte streams can be sent across networks
Ease of maintenance: filters can be added or replaced; Possible to hook any two
filters together
Potential for parallelism: filters implemented as separate tasks, consuming and
producing data incrementally
Certain analyses Throughput, latency, deadlock
Concurrent execution

Disadvantages
Batch-oriented processing (Often lead to a batch organization of processing)
Must agree on lowest-common-denominator data format
Does not guarantee semantics
Limited application domain: stateless data transformation
Sharing global data expensive or limiting
Scheme is highly dependent on order of filters
Can be difficult to design incremental filters
Not appropriate for interactive applications
Error handling difficult: what if an intermediate filter crashes?
Data type must be greatest common denominator, e.g. ASCII

Pipe and Filter

Pipe-and-Filter vs. Batch Sequential

Both decompose the task into a fixed sequence of computations (components) interacting
only through data passed from one to another

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 6

 Software Architecture

CALL-AND-RETURN STYLES
Call-and-Return architectures have the goal of achieving the qualities of modifiability and
solvability. Call-and-Return architectures have been the dominant architectural style in large
software systems for the past 30 years. However, within this style, a number of sub styles, each
of which has interesting features, have emerged.

consumer components invoke functionality in provider components

usually the caller waits until an invoked service, completes and returns results before
continuing
components depend on invoked functionality to get their own work done
the correctness of each component may depend on the correctness of the functionality it
invokes

Various categories of Call-Return Styles

subroutines
o decomposition of main program into processing steps
functional modules
o aggregation of processing steps into modules
abstract data types
o bundle operations and data, hide representations and other decisions
objects
o sub-typing, polymorphism, dynamic binding of methods

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 7

 Software Architecture

client-server
o distribution, tiers
components
o multiple interfaces, advanced middleware services
services
o late binding of providers

Main Program and Subroutine Architecture

Main-Program-and-Subroutine architectures are the classical programming paradigm. The goal

is to decompose a program into smaller pieces to help achieve modifiability. A program is
decomposed hierarchically. There is typically a single thread of control and each component in
the hierarchy gets this control (optionally along with some data) from its parent and passes it
along to its children.

Components: Routines, Procedures, data

Connectors: Routine calls, Procedure calls
Key aspects
Routines correspond to units of the task to be performed
Combined through control structures
Routines known through interfaces (argument list)

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 8

 Software Architecture

Variations
Objects as concurrent tasks
Control Topology: Hierarchical
Control Synchronicity: Sequential
Binding time: Write/Compile time
Data Topology: Arbitrary
Data Continuity: Sporadic, low volume
Data Mode: Passed and shared
Data binding time: Run time
Control/Data Interaction: not isomorphic
Flow Direction: N/A
Type of Reasoning: Hierarchy

Advantages

Architecture based on well-identified parts of the task

Change implementation of routine without affecting clients
Reuse of individual operations
o Maintainability: modifiability of method bodies

Disadvantages

Must know which exact routine to change

Hides role of data structure
Does not take into account commonalities between variants
o Bad support for extendibility
Remote Procedure Call

Remote procedure call systems are main-program-and-subroutine systems that are decomposed
into parts that live on computers connected via a network. The goal is to increase performance
by distributing the computations and taking advantage of multiple processors. In remote
procedure call systems, the actual assignment of parts to processors is deferred until runtime,
meaning that the assignment is easily changed to accommodate performance tuning. In fact,
except that subroutine calls may take longer to accomplish if it is invoking a function on a
remote machine, a remote procedure call is indistinguishable from standard main program and
subroutine systems.

Object Oriented Systems

Object-oriented or abstract data type systems are the modern version of call-and-return
architectures. The object-oriented paradigm, like the abstract data type paradigm from which it
evolved, emphasizes the bundling of data and methods to manipulate and access that data (Public
Interface). The object abstractions form components that provide black-box services and other
components that request those services. The goal is to achieve the quality of modifiability.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 9

 Software Architecture

This bundle is an encapsulation that hides its internal secrets from its environment. Access to
the object is allowed only through provided operations, typically known as methods, which are
constrained forms of procedure calls. This encapsulation promotes reuse and modifiability,
principally because it promotes separation of concerns: The user of a service need not know, and
should not know, anything about how that service is implemented.

Components: Classes
Connectors: Routine calls
Key aspects
A class describes a type of resource and all accesses to it (encapsulation)
Representation hidden from client classes
Variations : Objects as concurrent tasks

Object: collection of data and operations (component)

Class: description of set of objects (component)
Subclass: class with additional properties More restrictive than class => fewer
members
Instance: object of a class
Method: procedure body implementing operation Dynamically bound
Message: procedure call; request to execute method Connector
Properties: intuitive, support REUSE

Advantages

Change implementation without affecting clients

Can break problems into interacting agents
Can distribute across multiple machines or networks

Disadvantages

Objects must know their interaction partners; when partner changes, clients must change
Side effects: if A uses B and C uses B, then Cs effects on B can be unexpected to A
Identity of interacting objects needs to be known and needs to be changed in all objects
interacting with an object whose identity was modified

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 10

 Software Architecture

Layered Systems

Layered systems are ones in which components are assigned to layers to control inter component
interaction. In the pure version of this architecture, each level communicates only with its
immediate neighbours.

The goal is to achieve the qualities of modifiability and, usually, portability. The lowest layer
provides some core functionality, such as hardware, or an operating system kernel. Each
successive layer is built on its predecessor, hiding the lower layer and providing some services
that the upper layers make use of.

Components (layers)
Programs or subprograms
Connectors (services)
Procedure calls or system calls
Configurations
Onion or stovepipe structure, possibly replicated
Underlying computational model
Procedure call/return
Stylistic invariants
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)
Each layer provides certain services Hides part of lower layer (invariant)
Provides well-defined interfaces of services to certain other layers
(invariant)
Various functions Kernels: provide core capability, often set of procedures
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
Modifiability : Changing one layer influences only the two adjacent layers
Reuse : Different implementations easy to substitute

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 11

 Software Architecture

Disadvantages
Performance degrades with too many layers
Can be difficult to cleanly assign functionality to the right layer
Not all systems suitable for this
Performance may require other coupling
Abstraction quite hard

Layered Virtual Machine Example : Java

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 12

 Software Architecture

Layered System Example : OSI Protocol Stack

SHARED INFORMATION STYLES

Component : Documents
Connectors : Hyperlinks
Data Topology : Arbitrary
Data Continuity : Continuous
Data Mode : Shared
Data binding time : Write/Compile/Run time
Type of Reasoning : Representation

Note : Control Topoly, Control Synchronicity, Binding Time, Control / Data Interaction, Flow
Direction parameters are NOT APPLICABLE for this style

Has the goal of integrating the data

Refers to systems in which the access and update of a widely accessed
data store occur
A client runs on an independent thread of control
The shared data may be a passive repository or an active blackboard
o A blackboard notifies subscriber clients when changes occur in
data of interest
At its heart is a centralized data store that communicates with a number
of clients
Clients are relatively independent of each other so they can be added,
removed, or changed in functionality
The data store is independent of the clients
Use this style when a central issue is the storage, representation,
management, and retrieval of a large amount of related persistent data
Note that this style becomes client/server if the clients are modeled as
independent processes

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 13

 Software Architecture

In data-centered architecture, the data is centralized and accessed frequently by other

components, which modify data. The main purpose of this style is to achieve integrality of
data. Data-centered architecture consists of different components that communicate through
shared data repositories. The components access a shared data structure and are relatively
independent, in that, they interact only through the data store.

The most well-known examples of the data-centered architecture is a database architecture, in

which the common database schema is created with data definition protocol for example, a set
of related tables with fields and data types in an RDBMS.

Another example of data-centered architectures is the web architecture which has a common
data schema (i.e. meta-structure of the Web) and follows hypermedia data model and processes
communicate through the use of shared web-based data services.

Data-Centered Style
Client A Client B Client C

Shared Data

Client D Client E Client F

23

Advantage
Clients are independent from each other. Thus, a client can be changed, without affecting
the others. Also further clients can be added.
This advantage pales if the architecture is changed in such a way that clients are coupled
closely, for example in order to improve the performance of the system.

Disadvantage
Data consistency - synchronization of read/write operations
Data security, access control
Single point of failure

Types of Components

There are two types of components

A central data structure or data store or data repository, which is responsible for
providing permanent data storage. It represents the current state.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 14

 Software Architecture

A data accessor or a collection of independent components that operate on the central

data store, perform computations, and might put back the results.

Access to shared data represents the core characteristic of data-centered architectures. The data
integrability forms the principal goal of such systems

The means of communication between the components distinguishes the subtypes of the data-
centered architectural style:

Interactions or communication between the data accessors is only through the data store. The
data is the only means of communication among clients. The flow of control differentiates the
architecture into two categories as,

Repository Architecture Style : passive data

Blackboard Architecture Style : active data
o A blackboard sends notification to subscribers when relevant data change
( Observer pattern)
o A Blackboard architecture informs the clients interested in changes.

Repository Architecture Style

In Repository Architecture Style, the data store is passive and the clients (software components
or agents) of the data store are active, which control the logic flow. The participating
components check the data-store for changes.

A client sends a request to the system to perform actions (e.g. insert data). The computational
processes are independent and triggered by incoming requests. If the types of transactions in an
input stream of transactions trigger selection of processes to execute, then it is traditional
database or repository architecture, or passive repository. This approach is widely used in
DBMS, library information system, the interface repository in CORBA, compilers, and CASE
(computer aided software engineering) environments.

Advantages
Provides data integrity, backup and restore features.
Provides scalability and reusability of agents as they do not have direct communication
with each other.
Reduces overhead of transient data between software components.

Disadvantages
High dependency between data structure of data store and its agents.
Changes in data structure highly affect the clients.
Evolution of data is difficult and expensive.
Cost of moving data on network for distributed data.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 15

 Software Architecture

Blackboard Architecture Style

In Blackboard Architecture Style, the data store is active and its clients are passive. Therefore the
logical flow is determined by the current data status in data store. It has a blackboard component,
acting as a central data repository, and an internal representation is built and acted upon by
different computational elements.

Further, a number of components that act independently on the common data structure are stored
in the blackboard. In this style, the components interact only through the blackboard. The data-
store alerts the clients whenever there is a data-store changes. The current state of the solution is
stored in the blackboard and processing is triggered by the state of the blackboard.

When changes occur in the data, the system sends the notifications known as trigger and data to
the clients. This approach is found in certain AI applications and complex applications, such as
speech recognition, image recognition, security system, and business resource management
systems etc.

If the current state of the central data structure is the main trigger of selecting processes to
execute, the repository can be a blackboard and this shared data source is an active agent.
A major difference with traditional database systems is that the invocation of computational
elements in a blackboard architecture is triggered by the current state of the blackboard, and not
by external inputs.

Independent components asynchronously emit and receive events communicated over

event buses
Components
Independent, concurrent event generators and/or consumers
Blackboard Client programs
Connectors
Event buses (at least one)
Blackboard : shared data repository (possibly with finite capacity)
Configurations
Multiple client sharing single blackboard
Data Elements: Events data sent as a first-class entity over the event bus

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 16

 Software Architecture

Underlying computational model

Synchronized, shared data transactions, with control driven entirely by blackboard
state.
Topology
Components communicate with the event buses, not directly to each other.
Variants
Component communication with the event bus may either be push or pull based.
Highly scalable, easy to evolve, effective for highly distributed applications.

Parts of Blackboard Model

Knowledge Sources (KS)

Knowledge Sources, also known as Listeners or Subscribers are distinct and
independent units. They solve parts of a problem and aggregate partial results. Interaction
among knowledge sources takes place uniquely through the blackboard.

Blackboard Data Structure

The problem-solving state data is organized into an application-dependent hierarchy.
Knowledge sources make changes to the blackboard that lead incrementally to a solution
to the problem.

Control
Control manages tasks and checks the work state.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 17

 Software Architecture

Advantages

Blackboard Model provides concurrency that allows all knowledge sources to work in parallel as
they independent of each other. Its scalability feature facilitates easy steps to add or update
knowledge source. Further, it supports experimentation for hypotheses and reusability of
knowledge source agents.

Disadvantages

The structural change of blackboard may have a significant impact on all of its agents, as
close dependency exists between blackboard and knowledge source.
Blackboard model is expected to produce approximate solution; however, sometimes, it
becomes difficult to decide when to terminate the reasoning.
Further, this model suffers some problems in synchronization of multiple agents,
therefore, it faces challenge in designing and testing of the system.

EVENT STYLES
Event Based Implicit Invocation

In event-based implicit invocation architecture, components register their interest in specific

events with an event manager (using its provided interface). As part of the registration process,
each component makes a callback method on its provided interface available to the event
manager as one of its required interfaces. Thereafter, whenever a registered event is detected by
the event manager, it calls the callback method of every component registered for it and gives
each one the event

Examples
debugging systems (listen for particular breakpoints)
database management systems (for data integrity checking) _ graphical user interfaces

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 18

 Software Architecture

Interesting properties
announcers of events dont need to know who will handle the event
Supports re-use, and evolution of systems (add new agents easily)

Disadvantages
Components have no control over ordering of computations

Components
Programs or program entities that announce and/or register interest in events
Events represent happenstances inside an entity that may (or may not) be of interest to
other entities

Connectors
Direct registration with announcing entities
Or, explicit event broadcast and registration infrastructure

Configurations
Implicit dependencies arising from event announcements and registrations

Underlying computational model

Event announcement is broadcast
Procedures associated with registrations (if any) are invoked

Publish-Subscribe Event-Based

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 19

 Software Architecture

Event Based Style

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 20

 Software Architecture

Publish Subscribe Implicit Invocation

A component may:
Announce events
Register a callback for events of other components
Connectors are the bindings between event announcements and routine calls (callbacks)

Publish - Subscribe Style : Properties

Publishers of events do not know which components (subscribers) will be affected by

those events. Components cannot make assumptions about ordering of processing, or
what processing will occur as a result of their events

Components
o Publishers, subscribers
o Event generators and consumers

Connectors
Procedure calls
Event bus

Topology
Subscribers connect to publishers directly (or through network)
Components communicate with the event bus, not directly to each other

Advantages
o Efficient dissemination of one-way information
o Provides strong support for reuse
o Allows for decoupling and autonomy of components
o Any component can be added, by registering/subscribing for events
o Eases system evolution
components may be replaced without affecting other components in the system

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 21

 Software Architecture

Disadvantages
o Need special protocols when number of subscribers is very large
o Event abstraction does not cleanly lend itself to data exchange
o Difficult to reason about behaviour of an announcing component independently of
components that register for its events
o When a component announces an event:
it has no idea what other components will respond to it,
it cannot rely on the order in which the responses are invoked
it cannot know when responses are finished
o Correctness hard to ensure: depends on context and order of invocation

QA evaluation

Performance : Can deliver 1000s of msgs

Event bus: how does it compare to Repository?
Availability : Publisher needs to be replicated
Scalability : Can support 1000s of users, growth in data size
Modifiability : Easily add more subscribers, change in message format
affects many subscribers
Examples

Used in programming environments to integrate tools:

o Editor scrolls to the appropriate source line and highlights it
o Editor shows syntax errors reported by compiler
Editor announces it has finished editing a module
o Compiler registers for such announcements and automatically re-compiles module
Debugger announces it has reached a breakpoint
o Editor registers for such announcements and automatically scrolls to relevant
source line
Syntax-directed editors to support incremental semantic checking
Twitter, Google+
User interfaces (Model-View-Controller)

Summary:

Subscribers register/deregister to receive specific messages or specific content.

Publishers broadcast messages to subscribers synchronously or asynchronously.
Design elements
o Components: publishers, subscribers
o Connectors: procedure calls/network protocols
o Data: subscriptions, notifications, published information
Topology:
o Either subscribers directly connected to publishers
o Or via intermediaries
What are common examples of its use?
o Social media friending

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 22

 Software Architecture

o GUI
o Multi-player network-based games
What are the advantages of using the style?
o Subscribers are independent from each other
o Very efficient one-way information dissemination
What are the disadvantages of using the style?
o When a number of subscribers is very high, special protocols are needed

CASE STUDIES
CASE STUDY 1 : KWIC (KEY WORD IN CONTEXT)

REFER UNIT 1

CASE STUDY 2 : INSTRUMENTATION SOFTWARE

Describes the industrial development of software architecture.

The purpose of the project was to develop a reusable system architecture for oscilloscope
Oscilloscope is an instrumentation system that samples electrical signals and displays
pictures of them on screen.
Oscilloscope also performs measurements on the signals and displays them on screen.
Modern oscilloscope has to perform dozens of measurements supply megabytes of
internal storage.
Support an interface to a network of workstations and other instruments and provide
sophisticated user interface, including touch panel screen with menus, built-in help
facilities and color displays.
Problems faced:
o Little reuse across different oscilloscope products.
o Performance problems were increasing because the software was not rapidly
configurable within the instrument.
Goal of the project was to develop an architectural framework for oscilloscope.
Result of that was domain specific software architecture that formed the basis of the next
generation of oscilloscopes.

SOLUTION 1: OBJECT ORIENTED MODEL

Different data types used in oscilloscope are:

Waveforms
Signals
Measurements
Trigger modes so on
There was no overall model that explained how the types fit together. This led to confusion about
the partitioning of functionality. Ex: it is not clearly defined that measurements to be associated
with types of data being measured or represented externally.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 23

 Software Architecture

SOLUTION 2: LAYERED MODEL

To correct the problems by providing a layered model of an oscilloscope.

Core-layer: implemented in hardware represents signal manipulation functions that filter
signals as they enter the oscilloscope.
Initially the layered model was appealing since it partitioned the functions of an
oscilloscope into well defined groups.
But, it was a wrong model for the application domain. Because, the problem was that the
boundaries of abstraction enforced by the layers conflicted with the needs for interaction
among various functions.

SOLUTION 3: PIPE-AND-FILTER MODEL:

In this approach oscilloscope functions were viewed as incremental transformers of data.

o Signal transformer: to condition external signal.
o Acquisition transformer: to derive digitized waveforms
o Display transformers: to convert waveforms into visual data.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 24

 Software Architecture

It is improvement over layered model as it did not isolate the functions in separate
partition.
Main problem with this model is that
o It is not clear how the user should interact with it

CASE STUDY 3 : MOBILE ROBOTICS

Mobile Robotic systems

o Controls a manned or semi-manned vehicle
E.g., car, space vehicle, etc
o Used in space exploration missions
o Hazardous waste disposal
o Underwater exploration
The system is complex
o Real Time respond
o Input from various sensors
o Controlling the motion and movement of robots
o Planning its future path/move
Unpredictability of environment
o Obstacles blocking robot path
o Sensor may be imperfect
o Power consumption
o Respond to hazardous material and situations

DESIGN CONSIDERATIONS

REQ1: Supports deliberate and reactive behavior. Robot must coordinate the actions to
accomplish its mission and reactions to unexpected situations
REQ2: Allows uncertainty and unpredictability of environment. The situations are not fully
defined and/or predicable. The design should handle incomplete and unreliable information
REQ3: System must consider possible dangerous operations by Robot and environment
REQ4: The system must give the designer flexibility (missions change/requirement changes)

SOLUTION 1: CONTROL LOOP

Req1: An advantage of the closed loop paradigm is its simplicity

it captures the basic interaction between the robot and the outside.
UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 25
 Software Architecture

Req2: control loop paradigm is biased towards one method

reducing the unknowns through iteration
Req3: fault tolerance and safety are supported which makes duplication easy and reduces the
chances of errors
Req4: the major components of a robot architecture are separated from each other and can be
replaced independently

Control Loop Layered Architecture

SOLUTION 2: LAYERED ARCHITECTURE

Figure shows Alberto Elfess definition of the layered architecture.

Level 1 (core) control routines (motors, joints,..),

Level 2-3 real world I/P (sensor interpretation and integration (analysis of combined I/Ps)
Level 4 maintains the real world model for robot
Level 5 manage navigation
Level 6-7 Schedule & plan robot actions (including exception handling and re-planning)

Top level deals with UI and overall supervisory functions

Req1: it overcomes the limitations of control loop and it defines abstraction levels to
guide the design
Req2: uncertainty is managed by abstraction layers
Req3: fault tolerance and passive safety are also served
Req4: the interlayer dependencies are an obstacle to easy replacement and addition of
components.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 26

 Software Architecture

SOLUTION 3: IMPLICIT INVOCATION

The third solution is based on the form of implicit invocation, as embodied in the Task-Control-
Architecture (TCA). The TCA design is based on hierarchies of tasks or task trees
Parent tasks initiate child task
Temporal dependencies between pairs of tasks can be defined
A must complete A must complete before B starts (selective concurrency)
Allows dynamic reconfiguration of task tree at run time in response to sudden
change(robot and environment)
Uses implicit invocation to coordinate tasks
Tasks communicate using multicasting message (message server) to tasks that are
registered for these events

TCAs implicit invocation mechanisms support three functions:

Exceptions: Certain conditions cause the execution of an associated exception handling
routines.
o i.e., exception override the currently executing task in the sub-tree (e.g., abort or
retry) tasks
Wiretapping: Message can be intercepted by tasks superimposed on an existing task tree
o E.g., a safety-check component utilizes this to validate outgoing motion
commands
Monitors: Monitors read information and execute some action if the data satisfy certain
condition
o E.g. battery check

Implicit Invocation Black Board Architecture

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 27

 Software Architecture

Req1: permits clear cut separation of action and reaction

Req2: a tentative task tree can be built to handle uncertainty
Req3: performance, safety and fault tolerance are served
Req4: makes incremental development and replacement of components straight forward

SOLUTION 4: BLACKBOARD ARCHITECTURE

The components of CODGER are the following:

Captain: overall supervisor
Map navigator: high-level path planner
Lookout: monitors environment for landmarks
Pilot: low-level path planner and motor controller
Perception subsystems: accept sensor input and integrate it into a coherent situation
interpretation

The requirements are as follows:

Req1: the components communicate via shared repository of the blackboard system.
Req2: the blackboard is also the means for resolving conflicts or uncertainties in the
robots world view
Req3: speed, safety and reliability is guaranteed
Req4: supports concurrency and decouples senders from receivers, thus facilitating
maintenance.

UNIT III R.M.D.ENGINEERING COLLEGE : IT DEPARTMENT Page 28