模板
教程
环境
性能
功能
管理
选择一种UML建模工具
选择一种UML建模工具
| 信息仓储支持 | 双向工程 |
| HTML文档化 | 完全UML1.3支持 |
| 选择列表 | 数据建模 |
| 版本控制 | 模型导航 |
| 打印支持 | 图表视图 |
| 图表输出 | 脚本 |
| 健壮性 | 平台 |
| 升级 | 未来... |
以下标准用于评估一种UML工具。当然，除了已被列出的以外，可以用这些标准来评估的产品还很多，但如果你想选择最好的，请花时间按照清单对产品作测试。如果你特别重视某项标准而在清单中没有列出， uml-tools@objectsbydesign.com">请告诉我们。
对于一个大项目，信息仓储(Repository)对在开发人员之间共享组件设计是必要的。两个以上的开发人员可以共享同一模型的的组件，甚至可以通过在适当级别上定义所有权和共享权来合作进行单一组件的开发。 信息仓储通常用提供数据共享和并发控制等特性的数据库来实现。 通过提供锁定和只读访问，信息仓储允许一个开发人员拥有整个模型而其他人对该模型及其组件只读访问，或者将这些组件结合到自己的设计中。重要的是： 这种工具应该允许你从另一个模型只引入你所需要的组件而不必引入整个模型。 构造信息仓储的另一个令人感兴趣的方法是利用项目的源代码，使用源码控制系统来提供并发控制。这种方法的好处是在源码和模型之间有更高级别的同步，另一个好处是更除去了另一个数据源--别忘了，如果你为信息仓储使用了数据库，你必须对各种存储数据分别备份并完成在模型、信息仓储和源代码之间的三方同步，而不止是在代码和模型之间的两方同步。 有了建模工具对信息仓储的支持，对任何组件的修改将被自动传播到所有引入该组件的设计。
对源代码(Java, C++, CORBA IDL)的正向和逆向工程的能力是一项复杂的需求，不同厂商在不同程度上成功地支持这一点。对正向和逆向工程这两方面的成功结合，定义为双向工程。 正向工程在第一次从模型产生代码时非常有用，这将为你节省许多用于编写类、属性、方法代码的琐碎工作的时间。 在以前没有模型存在的情况下，将代码转换成模型；或者在迭代结束，重新同步模型和代码时，逆向工程非常有用。 在一个迭代开发周期中，一旦一个模型作为迭代的一部分被修改，另一轮的正向工程应允许所有加入该模型的新的类、方法、属性的代码被更新。这个步骤通常不被开发者采用，因为许多工具在这个过程中没有办法管理源代码，问题在于源代码中不只包含与模型有关的信息。工具必须精于对在新一轮正向工程之前已有的源代码进行重新构造。 至少，建模工具应成功支持一开始的正向工程和全过程的逆向工程。同样，建模工具对纯Java语言的逆向工程的支持应该毫无问题。一定要针对你自己的源代码确认这一点，因为我们见到过优秀的工具在对Java的一些特性如内联类(inner classes)等进行逆向工程时失败了，每一次进行逆向工程时，你不得不把讨厌的代码注释掉----确实非常痛苦。
对象建模工具应能为对象模型及其组件无缝地产生HTML文档。HTML文档提供对象模型的静态视图，以便开发者通过浏览器迅速查询而不需要加载建模工具本身。另外，通过产生HTML文档，所需建模工具的许可证(licenses)会因减去那些对模型只需要有只读权限的人而减少。 HTML文档应包括模型中每个图形的一张位图，并允许通过超链接浏览整个模型。产生HTML文档所需的时间应是合理的。现在许多产品在不同程度上成功支持这一点。再说一遍，你必须亲自测试这个特性，在特征表上有打勾并不能保证成功支持。
虽然许多工具声称完全支持UML1.3，实际上，这是一项复杂的需求，一些工具并不能做到广告所声称的完全支持。至少应支持的图表有：用例图(Use Case diagrams)，类图(Class diagrams)，协作图(Collaboration diagrams)，顺序图(Sequence diagrams)，包图(Package diagrams)，状态图(State diagrams)。
建模工具应在一些关键界面上提供选择列表: 协作图(Collaboration Diagrams)和顺序图(Sequence Diagrams) --工具应允许从模型的类列表中选择一个类，把一个对象分配给它，并允许对象间传送的消息能够从接收消息对象(类)的有效方法列表中选取。 类图(Class Diagram) --工具应允许从别的包或模型的类列表中选择并引入类 。 选择列表特性在直观上对建模工具至关重要，可以看作是必备特性。能够迅速从列表中选择一个对象到另一个对象的消息，给开发顺序图和协作图带来很大的方便。
对象建模工具应允许集成数据建模工具。有许多方法可以提供这种功能。一种方法是UML工具提供将对象模型转换成DDL(数据定义语言，用于为类创建表的SQL)。另一种方法是UML工具输出元数据到能够输入这些元数据的数据建模工具，并将其作为数据模型的基础。一套先进、完整的工具应允许数据模型和对象模型之间在每次设计的迭代之后同步。
建模工具应允许储存各种版本，以便后续迭代开始时，以前的版本仍然可以得到，并用于重建或保持基于该版本的已有代码。
建模工具应提供强的导航支持以允许开发者全盘浏览模型中的所有图表和类。一种方法是提供一个按名字排序的类目录或选择列表，以便设计人员随意跳到图表中想去的类。 对于大的图表，工具应使得在缩放和平移时，能够轻松实现浏览。 工具也应允许在使用双向工程时，对类的源代码轻松浏览。
建模工具应允许一张大图表能够准确地用多个页面打印出来，并提供打印预览和缩放功能，轻松地使图表能够在所需页数内放置。允许将一张图表放置在单页中的能力在清单中是高要求。不幸的是，我们发现许多工具很难用无缝的方式完成这项重要的任务。
建模工具应能方便定制类及其细节的视图。例如，它应有可能从图表中排除所有的get/set方法，因为它们会对阐明一个图表造成混乱。方法的全部信息应允许容易地根据不同级别细节的需要显示或隐藏。属性和方法的可见性(private, protected, public)是用于选择什么该显示，什么该隐藏的另一个尺度。
一个经常被忽略的关键特性是用某种格式输出图表，以便引入到文字处理文档或Web页面中。用于输出的最流行图像格式是GIF、PNG和JPEG。输出时，工具应允许你定义所产生图形的首选分辨率和尺寸。这个功能需求来自那些野心勃勃，需要写一本包括图表的UML书籍的作者，或者希望将他们的工作展示在网站上的人。
用脚本编程是建模工具应该支持的另一个强大的特性。有了脚本功能，高级用户可以创建能在建模工具内直接访问对象模型的脚本来添加其它功能，例如：为当前开发的项目做的项目管理表格，定制文档，定制代码，报表和度量。一个定制代码的例子是集合类和用于访问集合类的get/set方法。 为了方便使用脚本，建模工具应公开访问自身对象模型的接口，以便在开发时能提供对对象模型组件的访问。(如果这一句听起来有点绕口，请再读一遍。)例如，脚本编写者应能在整个迭代周期中访问类图中类的集合，从而能够通过类对象的aclearcase/" target="_blank" >ccessor方法来访问类的属性。当然，脚本语言自身应该是面向对象的；一个明显的选择就是Java语言本身，另一种选择就是Python脚本语言。
你的UML工具需要象岩石般坚固可靠，以防止设计期间工具崩溃而使用户的时间和生产率在不知不觉中损失，或者在模型没有备份的情况下崩溃。我们曾亲眼见过许多领先的工具因为崩溃或文件损坏而引起数小时的工作成果丢失。如果你是一位开发人员，你知道那种因“生产率高的软件”反而比粗糙的代码工具生产率要低而产生的蔑视感觉。如果你是一位经理，你会看到被要求使用一种不可靠的工具时开发人员的愤恨。 今天，健壮性常被发现于用Java实现的应用程序(JVM运行时保护)或开放源码的项目(在web范围内并行调试)。发现某种特定的UML工具是否健壮的最快方法是在comp.object等新闻组四处询问，你一定会听到许多抱怨的！ 可用于此处的另一个策略可以借鉴有效率的办公应用程序，我们也推荐工具开发商采用这种策略。该策略就是让UML工具每隔一定时间间隔就在背后自动保存模型。
为了使你在建模工具上的投资得到最大回报，请慎重地考虑工具将运行在哪种平台上。你需要为Windows还是Unix开发软件？还是二者都要？将在哪种平台上开发？ 最近的各种事件一起推翻了这个神话：一流的跨平台图形用户界面还不能实现或者拥有一个"最少共同支配者"的视感。很长时间以来,这是不可能的(除了基于HTML的应用程序之外)，直到最近Java的Swing用户界面的出现。但是，跨平台工具需要在Linux等常用平台得到支持，以大规模地被程序员们采用。 Sun最初几乎没有做什么事情来促进Java在Linux上的应用。但最近工业界元老们，主要是IBM，IBM保证在他们所有的硬件平台上为Linux提供无限广泛的支持，并支持Apache/Jakarta项目, IBM现正快速地在Linux上推广Java。也许因为IBM已经开始为主要的Linux厂商发放它的JDK 1.1.8版本，Sun被迫支持在Linux上的 全功能JDK 1.2 （带Swing的Java2）的发放。通过Blackdown小组的努力，这个Linux上的Java端口大部分已被完成。 迄今为止我们已经测试了一种Linux平台上基于Swing的领先Linux工具，结果优秀。但要告诫的是：128M内存是必需的。
你需要选择一种将会不断通过修正错误、改进性能、添加新特性来进行改进的建模工具，毕竟你在时间和金钱上进行了一项大的投资，而且改换到另一种建模工具并不容易。 小心那些已经被大公司拥有的产品。在兑现所有期权之后，最初的开发者常常会离开公司，寻找下一次大的机会。寻找有才能的、能读懂和维护最初并非由其编码的软件复杂模块的程序员并不容易。这种场景也会出现在开放源码项目上。 如何能知道一种产品是否在改进？向销售代表询问下一版本发放的详细时间表以及该产品将来的蓝图。密切观察产品改进和添加新特性的速度。产品计划什么时候支持UML 1.3？图形界面是否支持最新的流行样式？你也可以看看该公司的网站：如果产品发布和外界评论是旧的，就是可疑的。
现在我们来看看对未来有什么希望。建模工具的当前成熟程度表明，工具厂商准备通过添加高级特性来使产品达到新的高度。我们希望在下一代产品中看到以下特性的出现。
在模型的迭代开发过程中，将UML图表和相邻窗口的源代码匹配，是非常有效率的。支持这种视图协调的产品可以给模型设计者的工具箱添加一个额外的功能选项，以直接给建模工具添加强大的源代码编辑特性。当建模工具不必作为设计者的首选编辑器时，能够在代码里直接更改方法的名字或原型，并立即反映到模型中。 最想要的特性是类似emacs等流行编辑器的键盘仿真，另一个热门特性是通过改变颜色来突出语言关键字，注释等等，提高了代码的易读性。一个重要特性是在类图中选择一个类、属性或方法时跳转到匹配代码行的能力。 最重要的是, 编辑器应该是快速易用的。 作为变通的方法，另一种解决方案是允许建模工具和开发者喜爱的编辑器通信。例如，通过一个热键，允许建模工具从当前活动窗口跳转到伴随编辑器的匹配代码行。
我们真正想在不久的将来看到的一个特性是，建模工具帮助产生交互图和状态图的能力。 工作方式是：在一个已有的程序的执行过程中，建模工具应容易生成一个追踪文件，目的是获取对象间互相传递信息时的交互。产生追踪文件后，建模工具将被用于分析该追踪文件，以发现对象交互的模式。建模工具应允许用户从一组类中选择一个来分析，然后展示被追踪文件记录的每个类唯一的一套交互，允许用户为模型选择交互。最后，工具应能够产生一张基于真实记录对象交互的顺序或协作图。 很酷吗？它并不象听起来的那样太过前卫。因为追踪技术已经十分成功地应用在帮助开发人员追捕他们的程序中性能瓶颈的工具中。这类产品一个很好的例子就是KL Group的JProbe，用于分析Java程序的性能。 使用同样的技术自动产生状态图也是可能的。对以前描述过的顺序的修改将允许用户为状态机里的状态指定基类的名称。建模工具将追踪基类的衍生类之间的交互。从这种追踪，建模工具能够通过描绘每次被记录的状态迁移来创建状态图。
如果你是项目经理中的一员，你最有可能想要能够估量你的O-O项目进展如何。一个应被集成到建模工具中的很好的特性是能够输出模型信息到允许你追踪项目设计和实现进程的工具中。由于它的通用性和可塑性，电子表格是实施这个解决方案的理想工具。项目管理工具也是理想的候选。 这个特性如何工作呢？在高层次，通常你想追踪的是模型中的类和负责在这些类上工作的的人。 你想知道什么时候有人开始在该类上工作，完成任务到了哪种水平。在下一层次的细节上，你想要知道每个类的方法。在这一层次，你可能想要知道哪种方法已经包括在交互图中，或在实施阶段，每种方法完成了多少代码量。 要使这个特性起作用，你需要“敏捷”地更新你的项目管理信息。不象报表工具那样总是从头产生一个新报表，你只需要在第一次输出所有东西。产生初始报表后，你的建模工具应该只被要求用新信息来修改你的管理工具。根据用户需要控制的级别，建模工具能在输出之前展现给用户一个修改的清单。 建立一个项目管理链接的一个美妙的好处是，提供把分析和设计阶段的完成日期作为目标的能力。具体方法是通过计算进展速度，并基于完成模型所需的剩余的工作，使用这个速度来计算预期的完成日期。
当你的项目开始成熟时，你可能需要知道你的模型的度量。度量能在一个特殊的模型的生存质量上给面向对象分析员一些即时的反馈。一些感兴趣的度量包括：类层次中的超类数量，每个类中方法的数量，每个类中属性的数量，get/set的数量，方法重载的数量，每个方法的代码行数，public、private和protected方法的百分比，每个类的耦合度（该类知道另外的类的数量），以及被注释方法的百分数。 度量可以通过一个报表界面提供，或者，更好的是，通过一个到电子表格的链接，类似于前面描述的项目管理链接。
为达到真正的、标准化的矢量图形输出/输入功能，UML工具厂商即将有一种选择。W3C的可缩放矢量图形(Scalable Vector Graphics, SVG)建议是可格式化图形的一种XML语法，成熟的1.0版本规范已经进展到“最后预览”阶段(3/3/2000)。一旦被完全认可，你可以留意HTML浏览器厂商什么时候在他们的下一代浏览器中提供支持。 为什么是SVG？因为一套用这种矢量图形格式输出的UML图表可以被链接到网页上。“over the web”的UML设计文档的读者将能够使用这种图形浏览技术，如在浏览器内缩放和平移，来更轻松地浏览一张大的UML图表。还有，和GIF格式图形相比，这种格式将戏剧性地提高通过web加载大图形的速度。请看今天Macromedia Flash的展示在浏览器中加载是如何之快，就可以证明这一点！ 为了强调GIF图形和可缩放图形在出版环境中的强烈差别，我们准备了一个模拟，通过创建包括两个类图实例的Adobe PDF文件，其中一张是输入的GIF图形，另一张是矢量图形。你可以下载这个PDF文档并在Adobe Acrobat中观看。尝试放大到很高的水平如800%或1600%，然后比较GIF图形和矢量图形的结果。这个实验并非不切实际：你可能需要准备一张被缩放到一个可读性提高的水平的演示图。 为了展望UML和SVG的未来，我们也准备了一个使用SVG在浏览器中显示类图的演示。为了观看这个演示，你必须首先为你的浏览器下载一个SVG察看器。我们推荐来自优秀的Adobe SVG站点的插件。这样你就可以观看用SVG显示的图形模型演示。
对UML开发团体来说，对象管理组织(OMG)的XMI标准是最近最令人振奋的进展。XMI是一种有潜力最终允许在领先的开发工具之间无缝共享模型的交换格式。例如，与其在UML建模工具中书写脚本来创建报表，不如让用户简单地在开发时使用XMI输出该模型，然后引入到一种特定的报表书写工具中。事实上，这个范例将平等地、很好地应用到前面讨论过的特性：O-O度量追踪和项目管理。此外，自从XMI使用XML来表示模型信息，一批XML解决方案很快会出笼，例如为基于浏览器表示提供的XSL格式表和为搜索兼容性提供的 XQL查询工具。
XMI标准是复杂的，在被广泛使用之前，它将需要时间来适应许多不可避免的兼容性问题(谁说标准经不起解释？)。但是，既然XMI是由IBM和Unisys等领先的工业巨头开发的，可以预期产品很快会出现。一直到用户团体不断要求厂商来驱动在UML工具中的XMI支持的需求。关于XMI的进一步信息，请看优秀的IBM网页。 作为XMI如何投入使用的例子，请看我们的项目， 转换XMI到HTML. 这个项目展示了XSL格式表如何能被用来产生UML模型的HTML翻译。 读者建议 如果您对在清单中未列出的UML建模工具新特性有什么想法， 我们将很乐意听到。 谢谢曾经把他们的UML工具评价标准Email给我们的读者。他们的原始建议在这儿。
|
