正式而明确地定义ODX数据模型：统一建模语言(UML)的介绍和使用

来源：ASAM_AE_MCD-2_D_BS_ODX_V2-2-0.pdf
第六章：INTRODUCTIQNTO AND USE OF THE UNIFIED MODELINGLANGUAGE (UML)

6.1通用特性

统一建模语言(UML)用于正式而明确地定义ODX数据模型。它通过图形化的数据模型图增强了可读性，本节对UML做了一个简短的介绍。在ODX数据模型中只描述了UML的那些方面。具体地说，从大量可用的UML图中，我们只应用类图进行数据建模

6.2类图

6.2.1类

UML中的中心建模元素是一个类。类表示一组类似对象。通常，一个类可以被实例化多次。类的每个实例都称为对象。类具有属性(定义这些对象的属性)和方法(定义对象可以执行的操作)。对于ODX方法是不相关的，不被使用。
下图显示了UML表示法中的类及其属性。类由一个最多有三个字段的矩形表示。顶部字段包含类的名称，例如PERSON。第二个字段包含类的属性，例如名称、年龄、职业和ID。方法在可选的第三个字段中定义。属性字段并不总是显示在ODX数据模型图中。因为方法字段在ODX数据模型中没有使用，所以它从不显示。

属性由属性名(如name)和属性的基数(如[1]或[0…1])和属性类型组成，例如字符串。此外，可以指定属性的默认值。这样的默认值跟随属性的类型描述符，并由符号"="与之分隔。
在名称前面用《attr》构造型指定的UML属性被实现为XML元素的XML属性。没有这个构造型的UML属性被实现为XML元素的XML子元素。在整个ODX数据模型中，类名和属性名都用大写字母书写。

6.2.2继承关系

类可以从其他类继承属性。在上图中，从PERSON类派生出一个新类SCHOOLKID。这意味着SCHOOLKID类隐含地拥有与PERSON相同的所有属性，以及那些专门为新SCHOOLKID类定义的属性，例如年级。PERSON被称为父类;SCHOOLKID被称为继承关系的子类或子类。因为子类向超类添加了更多的细节，因此更具体，继承关系通常被称为“专门化”。
继承关系可用于构建任意深度的继承树。这样一个树中的类继承了继承树中所有祖先(父类、祖父母类等)的传递闭包中的所有属性。

6.2.3聚合和组合关系

除了继承关系之外，一对类还可能具有聚合或组合关系。如果一个类的对象包含在另一个类的对象中，则使用聚合或组合关系。它们被绘制成在包含类的末尾带有菱形的线。组合关系的菱形已填充:聚合的菱形未填充。
这两种关系之间的区别如下:组合关系中包含的元素是包含元素的一部分:如果包含元素被删除，则包含的元素不再存在。因此，复合意味着一个对象可能只包含在另一个对象中。聚合关系是一个共享对象。这意味着，多个对象可能合并同一个对象。因此，即使聚合对象被删除，聚合对象仍然存在。下图给出了定义了组合和聚合关系的三个类的示例。一个人可能有两只脚(两个物体类型的脚)。脚通常是它的主人不可分割的一部分。因此，使用组合关系。如果人不再存在，脚也不存在。相反，一个人也可能有很多外套。然而，一件外套通常可以被多人使用，它的寿命周期通常独立于其穿戴者的寿命周期。因此，人和大衣之间的关系被建模为聚合关系。

组合关系可能带有基数，下图的基数在UML中很常见

可能会指定更具体的基数，例如5或2…8
基数读取如下:要指定类PERSON的多少个对象与类FOOT的一个对象相关，关系的PERSON末尾的基数被使用。反之亦然，使用关系末尾的基数。这个经济效益以下结果:一个对象类的脚可能与一个对象的类人(一只脚总是属于一个且只有一个人),一个对象的类人应与两个对象类的脚(一个人通常有两英尺)。

6.2.4协会的关系(ASSOCIATION RELATIONSHIPS)

在ODX数据模型中使用的第三种类关系是关联关系。它是在两个类之间画的一条简单的线。关联关系的语义比组合关系弱。在这里，两个对象具有“平等的权利”。关联关系打开相关对象属性的可见性。下图给出了一个关联的示例。在关联中，一个类的对象可能与另一个类的一个或多个对象相关。为了限制两个类之间相同类型的关联的数量，使用基数的方式与使用组合的方式相同。

关联可以携带一个名称，并且可以在每个关联结尾提供一个角色名称。在上图中，PERSON类在与SCHOOLKID的关系中携带角色MOTHER。基数表明SCHOOLKID只有一个MOTHER，而PERSON可以是MOTHER，也可以是任意数量的SCHOOLKID。
一个关联关系可以在一个关联端带箭头。这允许指定哪个对象可以实际访问另一个对象的属性。

6.2.5关联类(ASSOCIATION CLASSES)

关联类是关联和类的混合体。通常，它们可以被解释为带有自己属性(和方法)的关联。它们的绘制方式就像一个类符号的关联，用虚线连接到关联线的中心，见下图。
在下图中，一个被雇主雇佣的人的例子被建模为一个关联类。在这里，雇佣关系有一个名为SALARY的属性。这份特定于工作的薪水显然不是一个人的财产。因为一个人可能有多种工资。此外，如果这个人失业了，工资可能就不存在了。它也不是雇主的财产，因为雇主有许多不同的雇员特有的工资。这是工资是雇佣关系的财产的最好证明

6.2.6接口(INTERFACES)

接口使对象的某些属性对其他对象可用。Interfaces是一种特殊的方法，用于将类的某些方面分组，并使其他类只依赖其中一个方面，而不是整个类接口符号看起来与类符号相同。它可以通过原型《interface》在符号的名称字段中与类区分开来，下图包含一个关于如何在模型中使用接口的小示例。类COMPANY实现了两个接口:雇员和竞争对手。被本公司雇用的人不会将本公司视为竞争对手，而与本公司竞争的公司也不会将竞争对手视为雇主。如果一个类实现了一个Interface，它会用一个虚线箭头来显示，类似于继承箭头。接口的测试类(例如PERSON)可以简单地使用关联或聚合来关联接口。知道tester类(PERSON)可能只使用在这个接口中定义的实现雇主接口的类的那些方面是很重要的。因此，一个公司也可以平等地由一个管理机构雇用一个人，因为后者也实行接口员工。

6.2.7约束(CONSTRAINTS)

UML允许对所使用的模型元素定义约束。一个经常使用的约束是两个关联(或聚合)之间的{xor}约束。它强制一个类的实例与一个或另一个关联类的实例具有关系，但从不同时同时具有这两个实例。下图显示了这样一个约束的示例。一个人可以同时穿两只鞋或两只靴子，但绝对不能同时穿两只鞋。

6.3映射到XML(MAPPING TO XML)

ODX交换格式的目标实现格式是XML。在这一段中，给出了如何将UML模型映射到XML语言元素的一个非常简短的概念。它并没有说它是完整的，但只是一个示例，可以简化对整个文档中给出的XML示例的理解。完整的XML映射规则和生成的XML模式将在第8节中描述。

一般适用下列规则:

1. 类通常映射到XML元素上。
2. 如果《attr》原型为UML属性定义，则类的属性映射到XML元素的XML属性上;如果没有定义原型，则映射到XML子元素上。如果定义了一个构造型《content》的UML属性，该属性就简单地映射到XML元素的内容上。
3. 通过组合或聚合关系连接到另一个类的类被映射到子元素上。在被包含类的目标基数为多个的情况下，将生成围绕子元素的包装器元素。如果分别在组合关系或聚合关系上定义了{nowrapper}-约束，包装器元素将被省略
4. 与其他类的关联被映射到对其他元素的XML引用上。已经为ODX定义了三种引用机制。分别通过原型《snref》， 《snpathref》和《odxlink》进行标记。有关这些参考机制的详细实现，请参阅第7.3.13节。
5. 在ODX中，属于继承层次结构的类在XMI中被映射，这取决于使用的UML继承关系原型。在ODX中使用的两个继承原型是《impl-child》和《impl-parent》。这两个原型都表示了6.2.2中定义的专门化。当使用《impl-child》构造型指定继承关系时，所有的子类型或子类型都在XML中指定;也就是说，每个子类型将有一个XML模式类型。当使用《impl-parent》构造型时，生成的XML元素带有一个名为xsitype的属性。它包含在特定实例中使用的子类型的名称。

根据这些规则，上图中的示例被映射到如下所示的XML文档上。包含根元素是为了满足XML的形状。

在整个文档中，使用了一些本节中没有解释的其他约束和构造型。其中包括:

《value-inherit》诊断层间继承;
《element-name》偏离了标准的命名模式，XML元素被命名为与它们对应的UML类相同的名称;
《import》描述从另一个诊断层导入数据;
{ordered}强制XML子元素的顺序是重要的，并且不能被任何兼容odx的工具改变;

有关映射到XML的更详细信息，请参阅第8节。