1. Dataflow Architectural Styles (Styles 2) CPSC 410

2. Design Review Signups Send course e-mail team available times before class on Wednesday All members must attend Include at least one 30 minute block for each day, between 9am and 6pm ▫Oct. 12 th, Oct 13 th, and Oct 14th

3. Design Review ~20 mins Each team member should contribute. One possible timeline ~3 mins: high-level overview ~5 mins x 3: Describe a few related User Stories by … ▫Showing how the story corresponds to HTML UI ▫Showing how the story corresponds to Class diagram

4. Dataflow Styles Focus is on Process View Req 1. The output of one component passes to the input of another component ▫Without the use of shared storage Req 2. System execution (control) always moves data forward ▫No central coordination ▫Contrast to layered styles SourceC1C2Sink

5. Dataflow Formats Data processing is primary focus of architecture Often a single data format is mandated for input/output Simplifies composibility e.g. Document sort(Document in) Document find(Document in, String searchWord) Document head(Document in, int lines) Document tail(Document in, int lines)

6. Common Dataflow Arch. Audio streams e.g. Jipes signal processing libraries Text streams e.g. UNIX pipes: stdin/stdout Image manipulation e.g. rotate -> scale -> blur -> mask -> etc… RSS Feeds e.g. Yahoo! Pipes

7. Relationship to Decorator chains Often decorators exhibit dataflow style characteristics ▫Not always ▫e.g. GUI Window decorator Not surprising because … ▫Decorator chains can help with moving data between two components Decorators do not consider Process View

8. Batch Sequential Style Each component completes transformation of input before passing to output Dataflow is equivalent to function composition sink(c2(c1(source()))) SourceC1C2Sink

9. Batch-Sequential: A Financial Application Citation: Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

10. Batch Sequential Consequences + Supports easy reuse of components + Easy to reason about composition + Easy to maintain by adding/removing components – Each component has to wait for the output of the previous component to begin ▫No parallelism

11. Bad Dataflow Architecture Example transfer(Account from, Account to, double amt) { boolean ok = from.withdraw(amt); if(ok) { to.deposit(amt); } transferwithdrawdeposit ????

12. A better design? Seems correct but … Provides no useful composibility Some problems just aren’t good with dataflow arch. transfer Account DB from account to account amount New Account DB

13. Bad Dataflow Architecture Problems 1. Data is persistent/shared Data does not flow through the system Account data stays in one place 2. Control is centrally coordinated transfer uses result of withdraw to decide on flow of execution

14. Pipe and Filter Style Components run asynchronously; don’t wait before outputting data SourceC1C2Sink

15. Pipe and Filter Example Unix pipes echo -e “My World\nHello World\nFriends” | grep World

16. Pipe and Filter Consequences + Parallelization efficient, and concurrency easy to reason about (no resource contention) – Harder to program, debug Need to manage chunking and buffering using stream libraries

17. Why not parallelism? 1. Fundamental Simply not possible to break up data into smaller units e.g. sort vs. grep 2. Accidental Developers did not spend time to program concurrency

18. Fundamental Parallelism Bottleneck Unix pipes echo -e “My World\nHello World\nFriends” | grep World | sort

19. Conclusion (1/3) Not all systems make good dataflow architectures But … Not making a dataflow architecture when it is possible is a missed opportunity ▫To simplify composition

20. Conclusion (2/3) Not all dataflow systems make good pipe-and- filter architectures But … Not making a pipe-and-filter architecture when possible is a missed opportunity ▫To improve performance

21. Conclusion (3/3) More on dataflow architecture when we learn about Business Process Models