Introduction to C Programming

CE00312-1

Lecture 5

Program Design in C

Design theory

Difference between functional and object-oriented programming paradigm and design of resulting code.

Top-down design

Stepwise refinement

Functional decomposition

Design of Processes

functional analysis used to design resulting code

Break down design into logical blocks        Stepwise refinement        Functional decomposition

Functional Analysis

Get upGo to UniversityFor as long as there is a lecture to attend

Go to lectureTake notes attentively and enthusiastically!

Eat teaGo to townFor as long as you have money and are thirsty

Buy a drinkGo home

If you have spare money go by taxi

Else walk

Go Function

College Function

Food Function

Go out Function

Go home Function

Design Notation

Top Down design Problem decomposition expressed as combinations of

sequence, selection, iteration both Inter-function and intra-function

Level of abstraction or degree of modularity determined by complexity of problem and design notation used

Object Design Uses object modeling to determine level of abstraction Problem decomposition determined by object definition Processes expressed as behaviour of objects

Top-Down design

Take main functions Systematically break into smaller chunks Use a method to ‘represent’ solution Stop when resulting modules are small

enough to be easily implemented (but not too cumbersome)

‘Clever’ chunking results in reusable modules

Top Down design notation

Representative of problem Diagrammatic notation;

sequence, selection, iteration JSP Nassi-Scneidermann

Pseudo Code/ Structured English Embeds descriptive language into basic construct

syntax

Pseudocode/Structured English

While valid input If mark entry enter name enter mark Case {mark 0 - 39 “refer”

mark 40 – 59 “pass”mark 60 – 79 “merit”mark 80 – 100 “Distinction”}

else “Error”

output name and grade Else Clear

0 < O R > 100 < 40 < 60 < 80 else

In p u tN am e & E xam

oE rro r

oR e fe rra l

oP ass

oM erit

oD is tin c tion

C h eckE xam

O u tp u tN am e & G rad e

oG rad e

oC lear

C h eck E ven t *

E xam G rad e

Jackson Structured Design

Inputs

Output

Nassi-Schneidermann

Enter details

While user input

If Not Clear

Clear

RP M D E

Output mark & name

Testing

Purpose of testing Designing test cases and test case data

with corresponding input and expected output

Black and White box testing Difference between these two categories

of test; when test data can be designed and purpose.

Black Box testing

Black Box testing consists of Categories Functional Tests Invalid Tests Boundary Tests Special Tests

White Box testing

Categories Path Analysis Complex Conditions

Testing Example

Consider the example used as one of the week 2 practical exercises;

reading in percentage scores greater than 0 and printing out the corresponding letter grade. This is repeated until a negative value is read in. At this stage, the total number of values in each grade range is printed. An error message is printed for any input value greater than 100.

Black Box Tests1. Functional Tests

F1: Read in a percentage score and print the corresponding letter grade

F2: Produce an error message if a positive number greater than 100 is input

F3: Print out the number of input values in each of the letter grade ranges

F4: Terminate input when a negative value is read in.

2. Invalid Tests

I1: A positive number greater than 100 should produce an error message

3. Boundary Tests

B1: Input largest valid value B2: Input smallest invalid positive value B3: Input lowest valid positive value B4: Input largest invalid negative value B5: Input lowest value in ‘A’ range B6: Input highest value in ‘B’ range B7: Input lowest value in ‘B’ range B8: Input highest value in ‘C’ range B9: Input lowest value in ‘C’ range B10: Input highest value in ‘D’ range B11: Input lowest value in ‘D’ range B12: Input highest value in ‘F’ range

4. Special Test Cases

S1: First input value is negative S2: No values are input in a particular letter

grade range

White Box Tests

Can only be designed after the code has been written.

Complex Conditions None in this example

Path Analysis

P7P1

Not P2

P5

P3Not P3

P4 Not P4

Not P6

Not P5P6

P2

Path Analysis

Path Analysis P1: Initial sequence P2: Value greater than 100 Not P2: Positive value less than or equal to 100 P3: A’ grade Not P3: value below an ‘A’ grade P4: ‘B’ grade Not P4: value below a ‘B’ grade P5: ‘C’ grade Not P5: value below a ‘C’ grade P6: ‘D’ grade Not P6: ‘F’ grade P7: Print out total number of values in each grade range

Test Data F1: 90 -2 F2: 110 –2 F3: 67 78 89 90 93 53 54 65 72

73 -3 F4: As for F1 I1: As for F2 B1: 100 -1 B2: 101 -1 B3: 0 -1 B4: -1 B5: As for F1 B6: 89 -1 B7: 80 -1 B8: 79 -1 B9: 70 -2 B10: 69 -1 B11: 60 -1 B12: 59 –1 S1: As for B4 S2: 90 89 78 -1

P1: As for F1 P2: As for F2 P3: As for F1 Not P3: As for B12 P4: As for B7 Not P4: As for B12 P5: As for B9 Not P5: As for B12 P6: As for B12 Not P6: As for F3 P7: As for F1

Complex ConditionsConsider the following if condition 

if (age<18 || age >=65) Resulting complex conditions:  age<18 age>=65C1: True TrueC2: True FalseC3: False TrueC4: False False C1: impossibleC2: age = 16C3: age = 70C4: age = 21

The number of complex conditions is equal to 2N, where N is the number of parts to the condition.

 e.g.

 if ( age <18 || age >=65) && (gender==’m’ || gender==’f’)

              24 = 16 conditions

Truth Table

age<18 age>=65 gender==’m’ gender==’f’ False False False FalseFalse False False TrueFalse False True FalseFalse False True TrueFalse True False FalseFalse True False TrueFalse True True FalseFalse True True True

Repeated with column 1 containing True and columns 2, 3 and 4 unchanged.

e.g.   C3: age=21, gender=’m’ C4: impossible (gender can’t be both ‘f’ and ‘m’) C6: age = 70, gender=’f’ C9: age = 16 gender =’z’