1. Architectural Styles Acknowledgement: some slides from: Software Architecture: Foundations, Theory, and Practice; R. Taylor, N. Medvidovic, E.Dashofy

2. Common styles Traditional, language- influenced u Main program and subroutines u Object-oriented Layered u Virtual machines u Client-server Data-flow styles u Batch sequential u Pipe and filter Shared-state u Blackboard u Rule based Interpreter u Interpreter u Mobile code Implicit invocation u Event-based u Publish-subscribe Peer-to-peer

3. How Do You Design? 3 Where do architectures come from? Method 1)Efficient in familiar terrain 2)Not always successful 3)Predictable outcome (+ & - ) 4)Quality of methods varies Creativity 1)Fun! 2)Fraught with peril 3)May be unnecessary 4)May yield the best

4. Creativity u Enhance your skillset u Provide new tools Method u Focus on highly effective techniques (architectural patterns, styles) Develop judgment: when to develop novel solutions, and when to follow established method 4

5. Typical Engineering Design Process Feasibility stage: identifying a set of feasible concepts for the design as a whole Preliminary design stage: selection and development of the best concept. Detailed design stage: development of engineering descriptions of the concept. Planning stage: evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement. 5

6. Potential Problems If the designer is unable to produce a set of feasible concepts, progress stops. As problems and products increase in size and complexity, the probability that any one individual can successfully perform the first steps decreases.  As complexity increases or the experience of the designer is not sufficient, alternative approaches to the design process must be adopted.  Parallel, incremental,.. 6

7. The beast you fight: Complexity A complex system can no longer be made by a single person A very complex system can no longer be comprehended by a single person How to tackle complexity?

8. The Tools of “Software Engineering 101” Abstraction u Abstraction(1): look at details, and abstract “up” to concepts u Abstraction(2): choose concepts, then add detailed substructure, and move “down” Example: design of a stack class Separation of concerns 8

9. Abstraction and the Simple Machines What concepts should be chosen at the outset of a design task? One technique: Search for a “simple machine” u that serves as an abstraction of a potential system that will perform the required task u a plausible first concept of how an application might be built. u Most application domains have their common simple machines. 9

10. Simple Machines 10 DomainSimple Machines GraphicsPixel arrays Transformation matrices Widgets Abstract depiction graphs Word processingStructured documents Layouts Process controlFinite state machines Income Tax Software Hypertext Spreadsheets Form templates Web pagesHypertext Composite documents Scientific computing Matrices Mathematical functions BankingSpreadsheets Databases Transactions

11. Choosing the Level and Terms of Discourse Any attempt to use abstraction as a tool must choose a level of discourse, and once that is chosen, must choose the terms of discourse. Alternative 1: initial level of discourse is one of the application as a whole (step-wise refinement). Alternative 2: work, initially, at a level lower than that of the whole application. u Once several such sub-problems are solved they can be composed together to form an overall solution Alternative 3: work, initially, at a level above that of the desired application. u E.g. handling simple application input with a general parser. 11

12. Separation of Concerns Subdivision of a problem into (hopefully) independent parts. u Enforce one responsibility per module difficulties arise when the issues are either actually or apparently intertwined. u Separations of concerns frequently involves many tradeoffs u Total independence of concepts may not be possible. Key example from software architecture: separation of components (computation) from connectors (communication) 12

13. At a higher level Treat individual aspects of a problem separately --- the aim, again, master complexity Separation in time / space u eg do requirements analysis before design u creative design in the morning, meetings in afternoon u do necessary learning and study during the week, explore personal interests on weekends Separation by concerns u eg deal with correctness, then deal with efficiency Separation by views u eg data flow through a system, control/decision making within system concurrency and synchronization, timing restrictions of a real time system

14. Google-like problem: process a huge collection of documents (Web-pages) [Distributed] Grep: Produce a list of documents that contain a certain word. Count of URL Access Frequency: Process logs of web page requests and output the number of times each of them has been accessed. Reversed Web-Link Graph: For a list of web pages produce the set of links that point to these pages. Term-Vector per Host: A N-term vector summarizes the most N frequent words that occur in a document or a set of documents as a list of pairs. The goal is to produce the term vector for all domain hosts. Inverted Index: For each word, produce the list of documents where it appears. Common styles Traditional, language- influenced u Main program and subroutines u Object-oriented Layered u Virtual machines u Client-server Data-flow styles u Batch sequential u Pipe and filter Shared-state u Blackboard u Rule based Interpreter u Interpreter u Mobile code Implicit invocation u Event-based u Publish-subscribe Peer-to-peer

15. Google’s MapReduce

16. When There’s No Experience to Go On… The first effort you should make in addressing a novel design challenge is to attempt to determine that it is genuinely a novel problem. Basic Strategy u Divergence – shake off inadequate prior approaches and discover/admit a variety of new ideas that offer a potentially workable solution u Transformation – combine analysis and selection of these potential ides. New understanding and changes to the problem statement u Convergence – select and further refine ideas Repeatedly cycling through the basic steps until a feasible solution emerges. 16

17. Analogy Search Examine other fields and disciplines unrelated to the target problem for approaches and ideas that are analogous to the problem. Formulate a solution strategy based upon that analogy. A common “unrelated domain” that has yielded a variety of solutions is nature, especially the biological sciences. u E.g., neural networks 17

18. Brainstorming Technique of rapidly generating a wide set of ideas and thoughts pertaining to a design problem u without (initially) devoting effort to assessing the feasibility. Brainstorming can be done by an individual or, more commonly, by a group. Problem: A brainstorming session can generate a large number of ideas… all of which might be low-quality. Chief value: identifying categories of possible designs, not any specific design solution suggested during a session. 18

19. “Literature” Search Examining published information to identify material that can be used to guide or inspire designers Digital library collections make searching much faster and more effective u IEEE Xplore u ACM Digital Library u Google Scholar The availability of free and open-source software adds special value to this technique. 19

20. Morphological Charts The essential idea: u identify all the primary functions to be performed by the desired system u for each function identify a means of performing that function u attempt to choose one means for each function such that the collection of means performs all the required functions in a compatible manner. The technique does not demand that the functions be shown to be independent when starting out. Sub-solutions to a given problem do not need to be compatible with all the sub-solutions to other functions in the beginning. 20

21. Removing Mental Blocks If you can’t solve the problem, change the problem to one you can solve. u If the new problem is “close enough” to what is needed, then closure is reached. u If it is not close enough, the solution to the revised problem may suggest new venues for attacking the original. 21

22. Controlling the Design Strategy Exploring diverse approaches u Potentially chaotic u  care in managing the activity Identify and review *critical* decisions Relate the costs of research and design to the penalty for taking wrong decisions Insulate uncertain decisions Continually re-evaluate system “requirements” in light of what the design exploration yields 22