Transcript Lecture 2 Introductory Case Studies CSCE 742 Software Architectures Topics

CSCE 742 Software Architectures
Lecture 2
Introductory Case Studies
Topics




Architectural Styles
Key Word In Context (KWIC)
Other Cases Studies
Evolution of Software Engineering
January 15, 2009
Overview
Last Time



What is Software Architecture?
What do you already know?
Architectural styles
On last Time’s Slides(what we didn’t get to)

KWIC case study
New

Other Case studies
What do you know?


–2–
What is the waterfall Model?
What is the spiral model?
CSCE 742 Spring 09
Architectural Styles
 Dataflow Systems


Batch- sequential
Pipes and filters
 Call-and-Return Systems



Main program and subroutine
OO systems
Hierarchical layered systems
 Independent Components


Communicating processes
Event driven systems
 Machines


Interpreters
Rule-based systems
 Repositories - Data-centered systems



–3–
Databases
Hypertext Systems
Blackboards
CSCE 742 Spring 09
Architectural Case Studies
 Key word in context
 Instrumentation Software
 Compilers
 Layered Design with Different Styles for the Layers
 Interpreter using Different Idioms for Components
 A Blackboard
–4–
CSCE 742 Spring 09
Case Study: Key word in context
In 1972, Parnas proposed the following problem KWIC:
The KWIC [Key Word in Context] index system:
1. Accepts an ordered set of lines, each line is an
ordered set of words, and each word is an ordered
set of characters.
2. Any line may be ``circularly shifted'' by repeatedly
removing the first word and appending it at the end
of the line.
3. The KWIC index system outputs a listing of all
circular shifts of all lines in alphabetical order.
Reference: “On the Criteria for Decomposing Systems into
Modules,” David Parnas. CACM, 1972
http://www-2.cs.cmu.edu/People/ModProb/KWIC.html
–5–
CSCE 742 Spring 09
Who is David Parnas anyway?
He is an ACM Fellow and a leader in the development of
the field of Software engineering.
http://www.acm.org/sigs/sigsoft/SEN/parnas.html
First work experience in industry (1969) led him to
realize that the company was breaking things up into
modules incorrectly; thus leading to greater
complexity
–6–
CSCE 742 Spring 09
Case Study: Key word in context
Example: SC Clerk of Courts (1985 project)
One line

Assault and battery with intent to kill
Permuted yields







Assault and battery with intent to kill.
and battery with intent to kill. Assault
battery with intent to kill. Assault and
with intent to kill. Assault and battery
intent to kill. Assault and battery with
to kill. Assault and battery with intent
kill. Assault and battery with intent to
Then sorted yields




–7–
and battery with intent to kill. Assault
Assault and battery with intent to kill.
battery with intent to kill. Assault and
…
So “assault and battery”
could be found by
looking up either
keyword “assault” or
“battery”
CSCE 742 Spring 09
Case Study: Decomposition in KWIC
Parnas used the problem to contrast different criteria
for decomposing a system into modules:
1. Functional decomposition with shared access to
data representations, and
2. A decomposition that hides design decisions.
Examples: permuted index of the Unix man
–8–
CSCE 742 Spring 09
KWIC: Design Considerations
Changes in algorithm:
Changes in data representation
Have the system eliminate circular shifts that start with
certain noise words (such as "a", "an", "and", etc.).
Make the system interactive, and allow the user to
delete lines from the lists.
Finally, considering differences in architectural
solutions based on considerations of:
Performance: Both space and time.
Reuse
–9–
CSCE 742 Spring 09
KWIC: Software Arch. Considerations
Changes in processing algorithm
Changes in data representation
Enhancement to system function
Performance: Both space and time.
Reuse: To what extent can the components serve as
reusable entities.
– 10 –
CSCE 742 Spring 09
Architectural Approaches to KWIC
Solution 1: Main Program/Subroutine with Shared Data
Solution 2: Abstract Data Types
Solution 3: Implicit Invocation
Solution 4: Pipes and Filters
The first two of these were from Parnas 1972
Solution 3 was from Garlan, Kaiser and Notkin 1992
Solution 4 inspired by Unix command.
– 11 –
CSCE 742 Spring 09
KWIC: Main Program/Subroutine with
Shared Data
– 12 –
CSCE 742 Spring 09
KWIC: Main / Subroutine
Notes:
1. Data is shared, common storage. This is + and –
2. Serious drawbacks:




– 13 –
Changes in data storage format affects all modules
Changes in algorithm not well supported
Enhancements not easily encorporated
Not supportive of reuse
CSCE 742 Spring 09
KWIC: Abstract Data Types
– 14 –
CSCE 742 Spring 09
KWIC: Abstract Data Types
Notes:
1. Could be called object-oriented (Parnas 1972)
2. Data not accessed directly, but through accessor
functions
3. More easily modified than solution 1


Data
Algorithm
4. Reuse better supported because modules make
fewer assumptions about other modules.
– 15 –
CSCE 742 Spring 09
KWIC: Implicit Invocation
– 16 –
CSCE 742 Spring 09
KWIC: Implicit Invocation
Notes:
1. Shared data similar to solution 1.
2. Two differences in access model:
1.
2.
Data accessed abstractly i.e., “as a list, or set”
Computations are implicitly invoked; an “Active data”
model
 E.g., Adding a line causes an event to be sent to the line shift
module
3. Because data is accessed abstractly changes in
storage format can be localized
4. Supports functional enhancements

New modules easily added by registering the data events
that should caused them to be invoked
5. On the negative side it is difficult to control
computation order.
– 17 –
CSCE 742 Spring 09
KWIC: Pipes and Filters
– 18 –
CSCE 742 Spring 09
KWIC: Pipe and Filters
Notes:
1. Inspired by the old UNIX permuted index
2. Cat data | permuteLines | sort
– 19 –
CSCE 742 Spring 09
KWIC: Comparison
– 20 –
CSCE 742 Spring 09
KWIC: Comparison
Notes:
Shared Data

Not good at change in data or algorithm; efficient
ADT/OO

Good at change in data and in reuse; efficient also
Implicit Invocation

Good at change in algorithm; just register the new functions
Pipe and Filter

– 21 –
Good at reuse and change in algorithm, modularity; however
stuck with lowest level data transmission involving
reparsing overhead
CSCE 742 Spring 09
Case Studies
 Key word in context
 Instrumentation Software
 Compilers
 Layered Design with Different Styles for the Layers
 Interpreter using Different Idioms for Components
 A Blackboard
– 22 –
CSCE 742 Spring 09
Case Study: Instrumentation Software
Software architecture developed at Tektronix to develop
a “reusable system architecture” for oscilloscopes.
What is an oscilloscope?
Once simple analog device, now complex digital
technology with complex software.
Problems faced by Tektronix:
1.
2.
3.
Little reuse of software across different products
Both hardware and interface requirements were rapidly
changing
Performance problems increasing because of configuration
limitations
Goal: Develop new architecture for oscilloscopes
– 23 –
CSCE 742 Spring 09
Instrumentation Software: OO Model
Focused on producing object-oriented model of the
domain
This produced a good model of the data involved
Oscilloscope
Object
Waveform
Max-min Wvfm
– 24 –
X-Y Wvfm
…
Accumulate Wvfm
CSCE 742 Spring 09
Instrum. Software: OO Model Limitations
No overall model of how the types fit together
Led to confusion about partitioning the functionality


– 25 –
Should measurements be associated with data type of
what is being measured? Or represented externally
Which objects should the interface interact with?
CSCE 742 Spring 09
Instrum. Software: A Layered Model
Hardware
Digitization
Visualization
User Interface
– 26 –
CSCE 742 Spring 09
Instrum. Software: A Layered Model
This model was intuitively appealing since it partitioned
up the functionality into well defined groups.
However, wrong model:
main problem was that the boundaries of abstraction
enforced by the layers conflict with what was really
needed.
user interactions with the visualizations but real
oscilloscopes must interact at several levels
– 27 –
CSCE 742 Spring 09
Instrum. Software: Pipe and Filter Model
Couple – condition the signal
Acquire – derive digitized waveforms
To-XY - display
Clip – clip images to display
Trigger Subsystem Measure
Main Problem: How should user interact with the system?
– 28 –
CSCE 742 Spring 09
Instrum. Soft: Modified Pipe and Filter Model
Notes
1.
Performance problems – waveforms are large; copying is
expensive
2.
Different speed of the different filters
3.
Solution several types “colors” of pipes; one copies, one doesn’t
4.
Speed handled by pipelining
– 29 –
CSCE 742 Spring 09
Traditional Compiler
Lexical analysis
Syntax Analysis
Semantic Analysis
Optimization
Code Generation
Modified with globally accessible symbol table
– 30 –
CSCE 742 Spring 09
Modern Compiler
– 31 –
CSCE 742 Spring 09
Canonical Compiler Revisited
– 32 –
CSCE 742 Spring 09
Layered Design with Different Styles
PROVOX system designed by Fisher Controls
Level 1 – Process measurement
Level 2 – Process supervision – monitoring and
controlling level 1
Level 3 – Process management – plant automation,
management reports, optimization strategies
Level 4 – Plant Management – interactions; cost
accounting, inventory
Level 5 – Corporation Management – Order
proecessing/billing
– 33 –
CSCE 742 Spring 09
Layered Design with Different Styles
– 34 –
CSCE 742 Spring 09
Layered Design with Different Styles
Levels 1-3 were Object-oriented
Levels 4 and 5 were primarily respository (database)
models
– 35 –
CSCE 742 Spring 09
Rule Based Systems
– 36 –
CSCE 742 Spring 09
Blackboard model: Hearsay II (speech processing)
– 37 –
CSCE 742 Spring 09
Evolution of Software Engineering
What is engineering?
Phrases in answers:
1. Creating cost-effective solutions
2. … to practical problems …
3. … by applying scientific knowledge …
4. … building things …
5. … in the service of mankind …
Applied science for practical problems
– 38 –
CSCE 742 Spring 09
Traditional Engineering
Design experience built up over the years
Key design parameters abstracted from problems
Design problem formalized
Knowledge codified
Handbooks of Design
Well there are no handbooks of design for software.
There are algorithms and libraries and now class
libraries, but these are components.
– 39 –
CSCE 742 Spring 09
Evolution of an Engineering Discipline
– 40 –
CSCE 742 Spring 09