Untitled Flashcard Set
DFD (Data Flow Diagram): A visual representation of how data moves through a system.
Levels: DFDs are broken into levels to manage complexity. The highest level is a simple overview, and lower levels add more detail.
Decomposition: The process of breaking down a high-level process into a set of more detailed, lower-level processes.
Context Diagram (Level 0): Process is numbered 0.
Level 1 Diagram: Processes are numbered 1.0, 2.0, 3.0, etc.
Level 2 Diagram: Processes that break down process 2.0 would be numbered 2.1, 2.2, 2.3, etc.
Level 3 Diagram: Processes that break down process 2.2 would be numbered 2.2.1, 2.2.2, etc.
Process Modeling: The act of creating a graphical representation of how a business system works.
Of course. Here are the concise, easy-to-study notes from the document on Process Modeling and Data Flow Diagrams.
1. Introduction to Process Modeling
Process Modeling: The act of creating a graphical representation of how a business system works.
Purpose:
To clarify system requirements.
To document the current ("as-is") or future ("to-be") system.
To illustrate business processes and the data that flows through them.
Key Tool: Data Flow Diagram (DFD).
2. Types of DFDs
DFDs describe data flows in two main ways:
Logical DFD:
Focuses on WHAT the system does.
Shows the business processes and data flow, without worrying about how they are physically implemented.
Example: Shows that an order is processed, but not whether it's done by a person, a computer, or in a specific department.
Physical DFD:
Focuses on HOW the system is implemented.
More specific and detailed.
Shows the location of data processing (e.g., which department) and the devices used.
3. The 4 Core Elements of a DFD
4. DFD Notations: Gane & Sarson vs. Yourdon & DeMarco
There are two common visual styles for DFDs. You must pick one and use it consistently.
Most Important Rule: Consistency is key. DO NOT mix notations in the same set of diagrams.
5. Key Principles: Decomposition
Business processes are often too complex for a single DFD. We break them down using a technique called decomposition.
Concept: You start with a high-level overview (Context Diagram) and progressively break down each process into more detailed, lower-level diagrams.
Levels:
Context Diagram: The highest level, showing the whole system as one process (Process 0).
Level 0 DFD: Breaks down Process 0 into the main sub-processes (1, 2, 3...).
Level 1 DFD: Breaks down one of the Level 0 processes (e.g., Process 2) into its own sub-processes (2.1, 2.2, 2.3...).
...and so on to lower levels of detail.
Rule of Thumb: Each process in a DFD is a potential candidate to be broken down into its own, more detailed DFD on the next level.
Excellent! Here are the concise, easy-to-study notes for the Data Flow Diagram Rules.
1. Fundamental Principles
Rule #1: Balancing: The most important rule. The inputs and outputs of a process on a high-level diagram must match the total inputs and outputs of its detailed, lower-level diagram. If the parent process has 1 input and 2 outputs, its child diagram must also have a total of 1 input and 2 outputs.
Rule #2: Transformation: A process must transform data. The data that exits a process should be different from the data that entered it.
2. Illegal Connections (Data Must Go Through a Process)
A process is the "engine" of the system. Data cannot move between other elements without being acted upon by a process. The following direct connections are forbidden:
Rule #3: Entity to another Entity.
Rule #4 & #5: Entity to a Data Store (or vice-versa).
Rule #6: Data Store to another Data Store.
Correct Way: Data must always pass through a process to get from one element to another (e.g., Entity -> Process -> Data Store).
3. Process Logic Rules (Avoiding Impossible Processes)
Rule #7: No "Miracles": A process must have at least one input. It cannot magically create data from nothing (no outputs-only processes).
Rule #8: No "Black Holes": A process must have at least one output. It cannot receive data and have it simply disappear (no inputs-only processes).
Rule #9: No "Grey Holes": A process's outputs must be logically derivable from its inputs. You can't get more information out than you put in (e.g., you can't produce a "Bank Statement" if you only input an "Employee ID").
4. Data Flow Rules
Rule #10: A data flow arrow is one-way. To show a read-and-update, you must use two separate arrows.
Rule #13: A data flow cannot loop directly back into the same process it just left. It must go to another process or store first.
Data Store Interaction:
Rule #14: An arrow to a data store means update (write, add, delete, change).
Rule #15: An arrow from a data store means retrieve (read, use).
Flows to Multiple Destinations:
Fork (Rule #11): A data flow that goes to multiple destinations means the exact same data is being sent to each place.
Splitting (Rule #22): A composite data flow at a high level (e.g., "Payment and Coupon") can be broken into its individual parts ("Payment," "Coupon") at a lower level.
5. Naming and Diagramming Conventions
Labeling Rules (Rules #16-19):
Process: Use a Verb Phrase (e.g., "Calculate Total," "Validate Order").
Data Flow, Data Store, Entity: Use a Noun Phrase (e.g., "Customer Order," "Products," "Manager").
Rule #20: DFDs are NOT Flowcharts: DFDs show the flow of data, not the order of operations or logical decisions (like if/then/else).
Rule #21: No Conditional Flows: Do not show a single arrow splitting to represent a decision. Instead, use separate, clearly labeled data flows for each outcome (e.g., one arrow for "Approved Application" and another for "Rejected Application").
Of course. Here are the concise, easy-to-study notes for the module on decomposing and validating Data Flow Diagrams.
1. Decomposition of DFDs
Definition: The iterative process of breaking down high-level processes into more detailed, lower-level diagrams.
Goal: To show finer and finer detail until a process is a single, simple task (this lowest-level diagram is called a primitive DFD).
Process: A Level-1 DFD is a decomposition of the Context Diagram (Process 0). A Level-2 DFD is a decomposition of a single process from the Level-1 DFD, and so on.
When to Stop Decomposing:
You can stop breaking down a process when it meets one of these criteria:
It's a single, simple task (e.g., one calculation, one decision).
It represents a single business form or computer screen.
The system user is satisfied with the level of detail and doesn't need to see more.
2. Four Types of DFDs in System Analysis
DFDs are used to model the system at different stages of analysis. The typical progression is:
Current Physical: How the system works now, including the specific people, technology, and locations involved.
Current Logical: What the current system does, stripping away the "how" (the physical implementation details). This reveals the underlying business rules.
New Logical: What the new system should do, logically. New functions are added, and obsolete ones are removed. This is the blueprint for the new system.
New Physical: How the new system will be built, including new technology, software, and processes.
3. Guidelines for Drawing Quality DFDs
Completeness: Include all necessary components (processes, stores, flows, entities). Every component should be fully described in a data dictionary or CASE repository.
Consistency: The information shown at one level must be consistent across all other levels.
Timing: DFDs do not show timing or sequence. Model the system as if it's always ready to perform its functions.
Iterative Process: Expect to revise and redraw DFDs multiple times to refine them.
Analysis Tool: Use DFDs for Gap Analysis—finding discrepancies between different models (like the "current" and "new" systems) to identify what needs to be built.
4. Validating DFDs: Finding Errors
There are two main types of errors to look for when reviewing DFDs.
A. Syntax Errors
These are "grammatical" errors that violate the drawing rules of DFDs. They are the easiest to find and fix.
Common Syntax Errors:
Illegal Connections: Data flowing directly between entities or data stores without a process in between.
Black Hole: A process with inputs but no outputs.
Miracle: A process with outputs but no inputs.
Untransformed Data: An output data flow has the exact same name as an input data flow (a process must transform data).
Unlabeled Elements: Every process, store, flow, and entity must have a clear and correct label.
B. Semantic Errors
These are errors in the meaning or accuracy of the diagram. The diagram might follow all the drawing rules (good syntax), but it doesn't correctly represent the business process.
How to Find Semantic Errors:
User Walk-throughs: Ask the system users to validate the DFD. Does it accurately reflect how they do their work?
Check for Consistency: Ensure that a single business process or piece of data is named and used the same way across all diagrams.
Ensure Accuracy: The diagram must match the real-world business logic. Using tools like use cases to build the DFDs helps prevent these errors.