|
|
|
|
|
|
|
| A Data Flow Diagram (DFD) is a concise way of describing the flows of information within a system. As such it is an important method for understanding and communicating the functionality of a system. |
| Data Flow Diagrams fulfill this objective in a number of ways: |
|
|
|
|
| Data Flow Diagramming is useful from the earliest stages of analysis (e.g. taking notes at user interviews) through to specification of user requirements. Data Flow Diagrams are working documents that are subject to continual revision and change. Some simple guidelines to be observed include: |
|
|
|
|
| Too much emphasis on the aesthetic quality of the diagram at an early stage is counter-productive in that the author can become resistant to change. |
| The shapes used for the various diagram components have been chosen so that they are easily distinguishable. |
| External Sources or Recipients |
| Processes |
| Datastores |
| Dataflows |
| Boundary Box |
| An oval denotes a Source or Recipient of information that is external to the system, or project, with which the system communicates. |
| The external sources and recipients are always outside the boundary box. |
| In most diagrams, only those sources and recipients that originate and/or receive data need to be represented. These may include company management or other external systems. |
| A source of information may also be a recipient of another piece or type of information. |
| To minimize complex crossing dataflows in diagrams, sources and recipients may be duplicated. |
| Duplicated sources or recipients are indicated by a diagonal line at the top right hand of the oval. |
| A rectangle represents a process which transforms or manipulates information in a system |
| It contains three descriptive elements: |
| Unique Identifier |
| Location |
| Description |
| The identification is a number. It has no implications for priority or sequence, and serves simply as a unique reference. |
| That number may be allocated arbitrarily at top level Data Flow Diagram. |
| In order to maintain simple, cross-referenced documentation, each process within the boundary of a lower level Data Flow Diagram is identified by a decimal extension to the higher level process identifier. |
| For example, lower level processes within Process 12 would be 12.1, 12.2, etc. |
| The location is a reference to where in the system the process takes place. |
| This may be a physical department, e.g. "Personnel Office", or a "computer". |
| The description is a simple imperative sentence, with the verb as specific as possible, e.g. |
|
|
|
| Avoid the trap of glossing over processes without really being clear about what they are. Indications of this are vague terms such as "process", "update", etc. |
| The open-ended, narrow rectangle represents a store of data that is retained and used within the system. This may be a computer file, box of documents, or any other means of storing data. Datastores may be standing, long-term files, such as sales and purchase ledgers, or short-term accumulations, e.g. daily batches of documents. |
| Each store is given a unique number and a reference : |
| "D" - a permanent computer file |
| "T" - a temporary manual file, or an internal transient /transaction computer file |
| "M" - a permanent manual file. |
| As with sources and recipients, the same datastore may occur several times on a Data Flow Diagram, to avoid complex flows. |
| Multiple instances are indicated by a double vertical bar at the left hand edge. |
| A dataflow represents the direction, and content, of the flow of information both within the system, and between the system and its environment. |
| A dataflow is represented by a line, with an arrowhead showing the direction of flow. |
| Each dataflow may be referenced by using the references of the processes, sources and recipients, or datastores, at its head and tail, but may have a description of its contents written alongside it. |
| The description must be meaningful to the reviewers of the data flow diagram. |
| At the top level the description may be omitted if a representative name cannot be found. As the process is broken down, however, names should be found. |
| In some cases, it is obvious what data is involved, and not essential to name the flow, but it is better to include an unnecessary name than to leave any margin for doubt or confusion. |
| In describing an existing system, actual document titles or references may be used. |
| For convenience and conciseness, a double-headed arrow may be used in place of two lines, where dataflows are paired. |
| Physical Resources - goods - often carry a data content which is used in the information system. |
| As such they are included in the Data Flow Diagrams as dataflows. Their name should make it clear that they are physical resources. |
| The boundary between the system, or project, and its external environment is shown by a large rectangle. |
| The Boundary Box icon is used to show either the boundary of the whole system/project, or the boundary of an individual process. |
| It is a special form of the process icon which displays the process name, reference and location. |
| On top level Data Flow Diagrams, it defines the system boundary and has reference 0. |
| On lower level Data Flow Diagrams, it defines the process boundary and displays the name, reference and location of the parent process. |
| Data Flow Diagram Types |
| Level 1 Data Flow Diagram Steps |
| Leveled Data Flow Diagram Steps |
| Logical Data Flow Diagram Steps |
| There are four types of Data Flow Diagram that are developed at different times during a development project: |
| Physical Data Flow Diagrams |
| Logical Data Flow Diagrams |
| Business System Options |
| Required Data Flow Diagrams |
| If it has been decided to investigate the current system, then the physical Data Flow Diagrams will be the first type produced. |
| If, however, the current system is not to be investigated, then the technique will first be used to create a set of Business System Option to present to the user. These options will be depicted, in part, as Level 1 Data Flow Diagrams. |
| Physical Data Flow Diagrams depict the scope of the project and the current system. |
| They can be of varying degrees of complexity. |
| A simple model can be used for estimating purposes and for initial scoping. |
| A more complex diagram can model the current business. |
| Use the Level 1 and Leveled Steps. |
| These are derived from the current physical Data Flow Diagrams, and show the underlying functionality of the system, without the constraints imposed by its current implementation. |
| Use the Logical Steps. |
| These show one or more business system options from which one must be chosen to form the basis of the required system |
| Use Level 1 Steps. |
| These depict the required system and are developed from the Data Flow Diagram that represents the selected business option. |
| Use the Leveled Steps. |
| Overview of Approach |
| Step 1: List Key Flows of Information |
| Step 2: Create Initial Data Flow Diagram |
| Step 3: Agree System Boundary |
| Step 4: Identify Processes and Datastores |
| Step 5: Complete the Level 1 Data Flow Diagram |
| Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning |
| Step 7: Review the Data Flow Diagram |
|
|
| The approach set out below can be used for creating a Level 1 Data Flow Diagram depicting a current system, or a proposed Business System Option. |
| The analyst is first concerned with establishing the basic characteristics of the system being considered. These basic characteristics are: |
|
|
|
|
| The partitioning implied in the identification of system processes may also be useful in partitioning the workload and allocating analysts to specific areas of the system. |
| Note that although the user must review results in steps 3 and 7, the user should be involved in the other activities at least in the form of interviews and question and answer sessions, etc. |
| Users may also actively participate in constructing the Data Flow Diagram. |
| List key documents and information flows used in and produced by the system, and the sources and recipients of those flows. |
| These information flows will help to define the main elements of the system. Examples are: |
|
|
|
| Notice that minor documents and exception documents are omitted at this stage so that attention is initially focused on the main functions of the system. |
| Other documents can be noted for consideration at a later stage, when expanding the top level Data Flow Diagram or developing second and third level Data Flow Diagrams. |
| Also omitted are "inquiry only" dataflows. |
| Initially, expect to deal with no more than about 15 dataflows. |
| The objective at this stage is to identify the sources and recipients of information in the system and to chart the main communications between them. Too much detail will obscure the basic "shape" of the system. |
| As well as listing documents in Step 1, sending and receiving locations (the sources and recipients) must be determined. |
| Build an Initial Data Flow Diagram showing only the source and recipient of each key document and the flows between them. |
| In this activity, the receiver and sender locations of each document are identified, and the Initial Data Flow Diagram (or Information Flow Diagram) is drawn. For this activity, a receiver or sender may be one of the following: |
|
|
|
| In this activity, all senders and receivers are represented by the Source/Recipient symbol. |
| The initial Data Flow Diagram is built incrementally, document by document. To improve clarity, experiment with different layouts. |
| Actual document names should be used during this step to improve readability and user understanding. There may sometimes be conflicts between accuracy and readability which common sense should be able to resolve. For example, the readable term may be "sales order" but what the system strictly processes is the "sales order form." |
| Unless there is real danger of confusion, the simpler term can be used at this stage, to be replaced by more accurate definitions, and even document reference numbers, once the detailed Data Flow Diagrams have been produced. |
| A quick completeness check should be performed by identifying locations that are only sources or recipients, and by considering whether this is correct. |
| Determine the system boundary and mark it on the Initial Data Flow Diagram. |
| The Initial Data Flow Diagram must be reviewed with the user, initially to ensure accuracy and then to determine the system boundaries, i.e. the scope of further systems analysis and design needs. |
| At this point, the user may mention further documents and communications between senders and receivers. These can either be added to the Initial Data Flow Diagram if they are of major importance, or listed with the minor documents for attention later. |
| When the current system is being investigated, the analyst must obtain the user's guidance and agreement on the scope of the systems analysis. |
| Those areas whose method of working is likely to be radically changed should probably be within the scope of the analysis. Those who will not be changed will, usually, not be investigated further. |
| The main exception is when the information provided to, or received from the excluded area is to be changed. In this case, it may be necessary to provide instructions or explanations connected with the changed information flows. |
| It may also be necessary to review the identification of the senders and receivers in the light of user comments and the definition of the scope of systems analysis. |
| In these areas, only the portions of the activities that impact the order processing system are addressed. |
| Note that when a system boundary is added to the Initial Data Flow Diagram, external sources and recipients cannot be inside the system boundary - the sources and recipients inside the boundary are replaced by processes. |
| If there is any difficulty conveying the exact scope of the system, it may be worth drawing a 'Context Diagram' showing the entire system area to be investigated as a single 'black box' process, receiving inputs and supplying outputs to the external entities. |
| Although conceptually trivial, this representation for more complex systems does focus attention on the system boundaries. It can convey clearly and concisely the scope of a system and the environment in which it exists. |
| For each flow crossing the system boundaries on the Initial Data Flow Diagram, identify its receiving or generating process and associated datastores. |
| Now the parts of the Initial Data Flow Diagram that are within the system boundary can be expanded. This is done by identifying the processes associated with each flow. |
| Each sender or receiver within the system boundary will be expanded into one or more processes. Datastores should also be added at this stage. |
| A single (Level 1) level Data Flow Diagram should be produced, but if the emerging picture seems too extensive and elaborate (more than 12 process boxes), some of these processes should be grouped under a more general name. |
| This step is initiated by adding a "generating" and/or "receiving" process to each document in the flow. |
| For each process, physical datastores that may be used to store or retrieve data are identified. In discussions with the user, or from existing knowledge of the Business System Option being depicted, datastores that are used are identified, and then recorded on the Data Flow Diagram. |
| Three main types of datastores may be identified: |
| "D" Type Datastores - Permanent Computer Files |
| "T" Type Datastores - Temporary, Transient, Transaction Files |
| "M" Type Datastores - Permanent Manual Files |
| Each process must be evaluated to determine whether it needs to retrieve data from, or store data in, any of the three types of datastores. |
| Input processes, for example, often retrieve standing data for validation purposes and create reference copies and batch accumulations of transactions. |
| It is useful to have a checklist of likely datastores or types of datastores to ensure that none are missed. |
| Every sender and receiver which is now located outside the system boundary becomes an external source or recipient with respect to the system being depicted. |
| Each of the documents entering the system is received by a process which deals with it, similarly each document produced by the system originates with a process. |
| The initial assumption is that every document has a separate input or output process. However, processes may be combined if this is clearly appropriate. |
| Each process is given: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Complete the overview Data Flow Diagram by adding further dataflows and processes if needed. |
| There are two reasons why the Data Flow Diagram produced in Step 4 may still be incomplete. |
|
|
| In this step, the most effective approach is generally to work backwards from the output processes, asking the following questions: |
|
|
| The extra elements identified are then added to the Data Flow Diagram. |
| Review the Data Flow Diagram for consistency, completeness, and effectiveness of the partitioning into processes. |
| Before the final review some simple checks for consistency and completeness should be carried out. Before considering these checks in more detail, the purpose of a Data Flow Diagram should be reviewed. |
| For the current system, these checks are: |
|
|
|
|
|
| For Business System Options, the checks are: |
|
|
|
| It is helpful in this activity to ensure that each process can be investigated independently with few references to other processes; this is called partitioning. |
| If partitioning has taken place, it is easier for many analysts to work in the detailed investigation without duplicating, overlapping or getting in each other's way. |
| The three tests listed below are intended to help verify that the most useful or optimum approach to partitioning has been chosen. |
|
|
|
| Initially, producing too low a level should be avoided. Level 1 Data Flow Diagrams will later be expanded into level 2s, and some of these may possibly be expanded into level 3s. |
| To ensure completeness and consistency. |
|
|
|
| The final step in producing the Level 1 Data Flow Diagram for the current physical system is to review it with the user. Given the amount of interaction in producing the Level 1 Data Flow Diagram, major surprises should be rare at this point. However, it is worth ensuring that: |
|
|
|
| When producing Data Flow Diagrams of Business System Options, normally two or more options are produced for user review and discussion. |
| Overview of Approach |
| Step 1: Minimize Number of Level 1 Data Flow Diagram Processes |
| Step 2: Identify Lower Level Processes and Datastores |
| Step 3: Balance Lower Level Data Flow Diagram with Higher Level Data Flow Diagram |
| If the original definition of processes (partitioning) has been done effectively, it should be possible to expand or decompose each process with little or no reference to other processes. |
| The basis of effective partitioning is that each process defined should represent a self-contained activity, i.e. that, as far as possible it should contain no activities which are also contained in another process at the same level. |
| For example, it would be unhelpful to partition a Level 1 Data Flow Diagram on the basis of geographic locations (process 1 represents office A, process 2 office B, etc.) when similar or overlapping activities are carried out in each one. |
| Avoid the creation of giant Level 1 Data Flow Diagrams. As a general rule, a Level 1 diagram should have not more than 12 to 15 process boxes. For large systems, this may seem difficult to achieve. |
| The recommended solution is to reduce the number of Level 1 processes defined by merging some under a more general name. |
| For example, "Maintain Customer Names and Addresses" and "Set Credit Limits" might become "Maintain Customer Details". |
| In looking for suitable processes to merge, look for the following indicators. Processes which: |
|
|
|
|
| Start by merging those processes which seem the least complex and continue until a reasonable number of Level 1 processes remain. |
| This will result in a better "balanced", more readable set of Data Flow Diagrams - probably without increasing the overall number of levels involved. The merged processes should not be lost but held for inclusion in a lower level Data Flow Diagram. |
| When the user has reviewed and accepted the Level 1 Data Flow Diagrams of the current system, the work may be defined in greater detail by the creation of level 2 Data Flow Diagrams. |
| If the Level 1 Data Flow Diagrams represent Business System Options, then it is after the chosen option has been selected that the analyst begins to define the required system in more detail. Part of this detailed definition will be in the form of level 2, and sometimes, level 3 Data Flow Diagrams. |
| Each process box on a Level 1 Data Flow Diagram should be considered separately and may be expanded into a Data Flow Diagram in its own right. These lower level processes can be further expanded until a satisfactory level of detail is achieved. |
| In order to maintain simple, cross-referenced documentation, each process within the boundary of the lower-level Data Flow Diagram is identified by a decimal extension to the higher level process identifier, e.g. processes within Process 12 would be 12.1, 12.2, etc. |
| A Level 1 process would typically expand to between 4 and 8, level 2 processes. When exception and error handling processes are added to the Data Flow Diagrams, each second-level Data Flow Diagram may have about 6-12 process boxes. |
| Again giant lower levels should be avoided. The processes should be merged using the same techniques for reducing the number of Level 1 processes. |
| External sources and recipients are not shown within the boundary of a process even if they communicate only with that process but are always shown outside the process boundary. |
| If datastores are used only within a process boundary, they are drawn inside the boundary. Datastores which are also used by other processes remain outside the boundary of the lower level Data Flow Diagram. |
| The lower level expansion may force the analyst to investigate the details of processing in greater depth in order to create an accurate view. |
| Inclusion of the changes introduced by the expansion of a process to a lower level may result in changes/additions to the Level 1 Data Flow Diagram. |
| When producing lower level Data Flow Diagrams, it is often necessary to show separately the processes which are activated by the same source but are treated differently. |
| The maintenance procedure for a Product and Prices file may, for instance, be shown on the Level 1 as: |
| The lower level Data Flow Diagram would show this as three separate flows. This approach to breaking down dataflows is called "parallel decomposition". |
| The production of logical Data Flow Diagrams involves a three step conversion from physical to logical. |
| Overview of Approach |
| Step 1: Convert Datastores (Physical to Logical) |
| Step 2: Convert Dataflows (Physical to Logical) |
| Step 3: Convert Processes (Physical to Logical) |
| In producing the current physical Data Flow Diagrams, "how the system works" is recorded. |
| It is important that this is understood and can be demonstrated to the user. It is also a useful medium for identifying problems in the current system. |
| However "how the system works" is invariably more complex than "what the system achieves" because of the physical constraints within which it was designed to operate. |
| These constraints may include: |
|
|
|
|
| By creating a current physical Data Flow Diagram, an understanding of the current system processing and the underlying business activities it supports has been gained. |
| This knowledge is used to abstract those elements that needed to support the business activities and discard any physical constraints or anomalies |
| Produce a logical Data Flow Diagram to do this. Producing a logical model is an intermediate step towards the goal of specifying the required system. |
| Logical Data Flow Diagrams will provide: |
|
|
| The files within a system usually provide the underlying structure around which the system's processing is designed. In cases where files are poorly designed, the system's processing will also contain related anomalies. Some typical problems associated with file designs are: |
|
|
|
|
| The purpose of this step is to identify the problems associated with the existing file structures. |
| The logicalization of datastores will provide a basis for redefining and streamlining the systems processes. |
| It is not a direct input to the process of rigorous physical design of the files/database to be used in the required system - a task addressed later in the project. |
| Outlined below are the steps necessary to convert the current physical datastores to logical datastores: |
| Review Transient (T) Datastores |
| Redefine Datastores by Reference to the Data Model |
| Replace Datastores on the Current Data Flow Diagram |
| Transient files are normally introduced when there is a time delay between processes or a performance pay-back in batch processing. |
| "T" type datastores are reviewed in order to check that they are logically required. This is done by applying two tests: |
|
|
| The current physical Datastores may contain badly organized or redundant data. This will be highlighted when the Physical Datastore/Entity Cross-Reference table is drawn up. |
| To prevent such a situation being carried forward into the new system, the Datastores must be re-organized logically. |
| The files needed to reflect the data accurately within the application can be determined from the Current Data Model. |
| There are three rules that must be applied: |
|
|
|
| The physical datastores shown on the Data Flow Diagrams are replaced with the entity or group of entities shown on the Data Model. (Note that this Data Model has no redundancy, i.e. each entity occurs only once). |
| Rather than re-draw the Data Flow Diagram showing entities and collections of entities instead of datastores, the Data Model is divided into a set of "subject" clusters. Each cluster will represent a "logical" datastore. |
| The Data Flow Diagram is modified to show these logical datastores instead of physical ones. |
| Revise the datastores on the Data Flow Diagram to reflect the entity sub-structures they represent. |
| This is done by replacing the "current physical" datastores shown on the Data Flow Diagram with the "logical" datastores that have been defined. |
| To achieve this, it may be necessary to combine or split dataflows. |
| Logical datastores should all be given the "D" prefix. |
| Many of the redundant dataflows would have been removed in the previous step. |
| In order to resolve any remaining anomalies, the dataflows must first be renamed to reflect the actual data being passed. |
| Any duplicate flows can then be removed. |
| Rename the Dataflows |
| Remove Redundant Dataflows |
| Provided below is a checklist of the things to consider when renaming dataflows: |
|
|
|
| Redundant dataflows appear in two forms. |
|
|
| In order to discover redundancy in dataflows, the data contained in each flow must be defined. Producing a list of the content of each flow helps to highlight redundancy. |
| The final Logical Data Flow Diagram Step is to remove possible problems associated with the processes. This involves reviewing each process for the following types of problem: |
| Redundant Processes |
| Incorrect or Unnecessary Functional Division |
| Illogical Sequencing of Processes |
| Unnecessary Processing Cycles |
| This activity ensures that each process either: |
|
|
| Any process which does not satisfy the above conditions, should be removed from the Data Flow Diagram because they are a feature of the current environment and do not support the business. |
| At this point, the remaining processes are renamed to reflect the actual activity performed and references to physical locations are removed. |
| This activity may result in merging Data Flow Diagram processes (in a similar way to that employed when avoiding 'giant' Data Flow Diagrams) in order to improve functional division. |
| The rationale for deciding which processes to combine is as follows: |
|
|
| The rule to be applied for this step is that sequencing of processes is only necessary when: |
|
|
| Systems will frequently have physical processing cycles associated with them. Such processing cycles are concessions to implementation constraints and should be removed. |
| Processes that are carried out daily, weekly, or monthly in the current system may be constrained by the current physical organization and not by the requirements of logical processing (e.g. a picking list may not be produced until a certain number of orders to be filled are received). |
| However, if the processing cycle represents a business or legislative constraint upon the system (e.g. end of year accounting, weekly payroll, etc.) it should be retained. |
| Level 1 Data Flow Diagrams |
| Leveled Data Flow Diagrams |
| Logical Data Flow Diagrams |
| Overview of Tutorial |
| Step 1: List Key Flows of Information |
| Step 2: Create Initial Data Flow Diagram |
| Step 3: Agree System Boundary |
| Step 4: Identify Processes and Datastores |
| Step 5: Complete the Level 1 Data Flow Diagram |
| Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning |
| A simple order processing system is developed to illustrate the process. The systems operation can be described as follows: |
|
|
|
| Customer Service uses the report to identify errors, correct the original Sales Orders, and send the corrected Sales Orders to Data Entry as re-input Sales Orders |
|
|
|
| Assume that the following are relevant to the example: |
|
|
|
|
|
|
|
|
| Examples of documents that typically would have been left out of the above list include: |
|
|
|
|
| The sending and receiving locations appear to be: |
|
|
|
|
|
|
|
| Is it reasonable that the Shipping department only receives documents but does not output anything? |
| In fact, the Warehouse sends the picked goods to the Shipping department. The Shipping department sends corrected Consignment Notes with the goods to the Customer and updates the computer system with Consignment Adjustments. |
| The scope of the system may include most of the following areas: |
|
|
|
|
|
| Some of these areas are only partially within the system boundary: |
|
|
|
|
|
|
|
| Starting with Sales Order Forms, these documents are sent by Customers to Customer Service where they are received and sorted into batches. The flow becomes: |
| "Are any files used in the process?" |
| In this case the answer is "no." |
| The document flow at the end of Step 3, can be used to assist in considering each document and adding a "generating" and/or "receiving" process. |
| Take each document in turn to build up the Level 1 Data Flow Diagram in this way. |
| When considering the third process and asking the question "does the process use or output any datastores?", it is discovered that in this case the Validate process uses both Customer and Product Files. These are added to the diagram at this stage. |
| Question 1 - "How does Process 5, 'Check Inventory and Price', obtain Sales Order Data?" |
| Answer 1 - "A temporary datastore of Validated Sales Orders." |
| Question 2 - "From where does Process 8, 'Adjust Consignment Notes',get its data?" |
| Answer 2 - "A dataflow from Process 7 'Create Consignment'." |
| Question 3 - "Does 'Create Invoices', Process 9, require only Invoice Details as input?" |
| Answer 3 - "Process 9 also requires Customer Names and Addresses from the Customer datastore Create Invoices." |
| In the example provided, a completeness check will indicate the following: |
| Question 1 - What happens to Valid Sales Orders for which there is no Inventory? |
| Answer 1 - The Check Inventory and Price process (process 5), has as both input and output a re-cycling Pending Order datastore |
| Question 1 - What happens to the original Sales Order Forms? |
| Answer 1 - The original Sales Orders, once data prepared (process 2), are stored in a manual datastore and used in the Correction process (process 4). |
| Step 2: Identify Lower Level Processes and Datastores |
| Step 3: Balance Lower Level DFD with Higher Level DFD |
| Initial Level 2 Diagram For Process 5 |
| Question 1 - "Does the Process 5 feed Picking Lists and Consignment Notes directly into Processes 6 and 7?" |
| Question 2 - "Is there anything else missing from the process?" |
| Question 3 - "Is the Pending Order file, D5, used only within the Check Inventory and Price process?" |
| Final Level 2 Diagram for Process 5 |
| Answering the second question reveals that when Balance Failures occur in Process 5.4, the system creates a temporary file of failures that is later processed to produce a "Credit Failure" report which is sent to the Accounting department. |
| The third question, concerning the "Pending Order" file, highlights the point that a datastore, shown on a Level 1 Data Flow Diagram, must be shared by more than one process. |
| In the example, the "Pending Order" file is used wholly within the "Check Inventory and Price" process, and thus becomes an internal datastore. |
| After inclusion of the changes introduced by the expansion of the "Check Inventory and Price" process, the Level 1 Data Flow Diagram will have to be modified accordingly. |
| Overview of Tutorial |
| Step 1: Convert Datastores (Physical to Logical) |
| Step 2: Convert Dataflows (Physical to Logical) |
| Step 3: Convert Processes (Physical to Logical) |
| In order to illustrate these steps, an example based on an order processing Data Flow Diagram is provided. |
| The Data Flow Diagram is the same as the one developed in the section on Level 1 Data Flow Diagrams, except that the "Pending Order" datastore and amendment process have been added to provide an example of logicalizing datastores. |
| An "Adjust Inventory Quantity" process box has also been added to demonstrate the logicalization of processes. |
| A Data Model has been provided to assist in the process. |
| Review Transient (T) Datastores |
| Redefine Datastores by Reference to the Data Model |
| The creation of picking lists requires batched input and needs a transient file. |
| The creation of consignment notes, on the other hand, requires neither batched input nor a time delay between the processes. |
| Therefore, the Data Flow Diagram should be modified to show this. |
| The result is the separation of the "Create Picking Lists" and "Create Consignment Note" processes, with consignment note data going directly to the latter process. |
| D1 Customers |
| D2 Products and Prices |
| D3 Inventory |
| D4 Invoice Details and D5 Pending Orders |
| Existing Datastore is Logical |
| Existing Datastore is Logical |
| Existing Datastore is Logical |
| In the above illustration, the Order Line entity is represented in two datastores, (the rule states that an entity can belong to only one datastore). |
| Also, the Invoice Detail datastore contains a significant amount of Sales Order data. |
| The logical solution is to create a single datastore from Invoice details and Pending Orders. |
| The logical datastore resulting from this combination would be represented on the Data Model as the following sub-structure. |
| Rename Dataflows |
| Redundant Flows |
| Note that the filled orders passed to Process 13, "Create Consignment Notes", contains the Customer name and address (left hand side of diagram). Assuming that this data is available in the Customer datastore, it should logically be passed to the process from there, rather than through the "Check Inventory and Price" process (right hand side of diagram). |
| Remove Redundant Processes |
| Incorrect or Unnecessary Functional Division |
| Illogical Sequencing of Processes |
| Unnecessary Processing Cycles |
| Processes 1 and 2 are removed because they neither validate the dataflows, nor logically change dataflows or datastores. |
| Processes 9 and 11 are separated only because of a difference in location (i.e. Dispatch and Inventory departments). Logically, they should be combined. |
| The "Create Consignment" process, (process 7), in data processing terms, only adds actual quantities to the consignment details. It can therefore be merged with Process 11. |
| It is logically correct for the order to be validated prior to being filled; this sequence must be retained. Note that no occurrence of illogical sequencing exists in the example. |
| In the previous example, there was no business constraint that specifically required the balance failures to be reported on a particular cycle, i.e. weekly, or monthly, etc., so this processing cycle could be removed, as shown below. |