Unit II

CONSTRUCTION DESIGN
Topics to be discussed

 Design Challenges
 Key Design Concepts
 Design Building Blocks
Design Challenges

 Software Design
 Scheme for turning a specification of a computer
program into an operational program.
 Activity that links requirements to coding and
debugging.
Design Challenges

 Design is a wicked problem

 “Wicked Problem” – one that can be clearly defined
only by solving it or solving a part of it.

 Design is a Sloppy Process

 Finished s/w design is well organized and clean
whereas the process used to develop is not.
 Sloppy cos - Lot of mistakes ; don’t know how
much detail is enough, when are you done???? Ans:
Outta time
Design Challenges

 Design is about Trade-Offs and Priorities

 Start Off, Storage Space, N/w Bandwidth , Errors , Cost
 Fast Response and Slow dev time - Design 1
Fast Dev time and Slow Response time – Design 2
 Design involves Restrictions
 Restrict possibilities – Restricted Resources for
development will simplify the solution ultimately
improves the solution.
 Design is Non- Deterministic
 One Problem – different design
Design Challenges

 Design is a Heuristic process

 No thumb rule
 Design involves trial and error

 Design is Emergent
 evolve and improve through design reviews,
informal discussions, experience writing the code ,
and experience revising the code itself.
Key Design Concepts

 Characteristics :
 Minimal Complexity
 Avoid making clever designs
 Make simpler and easy to understand
 Ease of Maintenance
 Design for the Maintenance programmer
 Design the system to be self explanatory
 Minimal Connectedness
 Strong Cohesion and loose coupling
 Information hiding to design classes with minimal connections
 Minimizes the work during integration , testing and
Maintenance
Key Design Concepts
 Extensibility
 Enhance system without damaging the underlying structure
 Reusability
 Reuse the pieces of it for other system
 High Fan –In
 High no. of classes that use a given class
 implies that a system has been designed to make
good use of utility classes at the lower levels in the
system.
 Low – Medium Fan-Out
 given class use a low-to-medium number of other
classes
Key Design Concepts

 Portability
 designing the system so that you can easily move it to
another environment.
 Leanness
 designing the system so that it has no extra parts
 Stratification
 trying to keep the levels of decomposition stratified
so that you can view the system at any single level
and get a consistent view.
Design Building Blocks

 Find the real world object

The steps in designing with objects are :
 Identify the objects and their attributes (methods
and data).
 Determine what can be done to each object.
 Determine what each object can do to other objects.
 Determine the parts of each object that will be
visible to other objects which parts will be public and
which will be private.
 Define each object’s public interface.
Design Building Blocks

 Form Consistent Abstractions

 Any time work with aggregate – dealing with

Abstraction.

 Base classes are abstractions that allows you to focus

on common attributes of set of derived classes and
ignore the details of the specific classes while you’re
working on the base class.
 Abstraction allows you to take a simpler view of a
complex concept.
Design Building Blocks

 Encapsulate Implementation details

 “You’re allowed to look at an object at a high level of
detail”
 Furthermore, “you aren’t allowed to look at an
object at any other level of detail”

 Encapsulation says that, not only are you allowed to take a

simpler view of a complex concept, you are not allowed to
look at any of the details of the complex concept.
Design Building Blocks

 Inherit when Inheritance Simplifies the

Design
 Similar objects with few difference
 General routine to handle general properties and
then write specific operations
Design Building Blocks

 Hide Secrets ( Information Hiding)

 Black Boxes
Construction Languages : Coding

 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
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
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
Ex:
 System assumes that customer information file never has more than 50 k
records. As long as the number of records is less than or equal to 50,000, the
assertion will be silent. If it encounters more than 50,000 records, however, it
will loudly “assert” that there is an error in the program.
 Assertions are especially useful in large, complicated
programs and in high- reliability programs .
Assertions

 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.";
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
Error Handling Techniques

 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
Error Handling Techniques

 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
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.
 Safety Critical Applications  ????
Consumer Applications  ????
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
 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 ) {
}
 TRY

 The "try" keyword is used to specify a block

where we should place an exception code. It
means we can't use try block alone. The try
block must be followed by either catch or
finally.
 CATCH

 The "catch" block is used to handle the

exception. It must be preceded by try block
which means we can't use catch block alone.
It can be followed by finally block later.
 FINALLY

 The "finally" block is used to execute the

necessary code of the program. It is executed
whether an exception is handled or not.
 “ THROW “ AND “THROWS”

 The "throw" keyword is used to throw an

exception.
 The "throws" keyword is used to declare
exceptions. It specifies that there may occur
an exception in the method. It doesn't throw
an exception. It is always used with method
signature.
 SAMPLE CODE

 public class JavaExceptionExample{  
   public static void main(String args[]){  
    try{  
       //code that may raise exception  
       int data=100/0;  
    }catch(ArithmeticException e){System.out.println(e);}  
    //rest code of the program   
    System.out.println("rest of the code...");  
   }  
 }  
The Pseudo code Programming Process
Steps in building Classes and Routines
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
Steps in building a routine
Pseudocode for Pros

 The term “pseudocode” refers to an informal, English-like

notation for describing how an algorithm, a routine, a
class, or a program will work.
 Use English-like statements that precisely describe specific
operations.
 Avoid syntactic elements from the target programming language.
 Write pseudocode at the level of intent. Describe the meaning of
the approach rather than how the approach will be implemented
in the target language.
 Write pseudocode at a low enough level that generating
code from it will be nearly automatic. Refine the
pseudocode in more and more detail until it seems as if it
would be easier to simply write the code.
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
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
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
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
...
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 ) {
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
Scope of Variables

 Scope, or visibility, refers to the extent to which your

variables are known and can be referenced throughout a
program.
 Handling of Scope Different languages Different
ways.
 Primitive Languages – All variables are global and no control over
the variable
 Whereas , in C++ & similar you can make the variable visible:
 Specific block of code
 Routine / Class/ Whole program
 Packages/Namespaces
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.
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
Wrong way
Systematic way
Contd..,
 Follow the if clause with a meaningful statement
 Ex: Wrong way
if ( SomeTest )
;
else {
// do something
...
}

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

 Test the else clause for correctness

 Check for reversal of the if and else clauses
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." );
}
Case Statements

 Choosing the most effective ordering cases:

 Order cases alphabetically or numerically
 Put the normal case first
 Order cases by frequency
 Keep the actions of each case simple
 Short codes after cases makes the structure
readable
 Use the default clause to detect errors
Selecting the Kind of Loop

 Selecting the kind of loop:

 Based on the flexibility
 Based on the location

Language Loop Flexibility Location

C, C++, C#, for flexible Beginning
Java
while flexible Beginning
do-while Flexible End
foreach* Rigid beginning
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
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
 Edward Kit – chapter 8

LEVELS OF
TESTING
 Low-level testing --- individual program
components, one at a time or in combination.
 Unit (module) testing
 Integration testing

 High-level testing --- involves whole product

 Usability testing
 function testing
 System testing
 Acceptance testing
 Unit Testing
 Searches for defect and verifies the functionality of software,
depending upon the context of the development

 It includes testing of functional and non-functional

characteristics

 It occurs with access to code being tested and with the support
of development environment

 Defects are fixed as soon as they are found with out formally
recording incident

 If test cases are prepared and automated before coding, it is

termed as test-first approach or test-driven development.
 INTEGRATION TESTING
Objective is to discover errors in the interface between the components

Non- incremental – “big bang”

all components are combined at once to form a program.
Then it is tested. It is least effective approaches. Debugging in
difficult .
Incremental integration – unit test the next program
component after combining it with a set of previously
tested components. Debugging is easier.

Bottom-up integration
Top-down integration
Incremental Integration
testing
 Takes more time and effort
 Identifying errors is easier
 Errors can be added in the last added module
Top down Integration Testing

 Start with the topmost module

 Move towards the scratch module
 Sub ordinate modules are simulated using
dummy module called stubs
 In top down integration a module can be
integrated if all of its super ordinate modules
are tested earlier
Stub Testing (Stubs and
Drivers)
- Unit and Integration testing
Stubs: dummy modules used
Top-Down Integration Testing for testing if higher level
A modules are working properly.

b c d Stubs

B C D

e f g Stubs A

B C D

E F G
Bottom up Integration
Testing
 Start with the Scratch module
 Move towards the topmost module
 Super ordinate modules are simulated using
dummy module called drivers
 In bottom up integration a module can be
integrated if all of its subordinate modules
are tested earlier
Bottom-Up Integration testing

A Driver: dummy modules used

for issuing calls to lower modules
B C D and testing if the lower modules are
working properly.
E F G

a Driver

B C D

E F G

b Driver c Driver a Driver

E F G D
 Cost of developing stubs and drivers
 generally, Driver modules are easier to develop --
so, bottom-up integration testing is less costly.
 With Top-Down Integration Testing, major modules
are coded and tested first - strong psychological
boost when major modules are done. It gives skeletal
structure
 With Bottom-Up Integration testing, no working
program can be demonstrated until the last module
is tested -- major design errors may not be detected
till the end, when entire programs may need revision!
 Meet-in-the-middle approach may be best.
 Usability testing
 Process of attempting to identify discrepancies
between the user interfaces of a product and the
human engineering requirements of its potential
users.
 Requirement based
 Validation activity rather than a verification activity

Characteristics :
Accessibility
Responsiveness
Efficiency
Comprehensibility
 Function testing
 Process of attempting to defect discrepancies
Between a program’s functional specification and its
actual behavior.
 Performed by a testing group before the product is
made available to customers
 Function coverage is measured with function
coverage matrix form
Functions/Inputs
Priority
Test cases
 System testing
 Process of attempting to demonstrate that a
program or system does not meet its original
requirements and objectives, as stated in the
requirements specification.
 It is difficult
 Needs a great deal of creativity
 Designed by analyzing the requirements
specification and then formulated by analyzing
the functional design specification or user
documentation.
 Types/goals of System Testing
 Volume Testing
 Load/stress Testing
 Security testing
 Usability testing
 Performance testing
 Resource usage testing
 Configuration testing
 Compatibility/conversion testing
 Installability testing
 Recovery testing
 Serviceability testing
 Reliability/availability testing
 Steps of system testing
 Decompose and analyze the requirements specification
 Partition the requirements into logical categories and ,
for each components, make a list of the detailed
requirements
 For each type of system testing
 Determine inputs and outputs
 Develop the requirements test cases
 Develop a requirements coverage matrix
 Execute the test cases and measure logic coverage
 Develop additional tests, by combined coverage
information
 Acceptance testing
Process of comparing the end product to the current
needs of its end users.

 Acceptance criteria – If the product is not developed

under contract, the developing organization can
arrange for alternative forms of acceptance testing –
ALPHA & BETA

 Site location is important for support purposes

 Bilateral plans and agreements are recommended

 ALPHA test is performed by end users inside the
developing company but outside the development
organization

 BETA test is performed by a selected subset of

actual customers outside the company, before the
software is made available to all customers

 Progressive testing is the process of testing new

code to determine whether it contains error

 Regressive testing is the process of testing a

program to determine whether a change has
introduced errors in the unchanged code.