SOFTWARE CONSTRUCTION

AND MAINTENANCE

PRACTICAL
CONSIDERATIONS

1
Topics to be discussed

 Construction design
 Construction Languages
 Coding
 Construction Testing
 Reuse
 Construction Quality
 Integration

2
CONSTRUCTION DESIGN

3
Software Design

The process of defining the software architecture,

components, modules, interfaces, test approach,
and data for a software system to satisfy specified
requirements.

4
Importance of Managing Complexity
 Most technical issues are due to high complexity
 Users are demanding more functionality
 Frequent source of complexity
 Software Crisis: Ability to produce suitable
applications is not keeping pace with demand
 Causing systems to be unreliable, slow, insecure,
buggy
 “Separation of concerns” is one method to overcome
complexity
 Writing programs in terms of the problem domain,
rather than in terms of low-level implementation details

5
Overcome Complexity

Ineffective designs come from three sources:

 A complex solution to a simple problem
 A Simple, incorrect solution to a complex problem
 An inappropriate, complex solution to a complex
problem

Two ways to manage complexity:

 Minimize the amount of essential complexity
 Keep accidental complexity from proliferating

6
Design Characteristics
1. Minimal complexity
2. Ease of maintenance
3. Loose coupling
4. Extensibility
5. High fan-in
6. Low-to-medium fan-out
7. Portability
8. Leanness
9. Stratification
10.Standard techniques
7
Minimal complexity
 Avoid making “clever” designs. make “simple” and
“easy-to-understand” designs
Ease of maintenance
 Designing for the maintenance programmer
 Use common programming constructs and
consistent naming conventions
Loose coupling
 Reduce interdependencies within the code
Extensibility
 Minimal ripple effect when changes are made
Reusability
 Modules, components, & subsystems can be and
are reused
8
High fan-in
 Highly utilized classes
Low to medium fan-out
 Call tree not to large
Portability
 Able to be redeployed in a different environment
Leanness
 No extra parts
Stratification
 Consistent levels of abstraction across subsystems
Standard techniques
 Stay with the “tried and true”
9
Levels of Design

5 levels of abstraction in software design:

• Software System
• Subsystems
• Classes
• Routines
• Internal Routine Design

10
Level 1 – Software System

 The entire system

 Concern of the architect, not detailed designer
 Unless system is extremely small

11
Level 2 – Division into Subsystems or Packages

 Identify all major subsystems

 I.e. identity the architectural layers and the contents
in each layer
 Major design activities at this level are
1. Partition the program into major subsystems
Business rules ,User interface, Database access, System
dependencies
2. Define subsystem interfaces

12
Level 3 – Division into Classes

 Identify all classes by subsystem

 Define class relationships
 Generalizations
 Dependencies
 Associations
 For each class, define its interface

13
Level 4 – Division into Routines

 Define the routines for each class

 Previously defined interfaces will help
 Need to also identify internal routines
 Level 4 activities may necessitate a return to
Level 3 to further define the interface
 This is normal and encouraged in an iterative
development approach

14
Level 5 – Internal Routine Design

 Lay out the detailed functionality of each routine

 Closest activity to programming
 This includes:
 Deciding program flow, perhaps by writing pseudocode
 Choosing algorithms
 Determining program calls
 Determining return points
 Inserting programming constructs such as loops and case
statements

15
Design Techniques

 Find Real-World Objects

 Form Consistent Abstractions
 Encapsulate Implementation Details
 Apply Inheritance
 Hide Internal Information
 Identify Areas Likely to Change
 Ensure Loose Coupling
 Apply Design Patterns

16
 Aim for Strong Cohesion
 Build Hierarchies
 Formalize Class Contracts
 Assign Responsibilities
 Design for Test
 Avoid Failure
 Choose Binding Time Consciously
 Make Central Points of Control
 Consider Using Brute Force
 Draw a Diagram
 Keep Your Design Modular
17
Design Approaches

Iterate
 Don’t stagnate in any one activity
 Instead, cycle through activities and return to the beginning
 Build on previous work
Divide and Conquer
 Divide problem into more manageable chunks
Prototype
 Create a “quick and dirty” version of the application
 Provides insight into the problem
Collaborative Design
 Two (or more) heads is better than one
 Can be formal or informal

18
Construction Languages : Coding

19
Construction languages include all forms of
communication by which a human can specify an
executable problem solution to a computer.
Toolkit languages are used to build applications out of
toolkits and are more complex than configuration
languages.
 Toolkit languages may be explicitly defined as
application programming languages (for example,
scripts), or may simply be implied by the set of
interfaces of a toolkit.

20
Programming languages are the most flexible type of
construction languages.
 It contains the least amount of information about
specific application areas and development
processes, and so require the most training and skill
to use effectively.

21
There are three general kinds of notation used for
programming languages, namely:
 Linguistic
 Formal
 Visual

22
 Defensive Programming:
Approach to improve software quality by “Making
the software behave in a predictable manner despite
unexpected input or user actions
 Protecting your program from Invalid Inputs
 Assertions
 Error Handling Techniques
 Exceptions

23
Protecting Ur Program From Invalid
Inputs
 A good program uses “garbage in, nothing out”; “garbage
in, error message out”; or “no garbage allowed in”
instead.
 There are three general ways to handle garbage in:

 Check the values of all data from external sources

 attempted buffer overflows, injected SQL commands, injected html
or XML code, integer over flows, and so on.

 Check the values of all routine input parameters

 Decide how to handle bad inputs :

 Write Pseudo code before code – Low level inspections
24
Assertions

 An assertion is code that’s used during

development—usually a routine or macro—that
allows a program to check itself as it runs.
 Assertion = True  Everything working as
expected
 Assertion = False  Detected an unexpected
error in the code
 Assertions are especially useful in large,
complicated programs and in high- reliability
programs.

25
 An assertion usually takes two arguments: a Boolean
expression that describes the assumption that’s
supposed to be true and a message to display if it
isn’t.

 Ex:
 assert denominator != 0 : "denominator is
unexpectedly equal to 0.";

26
Error Handling Techniques

 Assertions are used to handle errors that should

never occur in the code. code. How do you
handle errors that you do expect to occur?
 Return a neutral value
 Return a value that’s known to be harmless.
 Numeric Computation  0
 String  Empty String
 Pointer  Empty Pointer
 Drawing Routine  Default color
 Substitute the next piece of valid data

27
 Return the same answer as the previous time
 Substitute the closest legal value
 Log a warning message to a file
 Return an error code
 Set the value of a status variable
 Return status as the function’s return value
 Throw an exception using the language’s built-in exception
mechanism
 Call an error processing routine/object
 centralize error handling in a global error handling routine
or error handling object.
 Debugging Easy

28
 Display an error message wherever the error is encountered

 Handle the error in whatever way works best locally .

 Some designs call for handling all errors locally the
decision of which specific error-handling method to use is
left up to the programmer designing and implementing the
part of the system that encounters the error.

 Shutdown
 Some system shutdown when they detect error.
 Useful in Critical Application

29
Correctness Vs Robustness

 Correctness means never returning an inaccurate

result; no result is better than an inaccurate result.
 Robustness means always trying to do something
that will allow the software to keep operating,
even if that leads to results that are inaccurate
sometimes

30
Exceptions

 Exceptions are a specific means by which code

can pass along errors or exceptional events to the
code that called it.
 Use exceptions to notify other parts of the program about
errors that should not be ignored.
 Throw an exception only for conditions that are truly
exceptional
 Don’t use an exception to pass the buck
 If an error condition can be handled locally,
handle it locally

31
 Include all information that led to the exception in the
exception message
 If the exception was thrown because of an array
index error, be sure the exception message includes
the upper and lower array limits and the value of
the illegal index.

 Avoid empty catch blocks :

try {
...
// lots of code
...
} catch ( AnException exception ) {
}

32
The Pseudo code Programming Process
Steps in building Classes and Routines

33
 Steps in creating a Class
 Create a general design for the class:
 Define the class’s specific responsibilities.
 Define what “secrets” the class will hide.
 Determine whether the class will be derived from
another class, and whether other classes will be
allowed to derive from it.
 Identify the class’s key public methods.
 Identify and design any non- trivial data members used
by the class.
 Construct each routine within the class
 Review and test the class as a whole 34
Steps in building a routine

35
Pseudocode

 The term “pseudocode” refers to an informal,

English-like notation for describing how an
algorithm, a routine, a class, or a program will
work.

36
Bad Pseudocode

increment resource number by 1

allocate a dlg struct using malloc
if malloc() returns NULL then return 1
invoke OSrsrc_init to initialize a resource for the
operating system
*hRsrcPtr = resource number
return 0

37
Good Pseudocode

Keep track of current number of resources in use

If another resource is available
Allocate a dialog box structure
If a dialog box structure could be allocated
Note that one more resource is in use
Initialize the resource
Store the resource number at the location provided by the caller
Endif
Endif
Return TRUE if a new resource was created; else return FALSE

38
General issues in using Variables

 Implicit Declarations
 Ex : Visual Basic – Don’t declare compiler
declares(compiler settings)
 Using a variable in body of a routine  Have to
declare explicitly.
 Turn off Implicit Declarations
 Declare all Variables as you type in
 Use naming Conventions
 Check Variable names

39
Guidelines to Initialize Variables

 Initialize each variable as it’s declared

 char studentName [ NAME_LENGTH + 1 ] = {'\0'}; // full name
of student
 Initialize each variable close to where it’s first used
Dim accountIndex As Integer
accountIndex = 0
' code using accountIndex
...
Dim total As Double
total = 0.0
' code using total
...

40
Guidelines to Initialize variables

 Ideally, declare and define each variable close to where it’s

used
int accountIndex = 0;
// code using accountIndex
...
double total = 0.0;
// code using total
...
boolean done = false;
// code using done
while ( ! done ) {

41
Guidelines to Initialize Variables

 Pay special attention to counters and accumulators :

 The variables i, j, k, sum, and total are often counters
or accumulators.
 Common error is forgetting to reset a counter before
the next time it is used.
 Take advantage of your compiler’s warning messages
 Many compilers warn you that you’re using an
uninitialized variable.
 Use the compiler setting that automatically initializes all
variables
 Use a memory-access checker to check for bad pointers

42
Using Conditionals

 A CONDITIONAL IS A STATEMENT that

controls the execution of other statements;

 Simplest  If / If – Then ;
 If – then – else little more complex ;
 chain of if –then –else –if  more complex.

43
Plain if- then Statements

 Write the nominal path through the code first;

then write the unusual cases

 Make sure that you branch correctly on equality

 Can avoid Off-by- One error

 Put the normal case after the if rather than after the
else

44
Contd..,
 Follow the if clause with a meaningful statement
 Ex: Wrong way
if ( SomeTest )
;
else {
// do something
...
}

Proper way
if ( ! SomeTest ) {
// do something
...
}

45
 Test the else clause for correctness
 Check for reversal of the if and else clauses

46
Chains of if-then-else Statements
Simplify complicated tests with boolean function calls
if ( inputCharacter < SPACE ) {
characterType =
CharacterType_ControlCharacter;
} }
else if (
inputCharacter == ' ' ||
inputCharacter == ',' ||
inputCharacter == '.' ||
inputCharacter == '!' ||
inputCharacter == '(' ||
inputCharacter == ')' ||
inputCharacter == ':' ||
inputCharacter == ';' ||
inputCharacter == '?' ||
inputCharacter == '-'
{
characterType =
CharacterType_Punctuation;
else if ( '0' <= inputCharacter &&
inputCharacter <= '9' ) {
characterType = CharacterType_Digit;
}
else if (
( 'a' <= inputCharacter &&
inputCharacter <= 'z' ) ||
( 'A' <= inputCharacter &&
inputCharacter <= 'Z') ) {
characterType = CharacterType_Letter;
}
47
Contd..,
 Put the most common
cases first :
if ( IsControl( inputCharacter ) ) {
if ( IsLetter( inputCharacter ) ) {
characterType =
CharacterType_ControlCharacter; characterType = CharacterType_Letter;
}
}
else if ( IsPunctuation( inputCharacter ) ) {
else if ( IsPunctuation( inputCharacter ) )
characterType
{ =CharacterType_Punctuation;
characterType = }
CharacterType_Punctuation; else if ( IsDigit( inputCharacter ) ) {
} characterType = CharacterType_Digit;
else if ( IsDigit( inputCharacter ) ) { }
characterType = CharacterType_Digit; else if ( IsControl( inputCharacter ) ) {
} characterType
=CharacterType_ControlCharacter;
else if ( IsLetter( inputCharacter ) ) {
}
characterType = CharacterType_Letter;
} 48
Contd..,

 Make sure that all cases are covered

if ( IsLetter( inputCharacter ) ) {
characterType = CharacterType_Letter;
}
else if ( IsPunctuation( inputCharacter ) ) {
characterType = CharacterType_Punctuation;
}
else if ( IsDigit( inputCharacter ) ) {
characterType = CharacterType_Digit;
}
else if ( IsControl( inputCharacter ) ) {
characterType = CharacterType_ControlCharacter;
}
else {
DisplayInternalError( "Unexpected type of character detected." );
}

49
Selecting the Kind of Loop

 Selecting the kind of loop:

 Based on the flexibility
 Based on the location

Language Loop Flexibility Test Location

C, C++, C#, for flexible Beginning
Java
while flexible Beginning
do-while Flexible End

50
Usage of Loops

When to use while loops????

 Loop with Test at the Beginning
 C,C++,C# - While
 Loop with Test at the End
 do-while in C++, C, and Java,
 Do-Loop-While in Visual Basic
 Loop-with-exit Loop
 loop-with-exit loop in Visual Basic
 while and break in C++, C, and Java

51
Usage of Loops
When to use For loops????
 Need a loop that executes for a specified number
of time
 Use for loop for simple activities that don’t
require internal loop controls.
 When the loop controls involves simple increment
and decrement.
 In For need not to do anything to control it, if
there’s a condition where the execution has to jump
out of loop use While.
 For is for simple activities whereas while is for
complicated looping tasks
52
CONSTRUCTION TESTING

53
Design principles for Construction testing

 Software should work correctly

 Software must conform to requirements
specification
 Software must be reliable over time and data
 Software must be evolutionary
 Software must be easy to use
 Software should be easy to test & implement
 Software should use computer resources
efficiently
54
 Construction involves two forms of testing, which
are often performed by the software engineer who
wrote the code:
 Unit testing
 Integration testing

55
 The purpose of construction testing is to reduce
the gap between the time at which faults are
inserted into the code and the time those faults are
detected.
 In some cases, construction testing is performed
after code has been written. In other cases, test
cases may be created before code is written.

56
Verification and Validation

• Verification: The process of evaluating a system or

component to determine whether the products of a
given phase satisfy the conditions imposed at the start
of that phase.(process done by customer)

 Validation: The process of evaluating a system or

component during or at the end of the
development process to determine whether it
satisfies specified requirements.(process done by
s/w developer)
57
Software Construction Strategies

 TOP-DOWN : High-level to low-level; user

interface to detail logic

 BOTTOM-UP : Reverse of the above

 MIDDLE-OUT : Some of both

58
Two Software Evaluation Metrics

1. Cohesion

2. Coupling

59
COHESION: The measure of strength of the
interrelatedness of statements within a module
 Functional: one action or goal
• Informational: multiple independent actions on
the same data
 Communicational: series of steps on same data
 Procedural: series of steps for an action
• Temporal: series of related actions related in time
• Logical: series of related actions
• Coincidental: multiple, unrelated actions

60
 Cohesion

Coincidental Logical Temporal ..... Informational Functional

low (“worst”) high (“best”)

“Scatter-brained” module “Single-minded” module

61
COUPLING: The measure of strength of the
connection between modules
 Content: direct branch into middle of module

 Common: global reference of variables

 Control: control element being passed

 Stamp: pass an entire data structure

 Data: variables or fields only being passed

 No Coupling

62
 Coupling

No coupling Data Stamp Control Common

Content

low (“best”) high (“worst”)

“highly independent” “highly dependent”
module module

63
 TESTING PRINCIPLES
 User-accepted test plan
 General testing strategy/philosophy:
 Cause and discover errors
 Rules of reasonableness should prevail
 Testing Strategies:
 Top-Down
 Bottom-Up
 Middle-out
 Hybrid
 Black box
 White box
 Alpha
 Beta 64
Testing Methodology
User Acceptance Testing

System Testing

component Testing

Integration Testing

Unit Testing

65
 Unit testing
 execution of a complete class, routine, or small
program that has been written by a single
programmer.
 Integration testing
 Combined execution of two or more classes,
packages, components, subsystems that have been
created by multiple programmers or programming
teams.
 Component Testing
 execution of a class, package, small program, or
other program element that involves the work of
multiple programmers or programming teams.

66
System testing
execution of the software in its final configuration.
Regression testing
Repetition of previously executed test cases for the
purpose of finding defects in software that
previously passed the same set of tests.

67
Reuse

 “Implementing software reuse entails more than

creating and using libraries of assets. It requires
formalizing the practice of reuse by integrating
reuse processes and activities into the software
life cycle.“

68
Task related to reuse

 The selection of the reusable units, databases, test

procedures, or test data
 The evaluation of code or test reusability
 The reporting of reuse information on new code,
test procedures, or test data

69
Construction Quality

70
Definitions
 The totality of features and characteristics of a
product or service that bear on its ability to satisfy
stated or implied needs.
 Software has both external and internal quality
characteristics.
 The degree to which a system, component, or
process meets specified requirements
 A product that satisfies the stakeholders needs
(Compliant Product + Good Quality + Delivery
Within Budget/Schedule.)

71
Internal Characteristics

 reliability - the ability to operate error free

 reusability – the ability to use parts of the
software to solve other software problems
 extendibility - the ability to have enhancement
changes made easily
 understandability - the ability to understand the
software readily, inorder to change/fix it (also
called maintainablity)

72
 efficiency - the speed and compactness of the
software
 usability - the ability to use the software easily
 testability - the ability to construct and execute
test cases easily
 portability - the ability to move the software
easily from one environment to another and of
course
 functionality – what the product does

73
Quality and Software Construction

Functionality [+ usability]
 Build software as early as possible and give it to
the user
 As often as possible
Reliability [correctness + robustness]
 Run and test the software
 As often as possible
Reusability [modifiability + extendibility]
 Redesign and improve the source code
74
Techniques for improving code quality

 To improve the quality of the product you must improve the

quality of the process [#1 rule of software engineering]
 Institute a set of coding guidelines (standards) for the
development of code
 Institute code walkthroughs or inspections
 Institute a verification and validation (V&V) process to
verify code
 Use external audits when necessary
 Develop a reward structure that rewards the “good”
producers of code rather that the error prone producers of
code

75
Defect – Detection Rates

Detection Technique Lowest Rate Model Rate Highest Rate

(%) (%) (%)
Personal checking of design documents 15 35 70
Informal group design reviews 30 40 60
Formal design inspections 35 55 75
Formal code inspections 30 60 70
Modeling or prototyping 35 65 80
Personal desk-checking of code 20 40 60
Unit testing (single routine) 10 25 50
Function testing (Related routine) 20 35 55
Integration testing (Complete system) 25 45 60
Field testing (live data) 34 50 65
Cumulative effect of complete series 93% 99% 99%

76
 Model defect rates are not above 65% of any single
technique
 Code inspections found a 60% model defect rate
 The model defect rate for [the popular] unit testing is
only 25%
 Code reading detected more interface defects;
functional testing detected more control defects
 To improve defect detection use more than one
technique
 The earlier a defect is caught, the cheaper it is to fix
 Approximately 50% of the construction phase is
spent debugging finished code and finding errors
77
The primary techniques used for
construction include
 Unit testing and integration testing
 Test-first development
 Code stepping
 Use of assertions
 Debugging
 Technical reviews
 Static analysis

78
Goals

 The goal of software construction is to build a

product that satisfies the quality requirements
 “Good enough software”
 Not excellent software !

79
Integration

 Construction is the integration of separately

constructed routines, classes, components, and
subsystems.
 In addition, a particular software system may
need to be integrated with other software or
hardware systems.
 Small Projects – Hooking handful of classes
together ; day or two work.

80
 Large projects - hooking sets of programs
together; weeks or month together.

81
Construction integration include

 planning the sequence in which components will

be integrated.
 creating scaffolding to support interim versions of
the software.
 determining the degree of testing and quality
work performed on components before they are
integrated.
 determining points in the project at which
interm versions of the software are tested.

82
System Integration

 The act of merging a software element or elements

with another element
 The act of merging a hardware component or
components with another hardware component
 The act of merging software configuration items
with hardware configuration items in order to
produce a total system which satisfies customer
requirements

83
Types of Integration techniques

 All in one integration (the “big bang” integration)

 Incremental integration
 Top-down integration
 Bottom-up integration
 Sandwich integration

84
 The Big Bang Integration
 All components, modules, and subsystems are
combined and integrated at one time

 This is called the “big bang” because it frequently

blows up

 If (and when) the system fails to integrate, it is next

to impossible to determine the cause

 This is called the “smoke test” in the hardware world

 “Let’s put the power to it and see where the smoke
rises” 85
Incremental Integration

 Incremental integration:
1. Develop a small core of the system
2. Test and debug it
3. Design, code, test, and debug another part
(module, routine, etc.)
4. Integrate the new part with the core
5. Ensure that the new partial system works
6. Repeat steps 3 through 5 until finished

86
Benefits of Incremental Integration

 Errors are easy to locate – The last integration is probably at

fault
 Incremental integration provides early evidence that progress
is being made (better status information)
 Planning (scheduling) is more accurate
 Components are tested more fully and frequently
 Improves the development schedule by work being done in
parallel
 Development and testing are more easily distributed
 Integration can be done beginning at the top or the bottom
(called top-down integration an d bottom –up integration)
87
Top-Down Integration

 Identify the order of development such that:

 When developing a routine, all higher routines are
completed
 Harder problems are attacked first; easier problems
are delayed
 Test stubbing is easiest

88
 The order of development depends on the type of
project
 Control oriented: Calling routines are higher than
called routines
 Data oriented: Routines that primarily set data higher
than routines that primarily use data
 Requirements oriented: Routines least sensitive to
requirements or design choices are ranked higher than
more sensitive routines
 Test oriented: Routines critically needed for testing of
other routines are higher ranked than routines not
needed for testing

89
 Difficulty oriented: Harder routines are ranked
higher than easier routines (This is the order that is
illustrated)

90
Top-Down vs. Bottom-Up
Integration

91
Phased Integration Vs Incremental
Integration

92
Phased Integration Vs Incremental
Integration
 Errors are easy to locate
 The system succeeds early
in the project
 The system succeeds early
in the project
 You’ll improve customer
relations
 The units of the system
are tested more fully
 You can build the system
with a shorter
development schedule
93
Other Approaches

Top Down Integration Bottom Up Integration

94