Transcript PowerPoint - Cornell University

CS 501: Software Engineering
Lecture 13
System Architecture and Design I
1
CS 501 Spring 2006
Administration
BOOM
Wednesday, Duffield Atrium 4-6
2
CS 501 Spring 2006
Quiz 2, Question 1
Question 1
At the end of your CS 501 project, you mount your programs and
documentation on GForge. The project team gives the client an
unrestricted license to use the project for the client's purposes but
not to distribute it to others.
A year later, two members of your team start a company, selling a
product that is based on your CS 501 system.
3
CS 501 Spring 2006
Quiz 2, Question 1
(a)
They would like to keep the specification of the system
secret. For this purpose they remove the system from GForge.
Can they claim legal protection of the specification as trade
secret?
No. The presumption is that by placing it on the GForge for a
year, trade secret protection was lost, unless the GForge site is
securely protected and, from the very start, everybody who saw
the specification was required to keep it secret.
4
CS 501 Spring 2006
Quiz 2, Question 1
(b) The company extends the system with a new component. Can
they protect the specification of the new component as trade
secret? If so, what procedure should they follow?
Yes, by creating procedures to keep the specification secret,
e.g., by restricting access and by ensuring that everybody who
has access understands the necessity of keeping it secret.
(c) Can the company require the CS 501 client to pay to use the
new component?
Yes. Unless the license from the project team to the client says
otherwise.
5
CS 501 Spring 2006
Quiz 2, Question 1
(d) Some time later, another member of the CS 501 project team
complains that he was never consulted about the company
using the software from the project. He asks for a share of the
profits. What should the company do?
Best answer: Ask a lawyer. This is a serious complaint, which
might cause problems for the company unless it is resolved.
Less good answer: Other members of the team are joint owners of
the copyright and have a right to share in the profits unless they
have signed a license agreement with the members of the
company. (This may be the advice that a lawyer will give, but
the situation is too complex not to seek professional advice.)
6
CS 501 Spring 2006
Quiz 2, Question 2
• An actor is a user of a system in a
particular role.
BookBorrower
Borrow book
OnlineShopper is a role
User is too vague to be useful
Mary is an individual, not a role
• A use case is a a task that an actor
needs to perform with the help of the
system.
PlaceOrder is a user task (and a use case)
Search the Catalog is part of this use case
7
CS 501 Spring 2006
System Architecture and Design
The overall design of a system:
•
•
•
•
•
•
8
Computers and networks (e.g., monolithic, distributed)
Interfaces and protocols (e.g., http, sql)
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)
CS 501 Spring 2006
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.
9
CS 501 Spring 2006
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
10
A node is a physical element that exists at run
time and represents a computational resource,
e.g., a computer.
CS 501 Spring 2006
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.
11
CS 501 Spring 2006
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 server
JavaScript at client
Java applets
Style sheets:
CSS, etc.
12
CS 501 Spring 2006
Web Interface: Basic
Web browser
Web server
• Static pages from server
• All interaction requires communication with server
13
CS 501 Spring 2006
UML Notation: Deployment Diagram
PersonalComp
WebBrowser
14
DeptServer
WebServer
CS 501 Spring 2006
UML Notation:
Application Programming Interface (API)
API is an interface that is realized by one or more components.
WebServer
Get
15
Post
CS 501 Spring 2006
UML Notation: Interfaces
WebBrowser
WebServer
HTTP
dependency
realization
interface
16
CS 501 Spring 2006
Web User Interface: CGI Script
Data
Web browser
Web server
CGI
Scripts
• Scripts can configure pages
• Scripts can validate information
• All interaction requires communication with server
17
CS 501 Spring 2006
UML Notation:
CGI Interface Diagram
MySQL
These components might be
located on a single node.
SQL
Apache
HTTP
18
CGIScript
CGI
CS 501 Spring 2006
Web User Interface: JavaScript
Data
Web browser
html
Java
Script
Web server
CGI
Scripts
• JavaScripts can validate information as typed
• Some interactions are local
• Server interaction constrained by web protocols
19
CS 501 Spring 2006
UML Notation: Package
JavaScript
A package is a general-purpose mechanism for organizing
elements into groups.
Note: Some authors draw packages with a different shaped box:
JavaScript
20
CS 501 Spring 2006
Example: Web Browser
WebBrowser
HTMLRender
Each package
represents a group of
objects.
JavaScript
HTTP
21
CS 501 Spring 2006
Web User Interface: Applet
Any
server
Applets
Web browser
Web servers
• Any executable code can run on client
• Client can connect to any server
22
CS 501 Spring 2006
Applet Interfaces
XYZInterface
XYZServer
WebBrowser
WebServer
HTTP
23
CS 501 Spring 2006
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.
24
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.
CS 501 Spring 2006
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.
25
CS 501 Spring 2006
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)
26
CS 501 Spring 2006
Batch Processing
Example: Electricity Utility Billing
First attempt:
Transaction
Data input
Master file
Bill
Each transaction is handled as it arrives.
27
CS 501 Spring 2006
Transaction Types
•
•
•
•
•
•
•
•
28
Create account / close account
Meter reading
Payment received
Other credits / debits
Check cleared / check bounced
Account query
Correction of error
etc., etc., etc.,
CS 501 Spring 2006
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
29
CS 501 Spring 2006
Batch Processing: Validation
errors
Batches of
incoming
transactions
Edit &
validation
Data input
Batches of
validated
transactions
read only
Master file
30
CS 501 Spring 2006
UML Deployment Diagram:
Batch Processing Validation
DataInput
EditCheck
RawData
ValidData
MasterFile
31
CS 501 Spring 2006
Batch Processing: Master File Update
Validated
transactions
in batches
errors
Sort by
account
Master file
update
32
Reports
Bills
Instructions
CS 501 Spring 2006
Interfaces to DataInput
EditCheckError
UpdateError
RawData
DataInput
DataforCheck
33
CS 501 Spring 2006
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
34
CS 501 Spring 2006
Online Inquiry
Customer
Service
read only
New
transaction
Master file
Customer Service department can read file, make annotations,
and create transactions, but cannot change the master file.
35
CS 501 Spring 2006
Online Inquiry: Use Cases
AnswerCustomer
<<uses>>
CustomerServer
36
NewTransaction
CS 501 Spring 2006
Data Intensive Systems
Example: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
37
•
Complex customer inquiries
•
Highly competitive market
CS 501 Spring 2006
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)
38
CS 501 Spring 2006
Real-time Transactions
Real-time
transactions
Products &
services database
39
Customer &
account database
External
services
CS 501 Spring 2006
Real-time Transactions & Batch
Processing
Real-time
transactions
Products &
services database
40
Data
input
Batch
processing
Customer &
account database
External
services
CS 501 Spring 2006
Stock Broker: Interface Diagram
OnLineTR
ProductDB
41
BatchTR
CustomerDB
CS 501 Spring 2006
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 commit
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?
*
42
These practical considerations may be major factors in
the choice of architecture.
CS 501 Spring 2006