SEng 5861: Software Architecture

1. SEng 5861: Software Architecture Lecture 9 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

2. Topics for Today • Questions / Comments from Last Week • Project Phase III Questions / Examples • Architectural Patterns & Pattern Languages • Guest Lecture: Software Product Line Engineering SEng 5861 - Mike Whalen

3. Project Phase III Do this 1.Version History 2.Table of Contents 3.Introduction 4.1Purpose and Scope 4.2Audience 4.3Status 4.4Architectural Design Approach 5.Glossary 6.System Context 6.1System Environment 6.2Overview of Requirements 6.3System Scenarios 7.Architectural Forces 7.1Goals 7.2Constraints 7.3Architectural Principles 8.Architectural Views for Top-Level System • Pick Two views 9. Architectural Views for Subsystem • Pick Two Views 10.Appendices 10.1Appendix: Decisions and Alternatives 10.3Appendix: References Do this Refer to Phase II Do this Refer to Phase II Optional What do I do HERE? Do this SEng 5861 - Mike Whalen

4. How do I bound my (sub)system? • Several questions about what to call a subsystem and when is it architecturally interesting? • To make it concrete, I’ll pick on Ziad a little  SEng 5861 - Mike Whalen

5. Choosing a subsystem to analyze for Android • The Android SDK allows one to build applications for the Google Android phone platform • It is all in Java, so the SDK is a (large!) suite of Java classes that act as a framework for Android applications SEng 5861 - Mike Whalen

6. Choosing a subsystem to analyze for Android • View class is the base class for all GUI widgets • All controls, canvases, windows, etc. are derived from View. • Layout and composition is performed by ViewGroupsubclass • Question 1: Do Android Views (the View class and its descendents) form an architecturally interesting subsystem to analyze? • Question 2: Is it enough to look atthe View class and its descendents? SEng 5861 - Mike Whalen

7. Android Views: Interesting? • Q1: Yes. • Q2: No • The Android view architecture encompasses more than just the subclasses of the View class • Layout can be externalized to XML resources • View class can also process UI events generated by the platform (i.e. it also acts as controller) • Usually this event processing is performed by event listener classes that attach to views SEng 5861 - Mike Whalen

8. So which parts are interesting? • Do not describe all 50+ subclasses of View • Interesting parts (to me) are: • Top-level interface for view objects and how this allows a MVC-style architecture for the GUI • View compositing hierarchy – how are child views laid out and composed? • View creation: either programmatic or via the XML interface • Use of event listeners to specialize view event processing SEng 5861 - Mike Whalen

9. Which viewpoints are interesting? SEng 5861 - Mike Whalen

10. Which viewpoints are interesting? • Well, certainly functional • Depending on XML creation interface, • Deployment: The XML view descriptions are stored as separate resource files that must be bundled with the application. How does this work? • Development: describe the module structure for views and their dependencies to other portions of the Android API. SEng 5861 - Mike Whalen

11. Architectural patterns SEng 5861 - Mike Whalen

12. Architecture & Design Patterns • A design pattern is a solution to a problem that occurs repeatedly in a variety of applications • Documents both how problem is solved and (to some extent) why • Why is this idea problematic? • What is the rationale for the solution? • Solution (pattern) must be non-obvious SEng 5861 - Mike Whalen

13. SEng 5861 - Mike Whalen

14. Architecture & Design Patterns • Each pattern has a name • Use of each pattern has documented consequences • May be both positive and negative • When is a pattern “architectural”? • Short answer: it depends • Longer answer (in the form of a question): how central is it to the architecture being described? SEng 5861 - Mike Whalen

15. A Pattern Language • Describe a system in terms of interacting patterns • Focus is on describing relationships between patterns SEng 5861 - Mike Whalen

16. Patterns and Views SEng 5861 - Mike Whalen

17. Example: Layers Pattern Pattern: Layers Consider a system in which high-level components depend on low-level components to perform their functionality, which further depend on even lower-level components and so on. Decoupling the components in a vertical manner is crucial in order to support modifiability, portability, and reusability. On the other hand components also require some horizontal structuring that is orthogonal to their vertical subdivision. To achieve these goals, the system is structured into layers so that each layer provides a set of services to the layer above and uses the services of the layer below. Within each layers all constituent components work at the same level of abstraction and can interact through connectors. Between two adjacent layers a clearly defined interface is provided. In the pure form of the pattern, layers should not be by-passed: higher-level layers access lower-level layers only through the layer beneath. SEng 5861 - Mike Whalen

18. Layers • Examples: • Network stacks: OSI, TCP/IP • OS Organization • Virtual Machines • Robotics • Planning Systems • Avionics SEng 5861 - Mike Whalen

19. Indirection Layer • Provide a unified interface to a set of interfaces in a subsystem without damaging the generic form of the sub system. • Also called Façade pattern Image from: http://www.renaissance.co.il/ivbug/meeting87/Architecture%20and%20design%20patterns.ppt

20. Data and Layer Patterns SEng 5861 - Mike Whalen

21. Pipe and Filter Pattern Target Data Transformation Program Source Data … … … … SEng 5861 - Mike Whalen

22. Data Repository Blackboard usage is for splitting processing of complex problem into subtasks that can be simultaneously solved. A control client monitors & coordinates the blackboard Can be passive or active; passive repo stores data; active repo broadcasts changes in data to interested clients (Pub / Sub) Coordinator SEng 5861 - Mike Whalen

23. Adaptation Patterns Deferred Binding Patterns Generic Interface Patterns Language Interpretation-based patterns SEng 5861 - Mike Whalen

24. Microkernel SEng 5861 - Mike Whalen

25. Microkernel Pattern Mechanism implementing primitives Resource Policies Client Services SEng 5861 - Mike Whalen

26. Microkernel Pattern From: people.cs.uchicago.edu/~mark/51050/lectures/lecture.6/lecture.6.ps SEng 5861 - Mike Whalen

27. Reflection • Reflection allows runtime discovery of interfaces and dynamic calls to discovered services. • Built into programming languages • Java • Python • Ruby • Also built into middleware • COM/DCOM • CORBA SEng 5861 - Mike Whalen

28. Reflection & Modification • Some tools allow reflection interface to modify class or even language definitions • Re-program system on-the-fly! • These are often called Metaobject protocols • Easy to create derivative languages using this functionality SEng 5861 - Mike Whalen

29. Interceptor Pattern SEng 5861 - Mike Whalen

30. Language Patterns in More Detail SEng 5861 - Mike Whalen

31. User Interaction Patterns SEng 5861 - Mike Whalen

32. Model-View-Controller • Benefits • Supports independentupdate of GUI (view) and business logic (model) • Allows display ofsame data multiple ways • Better testability • Examples: Built into most object-oriented UI frameworks • Java, MFC (C++), Cocoa (Mac), .NET SEng 5861 - Mike Whalen

33. Presentation Abstraction Control SEng 5861 - Mike Whalen

34. Component Interaction Patterns Method Call / RPC Observer Notification Mechanisms for Response SEng 5861 - Mike Whalen

35. Component Interaction Patterns II SEng 5861 - Mike Whalen

36. Broker Pattern SEng 5861 - Mike Whalen

37. What Have We Learned? • Some Examples of Architectural Patterns • What a Pattern Language is • How a PL can be used to relate patterns SEng 5861 - Mike Whalen

38. Further Reading • Pattern-oriented Software Architecture: System of Patterns by Frank Buschmann et. al • Currently 5 volumes! • Grounded in examples of real systems SEng 5861 - Mike Whalen