REQUIREMENTS GATHERING - A Developer's Guide to Data Modeling for SQL Server - page 109

Extend
Most processes have optional behavior that is outside the “nor-
mal” course of events for that process. In our example, creating a
customer record is a process that only occasionally needs to exe-
cute within the context of making or modifying a reservation. So
the use case “Create Customer Record” is listed as an extension
of the current use case.

■

Generalization
In some cases, certain use cases inherit properties of other use
cases, or are child use cases. Whenever there is a more general
use case whose children inherit properties, there is a generaliza-
tion relationship between the use cases. In our example, the use
case is the parent use case. We look at a sample child use case a
little later.

■

Flow of Events
This section deals with the actual events that occur in the process—
the meat and potatoes. Be sure to document the majority of the
steps necessary to complete the process.
■

■

Subflows
Here's where you document any branches in the process, to ac-
count for various actions that need to take place. Depending on
the level of detail you are putting into the use case, this section
may become quite lengthy. Be careful to note any use cases
whose Subflows section becomes too long; this indicates that you
may need separate use cases to break down the process.

You can choose to add other types of information, from the execution
time of the process to lists of prerequisites for the use case to be activated.
It may also be worthwhile, in the case of detailed use cases, to document
the data inputs and outputs. This will be particularly important to you as a
data modeler so that you can associate data movement with the processes
that will be built on top of the database.

Use Case Diagrams
Now that you have documented the process as a use case, you have the
building blocks necessary to create a use case diagram. A use case diagram
is a visual representation of how a system functions. Each process, or use