![]() |
Nathalie Gaertner 本文来自于 Rational Edge :本文描述了一种建模的方法,这种方法可以被应用到技术的和非技术的系统中,并产生一种绘图法 — 内部依赖的系统或者相互依赖的系统模型。
本文讨论了一个建模方法,这个建模方法围绕着系统的类型和产生一种绘图法,或者是内部依赖的/相互依赖的系统模型。本文描述了如何创建这样一种绘图法,它可以更进一步的体现使用基于 UML1 的建模工具(比如 IBM Rational Rose® 或者 IBM Rational Rose XDE Modeler/Developer® )的好处,而不是仅仅使用一般的画图工具。 什么是绘图法? 在本文的环境中,我们将使用术语绘图法代表一个交互的和内部相关的系统抽象的可视化的表示。 通常,创建软件的绘图法包括获取已存在信息系统的详细目录并用一个全局的视图描述他们。换句话说,绘图工作就是清点工作 — 或者,如果信息没有被文档化或者是不可得到的,绘图就是考古的工作 。在任何情况下,开发一个软件绘图法都会产生以下的利益“
让我们假设你想要说明和文档化你公司中的系统、位置和人。你可以指出、可视化和文档化部门的和在这些部门中负责管理和维护系统的人的抽象,这些部分所依靠的软件系统和这些软件被安装的计算机的抽象等等。一个可视化的模型 — 一种绘图法 — 能够给你这样的画面。绘图法扩展了”传统的“软件开发模型的范围。 为什么使用建模工具? 建模工具能够比画图工具更好的支持这种复杂的建模工作。它提供了创建系统不同视图(图)、视图之间的依赖关系和环境的方法。使用适当的建模工具提供了以下的好处:
IBM Rational Rose and IBM XDE Rose Modeler/Developer 提供了这些好处,并完美的融入到了绘图建模的环境中。此外,他们还给你下面的额外好处:
选择绘图的方法 在接下来的部分,我们将描述完成这些事情的最好方法,使用 IBM Rational Rose 中嵌入的 UML 。 类和对象方法的缺点 使用 Rational Rose 创建一个绘图模型的一个方法是为抽象创建类,然后创建 UML 对象图(例如,没有消息的协作图)。你可以通过识别主要的抽象开始。这些抽象的一个子集显示在图 1 中。 ![]() 然后你可以象在图 2 中的那样创建一个协作图。 ![]() 图 2: 显示了图1 中的类的实例(比如,对象)的样例图 然而,这个方法存在着它的缺点:
最佳方法:元类和类 你可以在 IBM Rational Rose 中使用查询和过滤菜单来探究和理解被建模环境的内部和相互的依赖:
通过使用这种方法,你现在可以在图 2 中建模象图 3 中的元素了。 ![]() 图 3: 由实例级别到类级别的转化 ![]() 就像你能够看到的,这将产生一个元模型(模型的模型)。 ”流行的 meta“能够被反复的应用;在一个场合的元模型能够是另一个场合下的模型。这也就是使用 UML 和 Meta Object Facility (MOF)3所发生的事情。 在这种方法中,元模型是一种绘图法语言。它定义了建模工作的范围,因为它定义了
作为类的模型绘图法实体 在元模型中的类的名字将变成在模型中原型的名字。在图 4 中,元模型中的 Person 类是模型中的原型的名字。 在你的模型中使用原型类的好处是你能够关联一个图标到一个类,这是模型更加的直观、易于理解和易读,甚至对于不熟悉 UML 的人。在 IBM Rational Rose 中你能以一种用户友好的方式扩展图工具栏,以便你可以通过使用鼠标点击来创建模型类,并且被期望的原型名将已经被定义了。 我推荐你通过绘图法的字母缩写来作为你期望的原型名字的开始。也就是说,你的所有原型的名字将出现在下拉列表和自定义工具栏窗口。对于我们的例子,我们可以使用 System Cartography 作为属名,他的字母缩写为 SC 。 在 IBM Rational Rose 中的自定义的工具栏 (Toolbox)看起来象图 5 中所示。 ![]() 图 5: 自定义 IBM Rational Rose 工具栏的例子 建模绘图法实体的特征作为特性的属性 绘图法的类(模型级别)拥有特性。比如,系统 OrderEntry_V3 有一个生产日期。你可以列出你期望的特性作为在元模型类中的属性(见图 6 )。 ![]() 你该如何实例化这些属性以得到你的模型信息呢?一种在你的模型中输入这个信息的方法是使用被标记的 UML 值。在 IBM Rational Rose 中,被标记的值为所有类定义的特性。不幸的是,特性不能被显示在图中。然而,这些类的特性值应该在图中可见:记住,你不要对工程代码建模!相反,你应该建模绘图法以评估和文档化已存在环境的当前状态。 在 Rational Rose 中,我们可以使用属性代替特性显示在图中。如图 7 所示,这些属性的名字包括特性的名字(例如,ProductionDate)和初始值(例如,12.12.2000)。 ![]() 不幸的是,我们必须手工的在特性名和它的值中进行输入。对所有<<System>> 的类输入特性的名字(比如,ProductionDate)是耗时的并且容易产生错误。 然而,你可以使用一个基于 Rational Rose 脚本的自动化的方案。这个脚本能够根据所有被需要特性的名字(仅仅是被需要的特性)创建一个对话框,通过这个对话框你仅仅能够添加初始值(见图 8 )。这使 Rational Rose 能够解释并迫使在模型级别的规则与那些已经在元模型级别被指定的规则相一致。 此外,假设对每一个元模型类你都有多于 5 个属性,并且对于每一个元模型类你将至少创建 20 个类。如果你不必找到并创建 100 个或者更多的属性名,这对你来说将是巨大的帮助。 ![]() 图 8: IBM Rational Rose 脚本使用创建必要的属性名并输入初始值 然而,不是所有在元模型类中的属性都是最好的在模型中作为属性被实例化的。例如,如果你在元模型类中有一个 comment 属性,在模型中这个属性最好是使用文档域来实例化。类似的,一些属性可以作为连接的文档被实例化。 为了更加准确的知道每一个元模型类的属性是如何在模型中被实例化的,你可以使用表 1 中显示的原型。
例如,在图 9 中的元模型类被如图 10 那样实例化。 ![]() ![]() 图 10 中的 Tom Joad 类也有一个指向一个图片的附件和一个可以被用于额外信息的文档窗口。你也可以添加图标到原型类。例如,你可以为 <<SC Person>>: 使用图 11 中的图标。 ![]() 在模型中的关系 在模型的模型中的类存在与其他类之间的关系。例如,系统 OrderEntry_V3 有一个或者几个对类型 Person 类的关联。多少关联是被允许的?每一个为什么存在?这个信息被包含在元模型中。 在元模型类之间的关系被作为模型类之间的关系实例化。在元模型中的多样性定义了在模型中有多少(最少和最多)关系被定义了。元模型的角色名字或者关联的名字进一步的限定了关联的端点或者关联;这些名字能够在模型级别作为原型的名字或者角色的名字被重用。例如,在图 12 中的元模型指示了一个系统有一个或者几个管理员( Person 类型)和零个或者几个用户( Person 类型)。模型信息(元模型的实例化)看起来如图 12 。 ![]() 我们仍然不知道选择什么样的关系类型。我们应该选择关联和/或依靠和/或其他的什么?我的建议是使用关联,因为
构建模型 一个重要的成功因素是模型类在模型浏览器中是如何被组织的。核心的原则是避免重复信息。. 这对于类来说看起来非常明显:你不应该复制类的定义。然而,这个原则不仅仅应用到类本身。考虑一下在包中的组织:你需要包来组织你的模型内容,但是你也希望避免过多的包名。因此你不应该仅仅从元类名中生成包。例如,不要总是创建包 Persons ,在这个包中你放入了所有的 <<SC Person >> 实例,包 Systems, 在这个包中放入了所有的 <<SC System>> 实例,包 Software ,在这个包中放入了所有的 <<SC Software>> 实例,等等。 考虑一下图 13 显示的模型组织: ![]() 注意这产生了完全相同的子包。更好的方案被显示在图 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 。 如果你想要一个根据元模型的强大的模型查询机制,请跟随下面的步骤:
你既可以使用 IBM Rational Rose scripts 也可以使用一个 COM 服务器来执行这些步骤。 现在,你具备了所有你需要用来创建几个类图和你的绘图法抽象的条件了。根据你所选择的范围,建模的工作是相当花时间的。通常,图显示大量的信息(类)。尽量的将元素进行逻辑分组并且使用有意义的名字来限定类图。当有必要时不要忘记显示或者隐藏属性。 在接下来的部分我们将介绍一个样例绘图法的创建。 样例绘图法 使用 IBM Rational Rose ,这个样例应用了所有的在上面定义的概念,并生成了一个显示绘图法模型快照的报告。当然,使用 IBM Rational Rose 的“浏览”和“查询/过滤/报告”的特性是一种高级的可视化、掌握和使用一个绘图法的方法。 首先,就像我们上面讨论过的,我们想要创建一个元模型(图 15 )来为绘图法定义一种语言。 ![]() 通过看这个元模型,我们可以发现:
然后,我们可以构建图 16A、 B、 C 和 D 来实例化元模型并创建绘图法本身。 ![]() 图 16A 显示了一个被公司系统使用软件视图。在这张图中显示的所有的类是在图 15 中定义的 Software 类的实例,并且有原型 <<Software>> 。这张图的设置表明这个原型应该使用一个图标表示:一个软盘。这些 <<Software>> 类之间的关联表示了他们之间的相互依赖。 ![]() 图 16B 显示了一个公司的 OrderEntry_V3 系统的视图。在图中间的OrderEntry_V3 类有原型 <<System>> ;这张图的设置表明这个原型用了一个盒子的图标表示。这些设置也指明了类的属性应该被隐藏。图中显示了 OrderEntry_V3 系统仅有一个管理员(Daniel Diebolt)和两个用户(Christophe Tournier and Thierry Duvanel);它运行在名为 CH-Server1 的服务器上,并且使用了软件 SAP R/3, v4.6 。 ![]() 图 16C 显示了一个公司软件开发环境系统的视图,并能够显示了 <<system>> Software Development Environment 类的属性。系统有一个管理员和两个用户。系统运行在一个服务器上并使用相互依赖的软件。 ![]() 图 16D: Christophe Tournier 的详细视图 使用所有被输入的信息来创建了在图 16B 和 图 16C 中的图,我们现在可以使用建模工具的查询机制来创建子图 16D 中的图:Christophe Tournier 作为管理员或者用户使用的所有系统的视图。这个类图被设置来显示 Person 和 System 类的属性。 使用 IBM Rational XDE Modeler/Developer 为了使用 Rational Rose XDE Modeler/Developer 创建绘图法,你应该使用一种类似于我们刚刚描述的 IBM Rational Rose 的方法。首先,你应该定义你的 profile ,它将变成你的“语言”(例如,元模型)。就像使用 Rational Rose 一样,你可以使用被标记的值(在 Rational Rose 中成为特性)。但是要记住,你将不会在图中看到那些被标记的值。就像我们前面建议的,最好是使用属性和属性值来代替特性。 在 IBM Rational Rose XDE Modeler/Developer 中,模型浏览器层次应该被良好的定义,但是你可以操作引用了其他模型的不同模型。Rational Rose XDE Modeler/Developer 是可以使用多个模型的。 在 IBM Rational Rose XDE Modeler/Developer 中,报告也是可以得到的。就像 IBM Rational Rose 一样,通过与 IBM Rational SoDA 可以使你生成指定的、自定义的和灵活的报告。 IBM Rational Rose XDE Modeler/Developer 也提供了一个开发的应用编程接口(API)来读模型信息。这个 API 被命名为 Rational XDE Extensibility (RXE)。 它提供了所有你需要创建额外模型检查的能力。 建模工具:对任何系统都是有用的 想象一下创建公司中所有数据库的绘图法是多么有用。如果你有一个在公司中使用他们的接口和位置的所有已存在系统的图,你就可以有效的控制、集成和管理那些系统。 IBM Rational Rose 和 IBM Rational Rose XDE Modeler/Developer 可以帮助你在绘图法元素上创建、维护、可视化、理解、查询 绘图法元素并执行元素之间的冲突分析。你可以容易的创建显示不同方面的不同的图,同时保证他们的一致性。添加新的元素和更新图以反映变化是一个直接了当的过程。一旦你将你的模型置于版本管理之下,你就可以跟踪变化,并且当你构建你的绘图法时,你可以在团队之中工作。 虽然你可以假设创建对象图是最具合理的开始构建一个绘图法方法,但实际上你需要更加强大的工具来支持你通过使用类图来获得这种能力。“流行的 meta ”是最好的方法,因为它允许你在 meta 级别上定义一种语言,然后在模型级别上使用类图建模真正的实体。 我们可以总结一下创建一个绘图法的步骤:
一旦你执行了这些步骤,你已经准备好了使用类图和类图元素创建你的绘图法。当然,如果有必要的话,你也可以添加其他类型的图。 鸣谢 注释 2Webster's Revised Unabridged Dictionary, MICRA, Inc., 1998. 3 MOF 是一个抽象语言和框架,它被用来说明、构建和管理技术中立的元模型。MOF meta-metamodel 是一种被用来定义 UML 元模型的语言。
| ![]() |
超越软件开发建模: 使用 IBM Rational Rose 和 IBM Rational Rose XDE Modeler/Developer 创建绘图法
最新推荐文章于 2022-10-08 16:29:32 发布