2.7 工具的支持

使用建模语言需要相应的工具支持。即使人工在白板上画好了模型的草图，建模者也需要使用工具。因为模型中很多图的维护，同步和一致性检查等工作，人工做起来几乎是不可能的。
自 从用于产生程序的第一个可视化软件问世以来，建模工具（又叫CASE 工具）一直不很成熟。许多CASE 工具几乎和画图工具一样，仅提供了建模语言和很少的一致性检查，增加了一些方法的知识。经过人们不断地改进，今天的CASE 工具正在接近图的原始视觉效果，比如，Rational Rose 工具，就是一种比较现代的建模工具。但是还有一些工具仍然比较粗糙，比如一般软件中很好用的“剪切”和“粘帖”功能在这些工具中尚未实现。另外，每种工具 都有属于自己的建模语言，或至少有自己的语言定义也限制了这些工具的发展。随着统一建模语言UML 的发布，工具制造者现在可能会花较多的时间来提高工具质量，减少定义新的方法和语言所花费的时间。
一个现代的CASE 工具应提供下述的功能：
&<048698; 画图(draw diagrams)
CASE 工具中必须提供方便作图和为图着色的功能,也必须具有智能,能够理解图的
目的,知道简单的语义和规则。这样的特点带来的方便是，当建模者不适当地或错误地使用模型元素时，工具能自动告警或禁止其操作。
&<048698; 积累（repository）
CASE 工具中必须提供普通的积累功能，以便系统能够把收集到的模型信息存储下
来。如果在某个图中改变了某个类的名称，那么这种变化必须及时地反射到使用该类的所有其他图中。
&<048698; 导航（navigation）
CASE 工具应该支持易于在模型元素之间导航的功能。也就是使建模者能够容易地
从一个图到另一个图地跟踪模型元素或扩充对模型元素的描述。
&<048698; 多用户支持
CASE 工具提供该功能使多个用户可以在一个模型上工作，但被此之间没有干扰。
&<048698; 产生代码（generate code）
一个高级的CASE 工具一定要有产生代码的能力。该功能可以把模型中的所有信息翻译成代码框架，把该框架作为实现阶段的基础。
&<048698; 逆转（reverse）
一个高级的CASE 工具一定要有阅读现成代码并依代码产生模型的能力，即模型可由代码生成，它与产生代码是互逆的两个过程。对开发者来说，他可以用建模工具或编程二种方法建模。
&<048698; 集成（integrate）
CASE 工具一定要能与其他工具集成，即与开发环境（比如编辑器编译器和调试
器）和企业工具（比如配置管理和版本控制系统等）的集成。
&<048698; 覆盖模型的所有抽象层
CASE 工具应该能够容易地从对系统的最上层的抽象描述向下导航至最低的代码层。这样，若需要获得类中一个具体操作的代码，只要在图中单击这个操作的名字即可。
&<048698; 模型互换
模型或来自某个模型的个别的图应该能够从一个工具输出，然后再输入到另一个工具。就像JAVA 代码可在一个工具中产生，而后用在另一个工具中一样。模型互换功能也应该支持用明确定义的语言描述的模型之间的互换（输出/输入）。

2.7.1 绘图支持
CASE 工具应使绘图工作简单而有趣，一个高级的绘图工具能够充当CASE 工具经历了一段很长的时间，那是因为CASE 工具不仅必须提供优秀的选择、放置、连接和定义图中元素的机制，而且还要帮助建模者着色，形成一张正确的图。

CASE 工具还应该有理解模型元素语义的能力。这种能力能够在错误地使用模型元素时发出警告，或者提示一个具体的操作与其他操作之间可能存在不一致问题。比如，在 一个模型中，若修改某个图后，将会引起该图与其他图的冲突，这时系统就会自动告警提，示建模者的修改可能出现错误。

CASE 工具也应提供图的版面设计功能。比如，允许建模者重新排列模型元素，而代表消息的线条由工具自动地重新排列，使它们彼此不会交叉。在很多CAD 系统中，这个功能实现得很好，建模工具的制造者可以从中借鉴一些经验。

2.7.2 模型积累
CASE 工具的模型积累就是提供一个数据库。用数据库保存模型中元素的所有信息，而不考虑这些信息来自哪个图。这个积累应该含有整个模型的基本信息，这些基本信息可以通过若干个图看到。如图2-18 所示。

2.7.8 模型互换

模型互换的含义是在一个工具中产生的模型能够应用于另一个工具中。执行模型互换的先决条件是把存储模型的格式标准化。为UML 定义这种格式的工作正在进展中，尽管这种格式还不是OMG 标准的组成部分。
当工具之间的模型互换变成现实的时候，开发环境中的建模工具会更加简单，同时这
种模型也可能被集成到更高级的工具之中。
用户将是模型互换功能的最大受益者，因为他们可以不再紧紧依靠某个CASE 工具制
造商。如果他们喜欢另一种CASE 工具，只要直接将他们的模型移植过来即可，有了统一的标准格式（版本），其他相互独立的工具（比如，文档、报告和生成数据库等工具）也能容易地开发出来。

2.7.9 小结

UML 语言用若干个视图（view）构造系统模型。每个视图代表系统的一个方面，视图用图描述图，又用模型元素的符号表示。图中包含的模型元素可以有类、对象、结点、组件、关系（关联、通用性、依赖等），这些模型元素有具体的含义并且用图形符号表示。
UML 图包括：类图、对象图、用例图、状态图、序列图、协作图、活动图、组件图、和展开图。这些图的用途和绘制这些图时应遵守的规则在后续章节中叙述。

UML 的通用机制用来给图添加信息。通用机制有：修饰（与元素名一起放置）、笔记（存储任何类型的信息）和规格说明。UML 的扩展机制有：加标签值、约束、版类（在已有模型元素的基础上定义新的模型元素）。
一个系统由多个不同类型的模型描述，每种模型都有不同的目的。分析模型描述功能
需求和为真实世界的类构建模型设。计模型把分析结果转换成技术解决方案。实现模型使用面向对象的编程语言将系统编码实现。展开模型把建好的代码放置在物理架构中。上述的几个建模工作是重复迭代操作的过程，并且必须按一定的顺序进行。
在实际工程中，用户使用UML 时需要借助工具。现代CASE 工具应具有下列能力：绘图、存储积累信息、导航、产生报告和文档、代码生成、识别代码产生模型、与其他开发工具集成。

第二章 完