1. 1 Architectural Patterns Yasser Ganji Saffar ganji@ce.sharif.edu

2. 2 What are patterns?  A pattern addresses a recurring problem that arises in specific design situations and presents a solution to it.  Patterns provide a common vocabulary and understandings for design principles  Patterns are a means of documenting software architecture  Patterns help you manage software complexity  Patterns help you build on the collective experience of skilled software engineers.

3. 3 Patterns Categories  Architectural Patterns  Design Patterns  Language Idioms

4. 4 Architectural Patterns  An architectural pattern expresses a fundamental structural organization schema for software system.  It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationship between them.

5. 5 Architectural Patterns Categories  From mud to structure Layers Pipes and Filters Blackboard  Interactive systems Model-View-Controller (MVC) Presentation-Abstraction-Controller (PAC)  Adaptable systems Microkernel Reflection  Distributed systems Broker

6. 6 Pattern Specification  Name  Also Known As  Example  Context A situation giving rise to a problem  Problem The recurring problem arising in that context  Solution  Structure Components Relationships  Dynamics Scenarios  Implementation  Variants  Known Uses  Consequences

7. 7 Layers  Helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction Core level Useful System Basic Utility

8. 8 Layers  Example: OSI 7-Layer Model Physical Application Data Link Network Transport Session Presentation

9. 9 Layers  Context: A large system that requires decomposition  Problem: A system whose dominant characteristic is a mix of low and high level issues, where high level operations rely on lower-level ones.

10. 10 Layers  Solution Structure your system into an appropriate number of layers and place them on top of each other Start at the lowest level of abstraction and move up to the top level of functionality

11. 11 Layers  Structure Class Layer J Responsibility Provides services used by Layer J+1 Delegates subtasks to Layer J-1 Collaborator Layer J-1

12. 12 Layers  Variants Relaxed layered system  More Performance & Flexibility  Less Maintainability  Can be used in infrastructure systems such as X Window System that are modified less than application systems and performance is more important than maintainability Layering through inheritance  A higher level inherits from a lower level implementation  Higher levels can modify lower layer services

13. 13 Layers  Known Uses Information Systems  4 layer architecture:  Presentation, Application logic, Domain layer, Database Virtual Machines  e.g. JVM translates Java bytecodes to machine- dependent codes APIs  An API is a layer that encapsulates lower layers of frequently-used functionality  e.g. C standard library on top of Unix Syscalls

14. 14 Layers  Advantages Portability Modifiability  Late source code changes do not ripple through the system Understandability & Maintainability  Similar responsibilities are grouped Reuse of layers Support for standardization  Clearly-defined and commonly-accepted levels of abstraction enable the development of standardized tasks and interfaces

15. 15 Layers  Disadvantages Lower performance Difficulty of establishing the correct granularity of layers  Too few layers → Lower reusability, changeability and portability  Too many layers → Complexity and overhead in the separation of layers

16. 16 Pipes and Filters  Provides a structure for systems that process a stream of data  Each processing step is encapsulated in a filter component  Data is passed through pipes between adjacent filters

17. 17 Pipes and Filters  Example Compilers Scanner Parser Code Generator Optimizer Program text Token stream Abstract syntax tree Assembly code Optimized code

18. 18 Pipes and Filters  Context Processing data streams  Problem You want to build a system that must process or transform a stream of input data The system has to be built by several developers The requirements are likely to change The global system task decomposes naturally into several processing stages

19. 19 Pipes and Filters  Solution Divides the task of a system into several sequential processing steps. These steps are connected by the data flow through the system Each processing step is implemented by a filter component Data source, data sink and filters are connected by pipes

20. 20 Pipes and Filters  Structure Class Filter Responsibility Gets input data Performs a function on its input data Supplies output data Collaborator Pipe

21. 21 Pipes and Filters  Structure Class Pipe Responsibility Transfers data Buffers data Synchronizes active neighbors (FIFO buffer) Collaborators Data Source Data Sink Filter

22. 22 Pipes and Filters  Structure Class Data Source Responsibility Delivers input to processing pipeline Collaborator Pipe

23. 23 Pipes and Filters  Structure Class Data Sink Responsibility Consumes output Collaborator Pipe

24. 24 Pipes and Filters  Variants Tee and Join pipeline systems  Filters with more that one input and/or more that one output

25. 25 Pipes and Filters  Advantages No intermediate files necessary Flexibility  By filter exchange  By recombination Reuse of filter components  Rapid prototyping Efficiency by parallel processing  If each filter in a pipeline produces and consumes data incrementally they can perform their functions in parallel

26. 26 Pipes and Filters  Disadvantages Sharing state information is expensive or inflexible Efficiency gain by parallel processing is often an illusion  Some filters consume all their input before producing any output  Context-switching between threads or processes is generally an expensive operation on a single processor machine Data transformation overhead  For example if our pipes can only transform ASCII data Error handling  Because pipeline components do not share any global data error handling is hard (stderr in Unix)

27. 27 Model-View-Controller  Divides an interactive application into three components.  Model contains core functionality.  View displays information to the user.  Controller handle user input.  View and Controller together comprise the user interface.

28. 28 Model-View-Controller  Context Interactive applications with a flexible human- computer interface  Problem Changes to the UI must be easy Supporting different “look and feel” standards or porting the UI should not affect code

29. 29 Model-View-Controller  Solution Model encapsulates core data and functionality. It is independent of specific output representation or input behavior View component obtains the data from the model and displays them to the user. There can be multiple views of the model. Each view has an associated controller component. Controllers receive inputs (from mouse, keyboard,…) and translates them to service requests for model or view When a user changes the model state via the controller of one view, all other views should reflect the changes

30. 30 Model-View-Controller  Structure Class Model Responsibility Provides functional core of the application Registers dependent views and controllers Notifies dependent components about data changes Collaborators View Controller

31. 31 Model-View-Controller  Structure Class View Responsibility Creates and initializes its associated controller Displays information to the user Implements the update procedure Retrieves data from the model Collaborators Controller Model

32. 32 Model-View-Controller  Structure Class Controller Responsibility Accepts user input as events Translates events to service requests for the model or display requests for the view Implements the update procedure if required Collaborators View Model

33. 33 Model-View-Controller

34. 34 Model-View-Controller  Variants Document-View  Relaxes the separation of view and controller  Sacrifices exchangeability of controllers  Document = Model in MVC

35. 35 Model-View-Controller  Known Uses MFC in Visual C++ User interface framework in Smalltalk ET++

36. 36 Model-View-Controller  Advantages Multiple views of the same model Synchronized views Pluggable views and controllers  UI objects can even be substituted at run-time Portability  Exchangeability of “look and feel”

37. 37 Model-View-Controller  Disadvantages Increased complexity Not all views are interested in every change propagated by the model Intimate connection between view and controller Close coupling of views and controllers to a model  Changes to model’s interface impact all views and controllers Inefficiency of data access in view Difficulty of using MVC with modern UI tools  Many high level tools define their own flow of control and handle some events internally

38. 38 Presentation-Abstraction-Control  PAC defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.  Every agent is responsible for a specific aspect of the application’s functionality and consists of three components: presentation, abstraction and control.

39. 39 Presentation-Abstraction-Control  Context Development of an interactive application with the help of agents  Problem Interactive systems can often be viewed as a set of cooperating agents.  Agents for human-computer interaction  Agents that maintain the data model  Agents for error handling  Agents for communicating with other systems

40. 40 Presentation-Abstraction-Control  Solution Structure the interactive application as a tree-like hierarchy of PAC agents.  Top-level PAC agent  Intermediate-level PAC agents  Bottom-level PAC agents Presentation component of agents provides the visible behavior of them Abstraction component maintains the data model Control component connects the Presentation and Abstraction components and provides the functionality for the agent to communicate with other PAC agents

41. 41 Presentation-Abstraction-Control Data repository Access to data View coordinatorSpreadsheet Pie chartBar chart Intermediate- level PAC agent Top-level PAC agent Bottom-level PAC agent

42. 42 Presentation-Abstraction-Control  Structure Class Top-level Agent Responsibility Provides the functional core of the system Controls the PAC hierarchy Collaborators Intermediate-level agent Bottom-level agent

43. 43 Presentation-Abstraction-Control  Structure Class Intermediate-level Agent Responsibility Coordinates lower- level PAC agents Composes lower-level PAC agents to a single unit of higher abstraction Collaborators Top-level agent Intermediate-level agent Bottom-level agent

44. 44 Presentation-Abstraction-Control  Structure Class Bottom-level Agent Responsibility Provides a specific view of the software or a system service, including its associated human-computer interaction Collaborators Top-level agent Intermediate-level agent

45. 45 Presentation-Abstraction-Control  Variants PAC agents as active objects  By using multi-threading all the agents can be active the same time PAC agents as processors  Agents located on different processes or on remote machines

46. 46 Presentation-Abstraction-Control  Advantages Separation of concerns  Different semantic concepts in the application domain are represented by separate agents Support for change and extension  Changes within the presentation or abstraction components of a PAC agent do not affect other agents in the system. Support for multi-tasking  Agents can be distributed easily to different threads, processes or machines

47. 47 Presentation-Abstraction-Control  Disadvantages Low efficiency  Overhead in agents communication Increased system complexity  Implementing every semantic concept with an agent  A sea of agents Complex control component  Its interface must be independent of internal details

48. 48 References  Buschmann F., et. al, “Pattern – Oriented Software Architecture”, John Willey & Sons, 1996  Brown K., “Crossing Chasms: The Architectural Patterns”  Shaw M., “Patterns for software architecture”, First annual conference on the pattern languages of programming, 1994  Schmidt D., “Inside Patterns”, 2000

49. 49 THE END