Chap-7 review exercise

Key terms
7.1 Action stubs
7.2 Balancing
7.3 Condition stubs
7.4 Context diagram
7.5 Data flow diagram (DFD)
7.6 Data store
7.7 Decision table
7.8 DFD completeness
7.9 DFD consistency
7.10 Functional decomposition
7.11 Gap analysis
7.12 Indifferent condition
7.13 Level-0 diagram
7.14 Level-n diagram
7.15 Primitive DFD
7.16 Process
7.17 Rules
7.18 Source/sink

____ A picture of the movement of data between external entities and the processes and data stores within a system.
____ The part of a decision table that lists the actions that result for a given set of conditions.
____ The conservation of inputs and outputs to a DFD process when that process is decomposed to a lower level.
____ A DFD that represents a system’s major processes, data flows, and data stores at a high level of detail.
____ The origin and/or destination of data; sometimes referred to as external entities.
____ In a decision table, a condition whose value does not affect which actions are taken for two or more rules.
____ An overview of an organizational system that shows the system boundary, external entities that interact with the system,
and the major information flows between the entities and the system.
____ The lowest level of decomposition for a DFD.
____ The extent to which all necessary components of a DFD have been included and fully described.
____ A matrix representation of the logic of a decision; it specifies the possible conditions for the decision and the resulting
actions.
____ The extent to which information contained on one level of a set of nested DFDs is also included on other levels.
____ A DFD that is the result of n nested decompositions of a series of sub processes from a process on a level-0 diagram.
____ The part of a decision table that lists the conditions relevant to the decision.
____ The work or actions performed on data so that they are transformed, stored, or distributed.
____ Data at rest, which may take the form of many different physical representations.

____ The process of discovering discrepancies between two or more sets of DFDs or discrepancies within a single DFD.

____ The part of a decision table that specifies which actions are to be followed for a given set of conditions.
____ An iterative process of breaking the description of a system down into finer and finer detail, which creates a set of
charts in which one process on a given chart is explained in greater detail on another chart.

REVIEW QUESTIONS
7.19 What are the symbols making up a DFD?

A DFD (Data Flow Diagram) is a visual representation of the flow of data within a system. The symbols used in a
DFD are:

1. Process symbol: This symbol represents a process or transformation of data. It is depicted as a rectangle
with rounded corners.
 2. Data flow symbol: This symbol represents the flow of data between processes. It is depicted as an arrow
that connects two processes, and it shows the direction of data flow.
3. External entity symbol: This symbol represents an external entity that interacts with the system. It is
depicted as a rectangle with rounded corners and has no input or output data flows.
4. Data store symbol: This symbol represents a repository of data. It is depicted as two parallel lines with a
rectangle between them.
5. Terminator symbol: This symbol represents the end of a data flow. It is depicted as a circle with an X
inside.

These symbols are used to create a graphical representation of the data flow within a system, which can help to
identify potential bottlenecks, inefficiencies, and areas for improvement.

7.20 When drawing a DFD of the symbols Process, Data store, and External entity, one
must always be placed between the others. Which one, and why?

When drawing a DFD, a data store must always be placed between a process and an external entity. This is because
a data store represents a repository of data that is used by a process or an external entity, and the data stored in it is
the subject of the data flow between them.

Placing a data store between a process and an external entity makes it clear that the process uses data from the data
store, and that the external entity can also access and update data in the data store. This helps to ensure that the flow
of data is properly represented in the DFD and that all relevant interactions between the process, data store, and
external entity are captured.

For example, consider a DFD that represents a system for managing customer orders. In this system, a process might
be used to validate and process customer orders, while an external entity could be a customer or a sales
representative. The data store would represent a database that stores customer and order information. In this case,
the data store would be placed between the process and the external entity to show that the process uses data from
the data store, and the external entity can access and update data in the data store.

7.21 What is decomposition? What is balancing? How can you determine if DFDs are not
balanced?

Decomposition refers to the process of breaking down a complex system or process into smaller, more manageable
components. In the context of data flow diagrams (DFDs), decomposition involves dividing a high-level DFD into
lower-level DFDs, each of which represents a more detailed view of a specific part of the system or process being
modeled.

Balancing, on the other hand, refers to ensuring that the inputs and outputs of each process in a DFD are balanced.
In a balanced DFD, the sum of the inputs to a process must be equal to the sum of its outputs. Balancing is important
because it ensures that data is accurately represented in the DFD and that the system being modeled is functioning
properly.

To determine if a DFD is not balanced, you can perform a balancing check. This involves examining each process in
the DFD to ensure that the sum of the inputs equals the sum of the outputs. If the inputs and outputs are not
balanced, it could indicate that there is an error in the DFD or that the system being modeled is not functioning
correctly. In such cases, the DFD needs to be revised to correct the imbalance.
7.22 As the name clearly states, drawing a DFD is about displaying the transference and
manipulation of data. However,
equally important is discovering where most of the system’s code will be needed. How does
drawing DFDs help in finding out what code needs to be written?

Drawing Data Flow Diagrams (DFDs) can help in finding out what code needs to be written in several ways:

1. Identifying Processes: DFDs help in identifying the processes that manipulate data within the system.
These processes are represented as bubbles or circles in the DFD. By analyzing these processes, developers
can identify the areas where most of the system's code will be needed. Each process represents a distinct
task that needs to be performed by the system, and developers can write code to implement these tasks.
2. Defining Data Requirements: DFDs help in defining the data requirements of the system. Each data flow in
the DFD represents the movement of data from one point to another. By analyzing the data flows,
developers can identify the data that needs to be processed and the data that needs to be stored. This
information can help in determining what code needs to be written to handle the data processing and
storage tasks.
3. Understanding System Interactions: DFDs help in understanding how different parts of the system interact
with each other. The interactions between processes, data stores, and external entities are represented in the
DFD. By analyzing these interactions, developers can identify the dependencies between different parts of
the system. This information can help in determining what code needs to be written to handle the
interactions between different parts of the system.

Overall, drawing DFDs can help in identifying the functional requirements of the system, which in turn can help in
determining what code needs to be written to implement these requirements. By understanding how data flows
through the system, developers can identify the areas where code needs to be written to handle data processing,
storage, and manipulation tasks.

7.23 In a context diagram and a level-0 diagram, some objects will remain exactly the same.
Which ones? What is the reason for this?

In a context diagram and a level-0 diagram, the external entities and the data stores remain exactly the same.
The reason for this is that the purpose of these diagrams is to show the high-level view of the system and its
interactions with external entities without getting into the details of how the system processes or stores data.

External entities represent the sources and destinations of data flowing in and out of the system. They remain the
same in both diagrams because the system's interactions with these entities do not change based on the system's
internal operations.

Data stores represent the places where data is stored in the system. They also remain the same in both diagrams
because the data stored in these data stores is not affected by the system's internal operations.

In a context diagram, the system is represented as a single process and the interactions between the system and
external entities are shown through data flows. In a level-0 diagram, the system is decomposed into a set of
processes, and the interactions between these processes are shown through data flows. However, the external entities
and data stores remain the same in both diagrams as they are considered to be outside the scope of the system being
modeled.
7.24 State which of the following a DFD is not good at: showing progression and
transformation of information or showing the timing of different processes.

A Data Flow Diagram (DFD) is not good at showing the timing of different processes. While a DFD shows the
progression and transformation of information within a system, it does not depict the time taken by different
processes to complete their tasks.

A DFD represents a static view of the system, which means that it shows the different components of the system and
how they interact with each other, but not the sequence or timing of these interactions. For example, a DFD can
show that a customer places an order and the order is processed by the system, but it does not show the time taken
by the system to process the order.

To show the timing of different processes, developers need to use other modeling techniques such as sequence
diagrams, activity diagrams, or flowcharts. These techniques are designed to represent the sequence and timing of
different activities within a system and are better suited for depicting the dynamic behavior of the system.

7.25 Explain the guidelines for deciding when to stop decomposing DFDs.

Decomposing Data Flow Diagrams (DFDs) is an iterative process that involves breaking down a complex system
into smaller, more manageable components. However, it is essential to know when to stop decomposing DFDs. Here
are some guidelines for deciding when to stop decomposing DFDs:

1. Completeness: The first guideline for stopping decomposition is completeness. The DFD should be
complete and cover all aspects of the system being modeled. If the DFD is not complete, it may lead to
errors in the system design and development.
2. Clarity: The DFD should be clear and understandable to all stakeholders involved in the project. If the DFD
becomes too complex or difficult to understand, it may indicate that the decomposition process has gone
too far.
3. Balancing: The DFD should be balanced, meaning that the inputs and outputs of each process should be
equal. If the DFD is not balanced, it may indicate that the decomposition process needs to be revised.
4. Manageability: The DFD should be manageable, meaning that the components of the system should be
small enough to be easily understood and developed. If the components become too small, it may lead to
unnecessary complexity and difficulty in managing the system.
5. Feasibility: The DFD should be feasible in terms of implementation. If the decomposed components are too
complex to implement or require significant resources, it may indicate that the decomposition process has
gone too far.

In summary, deciding when to stop decomposing DFDs involves balancing completeness, clarity, balancing,
manageability, and feasibility. It is essential to strike a balance between these factors to develop a comprehensive
and understandable system design.

7.26 Which of the following statements is true?

a. A data flow to a data store means retrieve or use.
b. Many processes can, in a way, be viewed as context diagrams of their own.
c. A data store can be directly connected to another data store.
d. In the notation used in this chapter, a process doesn’t have to be numbered.
The statement that is true is d. In the notation used in this chapter, a process doesn't have to be numbered.

In Data Flow Diagrams (DFDs), processes are usually numbered to indicate their sequence in the system. However,
the notation used in this chapter does not require processes to be numbered. This means that the absence of a
number does not necessarily mean that the process is not important or not part of the system.

Option a is incorrect because a data flow to a data store means that data is being stored in the data store, not
necessarily retrieved or used.

Option b is partially correct but is not entirely accurate. While it is true that processes can be viewed as context
diagrams of their own, they do not represent the entire system and are only a part of the larger system being
modeled.

Option c is incorrect because a data store cannot be directly connected to another data store in a DFD. Data can only
flow from a data store to a process or from a process to a data store.

7.27 What part of a context diagram must also appear in its corresponding level-0
diagram?

In a Data Flow Diagram (DFD), the context diagram and level-0 diagram are the highest-level diagrams used to
depict the system being modeled. The context diagram represents the system as a single process and its external
entities, while the level-0 diagram shows the breakdown of the system into its major processes and the data flow
between them.

The external entities and data flows present in the context diagram must also appear in the corresponding level-0
diagram. This means that the inputs and outputs of the system depicted in the context diagram should also be present
in the level-0 diagram.

The level-0 diagram is a more detailed representation of the system, and it shows how the system functions by
breaking down the process depicted in the context diagram into its constituent processes. The data flows between the
processes in the level-0 diagram are more detailed than those in the context diagram, but they should still reflect the
same data flows and external entities as in the context diagram.

Therefore, the external entities and data flows present in the context diagram must be reflected in the level-0
diagram to ensure consistency and completeness in the system modeling.

7.28 What are the three headings or keywords used in a decision table?

The three headings or keywords used in a Decision Table are:

1. Condition: This heading represents the different conditions or factors that affect the outcome of the
decision. The conditions are usually represented as a list of variables or parameters that can take on
different values.
2. Action: This heading represents the different actions or outcomes that can result from the decision based on
the different combinations of conditions. The actions are usually represented as a list of options or choices
that are available to the decision maker.
 3. Rule: This heading represents the different rules or logic that govern the decision making process. The rules
are usually represented as a set of conditional statements that specify the relationship between the
conditions and the actions.

In a Decision Table, the conditions and actions are arranged in a matrix format, with each row representing a unique
combination of conditions and each column representing a unique action. The rules are then specified in the cells of
the matrix, with each cell containing a logical expression that defines the relationship between the conditions and the
actions.

By using a Decision Table, complex decision making processes can be simplified and made more systematic,
enabling the decision maker to consider all the possible combinations of conditions and actions and make a well-
informed decision.

7.29 In a certain decision table, there are eight rules and three of them yield the same
result. How many rules are there in the reduced decision table?

If there are eight rules in a decision table and three of them yield the same result, we can combine these three rules
into a single rule, which will reduce the number of rules in the table.

This means that we have effectively removed two of the eight rules, leaving us with a reduced decision table that has
only six rules. The three rules that yield the same result are now combined into a single rule, which will have the
same action or outcome as the individual rules.

Therefore, the reduced decision table will have six rules instead of eight.

7.30 What is the formula that is used to calculate the number of rules a decision table must
cover?

The formula used to calculate the number of rules a decision table must cover is:

N = (2^C) x A

Where N is the total number of rules, C is the number of conditions or factors that affect the decision, and A is the
number of possible actions or outcomes.

This formula is based on the fact that each condition or factor can take on two possible values (True or False) and
that there are a total of A possible actions or outcomes. By multiplying the number of possible values for each
condition (2^C) by the number of possible actions (A), we can determine the total number of rules that the decision
table must cover to ensure that all possible combinations of conditions and actions are considered.

For example, if a decision table has 3 conditions and 2 possible actions, the total number of rules that must be
covered would be:

N = (2^3) x 2 N = 8 x 2 N = 16

This means that the decision table must cover a total of 16 rules to consider all possible combinations of conditions
and actions.