cs 5150 software engineering lecture 13 software architecture 2

CS 5150Software

EngineeringLecture 13

Software Architecture 2

2CS 5150

Administrivia

• Presentations tomorrow & Friday

• Reports due Friday

• Teammate feedback due Monday

3CS 5150

SE in the News

• Nothing caught my eye ☹

4CS 5150

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)

5CS 5150

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.,

6CS 5150

First System Architecture

7CS 5150

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

8CS 5150

Adding Batch Processing and Validation

9CS 5150

UML Deployment Diagram for Validation

10

CS 5150

Adding Checkpoints, Reports and Error Messages

11

CS 5150

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

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

Online Inquiry

• Customer Service department can read the master file, make annotations, and create transactions, but cannot change the master file.

14

CS 5150

Our Final Electrical Utility Architecture

• Advantages: Efficient way to answer customer inquiries.

• Disadvantages: Information in master file is not updated immediately.

15

CS 5150

A New Twist: Real-Time Transactions

16

CS 5150

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

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

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

Why Program Concurrently?

• Real-world interaction

• Isolation

• Concurrent design patterns

• Parallel performance

20

Why Program Concurrently?

• Real-world interaction

• Isolation

• Concurrent design patterns

• Parallel performance

21

Why Program Concurrently?

• Real-world interaction

• Isolation

• Concurrent design patterns

• Parallel performance

22

Why Program Concurrently?

• Real-world interaction

• Isolation

• Concurrent design patterns

• Parallel performance

23

Parsing, Batch Approach

• batch_parse( pile_of_characters ) pile_of_tokens = tokenize( pile_of_characters ) syntax_tree = parse( pile_of_tokens )

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 ) <parsing logic>

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 ) <parsing logic>

• tokenize_driver( pile_of_characters ) declare parser_state while( ... ) small_pile_of_tokens = <tokenizing logic> parse_a_little( parser_state, small_pile_of_tokens )

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

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

Why Program Concurrently?

• Real-world interaction

• Isolation

• Concurrent design patterns

• Parallel performance

29

How to Program Concurrently?

30

Units of Concurrency

31

Units of Concurrency

32

Units of Concurrency

33

Units of Concurrency

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

To Every Unit of Concurrency a Purpose