The Program Life Cycle.

Download Report

Transcript The Program Life Cycle.

IO and Module Charts.
1. Input format.
2. Output format.
3. Exception handling.
4. Top-down design.
1. Input format.
 C# defaults to inputting all data in a string format.
 This means that all data is represented simply as
a series of characters (bytes).
 Console.ReadLine () can be used “as is” if inputting to a
string;
 string Last_Name;
Last_Name = Console.ReadLine ();
Input conversion.
 In all other cases, the character string must be
converted into the appropriate data type.
using the methods in Convert, e.g.
float Num1;
Num1 = Convert.ToSingle (Console.ReadLine ());
double Num2;
Num2 = Convert.ToDouble (Console.ReadLine ());
int Num3;
Num3 = Convert.ToInt32 (Console.ReadLine ());
2. Output format.
 When outputting complex data e.g. in table
format, it is helpful to control the format so that
there is a uniform left or right edge.
 C# provides 2 main methods of formatting output:
 (1) Place-holders (see Format1.cs)
 (2) Display methods associated with each variable
(see Format2.cs)
3. Exception handling.
 This is an advanced topic, but the basic idea is
simple.
 If code is risky (e.g. there could be bad data,
division by zero), then it is possible that an
exception will be thrown (a run-time error).
 If it is, and the exception isn’t handled, then either
the program crashes or you may see bizarre output
e.g. declaring you have an Infinite number of
dollars!
Exception handling.
 “I take exception to that remark….”
 A programmer can prevent some problems by
careful use of if else logic, e.g.
 float Total, Count, Average;
if (Count != 0)
Average = Total / Count;
else
Console.Write (“Naughty person”);
Exception handling.
 However, this is more difficult in some
cases, especially if there is bad data.
 In that case, it is recommended to enclose
the risky code in a try { } and then handle
exceptions in a catch (Exception) { }
 See TryCatch.cs for a simple example.
4. Top-down design.
 With simple projects, one can throw ideas out and
hope one finds a solution (trial and error).
 This is a bottom-up problem-solving approach,
where we start at the bottom with individual ideas
and hope that we can use them to build the
complete solution (the top).
 Compare: randomly pulling out legos, and
assembling them blindfold.
 Works for some projects, but….
Top-down design.
 What is the limitation of this approach?
 It cannot handle finely-tuned complexity.
 E.g. what are the chances of assembling a
replica of a Ferrari engine by randomly
selecting engine parts and fitting them
together, even with a large number of trials?
Top-down design.
 A better approach is top-down design. We
start at the top, with the whole problem,
then gradually break it down into its main
tasks, then analyze each of these into subtasks. E.g.
 1) Build a computer desk.
 2) Write a research paper.
 3) Create a S/W application package.
Top-down design.
 Remember our definition of “algorithm”
emphasizes a step-by-step approach, so
order matters. E.g. introduction before body
before conclusion.
 Top-down design generates a 3rd form of
algorithm representation, a module chart or
hierarchy structure chart. See diagram.
Module charts.
 What are the advantages?
 A. Ensure solution consists of co-ordinated
parts.
 B. Avoid the sins of
 (1) Omission, (2) Repetition, (3) Confusion.
 C. Divide and Conquer.
Rules for module charts.
 1. One well-defined function per module.
 2. When a module is broken down into lower-level
modules, the lower-level modules must be sub-problems
of the original module.
 3. Module chart lines can diverge, but unlike a
flowchart, cannot converge.
 4. On any given level, the order of tasks should be left
to right.
 5. Modules should be broken down gradually into
lower-level modules e.g. from 1 to 3 or 4, but not 7 or 8.
In-class exercise.
 See the specification for the actuarial
program, “Financial Calculator,” which
generates an amortization table for paying
off a loan.
 Without worrying about the detailed
instructions, develop a module chart
showing the main program tasks.