Cmput 201 - Lecture 1

Introductory Remarks

Who am I? Who are you?

What is this course about?

This is a course on how to design and construct good programs. It is about programming in the small as opposed to system design.

How is this course going to be run?

Rather than teach the syntax of the C/C++ language in class, I will try to examine some case studies: sample problems where we duplicate the problem solving process, complete with false starts and bad decisions.

Why? Because you learn by doing, and that means making mistakes. Engineering Maxim: You learn more from your failures than from your successes.  Therefore it is important that you do the assigned work yourself, and not "borrow" heavily from the work of those who have gone before you through C201.

What do I expect you to do?

Most importantly, I expect you to ask questions. If you are confused during the lecture, stop me and ask. Chances are that others are equally confused.

The Bureaucracy

The course description contains important information. It is available through netscape/explorer. Take some time to read it now. Important things to note:

Software Engineering is a Serious Business

Software is not benign, it has risks.  Software in embedded systems, like airplane flight controllers, fuel injection systems, traffic light control, real-time systems (such video arcade games!) can lead to serious problems if they malfunction

What characterizes good software?

Many of these are exactly the same as used for the engineering of physical devices.

How is software (both good and bad) developed?

The waterfall model (see Figure 1.1 of Code Complete, perhaps):

        requirements    - the goals of the client
        specification   - a description of the tools to be built
        design          - overall plan for the software
        implementation  - the coding of the software
        testing         - weak verification that the implementation is
                            correct
        maintenance     - fixing errors and evolving the system
For many systems, in which the requirements are well defined, the waterfall model is satisfactory. However Typical situation: University Accounting and Student Information System, with revisions for the year 2000.

No point in simply automating some existing manual process. It is better to re-asses the entire way of doing things and exploit the additional power of the hardware/software of the new computing system.

Rapid Prototyping:

        repeat:
                specify
                design and implementation
                use
                reevaluate
For this course you will be using the rapid prototyping model. Why? Because all of you are presumably unfamiliar with the power of C and C++, and so each program of any significance will take a number of attempts.
  • Press here for next lecture 2 (this requires a postscript viewer like ghostview). Ask your TA about this viewer.
  • Press here for next lecture 2 (text)
  • Press here table of contents