CS 501: Software Engineering

1
CS 501 Software Engineering
Lecture 13 System Architecture and Design I
2
Administration

• Remember to schedule your presentations.

3
System Architecture and Design
The overall design of a system 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)
4
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.
5
UML Notation Component Node
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.
6
System Architecture ExampleExtensibility in Web
Browsers
Web browsers provide a flexible user interface by
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
7
Web Interface Basic
Web browser
Static pages from server All
interaction requires communication with server
8
UML Notation Deployment Diagram
PersonalComp
DeptServer
WebBrowser
WebServer
9
UML NotationApplication Programming Interface
(API)
API is an interface that is realized by one or
more components.
WebServer
Get
Post
10
UML Notation Interfaces
WebBrowser
WebServer
HTTP
dependency
realization
interface
11
Web User Interface CGI Script
Data
CGI Scripts
Web browser
Scripts can configure pages Scripts can
validate information All interaction
requires communication with server
12
UML Notation CGI Interface Diagram
MySQL
These components may be located on a single node.
SQL
CGIScript
Apache
HTTP
CGI
13
Web User Interface JavaScript
Data
Web browser
html
CGI Scripts
Java Script
JavaScripts can validate information as
typed Some interactions are local
Server interaction constrained by web protocols
14
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
15
Example Web Browser
WebBrowser
Each package represents a group of objects.
HTMLRender
JavaScript
HTTP
16
Web User Interface Applet
Any server
Applets
Web browser
Any executable code can run on client
Client can connect to any server
17
Applet Interfaces
XYZInterface
XYZServer
WebBrowser
WebServer
HTTP
18
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.
19
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.
20
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.
21
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)
22
Data Intensive SystemsExample Electricity
Utility Billing
First attempt
Bill
Master file
Transaction
Data input
Each transaction is handled as it arrives.
23
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.,
24
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

25
Batch Processing Validation
errors
Edit validation
Incoming transactions
Validated transactions
Data input
read only
Master file
26
UML Deployment DiagramBatch Processing
Validation
EditCheck
DataInput
ValidData
RawData
MasterFile
27
Batch Processing Master File Update
Reports
errors
Validated transactions in batches
Sort by account
Bills
Master file update
Instructions
28
Interfaces to DataInput
EditCheckError
UpdateError
RawData
DataInput
DataforCheck
29
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

30
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.
31
Online Inquiry Use Cases
AnswerCustomer
ltltusesgtgt
NewTransaction
CustomerServer
32
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
33
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)

34
Real-time Transactions
Real-time transactions
Products services database
External services
Customer account database
35
Real-time Transactions Batch Processing
Data input
Real-time transactions
Batch processing
Products services database
External services
Customer account database
36
Stock Broker Interface Diagram
OnLineTR
BatchTR
CustomerDB
ProductDB
37
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?

38
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.
39
Merger of Two Banks Options
A
B
???
???
40
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