【问题标题】:Should I use a UML trace or realization我应该使用 UML 跟踪还是实现
【发布时间】:2019-08-27 12:53:11
【问题描述】:

我有一个用于不同系统的逻辑数据模型和多个物理数据模型,所有这些都记录在 UML 中。我想展示物理模型中的数据如何追溯到逻辑模型,以便在对逻辑模型进行更改时,我们可以轻松确定所有受影响的物理模型。

这些关系最好用痕迹还是实现来表示?我怀疑答案是“跟踪”,但想看看其他人在投入太多时间和错误之前的想法。跟踪或实现关系是否提供了在此上下文中有用的额外语义?

【问题讨论】:

  • 你的物理模型、部署(工件...)是什么级别?零件 ?其他?

标签: uml data-modeling


【解决方案1】:

到目前为止我的解释(有意引用):“我通常使它们成为<<trace>> 依赖项。Realization 位于接口或抽象类和'常规'类之间。物理模型源自逻辑模型, 不是 1:1 实现的。在大多数情况下,您在物理级别上进行了逻辑模型中未预见到的修改(在 DB 级别上需要的非规范化和各种优化)。不知何故,这是一种实现。 "

然而,这是纯粹的事实,这就是 UML 规范在 p 上所说的。 54:

7.8.14 实现[类]

实现是两组模型元素之间的一种特殊抽象关系,一组表示规范(供应商),另一组表示后者的实现(客户)。实现可用于建模逐步细化、优化、转换、模板、模型合成、框架组合等。

所以你实际上可以在这里使用一个实现。 <<trace>> 更不正式,但不一定是错误的。

【讨论】:

    【解决方案2】:

    这些关系最好表示为跟踪,即与构造型 > 的依赖关系。跟踪旨在关联 不同 模型中的元素,这正是您的情况。

    UML 2.5.1 规范将跟踪构造型定义为“标准配置文件”(第 22.3 节)的一部分,如下所示:

    指定模型元素或模型集之间的跟踪关系 在不同模型中代表相同概念的元素。痕迹是 主要用于跨模型跟踪需求和变化。作为 模型的变化可以在两个方向上发生,方向性 依赖通常可以忽略。映射指定关系 两者之间,但它很少可计算并且通常是非正式的。

    虽然 UML 规范对实现关系的定义也足够广泛以适合您的目的,但 UML 规范中的示例(例如图 7.21)以及我在现实世界项目中使用这种关系的方式让我得出了结论这种类型的关系主要用于关联同一模型中的元素,特别是接口元素与实现这些接口的类。

    【讨论】:

    • 我完全同意。确切地说,«trace»只是间接的依赖关系。基本元素是一个抽象,而抽象又是一个特殊的依赖。实现也是抽象。这使他们成为兄弟姐妹。一个是刻板印象,另一个是模型元素。这意味着,«trace» 比实现更接近抽象。
    猜你喜欢
    • 2018-11-19
    • 2011-07-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-12
    • 2017-04-19
    • 2012-07-12
    • 2012-07-23
    相关资源
    最近更新 更多