Section 5.6. Use Cases

   

5.6 Use Cases

Once you have defined what objects should be in your system, you need to describe how the user will interact with the system. This is most commonly done with use cases.

5.6.1 What Are Use Cases?

A use case is a high-level description of a discrete user interaction with an aspect of a software system. Collecting a complete set of use cases should describe your system entirely.

Use cases drive the analysis, design, implementation, and testing phases:

  • In the analysis stage, use cases help ensure that you are representing the system correctly to your customer.

  • In the design stage, use cases help you see your project completely. This means you can refine, refactor, and reduce your project's operative agents .

  • In the implementation stage, use cases help you to concentrate on the code you're writing so that you don't write anything you don't need to, and so you do write all of the code sufficient to cover every user-based eventuality that your system could generate.

  • In the testing stage, use cases help to measure that you have written to spec, and they speed up the time required to test. Because the system must make the use cases possible, it is very easy for QA to test if they work ”the tests are built into the system.

Use cases support you at every step of the way on a project. They are a cornerstone of good OOAD.

In order to really start writing use cases, there is another term we should understand: the actor. An actor is either a real person or another system that interacts with the system being designed. This could be a Web service, a user in a role (such as a secretary logged in as content updater or a manager logged in as administrator), another program, or an intelligent agent. The (ever-evaporating) distinction between people and machines is totally useless to a use case. Something that interacts with your system just needs a description of what that interaction is, what the outcome is supposed to be, and what happens if all does not go as planned.

It is sort of easy to generate use cases once you understand them, so we won't belabor it. Consider our WWWBooks case study. What are some of the things a user will need to do with that system?

  • A user can login to the system and is assigned a role for that session.

  • A user in the employee role enters a new order.

  • A user in the manager role requests a graph indicating bookseller performance for the month.

  • And so on.

Note that the customer never directly acts with the system. This would be modified, of course, if implemented on the Web. Writing out all of your use cases tends to force you to answer questions that you might otherwise wait until later (or never) to deal with. Later in this chapter you will see how to create a use-case diagram.


   
Top


Java for ColdFusion Developers
Java for ColdFusion Developers
ISBN: 0130461806
EAN: 2147483647
Year: 2005
Pages: 206
Authors: Eben Hewitt

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