我一直使用 UML 序列图，并且熟悉 UML2 符号。
但我只用它们来捕捉我打算做的事情的本质。换句话说，图表总是存在于实际代码之上的抽象级别。每次我使用它们来尝试准确地描述我打算做什么时，我最终都会使用如此多的水平空间和如此多的 alt/loop 帧，这不值得付出努力。
所以理论上可能是可能的，但有没有人真正使用过这个详细程度的图表？如果是这样，你能提供一个例子吗？
Garth Gilmour
问问题
1975 次
6 回答
8
我有同样的问题，但是当我意识到我要低级时，我重新阅读了这个：
当您想查看单个用例中多个对象的行为时，您应该使用序列图。序列图擅长展示对象之间的协作；他们不太擅长对行为进行精确定义。
如果您想查看多个用例中单个对象的行为，请使用状态图。如果您想查看跨多个用例或多个线程的行为，请考虑使用 活动图。
如果您想快速探索多种替代交互，则最好使用CRC 卡，因为这样可以避免大量的绘制和擦除。有一个 CRC 卡会话来探索设计替代方案，然后使用序列图来捕获您以后想要参考的任何交互，这通常很方便。
[摘自 Martin Fowler 的UML Distilled书]
于 2008-09-29T20:30:49.480 回答
4
都是相对的。制作图表时，收益递减法则始终适用。我认为展示对象之间的交互很好（objectA 初始化 objectB 并在其上调用方法 foo）。但是展示函数的内部是不切实际的。在这方面，序列图在与代码相同的深度捕获逻辑是不切实际的。我会争论复杂的逻辑，你会想使用流程图。
于 2008-09-29T20:20:54.530 回答
2
我认为有两个问题需要考虑。
是具体的
当序列图用于传达单个具体场景（例如用例）时，它们处于最佳状态。
当您使用它们来描述多个场景时，通常是为了显示通过用例的每条可能路径中发生的情况，它们会很快变得复杂。
由于源代码在这方面就像一个用例（即一般描述而不是特定描述），因此序列图不太适合。想象一下扩展某个方法的调用图的 x 级别，并在单个图上显示所有信息，包括所有 if 和循环条件。
这就是为什么你所说的“捕捉本质”如此重要。
理想情况下，序列图适合单个 A4/Letter 页面，任何更大的东西都会使图表变得笨拙。也许根据经验，将对象数量限制为 6-10，将调用次数限制为 10-25。
专注于沟通
序列图旨在突出通信，而不是内部处理。
在指定发生的通信（相关方、异步、同步、立即、延迟、信号、调用等）时，它们非常有表现力，但在涉及内部处理时却没有（实际上只有动作）
此外，尽管您可以使用变量，但它远非完美。顶部的对象是对象。您可以将它们视为变量（即使用它们的名称作为变量），但这不是很方便。
例如，尝试描绘一个链表的遍历，您需要在其中使用序列图来密切关注元素及其前身。您可以使用两个名为“current”和“previous”的“变量”对象，并添加必要的操作以使 current=current.next 和 previous=current 但结果很尴尬。
于 2008-10-22T22:42:37.680 回答
1
答案是否定的 - 它确实比您的源代码更好地捕获它！至少在某些方面。让我详细说明。
你——和包括我在内的大多数程序员一样——思考源代码行。但是软件最终产品——我们称之为系统——远不止这些。它只存在于您的团队成员的脑海中。在更好的情况下，它也存在于纸上或其他记录形式中。
有很多标准的“视图”来描述系统。像 UML 类图、UML 活动图等。每个图都从另一个角度显示系统。您有静态视图、动态视图，但在架构/软件文档中您不必止步于此。您可以用自己的话来呈现非标准视图，例如部署视图、性能视图、可用性视图、公司价值视图、老板喜欢的东西视图等。每个视图都捕获并记录了系统的某些属性。
意识到源代码只是一个视图是非常重要的。最重要的是，因为它需要生成计算机程序。但它不包含您系统的每一条信息，也没有显式或隐式地包含。（例如程序模块之间的共享数据，仅通过离线用户活动连接。源中没有跟踪）。它只是一个静态视图，对理解您的流程、您的呼吸程序的运行时动态几乎没有帮助。
观察者模式的一个经典例子。特别是如果它大量使用，您将很难从源代码中理解系统机制。这就是在这种情况下使用序列图的原因。它比源代码更好地捕获系统的“动态逻辑”。
但是，如果您要详细说明某种业务逻辑，则最好使用纯文本/源代码/伪代码等。您不必仅仅因为它们是标准而使用 UML 图。您可以在不绘制用例图的情况下使用用例建模。始终选择最适合您和您的目的的视图。
于 2008-09-30T11:33:22.027 回答
1
就我个人而言，我只使用序列图来描述不同对象之间的一般交互，即作为快速的“时间交互草图”。当我试图更深入时，所有人很快就开始感到困惑......
我发现最好的折衷方案是“简化”序列图，然后对下面的逻辑进行清晰而深入的描述。
于 2008-09-29T20:27:52.407 回答
0
UML 图是指导方针，而不是严格的规则。
您不必将它们完全和详细地制作为源代码，但是，如果您愿意，可以尝试一下。
有时，它可以做到，有时，它不可能，因为系统的细节或复杂性，或者没有时间或细节去做。
干杯。
PD 有适合猫吃的芝士汉堡或金枪鱼汉堡吗？
于 2012-06-12T18:36:50.753 回答