Develop a structure chart for student asking diploma in university after graduation of Diagram-0. Your structure chart must automate all processes, data flows and data stores shown on Level-0. Your completed structure chart will have at least three layers (one top-layer module, several middle-layer modules, and several third-layer (or leaves) modules, which capture inputs/outputs, interact with data stores or other common subroutines Solution This should be easy, if you have a leveled set of data flow diagrams available. Start with the context diagram, then repeat the following step for as long as possible (that is, as long as processes that are specified by lower level diagrams exist on the diagram you\'ve obtained). Choose a process on your diagram that\'s specified by a lower level data flow diagram, instead of a process specification. ``Cut and paste,\'\' replacing this process by the simpler processes (and any data stores) in the lower level data flow diagram. Since the conservation of flow rule was used if the leveled set of data flow diagrams was correctly prepared, you should be able to ``match up\'\' the data flows to and from the process being replaced, by the data flow diagrams into and out of the processes you\'re adding to replace it. It should now be the case that all the processes on your diagram are refined by process specifications, and not by lower level data flow diagrams. You\'re ready for the next step. Choose this case if the diagram is ``nontrivial\'\' - it includes four or more processes - and it is easy to split it up into pieces that represent ``subsystems,\'\' such that there is virtually no (direct) communication between subsystems, and the entire system works by invoking each of these subsystems, one at a time. In the ``Student Information System\'\' that will eventually follow, we\'ll see that the diagram we start with has this property. In particular, it will include a ``startup\'\' process that can be considered to be one subsystem, which reads system data from a text file, and initializes data areas - and which is actively ony once, when the system is initiated. All the other processes in the system form a subsystem that repeatedly requests and obtains a user\'s command and executes it. This second ``subsystem\'\' is only activated after the first ``subsystem\'\' terminates. While the two subsystems share information indirectly, in the sense that the second subsystem uses the data areas that the first set up, the only direct communication between the two ``subsystems\'\' is the transmission of a control signal from the first subsystem to the second. Transaction Flow A nontrivial data flow diagram exhibits transaction flow if there is one process in the diagram - a transaction center - that results in multiple data streams flowing out of the transaction center. Each of these data streams corresponds to a major subsystem. Typically, each time the transaction center is activated, it responds by triggering activit.

1. Develop a structure chart for student asking diploma in university after graduation of Diagram-0.
Your structure chart must automate all processes, data flows and data stores shown on Level-0.
Your completed structure chart will have at least three layers (one top-layer module, several
middle-layer modules, and several third-layer (or leaves) modules, which capture inputs/outputs,
interact with data stores or other common subroutines
Solution
This should be easy, if you have a leveled set of data flow diagrams available.
Start with the context diagram, then repeat the following step for as long as possible (that is, as
long as processes that are specified by lower level diagrams exist on the diagram you've
obtained).
Choose a process on your diagram that's specified by a lower level data flow diagram, instead of
a process specification. ``Cut and paste,'' replacing this process by the simpler processes (and
any data stores) in the lower level data flow diagram. Since the conservation of flow rule was
used if the leveled set of data flow diagrams was correctly prepared, you should be able to
``match up'' the data flows to and from the process being replaced, by the data flow diagrams
into and out of the processes you're adding to replace it.
It should now be the case that all the processes on your diagram are refined by process
specifications, and not by lower level data flow diagrams. You're ready for the next step.
Choose this case if the diagram is ``nontrivial'' - it includes four or more processes - and it is
easy to split it up into pieces that represent ``subsystems,'' such that there is virtually no (direct)
communication between subsystems, and the entire system works by invoking each of these
subsystems, one at a time.
In the ``Student Information System'' that will eventually follow, we'll see that the diagram we
start with has this property. In particular, it will include a ``startup'' process that can be
considered to be one subsystem, which reads system data from a text file, and initializes data
areas - and which is actively ony once, when the system is initiated. All the other processes in the
system form a subsystem that repeatedly requests and obtains a user's command and executes it.
This second ``subsystem'' is only activated after the first ``subsystem'' terminates. While the
two subsystems share information indirectly, in the sense that the second subsystem uses the data
areas that the first set up, the only direct communication between the two ``subsystems'' is the
transmission of a control signal from the first subsystem to the second.
Transaction Flow
A nontrivial data flow diagram exhibits transaction flow if there is one process in the diagram - a

2. transaction center - that results in multiple data streams flowing out of the transaction center.
Each of these data streams corresponds to a major subsystem. Typically, each time the
transaction center is activated, it responds by triggering activity in exactly one of these data
streams.
As this may suggest, a data flow diagram exhibiting transaction flow often has a noticeable
shape: One or more streams of ``input paths'' or command acquisition paths lead into the
transaction center, and several activity paths stream or radiate out of the transaction center, (so
that the transaction center looks a bit like the hub of a wheel, or the top of the root of a plant).
The top (or second) level of diagrams for transaction processing systems often exhibit
transaction flow. These are systems that receive commands from users, when there is a fixed
number of different kinds of commands that can be selected, and each of the different kinds of
commands will be executed by a different subsystem (and with each subsystem corresponding to
one of the ``data streams'' or ``activity paths'' that radiate out of the transaction center on the
system's data flow diagram).
Examples of ``transaction processing systems'' are an automated teller (that is, banking
machine), or any (other) menu based system, which starts by displaying a menu or possible
commands to a user and requiring the user to choose one of those commands.
Recall that the system's data flow diagrams might be changed as details about the human
computer interface are added. The ``transaction center'' may well be one of those processes that
don't appear on the first data flow diagrams (for ``essential requirements'') but that are added to
the data flow diagrams in order to model the interface.
Transform Flow
A data flow diagram exhibits transform flow if the subsystem it represents is centered around a
central transform - a process or a set of processes. Incoming data are collected for processing by
chains of processes leading from terminators into the central transform; these processes prompt
for data, check for (and report) syntax and semantical errors (and can report these problems if
they're discovered), and may also convert the validated inputs into ``logical'' or ``internal''
formats. Nontrivial computations using the collected (and validated) inputs are then performed in
the transform center. After that, output flows from the transform center (and is formatted for
display) along chains of processes toward the terminators receiving them.
In fact, almost any reasonable data flow diagram can be processed as if it exhibited transform
flow: The other kinds of information flow (and kinds of data flow diagrams) can all be
considered to be ``special cases'' of this one. Thus, here is an easy rule to follow in order to
identify the type of information flow for a data flow diagram: If, based on an inspection of the
system and the above descriptions ofindependent subsystems and transaction flow, you can
convince yourself that one of these two cases applies, then use it. Otherwise, choose ``transform

3. flow'' as a default (and continue).
A Trivial Diagram
This is any diagram with (approximately) three or fewer processes.
Processing Diagrams with ``Independent Subsystems"
Recall that you chose this type because the diagram was nontrivial and it was easy to break it up
into pieces that represented (almost) independent subsystems.
Partitioning the Diagram
Partition the processes on the diagram into sets that correspond to the ``subsystems'' you
identified. That is, choose a ``subdiagram'' for each subsystem, that includes all the processes in
the subsystem. You should end up with each one of the processes on the original diagram shown
on exactly one of the ``subdiagrams'' you've generated.
First Level Factoring
If necessary, create a main module for the system; give this a name that describes the system (or
subsystem) it controls, but note as well that you'll probably want to use this as the name for the
function that will implement it, in the computer program you eventually write.
It will be necessary to create a main module if you've just started - so that you haven't yet
created any modules at all. It usually won't be necessary otherwise, because there will usually
already be a module in the structure chart you've generated, that serves as the ``main module''
for this part of the system.
Second Level Factoring
Now, recursively apply this whole second part of ``Step 1'' (that is, the process to map a large
data flow diagram to a set of modules), to each one of the ``subdiagrams'' you just created. Add
a control connection (drawn as an arrow) from the ``main module'' you either created or
identified during ``first level factoring,'' to the main module for each of the structure charts
you've recursively generated during ``second level factoring,''