Writing the

Programs

Shari L. Pfleeger
Joann M. Atlee

4th Edition
Contents

7.1 Programming Standards and Procedures

7.2 Programming Guidelines
7.3 Documentation
7.4 The Programming Process
7.5 Information System Example
7.6 Real Time Example
7.7 What this Chapter Means for You

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.2

Practice
Chapter 7 Objectives

• Standards for programming

• Guidelines for reuse
• Using design to frame the code
• Internal and external documentation

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.3

Practice
Programming as a Challenging Task

• All detailed issues have not been addressed

• Structures and Relationships that are easy to
draw may not be straightforward to program
• Code understandable for others
• Benefit from characteristics of design as well
as keeping the code reusable

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.4

Practice
7.1 Programming Standards and Procedures

• Standards for you

– methods of code documentation
• Standards for others
– Integrators, maintainers, testers
– Prologue documentation
– Automated tools to identify dependencies
• Matching design with implementation
– Changes in design can be easily implemented in
code
• Carry forward the design’s modularity

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.5

Practice
7.1 Programming Standards and Procedures
Prologue Documentation

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.6

Practice
7.2 Programming Guidelines
Control Structures

• Make the code easy to read

– Reader should not worry about understanding the
control flow
– Reflect the design’s control structure

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.7

Practice
7.2 Programming Guidelines
Example of Control Structures
• Control skips around among the program’s
statements
benefit = minimum;
if (age < 75) goto A;//may be a function call
benefit = maximum;
goto C;
if (AGE < 65) goto B;
n g
i
if (AGE < 55) goto C;
A: if (AGE < 65) goto B;
u r
benefit = benefit * 1.5 + bonus;
goto C;
c t
B: if (age < 55) goto C;
tr u
benefit = benefit * 1.5;
C: next statement
e s
• Rearrange the code R
if (age < 55) benefit = minimum;
elseif (AGE < 65) benefit = minimum + bonus;
elseif (AGE < 75) benefit = minimum * 1.5 + bonus;
else benefit = maximum;

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.8

Practice
7.2 Programming Guidelines
Control Structures

• Make the code not too specific, and not too

general
– Specific enough to be understood, generic enough
to be re-used
• Use parameter names and comments to exhibit
coupling among components

• Make the dependency among components

visible
Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.9
Practice
7.2 Programming Guidelines
Algorithms
rn ’
e a er
• Common objective and concern: performance
L il
(speed)/execution time p o
m
• Efficiency may have hidden costs co way
– cost to write the faster code iz
– cost to test the code tim
– cost to understand the code op
– cost to modify the code

Do not sacrifice clarity and correctness for

speed
Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.10
Practice
7.2 Programming Guidelines
Data Structures

• Several techniques that used the structure of

data to organize the program
– keeping the program simple
– using a data structure to determine a program
structure

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.11

Practice
7.2 Programming Guidelines
Keep the Program Simple
Example: Determining Federal Income Tax
1.For the first $10,000 of income, the tax is 10%
2.For the next $10,000 of income above $10,000, the tax is 12 percent
3.For the next $10,000 of income above $20,000, the tax is 15 percent
4.For the next $10,000 of income above $30,000, the tax is 18 percent
5.For any income above $40,000, the tax is 20 percent
tax = 0.
if (taxable_income == 0) goto EXIT;
if (taxable_income > 10000) tax = tax + 1000;
else{
tax = tax + .10*taxable_income;
goto EXIT;
}
if (taxable_income > 20000) tax = tax + 1200;
else{
tax = tax + .12*(taxable_income-10000):
goto EXIT;
}
if (taxable_income > 30000) tax = tax + 1500;
else{
tax = tax + .15*(taxable_income-20000);
goto EXIT;
}
if (taxable_income < 40000){
tax = tax + .18*(taxable_income-30000);
goto EXIT;
}
else
tax = tax + 1800. + .20*(taxable_income-40000);
EXIT;

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.12

Practice
7.2 Programming Guidelines
Keep the Program Simple Example (continued)

• Define a tax table for each “bracket” of tax

liability
Bracket Base Percent
0 0 10
10,000 1000 12
20,000 2200 15
30,000 3700 18
40,000 5500 20

• Simplified algorithm
for (int i=2, level=1; i <= 5; i++)
if (taxable_icome > bracket[i])
level = level + 1;
tax= base[level]+percent[level] * (taxable_income - bracket[level]);
Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.13
Practice
7.2 Programming Guidelines
General Guidelines to Preserve Quality

• Employ pseudocode a
e f
• Revise and rewrite, rather than patch R
– Convoluted control flow

Re
– Decision process hard to understand
– Unconditional branches difficult to eliminate
• Reuse
– Producer reuse: create components designed to
be reused in future applications
– Consumer reuse: reuse components initially
developed for other projects

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.14

Practice
7.2 Programming Guidelines
Consumer Reuse

• Four key characteristics to check about

components to reuse
– does the component perform the function or
provide the data needed?
– is it less modification than building the
component from scratch?
– is the component well-documented?
– is there a complete record of the component’s
test and revision history?

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.15

Practice
7.2 Programming Guidelines
Producer Reuse

• Several issues to keep in mind

– make the components general
– separate dependencies (to isolate sections likely
to change)
– keep the component interface general and well-
defined
– include information about any faults found and
fixed
– use clear naming conventions
– document data structures and algorithms
– keep the communication and error-handling
sections separate and easy to modify

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.16

Practice
7.3 Documentation

• Internal documentation
– header comment block
– meaningful variable names and statement labels
– other program comments
– format to enhance understanding
– document data (data dictionary)

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.17

Practice
7.3 Documentation
Information Included in Header Comment Block

• What is the component called

• Who wrote the component
• Where the component fits in the general
system design
• When the component was written and revised
• Why the component exists
• How the component uses its data structures,
algorithms, and control

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.18

Practice
7.3 Documentation

• External documentation
– describe the problem
– describe the algorithm
– describe the data

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.19

Practice
7.4 The Programming Process

• Documentation is still essential in agile-

methods
– Assists the developers in planning, as a roadmap
– Helps describe key abstractions and defines
system boundaries
– Assists in communicating among team members

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.20

Practice
7.5 Information System Example
Piccadilly System

• Design Description
Input: Opposition schedule
For each Television company name, create Opposition company.
For each Opposition schedule,
Locate the Episode where Episode schedule date =
Opposition transmission date AND
Episode start time = Opposition transmission time
Create instance of Opposition program
Create the relationships Planning and Competing
Output: List of Opposition programs
• Data dictionary description
Opposition schedule = * Data flow *
Television company name
+ {Opposition transmission date
+ Opposition transmission time +
Opposition program name
+ (Opposition predicted rating)}

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.21

Practice
7.5 Information System Example
Piccadilly System’s Implementation
• Passing by value
void Match:: calv(Episode episode_start_time)
{
first_advert = episode_start_time + increment;
// The system makes a copy of Episode
// and your program can use the values directly.
}
• Passing by pointer
void Match:: calp(Episode* episode)
{
episode->setStart (episode->getStart());
// This example passes a pointer to an instance of Episode.
// Then the routine can invoke the services (such as setStart
// and getStart) of Episode using the -> operator.
}
• Passing by reference
void Match:: calr(Episode& episode)
{
episode.setStart (episode.getStart());
// This example passes the address of Episode.
// Then the routine can invoke the services (such as setStart
// and getStart) of Episode using the . operator.
}

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.22

Practice
7.6 Real-Time Example
Ariane-5

• Should have included an exception handler

try {
}
catch (…..) {
//attempt to patch up state
//either satisfy postcondition or raise
exception again
}

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.23

Practice
7.7 What This Chapter Means for You

• Things to consider when writing a code

– organizational standards and guidelines
– reusing code from other projects
– writing code to make it reusable on future
projects
– using the low-level design as an initial
framework, and moving in several iterations from
design to code

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.24

Practice
Disclaimer

• Minor modifications have been made in

content and flow of UCF slides

Pfleeger and Atlee, Software Engineering: Theory and Chapter 7.25

Practice