这个文章系列向您详细阐述了编程者是如何利用 IBM® Rational®
Software Architect、IBM® Rational® Systems Developer，以及
IBM® Rational® Software Modeler 来编写 UML 概要文件的。第
2 部分讨论了变更管理、部署、定位、编程支持，以及最佳实践。
这篇文章对 IBM® Rational® Software Architect IBM、®Rational®Systems
Developer，以及 IBM® Rational® Software Modeler（7.0
以及更新版本）产品中的 UML Profile Authoring 是一个详细的指导。它覆盖了 UI 支持和程序性支持（对于用户来说延伸本身这个工具）。它的主要目标对象是概要文件作者，但是它还为概要文件的使用提供了一些见解。
这个系列的第 1 部分向您显示了如何创建或者导入 UML 概要文件。您还将学习 OCL 和 Java™的内嵌构建支持，以及如何运用一个概要文件。
这篇文章 ，也就是这个系列的第 2 部分，将讨论变更管理，部署，定位，程序性支持，以及最佳实践。
特定的参考版本（按照发布的时间顺序排列） 是 7.0， 7.0.0.1， 7.0.0.2， 7.0.0.3，
7.0.0.4， 7.0.0.5 （仅仅是 Rational Software Architect） 和
7.0.5 （Rational Software Modeler 和 Rational Systems
Developer）。这个文章清晰地表明行为和版本之间的差异所在。
这篇文章中的信息应用于 Rational Software Architect， Rational Systems
Developer，以及 Rational Software Modeler。 除非有其他特定的方式，否则“Rational
Software Architect”将在这篇文章中被用来代表三个产品。
这篇文章假定您已经拥有合理的关于 UML 2.1 规范的知识，尤其是与概要文件相关的部分。它并不试图进一步描述或者澄清这个规范，但是会更加强调
Rational Software Architect 中它执行的问题。一般关于 Eclipse 和 Rational
Software Architect 的知识也一样有用处。如果您希望创建基于概要文件的插件就需要 Eclipse
PDE （插件开发环境子项目） 知识。
理解与概要文件一起工作的变更管理是十分重要的。例如，当一个旧的概要文件版本运用到一个模型中时，这个迁移过程（到更新版本的）
就会使用编排版本机制构建到这个概要文件本身中去。那个机制是完全独立于您所使用的任何源控制系统的。当然，当您利用这个概要文件的两个不同版本合并概要文件的这两个版本，或者一个模型的两个版本时，这个源控制系统现存的介绍就会更加复杂。
概要文件版本化
每个概要文件包括一个或者更多概要文件的版本。每次保存这个概要文件时就会创建一个新的版本，而且其它版本不会被清除。它可能将有助于您想象一个版本就是一个概要文件的运行组件，并且有到
UML 定义的链接。当这个概要文件运用到一个模型时，它才是链接到这个模型的最新版本 （运行组件）。这个概要文件的
UML 定义通过版本直接链接到这个模型。
当它保存时，这个概要文件就已经有效。如果存在任何错误，那么这个概要文件被保存，但是不会创建一个概要文件版本。您
（正如这个概要文件编辑器）必须为了产生这个概要文件版本修复所有的错误。当然会报告这些警告，但是它们并不会阻止这个概要文件版本的创建。概要文件中的一个普通错误案例都是原型或者没有类型的类属性。
只有最新版本才能完全和精确地反映这个概要文件的 UML 定义。其它所有版本仅仅抓住了足够信息的使模型平稳转换——利用运用于的版本——为这个概要文件的最新版本。这是在假定版本之间没有不兼容变更存在的前提下发生的
（在兼容性规则板块有更多关于这个话题的资料）。
要查看当前 （最新） 概要文件的版本，请在 Project Explorer 中选定它并导航到 Properties
视图中的 General标签。它有一个只读 Version 区域。这个信息在
Profile Editor 中也可以找到，在 General 标签上的Versions
表格中。
将它与已经运用在这个模型中的版本进行比较，选择 Project Explorer 中的模型并导航到 Properties
视图中的 Profiles标签。其中一行将代表感兴趣的概要文件 （如果它被实际运用），并且在这个表格中有一个
Version 专栏。
发布一个概要文件
发布一个概要文件，就会创建这个概要文件的一个特定版本。要调用它，选择 Project Explorer
中的这个概要文件，右键点击它，并 点击 Release。您还应该利用 Profile Editor
来操作：选择 General 标签上的 Versions 表格，并点击 Release按钮。这样就启动了图
1中所显示的对话框，这时您可以详细说明将要联合在这个发布版本的发布标签。这个发布标签是完全随意的：它可以是您想要键入的任何字符串。
图 1. 发布 Profile 对话框
这个概要文件的所有发布版本都列在 Properties 视图中 General 标签上的
Releases区域。所有的概要文件版本（包括发布的版本） 都列在 Profile Editor
的 Overview 标签上的 Versions 表格中。
如果发布了大多数最近的版本，那么 Release Label区域就会显示和它一起的标签。如果这个概要文件从没有被发布，或者如果它已经在最后发布后就已经被修改，那么
Release Label 区域将会表明出来。
除了将最新的非发布概要文件版本标记为发布版本（并将它与发布标签联合起来）之外，所有其它非发布版本都被清除。因此，概要文件的非发布版本应该仅仅运用到最佳模型中这些应用即时概要文件版本的模型将能够迁移到这个发布版本，但是它们会丢失数据：应用的固定模型和固定模型值将构成一些特性。发布过程利用最新的非发布版本作为发布版本，直到这个概要文件处于被修改的状态：在这个案例中，概要文件首先被保存，这样就可以创建一个新的非发布版本，然后那个版本就会被发布。
还有一种能够安全将数据从应用了非发布概要文件版本的模型中移出的方法：在发布这个概要文件之前，所有这样的模型都移到这个概要文件的最新非发布版本中。然后这个概要文件在不做任何其它修改的情况下被发布。
发布一个概要文件同时还要建立一个核对基准点：这个工具在您对已经被发布的概要文件进行变更时会加强兼容性规则。
兼容性规则
在概要文件迁移过程中对它进行一定的变更，结果会导致数据的损失。下面这些行为将导致兼容性问题：
- 对存在于先前版本中的元素重新命名
- 删除存在于先前版本中的一个元素
- 变更 Stereotype 的类型或者存在于先前版本中的 Class 属性
这个工具将阻止您进行这样的变更，但是仅仅于发布版本相关。
例如，如果您创建一个带有原型的概要文件 （S1）
并将它发布，然后添加另一个原型 （S2） 到这个概要文件中，这个工具将允许您删除（或者重新命名）S2单不可以是S1。
这个兼容性规则使用在整个现时约束中：从 Preferences > Window菜单中，点击Model
Validation > Constraints。接下里，点击 UML 2.1 >
Modeling > Profiles 或者 UML 2.1 > Model
Quality Dimensions > Compatibility。最后，选择 Profile
Compatibility Restrictions 约束。
如果您必须做出一个变更 ，使它与发布版本不相兼容，不管是什么原因，那么就会有一个临时后门丧失这个约束的能力。当然，如果这是完全必需的，就只能这样做。然而，在这种情况下会收到这样的警告：在概要文件迁移过程中很可能会丢失数据。
迁移
迁移更新了模型中应用的概要文件版本。它还更新了模型的链接，从先前应用到它的版本到这个概要文件的最新版本。应用的原型以及原型分配的值都没迁移，使其遵守这个概要文件的新
UML 定义。
如果在版本之间并没有不兼容变更，那么其中某些数据就会丢失。例如，如果一个原型 （那已经应用到这个模型的某些元素中）已经从这个概要文件中删除，那么所有的原型应用软件都将丢失。这个原型分配的所有属性都会发生同样的情况。
如果这个概要文件完全不包括先前应用在这个模型中的版本，那么只有连接到应用概要文件的版本会更新。所有应用的概要文件以及原型分配的属性都将丢失。
自动迁移
当一个模型打开时就会发生自动迁移：如图 2所示，如果这个系统检测到使用了旧版本的概要文件，它将提示您执行迁移。当然，您可以拒绝这样做。
图 2. 概要文件迁移警告
然而，如果这个概要文件不再应用先前的版本，这个迁移将导致被使用原型的迁移。当保存这样的模型时，您将会被提示（请参见图
3），关于保存为被意识到的内容 （基本上是丢失的原型应用软件）。如果这个概要文件一起丢失，那么这个工具就不会提供迁移；您指挥被通报关于丢失概要文件的消息。
图 3. 保存一个带有未被识别内容的模型
打开和保存带有未被识别内容的模型的行为都可以通过参数设置（点击 Window > Preferences
使其个性化，然后导航到 Modeling 页面）。您的选项是 Always，Never，
以及 Prompt。默认的行文是提示。
手工迁移
您可以在任何时候手工从 Properties 视图或者从 Model Editor 迁移一个应用的概要文件（为选择的包）。要执行这个迁移，请在
Project Explorer 中选择应用了这个概要文件的包裹（模型），并导航到 Properties
视图的 Profiles 标签键符，如图 4所示。
这个表格列出了所有的应用概要文件，并且所有不同步的概要文件都被清晰地标识出来。这个 Migrate
Profile按钮是用来执行实际迁移的。在整个 Model Editor 中将会实现同样的结果：导航到
Details 标签，您将看到 Applied Profiles区域中的 Migrate
按钮。
图 4. 手工概要文件迁移
压缩一个概要文件
可以在没有发布概要文件的情况下清除中间（非发布的） 版本。可以这样操作，选择 Project Explorer
中的概要文件，右键点击它并点击 Compress。这样就可以删除所有非发布本版，除了最后一个外。如果这个文件已经更新，那么它将首先创建一个非发布版本，然后将它保存并使它创建的版本和最新的非发布版本保持在它之前。
在 Profile Editor 整个过程中也会发生同样的结果：导航到 Overview
标签，而且 Compress 按钮在 Versions区域中。
当这个概要文件有一个长期的开发过程时，这个行为就十分有用了。因为每次保存概要文件时就会创建一个新的版本，它可以迅速增长，这样就可以对性能产生深远影响
（在内存使用和速度两个方面）。
有两种部署概要文件的方法：文件基于系统的部署，以及插件部署。不管在哪种情况下，都强烈推荐拥有一个概要文件定位的路径映射指点。尽管不是强制性的，但是它时管理部署的最简单的方法。如果不使用路径映射，那么这个系统将在这个概要文件应用位置的模型文件中存储一个文件路径（如果可能的话）。在某些情况下已经
OK 了，但是当这些模型和概要文件共享时一定会导致一些问题，尤其是当则这个概要文件位置没有确定的时候。
同样，还强烈推荐要避免不同的位置中的概要文件存在于它们所应用的模型中，尽管并不禁止它们共享一个位置。这个工具将在模型中存储相关的路径来参考这样的概要文件
，即使对那个位置已经有一个定义的路径映射。
文件系统部署
这个概要文件可以部署在文件系统的任何地方：它并不一定要在工作空间中。当然，您必须为了创作将概要文件保存在您的工作空间中。
然而，如果这个位置包含由路径映射指引的概要文件，将会十分有利。路径映射可以仅仅用在与资源链接的结合点
（这是一个 Eclipse 概念：请参见Resources区域获取更多详细情况）。实质上，一个路径映射是分配给一个链接的代表一个文件夹的参考资料的。
要创建一个路径映射，请点击Window > Preferences，然后点击Modeling
> Pathmaps。这个结果显示在图5中。
注释：定义的工具路径映射显示在只读模式中。
图 5. 路径映射
首先利用页面顶部的这个链接（‘Linked Resources’）来创建一个指向想要的文件夹的链接参考资料（请参见图
6）。然后就存在这个优先的页面，重新打开它，并再次导航到 Pathmaps 页面。这个步骤是必须的，因为最新创建的链接参考资料将不会在这个列表中显示出来，直到
Preferences 页面被重新启动。
图 6. 创建新的链接参考资料
现在在 Pathmap 页面，激活如图 7所示的链接参考资料。
图 7. 激活链接的参考资料作为路径映射
如果这个模型和应用的概要文件被共享 ，那么相同的路径录必须在每个被使用的系统上创建。这个工具将不会强制执行存在性或者路径的正确性：该由您的特殊小组来确保这个路径映射存在并指向有效的位置。如果这个路径映射并不存在或者是无效的，那么这个模型将不会被适当地打开，因为这个工具将不能找到应用地概要文件
（请参见变更管理区域获取更详细的信息）。
请注意，您作为这个概要文件的创作者，不能保证路径映射的使用：真正只有安装它的概要文件用户才可以保证。
插件部署
概要文件可以通过插件来部署。这个插件机制为概要文件创作者提供了更多的控制，并且为概要文件用户简化了使用和维护这个概要文件的工作。从另一方面来看，对概要文件的创作者来说的确需要更多的工作和知识。基本上，概要文件存储在插件中，并且通过它的
plugin.xml 文件来注册。然后插件就分配到概要文件用户，他们必须将它安装在他们的 IDE （集成开发环境）
——或者运行环境中——取决于他们需要使用概要文件或者插件的位置。
通过这样方法部署的概要文件由这个系统来管理。那就意味着您不需要在这个文件系统中浏览这个概要文件，但是当应用概要文件时却需要从这个下拉菜单（Deployed
Profile） 中选择它。您有一个选项可以阻止这个概要文件在这个列表中显示 （更多的信息在后面显示）。
另一个有用的特征是，您还可以在 plugin.xml 文件中定义这个路径映射。用这种方法，概要文件的用户就不必但心概要文件定位以及路径映射了。
这个概要文件通过插件机制部署，同样可以将 Java 作为概要文件限制的语言。
插件的复杂性真的是依靠您和实际的设计来保持概要文件的。您可以创建以部署概要文件的单一目的来创建插件，或者这个概要文件可以添加到一个现存的插件中，在这里它仅仅是众多构件中的一个。另外还有伴随这个概要文件的代码，在运用概要文件的位置提供模型的运行操纵（如果需要，再次操作）。
在 Rational Software Developer 或者 Rational Systems Developer
（V7.0.5 或者更新的版本）中配置这个概要文件的单键部署的最简单方法是，在 Project Explorer
中的概要文件中使用 Generate Profile Tooling菜单条目。即使没有其它工具，而仅仅需要为概要文件构建一个插件所有人，这个向导仍然是实现它的最简单的方法：只需要清除所有的工具选项和一个适当配置插件的支持，这个概要文件就会产生。这个板块剩余部分覆盖了插件部署的手工安装。它在下面这些情形下十分有用：
- 这个概要文件构建在 V7.0 或者 7.0.0.x 版本其中一个中，这样 Generate
Profile Tooling 菜单条目就不能使用。
- 这个插件已经存在。也许它已经包含了这个概要文件。您需要构建一些手工的调整和需求来理解语境以及同步所包含的内容。
定位
概要文件存储在插件中的实际物理位置，这个工具并没有指令；这取决于您来决定特殊插件的最佳地址结构。这个概要文件可以存储在插件根目录尽可能高的位置，或者其它子文件夹中。那里可能有一个或者多个概要文件。这个文件夹还可以包含文件以及非概要文件的文件夹。
既然说了，这个工具使用了这样的惯例，工具创建概要文件存储在插件根目录中概要文件的子文件夹中。这对用户创建的概要文件来说十分有用。
注释：这仅仅是一个惯例。它并不是要求或者强制的。
这个概要文件应该包含在二进位的构建中，它设置在 build.properties 文件中。您可以将它手工设置在那个文件中，或者通过
Plug-in 编辑器 （使用 Plug-in 编辑器在一个单独的部分中涉及到）。您要么可以分别具体化每个概要文件，要么只需要包含整个包括概要文件的文件夹。
列表 1 是一个 build.properties 文件内容的例子 （它假设这些概要文件存在于概要文件的文件夹中）。
列表 1. build.properties 文件
bin.includes = plugin.xml,\
plugin.properties,\
<some file>,\
profiles/,\
<some file> |
这个定义概要文件位置的行是粗体显示的。
附属关系
托管这个概要文件的插件将需要对 org.eclipse.gmf.runtime.emf.core
和 com.ibm.xtools.uml.msl插件的附属关系。如果这个概要文件要使用基于
Java 的系统规定参数，那么它将需要与org.eclipse.emf.validation插件的附属关系。
注册一个路径映射
不管这个概要文件储存在插件中的什么位置，这个位置应该有一个定义的路径映射。这个路径映射可以通过插件的
plugin.xml 文件来注册。
列表 2 显示了一个例子。
列表 2. 路径映射元素
<extension
id="somePathmapExtensionId"
name="somePathmapExtensionName"
point="org.eclipse.gmf.runtime.emf.core.Pathmaps">
<pathmap
name="MY_SAMPLE_PROFILES"
path="profiles">
</pathmap>
</extension> |
这个扩展点是 org.eclipse.gmf.runtime.emf.core.Pathmaps。您可以选择这个扩展的id和名称。这个路径映射元素有两个属性：名称和路径。这个名称将会在其它很多地方引用，它也应该是唯一的。它还表明了所有者和目的。这个
路径是一个开始于插件根目录的相关路径。
这个 plugin.xml 文件还可以定义指向其它插件中位置的一个路径映射。在那种情况下，这个路径元素还有
另一个属性：插件，如列表 3所示。这个插件属性值就是参考参见的名称，没有版本信息。
列表 3. 路径映射插件的属性
<extension
id="somePathmapExtensionId2"
name="somePathmapExtensionName2"
point="org.eclipse.gmf.runtime.emf.core.Pathmaps">
<pathmap
name="MY_SAMPLE_PROFILES_2"
plugin="com.mycompany.myproduct.myplugin"
path="profiles">
</pathmap>
</extension> |
注册一个概要文件
这个概要文件本身还可以通过 plugin.xml 文件来注册。列表 4显示了一个使用来自先前部分的路径映射MY_SAMPLE_PROFILES的例子，有三个概要文件
（MyProfileA, MyProfileB, and MyProfileC） 部署在这个插件的概要文件子文件夹中。
列表 4. 带有三个概要文件的 plugin.xml 文件
<extension
name="someProfileExtensioName"
point="com.ibm.xtools.uml.msl.UMLProfiles">
<UMLProfile
id="MyProfileA"
name="%MyProfileA.name"
path="profiles/MyProfileA.epx"
required="false"
visible="true">
</UMLProfile>
<UMLProfile
id="MyProfileB"
name="MyProfileB"
path="profiles/MyProfileB.epx"
required="false"
visible="true">
</UMLProfile>
<UMLProfile
id="MyProfileC"
name="%MyProfileC.name"
path="pathmap://MY_SAMPLE_PROFILES/MyProfileC.epx"
required="false"
visible="false">
<LegacyProfileVersion
description="%MyProfileC.3.description"
migrationNotice="%MyProfileC.3.migration"
version="http:///schemas/MyProfileC/_UZU6IL2lEdyr3qYLlwtaSA/3">
</LegacyProfileVersion>
</UMLProfile>
</extension> |
这个扩展点就是 com.ibm.xtools.uml.msl.UMLProfiles。您可以选择这个扩展的id和名称。这个
UMLProfile元素拥有以下这些属性： id，名称，路径，需求的，以及可见的。
这个id应该是唯一的，从而确保可以程序化地找到这个概要文件的注册。我们可以对它使用一个
Java 包裹，或者类似<plug-in name>.<profile
name>的东西。
这个概要文件的名称将用作显示的作用。例如，当您应用概要文件时，它用在部署的概要文件的列表中。这个值就当作它本身来使用，除非它要放置在一个百分号（%）之前。这个百分数符号表示那个名称是固定的，可以从这个
plugin.properties 文件中查找到，将这个值的剩余部分作为属性文件的 关键码 （这是在 plugin.xml
中提供定位的字符串的标准 Eclipse 行为：在参考资源板块中阅读更多关于 Eclipse
的知识）。因此，在这个例子中的 MyProfileB 名称定义在 plugin.xml 文件中 （MyProfileB），而hile
the names for MyProfileA 和 MyProfileC 的名称定义在 plugin.properties
文件中，并使用了特殊的钥匙（分别是 MyProfileA.name 和 MyProfileC.name）。
您可以不同形式的数字具体说明这个路径，但是它对使用路径映射形式是很有利的。在这个例子中，所有三个概要文件都使用路径映射，尽管开始扫过一眼的时候它看起来并不是这么回事。MyProfileA
和 MyProfileB 的路径是根据这个插件的根目录来详细说明的（profiles/MyProfileA.epx
和 profiles/MyProfileB.epx）。然后，这个 profiles 文件夹是由
MY_SAMPLE_PROFILES 路径映射所覆盖的，因此这个工具将自动使用这个路径映射。MyProfileC
的注册更加明确：它直接陈述了这个路径映射 （pathmap://MY_SAMPLE_PROFILES/MyProfileC.epx）。
您不应该使用这个 required 标识。如果它详细指定了，这个值就应该设置为
false（不管怎么说这是默认的）。还可能有一些极端的绝对需要使用这个标识的例子，但是应该用极端的警告来处理。基本说来，如果它设置为
true, ，这个标识就会告诉这个工具自动将那个概要文件应用到任何没有应用它的模型中。
这个 visible 标识将指示这个工具，当您应用概要文件时，不管概要文件是否显示在部署的概要文件中。这个默认值是
false 。这个值显然是取决于这个意图的：如果这个概要文件仅仅程序化地应用，那么这个值应该是
false ，否则它就是 true。
这个 LegacyProfileVersion
子元素（在这个例子中是 MyProfileC 文件的） 注册版本 3作为这个概要文件的遗留版本。这个遗留版本在下面的情形中被复核：
- 当您应用这样一个概要文件时，您可以看到这个概要文件的列表，可以从中选择应用（与简单地应用最新版本相反）。这个列表由最新版本
（也是默认选择的）和所有的注册遗留版本组成。
- 当您运用一个带有这样概要文件的模型时，并且这个工具检测到概要文件使用了旧的版本，这个旧的概要文件版本将会按照遗留版本再次复核。如果它是一个遗留版本，那么a）您将不会被提示在模型下载过程中迁移b）您将会被警告这是一个遗留版本如果这个用户尝试手工迁移它。当然，您当然可以继续进行并迁移。
这个 LegacyProfileVersion
仅仅在 Rational Software Modeler 或者 Rational Systems Developer
V7.0.5 或者更新版本中可以利用。使用这个机制，这个工具会伴随产生一个概要文件：Ecore 概要文件与遗留版本一起注册，与
Rational Software Architect V7.0.0.x 中的可利用版本相对应。同时，LegacyProfileVersion仅仅在概要文件没有需要的原型时被支持。
这个 plugin.xml 文件还定义了一个位于其它插件中的 UML Profile。在那种情况下，这个
UMLProfile 元素拥有另一个属性： bundle。这个捆属性的值与参考插件的名称一样，没有版本的信息，如列表
5所示
列表 5. bundle 属性
<extension
name="someProfileExtensioName2"
point="com.ibm.xtools.uml.msl.UMLProfiles">
<UMLProfile
id="AnotherProfile"
name="%AnotherProfile.name"
path="profiles/AnotherProfile.epx"
bundle=”com.mycompany.myproduct.otherplugin”
required="false"
visible="true">
</UMLProfile>
</extension> |
利用这个 New Plug-in Project 向导和 Plug-in 编辑器
这个 New Plug-in Project 向导和 Plug-in 编辑器是 Eclipse 概念，因此可获得更多关于这个话题的详细情况，请参见参考资料板块。唯一的概要文件－特殊信息是注册路径映射和概要文件的精确延伸，正如先前部分中所描述的。然而，由于完整性的原因，这个板块将提供一个如何利用向导创建一个插件项目的简短概述，然后是如何利用这个
Plug-in 编辑器修改 plugin.xml 文件。
要调用这个 New Plug-in Project 向导，点击 File > New >
Project，然后选择 Plug-in Development组中的 Plug-in
Project，如图 8所示。
注释：要使用这个插件开发性能，这个 Eclipse Plug-in Development
性能必须被激活。可以这样操作：
- 点击 Window > Preferences
- 点击 Workbench > Capabilities
- 点击 Eclipse Developer
- 选择 Eclipse Plug-in Development性能
图 8. 新项目
这个向导中域值（图 9）取决于这个项目想要的功能特性。例如，如果它仅仅是要获取这个概要文件，那么您可能就不需要
Java 支持。如果要获得一些程序化的操纵——或者如果它是一个将会拥有比简单的概要文件更多的程序化操纵的插件——那么您可能需要创建这个
Java 项目。这由您来决定在这个点上的设置。
图 9. 新建 Plug-in Project 向导
接下来的步骤是在这个插件中创建一个文件夹来获取概要文件。如果使用了命名惯例，它将是这个插件根目录地址的概要文件文件夹。当然，接下来的逻辑步骤是在那个位置创建这个概要文件——如果这个概要文件已经存在于另一个项目中——只需拷贝并移动它即可。
要在这个 lugin.xml 文件中注册一个路径映射和概要文件，您需要启动 Plug-in 编辑器。简单地双击这个
plugin.xml 文件，这个编辑器就会启动，提供插件的详细资料，如图 10所示。
图 10. Plug-in 编辑器
要在文本模式中操作，只需去到这个 Plug-in 编辑器的 plugin.xml 和
build.properties标签。这个句法与先前一些板块中的例子中所使用的是一样的。然而，您可能希望利用
Plug-in 编辑器中更高级的一些特性的优势。
这些附属关系具体地显示在 Dependencies 标签中。您可以通过 Extensions
标签注册路径映射以及概要文件。另外，确保 Build 标签上的文件夹包含的概要文件包括在二进位的构建中。
一旦这个插件已经准备好部署，您就可以利用 Eclipse的插件出口服务器展开它。如何调用这个出口服务器，显示在图
11中：
- 在 Navigator 视图中选择想要的插件
- 点击 File > Export
- 从这个列表中选择 Plug-in Development > Deployable
plug-ins and fragments 条目
图 11.输出插件向导
当然，这个插件可以是拥有它自己打包插件功能的大型应用软件的一部分。
Rational Software Modeler 和 Rational Software Architect
同时还在一定程度上支持开源。Eclipse UML2 格式 （文件的命名惯例是 <profile
name>.profile.uml） 可以直接用三种工具（*.emx）应用到模式中。您可以使用文件系统部署和插件部署。Rational
Software Modeler 和 Rational Software Architect 还向或者从这个
uml2 格式中提供输出和输入功能。
要获取更多关于开 UML2 格式的信息，请参见Resources部分。
Export
要调用这个 Export 向导，点击 File > Export > Other >
UML 2.1 Model。这个向导——显示在图 12中——将在具体的位置创建一个 *.profile.UML
概要文件。
重要的区域是 Recreate IDs（如果您打算维持 Rational Software
Architect 中的概要文件请关闭它，稍后再重新输出） 和 Export applied profiles（如果由任何
Rational Software Architect 概要文件应用到您的概要文件中，请关闭它）。
注释：在工作空间中浏览的能力只存在于 Rational Software Modeler
或者 Rational Systems Developer V7.0.5 以及更新版本，在旧版本中，您必须在文件系统中浏览。
图 12. 输出向导
输入
输入功能与输出功能十分相似：它只是以相反的方向操纵。要调用 Import 向导，点击 File
> Import > Other > UML 2.1 Model。这个向导将在具体的位置创建一个
*.profile.epx 文件。
为了定位的目的，概要文件使用标准的 Eclipse 机制。要定位这个概要文件，您需要在相同的位置提供定位文件作为概要文件它本身。定为文件的命名惯例与
Eclipse 的命名规则相同：
<profile file name>[_<locale>].properties |
例如，如果您创建这个概要文件 MyProfile.epx，那么这个默认定位文件的名称就是
MyProfile.properties。French 区域中定位的名称（举个例子来说）
就应该是 MyProfile_fr.properties。
自从对命名各种概要文件构建由了严格的规则之后，您可以利用定位机制来提供更多合适的显示名称。那些名称可以存储在默认的定位文件中，即使没有提供实际定位的计划。
下面概要文件中的字符串都是可定位的：
- 命名元素的名称（概要文件，原型，类，属性，列举，以及列举文字）
注释：限制名称是不能定位的
这个定位文件由 ID-value 对组成，使用标准的 Java 格式。命名元素的名称 ID 是元素的完全资格名称，带有::（两个直线）序列被双下划线
（__）所代替。任何空格字符都应该避免使用向前的斜线（\）字符。原型分类的 IDs 和限制消息都是它们自己的字符。
图 13 显示了一个例子。
图 13. 定位的概要文件结构的案例
原型 S1 有一个类别 MyCategory。它显示了只能拥有一个消息
IDMyMsgId。同样，请注意列举文字名称中的空格
（L 1）。列表 6显示了定位文件相应的内容：
列表 6. 定位文件
#Profile: MyProfileA
#Fri May 27 13:03:55 EDT 2005
MyProfileA__E1=E1
MyProfileA__S1__e1=e1
MyProfileA__E1__L\ 1=L 1
MyProfileA__S1=S 1
MyCategory=My Category
MyProfileA__E1__L2=L2
MyProfileA=My Profile A
MyMsgId=My Message |
Rational Software Architect 可以重新组装这个定位文件。当这个概要文件已经选择为
（Localize菜单条目）时，可以从弹出式菜单中调用这个行为。这个先前组装的文件将拥有合适的
IDs，并且这些值将与实际的字符串一样。
这个行为并不处理限制消息 IDs：它们将不被包括在先前组装的文件中。
这个部分是为您要在模型中提供一些种类的（额外的） 程序性操纵而预备的，概要文件就是应用在这个模型中，或者即使应用在程序性的概要文件中。它并不程序化地创建和修改概要文件本身；如果您计划这样做，请参考参考资料部分中地开源文献。
Rational Software Architect 主要不是为概要文件和原型支持公开展示它的 API。然而，有少许被展示的类在您创建概要文件的时候使生命变得更加简单。当然，自从这个工具建立在开源
Eclipse UML2 项目上之后，整个开源 API 都是自由可利用的。这个开源 API 有它自己的文献，但是这个部分将概述将对您有用的主要接口。
要执行这个程序化的操纵，您必须通过一个插件部署这个代码。最简单的结构应该在相同的插件中部署概要文件和代码。当然，这个概要文件仍需要利用这个位置的概要文件被注册。
要使用这些 APIs，这个插件将需要与各种其它插件的附属关系。请参见 部署 部分，从而获取更多关于如何创建一个插件依存性的细节。
Rational Software Architect
Specific APIs： UMLModeler
这个UMLModeler类可以用来获取这个概要文件。它是通过com.ibm.xtools.modeler.ui插件来提供的。
这个列表 7中的例子获得了来自这个定位由 MY_SAMPLE_PROFILES 路径映射提供的 MyProfileA
概要文件。如果这个概要文件还没下载，这个代码就强制加载（getResource
方法的 Boolean 参数）：假设这个 URI 函数提供的路径是正确的。
列表 7. UMLModeler 类
import java.util.List;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.uml2.uml.Profile;
import com.ibm.xtools.modeler.ui.UMLModeler;
...
...
...
Profile profile;
URI uri = URI.createURI("pathmap://MY_SAMPLE_PROFILES/MyProfileA.epx");
Resource resource = UMLModeler.getEditingDomain().getResourceSet()
.getResource(uri, true);
if (resource != null) {
List contents = resource.getContents();
if (contents.size() == 1 & contents.get(0) instanceof Profile) {
profile = (Profile) contents.get(0);
}
} |
请注意这个 URI 类是来自org.eclipse.emf.common.util包裹的。
Open
Source API – Eclipse EMF
概要文件系统规定参数作为 Java 类执行的必须扩展这个
org.eclipse.emf.validation.AbstractModelConstraint
类。它是由 org.eclipse.emf.validation 插件提供的。
这个函数覆写的是：
public IStatus
validate(IValidationContext
ctx)
变量 （ctx） 可以用来创建返回的状态对象。这个
IValidationContext 接口定义了 createFailureStatus
和 createSuccessStatus
方法。
Open
Source API: Eclipse UML2
对于开源 UML2 API 完全文献，请参见参考资料部分。
下面的部分相当于主要接口，当您程序化处理概要文件时可能会有兴趣。每个部分都会列出主要的相关方法。这个部分并对于开源
API 来说并没有详尽的资料，但是为您指出了必须的 API 的正确方向。
这个部分列出的所有的类和接口都是由 org.eclipse.uml2.uml 插件提供的。
列表 8. org.eclipse.uml2.uml.Package
EList<EObject> applyProfile(Profile profile);
ProfileApplication createProfileApplication();
EList<Profile> getAllAppliedProfiles();
EList<ProfileApplication> getAllProfileApplications();
Profile getAppliedProfile(String qualifiedName);
Profile getAppliedProfile(String qualifiedName, boolean recurse);
EList<Profile> getAppliedProfiles();
ProfileApplication getProfileApplication(Profile profile);
ProfileApplication getProfileApplication(Profile profile, boolean recurse);
EList<ProfileApplication> getProfileApplications();
boolean isProfileApplied(Profile profile);
EList<EObject> unapplyProfile(Profile profile); |
列表 9. org.eclipse.uml2.uml.Element
boolean addKeyword(String keyword);
EObject applyStereotype(Stereotype stereotype);
Stereotype getApplicableStereotype(String qualifiedName);
EList<Stereotype> getApplicableStereotypes();
Stereotype getAppliedStereotype(String qualifiedName);
EList<Stereotype> getAppliedStereotypes();
Stereotype getAppliedSubstereotype(Stereotype stereotype, String qualifiedName);
EList<Stereotype> getAppliedSubstereotypes(Stereotype stereotype);
EList<String> getKeywords();
Stereotype getRequiredStereotype(String qualifiedName);
EList<Stereotype> getRequiredStereotypes();
EObject getStereotypeApplication(Stereotype stereotype);
EList<EObject> getStereotypeApplications();
Object getValue(Stereotype stereotype, String propertyName);
boolean hasKeyword(String keyword);
boolean hasValue(Stereotype stereotype, String propertyName);
boolean isStereotypeApplicable(Stereotype stereotype);
boolean isStereotypeApplied(Stereotype stereotype);
boolean isStereotypeRequired(Stereotype stereotype);
boolean removeKeyword(String keyword);
void setValue(Stereotype stereotype, String propertyName, Object newValue);
EObject unapplyStereotype(Stereotype stereotype); |
注释：这个列表还包括相关的关键字方法。关键字并不真的是一个概要文件概念，但是它们通常被用作一个轻量型方法，可以标记元素而不是原型。
列表 10. org.eclipse.uml2.uml.Profile
EObject create(Classifier classifier);
ElementImport createMetaclassReference(PackageableElement importedElement);
PackageImport createMetamodelReference(org.eclipse.uml2.uml.Package importedPackage);
Stereotype createOwnedStereotype(String name);
Stereotype createOwnedStereotype(String name, boolean isAbstract);
EPackage define();
EPackage getDefinition();
ENamedElement getDefinition(NamedElement namedElement);
ElementImport getMetaclassReference(PackageableElement importedElement);
EList<ElementImport> getMetaclassReferences();
PackageImport getMetamodelReference(org.eclipse.uml2.uml.Package importedPackage);
EList<PackageImport> getMetamodelReferences();
EList<Extension> getOwnedExtensions(boolean requiredOnly);
Stereotype getOwnedStereotype(String name);
EList<Stereotype> getOwnedStereotypes();
EList<org.eclipse.uml2.uml.Class> getReferencedMetaclasses();
EList<Model> getReferencedMetamodels();
boolean isDefined();
|
列表 11. org.eclipse.uml2.uml.Stereotype
Extension createExtension(org.eclipse.uml2.uml.Class metaclass, boolean isRequired);
Image createIcon();
EList<org.eclipse.uml2.uml.Class> getAllExtendedMetaclasses();
EClass getDefinition();
EList<org.eclipse.uml2.uml.Class> getExtendedMetaclasses();
EList<Image> getIcons();
Profile getProfile(); |
列表 12. org.eclipse.uml2.uml.util.UMLUtil
public static Element getBaseElement(EObject stereotypeApplication);
public static Profile getProfile(EPackage definition);
public static Profile getProfile(EPackage definition, EObject context);
public static Stereotype getStereotype(EObject stereotypeApplication); |
下面是最佳实践的列表：
- 保持概要文件和模型在单独的位置。如果可能的话，使它们 保持在单独的变更管理生命周期中。
- 通常使用路径映射，不管是什么部署类型（文件系统与基于插件的系统）。
- 概要文件应该被看作是工具的延伸，而不是建模构件。
- 保持这个概要文件规模受到控制。每次您保存概要文件的时候，就会在这个文件中创建一个新的版本。打开一个拥有10个版本的概要文件比只有一个版本或者模型的概要文件要复杂得多。概要文件中的版本数量可以深刻反映这个应用软件的性能。利用the压缩选项来减少这个概要文件的规模。您还可以不时地发布这个概要文件，但是要注意所产生地后果：它创建一个阻止某些变更的检验点，那个版本不能被发布，等等。在
变更管理部分还有更多关于这个话题的详细信息。
- 不要对一个生产模型应用一个非发布概要文件。非发布概要文件应该仅仅运用到测试模型中来测试概要文件本身。一旦这个概要文件被释放，所有的非发布版本都会被删除（除最后的获得被发布标记的概要文件之外），导致迁移过程中使用模型中数据的丢失。
- 不要给您的客户提供非发布概要文件，除非您明确地说明这样的概要文件只能用来示范或者测试目的，并且迁移到官方的（发布）版本将导致数据的丢失。
- 当开发一个插件概要文件时，创建一个带有相同名称的路径映射，从而在开发（IDE）和运行（目标）环境中指向同一个位置。更适宜的方法是，路径映射应该为了运行环境，在开发环境和插件的
plugin.xml 文件中被定义为一个用户路径映射（通过这个 Preferences）。那样，这些模型就可以轻松地在两个环境中共享。
- 在 Rational Software Modeler 或者 Rational Systems
Developer 中，您应该使用 Generate Profile Tooling
选项来创建插件，如果您用那种方法来部署您的概要文件的话。
下面是这篇文章中详述的产品版本的特殊概要文件的已知问题列表。它并没有列出 Rational Software
Modeler 和 Rational Software Architect 中其它的普通问题，尽管它们可能（通常会）
也会影响概要文件。对于那些，请咨询您所使用的特殊 Rational Software Modeler 和
Rational Software Architect 版本的发布注释。
- 在非发布版本之间可能会存在迁移的问题。
- 相同元素之间的多重普遍化关系 （例如，原型
S1
具体化了原型 S2两次） 将会阻止概要文件在迁移情景下迁移：V7.0.5
概要文件装载在V7.0.0.4 或者 V7.0.0.5中。要处理那个问题，清除无关的普遍化关系，保存并压缩这个概要文件，从而清除旧的已损坏概要文件版本。如果
当它还拥有这样的普遍化关系时发布概要文件 ，那么它将被手工编辑，或者利用 EMF 编辑器来清除发布概要文件版本中的无关普遍化关系。
- 这个工具将允许您挑选任何文件作为一个原型图标或者图像文件。确保它的确是一个有效的支持的图像文件完全是您的（这个概要文件的作者的）
责任。
在这个系列中，您已经学习如何在 Rational Software Architect 中创建和部署
UML 概要文件。
UML 概要文件使您能够为了不同的目的扩展 UML 模型。实质上，那意味着这个工具的行为也是扩展的。Rational
Software Architect 提供了广泛的 UI 来构建和使用概要文件。它们从简单的概要文件开始排列，提供一些额外的陈述功能，一直到通过插件部署的复杂的概要文件，并伴随着充分利用这个概要文件的模型扩展优势的代码。
学习
获得产品和技术
讨论 | 
