13 Application Architecture and Modeling

13

Application Architecture and Modeling

Overview

Chapter 13 teaches the student how to make the up-front architectural deci-sions that we used to refer to as general systems design, and how to model those decisions using physical data flow diagrams. This chapter also serves to stimulate the reader’s imagination and creativity with respect to the many ar-chitectural and technological choices that can and should be made during gen-eral systems design inclusive of network, database, interface, and software de-velopment technologies.

Chapter to Course Sequencing

Students are encouraged to first read Chapter 12, Systems Design, before this chapter. It is also assumed that the reader is familiar with logical data flow diagrams (Chapter 9). The feasibility analysis techniques taught in Chapter 10 are useful, but not essential.

Looking to the future, we expect DFDs to eventually give way to object-oriented analysis techniques using UML equivalents such as deployment mod-els. We actively seek adopter input as to how to handle the transition. Clearly, DFDs will not go away overnight.

For the time being, we recommend that this chapter be at least surveyed prior to introducing our object-oriented design coverage in Chapter 18.

What’s different here and why?

This chapter did not necessitate many changes from the sixth edition.

1. As with all chapters, we have streamlined the SoundStage episode into a quick narrative introduction to the concepts presented the chapter.

2. We updated all technology references throughout the chapter.

13-2 Chapter Thirteen

Copyright © 2007 The McGraw-Hill Companies. All Rights reserved.

Lesson Planning Notes for Slides

The following instructor notes, keyed to slide images from the PowerPoint repository, are intended to help instructors integrate the slides into their indi-vidual lesson plans for this chapter.

Slide 1

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

Chapter 13

Application Architecture and Modeling

slide appearance after initial mouse click in slide show mode

This repository of slides is intended to support the named chapter. The slide repository should be used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector. Each slide includes instructor notes. To view those notes in PowerPoint, click-left on the View Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor notes. The instructor notes are also available in hard-copy as the Instructor Guide to Accompany Sys-tems Analysis and Design Methods, 6/ed.

Slide 2

13-2

Objectives

• Define an information system’s architecture in terms of the KNOWLEDGE, PROCESSES, and COMMUNICATION building blocks.

• Differentiate between logical and physical data flow diagrams, and explain how physical data flow diagrams are used to model an information system’s architecture.

• Describe centralized and distributed computing alternatives, including client/server and Internet-based computing options.

• Describe database and data distribution alternatives for system design.

• Describe user and system interface alternatives for system design.

• Describe various software development environments for information system design.

• Describe strategies for developing or determining architecture of an information system.

• Draw physical data flow diagrams for an information system’s architecture and processes.

No additional notes.

Application Architecture and Modeling 13-3


Slide 3

13-3

Teaching Notes This slide shows the how this chapter's content fits with the building blocks framework used throughout the textbook. The emphasis of this chapter is with the physical design phase. It spans the communication focus, knowledge fo-cus, and process focus. It involves system de-signers, system users, and systems analysts working with the organization's strategic enter-prise information technology architecture.

Slide 4

13-4

Application Architecture

Application architecture – a specification of the technologies to be used to implement information systems. The blueprint to communicate the following design decisions:• The degree to which the information system will be

centralized or distributed.• The distribution of stored data.• The implementation technology for software

developed in-house.• The integration of commercial off-the-shelf software.• The technology to be used to implement the user

interface.• The technology to be used to interface with other

systems

Teaching Notes We like to compare an application architecture to a set of construction blueprints that a building contractor might require for different building aspects such as framing, electrical, plumbing, ventilation, etc.

Slide 5

13-5

Physical Data Flow Diagram (DFD)Physical data flow diagram (DFDs) – a process model used to communicate the technical implementation characteristics of an information system.

• Communicate technical choices and other design decisions to those who will actually construct and implement the system.

• Recall from Chapter 9 that DFDs are a type of process model.

Teaching Notes Physical DFDs are part of structured analysis and design. For some students, a review of Chapter 9 should precede this lesson. It may be useful to quickly review the slides from Chapter 9 that differentiated between logical and physical modeling.



Slide 6

13-6

Sample Physical Data Flow Diagram

Teaching Notes We have found it useful to walk through this first DFD. Don’t be alarmed if students take excep-tion to some of the oversimplification of the illus-trated problem—it can actually contribute to the learning experience.

Slide 7

13-7

Physical Processes

Physical process – either a processor, such as a computer or person, or a technical implementation of specific work to be performed, such as a computer program or manual process.

• Logical processes may be assigned to physical processors such as PCs, servers, people, or devices in a network. A physical DFD would model that network structure.

• Each logical process requires an implementation as one or more physical processes.

• A logical process may be split into multiple physical processes:

• To define aspects performed by people or computers.• To define aspects implemented by different technologies.• To show multiple implementations of the same process.• To add processes for exceptions and security.

Teaching Notes Some students have difficulty understanding why we might split a logical process into multiple physical processes. It may be useful to walk through this list and give them examples from your own experience or reading.

Slide 8

13-8

Physical Process Notation

ID (optional)

Action Verb+

Noun or ObjectPhrase

Implementation

Conversion Notes This is the Gane and Sarson notation. The DeMarco and Yourdon notation does not provide for a separate symbolic differentiation between logical and physical processes. Depending on your choice of CASE or automated modeling tool, you may need to specify slightly different notations for your students.



Slide 9

13-9

Samples of Physical Processes

Teaching Notes This slide does not illustrate the splitting of a logical process into four physical processes This slide illustrates four possible implementa-tions of the same logical process

Slide 10

13-10

Possible Computer Process Implementations• A purchased application software package

• Also called commercial off-the-shelf (COTS) software

• A system or utility program• Such as an e-mail/message server or third-party

framework

• An existing application program from a program library• May require modification

• A program to be written


Slide 11

Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved

Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS 6th Edition

Sample Physical Process Implementations




Slide 12

13-12

Physical Data Flows

A physical data flow represents:• Planned implementation of an input to, or

output from a physical process.• Database command or action such as create,

read, update, or delete.• Import of data from, or

export of data to another information system.

• Flow of data between two modules or subroutines (represented as physical processes).

Implementation method:Data flow name

Data flow name(Implementation method)

OR

Teaching Notes The last bulleted item may not be as clear to all students. Many have never used a DFD to factor a program into modules. But most students do appreciate the need to pass parameters, vari-ables, and arguments between modules of a program. Reminding them of this is the first step towards appreciating DFDs as a programming tool.

Slide 13

13-13

Sample Physical Data Flows

Teaching Notes It may be useful to walk through this table to help students appreciate that there are always alterna-tive physical implementations for any logical data flow.

Slide 14

13-14

Sample Physical Data Flows (continued)




Slide 15

13-15

Physical External Agents

Physical external agents are carried over from the logical DFD models.

• If scope changes, the logical models should be changed before the physical models are drawn.


Slide 16

13-16

Physical Data Stores

A physical data store represents the planned implementation of one of:

• A database• A table in a database• A computer file• A tape or media backup of anything important• A temporary file or batch• Any type of noncomputerized file


Slide 17

13-17

Physical Data Store Notation




Slide 18

13-18

Physical Data Store Implementations

Teaching Notes Again, a walk through of these implementation alternatives can be useful.

Slide 19

13-19

Distributed versus Centralized SystemsDistributed system – a system in which components are distributed across multiple locations and computer networks.

• Accordingly, the processing workload is distributed across multiple computers on the network.

Centralized systems – a system in which all components are hosted by a central, multi-user computer.

• Users interact with the system via terminals (or a PC emulating a terminal).

• Virtually all the actual processing and work is done on the host computer.


Slide 20

13-20

Why the Trend Toward Distributed Systems?• Modern businesses are already decentralized

(distributed).• Distributed computing moves information and services

closer to the customers and users who need them.• Distributed computing consolidates the power of

personal computers across the enterprise.• Distributed computing solutions are in general more

user-friendly because they use the PC as the user interface processor.

• Personal computers and network servers are less expensive than mainframe computers • Though total cost of ownership is at least as expensive

Teaching Notes The last bullet is controversial. Some experts sincerely believe that distributed computing is more costly to maintain. But this belief has not deterred the proliferation of distributed solutions.



Slide 21

13-21

Computing Layers

• Presentation layer—the user interface

• Presentation logic layer—processing that must be done to generate the presentation, such as editing input data or formatting output data.

• Application logic layer—the logic and processing to support business rules, policies, and procedures

• Data manipulation layer—to store and retrieve data to and from the database

• Data layer—the actual business data

Conversion Notes In some books, the presentation and presentation logic layers are combined.

Slide 22

13-22

Types of Distributed Computing

Teaching Notes Note the five layers Note the three basic types of distributes systems architecture (with sub-types): File server Client/server Internet-based You might want to use this slide twice: first to provide the overview and then later as a review AFTER showing all of the physical DFDs we present for the different flavors.

Slide 23

13-23

File Server Architecture

Local area network (LAN) – a set of client computers (PCs) connected over a relatively short distance to one or more servers.File server system – a LAN in which a server hosts the data of an information system.

• All other layers are implemented on the client computers.

• Frequently excessive network traffic to transport data between servers and clients.

• Client must be fairly robust (“fat”) because it does most of the work.

• Database integrity can be compromised.




Slide 24

13-24

File Server Architecture

Teaching Notes We are constantly amazed at the number of stu-dents who think Access applications that store their data on a file server are truly client/server applications (and many books proliferate the misconception). This slide, when contrasted with the client/server equivalent slides, is intended to dispel that myth. Because the client executes any CREATE, READ, UPDATE, and DELETE commands for a file-server database (such as Access), the entire table must be transported to the client to execute the command. The result is increased data traffic on the network and slow performance.

Slide 25

13-25

Client/Server Architecture —Clients

Thin client – a personal computer that does not have to be very powerful because it only presents the user interface to the user.

Fat client – a personal computer, notebook computer, or workstation that is typically powerful.

Client/server system – a distributed computing solution in which the presentation, presentation logic, application logic, data manipulation, and data layers are distributed between client PCs and one or more servers.

Teaching Notes Emphasize that we are not using “fat client” in a negative sense. For the time being, most knowledge workers will require fat clients for their personal productivity applications (e.g., word processing and spread-sheets), but they may use thin client architecture on those fat clients (e.g., a Web browser or ter-minal emulator) to run or access remote applica-tions (such as those provided by the information systems unit of the company).

Slide 26

13-26

Client/Server Architecture —Servers• Database server – a server that hosts one or more

databases and executes all data manipulation commands at the server.

• Transaction server – a server that hosts services which ensure that all database updates for a transaction succeed or fail as a whole.

• Application server – a server that hosts application logic and services for an information system.

• Messaging or groupware server – a server that hosts services for e-mail, calendaring, and other work group functionality.

• Web server – a server that hosts Internet or intranet websites.

Teaching Notes The sub-point on database server is to empha-size that we are not talking about a Microsoft Access file server. Only a client/server database management system, such as Oracle, SQL Server, DB2, etc. acts as a database server. Emphasize that these server categories are not mutually exclusive. For example, many database server and transaction server functions may be integrated on a single physical server. Also, web and messaging server functions are being inte-grated with each new release of some products.



Slide 27

13-27

Client/Server—Distributed PresentationDistributed presentation – a client/server system in which the presentation and presentation logic layers are shifted from the server to reside on the client.

• The application logic, data manipulation, and data layers remain on the server (frequently a mainframe).

• Character user interface (CUI)• Graphical user interface (GUI)

Teaching Notes This is sometimes called “the poor man’s cli-ent/server.” In reality, the underlying technology allows organizations with constrained resources to give mainframe systems a client/server facelift that extends their useful lifetime until they can be redesigned to more contemporary architectures.

Slide 28

13-28

Building a GUI From a CUI –Screen Scrapers


Slide 29

13-29

Client/Server—Distributed Presentation




Slide 30

13-30

Client/Server—Distributed Data

Distributed data – a client/server system in which the data and data manipulation layers are placed on the server(s), and other layers are placed on the clients.

• Sometimes called two-tiered client/server computing.• Difference to file server systems is where the data

manipulation commands are executed.• Much less network traffic than file server systems

because only the database requests and the results of those requests are transported across the network.

• Database integrity is easier to maintain.

Teaching Notes Tell students that this architecture characterizes most Visual Basic and Powerbuilder applications in existence today.

Slide 31

13-31

Client/Server—Distributed Data


Slide 32

13-32

Client/Server—Distributed Data and ApplicationDistributed data and application – client/server system:

1. The data and data manipulation layers are placed on their own server(s),

2. The application logic is placed on its own server,3. The presentation logic and presentation layers are placed on

the clients.

• Also called three-tiered or n-tiered client/server computing. • Requires design partitioning.

Partitioning – the art of determining how to best distribute (duplicate) application components across the network.




Slide 33

13-33

Client/Server — Distributed Data and Application


Slide 34

13-34

Internet- and Intranet-based ArchitecturesNetwork computing system – presentation and presentation logic layers implemented in client-side Web browsers using content downloaded from a Web server.

• Presentation logic layer connects to application logic layer running on application server, which connects to database servers on the backside of the system.

• The greatest potential of this approach is its applicability to redesign of traditional information systems to run on an intranet.

Intranet – a secure network that uses Internet technology to integrate desktop, work group, and enterprise computing into a cohesive framework.

Teaching Notes Inform students that this is the architecture that is driving e-commerce and e-business. We expect this architecture to eventually replace most two- and three-tier solutions.

Slide 35

13-35

Network Computing System: Internet/Intranet




Slide 36

13-36

Internet and Intranet Technologies• Java

• Mostly for programming server-side application logic called “servlets”

• Occasionally for programming client-side application logic called “applets”

• HTML (HyperText Markup Language)• Mostly for programming the presentation layer

• XML (Extensible Markup Language)• Mostly for programming data content to be transported across

the web• SQL (Structured Query Language)

• Universal standard language for database manipulation• Web Browsers


Slide 37

13-37

Data Architectures

Relational database stores data in tabular form. Each file is implemented as a table. Each field is a column in the table. Related records between two tables are implemented by intentionally duplicated columns in the two tables.

Distributed relational database – A database system that duplicates tables to multiple database servers located in geographically important locations.

Distributed relational database management system –a software program that controls access to and maintenance of stored data in the relational format.


Slide 38

13-38

Types of Data(base) DistributionData partitioning truly distributes rows and columns of tables to specific database servers with little or no duplication between servers.

• Vertical partitioning assigns different columns to different servers.

• Horizontal partitioning assigns different rows to different servers.

Data replication duplicates some or all tables on more than one database server.

• Propagates updates on one database server to any other database server where the data is duplicated.




Slide 39

13-39

Data Partitioning versus Data Replication


Slide 40

13-40

Interface Architectures – Inputs, Outputs, & Middleware• Batch inputs and outputs• Online inputs and outputs• Remote batch• Keyless data entry (and automatic identification)• Pen input• Electronic messaging and work group

technology• Electronic Data Interchange (EDI)• Imaging and document interchange• Middleware


Slide 41

13-41

Batch Inputs and Outputs




Slide 42

13-42

On-Line Inputs and Outputs


Slide 43

13-43

Remote Batch


Slide 44

13-44

Keyless Data Entry (and Automatic Identification)




Slide 45

13-45

Pen Input


Slide 46

13-46

Electronic Data Interchange (EDI)Electronic Data Interchange (EDI) – the standardized electronic flow of business transactions or data between businesses.

• Typically, many businesses must agree to a common data format to make EDI feasible.


Slide 47

13-47

Middleware

Middleware – utility software that enables communication between different processors in a system.

• It may be built into the respective operating systems or added through purchased middleware products.

• Presentation middleware• Application middleware• Database middleware

Teaching Notes Some students have probably used database middleware products such as ODBC or JDBC that allow a single application to access and use different vendors’ database engines without hav-ing to write a different version of the program for each database engine.



Slide 48

13-48

Process Architectures

Software development environment (SDE) – a language and tool kit for developing applications.

• SDEs exist for centralized computing• SDEs exist for distributed presentation• SDEs exist for two-tiered client/server• SDEs exist for multi-tiered client/server• SDEs exist for Internet and intranet client/server

Clean layering – a design strategy that requires that presentation, application, and data layers of an application be physically separated.

• Allows components of each layer to be revised or enhanced without affecting the other layers.

Teaching Notes Most students have used an SDE without realizing it, Visual Studio for instance. Simi-larly, Micro Focus COBOL is an SDE for COBOL, and Visual Café’ and J Builder are SDEs for Java.

Slide 49

13-49

Application Architecture Strategies for System Design• The Enterprise Application Architecture Strategy

• Enterprise-wide information technology architecture to be followed in all development projects.

• Approved network, data, interface, and processing technologies and development tools.

• Strategy for integrating legacy systems and technologies.• On-going process for continuously reviewing application

architecture.• On-going process for researching emerging technologies• Process for analyzing requests for variances from the above.

• The Tactical Application Architecture Strategy• Defines architecture for each new system on an

application-by-application basis as needed.• Requires feasibility analysis for each application.

Teaching Notes Feasibility analysis was covered in Chapter 11.

Slide 50

13-50

Drawing Physical DFDs for Network Architecture• Develop a physical data flow diagram (DFD) for

the network architecture. • Each process symbol represents a server or class of

clients.

• For each processor, develop a physical DFD to show the event processes (from Chapter 9) that are assigned to that processor.

• All but simple processes should be factored into design units and modeled as a more detailed physical DFDs.

Conversion Notes Adapted from the former STRADIS and AD/Method methodologies.



Slide 51

13-51

Design Units

Design unit – a self-contained collection of processes, data stores, and data flows that share similar design characteristics.

• A design unit serves as a subset of the total system whose inputs, outputs, files and databases, and programs can be designed, constructed, and tested as a self-contained unit.

• Ultimately, design units must be integrated into a whole system.


Slide 52

13-52

The Network Architecture DFD

Network architecture – a physical DFD that allocates processors (clients and servers) and devices (machines and robots) to a network and establishes:

• the connectivity between clients and servers• where users will interface with the

processors


Slide 53

13-53

Network Architecture DFD




Slide 54

13-54

Data 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.

No additional notes

Slide 55

13-55

Data Distribution and Technology Assignments DFD


Slide 56

13-56

Process Distribution and Technology Assignments• For two-tiered client/server systems, all logical

even diagrams are assigned to the client.• For three-tiered client/server and network

computing systems, must closely examine each event’s primitive (detailed) DFD.• Determine which primitive processes should be

assigned to the client and which should be assigned to an application server.

• Generally data capture and editing are assigned to servers

• If different aspects of a single DFD are partitioned to different clients and servers, draw separate physical DFD for each.




Slide 57

13-57

Physical DFD for an Event

See Figure 13-13 in text for a more readable version


Slide 58

13-58

The Person/Machine Boundary

See Figure 13-14 in text for a more readable version


Slide 59

13-59

A Manual Design Unit




Answers to End of Chapter Questions and Exercises Review Questions 1. Physical data flow diagrams of the current system

a. Logical data flow diagrams of the current system b. Logical data flow diagrams of the new system to be developed c. Physical data flow diagrams of the new system d. Structure charts of the hierarchal software elements of the new system

2. The complete structured analysis and design methodology is extremely la-

bor-intensive, and requires considerable precision. However, the data flow diagramming portion of the methodology is still a viable tool in wide use.

3. The designers need to check that all the required data flows have been

added to ensure that the logical process requirements are being fully met by the multiple physical processes.

4. The logical processes generally need to be split into multiple physical proc-

esses because: a. The same logical processes ins implemented in different physical proc-

esses b. The logical processes are performed by both people and computers c. The logical processes do not include physical “housekeeping” processes

such as exception handling and audit trail processes, T d. The logical processes are implemented by different technologies, e. The logical processes include physical processes needed for data input

and editing 5. A physical data flow represents any one of the following processes:

a. The planned implementation of an input or output from a physical proc-ess

b. A database command or CRUD action c. Data that is being imported or exported between information systems

across a network 6. Data that is flowing between two modules or subroutines within the same

program. The file cabinet containing hardcopy records and files is an important data store that is frequently forgotten when identifying, designing and depicting the physical data stores.



7. • Distributed systems are a natural “fit” for today’s businesses which tend to be distributed already.

• Distributed computing reduces the distance between customers and the information and services they need.

• Distributed computing takes advantage of the proliferation of personal computers and their enormous collective power.

• Distributed system solutions are generally more user-friendly because they use personal computers for their user interface.

• Acquisition costs for personal computers and network servers are far less than for mainframes.

8. The presentation layer is the user interface itself, i.e., what users see when

they use the system, and what they use to enter and retrieve data and in-formation.

The presentation logic layer is the behind the scenes processing, such as ed-iting input data or formatting output data, that is needed by the actual presentation layer.

9. In a file server system, the data layer is hosted by a server computer, and

the other layers of the application reside in client personal computers. File server systems are built on a local area network (LAN).

10. File server systems must download the entire data file or table to the client

personal computer in order for the application to read or manipulate the desired record. They must also lock the entire file to other users when a cli-ent PC is updating a record, thus significantly slowing access time. In ad-dition, the client PC must have sufficient power and capacity to run the application and store the downloaded file or table. Consequently, file server systems are not really practical except for small information systems without many users. Also, the entire

11. A thin client is a computer with limited power, memory and storage that

presents only its application screens to the user, and that acts as if it were a dumb terminal. Applications do not execute on the thin client, but on a remote application server.

A fat client is a personal computer or workstation that has more power and capabilities, ant that executes applications with its own processor(s). The vast majority of personal computers are fat clients.

12. A network computing system is the network architecture used in e-

commerce. It is a multi-tiered solution, in which client-side web browsers contain the presentation and presentation logic layers, which connects with



the application logic layer on the application server. In turn, the applica-tion server connects with the database server.

13. • Ensure that the perquisites, i.e., the logical data model, logical process

models, and repository details, are all completed. • Draw the first physical data flow diagram, which is network architecture

DFD. • Determine the plan for distributing data stores to the network proces-

sors and then execute your plan. • Assign the information system processes to processors, with the as-

signment method based upon whether you are using a two-tiered or three-tiered client/server.

• Establish the person/machine boundaries by eliminating any part of the physical DFD that represents a manual process.

Problems and Exercises 1. In non-technical language, application architecture is like a blueprint. It

shows what you are going to build, what materials you are going to build it with, and how everything will be assembled. Application architecture an-swers the following questions: • Will the information system applications be centralized in one place, or

distributed in different locations? If distributed, what is the distribution method?

• How and where will the data be stored? • If the system is being developed in-house, what programming language

and tools will be used to build the system software? • If commercial off-the-shelf system is being used, how will it be integrated

into the system? • What type of technology will be used for the interfaces – both to other

systems and with system users? 2. • The purpose of the physical DFD is to be the technical blueprint used by

developers to construct and implement the system. • The physical DFD shows the technical and implementation aspects of the

information system processes; the logical DFD does not. • The physical DFD employs the same basic set of shapes and connections

as does the logical DFD: processes, external agents, data stores and data flows.

• Physical DFDs were originally developed for structured analysis and de-sign, but physical (and logical) DFDS are still very useful tools and very widely used tools today.



3. The physical depiction of a logical process involving both people and com-puters should show separate physical processes for each. In addition, the title or role of the person performing the manual process needs to be shown, as do the data flow(s) between the manual and automated processes. For the logical process that is entirely automated, but with different technolo-gies, multiple physical processes should be shown, each showing its respec-tive implementation technology.

4. Data replication intentionally creates duplicates of tables or subset of tables

on multiple database servers. The main purpose of data replication is to re-duce network traffic. A distributed relational database management system (distributed RDMS) is used to control and maintain the distributed data.

5. A three-tiered system is also called a distributed data and application cli-

ent/server system or n-tiered client-server system. The application logic re-sides on an application or transaction server, the application logic, presen-tation logic and presentation resides on the client server, and the data and data manipulation layers on the data server.

A two-tiered system is also called a distributed data client/server system, and the application logic, presentation logic and presentation resides on the client server, and the data and data manipulation layers on the data server.

A distributed presentation client/server system please the presentation and the presentation logic layers on the client, and the application logic, data manipulation and data layers on the server.

6. The database is stored on the server in both file server systems and cli-

ent/server systems. But file server system execute their data manipulation commands on the client, while client/server systems do so on the server. The advantages are:

a. Network traffic is greatly reduced, because only the database requests

and the requested records move across the network, instead of the entire tables.

b. Database integrity can be preserved much easier, because in general, only the records currently in use must be locked.

7. Based upon the current number of clients, the projected level of network

traffic, and the healthy budget to purchase new workstations and personal computers, a two-tiered system would most likely be satisfactory at the cur-rent time. However, given the business drives and the dynamic growth of the company, you would probably recommend a three-tiered client/server architecture. Because clients store only the presentation logic and presenta-tion in a three-tiered system, this solution will provide the capacity to main-



tain a very high level of performance as the company continues to grow rap-idly.

8. Client/server architectures are inherently distributed. The opposite is true

for network computing architectures. Consider an organization’s Intranet. There, every application runs in or from the browser. This includes both the individual employee productivity applications tools, such as Microsoft Office, the organization’s information system applications, the organization’s e-mail system(s), and links to the Internet itself.

9. 1D, 2A, 3J, 4L, 5K, 6I, 7B, 8C, 9E, 10, 11H, 12F, 13M 10. There are a number of reasons why batch processing applications are still

viable and/or being developed, despite the trend towards online processing. In some cases, the business processes, are so entrenched and pervasive that the cost and effort to reengineer them would not be worthwhile. In other cases, the business processes naturally lend themselves to batch in-put processing – at least at this time. An example would be the acci-dent/financial responsibility reports that drivers must fill out after an acci-dent and send to the DMV in many states. Another related reason is that batch processing is a very efficient method of processing extremely large amounts of data that require little interaction between the system and us-ers.

11. 1H, 2I, 3K, 4J, 5G, 6M, 7L, 8E, 9A, 10C, 11F, 12D, 13B 12. This situation is not uncommon, because processes are frequently a com-

bination of manual and automated tasks, and the logical DFD by design does not include implementation methods.

Yes, the manual processes need to be shown on the physical DFD. They are put into their own design unit consisting of solely manual processes, with their interfaces to computerize processes shown as external agents.

13. • Can a system that works be built from these physical DFDs?

• Will building a system from these physical DFDS result in a system that meets user requirements, as identified in the logical DFDs?

• Will system performance be satisfactory? • Do the physical DFDS show adequate system control to preserve data

integrity and security? • Will building a system from these physical DFDS result in a system that

is flexible and robust enough to incorporate future changes and en-hancements?



Project and Research 1. Although this inventory system is quite basic, the data flow diagrams from

different students with different perspectives will probably vary signifi-cantly, although they should have the same common objects (such as Artist, Song, Studio), and CRUD processes. Responses should be logical, consis-tent, and workable and indicate a basic understanding of object-oriented analysis and modeling.

2. Responses are open-ended; the intent of this question is to help students

understand the intranet architectures, the way they are being utilized today in organizations, and their potential impact upon organizational collabora-tion and employee productivity.

3. Response is open-ended, but it should indicate that the student under-

stands the complexity of determining the data distribution approach an or-ganization should take. In effect, the complexity is equal to or greater than that of the systems analysis and design approach. Also, the response should indicate that the decision should be based upon far more than just the technological factors, i.e., like systems design, the business factors will ultimately drive the technological choice to be made.

4. Responses are open-ended, but should indicate that the student found and

used some of the copious amounts of information available on this subject. Sales information and other industry information should indicate that mainframe computing, while no longer in a leading role, is certainly still alive and relatively well, at least as of this writing. Students should find that the major customer of mainframes is the public sector. Predictions about the future will vary, but students should find no lack of industry ex-perts to support their response, no matter what it may be.

5. Responses are open-ended, but should indicate that the student under-stands the architecture of Internet technologies and tools, can visualize how they might be utilized in a specific organization, and can communicate this effectively to the targeted audience.

6. Response is open-ended, but should indicate that the student has grasped

the strategic organizational and technological issues associated with appli-cation architectures, as well as how they impact and are applied in a spe-cific organization.

Mini-Cases 1. Note to professor: Answers among students will vary, but expect strong

similarity in answers to that of Figure 13-10 on page 519. Allow variation to



include users, other servers, etc. due to specific business assumptions (such as outsourcing).

2. Note to professor: Many times, an unacceptable system is the result of a

miscommunication or lack of clarity in either: design, user requirements, or technical needs. Rarely is it the result of not having the available technol-ogy. Communication between teams and with the customer is paramount.

3. Note to professor: These answers will vary, but mostly in depth rather than

structure. Insist on fully developed answers to this. Answers should in-clude not just a discussion on what should be done, but also how it should be done, and any inherent issues.

Example Structure: Step 1: Do some background research on issues such as: • What is the company mission and purpose? • What are the goals of management with this new system? • What are the competitors doing? • Does the technology and talent appear to be available?

Step 2: Determine Requirements: • Surveys • Interviews • Shadowing • Historical data • JAD

Step 3: Conduct a Feasibility Study on: • Legal • Economic • Operational/Organizational/Political • Timeline • Technical

Step 4: Design • UML: Use Case, Sequence, State, Class • DFD: Physical, Logical

4. Note to professor: PIECES gives more of a perspective on the requirement

needs. The Candidate System Matrix gives a perspective on the alternatives used to meet those needs. As a system is designed and developed, it is easy to lose sight of the needs of the user and the actual business purpose of the system. This exercise is meant less to elicit a specific answer on the video



store, and more to remind the students of a tangible way to remember user requirements as they progress through the design of the system.

Team and Individual Exercises There are no answers to this section.

Documents

13 Application Architecture and Modeling