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 sub- tasks. 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 3 rd 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.