本节向大家介绍一下如何选择一种UML建模工具，选择时有若干标注，这里向大家一一介绍，希望通过本节的介绍你对选择UML建模工具的标准有一定的认识。下面是具体介绍。
选择一种UML建模工具
以下标准用于评估一种UML工具。当然，除了已被列出的以外，可以用这些标准来评估的产品还很多，但如果你想选择最好的，请花时间按照清单对产品作测试。如果你特别重视某项标准而在清单中没有列出，请告诉我们。
信息仓储支持
对于一个大项目，信息仓储(Repository)对在开发人员之间共享组件设计是必要的。两个以上的开发人员可以共享同一模型的的组件，甚至可以通过在适当级别上定义所有权和共享权来合作进行单一组件的开发。信息仓储通常用提供数据共享和并发控制等特性的数据库来实现。通过提供锁定和只读访问，信息仓储允许一个开发人员拥有整个模型而其他人对该模型及其组件只读访问，或者将这些组件结合到自己的设计中。重要的是：这种工具应该允许你从另一个模型只引入你所需要的组件而不必引入整个模型。
构造信息仓储的另一个令人感兴趣的方法是利用项目的源代码，使用源码控制系统来提供并发控制。这种方法的好处是在源码和模型之间有更高级别的同步，另一个好处是更除去了另一个数据源--别忘了，如果你为信息仓储使用了数据库，你必须对各种存储数据分别备份并完成在模型、信息仓储和源代码之间的三方同步，而不止是在代码和模型之间的两方同步。
有了建模工具对信息仓储的支持，对任何组件的修改将被自动传播到所有引入该组件的设计。
双向工程
对源代码(Java,C++,CORBAIDL)的正向和逆向工程的能力是一项复杂的需求，不同厂商在不同程度上成功地支持这一点。对正向和逆向工程这两方面的成功结合，定义为双向工程。
正向工程在第一次从模型产生代码时非常有用，这将为你节省许多用于编写类、属性、方法代码的琐碎工作的时间。
在以前没有模型存在的情况下，将代码转换成模型；或者在迭代结束，重新同步模型和代码时，逆向工程非常有用。
在一个迭代开发周期中，一旦一个模型作为迭代的一部分被修改，另一轮的正向工程应允许所有加入该模型的新的类、方法、属性的代码被更新。这个步骤通常不被开发者采用，因为许多工具在这个过程中没有办法管理源代码，问题在于源代码中不只包含与模型有关的信息。工具必须精于对在新一轮正向工程之前已有的源代码进行重新构造。
至少，UML建模工具应成功支持一开始的正向工程和全过程的逆向工程。同样，建模工具对纯Java语言的逆向工程的支持应该毫无问题。一定要针对你自己的源代码确认这一点，因为我们见到过优秀的工具在对Java的一些特性如内联类(innerclasses)等进行逆向工程时失败了，每一次进行逆向工程时，你不得不把讨厌的代码注释掉----确实非常痛苦。
HTML文档化
对象UML建模工具应能为对象模型及其组件无缝地产生HTML文档。HTML文档提供对象模型的静态视图，以便开发者通过浏览器迅速查询而不需要加载建模工具本身。另外，通过产生HTML文档，所需建模工具的许可证(licenses)会因减去那些对模型只需要有只读权限的人而减少。
HTML文档应包括模型中每个图形的一张位图，并允许通过超链接浏览整个模型。产生HTML文档所需的时间应是合理的。现在许多产品在不同程度上成功支持这一点。再说一遍，你必须亲自测试这个特性，在特征表上有打勾并不能保证成功支持。
完全UML1.3支持
虽然许多工具声称完全支持UML1.3，实际上，这是一项复杂的需求，一些工具并不能做到广告所声称的完全支持。至少应支持的图表有：用例图(UseCasediagrams)，类图(Classdiagrams)，协作图(Collaborationdiagrams)，顺序图(Sequencediagrams)，包图(Packagediagrams)，状态图(Statediagrams)。
类和方法的选择列表
UML建模工具应在一些关键界面上提供选择列表:
协作图(CollaborationDiagrams)和顺序图(SequenceDiagrams)--工具应允许从模型的类列表中选择一个类，把一个对象分配给它，并允许对象间传送的消息能够从接收消息对象(类)的有效方法列表中选取。
类图(ClassDiagram)--工具应允许从别的包或模型的类列表中选择并引入类。
选择列表特性在直观上对建模工具至关重要，可以看作是必备特性。能够迅速从列表中选择一个对象到另一个对象的消息，给开发顺序图和协作图带来很大的方便。
数据建模集成
UML建模工具应允许集成数据建模工具。有许多方法可以提供这种功能。一种方法是UML工具提供将对象模型转换成DDL(数据定义语言，用于为类创建表的SQL)。另一种方法是UML工具输出元数据到能够输入这些元数据的数据建模工具，并将其作为数据模型的基础。一套先进、完整的工具应允许数据模型和对象模型之间在每次设计的迭代之后同步。
版本控制
建模工具应允许储存各种版本，以便后续迭代开始时，以前的版本仍然可以得到，并用于重建或保持基于该版本的已有代码。
模型导航
UML建模工具应提供强的导航支持以允许开发者全盘浏览模型中的所有图表和类。一种方法是提供一个按名字排序的类目录或选择列表，以便设计人员随意跳到图表中想去的类。对于大的图表，工具应使得在缩放和平移时，能够轻松实现浏览。工具也应允许在使用双向工程时，对类的源代码轻松浏览。
打印支持
UML建模工具应允许一张大图表能够准确地用多个页面打印出来，并提供打印预览和缩放功能，轻松地使图表能够在所需页数内放置。允许将一张图表放置在单页中的能力在清单中是高要求。不幸的是，我们发现许多工具很难用无缝的方式完成这项重要的任务。
图表视图
UML建模工具应能方便定制类及其细节的视图。例如，它应有可能从图表中排除所有的get/set方法，因为它们会对阐明一个图表造成混乱。方法的全部信息应允许容易地根据不同级别细节的需要显示或隐藏。属性和方法的可见性(private,protected,public)是用于选择什么该显示，什么该隐藏的另一个尺度。
输出图表
一个经常被忽略的关键特性是用某种格式输出图表，以便引入到文字处理文档或Web页面中。用于输出的最流行图像格式是GIF、PNG和JPEG。输出时，工具应允许你定义所产生图形的首选分辨率和尺寸。这个功能需求来自那些野心勃勃，需要写一本包括图表的UML书籍的作者，或者希望将他们的工作展示在网站上的人。
脚本
用脚本编程是UML建模工具应该支持的另一个强大的特性。有了脚本功能，高级用户可以创建能在建模工具内直接访问对象模型的脚本来添加其它功能，例如：为当前开发的项目做的项目管理表格，定制文档，定制代码，报表和度量。一个定制代码的例子是集合类和用于访问集合类的get/set方法。
为了方便使用脚本，建模工具应公开访问自身对象模型的接口，以便在开发时能提供对对象模型组件的访问。(如果这一句听起来有点绕口，请再读一遍。)例如，脚本编写者应能在整个迭代周期中访问类图中类的集合，从而能够通过类对象的accessor方法来访问类的属性。当然，脚本语言自身应该是面向对象的；一个明显的选择就是Java语言本身，另一种选择就是Python脚本语言。
【编辑推荐】
