Topic

1. Topic Architectural Patterns – Review of Patterns

2. What is a Pattern • A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and represents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate • Buschmann, F. et al, Pattern Oriented Software Architecture – Volume1, Wiley, 1996

3. Pattern – Three-part Schema Context A situation giving rise to a problem Problem Pattern The recurring problem arising in that context Solution A proven solution of the problem

4. Patterns – Three Categories Architecture Design Implementation Refined Idiom

5. Architectural Patterns Layers Pipes and Filters Blackboard Mud to Structure Broker Distributed Systems Model-View-Controller Presentation-Abstraction-Control Interactive Systems Microkernel Reflection Adaptive Systems

6. Mud to Structure

7. Mud to Structure Layered Architectural Style

8. Layers The layers architectural pattern helps to structure application that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction

9. Layers Implementing protocols Conceptually different issues split into separate, interacting layers Functionality decomposed into layers; helps replace layer(s) with better or different implementation

10. Layers – 3 part schema

11. OSI 7-Layer Model Application Provides miscellaneous protocols for common activities Layer 7 Presentation Structures information and attaches semantics Layer 6 Provides dialog control and synchronization facilities Session Layer 5 Transport Breaks messages into packets and guarantees delivery Layer 4 Selects route from sender to receiver Network Layer 3 Detects and corrects errors in bit sequences Data Link Layer 2 Transmits bits: velocity, bit-code, connection etc. Physical Layer 1

12. Layers Class Layer J • Collaborators • Layer J-1 • Responsibility • Provides services user by Layer J+1 • Delegates subtasks to Layer J-1 Main characteristic is services of Layer J are only used by Layer J+1 No further direct dependencies between layers Each layer may be further composed of many components

13. Layers Client Layer N Layer N-1 Layer 1

14. Layers - Detailed

15. Dynamics • Scenario I • Top Down communication • Client issues a request to Layer N • Layer N, cannot carry out the request on its own, it calls Layer N-1 • N-1 to N-2 till Layer 1 is reached

16. Dynamics • Scenario II • Bottom Up communication • Chain of actions starts from Layer 1 • Translates events to internal format and reports to Layer 2 • Notifications flow till the topmost layer and then processed

17. Dynamics • Scenario III • Top Down Communication • Request may not reach the bottom most layer

18. Dynamics • Scenario IV • Bottom Up Communication • Request may not reach the top most layer

19. Dynamics Layer N Layer N Layer N-1 Layer N-1 Layer 1 Layer 1 • Scenario V • Involves two stacks communication with each other

20. Implementation Steps

21. 1: Define abstraction criteria • Use various paradigms to arrive at an abstraction criteria • Degree of customization for specific domains • Degree of conceptual complexity • An Example [Ordered from Top to Bottom]– • User-visible elements • Specific Application Modules • Common Service Levels • OS Interface Level • Hardware

22. 2: Determine the no. of abstraction levels Typically each abstraction level is one layer Map the abstraction levels to layers; one-one may not be as obvious Use mechanisms to keep number of layers to optimum number Too Few Layers  Can Result in Poor Structure Too Many Layers  Impose Unnecessary Overhead

23. 3: Name the layers and assign tasks Use a top down or bottom up approach to assign tasks Requires experience to achieve this

24. 4: Specify the services Strict separation of layers No component should spread over two layers Inverted pyramid of use

25. 5: Refine the layering Iterate to arrive at the best possible number and functionality of layers Define components and services and impose structure of layers should be avoided

26. 6: Specify an interface for each layer Use a black box approach Layer N does treats Layer N-1 as a black box

27. 7: Structure individual layers Focus should be on proper relationships between layers Individual layers should not be a chaos Structure the individual layers thru decomposition Make use of other patterns (bridge, strategy) Bridge Pattern  Supports multiple implementations of services provided by a layer Strategy Pattern  Supports Dynamic exchange of algorithms used by a user

28. 8:Specify communication bet. Adja. layers Use of push pull mechanism Use of call backs

29. 9: Decouple adjacent layers Lower layer is not aware of higher layer Higher layer is aware of lower layer Changes in Layer J can ignore the presence and identity of Layer J+1 [ Suitable for Top-up communication] Use of call backs

30. 10: Design an error handling strategy Define an efficient strategy Handling may be expensive – errors need to propogate

31. Variants Relaxed Layered System Layering Through Inheritance

32. Benefits Reuse of layers Support for standardisation Dependencies are kept local Exchangeability

33. Liabilities Cascades of changing behaviour Lower efficiency Unnecessary work Difficulty in establishing the correct granularity

34. Known Uses Virtual Machines APIs Information Systems Windows NT Find (at least 2) more popular uses and document them

35. Layers

36. Layers Quick Reference Class Layer J • Collaborators • Layer J-1 • Responsibility • Provides services user by Layer J+1 • Delegates subtasks to Layer J-1 Layer N Layer N Layer N-1 Layer N-1 Layer 1 Layer 1