Chapter 10 – The Traditional Approach to Design
Solutions to End-of-Chapter Material
Review Questions
1. Explain the relationship and differences between a module and a program.
A program is a set of modules that work together to perform all the required functions. A module is a relatively small set of statements that carry out a single function.
2. What is the purpose of the automation system boundary? How do you develop one?
The automation system boundary defines which processes are going to be automated within the computer system, and which processes are part of the environment, or manual system. The system boundary, although needed for both structured and object-oriented development, needs to be defined explicitly for the structured approach. The object-oriented approach already has the system boundary defined in the use case diagram. The automation system boundary is developed at the DFD fragment level or below, by defining which processes are manual and which are automated. The boundary line is a line between these two processes.
3. What is a system flow chart used for?
A system flow chart is used to depict the overall flow of information and control in a total system that consists of several programs.
4. What symbols are used on a system flow chart?
The symbols include a rectangle for a program, a rectangle with curved sides or a disk for a file, a rectangle with a curved bottom line for a report, a circle with a tail for a file, a trapezoid for a manual operation, and an arrow or lightning bolt for a transmission or movement of data.
5. What is the purpose of a structure chart?
A structure chart depicts the hierarchical structure of modules that make up a computer program. It shows the calling hierarchy as well as the data parameter that is passing between the modules.
6. What are the symbols used on a structure chart?
The symbols include a rectangle for the module, a connection line or arrow for the calling structure, and small arrows with open circles for data couples or with black circles for flags.
7. Explain transaction analysis.
Transaction analysis is the process of identifying a set of transactions (usually via DFD fragments) and developing a structure chart. Transaction analysis results in a structure chart with a calling structure to call a module for each transaction type.
8. Explain transform analysis. What is meant by the term central transform?
Transform analysis is the process of taking a DFD diagram and converting it to a structure chart. Transform analysis is based on the idea of “transforming” an input data flow into an output data flow. The central transform is the central process that transforms the data.
9. What is the difference between afferent and efferent data flow?
Afferent data flow is the incoming data flow in a sequential set of process bubbles. Efferent data flow is the outgoing data flow from a sequential set of process bubbles.
10. Explain module coupling and module cohesion. Why are these concepts important?
In structured analysis, modules are ideally defined and built to have low coupling and high cohesion. With low coupling, the only knowledge that one module has about another module is its input parameters and output fields. Like a black box, a well-defined module is built this way so that other modules do not have to know its internal workings. Module cohesion refers to the single purpose of a module. If a module carries out only one function, it is self-contained and easier to maintain.
11. Describe how structure charts for three-layer architecture are different from those for all-encompassing programs that execute on a single computer system.
Structure charts for three-layer architecture show all three layers but may not include modules to handle all operational aspects of the application tasks (for example, the data access modules that are included within the data access layer). All-encompassing programs that execute on a single computer system will include all modules.
Thinking Critically
1. Given the data flow diagram in Figure 10-24, do the following: (a) draw a system boundary; (b) divide the DFD into program components such as real-time, monthly, daily, periodic, and so forth; and (c) draw a system flow chart based on the division into program components. id Customer id Bank id Billing & Collections id Meter Operations id Customer Accounts id Meter Information id TransactionsUsage id Payment History Produce Meter Reading Schedule id Apply Meter Readings Create Billing Statement id Apply Payments Process Customer Query id Produce Periodic FInancial Statements id Adjust Customer Account id Realtime Realtime Realtime Monthly
Create Bills Program Produce Meter Schedule
Program Produce Financial Statement Program Realtime Updates Program
(Payments, MeterReadins, Adjustment, Queries) Customer Accounts Payment History Meter Information Usage Transactions
2. Given the data flow diagram shown in Figure 10-25, and using transaction analysis, develop a structure chart.
Registration Program
Inquire Course
Info Verify Schedule Add Class Drop Class
Check Registration Status
3. Given the data flow diagram shown in Figure 10-26, and using transform analysis, develop a structure chart.
Add Class
Disply Course Info Get Course Update StudentSchedule
Verify Student Verify Sections Update Schedule File
Display Schedule
4. Integrate the structure charts from problem numbers 2 and 3 together into a single structure chart.
5. Given the data flow diagram shown in Figure 10-27, and using transform analysis, develop a structure chart.
Create Special Orders
Get Special Order Info
Read Supplier Info
Update Orders
Sort Display Orders Get Approvals orChanges
Create Purchase Order Output
6. Finish developing business logic layer modules for the view layer modules in Figure 10-20.
Answers will vary. See Figure 14-6 on page 545 for a structure chart that provides a starting point for this answer.
Experiential Exercises
1. Discuss the hierarchical nature of traditional structured design. What kinds of systems are naturally more inclined to a hierarchy?
Hierarchies are a good design representation when software will be organized into a hierarchy. Hierarchical software reorganization requires both a supporting deployment environment (for example, a third- or fourth-generation programming language such as C or FORTRAN) and an application for which hierarchical organization makes sense.
Some systems, such as the batch payroll examples used in this chapter, are clearly suited to a hierarchy. Others, such as a distributed event-driven order-entry system, are clearly suited to representation and implementation as objects. But there are many gray areas in between. It is an oversimplification to make statements such as “All interactive systems should be object-oriented, and all batch systems should be hierarchies.”
2. Find an example of a business system that is written in COBOL or Basic that has a hierarchical structure and was probably developed using traditional methods. Search the Internet for COBOL, Microfocus COBOL, or Visual BASIC.
Answers will vary.
3. Find a local company that is doing development using traditional structured techniques. Set up an interview with an IS staff member. Gather as much information as you can about the company’s systems. Review the company’s techniques and SDLC
methodology.
Case Studies
Case Study: Real Estate Multiple Listing Service System (Structured)
Refer to the description of the Real Estate Multiple Listing Service System in the case studies of Chapter 5 and the DFDs you developed in the case studies for Chapter 6. Develop a structure chart for the system. Follow the steps indicated in this chapter, including any additional modules required for accessing data.
Get Transaction Choice
Process Listing Transactions
Add Listing Update Listing Display ListingInformation Print ListingBook
Get Listing Information Read Listing File Write Listing Record Get Listing Updates Read Listing File Write Listing Record Transa ction C hoice New Lis ting Info rmat ion Lis tin g D eta ils Lis tin g D e ta ils C ha nges Upd ated Lils ting Listing D etails Lilsting ID Listin g D eta ils Maintain Office Records Maintain Agent Records
Maintain Office Records
Get Transaction
Type Add New Office
Change Office Data Delete Office Record Read Office Record Get New Office
Data Write Office Record Get Office Changes Write Office Record Maintain Agent Records Get Transaction
Type Add New Agent
Change Agent Data Delete Agent Record Read Agent Record Get New Agent
Data Write Agent Record Get Agent Changes Write Agent Record
Case Study: Rethinking Rocky Mountain Outfitters
Review the decisions about the deployment environment and design for the Rocky Mountain Outfitters customer support system as described in Chapters 8 and 9 (see pages 311 and 343) and the related traditional design models in this chapter. Specifically for this system, what are the comparative advantages and disadvantages of software design with traditional methods and models compared with objectoriented methods and models? Refer to Figure 85, which summarizes key aspects of the development and deployment environments, and Figure 913, which provides a detailed description of the deployment environment. Note that there are three proposed development languages, only one of which (Java) is fully objectoriented. Visual Basic .NET is objectoriented includes some OO features in its latest versions. The latest Microsoft development tools for VB (Visual Studio .NET) make it easy to deploy VB programs as components. Web development is not often OO in deployment. The development environment leaves open the possibility of using a mixture of traditional and OO design approaches. However, given the use of Java and the Webbased, componentbased, and distributed natures of the system, OO design techniques are the best fit. Note: The opening chapter case makes a good comparison point to this case.Case Study: Focusing on Reliable Pharmaceutical Service (Structured)
Based on the description of the Reliable Pharmaceutical Service system in Chapters 5 and 6 and the DFDs you developed for Chapter 6, develop a system flowchart and structure charts for the system. Assume that the system will be designed and deployed according to three-layer architecture.
Answers will vary but should look similar to Figure 10-19 on page 373, which shows a three-layer architecture, and Figure 10-20 on page 374, which shows a structure chart for three-layer
