Download CHAPTER10

Application Architecture & Process
Design
Introduction

The chapter will address the following questions:





What is an information system’s architecture in terms of DATA,
PROCESSES, INTERFACES, and NETWORKS — the building
blocks of all information systems?
What are both centralized and distributed computing alternatives
for information system design, including various client/server and
Internet/intranet options?
What are the database and data distribution alternatives for
information system design?
What are the make versus buy alternatives and variations for
information system design?
What are the user and system interface alternatives for information
system design?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
1
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Introduction

The chapter will address the following questions:




What are the various networking topologies and their importance
in information system design?
What are the methods for general application architecture and
design?
What are the differences between logical and physical data flow
diagrams, and explain how physical data flow diagrams are used to
model application architecture and guide process design?
How do you draw physical data flow diagrams for a
system/application?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
2
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
General System Design

During general systems design the basic technical
decisions are made. These decisions include:





Will the system use centralized or distributed?
Will the system’s data stores be centralized or distributed? If
distributed, how so? What data storage technology(s) will be used?
Will software be purchased, built in-house, or both? For programs
to be written, what technology(s) will be used?
How will users interface with the system? How will data be input?
How will outputs be generated?
How will the system interface to other, existing systems?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
3
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
General System Design

The decisions made during general systems design
constitute the application architecture of the system.

An application architecture defines the technologies to be used
by (and to build) one, more, or all information systems in terms of
its data, process, interface, and network components. It serves as a
framework for general design.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
4
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
INFORMATION SYSTEMS FRAMEWORK
SYSTEM
OWNERS
(scope)
FOCUS ON
SYSTEM
DATA
FOCUS ON
SYSTEM
PROCESSES
FOCUS ON
SYSTEM
INTERFACES
FOCUS ON
SYSTEM
GEOGRAPHY
System
Development
Business Subjects
Business Functions
System Context
Operating Locations
Survey Phase
(establish scope
and project plan)
Custom ers order zero,
one, or m ore products.
Products m ay be ordered
by zero, one, or m ore
custom ers.
Accounts
Receivable
Database
Marketing
Cr edit
Advertising
Custom er
Sales
Or der
Managem ent
System
Or der
Picking
Or der
War ehouse
Cr edit
Voucher
O rders
Cancellat ions
Services
Bank
Data Requirements
Business Processes
Interface Requirements
Communication Reqts.
rejected order
S
Y
S
T
E
M
A
N
A
L
Y
S
T
S
SYSTEM
USERS
(requirements)
PRODUCT
product-no
product-name
unit-of-measure
unit-price
quantity-available
CUSTOMER
customer-no
customer-name
customer-rating
balance-due
order
SYSTEM
DESIGNERS
Validate
customer
EDI
Cust
Check
credit
customer
number
ORDER
order-no
order-date
products-ordered
quantities-ordered
Database Scehma
credit
Customers
valid order
order without
valid
customer
Validate
products
quantity
in stock
Release
order
Get an
Order
Validate
an Order
picking
ticket
SYSTEM
BUILDERS
O RDER_PRODUCT
O RDER
order_no [Alph a(12)] INDEX O RDER. ord er_n o
order_date [Date(mmd dyyyy) PRODUCT.p rod uct_n o
qu an tity_ordered [Integer(2)
CUST OMER.cu sto mer_n o
Database
Decisions
Indy
Warehouse
NY
Office
ship order
Maintenance
Records
Interface Schema
Network Schema
Custom er
For m
New Custom er
Shutdown
Routine
Definition Phase
(establish and
prioritize business
system requirements)
Or der Accepted
Change
of
Address
New Or der
Com m unications
Contr oller
St. Louis
Mainfr am e
NT Ser ver LA
Or der Help Complete
File an
Order
Or der Form
Check
Customer
Credit
Check
Product
Data
Check
Credit
Data
Fir st Or der
PBX
Request Order Help
(specification)
ship
order
ser vice
Logon
Process
an Order
credit
credit
LA
Office
Order
Processing
Program
Initiation
Routine
Pr oducts
Catalog
East
Custom ers
Orders
approved
order
Application Schema
PRODUCT
CUST OMER
prod uct_no [Alph a(10)] INDEX
cu sto mer_n o [Alp ha (10)] INDEX
prod uct_name [Al pha(32)]
cu sto mer_n ame [Alph a(32)]
un it_of_measu re [Alp ha(2)]
cu sto mer_ratin g [Alp ha(1)] INDEX
un it_pri ce [Real(3, 2)]
balan ce_du e [Real (5,2)]
qu an tity_available [In teg er(4)]
catalog
changes
ship
order
West
Custom ers
Fi recracker Sal es
prices
Products
St.
Louis
HQ
order
approved order
order with
valid products
Study Phase
(establish system
improvement
objectives)
Release
an
Order
Help +
Request
Pr oduct
Lookup
NT Ser ver NY
Ether net LAN/NT
Ether net LAN/NT
Request Product Lookup Help
Indy AIX Ser ver
Customers
Products
Pr oduct Lookup Help Complete
Orders
Pr oduct
Lookup
Interface
Decisions
Process
Decisions
Client P C
Client P C
Client P C
Enter net LAN AIX /Lan
Manager
Network
Decisions
Client P C
Design/Constructio
n Phases
(design and develop
the system solution)
(components)
INFORMATION
TECHNOLOGY
ARCHITECTURE
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Database
Architecture
Processor and
Software Architecture
5
Interface
Architecture
Implementation
Phase
(deliver the new
system into
operation)
Networking
Architecture
Architecture Project
or
Configuration
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing
What is client/server computing?
 A client is single-user computer that provides (1) user interface
services, appropriate database and processing services; and (2)
connectivity services to servers (and possibly other clients).
 A server is a multiple-user computer that provides (1) shared
database, processing, and interface services; and (2)
connectivity to clients and other servers.
 In client/server computing an information system’s database,
software, and interfaces are distributed across a network of
clients and servers which communicate and cooperate to
achieve system objectives. Despite the distribution of
computing resources, each system user perceives that a single
computer (their own client PC) is doing all the work.
Prepared by Kevin C. Dittman for

Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
6
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Client/server computing is an alternative to traditional centralized
computing.
 In centralized computing, a multi-user computer (usually a
mainframe or minicomputer) hosts all of the information
system components including (1) the data storage (files and
databases), (2) the business logic (software and programs), (3)
the user interfaces (input and output), and (4( any system
interfaces (networking to other computers and systems). The
user may interact with this host computer via a terminal (or,
today, a PC emulating a terminal), but all of work is actually
done on the host computer.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
7
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Centralized
Computing
Distributed Presentation
Computing
Distributed Database
Computing
Distributed Data/Logic
Computing
Internet/Intranet
Computing
What is the
server and
operating
system?
The server is usually a
minicomputer or mainframe,
possibly networked to other
minicomputers or mainframes.
The server is usually a
minicomputer (e.g., OS/400 OS) or
mainframe computer (e.g. MVS,
VM, or UNIX OS).
A database server is usually
microprocessor-based (e.g., UNIX
or Windows/NT Server) but could
still be a mainframe or
minicomputer.
Typically. data and business logic
(and possibly other services) are
on separate servers (same OS's as
in previous column).
Utilizes data and/or file servers as
in previous two columns, but adds
one or more Internet and intranet
servers.
Where are
database
commands
executed?
All data is stored on the server and
all file and database access and
update commands and instructions
are executed on the server
computer.
All data is stored on the server and
all file and database access and
update commands and instructions
are executed on the server
computer.
All data is stored on the server and
all file and database access and
update commands and instructions
are executed on the server
computer.
All data is stored on the server
(possibly multiple servers) and all
file and database access and
update commands and instructions
are executed on the server
computers.
All data is stored on the server
(possibly multiple servers) and all
file and database access and
update commands and instructions
are executed on the server
computers.
Most business logic is programmed
to execute on the server.
Appropriate business logic is
programmed to execute on the
server.
Local
Area
Network
Where is
the
business
logic
instruction
s
executed?
Where are
user/syste
m interface
instruction
s
executed?
What is the
client and
operating
system?
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
All business logic is programmed
to execute on the server.
All business logic is programmed
to execute on the server.
Resulting data files may be
transferred to another server
across the network.
Resulting data files may be
transferred to another server
across the network.
All business logic is programmed
to execute on the client using a
PC-based programming language.
Local
Area
Network
Some business logic may be
programmed to execute on the
client.
The user interface (usually
non-graphical) is stored and
executed on the server.
The user interface (usually
graphical) is stored and executed
on the client.
The user interface (usually
graphical) is stored and executed
on the client.
Wide
Area
Network
The user interface (usually
graphical) is stored and executed
on the client.
Appropriate business logic may be
downloaded from Inter/intranet
server to execute on the client.
Intranet
or
Internet
Wide
Area
Network
Local or
Wide Area
Network
Any system interfaces are either
executed on the server or across
the network on another server.
Any system interfaces are either
executed on the server or across
the network on another server.
Any system interfaces are either
executed on the server or across
the network on another server.
Any system interfaces are either
executed on the server or across
the network on another server.
System interfaces are managed
from the Internet or intranet.
The clients are either dumb
(non-programmable) terminals, or
PCs (any OS) that are emulating
dumb terminals using software.
The clients are personal
computers or workstations
(sometimes called fat clients)
running Windows 9x, Windows NT,
OS/2, or Macintosh OS.
The clients are personal
computers or workstations
(sometimes called fat clients)
running Windows 9x, Windows NT,
OS/2, or Macintosh OS.
The clients are personal
computers or workstations
(sometimes called fat clients)
running Windows 9x, Windows NT,
OS/2, or Macintosh OS.
In addition to fat clients (see
previous column), some clients
may be network computers (also
called NCs or thin clients) that only
execute downloaded programs
8
Wide
Area
Network
Local
Area
Network
User interfaces may be stored and
executed on the client, or
downloaded from the Internet or
intranet for execution on the client.
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Centralized Computing:
 Centralized process architectures were once dominant because
the cost of placing computers closer to the end-user was
prohibitive.
 Many (if not most) legacy applications remain centralized on
large mainframe computers (such as IBM’s S/370 and 3090
families of computers) or smaller minicomputers (such as
IBM’s AS/400).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
9
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Presentation:
 This alternative builds upon and enhances centralized
computing applications.
 The old character user interfaces are stripped from the
centralized applications and regenerated as graphical user
interfaces that will run on the PC.
 The user interface (or presentation) is distributed off the server
and onto the client.
 All other elements of the centralized application remain on the
server, but the system users get a friendlier graphical user
interface to the system.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
10
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Presentation:
 Distributed presentation computing advantages:
• It can be implemented relatively quickly since most aspects of the
legacy application remain unchanged.
• Users get a friendly and familiar interface to existing systems
• The useful lifetime of legacy applications can be extended until
such a time as resources warrant a wholesale redevelopment of the
application.

Distributed presentation computing disadvantages:
• The application’s functionality cannot be significantly improved,
and the solution does not maximize the potential of the client’s
desktop computer by only dealing with the user interface.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
11
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Data:
 Sometimes called two-tiered client/server.
 This architecture places the information system’s stored data on
a server, and the business logic and user interfaces on the
clients.
 A local or wide area network usually connects the clients to the
server.
• A local area network (or LAN) is a set of client computers
(usually PCs) connected to one or more server computers (usually
microprocessor-based, but could also include mainframes or
minicomputers) through cable over relatively short distances.
• A wide area network (or WAN) is an interconnected set of LANs,
or the connection of PCs over a longer distance.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
12
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Data:
 The database server is fundamental to this architecture and it’s
technology is different from a file server.
• File servers store the database, but the client computers must
execute all database instructions. This means that entire databases
and tables may have to be transported to and from the client across
the network.
• Database servers also store the database, but the database
commands are also executed on those servers. The clients merely
send their database commands to the server. The server only
returns the result of the database command processing — not
entire databases or tables. Thus, database servers generate much
less network traffic.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
13
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Data:
 The clients in the distributed database solution typically run the
business logic of the information system application.
 Distributed data computing advantages:
• Separates data and business logic to (1) isolate each from changes
to the other, (2) make the data more available to users, and (3)
retain the data integrity of centralized computing through centrally
managed servers.

Distributed data computing disadvantages:
• The application logic must be maintained on all of the clients.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
14
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Data and Logic:
 Referred to as three-tiered or n-tiered client/server computing.
 This approach distributes databases and business logic to
separate servers.
 Uses the same database server(s) as in the two-tiered approach.
 Uses an application server.
• The application server provides a transaction monitor such as to
manage transactions.
• Some or all of the business logic of the application can be moved
from the client to the application server.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Only the user interface and some relatively stable or personal
business logic need be executed on the clients.
15
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

Distributed Data and Logic:
 Distributed data and logic computing disadvantages:
• Very complex to design and development.
• The most difficult aspect of three-tier client/server application
design is partitioning.
– Partitioning is the act of determining how to best distribute or
duplicate application components (data, process, and
interfaces) across the network.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
16
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Internet and Intranets:
 The Internet is an (but not necessarily ‘the’) information
superhighway that permits computers of all types and sizes, all
over the world to exchange data and information using standard
languages and protocols.
 An intranet is a secure network, usually corporate, that uses
Internet technology to integrate desktop, workgroup, and
enterprise computing into a single cohesive framework.
• The intranet provides management and users with a common
interface to applications and information
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
17
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Internet and Intranets:
 Java is a cross-platform programming language designed
specifically to exploit the Internet standards.
• Java applets (modular software components) are stored on an
Internet or intranet server and downloaded to the client when they
access the application.
• Java applets can execute on any client computing platform.

A network computer (or NC) is designed to only run Internetbased applications (such as web browsers and Java applets).
• The NC (also called a thin client) is simpler, and much cheaper
than personal computers (increasingly called a fat client).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
18
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Role of Network Technologies:
 The well designed network provides connectivity and
interoperability.
• Connectivity defines how computers are connected to “talk” to
one another.
• Interoperability is an ideal state in which connected computers
cooperate with one another in a manner that is transparent to their
users (the clients).
• Network topology describes how a network provides connectivity
between the computers on that network.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
19
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Distributed Presentation
Network
All data on the
mainframe server
User Interface
on the PC Client
All business logic on
the mainframe server
Distributed Data (2-tier)
Network
Logic & user
interface on PC
Data and DB
process on server
Distributed Data & Logic (3-tier)
Network
Network
User interface
on the PC client
Business logic on
application server
Data on DB process
on Server
Internet and Intranet
Secure intranet
provides access
to data, logic,
and interfaces
Network
Data on database
server
Secure
connection
to database
server
Some logic on
Intranet Server
Secure Gateway
to protect applications
and data
Connection
to outside
world
Internet Connection
provides access to
interfaces and
some logic
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Some logic on
Internet Server
20
Internal user
interface on PC
External user
PC client
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Role of Network Technologies:
 The Bus network topology:
• A direct point-to-point link between any two computer systems.
• The simplest network topology.
• The network can contain mainframes, minicomputers (or midrange computers), personal computers, and dumb and intelligent
terminals.
• To completely connect all points between n computers, you would
need n times (n-1)/2 direct paths.
• Only one computer can send data through the bus at any given
time.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
21
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Role of Network Technologies:
 The Ring network topology:
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• Connects multiple computers and some peripherals into a ring-like
structure.
• Each computer can transmit messages, instructions, and data
(called packets) to only one other computer (or node on the
network).
• Every transmission includes an address.
• When a computer receives a packet, it checks the address and if
the packet’s address is different than the computer’s address, it
passes it on to the next computer or node.
• Ring networks generally transmit packets in one direction;
therefore, many computers can transmit at the same time to
increase network throughput.
22
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Role of Network Technologies:
 The Star network topology:
• Links multiple computer systems through a central computer.
• The central computer does not have to be a mainframe or
minicomputer.
• Central computer could be an application server that manages the
transmission of data and messages between the other clients and
servers (as in the n-tier model).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
23
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Network Architectures for Client/Server Computing

The Role of Network Technologies:
 The Hierarchical network topology:
• Can be thought of as a multiple star network, where the
communications processors are arranged in a hierarchy.
• The top computer system (usually a mainframe) controls the entire
network.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
All network topologies operate according to established
network protocols that permit different types of computers to
communicate and interoperate.
24
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Data Architectures for Distributed Relational
Databases

The underlying technology of client/server computing has made it
possible to distribute data without loss of centralized control.
 This control is being accomplished through distributed
relational databases.
• A relational database stores data in a tabular form. Each file is
implemented as a table. Each field is a column in the table. Each
records in the file is a row in the table. Related records between
two tables are implemented by intentionally duplicating columns
in the two tables.
• A distributed relational database distributes or duplicates tables
to multiple database servers (and in rare cases, clients).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
25
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Data Architectures for Distributed Relational
Databases

The software required to implement distributed relational
databases is called a distributed relational database management
system.
 A distributed relational database management system (or
distributed RDBMS) is a software program that controls
access to, and maintenance of the stored data. It also provides
for backup, recovery and security. It is sometimes called a
client/server database management system.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
26
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Data Architectures for Distributed Relational
Databases

What sets a distributed RDBMS apart from a PC RDBMS is the
database engine.
 The database engine is that part of the DBMS that executes
database commands to create, read, update, and delete records
(rows) in the tables.
• In a PC RDBMS, the database engine that processes all database
commands must execute on the client PC, even if the data is
actually stored on the server.
• In a distributed RDBMS, the database engine that processes all
database commands executes on the database server.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
27
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Data Architectures for Distributed Relational
Databases


True data distribution partitions data to one or more database
servers.
 Entire tables can be allocated to different servers, or subsets of
rows in a table can be allocated to different servers.
 An RDBMS controls access to and manages each server.
Data replication duplicates data on one or more database servers.
 Entire tables can be duplicated on different servers, or subsets
of rows in a table can be duplicated to different servers.
 The RDBMS not only controls access to, and management of
each server database — it also ensures that updates on one
server are updated on any server where the data is duplicated.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
28
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Batch Input/Output:
 In batch processing, transactions are accumulated into batches
for periodic processing.
• The batch inputs are processed against master files or databases.
• Transaction files or databases may also be created or updated by
the transactions.
• Most outputs tend to be generated to paper or microfiche on a
scheduled basis.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
29
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

On-line Processing:
 The majority of systems have slowly evolved from batch
processing to on-line processing.
 On-line systems provide for a conversational dialogue between
user and computer.
 Business transactions and inquiries are often best processed
when they occur.
• Errors are identified and corrected more quickly.
• Transactions tend to be processed earlier since on-line systems
eliminate the need for batch data file preparation.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
On-line methods permit greater human interaction in decision
making, even if the data arrives in natural batches.
30
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Remote Batch:
 Remote batch combines the best aspects of batch and on-line
I/O.
 Distributed on-line computers handle data input and editing.
 Edited transactions are collected into a batch file for later
transmission to host computers that process the file as a batch.
 Results are usually transmitted as a batch back to the original
computers.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
31
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Keyless Data Entry:
 Keying errors have always been a major source of errors in
computer inputs (and inquiries).
 In batch systems, keying errors can be eliminated through
optical character reading (OCR) and optical mark reading
(OMR) technology.
 The real advances in keyless data entry are coming for on-line
systems in the form of auto-identification systems.
• Bar coding systems (similar to universal product code systems that
are commonplace in the grocery and retail industries) are widely
available for many modern applications.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
32
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Pen Input:
 Some businesses use this technology for remote data collection.
• For example, UPS.

A promising technology is emerging in the form of handheld
PCs (HPCs).
• Similar to personal organizers and personal data assistants, these
HPCs offer greater compatibility with desktop and laptop PCs.
• Based on Microsoft’s Windows CE operating system, they can be
programmed to become disconnected clients in a client/server
application.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
33
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Graphical User Interfaces:
 GUI technology has become the user interface of choice for
client/server applications.
 GUIs do not automatically make an application better.
 Poorly designed GUIs can negate the alleged advantages of
consistent user interfaces.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
34
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Graphical User Interfaces:
 Most users interface with the Internet via a client software tool
called a browser.
• The browser paradigm is based on hypertext and hyperlinks.
– Hypertext are keywords that are clearly highlighted as a link to
a new page of information.
– Hyperlinks are links from graphics, buttons, and areas that link
to a different page of information.
• These links may it easy to navigate from page-to-page and
application-to-application.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
35
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Electronic Messaging and Work Group Technology:
 Information systems are being designed to directly incorporate
the electronic mail.
• For example, Microsoft Outlook and Exchange Server and
IBM/Lotus Notes allow for the construction of intelligent
electronic forms that can be integrated into an application.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
36
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Electronic Data Interchange:
 Businesses that operate in many locations and businesses that
seek more efficient exchange of transactions with their
suppliers and/or customers often utilize electronic data
interchange.
• Electronic data interchange (EDI) is the electronic flow of
business transactions between customers and suppliers.
With EDI, a business can eliminate its dependence on paper
documents and mail, plus dramatically reduce response time..
 Various EDI standards exist for the standardized exchange of
data between organizations within the same industry.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
37
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Imaging and Document Interchange:
 Similar to EDI except that the actual images of forms and data
are transmitted and received.
 It is particularly useful in applications in which the form images
or graphics are required. (insurance industry)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
38
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Middleware:
 Information systems must also interface to other information
systems.
• System integration is the process of making heterogeneous
information systems (and computer systems) interoperate.

A key technology used to interface and integrate systems is
middleware.
• Middleware is utility software that serves to interface systems
built with incompatible technologies. Middleware serves as a
consistent bridge between two or more technologies. It may be
built into operating systems, but it is also frequently sold as a
separate product.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
39
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Interface Architectures - Inputs, Outputs, &
Middleware

Selecting User and System Interface Technologies:
 The preferred or approved user and system interface
technologies may be specified as part of the Interface
architecture.
 An organization may leave interface technologies as a decision
to be made on a project-by-project basis.
 An organization may establish macro guidelines for interfaces
and leave the micro decisions to individual projects.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
40
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

The PROCESS architecture of an application is defined in terms of
the software languages and tools that will be used to develop the
business logic and application programs.
 This is expressed as a menu of choices since different software
development environments (SDEs) are suited to different
applications.
• A software development environment is a language and tool kit
for constructing information system applications. They are usually
built around one or more programming languages such as COBOL,
Basic, C or C++, Pascal, Smalltalk, or Java.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
41
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Centralized Computing & Distributed Presentation:
 The software development environment for centralized
computing consists of:
• An editor and compiler, usually COBOL, to write programs.
• A transaction monitor, usually CICS, to manage on-line
transactions and terminal screens.
• A file management system, such as VSAM, or a database
management system, such as DB2.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
42
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Centralized Computing & Distributed Presentation:
 The personal computer brought many new COBOL
development tools down to the mainframe.
• A PC-based COBOL SDE provided the programmer with more
powerful editors, and testing and debugging tools at the
workstation level.
• A programmer could do much of the development work at the PC
level, and then upload the code to the central computer for system
testing, performance tuning, and production.
• The SDE could be interfaced with a CASE tool and code generator
to take advantage of process models developed during systems
analysis.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
43
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Centralized Computing & Distributed Presentation:
 SDEs provide tools to develop distributed presentation
client/server.
• The Micro Focus Dialog Manager provided COBOL Workbench
users with tools to build Windows-based user interfaces that could
cooperate with the CICS transaction monitors and the mainframe
COBOL programs.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
44
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Two-Tier Client/Server:
 The SDE for two-tiered client/server applications (also called
distributed data) consists of a client-based programming
language with built-in SQL connectivity to one or more server
database engines.
 SDEs provide the following:
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• Rapid application development (RAD) for quickly building the
graphical user interface that will be replicated and executed on all
of the client PCs.
• Automatic generation of the template code for the above GUI and
associated system events (such as mouse-clicks, keystrokes, etc.)
that use the GUI. The programmer only has to add the code for the
business logic.
45
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Two-Tier Client/Server:
 SDEs provide the following: (continued)
• A programming language that is compiled for replication and
execution on the client PCs.
• Connectivity (in the above language) for various relational
database engines, and interoperability with those engines.
Interoperability is achieved by including SQL database commands
(to, for example, create, read, update, delete, and sort records) that
will be sent to the database engine for execution on the server.
• A sophisticated code testing and debugging environment for the
client.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
46
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Two-Tier Client/Server:
 SDEs provide the following: (continued)
• A system testing environment that helps the programmer develop,
maintain, and run a reusable test script of user data, actions, and
events against the compiled programs to ensure that code changes
do not introduce new or unforeseen problems.
• A report writing environment to simply the creation of new enduser reports off a remote database.
• A help authoring system for the client PCs.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
47
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for MultiTier Client/Server:
 Unlike two-tied applications, n-tiered applications must support
more than 100 users with mainframe-like transaction response
time and throughput; with 100 gigabyte or larger databases.
 The SDEs in this class must provide the all of the capabilities
typically associated with two-tiered SDEs plus the following:
• Support for heterogeneous computing platforms, both client and
server, including Windows, OS/2, UNIX, Macintosh, and legacy
mainframes and minicomputers.
• Code generation and programming for both clients and servers.
Most tools in this genre support pure object-oriented languages
such as C++ and Smalltalk.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
48
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for MultiTier Client/Server:
 The SDEs in this class must provide the all of the capabilities
typically associated with two-tiered SDEs plus the following:
(continued)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• A strong emphasis on reusability using software application
frameworks, templates, components, and objects.
• Bundled mini-case tools for analysis and design that interoperate
with code generators and editors.
• Tools to help analysts and programmers partition application
components between the clients and servers.
• Tools to help developers deploy and manage the finished
application to clients and servers. This generally includes security
management tools.
49
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for MultiTier Client/Server:
 The SDEs in this class must provide the all of the capabilities
typically associated with two-tiered SDEs plus the following:
(continued)
• Ability to automatically ‘scale’ the application to larger and
different platforms, client and server. This issue of scalability was
always assumed in the mainframe computing era, but is relatively
new to the client/server computing era.
• Sophisticated software version control and application
management.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
50
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

SDEs for Internet and Intranet Client/Server:
 Most of these rapid application development tools are built
around three core standard technologies:
• HTML (Hypertext Markup Language) — the language used to
construct world wide web pages and links.
• CGI (Computer Graphics Interface) — a language for
publishing graphical world wide web components and links
• Java — a general purpose programming language for creating
platform-independent programs and applets that can execute across
the world wide web.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
These SDEs can create both Internet, intranet, and nonInternet/intranet applications.
51
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Information Technology Architecture

Process Architecture - The Software Development
Environment and System Management

System Management:
 Client/server computing applications usually require one or
more of the following common process development and
management tools:
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• Transaction Processing (TP) Monitors — software that ensures
that all of the data associated with a single business transaction is
processed as a single transaction amongst all of the parallel
business transactions that may be in the system at the same time.
• Version Control and Configuration Managers — software that
tracks on-going changes to software that is usually developed by
teams of programmers. The software also allows management to
rollback to a prior version of an application if the current version
encounters unanticipated problems.
52
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

The Enterprise Application Architecture Strategy


In this strategy, the organization develops a enterprise wide
information technology architecture to be followed in all
subsequent information system development projects.
This IT architecture defines the following:
 The approved network, data, interface, and processing
technologies and development tools (inclusive of hardware and
software; and clients and servers).
 A strategy for integrating legacy systems and technologies into
the application architecture.
 An on-going process for continuously reviewing the application
architecture for currency and appropriateness.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
53
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

The Enterprise Application Architecture Strategy

This IT architecture defines the following: (continued)
 An on-going process for researching emerging technologies and
making recommendations for their inclusion in the application
architecture.
 A process for analyzing requests for variances from the
approved application architecture. (You may recall that
SoundStage received such a variance to prototype object
technology in the member services system project.)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
54
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

The Tactical Application Architecture Strategy



In the absence of an enterprise wide application architecture, each
project must define its own architecture for the information system
being developed.
The developers usually have somewhat greater latitude in
requesting new technologies, but they must be defended and
approved as feasible.
IT feasibility usually includes the following aspects:
 Technical feasibility — This can either be a measure of a
technology’s maturity, or a measure of the technology’s
suitability to the application being designed, or a measure of the
technology’s ability too work with other technologies.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
55
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

The Tactical Application Architecture Strategy

IT feasibility usually includes the following aspects: (continued)
 Operational feasibility — This is a measure of how
comfortable the business management and users are with the
technology, and how comfortable the technology managers and
support personnel are with the technology.
 Economic feasibility — This a measure of both whether or not
the technology can be afforded, and whether it is cost effective,
meaning the benefits outweigh the costs.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
56
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

Build versus Buy Implications


One of the most fundamental software decisions in any project is
build versus buy — should we design and build the software inhouse, or should we purchase the software as a package?
 The packages are referred to as COTS — commercial of the
shelf.
Many organizations have made an enterprise IT decision to always
purchase those applications that do not significantly add
competitive advantage to the business.
 Typically, these include human resources (and payroll),
financial systems, and systems subject to frequent regulatory
change (such as college financial aid).
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
57
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

Build versus Buy Implications

The purchase of application software does not invalidate systems
analysis and design, but it does, however, change the methodology
and project in the following ways:
 Alternative application software packages must be analyzed
against the user requirements, and any unfilled business
requirements must be identified.
 Options and preferences within the chosen software package
must be analyzed and selected. (Most packages allow various
one-time and on-going customization.)
 Business processes and documents must be analyzed and
redesigned to interoperate with the selected software.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
58
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Application Architecture Strategies &
Design Implications

Build versus Buy Implications


The purchase of application software does not invalidate systems
analysis and design, but it does, however, change the methodology
and project in the following ways: (continued)
 Transition processes must be analyzed and designed to import
data from legacy systems into the new software’s files and
databases.
 The application software’s interfaces to other information
systems must be analyzed and designed.
 Any unmet business requirements are subject to analysis and
design as extensions to the chosen software package
Purchased application software may also be subject to any IT
architectural standards adopted by a business.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
59
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

DFDs can also be used to model the physical (meaning ‘technical’)
design of the system.
 Physical data flow diagrams model the technical and human
design decisions to be implemented as part of an information
system. They communicate technical and other design
constraints to those who will actually implement the system—
in other words, they serve as a technical blueprint for the
implementation.
• Physical DFDs use the same shapes and connections as logical
DFDs: processes, external agents, data stores, and data flows.
Only the naming standards (and a few new rules) are changed to
extend the language to document technology and design decisions.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
60
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
You
Bank
Monthly
Statement
(Printed Form)
Beginning and Ending Balance
(Windows Dialog Box)
Verify balances
and transactions
(You)
Revised Transactions
(Create, Delete, Update)
Cleared
Transactions
(Window Checkboxes)
This diagram
is intentionally
incomplete and
oversimplified
Reconcile account
balances
(Quicken)
Teller Receipt
(Printout Form)
Cleared Transactions
(Update)
Bill
(Paper Invoice)
Bill
(Electronic Invoice)
Plan payment of
the bill
(You)
Schedule a
payment
(Quicken)
Transaction
(Create,
Update)
Record deposit or
withdrawal
Transaction
(Create, Delete, or Update)
ATM Receipt
(ATM printout)
Direct
Deposit
Reminder
(read)
Reusuable
Transaction
Details
(Read)
Check
(Electronic
Fund Transfer)
Time to pay a bill
Pay a bill
Make a
withdrawal
(ATM)
Memorized and Scheduled
Transactions
(Quicken File)
Customer PIN (bank card)
and
Withdrawal Info (keypad)
Check
(Hand)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Make a deposit or
withdrawal at the
bank
(You)
Reconciliation Report
(Window and/or Printed Report)
Memorized or Scheduled Transaction
(Create, Delete, or Update)
Check
(Printed)
Withdrawal
(verbal)
Transactions
and
Balances
(Read)
Account Register
(Quicken File)
Creditor
Deposit Slip
(Form)
Transaction Due
(Read)
You
Paid Transaction
(Update)
61
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Processes:
 Recall that processes are the key shapes on any DFD.
• A physical process is either (1) a processor, such as a client PC,
network server, or robot; or (2) specific work or actions to be
performed on incoming data flows to produce outgoing data flows.
In the latter case, the physical process must clearly designate
which person(s) or what technology(s) will be assigned to do the
work.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
62
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Processes:
 There are two elements to physical data flow diagrams:
• Logical processes are frequently assigned to specific physical
processors such as clients, servers, or other devices in a computer
network. To this end, we might draw a physical DFD called a
network topology data flow diagram for the information system.
• Subsequently, logical processes are usually implemented as one or
more physical processes.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
63
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Processes:
• Some logical processes must be split into multiple physical
processes for the following reasons:
– To split the process into that portion performed by a person and
that portion performed by the computer.
– To split the process into that portion to implemented with one
technology, and that portion to be implemented with a different
technology.
– To show multiple, different implementations of the same
logical process (such as processing a paper order versus
processing a phone order).
– To add processes that are necessary to implement audit and
control requirements, or handle exceptions.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
64
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

ID# (opt)
action verb + object
clause
implementation
method
Physical Data Flow Diagrams

Physical Processes:
 Process names use the action verb + object clause convention,
however, the name is preceded or followed by an
implementation method. The format is:
• implementation method : action verb + object clause
• action verb + object clause : implementation method
ID# (opt)
implementation
method : action
verb + object
clause

ID# (opt)
action verb +
object clause
(implementation
method)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
If a logical process is to be implemented partially by people and
partially by software, it must be split into separate physical
processes and appropriate data flows must be added between
the physical processes.
• The name of a physical process to be performed by people, not
software, should indicate who will perform that process.
65
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Processes:
 For computerized processes, the implementation method is, in
part, chosen from one of the following methods:
•
•
•
•
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
A purchased software package, possibly to be selected.
A productivity or utility program.
An existing application program from a program library.
A program to be written.
66
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Processes:
 The number of processes on a physical DFD will usually be
greater than the number of processes on its equivalent logical
DFD.
• Processes may be added to reflect data flow collection, filtering,
forwarding, preparation, business controls—all in response to the
implementation target that has been selected.
• Some logical processes may be split into multiple physical
processes to reflect portions of a process to be done manually
versus by a computer, to be implemented with different
technology, or to be distributed to clients, servers, or different host
computers.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
67
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Data Flows:
 Recall that all processes have at least one input and one output
data flow.
 A physical data flow represents the planned implementation of
an input to or output from a physical process. It can also
indicate database action such as create, delete, read, or update a
record. It can also represent the import of data from, or the
export of data to another information system across a network.
Finally, it can represent the data flows data between two
modules or subroutines within the same program.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
68
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

implementation method :
data flow name
Physical Data Flows:
 Physical data flow names use one of the following general
formats:
• implementation medium : data flow name
• data flow name : implementation method
data flow name :
(implementation method)
For data transmitted across a network, the implementation
media should indicate the file transfer protocol to be used.
 For data transmitted between processes that are to be part of the
same program, you could specify parameters and variables to
be passed between the program modules.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
69
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Data Flows:
 Physical DFDs must also indicate any data flows to be
implemented as business forms.
• Business forms frequently use a multiple (carbon or carbonless)
copy implementation.
• At some point in processing, the different copies are split and
travel to different manual processes.
– This is shown on an physical DFD as a diverging data flow.
– Each copy should be uniquely named.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
70
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Data Flows:
 Most logical data flows are carried forward to the physical
DFDs.
• Some may be consolidated into single physical data flows that
represent business forms.
• Some may be split into multiple flows as a result of having split
logical processes into multiple physical processes.
• Some may be duplicated as multiple flows with different technical
implementations.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
71
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical External Agents:
 External agents are carried over from the logical DFD to the
physical DFD unchanged.
• Because, by definition, external agents were classified during
systems analysis as outside the scope of the systems and, therefore,
not subject to change.
• Only a change in requirements can initiate a change in external
agents.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
72
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

database name
(implementation
method)
Physical Data Stores:
 Each data store on the logical DFD now represents a data entity
on a normalized entity relationship diagram.
 Most physical data stores represent a single file or a single
database or table in the database. Additional physical data
stores may be added to represent temporary files or batches
necessitated by physical processes.
 The name of a physical data store uses the following format:
implementation
method:
database name
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• file or database implementation method : file, database, or table
name
• file, database, or table name : file or database implementation
method
73
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

Physical Data Flow Diagrams

Physical Data Stores:
 Some designs require that temporary files be created to act as a
queue or buffer between processes.
• Such files are documented in the same manner except that their
name should include some indication of their temporary status.

A design may also include non-computerized files.
• The storage mechanism name replaces the file organization.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
74
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts



Before the popularity of DFDs, systems flowcharts were a popular
tool for modeling design decisions.
 System flowcharts are diagrams that show the flow of control
through a system while specifying all programs, inputs, outputs,
and file/database accesses and retrievals.
The American National Standards Institute (ANSI) has established
certain symbols that have been widely used in the computer
industry to describe the flow of process control in systems.
System flowcharts are supposed to be the basis for communication
between systems analysts, end-users, applications programmers,
and computer operators.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
75
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts

System Flowchart Symbols:
 System flowchart symbols can be conveniently classified into
six subsets:
• There are four symbols for processing:
– the computer program (to be written)
– the library program (that already exists—possibly a utility
program)
– the manual operation (indicating who and/or what—the
symbol is also used as a start or finish symbol in a flowchart)
– the auxiliary operation (used to indicate operations performed
by other office equipment)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
76
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts

System Flowchart Symbols:
 System flowchart symbols can be conveniently classified into
six subsets: (continued)
• There are four symbols for batch input:
– the source document or form (from which data will be keyed
into the system)
– the key-to-punched-card (a dated and increasingly rare batch
input medium)
– the key-to-disk (KTD) or key-to-tape (KTT)
– the optical character (or mark) document (which could also be
used for EDI and imaged documents)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
77
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts

System Flowchart Symbols:
 System flowchart symbols can be conveniently classified into
six subsets: (continued)
• Batch output forms or files are represented by a single printed
output symbol.
– The symbol could also be used for microfiche output.
• System flowcharts show only those files and databases stored on
computers.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
78
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts

System Flowchart Symbols:
 System flowchart symbols can be conveniently classified into
six subsets: (continued)
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
• There are only two symbols: the tape file, and the disk file or
database.
– Because tape files are always sequential, updates always occur
in pairs—an original file is input to a program and a new file is
produced by the program.
– Disk files need not be duplicated since reads and writes are
processed against the same copy of the file or database.
– Databases serve to integrate many files., therefore they can be
depicted as one integrated symbol or as one symbol per file,
record type, or table—depending on what level of detail you
are trying to depict.
79
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts

System Flowchart Symbols:
 System flowchart symbols can be conveniently classified into
six subsets: (continued)
• Most designers show only the net inputs and outputs and exclude
the on-line dialogue that gets you to those inputs and outputs.
– There are two on-line symbols: the on-line input and the online output.
• There are a number of miscellaneous symbols in the ANSI
standard.
– The most important of these symbols is the comment.
– It may be connected via a dashed line to any other symbol to
add information about such things as timing, security, or
instructions.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
80
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

System Flowcharts

Reading System Flowcharts:
 The symbols are connected by one of three lines:
• A single-ended arrow (indicating either the sequence of activities
or processing in the system or a read-only or write-only access to a
file or database).
• A double-ended arrow (indicating read-write operations against
files and databases).
• A jagged-double-ended arrow (indicating on-line dialogue or data
flow).
Unlike DFDs, connections on system flowcharts are not labeled
or named.
 Symbols and connections are combined in classic inputprocess-output patterns to document the design of a system.

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
81
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes

CASE for Physical DFDs and Flowcharts


Most CASE products support DFDs, but don’t distinguish between
logical and physical models.
Some CASE users simply modify the logical DFDs that they
created during systems analysis.
 The problem with that approach is that you are overwriting the
logical DFDs—the requirements themselves!
 A better approach is to copy the logical models and then
transform the copies into physical DFDs.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
82
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Drawing Physical DFDs

Physical DFDs document the high-level, general design of the new
system. An acceptable design results in:
 A system that works.
 A system that fulfills user requirements (specified in the logical
DFDs).
 A system that provides adequate performance (throughput and
response time).
 A system that includes sufficient internal controls (to eliminate
human and computer errors, ensure data integrity and security,
and satisfy auditing constraints).
 A system that is adaptable to ever-changing requirements and
enhancements.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
83
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Drawing Physical DFDs


A single physical DFD, or a set of physical DFDs can be drawn for
the target system.
The FAST methodology calls for the following:
 A physical data flow diagram should be developed for the
network topology.
 For each processor on the above model, a physical data flow
diagram should be developed to show those event processes
that will be assigned to that processor.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
84
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Drawing Physical DFDs

The FAST methodology calls for the following: (continued)
 For all but the simplest event processes, they should be factored
into design units and modeled as a single physical data flow
diagram.
• A design unit is a self-contained collection of processes, data
stores, and data flows that share similar design attributes. A design
unit serves as a subset of the total system whose inputs, outputs,
files and databases, and programs can be designed, constructed,
and unit tested as a single subsystem.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
85
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Prerequisites

The prerequisites to creating physical DFDs include:
 A logical data model.
 Logical process models.
 Logical network model. (optional)
 Repository details for all of the above.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
86
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Prerequisites

Given the previous models and details, data and processes can be
distributed to create a general design.
 The general design will normally be constrained by one or
more of the following:
• Architectural standards that predetermined the choice of database
management systems, network topology and technology, user
interface(s), and/or processing methods.
• Project objectives that were defined at the beginning of systems
analysis and refined throughout systems analysis.
• Feasibility of chosen or desired technology and methods.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
87
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

The Network Topology

The first physical DFD to be drawn is the network topology DFD.
 A network topology DFD is a physical data flow diagram that
allocates processors (clients and servers) and devices (e.g.,
machines and robots) to a network and establishes (1) the
connectivity between the clients and servers, and (2) where
users will interact with the processors (usually, only the
clients).

Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
Network topology DFDs they show highways over which data
flows may travel in either direction.
88
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

The Network Topology


Network topology DFDs indicate the following:
 Servers and their physical locations.
 Clients and their physical locations.
 Processor Specifications.
 Transport protocols.
The network topology DFD can be used to either design a
computer network or to document the design of an existing
computer network.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
89
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Data Distribution and Technology Assignments


The goal of this step is to distribute data stores to the network
processors.
 The required logical data stores are already known from
systems analysis — as data stores on the logical DFDs or as
entities on the logical ERDs.
The following are possible distribution options.
 Store all data on a single server.
 Store specific tables on different servers.
 Store subsets of specific tables on different servers.
 Replicate (duplicate) specific tables or subsets on different
servers.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
90
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Data Distribution and Technology Assignments


The reasons to distribute data storage are as follows:
 Some data instances are of local interest only.
 Performance can often be improved by subsetting data to
multiple locations.
 Some data needs to be localized to assign custodianship of that
data.
Data distribution decisions can be very complex—normally the
decisions are guided by data and database professionals
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
91
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Process Distribution and Technology Assignments

Information system processes can now be assigned to processors as
follows:
 For single-tiered client/server systems, all of the logical event
diagrams are assigned to the server.
 For two-tiered client/server systems, all of the logical event
diagrams are assigned to the client.
 For three-tiered client/server systems, you must closely
examine each event’s primitive (detailed data flow diagram.
• In general, data capture and editing is assigned to clients, and other
business logic is assigned to servers.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
92
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

Process Distribution and Technology Assignments

After partitioning, each physical DFD corresponds to a design unit
for a given business event.
 For each of these design units, you must assign an
implementation method, the SDE that will be used to
implement that process.
 You must also assign implementation methods to the data
flows.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
93
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Designing the Application Architecture &
the Information System Processes

The Person/Machine Boundaries


The last step of process design is to factor out any portion of the
physical DFDs that represent manual, not computerized processes.
 This is sometimes called “establishing a person/machine
boundary.”
Establishing a person/machine boundary becomes complex when
the person/machine boundary cuts through a logical process—in
other words, part of the process is to be manual and part is to be
computerized.
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
94
Copyright Irwin/McGraw-Hill 1998
Application Architecture & Process
Design
Summary





Introduction
General System Design
Information Technology Architecture
Application Architecture Strategies & Design
Implications
Designing the Application Architecture & the
Information System Processes
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley
95
Copyright Irwin/McGraw-Hill 1998