Usecasedriven"meanswritingtheusermanualfirst,thenwritingthecode

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.