您如何在同一 UML class 图中表示同一实体类型 (class) 的不同版本？
How do you represent different versions of the same entity type (class) in the same UML class diagram?
我正在尝试弄清楚如何为具有以下属性的情况建模：
- 域中存在一组实体类型 Ei...Ej 以及这些实体类型 Ri...Rj 之间的一组关系类型；
- 可以同时区分对系统不同部分重要的那些实体和关系类型的至少两个不同版本。
在最简单的情况下，这些不同的版本可能是“实时数据”版本和“最后批准的快照”版本。在这种情况下，对系统的不同部分很重要可能会转化为以下内容：
- 特权角色和用例较少，只能与“最后批准的快照”版本一起使用；
- 同时，有更多具有相同或不同用例集的特权参与者可以使用“实时数据”版本；
- 有实体类型 Ex...Ey 与来自“最后批准的快照”版本的实体 ei...ej 形成关系，或者其约束引用来自“最后批准的快照”版本的实体 ei...ej 的属性值快照”版本；
- 同时存在不同的实体类型 Ea...Eb，它们要么与来自“实时数据”版本的实体 ei...ej 形成关系，要么其约束参考实体 ei...的属性值来自“实时数据”版本的 ej。
如果我想在同一张图上显示上述示例中的所有实体类型 Ei...Ej、Ex...Ey 和 Ea...Eb 以及它们之间的约束和关系，我该怎么做那？
我正在考虑对同一实体类型使用两个不同的 classes：一个 class 代表该实体类型的“最后批准的快照”版本，另一个 class代表该类型的“实时数据”版本。
但我不太喜欢这种方法，因为
- 好像多余；
- 我实际上不确定代表同一实体类型的两个不同版本的两个 classes 之间存在什么样的关系以及如何在图表中表示该关系（也许是从标准中“派生”刻板印象profile 在这里是合适的，但我不确定）。
编辑
不幸的是，我不能使用我工作中的例子，所以我想出了这个完全虚构的例子，但它也部分模仿了我最近试图解决的问题。我将使用流行的“WorksInUsing”协会来表达应有的敬意。这将使问题更加具体。
此外，需要说明的是，我正在尝试创建概念模型，而不是 OOP/relational design/implementation 模型。
让我们假设一个实体类型 Employee。
让我们假设一个名为“SkillAdministrator”的参与者管理以下实体和关系类型：
- 实体类型技能
- 实体类型部门
- 实体类型 Employee 和 Skill 之间的关系类型 KnownSkill
- 实体类型 Employee 和 Department 之间的关系类型 WorkInDepatment
让我们假设，上述所有实体和关系类型的更改很少发生，但当它们发生时，它们会以非常大的批量发生，我们的技能管理员需要相当长的时间来处理每个此类更改。
他完成更改处理后，运行s PublishChange 用例创建实体和关系类型 Skill 和 KnownSkill 的快照，并使该快照可供系统的其他用户使用。
现在假设一个名为 Manager 的参与者管理以下实体和关系类型：
- 实体类型项目
- 实体类型 Employee、Skill 和 Project 之间的关系类型 WorksInUsing。
只有在 PublishChange 用例的最后 运行 中存在的技能才能在 WorksInUsing 关联中发挥作用。此外，KnownSkill 对是三元组 WorksInUsing 的先决条件，但同样仅存在于 PublishChange 用例的最后 运行 中的那些 KnownSkill 对。
在 Manager 管理 WorksInUsing 关联的同时，SkillAdministrator 可以开始处理他管理的实体和关系类型的下一个重大变化。经理看不到这些更改，直到 PublishChange 用例再次 运行。
（根据领域的不同，系统管理员有多种不同的方法来处理特定技能或已知技能关联的删除，然后应用这些更改 - 在最简单的情况下，两种类型都可以假定为永久性的，所以新可以添加实例，但不能删除现有实例，例如法律就是这样运作的）
其实没有太多选择。要么你要区分继承
或通过旗帜
根据domain/context，两种解决方案各有利弊。在这种情况下，我倾向于使用标志变体。仅仅因为它代表了一种可以改变的状态（另见 here as suggested by @Christophe）。选择继承会使将未批准的快照变成已批准的快照变得复杂（您需要创建一个新实例并复制内容）。
在任何情况下，您都需要一些约束来描述如何限制访问，以便某些参与者可以处理一个或另一个变体。只需应用奥卡姆剃刀原则，不要试图找到过于复杂的模型，而简单的模型也可以。出于业余爱好或 puzzle/stun 其他人，这很好。但实际上呢？
I was thinking about using two different classes for the same entity type
这可能意味着 classes 根据实体批准历史出现和消失！
假设还没有批准的版本，那么只有一个实时版本随着时间的推移而演变，当该版本被批准时仍然只有一个版本既是最后批准的版本又是实时版本，也许你可以使用同样的 class 现在被批准了。然后必须进行第一个更改，因此最后批准的版本仍然存在并被克隆以创建实时版本的 class。当该实时版本获得批准时，必须删除已经存在的最后批准 class。等
参与者（在非 UML 用例意义上）必须访问权限 class 才能尝试与之交互。
我不是你确定你想要在元模型级别工作。
第二种方法是让 class 始终管理最后批准的版本，让另一个 class 管理实时版本，在给定时间每个 [=0 或一个实例=43=]，但当实体存在时至少有一个。
假设还没有批准的版本，所以没有最后批准版本的实例 class，所以只有一个实时版本的实例 class 随着时间的推移而演变。当该版本获得批准后，必须从实时 class 实例创建已批准版本 class 的实例，然后至少必须删除该版本。然后必须进行第一个更改，因此最后批准版本的实例仍然存在并被克隆以创建实时版本的 class 实例。当该实时版本获得批准时，必须更新或删除最后批准的 class 的现有实例并创建另一个实例，并删除实时 class 的实例。等
演员必须访问 class 的正确实例才能尝试与之交互。
第三种方法不是使用不同的 class 而是使用相同 class 的不同 实例 。在实体审批历史中，实例 created/deleted 与第一种方式相同 classes。但是级别不是元模型。
就像以前的方式一样，演员必须访问 class 的正确实例才能尝试与之交互。
第四种方法是对同一时间存在的实体的所有版本使用相同的实例，该实例能够以正确的方式做出反应，具体取决于它的 视图由演员使用，还要检查演员是否获得授权。每个实例都为给定实体创建一次，无论版本和批准历史如何。
因为只有一个实例，演员不必在多个实例中做出选择 instances/classes。如果实体之间存在关联，则它们始终相同，并且不必 created/deleted 取决于实体的版本。
我正在尝试弄清楚如何为具有以下属性的情况建模：
- 域中存在一组实体类型 Ei...Ej 以及这些实体类型 Ri...Rj 之间的一组关系类型；
- 可以同时区分对系统不同部分重要的那些实体和关系类型的至少两个不同版本。
在最简单的情况下，这些不同的版本可能是“实时数据”版本和“最后批准的快照”版本。在这种情况下，对系统的不同部分很重要可能会转化为以下内容：
- 特权角色和用例较少，只能与“最后批准的快照”版本一起使用；
- 同时，有更多具有相同或不同用例集的特权参与者可以使用“实时数据”版本；
- 有实体类型 Ex...Ey 与来自“最后批准的快照”版本的实体 ei...ej 形成关系，或者其约束引用来自“最后批准的快照”版本的实体 ei...ej 的属性值快照”版本；
- 同时存在不同的实体类型 Ea...Eb，它们要么与来自“实时数据”版本的实体 ei...ej 形成关系，要么其约束参考实体 ei...的属性值来自“实时数据”版本的 ej。
如果我想在同一张图上显示上述示例中的所有实体类型 Ei...Ej、Ex...Ey 和 Ea...Eb 以及它们之间的约束和关系，我该怎么做那？
我正在考虑对同一实体类型使用两个不同的 classes：一个 class 代表该实体类型的“最后批准的快照”版本，另一个 class代表该类型的“实时数据”版本。
但我不太喜欢这种方法，因为
- 好像多余；
- 我实际上不确定代表同一实体类型的两个不同版本的两个 classes 之间存在什么样的关系以及如何在图表中表示该关系（也许是从标准中“派生”刻板印象profile 在这里是合适的，但我不确定）。
编辑
不幸的是，我不能使用我工作中的例子，所以我想出了这个完全虚构的例子，但它也部分模仿了我最近试图解决的问题。我将使用流行的“WorksInUsing”协会来表达应有的敬意。这将使问题更加具体。
此外，需要说明的是，我正在尝试创建概念模型，而不是 OOP/relational design/implementation 模型。
让我们假设一个实体类型 Employee。
让我们假设一个名为“SkillAdministrator”的参与者管理以下实体和关系类型：
- 实体类型技能
- 实体类型部门
- 实体类型 Employee 和 Skill 之间的关系类型 KnownSkill
- 实体类型 Employee 和 Department 之间的关系类型 WorkInDepatment
让我们假设，上述所有实体和关系类型的更改很少发生，但当它们发生时，它们会以非常大的批量发生，我们的技能管理员需要相当长的时间来处理每个此类更改。
他完成更改处理后，运行s PublishChange 用例创建实体和关系类型 Skill 和 KnownSkill 的快照，并使该快照可供系统的其他用户使用。
现在假设一个名为 Manager 的参与者管理以下实体和关系类型：
- 实体类型项目
- 实体类型 Employee、Skill 和 Project 之间的关系类型 WorksInUsing。
只有在 PublishChange 用例的最后 运行 中存在的技能才能在 WorksInUsing 关联中发挥作用。此外，KnownSkill 对是三元组 WorksInUsing 的先决条件，但同样仅存在于 PublishChange 用例的最后 运行 中的那些 KnownSkill 对。
在 Manager 管理 WorksInUsing 关联的同时，SkillAdministrator 可以开始处理他管理的实体和关系类型的下一个重大变化。经理看不到这些更改，直到 PublishChange 用例再次 运行。
（根据领域的不同，系统管理员有多种不同的方法来处理特定技能或已知技能关联的删除，然后应用这些更改 - 在最简单的情况下，两种类型都可以假定为永久性的，所以新可以添加实例，但不能删除现有实例，例如法律就是这样运作的）
其实没有太多选择。要么你要区分继承
根据domain/context，两种解决方案各有利弊。在这种情况下，我倾向于使用标志变体。仅仅因为它代表了一种可以改变的状态（另见 here as suggested by @Christophe）。选择继承会使将未批准的快照变成已批准的快照变得复杂（您需要创建一个新实例并复制内容）。
在任何情况下，您都需要一些约束来描述如何限制访问，以便某些参与者可以处理一个或另一个变体。只需应用奥卡姆剃刀原则，不要试图找到过于复杂的模型，而简单的模型也可以。出于业余爱好或 puzzle/stun 其他人，这很好。但实际上呢？
I was thinking about using two different classes for the same entity type
这可能意味着 classes 根据实体批准历史出现和消失！
假设还没有批准的版本，那么只有一个实时版本随着时间的推移而演变，当该版本被批准时仍然只有一个版本既是最后批准的版本又是实时版本，也许你可以使用同样的 class 现在被批准了。然后必须进行第一个更改，因此最后批准的版本仍然存在并被克隆以创建实时版本的 class。当该实时版本获得批准时，必须删除已经存在的最后批准 class。等
参与者（在非 UML 用例意义上）必须访问权限 class 才能尝试与之交互。
我不是你确定你想要在元模型级别工作。
第二种方法是让 class 始终管理最后批准的版本，让另一个 class 管理实时版本，在给定时间每个 [=0 或一个实例=43=]，但当实体存在时至少有一个。
假设还没有批准的版本，所以没有最后批准版本的实例 class，所以只有一个实时版本的实例 class 随着时间的推移而演变。当该版本获得批准后，必须从实时 class 实例创建已批准版本 class 的实例，然后至少必须删除该版本。然后必须进行第一个更改，因此最后批准版本的实例仍然存在并被克隆以创建实时版本的 class 实例。当该实时版本获得批准时，必须更新或删除最后批准的 class 的现有实例并创建另一个实例，并删除实时 class 的实例。等
演员必须访问 class 的正确实例才能尝试与之交互。
第三种方法不是使用不同的 class 而是使用相同 class 的不同 实例 。在实体审批历史中，实例 created/deleted 与第一种方式相同 classes。但是级别不是元模型。
就像以前的方式一样，演员必须访问 class 的正确实例才能尝试与之交互。
第四种方法是对同一时间存在的实体的所有版本使用相同的实例，该实例能够以正确的方式做出反应，具体取决于它的 视图由演员使用，还要检查演员是否获得授权。每个实例都为给定实体创建一次，无论版本和批准历史如何。
因为只有一个实例，演员不必在多个实例中做出选择 instances/classes。如果实体之间存在关联，则它们始终相同，并且不必 created/deleted 取决于实体的版本。