In system development life cycle (SDLC), a system model can be developed using Data Flow Diagram(DFD). DFD is graphical diagrams for specifying, constructing and visualizing the model of a system.DFD is used in defining the requirements in a graphical view. In this paper, we focus on DFD and itsrules for drawing and defining the diagrams. We then formalize these rules and develop the tool based onthe formalized rules. The formalized rules for consistency check between the diagrams are used indeveloping the tool. This is to ensure the syntax for drawing the diagrams is correct and strictly followed.The tool automates the process of manual consistency check between data flow diagrams.
Figures - uploaded by Rosziati Ibrahim
Author content
All figure content in this area was uploaded by Rosziati Ibrahim
Content may be subject to copyright.
Discover the world's research
- 20+ million members
- 135+ million publications
- 700k+ research projects
Join for free
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
DOI : 10.5121/ijsea.2010.1406 95
FORMALIZATION OF THE DATA FLOW DIAGRAM
RULES FOR CONSISTENCY CHECK
Rosziati Ibrahim and Siow Yen Yen
Department of Software Engineering, Faculty of Computer Science and Information
Technology, Universiti Tun Hussein Onn Malaysia (UTHM),
Parit Raja, 86400, Batu Pahat, Johor Malaysia
rosziati@uthm.edu.my
yenyen0831@hotmail.com
A
BSTRACT
In system development life cycle (SDLC), a system model can be developed using Data Flow Diagram
(DFD). DFD is graphical diagrams for specifying, constructing and visualizing the model of a system.
DFD is used in defining the requirements in a graphical view. In this paper, we focus on DFD and its
rules for drawing and defining the diagrams. We then formalize these rules and develop the tool based on
the formalized rules. The formalized rules for consistency check between the diagrams are used in
developing the tool. This is to ensure the syntax for drawing the diagrams is correct and strictly followed.
The tool automates the process of manual consistency check between data flow diagrams.
K
EYWORDS
Consistency Check, Context Diagram, Data Flow Diagram, Formal Method
1.
I
NTRODUCTION
System development life cycle (SDLC) is an essential process uses during the development of
any system. SDLC consists of four main phases. They are planning, analysis, design and
implementation. During analysis phase, context diagram and data flow diagrams are used to
produce the process model of a system. A consistency of the context diagram to lower-level data
flow diagrams is very important in smoothing up developing the process model of a system.
However, manual consistency check from context diagram to lower-level data flow diagrams
using a checklist is time-consuming process [1]. At the same time, the limitation of human
ability to validate the errors is one of the factors that influence the correctness and balancing of
the diagrams [2]. This paper presents a technique for modeling data flow diagram rules and
proposes a formalization of its rules. The tool is then developed based on the formalized rules.
The purpose for the development of a tool is to automate the manual consistency check between
data flow diagrams (DFDs) based on the rules of DFDs. The tool serves two purposes: as an
editor to draw the diagrams and as a checker to check the correctness of the diagrams drawn as
well as consistency between diagrams. The consistency check from context diagram to lower-
level data flow diagrams is automated to overcome the manual checking problem.
The motivation of formalizing the rules of data flow diagrams is because DFD has been used in
a widely basis for modeling any system but still lacking a precise understanding. Therefore, by
formalizing the DFD rules, we can get a formal model of DFD rules. This formal model can be
used to ensure that the diagrams drawn are correct and they are consistent with each other.
The rest of this paper is organized as follows. The review of DFD is in Section 2 and the
discussion on the related works is in Section 3. Section 4 discusses the syntax and semantics
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
96
rules of DFD and Section 5 formalizes the DFD rules. The development of the tool is discussed
in Section 6 and finally, Section 7 concludes the paper.
2.
OVERVIEW OF DFD
SDLC is a process uses during the development of software system starting from planning until
the implementation phase. Data flow diagramming, on the other hand, is used to produce the
process model during the analysis phase [3]. Process model is very important in defining the
requirements in a graphical view. Therefore, the reliability of the process model is the key
element to improve the performance of the following phases in SDLC.
SDLC is also used to understand on how an information system can support business needs,
designing the system, building the system and delivering the system to users [3]. SDLC consists
of four fundamental phases, which are analysis, design, implement and testing phases. In the
analysis phase, requirements of a system are identified and refined into a process model.
Process model can be used to represent the processes or activities that are performed in a system
and show the way of data moves among the processes. In order to diagram a process model,
data flow diagramming is needed. Dixit et al. [4] define data flow diagram as a graphical tool
that allows system analysts and users to depict the flow of data in an information system.
Normally, the system can be physical or logical, manual or computer based. Data flow diagram
symbols consist of four symbols which are processes, data flows, data stores and external
entities. The standard set of symbols that will be used in this paper is devised by Gane and
Sarson symbols in [3]. Table 1 shows these symbols.
Table 1 : Symbols for DFD elements in [3]
Symbol Element Name
Process
Data Flow
Data Store
External Entity
In data flow diagram, the highest-level view of the system is known as context diagram. The
next level of data flow diagram is called the level 0 data flow diagram which represents a
Name
D1
Name
Name
Name
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
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
98
hand, state that notations used in the data flow diagram are usually graphical and different tools
and practitioners interpret their notations differently. Therefore, a well-defined semantics or
data flow diagram formalism could help to reduce inconsistencies and confusion.
This paper formalizes important DFD rules to address the consistency issues in DFD. Our
research focuses on consistency check between data flow diagrams and develops a tool to
automate a consistency check between data flow diagrams based on the formal notations used
for the DFD rules.
4.
SYNTAX AND SEMANTIC RULES OF DFD
Data flow diagrams are illustrated movement of data between external entities and the processes
and data stores within a system [11]. According to Donald and Le Vie [12], data flow diagrams
are a tool that can reveal relationships among and between the various components in a program
or system. Tao and Kong [5], on the other hand, stated that data flow diagram technique is
effective for expressing functional requirements for large complex systems. Definition 1 gives
the definition of data flow diagram where there are four symbols in the data flow diagram which
are processes, data flows, data stores and external entities (source/sink). In general, there are
two commonly used styles of symbols in data flow diagram as described in [3] and [4]. For our
research, we will use Gane and Sarson symbols as described in [3] which appear in Table 1.
Definition 1: A Data Flow Diagram consists of:
• Processes
• Data Flows
• Data Stores
• External Entites
where
- A process is an activity or a function that is performed for some specific business reason;
- A data flow is a single piece of data or a logical collection of several pieces of
information;
- A data store is a collection of data that is stored in some way;
- An external entity is a person, organization, or system that is external to the system but
interact with it.
The highest-level of data flow diagram is known as the context diagram. According to Jeffrey et
al. [8], a context diagram is a data flow diagram of the 10 scope of an organizational system that
shows the system boundaries, external entities that interact with the system and the major
information flows between the entities and the system. Dennis et al. [3] state that the context
diagram shows the overall business process as just one process and shows the data flows to and
from external entities. Data stores are not usually included on the context diagram. The context
diagram therefore is decomposed into the lower-level diagram which is level 0 data flow
diagram. In fact, each process on the level 0 data flow diagram can be decomposed into more
explicit data flow diagram, called level 1 diagram and can be further decomposed into next
lower-level diagram when it is needed. In general, there are two fundamentally different types
of problems that can occur in data flow diagrams which are syntax errors and semantics errors.
Tao and Kong [5] defined the syntax of the data flow diagram is how components are
interconnected through data flows and what components constitute the subsystem being
modeled. The semantics of the data flow diagram, on the other hand, is how data flows are
interrelated in terms of data transformations. Dennis et al. [3] claimed that syntax errors are
easier to find and fix than are semantics errors because there are clear rules that can be used to
identify them. There is a set of rules that must be followed by analysts when drawing data flow
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
99
diagrams in order to evaluate data flow diagrams for correctness [12]. Definition 2 until
Definition 8 stated these rules.
Definition 2: Rules of data flow diagrams:
• At least one input or output data flow for external entity
• At least one input data flow and/or at least one output data flow for a process
• Output data flows usually have different names than input data flows for a process
• Data flows only in one direction
• Every data flow connects to at least one process
Definition 3: Unique name in data flow diagrams:
• A unique name (verb phase), a number and a description for a process
• A unique name that is a noun and a description for a data flow
• A unique name that is a noun and a description for data store
• A unique name that is a noun and a description for external entity
Definition 4: Consistency:
• Every set of data flow diagrams must have one context diagram.
Definition 5: Consistency Viewpoint:
• There is a consistency viewpoint for the entire set of DFDs.
Definition 6: Decomposition:
• Every process is wholly and completely described by the processes on its children DFDs.
Definition 7: Balancing:
• Every data flow, data store and external entity on a higher level DFD is shown on the
lower-level DFD that decomposes it.
Definition 8: Data Store:
• For every data store, data cannot move directly from one data store to another data store.
• Data must be moved by a process.
Definitions 2 until 8 explain the fundamental rules of data flow diagrams. The consistency
between context diagram and data flow diagram is very important and the rules for these
consistency is captured in Definitions 4 and 5. Following on the consistency issue, Definition 6
addresses aspect on decomposition of the processes to its lower level of DFD and Definition 7
addresses aspect of balancing of DFD elements to its lower level of DFD. Syntax rules are used
to verify syntax errors within the DFD. The syntax rules are defined in Definition 9.
Definition 9: Syntax rules of data flow diagram:
• At least one input data flow for a process
• At least one output data flow for a process
• Process from external entity cannot move directly to another external entity
• At least one input data flow for a data store
• At least one output data flow for a data store
• Data from one data store cannot move directly to another data store
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
100
Based on Definition 9, six syntax rules are used in order to verify the correctness of the context
diagram and level 0 data flow diagram. However, the syntax rules of data store only applied in
level 0 data flow diagram. Semantics rules are used to verify semantics errors from context
diagram to level 0 data flow diagram. The semantics rules are defined in Definition 10.
Definition 10: Semantic rules of data flow diagram:
• The total number and name of external entities in context diagram are the same as in level
0 DFD
• The total number and name of data flows between process and external entity in context
diagram are same as level 0 DFD
• The total number and name of external entities in level 0 DFD are same as context diagram
• The total number and name of data flows between process and external entity in level 0
DFD are the same as in context diagram
The semantics rules defined in Definition 10 are used to perform consistency check from
context diagram to level 0 data flow diagram. We then formalize the DFD rules and represented
them using mathematical notations in order to better understand the rules. Similar approach for
formalization of DFDs is in [6] and [7], where Tong and Tang [6] use temporal logic language
and Lee and Tan [7] use Petri Net model. Gao and Huaikou [13], on the other hand, integrate
structured approach with object-oriented approach and suggest a formal language using Z
notations for predicate data flow diagram (PDFD). The formalization of DFD rules is discussed
in next section.
5.
FORMALIZATION OF DFD RULES
This section formalizes the important DFD rules based on the syntax and semantics rules of
DFD given in Section 4. The mathematical notations are used, for better understanding of the
DFD rules.
Rule 1. Let D be a data flow diagram, then
D = {P, F, S, E} (1)
where
P = {p
1
, p
2
, p
3
…, p
m
} is a finite set of processes;
F = {f
1
, f
2
, f
3
…, f
m
} is a finite set of data flows;
S = {s
1
, s
2
, s
3
…, s
m
} is a finite set of data stores;
E = {e
1
, e
2
, e
3
…, e
m
} is a finite set of external entities;
Rule 1 defines the data flow diagram. Data flow diagram consists of a set of processes, data
flows, data stores and external entities.
Rule 2. Let C be a context diagram then
mkjikjefppfeC
ikji
,,1,},,,,,,{
11
(2)
Rule 2 defines the context diagram. Context diagram consists of one process only and a set of
external entities and data flows. Data flow can be connected from external entity to a process
and vice versa but the data flow must be a different data flow. Note that, data store can only
exist in data flow diagram but not context diagram.
Rule 3.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
101
mji, 1 ,,,
jiji
ppPpp
(3)
From Rule 3, the name of the process is unique. For any process, no duplication is allowed. The
same rules apply for data flows (Rule 4), data stores (Rule 5) and external entities (Rule 6). The
name is unique and duplication of name is not allowed.
Rule 4.
mjifFff
jji
,1,f ,,
i
(4)
Rule 5.
mjissSss
jiji
,1,,,
(5)
Rule 6.
m j i, 1 ,e,,
j
iji
eEee
(6)
Rule 7.
mjifDfCf
jji
≤≤=∈∃∈∀ ,1,f , ,
i
(7)
Rule 7 indicates that for any data flow that belongs to context diagram, that data flow must exist
in data flow diagram. The same rule applies to external entity. That is, for any external entity
that belongs to context diagram, that external entity must exist in data flow diagram (Rule 8).
Rule 8.
mjieDeCe
jji
,1,e , ,
i
(8)
Rule 9.
Dfssee
kjiji
,,,,
, then (9)
},,{ ><≠
jki
efeD
and
},,{ ><≠
jki
sfsD
,
mkji
,,1
Rule 9 indicates that for any data flow diagram, a data flow cannot connect from one external
entity to another external entity and a data flow cannot also connect from one data store to
another data store.
Rule 10.
Dfse
kji
,,
, then (10)
},,{ ><≠
jki
sfeD
and
},,{ ><≠
ikj
efsD
,
mkji
,,1
Rule 10 indicates that for any data flow diagram, a data flow cannot connect from one external
entity to data store and a data flow cannot also connect from one data store to external entity.
Rule 11.
Dffsp
kjii
∈∀ ,,,
, then (11)
},,{
iji
sfpD
and
},,{
iki pfsD
,
mkjiff
kj
,,1,,
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
102
Rule 11 indicates that for any data flow that connect from process to data store, another data
flow can connect from data store to process but must be different from the previous used data
flow.
Rule 12.
Dffpe kjii ∈∀
,,,
, then (12)
},,{
iji
pfeD
and
},,{
iki efpD
,
mkjiff
kj
,,1,,
Rule 12 indicates that for any data flow that connect from external entity to process, another
data flow can connect from process to external entity but must be different from the previous
used data flow.
Rule 13.
Dffpp kjji ∈∀
,,,
, then (13)
},,{
jji
pfpD
and
},,{
ikj
pfpD
,
mkjiff
kj
,,1,,
Rule 13 indicates that for any data flow that connect from one process to another process,
another data flow can connect from another process to previous process but must be different
from the previous used data flow.
6.
THE TOOL
The tool is developed based on the set of rules imposed by data flow diagrams as described in
Section 5. A graphical layout is used in order to use the tool as an editor for drawing the
diagrams and as a checker as well to check the correctness of the diagrams. Figure 1 shows the
main interface of the tool.
Figure 1. Interface of the Tool
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
103
From Figure 1, the main interface provides a platform that allows the user to input both
diagrams by using the data flow diagram elements provided. The main interface includes four
main parts where the top of the interface is the menu bar consists of five menu functions, the
toolbar of the data flow diagram elements is in the left-side of the interface, the bottom-right is
an error list text box and a "Consistency Check" button. The rest of interface is the drawing
panel for user to draw the particular diagram. The five functions in menu bar are open a new
file, open a saved file, save the data flow diagrams, print the data flow diagrams and open a help
menu. In the toolbar, there are four data flow diagram elements which are process, external
entity, data flow and data store. User is allowed to drag and drop the data flow diagram
elements on the drawing panel. "Consistency Check" button, on the other hand, is used to
perform the consistency check after both diagrams are created. Therefore, the tool serves two
purposes. The first purpose is as an editor for drawing the context diagram and level 0 data flow
diagram and the second purpose is as a checker for checking the consistency between context
diagram and level 0 data flow diagram.
In this paper, we give one simple example of an academic information system and use the tool
to represent the context diagram and its level 0 of data flow diagram. Figure 2 shows the
example of the context diagram for a lecturer who is going to use the Academic Information
System (AIS). A lecturer can send his or her academic information to the system and can get a
list of academicians from the system.
Figure 2. Example of Context Diagram
In reference to Figure 2, using Rule 2, the AIS consists of 1 entity, 1 process and 2 data flows.
That is,
},,,,,{
121111
efppfeC
. The context diagram also follows Rule 4 for the
uniqueness of data flow name. From context diagram, a level 0 data flow diagram can be drawn
as shown in Figure 3.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
104
Figure 3. Example of Level 0 Data Flow Diagram
Based on Figure 3, level 0 data flow diagram for AIS consists of 2 processes, 1 external entity, 1
data store and 5 data flows. That is,
},,,,,,,,,,,,,,{
351143332223212
pfssfppfpefppfeD
Data flow diagram follows Rules 3 until 6 for uniqueness name used. For data flow, Rule 7 is
also followed. However, for external entity, Rule 8 is not followed. That is, if there exist
external entity in context diagram, that external entity must exist in data flow diagram.
Therefore, the data flow diagram consists of syntax errors.
The tool verifies the syntax errors for all the data flow diagram elements used. When there is
any syntax errors exist in the data flow diagram elements, the tool displays an error message to
user. Figure 3 shows an existence of syntax error from the data flow diagram. Since the entity
from context diagram is Lecturer, the tool informs the inconsistency between context diagram
and data flow diagram. The user can then use the editor of the tool to correct the syntax error. If
the entity is correct, the tool validates the consistency check as shown in Figure 4.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
105
Figure 4. Consistency Check
Based on Figure 4, level 0 data flow diagram consists of the correct external entity. That is,
},,,,,,,,,,,,,,{
351143332123211
pfssfppfpefppfeD
Data flow diagram described in Figure 4 follows Rule 8. That is the external entity exists in
context diagram as well as in data flow diagram. The tool verifies that both diagrams are
consistent.
Once the diagrams are drawn, they can be saved to a new or existing folder. The tool allows the
user to save and print the diagrams. The user can open the folder again for viewing or editing of
the diagrams. The user can also print the diagrams. The Help menu can be used for getting more
information regarding the tool.
The development of the tool also incorporated the rules for syntax errors. Rules 9 until 12 are
also implemented inside the tool. For example, if a user wants to draw a data flow from one
external entity to another external entity, the tool prompts a syntax error indicating that such
connection cannot be done. Figure 5 shows the example of it.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
106
Figure 5. Example of Syntax Error for Rule 9.
Figure 5 shows that if a user wants to connect a data flow from one external entity to another
external entity, the tool prompts a syntax error indicating that the drawing cannot be done. The
same goes to other rules such as Rule 10. The tool prompts a syntax error if a user tries to
connect a data flow from external entity to data store.
We demonstrate another example of using our tool to represent the context diagram and its level
0 of data flow diagram. Figure 6 shows the example of the context diagram for a student who
wants to borrow book using the Library System (LS). A Student can send his or her list of book
to borrow to the system and can get a list of book that is available for him or her to borrow from
the system.
Figure 6. Context Diagram for Library System (LS)
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
107
In reference to Figure 6, using Rule 2, the LS consists of 1 process, 3 entities and 6 data flows.
The context diagram also follows Rule 4 for the uniqueness of data flow name. From context
diagram, a level 0 data flow diagram can be drawn as shown in Figure 7.
Figure 7. Example of Level 0 Data Flow Diagram
Based on Figure 7, level 0 data flow diagram for LS consists of 3 processes, 3 entities, 1 data
store and 10 data flows. Data flow diagram follows Rules 3 until 6 for uniqueness name used.
For external entity, Rule 8 is followed. However, for data flow, Rule 7 is not followed. That is,
if there exist data flow in context diagram, that data flow must exist in data flow diagram.
Therefore, the data flow diagram consists of syntax errors.
The tool validates the syntax errors for all the data flow diagram elements used. When there is
any syntax errors exist in the data flow diagram elements, the tool displays an error message to
user. Figure 7 shows an existence of syntax error from the data flow diagram. Since the data
flow from context diagram is <check list>, the tool informs the inconsistency between context
diagram and data flow diagram. The user can then use the editor of the tool to correct the syntax
error. If the data flow is correct, the tool can also be used for the consistency check. Figure 8
shows that the diagrams (context diagram and level 0 data flow diagrams) are consistent.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
108
Figure 8. Consistency Check
Based on Figure 8, level 0 data flow diagram consists of the correct data flow. Data flow
diagram follows Rule 7. That is the data flow exists in context diagram as well as in data flow
diagram. The tool will verify that both diagrams are consistent.
Once the diagrams are drawn, they can be saved to a new or existing folder. The tool allows the
user to save and print the diagrams. The user can open the folder again for viewing or editing of
the diagrams. The user can also print the diagrams. The Help menu can be used for getting more
information regarding the tool.
The development of the tool also incorporated the rules for syntax errors. Rules 9 until 12 are
also implemented inside the tool. For example, if a user wants to draw a data flow from one
external entity to data store, the tool prompts a syntax error indicating that such connection
cannot be done. Figure 9 shows the example of it.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
109
Figure 9. Example of Syntax Error for Rule 10.
Figure 9 shows that if a user wants to connect a data flow from one external entity to data store,
the tool prompts a syntax error indicating that the drawing cannot be done. The same goes to
other rules such as Definition 9. The tool prompts a syntax error if a user tries to connect a data
flow from external entity to data store. The tool ensures the correctness of the diagrams drawn
and the balancing of every data flow and external entity between context diagram with level 0
data flow diagram.
7.
C
ONCLUSIONS
This paper has discussed how to model a business process flow using data flow diagrams and
presented a set of syntax and semantics rules of data flow diagrams. The rules are then being
formalized and used to automate the process of checking the consistency between the context
diagram and level 0 data flow diagrams. The automatic checking of consistency overcomes the
time-consuming process of manually checking the correctness of the diagrams. The developers
can use the tool for drawing and designing their process model of the system that they want to
develop.
The tool serves two purposes. The first purpose is as an editor to draw the diagrams and the
second purpose is as a checker to check the correctness of the diagrams drawn as well as
consistency between the diagrams. Our tool has several advantages. First, we can minimize the
syntax errors when drawing the diagrams since the tool prevents the user from making such
errors. Second, the correctness of diagrams is guaranteed since the consistency check between
diagrams are also done via the tool.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
110
A
CKNOWLEDGEMENTS
This research is supported by the Science Fund under Ministry of Science, Technology and
Innovation (MOSTI), Malaysia.
R
EFERENCES
[1] Ahmed Jilani, A. A., Nadeem, A., Kim, T. H. and Cho, E. S. (2008). Formal Representations of the Data
Flow Diagram: A Survey. Proc. of the 2008 Advanced Software Engineering and Its Applications.
Washington, USA: IEEE Computer Society. pp. 153-158.
[2] Lucas, F.J., Molina, F. and Toval, A. (2009). A Systematic Review of UML Model Consistency
Management. Information and Software Technology, 51(12), pp. 1 – 15.
[3] Dennis, A., Wixom, B.H. and Roth, R.M. (2006). Systems Analysis and Design. 3rd ed. Hoboken: John
Wiley & Sons, Inc.
[4] Dixit, J. B. and Kumar, R. (2008). Structured System Analysis and Design. Paperback ed. New Delhi, India:
Laxmi Publisher.
[5] Tao, Y.L. and Kung, C.H. (1991). Formal Definition and Verification of Data Flow Diagrams. Journal of
Systems and Software, 16(1), pp. 29-36.
[6] Tong, L. and Tang, C.S. (1991). Semantic Specification and Verification of Data Flow Diagrams. Journal
of Computer Science and Technology, 6(1), pp. 21-31.
[7] Lee, P.T and Tan, K.P. (1992). Modelling of visualized data-flow diagrams using Petri Net Model.
Software Engineering Journal, January 1992, pp. 4-12.
[8] Kim, D.H. and Chong, K. (1996). A Method of Checking Errors and Consistency in the Process of Object-
Oriented Analysis. Proceedings of the 1996 Third Asia-Pacific Software Engineering Conference. Korea:
IEEE Computer Society. Pp. 208-216.
[9] Rosziati Ibrahim and Noraini Ibrahim. A Tool for Checking Conformance of UML Specification.
Proceedings of the 2009 World Academic of Science and Technology (WASET), Volume 51 (v51-45),
pp262-266.
[10] Leavens, G.T., Wahls, T. and Bakar, A.L. (1999). Formal Semantics for SA Style Data Flow Diagram
Specification Languages. Proceedings of the 1999 ACM Symposium on Applied Computing. Oregon, US:
IEEE Computer Society. pp. 526–532.
[11] Jeffrey, A. H., George, J.F. and Valacich, J.S. (2002) Modern Systems Analysis and Design . 3rd ed. US:
Prentice-Hall.
[12] Donald, S. and Le Vie, Jr. (2000). Understanding Data Flow Diagram. Proceedings of the 47th annual
conference on Society for Technical Communication. Texas: Integrated Concepts, Inc.
[13] Gao Xiaolei and Huaikou Miao. (2008). The Axiomatic Semantics of PDFD. Proceedings of the 2008
Japan-China Joint Workshop on Frontier of Computer Science and Technology, IEEE Computer Society,
pp. 139-146.
International Journal of Software Engineering & Applications (IJSEA), Vol.1, No.4, October 2010
111
Authors
Rosziati Ibrahim is with the Software Engineering
Department, Faculty of Computer Science and
Information Technology, Universiti Tun Hussein
Onn Malaysia (UTHM). She obtained her PhD in
Software Specification from the Queensland
University of Technology (QUT), Brisbane and her
MSc and BSc (Hons) in Computer Science and
Mathematics from the University of Adelaide,
Australia. Her research area is in Software
Engineering that covers Software Specification,
Software Testing, Operational Semantics, Formal
Methods, Data Mining and Object-Oriented
Technology.
Siow Yen Yen is a student at the Department of
Software Engineering, Faculty of Computer
Science and Information Technology, Universiti
Tun Hussein Onn Malaysia (UTHM), Batu Pahat,
Johor, Malaysia.
... As a well-defined systematic approach is the main benefit of the engineering approach, software development life cycle (SDLC) is an essential process for the development of software, which consists of defining a sequence of different activities and phases. They are requirements analysis, design, coding, testing, and maintenance [3]. ...
The study of software engineering professional practices includes the use of the formal methodology in a software development. Identifying the appropriate methodology will not only reduce the failure of software but will also help to deliver the software in accordance with the predetermined budget and schedule. In literature, few works have been developed a tool for prediction of the most appropriate methodology for the specific software project. In this paper, a method for selecting an appropriate software development life cycle (SDLC) model based on a ranking manner from the highest to the lowest scoring is presented. The selection and ranking of appropriate SDLC elaborate the related SDLC's critical factors, these factors are given different weights according to the SDLC, then these weights are used by the proposed mathematical method. The proposed approach has been extensively experimented on a dataset by software practitioners who are working in the software industry. Experimental results show that, the proposed method represents an applicable tool in predicting and ranking suitable SDLC models on various types of projects, such as: life-critical systems, commercial uses systems, and entertainment applications. Keywords: Agile Incremental ITerative Scrum SDLC Spiral Waterfall This is an open access article under the CC BY-SA license.
... While there are different strategies, researchers are able to utilise a strategy within another strategy. For example, a study that involves a case study strategy can include an experimental strategy included [41]. e selection among various strategies can be guided or influenced by the philosophy, approach, and the kind of questions that a study aims to answer. ...
Medication errors related to medication administration done by both doctors and nurses can be considered a vital issue around the world. It is believed that systematisation and the introduction of main documents are done manually, which might increase the opportunities to have inaccuracies and errors because of unexpected wrong actions done by medical practitioners. Experts stated that the lack of pharmacological knowledge is one of the key factors, which play an important role in causing such errors. Doctors and nurses may face problems when they move from one unit to another and the medication administration list has changed. However, promoting public health activities and recent AI-enabled applications can provide general information about medication that helps both doctors and nurses administer the right medication. However, such an application can require a lot of time and effort to search and then find a medication. Therefore, this article aims to investigate whether AI-enabled applications can help avoid or at least minimize medication error rates.
... To illustrate a general description of a system that shows the activities that occur between the system and its entities, a Data Flow Diagram (Context Diagram) is created to specifying, constructing, and visualizing the system in a model [9]. The context diagram explained that there are two users involved in the system, namely Admin and Manager. ...
... In addition to these flow typing constraints, we adopt some common rules from the DFD literature for well-formed B-DFDs: diagrams may not contain loops (flows with identical source and target activators) , activators cannot be isolated (disconnected from all other activators), and processes must have at least one incoming and outgoing flow (see e.g. Falkenberg et al., 1991;Ibrahim et al., 2010;Dennis et al., 2018). • if n : proc then n ∈ S(G) and n ∈ T (G) • if n : ext or n : db then n ∈ S(G) or n ∈ T (G) ...
- Hanaa Alshareef
- Sandro Stucki
-
![Gerardo Schneider]()
Recent regulations, such as the European General Data Protection Regulation (GDPR), put stringent constraints on the handling of personal data. Privacy, like security, is a non-functional property, yet most software design tools are focused on functional aspects, using for instance Data Flow Diagrams (DFDs). In previous work, a conceptual model was introduced where DFDs could be extended into so-called Privacy-Aware Data Flow Diagrams (PA-DFDs) with the aim of adding specific privacy checks to existing DFDs. In this paper, we provide an explicit algorithm and a proof-of-concept implementation to transform DFDs into PA-DFDs. Our tool assists software engineers in the critical but error-prone task of systematically inserting privacy checks during design (they are automatically added by our tool) while still allowing them to inspect and edit the. PA-DFD if necessary. We have also identified and addressed ambiguities and inaccuracies in the high-level transformation proposed in previous work. We apply our approach to two realistic applications from the construction and online retail sectors.
... The purpose of decomposition is to break down the system to create a security and privacy profile based on areas of vulnerability for security and privacy. The framework uses the DFDs decomposition levels presented in research by [56] and [6]. The DFDs hierarchical levels are: Level 0 -context diagram, system as a single entity; Level 1 -more detailed DFD through refinement of the system; Level 2 -more complex systems requiring decomposition of some components with annotations; Level 3further decomposition of complex systems. ...
The General Data Protection Regulation has propelled privacy to an equal requirement with security for data protection. A key regulation requirement is data protection by design and a corresponding data protection impact assessment that details security and privacy by design for a project processing data. Security and privacy of data in the Internet of Medical Things (IoMT) handles sensitive health data and accordingly is bound by additional regulatory safety, security and privacy requirements. Health data in the IoMT can potentially flow through a diversity of apps, systems, devices and technologies, open networks. This exposes the transmitted data in the IoMT to additional attack surfaces and consequently increases on the need for security and privacy. Applying security and privacy regulatory requirements is a struggle for developers in small to medium enterprises due to a lack of knowledge, understanding, training, experience and financial constraints. This paper proposes a framework aimed at developers in small to medium enterprises, to assist in meeting regulatory requirements for security and privacy of data in flow in the IoMT. This framework expands on the basic established threat modeling steps to apply both security and privacy properties to protect data in flow in the IoMT. The framework includes a set of categorised technical security and privacy controls developed through medical device security standards to mitigate identified security and privacy threats. This framework also provides a foundation for the administration of a data protection impact assessment.
... The more you know about the system, the easier it is to uncover threats (Meier et al., 2003). The framework applies the DFDs decomposition levels presented in research by (Ibrahim & Yen, 2010) and Dhillon (2011). The DFDs hierarchical levels are: Level 0 context diagram, system as a single entity; Level 1 more detailed DFD through refinement of the system; Level 2 more complex systems requiring decomposition of some components with annotations; Level 3 further decomposition of complex systems Dhillon (2011). ...
... In addition, it is used to visualize data processing (structured design).It shows what type of information enters (input) or leaves (output) the system, where it comes from and where it is stored. However, it does not indicate the timing of data transmissions, nor order in which data flows [26]. ...
In recent years, Big Data requirements have evolved. Organizations are trying more than ever to accent their efforts on industrial development of all data at their disposal and move further away from underpinning technologies. After investing around Data Lake concept, organizations must now overhaul their data architecture to face IoT (Internet of Things) and AI (Artificial Intelligence) expansion. Efficient and effective data mapping treatments could serve in understanding the importance of data being transformed and used for decision-making process endorsement. As current relational databases are not able to manage large amounts of data, organizations headed towards NoSQL (Not only Structured Query Language) databases. One such known NoSQL database is MongoDB, which has a high scalability. This article mainly put forward a new data model able to extract, classify, and then map data for the purpose of generating new more structured data that meet organizational needs. This can be carried out by calculating various metadata attributes weights, which are considered as important information. It also processed on data clustering stored into MongoDB. This categorization based on data mining clustering algorithm named K-Means.
... Context Diagram (CD) is a model that demonstrates the product interaction with outside people, systems, and/or organizations. The context diagram assists in identifying the interfaces needed to account, identifying the potential stakeholders, identifying the scope, and understanding the context in which you are working in a better way [ 93 ] . Figure 6 shows the Context Diagram for the proposed system. ...
- Nada Abdullah Alqarni
- Shahad Saeed Alqahtani
- Sara Ahmed Alhumaidi
-
![Ibrahim Almarashdeh]()
The increasing chronic disease's epidemic is due to alcohol, smoking, lack of physical activity, obesity and unhealthy diet causing common diseases such as hypertension, osteoporosis, stroke, myocardial infarction renal insufficiency and diabetes. Preventive action against such diseases could be to improve health awareness through the use of health awareness platforms supporting behavior change and self-observation. Policy-makers play a vital role in decreasing the burden and risk of chronic diseases through implementing programs and policies that improve access to healthcare and provide a healthy environment. An official planning framework and national policy are crucial to give chronic diseases proper priority and to arrange resources properly. This work aims to design and develop a platform for chronic disease awareness. The proposed system was developed using the Unified Modeling Language (UML), ASP.NET, HTML and CSS.
Privacy, like security, is a non-functional property, yet most software design tools are focused on functional aspects, using for instance Data Flow Diagrams (DFDs). In previous work, a conceptual model was introduced where DFDs were extended into so-called Privacy-Aware Data Flow Diagrams (PA-DFDs) with the aim of adding specific privacy checks to existing DFDs. An implementation to add such automatic checks has also been developed. In this paper, we define the notion of refinement for both DFDs and PA-DFDs as a special type of structure-preserving map (or graph homomorphism). We also provide three algorithms to find, check and transform refinements, and we show that the standard diagram "transform→refine/refine→transform" commutes. We have implemented our algorithms in a proof-of-concept tool called DFD Refinery, and have applied it to realistic scenarios.
- Andri Suryadi
Di era industri 4.0 sekarang ini, perkembangan teknologi informasi dirasakan sangat cepat. Berbagai negara didunia berlomba-lomba untuk dapat bersaing dalam bidang teknologi informasi. Peran teknologi informasi khususnya sistem informasi pada saat ini sangat diperlukan dalam kehidupan sehari-hari. Sistem informasi manajemen yang baik adalah sistem informasi yang dapat mendukung terhadap jalannya organisasi. Sama halnya dengan Universitas Terbuka dukungan sistem informasi menjadi hal yang sangat penting. Terdapat beberapa masalah yang terjadi di Universitas Terbuka salah satunya adalah saling tumpang tindih kegiatan dari berbagai unit kerja. Tumpang tindih terjadi dikarenakan setiap unit mempunyai agenda masing-masing tanpa mengetahui agenda dari unit yang lainnya. Oleh karena itu perlu dibangun sebuah sistem informasi manajemen yang dapat memberikan informasi kegiatan pada masing-masing unit kerja. Sebelum dibangun sistem informasi manajemen perlu adanya perancangan terlebih dahulu untuk memudahkan dalam proses pembuatan aplikasi sistem informasi manajemen kegiatan di Universitas Terbuka, maka tujuan penelitian ini merancang sebuah sistem informasi manajemen kegiatan di Universitas Terbuka menggunakan model terstruktur. Model terstruktur merupakan turunan dari pemrograman terstuktur yang digunakan di Universitas Terbuka sehingga model ini sangat cocok digunakan. Hasil dari model terstruktur ini berupa perancangan arsitektural, perancangan data, perancangan antar muka dan perancangan prosedural.Kata Kunci: perancangan, sistem Informasi manajemen, kegiatan sivitas akademika
Unified Modeling Language (UML) is a standard language for modeling of a system. UML is used to visually specify the structure and behavior of a system. The system requirements are captured and then converted into UML specification. UML specification uses a set of rules and notations, and diagrams to specify the system requirements. In this paper, we present a tool for developing the UML specification. The tool will ease the use of the notations and diagrams for UML specification as well as increase the understanding and familiarity of the UML specification. The tool will also be able to check the conformance of the diagrams against each other for basic compliance of UML specification. Keywords—Software Engineering, Unified Modeling Language (UML), UML Specification. I. INTRODUCTION OFTWARE development life cycle (SDLC) is used to process the activities of software development. Four main phases are used in SDLC. There are analysis, design, implementation and testing (5). In SDLC, modeling tool is usually used to do the analysis of a system. The modeling tool used can be either a structured approach or an object-oriented approach or a hybrid approach. A structured approach uses diagrams such as entity relationship diagrams (ERD) and context diagrams to model and analyze the system requirements. Object-oriented approach, on the other hand, uses diagrams such as use-case diagrams and class diagrams to model and analyze the system requirements. A hybrid approach is a combination of a structured and object-oriented approach.
-
![Gary T. Leavens]()
- Tim Wahls
- Albert L. Baker
Using operational semantic techniques, we present a formal semantics for an extended variant of structured analysis style data flow diagrams. This semantics is intended to serve as a semantic foundation for many different specification languages that specify concurrent systems using a graphical notation similar to data flow diagrams. Besides allowing one to specify how information is processed, it allows one to specify the dynamic behavior of a concurrent system. We discuss various semantic issues, including the need for a twostep firing rule and how the semantics supports the notion of refinement.
- Tong Liu
- C. S. Tang
Data Flow Diagram (DFD) has been widely used in Software Engineering as means of requirement analysis and system specification. However, one defect of DFD approach remains untackled: the lack of formal semantics has brought about a lot of problems. In this paper, we model Data Flow Diagram as networks of concurrent processes. With the use of temporal logic language XYZ/E, the formal basis of the semantic specification of DFD can be ensured, and the system properties such as safety and liveness can be easily characterized. The main part of this paper is devoted to the study of the hierarchical decomposition of semantic specification and its correctness. A verification methodology is proposed and several examples are analyzed. The implementation of the tools which can support the formal specification, verification and simulation of DFD are also briefly described.
- Gao Xiaolei
- Huaikou Miao
The integration of formal, structured and object-oriented methodology is the focus in the field of software development methodology. SOZL (structured methodology + object-oriented methodology + Z language) is a language that attempts to integrate structured method, object-oriented method and formal method. The core of this language is an improved data flow diagram, known as predicate data flow diagram, which is designed by adding input set, output set and corresponding predicate constraints to the components of the traditional data flow diagram. In order to eliminate the ambiguity of predicate data flow diagrams and their associated textual specifications, a formalization of the syntax and semantics of predicate data flow diagrams are necessary. In this paper we use Z notation to define an abstract syntax and the related structural constraints for the predicate data flow diagram notation, and provide it with an axiomatic semantics based on the concept of data availability. Necessary proofs are given to establish important properties on the axiomatic semantics.
- A.A.A. Jilanic
-
![Aamer Nadeem]()
- Tai-Hoon Kim
- Eun-suk Cho
Structured analysis and design methodology has now been replaced by object oriented analysis and design software development techniques. A major design artifact in structured approach is the data flow diagram (DFD). DFD is very important for the modernization of old legacy systems. It is also very useful in requirement elicitation. However, DFD lacks formalism and by representing DFD formally, ambiguity and inconsistencies can be removed. Formal representation of DFD and its formal semantics help in better understanding of requirements and design. In this paper, we present a survey of techniques that formally represent or give formal semantics to the data flow diagram. We analyze formal representation techniques using analysis parameters. On the basis of identified parameters, we present an analysis table, which describes the strengths and weaknesses of representation techniques.
Information System (IS) development has been beset by consistency problems since its infancy. These problems are greater still in UML software development, and are principally caused by the existence of multiple views (models) for the same system, and may involve potentially contradictory system specifications. Since a considerable amount of work takes place within the scope of model consistency management, this paper presents a systematic literature review (SLR) which was carried out to discover the various current model consistency conceptions, proposals, problems and solutions provided. To do this, a total of 907 papers related to UML model consistency published in literature and extracted from the most relevant scientific sources (IEEE Computer Society, ACM Digital Library, Google Scholar, ScienceDirect, and the SCOPUS Database) were considered, of which 42 papers were eventually analyzed. This systematic literature review resulted in the identification of the current state-of-the-art with regard to UML model consistency management research along with open issues, trends and future research within this scope. A formal approach for the handling of inconsistency problems which fulfils the identified limitations is also briefly presented.
-
![Yonglei Tao]()
- Chenho Kung
Data flow diagrams (DFD) are widely used to specify large complex software systems. A DFD is visual and informal, hence, easy to learn and use. However, its informality makes it difficult to conduct formal verification of the consistency and completeness of a DFD specification. The objective of this article is to provide a formal basis for the DFD. A DFD is defined as a diagraph together with a binary relation, called the precedence relation. The nodes of the digraph represent the processes, data stores, and external entities, and the directed edges represent the data flows. The precedence relation for a DFD is an abstraction of the functional semantics and specifies the "is-used-to-produce" relationships among the data flows. Based on this definition, the notion of consistency in process decomposition is defined. The child DFD that results from decomposition is consistent with the parent process if the child DFD preserves the precedence relation for the parent process and does not introduce additional precedence relationships between the input and output flows of the parent process. This consistency criterion is shown to be stronger than those found in the literature. Moreover, a number of completeness criteria are discussed and formalized. The results of this paper can be easily incorporated into some existing CASE tools.
- Do-Hyoung Kim
- Kiwon Chong
It is important to check errors and keep consistency in the process of object-oriented analysis. However, current object-oriented development methodologies fail to present standardized methods to detect errors and to verify consistency. This paper presents a method of checking errors and consistency in object-oriented analysis models using a knowledge base. The method consists of three steps; modeling, formalizing and verifying. In the modeling step, three models are produced: the object model, the dynamic model and the functional model, as in Rumbaugh's OMT (Object Modeling Technique) (1991). In the formalizing step, these three models are transformed into atomic formulae and are stored in an application knowledge base. In the verifying step, the rules for detecting errors and checking consistency are applied. The results of the analysis process for some ATM (Automated Teller Machine) models were used to validate this method. The method is expected to produce more reliable analysis models
Source: https://www.researchgate.net/publication/47619337_Formalization_of_the_Data_Flow_Diagram_Rules_for_Consistency_Check
Posted by: vernonvernonerskine0273009.blogspot.com
