超越软件开发建模： 使用 IBM Rational Rose 和 IBM Rational Rose XDE Modeler/Developer 创建绘图法
2004-11-30 08:19
766 查看
 |
IBM 2004 年 4 月 本文来自于 Rational Edge ：本文描述了一种建模的方法，这种方法可以被应用到技术的和非技术的系统中，并产生一种绘图法 — 内部依赖的系统或者相互依赖的系统模型。  在我们的工业里，多数的建模工作是瞄准创建定义了软件系统将如何被设计和实现的分析、设计和实现模型。但是，如果我们能够使用相同的工具来建模软件和非软件的系统，那对我们不是更加有帮助吗？ 本文讨论了一个建模方法，这个建模方法围绕着系统的类型和产生一种绘图法，或者是内部依赖的/相互依赖的系统模型。本文描述了如何创建这样一种绘图法，它可以更进一步的体现使用基于 UML1 的建模工具（比如 IBM Rational Rose® 或者 IBM Rational Rose XDE Modeler/Developer® ）的好处，而不是仅仅使用一般的画图工具。 什么是绘图法？ “绘图法”这个词已经被定义成为了一种“形成图标或者地图的技术或者业务，”2 地图所表示的是“通过正确的空间位置的缩小比例的图解方式表示显示世界的一个地域。” 在本文的环境中，我们将使用术语绘图法代表一个交互的和内部相关的系统抽象的可视化的表示。 通常，创建软件的绘图法包括获取已存在信息系统的详细目录并用一个全局的视图描述他们。换句话说，绘图工作就是清点工作 — 或者，如果信息没有被文档化或者是不可得到的，绘图就是考古的工作 。在任何情况下，开发一个软件绘图法都会产生以下的利益“ 更好的理解已存在的系统和对系统更好的管理能力。 理解在哪里存在着信息或者功能的重复。 在对系统进行变更前分析变更所导致的影响的能力。 更好的对系统进行沟通的方式。 让我们假设你想要说明和文档化你公司中的系统、位置和人。你可以指出、可视化和文档化部门的和在这些部门中负责管理和维护系统的人的抽象，这些部分所依靠的软件系统和这些软件被安装的计算机的抽象等等。一个可视化的模型 — 一种绘图法 — 能够给你这样的画面。绘图法扩展了”传统的“软件开发模型的范围。 为什么使用建模工具？ 大多数的时候，在”非常规的“情况下（也就是，当我们不创建一个将要建立的软件应用的分析或者设计模型时），我们使用画图工具（比如 Visio、CorelDRAW 等等）。然而，这些工具对软件的建模来说是不适合的。他们只适于创建单个的图画；如果我们想要创建几个图，我们必须可以手工的保证在多个维护点上的一致性。同时，如果你尝试着通过一个大图来描述系统，你将发现在视图中添加甚至一个元素都将是”不可能完成的任务“。你将需要找到自由的空间来画新的元素，并要避免交叉关系连线。最终，你将个到一个非常复杂的图，这个图是让人难以理解的，不是真正有用的和几乎不可能仅在一张纸中打印的下的。 建模工具能够比画图工具更好的支持这种复杂的建模工作。它提供了创建系统不同视图（图）、视图之间的依赖关系和环境的方法。使用适当的建模工具提供了以下的好处： 你可以通过以下的好处管理模型的复杂性： 创建几个仅仅显示少量元素的图。 仅定义一个元素一次，就可以使它在几个图中显示（建模工具确保一致性；如果你在一个模型或者任何显示了这个元素的图中修改了一个元素，修改将自动的在其他多处引用了这个元素的图中被进行）。 在某个图中显示或者隐藏元素的细节/属性。 你可以查询模型以得到指定的信息并了解元素内部和元素之间的依赖。例如，你可以让建模工具创建一个图，图中的所有元素与其他元素存在着特定类型的关系。你也可以匹配你的搜索标准来得到所有显示了元素的图（然后浏览他们中的每一个）。 你可以检查并确保图的元素符合 UML 的规范。 你可以添加原型和相应的图标。自定义的图标能够很大程度的改进易读性并能够可视化的表达意图（甚至读者还不熟悉 UML）。 你可以在团队中使用相同的模型工作。 IBM Rational Rose and IBM XDE Rose Modeler/Developer 提供了这些好处，并完美的融入到了绘图建模的环境中。此外，他们还给你下面的额外好处： IBM Rational Rose 扩展接口或者 IBM Rational XDE Development Kit (XDK) 能够扩展建模工具的能力以支持复杂的报告和管理功能。 你可以根据你的需要使用 IBM Rational SoDA® 来生成 MS Word 或者 FrameMaker 报告。 选择绘图的方法 为了成功的进行绘图建模，定义一种语言是首要的任务，这个语言应该包括能够表示各种类型的元素和他们之间的关系、依靠和语义的能力。所有项目中的成员都必须一致认可一种公用的语言，以保证在产出模型上的公共理解。此外，项目中的所有成员都应该对建模过程的范围达成一致。 在接下来的部分，我们将描述完成这些事情的最好方法，使用 IBM Rational Rose 中嵌入的 UML 。 类和对象方法的缺点 假设你想管理一个复杂的部门集合，包括这些部分依赖的系统、他们用来运行软件的计算机和负责管理和维护系统的人员。 使用 Rational Rose 创建一个绘图模型的一个方法是为抽象创建类，然后创建 UML 对象图（例如，没有消息的协作图）。你可以通过识别主要的抽象开始。这些抽象的一个子集显示在图 1 中。  图 1: 在一个管理例子中的主要抽象的子集 然后你可以象在图 2 中的那样创建一个协作图。  图 2: 显示了图1 中的类的实例（比如，对象）的样例图 图 2 ，和所有其他的协作图一起建模环境对象。也要注意有意义的建模工作将添加大量的对象。 然而，这个方法存在着它的缺点： 如果不使用大量的 UML 注释，你将不能对协作图添加所有有用的细节。例如，你如何显示 Tom Joad 是 OrderEntry_V3 系统的管理员？如何显示OrderEntry_V3 系统的属性 OrderEntry_V3 的值？ 你不能检查在协作图与类模型之间的语义的一致性。你如何能够验证每一个系统对象都被连接到至少一个管理员呢？你如何能够验证每一个系统对象，比如在我们的例子中的 OrderSystem_V3 ，对于ProductionDate 属性有相应的值呢？ 你不能简单的查询协作图的内容。IBM Rational Rose 仅仅对类图提供了有趣的过滤和查询功能。这类建模工作的目标不是生成代码，而是获得抽象当前状态的建模方法的利益。例如，你可以真正的从创建一个显示了 Tom Joad 的新图中获益，然后使用 Rational Rose 中的 ”Expand selected elements“ 功能找到并显示Tom Joad担任用户或者管理员的所有系统。 你不能在一个对象之下组织其他元素（对象和/或图）。然而，你能在模型浏览器中组织建模实体层次结构。 你不能在不同的协作图中重用相同的对象。 最佳方法：元类和类 为了避免我们提出的对于类和对象方法的缺点，你可以使用一个 meta 级别。如果你建模 Tom Joad 作为一个类（代替一个对象），你可以使用类图并得到以下的好处： 你可以在 IBM Rational Rose 中使用查询和过滤菜单来探究和理解被建模环境的内部和相互的依赖： 你可以展开被选定的元素并自动化的创建有意义的包含类及其类与其他被选定的类之间的关系类型的图。 你可以通过指定的名字添加类。 你可以隐藏被选定的类。 你可以在当前的图中过滤连接类的关系（显示或者隐藏特定的关系类型）。 你可以根据图来隐藏或者显示类的细节（属性或者操作）。 你可以使用角色的名字进一步的限定类之间的关联。 你可以在不同的图中重用相同的元素，这与在交互图中对象属于，并仅属于一个图正相反。 你可以在一个层次结构中组织被建模的实体，比如，在其他类下被组织的类。 通过使用 IBM Rational Rose 扩展接口 (REI) 和/或 IBM Rational SoDA，你可以得到更加前强大的报告能力。 通过使用这种方法，你现在可以在图 2 中建模象图 3 中的元素了。  图 3: 由实例级别到类级别的转化 你然后也可以推进类向上一个级别，就像图4 所示。  图 4: 元模型和模型方法 就像你能够看到的，这将产生一个元模型（模型的模型）。 ”流行的 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 ）。  图 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 属性，在模型中这个属性最好是使用文档域来实例化。类似的，一些属性可以作为连接的文档被实例化。 为了更加准确的知道每一个元模型类的属性是如何在模型中被实例化的，你可以使用表 1 中显示的原型。 表 1: 对于元模型属性的原型
 图 9: 元模型类  图 10: 模型类实例化图 9 中的元模型类 图 10 中的 Tom Joad 类也有一个指向一个图片的附件和一个可以被用于额外信息的文档窗口。你也可以添加图标到原型类。例如，你可以为 <<SC Person>>: 使用图 11 中的图标。  图 11: 用于原型类的图标 在模型中的关系 在模型的模型中的类存在与其他类之间的关系。例如，系统 OrderEntry_V3 有一个或者几个对类型 Person 类的关联。多少关联是被允许的？每一个为什么存在？这个信息被包含在元模型中。 在元模型类之间的关系被作为模型类之间的关系实例化。在元模型中的多样性定义了在模型中有多少（最少和最多）关系被定义了。元模型的角色名字或者关联的名字进一步的限定了关联的端点或者关联；这些名字能够在模型级别作为原型的名字或者角色的名字被重用。例如，在图 12 中的元模型指示了一个系统有一个或者几个管理员（ Person 类型）和零个或者几个用户（ Person 类型）。模型信息（元模型的实例化）看起来如图 12 。  图 12: 模型类之间的关系 我们仍然不知道选择什么样的关系类型。我们应该选择关联和/或依靠和/或其他的什么？我的建议是使用关联，因为 你想要的关联模型：结构关系。 如果你正使用 IBM Rational SoDA 报告工具，过滤/得到一种关系类型是更加容易的。 如果语义比关联之一更加符合的话，你也可以使用其他的关系。 构建模型 一个重要的成功因素是模型类在模型浏览器中是如何被组织的。核心的原则是避免重复信息。. 这对于类来说看起来非常明显：你不应该复制类的定义。然而，这个原则不仅仅应用到类本身。考虑一下在包中的组织：你需要包来组织你的模型内容，但是你也希望避免过多的包名。因此你不应该仅仅从元类名中生成包。例如，不要总是创建包 Persons ，在这个包中你放入了所有的 <<SC Person >> 实例，包 Systems， 在这个包中放入了所有的 <<SC System>> 实例，包 Software ，在这个包中放入了所有的 <<SC Software>> 实例，等等。 考虑一下图 13 显示的模型组织：  图 13: 在浏览器中可能的模型组织 注意这产生了完全相同的子包。更好的方案被显示在图 14 中。  图 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 模型。 为绘图法本身创建一个 Rational Rose 模型。 动态的阅读元模型，并为检查模型构建规则。 你既可以使用 IBM Rational Rose scripts 也可以使用一个 COM 服务器来执行这些步骤。 现在，你具备了所有你需要用来创建几个类图和你的绘图法抽象的条件了。根据你所选择的范围，建模的工作是相当花时间的。通常，图显示大量的信息（类）。尽量的将元素进行逻辑分组并且使用有意义的名字来限定类图。当有必要时不要忘记显示或者隐藏属性。 在接下来的部分我们将介绍一个样例绘图法的创建。 样例绘图法 下面的样例是基于我们上面讨论过的绘图法模型的，它包括一个公司的系统、软件和他们需要的计算机，还有负责管理和使用系统的人员 使用 IBM Rational Rose ，这个样例应用了所有的在上面定义的概念，并生成了一个显示绘图法模型快照的报告。当然，使用 IBM Rational Rose 的“浏览”和“查询/过滤/报告”的特性是一种高级的可视化、掌握和使用一个绘图法的方法。 首先，就像我们上面讨论过的，我们想要创建一个元模型（图 15 ）来为绘图法定义一种语言。  图 15: 为样例绘图法定义语言的元模型 通过看这个元模型，我们可以发现： 绘图法应该显示系统、人、软件和服务器。 系统能够运行在一台或者几台服务器上。 系统可以依赖零个或者几个软件部分。 软件本身可以依赖其他软件。 每个系统将至少有一个扮演管理员角色的人和零个或者更多的扮演用户角色的人。 绘图法的每一个元素的特性通过在图 15 中的类的属性被定义。 然后，我们可以构建图 16A、 B、 C 和 D 来实例化元模型并创建绘图法本身。  图 16A: 软件视图 图 16A 显示了一个被公司系统使用软件视图。在这张图中显示的所有的类是在图 15 中定义的 Software 类的实例，并且有原型 <<Software>> 。这张图的设置表明这个原型应该使用一个图标表示：一个软盘。这些 <<Software>> 类之间的关联表示了他们之间的相互依赖。  图 16B: OrderEntry_V3 系统视图 图 16B 显示了一个公司的 OrderEntry_V3 系统的视图。在图中间的OrderEntry_V3 类有原型 <<System>> ；这张图的设置表明这个原型用了一个盒子的图标表示。这些设置也指明了类的属性应该被隐藏。图中显示了 OrderEntry_V3 系统仅有一个管理员（Daniel Diebolt）和两个用户（Christophe Tournier and Thierry Duvanel）；它运行在名为 CH-Server1 的服务器上，并且使用了软件 SAP R/3, v4.6 。  图 16C: 软件开发环境视图 图 16C 显示了一个公司软件开发环境系统的视图，并能够显示了 <<system>> Software Development Environment 类的属性。系统有一个管理员和两个用户。系统运行在一个服务器上并使用相互依赖的软件。  图 16D: Christophe Tournier 的详细视图 使用所有被输入的信息来创建了在图 16B 和 图 16C 中的图，我们现在可以使用建模工具的查询机制来创建子图 16D 中的图：Christophe Tournier 作为管理员或者用户使用的所有系统的视图。这个类图被设置来显示 Person 和 System 类的属性。 使用 IBM Rational XDE Modeler/Developer IBM Rational Rose XDE Modeler/Developer 通过创建 XDE profile 提供了一种非常好的 UML 扩展以支持元模型/模型的方法。一个 profile 是一系列的被标记的值和原型。被标记的值捕获模型元素中的额外信息，原型添加语义到模型元素。 为了使用 Rational Rose XDE Modeler/Developer 创建绘图法，你应该使用一种类似于我们刚刚描述的 IBM Rational Rose 的方法。首先，你应该定义你的 profile ，它将变成你的“语言”（例如，元模型）。就像使用 Rational Rose 一样，你可以使用被标记的值（在 Rational Rose 中成为特性）。但是要记住，你将不会在图中看到那些被标记的值。就像我们前面建议的，最好是使用属性和属性值来代替特性。 在 IBM Rational Rose XDE Modeler/Developer 中，模型浏览器层次应该被良好的定义，但是你可以操作引用了其他模型的不同模型。Rational Rose XDE Modeler/Developer 是可以使用多个模型的。 查询和过滤也是可得到的：选项一个类，右键点击，并选择 "Add related shapes" 。然而，在 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 都支持绘图法的创建，并且能够更加有效的被扩展以支持它。如果你正在建模一个复杂的系统，并且不需要产生代码，你将可以获得建模工具带来的巨大利益。 想象一下创建公司中所有数据库的绘图法是多么有用。如果你有一个在公司中使用他们的接口和位置的所有已存在系统的图，你就可以有效的控制、集成和管理那些系统。 IBM Rational Rose 和 IBM Rational Rose XDE Modeler/Developer 可以帮助你在绘图法元素上创建、维护、可视化、理解、查询 绘图法元素并执行元素之间的冲突分析。你可以容易的创建显示不同方面的不同的图，同时保证他们的一致性。添加新的元素和更新图以反映变化是一个直接了当的过程。一旦你将你的模型置于版本管理之下，你就可以跟踪变化，并且当你构建你的绘图法时，你可以在团队之中工作。 虽然你可以假设创建对象图是最具合理的开始构建一个绘图法方法，但实际上你需要更加强大的工具来支持你通过使用类图来获得这种能力。“流行的 meta ”是最好的方法，因为它允许你在 meta 级别上定义一种语言，然后在模型级别上使用类图建模真正的实体。 我们可以总结一下创建一个绘图法的步骤： 定义一种稳定的语言，或者元模型，它包含类、属性和关系。 自定义 IBM Rational Rose 或者 IBM Rational Rose XDE 工具栏，并且创建可以简单的输入模型类属性的脚本。 在 Rational Rose 中定义一个模型浏览结构，这可以合理的组织信息，并且实现可以容易的得到模型元素的方法。 使用 IBM Rational SoDA 建立必要的报告。 将你的模型置于版本控制之下以方便团队的协调和变更的跟踪。 一旦你执行了这些步骤，你已经准备好了使用类图和类图元素创建你的绘图法。当然，如果有必要的话，你也可以添加其他类型的图。 鸣谢 非常感谢 Christophe Tournier ，他推动了我写这篇文章，同时我和他进行了讨论并发展了我的想法和概念。同时非常感谢 Catherine Southwood ，她提供了非常有简直的注释和编辑工作。 注释 1 UML,® 或者统一建模语言， 是用于说明、可视化和文档化软件和非软件系统的图形化的语言。 更多的信息参见 http:// www.omg.org/uml/ 2Webster's Revised Unabridged Dictionary, MICRA, Inc., 1998. 3 MOF 是一个抽象语言和框架，它被用来说明、构建和管理技术中立的元模型。MOF meta-metamodel 是一种被用来定义 UML 元模型的语言。
| |
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 