| 编辑推荐: |
| 本文来自于ibm.com，在一个较高的层面上描述了创建一个
NIEM IEPD 涉及的步骤。 |
|
如何使用 NIEM？
NIEM XML 数据模型提供公共对象的构造块。一个构造块可能处于一个非常细粒度的级别，比如 “个人姓名”
或 “生日”，也可能是一个更复杂的组件，比如 “拘捕” 或 “诉讼案件”。但是，NIEM 模型本身并不定义完整的信息交换消息，比如
“Arrest Report” 或 “Suspicious Activity Report”。它也不指定任何特定消息类型或
XML 文档的根元素。
要实际使用 NIEM，需要构建一个 IEPD。IEPD 从 NIEM 核心和域模型提取必要的元素，并扩展它们来创建一个信息交换。一个
IEPD 包含几个工件：
XML 模式定义在这个交换中使用的 NIEM 模型的子集，称为子集模式。
一个定义交换的根元素的模式，称为交换模式。
一个定义 NIEM 模型的扩展的模式，称为扩展模式。
交换文档，比如 UML 图表、叙述性说明和样例。
开发一个 IEPD
任何信息交换项目的首要任务都是收集并分析您的需求。NIEM 并不需要任何特殊的方法来定义需求，因此本文不介绍这个过程。事实上，本文假设您在实际创建您的
IEPD 之前，已经对想要交换的数据元素和用于组织这些元素的消息类型有所认识。
本文将从头至尾详细介绍一个简单示例，最后生成一个完整的 IEPD。这个示例案例研究报告将实现一个简单的涉及注册车辆的盗窃报告。假设当地司法机关将使用这个盗窃报告来通知有关各方（比如
Division of Motor Vehicles 或 City Bicycle Registration
Bureau）关于机动车和自行车的盗窃情况。在我的需求收集阶段，我已经收集了关于需要共享的数据的一般信息，并确定只需一种类型的消息：盗窃报告。在现实中，一个
IEPD 通常包含多个相关的消息类型。
由于 NIEM 的一个主要目标是数据互操作性，合理的做法是在从头创建一个新的 IEPD 之前考虑重用一个现有的
IEPD。NIEM 提供了一个 IEPD 交换所（clearinghouse），支持搜索由其他组织提交的
IEPD。参见 参考资料 获取到这个 IEPD 交换所的链接。
如果您不能找到一个符合需求的 IEPD，则需要构建一个。构建一个新的 NIEM IEPD 需要以下
5 步：
1.建模您的交换。
2.将您的交换映射到 NIEM 数据模型。
3.创建一个 NIEM 模型的子集以用于您的交换。
4.创建交换和扩展模式来描述您的自定义组件。
5.使用所有合适的工件来组装一个 IEPD。
本文将介绍步骤 1，本系列其他文章将介绍步骤 2 到步骤 5。即使您选择重用一个现有 IEPD，这个系列文章也可能有助于您理解您正在使用的
IEPD 的内容和结构。
理解 NIEM 模型
在为您的交换创建一个模型之前，理解 NIEM 数据模型的结构是很有用的。NIEM 定义了一些概念
— 比如类型、属性和关联 — 您可能已从其他数据建模范式中熟悉了这些概念。
NIEM 模型概念
类型 表示事物 —— 无论是有形事物还是无形事物。NIEM 模型中的一些最基本的类型是 PersonType、ActivityType、ItemType、LocationType
和 OrganizationType。还有数千种类型，它们使用不同的粒度水平。在其他建模范式中，类型可能称为类别
或实体。
属性（properities）是类型的特性（attributes）。它们本身可以拥有复杂的类型。例如，PersonName
是 PersonType 的一个属性，但它也可以拥有一个类型 PersonNameType，这个类型拥有自己的结构，包含
PersonGivenName、PersonSurName 等。
类型可以从其他类型派生出来并继承它们的属性，这类似于面向对象模型中的泛型（generalizations）。例如，ItemType
是一个泛型，派生出很多类型，包括 VehicleType、JewelryType 和 RealEstateType。
关联 指两种类型之间的关系。Incident 和 Person 之间可能有一个关联，Person
和 Location 之间也可能有一个关联。NIEM 中的关联独立于它们与之相关的类型。
角色 表示一种类型在一个特殊的上下文中可能拥有的临时从属关系。例如，在一个盗窃事件中，某个人可能充当
Victim、Subject 或 Witness 角色。
augmentations 是可以重用和共享的属性集。这些属性在 NIEM 域模型中经常使用，但在您的
IEPD 中则使用的少一些。
元数据 是关于一条消息的内容的信息，比如信息收集时间，信息可靠程度等。NIEM 在其模型中在相关数据到元数据之间进行特殊的供应。
XML 中的 NIEM 模型
NIEM 模型完全作为一组 W3C XML Schema 文档实现。XML 模式中的注释和引用用于表明某个事物是否是一个类型、一个关联等。幸运的是，您不必阅读
XML 模式文档本身来导航这个模型；NIEM 提供了一些工具来以更图形化的方式搜索和导航这个模型。
通常，NIEM 类型被实现为 XML Schema 复杂类型，属性为这些类型中包含的元素。清单 1
展示了如何使用一个 ActivityType 复杂类型来表示一个活动，ActivityIdentification
和 ActivityCategoryText 等属性被实现为子元素。
清单 1. XML Schema 中的部分
NIEM ActivityType 实现
NIEM 使用 XML Schema 扩展进行类型派生。清单 2 展示了一个更具体的活动 —AssessmentType
复杂类型 — 如何从 ActivityType 派生而来。
清单 2. XML Schema 中的
NIEM 类型派生
关联是特殊的复杂类型，包含对它们关联的类型的引用。清单 3 展示了如何实现一个人和一个活动之间的关联
—ActivityPersonAssociationType。所有关联类型都是 NIEM 核心 AssociationType
的直接或间接的扩展。
清单 3. XML Schema 中的
NIEM 关联类型
建模您的交换
NIEM 不需要您使用任何特殊方法学或图表类型来建模您的 XML 交换，甚至根本不需要您建模。但是，建模是
IEPD 设计中的一个重要步骤。建模过程能使需求具体化，最终结果为业务和技术用户提供了有帮助的文档。这个模型还充当
IEPD 创建过程中的后续步骤的有用输入。
选择一个模型范式
一个好的选择是 UML — 特别是 UML 类图表 — 因为 UML 概念可以轻松映射到 NIEM
模型概念。当然，您可以创建其他 UML 范式（比如用例图表和序列图表）来归档您的交换。本文主要关注类图表，因为它对
IEPD 开发流程最为关键。
最好首先独立创建您的初始模型，不要试图使其适应 NIEM 模型。只有避免受到 NIEM 方法的影响，您才能使您的模型更适合您的业务需求。在
IEPD 流程的后面的几个阶段，经常会对初始模型进行一些微小的有意义的修改来更好地适应 NIEM。但是，您的模型和
NIEM 模型之间总是有区别的。
类型和属性
本文篇幅有限，不能完整地介绍 UML 建模，因此本文主要关注特定于 NIEM 的指针。如您所料，NIEM
类型由一个类别图表中的类别表示。属性（properties）由类的特性（attributes）表示。
在我的示例案例研究中，我确定了几个需要交换的类 — 例如 Theft、MotorVehicle、Bicycle、Victim、Witness
和 TheftLocation。图 1 描述了这些类型及其属性。（查看 图 1 的文字版。）
图 1. 带有类型及其属性的初始 UML
模型
指定属性的数据类型时，使用 XML Schema 原始数据类型很有用，因为属性将最终在一个 XML
模式中表示，且如果您使用一个公共数据类型组，则可以更轻松地确定现有 NIEM 模型是否适合您的需求。表
1 列示了最常用的 XML Schema 数据类型。
表 1. 常用 XML Schema
数据类型
有些属性拥有一个有效值的枚举列表，也称为代码列表。代码列表值可以在 UML 模型中用注释描述，也可以记录在系统文档的其他地方。在我的示例中，为保持模型整洁，我仅仅将这些值列举为拥有一个数据类型
code。我将在这个 IEPD 流程的下一步骤中创建的映射电子表格中记录有效值。
泛型和角色
NIEM 模型使用泛型，在适当的时候，您应该在您的模型中使用它们。在这个案例研究中，MotorVehicle
和 Bicycle 都是可能失窃的财产的具体种类。因此，我决定添加一个更通用的 Property 类并从该类派生出
MotorVehicle 和 Bicycle。这样做的话，我只需定义一次 SerialNumber
等公共属性，还能通过允许 Property 类关联到 Theft 类来简化关联。
Victim 和 Witness 似乎遵循相同的规则，毕竟它们都是更具体的人员种类。但是，某个人作为目击者或受害人的状态是临时的，因此最好将其表示为一个角色。事实上，在本例中，同一个人在一个具体的盗窃案例中可以同时作为受害人和目击者。在这种情况下，您将使用两个不同的角色来表示同一个人。我通过以下方法在我的模型中展示这一点：添加一个单独的
Person 类，并创建到 Victim 和 Witness 类的关联。我将这样的关联标记为 Role
Of Person，以表明它们通过一个角色而不是一个常规关联相关。
图 2 展示了添加了泛型和角色的模型。
图 2. 添加了泛型和角色的 UML
模型
关系
UML 有三种方法来表示关系：聚合（aggregations）、复合（compositions）和关联（associations）。
聚合和复合关系通常表示 “拥有” 关系，其中一个类隶属于另一个类。在这个示例案例研究中，一个 Person
“拥有” 一个 PersonName。如果没有一个 person 与之关联，PersonName 类毫无用处。聚合和复合在
NIEM 中受到同等对待。在最终的 XML 结构中，附属类将包含在其他类中。例如，有一个 Person
元素，它包含一个 PersonName 元素。
相反，关联处于两个独立存在的类之间。在这个示例案例研究中，Theft 和 TheftLocation
是两个独立的类，不需要依赖对方就可以独立存在。为在您的模型中表示这些关联，您可以使用泛型 UML 关联，或者，如果有额外的属性与关联本身相关，那么可以对模型添加独立的关联类。无论哪种方法，在这个
NIEM XML 结构中，这些类都应表示为带有一个独立的关联元素的明确元素。这个关联元素包含与它有关的那些元素的引用
— 在本例中这些元素为 Theft 和 TheftLocation。
在这个示例案例研究中，我使用复合来表示 Person-PersonName 关系，用简单的 UML
关联来使这些类的其余部分互相相关。图 3 展示了添加了关系后的模型。（查看 图 3 的文字版。）
图 3. 添加了关系的 UML 模型
选择一个根
每条 XML 消息必须拥有一个根。通常，在一个 XML 交换中，消息有一个关注点或目的。在本例中，它是盗窃报告本身。我对我的模型添加了一个
TheftReport 类和一个属性 TheftReportDate，在 TheftReport 和
Theft 之间添加了一个聚合关系，表明这个盗窃报告包含一组盗窃。
图 4 展示了完成后的 UML 模型。这个模型并不完美，也不必完美。在整个 IEPD 开发过程中对模型进行反复修改是很常见的。例如，在适当的时候，修改结构和名称来更好地适应
NIEM 模型可能很有用。（查看 图 4 的文字版。）
图 4. 完成的 UML 模型
结束语
本文在一个较高的层面上描述了创建一个 NIEM IEPD 涉及的步骤，深入介绍了第一个步骤：创建模型。这个步骤的结果是一个
UML 模型的工作草案，您可以使用它来继续 IEPD 开发。如果您在建模过程中使用针对 NIEM 的概念，比如角色和
XML Schema 数据类型，那么 IEPD 开发过程的其余步骤将变得更轻松。 |
