24
Programming for Programming for Beginners Beginners Martin Nelson Elizabeth FitzGerald Lecture 5: Software Design & Testing; Revision Session

Programming for Beginners Martin Nelson Elizabeth FitzGerald Lecture 5: Software Design & Testing; Revision Session

Embed Size (px)

Citation preview

Programming for Programming for BeginnersBeginners

Martin Nelson

Elizabeth FitzGerald

Lecture 5: Software Design & Testing; Revision Session

Revision of Sessions 1-4

So far, we’ve seen the basics of the Java language.

We’ve seen many common data types: int, char, String, boolean and others.

We can branch our code using if and switch statements.

We can repeat tasks many times using for loops, while loops and do-while loops.

Session 5 - aims & objectives

Later, we will go through an example which includes all the material covered so far.

Plenty of time to ask questions, or recap past material.

First, let’s think about how to assemble a complicated program. Software design Software testing

Software design

There is a difference between program design and coding

Effective programming requires both Program design is a formalised process

Describe the problem in logical steps Test the description Refine the description Test the refinements Code the program

Coding without design should always be avoided

Top-down design

Most widely favoured method of program development

The task is described as a problem

The problem is divided into sub-problems

Sub-problems are further divided, until the stages are easily represented by program code

Program description

State the problem in hand Make this clear and precise May need clarification from the 'client' This problem statement can be broken down into partly or

completely separate components

Functional specification Usually for large programming projects This must be a written document agreed by all parties

e.g. 'clients', 'programmers'

Algorithms

An algorithm is the solution for a problem

Algorithms must be: Finite:

there must be a measurable point at which the problem can be said to be solved

Ordered:the algorithm must consist of a series of steps

Unambiguous:each step must follow on from a previous step – if choices are made they must be based on conditions determined earlier in the sequence

Top Tip!!

When designing your algorithms...

START WITH A PEN AND PAPER!!

Until you can write the solution down clearly on paper, you’re not likely to be able to code it effectively.

Pseudocode

A detailed description of a program Half way between programming syntax and

human-readable English. Ignores specific programming syntax Provides enough detail so that each part of the

description can correlate to actual source code In object-oriented programming, try to design

pseudocode in an object-oriented manner (use external classes and methods)

Successive refinement

First – develop an initial solution Does not involve a lot of detail or program code Must describe the solution correctly

Secondly – refine this solution Each stage considered as a problem in its own right This solution must be described correctly

Continue until the problem is completely solved 'successive refinements'

Pseudocode

Example of program design – 1

Problem: write a program that prompts the user for 3 integers, and then writes out the total and the average numbers to the console

Example output:

Enter three integers: 5 32 17Total: 54Average: 18

Example of program design – 2

Successive refinement: Initial description

Prompt user for 3 integers Add the numbers together Work out the average Display the total and average to the console

Refinement of first action Refinement of second action Refinement of third action Refinement of fourth action

Example of program design – 3

Refinement of first action Display prompt asking user to input 3 integers Read in values for int1, int2 and int3

Refinement of second action Set up a variable to store the sum Sum = int1 + int2 + int3

Example of program design – 4

Refinement of third action Set up a variable to store the average Average = sum/3

Refinement of fourth action Display the total to the console Display the average to the console

Testing a program design

Desk tracing Data values are chosen Actions of program carried out by hand-tracing the

program steps using these values Can be done on paper (with or without a calculator)

Assertion testing Test the logic of the algorithm Describe the state of the program at any one point Consider what the effects are, of the next step being

applied Repeat for entire algorithm

Example - assertion testing

Assertion: when the 3 numbers are entered their values are stored in int1, int2 and int3

Assertion: sum is assigned the total of int1, int2 and int3

Assertion: average is assigned the value of sum divided by 3

Coding and testing

When the design is considered sound, the program is coded

Each line of pseudocode is replaced by real code

The code is compiled and syntax errors are fixed

The program is tested with lots of variations of data sets (including extreme ones)

State the problem

Is it feasible?

Plan and refine an action sequence

Does it solvethe problem?

Write and compilethe source code

Is it free of syntax errors?

Run the program

Are the resultscorrect?

Run the program

Does it do the job?Yes

No

No

Yes

No

Yes

No

Yes

No

Hooray!

Yes

PROGRAM DESIGNPROGRAM DESIGN

Coding hints

Start coding with a template that you know works properly

Make very small additions/changes and test the partly-finished code: Syntax errors – does it compile properly?

Functionality – does it run correctly?

Fix errors as they occur (or comment them out)

Don't write a complete program and expect it to work the first time – it probably won't!

Use a good coding style (neat indentations and comments)

Coding style

Write code that is easy to understand:

Identifiers should be meaningful e.g. hours rather than h

Presentation of code should reflect its structure Indent code blocks, have matching braces in the same

column

Actions in the code should be commented

Comments should add meaning, not repeat information already in the code e.g. int3=int1+int2 // add numbers

int3=int1+int2 // int3 is sum of int1 + int2

not very useful

this is more useful

Example of bad style

class abc{public static void main(String []args){int a=3,b=7,c; if (a>0) {c=a+b; else c=a} System.out.println(c);}}

Example of good style

/* Program to display the value of c tothe console */

class displayValue{

public static void main(String []args){ int a=3,b=7,c; //set values of integers a and b if (a>0) {

c=a+b } // if condition sets value of

'c' else { // dependent on value of 'a'

c=a }

System.out.println(c); //print value of 'c' to } //console

}

Revision task – Fizzbuzz!

Fizzbuzz is a counting game played in schools.

Going around the room, each person takes it in turns to count a number, but... If the number contains a 3 or is divisible by 3, they must say

“Fizz” instead of the number.

If the number contains a 7 or is divisible by 7, they must say “Buzz” instead of the number.

If both of the above are true, they must say “Fizzbuzz” instead of the number.

If you get it wrong, you’re out!

Task: Write a Fizzbuzz simulator which prints a table of numbers, replacing some numbers by “Fizz”, “Buzz” or “Fizzbuzz” appropriately.

Coming up in Session 6...

Object Oriented Programming!!