CS 5150
Software Engineering
Lecture 14
System Architecture 2
CS 5150
1
Administration
Next and final presentations
Sign up now
Team members who were unable to come to the first
presentation should attend the second
Office hours
No office hours tomorrow, October 18.
CS 5150
2
Administration
Tests
There are 4 tests, each with 2 questions. The final grade will
be based on the best 6 questions out of 8.
Uncollected answer books are at 301 College Avenue.
Average grades:
Test 1 Q1
Test 1 Q2
Test 2 Q1
Test 2 Q2
6.9
6.2
8.4
7.8
Last time that this course was taught, poor test results were a
common reason for getting a poor overall grade for the course
CS 5150
3
Test 2 Question 2
The Pizza Ordering System allows the user of a web browser to
order pizza for home delivery. To place an order, a shopper
searches to find items to purchase, adds items one at a time to a
shopping cart, and possibly searches again for more items.
When all items have been chosen, the shopper provides a
delivery address. If not planning to pay with cash, the shopper
also provides credit card information.
The system has an option for shoppers to register with the pizza
shop. They can then save their name and address information,
so that they do not have to enter this information every time
that they place an order.
CS 5150
4
Test 2 Question 2 (i)
Develop a use case diagram, for a use case for placing an
order, PlaceOrder. The use case should show a relationship to
two previously specified use cases, IdentifyCustomer, which
allows a user to register and log in, and PaybyCredit, which
models credit card payments.
Definition from Lecture 9:
A use case is a a task that an actor needs to perform with the
help of the system.
CS 5150
5
Test 2 Question 2 (i)
Example from Lecture 9:
TakeExam
<<includes>>
Authenticate
ExamTaker
CS 5150
CheckGrades
<<includes>>
6
Test 2 Question 2 (i)
FAQ about Use
Cases
See:
http://www.andrew.c
mu.edu/course/90754/umlucdfaq.html
CS 5150
7
Test 2 Question 2 (i)
Example from
Wikipedia:
CS 5150
8
Test 2 Question 2 (i)
Correct solution
<<includes>>
PaybyCredit
PlaceOrder
Shopper
<<includes>>
Optional
link
IdentifyCustomer
CS 5150
9
Test 2 Question 2 (i)
Incorrect Solution
SearchMenu
AddtoCart
Pay
<<includes>>
Shopper
PaybyCredit
<<includes>>
IdentifyCustomer
CS 5150
10
System Design:
Data Intensive Systems
Examples
• 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)
CS 5150
11
Architectural Style: Master File Update
Example: Electricity Utility Billing
Requirements analysis identifies several transaction types:
• Create account / close account
• Meter reading
• Payment received
• Other credits / debits
• Check cleared / check bounced
• Account query
• Correction of error
• etc., etc., etc.,
CS 5150
12
Electricity Utility Billing
First attempt:
Transaction
Data input
Master file
Bill
Each transaction is handled as it arrives.
CS 5150
13
Criticisms of First Attempt
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
CS 5150
14
Electricity Utility Billing
Batch Processing: Edit and Validation
errors
Batches of
incoming
transactions
Edit &
validation
Data input
Batches of
validated
transactions
read only
Master file
CS 5150
15
UML Deployment Diagram:
Validation
DataInput
EditCheck
RawData
ValidData
MasterFile
Check
CS 5150
16
Electricity Utility Billing
Batch Processing: Master File Update
errors
Reports
Validated
transactions
in batches
Sort by
account
Batches of
input data
Master file
update
Bills
Checkpoints
and audit trail
CS 5150
17
Electricity Utility Billing
Benefits of Batch Updating
• 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
CS 5150
18
Architectural Style: Master File Update (basic)
Example: billing system for electric utility
Data input and
validation
Sort
Master file
update
Mailing and
reports
Advantages:
Efficient way to process batches of transactions.
Disadvantages:
Information in master file is not updated immediately.
No good way to answer customer inquiries.
CS 5150
19
Online Inquiry: Use Case
AnswerCustomer
<<uses>>
CustomerRep
NewTransaction
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
20
Online Inquiry
Customer
Service
Representative
read only
New
transaction
Master file
Customer Service department can read the master file, make
annotations, and create transactions, but cannot change the
master file.
CS 5150
21
Architectural Style: Master File Update (full)
Example: billing system for electric utility
Data input and
validation
Sort
Master file
update
Mailing and
reports
Customer
services
Advantages: Efficient way to answer customer inquiries.
Disadvantages: Information in master file is not updated
immediately.
CS 5150
22
Data Intensive Systems with
Real Time Transactions
Example: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
• Complex customer inquiries
• Highly competitive market
CS 5150
23
Real-time Transactions & Batch Processing
Real-time
transactions
This is a combination of the
Repository style and the
Master File Update style
CS 5150
Data
input
Customer &
account database
24
Extending the Repository Architectural Style:
A Small-town Stockbroker
Databases
• Customer and account database
• Financial products (e.g., account types, pension plans,
savings schemes)
• Links to external databases (e.g., stock markets, mutual
funds, insurance companies)
CS 5150
25
Real-time Transactions
Real-time
transactions
Products &
services database
CS 5150
Customer &
account database
External
services
26
Real-time Transactions & Batch Processing
Real-time
transactions
Products &
services database
CS 5150
Data
input
Batch
processing
Customer &
account database
External
services
27
Stock Broker: Interface Diagram
OnLineTR
BatchTR
External
ProductDB
CS 5150
CustomerDB
28
Practical considerations to include in
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.
CS 5150
29
System Design: Non-Functional Requirements
In some types of system architecture, non-functional
requirements of the system may dictate the software
design and development process.
CS 5150
30
Non-functional requirements:
Continuous Operation
Many systems must operate continuously
•
Software update while operating
•
Hardware monitoring and repair
•
Alternative power supplies, networks, etc.
•
Remote operation
These functions must be designed into the fundamental
architecture.
CS 5150
31
Time-Critical Systems
A time-critical (real time) system is a software system
whose correct functioning depends upon the results
produced and the time at which they are produced.
• A soft real time system is degraded if the results
are not produced within required time constraints
e.g., a network router is permitted to time out or lose a
packet
• A hard real time system fails if the results are
not produced within required time constraints
e.g., a fly-by-wire control system for an airplane, must
respond within specified time limits.
CS 5150
32
Time Critical System:
Architectural Style - Daemon
A daemon is used when messages might arrive at closer
intervals than the the time to process them.
Daemon
Spawned
process
Example: Web server
The daemon listens at port 80
When a message arrives it:
spawns a processes to handle the message
returns to listening at port 80
CS 5150
33
Software Considerations:
Testing
Example: Testing multi-threaded and parallel systems
Several similar threads operating concurrently:
•
•
Re-entrant code -- separation of pure code from
data for each thread
May be real-time (e.g., telephone switch) or non-time
critical
The difficult of testing real-time, multi-threaded systems
may determine the entire software architecture.
•
CS 5150
Division into components, each with its own
acceptance test.
34
Software Considerations:
Time-Critical System
Developers of advanced time-critical software
spend much of their effort developing the software
environment:
• Monitoring and testing -- debuggers
• Crash restart -- component and system-wide
• Downloading and updating
• Hardware troubleshooting and reconfiguration
etc., etc., etc.
CS 5150
35