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

這個(gè)10種UML常見**錯(cuò)誤列表是由UML領(lǐng)域的絕對(duì)專家Doug Rosenberg總結(jié)出的。 Doug Rosenberg目前在ICONIX軟件工程公司工作，有近20年的設(shè)計(jì)系統(tǒng)開發(fā)工具培訓(xùn)經(jīng)驗(yàn)。他于1993年開發(fā)了一種統(tǒng)一的 Booch/Rumbauge/Jacobson設(shè)計(jì)方法，這比Rational的UML早了許多年。他編寫了十幾種關(guān)于對(duì)象技術(shù)的書。本文是Top 10 UML Errors Lists系列之二：10種最常見用例建模錯(cuò)誤。

* 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.描述用例的使用方法，而不是對(duì)屬性和方法的描述
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.不要把用例寫得過于簡單而丟失細(xì)節(jié)
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.不要使開發(fā)工作背離實(shí)際的用戶交互特性
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.對(duì)邊界對(duì)象的命名務(wù)必明確、清楚
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.用主動(dòng)語態(tài)表達(dá)用戶的觀點(diǎn)
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.不要只描述與用戶的交互而忽略系統(tǒng)作出的響應(yīng)
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.不要忽視對(duì)交替活動(dòng)的過程描述
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.不要關(guān)心諸如“如何到達(dá)這里或以后將發(fā)生什么” 等問題，要關(guān)注用例的內(nèi)部情況
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.不要做花一個(gè)月時(shí)間來決定使用包含結(jié)構(gòu)還是擴(kuò)展結(jié)構(gòu)這樣的傻事
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.