Software Engineering

Dr. Saba Bashir

 Scenario-based Modeling

1
Todays’ Lecture
• Use Case
• Use Case Diagram
• Use Case Diagram Notations
• Benefits of Use Case Diagram
• Draw Use Case Diagram
• Structuring Use Cases
• Use Case Diagram Examples
• UML Tools
• Use Case – Tabular Form
2
Use Case
• A use case describes how a user uses a system to
accomplish a particular goal.
• A use case is a list of actions or event steps typically
defining the interactions between a role of an actor and a
system to achieve a goal.
• A use case is a useful technique for identifying, clarifying,
and organizing system requirements.
• A use case is made up of a set of possible sequences of
interactions between systems and users that defines the
features to be implemented and the resolution of any errors
that may be encountered.
3
Use Case
• A use case (or set of use cases) has these characteristics:
1. Organizes functional requirements
2. Models the goals of system/actor (user) interactions
3. Describes one main flow of events (main scenarios)
and possibly other exceptional flows (alternatives),
also called paths or user scenarios

4
Use Case Diagram
• A use case diagram consists of the system, the
related use cases and actors and relates these to
each other to visualize:
• what is being described? (system),
• who is using the system? (actors) and
• what do the actors want to achieve? (use cases),
• Thus, use cases help ensure that the correct system
is developed by capturing the requirements from
the user's point of view.
5
Use Case Diagram
• A use-case diagram can help provide a higher-level
view of the system, providing the simplified and
graphical representation of what the system must
actually do.

6
Use Case Diagram – Example

7
Use Case Diagram – Notations
• A use case diagram contains four main
components
• Actor
• Use Case
• Relationship
• System Boundary

8
Use Case Diagram – Notations
• Actor
• Actors are usually individuals involved with the system defined
according to their roles.
• The actor can be a human or other external system.

• Use Case
• A use case describes how actors uses a system to accomplish a
particular goal.
• Use cases are typically initiated by a user to fulfill goals
describing the activities and variants involved in attaining the
goal. 9
Use Case Diagram – Notations
• Relationship
• The relationships between and among the actors and the use
cases.

• System Boundary
• The system boundary defines the system of interest in
relation to the world around it.

10
Use Case Diagram – Notations

11
Use Case Diagram - Benefits
• Use cases is a powerful technique for the elicitation and
documentation of black-box functional requirements.
• Because, use cases are easy to understand and provide an
excellent way for communicating with customers and users
as they are written in natural language.
• Use cases can help manage the complexity of large
projects by partitioning the problem into major user
features (i.e., use cases) and by specifying applications
from the users' perspective.

12
Use Case Diagram - Benefits
• Use cases provide a good basis to link between the
verification of the higher-level models (i.e. interaction
between actors and a set of collaborative objects), and
subsequently, for the validation of the functional
requirements (i.e. blueprint of white-box test).
• Use case driven approach provides an traceable links for
project tracking in which the key development activities
such as the use cases implemented, tested, and delivered
fulfilling the goals and objectives from the user point of
views.

13
How to draw Use Case Diagram?
• A Use Case model can be developed by following the
steps below.
1. Identify the Actors (role of users) of the system.
2. For each category of users, identify all roles played by the
users relevant to the system.
3. Identify what are the users required the system to be
performed to achieve these goals.
4. Create use cases for every goal.
5. Structure the use cases.
6. Prioritize, review, estimate and validate the users.
14
Draw packages for logical categorization of use cases into
related subsystems.

15
Structuring Use Cases
• UML defines three stereotypes of association
between Use Cases
• <<include>> Use Case
• <<extend>> Use Case
• Abstract and generalized Use Case

16
<<include>> Use Case
• The time to use the <<include>> relationship is after you
have completed the initial description of all your main Use
Cases.
• You can now look at the Use Cases and identify common
sequences of user-system interaction.

17
<<extend>> Use Case
• An extending use case is, effectively, an alternate course of
the base use case.
• The <<extend>> use case accomplishes this by
conceptually inserting additional action sequences into the
base use-case sequence.

18
Abstract and Generalized Use Case
• The general use case is abstract.
• It can not be instantiated, as it contains incomplete
information.
• The title of an abstract use case is shown in italics.

19
Use Case Diagram - Examples
• This examples depicts a model of the
interactions between the system and their
primary actors.
• Restaurant
• Airport
• Bank ATM
• Document Management System

20
21
Use Case Diagram - Airport

22
Use Case Diagram – ATM

23
Use Case Diagram – Document Management System

24
UML Tools
• Microsoft Visio
• Visual Paradigm
• Visual Paradigm Online

25
Use Case Tabular Format - Template

26
Use Case Tabular Format - Example

27
28
29
End of Lecture

30
 Software Engineering
Dr. Saba Bashir

 Activity Diagram

1
Todays’ Lecture
• What is Activity Diagram?
• Objectives of Activity Diagram
• Where to use Activity Diagram?
• When to use Activity Diagram?
• Notations Summary
• Drawing an Activity Diagram
• Elements of an Activity Diagram
• Activity Diagrams Examples
• Activity Diagrams with Swimlanes 2
 Activity Diagram
• Activity diagram is another important diagram in UML to
describe dynamic aspects of the system.
• Activity diagram is essentially an advanced version of flow chart
that models the flow from one activity to another activity.
• The activity can be described as an operation of the system.
• The control flow is drawn from one operation to another.
• This flow can be sequential, branched, or concurrent.
• Activity diagrams deal with all type of flow control by using
different elements such as fork, join, etc.

3
 Objectives of Activity Diagram
• It captures the dynamic behavior of the system.
• Activity diagram is used to show message flow
from one activity to another.
• Activity is a specific operation of the system.
• It does not show any message flow from one
activity to another.

4
Where to use Activity Diagrams?
• The usage of activity diagram is to model the control flow
from one activity to another.
• This control flow does not include messages.
• Activity diagram is suitable for modeling the activity
flow of the system.
• An application can have multiple systems.
• Activity diagram also captures these systems and
describes the flow from one system to another.
• These systems can be database, external queues, or any
other system.
5
Where to use Activity Diagrams?
• An activity diagram is drawn from a very high level.
• It gives high level view of a system.
• This high level view is mainly for business users or any
other person who is not a technical person.
• This diagram is used to model the activities which are
business requirements.
• The diagram has more impact on business understanding
rather than on implementation details.

6
Where to use Activity Diagrams?
• Activity diagram can be used for
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's
functionalities.
• Investigating business requirements at a later stage.

7
When to use Activity Diagrams?
• Activity Diagrams describe how activities are coordinated
to provide a service which can be at different levels of
abstraction.
• Typically, an event needs to be achieved by some
operations, particularly where the operation is intended to
achieve a number of different things that require
coordination, or how the events in a single use case relate
to one another, in particular, use cases where activities
may overlap and require coordination.
• It is also suitable for modeling how a collection of use
cases coordinate to represent business workflows 8
Drawing an Activity Diagram
1. Identify candidate use cases, through the examination of
business workflows
2. Identify pre- and post-conditions (the context) for use
cases
3. Model workflows between/within use cases
4. Model complex workflows in operations on objects
5. Model in detail complex activities in a high level activity
diagram

9
Elements of an Activity Diagram?
• The main element of an activity diagram is the activity itself.
• An activity is a function performed by the system.
• After identifying the activities, we need to understand how they
are associated with constraints and conditions.
• Before drawing an activity diagram, we should identify the
following elements
• Activities
• Association
• Conditions
• Constraints 10
How to Draw an Activity Diagram?
• Once the above-mentioned parameters are
identified, we need to make a intellectual layout
of the entire flow.
• This layout is then transformed into an activity
diagram.

11
 Notations Summary
Activity Represents a set of actions

Control Shows the sequence of

Flow execution

Portrays the beginning of a

Initial Node
set of actions or activities

Final Node Stop all flows in an activity

12
 Notations Summary
Represent a test condition to
Decision
ensure that the flow goes
Node
down one path
Bring back different paths
Merge
that were created using
Node
decision node
Split behavior into a set of
Fork Node
parallel activities

Bring back together a set of

Join Node
parallel activities
13
 A
basic
Activity
Diagram

14
Activity Diagram - Modeling a Word Processor
• The activity diagram example below describes the workflow for
a word process to create a document through the following
steps:
• Open the word processing package.
• Create a file.
• Save the file under a unique name within its directory.
• Type the document.
• If graphics are necessary, open the graphics package, create the graphics,
and paste the graphics into the document.
• If a spreadsheet is necessary, open the spreadsheet package, create the
spreadsheet, and paste the spreadsheet into the document.
• Save the file.
• Print a hard copy of the document. 15
• Exit the word processing package
Activity
Diagram -
Modeling
a
Word
Processor
16
Activity Diagram Example - Process Order
• Given the problem description related to the workflow
for processing an order, let's model using an activity
diagram:
• Once the order is received, the activities split into two parallel
sets of activities. One side fills and sends the order while the
other handles the billing.
• On the Fill Order side, the method of delivery is decided
conditionally. Depending on the condition either the
Overnight Delivery activity or the Regular Delivery activity is
performed.
• Finally the parallel activities combine to close the order.
17
Activity
Diagram
Example
-
Process
Order
18
 Activity Diagram – Student Enrollment
• This UML activity diagram example describes a process
for student enrollment in a university as follows:
• An applicant wants to enroll in the university.
• The applicant hands a filled out copy of Enrollment Form.
• The registrar inspects the forms.
• The registrar determines that the forms have been filled out
properly.
• The registrar informs student to attend in university overview
presentation.
• The registrar helps the student to enroll in seminars
• The registrar asks the student to pay for the initial tuition. 19
Activity Diagram – Student Enrollment

20
Swimlane
• A swimlane is a way to group activities
performed by the same actor on an activity
diagram or activity diagram or to group activities
in a single thread.
• Here is an example of a swimlane activity
diagram for modeling Staff Expenses
Submission:

21
Swimlane Activity Diagram - Staff Expenses Submission

22
 Meeting
Client:
Non-
Swimlane
Activity
Diagram

23
 Meeting
Client:
Swimlane
Activity
Diagram

24
End of Lecture

25
 Software Engineering
Dr. Saba Bashir

 Data Flow Diagram

1
Todays’ Lecture
• Data Flow Diagram
• Why DFD?
• Symbols
• Process, Data Flow, Data Store, External Entity
• Top-Down Decomposition Techniques
• Logical vs Physical DFDs
• Benefits of Logical DFDs
• Benefits of Physical DFDs
• Example DFDs – Grocery Store
2
Data Flow Diagram

3
Data Flow Diagram
• Also known as DFD.
• Data flow diagrams are used to graphically
represent the flow of data in a business
information system.
• DFD describes the processes that are involved in
a system to transfer data from the input to the file
storage and reports generation.

4
Why DFD?
• DFD graphically representing the functions, or processes,
which capture, manipulate, store, and distribute data
• between a system and its environment and
• between components of a system.
• The visual representation makes it a good communication
tool between User and System designer.
• Structure of DFD allows starting from a broad overview
and expand it to a hierarchy of detailed diagrams.

5
Why DFD?
• DFD has often been used due to the following
reasons:
• Logical information flow of the system
• Determination of physical system construction
requirements
• Simplicity of notation
• Establishment of manual and automated systems
requirements

6
DFD Symbols
• There are four basic symbols that are used to
represent a data-flow diagram
• Process
• Data Flow
• Data Store
• External Entity

7
 DFD Symbols – Process
• A process receives input data and produces output with a
different content or form.
• Processes can be as simple as collecting input data and saving in
the database, or
• It can be complex as producing a report containing monthly sales
of all retail stores in the northwest region.
• Every process has a name that identifies the function it performs.
• The name consists of a verb, followed by a singular noun.
• Example:
• Apply Payment
• Calculate Commission
8
• Verify Order
Process – Notation
• A rounded rectangle represents a process
• Processes are given IDs for easy referencing

9
Process – Example

10
DFD Symbols – Data Flow
• A data-flow is a path for data to move from one part
of the information system to another.
• A data-flow may represent a single data element such
the Customer ID or it can represent a set of data
element (or a data structure).
• Example:
• Customer_info (LastName, FirstName, SS#, Tel #, etc.)
• Order_info (OrderId, Item#, OrderDate, CustomerID, etc.).

11
Data Flow – Notation
• Straight lines with incoming arrows are input
data flow
• Straight lines with outgoing arrows are output
data flows

12
Rules of Data Flow
• One of the rule for developing DFD is that all flow must
begin with and end at a processing step.
• This is quite logical, because data can't transform on its
own with being process.
• By using the rule of thumb, it is quite easily to identify
the illegal data flows and correct them in a DFD.

13
Rule of Data Flow
• Wrong

• Right

• Reason:
• An entity cannot provide data to another entity without
some processing occurred. 14
Rule of Data Flow
• Wrong

• Right

• Reason:
• Data cannot move directly from an entity to a data
15
story without being processed.
Rule of Data Flow
• Wrong

• Right

• Reason
• Data cannot move directly from a data store
16
without being processed.
Rule of Data Flow
• Wrong

• Right

• Reason:
• Data cannot move directly from one data store to
17
another without being processed.
DFD Symbols – Data Store
• A data store or data repository is used in a data-
flow diagram to represent a situation when the
system must retain data because one or more
processes need to use the stored data in a later
time.

18
Data Store – Notation
• Data can be written into the data store, which is
depicted by an outgoing arrow
• Data can be read from a data store, which is
depicted by an incoming arrow.
• Examples are: inventory, Accounts receivables,
Orders, and Daily Payments.

19
Data Store – Example

20
DFD Symbols – External Entity
• An external entity is a person, department, outside
organization, or other information system that provides data to
the system or receives outputs from the system.
• External entities are components outside of the boundaries of
the information systems.
• They represent how the information system interacts with the
outside world.

21
External Entity – Notation
• A rectangle represents an external entity
• They either supply data or receive data
• They do not process data

22
External Entity – Example

23
Top-Down Decomposition Techniques

24
Top-Down Decomposition Techniques
• Top-down decomposition, also called leveling, is
a technique used to show more detail in lower-
level DFDs.
• Leveling is done by drawing a series of
increasingly detailed diagrams until the desired
degree of detail is reached.
• As shown in the Figure, DFD Leveling is first
displaying the targeted system as a single
process, and then showing more detail until all
25
processes are functional primitives
DFD Symbols – Process

26
DFD Level 0 – Context Diagram

27
 Context-Level Diagram
• A context diagram gives an overview and it is the highest level
in a data flow diagram, containing only one process
representing the entire system.
• It should be split into major processes which give greater detail
and each major process may further split to give more detail.
• All external entities are shown on the context diagram as well as
major data flow to and from them.
• The diagram does not contain any data storage.
• The single process in the context-level diagram, representing the
entire system, can be exploded to include the major processes of
the system in the next level diagram
28
DFD Level 1

29
End of Lecture

30
Software Engineering
Dr. Saba Bashir

1
 Today’s Lecture
• Data Modeling • ERD Notations
• Data Object • Entity, Entity Attributes,
• Data Attributes Primary Key, Foreign Key,
Cardinality
• Relationships
• ER Models
• Cardinality and Modality
• Conceptual
• Entity Relationship Diagram (ERD)
• Logical
• What is an ERD?
• Physical
• When to draw ERD?
• How to draw an ER diagram
• Entity Relationship Diagram
• ERD Examples
• What is an ERD?
• When to draw ERD? 2
Data Modeling

3
Data Modeling
• Analysis model often begin with data modeling.
• Data model consists of three interrelated pieces of
information:
• The data object,
• The attributes that describe the data object, and
• The relationships that connect data objects to one
another.

4
Data Object
• A data object is a representation of almost any composite information that
must be understood by software.
• composite information - number of different properties or attributes.
• A data object can be:-
• An external entity (e.g., anything that produces or consumes information),
• A thing (e.g., a report or a display),
• An occurrence (e.g., a telephone call)
• Event (e.g., an alarm),
• A role (e.g., salesperson),
• An organizational unit (e.g., accounting department),
• A place (e.g., a warehouse),
• A structure (e.g., a file).

5
For Ex.- Set of attributes can be defined for a
person or a car (i.e. Data Object)

6
Data Attributes
• Define the properties of a data object.
• Attributes name a data object, describe its
characteristics, and in some cases, make
reference to another object.
• In addition, one or more of the attributes must
be defined as an identifier( Key value or
Unique value).
Ex. Data object Car has Id number as identifier.

7
Relationships
• Data objects are connected to one another in different
ways.
• Consider two data objects
• Book
• Bookstore
• A connection is established between book and bookstore
because the two objects are related.

8
Relationship
• To determine relationship between them, must
understand the role of book and bookstore.
• Can define a set of object/relationship pairs that
define the relevant relationships.

For Example:
• A bookstore orders books.
• A bookstore displays books.
• A bookstore stocks books.
• A bookstore sells books. 9
• A bookstore returns books.
Cardinality and Modality
• Additional element of data modeling.
• Object X relates to object Y does not provide
enough information.
• How many occurrences of object X are related to
how many occurrences of object Y called
cardinality.

10
Cardinality
• Representing the number of occurrences objects in a given
relationship.
• Cardinality is the specification of the number of occurrences of
one [object] that can be related to the number of occurrences of
another.
• Cardinality is usually expressed as simply 'one' or 'many’.
• 1:1 – One object can relate to only one other object.
• 1:M – one object can relate to many objects.
• M:N – Some no. of occurrences of an object can relate to some
other no. of occurrences of another object.

11
Example
Example
Example
Example
Modality
• Cardinality does not provide an indication of whether or
not a particular data object must participate in the
relationship.
• Modality of a relationship is 0 if there is no explicit need
for the relationship to occur or the relationship is
optional.
• The modality is 1 if an occurrences of the relationship is
mandatory.

20
Entity Relationship Diagram
ERD

21
What is an ERD?
• Database is absolutely an integral part of software systems.
• To fully utilize ER Diagram in database engineering
guarantees you to produce high-quality database design to use
in database creation, management, and maintenance.
• An ER model also provides a means for communication.
• An ERD contains different symbols and connectors that
visualize two important information:
• The major entities within the system scope, and
• The inter-relationships among these entities.
• That's why it's called "Entity" "Relationship" diagram (ERD)
22
What is an ERD?
• When we talk about entities in ERD, very often we are
referring to
• business objects such as people/roles (e.g. Student),
• tangible business objects (e.g. Product),
• intangible business objects (e.g. Log), etc.
• "Relationship" is about how these entities relate to each other
within the system.

23
When to draw ER Diagram?
• Depending on the scale of change, it can be risky to alter a
database structure directly in a DBMS.
• To avoid ruining the data in a production database, it is
important to plan out the changes carefully.
• ERD is a tool that helps. By drawing ER diagrams to visualize
database design ideas, you have a chance to identify the
mistakes and design flaws, and to make corrections before
executing the changes in the database.

24
ERD Notations
• Entity
• Entity Attributes
• Primary Key
• Foreign Key
• Cardinality

25
ERD Notations – Entity
• An ERD entity is a definable thing or concept within a
system, such as
• a person/role (e.g. Student),
• object (e.g. Invoice),
• concept (e.g. Profile) or
• event (e.g. Transaction)
• When determining entities, think of them as nouns.
• In ER models, an entity is shown as a rounded rectangle,
with its name on top and its attributes listed in the body of
the entity shape.
• The ERD example above shows an example of an ER entity.
26
ERD Notations – Entity Attributes
• An attribute is a property or characteristic of the entity that
holds it.
• An attribute has
• a name that describes the property and
• a type that describes the kind of attribute it is,
such as varchar for a string, and int for integer.

• When an ERD is drawn for physical database development, it is

important to ensure the use of types that are supported by the
target RDBMS.
• The ER diagram above shows an entity with some attributes in it.
27
 ERD Notations – Primary Key
• A primary key is a special kind of entity attribute that uniquely defines a
record in a database table.
• In other words, there must not be two (or more) records that share the same
value for the primary key attribute.
• The ERD example below shows an entity 'Product' with a primary key attribute
'ID', and a preview of table records in the database.
• The third record is invalid because the value of ID 'PDT-0002' is already used
by another record.

28
ERD Notations – Foreign Key
• A foreign key is a reference to a primary key in a table.
• It is used to identify the relationships between entities.
• Note that foreign keys need not be unique.
• Multiple records can share the same values.
• The ER Diagram example below shows an entity with some
columns, among which a foreign key is used in referencing
another entity.

29
ERD Notations – Foreign Key

30
ERD Notations – Relationship
• A relationship between two entities signifies that the two
entities are associated with each other somehow.
• For example, a student might enroll in a course. The entity
Student is therefore related to Course, and a relationship is
presented as a connector connecting between them.

31
ERD Notations – Cardinality
• Cardinality defines the possible number of occurrences in
one entity which is associated with the number of
occurrences in another.
• For example, ONE team has MANY players. When present in
an ERD, the entity Team and Player are inter-connected with a
one-to-many relationship.
• In an ER diagram, cardinality is represented as a crow's foot
at the connector's ends.
• The three common cardinal relationships are one-to-one, one-
to-many, and many-to-many.

32
ERD Notations – One-to-One Cardinality
• A one-to-one relationship is mostly used to split an entity in two
to provide information concisely and make it more
understandable.
• The figure below shows an example of a one-to-one relationship.

33
ERD Notations – One-to-Many Cardinality
• A one-to-many relationship refers to the relationship between
two entities X and Y in which an instance of X may be linked to
many instances of Y, but an instance of Y is linked to only one
instance of X.
• The figure below shows an example of a one-to-many
relationship.

34
 ERD Notations – Many to Many
• A many-to-many relationship refers to the relationship between two
entities X and Y in which X may be linked to many instances of Y and
vice versa.
• The figure below shows an example of a many-to-many relationship.
• Note that a many-to-many relationship is split into a pair of one-to-
many relationships in a physical ERD.

35
 ER Models
• An ER model is typically drawn at up to three levels of
abstraction:
• Conceptual ERD / Conceptual data model
• Logical ERD / Logical data model
• Physical ERD / Physical data model

36
 Conceptual Data Model
• Conceptual ERD models the business objects that should
exist in a system and the relationships between them.
• A conceptual model is developed to present an overall picture
of the system by recognizing the business objects involved.
• It defines what entities exist, NOT which tables.
• For example, 'many to many' tables may exist in a logical or
physical data model but they are just shown as a relationship
with no cardinality under the conceptual data model.

37
 Logical Data Model
• Logical ERD is a detailed version of a Conceptual ERD.
• A logical ER model is developed to enrich a conceptual model
by defining explicitly the columns in each entity and
introducing operational and transactional entities.
• Although a logical data model is still independent of the
actual database system in which the database will be created,
you can still take that into consideration if it affects the
design.

38
Logical Data Model – Example

39
 Physical Data Model
• Physical ERD represents the actual design blueprint of a
relational database.
• A physical data model elaborates on the logical data model by
assigning each column with type, length, nullable, etc.
• Since a physical ERD represents how data should be
structured and related in a specific DBMS it is important to
consider the convention and restriction of the actual database
system in which the database will be created.
• Make sure the column types are supported by the DBMS and
reserved words are not used in naming entities and columns.

40
Physical Data Model – Example

41
Conceptual/Logical/Physical ER Models

42
How to draw an ER diagram?
1. Make sure you are clear about the purpose of drawing the
ERD. Are you trying to present an overall system
architecture that involves the definition of business objects?
Or are you developing an ER model ready for database
creation? You must be clear about the purpose to develop an
ER diagram at the right level of detail
2. Make sure you are clear about the scope to model. Knowing
the modeling scope prevents you from including redundant
entities and relationships in your design.
3. Draw the major entities involved in the scope.
4. Define the properties of entities by adding columns.
43
 How to draw an ER diagram?
5. Review the ERD carefully and check if the entities and columns are
enough to store the data of the system. If not, consider adding
additional entities and columns. Usually, you can identify some
transactional, operational and event entities in this step.
6. Consider the relationships between all entities and relate them with
proper cardinality (e.g A one-to-many between entity Customer and
Order). Don't worry if there are orphan entities. Although it's not
common, it's legit.
7. Apply the technique of database normalization to re-structure the
entities in a way that can reduce data redundancy and improve data
integrity. For example, the details of the manufacturer might be
stored under the Product entity initially. During the process of
normalization, you may find that the detail keeps repeating records
44
over records, then you can split it as a separate entity Manufacturer,
and with a foreign key that links between Product and Manufacturer.
ERD Example – Loan System

45
ERD Example – Online Shop

46
ERD Example – Movie Rental

47
End of Lecture

48
 Software Engineering
Lecture 12

Software Testing Techniques

1
 Software Testing
• Testing is the process of exercising a program
with the specific intent of finding errors prior
to delivery to the end user.

2
 Testability
• Operability — it operates cleanly

• Observability — the results of each test case

are readily observed

• Controllability — the degree to which testing

can be automated and optimized

3
 Testability

• Simplicity — reduce complex architecture and

logic to simplify tests

• Stability — few changes are requested during

testing

• Understandability — of the design

4
 What Testing Shows
errors

requirements conformance

performance

an indication
of quality
 Who Tests the Software?

developer independent tester

Understands the system Must learn about the system,

but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality
 Exhaustive Testing

loop < 20 X

There are 1014 possible paths! If we execute one test per

millisecond, it would take 3,170 years to test the program
 Selective Testing

Selected path

loop < 20 X

What you can do is do some selective path testing to assure it is

possible to get down a particular path
 Test Case Design
"Bugs lurk in corners
and congregate at
boundaries ..."
Boris Beizer

OBJECTIVE to uncover errors

CRITERIA in a complete manner

CONSTRAINT with a minimum of effort and time

 Software Testing
Software testing comes in many flavors for testing one method
or program

white-box black-box
methods methods

Methods

Strategies

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
 White-Box Testing

... our goal is to ensure that all

statements and conditions have
been executed at least once ...

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
 Why Cover?

logic errors and incorrect assumptions

are inversely proportional to a path's
execution probability

we often believe that a path is not

likely to be executed; in fact, reality is
often counter intuitive

typographical errors are random; it's

likely that untested paths will contain
some

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
 Basic Path Testing
Next, we derive the
independent paths:
1

2 There are four paths

3 Path 1: 1,2,3,6,7,8
4
5 6
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
7
Finally, we derive test
cases to exercise these
8
paths.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
 Loop Testing

Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
 Loop Testing: Simple Loops

Minimum conditions—Simple Loops

1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through Simple
the loop loop

where n is the maximum number

of allowable passes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
 Loop Testing: Nested Loops
Nested Loops
Start at the innermost loop.
Set all outer loops to their minimum iteration parameter
values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.

Move out one loop and set it up as in step 2, holding all

other loops at typical values. Nested
Loops
Continue this step until the outermost loop has been
tested.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
 Loop Testing: Concatenated Loops

Concatenated Loops

If the loops are independent of one another

then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value
of loop 1 is used to initialize loop 2.

Concatenated
Loops
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
 Black-Box Testing

requirements

output

input events

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
 Equivalence Partitioning

user output FK
queries mouse formats input
data
picks prompts

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
 Equivalence Partitioning

Invalid inputs Valid inputs

System

Outputs
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
 Equivalence Partitioning
Partition system inputs and outputs into
‘equivalence sets’
 If input is a 5-digit integer between 10,000 and 99,999,
equivalence partitions are <10,000, 10,000-99, 999 and > 99,999

Choose test cases at the boundary of these

sets

 00000, 09999, 10000, 99999, 100001

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
 Boundary Value Analysis

user output FK
queries mouse formats input
data
picks prompts

output
input domain domain
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
 Other Black Box Techniques

error guessing methods

decision table techniques
cause effect graphing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
End of Lecture

24
 Software Engineering
Lecture 13

Software Testing Techniques

1
 Software Testing
Software testing comes in many flavors for testing one method
or program

white-box black-box
methods methods

Methods

Strategies

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
 White-Box Testing

... our goal is to ensure that all

statements and conditions have
been executed at least once ...

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
 Why Cover?

logic errors and incorrect assumptions

are inversely proportional to a path's
execution probability

we often believe that a path is not

likely to be executed; in fact, reality is
often counter intuitive

typographical errors are random; it's

likely that untested paths will contain
some

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
 Basic Path Testing
Next, we derive the
independent paths:
1

2 There are four paths

3 Path 1: 1,2,3,6,7,8
4
5 6
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
7
Finally, we derive test
cases to exercise these
8
paths.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
 Loop Testing

Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
 Loop Testing: Simple Loops

Minimum conditions—Simple Loops

1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through Simple
the loop loop

where n is the maximum number

of allowable passes

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
 Loop Testing: Nested Loops
Nested Loops
Start at the innermost loop.
Set all outer loops to their minimum iteration parameter
values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.

Move out one loop and set it up as in step 2, holding all

other loops at typical values. Nested
Loops
Continue this step until the outermost loop has been
tested.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
 Loop Testing: Concatenated Loops

Concatenated Loops

If the loops are independent of one another

then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value
of loop 1 is used to initialize loop 2.

Concatenated
Loops
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
 White Box Testing

White box testing techniques analyze the

internal structures, the used data structures,
internal design, code structure, and the
working of the software rather than just the
functionality as in black box testing.
White box testing is also known as structural
testing or code-based testing, and it is used
to test the software’s internal logic, flow, and
structure.
The tester creates test cases to examine the
code paths and logic flows to ensure they
meet the specified requirements.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
What Does White Box Testing Focus On?

 Path Checking: Examines the different routes the

program can take when it runs. Ensures that all
decisions made by the program are correct, necessary,
and efficient.
 Output Validation: Tests different inputs to see if the
function gives the right output each time.
 Loop Testing: Checks the loops in the program to
make sure they work correctly and efficiently. Ensures
that loops handle variables properly within their scope.
 Data Flow Testing: Follows the path of variables
through the program to ensure they are declared,
initialized, used, and manipulated correctly.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
 Types of White Box Testing

White box testing can be done for different

purposes. The three main types are:

 Unit Testing
 Integration Testing
 Regression Testing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
 Black-Box Testing

requirements

output

input events

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
Black Box Testing is an important part of
making sure software works as it should.
Instead of exploring the code, testers check
how the software behaves from the outside,
just like users would. This helps catch any
issues or bugs that might affect how the
software works.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
 Types of Black Box Testing

The following are the various categories of

black box testing:

Functional Testing
Regression Testing
Nonfunctional Testing (NFT)

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
 Equivalence Partitioning
It is often seen that many types of inputs
work similarly so instead of giving all of them
separately we can group them and test only
one input of each group.
The idea is to partition the input domain of the
system into several equivalence classes such
that each member of the class works
similarly.
If a test case in one class results in some
error, other members of the class would also
result in the same error.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
 Equivalence Partitioning

user output FK
queries mouse formats input
data
picks prompts

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
 Equivalence Partitioning

Invalid inputs Valid inputs

System

Outputs
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
 Equivalence Partitioning
Partition system inputs and outputs into
‘equivalence sets’
 If input is a 5-digit integer between 10,000 and 99,999,
equivalence partitions are <10,000, 10,000-99, 999 and > 99,999

Choose test cases from these sets

 00000, 09999, 10000, 99999, 100001

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
 Example
Let us consider an example of any college
admission process. There is a college that
gives admissions to students based upon
their percentage.

Consider percentage field that will accept

percentage only between 50 to 90 %, more
and even less than not be accepted, and
application will redirect user to an error page.
If percentage entered by user is less than 50
%or more than 90 %, that equivalence
partitioning method will show an invalid
percentage. If percentage entered is between
50 to 90 %, then equivalence partitioning
method will show valid percentage.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
 Boundary Value Analysis

Boundaries are very good places for errors to

occur.
Hence, if test cases are designed for
boundary values of the input domain then the
efficiency of testing improves and the
probability of finding errors also increases.
For example – If the valid range is 10 to 100
then test for 10,100 also apart from valid and
invalid inputs.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
 Boundary Value Analysis

user output FK
queries mouse formats input
data
picks prompts

output
input domain domain
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
 Example

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
25
 Other Black Box Techniques

error guessing methods

decision table techniques
cause effect graphing

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
26
End of Lecture

27