Section 5.9. User Scenarios and Use-Case Diagrams
5.9 User Scenarios and Use-Case Diagrams
A user scenario is a step-by-step description of a discrete user interaction with your system. It is a sequence written out as a simple paragraph. You can have different scenarios of varying degrees of generality to cover everything in your system. For instance, our WWWBooks online store example would probably have a user scenario for Check Out. The Check Out scenario would look something like this:
Customer views items in the catalog. Customer adds items to shopping cart. When the customer clicks Check Out, forms are presented for entering billing information and shipping information. The system sends the credit card information to the authorization server. The customer is notified of his or her order number on screen and advised of the shipment tracking section of the site .
User scenarios are useful in the project discovery stage, and they help you derive your use cases.
A use case is a description of a set of scenarios, all with a common goal. There is not really a standard specification in UML for describing use cases. For this reason, one sees a good number of slightly varying descriptions. Some will include, for instance, the preconditions for a use case (the preconditions are the things that need to be true before the use case can take place, such as "customer has more than one item in shopping cart" or "user is logged on in the SU role"). There also cannot really be hard and fast rules about what the limit of a use case is; that is, how much ground it covers. There are practical limits to be sure.
Use cases and use-case diagrams were introduced by Jacobson in 1994. It is important to remember that the use case and the use-case diagram are separate entities. You do not need to draw the diagram to get the benefit of the use case. Either way, use cases involve actors in some kind of relation to the system, interacting with some aspect of the system.
5.9.1 Actors
Actors perform use cases. An actor can be thought of as a user in a role that performs an interaction. The actor can be a person or another system. Actors in our WWWBooks case study would include Customer, Manager, and Bookseller.
The number or variance of individuals within a role does not matter to the system. It makes no difference to Java if it is Fred or Murray purchasing something at the store. They are both users, yes, but they are in the same role ”Customer ”and customers all act exactly the same with respect to the system. Actors may play more than one role. It can be difficult, but you must try to think of users as always being in a role, instead of as being individuals.
Actors are the key to good software design. Determining the roles that will interact with your system is the foundation of writing solid systems. Everything is about the user. Before you start writing use cases, determine who your actors are and what they need. The use cases should fall out of this. Determine your actors' goals, and figure out different ways of fulfilling those goals.
Now, on the other hand, use cases will not necessarily result from an actor determination. Often actors represent the user role that requests a particular service from a system. The identity of the appropriate actor is not always entirely clear. That's okay. Try to think of who derives benefit from the use case. This can be another way of thinking of appropriate actors.
Actors are represented in a diagram as human stick figures, though they are not always. A likely example of a non-human actor is an intelligent agent or Web service.
There are discussions in the OOAD community about how detailed to get in a user scenario or use case. Some argue that more detail helps you see problems early on and optimize your design. Others say that you can get bogged down in the details writing use cases all day and that this will impede and confuse the work. A good general rule is that you can vary the degree of detail as appropriate. If a use case is fairly complex, you might break it up into two or more use cases. If the use case involves a good deal of risk, you'll probably want to specify things in greater detail. Anyway, I suggest keeping things relatively simple for a while.
5.9.2 When to Use Use Cases
Use use cases every time you design a new system. Every time you revise or add a significant section to an existing system. All the time.
Use cases force you to focus on the user of the system (see Figure 5.2). They help keep you from running down tempting programmatic paths that don't do anything to help the system or the user.
Figure 5.2. Use-case outline.
When you start designing your system, write it out in user scenarios. Name the different interactions. Use cases are generally the second thing you create when designing your system, after user scenarios. Writing the class diagrams is somewhat of an iterative process that in theory might be the first thing you do, but in practice I've found it occurs in tandem with the creation of use cases.
| |
| Top |
EAN: 2147483647
Pages: 206