Lecture 2 Introductory Case Studies Topics Architectural Styles Key Word In Context (KWIC) Other...

Lecture 2Introductory Case Studies

Lecture 2Introductory Case Studies

TopicsTopics

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

January 15, 2009

CSCE 742 Software Architectures

– 2 – CSCE 742 Spring 09

OverviewOverview

Last TimeLast Time What is Software Architecture? What do you already know? Architectural styles

On last Time’s Slides(what we didn’t get to)On last Time’s Slides(what we didn’t get to) KWIC case study

NewNew Other Case studies

What do you know?What do you know? What is the waterfall Model? What is the spiral model?


Architectural StylesArchitectural Styles Dataflow SystemsDataflow Systems

Batch- sequential Pipes and filters

Call-and-Return SystemsCall-and-Return Systems Main program and subroutine OO systems Hierarchical layered systems

Independent ComponentsIndependent Components Communicating processes Event driven systems

MachinesMachines Interpreters Rule-based systems

Repositories - Data-centered systemsRepositories - Data-centered systems Databases Hypertext Systems Blackboards


Architectural Case StudiesArchitectural Case Studies Key word in contextKey word in context

Instrumentation Software Instrumentation Software

CompilersCompilers

Layered Design with Different Styles for the LayersLayered Design with Different Styles for the Layers

Interpreter using Different Idioms for ComponentsInterpreter using Different Idioms for Components

A Blackboard A Blackboard


Case Study: Key word in contextCase Study: Key word in contextIn 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.htmlhttp://www-2.cs.cmu.edu/People/ModProb/KWIC.html


Who is David Parnas anyway?Who is David Parnas anyway?

He is an ACM Fellow and a leader in the development of He is an ACM Fellow and a leader in the development of the field of Software engineering.the field of Software engineering.

http://www.acm.org/sigs/sigsoft/SEN/parnas.html

First work experience in industry (1969) led him to First work experience in industry (1969) led him to realize that the company was breaking things up into realize that the company was breaking things up into modules incorrectly; thus leading to greater modules incorrectly; thus leading to greater complexitycomplexity


Case Study: Key word in contextCase Study: Key word in contextExample: SC Clerk of Courts (1985 project)

One line Assault and battery with intent to kill

Permuted yieldsPermuted 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”


Case Study: Decomposition in KWICCase 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


KWIC: Design Considerations 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


KWIC: Software Arch. ConsiderationsKWIC: 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.


Architectural Approaches to KWICArchitectural 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.


KWIC: Main Program/Subroutine with Shared Data KWIC: Main Program/Subroutine with Shared Data


KWIC: Main / SubroutineKWIC: Main / Subroutine

Notes:

1. Data is shared, common storage. This is + and –

2. Serious drawbacks: Changes in data storage format affects all modules Changes in algorithm not well supported Enhancements not easily encorporated Not supportive of reuse


KWIC: Abstract Data Types KWIC: Abstract Data Types


KWIC: Abstract Data TypesKWIC: 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.


KWIC: Implicit InvocationKWIC: Implicit Invocation


KWIC: Implicit InvocationKWIC: Implicit InvocationNotes:

1. Shared data similar to solution 1.

2. Two differences in access model:1. Data accessed abstractly i.e., “as a list, or set”2. 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.


KWIC: Pipes and FiltersKWIC: Pipes and Filters


KWIC: Pipe and FiltersKWIC: Pipe and Filters

Notes:

1. Inspired by the old UNIX permuted index

2. Cat data | permuteLines | sort


KWIC: ComparisonKWIC: Comparison


KWIC: ComparisonKWIC: ComparisonNotes:Notes:

Shared DataShared Data Not good at change in data or algorithm; efficient

ADT/OOADT/OO Good at change in data and in reuse; efficient also

Implicit InvocationImplicit Invocation Good at change in algorithm; just register the new functions

Pipe and FilterPipe and Filter Good at reuse and change in algorithm, modularity; however

stuck with lowest level data transmission involving reparsing overhead


Case StudiesCase Studies Key word in contextKey word in context

Instrumentation SoftwareInstrumentation Software

CompilersCompilers

Layered Design with Different Styles for the LayersLayered Design with Different Styles for the Layers

Interpreter using Different Idioms for ComponentsInterpreter using Different Idioms for Components

A Blackboard A Blackboard


Case Study: Instrumentation SoftwareCase Study: Instrumentation Software

Software architecture developed at Tektronix to Software architecture developed at Tektronix to develop a “reusable system architecture” for develop a “reusable system architecture” for oscilloscopes.oscilloscopes.

What is an oscilloscope?What is an oscilloscope?

Once simple analog device, now complex digital Once simple analog device, now complex digital technology with complex software.technology with complex software.

Problems faced by Tektronix:Problems faced by Tektronix:1. Little reuse of software across different products2. Both hardware and interface requirements were rapidly

changing3. Performance problems increasing because of configuration

limitations

Goal: Develop new architecture for oscilloscopesGoal: Develop new architecture for oscilloscopes


Instrumentation Software: OO Model Instrumentation Software: OO Model

Focused on producing object-oriented model of the Focused on producing object-oriented model of the domaindomain

This produced a good model of the data involvedThis produced a good model of the data involved

Oscilloscope Object

Waveform

Max-min Wvfm X-Y Wvfm Accumulate Wvfm

…


Instrum. Software: OO Model LimitationsInstrum. Software: OO Model Limitations

No overall model of how the types fit togetherNo overall model of how the types fit together

Led to confusion about partitioning the functionalityLed 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?


Instrum. Software: A Layered ModelInstrum. Software: A Layered Model

Hardware

Digitization

Visualization

User Interface


Instrum. Software: A Layered ModelInstrum. Software: A Layered Model

This model was intuitively appealing since it partitioned This model was intuitively appealing since it partitioned up the functionality into well defined groups.up the functionality into well defined groups.

However, wrong model:However, wrong model:

main problem was that the boundaries of abstraction main problem was that the boundaries of abstraction enforced by the layers conflict with what was really enforced by the layers conflict with what was really needed.needed.

user interactions with the visualizations but real user interactions with the visualizations but real oscilloscopes must interact at several levelsoscilloscopes must interact at several levels


Instrum. Software: Pipe and Filter ModelInstrum. 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?


Instrum. Soft: Modified Pipe and Filter ModelInstrum. 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


Traditional CompilerTraditional Compiler

Lexical analysisLexical analysis

Syntax AnalysisSyntax Analysis

Semantic AnalysisSemantic Analysis

OptimizationOptimization

Code GenerationCode Generation

Modified with globally accessible symbol tableModified with globally accessible symbol table


Modern CompilerModern Compiler


Canonical Compiler RevisitedCanonical Compiler Revisited


Layered Design with Different StylesLayered Design with Different Styles

PROVOX system designed by Fisher ControlsPROVOX system designed by Fisher Controls

Level 1 – Process measurementLevel 1 – Process measurement

Level 2 – Process supervision – monitoring and Level 2 – Process supervision – monitoring and controlling level 1controlling level 1

Level 3 – Process management – plant automation, Level 3 – Process management – plant automation, management reports, optimization strategiesmanagement reports, optimization strategies

Level 4 – Plant Management – interactions; cost Level 4 – Plant Management – interactions; cost accounting, inventoryaccounting, inventory

Level 5 – Corporation Management – Order Level 5 – Corporation Management – Order proecessing/billingproecessing/billing



Levels 1-3 were Object-orientedLevels 1-3 were Object-oriented

Levels 4 and 5 were primarily respository (database) Levels 4 and 5 were primarily respository (database) modelsmodels


Rule Based SystemsRule Based Systems


Blackboard model: Hearsay II (speech processing)Blackboard model: Hearsay II (speech processing)


Evolution of Software EngineeringEvolution of Software Engineering

What is engineering?What is engineering?

Phrases in answers:Phrases in answers:

1.1. Creating cost-effective solutionsCreating cost-effective solutions

2.2. … … to practical problems …to practical problems …

3.3. … … by applying scientific knowledge …by applying scientific knowledge …

4.4. … … building things …building things …

5.5. … … in the service of mankind …in the service of mankind …

Applied science for practical problemsApplied science for practical problems


Traditional EngineeringTraditional Engineering

Design experience built up over the yearsDesign experience built up over the years

Key design parameters abstracted from problemsKey design parameters abstracted from problems

Design problem formalizedDesign problem formalized

Knowledge codifiedKnowledge codified

Handbooks of DesignHandbooks of Design

Well there are no handbooks of design for software.Well there are no handbooks of design for software.

There are algorithms and libraries and now class There are algorithms and libraries and now class libraries, but these are components.libraries, but these are components.


Evolution of an Engineering DisciplineEvolution of an Engineering Discipline

Lecture 2 Introductory Case Studies Topics Architectural Styles Key Word In Context (KWIC) Other...

Documents

Transcript of Lecture 2 Introductory Case Studies Topics Architectural Styles Key Word In Context (KWIC) Other...