The Functional Specifications - Data Flow Diagrams Oracle Database Tips by Donald Burleson

The generally accepted starting point is to begin with either a traditional data flow diagram or a functional model.  (Remember from chapter 3 that a data flow diagram and functional model is almost the same thing)  Let's begin by doing a short review of object analysis.  A functional specification for any system describes the complete logical model and consists of three documents.  The data flow diagram is a pictorial description of all of the processes in the system, and it is supplemented with two other documents.  The data dictionary, that is used to define all of the data flows and data stores in our system, and the process logic specifications (mini-specs) that are used to describe each process, showing how the data flow is modified within each process.

As we may remember from Chapter 3 and our discussion of basic object analysis, the data flow diagram is the foundation of any systems analysis.  The DFD  , diagrams the processes, data flows and data stores as we decompose the system.  While these documents may be known by different names depending upon the analysis methodology that is chosen, they should contain a complete description of all of the entities in our system.  Let's begin by taking a level one data flow diagram and showing the breakdown of the processes (Figure 8.2). 

Figure 8.2 - A level one data flow diagram for filling orders.

Here we see the overall specification for the ?fill order? process, and we can easily see all of the incoming and outgoing data items.  In this case, we see ?cust_info? coming in as the input to the ?fill order? process.  Of course, ?cust_info? does not tells us about the details of this data flow, and we must go to the data dictionary to see the contents of cust_info:

cust_info =  

cust_full_name +
                cust_last_name
                cust_first_name
                cust_middle_initial 

cust_full_address +
                cust_street_address
                cust_city_name
                cust_state
                cust_zip_code 

cust_phone_nbr + 

1
{ item_ID + item_quantity }
n 

We will use these data dictionary definitions to gather the data items that are of interest to each process in our data flow diagram.  Remember, the purpose of designing methods is to map the incoming and outgoing data flows to clean, well-defined procedures that can be coupled with the database entities. 

Now let's take a look at how the fill_order process is decomposed into lower level DFDs.  Looking at the next lowest level DFD (Figure 8.3), we see that fill_order is broken down into three sub-processes, check_customer_credit, check_inventoty, and prepare_invoice.  This DFD shows all of the input and output data flows for these processes.

Figure 8.3 - A level two data flow diagram for the fill order process.

Here we see another level of detail for the fill_order process.  This process is broken down into three sub-processes, each with its own data flows and processes.  As we might guess, the departitioning of the processes will correspond to the departitioning of the methods for our object database.

Let's complete the foundation for our methods by showing the next level DFD for some of the lower-level processes, we will use the check_inventory process (Figure 8.4) and the prepare_invoice process (Figure 8.5).  We can assume that these are ?functional primitive? processes and they will serve as our lowest level methods in our example.

It is important for the mapping of methods to database objects to understand when a process has been departitioned to a level that corresponds with the functions of a database entity.  We could continue to departition this DFD, making each process smaller and smaller, but the sub-processes would not easily map to the database objects.  Hence, when we see that a process on our DFD deals with a single function on a single database entity, we know that we have reached the ?functional primitive? level, and the analysis is complete.

Figure 8.4 - The data flow diagram for the check_inventory process.

Figure 8.5 - The data flow diagram for the prepare_invoice process.

Now that we have completed the functional specifications for this system we are ready to take these definitions and create the ?prototypes? for the methods that will eventually become the methods for our database objects.

 

---