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.