Download Errata-Program1

Problems with Program #1 Deliverables
While most of the turn ins were quite good, below is an ‘errata’ if you will of
problems encountered while grading.
System Flow Chart –
Files should be annotated with both logical and physical file names.
Several deliverables forgot a file.
Be certain to use the correct media symbols.
Structure Chart
Remember, this is your Architectural Design (Preliminary Design).
The original requirements are decomposed into functional units, so the
thrust of the structure chart is functionally decomposing the requirements
into modules. Remember, the higher level modules are main, abstract
modules. As we proceed ‘down the hierarchy,’ abstract modules (those
with more ‘control’ than ‘functionality’) become less and less and
modules having more functionality (computations, data manipulation,
logical compares, etc.) will dominate. So we are proceeding from the
abstract to the concrete; modules with more control to modules with more
functionality…
Common modules (headers, trailers) often not cited
Number was off
Often modules such as Read or Write were at a high level – clearly not
major functional components in the solution space.
Pseudo Code
Remember, this is your detail design.
Your pseudo code represents your algorithmic approach for each module
identified in the structure chart. For modules that are mundane
(like Moves, etc.) they can be collapsed and abbreviated. But for
modules that contain calculations or traversing a table, or other
searching routines, the details of HOW your solutions is going to
accomplish this is critical. Remember, together with data
descriptions, your pseudo code should be detailed enough to
support programming. But also remember, that the number of
lines of pseudo code should NOT be in one-to-one correspondence
with your source code.
Collapse number of moves when a note can make it clear.
Ensure your pseudo-code is not too Cobol-like. Remember, your pseudo
code is your algorithmic approach to solving a problem; as such it
should be language-independent – at least as much as possible.
Indentation is critical – as much in pseudo-code as it is in real source code.
Use scope terminators
Use verb…object statements, like Generate …. Loop and …. End-loop;
For all xxx …. end For; Calculate, ….
While mundane processing (Moves, etc.) can be collapsed, ensure that
details of calculations, searching, etc. are clearly articulated.
Source Code
Internal documentation – often missing. Need flower boxes.
Need to adhere to standard naming conventions, ‘a’ prefix for
accumulators, ‘c’ for counters, ‘p’ for print fields/records, ‘t’ for
tables, ‘f’ for flags, etc.
Also use two character prefixes for fields in input / output records that
reflect the name of the input records. Example for an 01
Inventory-Record, you might have fields: ir-stock-nbr; ir-quantyon-hand; ir-reorderpt; …
Indent at least four spaces. Be consistent too.
Output
Must be ACCURATE. If unsure, run your program with only a couple of
records. Do computations with a calculator to ensure your
program computed results correctly.
Be certain field size is sufficiently large to handle results of computations
– especially products!!!
Be certain output print / display products are professional looking with
appropriate line and page control as required by the specifications.
Never make any changes without consulting the client (me in this case).