emphasizes processes and the flows of data data in and out of the processes.
based on system theory which assumes inputs are fed into processes to produce outputs.
has feedback to eliminate system entropy and complete the system model.
processes analyzed in isolation. then integrate processes into a system model.
system has a hierarchy smaller systems, each has its own input, process, and output.
elementary components: the lowest level of the hierarchy, components can no longer be subdivided.
begins with 2 assumptions:
we are interested in what the application to do: what are the functions of the system.
top-down approach for problems: analyze external interfaces of the applications first, then high level functions (processes), then lower level functions (processes), and so on.
scope: defines the boundaries of the system to be analyzed. what’s inside the system and what’s outside the system.
context: is the environment in which the system operates. the context is outside the scope of the system.
context diagram: a diagram that shows the external interfaces of the system and the context in which the system operates.
data flow: the flow of data in and out of the system. (arrows).
components of context diagram:
square: external entity.
arrows: data flow.
circle: application.
data flow diagram (DFD):
a diagram that shows the data flow in and out of the system.
describes Level 0 of the system.
we go down into components of the system to describe Level 1, Level 2, and so on.
the primitive level: the lowest level of the system, the level where the system can no longer be subdivided.
structured decomposition: the process of breaking down a system into smaller components.
data dictionary: detailed definitions of each item in the data flow diagram DFD.
new customer (inward flow): store information about new customer.
rental request (inward flow): customer choses a video to rent, the speak to the clerk who handles the request, then customer pays. (analogous to an order).
rental receipt (outward flow): the clerk gives the customer a receipt for the rental and the customer signs that receipt.
video return (inward flow): the customer returns the video to the clerk, calculate if late fees are due, and give the customer a receipt.
top-down: decompose the problem into smaller problems. then decompose the smaller problems into smaller problems. and so on. functions at each level are called processes each of which should independent problem.
bottom-up: start by the details of task steps described by users, then combine them to define processes.
outward-in: start from the context diagram to define boundary processes, follow data flows to define internal processes.
functional sequence: start from data flows in the context diagram, define the first process, then define the next process, and so on.
timing is not important in data flow diagrams. eg. end of day, morning, etc. all defined as equal processes.
ignore exceptions in data flow diagrams.
pathological processes: processes with connection errors.
usually, sub-processes will become software modules.
aim for maximal cohesion and minimal coupling.
cohesion: the processes have only what they need and nothing more.
types of quality checks performed on the results of DFDs:
correctness: syntax and connections in the diagram are accurate.
completeness: diagram covers all parts of the problem.
