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