📄 umlcomoad002.htm
字号:
<head><meta NAME="´¡ãÍâÈí¼þ¹¡è³Ì" Content="Author:Asia Alien"><title>UML元元模型（中文）</title><meta http-equiv="Content-Type" content="text/html; charset=gb2312"><link REL="stylesheet" HREF="../../newcss.css" TYPE="text/css"></head><body><b><p><font size="5"><img border="0" src="i/umldilver.gif" WIDTH="606" HEIGHT="15"></font></p> <p><font size="5"><a name="1">1. 服务说明</a> <font size="5" face="宋体"><a href="umlcomoad001.htm">返回目录</a></font></p> </font><font face="Arial" size="5"><p></font><font size="5"><a name="1.1">1.1 概述</a></p> </font><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.1">1.1.1 背景</a></p> </font> </b><p>本文档为瑞理公司（Rational）等组织向对象管理小组(CORBA) OADTF RFP-1 提交的文档资料的一部分。CORBA小组成员可以从网点 <i><a href="http://www.omg.org/member/doclist-97.html">http://www.omg.org/member/doclist-97.html</a> </i>处获得全部的提交资料(文档ad/97-01-01到ad/97-01-14)。在网点 <a href="http://www.rational.com/UML"><i>http://www.rational.com/UML</i></a>处可获得UML语言的最新资料。请把您对该文档的意见通过电子邮件发送到以下地址：UML<i>_feedback@rational.com<font face="Times New Roman"></p> </font> </i><p>RFP的一个主要的目标是实现面向对象的可视化工具之间的相互协作，进而推动软件工业的发展。OA&D工具定义了一些支持工具协作的接口。</p> <p>但要想使模型信息在不同工具之间的交换具有意义，各种工具的语义和模型表示应该基本一致。在文档《<i>UML语义</i>》中定义的元模型说明了UML语言的语义和表示法。文档《<i>UML到CORBAIDL的映射</i>》讨论了如何把UML模型转换成对应的IDL模型。本工具文档中定义的IDL模型大部分都是从UML1.0版元模型直接对应过来的。</p> <p>提交给CORBARFP的大多数文档都是首先定义一些接口，然后解释接口中包含的语义概念。本文档的结构稍微有一些不同。因为UML语言的语义非常复杂，我们把这部分内容放在文档《<i>UML语义</i>》中讨论，因此本工具文档中不包括语义内容。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.2">1.1.2 工具共享的方案</a></p> </font> </b><font face="Times New Roman"><p></font>OAD任务小组的主要工作是实现“OA&D工具之间的语义协作”。因此RFP在文档的5.5.2节指出：“提交文档必须定义支持工具访问其他工具产生的模型或模型元素的接口。模型访问工具可以是一个<i>输入</i>工具，也可以是<i>连接</i>工具，或者两者都是。”</p> <font face="Times New Roman" size="3"><p><img border="0" src="i/image51.gif" WIDTH="479" HEIGHT="359"></p> </font><p>如图所示，对象模型的共享有三种可行的方案：</p> <b><p>库（Repository）－</b>各种工具连接同一个库，通过库访问模型。元对象工具（MetaObject Facility，简称MOF）可以作为这样的库，尽管这并不需要持久性。MOF工具无法指定依从UML的工具的基础模型的丰富语义，因此从工具模型到MOF模型的转换与具体的实现紧密相关。提交文档没有对库方式进行过多的讨论，但在文档《<i>UML语义</i>》的附录中有关于工具模型到MOF模型的转换的内容。</p> <b><p align="JUSTIFY">模型传送（Model Transfer）－</b>不同工具都支持同一种流格式，通过流（也可以是文件）来交换模型信息。RFP把这种流格式称做“输入工具”。对于没有在CORBA环境下实现的工具，为了提供一个路径，就必须定义这种接口。在文档《<i>依从UML的交换格式</i>》中定义了这种流格式；该格式是CDIF主题领域定义的。这种格式的流可以通过OA&D工具的接口内部化为UML模型元素或者从UML模型元素外部化而来。</p> <b><p align="JUSTIFY">模型访问（Model Access）－</b>不同工具之间逐部分交换模型信息。RFP把这种方法叫做“连接工具”。虽然对于共享整个模型，采用模型访问的方案可能效率并不是最好，但这种方法可以允许最大限度的语义协作，对客户程序更有帮助。文档中定义了一些支持模型访问的IDL接口。还定义了一些支持把流内部化为模型或从模型外部化为流的OA&D工具接口。</p> <p>总而言之，OA&D工具定义了支持模型访问和模型传送方式的接口。这些接口与文档中的UML元模型是一致的。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.3">1.1.3 OA&D工具的典型用户</a></p> </font> </b><p>对于模型访问方式，下列客户可以使用OA&D工具：</p> <blockquote> <b><p align="JUSTIFY">传统的CASE工具－</b>传统的计算机辅助软件工程工具（Computer Aided Software Engineering tools）可以通过OA&D工具接口共享模型<b>。</p> <p align="JUSTIFY">制图/动画工具（Drawing/Animation Tools）－</b>OA&D工具中包括支持模型绘制和<b>动画</b>的详细接口。传统的CASE工具通常把应用程序的模型和模型的图形表示合在一起。分别维护模型和模型的图形表示可以使应用程序的图表，<b>动画</b>和文档部分分开。</p> <b><p align="JUSTIFY">报告/代码生成工具（Report/Code Generators）－</b>各种报告和代码的生成工具可以通过OA&D工具的接口，访问模型和模型的特征值。</p> <b><p align="JUSTIFY">商业对象工具（Business Object Facility）－</b>虽然BOF的定义时刻在发展，但BOF可以利用OA&D工具为商业对象的逻辑和物理特性（例如，UML的<i>组件</i>和<i>构件</i>）及它们之间的关系建模。BOF可以使用文档定义的对象元模型以及模型的扩展机制来存储模型，把元对象工具作为存储商业对象实现的库。</p> </blockquote> <p>文档的提交人员都认为为用户定义详细的接口是实现工具协作的重要内容。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.4">1.1.4 实例证明</a></p> </font> </b><p>文档定义的规范在技术上是完全可行的。例如，瑞理公司开发的可视化建模工具 Rational Rose? 虽然不是一个CORBA环境的工具，也实现了不少特性。Rose 4.0 版中定义了一套“Rose扩展接口”（叫做“Rose Script”），包括OLE automation server格式和 Visual Basic for Applications (VBA)格式。Rose 4.0 版中定义了一套“Rose 扩展接口”，该扩展接口由OLE automation server 和Visual Basic for Applications (VBA) scripting接口（即Rose Script）共同提供。这些接口类似于文档中定义的接口。有几个报告和代码生成工具已经使用了Rose Script，包括一个IDL的代码生成器。尽管Rose Script并不是IDL的，但这些都是Rose“服务”的“客户”。</p> <p>如果一些工具要实现用于信息交换的专利格式，我们认为CDIF（CASE工具数据交换格式/EIA）是比较好的选择，会得到软件工业界的广泛认可。CDIF格式的语法和编码标准是本文档的基础，已经有许多工具实现了这一标准。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.5">1.1.5 存在的问题</a></p> </font> </b><p>这个文档被定为 1.0 beta 1版本，是因为在工具定义中还存在着许多问题。这些问题将在1997年4月以前，向CORBA提交的修改文档中得到解决。RFP包括的范围太广，它试图同时实现语义的标准化和解决工具问题。然而，对语义的长期讨论使得一些工具问题迟迟得不到解决。如下列问题：</p> <blockquote> <p align="JUSTIFY">虽然UML元模型只是一个语义模型，还没有对工具上的问题进行修改，但作为向RFP的初次提交还是可以的。在预期于1997年4月完成的修改文档中，应该定义一个独立的工具元模型作为OA&D工具的基础。UML元模型中还缺少一些工具标准所必需的行为（操作）。</p> <p align="JUSTIFY">为了防止模块之间的循环依赖，工具中的IDL模块一般规模都很大，而且结构也不是很好。如果不存在一个独立的工具元模型，定义相互松耦合并且规模很小的模块是很难的。对接口的依赖关系的要求不同，将导致不同的模块集。</p> <p align="JUSTIFY">工具定义中的IDL模块与文档《<i>UML语义</i>》中的元模型并不完全一致。这是因为就在向CORBA小组提交该文档之前，我们对UML的语义作了一些修改。IDL模型在有关<i>状态</i>和<i>名字</i>的内容上与UML元模型略有出入，还有我们把元模型中的模式（pattern）改成了协同（collaboration）。</p> <p align="JUSTIFY">在这篇文档中，我们只说明了工具的一部分用法。我们确信UML元模型中的所有语义对用户都是有用的，因此我们为所有的语义都定义了相应的接口。在修改版的文档中，我们将讨论工具的其他一些用法。</p> <p align="JUSTIFY">目前，工具接口所声明的异常泛指所有的异常情况，还没有具体化。</p> <p align="JUSTIFY">我们还需要更深入的探讨局部模型传送的语法。例如，如果一个包（package）中包含与其他包中的类的双向关联，那么输出这个包就有可能产生问题。在文档《<i>依从UML的交换格式</i>》中涉及到了这个问题。</p> <p align="JUSTIFY">虽然UML1.0版的元模型定义了表示符号位置的类及其属性，但并没有制订符号布局的标准。因此，无法保证工具实现的图表设计。</p> <p align="JUSTIFY">目前的类型转换还没有使用国际化的字符串。</p> </blockquote> <p>文档的作者欢迎各位提出宝贵意见。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.6">1.1.6 工具的性能</a></p> </font> </b><p>采用<i>依从UML的交换格式</i>，模型的传送可以不必实现OA&D工具，例如在非CORBA的环境中。</p> <p>本工具文档定义了支持模型访问和模型传送服务的接口，这些接口基本上有两层性能：</p> <font face="Times New Roman"><p></font>1) 模型传送（Model Transfer）－0节中定义的“抽象”接口。</p> <font face="Times New Roman"><p></font>2) 模型访问（Model Access）－上述接口，及0节中定义的“详细”接口。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.7">1.1.7 其他所要的特性</a></p> </font> </b><p>实现OA&D工具的开发人员还可以发现许多有用的特性，如（在内部化/外部化过程中间的）过滤器（filters）和查询（queries）。工具开发人员还应该考虑定义和实现其他有价值的特性。</p> <b><font face="Arial" size="4"><p></font><font size="4"><a name="1.1.8">1.1.8 简介OA&D工具接口的组成</a></p> </font> </b><p>本节讨论工具的接口类型。大部分的接口直接对应于UML的元模型。还有一些接口是从CORBA服务中继承来的。</p> <b><font face="Arial"><p></font><a name="_Toc392905059">1.1.8.1 对应于UML元模型的接口</a></p> </b><p>作为一个基本的前提，OA&D工具的用户应该能够随意查看和管理一个模型。因此，我们为整个模型定义了接口。</p> <p>文档《<i>UML到CORBAIDL的映射</i>》中定义了可以直接从UML元模型导出的IDL模块的基本构件，主要包括：模块，界面，类型定义，枚举，异常，结构，常量，联合，属性和操作。</p> <p>另外，还定义和使用了几个转换模式：</p> <blockquote> <i><p>集合（Collections）</i>－集合定义于使用集合服务的特定关联上。集合与集合服务的关系将在后面讨论。</p> <i><p>关键字/限定关系（Keys/Qualifiers）</i>－添加了按名字查找的操作。</p> <i><p>关联类（Association Classes）</i>－继承于LifeCycle。</p> </blockquote> <b><font face="Arial"><p></font><a name="_Toc392905060">1.1.8.2 内部化和外部化</a></p> </b><p>首先明确那些用于工具间传送，表示局部模型的抽象“块”。主要有如下UML元素：系统，模型，包和图。</p> <p>如外部服务（Externalization Service）中定义的那样，在工具的实现中，这些块都是“可流动的”，可以从<i>内部化</i>进工具和从工具<i>外部化</i>而来流的格式可以是文档《<i>依从UML的交换格式</i>》中定义的CDIF。小一些的块和单个模型元素也可以通过OA&D工具的其它接口在工具之间交换。</p> <p>在内部化/外部化过程中发生的传送“转换”的语义在文档《<i>依从UML的交换格式</i>》中讨论。文档还讨论了名字域和对复用有重要意义的局部模型传送等概念。转换的语义并不影响工具接口的定义。</p> <p>工具与外部服务的关系在以后深入讨论。</p> <b><font face="Arial"><p></font><a name="_Toc392905061">1.1.8.3 生命周期服务</a></p> </b><p>工具定义了工厂（Factories）及其它的一些生命周期接口。这在以后详细讨论。</p> <b><font face="Arial"><p></font><a name="_Toc392905062">1.1.8.4 扩展</a></p> </b><p>明确关键的UML扩展机制，<i>特征值（tagged value）</i>，是有用处的。通过工具的接口，可以使用特征值把任意数目的未注册、未说明的索引包括到模型中。这可以作为一种结合机制，例如，在模型中添加从对象模型构件到构件实现的索引。</p> </body> ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -