1. CPSC 410: Software Architectural Style (Part I) By the end of this lecture, you will be able to: list various software architectural styles describe advantages and disadvantages of call-and-return and data-flow (sub-)styles be able to select and apply one of these styles

2. 2 Architectural style (Buildings) 18th Century Georgian Architecture “Old Corner Bookstore” Boston MA Early Gothic Architecture Notre Dame, Paris

3. 3 Styles and patterns Identifying styles (and patterns) can help codify and share knowledge/expertise Architectural Styles [Shaw and Garlan, Software Architecture, Prentice Hall 96] Design Patterns [Gamma, Helm, Johnson, Vlissides, Design Patterns, Addison Wesley 95] [Buschmann et. Al, Pattern-oriented Software Architecture: A System of Patterns, John Wiley & Sons 96] Code Patterns [Coplien, Advanced C++ Programming Styles and Idioms, Addison-Wesley 91]

4. 4 Architectural styles A style consists of: a set of component types (e.g., process, procedure) that perform some function at runtime a topological layout of the components showing their runtime relationships a set of semantic constraints a set of connectors (e.g., data streams, sockets) that mediate communication among components Styles provide a framework on which to base design From Chapter 5, Software Architecture in Practice, p. 94

5. 5 A catalog of architectural styles Today Next Time

6. 6 Example System: KWIC The KWIC index system accepts: an ordered set of lines each line is an ordered set of words each word is an ordered set of characters Every line is "circularly shifted" and copied by: repeatedly removing the first word appending it at the end of the line Outputs a listing of all circular shifts of all lines in alphabetical order “On the Criteria To Be Used in Decomposing Systems into Modules” –David Parnas

7. 7 KWIC Example Input: bar sock car dog town fog Output: bar sock car dog dog car fog town sock bar town fog Four steps: Input Circular shift Alphabetize Output Circular shift positions: 1 5 10 14 18 23 Alphabetize: 1 10 14 23 5 18

8. 8 Design Considerations Changes in algorithm: line shifting can be performed … on each line as it is read from the input device on all the lines after they are read on demand when the alphabetization requires a new set of shifted lines Changes in data representation: circular shifts … can be stored explicitly implicitly (as index and offsets) Extra Features: Have the system eliminate circular shifts that start with certain noise words (such as "a", "an", "and", etc.). Make the system interactive allow the user to delete lines from original list and re-output alphabetized list Performance: Both space and time Reuse: To what extent can the components serve as reusable entities

9. 9 Call-and-Return style Goal: achieve modifiability and scalability Substyles: Main-program-and-subroutine Decompose program hierarchically. Each component gets control from its parent. Object-oriented

10. 10 Object-oriented sub-style Objects help achieve modifiability by encapsulating internal secrets from environment Access to objects is only through methods (constrained forms of procedure calls)

11. 11 Input: read lines and stores them in Text array (buffer), index records starting position of each line Circular shift: Creates an index of starting positions for circular shifts, stores these in Word index Alphabetizer: Takes the input from Text array and Word index, creates an index of shifts which are alphabetized

12. 12 Design Considerations Changes in algorithm: Somewhat, however explicit data structure limits possibilities “Show me your data structures and I’ll tell you your algorithm” – Fred Brooks Changes in data representation: Not possible, because data is made available explicitly to all components. Extra Features: Have the system eliminate circular shifts that start with certain noise words Medium, requires changes to existing component Make the system interactive Medium, requires changes to Alphabetizer Performance: Space: Good, data is shared Time: Bad, no concurrency Reuse: To what extent can the components serve as reusable entities Bad, explicit data representation dependencies

13. 13 Line storage: Exports operations for getting characters in different positions Circular shifter: function SHIFT(l,w,c) returns cth character in the wth word of the lth shift Alphabetizer: function ITH(i) returns lines in sorted order

14. 14 Design Considerations Changes in algorithm: Good, data is made available through fine-grained operations Example: Alphabetizer can compute lines “on-demand” saving work if we stop early Changes in data representation: Good, data is hidden behind interface Example: Line storage could keep information from disk Extra Features: Have the system eliminate circular shifts that start with certain noise words Medium, requires changes to existing component Make the system interactive Medium, may require Alphabetizer to interact with Line storage Performance: Space: Good, data can be shared through function calls Time: Bad, no concurrency Reuse: To what extent can the components serve as reusable entities Medium, explicit interface dependencies

15. 15 Data-Flow style Data-flow Batch Sequential Pipes and Filters components are independent programs each step runs to completion before the next starts each batch of data is transmitted as a whole between steps Classic data-processing approach Goals: achieve reuse and modifiability

16. 16 Pipe-and-Filter sub-style Incremental transformation of data by successive components Filters transform data using little contextual information and retain no state between instantiations Pipes are stateless and are used to move streams of data between filters A pipe’s source end connects to a filter’s output port; sink end connects to filter’s input port Ex. cat file | gawk ‘/.*/ { if (match($0,”;{}”)) print $0; }’ | wc

17. 17 Pipe-and-Filter substyle... Pipes and filters run non-deterministically until no more computations or transmissions are possible Ex. In Unix this means EOF +Simple to reason about, eases maintenance, enhances reuse, can easily enhance performance by parallelizing or distributing - Interactive apps are difficult, filters can’t cooperate to solve a problem

18. 18 Each component creates actual text representation for output to passes to next component Simple design, easy to understand

19. 19 Design Considerations Changes in algorithm: Good, as long as it doesn’t require sharing data Example: Alphabetizer can use any sorting routine Changes in data representation: Bad, data is passed explicitly as complete text Extra Features: Have the system eliminate circular shifts that start with certain noise words Good, easy to insert new component in pipeline Make the system interactive Bad, there is no stored intermediate representation Performance: Space: Bad, data must be copied Time: Good, components run in parallel Bad, copying takes time Reuse: To what extent can the components serve as reusable entities. Good, depends only on very common textual representation

20. 20 Heterogeneous Use Systems are generally built from multiple styles Three kinds of heterogeneity: Locationally heterogeneous: Some components in one style participate in another style Ex. A layer in a layered style is also a client in client-server architecture Components make use of other styles Simultaneously heterogeneous: its actually two different styles Ex. Client-Server Layered Style All components play simultaneous roles Hierarchically heterogeneous: a component of one style, when decomposed is structured according to another style Ex. A filter written using objects Complete encapsulation

21. 21 Key points from today Describe advantages and disadvantages of call-and- return and data-flow (sub-)styles Be able to select and apply the call-and-return or data-flow (sub-)styles Sample questions: Portability is important for the system being built, what style might you choose? Here are the requirements for a system x … sketch a pipe- and-filter architectural design for the system