1. CS 5150 Software Engineering Lecture 13 Software Architecture 2

2. CS 5150 2 Administrivia Presentations tomorrow & Friday Reports due Friday Teammate feedback due Monday

3. CS 5150 3 SE in the News Nothing caught my eye ☹

4. CS 5150 4 Database Centered Applications Electricity utility customer billing (e.g., NYSEG) Telephone call recording and billing (e.g., Verizon) Car rental reservations (e.g., Hertz) Stock market brokerage (e.g., Charles Schwab) E-commerce (e.g., Amazon.com) University grade registration (e.g., Cornell)

5. CS 5150 5 Requirements Phase: Identify Transaction Types Example: electricity utility billing Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc., etc., etc.,

6. CS 5150 6 First System Architecture

7. CS 5150 7 First Architecture Critique Where is this first attempt weak? All activities are triggered by a transaction A bill is sent out for each transaction, even if there are several per day Bills are not sent out on a monthly cycle Awkward to answer customer queries No process for error checking and correction

8. CS 5150 8 Adding Batch Processing and Validation

9. CS 5150 9 UML Deployment Diagram for Validation

10. CS 5150 10 Adding Checkpoints, Reports and Error Messages

11. CS 5150 11 Benefits of Batch Processing All transactions for an account are processed together at appropriate intervals Backup and recovery have fixed checkpoints Better management control of operations Efficient use of staff and hardware Error detection and correction is simplified... but: Information is not available immediately in the main database No good way to answer customer inquiries

12. CS 5150 12 Online Inquiry Use Case A customer calls the utility and speaks to a customer service representative. The representative can read the master file, but not make changes to it. If the representative wishes to change information in the master file, a new transaction is created as input to the master file update system.

13. CS 5150 13 Online Inquiry Customer Service department can read the master file, make annotations, and create transactions, but cannot change the master file.

14. CS 5150 14 Our Final Electrical Utility Architecture Advantages: Efficient way to answer customer inquiries. Disadvantages: Information in master file is not updated immediately.

15. CS 5150 15 A New Twist: Real-Time Transactions

16. CS 5150 16 Practical Considerations for Architecture and Specification Can real-time service during scheduled hours be combined with batch processing overnight? How will the system guarantee database consistency after any type of failure? reload from checkpoint + log detailed audit trail How will transaction errors be avoided and identified? How will transaction errors be corrected? How will staff dishonesty be controlled? These practical considerations may be major factors in the choice of architecture.

17. CS 5150 17 Common Non-Functional Requirements High availability Hardware monitoring and redundancy In-flight software update Remote management Soft and hard real-time requirements Design for debugging Internal consistency checks Fail-fast versus fault tolerant

18. 18 Concurrent and Parallel Programming is Hard... but not impossible We can dramatically improve on current standard practices with available technologies There are important benefits to be reaped by expanding the use of concurrent programming

19. 19 Why Program Concurrently? Real-world interaction Isolation Concurrent design patterns Parallel performance

20. 20 Why Program Concurrently? Real-world interaction Isolation Concurrent design patterns Parallel performance

21. 21 Why Program Concurrently? Real-world interaction Isolation Concurrent design patterns Parallel performance

22. 22 Why Program Concurrently? Real-world interaction Isolation Concurrent design patterns Parallel performance

23. 23 Parsing, Batch Approach batch_parse( pile_of_characters ) pile_of_tokens = tokenize( pile_of_characters ) syntax_tree = parse( pile_of_tokens )

24. 24 Incremental; Parser Drives batch_parse( pile_of_characters ) pile_of_tokens = tokenize( pile_of_characters ) syntax_tree = parse( pile_of_tokens ) parse_driver( pile_of_characters ) declare tokenizer_state while(... ) small_pile_of_tokens = tokenize_a_little( tokenizer_state )

25. 25 Incremental; Tokenizer Drives batch_parse( pile_of_characters ) pile_of_tokens = tokenize( pile_of_characters ) syntax_tree = parse( pile_of_tokens ) parse_driver( pile_of_characters ) declare tokenizer_state while(... ) small_pile_of_tokens = tokenize_a_little( tokenizer_state ) tokenize_driver( pile_of_characters ) declare parser_state while(... ) small_pile_of_tokens = parse_a_little( parser_state, small_pile_of_tokens )

26. 26 Incremental; Symmetric incremental_parse1( pile_of_characters ) declare tokenizer_state declare parser_state while(... ) small_pile_of_tokens = tokenize_a_little( tokenizer_state ) parse_a_little( parser_state, small_pile_of_tokens )

27. 27 Incremental; Concurrent incremental_parse1( pile_of_characters ) declare tokenizer_state declare parser_state while(... ) small_pile_of_tokens = tokenize_a_little( tokenizer_state ) parse_a_little( parser_state, small_pile_of_tokens ) incremental_parse2( pile_of_characters ) declare token_channel start( tokenizer, pile_of_characters, token_channel ) start( parser, token_channel ) wait( tokenizer ) wait( parser )

28. 28 Why Program Concurrently? Real-world interaction Isolation Concurrent design patterns Parallel performance

29. 29 How to Program Concurrently?

30. 30 Units of Concurrency

31. 31 Units of Concurrency

32. 32 Units of Concurrency

33. 33 Units of Concurrency

34. 34 The Many Names of Cooperative Concurrency light-weight thread fiber green thread task generator event handler cooperative thread coroutine continuation goroutine iterator protothread eventlet greenlet

35. 35 To Every Unit of Concurrency a Purpose