The final section of the use case lets you express the details of your database requirements. Your narrative and activity diagram have referred to data elements and constraints, perhaps in an informal way. This section gives you a place to collect your requirements to show the overall impact of the use case on the database. You can also use this section in counting function points to estimate complexity factors [Garmus and Herron 1996].
Expanding a bit beyond the database, you can also summarize the set of objects and operations that the use case uses. As the section "Narratives" mentioned, these elements find their expression in design-related diagrams such as the class diagram and interaction diagrams. Whether or not you decide to link your use cases explicitly to these diagrams, it is useful to summarize their use in the use case itself.
Any data element to which your SQL or OQL statements refer should appear here, organized within their table, type, or class. The Identify Criminal with Alias use case, for example, refers to these data elements with Table 4-1. Business rules are constraints on the data or operations. Use cases mention both simple and complex constraints because the use of the data is the context in which such constraints usually apply. Often, however, your design will move these constraints into the database as triggers or constraints in the database schema. Regardless, the use case specifies the rules to ensure that the point of view of the user of the system comes through to the design. Since multiple use cases impose different rules on the data, the database design may reflect the input of several use cases, not just one. Sometimes the business rules even conflict between different use cases, making it necessary to design negotiation layers to handle the conflict. The source of these business rules is the use case narrative. Again, to make it easy for the user and designer to understand the rules, placing them in a summary is very useful.
For example, a simple rule is that a Person must own an Alias. That is, there is a foreign key constraint that requires the Alias to have an associated PersonID to identify the person. PersonID is therefore part of the primary key of the Alias table as well as being a foreign key to the Person table. What about an alias that you know about but that you can't yet link to a person? For example, Sherlock Holmes once dealt with a very secret informer [VALL]:
Table 4-1: Identify Criminal with Alias Use Case Data Elements Table
Table Column Comments
Person PersonID Unique integer
that identifies the person
Name The composed
name of the person
(concatenation of first and last
names)
Alias PersonID A foreign key to
Person.PersonI D
Alias An alias name
of a person; the actor passes this alias in to use to look up the person
"Porlock, Watson, is a nom-de-plume, a mere identification mark; but behind it lies a shifty and evasive personality. In a former letter he frankly informed me that the name was not his own, and defied me ever to trace him among the teeming millions of this great city."
…"Did you never trouble to see who called for [these letters]?" "No."
The inspector looked surprised and a little shocked. "Why not?"
"Because I always keep faith. I had promised when he first wrote that I would not try to trace him." "You think there is someone behind him?"
"I know there is."
"This professor that I have heard you mention?"
Given the circumstances, perhaps the business rule about linking each alias to a person is getting in the way. This is a fairly common design problem. You could dispense with the business rule and have aliases that don't correspond to people. Unfortunately, that would mean that querying people through aliases would simply miss Porlock, since there would be no associated person row. An alternative is to create a "fake" row in the Person table for an as-yet- unknown person. Taking the OO approach, you could create a subclass of Person called UnknownPerson that would serve this purpose admirably. The object could behave just like a regular person, but the name would be "Unknown" or something like that. When the consulting detective figures out who the person is, the UnknownPerson mutates into a person and carries its aliases with it.
Another problem: What if "Fred Porlock" is a nom de plume for several people, not just one Expressing a strong link between a person and an alias would make this impossible. You would need to enter the alias several times, once for each person you know uses it. A better design solution is to create a many-to-many relationship between Alias and Person with a constraint that there must be at least one row in the relationship for each Alias row. This is an additional business rule that should appear in your use case business rule summary.
Here is the business rule summary:
A person may have several aliases. Several people may use an alias. An alias must refer to at least one person, even if you don't know that person right now.
If you wish, you can express business rules in SQL, OQL, or an equivalent logical language. Unless the logic is critical, it's usually best to leave it in a simply stated natural language format that your audience can easily understand. Leave it to the class model to express the constraints formally.
Summary
Before even starting to develop your use cases, you develop a model of who uses them: actors. Actors provide the context for the system, the "who" that motivates what you're doing. Actors can be either stakeholders or external systems such as databases that you access.
Use cases themselves represent the transactions (logical units of work) that the actors perform. You can break the system down using the «extends» and «uses» relationships to create subatomic use cases that you can share between transactions. Each use case contains a summary, a narrative description, an optional activity diagram, a table of data elements that the use case uses, and a set of business rules that constrain the use case.
The use case is a critically important part of any database development project. A software system, however, like a play, does not consist of scenarios alone. The actors, the props, the stage, the playbook, the audience all play their part in the experience. The next chapter briefly discusses the role of use cases and requirements in testing,
preparing you for the rest of the book, which focuses on design.
Chapter 5: Testing the System
It is commonly said, and more particularly by Lord Shaftesbury, that ridicule is the best test of truth. Wit and Wisdom of Lord Chesterfield, Epigrams
Overview
The quality of a thing reflects the value of the work that goes into it. A well-done steak is, well, a mistake—unless that's what the customer wants. The trick to getting a high-quality database application system is not to load large amounts of data in the wild hope that, by brutalizing the system, you will find out what's wrong with it. Instead, you must compare the end result of your effort to the needs and wants of your customers. In this short chapter, I hope to cover some of the techniques I've learned over the years for testing databases against requirements.
There are two parts to such testing: the database and the requirements. If you are going to hold the database design and development accountable for meeting a set of requirements, you must be reasonably sure that the set is correct and complete. That means that you must verify your requirements in the same way that you verify your design and code. As with all testing, this is not a one-time, do-or-die testing effort that you must complete before moving on to design. You do it over and over as your design and implementation progress, always questioning, always testing the limits of your requirements. You start with presenting the use cases to your clients and getting their feedback on completeness and accuracy of the use cases as statements of their requirements. As your design and
implementation proceed, you find parts of the use cases that need revision, missing use cases, and different ways of thinking about the problem (as opposed to the solution). These changes lead you back to validation through more client interviews and observations, always subject to the need of your project to complete its tasks on schedule within a reasonable budget. Life is a trade-off.
On the other side of the equation, the validation process compares the end result of a project increment against its requirements. System validation testing of the database against its requirements is the critical test your project must pass to deliver a working database application. The section "Systems and Truth" in this chapter shows you how to tie your end result back to requirements through testing.