Date post: | 05-Jan-2016 |
Category: |
Documents |
Upload: | egbert-hutchinson |
View: | 218 times |
Download: | 2 times |
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