CS 5150
Software Engineering
Lecture 13
Software Architecture 2
Administrivia
•
•
•
CS 5150
Presentations tomorrow & Friday
Reports due Friday
Teammate feedback due Monday
2
SE in the News
•
CS 5150
Nothing caught my eye ☹
3
Database Centered Applications
•
•
•
•
•
•
CS 5150
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)
4
Requirements Phase: Identify Transaction
Types
•
•
•
•
•
•
•
•
•
CS 5150
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.,
5
First System Architecture
CS 5150
6
First Architecture Critique
•
•
•
•
•
•
CS 5150
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
7
Adding Batch Processing and
Validation
CS 5150
8
UML Deployment Diagram for
Validation
CS 5150
9
Adding Checkpoints, Reports and Error
Messages
CS 5150
10
Benefits of Batch Processing
•
•
•
•
•
•
•
CS 5150
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
11
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.
CS 5150
12
Online Inquiry
•
CS 5150
Customer Service department can read the
master file, make annotations, and create
transactions, but cannot change the master
file.
13
Our Final Electrical Utility Architecture
•
•
CS 5150
Advantages: Efficient way to answer customer
inquiries.
Disadvantages: Information in master file is
not updated immediately.
14
A New Twist: Real-Time Transactions
CS 5150
15
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?
•
•
•
•
•
•
CS 5150
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.
16
•
•
•
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
17
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
18
•
•
•
•
Why Program
Concurrently?
Real-world
interaction
Isolation
Concurrent
design
patterns
Parallel
performance
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
•
Parsing, Batch
Approach
batch_parse( pile_of_characters )
pile_of_tokens = tokenize( pile_of_characters )
syntax_tree
= parse( pile_of_tokens )
23
•
•
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>
24
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 )
25
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 )
26
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 )
27
•
•
•
•
Why Program
Concurrently?
Real-world
interaction
Isolation
Concurrent
design patterns
Parallel
performance
28
How to Program
Concurrently?
29
Units of Concurrency
30
Units of Concurrency
31
Units of Concurrency
32
Units of Concurrency
33
The Many Names of
Cooperative Concurrency
• coroutine
• continuation
• goroutine
• iterator
• protothread
• eventlet
• greenlet
• light-weight thread
• fiber
• green thread
• task
• generator
• event handler
• cooperative thread
34
To Every Unit of Concurrency a
Purpose
35