PROG8060_Lesson02_DebuggingRNHEdits.pptx

Debugging
PROG8060
Developing Quality Applications
Spring 2020
Baljeet S. Bilkhu
bbilkhu@conestogac.on.ca
Revised:
rhildred@conestogac.on.ca

Today’s Agenda…
From the Course Outline:
 1.0 Background and relevance of Computing Systems in Software
Development
 1.3 Identify the key methods and techniques used in debugging computer
applications.
 1.4 Identify the key components and building blocks of developing
algorithms.
 Agile – Product Vision, Product Objectives, Product Roadmap
 Project Work – Project Selection, Project Proposal Development

What is Debugging?
 From Wikipedia: The process of finding and resolving
defects or problems within a computer program that
prevent correct operation.
 In other words, computer programs rarely work on
their very first attempt at execution
 Once we find that the program is not working
correctly, we need to take steps to resolve the issue(s)

Debugging Process
Reproduce
the defect
Narrow down
the steps
Track down /
trace the
source of the
problem

Reproducing the Defect
 Once a defect has been noted, the next task is to
clearly identify how it can be reproduced…
 For the ProSum V 1.0 application, there is a way to
make this program crash 
 Try large numbers (say 5 digits or more)
 Not all 5 digit numbers will cause a crash!

Reproducing the Defect (cont…)
 Often times, a customer may call in to say that they
experienced a crash of an application, but it may not
be reproducible again or in another environment (say
when the development / testing team tries)
 Factors that can influence whether a defect is
reproducible
 Actual steps used to reproduce
 Actual environment – including hardware, software
 Maybe even the time of day!

Narrowing Down The Problem
 After reproducing the defect, the next area to focus
on is to narrow down the problem to the minimum
amount of steps or precise data values used
 For the ProSum V 1.0 application, there is a precise
way to make this program crash
 Have 32768 and 32767 (sum 65535) as the
minimum

Narrowing Down The Problem
(cont…)
 Often times, we’ll need to use the “divide and conquer”
approach to problems to narrow down the exact cause
 If we have a large set of data (such as in ProSum), we can
continue to divide the data set into two until we get the
exact values.
 Testers / Developers can also try to remove various
components (UI, Business Logic, Database) to continue to
narrow down where the issue exists.

Tracing to the root of the problem
 Once, the minimum number of steps are determined,
debugging tools can be used by the development /
testing team to determine the exact cause of the defect
 These debugging tools can show the exact values of
variables, contents of memory (heap and stack), as well
as performance metrics and other key aspects.

Debugging Techniques - Breakpoints
 One key (and simplest) technique in debugging code (using Visual
Studio, C#) is called using a Breakpoint
 Inserting a breakpoint where we want to start debugging
 Using “F10” to Step Over the code or “F11” to Step Into the code
 Step Over: for that code that you know is functioning
 Step Into: for that code that you have suspicions that it is not working
 Can also hit the pause button when the application is running and
then see the values of the variables, etc…

Breakpoint - Example
 Click to the <left> of the line number where you want to
add a Breakpoint:

Breakpoint – Example cont…
 Program here does not give any error…however, it
doesn’t show the correct result either 

 Run the program:

 Hovering over any variables will give us the value of it

 Next, press the F11 key to “Step Into” each line of code
after the breakpoint.

 To remove the Breakpoint, simply click on the red dot
that is beside the line number:

Breakpoint – Other Information
 Other information that could be valuable when debugging
while using a BreakPoint:
 Call Stack Window: will show which part of the code is calling a
particular method as well as the sequence of access (for example, if
you have multiple parts of the code calling the same method, they
each could be changing values that you were not expecting);
 Locals Window: displays the current values of all variables declared
locally in the method.

Conditional Breakpoints
 These are useful debugging techniques that can break
when (for instance) a particular variable takes on a
specific value. (This may not be present in Visual Studio
Express versions)

Conditional Breakpoints (cont…)
 Set your breakpoint (as you normally would);
 Right click on the breakpoint and select “Conditions…”

 Set your condition – in this case, let’s set i equal to four

 See that the red dot changes to include a “+”

Breakpoint – Hands On Work
 Copy the following code into a new project and set a BreakPoint at: static string titleAdd = "The sum of the numbers 11 and 22 is:"; use F11 to step into the code,
keeping an eye out on each variable.
class Program
{
static string titleAdd = "The sum of the numbers 11 and 22 is:";
static void CalculateSum() {
int firstNumber = 11;
int secondNumber = 22;
int sum = firstNumber + secondNumber;
Console.WriteLine(sum);
}
static string titleProduct = "The product of the numbers 33 and 44 is:";
static void CalculateProduct()
{
int thirdNumber = 33;
int fourthNumber = 44;
int product = thirdNumber * fourthNumber;
Console.WriteLine(product);
}
static void Main()
{
Console.WriteLine(titleAdd);
CalculateSum();
Console.WriteLine(titleProduct);
CalculateProduct();
Console.ReadLine();
}
}

Try – Catch Blocks
 To avoid unexpected program crashes and to generate meaningful
responses for errors, we can use try-catch blocks. When an error is
encountered, the code in the try section is skipped and execution resumes
in the catch section.
try
{
using (var myObject = new MyClass())
{
// Actual code is here
}
}
catch(Exception ex)
{
// How to handle an exception here
}

Try – Catch Block – Example (cont…)

Logging Data
 When working with large programs (say, hundreds or
thousands of lines of code), it may be difficult to find
exactly where the error occurred
 C# allows the ability to output text to a log file using the
StreamWriter class (in the System.IO namespace)

Developing Algorithms
 As we can recall, Algorithms are simply instructions or a set of
steps for completing a task or problem.
 We can take this definition to add the words “…in an efficient
method or manner”
 If we’re able to devise a set of steps that is more efficient than
another set of steps to solve the same problem, we will be
able to make the most of the finite resources (say CPU,
Memory, Network, Disk, etc…) that are at our disposal.

Developing Algorithms (cont…)
 For instance, if we are given the problem “add all
integers from 0 to 4 and show the result”, we can
develop the solutions as follows:
Solution A Solution B
Var1 = 0;
Var2 = 1;
Var3 = 2;
Var4 = 3;
Var5 = 4;
Sum = Var1 + Var2 + Var3 + Var4 +
Var5;
Print (Sum);
Sum = 0;
For i in range(4):
Sum += I
Print (Sum);

Building Blocks of Algorithms
 The key building blocks of Algorithms:
 Sequence / Action
 Selection / Decision
 Iteration / Loop

Building Blocks of Algorithms
 The key building blocks of Algorithms:
 Sequence / Action
▪ For example, sum var1 and var2
 Selection / Decision
▪ If the temperature is greater than 27C, then print “it is hot outside”
 Iteration / Loop
▪ Calculate the sum of all even numbers from zero to one-hundred

Building Blocks of Algorithms – Class
Work
 Print the name of your best friend
 Compute the area of a circle with a radius of 5cm
 Print the conversion equivalents of 0 to 100 from mph to
km/h
 If Jack is taller than Jill, then print “Jack is taller”
 Print the square root of all integers between 0 and 49

Product Vision
 This is usually the first stage in any Agile project – defining
the Product Vision – essentially an “elevator pitch” about
what your product is and how it will support your overall
company’s vision / objectives
Develop
Product
Objective
Draft a
Vision
Stateme
nt
Validate
Vision
Stateme
nt
Revise
Vision
Stateme
nt
Finalize
Vision
Stateme
nt

Product Objectives
 Focus is applied on developing / defining:
 Goals of the product
 Intended Customers
 Need
 Competition
 Distinctive Differences

Product Roadmap
 Provides an overall view of all of the product’s requirements
 Categorizes requirements into logical groupings
 Estimates the effort required
 Outlines what features will be delivered at what point in time
 Agile Best Practices: Road Maps Video

Definition of Done (DoD)
 Within Agile, each iteration or Sprint should deliver
some part or increment of the overall product with a
focus on increasing the quality, functionality or overall
completeness.
 The Definition of Done (DoD) is a definition that each
team / project group will define as to what they consider
as being “Done” for that particular sprint, iteration, or
release.
 It may be something as simple as “all unit tests must pass”

Task 2: Preparing Your Proposal
 Develop a Project Proposal using the template provided in eConestoga for this week.
 Due on Friday at the end of the Lab
 One submission per group / team
 Worth 5% of your overall project mark – deductions will apply for any late / absentees
 Need to include:
 Project Background and Description
 Problem Statement
 Project Scope
 High-Level Requirements
 Materials, Tools Required
 References Used

PROG8060_Lesson02_DebuggingRNHEdits.pptx

More Related Content

Similar to PROG8060_Lesson02_DebuggingRNHEdits.pptx

Recently uploaded

PROG8060_Lesson02_DebuggingRNHEdits.pptx

Editor's Notes