0% found this document useful (0 votes)
7 views

coding-M 4

SOFTWARE ENGINEERING-UNIT 4

Uploaded by

reshma.r
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

coding-M 4

SOFTWARE ENGINEERING-UNIT 4

Uploaded by

reshma.r
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

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

You might also like