IE4001 Software Engineering Course Overview: Eckchan@ntu - Edu.sg Elhchen@ntu - Edu.sg

IE4001 Software Engineering
Course Overview
Part I Part II
Dr Chan Chee Keong Dr Chen Lihui
School of Electrical and Electronic School of Electrical and Electronic
Engineering Nanyang Technological

Engineering Nanyang Technological
University University
Email: eckchan@ntu.edu.sg Email: elhchen@ntu.edu.sg
Office: S1-B1B-51 Office: S1-B1C-96
Course Overview
❑ Part I: Week 1 – 7 by Dr Chan Chee Keong
✓ Software Requirements Analysis and Design
✓ Software Testing
❑ Part II: Week 8 – 13 by Dr Chen Lihui
✓ Web Engineering
✓ Project Management
Continuous Assessments (CAs)
Part I:
QUIZ 1: 20%
Part II:
QUIZ 2: 20%
IE4001
Software Engineering
Part I – Software Requirements Analysis,
Design and Testing
Part I - Overview
Unit 1: Introduction to Software Engineering
Unit 2: Structured Methods for Requirements Analysis
Unit 3: UML Modeling I – Structural Modeling Q1 exam
Unit 4: UML Modeling II – Behavioral Modeling
Unit 5: Unified Software Development Process (USDP)
Unit 6: Software Testing I -- Introduction and Functional Testing
Q2exam
Unit 7: Software Testing II – Structural Testing and Overall Testing Approach
Proposed Study Method for Part I
The materials of Part I covers the most essential and fundamental knowledge in Software
Engineering. These are obtained from many books after in-depth understanding, hence,
not easy to read from books.
Keys for study Part I:
◦ It is Very IMPORTANT to follow the lecture so that you can have a good understanding of
the lecture notes.
◦ It is also important for you to practice the tutorials.
References

❑

Pressman Roger S, Software Engineering: A Practitioner's Approach, 9th Edition,

McGraw-Hill, 2020.
❑
Sommerville Ian, Software Engineering, 10th Edition, Pearson/Addison- Wesley, 2016.
❑
Mark Priestley, Practical Object-Oriented Design with UML, 2004, McGraw-Hill.

Paul C. Jorgensen, Software Testing: A Craftman’s Appraoch, 2nd Edition, CRC Press,

2002.
❑
Mauro Pezze, and Michal Young, Software Testing and Analysis: Process, Principles

and Techniques, Wiley, 2008.
❑

Roger S. Pressman and David Lowe, Web Engineering: A Practitioner’s Approach,

McGraw-Hill, 2009.

❑
Bob Hughes and Mike Cotterell, Software Project Management, 5th Edition, McGraw-Hill,

2009.

Unit 1 Introduction
❑ Software
❑ Definition of Software Engineering
❑ Role of Software Engineer
❑ Software Process
❑ Software Process Model
DEC 2022 DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL: ECKCHAN@NTU.EDU.SG;; TEL:67905377 1

Software
What is Software?
◦ Computer programs and associated documentation such as requirements, design
models and user manuals.
Software products may be
◦ Generic - developed to be sold to a range of different customers e.g. PC software
such as Excel or Word.
◦ Customised - developed for a single customer according to their specification.
New software can be created by developing new programs, configuring generic
software systems, reusing existing software or a combination of these.
Today, software is almost used in any area including home, business, health care,
education, defence etc.
DEC 2022
DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL:
ECKCHAN@NTU.EDU.SG;; TEL:67905377
2

Software Engineering
Definition
Software
Engineering is the application of engineering to develop quality software in a

cost-effective
way to meet the target objective.
Some Areas
◦ Software Modeling: Theory and methods for specifying software requirements and
design
◦ Software Development Methodology: Methods for developing software
◦ Software Security: Implement and audit security defense in software systems (most
of the security attacks exploit on software vulnerabilities)
◦ Software Reuse: Methods for reusing software.
◦ Software Testing: Theory and methods for testing software.
◦ Software Economics: Theory and methods for estimating resources and costs of
software development, etc.
◦ Many more
DEC 2022
3

Role of Software Engineer
❑ Programming is the basic essential skill but not enough
❑ Software engineering deals with the development of large and complex systems which
require the following important skills:
➢ Methods for specifying requirements and design
✓ these methods are called modeling methods; outputs created by them are called models
or specifications
✓ these methods cover the creation and analysis of models
✓ Methods for testing systems to ensure their quality
➢ Good Knowledge on commonly used software (e.g., database management systems)
➢ Communication skills
➢ Management skills
DEC 2022
4

Software Process
memov
A process is defined as a collection of activities when some work product is to be to created.
I 1
Each activity is populated by a set of actions. Each action is defined by a set of tasks to
complete the work products and other associated achievement.
In general, software processes comprises the following types of activities:
1.Communication: project initialization; requirements capture
2.Planning: plan technical tasks, resources, work products, work schedule; analyze risks
3.Modeling: requirements analysis, design
4.Construction: coding, testing
5.Deployment: software delivery, evaluation and feedback.
In Part I, we shall focus on the important activities – Requirement Specification, Requirements
Analysis, Design and Testing
DEC 2022
5

Software Process Models

Software process model gives a brief view (abstracted view) on how software is developed

We

shall discuss:

❑ Prescriptive models that are not specific to any software engineering approach (e.g., USDP

discussed in Unit 5)

❑ The general characteristics of agile software development (does not follow any fixed

model, and is also not specific to any software engineering approach)

DEC 2022
6

Prescriptive Process Models

Three

types:

❑ Waterfall Model

memorise

❑ Incremental Model

❑ Evolutionary Model

practice, these models are chosen depending on the environment, resources,
In

objective, etc., and made more specific accordingly

DEC 2022
7

Waterfall Model – The Process
Communication
Project initiation
Requirements gathering Planning
Estimating
Scheduling Modeling
Tracking Analysis Construction
requirements
Design Code
Deployment
Test
project Delivery
models
plan Support
Main Characteristics: testa Feedback
exe
✓ Five phases are arranged in sequence.
✓ The result of each phase is one or more documents that are approved.
✓ The following phase should not start until the previous phase has finished.
DEC 2022
8

Waterfall Model
Situations suitable for this model
✓ Well-defined requirements
✓ Adequate resources
✓ Project teams have good expertise/experience on the system
✓ Systems are not too large or complex
✓ There is no urgent need on any part of the system
DEC 2022
9

The Incremental Model

Diagrammatic View

Communication

Planning
Software Functionality and
Modeling (analysis, design)

Construction (code, test) delivery of

Deployment (delivery, feedback) nth increment

Features

delivery of

2nd increment

overlap

delivery of

1st increment

Project Calendar Time

DEC 2022
10

computerhardware

Incremental Model – Main Characteristics

Rather

than deliver the system as a single delivery, the development and
delivery

is broken down into increments

✓ Each increment delivering part of the required functionality.

✓ The first increment is called the core product which addresses the basic

requirement, later increments address modifications and additional

functions and features.

✓ Different process model can be used for different increment.

User

requirements are prioritised and the highest priority requirements are

included in early increments. operatingsystem

DEC 2022
1 11

The Incremental Model
Situations suitable for this model
✓Requirements are reasonably well-defined, but the overall scope of the
development effort precludes a purely linear, waterfall process.
✓Compelling need to provide a limited set of software functionality to users
quickly and then refine and expand on that functionality in later software
releases.
DEC 2022
12

Evolutionary models
They are explicitly designed to accommodate a product that evolves over
time (may change over time).
They are iterative, characterized in a manner that enables software engineer
to develop increasingly more complete, accurate or better versions of the
software.
Two sub-models
❑ Prototyping guideoverview
❑ Spiral
of project
DEC 2022
13
Prototyping –
Process and main characteristics
Begins with communication.
The software engineer and customer meet
and define the overall objectives for the
software, identify whatever requirements are
known, and outline areas where further
definition is mandatory
A prototyping iteration is planned quickly and
modeling (in the form of a "quick design")
occurs.
The quick design leads to the construction
of a prototype.
The prototype is deployed and then evaluated
by the customer/user. Feedback is used to
refine requirements for the software.
✓ Iteration occurs as the prototype is tuned to satisfy the needs of the customer
DEC 2022
14

Prototyping
Situations suitable for this model:
✓ Small systems
✓ User-interface intensive
✓ Unclear requirements
✓ Lack of expertise/experience
DEC 2022
15

Evolutionary Models: The Spiral

Diagrammatic View

Combines

iterative nature of prototyping and the controlled and systematic
aspects

of the waterfall model.

DEC 2022
16

The spiral
Explanation of the Diagrammatic View
The space around the spiral is divided into five segments, each representing one
key process activity, the circuit around the spiral represents the activity to carry out
Each loop in the spiral represents an iteration in the process
An anchor point (milestone) is defined at the end of each phase where a
combination of work product and conditions are noted
Risks are explicitly assessed and resolved throughout the process
DEC 2022
17

The Spiral
Situations suitable for this model:
✓ Large scale systems with unclear requirements
✓ Complex requirements
✓ High risk cases
Compare with
DEC 2022
18

How to select prescriptive process models?
Choose
according to project situation/requirements
In
practice, one may combine a number of process models together for a project.
Example:
✓ Problem: A large system with (1) reasonably well-defined requirements; (2) except
a small user-interface intensive part of it, the project team has sufficient
expertise/experience on the system; (3) no manpower problem, that is, can be
assigned accordingly; (4) overall, the whole system is not complex.
✓ Solution: (1) Develop the system using incremental model such that each
increment is of moderate size and the part that the project team does not have
sufficient expertise/experience forms a separate increment, J; (2) develop each
increment using waterfall model and develop J using prototyping (Note that our
solution uses three process models)
DEC 2022
19

Agile Software Development
Agile software engineering combines a philosophy and a set of development
guidelines
to address some issues in the use of prescriptive software process models
Manifesto
for agile software development:
Individuals and interactions over processes and tools

✓
Working software over comprehensive documentation

✓
Customer collaboration over contract negotiation
Responding to change over following a plan

✓
While the items on the right are still important the items on the left are more valuable
under this philosophy
DEC 2022
20

What is “Agility”?
✓ Rapid and adaptive response to change
✓ Effective communication among all stakeholders
✓ Drawing the customer onto the team
✓ Organizing a team so that it is in control of the work performed
✓ Rapid, incremental delivery of software
DEC 2022
21

Agility
✓encourages team structures that make communication among
developers and customers easier
✓emphasizes importance of rapid delivery of operational software
and de-emphasizes importance of intermediate work products
✓can be applied to any software process as long as the project
team is allowed to streamline tasks and conduct planning in way
that eliminate non-essential work products
DEC 2022
22

An Agile Process
✓ Is driven by customer descriptions of what is required (scenarios)
✓ Recognizes that plans are short-lived
✓ Develops software iteratively with a heavy emphasis on
implementation
✓ Delivers multiple ‘software increments’
✓ Adapts as changes occur
DEC 2022
23

Unit 2 Exam gullat
Structured Methods for Requirements Analysis
✓Introduce the two well-known traditional modeling techniques for
requirement analysis: Entity-Relationship (ER) modeling and Data Flow
Diagram (DFD) technique
✓Introduce the well-known traditional methodology for requirements
analysis: structured analysis
Dec 2022 DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL: ECKCHAN@NTU.EDU.SG 1

Requirements Analysis program
data f algorithm

-
We can classify the requirements for software into two aspects:

▪ Data: Information to deal with

▪ Processes: The tasks to perform

-
In traditional techniques for requirement analysis:

• Data and processes are modeled (systematically described) separately and

conceptually

• The modeling of data is called data modeling.

• The modeling of processes is called process or behavioral modeling.

-
In this unit, we shall cover some well-known modeling techniques for

requirements analysis:

• For data modeling: we shall cover Entity-Relationship (ER) modeling
memof• For process modeling: we shall cover Data Flow Diagram (DFD) technique

Dec 2022
ECKCHAN@NTU.EDU.SG
2

Entity-Relationship (ER) Modeling
Basic Principle:
◦ model the data using Entity-Relationship Diagram (ER diagram)
◦ describe the conceptual characteristics of data from business (conceptual or
logical) viewpoint
◦ used in the well-known traditional requirements analysis technique, called
structured analysis (will be discussed later)
◦ examine data independently from processing
process
◦ focus attention on the data domain intelligent
◦ create a model at the customer’s level of abstraction (abstraction is a
fundamental task to focus on some target aspect and ignore other aspects)
Basically, ER modeling describe the data in a system by entity types and the
relationships between them by relationship types in a ER diagram.
Dec 2022
ECKCHAN@NTU.EDU.SG
3

What is a Entity Type?
Entity Type — A entity type specifies a instantt David
t student
type of things that have identical entity
properties in the target system.
Each thing that is represented by an entity type is called an entity, a
data entity or an instance of the entity type.
Each entity plays a necessary role in the system, i.e., the system could
not function without the entity.
Each entity can be uniquely identified (that is has a key).
Each entity type is described by a set of data items, called attributes of
the entity type to show the characteristics of each of its instances.
Dec 2022
ECKCHAN@NTU.EDU.SG
4

quiz
content
How to use entity type, its instance and attribute to
model things?
Entity Type: to model a type of information, for example:
◦ Information structure of suppliers
◦ Student
Attribute of Entity Type: to model a property of information type, for example:
◦ Supplier name;
◦ Student address
Instance of Entity Type (Entity): to model an instance of information, for
example:
◦ IBM: a supplier
◦ Michael Lee: a student
Dec 2022
ECKCHAN@NTU.EDU.SG
5

ER Modeling using Entity Type - Examples
Things that the system need to keep track of their status. For example:
◦ Subject Registration System: Students, Subject, Tutorial Class
◦ Personnel and Payroll System: Employee, Department
Business transactions occurred that are required to be monitored. For
example:
◦ Order Processing System: Customer Order (to monitor the delivery and
billing subsequently), Invoice (to monitor the payment to invoice
subsequently)
Dec 2022
ECKCHAN@NTU.EDU.SG
6

Defining entity types in ER diagram

entity type is described by a set of attributes to show
An the characteristics of

each

instance of the entity type

Dec 2022
ECKCHAN@NTU.EDU.SG
7

What is a Relationship Type?

Relationship
Type — A relationship type specifies a type of
interactions
between things, that have identical properties.

These
things are modeled by entity types.
The
relationship type is referred as a relationship type between the latter

entity
types.
Each
such interaction is called an instance of the relationship type or a

relationship
(of the relationship type).

Example:
◦ We can use a “teach” relationship type to represent all the teaching
interactions between lecturers and students.
◦ As a result, “lecturer X teaches student A” is an instance of the
relationship type.
In
general, a relationship type may relate one, two, three, etc., entity types.
However,
we shall discuss only the first two. These two are quite sufficient
for
most of the problems.
Dec 2022
ECKCHAN@NTU.EDU.SG
8

How to use relationship type and its instance to model
things?
Relationship Type: to model a type of interactions, for example:
◦ Lecturers teach students
◦ Managers supervise staff
Instance of Relationship Type: to model an individual interaction, for
example:
◦ Dr K. C. Lee teaches OO programming
◦ Mr K .S. Tan buys a car with plate no SZZ 9999 G.
Dec 2022
ECKCHAN@NTU.EDU.SG
9

Relationship Type

Notation — A relationship type between two entity types is

represented

by a line connecting the two entity types. The name
of
the relationship type is written in the center along the line.

Example:

The teach relationship type discussed in the slide 8 can be specified as
follows:

entity entity

relationship

Further information discussed in the next two slides can be specified to a

relationship

type.

Dec 2022
ECKCHAN@NTU.EDU.SG
10 I

Cardinalities used in ER Diagram
memorise
mat min
Dec 2022
ECKCHAN@NTU.EDU.SG
11

Specifying Further Information to a Relationship Type in ER

Diagram

◼
We can specify a pair of cardinalities at each entity type end in a

relationship type as shown in the following example:

closertotype facingaway away

facing closerto type

ez fi

ez

exactly otomany Cea fz

◼
Definition: A pair of cardinalities specified at an entity type F end to

define that:

Each instance of entity type (E) at the other end is related to, at least the

minimum number and at most the maximum instances, of F.

We can add Role to each end of a relationship type to tell the function that

the entity type plays in the relationship type.

Dec 2022
ECKCHAN@NTU.EDU.SG
12

Example: A Relationship Type in Full
Dec 2022
ECKCHAN@NTU.EDU.SG
13

Example: A relationship type with
role and only one entity type
Dec 2022
ECKCHAN@NTU.EDU.SG
14

ER Diagram : An Example
The next slide will interpret the relationship type between Shipment and Supplier as an
illustration
Dec 2022
ECKCHAN@NTU.EDU.SG
15

Illustration of Precise Meaning of Relationship Type
The meaning of the relationship type between Supplier and Shipment entity type in
the previous slide is as follows:
◦ Each individual supplier (an instance of Supplier entity type) sends 0 to many
shipments (each shipment is an instance of Shipment entity type).
◦ Each shipment (an instance of Shipment entity type) is sent by exactly one
supplier.
◦ Supplier entity type plays the role of “sends” in the relationship type and
Shipment plays the role “sent by” in the relationship type.
◦ If supplier S (an instance of Supplier entity type) sends a shipment X and
supplier S also sends shipment Y, then these are represented by two instances
of this relationship type: the former is represented by an instance that relates S
and X; the latter is represented by an instance that relates S and Y.
Mathematically, we can represent these two instances as (S, X) and (S, Y)
respectively. l
tuple l
◦ If supplier T (an instance of Supplier entity type) does not send any shipment at
this point in time, T will not involve in any instance of this relationship type.
Following the above mathematical representation, this means that T will not form
any two elements tuple with instances of Shipment. It is wrong to interpret as T
forms a tuple (T, ) as anDRinstance of the relationship type.
Dec 2022
CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL:
ECKCHAN@NTU.EDU.SG
16

x
Building an ER Diagram
An ER diagram can be constructed to model the information for a problem by
performing tasks at the following three levels in the order shown:
Level 1—identify the data entities in the problem and model them as entity
types.
Level 2— identity the interactions between the data entities in the problem and
model them as relationship types.
Level 3—refine and fine tune the initial model and include attributes for entity
types to provide further depth.
Dec 2022
ECKCHAN@NTU.EDU.SG
17

Data Flow Diagram (DFD) Technique
- for modeling the behavior (processing) separately to realize the
requirements (“realize the requirements” means to show how the
requirements could be achieved) conceptually.
- This technique is for requirements analysis only
- Also called DFD modeling
Dec 2022
ECKCHAN@NTU.EDU.SG
18

DFD – Principle
Basic Principle: Model computer-based system from the
highest to the lowest level using the basic concept of
information transformer 0 important
level
information
transformer output
input
Data Flow Diagram (DFD) provides an attractive graphical
notation that is suitable for capturing a fairly immediate and
intuitive way, the flow of data and processing involved in an
information system
Dec 2022
ECKCHAN@NTU.EDU.SG
19

DFD – Principles and Characteristics
A semi-formal operational specification (that is, specifying a system in terms
of processing)
A data flow diagram (DFD) is the diagrammatic form to describe processes
and the data that they act on.
key
Classify the data into two types:
◦ Persistent data: they are stored in data repositories

◦ Intermediate data (transient data): they are passed between sub-tasks
Based on functional decomposition: A system is decomposed as a
collection of “functions” that interact with its external environment. You can
view functions as processes.
A DFD is drawn by just using four basic concepts: external entity; process;
data flow and data store. These basic concepts will be explained in the next
five slides.
DFD does not include control flow (sequence, selection and looping).
Dec 2022
ECKCHAN@NTU.EDU.SG
20

Notations for the Four DFD Basic Concepts
external entity: with the name shown in the
rectangle
Process: with the identification and name shown in
the circle
data flow: with the name shown along the arrow
direction
data store: with the name shown in between
the two parallel lines
files dB cloud
Dec 2022
ECKCHAN@NTU.EDU.SG
21

External Entity
TOM A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based
system
Basic Principle
Data must always originate somewhere and must always be sent to
something
Dec 2022
ECKCHAN@NTU.EDU.SG
22

Process
A data transformer (changes input
I to output), a task
Examples: compute taxes, determine area,
format report, display graph
Basic Principle
Data must always be processed in some way to achieve system
function
Dec 2022
ECKCHAN@NTU.EDU.SG
23

Data Flow
An intermediate data involved, a piece
of data
onedirection
Example: base and height are input data flows and area is an
output data flow of process compute triangle area
base
compute
area
triangle
height area
Basic Principle
Data flows through a system, beginning as input and be
transformed into output.
Dec 2022
ECKCHAN@NTU.EDU.SG
24

Data Stores
A data repository kept
Example: sensor data
input sensor #
sensor #, type,
look-up location, age
sensor
report required output

data
type,
input location, age

sensor number
sensor data
Basic Principle
Data is often stored for later use.
Dec 2022
ECKCHAN@NTU.EDU.SG
25

Data Flow Diagramming - Guidelines
All
basic notations must be labeled with meaningful names
apply hierarchical refinement (hierarchical decomposition, that is
decompose the requirements from the highest to the lowest level) – the
DFD evolves through a number of levels of detail, that is, a higher-level
process
can be specified by a separate DFD
When a higher-level process is refined into a separate DFD, the
process and the DFD must be consistent (balanced, will illustrate in the
next few slides):
◦ All data flows from the process must be shown in the lower level DFD
correctly
◦ Do not re-show any higher level process in the lower level DFD
always
begin with a context level diagram (also called level 0)
always
show all the external entities at level 0
do
not show control flow (that is the sequence, selection and looping of
processes)
Dec 2022
ECKCHAN@NTU.EDU.SG
26

Level 0 DFD - Example
processing
user request requested
video
digital signal
video monitor
processor
video
source video signal
In level 0, the whole system is shown as a single process
Dec 2022
ECKCHAN@NTU.EDU.SG
27

The Data Flow Hierarchy - Balancing
inputa consistentfor both levels
there are a b
x P y level 0
pips
a c p2
p1
f
b
p4
d p5
p3 e g
level 1
Two DFDs on this slide (one for level 0 and one for level 1)
Dec 2022
ECKCHAN@NTU.EDU.SG
28

Leveling of DFD – Another Illustration on Balancing

level O

levell

levels

(1) Three DFDs are shown on this slide (level 0, one and two).

For simplicity reason, the external entities are skipped in the context diagram.
(2)

Dec 2022
ECKCHAN@NTU.EDU.SG 2

The Process of Constructing DFD

Start

by drawing DFDs to describe the existing system. The resulting DFDs are called
existing physical DFDs. In these DFDs, we may name a process by the person who

performs the task. Such naming is an example of physical feature.

Transform

existing physical DFDs to DFDs for the target system by:

◦ Removing physical features: for example if a process is named by a person who

performs the task, we change the name to describe its function instead.

◦ Include enhancements to improve the system

The resulting DFDs are called proposed logical DFDs.

Draw higher-level DFD before lower-level DFD: use a 1:5 (approx.) expansion ratio as

a guide for the no of processes in each DFD.

Define

all the data flows and data stores using a data dictionary: discuss later

Write a process specification for each lowest-level DFD: discuss later

Dec 2022
ECKCHAN@NTU.EDU.SG
30

DFD – An Example – SafeHome Security System

Objective: To enable homeowner to configure the system, monitor home

through sensors, and interact with the system through control panel or

telephone line.

Configuration: homeowner registers his/her id and password, and other

configuration information through control panel.

Start and Stop: homeowner activates and deactivates respectively the

system.

Upon detection of an external sensor event: according to the configuration

information, the system:

◦ invokes an audible alarm attached.

◦
display message at control panel and send message to the telephone line.

Dec 2022
ECKCHAN@NTU.EDU.SG
31

DFD – SafeHome Security – Context Diagram (Level 0 Diagram)
Dec 2022
ECKCHAN@NTU.EDU.SG
32

DFD – SafeHome Security – Level 1 DFD
Dec 2022
ECKCHAN@NTU.EDU.SG
33

DFD – SafeHome Security – Level 2 DFD
Dec 2022
ECKCHAN@NTU.EDU.SG
34

Example – A Complete Set of DFDs
In the DFDs shown in the last three slides, assuming that in the level 1 DFD,
except the “Monitor sensors” process, other processes do not need further
decomposition, then the DFDs shown in the last three slides together form
the diagrams of a complete set of DFDs for modeling the SafeHome security
It can be easily verified that in a complete set of DFDs for a system:
◦ There is only one level 0 DFD and one level 1 DFD
◦ For other levels, the no of required DFD varies depending on the
complexity of the problem.
Dec 2022
ECKCHAN@NTU.EDU.SG
35

Data Dictionary
Two main components: data and process specifications
Data specification: A specification is included for each data flow and data
store.
Process specification: A specification is included for each lowest-level
process.
◦ Note that once all the lowest-level processes are specified, any higher-
level process is specified from the specifications of its member lower-level
processes. As such, higher-level processes should not be specified.
Dec 2022
ECKCHAN@NTU.EDU.SG
36

Data Specification (I)

To

describe each data flow and data store in DFD by a combination of data
items

in a hierarchical way. Data items are combined using four basic
structures--

sequence; iterate; optional; case.

Sequence:

sequential combination of data items

◦ Notation: +

◦ To indicate that data item B is after data item A, we specify A + B

◦ Example: Student name has surname and other name, and surname

appears first. So, we specify:

◦ Name = Surname + Other Name

Dec 2022
ECKCHAN@NTU.EDU.SG
37

Data Specification (II)
Iterate: combining multiple values of a data item
◦ Notation: {}*
Otomany
◦ To indicate the combination of multiple values of data item A together, we specify {A}*
◦ Example: Employee past appointments is specified as follows:
◦ Past Appointments = {Appointment }*
Optional: Option combination of a data item
◦ Notation: ()
◦ To indicate the optional combination of data item A – A may or may not have a value--, we
specify (A)
◦ Example: In the employee particular, to indicate that car no is optional, we specify:
◦ Employee Particular = ….+ (Car No) +…
Dec 2022
ECKCHAN@NTU.EDU.SG
38

Data Specification (III)
Case:
Combining one from a number of data items
◦ Notation: [.. | ..| ..]
OR
◦ To indicate the combination of one data item from data items A, B or C, we
specify [A |B |C]
◦ Example: A person is identified by a IC No or a FIN NO we specify:
◦ Person Identification = [IC No | FIN No]
Dec 2022
ECKCHAN@NTU.EDU.SG
39

Data Specification – A more complete Example

An

incomplete DFD:

Tania

the above DFD, the data flow, Order (a purchase order), consists of four attributes: Supplier-
In

Name, Date-Ordered, Method-of-Payment and Order-Items.

▪ Supplier-Name always has a First Name and a Last Name, and there may be a Middle Name

also.

▪ Date-Ordered is an elementary data item.

▪ Method-of-Payment must be one of the three values: Check, Credit-Card or Money-Order.

▪ Order-Items is formed by a number of values of the lower-level attribute Order-Item, which in

turns, has two mandatory elementary attributes, Item-Name and Qty-Ordered.

Dec 2022
ECKCHAN@NTU.EDU.SG
40

Data Specification – A more complete Example
A sample case of the order described on the previous slide:
Supplier Name: SCS Pte Ltd Date: 17-08-2009
Method of payment: Money Order
Item-Name Qty-Ordered
HP xw4400 Workstation 2
6WIND edge routers 1
………. ……..
The data flow, Order, should be specified as follows:
iompulsory
Order = Supplier-Name + Date-Ordered + Method-of-Payment + {Order-Item}* phot
Supplier-Name = First Name + (Middle Name) optional

+ Last Name
Method-of-Payment = [Check | Credit Card| Money Order]
Order-Item = Item-Name + Qty-Ordered VOR
o ormany
Dec 2022
ECKCHAN@NTU.EDU.SG
41

Process Specification (PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
▪ Pseudocode is the most commonly used method.
▪ PDL – Program Design Language
Dec 2022
ECKCHAN@NTU.EDU.SG
42

Process Specifications Using Pseudocode
Using programming language like syntax for the three basic control
structures - sequence, select and iterate.
You have studied in EE2008, so, we will just take a quick look of an
example.
Example:
begin pseudocode Iveryion
read (x);
read (y); instruction
while x  y loop
End
if x > y then
x := x – y;
else
gqyggmm.in
8
ceanauage
y := y – x; compile
I
end loop;
end if; w
end machine code

gcd := x; instance
another 0110011000111
end;
Dec 2022
ECKCHAN@NTU.EDU.SG
43

Requirements Analysis in General
Requirements analysis
◦ specifies software’s operational characteristics: conceptual processing needed to
implement the functions
◦ indicates software's interface with other system elements: all the external
interactions
◦ establishes constraints that software must meet: the environment that the target
system will operate on
Requirements analysis allows the software engineer (called an analyst or modeler in
this role) to:
◦ elaborate on basic requirements established during earlier requirement
engineering tasks
◦ build conceptual models (that is logical without taking physical implementation into
consideration) to realize a system.
Dec 2022
ECKCHAN@NTU.EDU.SG
44

Requirements Analysis in General --
A Bridge
system
description
analysis
model
design
model
Dec 2022
ECKCHAN@NTU.EDU.SG
45

Requirements Analysis in General
Rules of Thumb
The model should focus on requirements that are visible within the problem or
business domain. The level of abstraction should be relatively high (that is, it should
not include physical details of the target environment, for example, the hardware
used, the programming language used, etc.).
Each element of the analysis model should add to an overall understanding of
software requirements and provide insight into following need of the system:
◦ information: data
◦ function: external interaction
◦ Behavior: processing
Delay consideration of infrastructure and other non-functional models until design:
for example deployment.
Minimize coupling throughout the system: minimize the interdependency between
different analysis components.
Be certain that the analysis model provides value to all stakeholders.
Keep the model as simple as it can be.
Dec 2022
ECKCHAN@NTU.EDU.SG
46

Structured Analysis
The main requirements analysis methodologies are: Structured Analysis and Object-
Oriented Analysis
Structured Analysis: perform analysis realization of requirements (to effect the
requirements conceptually without considering the physical environment) in terms of
data and the processes that transform on data separately through performing:
◦ Data Modeling: Following the Entity-Relationship Modeling discussed earlier
◦ Process Modeling: Construct Data Flow Diagrams (DFDs) to conceptually realize
the requirements captured (the operating environments of the software should not
be taken into considerations)
Dec 2022
ECKCHAN@NTU.EDU.SG
47

Unit 3

UML Modeling I – Structural Modeling

-
UML stands for Unified Modeling Language

-
UML has been accepted as a standard language for modeling software problem

and solution in the industry

-
UML is a semi-formal language that is graphical-oriented and supplemented by

textual language

-
We shall study:

- Structural modeling (modeling the structure of information and processes) : the

basic UML modeling technique, Class Diagram, in details.

- Behavioral modeling (model occurrences and details of processes): Use-Case

Technique, Statechart Diagram and Sequence Diagram more detailed and

Activity Diagram briefly.

-
This unit covers structural modeling. Next unit covers behavioral modeling.


UMLI
Class Diagram - Fundamentals
Organize software problem and solution in terms of the basic concept, Object, that
will be discussed shortly: That is, the problem is decomposed into problem objects
and the solution is composed from solution objects.
Is an extension of ER modeling – a class diagram describes both the processes and
data together instead of data only using the concept object
Object has many attractive features to support good software design and make
software more reusable
Class diagram can be used for both requirements analysis and design: a design
model is a refinement of an analysis model
Dec 2022
ECKCHAN@NTU.EDU.SG
2

Object – Concept and Properties

◼
An object is an abstraction of something in a problem domain,
reflecting the following things

sort together

together:

◼ its information

◼ tasks that it can perform or can be performed on it

◼
Objects have state and behaviour:

◼ State: the condition of an object at any moment, affecting its behaviour

◼ Behaviour: what an object can do, or how it can respond to events (tasks)

◼
Object is specified by:

◼ a set of attributes to describe its state

◼ a set of operations to describe its behavior

◼
Objects in a system interact: Relationships are used to specify

the interactions between objects.

Dec 2022
ECKCHAN@NTU.EDU.SG
3

Examples of Objects
Object Behaviour State
A student. Register subject, First year, second
select FYP, etc. year, etc.
A shirt. Shrink, stain, rip. Pressed, dirty,
worn.
A sale. Earn loyalty points. Invoiced,
cancelled.
A bottle of Spill in transit. Unsold, opened,
ketchup. empty.
Dec 2022
ECKCHAN@NTU.EDU.SG 4

Specifying Objects
We use a class to specify (model) a type of things
that have identical properties.
Each individual thing belongs to the type is called an
instance of the class or an object of the class
In a class, we specify: objects instances
◦ attributes objects that share the
◦ operations = methods same attributes grouped
under i was
Dec 2022
ECKCHAN@NTU.EDU.SG
5

How to use class, instance, attribute and operation to model things?
Class:
to model a type of things, for example:
◦ Lecturer
◦ Student
Object:
to model an instance (or a piece) of thing, for example:
◦ IBM: a supplier
◦ Michael Lee: a student
Attribute: to model a property of a type of things, for example:
◦ Supplier name
◦ Student Address
Operation:
to model an associated task, for example:
◦ Compute interest
◦ Draw a circle
Dec 2022
ECKCHAN@NTU.EDU.SG
6

Specifying Class -- Notation
Notation
Class Name
attribute-name-1 : data-type-1 = default-value-1
attribute-name-2 : data-type-2 = default-value-2 attributes
•••
operation-name-1 (argument-list-1): result-type-1
operation-name-2 (argument-list-2): result-type-2 operationl
•••
methods
Example
Person
name
age
job
address
change-job
change-address
Dec 2022
ECKCHAN@NTU.EDU.SG
7

Example – a more comprehensive class
Bank Account
Owner: String
Balance: Dollars = 0
deposit (amount: Dollars)
withdraw (amount: Dollars)
Dec 2022
ECKCHAN@NTU.EDU.SG
8

Class Diagram - Overview
In this technique, we use classes to specify all the objects in a project
and use relationship types to specify all the interactions between them.
Classes: to specify all the objects designed to solve the target problem.
Relationship types: to specify the types of interactions between the
above mentioned objects. This will be discussed shortly.
Dec 2022
ECKCHAN@NTU.EDU.SG
9

Types of Relationships
Association: represent interactions between different objects
Aggregation: represent part-and-assembly type of association, is a
more strongly coupled type of association car tire engine

section
boonschapter
Generalization: represent type-and-subtype kind of relationships
between classes. A type has sub-types. The type is represented by a
super class. Each sub-type is represented by a subclass of the
superclass
Each relationship type will be illustrated further through examples later.
Dec 2022
ECKCHAN@NTU.EDU.SG
10

Specifying Associations
Associations can be further classified into:
-Binary Association: Relate two classes

2
-Ternary Association: Relate three classes 3
-Higher Order Association: Relate more than three classes
Notation for Specifying Associations:
• Binary association: a binary association is specified by a line
connecting the two associated classes with its name shown along the
line.
• Ternary or higher-order association: a ternary or higher order
association is specified by a diamond connected to all the associated
classes with its name shown next to it.
Dec 2022
ECKCHAN@NTU.EDU.SG
11

Specifying Associations
Binary Association - Example:
Person
Company Works-for name
name social security no.
address address
Ternary and Higher Order Association – Example:
Project
Supplier Part
Ship
Dec 2022
ECKCHAN@NTU.EDU.SG
12

Specifying Association – Multiplicity
similarto cardinality
Notation
for Multiplicity:
✓ In general, it is specified as j..k to denote all the integers from j to k, where j
and k are non-negative integers or * (many) and k  j .
✓ 0..* can be simplified as * meaning 0 to many.
✓ j..j is simplified as j. I
✓ Example:
- 6..8 617,8
- 1
- * jimann
- 0..1
O or I
Dec 2022
ECKCHAN@NTU.EDU.SG
13

Specifying Associations - Multiplicity
We
A key
can specify a multiplicity j..k (in general) at each associated class end in an
slid
association as shown in the following example:
associated
Definition: A multiplicity j..k specified at an associated class Cn end to define that:
Each combination of C1,… Cn-1 instances, one from each of them, associates to at
least j instances and at most k instances of Cn.
Dec 2022
ECKCHAN@NTU.EDU.SG
14

Specifying Associations – Role and Attributes

Role: Optionally, each class end in an association can be labeled with a role

name

to indicate the role that the class plays in the association.

association may also have attributes.
An Aiman michael trompany

Example:

michael 72 iompanies

i t

onmany Person

Company 1 *

name name mienae

address El employer employee social security no.
address

Works-for

went
salary

E Peter job title

I E george

Dec 2022
on YMployees 15
ECKCHAN@NTU.EDU.SG

Binary Association – Example 1

For

example, we can uses a “Work-for” association to represent the
interactions

between companies and people working for them:

-- Each person works for one company.

-- Zero to many people work for each company

Company 1 Works-for *
Person

name name

social security no.
address

address

Dec 2022
ECKCHAN@NTU.EDU.SG
16

Binary Association – Example 2
For example, in the previous “Work for” association, if the interactions
specified has two attributes: salary and job title. We can refine the
association and also includes roles as follows:
Company 1 *
Person
name name
employer employee social security no.

address
address
Works-for
salary
job title
Dec 2022
ECKCHAN@NTU.EDU.SG
17

More Examples for Binary Association
File can be assessed by Otomany people A user can aim
File
O *
O * User Oto many
files
Accessible by
access permission
Meaning: each file is accessible by zero to many users and each user accesses zero to many files and the
accessibility is described by the attribute of the association, access permission
Person
Company 1 *
name
name boss
social security no.
address 0..1
address
Works-for worker *
salary
job title
Manage
performance rating
Note that Manage is an association that associates different objects of Person Class: Each boss manages
many
workers and each worker is managed by at most one boss
Dec 2022
ECKCHAN@NTU.EDU.SG
18

Ternary Association – Example

The

following association specifies a part used by a project supplied by a supplier,

and

the quantity used All must iontribute possibilities

Iprjl S1 P1

IF Project IFyp si pl

* Otomany

Supplier * * Part

Use

Quantity

This

information specified cannot be specified by a combination binary associations.

Quantity

is the amount of a part used in a project supplied by a supplier.

Dec 2022
ECKCHAN@NTU.EDU.SG
19

Relationship between Instance Structure and Multiplicity
in Association
✓ Similar to a class, an association that associates n classes specifies
a collection of links each of which associates exactly one object from
each class. Each link is called an instance of the association.
✓ Each instance of an association has identical properties represented
by the association.
✓ Examples will be given in the next few slides to further illustrate the
above- mentioned concepts.
Dec 2022
ECKCHAN@NTU.EDU.SG
20

Instance of Binary Association -- Example
In the “Work-for” binary association shown at the bottom of this slide, if there are three people
p1, p2 and p3 working for company c1, then there are three links (instances) to represent the
fact:
✓1st link: associates c1 and p1; 111 Pll
✓2nd link: associates c1 and p2; 1111172
✓3rd link: associates c1 and p3. 1111737
Each link is also called an instance of the “Work-for” association. Mathematically, these three
instances can be denoted as (c1, p1); (c1, p2); (c1, p3).
In the above association, if c2 is a newly formed company and has not employed any employee
yet, then c2 will not involve in any instance (or link) of the association.
Company 1 Works-for * Person
name name
social security no.
address
address
Dec 2022
ECKCHAN@NTU.EDU.SG
21

Instance of Ternary Association -- Example
In the “Use” ternary association shown at the bottom of this slide, as an illustration,
each following fact is represented by an instance of the “Use” association as follows:
✓ Project proj1 uses 30 pieces of part pt1 from vendor v1: this is described by the
instance of “Use” that associates v1, pt1 and proj1, with attribute Quantity = 30.
Mathematically, this instance is denoted as (v1, pt1, proj1) with attribute Quantity = 30.
instance of “Use” that associates v1, pt1 and proj2, with attribute Quantity = 10.
Mathematically, this instance is denoted as (v1, pt1, proj2) with attribute Quantity = 10.
instance of “Use” that associates v2, pt1 and proj2 with attribute Quantity = 20.
Mathematically, this is denoted as (v2, pt1, proj2) with attribute Quantity = 20.
Instances of Higher-Order Association – exactly the same as ternary association.
Project
Vendor Part
* *
Use
Quantity
Dec 2022
ECKCHAN@NTU.EDU.SG
22

Instance Structure and Multiplicity in Binary Association -- Example

Example – Based on the following binary association:

multiplicity

Company Works-for Person
1 *

a 92 I 3 Pl P 2 173 P4

same person Iannotwork for 2 wmpanies

Multiplicity has implication on the instance structure: If we know the instances of the associated
classes,

from the multiplicities, we can make some deduction on possible sets of instances of this
“Work-for”

association. For example, if at this moment, there are three companies, c1, c2 and c3,
and
four persons, p1, p2, p3 and p4, then:

◦
Some possible sets of instances of this association are:

◦ {(c1, p1), (c2, p2), (c3, p3), (c3, p4)}
seiginstances

◦ {(c1, p1), (c2, p2), (c2, p3), (c2, p4)}

◦
Some impossible sets of instances of this association are:
works

◦ {(c1, p1), (c2, p1), (c2, p2), (c3, p3), (c3, p4)}: this is not possible as p1 works for two
Zaniest companies - violate the “1” multiplicity at Company.

◦ {(c1, p1), (c2, p2), (c3, p3)}: this is not possible as p4 does not work for any company –

violate the “1” multiplicity at Company
Note

that the above possible and impossible sets are not exhaustive: There could be some more.

Dec 2022
ECKCHAN@NTU.EDU.SG
23

Instance Structure and Multiplicity in Ternary Association -- Example

Example – A Ternary Association R:

test

R alibi C

* 1

ah A a C

*

by B bi pas b4 4

195163,64

In the association R, from the multiplicity specified:

◦ For each combination of instances one from A and one from B, there is a

unique C instance associates with it.

◦ For each combination of instances one from A and one from C, there are

0 to many B instances associates with it.

◦ For each combination of instances one from B and one from C, there are

0 to many A instance associates with it.

Is

Dec 2022
ECKCHAN@NTU.EDU.SG
24

Instance Structure and Multiplicity in Ternary Association -- Example

Example – A Ternary Association R (Continued):

R

* 1

A C

*

B

Multiplicity has implication on the instance structure: Similar to binary association case, at any

point in time, if we know how many objects each class has, then we can deduce possible sets of
instances

of R.

For

example, if class A has one object, a1; class B has two objects, b1 and b2; class C has two
objects c1 and c2. Then:

◦ Some possible sets of instances of R are:

◦ {(a1, b1, c1), (a1, b2, c2)}

◦ {(a1, b1, c1), (a1, b2, c1)}

◦ Some impossible sets of instances of R are:

◦ {(a1, b1, c1), (a1, b1, c2)}: this is not possible as the combination of A and B object, a1 and
b2, does not associate with any C object - violate the “1” multiplicity at class C.

◦ {(a1, b1, c1), (a1, b2, c1), (a1, b2, c2)}: this is not possible as the combination of A and B

object, a1 and b2, associates with two C objects, c1 and c2 – violate the “1” multiplicity at

class C.

Dec 2022
ECKCHAN@NTU.EDU.SG
25

Aggregation – Meaning, Notation and Example
part andassembly
Aggregation is to represent part-and-assembly kind of association so that this special
type of association is differentiated from the general associations.
Each object (instance) of a “part” class is a part-of an object (instance) of the
“assembly” class
Document Assembly
1 do made
upofmany Meaning: each
Meaning (brief): para paragraph instance is a
Sentence is part-of * Parte

part of a document
paragraph and instance
paragraph is part-of Paragraph
document
1 A para is
anassembly Meaning: each sentence
of many
sentenies
instance is a part of a
* paragraph instance
Sentence
Dec 2022
ECKCHAN@NTU.EDU.SG
26

Generalization – Meaning and Notation

hierarchy
Generalization is to represent the type and sub-type kind of relationships between classes: A type is

further

classified into several sub-types.

type is represent by a class called the super-class in a generalization. Each sub-type is represented
The

one class called a subclass in the generalization.
by

object ofsub lass
Each object (instance) of a subclass is an object (instance) of the super-class.

is an objectofsuffy
A
subclass inherits all the properties and operations from the super-class, and can override them by
redefinition

if not applicable.

gvingthing
ton

Iggy

no
tank Ii object

Yass overriding
instance of

• Class Y inherits attribute x1 from class X. It overrides the attribute x2 inherited from class X
by redefining it. In addition, it also defines a new attribute y2. So, altogether class Y has three

attributes: x1 inherited from X, and x2 and y2 defined in Y itself.

• Class Z inherits attribute x1 and x2 from class X. It defines attribute z1. So, altogether class Z

has three attributes: x1 and x2 inherited from X, and z1 defined in Z itself.

• Each instance of Y and Z is an instance of X.

Dec 2022
ECKCHAN@NTU.EDU.SG
27

Generalization - Examples
EMPLOYEE
EmplNumb
X EmplName
superclass RegNew
f Salary
Y HOURLY SALARIED
EMPLOYEE
inherit
EMPLOYEE empinum
subclass class y Monthly Rate

HourRate emptname
g OverTime
Salary
Salary computed
• Y is a sub-type of X. differently
• There are two types employees, hourly employee and salaried employee.
• class Y has attributes x and y and operations f and g
• classes HOURLY and SALARIED inherit attributes EmplNumb and EmplName
and operations RegNew from superclass EMPLOYEE
• classes HOURLY and SALARIED define their own version of operation Salary
Dec 2022
ECKCHAN@NTU.EDU.SG
28

Instances of a Super-class and its Sub-classes

As
discussed earlier, each instance of a subclass is an instance of the super-class.

However,

the converse is not true. That is, an instance of a super-class may not be an
instance

of any of the sub-class.

example, in the following generalization: A NBS student is an instance of the super-class,
For
NTU

Student. But, he/she is not an instance of any of the two subclass (EEE Student, SCE
Student).

above fact is because the classification represented by a generalization is not an
The

exhaustive classification.

Note

that a generalization represents the relationship between type and sub-types. Such
relationship is in fact constructed from a classification.

instanceof new studentsmany

super last maynot beinstanceofsubclass

Meaning: EEE student

Albert Mary NBS
and SCE student are

types of NTU students

sub albert

class

Dec 2022
ECKCHAN@NTU.EDU.SG
29

How

to use association, aggregation, generalization, and their Instances (if any) to

model things?

Association:

to model a general type of interactions, for example:

◦ Suppliers ship products

◦ Teachers teach students

Instance

of Association: to model an individual interaction, for example:

◦ Dr C. K. Lee teaches an OO programming course

Aggregation:

to model a part-and assembly kind of interactions, for example:

◦ A personal computer has a CPU

◦ A book has many chapters

Instance of Aggregation: to model an individual part-and assembly, for example:

◦ The book titled “C programming for beginner authored by C. K. Lee” has 10 chapters

Generalization: to model a classification

◦ Students are classified into course work and research students

◦ Employees are classified into daily-rated and monthly-rated.

Dec 2022
ECKCHAN@NTU.EDU.SG
30

Comparison - Association, Aggregation and Generalization
rep of us
Dileaver
Aggregation Versus Association
◦Aggregation is a special form of association, not an independent concept.
◦The decision to use aggregation is a matter of judgment. Often it is not obvious if an association should be
modeled as an aggregation. If you exercise careful judgment and are consistent, the imprecise distinction
between aggregation and ordinary association does not cause problems in practice.
Association Versus Generalization
◦Association is not the same thing as generalization. Association relates instances. Distinct objects are
involved. Generalization relates classes and is a way of structuring the description of a single object. With
generalization, an object of a subclass is simultaneously an instance of the subclass and its super-class.
Aggregation
Versus Generalization: As an aggregation is also an association, so it has the above differences

between
association and generalization, in addition, it also has the following difference:
◦Aggregation is “a-part-of” relationship; generalization is “a-kind-of” or “is-a” relationship.
Dec 2022
ECKCHAN@NTU.EDU.SG
31

Example -- Comparing Association, Aggregation and Generalization
Meaning:
lecturers
teach
students
Meaning: Both tyre and
car engine are parts of
car
Dec 2022
ECKCHAN@NTU.EDU.SG
32

How to identify the types of relationships?
Properties
of Generalization, Aggregation and Association - Revisited:
✓ Generalization:
◦Each sub-class instance is also a super-class instance
◦Each sub-class is a sub-type of the super-class
◦Generalization does not describe connections of different objects (instances)
✓ Aggregation:
◦Each instance of a “part” class is a part-of an instance of the “assembly” class.
◦Aggregation describes connections (links), each of which connects different objects
✓ Association:
◦Association describes the connections (links), each of which connects different objects
How to determine whether a relationship type is a generalization, aggregation or association?
✓ First, check on above properties of Generalization. If it satisfies, then it is a Generalization
✓ If it does not satisfy the properties of generalization, then check on the above properties of
Aggregation. If it satisfies, then it is an aggregation.
✓ If it does not satisfy both the properties of Generalization and Aggregation, then it is an
association.
Dec 2022
ECKCHAN@NTU.EDU.SG
33

Example for using class diagram technique – The problem

Draw

a class diagram to model the structural properties of the program committee of an

international research conference organized as follows:

The

committee is formed by a program chair and more than twenty program committee
members.

The program chair manages the program committee. Each paper submitted
by
authors is managed by one program committee member and reviewed by four
reviewers.

A program committee member manages at least twelve papers. A reviewer
reviews

many papers. After the review of all the papers has been completed, a paper is
either

accepted or rejected. Authors may submit multiple papers.

dans T Tay

Vs

Dec 2022
ECKCHAN@NTU.EDU.SG
34

Example for using class diagram technique – The solution
relationship
paper
generalisation
paperon

Dec 2022
ECKCHAN@NTU.EDU.SG
35
Unit 4
UML Modeling II – Behavioral Modeling
- describes interactions between entities
- this unit covers the basic techniques for behavioral modeling in
UML: Use-Case Technique, State Diagram, Sequence Diagram and
L Activity Diagram ( activity diagram will be covered very briefly only).
- can be used for requirements specification, analysis and design
Requirements Specification
To describe the requirements gathered from users systematically, the major
techniques can be classified into the following types:
❑ An informal written document

❑ A set of models: a model comprises of graphical notations and texts to describe
requirements.
❑ A formal mathematical model: e.g., mathematical logic
❑ A collection of user scenarios: using use-cases that will be discussed shortly
❑ A prototype: using prototype as a means to describe requirements

Dec 2022
ECKCHAN@NTU.EDU.SG
2
Gathering Requirements from Users- Guidelines
Software engineers usually gather requirements from users through conducting
meetings/discussions. The guidelines for such meetings/discussions are as follows:
✓ meetings are conducted and attended by both software engineers and customers
✓ rules for preparation and participation are established
✓ an agenda is suggested
✓ a "facilitator" (can be a customer, a developer, or an outsider) controls the
meeting
✓ a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room or virtual forum) is used
✓ the goal is
◦ to identify the problem
◦ propose elements of the solution: business solution not software solution
◦ negotiate different approaches
Prioritization of requirements: prioritize the requirements for implementation according
to their importance, dependency, resources, etc.

Dec 2022
ECKCHAN@NTU.EDU.SG
3
Specifying Requirements
To specify requirements elicited.
The work product (also called output or deliverable) produced is called requirement
specification or requirement model.
As discussed earlier, there are many techniques for specifying requirements.
Use-case technique is the basic method to specify requirements in Object-Oriented
approaches.
It is the most commonly used technique for specifying software requirements.
Next, we shall study the use-case technique.

Dec 2022
ECKCHAN@NTU.EDU.SG
4
Use-Case Technique – Concept of Use-Case
A use-case is a collection of user scenarios for a usage of a system: A collection of related
interactions between a system and its external environment.
Specify each basic requirement (an independent usage) as a use-case.
Each scenario is described from the point-of-view of an “actor”— a person, device or any
external entity that interacts with the software in some way
Each scenario answers the following questions:
✓Who is the primary actor, the secondary actor (s)?
✓What are the actor’s goals?
✓What preconditions should exist before the story begins?
✓What main tasks or functions are performed by the actor?
✓What extensions might be considered as the story is described?
✓What variations in the actor’s interaction are possible?
✓What system information will the actor acquire, produce, or change?
✓What information does the actor supply to the system?
✓What information does the actor desire from the system?
✓Does the actor wish to be informed about unexpected changes?

Dec 2022
ECKCHAN@NTU.EDU.SG
5
Use-Case Technique
❑Specify each use-case using the template shown in the next two slides: some
slots in the template might be skipped where appropriate.
❑Give an overview of all the use-cases using a use-case diagram that will be
discussed after the use-case template.
❑The use-case diagram and a completed template for each use-case form a
Requirement Model (Requirements Specification).

Dec 2022
ECKCHAN@NTU.EDU.SG
6
Use-Case Template
A use-case has the following slots (those slots from priority onwards are usually optional)
to fill up:
✓ Use-case: name of the use-case

✓ Primary actor: the main user or actor
✓ Goal in context: the objective
✓ Preconditions: the property that must be satisfied before using the use-case
✓ Trigger: the action or event to start a use of the use-case
✓ Scenario: main interactions (the interactions when everything is smooth in the use)
between system and the actor in sequence
✓ Exceptions: errors and other behaviors.
✓ Priority: to indicate the prioritization.
✓ When available: to indicate the schedule.
✓ Frequency of use: to indicate the usage volume
✓ Channel to actor: to indicate the mechanism for the primary actor to interact with the
system.
✓ Secondary actors: to indicate all other users or actors who may need to access the use-
case
✓ Channels to secondary actors: to indicate the mechanism for secondary actors to interact
with the system.
✓ Open issues: issues/concerns that do not have a answer yet

Dec 2022
ECKCHAN@NTU.EDU.SG
7
Preparing Use-Case Description Example – Requirement
InitiateMonitoring is the following usage in SafeHome system:
✓The homeowner observes the control panel to determine if the system is ready. If
not, check all sensors to see which are open and close them.
✓The homeowner key in the password through the control panel. If the password is
incorrect, the control panel will beep once and reset for further trying. Otherwise, the
control panel awaits for further actions.
✓The homeowner selects and keys in stay or away. Stay activates only perimeter
sensors. Away activates all sensors.
✓When activation is successful, a red alarm light can be seen by the homeowner.

Dec 2022
ECKCHAN@NTU.EDU.SG
8
Use-Case Description Example – Completed Template (I)
Use-case: InitiateMonitoring
Primary actor: Homeowner.
Goal in context: To set the system to monitor sensors when the homeowner leaves the house or remains inside.
Preconditions: System has been programmed for a password and to recognize
various sensors.
Trigger: The homeowner decides to "set" the system, i.e., to turn on the alarm functions.
Scenario:
1. Homeowner: observes control panel.
2. Homeowner: enters password.
3. Homeowner: selects "stay" or "away."
4. Homeowner: observes red alarm light to indicate that SafeHome has been armed.
Exceptions:
errorsmistakes
1 . Control panel is not ready: homeowner checks all sensors to determine which are open; closes them.
2. Password is incorrect (control panel beeps once): homeowner reenters correct password.
3. Password not recognized: monitoring and response subsystem must be contacted to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors are activated.

Dec 2022
ECKCHAN@NTU.EDU.SG
9
Use-Case Description Example – Completed Template (II)
5. Away is selected: control panel beeps three times and an away light is lit; all sensors are activated.
Priority: Essential, must be implemented.

When available: First increment.
Frequency of use: Many times per day.
Channel to actor: Via control panel interface.
Secondary actors: Support technician, sensors.
Channels to secondary actors:
Support technician: phone line.
Sensors: hardwired and wireless interfaces.
open issues:
1 . Should there be a way to activate the system without the use of a password or with an abbreviated
password?
backdoor
2. Should the control panel display additional text messages?
3. How much time does the homeowner have to enter the password from the time the first key is pressed?
4. Is there a way to deactivate the system before it actually activates?

Dec 2022
ECKCHAN@NTU.EDU.SG
10
Use-Case Diagram
Each use-case in a system is represented by an ellipse.
Each human actor is represented by a human symbol.
Each of the remaining actors is represented by a rectangle.
Each system-user interaction is represented by a line connecting a use-case and
an actor.
The notations are illustrated in the next slide for a system that has five use-
cases.

Dec 2022
ECKCHAN@NTU.EDU.SG
11
Use-Case Diagram Example – System
A SafeHome security system has the following use-cases:
◦ Arms/disarms system
◦ Accesses system via internet
◦ Responds to alarm event
◦ Encounters on error condition
◦ Reconfigures sensors and related system features
I
Homeowner uses the first four use-cases and system administrator uses the last
one.
The last three use-cases also interact with sensors.

Dec 2022
ECKCHAN@NTU.EDU.SG
12
5 Use-Case Diagram Example – Diagram
I Ar ms / di s ar ms
s y s t em
non human
actor
2
Ac c es s es s y s t em s ens or s
v i a Int er net
homeow ner
numan 3
actor Res ponds t o
al ar m ev ent
4
Enc ount er s an
er r or c ondi t i on
human 5
Rec onf i gur es s ens or s
actor s y s t em
admi ni s t r at or and r el at ed
s y s t em f eat ur es

Dec 2022
ECKCHAN@NTU.EDU.SG
13
Validating Requirements
Key Criteria: rainingandnotraining not consistent
Consistency: all requirements consistent with each other? any conflict among them?
Completeness: all the requirements have been specified accurately? any missing
requirements?
Correctness: all requirements have been specified correctly? any misunderstanding?
Basic Task:
◼ Check the consistent through verifying the various parts of requirements
specifications against each others
◼ Check the correctness and completeness through review the requirements
specifications with users

Dec 2022
ECKCHAN@NTU.EDU.SG
14
Validating Requirements - Checklist
Is each requirement consistent with the overall objective for the
system/product?
Have all requirements been specified at the proper level of abstraction?
That is, do some requirements provide a level of technical detail that is
inappropriate at this stage? Is there any requirement that have not give
sufficient details?
Is the requirement really necessary or does it represent an add-on feature
that may not be essential to the objective of the system?
Is each requirement bounded and unambiguous?
Does each requirement have attribution? That is, is a source (generally, a
specific individual) noted for each requirement?
Do any requirements conflict with other requirements?

Dec 2022
ECKCHAN@NTU.EDU.SG
15
Validating Requirements - Checklist
Is each requirement achievable in the technical environment that will house the
system or product?
Is each requirement testable, once implemented?
Does the requirements model properly reflect the information, function and behavior
(processing) of the system to be built?
Has the requirements model been “partitioned” in a way that exposes progressively
more detailed information about the system?

Dec 2022
ECKCHAN@NTU.EDU.SG
16
State Machine Models
These model the behaviour of the system in response to external and internal
events.
They show the system’s responses to stimuli so are often used for modelling real-
time systems.
State machine models show system states as nodes and events as arcs between
these nodes. When an event occurs, the system moves from one state to another.
Statechart diagram is used in UML to represent state machine models.

Dec 2022
ECKCHAN@NTU.EDU.SG
17
Statechart Diagram
Statechart diagram is an extension of state diagram: it is a state diagram extended
with composite state to support decomposition.
Using a statechart, we can show a more complex state machine model
hierarchically from highest to the lowest level.
We can use statechart diagram to specify the behavior of any of the following:
◦ each object in a class
◦ a use-case describe
◦ an entire system the behaviour

Dec 2022
ECKCHAN@NTU.EDU.SG
18
The Elements of a Statechart Diagram
State - a set of observable circumstances that characterizes the behavior of a
software entity at a given time
State transition - the movement from one state to another
Event - an occurrence of which causes the software entity to exhibit some
predictable form of behavior
Action - process that will be activated as a consequence of event occurrence leading
to a state transition
Composite state - a state that is decomposed into lower-level states in a next lower
level statechart diagram

Dec 2022
ECKCHAN@NTU.EDU.SG
19
Statechart Diagram Notation
pointing to state transition
the start
state state
o state name trigger
entry/ action g causing transition

event
do/ activity
optional exit/ action action that occurs
new
state

Dec 2022
ECKCHAN@NTU.EDU.SG
20
Example - a Simple Photocopying Machine
Initially, the machine is free to read operator command.
When a user fills the document to be copied and presses the start button, the machine
invokes manage copying to start making copies for the users.
During the process of making copies,
◦ If paper jammed occurs, it will invoke problem diagnosis to direct user for necessary actions.
◦ When the copies are done, it will invoke read operator command to get ready for new
request.
After paper jammed is cleared, it will invoke read operator command to allow user to
start making copies again (continue).

Dec 2022
ECKCHAN@NTU.EDU.SG
21
Statechart diagram of a photocopying machine
event start
full and start y
invoke manage-copying reading
operator
commands full
copies done invoke
read-op-
ma Invoke read-op-input
input
making copies
reloading paper
empty
jammed invoke reload paper
invoke problem-diagnosis
problem state
not jammed
invoke read-op-input
Dec 2022
ECKCHAN@NTU.EDU.SG
22
Example - a Simple Microwave Oven
It has a switch to select full or half power, a numeric keypad to input the cooking time,
a start/stop button, and a numeric display.
The sequence of actions in using it is:
◦ Select the power level (half or full power).
◦ Input the cooking time using a numeric keypad.
◦ Press start and the food is cooked for the given time.
For safety reasons, it should not operate when the door is open and, on completion of
cooking, a buzzer is sounded. It has a very simple display for showing messages.
It starts from waiting state.

Dec 2022
ECKCHAN@NTU.EDU.SG
23
Statechart diagram of a microwave oven
full
Full Power
power
do/ set power
= 600 composite
or timer
number stat
got
Operation
Waiting full Set Time do/ operate
do/ display power oven
half do/ get Number
time exit/ set Time
power
start
half timer cancel
power Door Closed
0 Half Power Waiting
Enabled
door do/ display
do/ set power do/ display
open ‘Ready’
= 300 time
door
Exit
door closed
open
Disabled
do/ display
‘Waiting’

Dec 2022
ECKCHAN@NTU.EDU.SG
24
States and stimuli for the microwave oven (a)
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows the cooking time
selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Not
ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On
completion of cooking, the buzzer is sounded for five seconds. Oven light is on.
Display shows ‘Cooking complete’ while buzzer is sounding.

Dec 2022
ECKCHAN@NTU.EDU.SG
25
States and stimuli for the microwave oven (b)
Stimulus Description
Half power The user has pressed the half-power button.
Full power The user has pressed the full-power button.
Timer The user has pressed one of the timer buttons.
Number The user has pressed a numeric key.
Door open The oven door switch is not closed.
Door closed The oven door switch is closed.
Start The user has pressed the Start button.
Cancel The user has pressed the Cancel button.

Dec 2022
ECKCHAN@NTU.EDU.SG
26
Microwave oven operation (composite state)
Operation
time
Checking Cook
ok cooking
do/ check do/ run
status generator
turntable emitter fault timeout

fault
Alarm Done
do/ display do/ buzzer on for
event 5 secs
door open cancel
Disabled Waiting

Dec 2022
ECKCHAN@NTU.EDU.SG
27
How to construct Statechart Diagram?
Classify the behavior into types; and include a state to represent each type in a
state diagram
Identify all the changes between these states as state transitions and show all the
transitions in the state diagram
Identify the event that causes each state transition and the task that will be
performed during the transition, and include them in the state diagram.

Dec 2022
ECKCHAN@NTU.EDU.SG
28
Sequence Diagram
Sequence diagram is used for behavioral modeling
Sequence diagram is an “interaction diagram” that models a single scenario executing
in the system. It describes what happens during a use of the system. That is, it shows
how a use-case can be implemented. actors
objects
Sequence diagram has two axes:
◦ Horizontal: objects and the actors
◦ Vertical: time (from top to bottom)
Iim
Usage:
◦ Create a sequence diagram during requirements analysis to show how to implement each
use-case conceptually.
◦ Refine it in the design stage to form a design for the use-case.
I classdiagram
◦ The creation of sequence diagrams will lead to the identification of objects and associated
operations.

Dec 2022
ECKCHAN@NTU.EDU.SG
29
Sequence Diagram – Brief Introduction of the Notations
attributes
iampaign
a Fg
Mt lifeline
star start
if then
else
if then use Note: dashed arrows
give explanations
Dec 2022
ECKCHAN@NTU.EDU.SG
30
Creating Sequence Diagram and the Implication
We specify how to implement a use-case, conceptually first, then refine it to specify
final implementation.
To specify how to implement a use-case, we perform tasks on things (objects).
The responsibility for performing a task on a thing (an object) is delegated to the thing
(the object) by sending a message to it to request for a service (to perform the task).
From the sequence diagrams:
◦ Objects identified are specified by classes in a class diagram.
◦ Each message sends to an object implies that an operation is required to be
provided by the class that specifies the object: This is because the receiving
object needs to provide the operation to perform the task requested.
◦ The arguments and return type of a message implies the same for the operation
implied from the message. That is, the message protocol implies the operation
protocol.
◦ Hence, use-case implementation using sequence diagram leads to the discovery of
objects and associated operations.

Dec 2022
ECKCHAN@NTU.EDU.SG
31
Sequence Diagram – Example
Implement add a new Advert use-case:
✓Get the name of the client: Send a message getName() to Client object.
✓List all the campaigns for the client: Send a message listCampaigns() to Client object.
✓Get the details of each campaign: Send a message getCampaignDetails() multiple times to
Campaign object.
✓List all the advertisements for the selected campaign: Send a message listAdverts() to
Campaign object.
✓Get the details of each advertisement: Send the message getAdvertDetails() multiple times to
Advert object.
✓Add an new advertisement: Send a message addNewAdvert() to Campaign object.
✓Create an advertisement: Send the message Advert() to create a new Advert object, newAd

Dec 2022
ECKCHAN@NTU.EDU.SG
32
Example- Sequence Diagram

Dec 2022
ECKCHAN@NTU.EDU.SG
33
Example – Discovery of Objects and Operations from Sequence Diagram
The sequence diagram on slide 33 implies that:

▪ We must have objects of object types, Client, Campaign and Advert.
Hence, we have classes, Client, Campaign and Advert to model them
respectively.
▪ Client class must provide operations, getName() and listCampaign().
▪ Campaign class must provide operations, getCampaignDetails(),
listAdverts() and addNewAdvert().
▪ Advert class must provide operations, getAdvertDetails() and Advert().
The segment of sequence diagram on right-hand bottom corner of slide 30
implies that Request class must provide operation, Request(name: String,
cost: Money).

Dec 2022
ECKCHAN@NTU.EDU.SG
34
Brief Introduction to Activity Diagram
❑Very similar to flowchart
❑A tool in UML for providing a diagrammatic representation of procedural flow
❑An activity diagram shows the flow of actions (tasks)
❑It can be used to describe an use-case, the logic of an operation, or an entire
system.
❑It can be used in requirements capture, requirements analysis and design.
❑Next two slides will give a brief introduction of activity diagram through examples:
We shall only illustrate the notations as the creation of activity diagram is similar to
flowchart.

Dec 2022
ECKCHAN@NTU.EDU.SG
35
Activity Diagram – Example
3tries

Dec 2022
ECKCHAN@NTU.EDU.SG
36
Activity Diagram – Notation Illustration
time
same
m 4MS z nth
Dec 2022
ECKCHAN@NTU.EDU.SG
37
Unit 5
Unified Software Development Process (USDP)
‾ USDP is an Object-Oriented (OO) software development
methodology that uses the UML modeling techniques
discussed in the previous units from requirements capture
via design to implementation.
‾ This unit gives a brief introduction of USDP.
USDP - Overview
A software system is developed through carrying out the following processes iteratively
and incrementally:
◦ Requirements Capture
◦ Requirements Analysis
◦ Design
◦ Implementation
◦ Testing
Iteration is for:
◦ building or prototyping a part of the target system
◦ refining or correcting a part of the system or the whole system built in a previous
iteration
Incremental is for:
◦ building a system from small to large
◦ building a system from lower quality or performance to higher quality or performance

Dec 2022
ECKCHAN@NTU.EDU.SG
2
condition decision
sequence diagram useease
classes
USDP - Requirements Capture t
attributes
Requirements are defined in terms of use-cases. Each use-case describes a

way to use the target system.
A use-case diagram is drawn to give an overview of all the use-cases
developsequence diagram
Each use-case is specified by a use-case description using the template
discussed in Unit 4.
Activity diagram or statechart diagram can be used to supplement the
specification of complex use-cases:
◦ Activity diagram: for use-cases with complex procedure or logic
◦ Statechart diagram: for event and state intensive use-case.

Dec 2022
ECKCHAN@NTU.EDU.SG
3
USDP - Requirements Analysis
✓Each use-case is realized conceptually (that is, without taking the hardware
and operating environment into considerations) and specified by a
sequence diagram.
✓Other techniques such as activity diagrams and statechart diagrams can
also be used to supplement the sequence diagrams:
◦ Activity diagram: for use-cases with complex procedure or logic
◦ Statechart diagram: for event and state intensive use-case.
✓Objects required are discovered through the realization of use-cases.
Classes are constructed to represent the objects discovered. Messages
passed between objects are realized as operations to effect the messages.
✓If objects of an analysis class are state-event intensive, a statechart
diagram might be constructed to model the behavior of each object in the
class.
Dec 2022
ECKCHAN@NTU.EDU.SG
4
Illustrative Example - from Sequence Diagram to Class
Diagram
i
class class
J
operation

Dec 2022
ECKCHAN@NTU.EDU.SG
5
Illustrative Example - from Sequence Diagram to Class Diagram

Dec 2022
ECKCHAN@NTU.EDU.SG
6
Illustrative Example - from Sequence Diagram to Class Diagram
The sequence diagram on slide 5 implies that:
▪ We must have objects of object types, Client, Campaign and Advert.
Hence, we have classes, Client, Campaign and Advert to model them
respectively.
▪ Client class must provide operations, getName() and listCampaign().
▪ Campaign class must provide operations, getCampaignDetails(),
listAdverts() and addNewAdvert().
▪ Advert class must provide operations, getAdvertDetails() and Advert().
The segment of sequence diagram on right-hand bottom corner of slide 6
implies that Request class must provide operation, Request(name: String, cost:
Money).

Dec 2022
ECKCHAN@NTU.EDU.SG
7
System Analysis Versus Domain Analysis
◼ Requirements analysis can be classified into two types: system analysis and
domain analysis.
◼ When we carry out requirements analysis for a specific need. It is called
system analysis. For example, for the development of a subject registration
system for the School of EEE in NTU, we perform a system analysis for this
system.
◼ When we carry out requirements analysis for a family of similar systems (an
application domain). It is called domain analysis. In domain analysis, an
analyst is required to consider the requirements for all the systems in the
target domain. For example, when a software vendor wishes to develop an
application package for automating human resource activities, then he/she
must perform a domain analysis for human resource domain.
◼ Domain analysis must cater for the needs of any system in the domain of
concern. It targets to develop a system that can be used by many customers.

Dec 2022
ECKCHAN@NTU.EDU.SG
8
USDP - Design
✓For each use-case, the analysis realization of the use-case (specified by a
sequence diagram) is refined as a design realization of the use-case. The
design realization will take the implementation environment into
consideration. It is also specified by a sequence diagram.
✓Other techniques such as activity diagrams and statechart diagrams can
also be used to supplement the sequence diagrams:
oActivity diagram: for use-cases with complex procedure or logic
oStatechart diagram: for state-event intensive use-case.
✓Analysis objects are refined as design objects. New design objects might
also be discovered in the design realization of use-cases. The class
diagrams from the requirements analysis are refined to reflect the addition
and refinement.
✓If objects of a design class are state-event intensive, a statechart diagram
might be constructed to model the behavior of each object in the class.
Dec 2022
ECKCHAN@NTU.EDU.SG
9
USDP - Implementation and Testing
During implementation, the developers implement the designed classes as a
set of file components (source code) in the implementation model, from
which the executables such as Java classes, JavaBeans and ActiveX
components can be produced. The use-case guides the developers
determine the order in which to implement and integrate the components.
During the testing, the testers verify that the system indeed implements
functionality described in the use cases and satisfies the non-functional
requirements for the use cases (performance, reliability, etc.).

Dec 2022
ECKCHAN@NTU.EDU.SG
10
USDP Deliverables - Overview

Dec 2022
ECKCHAN@NTU.EDU.SG
11
Characteristics of USDP

Dec 2022
ECKCHAN@NTU.EDU.SG
12
Unit 6
Software Testing I --
Introduction and Functional Testing
❑Basic concepts on Software Testing blackbox white box
❑Three basic functional testing techniques
Dec 2022 DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL: ECKCHAN@NTU.EDU.SG; S2-B1B-51; TEL:67905377 1
How to Ensure Accuracy of Software?
❑For ensuring the accuracy of software, we perform Verification and
Validation (V&V)
a
❑Verification: Checking the consistency of an output in software
development with its input.
❑Validation: Assessing the degree to which a software system actually
fulfills its requirements, in the sense of meeting user’s real needs.
❑Software Testing plays an extremely important role in V&V.

Dec 2022
ECKCHAN@NTU.EDU.SG; S2-B1B-51; TEL:67905377
2
Software Testing - Definitions
Two Definitions:
Meyers: The process of exercising a
program with the specific intent of finding
errors prior to delivery to the end user.
IEEE: The process of exercising or evaluating a

system or system component by manual or
automated means to verify that it satisfies
specified requirements or to identify differences
between expected and actual results.

Dec 2022
3
Essence of Testing a set
case
of test
❑The essence of software testing is to determine a set ofydesign
test cases,
called a test suite, for the item to be tested.
❑What information should be in a test case:
✓Inputs: pre-conditions (circumstances that hold prior to test case
execution) and actual inputs that are identified by some testing method
✓Expected outputs: post-conditions (circumstances that hold after test
case execution) and actual outputs
❑Invalid and Unexpected Inputs:
✓Test cases must be written for INVALID and UNEXPECTED, as well as
valid and expected, inputs.
✓In many systems, MOST of the code is concerned with input error
checking and handling.

Dec 2022
4
Who Tests the Software?
Developer x independent tester

B
▪ 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
▪ Include test engineer and
end-user

Dec 2022
5
What is a “Good” Test?
A good test has a high probability of finding an error
A good test should be neither too simple nor too complex
A good test is not redundant.
A good test should detect the maximum number of errors.

Dec 2022
6
What Doe$ Te$ting Co$t?
About 50% of the total life-cycle effort is spent on testing.
About 50% of the total life-cycle time is spent on testing.

Dec 2022
7
Costs of Errors Over Life Cycle
The sooner an error can be found and corrected, the lower the cost for
developing software.
Costs can increase exponentially with time between injection and discovery.
COST
TIME

Dec 2022
8
When Might Testing Guarantee an
Error-Free Program?
When an “EXHAUSTIVE Testing” that includes the following
is achieved:
a. All the execution paths in codes are exercised

b. All combinations of possible input values are exercised
c. Some more….
The next two slides will show that in general exhaustive testing
is not possible.

Dec 2022
9
Exhaustive Testing is Exhausting
hit
as Y
Situation: input integer n
◦ The input to a module is two words with 32 bits each.

◦ Testing is completely automated: 100 nanoseconds are
required for each test case.
Question: How long would it take to test this module

exhaustively, i.e., covering every possible
combination of input values?

Dec 2022
10
Exhaustive Testing is Exhausting
(cont’d)
Short Answer: too long…
Proper Answer:
64 -9
2 X 100 X 10
⎯ ⎯ ⎯ ⎯ ⎯ ⎯ ⎯ ⎯ > 57,000 years!
3600 X 24 X 365

Dec 2022
11
Testing Techniques
Can be broadly classified into two types:
D
Black-Box Testing: Testing based solely on
analysis of requirements (unit/component
specification, user documentation, etc.). Also
know as functional testing. requirements
pof
D
White-Box Testing: Testing based on analysis
of internal logic (design, code, etc.). But
expected results still come from requirements.
Also known as structural testing.

Dec 2022
12
Black-Box Testing Characteristics
Testing based solely on analysis of requirements (specification, user
documentation, etc.). component
Also know as functional testing. unit test
Black-box testing techniques apply to all levels of testing: Testing must be
conducted to test unit, component, product, and system (all the four levels
of software hierarchy). Black-box testing can be applied to each level.
Black-box testing concerns techniques for designing tests; it is not a level
of testing.

Dec 2022
13
Black-Box Testing Characteristics (cont’d)
Testing the functionality

Testing the external characteristics (e.g., functions
provided, security defense, etc.)
Testing the external quality requirements (e.g.,
response time, etc.)
All user testing are black box testing

Dec 2022
14
Basic Black-Box Testing Techniques
Three basic and very important black-box

testing techniques will be covered in this
unit:
✓ Equivalence Class Testing memorise

✓
✓
Boundary Value Testing
Decision Table-Based Testing Jy

Dec 2022
15
Equivalence Class Testing
Idea is to partition the input space into a small number of equivalence
l
classes such that, according to the specification, every element of a given
class is “handled” (e.g., mapped to output, etc.) “in the same manner.”
If the program is implemented in such a way that being “handled in the same
manner” means that either:
✓every element of the class would be mapped to a correct output, or
✓every element of the class would be mapped to an incorrect output,
testing the program with just one element from each equivalence class would
be tantamount to exhaustive testing.

Dec 2022
16
Intuitive Illustration of Equivalence Class Construction
Input Space chose pick
representative to a
a
y
According to the specification, for each class (a block in
the diagram), each value (represented by a dot) in the
class is handled in the same way.

Dec 2022
ECKCHAN@NTU.EDU.SG; S2-B1B-51; TEL:67905377 17
Equivalence Class Testing (cont’d)
Two types of classes are identified: valid
(corresponding to inputs deemed valid from the
specification) and invalid (corresponding to inputs
deemed erroneous from the specification)
Technique is also known as partition testing.

Dec 2022
18
Finding Equivalence Classes
Based on the specification, for each input variable, divide its input space
into equivalence classes such that every element is handled in the same
way according to the specification.
x D y
Single input variable case: the equivalence classes for the only input
variable form the equivalence classes for the whole program.
Multiple input variables case:
x2
◦ Find equivalence classes for each individual input variable.
◦ The Cartesian product of each combination of above equivalence
classes, one for each input variable, forms a required equivalence class
for the whole program.
◦ Next slide will illustrate it through example.

Dec 2022
19
Illustration
Equivalence Classes of Multiple Input Variables Case
Three input variables: X, Y, Z
Equivalence classes:
oEquivalence class of X: X1, X2, X3
oEquivalence class of Y: Y1, Y2
oEquivalence class of Z: Z1
oSix equivalence class (3*2*1 = 6): represented by one Cartesian product
each
o X1* Y1 * Z1 = {(a, b, c)  a  X1, b  Y1 , c  Z1}
o X1* Y2 * Z1 = {(a, b, c)  a  X1, b  Y2 , c  Z1}
o X2* Y1 * Z1 = {(a, b, c)  a  X2, b  Y1 , c  Z1} 6 test as
o X2 * Y2 * Z1 = {(a, b, c)  a  X2, b  Y2 , c  Z1}
o X3* Y1 * Z1 = {(a, b, c)  a  X3, b  Y1 , c  Z1}
o X3* Y2 * Z1 = {(a, b, c)  a  X3, b  Y2 , c  Z1}
Dec 2022
20
Test Case Design
Find the equivalence classes for the program.

For each equivalence class, select a value from the class (any element from
the class).
Design a test case as follows:
✓Input = the value selected.
✓From the input, compute the expected output according to the
specification.

Dec 2022
21
Equivalence Class Testing programp
Example 1 T
now YYed
tinputvariabley
Specification: A program accepts hours worked by an employee from PC on weekly
basis. The hours worked will range in value from 0 to 40. If 0  hours worked  20, a
message “Low” should be displayed. If 20 < hours worked  40, a message “High”
should be displayed.
Four equivalence classes for Hours Worked: [0,20]; (20,40]; (-∞, 0); (40, ∞).
fid
Test Cases: pickone
◦ Hours Worked = 10; Message = “Low”
◦ Hours Worked = 40; Message = “High” invalid t
◦ Hours Worked = -10; Message = “Invalid”
◦ Hours Worked = 50; Message = “Invalid”

Dec 2022
22
Equivalence Class Testing – Example 2
Specification: A program computes the monthly commissions for salesmen
in a company. The monthly commission of a salesman is computed
according the following table based on his/her monthly sales total:
D Me
open Mse
I
gooseSales Total (MST)
Monthly Monthly Commission (MC)
0 ≤ MST < 200,000 0% of Monthly Sales Total

200,000 ≤ MST < 1,000,000 1% of Monthly Sales Total
one MST ≥ 1,000,000 2% of Monthly Sales Total
t
The monthly sales total that should never be in negative value is the input
variable of the program

Dec 2022
23
Equivalence Class Testing – Example 2 (Cont’d)
Four equivalence classes for MST: invalid
[0,200,000); [200,000, 1,000, 000); [1, 000, 000, ∞); (-∞, 0).
valid
I
Test Cases:
(1) Input: MST = 100,000;

Output: MC = 0
(2) Input: MST = 300,000; 101

1
Output: MC = 3,000
design of
(3) Input: MST = 2,000,000; 2 til test as
Output: MC = 40,000
(4) Input: MST = -100; Iinvalid

Output: Invalid Case

Dec 2022
24
Equivalence Class Testing – Example 3 (Multiple Input Variables)
▪ Specification for a city tax computation program:
The first input is a yes/no response to the question “Do you reside within
the city?” The second input is gross pay for the year in question.
A non-resident will pay 1% of the gross pay in city tax.
Residents pay on the following scale: resident
grosspay D tax
- If gross pay is not more than $30,000, the tax is 1%.
- If gross pay is more than $30,000, but not more than
$50,000, the tax is 5%.
- If gross pay is more than $50,000, the tax is 15%.

Dec 2022
25
Equivalence Class Testing -- Example 3
(Equivalence Classes for Each Input Variable)
dropdong
text
Gross_Pay
Res? A ◦ [0, 30K] (V) 101
◦ { yes } (V)
◦ { no } (V) ◦ (30K,50K] (V) 5
◦ { other } (I) ◦ > 50K (V) 15 t
◦ < 0 (I)

Dec 2022
26
Equivalence Class Testing -- Example 3 (Cont’d)
Cartesian product = the following 2-dimensional tables (as there are two input
variables).
There are twelve equivalence classes each of them is represented by one
box in the following table.
Gross_Pay
<0 [0, 30K] (30K, 50K] > 50K
yes Invalid 1% 5% 15%
Invalid 1% 1% 1%
Res? no
ifdropdown Invalid Invalid Invalid Invalid
others
Dec 2022
27
Equivalence Class Testing -- Example 3 (Cont’d)
Select any value from each class and design a test case for the
input value: So, we have the following twelve test cases:
1) input: Res = yes, Gross_Pay = -$1,000; Invalid case
2) input: Res = yes, Gross_Pay = $1,000; output: City Tax = $10 1010
5) input: Res = no, Gross_Pay = -$10; Invalid case
6) input: Res = no, Gross_Pay = $1,000; output: City Tax = $10 I 0lol
7) input: Res = no, Gross_Pay = $50,000; output: City Tax = $500 1 lol
8) input: Res = no, Gross_Pay = $51,000; output: City Tax = $510 11 lol
9) input: Res = ye, Gross_Pay = -$10; Invalid case
x city tax
10) input: Res = ye, Gross_Pay = $1,000; Invalid case
x city tax
11) input: Res = ye, Gross_Pay = $50,000; Invalid case
X City tax
12) input: Res = ye, Gross_Pay = $100,000; Invalid case X city tax

Dec 2022
28
Based on specification or requirement.
Boundary value testing focuses on the boundary of the input space to
identify test cases.
The rationale behind boundary value testing is that errors tend to occur near
the extreme values of an input variable.
Boundary value testing designs test cases to test the boundary values of
input conditions.

Dec 2022
29
Finding Boundary Values for an Input Condition
General Rule: Values exactly on the edges and values just miss the edges.
Range Case: For an input range bounded by a and b, test cases should
include values a and b and just below and just above a and b respectively.
Discrete Value Case: If an input condition specifies a set of discrete
numbers, test cases should be designed to exercise the minimum and
maximum numbers and values just below and above these limits.

Dec 2022
30
Boundary Values for Common Input Conditions
a bitlesser
than a
1. a ≤ X ≤ b ([a, b]): X=a-; a; b; b+. g
2. a ≤ X < b ([a, b)): X=a-; a; b.
3. a < X ≤ b ((a, b]): X=a; b; b+. keyside
4. X ≥ a ([a, )): X = a; a-.
5. X > a ((a, )): X = a.
6. X ≤ b ((-, b]): X = b; b+.
7. X < b ((-, b)): X = b.
8. X  {a1, ….. an}: X = min(a1, ….. an); X = min(a1, ….. an) -  ;
X = max(a1, ….. an); X = max(a1, ….. an) + .
**** Note: Here  is a small value
Example: 2 < X ≤ 100 ((2, 100]): X=2; 100; 101.
100 D
Dec 2022
31
Finding Boundary Values
stofve Single Input Variable Case
From the specification, extract the valid input conditions for the input
variable.
For each input condition, identify the boundary values.
Combine the boundary values identified for all the input conditions (remove
the repeated values) to form the boundary values for the input variable.
The resulting boundary values form the boundary values for the whole
program.

Dec 2022
32
Finding Boundary Values
Multiple Input Variables (n Input Variables) Case
Find the boundary values of each input variable as explained in the

previous slide.
Each combination of valid boundary values, one of each input variable,
forms a required boundary value (valid boundary value).
Each combination of one invalid boundary value of an input variable with
(n-1) valid boundary values, one of each remaining input variable, forms a
required boundary value (invalid boundary value).
definition
oftesting
invalid boundary
key V

Dec 2022
33
Designing Test Cases
From the specification or requirement, find the boundary values.

Design a test cases for each boundary value: Input value = the boundary
value; expected output is computed from the specification or
requirement.

Dec 2022
34
Boundary Value Testing -- Example 1
Specification: A program computes the monthly commissions for salesmen in a
company. The monthly commission of a salesman is computed according the
following table based on his/her monthly sales total:
Monthly Sales Total (MST) Monthly Commission (MC)

404
ten
0 ≤ MST < 200,000 0% of Monthly Sales Total
200,000 ≤ MST < 1,000,000 1% of Monthly Sales Total
MST ≥ 1,000,000 h 2% of Monthly Sales Total
O
close
The monthly sales total that should never be in negative value is the input
variable of the program

Dec 2022
35
Boundary Value Testing – Example 1 (Cont’d)
❑Input conditions: (1) 0 ≤ MST < 200,000; (2) 200,000 ≤ MST < 1,000,000;
(3) MST ≥ 1,000,000
❑Boundary Values for individual conditions: 0,200000
✓For input condition (1): MST = 0, -100, 200,000
✓For input condition (2): MST = 200,000, 199,900, 1,000,000 200000,1000
✓For input condition (3): MST = 1,000,000, 999,900
❑Required Boundary Values: MST = -100, 0, 200,000, 199,900, 1,000,000,
999,900.

Dec 2022
36
Boundary Value Testing – Example 1 (Cont’d)
Test Cases:
1) Input: MST = -100; Output: Invalid Case
2) Input: MST = 0; Output: MC = 0
3) Input: MST = 200,000; Output: MC = 2,000
4) Input: MST = 199,900; Output: MC = 0
5) Input: MST = 1,000,000; Output: MC = 20,000
6) Input: MST = 999,900; Output: MC = 9,999

Dec 2022
37
Boundary Value Testing – Example 2
Specification of a loan approval program:
The input, income of a customer and the number of houses mortgaged,
must be as follows: 1000,83333
✓ The income of a customer must be between $1000/month and
$83,333/month.
✓ The customer can have a loan for 1-5 houses.
Boundary Values for Individual Input Variables (from input conditions):
✓ Monthly income:. $1000/month (V) ; $83,333/month (V); $999/month
(I), $83,334/month (I) outside limit
range
✓ No of houses: 1 (V), 5 (V), 0 (I), 6 (I)

Dec 2022
38
Boundary Value Testing – Example 2 (Test cases)
Monthly income No of Result
Houses
$1,000 1 V
$83,333 1 V
$1,000 5 V
5
$83,333 5 V
$1,000 0 I
Walid
$1,000 6 I 1
$83,333 0 I
$83,333 6 I $1000/month $83, 333/month
$999 1 I
diagrammatical
$83,334
I 1 I
illustration of test
$999 5 I data
$83,334 5 I
Dec 2022
39
Decision Table-Based Testing
This technique is to explore on all feasible
combinations of input conditions.
Must test all the combinations of input conditions as
we never know how a program is coded.
This method is well suited for testing business rules.
This method is also called cause-effect testing.

Dec 2022
40
97811 b 5
974 be 8 FI
Decision Table-Based Testing – Test Case Design
ogicalcompound
From the specification or requirement, identify all basic input

conditions and output actions.
A decision table with the following is constructed:
◦ Conditions: represent the basic input conditions
◦ Actions: represent the basic output actions
A test case is designed for each rule (column) in the decision
table.

Dec 2022
41
Decision Table-Based Testing -- Example
Specification:
In the specification of a online stock trading program, the inputs to the
program are stock-name, quantity-to-buy and available fund in the
account. The buy order will be placed only if:
0
2
I
✓ Stock-Name: must be a valid listed company.
✓ Quantity-to-Buy: must be in the multiple of 1000.
✓ Available Fund: Must be sufficient, that is greater than sum of the
total cost and charges involved.
Otherwise, the buy order will not be placed.

Dec 2022
42
Decision Table-Based Testing – Example (Cont’d)
Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 Rule 7 Rule
8
Conditions
Valid No No No Yes No Yes Yes Yes

t t t t t
Stock? x o n
Valid No No Yes No Yes No Yes Yes

Quantity? o s 0 l o I
Sufficient No Yes No No Yes Yes No Yes
Funds?
o O 1 o
Actions
Buy? No No No No No No No Yes

Dec 2022
43
Decision Table-Based Testing – Example (Cont’d)
Design 2*2*2 = 8 test cases (1 for each rule) as follows :
1) For rule 1: stock name = “***”, qty = 0.2, Avail fund = 0; Buy = No
2) For rule 2: stock name = “***”, qty = 0.2, Avail fund = $10,000; Buy =
No
3) For rule 3: stock name = “XYZ”, qty = 1000, Avail fund = 0; Buy = No
4) For rule 4: stock name = “DBS”, qty = 300, Avail fund = $0; Buy = No
5) For rule 5: stock name = “WWW”, qty = 1000, Avail fund = $100,000;
Buy = No
6) For rule 6: stock name = “SingTel”, qty = 1002, Avail fund = $50,000;
Buy = No
7) For rule 7: stock name = “SingTel”, qty = 1000, Avail fund = $10; Buy
= No
8) For rule 8: stock name = “DBS”, qty = 1000, Avail fund = $100,000;
Buy = Yes
Dec 2022
44
Decision Table-Based Testing --- Rules With Interdependent Conditions
❑ In previous case, all the three basic conditions are independent, as such, we have
23 rules.
❑ If the basic conditions are interdependent, then the total number of rules will not
equal to the total number of combinations of condition values as the previous case.
❑ In the following case, as some of the conditions are interdependent, as such, we
only have 4 rules, but not 24 rules.
Rule 1 Rule 2 Rule 3 Rule 4

Conditions
X>5 Yes Yes No No

X≤5 No No Yes Yes
Y>2 Yes No Yes No
Y≤2 No Yes No Yes
Actions
……. …. …. …. …
Dec 2022
45
Conditions in Decision Table
▪ For the purpose of designing test cases, we can simply

include all the basic conditions in the decision table.
▪ The only disadvantage of the above method is that it may lead

to a large number of conditions in the decision table.
▪ If there are interdependencies between conditions, we can

eliminate some of them to get a minimal set of basic
conditions for the decision table.
▪ Next two slides discuss the method.

Dec 2022
46
as
How to Reduce the Set of Conditions to Minimal?
From the specification, identify all the basic conditions.
Check these conditions, one condition C at a time, and include it in the

decision table ONLY if:
▪ There is no conditions C1,….., Cn (n  1) that have already been
a
included in the table, such that, for each combination of values of
C1,….., Cn, the value of C can always be uniquely determined
(computed).
Finally, we have a minimal set of conditions for the decision table.

Dec 2022
47
Example – Finding Minimal Set of Conditions
Assuming we have the following basic conditions:

X > 5, X  5, Y > 2, Y  2
First, we include (X > 5) in the decision table straight away as there is no

conditions in the table yet.
Second, we check the next condition, (X  5), we find that based on the
condition (X > 5) in the table:
onionsa
▪ When (X > 5) = true, (X  5) always false
III'D
▪ When (X > 5) = false, (X  5) always true
that is, for each value of (X > 5), the condition considered, (X  5), can
always be uniquely determined. Hence, we do not include (X  5).
Y
Dec 2022 Dr Chan Chee Keong, School of EEE, NTU; email: eckchan@ntu.edu.sg; S2-B1B-51; Tel:67905377 48
Example – Finding Minimal Set of Conditions
Third, we check (Y > 2). For each value of the only condition (X > 5) in the
decision table, clearly, (Y > 2) can be any value (true or false). Hence, we
include (Y > 2) in the decision table.
Fourth, we check the next condition, (Y  2), we find that based on the
condition (Y > 2) in the table:
▪ When (Y > 2) = true, (Y  2) always false

▪ When (Y > 2) = false, (Y  2) always true
that is, for each value of (Y > 2), the condition considered, (Y  2), can always
be uniquely determined. Hence, we do not include (Y  2).
Hence, we only include {(X > 5), (Y > 2)} in the decision table
As a result, we have a minimal set of conditions for the decision table.
Dec 2022 Dr Chan Chee Keong, School of EEE, NTU; email: eckchan@ntu.edu.sg; S2-B1B-51; Tel:67905377 49
Unit 7
Software Testing II --
Structural Testing and Others
Introduce control flow graph
Introduce three basic structural testing techniques
Introduce basic structural coverage analysis for test suites
Briefly introduce approaches for overall testing
Dec 2022 DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL: ECKCHAN@NTU.EDU.SG; S1-B1B-51; TEL:67905377 1
convertfromprogram to IFG
mom
Control Flow Graph (CFG)
Control flow graph (CFG) shows the control flow between program
statements during execution.
CFG is a graph that is formed by nodes and edges.
Each node (circle) represents a sequence of statements that is always
executed from the first statement to the last statement sequentially during
program execution. Such sequence is called a basic block.
Each edge shows the flow between basic blocks. É
In a CFG, a node that has more than one outgoing edges is called a
decision node.
We can use a diamond to denote a decision node and circle to denote non-
decision node. But, variation is allowed.

Dec 2022
2
An Example to Illustrate Execution Flow
input
English
a assign
pseudorode
basiccondition
C
itdecision
then
machinecode
optional
Mitre

Dec 2022
3
Structured Constructs in CFG
similarto IF
LOOP
and and exitend exit
y
bygone

Dec 2022
4
How to construct CFG from code?
1) For structured programs, cut the code into basic blocks according to
the following rules:
◼ Cut out the while clause to form a basic block by itself. while
◼ Cut at the end of if, else, end-if and endwhile clauses. cutting blocks
In general, cut the code into basic blocks as follows:
Cut after each location (a statement or a clause) at which a jump to another
location not immediately after it may occur during program execution.
Cut before each location to which a jump from another location not
immediately before may occur during program execution.
Note that any sub-sequence of statements in a basic block is still a

basic block.
2) Represent each basic block as one node and show the flow between
basic blocks by edges between the nodes.
Dec 2022
5
Control Flow Graph of Program - Example
It

Dec 2022
6
A more complex control flow graph

Dec 2022
7
Structural Testing Techniques
▪ Structural testing techniques design test cases based on

program code.
▪ They design test cases from the flow graph of program.
▪ Each technique aims to cover certain aspects of programs.

Dec 2022
8
Basic Structural Testing Techniques
Three basic structural techniques will be covered in this unit:
◦ Statement Coverage
◦ Branch Coverage
bestone
◦ Basis Path Coverage

Dec 2022
9
Statement Coverage Testing
The objective of this technique is to design test cases to execute each statement in a
program at least once.
Note that as each node represents a basic block – a sequence of statements that is
always executed from the first statement to the last statement sequentially -- each
node is executed at least once implies that each statement is executed at least once.
This technique designs a test suite to execute each node in the CFG of a program at
least once as follows:
◦ Choose a set of paths through the CFG that pass through all the nodes.
◦ By defining appropriate input values, design test cases to execute all the above
paths: In order to execute a path, input values are defined to satisfy the conditions
of all the branches that the path follows.
Automated tool is required to apply this technique in practical cases.

Dec 2022
10
Statement Coverage Testing – Example
9 i inject input
in
ru
99th
1
4
xp tests
since y99
misstating
output
exit
A test suite for statement coverage testing of the above program (the design is explained in
the next slide):
✓ Test Case 1: Inputs: i = 99; y = -1; Expected Results: a=2, b=2

✓ Test Case 2: Inputs: i = 98; y = -1; Expected Results: a=3, b=3
This is not a minimal test suite to achieve statement coverage. Try to construct a minimal test
suite. DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL:
Dec 2022
11
Detailed Explanation of the Previous Example entry
1) A set of paths that pass through all the nodes:
{(1, 2, 3, 4, 6, 2, 7), (1, 2, 3, 5, 6, 2, 7)}
2 paths
2) A test suite for Statement Coverage Testing:
• Test Case 1 (to execute path (1, 2, 3, 4, 6, 2, 7)):
Inputs: i = 99, y = -1; Expected Results: a=2, b=2
Inputs: i = 99, y = 1; Expected Results: a=3, b=3
3) Instead of designing the above test suite, we can also design the following test suite for
Statement Coverage Testing:
a) Choose a set of paths with only one element: {(1, 2, 3, 4, 6, 2, 3, 5, 6, 2, 7)}
b) So, we design a test suite that has only the following test case to execute the only
path in the set:
Test case 1 (to execute path (1, 2, 3, 4, 6, 2, 3, 5, 6, 2, 7)): Inputs : i= 98, y = -1;
Expected results: a = 3, b =3
c) The latter test suite is a minimal test suite for Statement Coverage Testing.

Dec 2022
12
Branch Coverage Testing
Revisit the definition of decision node on slide 2: In a CFG, a node that has more than
one outgoing edges is called a decision node.
In a CFG, a branch is an outgoing edge at a decision node.
Branch coverage testing is to exercise each branch in the CFG of a program at least
once.
By defining input values, it designs a test suite to execute each branch in the CFG of a
program at least once:
◦ Choose a set of paths through the CFG that pass through all branches.
◦ By defining appropriate input values, design test cases to execute all the above
paths: In order to execute a path, input values are defined to satisfy the conditions of
all the branches that the path follows.

Dec 2022
13
Branch Coverage Testing -- Example
A test suite for branch coverage testing of the above program (the design is explained in the next
slide):
▪ Test Case 1: Inputs: i = 99; y = -1; Expected Results: a=2, b=2 (this forces through the
branch from node 3 to node 4 and both branches from node 2)
▪ Test Case 2: Inputs: i = 99; y = 1; Expected Results: a=3, b=3 (this forces through the
branch from node 3 to node 5 and both branches from node 2)
This is also not a minimal test suite to achieve branch coverage. Try to construct a minimal test
suite.
Dec 2022
14
Detailed Explanation of the Previous Example
1) The branches in the CFG are: (2, 3), (2, 7), (3, 4), (3, 5)
2) A set of paths that pass through all the branches:
{(1, 2, 3, 4, 6, 2, 7), (1, 2, 3, 5, 6, 2, 7)}
3) A test suite for Branch Coverage Testing :

Inputs: i = 99, y = -1; Expected Results: a=2, b=2
Inputs: i = 99, y = 1; Expected Results: a=3, b=3
4) Instead of designing the above test suite, we can also design the following test
suite for Branch Coverage Testing:
a) Choose a set of paths with only one element: {(1, 2, 3, 4, 6, 2, 3, 5, 6, 2, 7)}
b) So we design a test suite that has only the following test case to execute the
only path in the set:
Test case 1 (to execute path (1, 2, 3, 4, 6, 2, 3, 5, 6, 2, 7)):
Inputs i = 98, y = -1; Expected results: a = 3, b =3
c) Dec 2022
The latter test suite is a minimal
DR CHAN CHEE KEONG, test
SCHOOLsuite forEMAIL:
OF EEE, NTU; Branch Coverage Testing.
15
Relationship between Branch and Statement Coverage
Branch Coverage always implies Statement Coverage : This is because every
statement falls under one branch.
However, Statement Coverage does not imply Branch Coverage. The following
example illustrates this fact:
1
(1) read (x) n 3 F
T
if (x > 0) then
(2) x := x + 1
endif 2
(3) print (x)
▪ The following test suite of one test case provides statement coverage but not
branch coverage for the above program:
statement all
Test case 1: input: <x = 3>; expected output: <x = 4> covered
tested
butbranch i snot
The false-branch is not exercised ! (the details are explained in the next slide)
Dec 2022
16
Detailed Explanation of the Previous Example 1
F
T
1) Statement Coverage Testing:
a) A set of paths that pass through all the nodes: {(1, 2, 3)}
2
b) A test suite for Statement Coverage Testing:
Test case 1 (to execute path (1, 2, 3)):
Inputs: x = 3; Expected Results: x = 4 3
2) The above test suite does not execute the branch (1,3 ). Thus, it does not
provide branch coverage, and hence, it cannot be a test suite for branch
coverage testing.
3) For Branch Coverage Testing, we must design as follows:
need a tests
a) There are two branches: (1, 2), (1, 3).
b) A set of paths that pass through all the branches: {(1, 2, 3), (1, 3)}
c) A test suite for Branch Coverage Testing:
• Test Case 1 (to execute path (1, 2, 3)):
Inputs: x = 3; Expected Results: x = 4
• Test Case 2 (to execute path (1, 3)):
Inputs: x = 0; Expected Results: x = 0
Dec 2022
17
Basis Path Testing
In general, it is impossible to cover all the paths through the CFG of a

program (due to the possible existence of infinite number of paths).
The basic idea behind basis path testing is to identify an essential set of
paths through the CFG of a program based on some criteria.
By defining the input values, it designs a test suite to execute each path in
the essential set of paths at least once.

Dec 2022
18
Basis Path Testing
Memorise
✓ Design a test suite based on the following steps:
Step 1 — compute cyclomatic complexity, V(G) = E – N + 2, where N is the
total no of nodes and E is the total number of edges (more details will be
discussed shortly).
Step 2 — identify a basis set of linearly independent paths according to the
cyclomatic complexity (more details will be discussed shortly).
Step 3 —design a test case to force through each path identified in Step 2:
◦ In order to execute a path, input values are defined to satisfy the
conditions of all the branches that the path follows.
✓ Basis set of linearly independent paths is not unique. Thus, there could be
multiple basis sets of linearly independent paths.

Dec 2022
19
Basis Path Testing – Step 1
N 9
This method is based on the
determination of a basis set of
linearly independent paths
3 10 First, we compute the cyclomatic
86 9 complexity:
T y 7
5 V(G) = E – N + 2
6
= 11 - 9 + 2 = 4
The cyclomatic complexity tells the size (no. of

paths) of a basis set of linearly independent
paths in a control flow graph.
Dec 2022
20
Cyclomatic Complexity V(G)
A number of industry studies have indicated
that the higher V(G), the higher the probability
or errors.
modules
V(G)
modules in this range are

more error prone

Dec 2022
21
Basis Path Testing – Step 2:
Identify a Basis Set of Linearly Independent Paths
Informal Method:
pick a
◼ Firstly, include the shortest path
through the CFG in the set.
◼ Then, each time include a path
through the CFG in the set, based
on the previous path by making a
minimal change to the branches
followed, until all the reachable
nodes and edges have been
included.

Dec 2022
22
Basis Path Testing – Step 2: Example
0
We identify a basis set of
1 linearly independent paths
as follows:
2 Since V(G) = 4,
there are four paths
3
4
5 6 Path 1: 0,1,2,4,7,8
Path 2: 0,1,2,3,6,7,8
Path 3: 0,1,2,3,5,7,8
7 Path 4: 0,1,2,3,5,7,2,4,7,8

Dec 2022
23
Applying Basic Path Testing -- Example
V G E Nt 2
8 772
3 indeppath
CC = 3 and a basis set of linearly independent paths is: {(1, 2, 7), (1, 2, 3, 4, 6, 2,
7), (1, 2, 3, 5, 6, 2, 7)}
Fortestpath
Test cases:
Path (1, 2, 7): Inputs: i =101 y=1; Expected Results: a=1, b=1
Path (1, 2, 3, 4, 6, 2, 7): Inputs: i = 99; y = -1; Expected Results: a=2, b=2
Path (1, 2, 3, 5, 6, 2, 7): Inputs: i = 99; y = 1; Expected Results: a=3, b=3
Dec 2022
24
More on Execution Paths through CFGs
A path through a CFG is an alternative logic path to execute the program
represented by the CFG.
When a CFG has a loop, in total, there is an infinite number of paths through
the CFG. For example, in the following CFG, (1, 2, 7), (1, 2, 3, 5, 6, 2, 7), (1, 2,
3, 5, 6, 2, 3, 5, 6, 2, 7), (1, 2, 3, 5, 6, 2, 3, 5, 6, 2, 3, 5, 6, 2 , 7), ….…. , etc., are
all the paths through this CFG (in total, there is an infinite number of paths.
However, the following CFG has only 3 paths in a basis set of linearly
independent paths (discussed earlier).

Dec 2022
25
More on Execution Paths through CFGs
In the following CFG, the total number of paths through the CFG can be
computed as follows:
◦ Case 1: Without going through the loop in the CFG; = 1
◦ Case 2: Do not repeat the loop (i.e., go through the loop at most once) = (the total
number of paths for case 1) + 2 = 1 + 2 = 3
inside
Top apossibility
◦ Case 3: Repeat the loop at most once (i.e., go through the loop at most twice) = (the
total number of paths for case 2) + 2*2 = 3 + 4 = 7
◦ Case 4: Repeat the loop at most twice (i.e., go through the loop at most three times)
= (the total number of paths for case 3) + 2*2*2 = 7 + 8 = 15

Dec 2022
26
Note on Feasibility of Program Path
For all the program paths that we have encountered till now, we can always generate a
test case to force through them. However, this is not always the case.
Program paths can be classified into the following two types:
◦ Feasible Path: A path is said to be feasible if we can generate a test case to force
an execution through the path.
◦ Infeasible Path: A path is said to be infeasible if there is no input that can force an
execution through the path. Such path should be excluded in the test case design
when we apply structured testing techniques.
Example: GI E Nt2
7 6 2 3
1 4,126 cannot be tested

pom
• (1, 2, 3, 4, 5, 6)
and (1, 2, 4, 6)
410gyro are infeasible
Iannone paths in this CFG.

Dec 2022
27
Structural Coverage Analysis of Test Suites
The percentage of program artifact that a test suite has executed with respect to
each following coverage criterion is called the coverage of the test suite for the
criterion:
◦ Statement Coverage is the % of statements executed by a test suite.

◦ Branch Coverage is the % of branches executed by a test suite.
◦ Basis Path Coverage is the % of linearly independent paths executed by a test
suite.
It is easy to understand that if a test suite does not execute some codes, then
these codes are not tested at all. Therefore, coverage analysis is a good
measurement for measuring a test suite.
Coverage analysis is an important measurement adopted in the software

industry to manage the quality of testing:
◦ Commercialized software tools are available for measuring important coverage of a

test suite
◦ These tools automatically track the coverage when the test cases are executed.
Dec 2022
28
Coverage Analysis – A Simple Example
123467
▪ A Test Suite has only one test case to test the above program:
Inputs: i = 99; y = -1; Expected Results: a=2, b=2
▪ Statement Coverage = (12/14)*100% = 85.7%
(else, endif and endwhile are not statements, they are part of if and while statements)
▪ Branch Coverage = 75% (cover 3 out of 4 branches, the branch from node 3 to node 5
is not exercised )
▪ Basis path coverage = 33.33% (cover only 1 path out of 3 paths in a basis set of
linearly independent paths) DR CHAN CHEE KEONG, SCHOOL OF EEE, NTU; EMAIL:
Dec 2022
29
Findthe smallestunit
requires
drivers
a bottom daffy
Levels or Phases of Testing
Unit: testing of the smallest programmer work assignments that can reasonably be
planned and tracked (e.g., function, procedure, module, class, etc.)
Component: testing a collection of units that make up a component (e.g., program,

package, task, interacting object classes, etc.)
Product: testing a collection of components that make up a product (e.g., subsystem,

application, etc.)
System: testing a collection of products that make up a deliverable system.

Dec 2022
30
Process of Testing
Testing usually begins with functional (black-box) tests, supplemented by
structural (white-box) tests, working from the unit level toward the system level.
Waterfall Model of Testing Process:
Test Planning
Test Design
Test Implementation
Test Execution
Execution Analysis
Result Documentation
Final Reporting

Dec 2022
31
Higher-Level Testing
Component, product and system testing are all higher-level testing.
Higher-level testing begins with the integration of (already unit-tested)

modules to form higher-level program entities (e.g., components).
All higher-level testing can be viewed as various level of integration

testing.
The primary objective of integration testing is to discover interface

errors among the elements being integrated.
The basic functional and structural techniques can be applied to any

level of testing.

Dec 2022
32
Integration Testing
Integration testing is carried out when integrating (i.e., combining):
◦ Units or modules to form a component
◦ Components to form a product
◦ Products to form a system
The common strategies for integration testing are:
◦ Top-Down: top down according to invocation hierarchy
◦ Bottom-Up: bottom up according to invocation hierarchy
◦ Risk Driven
◦ Schedule Driven
◦ Function Driven
◦ Hybrid

Dec 2022
33
Testing OO Software
The basic functional and structural testing techniques can be applied.

Some features of object-oriented languages, however, require special
strategies and/or other considerations. These are not under the scope
of this subject.

Dec 2022
34
Other Types of Testing
Regression Testing: testing to detect problems caused by the adverse effects of
program change
Acceptance Testing: formal testing conducted to enable the customer to
determine whether or not to accept the system (acceptance criteria may be
defined in a contract)
Alpha: actual end-user testing performed within the development environment.
Beta: end-user testing performed within the user environment prior to general
release.

Dec 2022
35

IE4001 Software Engineering Course Overview: Eckchan@ntu - Edu.sg Elhchen@ntu - Edu.sg

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IE4001 Software Engineering Course Overview: Eckchan@ntu - Edu.sg Elhchen@ntu - Edu.sg

Uploaded by

Copyright:

Available Formats

IE4001 Software Engineering

Dr Chan Chee Keong Dr Chen Lihui

School of Electrical and Electronic School of Electrical and Electronic

Engineering Nanyang Technological

Email: eckchan@ntu.edu.sg Email: elhchen@ntu.edu.sg

Office: S1-B1B-51 Office: S1-B1C-96

❑ Part I: Week 1 – 7 by Dr Chan Chee Keong

✓ Software Requirements Analysis and Design

❑ Part II: Week 8 – 13 by Dr Chen Lihui

Continuous Assessments (CAs)

Part I – Software Requirements Analysis,

Design and Testing

Unit 1: Introduction to Software Engineering

Unit 2: Structured Methods for Requirements Analysis

Unit 3: UML Modeling I – Structural Modeling Q1 exam

Unit 4: UML Modeling II – Behavioral Modeling

Unit 5: Unified Software Development Process (USDP)

Unit 6: Software Testing I -- Introduction and Functional Testing

Unit 7: Software Testing II – Structural Testing and Overall Testing Approach

Proposed Study Method for Part I

not easy to read from books.

Keys for study Part I:

the lecture notes.

◦ It is also important for you to practice the tutorials.

❑ Definition of Software Engineering

❑ Role of Software Engineer

❑ Software Process Model

◦ Computer programs and associated documentation such as requirements, design

models and user manuals.

Software products may be

◦ Generic - developed to be sold to a range of different customers e.g. PC software

such as Excel or Word.

◦ Customised - developed for a single customer according to their specification.

New software can be created by developing new programs, configuring generic

software systems, reusing existing software or a combination of these.

education, defence etc.

Engineering is the application of engineering to develop quality software in a

way to meet the target objective.

◦ Software Development Methodology: Methods for developing software

of the security attacks exploit on software vulnerabilities)

◦ Software Reuse: Methods for reusing software.

◦ Software Testing: Theory and methods for testing software.

software development, etc.

Role of Software Engineer

❑ Programming is the basic essential skill but not enough

require the following important skills:

➢ Methods for specifying requirements and design

✓ these methods cover the creation and analysis of models

✓ Methods for testing systems to ensure their quality

➢ Good Knowledge on commonly used software (e.g., database management systems)

A process is defined as a collection of activities when some work product is to be to created.

complete the work products and other associated achievement.

In general, software processes comprises the following types of activities:

1.Communication: project initialization; requirements capture

3.Modeling: requirements analysis, design

4.Construction: coding, testing

5.Deployment: software delivery, evaluation and feedback.

In Part I, we shall focus on the important activities – Requirement Specification, Requirements

Analysis, Design and Testing

Software Process Models

objective, etc., and made more specific accordingly

Waterfall Model – The Process

Requirements gathering Planning