1 / 40

Lecture 2 Introductory Case Studies

Lecture 2 Introductory Case Studies. CSCE 742 Software Architectures. 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?

baby
Download Presentation

Lecture 2 Introductory Case Studies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lecture 2Introductory Case Studies CSCE 742 Software Architectures • Topics • Architectural Styles • Key Word In Context (KWIC) • Other Cases Studies • Evolution of Software Engineering January 15, 2009

  2. 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? • What is the waterfall Model? • What is the spiral model?

  3. 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 oflines, each line is an ordered set of words, and each word is an orderedset of characters. • Any line may be ``circularly shifted'' by repeatedlyremoving the first word and appending it at the end of the line. • TheKWIC index system outputs a listing of all circular shifts of all lines inalphabetical 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

  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: • Performance: Both space and time. • Reuse

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

  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 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. Evolution of an Engineering Discipline

More Related