Program Design

Overview
Program design consists of the steps a programmer should do before they start coding the
program in a specific language. These steps when properly documented will make the completed
program easier for other programmers to maintain in the future. There are three broad areas of
activity:

 Understanding the Program

 Using Design Tools to Create a Model
 Develop Test Data

Understanding the Program

If you are working on a project as one of many programmers, the system analyst may have
created a variety of documentation items that will help you understand what the program is to do.
These could include screen layouts, narrative descriptions, documentation showing the
processing steps, etc. If you are not on a project and you are creating a simple program you
might be given only a simple description of the purpose of the program. Understanding the
purpose of a program usually involves understanding its:

 Inputs
 Processing
 Outputs

This IPO approach works very well for beginning programmers. Sometimes, it might help to
visualize the program running on the computer. You can imagine what the monitor will look
like, what the user must enter on the keyboard and what processing or manipulations will be
done.

Using Design Tools to Create a Model

At first, you will not need a hierarchy chart because your first programs will not be complex. But
as they grow and become more complex, you will divide your program into several modules (or
functions).

The first modeling tool you will usually learn is pseudocode. You will document the logic or
algorithm of each function in your program. At first, you will have only one function, and thus
your pseudocode will follow closely the IPO approach above.

There are several methods or tools for planning the logic of a program. They include:
flowcharting, hierarchy or structure charts, pseudocode, HIPO, Nassi-Schneiderman charts,
Warnier-Orr diagrams, etc. Programmers are expected to be able to understand and do
flowcharting and pseudocode. These methods of developing the model of a program are usually
taught in most computer courses. Several standards exist for flowcharting and pseudocode and
most are very similar to each other. However, most companies have their own documentation
standards and styles. Programmers are expected to be able to quickly adapt to any flowcharting
or pseudocode standards for the company at which they work. The other methods that are less
universal require some training which is generally provided by the employer that chooses to use
them.

Later in your programming career, you will learn about using application software that helps
create an information system and/or programs. This type of software is called Computer-Aided
Software Engineering (CASE).

Understanding the logic and planning the algorithm on paper before you start to code is a very
important concept. Many students develop poor habits and skipping this step is one of them.

Develop Test Data

Test data consists of the programmer providing some input values and predicting the outputs.
This can be quite easy for a simple program and the test data can be used to check the model to
see if it produces the correct results.
Introduction- fundamental design concepts

The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved. They
are as follows:

1. Abstraction - Abstraction is the process or result of generalization by reducing the

information content of a concept or an observable phenomenon, typically in order to
retain only information which is relevant for a particular purpose.
2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a
macroscopic statement of function in a step-wise fashion until programming language
statements are reached. In each step, one or several instructions of a given program are
decomposed into more detailed instructions. Abstraction and Refinement are
complementary concepts.
3. Modularity - Software architecture is divided into components called modules.
4. Software Architecture - It refers to the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system. Good software
architecture will yield a good return on investment with respect to the desired outcome of
the project, e.g. in terms of performance, quality, schedule and cost.
5. Control Hierarchy - A program structure that represents the organization of a program
component and implies a hierarchy of control.
6. Structural Partitioning - The program structure can be divided both horizontally and
vertically. Horizontal partitions define separate branches of modular hierarchy for each
major program function. Vertical partitioning suggests that control and work should be
distributed top down in the program structure.
7. Data Structure - It is a representation of the logical relationship among individual
elements of data.
8. Software Procedure - It focuses on the processing of each module individually.
9. Information Hiding - Modules should be specified and designed so that information
contained within a module is inaccessible to other modules that have no need for such
information.
In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularisation, and
Hierarchy as fundamental software design principles. The acronym PHAME (Principles of
Hierarchy, Abstraction, Modularisation, and Encapsulation) is sometimes used to refer to these
four fundamental principles.
Modules and Modularization
 Modular design, or "modularity in design", is a design approach that subdivides a system
into smaller parts called modules.
 That can be independently created and then used in different systems.
 A modular system can be characterized by functional partitioning into discrete scalable.
 Besides reduction in cost (due to less customization, and shorter learning time), and
flexibility in design,
 Modularity offers other benefits such as augmentation (can increase size)
 Examples of modular systems are cars, computers, process systems, solar panels and
wind turbines, elevators and modular buildings.
 Earlier examples include railroad signaling systems, telephone exchanges, pipe organs
and electric power distribution systems.
 Computers use modularity to overcome changing customer demands and to make the
manufacturing process more adaptive to change (see modular programming).

Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s) independently.
These modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.
Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.

Advantage of modularization:

 Smaller components are easier to maintain

 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
Design notation
Design Notations are primarily meant to be used during the process of design and are used to
represent design or design decisions. For a function-oriented design, the design can be
represented graphically or mathematically by the following:

Data Flow Diagram

Data-flow design is concerned with designing a series of functional transformations that convert
system inputs into the required outputs. The design is described as data-flow diagrams. These
diagrams show how data flows through a system and how the output is derived from the input
through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They
show end-to-end processing. That is the flow of processing from when data enters the system to
where it leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.
The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named entities in a data-flow
diagram. The user inputs the name of the design represented by the diagram. The report
generator then finds all the names used in the data-flow diagram. It looks up a data dictionary
and retrieves information about each name. This is then collated into a report which is output by
the system.

Data Flow Diagram Example

Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The data items
listed contain all data flows and the contents of all data stores looking on the DFDs in the DFD
model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may
contain that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

 A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential since,
in large projects, different engineers of the project tend to use different terms to refer to
the same data, which unnecessarily causes confusion.
 The data dictionary provides the analyst with a means to determine the definition of
various data structures in terms of their component elements.

Structured Charts

It partitions a system into block boxes. A Black box system that functionality is known to the
user without the knowledge of internal design.

Structured Chart is a graphical representation which shows:

 System partitions into modules

 Hierarchy of component modules
 The relation between processing modules
  Interaction between modules
 Information passed between modules

The following notations are used in structured chart:

Examples of flowchart:
The various examples of the flowchart are given below:

Example 1:

Design a flowchart for adding two numbers entered by the user.

Example 2:

Design a flowchart for finding the largest among three numbers entered by the user.
Example 3:

Design a flowchart for calculating the profit and loss according to the value entered by the user.
Example 4:

Draw a flowchart to calculate the average of two numbers.

Example 5:

Design a flowchart for the multiplication of three numbers entered by the user.
Example 6:

Design a flowchart for calculating the area of a rectangle.

Example 7:

Design a flowchart for calculating the Simple Interest according to the value entered by the user.
Example 8:

Design a flowchart for checking whether the number is positive or negative according to the
number entered by the user.
Pseudo-code

Pseudo-code notations can be used in both the preliminary and detailed design phases. Using
pseudo-code, the designer describes system characteristics using short, concise, English
Language phases that are structured by keywords such as If-Then-Else, While-Do, and End.

Examples:

1.. If student's grade is greater than or equal to 60

Print "passed"
else
Print "failed"

2. Set total to zero

Set grade counter to one

While grade counter is less than or equal to ten

Input the next grade

Add the grade into the total

Set the class average to the total divided by ten

Print the class average.

3.

Initialize total to zero

Initialize counter to zero

Input the first grade

while the user has not as yet entered the sentinel

add this grade into the running total

add one to the grade counter
input the next grade (possibly the sentinel)

if the counter is not equal to zero

 set the average to the total divided by the counter
print the average

else

print 'no grades were entered'

Tables
A decision table is a good way to deal with combinations of things (e.g. inputs). This technique
is sometimes also referred to as a ’cause-effect’ table. The reason for this is that there is an
associated logic diagramming technique called ’cause-effect graphing’ which was sometimes
used to help derive the decision table (Myers describes this as a combinatorial logic network
[Myers, 1979]). However, most people find it more useful just to use the table described in
[Copeland, 2003].

 Decision tables provide a systematic way of stating complex business rules, which is
useful for developers as well as for testers.
 Decision tables can be used in test design whether or not they are used in specifications,
as they help testers explore the effects of combinations of different inputs and other
software states that must correctly implement business rules.
 It helps the developers to do a better job can also lead to better relationships with them.
Testing combinations can be a challenge, as the number of combinations can often be
huge. Testing all combinations may be impractical if not impossible. We have to be
satisfied with testing just a small subset of combinations but making the choice of which
combinations to test and which to leave out is also important. If you do not have a
systematic way of selecting combinations, an arbitrary subset will be used and this may
well result in an ineffective test effort.

Why Decision table is important?

Decision tables are very much helpful in test design technique – it helps testers to search the
effects of combinations of different inputs and other software states that must correctly
implement business rules. Also, provides a regular way of stating complex business rules, that’s
helpful for developers as well as for testers. Testing combinations can be a challenge, as the
number of combinations can often be huge. It assists in development process with developer to
do a better job. Testing with all combination might be unrealistic or unfeasible. We have to be
happy with testing just a small subset of combinations but making the option of which
combinations to test and which to leave out is also significant. If you do not have a efficient way
of selecting combinations, an arbitrary subset will be used and this may well result in an
ineffective test effort.
A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with complex
business rules. Also, used in model complicated logic.
Way to use decision tables in test designing
Firstly; get to know a suitable function or subsystem that acts according to a combination of
inputs or events. Taken system should be with fewer inputs or else combinations will become
impossible. Always better to take maximum numbers of conditions, split them into subsets and
use these subsets one at a time. After getting features that need to be combined, add them to a
table showing all combinations of “Yes” and “No” for each of the feature.
Let’s take an example of a finance application, where users pay money – monthly Repayment or
year wise (the term of loan). If user chooses both options, the system will create a negotiation
between two. So, there are two conditions of the loan amount, mention in the given below table,

TABLE 1: Blank decision table

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has

been mentioned

Terms of loan has been

mentioned

Next, recognize all of the combinations in “Yes” and “No” (In Table 2). In each column of two
conditions mention “Yes” or “No”, user will get here four combinations (two to the power of the
number of things to be combined). Note, if user has three things to combine, they will have eight
combinations, with four things, there are 16, etc. Because of this, it’s always good to take small
sets of combinations at once. To keep track on combinations, give alternate “Yes” and “No” on
the bottom row, put two “Yes” and then two “No” on the row above the bottom row, etc., so the
top row will have all “Yes” and then all “No” (Apply the same principle to all such tables).

TABLE 2: Decision table – Input combination

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

In the next step, recognize the exact outcome for each combination (In Table 3). In this example,
user can enter one or both of the two fields. Each combination is sometimes referred to as a step.

TABLE 3: Decision table – Combinations and outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes
Process loan money Y Y

Process term Y Y

At this time you didn’t think that what will happen when customer don’t enter anything in either
of the two fields. The table has shown a combination that was not given in the specification for
this example. This combination can result as an error message, so it is necessary to add another
action (In Table 4). This will flash the strength this method to find out omissions and ambiguities
in specifications.

TABLE 4: Decision table – Additional outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes

Process loan money Y Y

Process term Y Y

Error message Y

We will provide you some other example that allows the customer to enter both repayment and
term. This will change the outcome of our table, this will generate an error message if both are
entered (Shown in Table 5).

TABLE 5: Decision table – Changed outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes

Process loan money Y

Process term Y

Error message Y Y

The final process of this method is to write test cases to use each of the four steps in our table.
Stepwise refinement - Levels of abstraction (bottom-up
design)
The next process is what is called stepwise refinement or decomposition. Rather than leaving
step 1 as “walk to paper”, we need to be more clear than this. So, to break this step down with
stepwise refinement, we could say…

1. Walk to paper.
1a. Walk to wall
1b. turn right
1c. move
1d. turn left

As this program is relatively simple, I think it can be left at just the one breakdown. However,
more complicated programs will require that steps 1a, 1b, 1c, 1d and 1e are decomposed several
times.

For step 2 “pick it up”, the assignment says we can assume there will always be a paper there. To
be on the safe side, we might want to have a bit more detail here and put checks in place such as
using an if statement to check if a paper is present. Also, we could look here at pre-conditions
and post-conditions. We need to know where Karel will be after step 1 and where he needs to be
to start step 3. In the breakdown of “walk to paper” I decided to leave Karel at the inside of the
door facing out… so a pre-condition is that Karel needs to make 1 move to the paper. A post-
condition I will set is for Karel is that he has returned to inside the house facing west which
means we need to remember that as a pre-condition for step 3… returning to the start.

Breaking down part 2:

2. Pick it up

2a. Move to paper

2b. Check if paper available
2c. pick up paper
2d. turn around
2e. move (leave facing west)
Now we know that Karel is in the house, facing west we can break down step 3 as follows:

3. Return back to the start

3a. move to wall
3b. turn right
3c. move to wall

I decided to tackle point 3 a different way. Instead of sending Karel back to the couch the same
way he came in… along the top and right wall. I decided to make him simply continue west till
he hits the wall, then turn right and then move to the top wall.

Levels of Abstraction: Levels of abstraction was originally described by in a bottom-up design

technique. In this system each level of abstraction is composed of a group of related functions,
some of which are externally visible and some of which are internal to the level. Internal
functions are hidden from other levels; they can only be invoked by functions on the same level.
The internal functions are used to perform tasks common to the work being performed on that
level of abstraction. Each level of abstraction performs a set of services for the functions on the
next higher level of abstraction.

Example

Problem: Print the count and average of a sequence of positive integers

 Initial Solution:
1. Initialize data
2. Get data
3. Calculate results
4. Output results
 Refinement:
1. Initialize data
2. get data
 2.1 loop
 2.2 get integer x
 2.3 exit when x < 1
 2.4 process x
3. Calculate results
 3.1 avg = sum / count
4. Output results

 Further refinement (of step 2.4):

o 2.4.1 increase count by 1
 o 2.4.2 increase sum by x
 Process of refinement is complete when all steps can be easily programmed
Top-down design
Now that you know what you need to accomplish with your program, you now need to
knowhow you can accomplish it. The approach used to do that is called top-down design and
this simply means putting all the important main parts of the program in to a list.

An example I want to use is from a Karel world. In this example, Karel needs to collect the
beeper (which is called a newspaper in the assignment). The assignment states that Karel’s
world doesn’t change and that the door is always where it is and the paper is always on point
6,3 and that when collected, Karel needs to return back to the start.

A top-down design approach could go something like this:

1. Walk to paper.
2. Pick it up.
3. Return back to start.

This is our top level that describes what needs to be done in the most basic form. I guess we
could start at an even higher level and simply say “Collect paper”, but programming
problems can be tackled in many ways and the way above is simply the way I have decided
to do it.
Test plans-Design guidelines
What is a Test Plan?
A test plan is a detailed document that outlines the test strategy, Testing objectives, resources
(manpower, software, hardware) required for testing, test schedule, test estimation and test
deliverables.
The test plan serves as a blueprint to conduct software testing activities as a defined process
which is minutely monitored and controlled by the test manager.

Let’s start with following scenario

In a meeting, you want to discuss the Test Plan with the team members, but they are not
interested - .

Importance of Test Plan

Making Test Plan has multiple benefits

 Test Plan helps us determine the effort needed to validate the quality of the application
under test
 Help people outside the test team such as developers, business managers,
customers understand the details of testing.
 Test Plan guides our thinking. It is like a rule book, which needs to be followed.
 Important aspects like test estimation, test scope, test strategy are documented in Test
Plan, so it can be reviewed by Management Team and re-used for other projects.

How to write a Test Plan

You already know that making a Test Plan is the most important task of Test Management
Process. Follow the seven steps below to create a test plan as per IEEE 829

1. Analyze the product

2. Design the Test Strategy
3. Define Test Criteria
4. Define the Test Objectives
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables
Step 1) Analyze the product
How can you test a product without any information about it? The answer is Impossible. You
must learn a product thoroughly before testing it.
The product under test is Guru99 banking website. You should research clients and the end users
to know their needs and expectations from the application

 Who will use the website?

 What is it used for?
 How will it work?
 What are software/ hardware the product uses?

Step 2) Develop Test Strategy

Test Strategy is a critical step in making a Test Plan. A Test Strategy document, is a high-level
document, which is usually developed by Test Manager. This document defines:

 The project’s testing objectives and the means to achieve them

  Determines testing effort and costs

Step 3) Define Test Objective

Test Objective is the overall goal and achievement of the test execution. The objective of the
testing is finding as many software defects as possible; ensure that the software under test is bug
freebefore release.
To define the test objectives, you should do 2 following steps

1. List all the software features (functionality, performance, GUI…) which may need to test.
2. Define the target or the goal of the test based on above features

Step 4) Define Test Criteria

Test Criteria is a standard or rule on which a test procedure or test judgment can be based.
There’re 2 types of test criteria as following

Suspension Criteria
Specify the critical suspension criteria for a test. If the suspension criteria are met during testing,
the active test cycle will be suspended until the criteria are resolved.

Step 5) Resource Planning

Resource plan is a detailed summary of all types of resources required to complete project task.
Resource could be human, equipment and materials needed to complete a project
The resource planning is important factor of the test planning because helps
in determining the number of resources (employee, equipment…) to be used for the project.
Therefore, the Test Manager can make the correct schedule & estimation for the project.

Step 6) Plan Test Environment

What is the Test Environment

A testing environment is a setup of software and hardware on which the testing team is going to
execute test cases. The test environment consists of real business and user environment, as well
as physical environments, such as server, front end running environment.

Step 7) Schedule & Estimation

In the article Test estimation, you already used some techniques to estimate the effort to
complete the project. Now you should include that estimation as well as the schedule to the Test
Planning
In the Test Estimation phase, suppose you break out the whole project into small tasks and add
the estimation for each task as below

Task Members Estimate effort

Create the test specification Test Designer 170 man-hour

Perform Test Execution Tester, Test Administrator 80 man-hour

Test Report Tester 10 man-hour

Test Delivery 20 man-hour

280 man-hour
Total

Step 8) Test Deliverables

Test Deliverables is a list of all the documents, tools and other components that has to be
developed and maintained in support of the testing effort.
There are different test deliverables at every phase of the software development lifecycle.

Test deliverables are provided before testing phase.

 Test plans document.

 Test cases documents
 Test Design specifications.

Test deliverables are provided during the testing

 Test Scripts
 Simulators.
 Test Data
 Test Traceability Matrix
 Error logs and execution logs.
Test deliverables are provided after the testing cycles is over.

 Test Results/reports
 Defect Report
 Installation/ Test procedures guidelines
 Release notes