14 March 2001 Mickey M. Shroff Object Oriented Protocol Product ion, Sem inar Presentation. Layers, Filters and Pipes / / Mickey M.

Size: px

Start display at page:

Download "14 March 2001 Mickey M. Shroff Object Oriented Protocol Product ion, Sem inar Presentation. Layers, Filters and Pipes / / Mickey M."

Philip Riley
7 years ago
Views:

1 Layers, Pipes and Filters 14 March 2001 Mickey M. Shroff Object Oriented Protocol Product ion, Sem inar Presentation 1

2 Overview to Presentation What Kind of Patterns Layers, Pipes and Filters Are? The Layers Pattern The Pipes and Filters Pattern 2

3 W hat Kind of Patterns Layers, Pipes and Filters Are? Ball of Mud = problems + requirements + aspects... But we have not formed any organized structure, yet (workable slices) 3

4 W hat Kind of Patterns Layers, Pipes and Filters Are? Layers, pipes and filters are patterns to solve the problem of finding an organized structure 4

5 W hat Kind of Patterns Layers, Pipes and Filters Are? Layers, pipes and filters solve architectural problems Design patterns Idioms 5

6 The Layers Pattern Consept The Layer architectural pattern helps to structure applications that can be decom posed into groups of subtasks in which each group of subtasks is at a particular level of abstraction. [ POSA1] 6

7 The Layers Pattern ( Context ) A large system that requires decom posit ion System s division to groups has to be det erm ined. Result(division to groups) 7

8 The Layers Pattern ( Problem ) Forces When working in a team the work has to be divided in clear boundaries. Exchangeabilit y Com ponents can be changed to other ones without affecting the rest of the system. Any changes m ade to a com ponents functionality m ust not ripple other com ponents = > standard interfaces. 8

9 The Layers Pattern ( Forces continued) I f a com ponents becom es too com plex they can be fragm ented to subcom ponents. Highly related responsibilities/ tasks should be grouped t oget her. Com ponent boundaries m ay be broken if perform ance is im portant and the cost of crossing m any boundaries is high. 9

10 The Layers Pattern ( Solution ) Component 1 Component 2 Component 3 Layer n Layer n-1 Layer n-2 Layered system Different levels of abstraction Component 4 10

11 The Layers Pattern ( Structure ) Layer n Layer n-1 Layer n-1 provides services to the layer n. Layer n-1 uses the services of layer. n-2. Layer n-2 11

12 The Layers Pattern ( I m plem entation ) Define the abstraction criterion for grouping tasks into layers Determ ine the num ber of abstraction levels Nam e the layers and assign tasks to each of them Specify t he services 12

13 The Layers Pattern ( I m plem entation continued...) Refine t he layering iteration Specify an interface for each layer St ruct ure individual layers Specify the com m unication between adj acent layers Design an error-handling strategy 13

14 Benefits of Layers Pattern Reuse of layers Black- box reuse ( best choise) Support for st andardizat ion Not vendor dependent Dependencies are kept local changes to one layer does not ripple the whole system Exchangeabilit y layers can be changed (TCP < -> UDP) 14

15 Liabilities( draw backs) of Layers Pattern Lower efficiency / Unnecessary work checksum s error m essages How m any layers the application should have? OSI protocol stack 15

16 The Layers Pattern ( Exam ples) Web applicat ions View layer, business logic, dat abase Operation system s Protocol stacks TCP/ I P, OSI -m odel

17 The Layers Pattern Variants Relaxed Layered Syst em Services are not restricted to adjacent layers Layering Through inherit ance upper layers inherit s from lower layers 17

18 Pipes and Filters Pattern Consept The Pipes and Filters architectural pattern provides a structure for system s that process a stream of data. Each processing step is encapsulated in a filter com ponent. Data is passed through pipes between adj ancent filters. Recom bining filters allows you to build fam ilies of related system s. [ POSA1] 18

19 Pipes and Filters Pattern ( Context) Processing data stream s input Data processing output 19

20 Pipes and Filters Pattern ( Problem ) Data stream s can be processed in several step, each dependent from the previous but not from the other steps. Forces Processing st eps can be recom bined by the program m er by the user... 20

21 Pipes and Filters Pattern ( forces continued... ) Processing st eps can be added by the program m er by the user... Processing steps should be reusable in different cont ext s Sam e kind of input data can stream from various sources. The output data can be forwarded to different devices (disk, term inal...) 21

22 Pipes and Filters Pattern ( forces continued... ) Parallel processing of data stream s 22

23 Pipes and Filters Pattern ( Solution) Division to several sequential processing steps The outputs of one step are the inputs to others... 23

24 Pipes and Filters Pattern ( Structure ) Count L= L1*2 Then L Data is pushed or pulled (active or passive) Filter Pipe Count L = L1*2 After applying Pipes and Filters Count L +6

25 Pipes and Filters Pattern ( Structure ) Filt er gets input data stream processes the data outputs the processed data Pipe transfers data stream s buffers data stream s synchronizes data stream s 25

26 Pipes and Filters Pattern ( Structure ) Data Source Supplies data stream s to the first pipe. Data Sink Results of pipeline processing is gone here (the end of the last pipe) 26

27 Pipes and Filters Pattern ( I m plem entation ) Divide the system s task into sequence of processing st ages Define the data form at to be passed along each pipe Decide how to im plem ent each pipe connection Design and im plem ent the filters Design t he error handling set up t he processing pipeline 27

28 Benefits of Pipes and Filters Pattern Flexibilit y Reuse Prot ot yping Efficiency 28

29 Liabilities of Pipes and Filters Pattern State inform ation state inform ation between filters reduces the flexibility of the pattern Error handling 29

30 Pipes and Filters Pattern ( Exam ples) Unix -operator and > -operator 30

31 Pipes and Filters Pattern ( Variants) Tee and join pipeline system s m ultiple inputs and/ or outputs 31

32 This document was created with Win2PDF available at The unregistered version of Win2PDF is for evaluation or non-commercial use only.

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