Está en la página 1de 18

Analysis Modeling for Web Applications: Flow-Oriented Modeling and Data-Flow Diagrams

Data Flow-Oriented Modeling (Data Flow Diagrams DFDs)

DFD Free Online Tutorial: http://www.getahead-direct.com/gwbadfd.htm DFDs with Visual Paradigm: http://www.visual-paradigm.com/highlight/highlightdfd.jsp

Power of DFDs

analysis model

Maps into
design model

Data Flow Diagramming Rules 1) Processes cannot have only outputs, cannot have only inputs, and must have a verb phrase label. 2) Data can only move to a data store from a process, not from another data store or an outside source. 3) Similarly, data can only be moved to an outside sink or to another data store by a process. 4) Data to and from external sources and sinks can only be moved by processes. 5) Data flows move in one direction only. 6) Both branches of a forked or a joined data flow must represent the same type of data. 7) A data flow cannot return to the process from which it originated.

No process can have only outputs or only inputsprocesses must have both outputs and inputs.

Process labels should be verb phrases.

All flows to or from a data store must move through a process.

Data store labels should be noun phrases.

No data moves directly between external entities without going through a process. Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD. Source and sink labels should be noun phrases.

Bidirectional flow between process and data store is represented by two separate arrows. Forked data flow must refer to exact same data item (not different data items) from a common location to multiple destinations.

Joined data flow must refer to exact same data item (not different data items) from multiple sources to a common location. Data flow cannot go directly from a process to itself, must go through intervening processes.

10

(a) Improperly Drawn DFD

11

(b) Proper Use of a Process

12

Data Flow Diagramming: Guidelines

1) all icons must be labeled with meaningful names 2) the DFD evolves through a number of levels of details 3) always begin with a context level diagram (also called level 0) 4) always show external entities at level 0 5) always label data flow arrows 6) do not represent procedural logic

13

Context Diagram (An example)

user

processing request digital video processing

requested video signal monitor

video source

NTSC video signal

Important notes: A single processing unit No data storage units Multiple data sources (providers of data, receivers of data)
14

Context Diagram: An example of the University of Missouri St. Louis Student Registration System

A single processing unit No data storage units Multiple data sources (providers of data, receivers of data)

http://www.umsl.edu/~sauterv/analysis/dfd/dfd_homework.html

15

The Data Flow Hierarchy: from context diagram towards level-0 diagram

Context D. x Level 0 D. a
P1.0

Pr

c d

P2.0

f
P4.0

P3.0

P5.0

Main processing unit Pr (main function) can be divided into up to 9 sub-units (sub functions), labeled as P1.0, P2.0, P3.0, P4.0, etc.
16

Level 0 Diagram: An example of the University of Missouri St. Louis Student Registration System

A single processing unit No data storage units Multiple data sources (providers of data, receivers of data)

http://www.umsl.edu/~sauterv/analysis/dfd/dfd_homework.html

17

Power of DFDs

analysis model

Maps into

design model

18

También podría gustarte