Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Data Dictionaries for DFDs
This material was covered during lectures on January 31 - February 3, 1997.
In this course, we will usually extend an existing data dictionary for a system's ERD, by adding definitions for components of the system's data flow diagram(s), rather than creating a completely new one for the data flow diagram(s) alone.
A data dictionary definition should be given for every data store and data flow that appear on the diagram(s). One might choose to give definitions for terminators and processes as well - but these definitions wouldn't generally be very informative, so we won't bother to include definitions for these in this course.
All of the data dictionary symbols that were introduced for data dictionaries for ERDs are useful for data dictionaries for DFDs as well. Two additional bits of notation will be useful to define data flows and data stores:
Sometimes, when it is possible to ``typeset'' a data dictionary, the ``lower bound'' i used in the above definition of sequences will be written as a subscript of the right curly bracket, while the ``upper bound'' j will be written as a superscript of this curly bracket. That is, one might write
{T}ji
instead of i{T}j.
Note that the above ``example'' won't look right if you're viewing this page using lynx!
In a data dictionary definition for a data store, the ``kind'' listed will be ``DS.''
Many data stores on a data flow diagram will correspond to some component of the system's entity-relationship diagram. If we have a data store such that this is the case, then the definition for the corresponding component on the ERD can be used to help form the ``type definition'' for the data store.
For example, consider Version One of the Student Information System. A single data flow diagram for this system has already been given, and this includes a single data store, ``Student.'' An entity-relationship diagram for this system, and a data dictionary for it, have been given for this system as well. The ERD contains a single entity, ``Student;'' this has been defined in the ERD's data dictionary; and the data store ``Students'' on the DFD corresponds to this.
Under these circumstances, ``Students'' can be defined as follows.
Name: Students
Kind: DS
Type: { Student }
Description:
That is, we can think of an entity (or associative object, etc.) as being ``equivalent to'' a single instance of it, and then define the corresponding data store as a sequence of these.
Note as well that (as shown here) it isn't necessary to try to give an ``informal description'' in every data dictionary definition you provide; sometimes you just won't have anything useful to add to the ``formal'' part of the definition.
In general, the only kind of data store on a data flow diagram that doesn't correspond to some part of the ERD will generally be a ``register,'' which can only hold a bounded amount of information. The ``type'' for this will generally be one of the standard data types, or perhaps an aggregation of a fixed set of these. It certainly shouldn't involve a sequence.
In a data dictionary definition for a data flow, the ``kind'' listed will be ``DF.''
We'll consider several different cases which might arise.
If a data flow has the same name and type as an attribute of something on the system's ERD, then you shouldn't give two definitions. Instead, you can simply change the ``type'' in the definition for the attribute from ``At'' to ``At, DF.''
Consider, again, the above example. The entity ``Student'' has an ``ID number'' as one of its attributes, and (the same type of) ``ID number'' also appears as a data flow on the system's data flow diagram. In order to add the definition for the data flow, you can simply replace the existing definition,
Name: ID number
Kind: At
Type: integer
Description: A key attribute of Student; should be exactly eight digits long
with the new definition
Name: ID number
Kind: At, DF
Type: integer
Description: A key attribute of Student; should be exactly eight digits long
Some data flows correspond to a single instance of some component of the system's ERD. For example, in the diagrams used in this course, all data flows going into a data store have this property, if the data store corresponds to some component of the ERD, itself. In the diagrams used as examples in this course, the data flow will have the same name as the data store - except that the first letter of the name won't be capitalized - when this is the case. Under these circumstances, the data flow can be defined quite easily: Just list the name of the corresponding entity (etc.) as the data flow's ``type.''
Continuing the above example, note that there are several data flows with name ``student'' going in the data store ``Students'' on the system's data flow diagram. Each of these data flows corresponds to a single instance of the entity ``Student'' (that is shown on the ERD), and the data store corresponds to this entity as well. Now, the data flow ``student'' can be defined as follows.
Name: student
Kind: DF
Type: Student
Description:
Similarly, some data flows correspond to a sequence of instances of some component of the system's ERD. It will almost certainly be the case that some other data flow corresponds to a single instance of the same component, and the name of the ``data flow corresponding to multiple instances'' will probably be just the plural form of the name of the ``data flow for a single instance.'' This will make the type of the ``data flow corresponding to multiple instances'' extremely easy to define, as a sequence of values whose type is that of the ``data flow corresponding to a single instance.''
For example, the data flow ``students'' shown on the above-mentioned DFD could be defined as follows.
Name: students
Kind: DF
Type: { student }
Description:
The types of other data flows should be defined in terms of the ``standard'' data types, using aggregation (``+''), selection (``[ | ]''), optional values (enclosed by `(' and `)'), and sequences (constructed using `{' and `}') to define more complex types.
Indeed, the types of the above ``special kinds of data flows'' could be defined that way, too. However, the shortcuts given above do save some time, and reduce the possibility of errors being introduced when parts of the specification is changed.
It can be useful to introduce an ``intermediate'' or ``auxiliary'' definition, that doesn't correspond to any attribute, component of an ERD, or part of a data flow diagram itself, but that can be used to define these other things more easily.
Suppose, for example, that you wish to define a ``telephone number'' as something that is either a 7-digit ``local number'' or an 11-digit number that begins with a ``1,'' continues with a 3-digit ``area code,'' and ends with a ``local number.'' You (presumably) want to define this because ``telephone number'' is a data flow somewhere on the system's data flow diagram(s). Suppose that ``area code'' and ``local number'' don't appear anywhere as attributes or components of the system's ERD or data flow diagram(s). Now, if you ``couldn't'' include definitions for these in the system's data dictionary, then you might define ``telephone number'' as follows.
Name: telephone number
Kind: DF
Type: integer
Description: Should be 7 or 11 digits long; either a local telephone number, or a `1', followed by an area code, and then a local number...
On the other hand, you could introduce ``auxiliary definitions'' for ``area code'' and ``local number,'' and then give a definition for ``telephone number'' that is (arguably) a little bit easier to read. I've added a bit more detail (that used to be accurate in North America, and might still be), in this alternative set of definitions; while you could add these extra details to the single definition given above, its ``description'' would end up being fairly long.
Name: area code
Kind: H
Type: integer
Description: Should be exactly three digits long; first digit shouldn't be a `0' or a `1', while middle digit must be one of these. Used to define ``telephone number.''
Name: local number
Kind: H
Type: integer
Description: Should be exactly seven digits long; neither the first nor the second digit should be either a `0' or a `1.' Used to define ``telephone number.''
Name: telephone number
Kind: DF
Type: `1' + ( area code ) + local number
Description:
As shown above, you can use `H' as the `kind' for an auxiliary definition.
It isn't necessary to include definitions for these in data dictionaries that are prepared for this course. Even if you wanted to include them, just about all you could say in a ``definition'' of a terminator is that it is a terminator. Since processes will be described using ``process specifications'' (or, shortly, by other data flow diagrams), it isn't clear that a ``data dictionary definition'' for a process would serve any purpose at all.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Data Dictionaries for DFDs