我一直使用UML序列图，并且熟悉UML2表示法。

但是我只会用它们来捕捉我打算做的事情的本质。换句话说，该图始终以高于实际代码的抽象级别存在。每次我使用它们来尝试准确地描述我打算做什么时，我最终都会使用如此多的水平空间和如此多的alt / loop框架，这不值得付出努力。

因此，从理论上讲可能是可行的，但是每个人都真的在这个详细程度上真正使用过该图吗？如果可以，请提供示例吗？

解决方案

都是相对的。绘制图表时，收益递减定律始终适用。我认为最好显示对象之间的交互(objectA初始化objectB并在其上调用方法foo)。但是显示一个函数的内部是不切实际的。在这方面，时序图在与代码相同的深度处捕获逻辑是不切实际的。我会为复杂的逻辑辩护，我们想使用流程图。

就我个人而言，我仅将序列图用作不同对象之间一般交互的描述，即作为快速的"时间交互草图"。当我试图更深入地了解时，所有一切很快就开始混乱了。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。.........。。。。。。。。。。。。。。。。

我发现最好的折衷方案是一个"简化的"序列图，然后对其下方的逻辑进行清晰但深入的描述。

我有同样的问题，但是当我意识到自己要进入低级课程时，我会重新阅读以下内容：

You should use sequence diagrams
  when you want to look at the behavior
  of several objects within a single use
  case. Sequence diagrams are good at
  showing collaborations among the
  objects; they are not so good at
  precise definition of the behavior. 
  
  If you want to look at the behavior of
  a single object across many use cases,
  use a state diagram. If you want
  to look at behavior across many use
  cases or many threads, consider an
  activity diagram.
  
  If you want to explore multiple
  alternative interactions quickly, you
  may be better off with CRC cards,
  as that avoids a lot of drawing and
  erasing. It’s often handy to have a
  CRC card session to explore design
  alternatives and then use sequence
  diagrams to capture any interactions
  that you want to refer to later. 
  
  [excerpt from Martin Fowler's UML Distilled book]

答案是不，它的确比源代码更好地捕获了它！
至少在某些方面。让我详细说明。

我们喜欢大多数程序员，包括我在内的源代码行。但是软件最终产品，我们称它为System远不止于此。它只存在于团队成员的脑海中。在更好的情况下，它也可以书面形式或者其他文件形式存在。

有很多标准的"观点"来描述系统。像UML类图，UML活动图等。每个图从另一个角度显示系统。我们有静态视图，动态视图，但是在体系结构/软件文档中，不必到此为止。我们可以用自己的语言显示非标准视图，例如部署视图，性能视图，可用性视图，公司价值视图，老板喜欢的事物视图等。
每个视图都捕获并记录系统的某些属性。

意识到源代码只是一个视图，这一点非常重要。不过，这是最重要的，因为它是生成计算机程序所必需的。但是它不包含系统的每条信息，也不包含显式或者隐式的信息。 (例如，程序模块之间的共享数据，仅通过离线用户活动连接的数据。在源中无跟踪)。这只是一个静态视图，对了解过程以及实时呼吸程序的运行时动态几乎无济于事。

观察者模式的经典示例。特别是如果大量使用它，我们几乎不会从源代码中了解系统机制。这就是在这种情况下使用顺序图的原因。它比源代码更好地捕获了系统的"动态逻辑"。

但是，如果我们要详细说明某种业务逻辑，则最好使用纯文本/源代码/伪代码等。我们不必仅因为它们是标准而使用UML图。我们可以使用用例建模而无需绘制用例图。始终选择最适合我们和目的的视图。

我认为有两个问题要考虑。

具体一点

当序列图用于传达给单个具体场景(例如，一个用例)时，其处于最佳状态。

当我们使用它们来描述多个场景时，通常是为了显示用例在每种可能的路径中发生的情况，它们会很快变得复杂。

由于源代码在这方面就像一个用例(即一般描述而不是特定描述)，因此顺序图不太适合。想象一下扩展某种方法的调用图的x级别，并在单个图表上显示所有信息，包括所有if＆循环条件。

因此，正如我们所说的那样，"捕捉精华"是如此重要。

理想情况下，序列图可以放在单个A4 / Letter页面上，任何较大的序列图都会使该图变得笨拙。根据经验，可能将对象数限制为6-10，将调用数限制为10-25.

专注于沟通

顺序图旨在强调通信，而不是内部处理。

当指定发生的通信(涉及的各方，异步，同步，立即，延迟，信号，呼叫等)时，它们非常有表现力，而对于内部处理则不是(仅是真正的动作)

另外，尽管我们可以使用变量，但它远非完美。顶部的对象是对象。我们可以将它们视为变量(即使用其名称作为变量)，但这并不是很方便。

例如，尝试描绘一个链表的遍历，在该表中，我们需要使用顺序图在元素及其前身上保留制表符。我们可以使用两个名为"当前"和"上一个"的"变量"对象，并添加必要的动作以使" current = current.next"和" previous = current"生效，但是结果很尴尬。