Module 4
Coding
SHEMIL K.K
S6 CSE
Govt. Engg.
College
Idukki
Goal
To translate the design of the system produced
during the design phase into code in a given
programming language, which can be executed by
a computer and that performs the computation
specified by the design.
Coding phase
Affects both testing and maintenance
Programs should not be constructed so that
they are easy to write, but so that they are
easy to read and understand
The Weinberg Experiment
The famous experiment by Weinberg showed that if
programmers are specified a clear objective for the program,
they usually satisfy it [ws74].
Programming Practice
Top-Down and Bottom-Up
Structured Programming
Information Hiding
Programming Style
Internal Documentation
Top-Down and Bottom-Up
Top-down : implementation starts from the top of
the hierarchy and proceeds to the lower levels.
Bottom-up: starts with implementing the modules
at the bottom of the hierarchy and proceeds
through the higher levels until it reaches the top.
If there is a complete design, why is the
order in which the modules are built an
issue?
We want to incrementally build the system
(differ from incremental enhancement
process model)
Coding Issue
Real issue in which order the modules are coded
comes in testing
Top-down : stubs will have to be written for the lower
level modules that the set of modules under testing
invoke
Bottom-up: All modules that are lower in the hierarchy
have been developed and driver modules are needed
to invoke these modules under testing
Top-down development may be preferable to aid the
design while the implementation is progressing
Layered architecture: Bottom-up
In practice, a combination of these two approaches
Structured Programming
Structured programming movement started in the 1970s.
Static Structure
structure of the text of the program (fixed)
Dynamic Structure
sequence of statements executed during execution
of the program
Objective
Developing programs whose control flow
during execution is linearized (using structured
constructs) and follows the linear organization
of the program text.
Program understanding is to understand the
dynamic behavior of the program from text of
the program
Structured Programming
single-entry and single-exit constructs
e.g:
Selection: if B then S1 else S2
if B then S1
Iteration: While B do S
repeat S until B
Sequencing: S1;S2;S3;…
Information Hiding
Principle: when information is represented as data
structures, only some defined operations should be
performed on the data structures
Access and manipulation of data structures only through
access functions
Reduces coupling and make the system maintainable
Contd…
An effective tool for managing the complexity of
developing software
Information hiding is supported by many modern
languages in the form of data abstraction, helps
to increase the clarity of the program
Programming style
Names
Variable names: entity
module name: activity
Control constructs
single-entry, single-exit constructs
Gotos
forward transfers is more acceptable than a
backward jump
Information Hiding
Contd…
User- defined types: enumerated type
Nesting
deep nesting should be avoided
Module size
guiding principle should be cohesion and
coupling
Module Interface
any module whose interface has more than five
parameters should be carefully examined and broken
in to multiple modules with a simple interface
Contd…
Program Layout
proper indentation, blank spaces, and parentheses
should be used to enhance the readability of programs
Side Effects
if a module has side effects, they should be properly
documented
Robustness (exit gracefully)
a program is robust if it does something planned even
for exceptional conditions
Internal Documentation
Output document: code
Internal documents : comments (prologue)
Explain what the code is doing, not how it is doing it (Not
the logic)
Increases understandability and eases maintenance
Prologue contains
1. Module functionality, or what the module is doing
2. Parameters and their purpose
3. Assumptions about the inputs
4. Global variable accessed and/or modified in the module
Verification
Primarily for detecting errors
Shows that the code is consistent with the design
Two categories of verification methods
Static : errors detected directly (code reading, code
reviews and walkthroughs)
Dynamic : executed on some test data and outputs
are checked( program is compiled and executed)
(testing)
Verification
Code Reading
Static Analysis
Symbolic Execution
Proving Correctness
Code Inspections
Unit Testing
Code Reading (Desk Review)
Involves determining the abstraction
of a module and then comparing it
with its specifications
Details Abstraction
Static Analysis
Analyzing of programs by methodically analyzing the
program text
Performed by software tools
During this analysis the program itself is not executed, but
the program text is the input to the tools
Very cost-effective way of discovering errors
Provide “warnings” against potential errors and provide
insight into the structure of the program
Data flow analysis
One form of static analysis that concentrates on the uses
of data by programs and detects some data flow
anomalies.
Dataflow anomalies are technically not errors, they are
often a symptom of an error
Eg: Live variable problem
Contd…
Data flow analysis can provide valuable information for
documentation of programs
Can identify aliasing, which occurs when different variables
represent the same data object
Other examples of data flow anomalies are unreachable
code, unused variables, and unreferenced labels.
These are technically not errors, but often are symptoms of
errors, thus their presence often implies the presence of
errors.
Flow graph
Data flow analysis is commonly performed by
representing a program as a graph
Nodes represents statements of a program, while the
edges represent control paths from one statement to
another.
Each node can be represented as a procedure or
function (call graph)
Other uses of static analysis
Helps to identify mismatched parameter lists
Helps to detect calls to nonexistent program modules
Can also detect infinite loops and illegal recursion
Helpful for cross reference of different variables and
constants
Used to evaluate the complexity
Can produce the structure chart of programs
Symbolic Execution or symbolic evaluation
or symbolic testing
Program is “symbolically executed” with symbolic data
Inputs are not numbers but symbols representing the
input data
Output: symbolic formulas of input values
Example 1:
Path conditions
A Boolean expression over the symbolic inputs that never
contains any program variables, represented by “pc”.
Eg: 1f C then S1 else S2
• Path condition 1 :
• Path condition 2:
Example 2
Symbolic Execution Trees
Proving correctness
The aim is to prove a program correct
State formally what the program is supposed to do
Goal : Determining the pre-condition for which the post-
condition will be satisfied
One technique: axiomatic method (Floyd-Hoare proof
method)
Code Inspections or Reviews
Enhance reliability and reduce effort during testing
Reviews after other methods (save human time and effort)
Aim of review is to detect defects in code and quality issues
Two categories of defects
Logic and control (infinite loops, missing labels, improper
nesting)
Data operations and computations (incorrect access of array
components, improper initialization, misuse of variables)
Unit Testing
Dynamic method for verification
Test modules or “units”
Done by programmer
