Basic Computer Science and

Programming
CS 102

Asst. Prof. Dr. Mehmet smet Can Dede

Program Planning and Design

Algorithms

The goal of the problem-solving as explained before is to

develop an algorithm, or set of steps to solve the problem.
We use algorithms every day. Whenever we are doing a
task, such as assembling a bookcase, the algorithm tells us
each step in the proper order.
Write an algorithm to make butter-cheese sandwich.

Program Planning and Design

Algorithms

In the previous algorithm, step 1 is the input, steps 2

through 6 explain the process, and step 7 is the output.
It is clear from the algorithm that we should not do step 5
before step 3, or the sandwich would not be interesting.
Step 4 lets us make a choice whether to include cheese
slices in the sandwich.
Clearly, a number of other if statements could be included
for choosing lettuce, tomatoes, or any other ingredients.
Also, step 6 allows us the flexibility to repeat the same
process exactly several times.

1- Put the sliced bread, butter, sliced cheese, knife and plate onto the
workspace.
2- Place two slices of bread on the plate.
3- Using the knife, spread butter on one slice of bread.
4- If you want cheese, place the cheese slices on the buttered slice of bread.
5- Slap two slices of bread together.
6- Repeat steps 2 through 5 for each sandwich needed.
7- Eat sandwiches.

Program Planning and Design

Algorithms

To be correct, an algorithm has some specific

characteristics.

Has input, performs a process, and gives output.

Must be clear and unambiguous.
Must correctly solve the problem.
Can be followed with paper and pencil.
Must execute in a finite number of steps.

When writing algorithms for more complex numeric

problems, usually all the input is obtained in the first few
steps and the output is given in the last few steps.
Many steps can be subdivided.
Write the algorithm for a simple ATM machine.

Program Planning and Design

Algorithms

1. Get the password from the user.

2. If the password is not valid, construct an error message and skip to
step 6.
3. Get inputs.

4. If the transaction type is deposit, add the amount to the current

balance.
5. If the transaction type is withdrawal, check the current balance.

3.1. Get the transaction type (deposit-withdrawal) and amount from the user.
3.2. Get the current balance from the bank.

5.1. If amount is greater than the current balance, construct an error message
and skip to step 6.
5.2. If amount is equal to or less than then current balance, subtarct the amount
from the current balance.

6. Output the error message or the cash, and the current balance.
7. Ask the user whether to repeat steps 3 through 6 for another
transaction.

Program Planning and Design

Pseudocode and Flowcharting

Program Planning and Design

Pseudocode and Flowcharting

The algorithms in the previous section have been written in

a structured English method called pseudocode.
Notice that all the lines of the pseudocode contain a specific
verb.
In pseudocode, the steps of the algorithm are numbered in
such a way that one action is executed per line.
If a line requires two steps, it is subdivided in outline form
to the next level.
Pseudocode is usually a good way to begin to design a
solution to the problem, it lists the steps of the algorithm.
However, it is not always easy to begin coding the program
from pseudocode, because the program flow is not clear.

Program Planning and Design

Pseudocode and Flowcharting

The conditional statements and the statements to skip to

another step do not provide enough of a picture of what
should happen when.
In order to express the flow of processing in a much more
lucid fashion, many programmers use a flowchart, which is
a structured picture map showing the steps of the
algorithm.
The shapes usually used for each part of the flowchart are
described in the following slide.
The most frequently used ones are the rectangle,
parallelogram, diamond, circle and arrow shapes.

Program Planning and Design

Pseudocode and Flowcharting
Get bread, butter, cheese
slices, knife and plate

Program Planning and Design

Pseudocode and Flowcharting

In the flowchart, it is easy to identify the input and the

output actions because of the shapes used.

Put 2 slices of bread on the plate

Spread butter on one slice

Do you
want
cheese?

yes
Put cheese on the bread

no
Slap two slices together
yes

The results of the decision on whether to use cheese or not

is clear, either cheese is added or it is not.
Also, the arrow shows the flow of control back up to the top
to repeat the sandwich-making process.

Do you
want
another?
no
Eat the sandwich(es)

Program Planning and Design

Basic Control Structures

Program Planning and Design

Pseudocode and Flowcharting

Computer programs only do what the programmer has told

them to do, and in that specific order.
The basic control structures that are used are sequence,
selection, and repetition.
In the previous flowchart, most steps are executed in
sequence.
Step 4 allows a selection and step 6 provides for repetition.
A simple flowchart for 2 ATM machines could be constructed
with each step, input, process and output is done in order,
with no decisions or repetitions.

Get password

Get deposit amount

Add amount to current balance

Print the receipt

Get password

Get cash amount

Subtract amount from current balance

Dispense the cash

It is clear from flowcharts that some decisions are necessary.

Usually we want one machine to handle both withdrawal and deposit
actions.
Also, what if the password is not good? What if these is not enough
money in the account for withdrawal?
The flowchart needs to be constructed carefully one section at a time.

Program Planning and Design

Pseudocode and Flowcharting
Get password

Is the
password
good?

yes
Get type and amount

no

deposit

Deposit or
withdrawal?

Add amount to
current balance

no

withdrawal

yes

Is amount
< balance?

Subtract from
current balance

Give response or error message

Program Planning and Design

Top-down Design and Data Abstraction

Instead of indicating the flow of data, they illustrate the
tasks, or modules, for each part of the solution.
The only flow of data important is what should go into and
come out of each module.
Look back at the ATM program example, the overall task, or
the module at the highest level, is to simulate an ATM
machine.
The main subtasks would be to get the inputs, to perform
the calculations and to give the outputs.
Simulate an ATM machine

Get inputs

Perform all
calculations

Give outputs

Program Planning and Design

Top-down Design and Data Abstraction

The algorithms developed in the previous slides are fairly
simple.
Most often problems cannot be solved in such a simple way.
To attack complex problems, top-down design is used.
In top-down design, the overall problem is broken into the
main tasks (usually input, process, output), and then each
of these tasks is broken down into the subtasks until a
simple solution can be seen for each subtask.
Usually hierarchy charts are used as a help in top-down
design.
Hierarchy charts differ from flowcharts in that they indicate
what should be done, not how the job will be accomplished.

Program Planning and Design

Top-down Design and Data Abstraction

Each box represents a module of solution.
Notice, like pseudocode and flowcharts, each task begins
with a verb to show the action that must be performed by
that module.
Arrows coming from a box indicate data coming out from
that module, and arrows going into the box denote data
needed by that module.
Now that the overall task and the main subtasks are
identified, each module can be subdivided even further into
all the tasks that must be performed in that section.
The next level for the inputs and outputs is fairly
straightforward.

First level ATM hierarchy chart

Program Planning and Design

Top-down Design and Data Abstraction

Get transaction
type

Top-down Design and Data Abstraction

The calculation module is a little more complex; there are
two main subtasks, one to handle deposits and one to
handle withdrawals.
Each of these subtasks can be further broken down into
other simpler tasks.

Get inputs

Get password

Program Planning and Design

Get transaction
amount

Second-level ATM hierarchy chart for ATM input

Perform calculations

Give outputs

Handle
withdrawals

Handle deposits
Print error
message

Print balance

Dispense
charge

Add amount to
balance

Second-level ATM hierarchy chart for ATM output

Subtract amount
from balance

Check balance

Give error
message

Second- and third-level ATM hierarchy chart for ATM calculations

Program Planning and Design

Top-down Design and Data Abstraction

The Handle withdrawals module must check the balance to
see if there is enough money in the account before adjusting
the balance.
If there is not enough money, an error message is generated.
An error message is needed in the module that gets password.

Program Planning and Design

Top-down Design and Data Abstraction

Simulate an ATM machine

Get inputs

Get password

Get transaction
type

Give outputs

Perform calculations

Get transaction
amount

Print error
message

Dispense
charge

Print balance

Perform calculations

Handle
withdrawals

Handle deposits

Add amount to
balance

Check balance

Subtract amount
from balance

Handle
withdrawals

Handle deposits

Give error
message

Second- and third-level ATM hierarchy chart for ATM calculations

Add amount to
balance

Check balance

Subtract amount
from balance

Give error
message

Complete hierarchy chart for ATM machine