cs 5150 software engineering
DESCRIPTION
CS 5150 Software Engineering. Lecture 14 System Architecture 2. 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. Administration. Tests - PowerPoint PPT PresentationTRANSCRIPT
CS 5150 1
CS 5150 Software Engineering
Lecture 14
System Architecture 2
CS 5150 2
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 3
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 4
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 5
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 6
Test 2 Question 2 (i)
Authenticate
TakeExam
<<includes>>
<<includes>>
CheckGradesExamTaker
Example from Lecture 9:
CS 5150 7
Test 2 Question 2 (i)
FAQ about Use Cases
See: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html
CS 5150 8
Test 2 Question 2 (i)
Example from Wikipedia:
CS 5150 9
Test 2 Question 2 (i)
Shopper
PlaceOrder
<<includes>>
IdentifyCustomer
PaybyCredit
<<includes>>
Correct solution
Optional link
CS 5150 10
Test 2 Question 2 (i)
Incorrect SolutionSearchMenu
PaybyCredit
<<includes>>
IdentifyCustomer
<<includes>>
AddtoCart
Pay
Shopper
CS 5150 11
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 12
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.,
Architectural Style: Master File Update
CS 5150 13
Electricity Utility Billing
First attempt:
Data input Master fileTransaction Bill
Each transaction is handled as it arrives.
CS 5150 14
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 15
Electricity Utility BillingBatch Processing: Edit and Validation
Data input
Master file
Edit & validation
read only
errors
Batches of validated transactions
Batches of incoming transactions
CS 5150 16
UML Deployment Diagram:Validation
MasterFile Check
EditCheck
ValidData
DataInput
RawData
CS 5150 17
Electricity Utility BillingBatch Processing: Master File Update
Master fileupdate Bills
Validated transactionsin batches
Sort by account
errors
Reports
Batches of input data
Checkpoints and audit trail
CS 5150 18
Electricity Utility BillingBenefits 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 19
Architectural Style: Master File Update (basic)
Master file update
Data input and validation
Mailing and reports
Example: billing system for electric utility
Advantages:
Efficient way to process batches of transactions.
Disadvantages:
Information in master file is not updated immediately.No good way to answer customer inquiries.
Sort
CS 5150 20
Online Inquiry: Use Case
CustomerRep
AnswerCustomer
NewTransaction
<<uses>>
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 21
Online Inquiry
Master file
read only
Customer Service Representative
Customer Service department can read the master file, make annotations, and create transactions, but cannot change the master file.
New transaction
CS 5150 22
Architectural Style: Master File Update (full)
Example: billing system for electric utility
Advantages: Efficient way to answer customer inquiries.
Disadvantages: Information in master file is not updated immediately.
Customer services
Master file update
Data input and validation
Mailing and reports
Sort
CS 5150 23
Data Intensive Systems with Real Time Transactions
• Transactions
Received by mail or over telephone
For immediate or later action
• Complex customer inquiries
• Highly competitive market
Example: A Small-town Stockbroker
CS 5150 24
Real-time Transactions & Batch Processing
Customer & account database
Real-time transactions
Data input
This is a combination of the Repository style and the Master File Update style
CS 5150 25
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 26
Real-time Transactions
Customer & account database
Products & services database
Real-time transactions
External services
CS 5150 27
Real-time Transactions & Batch Processing
Customer & account database
Products & services database
Real-time transactions
Batch processing
Data input
External services
CS 5150 28
Stock Broker: Interface Diagram
CustomerDBProductDB
OnLineTR BatchTR
External
CS 5150 29
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 + logdetailed 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 30
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 31
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 32
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 33
Time Critical System: Architectural Style - Daemon
Daemon
Example: Web server
The daemon listens at port 80
When a message arrives it:spawns a processes to handle the messagereturns to listening at port 80
Spawned process
A daemon is used when messages might arrive at closer intervals than the the time to process them.
CS 5150 34
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.
• Division into components, each with its own acceptance test.
CS 5150 35
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.