1 / 42

Architectural Styles 1

Dive into software architectural styles and designs, focusing on reliability and availability. Explore various methodologies and theories while examining components, connectors, and constraints. Learn through real-world examples and industry insights.

bernardkent
Download Presentation

Architectural Styles 1

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. Images below – Homage to Magritte, in a way… Architectural Styles 1 CSSE 377 Software Architecture and Design 2Steve Chenoweth, Rose-Hulman InstituteWeek 2, Day 3, September 15, 2011 And this is not a filter!

  2. Right – The real Magritte. What does “This is not a pipe” mean, Rene? Today • First biweekly quiz from Tuesday – go over • Architectural styles, Part 1 – this • Relates strongly to software reliability/availability, and the other QA’s • We’ll talk about these thru slide 28 today. • More details – read the article case studies! • Tonight – HW 2 • Project 2 – • Progress reports: We’ll discuss in class the issues you’ve come up with, trying to test your system’s availability over since Tuesday. • Time to work on Project 2 in class • Friday, 9/16 (tomorrow), 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. • Policy clarification – • Late = significant points off, unless previously negotiated.

  3. First biweekly quiz - feedback • Look at the ones you missed! • “Key” is now out on course website, under Quizzes • Grading scale (“out of” 100, could get 111): • Counted # 3 as 2 pts each part (poss 12) • Counted all the others as 11 if full credit () • Let’s go over a couple in class 3. Performance scenarios 6. Architecture methodology • See next slide  • We want to be at “models and theories”

  4. Top: The real person shown here is Denzil Biter, City Engineer for Clarksville, TN. See www.cityofclarksville.com/ cityengineer/. “Here’s a great war story from the 1B project -- Impossible, but true!” Cirque du Soleil aerial contortionist is Isabelle Chasse, from http://www.montrealenespanol.com/quidam.htm Astronomer documenting observations. From www.astro.caltech.edu/ observatories/palomar/ faq/answers.htm. Folklore Ad hoc solutions The “Novelty Circle” of engineering; or, “Hey, where’s my needle in this haystack?” Codification New problems(novelty and nefarious outside forces) Boulder climber from www.gtonline.net/community/ gmc/boulder/pecqueries.htm Models & theories Image from www.sturdykidstuff.com/ tables.html “Yikes!” Improved practice Background is Claude Monet’s Meule, Soleil Couchant, 1891; Museum of Fine Arts, Boston Figure derived from Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan. Prentice Hall, 1996, ISBN 0-13-182957-2. Am I architecting software? Why am I architecting software? Image from www.reg.ufl.edu/ suppapp-splash.html.

  5. Architectural Styles Acknowledgement: • Some of the material in these slides is taken from “An Introduction to Software Architecture” by Garlan and Shaw, http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf. David Garlan and Mary Shaw, from their home pages http://www.cs.cmu.edu/~garlan/ and http://spoke.compose.cs.cmu.edu/shaweb/.

  6. What is an Architectural Style?

  7. What is a Software Architectural Style? Architectural Style = Components + Connectors + Constraints  Primarily, the dynamics of the design • Components: computational elements • Connectors: interactions between components • Constraints: how components and connectors may be combined

  8. Questions About Architectural Styles • What is the design vocabulary? • What are the allowable patterns? • What is the underlying computational model? • What are the essential invariants? • What are common examples? • What are advantages and disadvantages? • What are common specializations?

  9. Today’s styles (more tomorrow) Garlan & Shaw’s TOC: • Call and Return • Data Abstraction • Implicit Invocation • Pipe and Filter • Layered … with examples! (Slides 31+)

  10. Main One Two Foo Bar Three Call and Return • Basically, this is application of a “divide and conquer” systems theory. • “I’ll design and code Main and One, you want to take Two and Three? Then we’ll have another look at Foo and Bar…” • Most common style? • Fits with organizational considerations! • Like calling a sequence of functions.

  11. Call and Return Properties • Components are subroutines • Connectors are invocations • Heuristic: Cycles (recursion) are discouraged • Clearest when subroutines (or whatever the boxes mean) are called once to do “something” • Heuristic: Multitasking is discouraged • Easier to follow “what happens next” • Usually synchronous “call and return” message style • Heuristic: Try to follow an organized pattern of calling subroutines (like hierarchical). • Invariants? Not a lot of guarantees about how data is manipulated as it moves through the system. Note: “Invariants” = architectural principles that are true for this style, especially in regard to maintaining integrity of data.

  12. Call and Return Example • Commonly seen as a way to organize large systems like this. • Gives a basic way to control coupling and cohesion. • Down in the details, usually you need layers or abstraction (OO) to keep complexity down. Example is LDAP (Lightweight Directory Access Protocol) system, UC Berkeley. From http://softwareengineeringnotes.blogspot.com/2007/07/call-and-return-architecture.html.

  13. Data Abstraction (Object Oriented)

  14. Data Abstraction Properties • Components are objects - act as managers of resources • Connectors are function (method) invocations • Invariant 1: object maintains integrity of its representation • Invariant 2: representation is hidden from other objects

  15. Data Abstraction Advantages • May change representation without affecting clients • Facilitates decomposition of problems • Objects that mirror real-world entities will evolve slowly

  16. Data Abstraction Disadvantages • Must know identity of object in order to interact with it • Our next style fixes that! • Side effects: changes caused by method calls may propagate to clients • Example – a change in the number of parameters you need to pass

  17. Register interest in events Foo Bar Event 1 Event 2 Event 3 ... Notification of events Implicit Invocation (Callback) Announcement of events

  18. Implicit Invocation Properties • Components are modules with: • procedures • events that are announced • events of interest • Invariant: announcers of events do not know which components are registered with those events

  19. Implicit Invocation Advantages • Reuse: any component can be introduced by registering it for appropriate events • Evolution: components may be replaced without affecting other interfaces

  20. Implicit Invocation Disadvantages • Control: no way to know what will happen after event is announced • Data: may lead to performance problems • Correctness: meaning of procedure is context dependent

  21. Implicit Invocation Example • Publisher-Subscriber systems – used for event management, and more: Managed System S1 P1 DB Connection to Broker Connection to Broker Subscriptions Services Provided Web Client Subscription Broker Architecture S2 Subscription Distribution Connection to Broker Subscriptions Managed System Another System S3 P2 Connection to Broker Connection to Broker Services Provided Subscriptions S’s = subscribers to information. P’s = providers of information. Think RSS Feed, or Object Request Brokers like CORBA.

  22. Pipe and Filter

  23. Pipe and Filter Properties • Components apply local transformation to their inputs - filters • Connectors act as conduits - pipes • Invariant 1: filters must be independent • Invariant 2: filters do not know their neighbors

  24. Pipe and Filter Examples • Common Examples • Unix shell scripts • Compilers • How you translate the data coming & going from an application (often using 3rd party products) • Work flow manager – has a supervisory layer above the pipes and filters controls the flows of data • Specializations • Pipelines: linear structures • Bounded pipes: restrict amount of data • Typed pipes: data must be of certain type

  25. Pipe and Filter Advantages • Behavior is just composition of filters • Support reuse -- just reconnect • Using standard I/F’s, can build out of off-the-shelf pieces • Easy to maintain and enhance • Permit analysis - throughput, deadlock • Support concurrency • The filters can hand-off individual records, vs. whole files. Or better… • This is roughly how router connections on the Internet work, sometimes with only ~ 1-bit delays per box (like for ATM). • Two years ago in 377, teams built pipe and filter systems and had a speed contest. The winner converted a megabyte spreadsheet into XML in two seconds!.

  26. Pipe and Filter Disadvantages • Often lead to batch processing • What’s that? Programs in each stage run to completion before the next one starts. • Note that “batch” is legitimately how server maintenance is done – like backups and DB updating after hours, with checkpoints in the processes between steps • May be hard to coordinate streams • May force lowest common denominator for transmission • On one computer – a memory hog(how would you fix that?) • What do you do when there’s an error? • Can you debug the problem? • Can you backtrack for recovery?

  27. U p C v Layered

  28. Layered Properties • Components often implement a virtual machine for upper layers • Connectors defined by protocols between layers • Quasi-invariant: Layers often only interact with neighbors

  29. Layered Advantages • Abstraction: separation of concerns • Evolution: changes to one layer only affect neighboring layers • Reuse: layers have strong interfaces

  30. Layered Disadvantages • Some systems are hard to partition this way • Performance may require closer coupling between upper and lower layers • Hard to find the right levels of abstraction for all features

  31. More Complex Examples…  See Garlan & Shaw’s article (Case Studies) for more info on each of these.

  32. KWIC – Call and Return

  33. Key Word in Context (KWIC) The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be "circularly shifted'' by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order. -- David Parnas, 1972. He’s still around – see his profile at http://sigsoft.org/SEN/parnas.html.

  34. Input: descent of man the ascent of man the old man and the sea Output: the ASCENT of man DESCENT of man descent of MAN the ascent of MAN the old MAN and the sea the OLD man and the sea the old man and the SEA KWIC Example

  35. KWIC – Data Abstraction

  36. KWIC – Implicit Invocation

  37. KWIC – Pipe and Filter

  38. Oscilloscope • Sample electrical signals • Display pictures (traces) • Perform measurements

  39. Oscilloscope – Data Abstraction

  40. Oscilloscope – Layered

  41. Oscilloscope – Pipe and Filter

  42. Oscilloscope – Modified Pipe and Filter

More Related