CPE 308
Winter 2009
Turner
Homework #1 Data Dictionary 


Integration of the software can be quite an undertaking, especially if any of the modules make different assumptions about the "model" of the world in the problem domain.  To minimize later rework and problems, agreement on the precise definitions of the data entities must be recorded (and maintained with any changes or improvements).  This data dictionary becomes one of the central documents to understanding the system.  

You are to work on a basic data dictionary for the Grader Tool project.  Talk to the customer, note your own experience, begin to build a model of the data items in the problem domain of the grader tool.  What are the data items our tool must import, export and manipulate in order to solve the problem efficiently?  

DEFINITIONS and DETAILS:
A data dictionary is a detailed, formal description of all of the data entities in the Problem Domain .
The requirements engineer can elicit the data entities in a variety of ways:
  1. The nouns used by the user when speaking about the system.
  2. The nouns in the use case list.
  3. A brainstorming session with or without the user.

There are a wide variety of methods to write data dictionaries.  I suggest one from Wiegers.  

-  A data dictionary differs from a Glossary; a Glossary defines words, acronyms and terms in the system documentation.

-  A data dictionary differs from data structures; data structures are the data entities defined in the programming language.

The language used here is from textbook: Wiegers, "Software Requirments," 2nd Edition.  (A very useful book for this course, btw, used in many other courses, used copies ought to be available in town.)

The entities are organized hierarchically. Another acceptable organization is alphabeticly. 
Each has its advantages but most readers tend to prefer a hierarchy.  

Primitive data elements have no decomposition, they are atomic.  They are defined by the primitive's data type, size, range of allowed values, and other pertinent attributes.  Define them with a comment (delimited by asterisks), as in "Request_ID" below.  

Request ID = * a 6 digit system-generated sequential integer, beginining with 1, that uniquely identifies each request. *

Composition is defined for a data item that contains (other) multiple data items, using the "+" symbol, such as "Requested Chemical" below.   If an element is optional, enclose it in parenthesis as in vendor below.

Requested Chemical = Chemical ID
                                + Grade
                                + Amount
                                + (vendor)

Iteration allows for multiple instances of an item, enclosed in curly braces, as in "Request" below.  Note that the permissible range for the number of items is given in front of the curly braces.  

Request    =    Request ID
                 +    Request Date
                 +    Charge number
                 + 1:10{Requested Chemical}

Selection allows for enumerated primitives - a data element that can take on a limited number of discrete values.  Show the possible values in a list contained within square brackets, with vertical bars separating the list items.  

Quantity Units    =    ["grams"    |     "kilograms"    |     "milligrams"    |    "each"]
                                 * 9-character text string indicating the units associated with the quantity of chemical requested *

(Examples from Wiegers pages 190 and 191.)


Last updated 1/2009