Overview
For this assignment, you are to use the procedural dataflow design approach to
analyze and design the software described in Part I.
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 done with a drawing program.
The test cases should be 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.
If you want me to look at your diagrams before they are due, you may also email them to me. JPG (JPEG) or MS Word files are good as attachments. You will turn in paper, however. I'll try to give you quick feedback, though it obviously depends on when I get it.
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 (nodes). 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 prior to implementation will help you think about the solution.
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
five 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.
| Test Case | Input | Expected Output | Test Case Purpose |
|---|---|---|---|
| 1 - pos | 4 | 16 | known case; positive values handled correctly |
| 2 - neg | -3 | 9 | known case; negative values handled correctly |
| 3 - zero | 0 | 0 | unusual data; zero handled correctly |
| 4 - dec | 2.1 | 4.41 | numbers with decimals handled correctly |
| 5 - large | 2000 | 4000000 | extreme data; bigger numbers handled correctly |
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.