At one time programs required to use a separate editor to create their source code, a separate compiler program to compile the program, a separate linker to bind the compiled code with code from a library, to produce the executable program. Most development systems are now totally integrated, as illustrated in Figure 2, where the editor, compiler and linker are all part of the same integrated environment. An important tool is a debugger, which is used for two purposes:
To locate and fix errors. A debugger can be set-up to break the program at given points (known as breakpoints), and then the developer can test any of the variables within the program. This helps to locate errors in the program. The developer can also execute the program one line at a time (known as step-through). To perform a code walk-through. Even if a program is successfully running, it is impor-tant to perform a code walk-through. This involves stepping through the program one line at a time, and watching the route that the code takes, and how the variables change. This is important as there may be something occurring in the program which is unwanted, such as taking more time to conduct an operation, than is necessary.
Figure 2 Integrated development environment
Procedural or modular programming
Modules are identifiable pieces of code with a defined interface. They are called from any part of a program and allow large programs to be split into more manageable tasks, each of which can be independently tested.
A module can be thought of as a 'black box' with a set of inputs and outputs. It has a sole purpose, and processes its inputs in a way dictated by its goal and provides some output. In most cases the actual operation of the 'black box' should be invisible to the rest of the program. This can be likened to an educational programme, where the course is broken down into a series of modules, which the student must undertake. For each module there is an initial specification (the input to the module, along with the students enrolled on the module), and the output are graduated students, with their results. As much as possible these modules should be taken independently from the other modules on the programme, as the teaching and operation of one module should not really have much effect on other mod-ules. The amount that they are inter-related is known as cross-coupling. For example a student on a Computing course may be taken a Java module. The cross-coupling between this module, and the Legal Aspects of Computing module is likely to be zero, as the teaching of one does not effect the other. Some modules will have a strong coupling, such as the Object-Oriented Design Methods (OODM) and the Java module. With this the Java module will typically depend, in some way on the OODM module. If it was totally dependent on the way that it was taught and operated, then it would be 100% dependent. In most cases lecturers will try and reduce the amount of coupling, so that the module can run without effecting other modules.
A modular program consists of a number of 'black boxes' which, in most cases, work independently of all others, of which each uses variables declared within it (local variables) and any parameters sent to it. Figure 3 illustrates a function represented by an ideal 'black box' with inputs and outputs, and Figure 4 shows a main function calling several sub-functions (or modules). New techniques in software development use components, which are large general-purpose modules, which can be used in a number of ways. For example a networking component could be used in a program. If the component is well designed it could be used in a number of ways, such as supporting different network protocols, or different network types. These have led to the concept of component factories, where large software components are generated, which are general enough so that they can be reused for many different types of applications. These components could be stored around the Internet, and downloaded when a programmer requires to integrate them with their own program. [Link]
Figure 3 An ideal 'black-box' representation of a module
Figure 4 Hierarchical decomposition of a program
Traditional methods of programming involve writing a program which flows from one part to the next in a linear manner. The programs are designed using a top-down structured de-sign, where the task is split into a number of subtask (or submodules) and these are then called when they are required. This means that it is relatively difficult to interrupt the operation of a certain part of a program to do another activity, such as updating the graphics display. It is also an inefficient way of programming, as the program could be waiting for some other to occur, such as waiting for the user to press a key on the keyboard, as the computer could be doing something else while it is waiting.
An event-driven program differs from this method, and is written to respond to events, such as:
When the user clicks the mouse.
When the user presses a key on the keyboard.
When a character is received from a modem.
When the printer becomes busy.
Event-driven programs are typically more responsive to the user, as they can be made to respond to many different types of events. For example, the following are events that can occur when the user has selected a command button:
MouseOver event. Responding to the mouse cursor moving over the button.
KeyPress event. Responding to a key being press when the mouse cursor is over the button.
KeyUp event. Responding to a key being released.
KeyDown event. Responding to a key being pressed.
DblClick event. Responding to a double-click of a mouse button.
DragDrop event. Dragging another object on top of the button.
MouseDown event. Responds to a mouse button down.
MouseUp event. Responds to a mouse button up
LostFocus event. Responds another object being selected.
We live in a world full of objects; so object-oriented programming is a natural technique in developing programs. For example we have an object called a cup, and each cup has a number of parameters, such as its colour, its shape, its size, and so on. It is efficient for us to identify it as a cup, as we now that cups should be able to hold liquid, and we will place our cup beside all the other cups that we have. If we were a cup designer then we could list all the possible parameters of a cup, and for each design we could set the parameters. Some of the parameters might not actually be used, but for a general-purpose design we would specific every parameter that a cup might have. So let's design a cup. For a simple case we'll limit the choices for five main parameters:
Transparency (0 to 100%)
Handle type (Small/Large)
Thus we have three choices of shape (square, standard or mug), three choices of colour (red, blue or green), three choices in size (small, medium or large) and two choices of handle type (small or large). Also we can also chose a level of transparency of the cup from 0 to 100% (in integer steps. In object-oriented program the collection of parameters is known as a class. Thus we could have a class for our cup which encapsulates all the design parameters for our cup. The instance of our class, such as Cup 1, Cup 2 and Cup 3, is known as an object. We can create many objects from our class.
Many modern programming languages, such as Delphi, C++ and Java, now typically use object-oriented programming. It involves:
Classes. Defines a collection of parameters that can be used to define an object. For example, a class for a car may have the following parameters:
o Car type.
o Engine size.
Objects. Objects are created from classes. For example, as illustrated in Figure 3, two car objects could be created, as:
o Car 1 (Object 1). Car type = "Vauxhall", Colour = "Blue", Engine size= "1600".
o Car 2 (Object 2). Car type = "Ford", Colour = "Red", Engine size = "1000"
Object-oriented programming is an excellent programming technique as it involves creating a program around the data, and not, as in modular programming, around the modules. This allows for a much better definition of the problem.