Example Use Cases


Let's look at a couple of sample use cases. We start by walking through how a use case named Log In, associated with an Internet bookstore, might have come into existence.

You first establish where the actor is, and what he or she does to initiate the use case. The steps may be as follows :

  1. The Customer clicks the Login button on the Home Page.

  2. The use case describes the system's response:

     The system displays the Login Page. 

    The rest of the basic course of action for this use case describes the actions that the actor performs in order to log in to the bookstore, and the actions that the system performs along the way as well:

  3. The Customer enters his or her user ID and password and then clicks the OK button. The system validates the login information against the persistent Account data and then returns the Customer to the Home Page.

Remember that the Account class you defined in Chapter 1 (see Figure 1-3) contains three attributes, two of which are ID and password . As mentioned in the previous section, it's good practice to make explicit connections to domain model classes within use case text; you can certainly extend this principle to the attribute level as appropriate.

As you can see, the basic course addresses the sunny-day scenario: It assumes that nothing will go wrong. However, a good use case accounts for as many alternate paths and error conditions as possible. In this case, there are two kinds of alternate courses that we need to address. These are as follows:

  • The Customer can perform some other action before logging in. This leads to the following alternate courses:

    If the Customer clicks the New Account button, the system displays the Create New Account page.

    If the Customer enters his or her user ID and then clicks the Reminder Word button, the system displays a dialog box containing the reminder word stored for that Customer. When the Customer clicks the OK button, the system returns the Customer to the Home Page.

  • The system is unable to validate a value that the Customer provided and thus is unable to complete the login process. The following courses of action are possible:

    If the Customer enters a user ID that the system does not recognize, the system displays the Create New Account page.

    If the Customer enters an incorrect password, the system prompts the Customer to reenter his or her password.

    If the Customer enters an incorrect password three times, the system displays a page telling the Customer that he or she should contact customer service.

Note how the reader of a use case can see where each alternate course branches out from the basic course.

Another key principle is that a use case has to end with the system providing some result of value to an actor. The basic course of Log In reflects that the Customer is logged in to the system at the end of the use case. The alternate courses also reflect that result, albeit in somewhat different ways. In two cases, the Customer ends up back at the Home Page, and the assumption is that he or she will proceed with the basic course of action. In another case, the system takes the Customer to a different page; this may not be a desirable option from his or her standpoint, but it's still a result of value. And in two cases, the system displays a new page that the Customer can use to create a new account. (Let's assume that some use case diagram for our bookstore will show that Log In has a connection with a Create New Account use case.)

Our second, more complicated use case is called Write Customer Review. It illustrates more basic principles discussed previously: active voice from the actor's perspective, present tense, a result of value, no more than three paragraphs, and alternate courses of action that reflect different paths.

  • Basic Course

  • The Customer clicks the Review This Book button on the Book Page. The system displays a page entitled Write a Review.

  • The Customer selects a rating for the given Book, types a title for his or her review, and then types the review itself. Then the Customer indicates whether the system should display his or her name or email address, or both, in connection with the review.

  • When the Customer has finished selecting and entering information, he or she clicks the Preview My Review button. The system displays a Look Over Your Review page that contains the information that the Customer provided. The Customer clicks the Save button. The system stores the information associated with the Review and returns the Customer to the Book Page.

  • Alternate Courses

  • If the Customer clicks the Review Guidelines button on the Book Page, the system displays the Customer Review Guidelines page. When the Customer clicks the OK button on that page, the system returns the Customer to the Book Page.

  • If the Customer clicks the Edit button on the Look Over My Review page, the system allows the Customer to make changes to any of the information that he or she provided on the Write a Review page. When the Customer clicks the Save button, the system stores the review information and returns the Customer to the Book Page.




Fast Track Uml 2.0
Fast Track UML 2.0
ISBN: 1590593200
EAN: 2147483647
Year: 2004
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net