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 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 • 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)

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 • $ 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 • 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 • . https://www.ibm.com/developerworks/cloud/library/cl-cloudservices3saas/

41. http://cloudacademy.com/blog/aws-reinvent-saas-design/

42. SaaS vs PaaS vs IaaS • . https://kevinfielder.files.wordpress.com/2012/06/new-picture.png

43. Evolution of an Engineering Discipline