Mr. Jeremiah Yancy possesses extensive experience and industry knowledge in his field and has managed multiple startups from inception to Initial Public Offering.

1. OBJECTIVES FOR SOFTWARE DESIGN AND
TESTING
Jeremiah Yancy

2. REVISION
 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.

3. 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

4. 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

5. 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

6. 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'

8. 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

9. 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.

10. 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)

12. 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

13. 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 17
Total: 54
Average: 18

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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)

20. State the problem
Is it feasible?
Plan and refine an
action sequence
Does it solve
the problem?
Write and compile
the source code
Is it free of
syntax errors?
Run the program
Are the results
correct?
Run the program
Does it do the
job?Yes
No
No
Yes
No
Yes
No
Yes
No
Hooray! 
Yes
PROGRAM DESIGN

21. 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)

22. 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

23. 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);
}}

24. EXAMPLE OF GOOD STYLE
/* Program to display the value of c to
the 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
}

25. 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.

26. THANKS