用UML建模和有时和座在一大堆事物面前很相似，开始吃之前就有不能吃完盘子里面的所有食物的想法可能毁了你的食欲。同样的现象可能发生在UML建模过程中。用完全详细的动态模型描述系统的每一个用例，而不得不创建一系列完整的时序图、协作图、状态图、部署图，用例和类图的想法可能会让一个团队完全脱离面向对象分析和设计。
在一个给定的建模方法中决定使用哪一个组件简单同样是要考虑的。举例来说，在一个用例图上同时使用USES 和EXTENDS真的有必要吗？或者我们只需要使用USES？我的经验是流程化的东西越多，建模成功的可能性越大。
Write the User Manual Before You Design the Classes设计类之前写使用手册
写程序的一条老的规矩是在写代码之前写使用手册。在我学习的时候我认为这是一条好的建议，并且到今天为止我仍然认为是好的建议。在面向过程的年代和面向对象方法的早期，这条规矩很少被遵从。在用例驱动建模方法中，Jacobson把这个规律编写成一系列的步骤，通过这些步骤可以为对象服务并且能用UML描述。每一个步骤建立在上一个步骤的基础之上，形成一个可以跟踪的方法，直道最后，管理能加强这个方法把它作为一个设计范例并且确认在分析和设计的过程中能被遵守。
基础层次的人理解Objectory和用例驱动对象建模的本质的简单方法是：在设计类之前写使用手册。大脑里一直有这个想法将会帮助你在UML的迷宫里穿越静态和动态的建模符号。每一个用例代表着用户手册的一部分，并且应该按着“用例分析的目的是产生对象模型”的方式写。
Organize Use Cases into Packages用例打包
一旦你准备为你的系统的每一个用例书写使用手册的时候，你将很快会意识到需要更高层次的把用例组装起来。UML允许你把用例打包。这些可以用文件标签代表。每一个包至少应该包括一个用例图，这个图可以作为一个上下文图，它可能把设计阶段每个用例的动态视图和用例描述联系起来。有一些项目从高层次的包分割开始。这些分割并不总是代表最终的分割，有时是很好的开始起点。
Use the Objectory Stereotypes使用Objectory模板
整个设计过程从用例中分离出来，表明注重描述它们是“正确“的方法。同时在需求分析和业务过程建模中用例作为一种备选方案正越来越受到欢迎。不同形式的用例建模有一些不同的向导，我遇到的大部分项目仍把用例作为得到对象模型的方法。
Jacobson的早期的OOSE/Objectory包括这样一个我们称之为健壮性分析的阶段。在健壮性分析中，用例描述被解释为粗略地分割一系列协作对象。在分析的过程中，Jacobson提出将对象进行分类，把它们分为接口对象，控制对象，和实体对象。
这个小又快的建模步骤产生令人惊讶的收益。它帮助人们写出正确的用例，较早地确认客户端/服务器端和MVC设计信息，很可能最重要的是快速的浏览所有用例能确认可重用的对象。同时也填补了需求分析和详细设计之间的空白。
不幸的是，由于某些原因，健壮性分析的一些符号（三个容易画的符号），在转变的过程中只有部分保留在UML中。符号仍然存在，但被分离到一个称为对象过程扩展的文档当中，并且工具支持也缺少。我把健壮性分析作为一个整体部分描述用例（图变成了文本的完全检查）时，发现学生已经很快适应了这个对象。
文章来源于领测软件测试网 https://www.ltesting.net/
