Use case driven" means writing the user manual first, then writing the code

Use case driven" means writing the user manual first, then writing the code. This practice reinforces the fundamental notion that a system must conform to the needs of the users, instead of your users conforming to the system.

by Doug Rosenberg and Kendall Scott

這個10種UML常見**錯誤列表是由UML領域的絕對專家Doug Rosenberg總結出的。 Doug Rosenberg目前在ICONIX軟體工程公司工作，有近20年的設計系統開發工具培訓經驗。他於1993年開發了一種統一的 Booch/Rumbauge/Jacobson設計方法，這比Rational的UML早了許多年。他編寫了十幾種關於物件技術的書。本文是Top 10 UML Errors Lists系列之二：10種最常見用例建模錯誤。

* 10.不要將用例場景文字寫成功能需求
10. Don't write functional requirements instead of usage scenario text.
Requirements are generally stated in terms of what the system shall do, while usage scenarios describe actions that the users take and the responses that the system generates. Eventually, our use case text will be used as a run-time behavioral specification for the scenario we'll describe, and this text will sit on the left margin of a sequence diagram. We want to be able to easily see how the system (shown with objects and messages) implements the desired behavior, as described in the use case text. So, we need to clearly distinguish between usage descriptions(behavior) and system requirements.

* 9.描述用例的使用方法，而不是對屬性和方法的描述
9. Don't describe attributes and methods rather than usage.
Your use case text shouldn't include too many presentation details, but it should also be relatively free of details about the fields on your screens. Field names often match the names of attributes on your domain classes, which we discussed in January's article.Methods shouldn't be named or described in use case text because they represent how the system will do things, as opposed to what the system will do.

* 8.不要把用例寫得過於簡單而丟失細節
8. Don't write the use cases too tersely.
When it comes to writing text for use cases, expansive is preferable.You need to address all of the details of user actions and system responses as you move into robustness analysis and interaction modeling, so you might as well put some of those details in your use cases.Remember also that your use cases will serve as the foundation for your user manual. It's better to err on the side of too much detail when it comes to user documentation.

* 7.不要使開發工作背離實際的使用者互動特性
7. Don't divorce yourself completely from the user interface.
One of the fundamental notions of "use case driven" is that the development team conforms the design of the system to the viewpoints of the users. You can't do this without being specific as to what actions the users will perform on your screens. As we mentioned for item number nine, you don't need to talk about fields in your use case text, and you don't want to discuss the cosmetic appearance of your screens; however, you can let your rototypes, in whatever form they take, do that work for you. You do need to discuss those features of the user interface that allow the user to tell the system to do something.

* 6.對邊界物件的命名務必明確、清楚
6. Don't avoid explicit names for your boundary objects.
Boundary objects are the objects with which actors will interact. These frequently include windows, screens, dialogs and menus. In keeping with our theme of including ample detail and being explicit about user navigation, we submit that it's necessary to name your boundary objects explicitly in your use case text. It's also important to do this because you will explore the behavior of these objects during robustness analysis (the subject of the next article in this series), and it can only reduce ambiguity and confusion to name them early.

* 5.用主動語態表達使用者的觀點
5. Don't write in the passive voice, using a perspective other than the user's.
A use case is most effectively written from the user's perspective as a set of present-tense verb phrases in active voice. The tendency of engineers to use passive voice is well-established, but use cases should state the actions that the user performs, and the system's responses to those actions. This kind of text is only effective when it's expressed in the active voice.

* 4.不要只描述與使用者的互動而忽略系統作出的響應
4. Don't describe only user interactions; ignore system responses.
The narrative of a use case should be event- response oriented, as in, "The system does this when the user does that." The use case should capture a good deal of what happens "under the covers" in response to what the actor is doing, whether the system creates new objects, validates user input, generates error messages or whatever. Remember that your use case text describes both sides of the dialog between the user and the system.

* 3.不要忽視對交替活動的過程描述
3. Don't omit text for alternative courses of action. Basic courses of action are generally easier to identify and write text for.
That doesn't mean, however, that you should put off dealing with alternative courses until, say,detailed design. Far from it. In fact, it's been our experience that when important alternative courses of action are not uncovered until coding and debugging, the programmer responsible for writing or fixing the code tends to treat them in ways that are most convenient for him. Needless to say, this isn't healthy for a project.

* 2.不要關心諸如“如何到達這裡或以後將發生什麼” 等問題，要關注用例的內部情況
2. Don't focus on something other than what is "inside" a use case, such as how you get there or what happens afterward.
Several prominent authors, such as Alistair Cockburn and Larry Constantine, advocate the use of long, complicated use case templates. Spaces for preconditions and post-conditions are generally present on these templates. We like to think of this as the 1040 "long form" approach to use case modeling, in comparison to the 1040EZ-like template that we advocate (two headings: Basic Course and Alternate Course). You shouldn't insist on using long and complex use case templates just because they appeared in a book or article.

* 1.不要做花一個月時間來決定使用包含結構還是擴充套件結構這樣的傻事
1. Don't spend a month deciding whether to use includes or extends.
In our years of teaching use case driven development, we've yet to find a situation where we've needed more than one mechanism for factoring out commonality. Whether you use UML's include construct, or OML's invoke and precede mechanisms, or something else that you're comfortable with, doesn't matter; simply pick one way of doing things and stick with it. Having two similar constructs is worse than having only one. It's just too easy to get confused—and bogged down—when you try to use both. Don't spin your wheels.




Source: Applying Use Case Driven Object Modeling with UML
by Doug Rosenberg and Kendall Scott, Boston: Addison–Wesley, 2001.

[@more@]