嵌套的序列图中使用alt是否是一个好的实践？

Question

4

我创建了一个序列图，发现它有多个嵌套的alt。

这是好的还是不好的实践方法？

如果这是不好的实践，那我应该怎么做呢？

- Ngọc Nguyễn

2个回答

1

有点类似。您可以这样做，这样做也没问题。但是，一旦您开始这样做，就有可能陷入图形编程的危险之中。曾经有人梦想图形编程是未来的解决方案。但事实上，代码更加紧凑易读。因此，请不要以这种方式编写程序。

现在来讲述该结构的用途。无论何时需要展示某些复杂的协作关系，参与者的图形概览将非常有帮助。但前提是只关注沟通的最重要部分。与其嵌套片段，最好拥有不同的SD来聚焦。您可以使用消息端点在详细图之间进行跨越。同样，这取决于您如何进行拆分。需要一些经验才能找到黄金比例。

- qwerty_so

我完全同意关于图形化编程的观点。最好使用UML来展示代码中不容易找到的东西。这完全符合精神：https://twitter.com/Grady_Booch/status/1388930413280727042?s=20 - Christophe

1

@Christophe 我记得在80年代初尝试过图形编程，但很快就放弃了这种方式。自那以后，每当我使用图形编程时，我总会感到不安，幸运的是这些经历总是短暂而丑陋的。 - qwerty_so

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Christophe · Accepted Answer

优秀、糟糕和丑陋

在没有客观标准的情况下，很难为好坏实践提供建议，而这取决于图表的目的：

如果您将UML用于某种视觉编程，其中综合性图表应显示特定交互的所有细节，则如果没有其他选择，则嵌套的alt可能是一个良好的实践。由于不同的生存期引导独立的选择(FusionAuth 的外部 alt，Occupations 的内部选择)，因此嵌套适当地表示了行为逻辑。但是，如果相同的生存期会推动决策，则展开的alt可能是更可读的方法，以简化分支。
如果您使用UML来沟通和理解系统，则应轻松理解图表：嵌套将是一个糟糕的做法，因为它增加了一层复杂性。

我们幸运地避免了丑陋的现象：多个分支中相同的嵌套alt。

UML的秘密是拥有更多的图表，但每个图表都要更小，专注于单个方面。您几乎可以在Booch、Jacobson和Rumbaugh的书《UML用户指南》的每章结尾处找到这个建议。

这里适用两种策略：

每个场景一个图表：主要成功方案将是一个图表，不同的失败方案将是其他图表。超级容易阅读。
关注点分离：不同的问题将在不同的图表中解决，例如，您可以通过其客户端分离使用Occupations和Occupations完成业务的方式：在两个图表中分别分离Manager、Client、Occupations和Occupations、FusionAuth和Database；您将避免嵌套alt，内部选择在第二个图表中，并且不一定与相同观众相关。

备注：我不是视觉编程的大粉丝。但是，如果您是，则第二种策略与之完全兼容，并具有防止在多个位置重复相同嵌套片段的优势。