Architectural Patterns: From Mud to Structure

Size: px

Start display at page:

Download "Architectural Patterns: From Mud to Structure"

Sabrina Baker
8 years ago
Views:

1 DCC / ICEx / UFMG Architectural Patterns: From Mud to Structure Eduardo Figueiredo

2 From Mud to Structure Layered Architecture It helps to structure applications that can be decomposed into group of tasks Pipes and Filters It provides a structure for systems that process a stream of data Blackboard It is useful for problems for which no deterministic solution is known

Filters It provides a structure for systems that process a stream of

3 Layers

4 Layers Architectural Pattern It organizes the system as groups of tasks Each group of task is at a particular level of abstraction (layer) Each layer is client of the lower layer provides services to the upper layer

particular level of abstraction (layer) Each layer is

5 Example of 7 Layers

6 Example of 3 Layers Presentation Layer Business Layer Data Layer

7 Benefits Reuse of layers Each layer embodies a well-defined abstraction with a documented interface Incremental Development A lower layer does not depend on upper layers Exchangeability A layer can be replaced by a semanticallyequivalent one

Development A lower layer does not depend on upper layers

8 Liabilities Lower efficiency Data have to be transferred through several layers (communication overhead) Difficulty of establishing the correct granularity of layers Which services go to each layer? Cascades of changing behavior Changes in one layer may requires updates to the others

correct granularity of layers Which services go to each layer?

9 Pipes and Filters

10 Pipes and Filters This pattern provides a structure for systems that process a stream of data It defines two roles Pipes: data is passed through these components Filters: processing steps are encapsulated in filter components Recombining filters allows you to build families of related systems

through these components Filters: processing steps are encapsulated in

11 Architectural Pattern Solution It divides the tasks of a system into several processing steps (filters) These steps are connected by the data flow (pipes) Output data of one step is the input data of another step The sequence of filters combined by pipes is called pipeline

data flow (pipes) Output data of one step is the input data of

12 Example of Pipes and Filters Input: Invoices and Payments Output: Receipts and Reminders Invoices Payments Issue Receipts Receipts Read Issued Invoices Identify Payments Find Due Payments Reminders Issue Payment Reminders

Payments Issue Receipts Receipts Read Issued Invoices

13 Benefits Flexibility by filter exchange Filters have a simple interface and a well-defined responsibility Flexibility to recombination and reuse Efficiency by parallel processing Not only for sequential pipelines The workflow style is similar to several business model

recombination and reuse Efficiency by parallel processing Not only

14 Liabilities Filters require a common format of data In case of extensive data transformation, performance becomes an major concern Error handling is complex Pipeline components do not share any global state It is hard to give a general strategy for error handling

concern Error handling is complex Pipeline components do not

15 Blackboard

16 Blackboard Blackboard is useful for problems with no deterministic solution Several specialized components assemble their knowledge to build a partial solution Components collaborate Some components generate / write data Some components use / read data This pattern is often used to share data among different subsystems

solution Components collaborate Some components generate / write data Some

17 Example of Blackboard Selling Subsystem Inventory Control Subsystem Acquiring Subsystem Products DB

18 Benefits Easy way to share data Centralized backup and data protection Support for changeability and maintainability A subsystem does not need to know the other subsystems It is easy to aggregate additional subsystems Support for fault tolerance and robustness

subsystem does not need to know the other subsystems It is easy

19 Liabilities Difficulty of testing The solution may follow a nondeterministic algorithm All subsystems must understand the same format of data They can have different requirements It may be hard to maintain a large dataset

understand the same format of data They can have

20 Bibliography F. Buschmann et al. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Chap. 2 Architectural Patterns

Patterns in Software Engineering

Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 7 GoV Patterns Architectural Part 1 1 GoV Patterns for Software Architecture According to Buschmann et al.: A pattern for software architecture