0% found this document useful (0 votes)
46 views11 pages

UCI 202 TOPIC 9 Data and Process Modeling

Uploaded by

aroridouglas880
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views11 pages

UCI 202 TOPIC 9 Data and Process Modeling

Uploaded by

aroridouglas880
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

0|Page

UCI 202: COMPUTER-BASED INFORMATION SYSTEMS

P.O. Box 3275 - 40100, KISUMU | Tel: 057-2021013 | email: [email protected] |


http://ecampus.maseno.ac.ke
1|Page

Topic 9: Data and Process Modeling

Process Modeling
9.1 Introduction
 A model is a representation of reality.
 Most models are pictorial representations of reality.
 Logical models show what a system is or does. They are implementation independent; that is, they
depict the system independent of any technical implementation.
 Physical models show not only what a system is or does, but also how the system is (to be)
physically and technically implemented. They are implementation dependent because they reflect
technology choices.

9.2 Why logical models


(i). Logical models remove biases that are the result of the way the system is currently
implemented, or the way that any one person thinks the system might be implemented.
(ii). Logical models reduce the risk of missing business requirements because we are too
preoccupied with technical results.
(iii).Logical models allow systems analysis to communicate with end-users in nontechnical or less
technical languages.

9.3.1 Process Modeling & Tools


 Data and process modeling involves three main tools: document flow diagrams, context diagrams,
data flow diagrams, a data dictionary, and process descriptions.

Document Flow Diagrams


 A useful starting point for data flow diagramming simple technique used to identify the movement
of physical documents around a system.
 It shows:
(i). the name or data content of a document
(ii). where it comes from (the source)
(iii).where it goes to (the destination)
 N.B. a ‘document’ can take the form of a piece of paper, a conversation or electronic data transfer
 sources and destinations are often called agencies
 they are depicted in an oval shape
 in the example below, the document is a birthday card, which flows in the direction of the arrow
from you to your relative, the agencies.

Birth day Card Relative


You
2|Page

 Document flow diagrams can be useful to illustrate at a high level an overall view of documents
flowing around a system. They could be described as the big picture of the information system - not
focusing on any one aspect or detail
 They are useful for identifying the system boundary and external entities
 They can be rapidly transformed into a Context Diagram
 Example Document Flow Diagram: Order Processing

Guidelines for Drawing Document Flow Diagrams


(i). Identify and list names of documents or data being transferred in, around and out of the system
(ii). Identify where documents originate from
(iii).Identify who (person, job role) or what (functional area in system eg. warehouse, accounts dept.)
receives document
(iv).Do not show the movement of physical goods but do show any document or data that accompanies
the goods
(v). Do not cross over lines on diagram.
3|Page

Context Diagrams
 Used to identify that will interact with the system both internal and external.
 Example:

Data Flow Diagrams


• Provide a complete model of the information system showing:
– View of system focusing on processing of data flows
– Where data arrives from (input)
– Who receives it and how it is used (processing)
– Where it is kept (storage)
– Where the processed data is sent (output)
• A major generic technique
– Powerful and useful
– Not just in computer based systems development
• Notation
– There are a number of variations in symbols used (esp. methods used in USA)
• Yourdon
• Gane and Sarson
– We use SSADM notation
– All share exactly the same construction
1. Example:
4|Page

Data Flow Diagram Symbols

Data Flow

External Entity

Physical resource flow

Process

Data store

Data Flow Diagram Symbols Labelling


2. Example
5|Page

Comprehensive example
• Following example shows a Data Flow Model of an order processing system
• An initial document flow diagram can be used as a starting point
– Helps define the boundaries of the system and therefore the agencies which are external
6|Page
7|Page
8|Page
9|Page

Hierarchic structure of a Data Flow Model


• At highest level shows an overview of the system
• Level 1 is the most important
• Gradually refined into further detail:
– Level 2, 3 etc
• Until system processing is described in the utmost detail: i.e Elementary process descriptions

Components of a Data Flow Model

Basic Rules
1. Data MUST flow to or from a process
 not directly between external entities
 not directly between data stores
 not directly from external entity to data store (or vice-versa).
2. Data flow lines should NOT cross each other (for readability)
3. Process descriptions:
 MUST contain a verb
 and describe what is happening to DATA
 They must be concise. That is they must not be a list of sub-processes
4. Data stores can be used by only one process
 are internal to that process and
 are only shown when that process is decomposed into a lower level DFD.
 i.e. on a higher level diagram they can’t be seen.
5. Have a maximum of six processes in one diagram at a particular level
6. You will see examples of eight or more level 1 processes
 this is not good practice
o It results in too much detail at one level
o It is difficult to read
 Key features to look for in a DFD are: clarity, simplicity, completeness

Where to Use DFDs?


 DFDs are a powerful modelling tool used in analysis phase:
– To model the physical representation of current system
10 | P a g e

–For transformation into a “Logical” (clean) view of the current system by removing
physical circumstances
• Design phase:
– They show a logical view of the new required system by adding the users’ requirements.
– Later in the detailed design of a system they can be used to model the physical
representation of the required system.

You might also like