转贴一篇文章，使用UML朋友别错过：怎么避免Use_…

Whether your system boundaries are blurred or you've tangled your use cases in user-interface screens, you'll soon find that the first time you model it's easy to fall into some fairly predictable problem areas. Luckily for you, it's also easy enough to avoid them.

by Susan Lilly

Use cases are an increasingly popular technique for documenting system and software requirements. With their simple graphical notation and accessible natural-language specifications, use cases are attractive to development teams–even those with little experience in formal requirements specification. This simplicity can be deceptive, however. Although project teams have little trouble getting started with use cases, many of them encounter similar problems in applying them on a larger scale.

While learning from experience may be a powerful thing, it’s an expensive pedagogical technique in the business world. Your project team doesn’t have to experience the 10 most common pitfalls firsthand. I have four recommendations that will help prevent many of the common use-case pitfalls, and one recommendation that will help you detect and remove them.

Where’s the System?

Be explicit about the system boundary. The use-case model has a trivial notation. In its simplest form, it’s just a labeled box that indicates the system boundary, with actors (stick figures) drawn outside of this box and the use cases (labeled ellipses) inside. Lines or arrows connect the actors to the use cases.

The Top 10 Use-Case Pitfalls

1. The system boundary is undefined or inconstant.
2. The use cases are written from the system's (not the actors') point of view.
3. The actor names are inconsistent.
4. There are too many use cases.
5. The actor-to-use case relationships resemble a spider's web.
6. The use-case specifications are too long.
7. The use-case specifications are confusing.
8. The use case doesn't correctly describe functional entitlement.
9. The customer doesn't understand the use cases.
10. The use cases are never finished.

...

From Lilly, S., Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases, Proceedings of TOOLS USA '99, IEEE Computer Society, 1999.

But what is this labeled box that we call the system? Are we talking about a computer system? An application? A subsystem? Or a whole business enterprise? Use cases might legitimately be used to describe any of these system boundaries. However, they should only focus on one at a time. The actors and use cases appropriate at one system boundary are likely to be incorrect for a different system boundary.

Let’s look at an example from a baseball ticket ordering system. A Kiosk Customer uses the computer system to order tickets, or a Phone Customer calls an 800 number for the ticket business and a Phone Clerk (an employee of the ticket business) uses the computer system to order tickets. Who are the actors? In a use-case diagram with a mixed-up system boundary, the modelers try to show both the users of the business and the users of the computer system in the same use-case model. The textual specification of the Order Tickets use case also becomes muddled: The set of interactions between the Phone Customer and the business is different from the set of interactions between the other actors and the computer system.

The undefined or inconsistent system boundary (Pitfall 1) is probably the most universal problem I’ve observed in projects trying use cases for the first time. When the system boundary is confused, it’s hard to know what’s in and what’s out. You can end up with:

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有