【问题标题】:How to visualize collaborative activities in an UML activity diagram?如何在 UML 活动图中可视化协作活动?
【发布时间】:2022-10-17 05:30:15
【问题描述】:

我目前坚持为许多用户以协作方式发生的工作流建模活动图。它有点类似于多个用户同时编辑和验证同一个 Confluence 页面,所以我决定用这个作为一个易于理解的示例。

单个用户的工作流程如下所示:

用户编辑一个页面(在我的例子中是复杂的活动),发布它,然后在发布的页面上执行某种验证(另一个复杂的活动)。如果不满意,则用户返回编辑页面并重复此循环直到满意。

现在想象一下它的协作版本(这当然是一个可怕的工作流程,但想象一下你无论如何都必须对其进行建模):

多个用户协作编辑同一页面,并且在任何时候,其中一个用户都可以发布当前内容并开始验证到目前为止已编辑的内容。但是,其他用户将停留在编辑步骤中,并且可能会在第一个用户进行验证时编辑更多内容。各个用户的“状态”是相互独立的,因此用户 1 可以开始验证,然后用户 2 和 3 可以发布更改并开始验证,同时用户 1 回到编辑状态,在此期间用户 4 发布更改等。 只有在所有用户都决定不再需要任何更改后,工作流程才会结束。

这就引出了一个问题:我将如何更改图表来表达我在这里描述的协作工作流程? 整个活动图是一个<<parallel>>扩展区域吗?我要在最后添加一个同步点吗?它是一个 <<iterative>> 区域吗?还是内部活动是平行的,而不是整个工作流程?

【问题讨论】:

  • 你不能显示任何事物在一张图中。将其拆分为几个重要的场景并分别显示。这不是你展示它的唯一方式。以上将是晴天然后添加一个并发编辑,其中一个覆盖另一个编辑器的更改等。
  • 此外,您可能会为文档使用状态机,这样您就可以展示如何进行并发编辑(这可能很难到没有限制)。
  • 虽然我首先赞成这个问题,但现在我发现它没有简单的答案。协作工作非常复杂,您无法给出简明的答案,这就是为什么我现在投票赞成结束这个问题过于宽泛。

标签: architecture uml modeling activity-diagram


【解决方案1】:

如果所有Example 编辑/验证周期都是独立的,即用户编辑页面以进行他/她的更改并独立验证他/她的更改,那么您当前的表示会很好,因为工作流程将为每个用户开始和结束独立。

如果您想明确记录多个用户可以并行启动这些活动,则需要一个“封闭”活动图,该图显示多用户上下文而不破坏各个循环。该活动将有一个调用Example 编辑/验证循环活动的CallBehavioraction。为了显示并发情况,您确实会使用扩展区域,或者更好的是简写符号:

小星星看起来像一个类型,但实际上它意味着该活动有多个并发执行:

(UML 2.5.1 规范,第 483 页): (...) 不是使用模式关键字,而是在符号的右上角放置一个“*”(这旨在表示“多次执行”。符号映射到包含 CallBehaviorAction 的扩展区域(如图 16.50 所示)mode=parallel。

(注意:引号中缺少的右括号是规范中的错字)。

如果编辑/验证周期不是那么独立,例如,如果验证不仅要验证本地更改,还要验证其他人所做的更改,它会更复杂:

  • 首先,您需要以某种方式明确协作编辑或将更改与其他更改合并。
  • 那么,如果这个修改后的模型允许每个用户独立考虑每个“联合循环”,那么最好使用与上述相同的方法。但如果没有,您需要将其封闭为扩展区域。我不得不承认,我不清楚它的模式应该是parallel 还是stream
  • 然后,您还需要澄清其他用户在验证后所做的更改是否需要已经验证的用户在不进行任何更改的情况下重新验证​​。这可能需要进一步增强您的初始周期。

【讨论】:

  • 我确实在考虑用户最终同意整个内容,例如也许每个用户都会写一章,但也会验证其他章节,我本可以更清楚一点。对单个组合循环进行建模并将上面的一个级别用作并行活动或并行活动的想法听起来很有希望,我会尝试看看我是否可以使用它。
【解决方案2】:

这不是一个真正的答案,但评论太长了。问题在于你的问题本身。


假设您有一些内容,并且两个人同时编辑它以纠正两个不同位置的拼写错误。那可能是处理琐碎.但现在假设内容存在需要修复的矛盾。假设您在开头有一个声明 A,在结尾有 not A。现在你有两个编辑器。第一个将修复它以具有整体A 含义,第二个将其更改为整体not A。那里有冲突。

很多的处理方法。这就是重点。您必须定义这些方式。就像您可以按顺序一个接一个地制造汽车一样,还有一种方法可以并行化构建。但只能按照严格的规定。没有你,只会以一团糟结束。

那么结论是什么?清楚你想做什么以及你的目标是什么。然后才开始处理细节。反之亦然。

【讨论】:

  • 虽然您对制造过程是正确的,但想想 Confluence(或任何其他 Wiki)之类的东西:他们实际上并没有定义协作方式;他们只允许几个用户编辑同一个页面,查看其他人正在输入的内容,并添加了一个任何人都可以在任何给定时间按下的发布按钮。如果一个用户这样做,则该内容状态将被发布,但其他用户仍处于编辑模式。这意味着用户自己定义他们想要如何协作。我们的情况实际上是相似的,因为输出是数据,而不是要出售的产品。
  • 好吧,如果他们允许这样做,那只会导致一团糟。两个相互竞争的编辑不会产生有意义的结果。他们需要沟通并就必须做的事情达成一致。我只在 Confluence 上工作了很短的时间(我不喜欢它)。幸运的是,我没有遇到这样的竞争,可能是因为有一次我是唯一的编辑。在任何情况下,如果允许,它应该被丢弃用于最糟糕的设计。
  • 我已经成功地使用了最多六个人的 Confluence 协作编辑功能:想象它就像一个白板,周围站着六个人,每个人都有一支笔。当然,您需要主持这样的会议,但有一些方法可以做到这一点,而且它可能很有效,这取决于主持人。
  • 你去吧。你需要一个版主。模拟他的角色,你就完成了。
【解决方案3】:

我想知道这是你想要的吗?这是一种选择。

https://imgur.com/gallery/uIR4qUQ

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-04-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多