1. Lecture 2b Introductory Case Studies
CSCE 742 Software Architectures
Lecture 2b Introductory Case Studies
Topics
Architectural Styles
Key Word In Context (KWIC)
Other Cases Studies
Evolution of Software Engineering
May 10, 2017

2. Overview Last Time On last Time’s Slides(what we didn’t get to) New
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?
What is the waterfall Model?
What is the spiral model?

3. Architectural Styles Plan for 2017 Highlights (skip lots of slides)
Slides left off Lecture 01
Parnas Keyword in Context (5-8)
Layered again 26
Compiler views (31-32)
Rule-based Systems (36-37)
Software as a Service(SaaS) (40-43)
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
Databases
Hypertext Systems
Blackboards

4. 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

5. Case Study: Key word in context
In 1972, Parnas proposed the following problem KWIC:
The KWIC [Key Word in Context] index system:
Accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters.
Any line may be ``circularly shifted'' by repeatedly removing the first word and appending it at the end of the line.
The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order.
Reference: “On the Criteria for Decomposing Systems into Modules,” David Parnas. CACM, 1972

6. Who is David Parnas anyway?
He is an ACM Fellow and a leader in the development of the field of Software engineering.
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

7. 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 …
So “assault and battery” could be found by looking up either keyword “assault” or
“battery”

8. Case Study: Decomposition in KWIC
Parnas used the problem to contrast different criteria for decomposing a system into modules:
Functional decomposition with shared access to data representations, and
A decomposition that hides design decisions.
Examples: permuted index of the Unix man
$ ptx < input_file …
in most states, an assault/battery is committed when
/a more serious or "aggravated" assault/battery occurs when one:/
/("tort") cases involving assault and battery, visit the/
/distinct elements. In short, an assault is an attempt or threat to/
/.findlaw.com/criminal-charges/ assault-and-battery-overview.html#/

9. 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 certain qualities

10. KWIC: Software Arch. Considerations
Finally, considering differences in architectural solutions based on considerations of:
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.

11. 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.

12. KWIC: Main Program/Subroutine with Shared Data

13. KWIC: Main / Subroutine
Notes:
Data is shared, common storage. This is + and –
Serious drawbacks:
Changes in data storage format affects all modules
Changes in algorithm not well supported
Enhancements not easily encorporated
Not supportive of reuse

14. KWIC: Abstract Data Types

15. KWIC: Abstract Data Types
Notes:
Could be called object-oriented (Parnas 1972)
Data not accessed directly, but through accessor functions
More easily modified than solution 1
Data
Algorithm
Reuse better supported because modules make fewer assumptions about other modules.

16. KWIC: Implicit Invocation

17. KWIC: Implicit Invocation
Notes:
Shared data similar to solution 1.
Two differences in access model:
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
Because data is accessed abstractly changes in storage format can be localized
Supports functional enhancements
New modules easily added by registering the data events that should caused them to be invoked
On the negative side it is difficult to control computation order.

18. KWIC: Pipes and Filters

19. KWIC: Pipe and Filters Notes: Inspired by the old UNIX permuted index
Cat data | permuteLines | sort

20. KWIC: Comparison

21. KWIC: Comparison Notes: Shared Data ADT/OO Implicit Invocation
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
Good at reuse and change in algorithm, modularity; however stuck with lowest level data transmission involving reparsing overhead

22. 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

23. 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:
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

24. 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
X-Y Wvfm
Accumulate Wvfm

25. Instrum. Software: OO Model Limitations
No overall model of how the types fit together
Led to confusion about partitioning the functionality
Should measurements be associated with data type of what is being measured? Or represented externally
Which objects should the interface interact with?

26. Instrum. Software: A Layered Model
Hardware
Digitization
Visualization
User Interface

27. 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

28. 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?

29. Instrum. Soft: Modified Pipe and Filter Model
Notes
Performance problems – waveforms are large; copying is expensive
Different speed of the different filters
Solution several types “colors” of pipes; one copies, one doesn’t
Speed handled by pipelining

30. Traditional Compiler Lexical analysis Syntax Analysis
Semantic Analysis
Optimization
Code Generation
Modified with globally accessible symbol table

31. Modern Compiler

32. Canonical Compiler Revisited

33. 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

34. Layered Design with Different Styles

35. Layered Design with Different Styles
Levels 1-3 were Object-oriented
Levels 4 and 5 were primarily respository (database) models

36. Rule Based Systems

37. Blackboard model: Hearsay II (speech processing)

38. Evolution of Software Engineering
What is engineering?
Phrases in answers:
Creating cost-effective solutions
… to practical problems …
… by applying scientific knowledge …
… building things …
… in the service of mankind …
Applied science for practical problems

39. 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.

40. Cloud computing Software as a service.

42. SaaS vs PaaS vs IaaS .

43. Evolution of an Engineering Discipline