Module

1
Introduction to Software
Engineering

Lesson1
Basic Issues in Software
Engineerin

Decision tree
A decision tree gives a graphic view of the
processing logic involved indecision making
and the corresponding actions taken. The edges
of a decisiontree represent conditions and the
leaf nodes represent the actions to beperformed
depending on the outcome of testing the
condition.
Example: -
Consider Library Membership Automation
Software (LMS) where it should
support the following three options:

New member

Renewal

Cancel membership
New member option-
Decision: When the 'new member' option is
selected, the software asks details
about the member like the member's name,
address, phone number etc.
Action: If proper information is entered then a
membership record for the
member is created and a bill is printed for the
annual membership charge plus
the security deposit payable.
Renewal option-
Decision: If the 'renewal' option is chosen, the
LMS asks for the member's name
and his membership number to check whether
he is a valid member or not.
Action: If the membership is valid then
membership expiry date is updated and
the annual membership bill is printed, otherwise
an error message is displayed.
Cancel membership option-
Decision: If the 'cancel membership' option is
selected, then the software asks
for member's name and his membership
number.
Action: The membership is cancelled, a cheque
for the balance amount due to
the member is printed and finally the
membership record is deleted from the
database.
Version 2 CSE IIT, Kharagpur
Decision tree representation of the above
example -
The following tree (fig. 3.4) shows the graphical
representation of the above
example. After getting information from the
user, the system makes a decision
and then performs the corresponding actions.
Ask for member’s name, address, etc.
Create membership details
Prin
Fig. 3.4: Decision tree for LMS
Decision table
A decision table is used to represent the
complex processing logic in atabular or a matrix
form. The upper rows of the table specify the
variables orconditions to be evaluated. The
lower rows of the table specify the actions to
betaken when the corresponding conditions are
satisfied. A column in a table iscalled arule. A
rule implies that if a condition is true, then the
correspondingaction is to be executed.
Example: -
Consider the previously discussed LMS
example. The following decision table(fig. 3.5)
shows how to represent the LMS problem in a
tabular form. Here thetable is divided into two
parts, the upper part shows the conditions and
the lowerpart shows what actions are taken.
Each column of the table is a rule.
Cancellation
Invalid Option
User
Output
New Member
t Bill
Ask for membership details
Update expiry date
Print Bill
Renewal
Yes
Ask for membership details
Delete membership record
Print che
Valid selection?
que
No
Display error message
Version 2 CSE IIT, Kharagpur
Conditions
Valid selection
No Yes Yes Yes
New member
- Yes No No
Renewal
-
No Yes No
Cancellation
-
No No Yes
Actions
Display error message
x
-
-
-
Ask member's details
-
x
-
-
Build customer record
-
x
-
-
Generate bill
-
x
x
-
Ask member's name & membership number
-
-
x
x
Update expiry date
-
-
x
-
Print cheque
-
-
-
x
Delete record
-
-
-
x
Fig. 3.5: Decision table for LMS
From the above table you can easily understand
that, if the valid selectioncondition is false then
the action taken for this condition is 'display
errormessage'. Similarly, the actions taken for
other conditions can be inferred from the table.
Version 2 CSE IIT, Kharagpur
customer-address:
name + house# + street# + city + pin
name:
string
house#:
string
street#:
string
city:
string
pin:
integercustomer-id: integercustomer-
file:
{customer-address}*
bill:
{item + quantity + price}* + total-amount +
customer-address +
order#
material-issue-slip:
message + item + quantity + customer-address
message:
string
statistics:
{item + quantity + price}*
sales-statistics:
{statistics}* + date
quantity:
integer
order#:
integer /* unique order number generated by the
program */
price:
integer
total-amount: integer
generate-indent:
command
indent:
{indent + quantity}* + vendor-address
indents:
{indent}*
vendor-address:
customer-address
vendor-list: {vendor-address}*
item-file:
{item}*
item:
string
indent-request:
command
Commonly made errors while constructing a
DFD model
Although DFDs are simple to understand and
draw, students and practitionersalike encounter
similar types of problems while modelling
software problemsusing DFDs. While learning
from experience is powerful thing, it is an
expensivepedagogical technique in the business
world. It is therefore helpful to understandthe
different types of mistakes that users usually
make while constructing theDFD model of
systems.
Version 2 CSE IIT, Kharagpur
•
Many beginners commit the mistake of drawing
more than one bubblein the context diagram.
A context diagram should depict the system asa
single bubble.
•
Many beginners have external entities appearing
at all levels of DFDs.All external entities
interacting with the system should be
representedonly in the context diagram. The
external entities should not appear atother levels
of the DFD.
•
It is a common oversight to have either too less
or too many bubbles ina DFD. Only 3 to 7
bubbles per diagram should be allowed, i.e.
eachbubble should be decomposed to between 3
and 7 bubbles.
•
Many beginners leave different levels of DFD
unbalanced.
•
A common mistake committed by many
beginners whiledeveloping a DFD model is
attempting to represent control informationin a
DFD. It is important to realize that a DFD is the
data flowrepresentation of a system, and it does
not represent controlinformation. For an
example mistake of this kind:
o
Consider the following example. A book can be
searched in thelibrary catalog by inputting its
name. If the book is available inthe library, then
the details of the book are displayed. If the
bookis not listed in the catalog, then an error
message is generated.While generating the DFD
model for this simple problem, manybeginners
commit the mistake of drawing an arrow (as
shown infig. 5.10) to indicate the error function
is invoked after thesearch book. But, this is a
control information and should not beshown on
the DFD.
Fig. 5.10: Showing control information on a
DFD - incorrect
o
Another error is trying to represent when or in
what orderdifferent functions (processes) are
invoked and not representingthe conditions
under which different functions are invoked.
o
If a bubble A invokes either the bubble B or the
bubble C
depending upon some conditions, we need only
to represent the
Version 2 CSE IIT, Kharagpur
data that flows between bubbles A and B or
bubbles A and Cand not the conditions
depending on which the two modules
areinvoked.
•
A data store should be connected only to
bubbles through data arrows.A data store cannot
be connected to another data store or to
an external entity.
•
All the functionalities of the system must be
captured by the DFDmodel. No function of the
system specified in its SRS document shouldbe
overlooked.
•
Only those functions of the system specified in
the SRS documentshould be represented, i.e. the
designer should not assumefunctionality of the
system not specified by the SRS document
andthen try to represent them in the DFD.
•
Improper or unsatisfactory data dictionary.
•
The data and function names must be intuitive.
Some students andeven practicing engineers use
symbolic data names such a, b, c, etc.Such
names hinder understanding the DFD model.
Shortcomings of a DFD model
DFD models suffer from several shortcomings.
The important shortcomings of
the DFD models are the following:
•
DFDs leave ample scope to be imprecise. In the
DFD model, thefunction performed by a bubble
is judged from its label. However, ashort label
may not capture the entire functionality of a
bubble. Forexample, a bubble named find-book-
position has only intuitive meaningand does not
specify several things, e.g. what happens when
someinput information are missing or are
incorrect. Further, the find-book-position bubble
may not convey anything regarding what
happenswhen the required book is missing.
•
Control aspects are not defined by a DFD. For
instance, the order inwhich inputs are consumed
and outputs are produced by a bubble isnot
specified. A DFD model does not specify the
order in which thedifferent bubbles are
executed. Representation of such aspects is
veryimportant for modeling real-time systems.
•
The method of carrying out decomposition to
arrive at the successivelevels and the ultimate
level to which decomposition is carried out
arehighly subjective and depend on the choice
and judgment of theanalyst. Due to this reason,
even for the same problem, severalalternative
DFD representations are possible. Further, many
times it isnot possible to say which DFD
representation is superior or preferableto
another one.
Version 2 CSE IIT, Kharagpur
•
The data flow diagramming technique does not
provide any specificguidance as to how exactly
to decompose a given function into its sub-
functions and we have to use subjective
judgment to carry out decompositio

Pg-130, http://www.scribd.com/doc/14340261/Software-Engineering-Rajib-Mall