Architectural Styles 2

1. Architectural Styles 2 CSSE 377 Software Architecture and Design 2Steve Chenoweth, Rose-Hulman InstituteWeek 2, Day 4, Thursday, Sep 16, 2011 Left – Model for the “repository” style of architecture is a warehouse. Half the battle is designing it so that the same lift truck can access anything you might need. The other half, perhaps, is knowing where that is! Fisheye image from www.moodleman.net/archives/202 .

2. Today • HW 2 – Tim will post HW comments in Angel dropbox. • More on arch styles – this • Bonus: a few examples of possible questions on the next biweekly quiz! • Project 2 – • Time to work on Project 2 in class • 11:55 PM – File a spreadsheet showing the “availability” of the part of the system you stressed, and how much you predict you can improve it. Also turn in your journal with a discussion of that spreadsheet – how you decided on the numbers, especially.

3. Acknowledgements • Some of the material in these slides is taken from “An Introduction to Software Architecture” by Garlan and Shaw.

4. Arch styles, continuing… Garlan & Shaw’s TOC: • Quick review of yesterday’s styles • New styles for today: • Repository • Interpreter • Distributed Processes • Domain Specific • State Transition Systems … and 1 more example

5. Main One Two Foo Bar Three Review from Yesterday Call and Return

6. Review from Yesterday Data Abstraction (Object Oriented)

7. Register interest in events Foo Bar Event 1 Event 2 Event 3 ... Notification of events Review from Yesterday Implicit Invocation (Callback) Announcement of events • Example implicit invocation biweekly quiz question: • Why does “filters not knowing their neighbors” imply easy evolution?

8. Review from Yesterday Pipe and Filter • Example pipe-and-filter biweekly quiz questions: • What does “often leads to batch processing” mean? • Suppose this whole system ran in one computer, and passed large images from filter to filter for processing. How would you modify its operation to save memory?

9. U p C v Review from Yesterday Layered • Example layered system biweekly quiz question: • Suppose you discover that the “Useful system” level has to communicate directly with the “core level” to handle errors. What would you need to do to be sure doing this didn’t mess up your system design?

10. C D New! Repositories (Database or Blackboard)

11. Repositories Repository Properties • Components: • Central data structure • Independent computational elements • Database: input stream selects processes • Blackboard: State of central data structure selects processes • Used for finding nondeterministic solutions • Has “knowledge base” vs DB at its center • Invariant: decisions are based on data on the shared blackboard Today’s quiz – Q 1

12. Repositories Repository Advantages/Disadvantages • Similar to Implicit Invocation style: • Knowledge sources don’t know ID’s, but • Control is driven by the blackboard • Context is important for reasoning • Usually complex interpretation is the goal

13. Repositories Repository – A Blackboard Example • Hearsay II (in Garlan & Shaw’s article) • Speech recognition • Input stream – speech signal • Blackboard – hypotheses about what was being said • Independent computing elements – opportunistically tried to reach higher level conclusions – like “If these words say ‘Welcome to Terre Haute.” then that could be a coherent sentence. Hearsay II’s blackboard architecture – from www.cs.cmu.edu/.../Soft_Arch/base.105.html .

14. Repositories Additional uses for blackboards Breaking complex cryptographic codes Sensory interpretation and analysis (such as computer vision) Command and Control Systems Surveillance Systems Workflow Processing Case-based reasoning Symbolic learning Data Fusion

15. Interpreters Interpreter

16. Interpreters Interpreter Properties • Components: • Interpretation engine • Memory containing pseudo-code • Control state of interpretation engine • Current state of program being simulated • Connectors: • Closely bound, with direct procedure calls and shared state. • Interpreter examples – See PLC! • Lisp and Scheme, etc. • Invariant? Details of the data manipulation are hidden by the high-level language. Today’s quiz – Q 2

17. Interpreters Interpreters – what you get Binary instructions for a virtual machine, often called bytecode, as is done in Lua, Python, Ruby, Smalltalk, and many other systems (the approach was popularized in the 1970s by the UCSD P-system and UCSD Pascal) A tree-like representation of the original program, such as an abstract-syntax tree, as is done for many prototype or educational interpreters A tokenized representation of the source program, similar to Tcl The characters of the source program, as was done in MINT and TRAC

18. Interpreters Interpreter Advantages/ Disadvantages • Superb end-user programmability and maintainability; supports dynamically changing capabilities. • Slower than “raw code” doing the same thing.

19. Distributed Processes Distributed Processes • SAP, as an example: • Each server has a “dispatcher” and a number of work processes • These vary, depending on resource needs • E.g., one may have only “dialog processes” and another may have just “background processing”.

20. Distributed Processes Distributed Processes • Often described in terms of their topology: • ring • star • Sometimes described in terms of communication protocols: • client/server • peer-to-peer • Heartbeat • Invariant? Physical isolation of functions goes with separation of responsibilities

21. Distributed Processes Distributed ProcessesAdvantages/ Disadvantages • Inherently flexible and reliable • Can be slow instead of fast! • Use data close to its source, or batch it • Keep “conversations” short • Maintenance of individual parts • What happens when you change 1 interface? • Reliability • Minimize the number of transactions

22. Distributed Processes Distributed Process Example – Client/Server • Like Web browser connected to a server… • What are good & bad features of that? PC Client Database Servers Application Servers Web Servers Each doing individual tasks PC Client Runs major applications Gets requested data Hands out Web pages A typical 4-tiered client-server system Clients “request services,” Servers “respond”.

23. Distributed Processes Distributed Process Example – Cloud (peer-to-peer) Issues – • Achieving scalability via distribution • Achieving availability via duplication • What’s “stateless vs stateful” From “Building cloud-ready, multicore-friendly applications, Part 1: Design principles,” at http://www.javaworld.com/javaworld/jw-03-2009/jw-03-multicore-and-cloud-ready-1.html?page=4. Today’s quiz – Q 3

24. Domain-Specific Arch Domain-Specific Styles The prototypical example of a refined style – transaction processing using a credit / debit card:

25. Domain-Specific Arch Domain-Specific Styles • Specific to a family of systems -- a product line • Some components are common, but may be implemented in different ways • Connections between common components are preserved across family

26. Domain-Specific Arch Domain-Specific Example - Transaction processing systems • Used in banking, retail, loading docks, etc. • Domain idea is that some activity of real value occurs and needs to be recorded. Usually, assets change hands: • You get money at a bank machine • You buy an iTune for your iPod • You checkout your groceries at Kroger’s • 60 refrigerators get loaded onto your store’s truck at the manufacturer’s warehouse Image from www.handiramp.com/dock_equipment.htm .

27. Domain-Specific Arch Domain-Specific Example - Transaction processing systems What quality attributes are important? • Performance – usually impacts productivity or customer patience. • Reliability – different meaning. Want all transactions to be “atomic.”* • Usually are distributed systems, with parts owned by different organizations. • Invariant: Guaranteed completion or roll-back of transactions * Famously, we want all the ACID properties in transactions: Atomicity, Consistency, Isolation and Durability. See, e.g., http://en.wikipedia.org/wiki/ACID. Today’s quiz – Q 4

28. Domain-Specific Arch Domain-Specific Example - Transaction processing systems • Example – Buying groceries at Kroger’s: PIN Pad Kroger’s Inventory system POS Register Store Gets VISA data Tracks item-level sales Scanner Records transaction VISA In-store processor Scans groceries Authorizes payment Supplies item info to POS, Updates inventory system POS = Point of Sale Kroger image from compulsivec.wordpress.com/2007/03/ .

29. State-Transition Sys State Transition Systems Remember formal methods? Here’s where a state diagram IS the design!

30. State-Transition Sys State Transition Systems • Set of states as components • Set of transitions between states, as connectors • Often built on hardware “events” • Good style for reactive systems • Invariant: The various “states” defined determine what can be done there.

31. State-Transition Sys State Transition System Example – Process Control • Use feedback or feedforward to control a process: Diagram from http://en.wikipedia.org/wiki/Feedback. Feedback image from http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-302Feedback-SystemsFall2002/CourseHome/, an MIT open course on feedback systems Today’s quiz – Q 5

32. Examples Again, taken from Garlan & Shaw’s Case Studies section.

33. Compiler – Pipe and Filter • A first try at compiler architecture – hand off the data from one step to the next, in “passes.”

34. Compiler – Modified Pipe and Filter • But the steps all use the common Symbol Table built during compilation, so need to have that large, shared area to update.

35. Compiler – Repository • And more improvements occur when the steps can interact, using rules to guide decisions … • Like whether you are trying to make a single block of object code out of one segment of source code. • Which leads to more of a repository style architecture.