Get documents about "Information Architecture Flowchart - PowerPoint
Description
Information Architecture Flowchart document sample
Document Sample
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?
1
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?
2
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?
3
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.
4
Application Architecture & Process
Design
INFORMATION SYSTEMS FRAMEWORK
FOCUS ON FOCUS ON FOCUS ON FOCUS ON System
SYSTEM SYSTEM SYSTEM SYSTEM
DATA PROCESSES INTERFACES GEOGRAPHY Development
Business Subjects Business Functions System Context Operating Locations Survey Phase
Accounts
Customers order zero,
Marketing
Receivable
Database
(establish scope
Credit
SYSTEM one, or more products. and project plan)
OWNERS Products may be ordered Order
Picking
Customer Order Management Warehouse
by zero, one, or more Advertising Sales System
Order
customers.
(scope) Credit
Voucher
Orders Cancellations Services
Bank
Study Phase
(establish system
improvement
Data Requirements Business Processes Interface Requirements Communication Reqts.
rejec ted order
St.
objectives)
PRODUCT EDI
order Louis
catalog Products
c redit C ust changes C at alog
CUSTOMER product-no C us tomer s
C hec k HQ
c redit
customer-no product-name
customer-name unit-of-measure c us tomer
SYSTEM customer-rating unit-price number order with
approv ed order
W est ship East
S balance-due quantity-av ailable
v alid produc ts ra r al s
Firec cke S e
C ust omers order C ust omers
USERS
Y order Validate
c us tomer
v alid order Validate
produc ts Orders
credit credit
S approv ed
LA ship Indy
W are- ship order
NY
(requirements) ORDER order without pric es order
Office order
house
Office
T order-no v alid
c us tomer service
order-date pick ing
E products-ordered
Produc ts
quantity
in s toc k
R eleas e
order
tic k et
Maintenance
quantities-ordered R ecords
M Definition Phase
A (establish and
N
A
prioritize business
Database Scehma Application Schema Interface Schema Network Schema
L Or der
P r ocessing
N ew Customer
C ust omer
Form
system requirements)
Y PRODUCT
P r ogr am
CUSTOMER Logon Order Accepted
product_no [Alpha(10)] INDEX
S customer_no [Alpha (10)] INDEX product_name [Alpha(32)] Initiation P r ocess S hutdown
C hange
of
Communications
Controller
St. Louis
Mainframe
customer_name [Alpha(32)]
T SYSTEM unit_of_measure [Alpha(2)]
customer_rating [Alpha(1)] INDEX unit_price [Real(3,2)]
Routine an Or der Routine
N ew Order A ddress
balance_due [Real(5,2)] NT Server LA
S DESIGNERS quantity_available [Integer(4)]
Get an V alidate File an Order Help C omplete Order Form First Order
Or der an Or der Or der PBX NT Server NY
Ethernet LAN/NT
R equest
R equest Order H elp
Product Ethernet LAN/NT
(specification) ORDER ORDER_PRODUCT
Check
Custom er
Cr edit
Check
P r oduct
Data
Check
Cr edit
Data
Release
an
Or der
Lookup
order_no [Alpha(12)] INDEX ORDER.order_no H elp +
R equest Product Lookup Help
order_date [Date(mmddyyyy) PRODUCT.product_no Indy AIX Ser ver Client PC Client PC
CUSTOMER.customer_no quantity_ordered [Integer(2) Product Client PC Client PC
Or der s Product Lookup Help C omplete Enternet LAN AIX/Lan
Custom er s P r oducts Lookup Manager
Design/Constructio
n Phases
(design and develop
the system solution)
Database Process Interface Network
SYSTEM Decisions Decisions Decisions Decisions
BUILDERS
(components)
Implementation
Phase
(deliver the new
system into
operation)
Interface
INFORMATION
Processor and Architecture Networking
TECHNOLOGY
Database Software Architecture Architecture
ARCHITECTURE Architecture Architecture Project
or
Configuration
5
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.
6
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.
7
Application Architecture & Process
Design
Centralized Distributed Presentation Distributed Database Distributed Data/Logic Internet/Intranet
Computing Computing Computing Computing Computing
What is the A database server is usually
The server is usually a The server is usually a Typically. data and business logic Utilizes data and/or file servers as
microprocessor-based (e.g., UNIX
server and minicomputer or mainframe, minicomputer (e.g., OS/400 OS) or
or Windows/NT Server) but could
(and possibly other services) are in previous two columns, but adds
possibly networked to other mainframe computer (e.g. MVS, on separate servers (same OS's as one or more Internet and intranet
operating still be a mainframe or
minicomputers or mainframes. VM, or UNIX OS). in previous column). servers.
system? minicomputer.
All data is stored on the server All data is stored on the server
Where are All data is stored on the server and All data is stored on the server and All data is stored on the server and
(possibly multiple servers) and all (possibly multiple servers) and all
database all file and database access and all file and database access and all file and database access and
file and database access and file and database access and
update commands and instructions update commands and instructions update commands and instructions
commands update commands and instructions update commands and instructions
are executed on the server are executed on the server are executed on the server
are executed on the server are executed on the server
executed? computer. computer. computer.
computers. computers.
Local
Area
Network Most business logic is programmed Appropriate business logic is
to execute on the server. programmed to execute on the
Where is
server.
the All business logic is programmed All business logic is programmed
business to execute on the server. to execute on the server. Local Local
All business logic is programmed
logic to execute on the client using a Area Area
Resulting data files may be Resulting data files may be
instruction PC-based programming language. Network Network
transferred to another server transferred to another server
s across the network. across the network.
Some business logic may be Appropriate business logic may be
executed? programmed to execute on the downloaded from Inter/intranet
client. server to execute on the client.
The user interface (usually The user interface (usually The user interface (usually The user interface (usually Intranet
non-graphical) is stored and graphical) is stored and executed graphical) is stored and executed graphical) is stored and executed or
Where are executed on the server. on the client. on the client. on the client.
Internet
user/syste Wide Local or Wide Wide
m interface Area Wide Area Area Area User interfaces may be stored and
Network Network Network executed on the client, or
instruction Network downloaded from the Internet or
s intranet for execution on the client.
executed? Any system interfaces are either Any system interfaces are either Any system interfaces are either Any system interfaces are either
executed on the server or across executed on the server or across executed on the server or across executed on the server or across System interfaces are managed
the network on another server. the network on another server. the network on another server. the network on another server. from the Internet or intranet.
What is the The clients are personal The clients are personal The clients are personal In addition to fat clients (see
The clients are either dumb
computers or workstations computers or workstations computers or workstations previous column), some clients
client and (non-programmable) terminals, or
(sometimes called fat clients) (sometimes called fat clients) (sometimes called fat clients) may be network computers (also
operating PCs (any OS) that are emulating
running Windows 9x, Windows NT, running Windows 9x, Windows NT, running Windows 9x, Windows NT, called NCs or thin clients) that only
dumb terminals using software.
system? OS/2, or Macintosh OS. OS/2, or Macintosh OS. OS/2, or Macintosh OS. execute downloaded programs
8
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).
9
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.
10
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.
11
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.
12
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.
13
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.
14
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.
Only the user interface and some relatively stable or personal
business logic need be executed on the clients.
15
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.
16
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
17
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 Internet-
based 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).
18
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.
19
Application Architecture & Process
Design
Distributed Presentation
Network
User Interface
All data on the
All business logic on on the PC Client
mainframe server
the mainframe server
Distributed Data (2-tier)
Network
Logic & user
Data and DB interface on PC
process on server
Distributed Data & Logic (3-tier)
Network Network
User interface
Business logic on on the PC client
Data on DB process
application server
on Server
Internet and Intranet
Secure intranet
provides access
Network to data, logic,
and interfaces Internal user
Data on database Some logic on interface on PC
server Intranet Server
Secure Secure Gateway Connection
connection to protect applications to outside
to database and data world
server
Internet Connection
provides access to
interfaces and
some logic External user
Some logic on PC client
Internet Server
20
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 mid-
range 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.
21
Application Architecture & Process
Design
Information Technology Architecture
Network Architectures for Client/Server Computing
The Role of Network Technologies:
The Ring network topology:
• 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
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).
23
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.
All network topologies operate according to established
network protocols that permit different types of computers to
communicate and interoperate.
24
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).
25
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.
26
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.
27
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.
28
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.
29
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.
On-line methods permit greater human interaction in decision
making, even if the data arrives in natural batches.
30
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.
31
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.
32
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.
33
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.
34
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.
35
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.
36
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.
37
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)
38
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.
39
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.
40
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.
41
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.
42
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.
43
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.
44
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:
• 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
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.
46
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 end-
user reports off a remote database.
• A help authoring system for the client PCs.
47
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.
48
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)
• 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
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.
50
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.
These SDEs can create both Internet, intranet, and non-
Internet/intranet applications.
51
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:
• 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
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.
53
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.)
54
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.
55
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.
56
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 in-
house, 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).
57
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.
58
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.
59
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.
60
Application Architecture & Process
Design Deposit Slip
(Form)
You
Beginning and Ending Balance
Monthly Verify balances (Windows Dialog Box) Withdrawal
Bank Statement and transactions Revised Transactions (verbal)
(Printed Form) (You) (Create, Delete, Update) Make a deposit or
withdrawal at the
Transactions bank
Cleared Reconcile account (You)
and
Transactions balances
Balances
(Window Checkboxes) (Quicken)
(Read)
Teller Receipt
This diagram Reconciliation Report (Printout Form)
is intentionally (Window and/or Printed Report)
incomplete and
Cleared Transactions
oversimplified (Update)
Transaction
Account Register Record deposit or
(Create,
(Quicken File) withdrawal
Update)
Bill
(Paper Invoice) Plan payment of Schedule a
Creditor the bill Transaction
payment
Bill (You) (Create, Delete, or Update)
(Quicken)
(Electronic Invoice)
ATM Receipt
(ATM printout)
Memorized or Scheduled Transaction Direct
(Create, Delete, or Update) Deposit
Reminder
Make a
(read)
withdrawal
(ATM)
Check Reusuable
Check Memorized and Scheduled
(Electronic Transaction
(Printed) Transactions
Fund Transfer) Details
(Quicken File)
(Read)
Customer PIN (bank card)
Check and
(Hand) Withdrawal Info (keypad)
Transaction Due
Time to pay a bill You
(Read)
Pay a bill
Paid Transaction
(Update)
61
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.
62
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.
63
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.
64
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes
Physical Data Flow Diagrams
ID# (opt) Physical Processes:
action verb + object
clause
Process names use the action verb + object clause convention,
implementation
method
however, the name is preceded or followed by an
implementation method. The format is:
ID# (opt) • implementation method : action verb + object clause
implementation
method : action
• action verb + object clause : implementation method
verb + object
clause If a logical process is to be implemented partially by people and
partially by software, it must be split into separate physical
ID# (opt)
processes and appropriate data flows must be added between
action verb + the physical processes.
object clause
(implementation
method)
• The name of a physical process to be performed by people, not
software, should indicate who will perform that process.
65
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:
• 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
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.
67
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.
68
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes
Physical Data Flow Diagrams
Physical Data Flows:
Physical data flow names use one of the following general
implementation method :
data flow name formats:
• implementation medium : data flow name
data flow name :
• data flow name : implementation method
(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.
69
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.
70
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.
71
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.
72
Application Architecture & Process
Design
Modeling Application Architecture &
Information System Processes
Physical Data Flow Diagrams
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.
database name
The name of a physical data store uses the following format:
(implementation
method) • file or database implementation method : file, database, or table
name
implementation
method:
database name
• file, database, or table name : file or database implementation
method
73
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.
74
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.
75
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)
76
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)
77
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.
78
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 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
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 on-
line 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.
80
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 input-
process-output patterns to document the design of a system.
81
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.
82
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.
83
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.
84
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.
85
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.
86
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.
87
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).
Network topology DFDs they show highways over which data
flows may travel in either direction.
88
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.
89
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.
90
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
91
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.
92
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.
93
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.
94
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
95
