Lecture 2b Introductory Case Studies

1
Lecture 2bIntroductory Case Studies

CSCE 742 Software Architectures

• Topics
• Architectural Styles
• Key Word In Context (KWIC)
• Other Cases Studies
• Evolution of Software Engineering

May 10, 2017
2
Overview

• Last Time
• What is Software Architecture?
• What do you already know?
• Architectural styles
• On last Times Slides(what we didnt 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)

• 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
• http//www-2.cs.cmu.edu/People/ModProb/KWIC.html

6
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

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
• 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
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 lt 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
• 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 doesnt
• 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

• .

https//www.ibm.com/developerworks/cloud/library/c
l-cloudservices3saas/
41
http//cloudacademy.com/blog/aws-reinvent-saas-des
ign/
42
SaaS vs PaaS vs IaaS

• .

https//kevinfielder.files.wordpress.com/2012/06/n
ew-picture.png
43
Evolution of an Engineering Discipline