技术开发 频道

使用IBM Rational创建绘图法

为了更加准确的知道每一个元模型类的属性是如何在模型中被实例化的,你可以使用表 1 中显示的原型。

表 1: 对于元模型属性的原型

对于元模型属性的原型 模型中的实例化
<<>> 属性
<<URL>> 附件文档
<<DESC>> 文档域
<<Name>> 指示类名

 

    例如,在图 9 中的元模型类被如图 10 那样实例化。

Figure 9: Metamodel classes
图 9: 元模型类
Figure 10: Model class instantiating metamodel classes in Figure 9

图 10: 模型类实例化图 9 中的元模型类

    图 10 中的 Tom Joad类也有一个指向一个图片的附件和一个可以被用于额外信息的文档窗口。你也可以添加图标到原型类。例如,你可以为 <<SC Person>>: 使用图 11 中的图标。

Figure 11: Icon for stereotyped class

图 11: 用于原型类的图标


在模型中的关系

    在模型的模型中的类存在与其他类之间的关系。例如,系统 OrderEntry_V3有一个或者几个对类型 Person 类的关联。多少关联是被允许的?每一个为什么存在?这个信息被包含在元模型中。

    在 元模型类之间的关系被作为模型类之间的关系实例化。在元模型中的多样性定义了在模型中有多少(最少和最多)关系被定义了。元模型的角色名字或者关联的名字进一步的限定了关联的端点或者关联;这些名字能够在模型级别作为原型的名字或者角色的名字被重用。例如,在图 12 中的元模型指示了一个系统有一个或者几个管理员( Person 类型)和零个或者几个用户( Person 类型)。模型信息(元模型的实例化)看起来如图 12 。

Figure 12: Model class relationships
图 12: 模型类之间的关系

    我们仍然不知道选择什么样的关系 类型。我们应该选择关联和/或依靠和/或其他的什么?我的建议是使用关联,因为

  • 你想要的关联模型:结构关系。
  • 如果你正使用 IBM Rational SoDA 报告工具,过滤/得到一种关系类型是更加容易的。
  • 如果语义比关联之一更加符合的话,你也可以使用其他的关系。

构建模型

    一个重要的成功因素是模型类在模型浏览器中是如何被组织的。 核心的原则是避免重复信息。. 这对于类来说看起来非常明显:你不应该复制类的定义。然而,这个原则不仅仅应用到类本身。考虑一下在包中的组织:你需要包来组织你的模型内容,但是你也希望避免过多的包名。因此你不应该仅仅从元类名中生成包。例如,不要总是创建包 Persons,在这个包中你放入了所有的 <<SC Person >> 实例,包Systems, 在这个包中放入了所有的 <<SC System>> 实例,包Software ,在这个包中放入了所有的 <<SC Software>> 实例,等等。

    考虑一下图 13 显示的模型组织:

Figure 13: Possible model organization in a browser
图 13: 在浏览器中可能的模型组织

    注意这产生了完全相同的子包。更好的方案被显示在图 14 中。

Figure 14: Model organization that avoids duplicate subpackages

图 14: 避免了复制子包的模型组织

    如果有必要的话,你也可以在类之下组织类(嵌套类)。例如,如果你也必须对服务和人的位置建模 Country ,你应该为 Location 创建类并在他们下面组织其他的类。

    注意,你也可以在模型组织中添加图以显示你的绘图元素:类图(上面显示的)和其他类型的图,如果需要的话,可以添加比如活动或者状态图。

    当你构建你的模型时,你也应该考虑团队协作;你可以协调模型组织和包的结构以使并行开发成为可能。在 IBM Rational Rose 中,你可以在单独的被称作 控制单元的单元中存储包,然后将这些控制单元的每一个放入到版本控制之中;IBM Rational Rose 提供了一个内建的和 IBM Rational ClearCase 以及所有的 Source Code Control (SCC) 兼容的版本控制工具的集成。有越多的人在相同的模型之上工作,就会有越多的控制单元应该被定义,以使每个人可以在他自己的控制单元上工作。分配指定的责任给团队成员(例如,分配一些人建模 Person,另一些人建模 System ,等等)并创建相应的控制单元。你甚至可以创建子包,并且如果你需要更细的粒度,你可以将子包做成控制单元。如果你正独自的开发你的绘图法,记住放整个模型在版本控制下以跟踪变更仍然是好的实践。

查询和报告

    一旦你在模型级别输入了信息,你就可以使用 IBM Rational Rose 来实现 查询过滤。例如,使用 IBM Rational Rose 的 " Expand selected elements..." 特性对被选定的类来描述所有被连接的类是容易的。你可以拖放一个如OrderSystem_V3 类到一个新图上,并且查询所有与它相连接的类。你也可以继续得到完整的包括所有错综复杂的和相关的元素的层次图。结果生成的可视化的显示将使理解更加容易。

     报告的能力是被 IBM Rational SoDA 和/或 IBM Rational RoseWeb publisher 提供的。如果你需要自定义的报告能力,你可以使用 Rational SoDA 。

     如果你想要一个根据元模型的强大的模型查询机制,请跟随下面的步骤:

  1. 定义元模型作为一个单独的 IBM Rational Rose 模型。
  2. 为绘图法本身创建一个 Rational Rose 模型。
  3. 动态的阅读元模型,并为检查模型构建规则。

    你既可以使用 IBM Rational Rose scripts 也可以使用一个 COM 服务器来执行这些步骤。

    现在,你具备了所有你需要用来创建几个类图和你的绘图法抽象的条件了。根据你所选择的范围,建模的工作是相当花时间的。通常,图显示大量的信息(类)。尽量的将元素进行逻辑分组并且使用有意义的名字来限定类图。当有必要时不要忘记显示或者隐藏属性。

    在接下来的部分我们将介绍一个样例绘图法的创建。

0
相关文章