CSCE 742 Software Architectures Lecture 2 b Introductory

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

Overview Last Time n n n What is Software Architecture? What do you already know? Architectural styles On last Time’s Slides(what we didn’t get to) n KWIC case study New n Other Case studies What do you know? n n – 2– What is the waterfall Model? What is the spiral model? CSCE 742 Summer 2016

Architectural Styles l Dataflow Systems n n Batch- sequential Pipes and filters l Call-and-Return Systems n n n Main program and subroutine OO systems Hierarchical layered systems l Independent Components n n Communicating processes Event driven systems l Machines n n Interpreters Rule-based systems l Repositories - Data-centered systems n n n – 3– Databases Hypertext Systems Blackboards 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(Saa. S) (4043) CSCE 742 Summer 2016

Architectural Case Studies l Key word in context l Instrumentation Software l Compilers l Layered Design with Different Styles for the Layers l Interpreter using Different Idioms for Components l A Blackboard – 4– CSCE 742 Summer 2016

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/Mod. Prob/KWIC. html – 5– CSCE 742 Summer 2016

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/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 Summer 2016

Case Study: Key word in context Example: SC Clerk of Courts (1985 project) One line n Assault and battery with intent to kill Permuted yields n n n n Assault and battery with intent to kill. Assault and battery intent to kill. Assault and battery with intent to Then sorted yields n n – 7– and battery with intent to kill. Assault and … So “assault and battery” could be found by looking up either keyword “assault” or “battery” CSCE 742 Summer 2016

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 $ ptx < input_file … in most states, an /a more serious or "aggravated" /("tort") cases involving assault/battery is committed when assault/battery occurs when one: / 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#/ – 8– CSCE 742 Summer 2016

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", "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 – 9– CSCE 742 Summer 2016

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. – 10 – CSCE 742 Summer 2016

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 Summer 2016

KWIC: Main Program/Subroutine with Shared Data – 12 – CSCE 742 Summer 2016

KWIC: Main / Subroutine Notes: 1. Data is shared, common storage. This is + and – 2. Serious drawbacks: l l – 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 Summer 2016

KWIC: Abstract Data Types – 14 – CSCE 742 Summer 2016

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 n n Data Algorithm 4. Reuse better supported because modules make fewer assumptions about other modules. – 15 – CSCE 742 Summer 2016

KWIC: Implicit Invocation – 16 – CSCE 742 Summer 2016

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 l 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 n 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 Summer 2016

KWIC: Pipes and Filters – 18 – CSCE 742 Summer 2016

KWIC: Pipe and Filters Notes: 1. Inspired by the old UNIX permuted index 2. Cat data | permute. Lines | sort – 19 – CSCE 742 Summer 2016

KWIC: Comparison – 20 – CSCE 742 Summer 2016

KWIC: Comparison Notes: Shared Data n Not good at change in data or algorithm; efficient ADT/OO n Good at change in data and in reuse; efficient also Implicit Invocation n Good at change in algorithm; just register the new functions Pipe and Filter n – 21 – Good at reuse and change in algorithm, modularity; however stuck with lowest level data transmission involving reparsing overhead CSCE 742 Summer 2016

Case Studies l Key word in context l Instrumentation Software l Compilers l Layered Design with Different Styles for the Layers l Interpreter using Different Idioms for Components l A Blackboard – 22 – CSCE 742 Summer 2016

Case Study: Instrumentation 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 Summer 2016

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 Summer 2016

Instrum. Software: OO Model Limitations No overall model of how the types fit together Led to confusion about partitioning the functionality n n – 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 Summer 2016

Instrum. Software: A Layered Model Hardware Digitization Visualization User Interface – 26 – CSCE 742 Summer 2016

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 Summer 2016

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 Summer 2016

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 Summer 2016

Traditional Compiler Lexical analysis Syntax Analysis Semantic Analysis Optimization Code Generation Modified with globally accessible symbol table – 30 – CSCE 742 Summer 2016

Modern Compiler – 31 – CSCE 742 Summer 2016

Canonical Compiler Revisited – 32 – CSCE 742 Summer 2016

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 Summer 2016

Layered Design with Different Styles – 34 – CSCE 742 Summer 2016

Layered Design with Different Styles Levels 1 -3 were Object-oriented Levels 4 and 5 were primarily respository (database) models – 35 – CSCE 742 Summer 2016

Rule Based Systems – 36 – CSCE 742 Summer 2016

Blackboard model: Hearsay II (speech processing) – 37 – CSCE 742 Summer 2016

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 Summer 2016

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 algorithms and libraries and now class libraries, but these are components. – 39 – CSCE 742 Summer 2016