Вы находитесь на странице: 1из 59

1.

INTRODUCTION AND OVERVIEW


1.1 COMPUTER ORGANIZATION
A computer, in short, is an information processor. Data and information can be entered
into the computer as input and then processed to produce output (see Figure 1.1)

Input

Computer

Output

Figure 1.1: Structure of a Computer


The physical components of a computer together with devices that perform the input and
output are referred to as hardware. A set of computer instruction performed by the
computer is called a computer program. A significant part of this course deals with
problem solving and how to design computer programs. The set of programs written for a
computer is referred to as software.
Functional Components of a computer
Generally, Computer hardware is divided into four main functional areas. These are Input
devices, Output devices, Central Processing Unit (CPU) and Memory, see Figure 1.2
below.

CONTROL
UNIT
INPUT

OUTPUT
ALU

MEMORY
Figure 1.2: Basic structure of a computer

MT 512: Programming Design

Page no: 1

1. Input Devices:
Allows getting data into the computer. A simple example of input device is keyboard.
2. Output devices:
Shows the result after processing data or information.
3. Central Processing Unit (CPU)
It is electronic circuit that manipulates data into the required information. That is,
CPU executes the computer instruction. It consists of two parts, Arithmetic Logic
Unit (ALU) and Control Unit (CU).
-

Arithmetic Logic Unit


It the Brain of the computer system, i.e., performs the most important operation
of the computer system arithmetic and logic operation on the data.

Control Unit
Directs and coordinates the execution of stored program instruction.

4. Memory
There are two kinds of computer memory: primary and secondary. Primary memory
is accessible directly by the processing unit. Random Access Memory (RAM) is an
example of primary memory. As soon as the computer is switched off the contents of
the primary memory is lost. You can store and retrieve data much faster with primary
memory compared to secondary memory. Secondary memory is used to store data
permanently. An example of this type of memory includes floppy disks, magnetic
disk. Primary memory is more expensive than secondary memory. Because of this the
size of primary memory is less than that of secondary memory.
Computer memory is used to store two things: (i) instructions to execute a program
and (ii) data. When the computer is doing any job, the data that have to be processed
are stored in the RAM. This data may come from an input device like keyboard or
from a secondary storage device like a floppy disk.
In computer all information are stored in the form of bits. A bit is a binary digit,
which is either 0 or 1. A unit of 8 bits is known as Byte.
Computer memory is expressed in terms of the number of bytes it can hold. The
number of bytes is expressed as kilobytes, 2 to the 10th power (210), or 1024 bytes.
kilobyte is abbreviated KB, or simply K. Thus, the memory of a 640K computer can
store 640 x 1024, or 655,360 bytes of data. Memory capacity is most often expressed
in terms of a megabyte (1024 x 1024), abbreviated MB. One megabyte is roughly
one million bytes. Some large computers express memory in terms of gigabytes
(abbreviated GB)-billions of bytes.

MT 512: Programming Design

Page no: 2

1.2 COMPUTER PROGRAMMING


1.2.1 Program
Computer is a dumb machine and it cannot do any work without instruction from the
user. It performs the instructions at tremendous speed and with accuracy. It is you to
decide what you want to do and in what sequence. So a computer cannot take its own
decision as you can. Therefore, it requires specific logically related instructions that the
developer feeds into a computer to solve a particular problem. These instructions are
termed as program.
We can acquire a program in two ways; packaged software and custom software.
Package software is a readymade set of programs while custom software is a set of
programs that a written according to the users requirements.
1.2.2 Programming Languages
What language will a programmer use to communicate with the computer? Surely not the
English language, which-like any human language-can be loose and ambiguous and full
of slang, variations, and complexities. A programming language is needed. A
programming language is a set of rules that provides a way of telling the computer what
operations to perform.
A programming language, the key to communicating with the computer, has certain
definite characteristics. It has a limited vocabulary. Each word" in it has precise
meaning. Even though a programming language has limitations, it can still be used in a
step-by-step fashion to solve complex problems. There is not, however, just one
programming language; there are many.
There are various kinds of programming languages used to create programs. An example
of these languages includes COBOL, BASIC, FORTRAN, C, C++, and Pascal. All
languages have a grammar of their own -known as syntax of the language.
Programs written in any language are represented in a binary form (series of 1s and 0s) so
that the computer can execute them. Thus, all programs written in different programming
languages are translated into the binary code before the computer can execute them.
1.2.3 Program Specifications
Before a program is written, a detail specification must be drawn up showing exactly
what is to be done by the program. This may have already been done for the programmer
or by another more senior programmer or a system analyst. It is very important that a
programmer should not start trying to write a computer program before a clear
specification has been created. Usually, such as a specification is in three main parts:
MT 512: Programming Design

Page no: 3

a) Input: a description of the format of the input data.


b) Output: a description of the format of output data.
c) Processing: a description of the processes of the program must follow to get the
output from the input.
1.2.4 Programming Circle
When preparing problem solutions for the computer, it is not enough just to know the
rules of a computer language. Problem-solving skills are essential to successful
programming. In solving a problem, developing a program requires five steps.
i.
ii.
iii.
iv.
v.

Defining the problem


Planning the solution
Coding the Program
Testing the Program
Documentation

i. Defining the Problem


Analyzing system requirements, i.e., kind of input, processing, and output required.
ii. Planning the solution
To solve programming problem, one must follow a methodical approach, i.e., design an
ordered set if activities that will convert a given input into the desired an algorithm (An
algorithm is a step-by-step procedure to solve a given problem) for the problem. An
algorithm consists of three main components. These are input, process and output.
Algorithms implemented by a computer are known as computer programs. A program
consists of basically the following operations: a) Sequence- in order
b) Selection - Choosing from set (e.g., ifelse)
c) Iteration Repetition
These three operations are sufficient to describe any algorithm.
There are many approaches to planning solution, the common one are flowcharts and
pseudocode. We will discuss these approaches in incoming chapters
iii.
Coding the Program
We need a language to express an algorithm. A computer algorithm requires a computer
language. There are many high-level languages, each with a different compiler, such as
FORTRAN, COBOL, C, C++, Pascal, ADA, ALGOL, BASIC, etc.
iv.

Testing the Program

MT 512: Programming Design

Page no: 4

Once the program code is written, it is very unlikely that it will be perfect on the first run.
Programming errors are common in the early versions of the program. Most programmers
use the phase: desk-checking, translating and debugging.
Desk-checking: Tracing down the program code to discover any error that might be
there. Similar to proof reading and may uncover several errors.
Translating: A translator is a program that converts the code into a language, which the
computer can understand. A compiler is a translator and has in-built capabilities of
detecting errors and produce a listing of them. These are mostly errors due to the
wrong syntax in the use of the language.
Debugging: Detecting errors (bugs) by running the program. Most of the errors in this
phase are due to the logic of the program
v.
Documenting the Program
Documenting the program is a detailed description of the programming cycle and specific
facts about the program. Documenting is an on-going process needed to supplement
human memory and help organize program planning. Documentation is also critical to
communication with other who might have an interest in your program. Typical
documentation materials include origin and nature of the problem, brief description of the
program, logic tools such as flowcharts and pseudocode, and testing results. Comments
on the program code are also an important part of documentation.

MT 512: Programming Design

Page no: 5

2. ALGORITHMS, FLOWCHARTS, DATA TYPES


AND PSEUDOCODE
2.1

ALGORITHMS

The term algorithm originally referred to any computation performed via a set of rules
applied to numbers written in decimal form. The word is derived from the phonetic
pronunciation of the last name of Abu Ja'far Mohammed ibn Musa al-Khowarizmi, who
was an Arabic mathematician who invented a set of rules for performing the four basic
arithmetic operations (addition, subtraction, multiplication and division) on decimal
numbers.
An algorithm is a representation of a solution to a problem. If a problem can be defined
as a difference between a desired situation and the current situation in which one is, then
a problem solution is a procedure, or method, for transforming the current situation to the
desired one. We solve many such trivial problems every day without even thinking about
it, for example making breakfast, travelling to the workplace etc. But the solution to such
problems requires little intellectual effort and is relatively unimportant. However, the
solution of a more interesting problem of more importance usually involves stating the
problem in an understandable form and communicating the solution to others. In the case
where a computer is part of the means of solving the problem, a procedure, explicitly
stating the steps leading to the solution, must be transmitted to the computer. This
concept of problem solution and communication makes the study of algorithms important
to computer science.
Throughout history, man has thought of ever more elegant ways of reducing the amount
of labour needed to do things. A computer has immense potential for saving time/energy,
as most (computational) tasks that are repetitive or can be generalised can be done by a
computer. For a computer to perform a desired task, a method for carrying out some
sequence of events, resulting in accomplishing the task, must somehow be described to
the computer. The algorithm can be described on many levels because the algorithm is
just the procedure of steps to take and get the result. The language used to describe an
algorithm to other people will be quite different from that which is used by the computer,
however the actual algorithm will in essence be the same. An example of an algorithm
people use would be a recipe to make a cake.
"4 extra large eggs, beaten
1&1/2 C. stock
1/2 teaspoon salt
1 scallion, minced
1 C. small shrimp or lobster flakes
1 t. soy sauce
1 Tablespoon oil
1. Mix all the ingredients, except the oil, in a deep bowl.

MT 512: Programming Design

Page no: 6

2.
3.
4.
5.

Put 1" water in wide pot, then place deep bowl of batter inside.
Cover pot tightly and steam 15 min.
Heat oil very hot and pour over custard.
Steam 5 more min.
Serves 4 people"

This breaks down 'Making Chinese egg custard' into smaller steps. To make the product
one still needs to know how to execute each of the steps in the procedure and understand
all of the terms.

Definition:
A procedure is a finite sequence of well-defined instructions, each of which can be
mechanically carried out in a finite amount of time.
The procedure must break up the problem solution into parts that the recipient party can
understand and execute. In the case of a computer, the problem solution is usually in the
form of a program that encompasses the algorithm and explains to the computer a clearly
defined procedure for achieving the solution. The procedure must consist of smaller steps
each of which the computers understand. There may be no ambiguities in the translation
of the procedure into the necessary action to be taken. A program is then just a specific
realisation of an algorithm, which may be executed on a physical device.
A computer is essentially a physical device designed to carry out a collection of primitive
actions. A procedure is a sequence of instructions written in terms of which evoke a
proper operation. To make effective use of an algorithm on a computer one must not only
find and understand a solution to the problem but also convey the algorithm to the
computer, giving the correct sequence of understood commands that represent the same
algorithm.

Definition:
An algorithm is procedure consisting of a finite set of unambiguous rules (instructions)
which specify a finite sequence of operations that provides the solution to a problem, or
to a specific class of problems for any allowable set of input quantities (if there are
inputs). In other word, an algorithm is a step-by-step procedure to solve a given
problem
Alternatively, we can define an algorithm as a set or list of instructions for carrying out
some process step by step. A recipe in a cookbook is an excellent example of an
algorithm. The recipe includes the requirements for the cooking or ingredients and the
method of cooking them until you end up with a nice cooked dish.
In the same way, algorithms executed by a computer can combine millions of elementary
steps, such as additions and subtractions, into a complicated mathematical calculation.
Also by means of algorithms, a computer can control a manufacturing process or co-

MT 512: Programming Design

Page no: 7

ordinate the reservations of an airline as they are received from the ticket offices all over
the country. Algorithms for such large-scale processes are, of course, very complex, but
they are built up from pieces.
One of the obstacles to overcome in using a computer to solve your problems is that of
translating the idea of the algorithm to computer code (program). People cannot normally
understand the actual machine code that the computer needs to run a program, so
programs are written in a programming language such as C or Pascal, which is then
converted into machine code for the computer to run.
In the problem-solving phase of computer programming, you will be designing
algorithms. This means that you will have to be conscious of the strategies you use to
solve problems in order to apply them to programming problems. These algorithms can
be designed though the use of flowcharts or pseudocode.

2.2 FLOWCHARTS
Flowcharting is a tool developed in the computer industry, for showing the steps
involved in a process. A flowchart is a diagram made up of boxes, diamonds and other
shapes, connected by arrows - each shape represents a step in the process, and the arrows
show the order in which they occur. Flowcharting combines symbols and flowlines, to
show figuratively the operation of an algorithm.
In computing, there are dozens of different symbols used in flowcharting (there are even
national and international flowcharting symbol standards). In business process analysis, a
couple of symbols are sufficient. A box with text inside indicates a step in the process,
while a diamond with text represents a decision point. See the figure for an example.
If the flowchart is too messy to draw, try starting again, but leaving out all of the decision
points and concentrating on the simplest possible course. Then the session can go back
and add the decision points later. It may also be useful to start by drawing a high-level
flowchart for the whole organisation, with each box being a complete process that has to
be filled out later.
From this common understanding can come a number of things - process improvement
ideas will often arise spontaneously during a flowcharting session. And after the session,
the facilitator can also draw up a written procedure - a flowcharting session is a good way
of documenting a process.
Process improvement starts with an understanding of the process, and flowcharting is the
first step towards process understanding.

MT 512: Programming Design

Page no: 8

Flowcharting Symbols
There are 6 basic symbols commonly used in flowcharting of assembly language
programs: Terminal, Process, input/output, Decision, Connector and Predefined Process.
This is not a complete list of all the possible flowcharting symbols, it is the ones used
most often in the structure of Assembly language programming.
Symbol

Name

Function

Process

Indicates any type of internal operation


inside the Processor or Memory

input/output

Used for any Input / Output (I/O) operation.


Indicates that the computer is to obtain data
or output results

Decision

Used to ask a question that can


be answered in a binary format (Yes/No,
True/False)

Connector

Allows the flowchart to be drawn without


intersecting lines or without a reverse flow.

Predefined Process

Used to invoke a subroutine or an


interrupt program.

Terminal

Indicates the starting or ending of the


program, process, or interrupt program.

Flow Lines

Shows direction of flow.

Generally, there are many standard flowcharting symbols.

General Rules for flowcharting


1. All boxes of the flowchart are connected with Arrows. (Not lines)
2. Flowchart symbols have an entry point on the top of the symbol with no other
entry points. The exit point for all flowchart symbols is on the bottom except for
the Decision symbol.
3. The Decision symbol has two exit points; these can be on the sides or the bottom
and one side.

MT 512: Programming Design

Page no: 9

4. Generally a flowchart will flow from top to bottom. However, an upward flow
can be shown as long as it does not exceed 3 symbols.
5. Connectors are used to connect breaks in the flowchart. Examples are:
From one page to another page.
From the bottom of the page to the top of the same page.
An upward flow of more then 3 symbols
6. Subroutines and Interrupt programs have their own and independent flowcharts.
7. All flow charts start with a Terminal or Predefined Process (for interrupt
programs or subroutines) symbol.
8. All flowcharts end with a terminal or a contentious loop.
Flowcharting uses symbols that have been in use for a number of years to represent the
type of operations and/or processes being performed. The standardised format provides a
common method for people to visualise problems together in the same manner. The use
of standardised symbols makes the flow charts easier to interpret, however, standardising
symbols is not as important as the sequence of activities that make up the process.

Flowcharting Tips

Chart the process the way it is really occurring. Do not document the way a written
process or a manager thinks the process happens.

People typically modify existing processes to enable a more efficient process. If the
desired or theoretical process is charted, problems with the existing process will not
be recognised and no improvements can be made.
Note all circumstances actually dealt with.
Test the flow chart by trying to follow the chart to perform the process charted. If
there is a problem performing the operation as charted, note any differences and
modify the chart to correct. A better approach would be to have someone unfamiliar
with the process try to follow the flow chart and note questions or problems found.

Include mental steps in the process such as decisions. These steps are sometimes left
out because of familiarity with the process, however, represent sources of problems
due to a possible lack of information used to make the decision can be inadequate or
incorrect if performed by a different person.

Examples of Algorithms and Flowcharts


Example 1. Design an algorithm and the corresponding flowchart for adding the test
scores as given below:
26, 49, 98, 87, 62, 75

MT 512: Programming Design

Page no: 10

a) Algorithm
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

Start
Sum = 0
Get the first testscore
Add first testscore to sum
Get the second testscore
Add to sum
Get the third testscore
Add to sum
Get the Forth testscore
Add to sum
Get the fifth testscore
Add to sum
Get the sixth testscore
Add to sum
Output the sum
Stop

b) The corresponding flowchart is as follows:


Start

Sum = 0

Get first testscore

Add First testscore


To sum

Get second testscore

Add second testscore


To sum
1

MT 512: Programming Design

Page no: 11

Get third testscore

Add third testscore


to sum
Get Forth testscore

Add forth testscore


to sum
Get Fifth testscore
Add fifth testscore to sum

Get Six testscore


Add sixth testscore to
sum

Output Sum

STOP
The algorithm and the flowchart above illustrate the steps for solving the problem of
adding six testscores. Where one testscore is added to sum at a time. Both the algorithm
and flowchart should always have a Start step at the beginning of the algorithm or
flowchart and at least one stop step at the end, or anywhere in the algorithm or flowchart.
Since we want the sum of six testscore, then we should have a container for the resulting
sum. In this example, the container is called sum and we make sure that sum should start
with a zero value by step 2.

MT 512: Programming Design

Page no: 12

Example 2: The problem with this algorithm is that, some of the steps appear more than
once, i.e. step 5 get second number, step 7, get third number, etc. One could shorten the
algorithm or flowchart as follows:
1.
2.
3.
4.
5.
6.
7.

Start
Sum = 0
Get a value
sum = sum + value
Go to step 3 to get next Value
Output the sum
Stop

Start
Sum =
Get a value

Sum = sum + value

Output

STOP
This algorithm and its corresponding flowchart are a bit shorter than the first one. In this
algorithm, step 3 to 5 will be repeated, where a number is obtained and added to sum.
Similarly the flowchart indicates a flowline being drawn back to the previous step
indicating that the portion of the flowchart is being repeated. One problem indicates that
these steps will be repeated endlessly, resulting in an endless algorithm or flowchart. The
algorithm needs to be improved to eliminate this problem. In order to solve this problem,
we need to add a last value to the list of numbers given. This value should be unique so
that, each time we get a value, we test the value to see if we have reached the last value.
In this way our algorithm will be a finite algorithm which ends in a finite number of steps
as shown below. There are many ways of making the algorithm finite.
The new list of numbers will be 26, 49, 498, 9387, 48962, 1, -1. The value 1 is a unique
number since all other numbers are positive.
1. Start
2. Sum = 0
3. Get a value

MT 512: Programming Design

Page no: 13

4.
5.
6.
7.
8.

If the value is equal to 1, go to step 7


Add to sum ( sum = sum + value)
Go to step 3 to get next Value
Output the sum
Stop

Corresponding flowchart

START
Sum = 0

Get a value

Value
= -1

Yes

No
Sum = Sum + Value

Output Sum

STOP

3. DATA TYPES
Although some contemporary languages allow programmers to invent his own data
types, and define their related operations, there are a number of traditional data types
found in most languages:
Integer
Integers are numeric data items, which are either positive or negative including zero, i.e.
1, 488, -22, 0, 456. Some programming languages put restrictions on the magnitude of
integers which may be used in program instructions. These restrictions are usually
dependent on the size of the memory location of the computer in which the language
may run.

MT 512: Programming Design

Page no: 14

Real Numbers
There are two types of real numbers, Fixed-Point and Floating Point.
Fixed Point
Fixed point data items are numbers which have embedded decimal point i.e. 1.5,
458.4589, -0.569.
Floating Point
Floating point data items are numbers, which are, held as binary fractions by a computer.
The numbers are expressed in a form where you have a mantissa and an exponent, for
example
Number
12.3
= 0.123 * 102
123000 = 0.123 * 106
0.000123 =0.123 * 10-3

Mantissa
0.123
0.123
0.123

Exponent
2
6
-3

Floating point representation of data is used to overcome the restrictions placed on the
magnitude of numbers by the size of computers memory locations.

Character
Character data, sometimes referred to as string data, may consist of any digits, letters of
the alphabet or symbols which, the internal coding system of the computer is capable of
representing. Many programming languages require character data to be enclosed by
quotation marks when used in program instructions, for example PRINT HAPPY NEW
YEAR.
Boolean
Boolean data items are used as status indicators and may contain only one of two possible
values: True or False.
DATA ITEM
There are two basic methods of using data items in a program:

a)
Constants
Data items are sometimes required to keep their values throughout the program, hence the
term constant. A constant is a specific value or character string used explicitly in an
operation. Consider the constant values 47.5, 1, and 13 in the example below.
Multiply by 47.5
Add 1 to
If = 13
Print PLEASE INPUT TODAYS DATE

MT 512: Programming Design

Page no: 15

b)

Variables and Variable names

A variable is a symbolic name assigned to a data item by the programmer. At any


particular time, a variable will stand for one particular data, called the value of a variable,
which may change from time to time during a computing process. The value of a variable
may change many times during the execution of a program. A variable is usually given a
name by the programmer.

Assignment
The assignment operation has the form:
variable := expression. (Pascal)
variable = expression. (C/C++/Java)
The assignment operation is used to assign a name to a value. Thus it is used whenever
you need to keep track of a value that is needed later. Some typical uses include:

initialize a variable ( count = 0 )


increment/decrement a counter ( count = count + 1 )

accumulate values ( sum = sum + item )


capture the result of a computation ( y = 3*x + 4 )
swap two values ( t = x; x = y; y = t )

The assignment operator is not commute i.e. x = e is not the same as e = x. The variable
must be declared. Variables used in the expression must be defined (have values). The
type of the expression must be compatible with the type of the variable.
The order in which assignments are performed is important for example, if the first and
second assignments in the swap sequence were interchanged, x and y would end up
assigned to the same value. The input operation and the output operation share some of
the same constraints.

2.5 PSEUDOCODE
Pseudocode is one of the tools that can be used to write a preliminary plan that can be
developed into a computer program. Pseudocode is a generic way of describing an
algorithm without use of any specific programming language syntax. It is, as the name
suggests, pseudo code it cannot be executed on a real computer, but it models and
resembles real programming code, and is written at roughly the same level of detail.
Pseudocode, by nature, exists in various forms, although most borrow syntax from
popular programming languages (like C, Lisp, or FORTRAN). Natural language is used
whenever details are unimportant or distracting.
MT 512: Programming Design

Page no: 16

Computer science textbooks often use pseudocode in their examples so that all
programmers can understand them, even if they do not all know the same programming
languages. Since pseudocode style varies from author to author, there is usually an
accompanying introduction explaining the syntax used.
In the algorithm design, the steps of the algorithm are written in free English text and,
although brevity is desired, they may be as long as needed to describe the particular
operation. The steps of an algorithm are said to be written in pseudocode.
Many languages, such as Pascal, have a syntax that is almost identical to pseudocode and
hence make the transition from design to coding extremely easy.
The following section deal with the control structures (control constructs) Sequence,
Selection and Iteration or Repetition.

CONTROL STRUCTURES OR LOGICAL STRUCTURES


The key to better algorithm design and thus to programming lies in limiting the control
structure to only three constructs. These are illustrated below:

The sequence structure


The first type of control structures is called the sequence structure. This structure is the
most elementary structure. The sequence structure is a case where the steps in an
algorithm are constructed in such a way that, no condition step is required. The sequence
structure is the logical equivalent of a straight line.
For example, suppose you are required to design an algorithm for finding the average of
six numbers, and the sum of the numbers is given. The pseudocode will be as follows
Start
Get the sum
Average = sum / 6
Output the average
Stop
The corresponding flowchart will appear as follows:

MT 512: Programming Design

Page no: 17

Start

Get the sum

Average = sum/6

Output sum

Stop

Example 3: This is the pseudo-code required to input three numbers from the keyboard
and output the result.
Use variables: sum, number1, number2, number3 of type integer
Accept number1, number2, number3
Sum = number1 + number2 + number3
Print sum
End program
Example 4: The following pseudo-code describes an algorithm which will accept two
numbers from the keyboard and calculate the sum and product displaying the answer on
the monitor screen.
Use variables sum, product, number1, number2 of type real
display Input two numbers
accept number1, number2
sum = number1 + number2
print The sum is , sum
product = number1 * number2
print The Product is , product
end program
Decision Structure or Selection Structure
The decision structure or mostly commonly known as a selection structure, is case where
in the algorithm, one has to make a choice of two alternatives by making decision
depending on a given condition.

MT 512: Programming Design

Page no: 18

Selection structures are also called case selection structures when there are two or more
alternatives to choose from.
This structure can be illustrated in a flowchart as follows:

True

Condition

False

Task-A

Task-B

In pseudocode form we get


If condition is true
Then do task A
else
Do Task-B
In this example, the condition is evaluated, if the condition is true Task-A is evaluated
and if it is false, then Task-B is executed.
A variation of the construct of the above figure is shown below

False
Condition
True
Task-A

From the above structure, we have the following

MT 512: Programming Design

Page no: 19

If condition is true then


Do Task-A
In this case, if condition is false, nothing happens. Otherwise Task-A is executed.
The selection requires the following
Choose alternative actions as a result of testing a logical condition
Produce code to test a sequence of logical tests

Making Choices
There are many occasions where a program is required to take alternative actions. For
example, there are occasions where we need to take action according to the user choice.
All computer languages provide a means of selection. Usually it is in the form of If
statement and our pseudo-code is no exception to this.
We will use the if statement together with logical operators to test for true or false as
shown below.
If a = b
print a = b
The action is only taken when the test is true.
The logical operators used in our pseudo-code are
=
is equal to
>
is greater than
<
is less than
>=
is greater than or equal
<=
is less than or equal
<>
is not eaqual to
Example 5: The following shows how the selection control structure is used in a program
where a user chooses the options for multiplying the numbers or adding them or
subtracting.
Use variables: choice, of the type character
ans, number1, number2, of type integer
display choose one of the following
display m for multiply
display a for add
display s for subtract
accept choice
display input two numbers you want to use
accept number1, number2

MT 512: Programming Design

Page no: 20

if choice = m then ans = number1 * number2


if choice = a then ans = number1 + number2
if choice = s then ans = number1 - number2
display ans

Compound Logical Operators


There are many occasions when we need to extend the conditions that are to be tested.
Often there are conditions to be linked.
In everyday language we say things like If I had the time and the money I would go on
holiday. The and means that both conditions must be true before we take an action. We
might also say I am happy to go to the theatre or the cinema. The logical link this time
is or . Conditions in if statements are linked in the same way. Conditions linked with and
only result in an action when all conditions are true. For example, if a >b and a > c then
display a is the largest. Conditions linked with an or lead to an action when either or
both are true.
Example 6: The program is to input a examination mark and test it for the award of a
grade. The mark is a whole number between 1 and 100. Grades are awarded according to
the following criteria:
>=
>=
>=
<

80 Distinction
60 Merit
40 Pass
40 fail

The pseudo-code is
Use variables: mark of type integer
If mark >= 80 display distinction
If mark >= 60 and mark < 80 display merit
If mark >= 40 and mark < 60 display pass
If mark < 40 display fail
An if statement on its own is often not the best way of solving problems. A more elegant
set of conditions can be created by adding an else statement to the if statement. The else
statement is used to deal with situations as shown in the following examples.
Example 7: A person is paid at top for category 1 work otherwise pay is at normal rate.
If the work is category 1
pay-rate is top
Else
pay-rate is normal

MT 512: Programming Design

Page no: 21

The else statement provides a neat way of dealing with alternative condition. In pseudocode we write
If work = cat1 then p-rate: = top
Else p-rate = normal
Or
If work = cat1 then
p-rate: = top
Else
p-rate = normal
The following example illustrate the use of if else statements in implementing double
alternative conditions.
If salary < 50000 then
Tax = 0
Else
If salary > 50000 AND salary < 100000 then
Tax = 50000 * 0.05
Else
Tax = 100000 * 0.30
The case statement
Repeating the if else statements a number of times can be somewhat confusing. An
alternative method provided in a number of languages is to use a selector determined by
the alternative conditions that are needed. In our pseudo-code, this will called a case
statement.
Example 8: The following program segment outputs a message to the monitor screen
describing the insurance available according to a category input by the user.
Use variables: category of type character
Display input category
Accept category
If category = U
Display insurance is not available
Else
If category = A then
Display insurance is double
Else
If category = B then
Display insurance is normal
Else
If category = M then
Display insurance is medically dependent
Else
Display entry invalid

MT 512: Programming Design

Page no: 22

This can be expressed in a case statement as follows:


Use variables: category of type character
Display input category
Accept category
DO case of category
CASE category = U
Display insurance not available
CASE category = A
Display insurance is double
CASE category = B
Display insurance is normal
CASE category = M
Display insurance is medically dependent
OTHERWISE
Display entry is invalid
ENDCASE
Instead of using the word otherwise, one can use else.
Repetition or Iteration Structure
A third structure causes the certain steps to be repeated.

Condition

False

True
Task

The Repetition structure can be implemented using


Repeat Until Loop
The While Loop
The For Loop

Any program instruction that repeats some statement or sequence of statements a number
of times is called an iteration or a loop. The commands used to create iterations or loops

MT 512: Programming Design

Page no: 23

are all based on logical tests. There three constructs for iterations or loops in our pseudocode.
The Repeat Until loop.
The syntax is
REPEAT
A statement or block of statements
UNTIL a true condition
Example 9: A program segment repeatedly asks for entry of a number in the range 1 to
100 until a valid number is entered.
REPEAT
DISPLAY Enter a number between 1 and 100
ACCEPT number
UNTIL number < 1 OR number > 100
Example 10. A survey has been carried out to discover the most popular sport. The
results will be typed into the computer for analysis. Write a program to accomplish this.
REPEAT
DISPLAY Type in the letter chosen or Q to finish
DISPLAY A: Athletics
DISPLAY S: Swimming
DISPLAY F: Football
DISPLAY B: Badminton
DISPLAY Enter data
ACCEPT letter
If letter = A then
Athletics = athletics + 1
If letter = S then
Swimming = Swimming + 1
If letter = F then
Football = Football + 1
If letter = B then
Badminton = Badminton + 1
UNTIL letter = Q
DISLAY Athletics scored, athletics, votes
DISLAY Swimming scored, swimming, votes
DISLAY Football scored, football, votes
DISLAY Badminton scored, Badminton, votes
The WHILE loop
The second type of iteration we will look at is the while iteration. This type of conditional
loop tests for terminating condition at the beginning of the loop. In this case no action is
performed at all if the first test causes the terminating condition to evaluate as false.

MT 512: Programming Design

Page no: 24

The syntax is
WHILE (a condition is true)
A statement or block of statements
ENDWHILE
Example 11: A program segment to print out each character typed at a keyboard until the
character q is entered.
WHILE letter <> q
ACCEPT letter
DISPLAY The character you typed is, letter
ENDWHILE
Example 12: Write a program that will output the square root of any number input until
the number input is zero.
In some cases, a variable has to be initialised before execution of the loop as shown in
the following example.
Use variable: number of type real
DISPLAY Type in a number or zero to stop
ACCEPT number
WHILE number <> 0
Square = number * number
DISPLAY The square of the number is, square
DISPLAY Type in a number or zero to stop
ACCEPT number
ENDWHILE
The FOR Loop
The third type of iteration, which we shall use when the number of iterations is known in
advance, is a for loop. This, in its simplest form, uses an initialisation of the variable as a
starting point, a stop condition depending on the value of the variable. The variable is
incremented on each iteration until it reaches the required value.
The pseudo-code syntax will be:
FOR (starting state, stopping condition, increment)
Statements
ENDFOR
Example 13.
FOR (n = 1, n <= 4, n + 1)
DISPLAY loop, n
ENDFOR
The fragment of code will produce the output
Loop 1
Loop 2
Loop 3
Loop 4

MT 512: Programming Design

Page no: 25

In the example, n is usually referred as the loop variable, or counting variable, or index of
the loop. The loop variable can be used in any statement of the loop. The variable should
not be assigned a new value within the loop, which may change the behaviour of the
loop.
Example 14: Write a program to calculate the sum and average of a series of numbers.
The pseudo-code solution is:
Use variables: n, count of the type integer
Sum, number, average of the type real
DISPLAY How many numbers do you want to input
ACCEPT count
SUM = 0
FOR (n = 1, n <= count, n + 1)
DISPLAY Input the number from your list
ACCEPT number
SUM = sum + number
ENDFOR
Average = sum / count
DISPLAY The sum of the numbers is , sum
DISPLAY Average of the numbers is , average
Flowcharts have been used in this section to illustrate the nature of the three control
structures. These three are the basic control structures out of which all programs are built.
Beyond this, flowcharts serve the programmer in two distinct ways: as problem solving
tools and as tools for documenting a program.
Example
Design an algorithm and the corresponding flowchart for finding the sum of n numbers.
Pseudocode Program
Start
Sum = 0
Display Input value n
Input n
For(I = 1, n, 5)
Input a value
Sum = sum + value
ENDFOR
Output sum
Stop
In this example, we have used I to allow us to count the numbers, which we get for the
addition. We compare I with n to check whether we have exhausted the numbers or not in
order to stop the computation of the sum (or to stop the iteration structure). In such a
case, I is referred to as a counter.

MT 512: Programming Design

Page no: 26

The corresponding flowchart will be as follows:


Start
Sum = 0
I=1

Input a number

True
I>n

False

Output Sum

Sum = sum + number


Stop
I=I+1

Exercise
1. Design an algorithm and the corresponding flowchart for finding the sum of
the numbers 2, 4, 6, 8, , n
2. Using flowcharts, write an algorithm to read 100 numbers and then display the
sum.
3. Write an algorithm to read two numbers then display the largest.
4. Write an algorithm to read two numbers then display the smallest
5. Write an algorithm to read three numbers then display the largest.
6. Write an algorithm to read 100 numbers then display the largest.

MT 512: Programming Design

Page no: 27

CHAPTER

3
ALGORITHMIC PROBLEM SOLVING
In this chapter you will learn about
What an algorithm is.
The relationship between data and algorithm.
The characteristics of an algorithm.
Using pseudo-codes and flowcharts to represent algorithms.

32

Chapter 3

Algorithmic Problem Solving

3.1 Algorithms
In Chapter 2, we expounded the working of problem solving from a general
perspective. In computing, we focus on the type of problems categorically
known as algorithmic problems, where their solutions are expressible in the
form of algorithms.
An algorithm 1 is a well-defined computational procedure consisting of a
set of instructions, that takes some value or set of values, as input, and
produces some value or set of values, as output. In other word, an algorithm
is a procedure that accepts data, manipulate them following the prescribed
steps, so as to eventually fill the required unknown with the desired value(s).

Input

Algorithm

Output

Tersely put, an algorithm, a jargon of computer specialists, is simply a


procedure. People of different professions have their own form of procedure
in their line of work, and they call it different names. A cook, for instance,
follows a procedure commonly known as a recipe that converts the
ingredients (input) into some culinary dish (output), after a certain number of
steps.
An algorithm, whose characteristics will be discussed later, is a form that
embeds the complete logic of the solution. Its formal written version is
called a program, or code. Thus, algorithmic problem solving actually
comes in two phases: derivation of an algorithm that solves the problem, and
conversion of the algorithm into code. The latter, usually known as coding,
is comparatively easier, since the logic is already present it is just a matter
of ensuring that the syntax rules of the programming language are adhered to.
The first phase is what that stumbles most people, for two main reasons.
Firstly, it challenges the mental faculties to search for the right solution, and
secondly, it requires the ability to articulate the solution concisely into stepby-step instructions, a skill that is acquired only through lots of practice.
Many people are able to make claims like oh yes, I know how to solve it,
but fall short when it comes to transferring the solution in their head onto
paper.
Algorithms and their alter ego, programs, are the software. The machine
that runs the programs is the hardware. Referring to the cook in our analogy
again, his view can be depicted as follows:

The term algorithm was derived from the name of Mohammed al-Khowarizmi, a Persian mathematician in the ninth
century. Al-Khowarizmi Algorismus (in Latin) Algorithm.

3.1

Algorithms

33

ingredients

recipe
(software)

Cooking utensils
(hardware)

Ah-gong
bah-kut-teh
The first documented algorithm is the famous Euclidean algorithm written
by the Greek mathematician Euclid in 300 B.C. in his Book VII of the
Elements. It is rumoured that King Ptolemy, having looked through the
Elements, hopefully asked Euclid if there were not a shorter way to geometry,
to which Euclid severely answered: In geometry there is no royal road!
The modern Euclidean algorithm to compute gcd (greatest common
divisor) of two integers, is often presented as followed.
1. Let A and B be integers with A > B 0.
2. If B = 0, then the gcd is A and the algorithm ends.
3. Otherwise, find q and r such that
A = qB + r where 0 r < B
Note that we have 0 r < B < A and gcd(A,B) = gcd(B,r).
Replace A by B, and B by r. Go to step 2.
Walk through this algorithm with some sets of values.

34

Chapter 3

Algorithmic Problem Solving

3.2 Data Types And Data Structures


In algorithmic problem solving, we deal with objects. Objects are data
manipulated by the algorithm. To a cook, the objects are the various types of
vegetables, meat and sauce. In algorithms, the data are numbers, words, lists,
files, and so on. In solving a geometry problem, the data can be the length of
a rectangle, the area of a circle, etc. Algorithm provides the logic; data
provide the values. They go hand in hand. Hence, we have this great truth:
Program = Algorithm + Data Structures
Data structures refer to the types of data used and how the data are
organised in the program. Data come in different forms and types. Most
programming languages provides simple data types such as integers, real
numbers and characters, and more complex data structures such as arrays,
records and files which are collections of data.
Because algorithm manipulates data, we need to store the data objects
into variables, and give these variables names for reference. For example, in
mathematics, we call the area of a circle A, and express A in terms of the
radius r. (In programming, we would use more telling variable names such as
area and radius instead of A and r in general, for the sake of readability.)
When the program is run, each variable occupies some memory location(s),
whose size depends on the data type of the variable, to hold its value.

3.3 Characteristics Of An Algorithm


What makes an algorithm an algorithm? There are four essential properties
of an algorithm.
1. Each step of an algorithm must be exact.
This goes without saying. An algorithm must be precisely and
unambiguously described, so that there remains no uncertainty. An
instruction that says shuffle the deck of card may make sense to
some of us, but the machine will not have a clue on how to execute it,
unless the detail steps are described. An instruction that says lift the
restriction will cause much puzzlement even to the human readers.
2. An algorithm must terminate.
The ultimate purpose of an algorithm is to solve a problem. If the
program does not stop when executed, we will not be able to get any
result from it. Therefore, an algorithm must contain a finite number
of steps in its execution. Note that an algorithm that merely contains
a finite number of steps may not terminate during execution, due to
the presence of infinite loop.

3.3

Characteristics Of An Algorithm 35

3. An algorithm must be effective.


Again, this goes without saying.
correct answer to the problem.

An algorithm must provide the

4. An algorithm must be general.


This means that it must solve every instance of the problem. For
example, a program that computes the area of a rectangle should work
on all possible dimensions of the rectangle, within the limits of the
programming language and the machine.
An algorithm should also emphasise on the whats, and not the hows,
leaving the details for the program version. However, this point is more
apparent in more complicated algorithms at advanced level, which we are
unlikely to encounter yet.

3.4 Pseudo-Codes And Flowcharts


We usually present algorithms in the form of some pseudo-code, which is
normally a mixture of English statements, some mathematical notations, and
selected keywords from a programming language. There is no standard
convention for writing pseudo-code; each author may have his own style, as
long as clarity is ensured.
Below are two versions of the same algorithm, one is written mainly in
English, and the other in pseudo-code. The problem concerned is to find the
minimum, maximum, and average of a list of numbers. Make a comparison.
Algorithm version 1:
First, you initialise sum to zero, min to a very big number, and max to a
very small number.
Then, you enter the numbers, one by one.
For each number that you have entered, assign it to num and add it to the
sum.
At the same time, you compare num with min, if num is smaller than min,
let min be num instead.
Similarly, you compare num with max, if num is larger than max, let max
be num instead.
After all the numbers have been entered, you divide sum by the numbers of
items entered, and let ave be this result.
End of algorithm.

36

Chapter 3

Algorithmic Problem Solving

Algorithm version 2:
sum count 0

{ sum = sum of numbers;


count = how many numbers are entered? }
{ min to hold the smallest value eventually }
{ max to hold the largest value eventually }

min ?
max ?
for each num entered,
increment count
sum sum + num
if num < min then min num
if num > max then max num
ave sum/count

Note the use of indentation and symbols in the second version. What
should min and max be initialised with?
Algorithms may also be represented by diagrams. One popular
diagrammatic method is the flowchart, which consists of terminator boxes,
process boxes, and decision boxes, with flows of logic indicated by arrows.
The flowchart below depicts the same logic as the algorithms above.
start

Terminator box
Process box

sum count 0
min ?
max ?

Yes

Decision box

end of
input?
No
increment count
sum sum + num

num<min?
ave sum/count

min num

No

num>max?
end

Yes

Yes

max num

No

Whether you use the pseudo-code or the flowchart to represent your


algorithm, remember to walk through it with some sets of data to check that
the algorithm works.

3.5

Control Structures 37

3.5 Control Structures


The pseudo-code and flowchart in the previous section illustrate the three types
of control structures. They are:
1. Sequence
2. Branching (Selection)
3. Loop (Repetition)
These three control structures are sufficient for all purposes. The sequence
is exemplified by sequence of statements place one after the other the one
above or before another gets executed first. In flowcharts, sequence of
statements is usually contained in the rectangular process box.
The branch refers to a binary decision based on some condition. If the
condition is true, one of the two branches is explored; if the condition is false,
the other alternative is taken. This is usually represented by the if-then
construct in pseudo-codes and programs. In flowcharts, this is represented by
the diamond-shaped decision box. This structure is also known as the selection
structure.
The loop allows a statement or a sequence of statements to be repeatedly
executed based on some loop condition. It is represented by the while and
for constructs in most programming languages, for unbounded loops and
bounded loops respectively. (Unbounded loops refer to those whose number of
iterations depends on the eventuality that the termination condition is satisfied;
bounded loops refer to those whose number of iterations is known beforehand.) In the flowcharts, a back arrow hints the presence of a loop. A trip
around the loop is known as iteration. You must ensure that the condition for
the termination of the looping must be satisfied after some finite number of
iterations, otherwise it ends up as an infinite loop, a common mistake made by
inexperienced programmers. The loop is also known as the repetition structure.
Combining the use of these control structures, for example, a loop within a
loop (nested loops), a branch within another branch (nested if), a branch within
a loop, a loop within a branch, and so forth, is not uncommon. Complex
algorithms may have more complicated logic structure and deep level of
nesting, in which case it is best to demarcate parts of the algorithm as separate
smaller modules. Beginners must train themselves to be proficient in using and
combining control structures appropriately, and go through the trouble of
tracing through the algorithm before they convert it into code.

3.6

Summary

An algorithm is a set of instructions, and an algorithmic problem lends itself to


a solution expressible in algorithmic form. Algorithms manipulate data, which
are represented as variables of the appropriate data types in programs. Data
structures are collections of data.
The characteristics of algorithms are presented in this chapter, so are the
two forms of representation for algorithms, namely, pseudo-codes and
flowcharts. The three control structures: sequence, branch, and loop, which
provide the flow of control in an algorithm, are introduced.

38

Chapter 3

Algorithmic Problem Solving

Exercises
In the exercises below, you are asked to find the answers by hand, and jot
down the steps involved for the generalized versions. You need not write
programs for them yet you will be doing that later you need only to
discover the steps and put them down into an algorithm.
1.

Our coins come in denominations of 1 cent, 5 cents, 10 cents, 20 cents,


50 cents and 1 dollar. Assuming that there are unlimited number of
coins, how would you devise a coin-change algorithm to compute the
minimum number of coins required to make up a particular amount?
For example, for 46 cents you need 4 coins: two 20-cent coins, one 5cent coin, and one 1-cent coin.

2.

How would you sort 10 numbers in increasing order? Do you know any
of the basic sorting techniques?

3.

A word is a palindrome if it reads the same when the order of its


characters is reversed. For instance, 123321, RADAR and step on
no pets are palindromes. Derive an algorithm to determine if a word is
a palindrome.

4.

Two words are anagrams of each other if they differ only by the order
of their characters. For example, HATE and HEAT, NOW and
WON, reset and steer are anagrams, but sell and less are not.
Write an algorithm to determine if two given words are anagrams.

5.

How do you test for primality? That is, given a positive integer, how
do you determine that it is a prime number?

6.

In a mastermind game, the code maker hides a secret code consisting of


4 digits, and the code breaker is to provide 4-digit guess codes until he
gets the code right. The code maker gives feedback in this manner, a
sink is awarded to a perfect match of a digit plus its position, and a hit
refers to a right match of digit but in the wrong position. How do you
devise an algorithm to provide the correct feedback? First, work on the
special case that no digit in the code should be repeated. Then work on
the general case where digits can be duplicated.

4. PROGRAMMING APPROACHES
Organizations and individuals are continually searching for more efficient ways to
perform the software development process.
One-way of reducing the time and cost of development is to standardize software
programs and the programming process. The benefits of standardized programs are that
they are easier to code, maintain, debug, and modify.
In recent years, a variety of techniques have appeared attempting to minimize differences
in the way programmers' design and develop software. A few of the most commonly used
techniques for standardization are described in this lesson.
Programming Approaches: Nonstructured Vs. Structured Approaches
Structured programming is a standardization technique used for software development.
This approach works by having all programmers use the same structured design
techniques. Structured programming was invented to address the shortcomings of nonstructured programming, which frequently employed GO TO branch points to transfer
from one part of the program to another part. Using GO TO codes, one could transfer
backward, forward, or anywhere else within the program. The problem is that the
connections between parts of the program by using GO TO commands can become quite
haphazard.
The haphazard and sometimes convoluted pattern of linkages between parts of the
program has been called spaghetti code. This type of programming is difficult to
understand and debug. Non-structured programming of this nature is now viewed as an
ineffective programming strategy.
To develop good software, developers have to carefully think out and design the
programs. In the earliest days of computing, programmers wrote software according to
their own whims, with the result that programs were often confusing and difficult to work
with. Software today is expected to follow recognised design principles. The prevailing
design standards are structured programming and structured design.
4.1 STRUCTURED PROGRAMMING
Structured programming makes use of the control structures (sequence, selection and
repetition). Structured programming does not use GO TO commands. The sequence
principle implies that program instructions should be executed in the order in which they
appear. The selection principle implies that instructions may be executed selectively
using IF-THEN and/or IF-THEN-ELSE statements. These statements work in the
following way. IF a condition is met or is true, THEN a specific set of instructions will be
executed. If the condition is false, then another set of instructions will be executed.
MT 512: Programming Design

Page no: 38

For example, IF an employee works 40+ hours a week, THEN calculate gross pay based
on an overtime rate of time and a half. If the employee does not work 40+ hours a week,
THEN calculate gross pay based on the normal hourly pay rate. IF-THEN-ELSE works in
a similar way, but in this case the word ELSE is substituted for a false case, a condition
that is not met. IF the employee works 40+ hours a week, then calculate gross pay base
on a time and a half pay rate, ELSE calculate gross pay based on the normal rate.
Alternatively when there are many options, one can employ the CASE statement.
The iteration principle indicates that one part of the program can be repeated or iterated a
limited number of times. In most computer languages, the iteration may be activated by
using REPEAT ---UNTIL or using the WHILE loop and the FOR loop.
4.2

STRUCTURED DESIGN

According to structured design principles, a program should be designed from the topdown or bottom-up as a hierarchical series of modules. A module is a logical way of
partitioning or subdividing a program so that each module performs one or a small
number of related tasks.
4.2.1

Modular Programming

The Modular Approach to programming involves breaking a program down into


subcomponents called modules. Each module is composed of an independent or selfcontained set of instructions. Modules are also referred to as routines, subroutines, or
subprograms or procedures. Each module is designed to perform a specific task in the
overall program, such as to calculate the gross pay of an employee in a payroll program.
The advantage of modular programming is the ability to write and test each module
independently and in some cases reuse modules in other programs. A program consists of
multiple modules. In addition, there is a main module in the program that executes the
other modules.
You can use the following approaches in order to design a program consisting of
modules.
4.2.2

Top-Down Design or Top-Down Decomposition

One programming approach that has proven to be most productive is called top-down
decomposition. Top-down decomposition is the process of breaking the overall procedure
or task into component parts (modules) and then subdivide each component module until
the lowest level of detail has been reached. It is called top-down design or top-down
decomposition since we start "at the top" with a general problem and design specific
solutions to its sub problems. In order to obtain an effective solution for the main

MT 512: Programming Design

Page no: 39

problem, it is desirable that the subproblems (subprograms) should be independent of


each other. Then each sub-problem can be solved and tested by itself.
The top level of the decomposition is the level of the overall plan. Unfortunately there is
no single formula that will decompose a complex problem into individual tasks. The
strategy involves top-down reduction of the processing until a level is reached where
each of the individual processes consists of one self-contained task, which is relatively
easy to understand and can be programmed in a few instructions.
This stepwise process may create multiple layers or levels of modules beginning with a
main module at the top. The second level might contain intermediate modules, and the
third level minor modules. The program is developed from the top in stepwise fashion.
Using this method, a complex problem is separated into simpler parts, which can be
programmed easily. At each stage, the instructions or steps can be checked for errors in
logic, corrected or modified without any effect on the other subprograms. The result will
be a truly modular program that satisfies the requirement, which says a good program
can be modified easily.
This programming strategy focuses on developing a software program conceptually
before coding begins. A programming team will likely create a diagram that looks much
like an organisational chart with the main module at the top and subordinate modules
down below connected by lines with each box representing a program module. The chart
shows how modules relate to each other but does not depict the details of the program
instructions in each module. The structure chart is usually referred to as a Hierarchical
Program Organisation (HIPO)
Example top-down decomposition
The payroll system of a company can contain the following modules or tasks

Master file
Earnings
Deductions
Taxing
Net earning
Print reports

The tasks given above can be depicted in a hierarchical chart (Hierarchical Program
Organisation) as shown below.

MT 512: Programming Design

Page no: 40

PAYROLL PROBLEM

Master File

Create
Master
File

Update
Master
File

Earnings

Create
Earning
File

Update
Earning
File

Deductions

Create
Deduction
File

Taxing

Update
Deduction
File

Create or
update Tax
File

Identifying and diagramming the relationship between modules in this fashion allows
programmers to focus on the overall organisation and logic of the program without
getting bogged down in the details. Once the overall structure of the program is finalised,
detail coding of individual modules can proceed.
It is the set of principles that enable a problem to be solved by breaking it down into
manageable parts, step-by-step from the overall problem specification, in stages through
to the actual code.
4.2.3 Bottom-up Design
Already existing facilities/designs are used/taken into consideration as a model for a new
(better) design. Using Bottom-up design strategy, we take an already existing computer
program as a model for our new program. We try to utilise the existing facilities or design
in a way, which gives out program a better performance.
4.2.3 Stepwise Refinement
Stepwise refinement is a top-down design strategy. The program is developed by
successively refining levels of procedural detail. In each step of the refinement, one or
several instructions of the given program are decomposed into more detailed instructions.
This successive decomposition or refinement of specifications terminates when all
instructions are expressed in terms of any underlying computer or programming
language.
Every refinement step implies some design decisions. It is important that the programmer
is aware of the underlying criteria.

MT 512: Programming Design

Page no: 41

4.3
SUB-PROGRAMS
In top down design, the problem is broken down into sub-problems. The main problem is
solved by the corresponding main program. Solutions to the sub-problems are provided
by subprograms, known as procedures, functions, or subroutine depending on the
programming language. A subprogram performs or executes the computer instructions
required to solve a given subproblem.
Main Problem

Subproblem
A

Subproblem
B

Main Program

Subproblem
C

Subprogram A

Subprogram B

SubProgram C

4.3.1 User defined Sub Programs and Functions


A Sub Program is a part of a program that performs one or more related tasks, has its own
name, is written as a separate part of the program, and is accessed via a call statement.
A Function returns a value to the program and shares many of the same characteristics as
a Sub Program (e.g., has its own name, is written as a separate part of the program).
Pros and Cons of Using Procedures
Disadvantage -- Procedure calls consume execution time and memory.
Advantage -- Procedures make the program easier to write, test, debug and
maintain.
Within a program we can normally identify sub-tasks that are performing a specific
function. Where program features clearly identify sub-tasks it is good practice to
implement each sub-task in its own, stand-alone, sub-program.
The advantages of a separate sub-program are considerable:

A stand-alone sub-program can be written and tested independently.


Once written, the sub-program can be called a number of times within a
program.
The sub-program is referred to by a meaningful name chosen by the
programmer, which helps greatly in understanding the code.
The sub-program can also be used in subsequent programs.

The ability to reuse a sub-program is obviously useful. We can include an existing


subprogram in another program whenever you need it.

MT 512: Programming Design

Page no: 42

4.3.2 Procedures and Functions


A function or procedure is a sub-program that exists to perform a specific, single task. It
has its own inputs and its own outputs (often called parameters), it can also define its own
variables. It may return the values to the referencing or invoking program or procedure A
function is a special sort of procedure that has a single output.
Procedures
A procedure has a header, followed by declarations of variables used within the
procedure known as local variables (identifiers) and finally statements that are to be
performed when the procedure is invoked.
The procedure header is the mechanism used to give a name to the procedure. The
procedure header also may contain the values that can be communicated between the
procedure and its invocation known as parameters.
The general structure for defining a procedure (in C++) is:
void Procedure_Name(parameter)
{
.
//List of Statements.
}
Example
void WelcomeNote ()
{
Cout<<Welcome to Programming Concepts;
}
Procedures in c++ start with the keyword void.
Functions
The general structure for defining a function (in C++) is:
Data_type Function_Name(parameter)
{
.
.
Return statement;
}
Example
float Cube (float x)
{
float product;
product = x*x*x;
return product;
}
The principle thing to note is that the function must have a result type which dictates
what type of value the function represents.

MT 512: Programming Design

Page no: 43

A function is a special sort of sub-program - it is used when a sub-program is needed


which takes a number of inputs and returns a single output value (as with cube above).
This is typical of many algebraic functions (sine, cosine, exp, log, cube) but is otherwise
fairly unusual since the sub-programs that we want to define quite often have either no
output at all (as with manythanks) or very many outputs - in these cases we use a
procedure.
Parameters
As weve seen, procedures and functions can take a list of quantities called parameters.
Initially you might like to regard the parameters as the inputs to the module (but this is
not always true, as we shall see). For example:
void sum_and_difference( float a, float b)
{
float total, difference;
total =a+b
difference =a-b
cout<<The sum is <<total;
cout<<The difference is <<difference;
}
Both total and difference are local variables and only exist within the procedure, as soon
as the procedure finishes they and their values disappear.
The following program is an example of the main program:
void main()
{
float val1, val2;
val1=2;
val2=4;
sum_and_difference(val1,val2);
cout<< val1;
}
The values of val1 and val2 are simply copied into the variables a and b of the procedure
sum_and_difference. At the end of the procedure the values are not copied back!!!! The
value of val1 that the final output statement displays is therefore 2 (not 0).
Sometimes however, we would like the values to be copied back at the end of the
procedure. This is particularly true if there is more than one output of the procedure, as in
the case of sum_and_difference. The sum and difference cannot both be passed back as
the return value of a function, since a function can return only a single value.
void sum_and_difference( float a, float b, float & s, float & d)
{
s =a+b;
d =a-b;
}

MT 512: Programming Design

Page no: 44

void main()
{
float val1, val2;
float total, difference;
val1=2;
val2=4;
sum_and_difference(val1,val, total, difference);
cout<<The sum is <<total;
cout<<The difference is <<difference;
}
The symbol & in the procedure parameter list instructs the computer to copy back any
changes to the values of a and b once the procedure has completed.
In summary, if you want to write a sub-program that has a number of inputs and a single
output, write a function. If you want many outputs from the sub-programs, use a number
of var parameters in a procedure
4.3.3 Built in functions
While most programming languages enable you to write your own functions (as above),
most also provide a library of common functions ready for you to use (e.g. sine, cosine).
Exercise
1. Devise the pseudcode for a program that will accept names and marks of each student in

the class of 100 students, and then calculate the average of all marks. The program
should make sure the entered marks entered are valid (in the range of 0 and 100). Use
the idea of modular programming.
2. Write pseudcode for a program that will read two matrices and then display their sum.
3. The scalar product (also called the inner product or the dot product) of the two
vectors (one-dimensional arrays) A and B with n elements is defined as
n

product = A.B = ai bi = a1b1 + a 2 b2 + ... + a n bn


i =1

Write a pseudocode program, which references a Function with three parameters, A,


B, N. The main program should input N and the two arrays A and B. The Function
subprogram should have a name called Product and it should compute the scalar
product according to the formula given

MT 512: Programming Design

Page no: 45

5. CODING THE PROGRAM


Coding the Program refers to the process of transferring a pseudocode program or
flowchart into a computer program using a programming language. The program
statements are written in such a way that they are in accordance with the language syntax.
There is a compulsory set of programming rules to foster the habit of following some
convention consistently. These conventions are designed to improve code readability; on
the premises that far more human time is spent reading code than writing it, that far more
human time is spent modifying existing code than writing entire programs from scratch,
that far more code is written by groups of people than by single individuals. In particular,
following these rules will make it easier for the grader to grade your work and the
instructors to assist you if you are having difficulty.
5.1 NAMES
Choose your names carefully. As part of program documentation, names must clearly
indicate both the kind of thing being named and its role in the program.
5.1.1

Variable names:

One has two choices, and you should choose one and follow it consistently. Variable
names only one word long can begin either with a lower case or an upper case and
thereafter are lower case including other acceptable characters.
Guidelines for choosing meaningful names:

In general, choose English words, which describe the thing being named.
Use simple names for variables used briefly and locally. For example, a loop
counter might be a single letter.
Otherwise, avoid using lots of one- and two- character names like x or b2.
Use common prefixes/suffixes to associate names of the same general type or
category.
Avoid deliberate misspellings and meaningless suffixes to create variables with
similar names, e.g. if the name index is used, do not define another variable with a
name like indx, ndex, or index2.
Avoid names that are similar to each other and thus possibly confusable.
Never use acronyms as abbreviations, instead, if your names are getting long you
may eliminate vowels (e.g., frstElmnt), or use an unambiguous prefix (e.g.,
firstElem), but NOT fe.

MT 512: Programming Design

Page no: 46

5.1.2

Indentation

Maintain consistent indentation throughout your code. Examples:


if (condition) then
statements
else
statements
end if ...
for (...)
statements
end for ...
Rightward Drift. As you get more and more deeply nested block of code, indentation
pushes you farther and farther to the right, until eventually you have hardly any room to
write a line of code. To avoid this, you can do two things:

Use a modest size indentation. Four spaces is probably optimal. If you anticipate
problems with rightward drift, you could even try two or three, although this is
not as easy to read.

5.1.3 Comments
Comments should help the reader of your code to understand it. Like any other form of
expression, it should not be flowery or repetitive. In particular observe the following
guidelines

All internal documentation must be written in English. Avoid comments that


simply rephrase your code in English, without summarizing it or adding any
information.

For each variable, give a one-line comment stating the use of the variable. These
may follow the variable declaration, as
in:
int i;
/* loop variable */
for (i = 0; i < sizeOfArray; 1)
someArray[i] = 0;
}

MT 512: Programming Design

Page no: 47

Or you may use a comment block to identify the use of several variables together. Before
each major section of the program, give the purpose of that section.
At the end of statement blocks unless the block is only a couple lines long, there should
be a comment indicating which block is being ended. See the examples above.
Comment Blocks like the one used above should have a running line of /s or asterisks
which clearly identifies the block as a comment, even if the beginning or end of the
comment is not visible on the page or screen.
5.1.4

Keep Line Lengths Under 80 characters

On many machines and in many software packages, this is a standard line length. It
makes it easier for others to read and/or print your programs.
5.1.5

Make judicious use of White Space

Sometimes the simple insertion of a blank line here and there to help group a few lines of
code which work together to achieve a sub-goal can make the program much easier to
read. But don't put in too much white space or the reader will not be able to see enough of
the code at a time.

MT 512: Programming Design

Page no: 48

6. PROGRAM

TESTING

What is Program Testing?


Program testing is a formal evaluation technique in which software requirements, design,
or code are examined in detail by a person or group other than the author to detect faults,
violations of development standards, and other problems.
Assuming your program has compiled successfully with no warning messages, what
comes next? The answer is testing, but this is not as simple as it seems. Any program
needs testing in order to show that it works in the desired fashion. Most programs need
some form of input, and most of these can accept a potentially infinite number of inputs.
It is a good guess that we cannot test our programs on all inputs, and in fact it can be
proved that no amount of testing can prove, in general, that a program works, i.e. that it
meets the requirements laid down in the specification, or problem description. We can,
however, prove that certain kinds of programs work correctly, but this is a hard job,
involving complex mathematics and special-purpose computer tools.
The rest of us need to test our programs by choosing appropriate inputs, observing the
behaviour of the program with these inputs, and comparing the outputs with the ones
expected by examining the description.
Program correctness
A program is correct, if it exactly meets its given specification.
Consequently, the correctness of a program is always expressed relative to its
specification. A major problem in determining the correctness of a program is the
difficulty of finding a complete and adequate specification, which is often described in
abstract mathematical or physical statements
The best software is that which has been tested by thousands of users under thousands of
different conditions over years. Then it is known as "stable". Yet, this does not mean, that
the software is now flawless, free of bugs. It generally means that there are plenty of bugs
in it, but the bugs are well identified and fairly well understood. There is simply no way
to assure that software is free of flaws. Though software is mathematical in nature, it
cannot be "proven" like a mathematical theorem; software is more like language, with
inherent ambiguities, with different definitions, different assumptions, and different
levels of meaning that can conflict.
Debugging

MT 512: Programming Design

Page no: 49

Debugging is the process of locating, analyzing, and correcting suspected


errors.
In computers, debugging is the process of locating and fixing or bypassing bug (errors)
in computer program code. To debug a program is to start with a problem, isolate the
source of the problem, and then fix it. A user of a program that does not know how to fix
the problem may learn enough about the problem to be able to avoid it until it is
permanently fixed. When someone says they've debugged a program or "worked the bugs
out" of a program, they imply that they fixed it so that the bugs no longer exist.
Debugging is a necessary process in almost any new software development process,
whether a commercial product or an enterprise or personal application program. For
complex products, debugging is done as the result of the unit test for the smallest unit of a
system, again at component test when parts are brought together, again at system test
when the product is used with other existing products, and again when users try the
product out in a real world situation.
Because most computer programs contain thousands of lines of code, almost any new
product is likely to contain a few bugs. Invariably, the bugs in the functions that get most
use are found and fixed first. An early version of a program that has lots of bugs is
referred to as "buggy."
Debugging tools help identify coding errors at various development stages. Some
programming language packages include a facility for checking the code for errors as it is
being written.
Strategies for Testing
The idea of testing a program is twofold: the first is to see whether the program works in
a manner that fits the problem description; the second is to break it, i.e. to find a set of
circumstances in which it fails. Only when we know how a program fails can we improve
it.
A testing strategy is necessary because without a clear goal, testing can be a very hit-ormiss affair. Many programmers take this approach by default, and tie it in specifically to
a debugging strategy, which actually is a different topic.
Black Box Testing
Black box testing refers to the development of test cases that are focused on what the
software is supposed to do. That is, we are checking to see if the functionality is correct,
without regard to how the software accomplishes a specified task. Black box testing is
called that because the tester cannot "see" inside the module or component being tested.

MT 512: Programming Design

Page no: 50

This is the type of tests that are performed from a user perspective when we are doing
supported by tools that execute the software for us.
White Box Testing
White box testing might be more appropriately named clear box testing. In this type of
test, the tester knows how the software module or component is implemented. In this
scenario, the tester is trying to ensure that the software does not fail. Automation of white
box testing is more difficult than black box testing. This type of test is usually done from
the developer perspective during unit testing where one of the test resources is the source
code. We need to know how the software has been written so that we can test its possible
failure points.
Software testing is becoming increasingly important. It is important to do it well,
especially when we are involved in component-based development where we don't know
exactly what other components our software may interact with. Adherance to the
development specification and a properly working interface are essential. Some
companies, like Microsoft, have a tester for every developer because the test process is so
important.
Typical Input
Most testing should be done using typical input values that the program design is
supposed to cater for. The problem description will often contain ranges or even absolute
values that the program should expect to handle. Of course, even these can be too many
or too complex for exhaustive testing, so the tester can choose appropriate values.
Some programs do not place restrictions on their input values, but even if they do not,
programs need to be tested on typical values. In some cases, these will be sets of typical
inputs, not just one. The problem with testing on a single value is that the program may
work perfectly on your chosen typical representative value, but fail on another because it
handles the typical value specially without your knowledge. Choosing more than one
typical value can minimize this problem. These typical inputs also become part of the test
suite.
Special Input
Often programs will fail when presented with data that is zero or absent, or too small. It
can also be that the data is too big, or too long. A good strategy in these cases is to
present the program with the simplest possible case (typically zero or absent data) and
then to present it with a complex case involving large values, long strings, or large
numbers of items. If the program passes these tests, it may still fail on typical input
data, and several tests should be run on data that represents the typical case.

MT 512: Programming Design

Page no: 51

It is useless to rely on one representative input, and even when several tests have
succeeded, suspicion is still appropriate, and more probing is often necessary before
feeling happy about the program. For instance a program that expects to read a name
might get an empty string; a program that expects a number of inputs of the same kind
may get none; a program that stores a maximum of 100 names might get exactly 100. A
list of values might be terminated by a special sentinel value, or perhaps a negative value
where the norm is positive. The program should be able to cater for these, without failing,
so they become part of the test suite
Invalid Input
Many inputs have range restrictions, so the extreme end of the range, and beyond, should
be tested. Names of one character; ages less than zero, or greater than 150; car speeds
over 500 m.p.h., and so on.
These ranges should be tested at their extremes, and beyond to be safe. Even more
common is the program that tests for valid input but does not test for invalid input. If a
number between 1 and 5 is supposed to be input, and the user puts in 6 (or 10000!) what
happens? If a response should be y or n, what happens with a z? Programs that
behave gracefully under this kind of fire are called robust. Programs that crash when
presented with invalid input are just useless!.
Having assembled the test suite (and this could be as small as a handful of values for
small programs) the program should be executed using the inputs and its behaviour
observed and recorded. This is rather like experimentation. If the program succeeds on all
inputs, i.e. its observed behaviour matches the expected behaviour, as extracted from the
specification, then you are done! Mostly, however, and especially for programs of any
size, disasters of various sorts will occur. How to fix these disasters is a job for
debugging. However, they would not have occurred if comprehensive testing had not
been carried out.

Program Verification
Verification means that the characteristics of modules or programs are thoroughly
checked according to their specifications. A program is defined to be correct, whenever it
complies fully to the specifications, which means that for all given inputs it reacts with
correct outputs. We distinguish partial and total correctness of a program, where the
former means that it terminates for a given input and delivers the correct results. A
program is totally correct, if it terminates and it is partially correct for all inputs.

MT 512: Programming Design

Page no: 52

Program Validation
In contrast to verification, the process of validation is applied to check, if the system or
one particular module corresponds to the given requirements with correct results
according. To achieve this, the program is either executed or simulated. Two basic
approaches can be distinguished: the validation of the complete system (according to the
user's requirements) and the validation of the functional requirements. Testing may also
be described as the iterative application of validation.
Problems of Testing
A principle problem of testing is that in the general case and for a program of arbitrary
size and complexity, it can always only demonstrate the existence of errors, but it can
never prove the absence of errors. Furthermore, exhaustive testing is usually impossible
due to the amount of possible inputs a program states in most software systems. Yet,
since every test suite feeds a program under consideration only with selected inputs out of
the often-enormous space of all possibilities, certain bugs in the code may never be
evidenced. This means, that the total elimination of bugs is an unrealistic goal.
Usually, programs are not correct at the first place. In contrast, it is even highly probable,
that any developed program contains some errors. The reason for this is partially the
complexity of the program development process itself, partially the difficulty to define
solutions and realization as software, but also the high precision that is required from
software engineering in general.
Another main problem of testing is, that it is surprisingly often not considered until the
code has been run the first time and is found not to work. Statistics show that many errors
have already been made before coding begins, and the later the errors are detected, the
higher are the associated costs to rework the system in order to function correctly. Boehm
states that the most. In addition, the testing phase is still a highly tedious task, that is
mostly carried out manually, which is therefore error-prone in itself. A related question is
the amount of required testing, which is more often defined by the amount of available
budget or the given schedule.
And finally, it is very difficult to determine the sufficient amount of testing. It is clear,
that exhaustive testing is impossible in both principle and testing. In principle, there are
two possibilities to decide about test completion: statistical, when error statistics attest a
sufficient degree of reliability, and systematic, which tries to determine methods for
identifying the functional properties and classes of possible errors in programs. A very
common approach is to fix every detected bug and perform testing until the project
management orders a product release. Bach tries to articulate and perhaps quantify the
amount of testing [Bach 98], that is sufficient for different projects depending on the
circumstances and may be useful for everyday projects as well as mission- or life-critical
projects.

MT 512: Programming Design

Page no: 53

7. PROGRAM DOCUMENTATION
Documentation, or the preparation of documents, that explains the program of the is an
essential but sometimes neglected part of the programming process. Because the
provision of the necessary documentation to support a program is not seen as a challenge
or intellectual exercise (and because it is almost invariably left until after the program has
been developed and is then seen as delaying the new program), it is seldom done or done
properly. It should be one of the fundamental principles of programmer management that
no program is allowed to be used without having been provided with sufficient
documentation.
Documentation should be an ongoing part of developing a program and should be
finalised, after the program has successfully tested and ready for implementation.
Documentation developed during the programming process should include a narrative
description of the program, program design documents, such as flowcharts or
pseudocode, program listings, and test results including input and output format. The
documentation of the program can be contained in documents referred as program
manuals. Comments in the program itself are also an important part of program
documentation.
Data entry and computer operations procedures should also be documented prior to
implementation. The programmer who developed a program may leave the company for
various reasons, and another programmer may be required to make a change to the
program. When new programmer would rely on the Documentation of the program in
order to make changes. Otherwise, the new program has to study and understand the
program before making any changes. This may take a long time to understand a program
written by another programmer.
This indicates that, Documentation is valuable because it helps the next programmer who
is later is asked to update the program. Program Documentation can substantially reduce
the amount of time the new programmer will have to spend learning about the program to
know how best to make a change.
Documentation of the program is also necessary for the users who will be using the
program. The user must understand, what input he is required to provide for the program,
the nature of the processing carried out by the program and the output, which he will
receive.
Documentation for Programmers
The documentation is required to enable the programmer to maintain a program over its
life span may be divided in Internal and External Documentation.

MT 512: Programming Design

Page no: 54

Internal Documentation
This covers the aspects of programs which are embodied in the syntax of the
programming language, which includes
Meaningful names used to describe data items and procedures
Comments relating to the function of the program as a whole and of the modules
comprising the program.
Clarity of the style and format: i.e indentation of related block of instructions,
blank lines separating modules.
Use of symbolic Names (Variable Names) instead of constants.
External Documentation
This category covers the supporting documentation, which should be maintained in a
manual or folder accompanying any program. It is essential that as changes are made to a
program, its external documentation is updated at the same time. Out-of-date
documentation can be misleading to a maintenance programmer and result in time
wastage. External documentation should include:

A current listing of the source program


Program specification that is, a document defining the purpose and mode of
operation of the program.
Structure diagram depicting the hierarchical organisation of the modules currently
comprising the program.
Specification of the data being processed , items in reports, external files
processed.
Where applicable, the format of screens used to interact with users

Documentation for users


A user is concerned more with how he interacts with the program and what the program
does for him than with the technicalities of how the program handles its tasks. Programs
to be used by user, should a program manual. The users manual should cover:

A detailed description of the function performed by the program.


The means by which the user supplies data to the program including the format of
entering data.
Description of the output from the program.
Etc.

MT 512: Programming Design

Page no: 55

PROGRAM MAINTENANCE
Program maintenance includes all the changes to a program once it is implemented and
processing real transactions. Sometimes, maintenance is required to correct errors that
were not found during the testing stage. Other times, maintenance is required to make
changes that are the result of users new information requirements.

MT 512: Programming Design

Page no: 56

6.

PROGRAM ERRORS

Definition and Classification of Errors


Diagnosing and troubleshooting a software failure is a difficult activity. It starts with the
problem, that most of the terms and notions in this area have a common sense appeal and
lack precision. Thus, it is important to try to exactly distinguish the following words:

Error
Failure
Fault
Bug
etc
We will provide corresponding definitions in the following paragraphs, which have been
derived from existing literature.
We will stick to the common usage of the term "error", which covers all different kinds of
errors, bugs, failures, or faults. This view is sufficiently accurate and precise for our
needs.
A very informal definition of the most basic term "error" corresponding to computer
science is as follows:
An error is defined as the computation (calculation and outputting) of one or more
incorrect results by a computer.
This definition of an error is the most commonly used, and the term "error" has also been
used in the definition for debugging. The noted lack of precision is established by two
issues: On the one hand, there needs to be a distinction between the observed erroneous
behavior and the original error itself. On the other hand, the term "results" identifies not
only the output of a program, but also incorrect states during execution.
These problems are discussed in more detail by focusing on the states of
application programs, which consist of simple and compounded instructions.
In terms of errors, two kinds can generally be distinguished: hardware errors and software
errors. The former result from erroneous functions of electronic elements, which have
been initiated e.g. by dust, heat, variations in electrical currents, and others, or have been
introduced through corrupted connections and cables or by other faulty components. The
appearance of hardware errors leads to interruptions of service, which often result in
complete breakdowns or system shutdowns.
In the scope of this work, we will not consider hardware errors, but instead concentrate
on the second kind of errors, that manifest themselves in software.
Software errors (often called logical errors) are based on an incorrect sequence of
statements, which can further be attributed to errors in the implementation or in the basic
MT 512: Programming Design

Page no: 56

algorithm. These kinds of errors are related to program behavior, that is, unexpected,
unintended, or otherwise wrong due to some incorrect activity of a human.
A fault is rarely the work of a single operation. More often than not is it a logical
sequence that runs to dozens of lines of code and crosses modules. In this context, we
distinguishes between the following kinds of errors:

Errors of origin
Subsequent errors

An error of origin is one that is observed at the program state where it occurs initially.
Therefore, such an error manifests the first occurrence of an incorrect operation. This is
also the place, where the correction should be applied. However, since errors are seldom
detected immediately, users are usually confronted with subsequent errors first. Such
subsequent errors exist always only as a consequence of an error of origin. They reveal an
incorrect program state, which results from both, their operation and incorrect input
variables. This relation between several states of a program is also expressed in the term
fault, which can be defined as follows:
Definition
A fault is a logical sequence of statements (or rather state changes) or an
accidental condition that produces a result other than that which the programmer
intended or causes a program to fail to perform its required function. Therefore,
a fault gives rise to errors and inversely, an error is the result of a fault during
the creation of the program.

Probably the most common faults are typos in the source code text that have not been
detected by the compiler, or some other incorrect statements which do not comply with
the intended semantics of a program.
The worst kind of fault is a failure, which can be defined as follows:
Definition
A failure is the inability of a system (or one of its components) to perform a
given function within given limits.
Additionally, a failure is often defined as a loss of some service to the user. Therefore, it
represents one special kind of manifestation of erroneous program behavior [Choi 91],
because a program fails to produce expected results and may even terminate abnormally.
The missing term in this context is "bug", which is often used as an equivalent
replacement for error. However, in practice most people identify some additional
characteristics for a bug as specified in the following definition:

MT 512: Programming Design

Page no: 57

Definition
A bug is the commonly used term for an error with originally unknown location
and reason. A bug can also be attributed to a poorly prepared and executed test,
as well as a bad program description that may lead users to mistake correct
behavior for bugs.
The notions and terms described above can also be described with a conceptual
overview. A special group is the false errors, which occur at state changes that are
incorrectly assumed to be wrong.
During debugging, we want to pinpoint the very origin of an error, i.e. the first
incorrect operation, which is often a difficult task. For that reason, we may identify
several more characteristics of bugs.

In principal, if the software's design is logically correct, it should be so into infinity.


Consequently, if a software error arises it may only originate from the following set of
possibilities:

Included in the original design or coding.


Introduced through program modification.
Introduced as a side effect of another bug fix.

Additionally, there are those errors related to failures of the hardware on which the
program is executed, and to the corruption of the media on which the program is stored.
Software components differ fundamentally from hardware components, because they
don't suffer from aging or transient failures. Instead, when software components fail, the
reasons are:
Inaccuracies of the problem specification, which results in programs that behave
differently than intended by the specifier.
Errors introduced during software development, which results in programs that
behave differently than intended by the programmer.
Errors introduced during compilation, which results in programs that behave
differently than intended by the compiler.
Some more characteristics to establish a classification of errors with the following
three classes:

Consistency: errors may occur either with consistency or with a frustrating


lack of consistency
Fuzzy cases: is the problem really a result of a errors?

These different characteristics are very useful during debugging. Only if users are aware
about all the different possibilities, they are able to react to incorrect program behavior
and perform corresponding error detection activities. To underline the importance of
these tasks, the following section describes actual cases of erroneous behavior observed
in computer systems.

MT 512: Programming Design

Page no: 58

Crash
A serious computer failure. A computer crash means that the computer itself stops
working or that a program aborts unexpectedly. A crash signifies either a hardware
malfunction or a very serious software bug.

If your computer crashes, it is not your fault. If the program is good and your hardware is
functioning properly, there is nothing you can do to make your system crash.
Hang
To crash in such a way that the computer does not respond to input from the keyboard or
mouse. If your computer is hung, you usually need to reboot it, although sometimes
hitting the correct sequence of control characters will free it up.
Computers systems may crash. Files may be accidentally deleted. Disks may
accidentally be reformatted. Computer viruses may corrupt files. Files may be
accidentally overwritten. Disgruntled employees may try to destroy your files. All of
these can lead to the loss of your critical data. You may think it's lost forever, but we
employ the latest tools and techniques to recover your data.

In many instances, the data cannot be found using the limited software tools available to
most users. The advanced tools that we utilize allow us to find your files and restore them
for your use. In those instances where the files have been irreparably damaged, our
computer forensics expertise allows us to recover even the smallest remaining fragments.
Overflow error
An error that occurs when the computer attempts to handle a number that is too large for
it. Every computer has a well-defined range of values that it can represent. If during
execution of a program it arrives at a number outside this range, it will experience an
overflow error. Overflow errors are sometimes referred to as overflow conditions.
Runtime
Occurring while a program is executing. For example, a runtime error is an error that
occurs during program execution and a runtime library is a library of routines that are
bound to the program during execution. In contrast, compile-time refers to events that
occur while a program is being compiled.
Bomb
To fail. The term bomb usually refers to a program hanging or ending prematurely. Note
that bombing is usually less serious than crashing, because bombing refers to a single
program, whereas crashing refers to the entire system. The two terms, however, are not
always used consistently.

MT 512: Programming Design

Page no: 59

The Apple Macintosh computer actually has a bomb message that sometimes appears
just before the system crashes.
Abort
To stop a program or function before it has finished naturally. The term abort refers to
both requested and unexpected terminations. For example, many applications let you
abort a search or a print job. On the other hand, programs can abort unexpectedly for any
of the following reasons:

bugs in the software


unexpected input that the program cannot handle
hardware malfunction

When a program aborts, you are usually returned to the operating system shell level.
Contrast abort with crash, which makes the entire system, including the operating system,
unusable.
Underflow
Refers to the condition that occurs when a computer attempts to represent a number that
is too small for it (that is, a number too close to zero). Programs respond to underflow
conditions in different ways. Some report an error, while others approximate as best they
can and continue processing. For example, if your computer support 8 decimal places of
precision and a calculation produces the number 0.000000005, an underflow condition
occurs.
Fatal error
An error that causes a program to abort. Sometimes a fatal error returns you to the
operating system. When a fatal error occurs, you may lose whatever data the program
was currently processing.

MT 512: Programming Design

Page no: 60

Вам также может понравиться