CS 501: Software Engineering
Lecture 13
System Architecture and Design I
1
CS 501 Spring 2005
Administration
BOOM
Wednesday, Duffield Atrium 4-6
2
CS 501 Spring 2005
Quiz 2
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, the members of your team decide to go into
business, selling a product that is based on your CS 501 system.
You start a small company and hire three programmers.
3
CS 501 Spring 2005
Quiz 2
(a)
You would like to keep the specification of the system
secret. For this purpose you remove the system from GForge.
Can you 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 2005
Quiz 2
(b) Your company extends the system with a new component. Can
you protect the specification of the new component as trade secret?
If so, what procedure would you follow?
Yes, by creating procedures to keep the specification secret, e.g., by
restricting access and my ensuring that everybody who has access
understands the necessity of keeping it secret.
(c) Who owns the copyright in the original system? Who owns the
copyright in your new component?
You own the copyright to the original system. To be more specific,
the members of the project team jointly own the copyright.
The company owns the copyright to the new component.
5
CS 501 Spring 2005
Quiz 2
(d) Can you charge the CS 501 client money to use your new
component?
Yes. Unless your license says otherwise.
(e)
Two of your programmers leave and start their own
company. What use can they make of the programs that they wrote
while working for your company? Can they write new software
based on the specification of your new component?
They can make no use of the programs, without permission from
the company. They were created as work for hire.
6
They cannot write software based on this specification. The
specification is a trade secret of the company. The former
employees cannot use it, but they can use ideas from it.
CS 501 Spring 2005
System Architecture and Design
The overall design of a system:
•
•
•
•
•
•
7
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 2005
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.
8
CS 501 Spring 2005
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.
9
CS 501 Spring 2005
System Architecture Example:
Extensibility in Web Browsers
Web browsers provide a flexible user interface
through an extensible architecture.
Data types:
helper applications, plug-ins
Protocols:
HTTP, WAIS, Gopher, FTP, etc.
proxies
Executable code:
CGI scripts at server
JavaScript at client
Java applets
Style sheets:
10
CS 501 Spring 2005
Web Interface: Basic
Web browser
Web server
• Static pages from server
• All interaction requires communication with server
11
CS 501 Spring 2005
UML Notation: Deployment Diagram
PersonalComp
WebBrowser
12
DeptServer
WebServer
CS 501 Spring 2005
UML Notation:
Application Programming Interface (API)
API is an interface that is realized by one or more components.
WebServer
Get
13
Post
CS 501 Spring 2005
UML Notation: Interfaces
WebBrowser
WebServer
HTTP
dependency
realization
interface
14
CS 501 Spring 2005
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
15
CS 501 Spring 2005
UML Notation:
CGI Interface Diagram
MySQL
These components might be
located on a single node.
SQL
Apache
HTTP
16
CGIScript
CGI
CS 501 Spring 2005
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
17
CS 501 Spring 2005
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
18
CS 501 Spring 2005
Example: Web Browser
WebBrowser
HTMLRender
Each package
represents a group of
objects.
JavaScript
HTTP
19
CS 501 Spring 2005
Web User Interface: Applet
Any
server
Applets
Web browser
Web servers
• Any executable code can run on client
• Client can connect to any server
20
CS 501 Spring 2005
Applet Interfaces
XYZInterface
XYZServer
WebBrowser
WebServer
HTTP
21
CS 501 Spring 2005
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.
22
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 2005
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.
23
CS 501 Spring 2005
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.
24
CS 501 Spring 2005
System Design:
Data Intensive Systems
Examples
•
Electricity utility customer billing
• Telephone company call recording and billing
•
Car rental reservations (e.g., Hertz)
•
Stock market brokerage (e.g., Charles Schwab)
• E-commerce (e.g., Amazon.com)
25
CS 501 Spring 2005
Batch Processing
Example: Electricity Utility Billing
First attempt:
Transaction
Data input
Master file
Bill
Each transaction is handled as it arrives.
26
CS 501 Spring 2005
Transaction Types
•
•
•
•
•
•
•
•
27
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 2005
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
• No way to answer customer queries
• No process for error checking and correction
• All activities are triggered by a transaction
28
CS 501 Spring 2005
Batch Processing: Validation
errors
Batches of
incoming
transactions
Edit &
validation
Data input
Batches of
validated
transactions
read only
Master file
29
CS 501 Spring 2005
UML Deployment Diagram:
Batch Processing Validation
DataInput
EditCheck
RawData
ValidData
MasterFile
30
CS 501 Spring 2005
Batch Processing: Master File Update
Validated
transactions
in batches
errors
Sort by
account
Master file
update
31
Reports
Bills
Instructions
CS 501 Spring 2005
Interfaces to DataInput
EditCheckError
UpdateError
RawData
DataInput
DataforCheck
32
CS 501 Spring 2005
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
33
CS 501 Spring 2005
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.
34
CS 501 Spring 2005
Online Inquiry: Use Cases
AnswerCustomer
<<uses>>
CustomerServer
35
NewTransaction
CS 501 Spring 2005
Data Intensive Systems
Example: A Small-town Stockbroker
• Transactions
Received by mail or over telephone
For immediate or later action
36
•
Complex customer inquiries
•
Highly competitive market
CS 501 Spring 2005
A Database Architecture
Database(s):
• 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)
37
CS 501 Spring 2005
Real-time Transactions
Real-time
transactions
Products &
services database
38
Customer &
account database
External
services
CS 501 Spring 2005
Real-time Transactions & Batch
Processing
Real-time
transactions
Products &
services database
39
Data
input
Batch
processing
Customer &
account database
External
services
CS 501 Spring 2005
Stock Broker: Interface Diagram
OnLineTR
ProductDB
40
BatchTR
CustomerDB
CS 501 Spring 2005
Architectural considerations to
include in Specification
• Real-time service during scheduled hours with batch
processing overnight
• Combine information from several databases
• Database consistency after any type of failure
two-phase commit
reload from checkpoint + log
detailed audit trail
• How will transaction errors be avoided?
• How will transaction errors be corrected?
• How will staff dishonesty be controlled?
41
CS 501 Spring 2005
Data Intensive Systems: Merger of
Two Banks
Each bank has a database with its customer accounts. The
databases are used by staff at many branches and for back-office
processing.
The requirement is to integrate the two banks so that they appear
to the customers to be a single organization and to provide
integrated service from all branches.
This is an example of working with legacy systems.
42
CS 501 Spring 2005
Merger of Two Banks: Options
A
???
B
???
43
CS 501 Spring 2005
Merger of Two Banks:
Architectural Options
I.
Convert everything to System A
convert databases
retrain staff
enhance System A (software and hardware)
discard System B
II. Build an interface between the databases in
System A and System B
III. Extend client software so that it can interact
with either System A or System B database
44
CS 501 Spring 2005