2.1.

FLOWCHARTS
A flowchart is a graphic illustration of the steps to follow in order to arrive at the solution to a problem. It is a program design tool that you use prior to writing the actual program. A flowchart consists of a set of various standard shaped boxes that are interconnected by flow lines. Flow lines have arrows to indicate the direction of flow of control between the boxes. The description of the activity within the boxes is written in English. In addition, there are connector symbols that are used to indicate that flow of control continues elsewhere, for example, another page.

2.1.1 FLOWCHARTING STANDARDS

* Flowcharts are to be drawn on white, unlined 8 1/2" x 11" paper on one side only. * Your name, student number, the number of the assignment and the title of the program must appear at the top of each page, along with the page number. * Use only standard flowcharting symbols (see following page). * Use a template to draw the final version of your flowchart. * Print the contents of each symbol legibly. * Use English, not programming language statements, in flowcharts. * If your flowchart includes subroutines the flowchart for each subroutine must appear on a separate page. Each subroutine begins with a terminal symbol with the subroutine name and a terminal symbol labelled return at the end. * Flowcharts start on the top of the page and flow down and to the right. * Draw arrows between symbols with a straight edge and use arrowheads to indicate the direction of the logic flow.

2.1.2 STANDARD FLOWCHARTING SYMBOLS

Symbols are on the following page.

2.2. NALIN'S DICTUM COMPILATION

The following passages list some words of wisdom on programming principles (life?). Some "rules" are contradictory, but that's the point. Always remember: Every rule has an exception; including this rule. If it ain't broke, don't fix it. - Grandpa If it works it's obsolete. I would rather write programs to help me write programs than write programs. - Dick Sites, DEC Sure, 90% of all software is crud. That's because 90% of everything is crud. - Mary Shaw, CMU If you lie to a computer it will get you. - Perry Farrar Common sense is not so common. - Albert Einstein

2.2.1. DESIGN
KISS it. (Keep It Simple Stupid.) Understand the problem. The best design is often the simplest. - Jon Bentley, Bell Labs A design that does not fit on one 8.5-by-11 inch paper cannot be understood. - Mark Ardis, Wang When in doubt use brute force. - Ken Thompson, Bell labs Let the data structure the program. -David Parnas Design data structures first; rest of the program will write itself.

- David Jones Avoid arbitrary restrictions. The only reasonable restrictions are 0, 1, and [[infinity]]. It is often easier to derive a general solution than for a special case. Experience is what you get when you don't get what you want. Good judgement comes from experience, and experience comes from bad judgement. - Fred Brooks

2.2.2. PROJECT MANAGEMENT

Plan for deadlines. The sooner you start to code, the longer time it takes. Don't keep doing what doesn't work. Furious activity is no substitute for understanding. - H. H. Williams Prototyping cuts the work to produce a system by 40%. - Larry Bernstein, Bell Communication Research Plan to throw away one prototype. You will anyhow. - Fred Brooks Good customer relations doubles productivity. - Larry Bernstein, Bell Communication Research Beware of claims that "it's 95% complete". The first 90% of code accounts for the first 90% of development time. The remaining 10% of code accounts for the other 90% of development time. - Tom Cargil Respect standards: when in Rome, don't do as the Greeks do. - Grandpa

2.2.3. USER INTERFACE

Strive for orthogonality; keep unrelated features unrelated.

- Jon Bentley, Bell Labs Details count. - Peter Weinberger, Bell labs Make a user interface as consistent and as predictable as possible. Avoid too many special cases. Provide tools. Make them general. Use the right tool for the job. - P.J. Plauger, Yourdon Inc., Brian Kernighan, Bell Labs When the only tool you have is a hammer, everything looks like a nail. - Henning Mortensen

2.2.4. CODING
If you can't write it down in English, you can't code it. - Peter Halpern Avoid asymmetry. - Andy Huber, Data General Modularize. Remember 7 +/- 2. Brevity is the soul of wit. - The Bard The code for a module should fit on a screen. Why reinvent the wheel? Use library functions whenever possible. Handle normal cases and worst cases separately. Store dates internally as YYYYMMDD. A new millennium is coming. Know your limits. Remember September 28, 1989. Everything should be made as simple as possible, but no simpler. - Albert Einstein

2.2.5. DEBUGGING

Avoid bugs in the first place. An ounce of prevention is worth a pound of cure. Testing shows the presence of bugs, not their absence. - Edsger Dijkstra Make up exhaustive test data during design and coding. The first step in fixing a problem is getting it to fail repeatedly. - Tom Duff, Bell Labs 80% of bugs are syntax errors. Of remainder 80% are trivial logic errors. Of remainder 80% are pointer errors. Remaining .8% are hard. - Marc Donner, IBM If the code and comments disagree, both are probably wrong. - Norm Schryer Debug the code. Don't be led astray by the comments. Don't debug standing up. It reduces your patience. - Dave Storer

2.2.6. DOCUMENTING
No job is over until the paperwork is done. When explaining anything, first describe the problem it is designed to solve. - David Martin Be consistent in your style. Choose one format and stick to it. Strive for "self documenting" code and data. Don't over decorate. Avoid over-documentation. Black and White Rule: Use white space effectively. In a sea of white your eyes will spot the black. In a sea of black your eyes will catch the white. A picture is worth a thousand words. Graphics is only screen deep. - Rob Andrews, BNR

2.2.7. EFFICIENCY
Don't use a computer to do things that can be done efficiently by hand. Don't use hands to do things that can be done efficiently by a computer. Get it to work first. Then make it work faster. - Jon Bentley, Bell labs Before optimizing, use a profiler to locate "hotspots". - Jon Bentley, Bell Labs In allocating resources, strive to avoid disaster than to attain an optimum. - Butler Lampson In non-I/O-bound programs, less than 4% of a program generally accounts for more than half of its running time. - Don Knuth 80-20 rule: 80% of the world's resources are consumed by 20% of the population. Premature optimization is the source of much programming evil. - Don Knuth

2.2.8. Pice de rsistance

If it's true the brain is like a computer, then there aren't really any stupid people. - Ali Rezazadeh

2.3 C Programming style:

1. Put all prototype definitions into a header file, eg. file.h. 2. Prototype definitions should be of the form:
type name(vartype variable [,vartype variable....]);

eg
int func1(int i, float fvar, char **names);

3. The first line of a function definition should match the prototype exactly (except for the semi- colon).

type name(vartype variable [,vartype variable....]) { ... }

eg.
int func1(int i, float fvar, char **names) { ... }

4. The function main should always return 0 upon normal termination. 5. All braces should be on lines by themselves. 6. All control structure bodies should be indented one tab stop. 7. Debugging statements may be left in code if surrounded by #ifdef. For example use #ifdef DEBUG to include print statements within the body of the program for debugging. Debugging statements should appear in the functions being debugged, ie print the return value in the called function not the calling function, if possible. 8. All files should be documented. The form should be:
/*---------------------------------------------------------Filename: func.c Author: Your Name Student #: 184 101 111 routines: func1,func2,func3 -----------------------------------------------------------*/

9. All major functions should be documented. The form should be

/*----------------------------------------------------------Function name: func Purpose: Return the result of the integration parameters:

f() function to be integrated a lower limit of integration must be positive b upper limit of integration must be greater than a returns: Result of the integration -----------------------------------------------------------*/

NOTE: function and file documentation can be combined if a file contains only one function. 10. Do not use macros to create obscure code but use them to define any constants or frequently used constructs. ie: Do not use macros such as:
#define float int That obscure the function of program.

Do use macros such as:

#define MAXLEN 255 #define PIE (acos(-1)) #define NEW(x) (x *)malloc(sizeof(x)) which enhance the readablity of the program.

11. Global variables should be avoided where possible. Always start the name of a global variable with a capital letter. For example:
int Counter

12. No goto statements are allowed. 13. Use library functions wherever possible. Always include header files for libraries; eg:
#include <stdio.h> #include <signal.h>

Section 1

Issues in tertiary learning

Successful students at university have found that they need to think more deeply about their own learning to get the most out of their program of study. This section challenges you to think about learning itself by discussing what to expect at university as a learner, and general learning strategies and styles. It also emphasises the importance of self directing your own learning.

Commencing study of an overseas qualification

The first courses you study in a degree are generally thought of as being the most crucial for students. Research by McInnis, James and McNaught (1995) shows that in Australian universities the early experience that students have affects and determines success and satisfaction in the later years of study. The first year studying an overseas qualification will be challenging for most students. Students will not only have to get used to the academic program but to the way in which other aspects of their lives, such as family responsibilities, social commitments and paid employment, affect their university activities and the academic demands of their program. Most students will find that the type of learning required is largely different from what they experienced at secondary school. The greatest difference is that you are regarded as an independent learner; that is, someone who takes responsibility for what you need to do and what you need to know. Part of being an independent learner is developing independent thinking skills-something important to consciously develop. The thinking involved in your program will require: knowing the body of knowledge in your area of study, for example economics understanding that body of knowledge; that is, making sense of it making links between various aspects of the theoretical body of knowledge in your area of study

Your initial courses will help you develop an understanding of the sorts of knowledge you are expected to master and apply, knowledge to which you yourself may perhaps even ultimately contribute.

Learning styles & strategies

The teaching staff at university facilitate student learning, rather than just provide information. In this current environment of more self-directed learning, how a student approaches their learning is critical to their success. Students can benefit enormously by learning better how to learn. By increasing their awareness of various styles and strategies, a student can understand their strengths and weaknesses as a learner and adopt those styles and strategies which they consider are most appropriate to them. Learning styles Four common learning styles have been identified among people who are studying (Australian National Training Authority 1995). Learners predominantly tend to use one learning style. The

four basic learning styles are: the give me a reason style The learner relates the new information to personal experiences in order to give it personal meaning. This learner asks why should I learn this? the teach it to me style The learner absorbs new information provided to them, mainly in the form of concepts and models. This learner asks what should I learn? the let me try it out style The learner experiments with new information by solving problems and relating theory to practice. This learner asks how should I learn? the what if style The learner learns through their own experiences with new information; that is, looking at concepts in a different way. This learner asks what if?

The use of all of these styles in the learning process will enhance a student's ability to learn. Although generally students will favour the learning style most suited to them in the circumstances, they will benefit from improving their ability to use the other styles. It is suggested that as students learn, they should address the key questions: why should I learn this? what should I learn? how should I learn? what if?

Learning strategies You can more successfully improve your learning if you are aware of a range of learning strategies and use those which are most appropriate for the particular circumstances. You receive, process and retrieve information in four main ways-by seeing, by listening, by feeling and doing, or by reading and writing. Generally individuals are dominant in one or two of these sensory channels and so need to adopt learning strategies appropriate to this channel, although by strengthening the other channels it is possible to increase the ability to receive, process and retrieve information. Below are appropriate learning strategies based on each learning method. Seeing Strategies can include: underlining or using colours to highlight readings/notes, graphs, flowcharts, symbols watching videos of lectures or videos of related concepts in lectures, visualising concepts in your mind using images when attending lectures which use overheads and picturesque language, recall information using pictures and drawing diagrams.

Listening Strategies can include: listening to lectures or tape recordings of lectures (this will require you to make your own tapes) discussing topics with other students

reading notes or books out loud to yourself talking and listening to your fellow students recalling information by summarising notes on tapes and listening to them and explaining your understanding to other students.

Feeling and doing Strategies can include: listening to lecturers who relate to real-life examples seeing or thinking of real-life examples by relating to your own experiences to your lecturer or other students doing many application questions in study guides or on computer-aided packages selecting assignments which require some field work recalling information by writing practice answers from previous exams and doing more study guide questions.

Reading/writing Strategies can include: going to lectures where you can take good lecture notes or get good lecture hand-outs re-writing and summarising lecture notes reading many different sources using lists, headings, glossaries writing short essays recalling information by writing and reading many times and arranging your points into hierarchies.

Flexibility is the key to learning: adopt learning strategies which work for you in the circumstances. Different learning methods may be appropriate for different courses or within courses, and at varying times within courses. Working through a training manual and a computer to become familiar with a computer software program uses both the feeling and doing strategies and the reading strategies. Becoming familiar with a theoretical concept involves using the listening strategy and the reading/writing strategy.

Learning-your responsibility
As mentioned above the type of learning required at university requires you, the learner, to be largely self-directed. You will complete some of the reading on your own with guidance from the study guide between lecturer visits. You are given the opportunity to engage in a number of learning experiences such as lectures, reading, writing or group work, and you are encouraged to fully use these opportunities to learn as much as possible about each of the courses. A central tool in organising your learning is the Course information guide provided when you commence the course. The Course information guide outlines: the weekly topics that will be covered the due dates of assignments assessment requirements; that is, assignment questions, exam and test details details of recommended readings.

The Course information guide clearly sets out the expectations of the lecturer of students who are studying in that particular course. In one way the Course information guide may be thought

of as a contract between the lecturer and the student about how learning will be organised. The Course </f