序列图中的嵌套 alt 是一种好习惯吗？答案

【问题标题】：Is nested alt in sequence diagram a good practice?序列图中的嵌套 alt 是一种好习惯吗？
【发布时间】：2021-12-30 04:15:40
【问题描述】：

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

这是一种好习惯还是坏习惯？

如果这是一个不好的做法，我应该怎么做？

【问题讨论】：

【解决方案1】：

好的、坏的和丑陋的

如果没有客观标准，很难就好的和坏的做法给出建议，这取决于图表的目的：

如果您将 UML 用于某种可视化编程，其中一个全面的图表应该显示特定交互的所有细节，嵌套alt 可能是一个好如果别无选择，请练习。由于不同的生命线正在驱动独立的替代方案（FusionAuth 外部alt，Occupations 内部），因此嵌套适当地代表了行为逻辑。但是，如果同一条生命线可以推动决策，那么扁平化的 alt 可能是一种更易读的方式，将更复杂的嵌套与更多但更简单的分支进行交换。
如果您使用 UML 对系统进行交流和推理，那么图表应该很容易理解：嵌套将是一种不好的做法，因为它增加了一定程度的复杂性。

幸运的是，我们避免了丑陋：在多个分支中嵌套相同的 alt。

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

这里有两种策略：

每个场景的图表：主要的成功场景是一个图表，不同的失败场景是其他的。超级容易阅读。
Separation of concerns：不同的问题将在不同的图表中解决，例如，您可以将其客户对 Occupations 的使用与 Occupations 的业务方式分开：单独的 Manager、Client、Occupations 和Occupations、FusionAuth 和 Database 在两个图中；您应避免嵌套 alt，内部的位于第二张图中，不一定与同一受众相关。

备注：我不是可视化编程的忠实粉丝。但如果你是，第二种策略完全兼容它，优点是可以防止丑在几个地方重复相同的嵌套片段。

【讨论】：

第一种策略易于实施，但会产生大量图表且难以管理。第二种策略很棒，但对于像我这样没有经验的开发者来说很难实施，但值得一试:)
@NgọcNguyễn 缺乏经验可能很难实施，因为识别问题并了解如何最好地解耦并不明显。但这确实值得一试，因为关注点分离比建模更通用。有时由于底层设计的缺陷，很难将图表解耦。您尝试得越多，您的设计技能就会提高得越好。

【解决方案2】：

有点。你可以这样做，它会好起来的。然而，一旦你开始这样做，你就有陷入图形编程的危险。曾几何时，人们梦想将图形编程作为未来的解决方案。简单地说，它不是。代码更密集，更容易阅读。所以不要以这种方式开始编写程序。

现在使用该构造。无论您想在哪里展示一些复杂的协作，参与者的图形概览都会非常有帮助。但前提是你坚持沟通中最重要的部分。与其嵌套片段，不如关注不同的 SD。您可以使用消息端点在详细图之间进行交叉。同样，这取决于您如何进行拆分。找到黄金比例需要一些经验。

【讨论】：

我完全同意图形化编程。更好地使用 UML 来显示在代码中不容易找到的东西。完全精神：twitter.com/Grady_Booch/status/1388930413280727042?s=20
@Christophe 我记得在 80 年代初尝试过关于图形编程的尝试，但很快就停止了。自从我在使用图形编程时感到毛骨悚然，幸运的是总是遇到短暂的丑陋遭遇。