面向对象设计中对象生命周期的视图集成
1 引言
在处理对象生命周期的视图集成时，会遇到各种问题和挑战。不同的视图可能对活动和状态的定义存在差异，有些活动和状态在一个视图中详细定义，而在另一个视图中仅作为抽象元素；有些活动和状态只在一个视图中存在，而在另一个视图中缺失。本文将详细介绍相关概念和解决方法。
2 行为图
2.1 带标签的行为图
行为图基于 Petri 网，由活动、状态和弧组成。活动对应 Petri 网中的转换，表示对业务对象执行的工作；状态对应 Petri 网中的位置，显示对象当前所在的位置。每个对象类型的实例由唯一的令牌（对象标识符）表示，它可以位于一个或多个状态中。
活动可以在对象上被调用，前提是该活动的所有前置状态都被该对象标记。活动执行完成后，对象将被插入到该活动的所有后置状态中。与 Petri 网不同的是，我们假设活动可能需要一些时间，在活动执行期间，对象位于以该活动命名的隐式活动状态中。
行为图可以被标记，标记的概念来源于通过纸质工作处理业务对象的过程，不同的参与者处理业务表单的不同副本。在这个类比中，标签对应于特定的副本。弧（状态或活动）的标签表示表单的哪些副本沿着弧流动（位于某个状态或被某个活动处理）。
下面是一个对象类型 RESVT 的行为图示例：
graph LR
classDef activity fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef state fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
A(issue):::activity --> B(toCheckIn):::state
A --> C(toPay):::state
B --> D(use):::activity
D --> E(checkedOut):::state
C --> F(payByCheque):::activity
C --> G(payCash):::activity
F --> H(paid):::state
G --> H
style A fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
style B fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px
style C fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px
style D fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
style E fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px
style F fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
style G fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
style H fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px
定义 1：对象类型的带标签行为图（LBD）B = (S, T, F, L, l) 由以下部分组成：
- 状态集合 S ≠ ∅
- 活动集合 T ≠ ∅，且 S ∩ T = ∅
- 弧集合 F ⊆ (S × T) ∪ (T × S)
- 标签集合 L ≠ ∅
- 标记函数 l : F → 2^L \ {∅}，为 F 中的每个弧分配一个非空的标签集合
状态、活动和标签被称为元素。存在一个唯一的初始状态 α ∈ S，使得不存在 t ∈ T 满足 (t, α) ∈ F。状态和活动也被标记，状态或活动的标签集合是其入射弧的标签集合的并集。初始状态 α 被标记为所有标签，代表业务对象尚未创建的时间段，在图形表示中通常省略。
定义 2：对象的生命周期状态（LCS）σ 是 (S ∪ T) × L 的子集。初始 LCS 是 σA = {(α, x)|x ∈ L}。
由于活动的执行可能需要一些时间，并且对象在执行期间位于活动状态中，我们区分活动的开始和完成。活动 t 可以在对象上开始，如果该活动的所有前置状态都被该对象标记；开始 t 会产生一个新的生命周期状态，其中包含活动状态 t 但不包含 t 的前置状态。活动 t 可以在对象上完成，如果对象位于活动状态 t 中；完成 t 会产生一个新的生命周期状态，其中包含 t 的所有后置状态，但不再包含 t。
定义 3：对象的生命周期发生（LCO）γ 是 LCS 的序列 γ = [σ1, …, σn]，使得 σ1 = σA，并且对于 i = 1, …, n - 1，要么 σi = σi+1，要么存在活动 t ∈ T，使得要么 t 可以在 σi 上开始，并且 t 的开始产生 σi+1，要么 σi 包含 t 并且 t 的完成产生 σi+1。
例如，对于上述 RESVT 的行为图，一个可能的生命周期发生是：
[{(α, p), (α, r)}, {(issue, p), (issue, r)},
{(toPay, p), (toCheckIn, r)}, {(toPay, p), (use, r)}, {(toPay, p), (checkedOut, r)},
{(payCash, p), (checkedOut, r)}, {(paid, p), (checkedOut, r)} ]
2.2 行为图的特化
对象类型的行为图可以在子类型中以两种方式进行特化：通过细化，即将状态和活动分解为子图，将标签分解为子标签；或者通过扩展，即添加状态、活动和标签。
观察一致性作为特化的正确性标准，保证了如果忽略扩展元素并将细化元素视为未细化，子类型的任何生命周期发生都可以被视为超类型的生命周期发生。观察一致性允许“并行扩展”，但不允许“替代扩展”，即通过扩展在子类型的行为图中添加的活动不能从子类型从超类型的行为图继承的状态中消耗或产生到该状态中。观察一致性只要求活动和状态的部分继承，超类型行为图中建模的“替代方案”可以在子类型的行为图中省略。
我们使用总特化函数 h : S′ ∪ T′ ∪ L′ → S ∪ T ∪ L ∪ {ε} 来表示更特殊的行为图 B′ = (S′, T′, F′, L′, l′) 和行为图 B = (S, T, F, L, l) 之间的对应关系。继承函数 h 可以表示四种情况：
1. 无变化继承：如果元素 e 没有改变，则存在 e′ ∈ S′ ∪ T′ ∪ L′ 使得 h(e′) = e，并且对于所有 e′′ ∈ S′ ∪ T′ ∪ L′，e′′ ≠ e′，有 h(e′′) ≠ h(e′)。
2. 细化：如果 B 中的元素 e 被细化为一组元素 E（|E| > 1），则对于所有 e′ ∈ E，有 h(e′) = e。
3. 扩展：如果在 B′ 中添加了一组元素 E，则对于所有 e ∈ E，有 h(e) = ε。
4. 消除：如果在 B′ 中移除了一组状态和活动 E ⊆ S ∪ T，则对于所有 e ∈ E，不存在 e′ ∈ S′ ∪ T′ ∪ L′ 使得 h(e′) = e。
为了定义观察一致的特化，我们需要定义生命周期状态的泛化和生命周期发生的泛化。
定义 4：对象类型 O′ 的 LBD B′ 的生命周期状态 σ′ 到对象类型 O 及其 LBD B 的泛化，记为 σ′/O，定义为 σ′/O ⊆ (S ∪ T) × L，其中对于所有 e ∈ S ∪ T，x ∈ L，((e, x) ∈ σ′/O ⇔ 存在 e′ ∈ S′ ∪ T′，x′ ∈ L′ 使得 h(e′) = e 且 h(x′) = x 且 (e′, x′) ∈ σ′)。
定义 5：对象类型 O′ 的 LBD B′ 的生命周期发生 γ′ = [σ′1, …, σ′n] 到对象类型 O 的泛化定义为 γ′/O = [σ′1/O, …, σ′n/O]。
定义 6：对象类型 O′ 的 LBD B′ 是对象类型 O 的 LBD B 的观察一致特化，当且仅当对于 B′ 的任何可能的 LCO γ′ 都成立：γ′/O 是 B 的 LCO。
例如，对象类型 RESVT’ 的行为图是对象类型 RESVT 的行为图的观察一致特化。活动 use 被细化为一个子网，包括活动 checkIn、useRoom、useGarage 和 checkOut 以及这些活动之间的几个状态。标签 r 被分解为子标签 rr（房间登记）和 rg（车库停车位登记）。活动 accountVoucher、状态 vchrTAcc 和 vchrAcctd 以及标签 v 通过扩展添加。活动 payCash 通过扩展被省略，这只需要部分继承。
已经引入了一组充分必要的规则来检查 LBD 的观察一致细化和扩展。如果将特化视为细化和扩展的串联，这些规则也可以用于检查 LBD 的观察一致特化。
定义 7：LBD B 是 B′ 的观察一致泛化（限制、抽象），当且仅当 B′ 是 B 的观察一致特化（扩展、细化）。
3 视图集成概述
3.1 动机示例
我们使用一个小例子来激发对象生命周期集成的问题。对于对象类型 RES（其实例是房间预订），有两个视图。第一个视图（表示为 V1）由处理房间预订请求的预订组定义，而第二个视图（V2）由前台定义，前台需要处理房间的使用（可能之前已经预订）以及未提前预订而请求空房间的客人的请求。
两个视图之间存在两种主要差异：
1. 一些活动和状态在一个视图中详细定义，而在另一个视图中仅作为抽象元素定义。例如，在 V1 中详细定义了请求的确认，而在 V2 中仅作为抽象状态引用。同样，活动 use 在 V1 中是抽象的，但在 V2 中详细定义。
2. 一些活动和状态在一个视图中定义，而在另一个视图中未定义。V1 包含活动 decline 和状态 declined，在 V2 中不可见。此外，活动 arriveWithoutBooking、accept 和 refuse 以及状态 arrived 和 refused 仅在 V2 中定义。
集成的对象生命周期应该完整详细地定义至少在一个视图中考虑的所有对象的行为。在我们的例子中，集成结果如下：
graph LR
classDef activity fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef state fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
A(request-Booking):::activity --> B(toConfirm):::state
B --> C(confirmed):::state
C --> D(confirm):::activity
D --> E(used):::state
A --> F(toUse):::state
F --> G(inUse):::state
G --> H(checkIn):::activity
H --> I(use):::activity
I --> J(checkOut):::activity
J --> E
B --> K(declined):::state
K --> L(decline):::activity
M(arriveWithout-Booking):::activity --> N(arrived):::state
N --> O(accept):::activity
N --> P(refuse):::activity
P --> Q(refused):::state
3.2 对应关系和异质性
视图集成基于对应元素，即存在于两个视图中的活动、状态和标签。但由于视图由不同的用户定义，存在一些需要解决的异质性。
对应关系
一个视图中的元素可能以不同的方式对应于另一个视图中的元素：
1. 等价：如果两个元素具有相同的现实世界语义，则一个视图中的单个活动、状态或标签分别等价于另一个视图中的单个活动、状态或标签。
2. 包含：一个视图中的单个活动或状态对应于另一个视图中由多个活动、状态和弧组成的子网，或者一个标签对应于一组标签。
3. 子网对应：由活动、状态和弧组成的两个子网相互对应，或者两组标签相互对应。
4. 无对应：一个视图中的元素与另一个视图中的任何元素都不对应。
例如，在我们的动机示例中，一些活动、状态和标签彼此等价（例如，requestBooking、used 和标签 r）。活动 use 在 V1 中对应于 V2 中由 checkIn、inUse 和 checkOut 组成的子网。有些元素与另一个视图中的元素没有对应关系，例如 V1 中的活动 decline 和状态 declined。
我们将与另一个视图中的元素对应的元素称为公共元素，将所有其他元素称为唯一元素。
异质性
异质性在结构集成领域已经详细讨论过。对于行为，我们区分两种主要类型的异质性：
1. 外延异质性：由于两个视图的设计者在定义视图时考虑不同的扩展，即不同的实体集，而导致的异质性。基本上只有一种外延异质性，即缺失实体，意味着一个视图考虑了另一个视图中未考虑的实体。
2. 内涵异质性：由于视图中定义了不同的活动、状态和标签，或者元素以不同的细节定义而产生的异质性。内涵异质性可以进一步细分为：
- 命名冲突：两个等价元素有不同的名称（同义词）或不同元素有相同的名称（同音词）。
- 粒度冲突：对应元素以不同的细节定义，导致包含或子网对应。
- 特定视图的替代方案：替代分支仅在一个视图中定义。
- 特定视图的扩展：特定视图的扩展是仅用唯一标签标记的唯一活动和状态。
在我们的动机示例中，为了更好的可读性，没有命名冲突。粒度冲突源于检测到的包含关系（例如，状态 toUse 和活动 use 及其对应的细化）。在视图 V2 中，活动 arriveWithoutBooking、accept 和 refuse 以及状态 arrived 和 refused 构成了一个特定视图的替代方案。为了简单起见，我们的动机示例中没有特定视图的扩展。
下面是对应关系和异质性的总结表格：
| 类型 | 细分 | 描述 |
| ---- | ---- | ---- |
| 对应关系 | 等价 | 单个元素语义相同 |
| 对应关系 | 包含 | 单个元素对应子网或标签组 |
| 对应关系 | 子网对应 | 子网或标签组相互对应 |
| 对应关系 | 无对应 | 元素无对应 |
| 异质性 | 外延异质性 | 缺失实体 |
| 异质性 | 内涵异质性 | 命名冲突、粒度冲突、特定视图替代方案、特定视图扩展 |
通过对这些概念和问题的理解，我们可以更好地进行对象生命周期的视图集成，解决其中的异质性问题，得到完整准确的集成结果。后续将进一步介绍解决异质性问题的集成方法和步骤。
3.3 集成方法
为了解决视图集成中的异质性问题，我们提出一种集成方法，该方法的主要目标是将不同视图中的对象生命周期进行整合，使得整合后的生命周期能够准确反映所有视图中考虑的对象行为。具体步骤如下：
- 识别对应元素 ：首先，需要确定两个视图中对应元素的关系，包括等价、包含、子网对应和无对应关系。这可以通过对视图中的活动、状态和标签进行语义分析来实现。例如，在我们的示例中，通过分析可以确定 requestBooking、used 和标签 r 在两个视图中是等价的，活动 use 在 V1 中对应于 V2 中由 checkIn、inUse 和 checkOut 组成的子网。
-
解决异质性问题
- 外延异质性 ：对于缺失实体的问题，需要将一个视图中存在而另一个视图中缺失的实体添加到集成视图中。例如，如果 V1 中有活动 decline 和状态 declined，而 V2 中没有，那么在集成视图中需要包含这些元素。
-
内涵异质性
- 命名冲突 ：如果存在命名冲突，需要统一元素的名称。可以选择一个合适的名称作为标准，或者创建一个映射表来记录不同名称之间的对应关系。
- 粒度冲突 ：对于粒度冲突，需要将细化的元素与抽象的元素进行匹配。例如，将 V2 中细化的活动子网与 V1 中抽象的活动进行对应。
- 特定视图的替代方案 ：将特定视图的替代方案添加到集成视图中，确保集成视图能够涵盖所有可能的行为。例如，将 V2 中的活动 arriveWithoutBooking、accept 和 refuse 以及状态 arrived 和 refused 添加到集成视图中。
- 特定视图的扩展 ：如果存在特定视图的扩展，需要将其合理地集成到集成视图中。可以通过添加新的状态、活动和标签来实现。
- 构建集成视图 ：根据识别的对应元素和解决异质性问题的结果，构建集成视图。集成视图应该包含所有视图中考虑的对象行为，并且元素之间的关系应该清晰明确。
下面是集成方法的流程图：
graph TD
A[识别对应元素] --> B[解决异质性问题]
B --> C[构建集成视图]
B1[外延异质性] --> B
B2[内涵异质性] --> B
B21[命名冲突] --> B2
B22[粒度冲突] --> B2
B23[特定视图替代方案] --> B2
B24[特定视图扩展] --> B2
4 视图集成的正确性标准和步骤
4.1 正确性标准
在进行视图集成时，需要确保集成结果的正确性。主要的正确性标准是观察一致性，即集成后的视图应该满足观察一致特化的条件。具体来说，对于集成视图的任何可能的生命周期发生，其泛化应该是原始视图的生命周期发生。
4.2 集成步骤
集成步骤如下：
1.
初始化集成视图
：将两个视图中的公共元素添加到集成视图中。
2.
添加唯一元素
：将每个视图中的唯一元素添加到集成视图中。
3.
解决异质性问题
：按照前面介绍的方法解决外延异质性和内涵异质性问题。
4.
检查观察一致性
：使用定义的泛化方法检查集成视图是否满足观察一致特化的条件。如果不满足，需要调整集成视图，直到满足观察一致性为止。
下面是集成步骤的详细列表：
| 步骤 | 操作 |
| ---- | ---- |
| 1 | 初始化集成视图，添加公共元素 |
| 2 | 添加唯一元素 |
| 3 | 解决异质性问题 |
| 4 | 检查观察一致性，必要时调整视图 |
5 总结
通过对对象生命周期的视图集成的研究，我们了解了行为图的相关概念，包括带标签的行为图和行为图的特化。同时，我们分析了视图集成中存在的对应关系和异质性问题，并提出了相应的集成方法和步骤。
在实际应用中，视图集成可以帮助我们整合不同用户定义的视图，得到一个完整准确的对象生命周期模型。通过解决异质性问题，我们可以确保集成结果的正确性和一致性。未来的研究可以进一步探索更复杂的视图集成场景，以及如何优化集成方法以提高效率和准确性。
总之，对象生命周期的视图集成是一个重要的研究领域，对于构建复杂的业务系统和模型具有重要的意义。通过合理的集成方法和正确性标准，我们可以有效地解决视图集成中的问题，得到高质量的集成结果。
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
