3.

Software Modeling and Design

3.1Translating Requirement model into design model: Data Modelling.

3.2Analysis Modeling: Elements of Analysis model.

3.3 Design Modeling: Fundamental Design Concepts (Abstraction, Information

hiding, Structure, Modularity, Concurrency, Verification, Aesthetics).

3.4 Design notations: Data Flow Diagram (DFD), Structured Flowcharts, Decision
Tables.

3.5 Testing — Meaning and purpose, testing methods - Black-box and White-box,
Level of testing — Unit testing.

3.6 Test Documentation — Test Case Template, test plan, Introduction to defect
report, test summary report.
3.1Translating Requirement model into design model
Each element of the analysis model provides information
that is necessary to create the four design models

The data/class design transforms analysis classes into
design classes along with the data structures required to
implement the software

The architectural design defines the relationship between
major structural elements of the software; architectural
styles and design patterns help achieve the requirements
defined for the system

The interface design describes how the software
communicates with systems that interoperate with it and
with humans that use it

The component-level design transforms structural
elements of the software architecture into a procedural
description of software components
Three characteristics for the evaluation of good
design:-
1. The design must implement all of the explicit
requirements contained in the analysis
model,and it must include all of the implicit
requirement desired by the customer.
2. Design must be readable and understandable
to everyone.
3. The design need to give complete idea or
picture of s/w, addressing the data ,
functional, behavioral domain.
Design quality guidelines
1.A design should show architecture i.e. developed
with the help of understandable patterns, styles,
components that are having characteristics of good
design.
2.A design should be modular. Because of that s/w
can be partitioned logically into elements.
3.A design should contain different representation of
components ,interfaces , architectures and data.
4.A design should have appropriate classes and data
structures to be implemented,sourced from
recognizable data patterns.
5. A design should lead to components that
exhibits independent functional characteristics.
6. A design should lead to interfaces that reduce
the complexity of connection between
components and with the external
environment.
7. A design should be derived using a repeatable
method that is driven by information obtained
during analysis.
8. Design should be presented using a notation
that effectively communicates its meaning.
 Objective of Analysis Modeling
1. To State clearly what customer wants exactly.

2. To establish base for design model.

• Importance of analysis modeling:
1.Designing gets easier to the designer
2.Better understanding of system can be
accomplished
3.Defines data objects
4.Describes data attributes
5.Establishes data relationships
6.Identifies functions that transform data objects
7.Indicates different states of the system
8. Relates a functional hierarchy represent
behavior at different levels of detail
3.2 Elements of analysis model:

1. Flow-oriented modeling
2. Scenario-based modeling
3. Class-based modeling
4. Behavioral modeling
• Flow-oriented modeling – provides an indication
of how data objects are transformed by a set of
processing functions.

• Scenario-based modeling – represents the system

from the user's point of view.

• Class-based modeling – defines objects, attributes,

and relationships.

• Behavioral modeling – depicts the states of the

classes and the impact of events on these states.
• 3.3 Design Modeling: Fundamental Design
Concepts (Abstraction, Information hiding,
Structure, Modularity, Concurrency,
Verification, Aesthetics).
3.4 Design notations: Data Flow Diagram (DFD),
Structured Flowcharts, Decision Tables.

• A design notation allows designers to

communicate the end results of a program
without having to use formal code for that task.
• A flow chart is a commonly used design
notation.
• Types of Design Notation
1. DFD (Data Flow diagram)
2. Structured Flowchart
3. Decision Table
• DFD is the abbreviation for Data Flow Diagram.
The flow of data of a system or a process is
represented by DFD.
• It also gives insight into the inputs and outputs of
each entity and the process itself.
• Data Flow diagrams are very popular because they
help us to visualize the major steps and data
involved in software-system processes.
• Components of DFD
The Data Flow Diagram has 4 components:
• Process
Input to output transformation in a system takes
place because of process function.
• The symbols of a process are rectangular with
rounded corners, oval, rectangle or a circle.
• A circle (bubble) shows a process that transforms
data inputs into data outputs.
• Data Flow
Data flow describes the information
transferring between different parts of the
systems.
• The arrow symbol is the symbol of data flow.
• A relatable name should be given to the flow
to determine the information which is being
moved.
• A given flow should only transfer a single
type of information.
• Warehouse
The data is stored in the warehouse for later use.
Two horizontal lines represent the symbol of the
store.
• The warehouse is simply not restricted to being a
data file rather it can be anything like a folder with
documents, an optical disc, a filing cabinet.
• When the data flow from the warehouse it is
considered as data reading and when data flows to
the warehouse it is called data entry or data
updation.
• Terminator
The Terminator is an external entity that stands
outside of the system and communicates with the
system.
• It can be, for example, organizations like banks,
groups of people like customers or different
departments of the same organization, which is
not a part of the model system and is an external
entity. Modeled systems also communicate with
terminator.
Rules for creating DFD
• The name of the entity should be easy and understandable
without any extra assistance(like comments).
• The processes should be numbered or put in ordered list to
be referred easily.
• The DFD should maintain consistency across all the DFD
levels.
• A single DFD can have maximum processes upto 9 and
minimum 3 processes.
• Levels of DFD
Levels of DFD are as follows:
• 0-level DFD
• 1-level DFD:
• 2-level DFD:
• 0-level DFD: 
It is also known as a context diagram. It’s
designed to be an abstraction view, showing the
system as a single process with its relationship to
external entities.
• It represents the entire system as a single bubble
with input and output data indicated by
incoming/outgoing arrows. 
• 1-level DFD: 
In 1-level DFD, the context diagram is
decomposed into multiple bubbles/processes.

• In this level, we highlight the main functions of

the system and breakdown the high-level process
of 0-level DFD into subprocesses. 
• 2-level DFD: 
2-level DFD goes one step deeper into parts of 1-
level DFD.

• It can be used to plan or record the

specific/necessary detail about the system’s
functioning. 
• 3.5 Testing — Meaning and purpose, testing
methods - Black-box and White-box, Level of
testing — Unit testing.
Definition :-
“Testing is the process of executing a program with
the intent of finding errors”.

“Software testing is an activity to check whether

the actual results match the expected results and
to ensure that the software system is defect free.”

“Software testing is a process used to identify the

correctness, completeness, and quality of
developed computer software.”
 TESTING OBJECTIVE
A. Finding defects which may get created by the
programmer while developing the software.

B. To check whether the program is giving the

expected output as per input specification.

C. To check whether the flow of coding is correct.

D. To check out the errors of the program.

 Software Testing Methods
• Black-box

• White-box
 White Box Testing 
• White Box Testing is software testing technique
in which internal structure, design and coding of
software are tested to verify flow of input-output
and to improve design, usability and security.
• In white box testing, code is visible to testers so it
is also called Clear box testing, Open box testing,
Transparent box testing, Code-based testing and
Glass box testing.
• White box testing in software engineering is based
on the inner workings of an application and
revolves around internal testing.
What do you verify in White Box Testing?
• White box testing involves the testing of the
software code for the following:
• Broken or poorly structured paths in the coding
processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on
an individual basis
• White box software testing has three basic steps: prepare
for testing, create and execute tests, and create the final
report.
• Step 1: Prepare
• Preparation is the first step in the white box software
testing technique. It involves learning and understanding
the internal workings of the target application.
• Performing successful white box software testing requires
the tester to have in-depth knowledge of the inner
functionalities powering the application.
Step 2: Create and execute tests
• After understanding how the application works
internally, the tester then creates tests and executes
them.

• Step 3: Create the final report

• In the last stage, the tester creates a report that
communicates the results of the entire testing
process. The report should be provided in a format
that is easy to understand, give a detailed description
of the testing activity, and summarize the outputs of
the testing tasks.
White Box Testing Tools
• Below is a list of top white box testing tools.
• Parasoft Jtest
• EclEmma
• NUnit
• PyUnit
• HTMLUnit
• CppUnit
 Black Box Testing
• Black Box Testing is a software testing method
in which the functionalities of software
applications are tested without having knowledge
of internal code structure, implementation details
and internal paths.
• Black Box Testing mainly focuses on input and
output of software applications and it is entirely
based on software requirements and
specifications.
• It is also known as Behavioral Testing.
• The above Black-Box can be any software system
you want to test. For Example, an operating
system like Windows, a website like Google, a
database like Oracle or even your own custom
application.
• Under Black Box Testing, you can test these
applications by just focusing on the inputs and
outputs without knowing their internal code
implementation.
• Types of Black Box Testing
• Functional testing – This black box testing type is
related to the functional requirements of a system;
it is done by software testers.
• Non-functional testing – This type of black box
testing is not related to testing of specific
functionality, but non-functional requirements such
as performance, scalability, usability.
• Regression testing – Regression Testing is done
after code fixes, upgrades or any other system
maintenance to check the new code has not
affected the existing code.
• Tools used for Black Box Testing:
• Tools used for Black box testing largely depends
on the type of black box testing you are doing.
• For Functional/ Regression Tests you can use – 
QTP, Selenium
• For Non-Functional Tests, you can use – 
LoadRunner, Jmeter
 Levels of Testing 
•  In general, there are four levels of testing: unit
testing, integration testing, system testing, and
acceptance testing.
• The purpose of Levels of testing is to make
software testing systematic and easily identify all
possible test cases at a particular level.
• Unit Testing : checks if software components
are fulfilling functionalities or not.
• Integration Testing : checks the data flow
from one module to other modules.
• System Testing : evaluates both functional and
non-functional needs for the testing.
• Acceptance Testing : checks the requirements
of a specification or contract are met as per its
delivery.
 Unit Testing
 Unit Testing is a level of the software testing process where
individual units/components of a software/system are
tested.

 The goal of unit testing is to isolate each part of the

program and show that the individual parts are correct.

 A unit is the smallest testable part of software.

 It usually has one or a few inputs and usually a single

output.
 In procedural programming a unit may be an
individual program, function, procedure, etc.

 In many application a driver is known as “Main

program” that takes i/p from test case data & also
pass that data to component that need to be tested.

 Stubs are subprograms that are called by driver.

Aspects to be tested in Unit Testing
1. Interface:

 Interface is tested to ensure that information

properly flows into and out of the program unit .

 If data do not enter and exit properly, all other

tests are suffering lot of problems.

2.Local data structure: It check the integrity of

data structure.
3. Boundary conditions: Boundary conditions are
tested to ensure that the module operates properly at
boundaries

4. Independent paths: All independent paths (basis

paths) through the control structure are exercised to
ensure that all statements in a module have been
executed at least once.
5.Error-handling paths: All error handling
paths are tested so as to ensure that the error
are handled properly without causing system
failure and the appropriate message is shown
to user.
 Advantages of Unit Testing

1. we can tests any parts of project without waiting

for others to be completed.

2. Developers can learn what functionality is

provided by a unit and how to use it.

3. programmer can restructuring code at a later date,

and make sure the module still works correctly.
• Integration means combining. For Example, In this
testing phase, different software modules are combined
and tested as a group to make sure that integrated system
is ready for system testing.
• Integrating testing checks the data flow from one module
to other modules. This kind of testing is performed by
testers.
• As displayed in the image below when two different
modules ‘Module A’ and ‘Module B’ are integrated then
the integration testing is done.
3) System testing:
• System testing is performed on a complete, integrated system.
It allows checking system’s compliance as per the
requirements. It tests the overall interaction of components. It
involves load, performance, reliability and security testing.
• System testing most often the final test to verify that the
system meets the specification. It evaluates both functional
and non-functional need for the testing.

4) Acceptance testing:
• Acceptance testing is a test conducted to find if the
requirements of a specification or contract are met as per its
delivery. Acceptance testing is basically done by the user or
customer. However, other stockholders can be involved in this
process.
 3.6 Test Documentation
• Test Case Template
• Test plan
• Introduction to defect report
• Test summary report.
• Test documentation is documentation of artifacts
created before or during the testing of software.

• It helps the testing team to estimate testing effort

needed, test coverage, resource tracking, execution
progress, etc.

• It is a complete suite of documents that allows you

to describe and document test planning, test
design, test execution, test results that are drawn
from the testing activity.
 Types of Test Documentation
Test Case Template

• A test case template is a document containing an organized

list of test cases for different test scenarios that check
whether or not the software has the intended functionality.

• A test case is a set of steps carried out to test a specific

feature of an application.

• Other than the executable steps, a test case also contains

preconditions for testing, test data provided, expected
outcome, and actual result. A tester can judge the success of
a test case by comparing its expected and actual results.
Test Case
• The test case is defined as a group of conditions
under which a tester determines whether a software
application is working as per the customer's
requirements or not.
• Test case designing includes preconditions, case
name, input conditions, and expected result.
• A test case is a first level action and derived from
test scenarios.
Typical Test Case Parameters:
• Test Case ID
• Test Scenario
• Test Case Description
• Test Steps
• Prerequisite
• Test Data
• Expected Result
• Actual Result
• Environment Information
• Comments (TC Pass or Fail)
• Example:
• Let us say that we need to check an input field that
can accept maximum of 10 characters.

• While developing the test cases for the above

scenario, the test cases are documented the
following way.

• In the below example, the first case is a pass

scenario while the second case is a FAIL.
• If the expected result doesn't match with the actual
result, then we log a defect.
• The defect goes through the defect life cycle and
the testers address the same after fix.
 Test Plan

• A Test Plan is a detailed document that describes the test

strategy, objectives, schedule, estimation, deliverables, and
resources required to perform testing for a software product.
• Test Plan helps us determine the effort needed to validate
the quality of the application under test.
• 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.
• As per ISTQB definition: “Test Plan is A document
describing the scope, approach, resources, and schedule of
intended test activities.”
• Why are Test Plans important?
• They help individuals outside the QA teams
(developers, business managers, customer-facing
teams) understand exactly how the website or app
will be tested.
• They offer a clear guide for QA engineers to
conduct their testing activities.
• They detail aspects such as test scope, test
estimation, strategy, and so on. Collating all this
information into a single document makes it
easier to review by management personnel or to
re-use for other projects.
Components of a Test Plan
• Scope: Details the objectives of the particular
project. Also, it details user scenarios to be used in
tests. If necessary, the scope can specify what
scenarios or issues the project will not cover.
• Schedule: Details start dates and deadlines for
testers to deliver results.
• Resource Allocation: Details which tester will work
on which test.
• Environment: Details the nature, configuration, and
availability of the test environment.
• Tools: Details what tools are to be used for testing,
bug reporting, and other relevant activities.
• Defect Management: Details how bugs will be
reported, to whom and what each bug report needs to
be accompanied by. For example, should bugs be
reported with screenshots, text logs, or videos of their
occurrence in the code?
• Risk Management: Details what risks may occur
during software testing, and what risks the software
itself may suffer if released without sufficient testing.
• Exit Parameters: Details when testing activities must
stop. This part describes the results that are expected
from the QA operations, giving testers a benchmark to
compare actual results to.
 Introduction to Defect Report
• Defect:
A defect in a software product is also known as a bug, error
or fault which makes the software produce an unexpected
result as per the software requirements. For example;
incorrect data, system hangs, unexpected errors, missing or
incorrect requirements.  

Defect Report is a detailed document about bugs found in the

software application.

Defect report contains each detail about Defect like

description, date when Defect was found, name of tester who
found it, name of developer who fixed it, etc.
• A typical defect report contains the information in an xls Sheet
as follows.  
1. Defect ID :
Nothing but a serial number of defects in the report.  
2. Defect Description :
A short and clear description of the defect detected.  
3. Action Steps :
What the client or QA did in an application that results in the
defect. Step by step actions they took.  
4. Expected Result :
What results are expected as per the requirements when
performing the action steps mentioned.  
5. Actual Result :
What results are actually showing up when performing the action
steps.  
6. Severity : Means impact of defect on application , Severity may be
Low, Medium , High.

7. Attachments :
A sequence of screenshots of performing the step by step actions and
getting the unexpected result. One can also attach a short screen
recording of performing the steps and encountering defects. Short
videos help developers and/or QA to understand the bugs easily and
quickly.

8. Additional information :
The platform you used, operating system and version. And other
information which describes the defects in detail for assisting the
developer understand the problem and fixing the code for getting
desired results. 
Test Summary Report
• Test Report is a document which contains a summary
of all test activities and final test results of a testing
project.
• Test report is an assessment of how well the Testing is
performed. Based on the test report, test manager can
evaluate the quality of the tested product and make a
decision on the software release.
• For example, if the test report informs that there are
many defects remaining in the product, test manager
can delay the release until all the defects are fixed.
• Test Summary
• This section includes the summary of testing
activity in general. Information detailed here
includes
• The number of test cases executed
• The numbers of test cases pass
• The numbers of test cases fail
• Pass percentage
• Fail percentage