When drawing the lower level diagrams (level 1, level 2, and so on), please

keep
in mind the proper naming of the identifiers of your processes. If the parent
process has
the number one (1) as its identifier, the identifiers of the child processes
should be the
parent identifier, followed by a period and an arbitrary number (e.g. 1.1, 1.2,
1.3, etc.), as
shown in the next figure.
If for instance you’re to create another DFD level from the figure above (say,
process 1.1, the level 2 diagram should contain processes that have 1.1.1,
1.1.2, 1.1.3,
etc., as their identifiers. Also, keep in mind that when creating lower level
diagrams, you
have to consider its balance. The input and output data flows of the parent
DFD should
be maintained on the child DFD.
The following video provides a deeper explanation as well as a demonstration
on
how to create a level 0 diagram: Lecture 6 - DFD Diagram 0.mp4 You can
watch the video 54
Property of and for the exclusive use of SLU. Reproduction, storing in a retrieval system, distributing, uploading or posting online, or
transmitting in any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise of any part of this document, without the prior written
permission of SLU, is strictly prohibited.
until the 3:32 mark of the video, as the succeeding parts are no longer
necessary for this
topic. However, you can still choose to watch its entirety if you want to learn
how to create
a DFD using CASE tools.
Process Description Tools
Process Description, as the name implies, documents the details of a
functional
primitive, and represents a specific set of processing steps and business
logic. System
analysts and developers often choose from several approaches when
developing a
process description:
●
Modular Design - which is based on combinations of three logical structures
(also known as control structures), which serve as building blocks for the
process,
●
Structured English - is derived from structured programming language which
gives more understandable and precise description of process. It is based on
procedural logic that uses construction and imperative sentences designed to
perform operation for action.
○
It is best used when sequences and loops in a program must be considered
and the problem needs sequences of actions with decisions.
○
It does not have strict syntax rules. It expresses all logic in terms of
sequential decision structures and iterations.
For example, see the following sequence of actions:
●
Decision Tables – which are logical structures that shows every combination
of conditions and outcomes, and
●
Decision Trees – which are graphical representations of the conditions,
actions, and rules found in a decision table.55
Property of and for the exclusive use of SLU. Reproduction, storing in a retrieval system, distributing, uploading or posting online, or
transmitting in any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise of any part of this document, without the prior written
permission of SLU, is strictly prohibited.
Logical and Physical Models
While structured analysis tools are used to develop a logical model for a new
information system, such tools also can be used to develop physical models
of an
information system. A physical model shows how the system’s requirements
are
implemented.
Sequence of Models
Many systems analysts create a physical model of the current system and
then
develop a logical model of the current system before tackling a logical model
of the new
system. Performing that extra step allows them to understand the current
system better.
Four-Model Approach
This approach is widely used by many systems analysts and developers when
creating an information system. As the name implies, the analysts first
develop a physical
model of the current system, next a logical model of the current system, then
a logical
model of the new system, and finally, a physical model of the new system.
The only
disadvantage of the four-model approach is the added time and cost.