The course team's strategy is to concentrate on problems that do not need specialist background knowledge. The problem analysis principles and programming techniques used in tackling these problems are as widely applicable as possible. This basic strategy leads to another problem. Any techniques that are really widely applicable have to ignore the fact that you are working within Windows and that you are used to using programs which use buttons, menus and other visual devices. (Washing machines do not usually have sereens on which to display such things, though they might be easier to use if they did!)
The course team has decided on a compromise. The problem analysis and programming in the early part of the course will be as general as possible and will, to all intents and purposes, ignore the visual features of Windows. The latter part, particularly Blocks III and IV, will consider how to program for visual environments such as Windows. These ideas will, of necessity, be less generally applicable than the earlier ones.
Another problem arises simply because the course is an Open University course. The problems that you are asked to analyse and write programs to solve have to be suitable for a single programmer working in isolation, because studying is mostly a solitary activity in the Open University. In practice, most software is constructed by teams working together. This course team has deliberately chosen not to include group working as part of the course work. This decision means that you lose some of the force of ideas that are needed to make group working successful, but you gain something in flexibility of study pattern.
As in any subject area, team working requires techniques for ensuring that the parts of a project will combine correctly. Emphasis is placed on such techniques in MT262, partly for the reason just given and partly because the same techniques can help to reduce mistakes for a single-programmer project. One of the major principles that will be used is that any programming task beyond the very simple should be broken into smaller sections that can be dealt with and tested indepeiidently. The skills that are necessary for this approach are transferable to larger projects involving teams of workers. It is these issues that are partly responsible for the general approach of separating the description of what a piece of program code is supposed to do from the code that describes how it is actually done.
A third area of difficulty for any course which teaches programming is that there are two widely used and fundamentally different models of programming. In one, the procedural model, the program drives the user. The program controls when it will ask for input, when it will provide output and the order in which various things happen. In the second, the event-driven model, the user drives the program. Event-driven programs are the type you use within Windows. The program sits around doing nothing much until you generate an 'event' by pressing a button, clicking on a menu item or taking some similar action. Thus, in event-driven programs, the user (not the programmer) controls what happens and in what order. Just to complicate matters further, you may well have seen the phrase 'object-oriented programming'. Objects (in the technical sense) are usually associated with event-driven programming but do not have to be. The course team has adopted an approach that follows historical development; the plan is to start with procedural programming and introducé objects and event-driven programming later.
You may already have studied other Open University courses dealing with object-oriented programming. If so, a minor warning is in order here. Conceptually, objects are not a terribly involved idea, as you will see in