Case Studies

Key Word in Context

 Case Studies
•Key Word in Context
–The System accepts a ordered set of lines, each line is an ordered set of words, each word 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 system outputs a listing of all circular shifts of all lines in alphabetical order.
– How does an architecture change with respect to changes in
• Processing Algorithm
• Data representation
• Data Flow
• Control Flow
–How are these changes evaluated with respect to :
• System enhancements : modify the system
• Performance : Both space and time.
• Reuse : To what extent can the components serve as reusable entities.
• Other Quality Attributes
 Case Studies

Solution 1: Main Program/Subroutine with Shared Data

Solution 2: Abstract Data Types

Solution 3: Implicit Invocation

Solution 4: Pipes and Filters

 Main Program with Shared Data

Master Control
Subroutine Calls

Input Circular Shift Alphabetizes Output

DMA
Input Characters Index Alphabetized Index Output
Medium Medium

• Disadvantages:
• Advantages:
–Change in data storage format
–Efficient Control Flow
affects all modules
Mechanism
– Ease of Upgrade to different
–Efficient Data Representation
algorithms?
–Efficient Data Flow between – Reusable in different
modules domains?
 Abstract Data Types
Master Control Subroutine Calls

Input Output
Set Char

Set Char
Word

Word
Setup

Alpha
Char

Char
Input Output

Ith
Medium
Medium

Characters Circular Shift Alphabetic Shifts

• Data is no longer shared by the modules

– Each module provides an interface that permits other modules to access data only by invoking procedures
in its interface.
• Advantages:
– Both algorithms and data representations can be changed in each module without affecting the other
modules.
• Better reuse as the modules make few assumptions about the others in which they interact.
• Disadvantages:
– Adding new functions requires the other modules to be modify existing
modules or add new modules.
 Implicit Invocation
Master Control Subroutine Calls

Input Circular Shift Alphabetizer Output

Output
Delete

Delete
Insert

Insert
Input
I th

I th
Medium
Medium

Lines Lines

• Data Interface is more abstract: Accesses data as a list or set of lines

• Computations invoked implicitly as data is modified
– New lines causes events to the shift module, producing data shifts in a separate data store, which in turn causes an event to the
alphabetizer to alphabetize the lines.
– Note that NEW modules can be added to the system and they register for the events of interest. Reuse is enhanced as modules
only respond to registered events.
• Disadvantage: May be difficult to control the processing order and activation of the event driven modules.
Data driven invocation tend to use more memory.
– One of the problems I have encountered with the blackboard, in that if you are not specific in the events and trigger activation
conditions you get all kinds of computational activity happening when you least expect it or want it.
 Pipes & Filters

Input Circular Shift Alphabetizer Output Output

Medium

Input
Medium

•Advantages:
–Maintains the intuitive processing flow
–Each filter can function in isolation
–New functions easily added to the processing flow
–Filters are logically independent of one another
•Disadvantages:
–Impossible to modify the design for interaction
–Data design is inefficient as all data must be copied throughout the system.

Fall 2002
 Comparisons

Shared Data Abstract Data Type Implicit Invocation Pipe & Filter

Algorithm Changes - - + +

Data Representation
Changes
- + - -

Function Changes + - + +
Performance + + - -
Reuse - + - +
Control + + + -
Score 0 +2 0 0
 Suggested Comparisons

The shared data solution is particularly weak in its support for changes in

the overall processing algorithm, data representations, and reuse.

 On the other hand it can achieve relatively good performance, by virtue of

direct sharing of data.

Further, it is relatively easy to add a new processing component (also

accessing the shared data).

The abstract data type solution allows changes to data representation and

supports reuse, without necessarily compromising performance

 Instrumentation Software
–Our second case study describes the industrial development of a
software architecture at Tektronix, Inc.
–This work was carried out as a collaborative effort between several
Tektronix product divisions and the Computer Research Laboratory.
–The purpose of the project was to develop a reusable system
architecture for oscilloscopes.
– An oscilloscope is an instrumentation system that samples electrical
signals and displays pictures (called traces) of them on a screen.
– Additionally, oscilloscopes perform measurements on the signals, and
also display these on the screen.
–The goal of the project was to develop an architectural framework for
oscilloscopes that would address these problems.
 Instrumentation Software
–An object-oriented model
–The first attempt at developing a reusable architecture focused on
producing an object-oriented model of the software domain.
–This led to a clarification of the data types used in oscilloscopes:
waveforms, signals, measurements, trigger modes, etc.

–Ref the pdf for block diagram

 Instrumentation Software
–A layered model
–In this model the core layer represented the signal manipulation
functions that filter signals as they enter the oscilloscope.
–These functions are typically implemented in hardware. The next layer
represented waveform acquisition. Within this layer signals are digitized
and stored internally for later processing.
– The third layer consisted of waveform manipulation, including
measurement, waveform addition, Fourier transformation, etc.
–The fourth layer consisted of display functions. This layer was
responsible for mapping digitized waveforms and measurements to
visual representations. The outermost layer was the user interface. This
layer was responsible for interacting with the user and for deciding
which data should be shown on the screen.
 Instrumentation Software

–A Pipe and Filter Model

–The third attempt yielded a model in which oscilloscope functions were
viewed as incremental transformers of data.
–Signal transformers serve to condition external signals.
–Acquisition transformers derive digitized waveforms from these signals.
Display transformers convert these waveforms into visual data.

–Ref the pdf for block diagram

 Instrumentation Software
– An OO Model
• How does the data and model fit together which led to issues on
partitioning and measuring.
• How does the user interact with it ?
–A Layered Model
• Nice at first thought, however the boundaries of abstraction enforced
by the layers, conflicted with the needs for interaction between the
wave form processing functions.
–A Pipe & Filter Model
• Corresponded well with the engineers understanding of signal
processing and data flow between signal processing functions.
• How does the user interact with it ?
 Instrumentation Software
• Instrumentation Software
–A Modified Pipe & Filter
• Added a control interface to the architecture to allow an external entity to set parameters of
operation for the filters.
 This is especially true in signal processing domains where we have a flow of data through a
series of algorithms at break-neck speeds and we want to conduct real-time performance
enhancements and tuning.
 A Control interface addresses the ability to interact with the processing and tailor the
processing dynamically.
– Decouples the signal processing software from changes in the control parameters.
–Further Specialization
• Introduced several kinds of pipes and filters to address different waveforms to address the memory
requirements of the waveforms and constraints of the system.
–Summary
• Know the benefits of each architectural style
• Know how to tailor each style to address your particular needs

Filter (n)

Couple Acquire To:X-Y Clip

Control Variables
 Mobile Robotics
Design Considerations
– Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior
• Robot (system) must coordinate the actions to achieve the desired objectives based on the constraints
and its operating environment.
– Req. (2) Architecture must allow for Uncertainty
– Robot (system) actions are never fully predictable
– Robot (system) must be able to operate (decide) with incomplete and unreliable information.
– Req. (3) Architecture must account for dangers present in its environment or its operation
– Robot architecture must balance fault-tolerance, safety, performance
– (Especially when people are placed in harms way or do not have immediate access to emergency
services)
– Robot must be able to understand how to maintain its integrity, operators, and environment (you
really don’t want it to go bang (or cause a bang) in an explosive, corrosive, or contaminated
environment) ..I.e power conservation, detect unexpected failures, etc.
– Req. (4) Architecture must provide designer flexibility in application development,
experimentation, and reconfiguration (new uploads)
 Mobile Robotics
Control Loop Approach
–Req. (1) Architecture must:
• Accommodate Deliberate and Reactive Behavior

–Closed Loop (real-time) feedback systems are very simple.

–(Book:) Note that feedback control loops assume changes in the environment are
continuous and require continuous reactions.
 (Note that this is Not necessarily true -> Some feedback systems (especially weather prediction
systems) can take months of sample and analysis before we are able to update predicted data.
– If the system is required to have an immediate reaction to an environment then we should consider this
approach.
– We will find that there are better architecture approaches (I.e. simplified BB) for control of this type of
problem, even for the control of real-time video.
 Mobile Robotics
–Req. (2) Architecture must allow for Uncertainty
–In a control loop approach, the expected output signal is fed back to the input.
–The difference between the input signal and the predicted output signal
generates an error signal that drives the control loop algorithm.
–This is the only uncertainty allowed.
If more detailed uncertainty in the observed sampled inputs are required to be used
in the control laws then we might go to an optimal estimator.
–However if “Uncertainty” implies that we want “Emergent” as of yet
undefined behavior from our system in response to unplanned or unforeseen
inputs, then a simple control loop architecture will not be able to handle the
requirement.
 “I.e I want the Mars Rover to “Investigate” any situation that appears “interesting”.
 (Dynamic task prioritization)
 Mobile Robotics
• Control Loop Approach
–Req. (3) Architecture must account for dangers present in its environment or its operation
–Fault-tolerance and safety are supported by this architecture style to the extent that it is
“SIMPLE” and therefore reduces the errors that can enter the system.
 This is often not the case -> sensors fail, redundancy and voting logic must now be
incorporated into the system, adding weight, power, and cost.

–Req. (4) Architecture must provide designer flexibility in application development,

experimentation, and reconfiguration (new uploads)
– As is the case hardware components can often be easily replaced… What would you have to do
control this architecture in order to update a new software load?

–Conclusion:
–Control Loop Architecture appears to be the best for SIMPLE robotic systems that handle a few
number and types of inputs within a PREDICTABLE environment
Closed Loop robotic architecture