Software Development Techniques · Desk-Checking Topic 2 - 2.4 V1.0 © NCC Education Limited What...

© NCC Education Limited V1.0

Software Development

Techniques

Topic 2:

Desk-Checking

Desk-Checking Topic 2 - 2.2


Scope and Coverage

This topic will cover:

• A formal pseudo-code syntax – We don’t look at using programming languages in

this topic, so we need a formal syntax that we are

going to use for our pseudo-code.

• Desk-checking of algorithms – This is the working through, as a pen and paper

exercise, of pseudocode algorithms you or another

person have developed.



What Makes a Good Algorithm? - 1

A good algorithm has the following qualities:

• It is complete. – It contains the steps required to arrive at a desired

conclusion.

• It is robust. – It can deal with unlikely situations and incorrect

data.

• It is efficient. – It accomplishes its task in the minimum number of

steps.



What Makes a Good Algorithm? - 2

• It is readable. – When people look at the algorithm they can

understand what it is doing.

• It is maintainable. – If changes need to be made in the future, the

algorithm can be changed easily.

• It is documented. – There are instructions for people who wish to make

use of the algorithm.



Topic Pseudocode • There is no ‘correct’ form of pseudocode.

– There are many different styles, and none are the

‘right’ way to do it.

• In this module, we’re going to make use of a

specific form of pseudocode. – This makes sure everyone is writing the same kinds

of things in the same level of detail.

• As we go through the next few lectures, we’ll

encounter more ways to express things in

pseudocode.



Syntax

• The words and symbols that make up a

programming language are known as its syntax.

• Java, C, Visual Basic and so on all have their own

particular syntax.

• In exactly the same way, the pseudocode we

develop during this module will have its own

syntax. – It’s just that we won’t be able to compile it into real

computer code.



Why Pseudocode? • There are several reasons why we use

pseudocode in programming. – It means we are not tied to a specific programming

language.

– It means we can focus on the logic of an algorithm

rather than the language specific features.

– It means we can formally check the correctness on

paper.

• Later on in this topic, we’ll discuss turning

pseudocode into real code.



Pseudocode Syntax - 1 In this module, we will use the following syntax:

• When we need to hold some data, we use the word

data to set up a container for it: – Data <name> as <type>

• Data myAge as whole number

– Acceptable types for now are ‘whole number’, ‘real

number’, and ‘string’

• When we need to get information from the user, we

use the word input and say where it is going: – Input into myAge



Pseudocode Syntax - 2

• When we need to display anything to the user, we

use output. Enclose what’s seen by the user in

quotation marks.

– Output “Hello there!”

• If we need to output the contents of some data, we

also use output but omit the quotation marks:

– Output myAge



Pseudocode Syntax - 3

• We can put information in a data container like so:

– myAge = 20

• When we wish to perform arithmetic on numerical

data, we need a container for the answer and then

we use the arithmetic symbols:

– data doubleAge as whole number

– doubleAge = myAge * 2



Pseudocode Syntax - 4 Symbol Meaning

+ Addition

- Subtraction

* Multiplication

/ Division

% Modulus division

• In technical terms, these are known as arithmetic

operators. We’ll talk more about this in the coming

weeks.



Pseudocode Example - 1

data myAge as whole number

data myNewAge as whole number

output "Please enter your age"

input myAge

myNewAge = myAge + 1

output "In a year you will be"

output myNewAge



Pseudocode Example - 2 data firstNumber as whole number

data secondNumber as whole number

data answer as whole number

output "Please enter a number"

input firstNumber

output "Please enter a second number"

input secondNumber

answer = firstNumber * secondNumber;

Output "The answer is "

output answer



Pseudocode Checking

• An important aspect of having pseudocode is that it

is correct. – It does what we expect it to do, and it does it correctly.

• In later lectures, we will talk about ways in which

you can test your algorithms properly. – So you are reasonably sure they work for all sets of

data.

• For now, we are going to introduce an informal

mechanism for working through an algorithm. – It is called a desk-check.



Desk-Check

• Because pseudocode is not a real programming

language, it means we can run it by hand.

– We can’t do that as easily with real programming

code because much of what a language does is

hidden from us.

• A desk-check is a formal way of stepping through

every line in a pseudocode representation of an

algorithm, highlighting what happens at each line.



What is in a Desk-Check?

• For a desk-check, you must define:

– Any starting values.

– What input is provided by a user

– The contents of every data container you created

– The line of code you are currently checking

• It is best to do this in a table form.



Desk-Checking Pseudocode

Code myAge myNewAge Notes

Data myAge as

whole number

0 0

Data myNewAge as

whole number

0 0

Output “please

enter your age”

0 0 User output

Input myAge 21 0 User enters 21

myNewAge =

myAge+1

21 22

Output “In a

year you will

be”

21 22 User output

Output myNewAge 21 22 User Output



Desk-Checking - 1

• The code (or pseudocode) that we write defines the

flow of execution through a program. – This is the order in which code statements are

executed when the program is running.

• So far, we have looked only at sequential flow of

execution. – Each line of code is executed after the last.

• In later weeks, we will look at ways of representing

loops and choices. – These make desk-checking more challenging.



Desk-Checking - 2

• The full line of code is shown on the desk-check for

easy reference.

– An alternate, and easier, system is to provide line

numbers.

• For this, you will need to ensure that your pseudo-

code programs contain line numbers.

– Number only lines that contain pseudocode

statements.

• Do not number blank lines



Pseudocode Example - 3 1 data income as whole number

2 data taxRate as real number

3 data myTax as real number

4 data myNetPay as real number

5 output "What is your annual salary?"

6 input income

7 taxRate = 10.00

8 myTax = income * taxRate

9 myNetPay = income - taxRate

10 output "You pay the following tax:"

11 output myTax

12 output "You have the following net annual pay:"

13 output myNetPay



Desk-Check - 1 Code Line Income taxRate myNetPay myTax Notes

1 0

2 0 0

3 0 0 0

4 0 0 0 0

5 0 0 0 0 Output

6 20000 0 0 0 User inputs

20000

7 20000 10.00 0 0

8 20000 10.00 0 200000

9 20000 10.00 -180000 200000

10-13 20000 10.00 -180000 200000 Output



Desk-Checking - 1 • Desk-checks are there to uncover errors in your

logic.

– Pseudocode by itself does not always show that.

• When you have made an error, you can go back to

the pseudocode and correct it.

• By desk-checking complex algorithms, we can be

sure the problem is in our logic.

– Not in the computer code that we write.

• In this case, our tax calculation is incorrect.



Desk-Checking - 2

7 taxRate = 10.00

8 myTax = income * taxRate


7 taxRate = 10.00

8 myTax = (income / 100) * taxRate


Before After

• Mistakes are going to happen – that’s inevitable.

• Pseudocode lets us ensure that we fix it at the

earliest and easiest point - before we have written a

single line of code.



Desk-Check - 3 Code Line Income taxRate myNetPay myTax Notes

1 0

2 0 0

3 0 0 0

4 0 0 0 0

5 0 0 0 0 Output

6 20000 0 0 0 User inputs

20000

7 20000 10.00 0 0

8 20000 10.00 0 2000

9 20000 10.00 18000 2000

10-13 20000 10.00 18000 2000 Output



Desk-Checking - 4

• Fixing errors once they have been encountered

can be tricky. – Luckily, with a desk-check we can see where data

starts going wrong.

• Sometimes, errors won’t be uncovered in a single

desk-check. – You should do several on any pseudo-code you write.

• When picking user input, be awkward. – What happens if you enter a negative number in our

previous examples?



Desk-Checking - 5

• Desk checking is not about proving your pseudo-

code is correct. – It’s about proving that, for certain kinds of user

input, it’s not incorrect.

• A good desk-check is one that uncovers an error in

your pseudo-code. – The industry average is that for every 1000 lines of

code, there are between ten and twenty defects.

– The earlier you find these defects, the easier they

are to fix.



Commenting - 1

• The final thing to talk about in this topic is

commenting.

• All programs should contain comments. These are

human readable notes in the program that are

ignored when it is compiled.

• They make programs much more readable, and

you should get into the habit of doing it sooner

rather than later.



Commenting - 2

• The two main commenting styles in most

languages are line-by-line or block comments. You

can use either of these for your pseudocode.

// This is a comment /*

And so is this!

*/

Line Block



Commenting - 3

• Add comments when: – You are doing something unusual

• This ensures that people who read your code know

what it is you’re trying to do.

– You are doing something that requires some

assumptions.

• This ensures that people who read your code know

what assumptions you’ve made in writing it.

• Comments should detail your intention, not simply

describe what the code does.



Commenting - 4 /*

The following algorithm calculates

the

length of the hypotenuse of a right

angled triangle.

*/

/*

The following algorithm takes one

value

and squares it and then takes another

value and squares it. It then gives

the square root of the sum of those

squares.

*/

Good Comment Bad Comment

• A comment should explain to people what you were doing,

not how you were doing it. The code itself will do the latter

if it’s well written (more on that later).



Conclusion

• We are using a fixed pseudocode standard in this

module. – The special words we use are its syntax.

• Pseudo-code programs should have their lines

numbered.

• This makes it easier to do the desk-checking.

• Desk-checking is a process by which we can

uncover defects in our algorithms.

• It’s also the only way to ‘execute’ pseudocode.



Terminology • The following new pieces of terminology were

introduced in this lecture: – Syntax

• the special words used in a programming language

• In this case, it refers to the specific pseudocode we

will use in the topic.

– Desk-check

• the process of working through each line of code in an

algorithm

– Flow of execution

• the order in which programming statements are

executed by the system



Topic 2 – Desk-Checking

Any Questions?

Software Development Techniques · Desk-Checking Topic 2 - 2.4 V1.0 © NCC Education Limited What...

Documents

Transcript of Software Development Techniques · Desk-Checking Topic 2 - 2.4 V1.0 © NCC Education Limited What...