【问题标题】:Is that true that one bubble (use case) represent an activity diagram?一个气泡(用例)代表一个活动图是真的吗?
【发布时间】:2020-10-13 04:52:15
【问题描述】:

我曾经制作过一个活动图来表示具有 3 个参与者的用例。我为每个演员制作了一个泳道,因此我在活动图中有 3 个泳道。但是我的讲师说这是错误的,因为我应该有更多的活动图。他的意思是活动图基于用例图中的一个气泡(用例),而不是基于参与者。不过我浏览多了,发现我的讲师的话应该是时序图,而不是活动图。那么真实的说法是什么?我的第一个活动图或讲师的话?

【问题讨论】:

    标签: uml use-case activity-diagram


    【解决方案1】:

    你的导师是对的:

    • 用例图是关于系统必须提供什么来满足要求。每个用例对应于一组行为,这些行为可以在与参与者互动时执行,以帮助他们实现目标。
    • 活动图是关于系统如何执行基本行为或更复杂的行为集

    用例与系统内部无关。这是关于它的目的和与外界的主要关系。此类图中显示的用例之间绝对没有顺序。用户可能会阅读它并得到“对我有什么好处?”这个问题的答案。

    相反,活动与外部世界无关,也与演员无关。它是关于系统内部的:它的内部流,它遵循可以从控制和数据流语义中推断出来的顺序。开发人员可以阅读它并获得“这将如何工作?”问题的答案

    如果您知道某些活动是在与某些参与者交互的情况下执行的,并且如果您认为这很重要,您可以在模型中使用activity partition(以图形方式表示为“泳道”)传达此知识。但请注意,分区并非旨在映射到参与者或环境的其他元素。分区允许对具有一些共同特征的活动节点进行可视化分组。它们通常用于突出显示哪个组件或类在做什么。

    总之,活动和用例之间不一定存在直接映射,因为它们代表不同的现实。但是,如果存在这样的映射,则每个用例(气泡)至少有一个活动图。

    PS:稍作编辑以避免术语混淆:“swimline”是一个非 UML 术语coming from process modeling,它描述了一个图形布局,“partition”是一个模型中活动图的细分

    【讨论】:

    • @GeertBellekens 感谢您的两点合理评论。 1)我特意使用了这两个词:“分区”让 OP 熟悉 UML 术语,以及“泳道”,因为这是 OP 知道的,所以他/她可以连接点,因为泳道是视觉术语。顺便说一句,两者并不相互排斥:UML2.5 在第 406 页上使用了 4 次“泳道”来描述如何绘制分区 ;-)。
    • 我没有在规范中搜索“泳道”这个词。在 Sparx 中有一个非 UML 的泳道概念,即纯粹的可视化,还有 UML 的 ActivityPartition 概念,它实际上是模型的一部分。
    • @GeertBellekens 2) “非正式”可能不合适。但是我认为分区留给建模者选择,根据第 15.6.3.1 节“......是一种......用于识别具有一些共同特征的活动节点”。我认为“与某种演员互动”是一个有效的特征,即使这不是我个人的第一选择。如果考虑 EBC,则用例与不同参与者的每次交互将顺便对应于不同的分类器,这也是有效的分区。但如果我错过了什么,我准备编辑:-)
    • @GeertBellekens: ActivityPartitions 实际上不能拥有节点。他们只引用它们。它们是模型的一部分,因此它们不是“非正式的”。然而,语义没有很好的定义,因此有人可能会争辩说,它们在某种程度上是非正式的。当然,在定义了形式语义的情况下,还有表示的 elementtype 和 actiontype 的组合。
    • @AxelScheithauer 是的,确实,你是对的。 ActivityPartition 与 ActivityNodes 和边之间的关系称为 Contained,但 ActivityPartition 以及边和节点都应归 Activity 所有。甚至有一个明确的约束是这样说的。似乎 Sparx 通过强制节点归 ActivityPartition 所有来实现这个错误。
    【解决方案2】:

    活动图没有演员。

    它们旨在显示从一个活动(用例)到另一个活动(用例)的消息流。您可以阅读有关此here 的更多详细信息。

    活动图服务于以下主要目的,它:

    • 绘制系统的活动流,
    • 描述了从一项活动到另一项活动的顺序,并且
    • 描述了系统的并行、分支和并发流程。

    【讨论】:

    • @MeyLin 没问题。我希望它有助于澄清事情。
    【解决方案3】:

    没有一种方法可以指定用例。 UML 没有描述如何去做。因此,许多作者对如何做到这一点有不同的想法。因此,您使用分区(您称它们为泳道)来表示 Actor 的想法是有效的,只要它有助于您将用例传达给您的利益相关者。

    但是,当您的讲师有不同的意见时,这对您没有帮助。他或她可能有充分的理由发表这种说法。可能在他或她所经历的情况下效果很好。

    一些作者建议使用交互图。由于用例描述了参与者如何使用系统,换句话说,他们如何与系统交互,这可能是一个不错的选择。这里的问题是,大多数人只知道交互的序列图,它们不太适合描述实现用例目标的所有不同方式。

    因此,许多人使用活动图,即使官方无法描述参与者与系统之间的交互。它们实际上是为了描述一个系统的内部运作(当然也可以是一个人系统)。因此,您的活动图正式意味着该活动调用参与者的行为。我不认为那是你的想法。

    由于许多人仍然使用活动图来描述用例,我认为您对分区的解释并没有那么遥远。我个人认为,分区会使建模器的运行变得不必要地更加困难,因此不会使用它们。

    如果您选择使用活动来描述用例,则应该是每个用例一个活动。

    【讨论】:

    • 有趣。只是一个实际问题:假设 OP 有一个包含 3 或 4 个独立用例的用例图;当 UC 之间没有确定的顺序时,您将如何在单个活动图中对这些进行建模?是否允许多个初始节点不同时触发?
    猜你喜欢
    • 2021-05-21
    • 2017-04-23
    • 1970-01-01
    • 1970-01-01
    • 2011-12-23
    • 2018-06-13
    • 1970-01-01
    • 1970-01-01
    • 2021-10-11
    相关资源
    最近更新 更多