为了成功使用UML，在使用的过程中必须流程化。因此本文介绍了实施UML时的九项注意点，通过这些使UML符号更好的满足不同项目的需求。
1997年的最后一个季度，我在教一些来自不同项目的开发者使用UML作面向对象分析与实际。这些项目涉及许多应用领域包括零售货架空间管理，临床药物实验，移动电话等。开发语言包括Visual Basic, C++, Java, DB2还有其他。通过我们公司的用例驱动统一对象建模过程（是建立在Booch, Jacobson, and Rumbaugh方法的基础之上的）来从几个方面介绍UML符号如何更好得满足不同项目的需求。为如何使用UML提供了实际的指导。
UML的符号比较多（可能太多）而且足够灵活能适应大范围项目的需求。为了成功使用UML，在使用的过程中必须流程化。不同的项目需要不同的内容。项目中使用UML符号的哪些具体元素取决于项目的本质（使用关系数据库客户端/服务器端或实时嵌入式）及要使用的开发语言。使用JAVA或Smalltalk时一些详细的C++设计组件将不会被使用；如果使用VB，你可能想避免使用更多的泛化和继承。有时，纯粹的建模组件可能太庞大了，尤其对那些刚开始接触面向对象分析和设计的学生来说。但是，好消息是几乎任何事情都可以使用UML来建模来实现。有很多建模组件可供使用。
You Still Need a Process过程仍然需要
UML本身仅仅是一种符号，为了创建有效的模型，仍然需要一个建模过程。使用UML有很多种建模方法；建模语言本身并不描述过程。在UML产生的几年前，我们一直把作了微小变化的Objectory过程（从Ivar Jacobson的 《面向对象软件工程：一个用例驱动方法》而来，Addison-Wesley, 1992）作为Booch/Rumbaugh/Jacobson的综合来授课，并取得了成功。我们的方法将重点放在了区分更高层次的静态模型（域模型），同时也产生用例。然后我们精炼出静态模型，在开发用例和动态模型时反复精练。
或者你更倾向于使用Objectory，对象模型方法，我们的ICONIX统一对象模型过程，或其他一些方法。在从事建模工作之前，理解UML不是一个过程是重要的。让项目组处于同一个开发阶段尤其重要。让项目组对UML有统一的理解使建模成功的保证。UML的规模（文档符号的庞大相对于过程而言）很容易陷入“分析麻痹”。关注项目组通过UML符号对过程的统一理解，能让建模更容易。
Legacy Methods Are Important 过去的方法依然重要
我的大部分学生会问我理解Booch, Jacobson, and Rumbaugh过去的方法是否仍然很重要。我的答案是非常重要。就像知道电流设计并没有排除知道电路理论一样，虽然UML符号而不排除理解对象建模理论的必要性。自从UML代表了Jacobson, Booch, and Rumbaugh三人方法的综合，但早期的方法是信息的来源。
Keep It Simple保持简单
让一个项目组有效的使用UML是有难度的。项目组成员对于面向对象分析和设计以及UML的理解层次各自不同。开始之前统一培训是不错的方法，培训需要认真考虑项目组每个成员的背景及项目的特殊要求。最重要的决定在于课程表的明智选择和指导老师在工作期间的调整。
在学习UML中需要记住的一点是我们并不需要使用每一个存在的组件。让过程尽量简单化。流程化一个项目的文档和建模方法对项目的进行有非凡的作用。
用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模板
整个设计过程从用例中分离出来，表明注重描述它们是“正确“的方法。同时在需求分析和业务过程建模中用例作为一种备选方案正越来越受到欢迎。不同形式的用例建模有一些不同的向导，我遇到的大部分项目仍把用例作为得到对象模型的方法。[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
