Banda sonora de Blade Runner

The use case narrative is a series of text descriptions of the detailed steps in the use case. This usually takes the form of a numbered list of steps that alternate between the actor(s) and the system. The "system," in this case, is the software that implements the use case.

There really aren't many rules for constructing these narratives. The primary objective is to be as clear as possible. As you write, think about the audience for the use case, and shape the text to their level of understanding of the events. If you find it difficult to describe what goes on in the use case in language comprehensible to your audience, you might want to back off and redo the use cases in your system to reflect better what needs to happen. Keep it simple.

Also, you should stay away from describing specific user interface or system details, keeping the narrative as

abstract as possible. This technique (essential use case analysis) pushes the user interface decisions into the design stage, leaving the requirements to deal only with the generic behavior of the application. This delayed commitment to an interface can save you a good deal of stress and bother when you start designing your user interface. On the other hand, sometimes you really do have user interface requirements because of early architectural decisions or even because of explicit client expectations. For example, if a high-up manager at Holmes PLC hands you a copy of a case history report and tells you they want it to look exactly like that with such-and-such changes, you should put the specific interface requirements into your use case. You should always probe a bit under these circumstances to make sure the client really wants that format. Propose some alternatives and listen carefully to the response. For example, I once was required to develop a report in a specific format. The format allowed the client to print the report onto a half-page form already printed by the company. After questioning, it turned out that we could dispense with the printed forms if the report writer could produce printouts of comparable quality, which it could. On the other hand, the basic format needed to stay the same; the people using the form had used it for years and didn't want to have to learn a whole new layout.

In the end, if the client really wants a specific screen control or report format, you should make that a formal part of the requirements.

If the use case makes explicit reference to the database, you can express the step using the database access language. For an SQL database, that means an SQL statement. For an OO database, it might mean C++ code or OQL statements. You should keep your SQL or OQL as generic as possible, using only ANSI/ODMG standard language for the same reason that you avoid specific user interface controls or formats. Each statement should form a complete step in the narrative and in the activity diagram of the use case.

The use of SQL or OQL at this stage of development implies that you have a schema. As you iterate through creation of use cases, you will determine the classes of persistent objects the use cases require. Chapter 7

discusses the UML static structure diagrams (diagrams of classes, objects, and associations) that represent these objects. You should develop these diagrams in parallel, or at least iteratively, while you develop your use cases. This approach gives you a basic schema, with object or table names and attribute or column names that you can use in your SQL and OQL use case steps.

Using SQL or OQL in your use cases also gives you a clear picture of how your system will access the database. You can use such use cases during a design phase to understand more clearly how the system uses the database in terms of transaction processing and performance.

Your narrative should refer to «uses» relationships directly in the steps that use the shared behavior. However, you should not refer to «extends» relationships at all in your narrative. The whole point of the «extends» relationship is to remove the extension from the main use case to simplify it. Putting it back into the narrative would therefore be counterproductive. Usually, you add a section at the end entitled "Extensions" that contains a list of the extensions. In each element of this list, you detail the conditions under which the extension extends the use case and refer to the

extension by name. You should identify the point in the narrative where the extension condition appears, but that's all. The reader can then look up the extension use case to see its details if needed.

This narrative describes the Identify Criminal with Alias use case, in this case using the RDBMS/ORDBMS SQL approach:

1. The Identify Criminal with Alias use case begins with the Consulting Private Detective asking the System to identify a criminal by entering an alias, a character string.

2. The System looks up the criminal, returning the identity of the criminal (PersonID, Name), using this SQL statement:

3. SELECT PersonID, Name 4. FROM Person p, Alias a

5. WHERE p.PersonID 5 a.PersonID AND 6. Alias 5 :Alias

7. The System uses the Identify Criminal use case to display information relating to the criminal's identity. This ends the transaction.

The first step in this narrative tells you where the use case begins. For use cases relating to actors, this usually means identifying the actor and what the actor communicates to the system. Communications are either control ("asking the system to identify a criminal") or data ("by entering an alias, a character string"). You can regard the data as parameters to the use case. This step starts the transaction.

The second step in this narrative tells you what the system does in response to the user's request. In this case, it uses an SQL statement to describe the input (Alias, a "host variable"), the processing (a join of the Person and Alias tables on PersonID and a selection based on an equality comparison to the alias string), and the output (a projection of PersonID and Name).

The third step identifies a «uses» relationship. This kind of narrative step identifies the other use case by name. It can also identify any special issues regarding the relationship. For example, you can intermingle the steps in the other use case with steps in this one. I generally have found this is counterintuitive, so I avoid this kind of

relationship. This step also explicitly ends the transaction. You should try to end a transaction explicitly in only one place, the last step of the use case. Many use case designers will find that overconstraining because they want to leave the use case based on some conditional determination earlier in the sequence. It does clarify the logic of the use case a good deal to structure the logic with a single ending point.

Note

You do not mention «extends» relationships in this part of the narrative. The whole point of this kind of relationship is to get the other use case and the conditional logic involved out of the use case proper.

In the second step, you could have used extended ORDBMS SQL or OQL to specify the query. For example, using an ODBMS, you could have a Boolean method on the Person object that returns true if the person has an alias that matches the input alias string. The method could use some kind of complex pattern-matching algorithm. Your OQL might look like this:

SELECT p.PersonID, p.Name FROM Person p

WHERE p.matchesAlias(:Alias)

It's a good idea to keep the steps to a single SQL statement. This keeps the purpose of the step clear and the narrative easy to understand. The exception is when you have nested SQL statements in some kind of iteration, where you are doing the SQL inside the loop for each row from the outer SQL.

You might also think about identification and realize that it is both a fuzzy process and one that can result in ambiguity. In database terms, with this specification, you can't guarantee that you will return only a single row or object from this query. The step should read, "The System looks up the set of criminals that match the input alias, returning the identity of the criminals (PersonID, Name), using this OQL statement."

For the Identify Criminal use case, you have two choices for the first step. If the use case can stand on its own (usually a good idea), then you begin the use case just as for the previous one:

1. The Identify Criminal use case begins with the Consulting Private Detective asking the System to identify a criminal by entering a person identifier (a unique integer for the person).

If the use case always extends another, and thus never interacts with an external actor, you need to state that in the first step.

1. The Identify Criminal use case begins with another use case using it, passing it a unique person identifier (a unique integer for the person). This requests the System to display aliases, criminal history, and identification information for the criminal.

You should also state this in the use case summary.

The last part of the narrative is a section on extensions. In this section, you identify all the «extends» relationships for the use case and the conditions under which they occur. For example, it is possible that the alias you pass to Identify Criminal with Alias results in no criminal identifications. You can add an extension use case, No Criminal Identified, that displays an error message. In the extensions section, you add this paragraph:

1. The No Criminal Identified use case extends the Identify Criminal with Alias use case when the query in step 2 fails to return any rows or objects.

If your use case has conditional logic, often you can best express it through substeps. For example, the Identify Criminal use case step 5 conditionally displays information about the role of the person in a criminal organization:

5. Display the role of the person in criminal organizations. Query the set of roles that the criminal plays with this SQL statement:

6. SELECT p.Name, o.OrganizationID, o.OrganizationName,rt.ShortTyp 7. FROM Person p, Role r, RoleType rt, CriminalOrganization o 8. WHERE p.PersonID 5 r.PersonID AND

9. r.RoleTypeID 5 rt.RoleTypeID AND 10. r.OrganizationID 5 o.OrganizationID AND 11. p.PersonID 5 :PersonID

a. If there are no roles for this person, display the text "<Name> has no known association with any criminal organization."

b. If there are roles, for each role display the role's short type and the organization's name in this text: "<p.Name> plays the <ShortType> role in the <OrganizationName> criminal organization."

You can refer to these steps as "step 5a" and "step 5b" in other parts of your narrative and in an activity diagram. You show loops in the same way, as multiple steps within a larger step.

The use case is usually part of a larger system of models that include the class model and the interaction diagram. Depending on the level of detail you want at the requirements level, you can abstract the "things" in your use case narrative into a class model. You can connect the use case to it through interaction diagrams [Jacobson et al. 1992].

Chapter 7 goes into detail on using static structure models for database design. The section "Data Elements and Business Rules Summary" in this chapter suggests some ways to connect database elements with these other diagrams as well. As with other parts of the OO development process, you revise all these models incrementally and iteratively. As you design your class model, you will learn things about your use cases: what elements are missing, what things you could reorganize to take advantage of synergy between classes, and so on. You then can return to your use cases to make them better requirements models. You'll find a similar benefit in formalizing the narrative through UML activity diagrams.