Overview
For this lab, you are to use the procedural dataflow design approach to
analyze and design the software described in another handout.
You should also develop test cases as described below.
You must hand in on paper:
(1) a dataflow diagram, DFD, for the Testing program (50%)
(2) a structure chart (calling hierarchy) for the Testing program (15%)
(3) a set of five test cases for Testing with justification (35%)
The diagrams should be neatly written or
done with a drawing program.
The test cases should be written neatly or typed.
Half of your grade is on the proper use of the notation; half is on how complete and correct they are. Neatness counts in that I must be able to read your diagrams. I will not grade every little aspect of the diagrams. I will choose one or two data items and trace them through your diagrams.
This assignment is due Tuesday, September 21st at the beginning of class. You will turn in paper. You may turn it in early.
If you want me to look at your diagrams before they are due, you can bring them to me at office hours. You may also email them to me. JPG files are good as attachments, but I can read a lot of graphics formats. You will turn in paper.
Dataflow Diagram and Structure Chart
Refer to your notes and handouts concerning proper notation for
dataflow diagrams and structure charts.
Be sure that you are showing where the data flows.
This should not be a control flow diagram.
The software isn't really transforming or transacting.
But it is moving the data around.
Remember that the processes can be thought of as acting independently.
These diagrams do not need to be huge. Yours will probably have fewer than ten processes. The nodes are processes. The arcs are data. Be careful with your notation.
The structure chart should show in a somewhat hierarchical way how the functions are grouped and call each other. It shows the calling hierarchy, but there is no data on the lines between functions. Spend more time on your dataflow diagram; it's more important although the structure chart may more helpful as you do lower-level design.
Test Cases
Although testing occurs during and after implementation,
thinking about test cases now may help you think about the problem.
After all, this is a testing system you are building.
For this part of the assignment, consider test cases for a
program you will be testing rather than test cases for the testing system.
Describe at least one program and
four test cases for that program
and describe in English why you chose them (what potential bugs
you hope the tests will uncover).
Use precise English to describe the program specifications.
Present the test cases in a table much like shown below.
Example: Given a real number, the program prints the square of that value.
| Input | Output | Potential Bugs to Uncover |
|---|---|---|
| 4 | 16 | positive values handled incorrectly |
| -3 | 9 | negative values handled incorrectly |
| 0 | 0 | zero treated differently |
| 2.1 | 4.41 | numbers with decimals handled incorrectly |
| 2000 | 4000000 | bigger numbers handled incorrectly |
Remember that the goal of testing is to uncover bugs and that a good test case has the potential of uncovering a previously undiscovered bug. Give distinct test cases that you hope will uncover different bugs. You must be precise because you need to be able to make files that use these test cases. You may not use the test cases given here or in the problem description.
You may want to build these files to test your program. You are not limited to programs that crunch numbers.