HREF="http://www.aw.com/locations/ordering.html"> Ordering Information, C&P Welcome Page.
Jacobson raised the visibility of the use case (his name for a scenario) to the extent that it became a primary element in project development and planning. Since his book was published (1994), the object community has adopted use cases to a remarkable degree. My practice has certainly improved since I started using use cases in this manner.
So what is a use case?
In essence, a use case is a typical interaction between a user and a computer system. Take the word processor I'm using to write this book. Two typical use cases would be "make some text bold" and "create an index." From just those examples, you can get a sense for a number of properties of use cases.
During elaboration, this is all you need to get started. Don't try to capture all the details right at the start--you can get them when you need them. If you think that a given use case has major architectural ramifications, however, you will need more details up front. Most use cases can be detailed during the given iteration as you build them.
With system interactions, you can say that the use cases would include the likes of "define a style," "change a style," and "move a style from one document to another." However, all these use cases reflect things the user is doing with the system rather than the real goals the user is trying to achieve. The real user goals might be described with terms like "ensure consistent formatting for a document" and "make one document's format the same as another."
This dichotomy between user goal and system interaction is not present in all situations. For example, the process of indexing a document is pretty much the same whether you think of it as a user goal or a system interaction. However, where user goals and system interactions do differ, it is important to be aware of the difference.
Both styles of use cases have their applications. System interaction use cases are better for planning purposes; thinking about user goals is important so that you can consider alternative ways to satisfy the goals. If you rush too quickly toward system interaction, you will miss out on creative ways to satisfy user goals more effectively than you might by using the obvious first choice. In each case it is a good idea to ask yourself, "Why did we do that?" That question usually leads to a better understanding of the user goal.
In my work, I focus on user goals first, and then I come up with use cases to satisfy them. By the end of the elaboration period, I expect to have at least one set of system interaction use cases for each user goal I have identified (at minimum, for the user goals I intend to support in the first delivery).
I'll begin discussion of the elements of this diagram by talking about the actors.
There will probably be many traders in the given organization, but as far as the system is concerned, they all play the same role. A user may also play more than one role. For instance, one senior trader may play the Trading Manager role and also be a regular trader; a Trader may also be a Salesperson. When dealing with actors, it is important to think about roles rather than people or job titles.
Actors carry out use cases. A single actor may perform many use cases; conversely, a use case may have several actors performing it.
In practice, I find that actors are most useful when trying to come up with the use cases. Faced with a big system, it can often be difficult to come up with a list of use cases. It is easier in those situations to arrive at the list of actors first, and then try to work out the use cases for each actor.
Note that actors don't need to be human, even though actors are represented as stick figures within a use case diagram. An actor can also be an external system that needs some information from the current system. In Figure 3-1, we can see the need to update the accounts for the Accounting System.
The subject of interactions with external systems causes a lot of confusion and stylistic variations among users of use case diagrams.
Use cases are all about externally-required functionality. If the Accounting System needs a file, that is a requirement that needs to be satisfied.
Accessing Reuters is important but not a user need. If you follow option 4, you end up analyzing the Accounting System, which is something you would probably rather not get into. That said, you should always question use cases with system actors, find out what the real user goals are, and consider alternative ways of meeting those goals.
When I'm working with actors and use cases, I don't worry too much about what the exact relationships are among them. Most of the time, what I'm really after is the use cases; the actors are just a way to get there. As long as I get all the use cases, I'm not worried about the details of the actors.
One situation in which the actors do live on, however, is in configuring the system for different kinds of users. If your system has use cases that correspond with high-level user functions, you can use the actor/use case links to profile individual users. Each user would have an associated list of actor names, which you would use to determine which use cases that user can perform.
Another good reason to track the actors involves needing to know who wants which use case. This can be important when you are assessing competing needs. Understanding the actors may help you negotiate among competing development demands. They can also be useful in specifying security policy.
Some use cases don't have clear links to specific actors. Consider a utility company. Clearly, one of its use cases is "send out bill." It's not so easy to identify an associated actor, however. No particular user role requests a bill. The bill is sent to the customer, but the customer wouldn't object if it didn't happen. The best guess at an actor here is the Billing Department, in that it gets value from the use case. But Billing is not usually involved in playing out the use case.
Actors can have various roles with regard to a use case. They can be the ones that get value from the use case, or they can just participate in the use case. Depending on how you use the actor relationship, different actor roles will be important to you. I tend to be most concerned with controlling system development. So I'm generally most interested in who wants a given use case to be built--usually those people who get value from the use case.
The key is to remain aware that some use cases will not pop out as a result of the process of thinking about the use cases for each actor. If that happens, don't worry too much. The important thing is understanding the use cases and the user goals they satisfy.
A good source for identifying use cases is external events. Think about all the events from the outside world to which you want to react. A given event may cause a system reaction that does not involve users, or it may cause a reaction primarily from the users. Identifying the events that you need to react to will help you identify the use cases.
You use the extends relationship when you have one use case that is similar to another use case but does a bit more.
In our example, the basic use case is Capture Deal. This is the case in which all goes smoothly. There are things that can upset the smooth capture of a deal, however. One of these things is when some limit is exceeded--for instance, the maximum amount the trading organization has established for a particular customer. Here we don't perform the usual behavior associated with the given use case; we carry out a variation.
We could put this variation within the Capture Deal use case. However, this would clutter that use case with a lot of special logic, which would obscure the "normal" flow.
Another way to address the variation is to put the normal behavior in one use case and the unusual behavior somewhere else. The following is the essence of the extends relationship.
I split at the construction stage of the project if I can't build the whole use case in one iteration. I split a complex use case into a normal case and a few extensions and then build the normal case in one iteration and the extensions as part of one or more later iterations. (This will result in a change of the commitment schedule, of course, and needs to be negotiated with the users.)
The uses relationship occurs when you have a chunk of behavior that is similar across more than one use case and you don't want to keep copying the description of that behavior. For instance, both Analyze Risk and Price Deal require you to value the deal. Describing deal valuation involves a fair chunk of writing, and I hate copy-and-paste operations. So I spun off a separate Value Deal use case for this situation and referred to it from the original use cases.
Note the similarities and differences between extends and uses. Both of them imply factoring out common behavior from several use cases to a single use case that is used, or extended by, several other use cases. However, the intent is different.
The two types of relationships imply different things in their links to actors. In the case of extends, actors have a relationship to the use case that is being extended. It is assumed that a given actor will perform both the base use case and all of the extensions. With a uses relationship, there is often no actor associated with the common use case. Even if there is, that actor is not considered to be performing the other use cases.
As you perform your modeling tasks, you will come up with models that express how to do your use cases, either in software or in people (that is, squishyware). Obviously, there is more than one way to carry out a use case. In UML-speak, we say that a use case can have many realizations.
Often, you may want to sketch out several realizations to discuss before you decide which one to go with. If you do this, always remember to keep notes about discarded realizations, including why you discarded them. I don't want to tell you how many hours I have wasted in discussions that featured the likes of "I know there was a reason why we didn't do that...."
Most of your use cases will be generated during that phase of the project, but you will uncover more as you proceed. Keep an eye out for them at all times. Every use case is a potential requirement, and until you have captured a requirement, you cannot plan to deal with it.
Some people list and discuss the use cases first, then do some modeling. I sometimes do that, but I've also found that conceptual modeling with users helps uncover use cases. I recommend that you try it both ways and see which works best for you.
Different designers make use of use cases with varying degrees of granularity. For example, Ivar Jacobson says that for a 10-person-year project, he would expect about 20 use cases (not counting uses and extends relationships). In a recent project of about the same magnitude, I had more than 100 use cases. I prefer smaller-grained use cases because they make it easier to work with the commitment schedule. However, too many use cases can be overwhelming. I don't think there is one right answer at the moment, so be flexible and work with whatever seems comfortable.