Upload
cathleen-thornton
View
215
Download
1
Embed Size (px)
Citation preview
1 CS 501 Spring 2008
CS 501: Software Engineering
Lecture 13
System Architecture and Design I
2 CS 501 Spring 2008
Administration
Quizzes
There are 4 quizzes, 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:
Quiz 1 Q1 Quiz 1, Q2 Quiz 2 Q1 Quiz 2 Q2
7.6 6.2 6.8 8.0
3 CS 501 Spring 2008
CS 501: Software Engineering
Usability (continued)
4 CS 501 Spring 2008
Evaluation
• Making sure that a system is usable before launching it.
• Iterative improvements after launch.
• Categories of evaluation methods:
Analytical evaluation: without users
Measurements on operational systems
Empirical evaluation: with users
5 CS 501 Spring 2008
Evaluation
How do you measure usability?
Usability comprises the following aspects:
• Effectiveness – the accuracy and completeness with which users achieve certain goals Measures: quality of solution, error rates
• Efficiency – the relation between the effectiveness and the resources expended in achieving themMeasures: task completion time, learning time, clicks number
• Satisfaction – the users' comfort with and positive attitudes towards the use of the systemMeasures: attitude rating scales
From ISO 9241-11
6 CS 501 Spring 2008
Measurement
Basic concept: log events in the users' interactions with a system
Examples from a Web system
• Clicks (when, where on screen, etc.)
• Navigation (from page to page)
• Keystrokes (e.g., input typed on keyboard)
• Use of help system
• Errors
May be used for statistical analysis or for detailed tracking of individual user.
7 CS 501 Spring 2008
Evaluation based on measurements
Analysis of system logs
• Which user interface options were used?
• When was was the help system used?
• What errors occurred and how often?
• Which hyperlinks were followed (click through data)?
Human feedback
• Complaints and praise
• Bug reports
• Requests made to customer service
8 CS 501 Spring 2008
Evaluation with Users
Testing the system, not the users!
Stages of evaluation with users:
Preparation
Sessions conduct
Analysis of results
User testing is time-consuming, expensive, and essential.
9 CS 501 Spring 2008
Evaluation with UsersPreparation
• Determine goals of the usability testing
“Can a user find the required information in no more than 2 minutes?”
• Write the user tasks
“Answer the question: how hot is the sun?”
• Recruit participants
Use the descriptions of users from the requirements phase to detect potential users
10 CS 501 Spring 2008
Usability Laboratory
Concept: monitor users while they use system
Evaluators User
one-way mirror
11 CS 501 Spring 2008
Evaluation with UsersSessions Conduct
• Conduct the session– Usability Lab– Simulated working
environment
• Observe the user– Human observer(s)– Video camera– Audio recording
• Inquire satisfaction data
12 CS 501 Spring 2008
Evaluation with users:Results analysis
• If possible, use statistical summaries.
• Pay close attention to areas where users
– were frustrated
– took a long time
– could not complete tasks
• Respect the data and users' responses. Do not make excuses for designs that failed.
• Note designs that worked and make sure they are incorporated in the final product.
13 CS 501 Spring 2008
Usability: Design Tensions in Networked Systems
• Client computers and network connections vary greatly in capacity
• Client software may run on various operating systems. It may be current or an earlier version. What assumptions do you make about the user's computer and Web browser?
• Designers wish to control client software, e.g., Web browsers, but users wish to configure their own environments. This can be a factor in accessibility, e.g., which part of the system determines the font size.
14 CS 501 Spring 2008
System considerations of user interface design
• Personal computer cycles are there to be used
• Any network transfer involves delay
• Shared systems have unpredictable performance
• Data validation often requires access to shared data
• Mobile code poses security risks
15 CS 501 Spring 2008
Usability and Cost
• Good usability may be expensive in hardware or special software development
• User interface development may be a major part of a software development project
Programming environments provide powerful user interface toolkits
• Costs are multiplied if a user interface has to be used on different computers or migrate to different versions of systems
Web browsers provide a general purpose user interface where
others maintain the user interface software
16 CS 501 Spring 2008
Changes in user interface design
Examples of change: 1995 to 2007
17 CS 501 Spring 2008
1990
SEARCH I NSPEC Dat abase- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Type keywor ds and pr ess RETURN - - orent er a command
Def aul t i s ADJ : aci d f r ee- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Set #3: aci d adj f r e 0 r ecor ds I NSPEC Dat abase
Set #4: aci d adj f r ee 5 r ecor ds I NSPEC Dat abase
Set #5: aci d and paper 448 r ecor ds I NSPEC Dat abase
Set #6: deaci di f i cat i on 4 r ecor ds I NSPEC Dat abase- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
18 CS 501 Spring 2008
1995
19 CS 501 Spring 2008
2003
20 CS 501 Spring 2008
2003
21 CS 501 Spring 2008
1995
22 CS 501 Spring 2008
2006
23 CS 501 Spring 2008
1995
24 CS 501 Spring 2008
2003
25 CS 501 Spring 2008
1995
26 CS 501 Spring 2008
2006
27 CS 501 Spring 2008
CS 501: Software Engineering
System Architecture and Design
28 CS 501 Spring 2008
System Architecture and Design
The overall design of a system:
• Computers and networks (e.g., monolithic, distributed)
• Interfaces and protocols (e.g., http, ODBC)
• Databases (e.g., relational, distributed)
• Security (e.g., smart card authentication)
• Operations (e.g., backup, archiving, audit trails)
• Software environments (e.g., languages, source control tools)
29 CS 501 Spring 2008
UML: System and Subsystem Modeling
Subsystem model
A grouping of elements that specifies what a part of a system should do.
Component (UML definition)
"A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system."
A component can be thought of as an implementation of a subsystem.
30 CS 501 Spring 2008
UML Notation: Component & Node
orderform.java
A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.
Server
A node is a physical element that exists at run time and represents a computational resource, e.g., a computer.
31 CS 501 Spring 2008
Components and Replaceability
Components allow system to be assembled from binary replaceable elements.
• A component is physical -- bits not concepts
• A component can be replaced by any other component(s) that conforms to the interfaces.
• A component is part of a system.
• A component provides the realization of a set of interfaces.
32 CS 501 Spring 2008
System Architecture Example:Extensibility in Web Browsers
Web browsers provide a flexible user interface through an extensible architecture.
Protocols:HTTP, WAIS, Gopher, FTP, etc., proxies
Data types: helper applications, plug-ins, etc.
Executable code:CGI scripts at serverJavaScript at clientJava applets
Style sheets:
CSS, etc.
33 CS 501 Spring 2008
Web Interface: Basic
Web serverWeb browser
• Static pages from server
• All interaction requires communication with server
34 CS 501 Spring 2008
UML Notation: Deployment Diagram
WebBrowser
PersonalComp
WebServer
DeptServer
35 CS 501 Spring 2008
UML Notation:Application Programming Interface (API)
API is an interface that is realized by one or more components.
WebServer
Get Post
36 CS 501 Spring 2008
UML Notation: Interfaces
WebBrowser WebServer
HTTP
dependency
interface
realization
37 CS 501 Spring 2008
Web User Interface: CGI Script
Web browser
• Scripts can configure pages
• Scripts can validate information
• All interaction requires communication with server
Data
CGIScripts
Web server
38 CS 501 Spring 2008
UML Notation: CGI Interface Diagram
CGIScript
HTTP
Apache
CGI
ODBC
MySQL
These components might be located on a single node.
39 CS 501 Spring 2008
Web User Interface: JavaScript
Data
CGIScripts
Web server
Web browser
• JavaScripts can validate information as typed
• Some interactions are local
• Server interaction constrained by web protocols
JavaScript
html
40 CS 501 Spring 2008
UML Notation: Package
A package is a general-purpose mechanism for organizing elements into groups.
Note: Some authors draw packages with a different shaped box:
JavaScript
JavaScript
41 CS 501 Spring 2008
Example: Web Browser
HTTP
JavaScript
HTMLRenderEach package represents a group of objects.
WebBrowser
42 CS 501 Spring 2008
Web User Interface: Applet
Any server
Web serversWeb browser
• Any executable code can run on client
• Client can connect to any server
Applets
43 CS 501 Spring 2008
Applet Interfaces
WebBrowser WebServer
HTTP
XYZServer
XYZInterface
44 CS 501 Spring 2008
UML Diagrams and Specifications
For every subsystem, there is a choice of diagrams
Choose the diagrams that best model the system and are clearest to everybody.
In UML every diagram must have supporting specification
The diagrams shows the relationships among parts of the system, but much, much more detail is needed to specify a system explicitly.
For example, in the Applet Interface slide, at the very least, the specification should include the version of the protocols to be supported at the interfaces, the options (if any), and implementation restrictions.
45 CS 501 Spring 2008
Components and Classes
Classes represent logical abstractions. They may be grouped into packages.
Components represent physical things. They may live on nodes.
Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.
46 CS 501 Spring 2008
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)
47 CS 501 Spring 2008
Example: Electricity Utility Billing Transaction Types
Requirements analysis has identified 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.,
48 CS 501 Spring 2008
Batch Processing DesignExample: Electricity Utility Billing
First attempt:
Data input Master fileTransaction Bill
Each transaction is handled as it arrives.
49 CS 501 Spring 2008
Criticisms of First Attempt
Where is this first attempt weak?
• 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
• All activities are triggered by a transaction
50 CS 501 Spring 2008
Batch Processing: Validation
Data input
Master file
Edit & validation
read only
errors
Batches of validated transactions
Batches of incoming transactions
51 CS 501 Spring 2008
UML Deployment Diagram:Batch Processing Validation
MasterFile
EditCheck
ValidData
DataInput
RawData
52 CS 501 Spring 2008
Batch Processing: Master File Update
Master fileupdate
Bills
Validated transactionsin batches
Sort by account
errors Reports
Instructions
53 CS 501 Spring 2008
Interfaces to DataInput
DataInput
RawData
EditCheckErrorUpdateError
DataforCheck
54 CS 501 Spring 2008
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
55 CS 501 Spring 2008
Online Inquiry
Master file
read only
Customer Service
Customer Service department can read file, make annotations, and create transactions, but cannot change the master file.
New transaction
56 CS 501 Spring 2008
Online Inquiry: Use Cases
CustomerServer
AnswerCustomer
NewTransaction
<<uses>>
57 CS 501 Spring 2008
Data Intensive SystemsExample: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
• Complex customer inquiries
• Highly competitive market
58 CS 501 Spring 2008
A Database Architecture
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)
59 CS 501 Spring 2008
Real-time Transactions
Customer & account database
Products & services database
External services
Real-time transactions
60 CS 501 Spring 2008
Real-time Transactions & Batch Processing
Customer & account database
Products & services database
External services
Real-time transactions
Batch processing
Data input
61 CS 501 Spring 2008
Stock Broker: Interface Diagram
CustomerDBProductDB
OnLineTR BatchTR
External
62 CS 501 Spring 2008
Practical considerations to include in Architecture and Specification
• Real-time service during scheduled hours with batch processing overnight
• Database consistency after any type of failure
two-phase commitreload 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.
*