Abstract

Abstract Data flow is the name applied when data are passed from one thing to another. The “thing” that passes the data can include a piece of software or an application, a computer or a region in a computer, a person, group, or organizational unit, or combinations of these. The data passed can be simple or complex and it can be passed as a stream or a unit. A diagram that depicts objects or processes and the possible flows of data among them is called a data flow diagram (DFD). DFDs are useful for depicting information about how an organization operates; the interfaces between an application and the people or other applications that use it; and the high‐level design of an application. DFDs have been used in application development for a long time. There are two alternatives to (pure) data flow and each alternative has substantial disadvantages when used to link software components. One of these alternatives to data flow is for the data not to flow; that is, have various software modules access it directly in shared common data areas. A second alternative to pure data flow is the “call” statement, used in most languages to link subroutines. The call statement has two substantial limitations versus pure data flow: it also passes control and it explicitly names the target subroutine. In today's application development methodologies, DFDs are important for: analyzing organizational units; depicting the context of an application relative to users and other applications; designing the high level (process) architecture of applications; showing the interfaces between application processes and data stores; and documenting batch job streams. DFDs are likely to be increasingly important for designing distributed systems, object‐oriented design, depicting asynchronous components, and for reusable code. An examination of each is given.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call