International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
97
system’s major processes, data flows and data stores at a high level of detail. Every process in
the level n-1 data flow diagram would be decomposed into its lower-level data flow diagram
which is level n data flow diagram. The key principle in data flow diagram is to ensure
balancing which means that the data flow diagram at one level is accurately represented in the
next level data flow diagram when developing a project. The ideal level of decomposition is to
decompose the system until system analysts and users can provide a detailed description of the
process whereby the process descriptions is not more than one page. The final set of data flow
diagrams is validated for ensuring quality. In general, there are two types of problems that can
occur in data flow diagrams which are syntax errors and semantics errors. Semantics errors are
more complicated than syntax errors due to a set of rules that need to be followed in order to
identify them. For example, every process has at least one input data flow and every process has
at least one output data flow. Therefore, understanding the set of rules for data flow diagrams is
important. Once the rules are understand, a tool can be developed based on the rules so that the
tool can perform consistency check between context diagram to level 0 data flow diagram. The
tool is also able to perform grammatical errors checking within or across data flow diagrams in
order to achieve consistency. By using this tool, the correctness and reliability of data flow
diagrams can be increased.
3.
RELATED WORK
According to Lucas et al. [2], consistency problems have existed in Information System
development since its beginning and are usually linked to the existence of multiple models or
views which participate in the development process. Tao and Kong [5] state that a data flow
diagram is visual and informal, hence, it is easy to learn and use. However, its informality
makes it difficult to conduct formal verification of the consistency and completeness of a data
flow diagram specification.
Dixit et al. [4], on the other hand, defined data flow diagram consistency is the extent to which
information contained on one level of a set of nested data flow diagram is also included on other
levels. According to Tao and Kong [5], the child data flow diagram that results from
decomposition is consistent with the precedence relation for the parent process and does not
introduce additional precedence relationships between the input and output flows of the parent
process. Recently, many systems have been developed to provide automatic support for data
flow diagrams specifications. However, all of these systems are lack the ability to manipulate
the semantics of data flow diagram specification [6]. Research done by Lee and Tan [7] cover
the modelling of DFD using Petri Net model. In their research, they check consistency of the
DFDs by enforcing constraints on their Petri Net model. Tong and Tang [6], on the other hand,
model the DFD using temporal logic language. A method for checking consistency for Unified
Modelling Language (UML) specification, on the other hand, has been done for example in [2],
[8] and [9].
Various researches also stated that no formal language has been currently used for semantic
specification of data flow diagram ([1], [6], and [10]). However, Tao and Kong [6] point out
that there are few development environments or CASE tools provide automated verification
facilities that can detect inconsistency and incompleteness in a data flow diagram specification.
Dixit et al. [4] therefore describe that the concept of data flow diagram consistency is refers to
whether or not the depiction of the system shown at one level of a nested set of data flow
diagram is compatible with the depictions of the system shown at other levels. They also state
that a consistency check facility with a CASE tool will be helpful for the practitioners.
Consistency in process decomposition, on the other hand, means that the precedence relation is
faithfully inherited by the child data flow diagram [5]. Ahmed Jilani et al. [1], on the other