选择绘图的方法

    为了成功的进行绘图建模，定义一种语言是首要的任务，这个语言应该包括能够表示各种类型的元素和他们之间的关系、依靠和语义的能力。所有项目中的成员都必须一致认可一种公用的语言，以保证在产出模型上的公共理解。此外，项目中的所有成员都应该对建模过程的范围达成一致。

    在接下来的部分，我们将描述完成这些事情的最好方法，使用 IBM Rational Rose 中嵌入的 UML 。

类和对象方法的缺点

    假设你想管理一个复杂的部门集合，包括这些部分依赖的系统、他们用来运行软件的计算机和负责管理和维护系统的人员。

    使用 Rational Rose 创建一个绘图模型的一个方法是为抽象创建类，然后创建 UML 对象图（例如，没有消息的协作图）。你可以通过识别主要的抽象开始。这些抽象的一个子集显示在图 1 中。

图 1: 在一个管理例子中的主要抽象的子集

    然后你可以象在图 2 中的那样创建一个协作图。

图 2: 显示了图1 中的类的实例（比如，对象）的样例图

    图 2 ，和所有其他的协作图一起建模环境对象。也要注意有意义的建模工作将添加大量的对象。

    然而，这个方法存在着它的缺点：

1. 如果不使用大量的 UML 注释，你将不能对协作图添加所有有用的细节。例如，你如何显示 Tom Joad 是 OrderEntry_V3 系统的管理员？如何显示 OrderEntry_V3 系统的属性 OrderEntry_V3 的值？
2. 你不能检查在协作图与类模型之间的语义的一致性。你如何能够验证每一个系统对象都被连接到至少一个管理员呢？你如何能够验证每一个系统对象，比如在我们的例子中的 OrderSystem_V3 ，对于ProductionDate 属性有相应的值呢？
3. 你不能简单的查询协作图的内容。IBM Rational Rose 仅仅对类图提供了有趣的过滤和查询功能。这类建模工作的目标不是生成代码，而是获得抽象当前状态的建模方法的利益。例如，你可以真正的从创建一个显示了 Tom Joad 的新图中获益，然后使用 Rational Rose 中的 ”Expand selected elements“ 功能找到并显示 Tom Joad担任用户或者管理员的所有系统。
4. 你不能在一个对象之下组织其他元素（对象和/或图）。然而，你能在模型浏览器中组织建模实体层次结构。
5. 你不能在不同的协作图中重用相同的对象。

非常好的方法：元类和类

    为了避免我们提出的对于类和对象方法的缺点，你可以使用一个 meta 级别。如果你建模 Tom Joad 作为一个类（代替一个对象），你可以使用类图并得到以下的好处：

    你可以在 IBM Rational Rose 中使用查询和过滤菜单来探究和理解被建模环境的内部和相互的依赖：

1. 你可以展开被选定的元素并自动化的创建有意义的包含类及其类与其他被选定的类之间的关系类型的图。
   • 你可以通过指定的名字添加类。
   • 你可以隐藏被选定的类。
   • 你可以在当前的图中过滤连接类的关系（显示或者隐藏特定的关系类型）。
   • 你可以根据图来隐藏或者显示类的细节（属性或者操作）。
2. 你可以使用角色的名字进一步的限定类之间的关联。
3. 你可以在不同的图中重用相同的元素，这与在交互图中对象属于，并仅属于一个图正相反。
4. 你可以在一个层次结构中组织被建模的实体，比如，在其他类下被组织的类。
5. 通过使用 IBM Rational Rose 扩展接口 (REI) 和/或 IBM Rational SoDA， 你可以得到更加前强大的报告能力。

    通过使用这种方法，你现在可以在图 2 中建模象图 3 中的元素了。

图 3: 由实例级别到类级别的转化

    你然后也可以推进类向上一个级别，就像图4 所示。

图 4: 元模型和模型方法

    就像你能够看到的，这将产生一个 元模型（模型的模型）。 ”流行的 meta“能够被反复的应用；在一个场合的元模型能够是另一个场合下的模型。这也就是使用 UML 和 Meta Object Facility (MOF) ³ 所发生的事情。

    在这种方法中，元模型是一种绘图法语言。它定义了建模工作的范围，因为它定义了

• 在模型层使用的元素”类型“，
• 在模型层这些元素间可能的关系。
• 在类和关系背后的语义。

作为类的模型绘图法实体

     在元模型中的类的名字将变成在模型中原型的名字。在图 4 中，元模型中的 Person 类是模型中的原型的名字。

    在你的模型中使用原型类的好处是你能够关联一个图标到一个类，这是模型更加的直观、易于理解和易读，甚至对于不熟悉 UML 的人。在 IBM Rational Rose 中你能以一种用户友好的方式扩展图工具栏，以便你可以通过使用鼠标点击来创建模型类，并且被期望的原型名将已经被定义了。

    我推荐你通过绘图法的字母缩写来作为你期望的原型名字的开始。也就是说，你的所有原型的名字将出现在下拉列表和自定义工具栏窗口。对于我们的例子，我们可以使用 System Cartography 作为属名，他的字母缩写为 SC 。

    在 IBM Rational Rose 中的自定义的工具栏 （Toolbox）看起来象图 5 中所示。

图 5: 自定义 IBM Rational Rose 工具栏的例子

建模绘图法实体的特征作为特性的属性

    绘图法的类（模型级别）拥有特性。比如，系统 OrderEntry_V3 有一个生产日期。你可以列出你期望的特性作为在元模型类中的属性（见图 6 ）。

图 6: 定义元模型类的特性作为属性

    你该如何实例化这些属性以得到你的模型信息呢？一种在你的模型中输入这个信息的方法是使用被标记的 UML 值。在 IBM Rational Rose 中，被标记的值为所有类定义的特性。不幸的是，特性不能被显示在图中。然而，这些类的特性值应该在图中可见：记住，你不要对工程代码建模！相反，你应该 建模绘图法以评估和文档化已存在环境的当前状态。

    在 Rational Rose 中，我们可以使用属性代替特性显示在图中。如图 7 所示，这些属性的名字包括特性的名字（例如，ProductionDate）和初始值（例如，12.12.2000）。

图 7: 模型类拥有初始值的属性

    不幸的是，我们必须手工的在特性名和它的值中进行输入。对所有<<System>>的类输入特性的名字（比如，ProductionDate）是耗时的并且容易产生错误。

    然而，你 可以使用一个基于 Rational Rose 脚本的自动化的方案。这个脚本能够根据所有被需要特性的名字（ 仅仅是被需要的特性）创建一个对话框，通过这个对话框你仅仅能够添加初始值（见图 8 ）。这使 Rational Rose 能够解释并迫使在模型级别的规则与那些已经在元模型级别被指定的规则相一致。

    此外，假设对每一个元模型类你都有多于 5 个属性，并且对于每一个元模型类你将至少创建 20 个类。如果你不必找到并创建 100 个或者更多的属性名，这对你来说将是巨大的帮助。

图 8: IBM Rational Rose 脚本使用创建必要的属性名并输入初始值

    然而，不是所有在元模型类中的属性都是最好的在模型中作为属性被实例化的。例如，如果你在元模型类中有一个 comment 属性，在模型中这个属性最好是使用文档域来实例化。类似的，一些属性可以作为连接的文档被实例化。