摘要

本文重点介绍顶级模型驱动架构 (MDA) 建模的使用，以及如何在信息系统开发中完成向较低级别的自动转换。 这项工作的主要目的是设计一种在 MDA 中进行计算机独立模型 (CIM)-平台独立模型 (PIM) 转换的系统方法。 这些 CIM-PIM 转换方法专为代表 CIM 和 PIM 抽象级别的选定模型而设计。 我们展示的最终自动化 CIM 到 PIM 转换基于通过业务流程模型和表示法 (BPMN) 进行的业务流程建模。 BPMN 中的业务流程模型以可扩展标记语言流程定义语言 (XMLPDL/XPDL) 格式存储，用于自动转换为选定的统一建模语言 (UML) 设计模型，使用可扩展样式表语言转换 (XSLT) 中生成的转换算法 ） 语言。

关键字

  • 模型驱动架构
  • 计算机独立模型
  • 平台无关模型
  • 自动转换
  • 业务流程模型和符号
  • 统一建模语言

导论

不断创新和开发新的信息系统（information systems IS）旨在将信息系统的开发提升到更高的抽象层次。 因此，从实施的角度来看，信息系统的开发不仅是软件设计人员关注的问题，也是非 IT 专业人员关注的问题。 从信息系统实施的角度来看，相对较低的 IT 知识水平不应限制非 IT 专业人员参与开发过程。 非 IT 专业人员需要对设计问题有透彻的了解，因为他们对系统功能的贡献至关重要。 许多现有方法不区分 IT/业务对齐情况。企业架构 (Enterprise architecture EA) 可用于此连接，EA 模型是这些研究的成果。

这一原则很重要，主要是因为影响组织成功的个性化信息系统的开发。 为实现这一目标，有必要保证信息系统支持所有主要业务和管理流程的自动化。 因此，在设计信息系统时，我们需要包含并理解有关信息系统如何与外部组织系统交互的许多观点。 系统架构能够捕获、规范和描述实体和关系，以支持视点之间的通信，因此已成为信息系统设计的主要方法。

系统架构的描述由标准 ISO/IEC/IEEE 42010:2011 明确定义。 该标准在具体信息系统中的应用导致基于部分观点的体系结构，其中关系有助于为特定信息系统创建体系结构框架。 参与者之间的交流需要对应规则来转换信息系统各种观点之间的关系。 它是 [3] 中系统和软件架构 (SSA) 上下文中提到的问题之一，介于 [4] 中提出的需求规范和架构设计描述以及 [5] 中的需求工程和软件架构之间。

我们已经了解到，在过去，我们在日利纳大学的支持流程中忽视了信息系统设计的各种参与者之间的这种类型的交流。 因此，这些适用于两种架构观点的对应规则成为我们研究的重点。 为了定义通信规则，我们选择了对象管理组标准化的模型驱动架构 (MDA) 原则（MDA 指南版本 1.0.1）。

模型驱动架构——MDA 是 IS 设计的一种方法，可以帮助实现上述各种架构观点之间的通信要求。 MDA 框架基于系统地使用代表不同级别抽象和转换的模型 [6]。 它基于这样一种理解，即使用模型我们可以以改进的方式构建、修改和管理信息系统。 MDA 引入了四个相互关联的级别。 抽象的最高层是 CIM（计算机独立模型），然后是 PIM（平台独立模型），然后是 PSM（平台特定模型），最后，最低层是实现代码。 OMG 将关卡描述为模型； 然而，这些模型代表了不同的抽象层次。 MDA 框架工作并未精确定义所有级别所需的确切模型类型。 它描述了个体水平和它们之间的关系。 没有标准化的方法来创建和转换 MDA 定义的级别，只有描述抽象级别的通用规则

考虑到上面提到的 MDA 标准，CIM 级别代表即使是非 IT 专业人员也可以理解的业务观点，而 PIM 级别代表软件设计观点。

现在我们可以找到很多 MDA 的解决方案，从 PIM 级别开始，使用自动 PIM-PSM 转换，并进一步创建基本的实现代码。 有 CASE 工具和一些 MDA 工具可以使这些过程自动化。 然而，缺乏用于 CIM 到 PIM 转换的标准化方法以及用于此目的的工具。 因此，我们建议解决这个问题将是实现 MDA 最终愿景的重大进展。

在我们的研究中，我们关注顶层抽象 CIM 和低层 PIM 之间的转换规则。 我们发现这是 MDA 框架中最有问题的部分。 我们只发现了这方面的一些研究，我们在相关著作中分析了其中的一些。 CIM 到 PIM 的转换不是由 OMG 定义的，主要是通过分析进行的。 因此我们假设这个问题应该是 MDA 方法的重要资产。

在以下部分中，我们将介绍我们的研究方法和获得的结果。

相关工作

在检查评估问题的当前技术水平时，我们评估了 MDA 中 CIM-PIM 转换的不同方法，我们从中得出以下结论：

  • PIM 级别的所有符号都用 UML 语言定义
  • 除了方法 2 之外，PIM 级别是基本软件体系结构的组件模型。 这并不完全等同于业务实体的模型。
  • CIM 级别的符号是：
    (a) UML 2.0
    (b) BPMN
    (c) AND/OR graph
    (d) Description

CIM 级别定义为：

  • feature model
  • requirement model
  • business processes model
  • value model
  • model goals and information requirements
  • secure business process

通过检查类似研究中说明的 CIM 到 PIM 的转换，很明显，目前还没有任何现有方法得到 MDA 指定标准的完全支持。 到目前为止，作者只定义了非标准化的方法，这些导致整体互操作性的丧失。 大多数用于支持建模和转换的工具都受到成本（例如 QVT）和系统间有限合作的限制。 需要一个用于 CIM 到 PIM 转换的稳定框架的标准定义和支持普遍接受的标准的方法。 这种方法将增强许多标准化开发工具之间的兼容性

解决方案

我们在设计自动CIM-PIM转换时考虑了四个基本条件：

  1. 业务流程模型的符号必须具有足够的表现力，并且易于业务和 IT 用户理解。
  2. 业务流程模型的符号必须以图形和语义形式标准化。
  3. 设计模型的符号必须以图形和语义形式标准化。
  4. CIM-PIM 转换的内置自动化方法应该是通用的（独立于平台）和可扩展的。

通过使用 BPMN 符号（OMG Inc. BPMN 2.0 版）确保符合第一个条件。 BPMN 是标准化的图形符号，分配给流程建模。 业务和 IT 领域的人员很容易理解它。 这种表示法提供了足够大的表现力，因为它是
基于业务流程的图形可视化。 这具有让其他领域容易理解业务流程的巨大优势

由于BPMN只是一个图形化标准，为了转换的目的，需要将业务流程模型从BPMN转换为标准化的语义（文本）形式。 XPDL 格式（WFMC-TC-1025 Version 2.1a；WFMC-TC-1025 Version 2.2）以 BPMN 表示法引入业务流程模型脚本的标准化语义形式，是针对此需求的一种解决方案。 BPMN-XPDL 的转换在大多数可用的、面向业务流程的建模工具中自动完成。 通过 XPDL，甚至可以扩展 BPMN 元素语义。 使用 XPDL 可确保符合第二个条件。

符合第三个条件是关于建模语言 UML 及其标准化交换 MOF XMI 格式的问题，它允许 UML 模型脚本的语义形式。 XPDL 和 MOF XMI 是基于描述性 XML（可扩展标记语言）语言的格式。 因此，我们选择了 XSLT（可扩展样式表语言转换）来创建自动 CIM-PIM 方法的转换算法。 XSLT 语言允许创建基于 XML 的各种格式之间的转换规则。 XSLT 为这些转换提供了多功能性，因为执行转换算法的 XSLT 处理器是免费提供的，并且可以在任何平台（Windows、Linux）上实现。 这种方法还确保在需要丰富 BPMN 语义以及转换为基于 XML 的其他模型的情况下的可扩展性。 如此一来，连转化的第四个条件都满足了。

方法论转换原则 (Methodology Transformation Principles)

CIM-PIM 的自动转换基于XSLT 语言转换规则（算法）的创建，其中以XPDL 格式表示的BPMN 业务流程模型的元素被转换为选定的以MOF XMI 格式表示的UML 模型的元素。 这种格式通常可导入 UML/CASE 建模工具。 选择了两种类型的输出模型来促进这种转换：

  • UML 用例图。
  • UML概念类图表示的信息系统业务实体模型

这是因为 UML 用例图表示 IS 的功能，而业务实体模型表示具有必须在 IS 中处理的已定义操作或属性的业务实体。 对于 MOF XMI 格式，有必要通过在选定的 UML 模型中放置单个元素来执行分析。 基于这些考虑，为选定的 UML 模型类型创建了通用 XMI 模板，作为生成输出模型的基础。 该转换过程如图 1 所示

改造原理如下。 在以 BPMN 表示法创建业务流程模型后，该模型会通过建模工具自动转换为 XPDL 格式。 XPDL 格式连同由此产生的 XSLD 转换规则，成为 Kardos [14] 创建的软件应用程序的输入参数。 该软件应用程序具有以下功能：

  • 它自动创建 XPDL 格式的扩展属性以扩展 BPMN 元素的语义
  • XSLT 处理器将生成的 XSLT 转换算法应用于输入 XPDL 格式。
  • 应用 XSLT 规则以表示 UML 用例类图的 MOF XMI 文件形式创建输出。 UML 概念类图表示 IS 的业务实体模型。

软件应用程序的创建是必要的，因为它使两个例行活动自动化。 首先，它扩展了关于数据属性的语义 BPMN 元素，否则必须通过编辑表示 XPDL 格式的文件来手动添加这些属性。 这是一个耗时且不透明的过程。 其次是在生成的应用程序中实现的 XSLT 处理器的使用。 如果没有该应用程序，则需要通过命令行将输入输入 XSLT 处理器。 库 MSXML 的处理器是 .Net C# 的一部分，在创建的 XSLT 应用程序中实现。 此外，由此产生的软件应用程序可以自动执行封装在一个单元中的日常活动。

作者提出了一个转换算法的例子，我们称之为 UML 用例图的 Actors 创建。 为了简化 XSLT 转换算法，原理由一个伪算法描述，该算法捕获由 XPDL 格式表示的 BPMN 元素到用例 UML 图的 Actors 类型元素的映射基础

可以基于两个基本元素创建参与者。 首先是从 BPMN 元素创建参与者——泳道是池或泳道的块。 这些 BPMN 元素有助于组织和分类单个活动。 在交互式 B2B（企业对企业）流程的情况下，池代表业务角色——在流程中执行活动的参与者/成员。 Pool 作为参与者可以扮演两种角色，作为商业实体（例如日利纳大学）或商业角色（例如教师、研究员）。 Lane 是池的子分区，因此它可以代表某些业务角色（例如经理）。 它还可以表示业务流程的任何其他必要特征。 由于池可以代表业务角色并包含其他车道，因此通过创建演员，我们可以使用泛化原则从池中创建演员祖先，并从车道中创建演员后代。 在 XPDL 格式中，存在由具有相同名称的 XPDL 元素（pool 和 lane）描述的池和通道。 基于池或通道创建参与者适用于简单、映射良好的业务流程

在业务流程框架中创建执行者已经发展成为创建适用于简单和复杂业务流程图案例的执行者的通用方法

执行者代表执行特定过程或活动的参与者，也可以出现在两个角色中：作为业务实体或业务角色。 通过表演者创建演员是完全通用的，可用于表示最复杂的业务流程。 XPDL 格式的表演者被描述为参与者类型的元素

图 2 显示了用于创建 UML 用例图的参与者的伪算法。算法从变量的初始化开始。 输入函数参数是 XPDL 文件和参数 FromParticipant 表示，如果演员应该在 XPDL 元素的基础上创建，则类型为 Participant。 如果此参数的值设置为 true，则检查类型为 Participant 的 XPDL 元素。 如果数组 Participant 中的元素数大于零，则逐一检查此数组，并从当前元素 Participant 创建一个参与者 umlActor 并将其插入到 actorsumlActor 数组中（伪函数 CreateUmlActor）。 如果参数 FromParticipant 的值设置为 false，则参与者是从池中创建的。 数组池逐个元素检查，从池的每个元素中，创建一个角色 umlActor 插入到角色数组 umlActors 中。 如果当前元素池包含泳道，同时又是“业务角色”类型，则为数组Pool。 正在检查车道，其中每个元素车道都变成了演员 umlActor，并且还在当前检查的元素池和车道之间创建了演员的泛化（关系祖先 - 前任）。 在这种情况下，参数 Generalization 设置为 true

伪函数 CreateUmlActor 通过接受唯一标识符 ID 及其来自池、通道或参与者类型的 XPDL 元素的标识符名称来创建新的参与者 umlActor。 这些标识符进一步映射到具有相同名称的参与者 umlActor 的标识符。 伪函数还有另外两个参数：Parent 和 Generalization。 如果参数 Parent 的值已设置且参数 Generalization 的值为真，则创建到父项的链接（参数 Parent）以创建关联类型泛化。 如果参数 Parent 的值为空且参数 Generalization 的值为 false 则参数 Parent 没有关联值，这意味着创建的 umlActor 将不会包含在与另一个 actor 的类型泛化链接中。 返回值函数是变量umlActor

角色创建算法只是向 UML 用例图转换的一部分。 完整创建 UML 用例图所需的进一步转换算法是：创建功能 (UseCase) 以及创建参与者和功能之间的关联 (Association)。

在转换为业务实体模型（UML 概念类图）的情况下，使用了这些转换算法：类的创建（Class）、方法的创建（Methods）、属性的创建（Attributes）和关联的创建（Association） 类之间。

结论

在本文中，我们提出了一种在 MDA 框架中自动进行 CIM-PIM 转换的独特解决方案。 我们设计了代表 CIM 和 PIM 级别的有用模型和符号。 我们寻找用于从 BPMN 建模的业务流程转换为 UML 模型的自动化解决方案，具体是 UML 用例模型和 IS 的业务实体模型，用 UML 表示为概念类图。

我们的转型方法建议已通过 IS 的开发得到验证，IS 已成功支持日利纳大学的两个流程：科学研究流程和流动流程。 BPMN 符号中的模型（代表 CIM 模型）自动转换为两种类型的 UML 图（代表 PIM 模型）。 转换应用程序的示例将在会议的演示中展示。

我们创建 CIM 到 PIM 的自动化转换的初衷尚未完全实现。 这是因为输出的 UML 模型仍然需要通过导入 MOF XMI 格式的 UML 建模工具进行调整。 因此，将此称为在 MDA 中将 CIM 转换为 PIM 的半自动化方法更为合适。 自动转换有助于创建初始化 PIM 级别，该级别仍然需要手动调整表示的模型，以便将它们格式化以进一步转换为 PSM 模型。

更进一步的目标是确定XPDL格式扩展的精确规则，以便在BPMN中实现业务流程模型的最大程度的自动化转换。 这个目标不仅适用于选定的 UML 模型，而且适用于成功开发 IS 所需的其他模型。 另一个目标是创建 BPMN 模型的图形编辑器。 这将使我们能够扩大图形模型的 BPMN 元素的语义，并将这些扩大直接转换为 XPDL 格式。 一种可能性是自动创建 XSLT 转换规则

尽管作为自动生成的 PIM 模型的一部分，某些手动更改仍然是必要的，但这种独特的方法使用系统方法成功地解决了所提出的自动 CIM-PIM 转换问题。 该解决方案帮助我们更接近 MDA 的愿景，即在尽可能高的抽象级别创建信息系统，并在所有级别自动化这些转换，直到实现模型代码

作者知道 BPMN 用于建模业务流程，并且与时间线紧密相关。 BPMN 中的所有事件和活动都在层次结构中排序或链接。 在 BPMN 和 UML 之间的转换过程中，有可能会丢失这些特性。 UML 用于从不同的角度对软件进行建模，这就是为什么在转换后很难在 UML 中保留提到的特性（BPMN 语义）。 不仅捕获 BPMN 语义而且捕获一般数据语义都非常困难。 在“语义和知识捕获”领域，经常使用本体。 根据这一观点，我们接下来的研究将集中于本体如何为 MDA 方法带来新的可能性。