序列图能否以与代码相同的深度真实地捕获您的逻辑？
我一直使用 UML 序列图，并且熟悉 UML2 表示法。
但我只用它们来捕捉我想做的事情的本质。 换句话说，该图始终存在于实际代码之上的抽象级别。 每次我使用它们来尝试准确描述我打算做什么时，我最终会使用太多的水平空间和太多的替代/循环框架，以至于不值得付出努力。
所以理论上是可能的，但是有人真正使用过这个详细程度的图表吗？ 如果是这样，您能提供一个例子吗？
I use UML Sequence Diagrams all the time, and am familiar with the UML2 notation.
But I only ever use them to capture the essence of what I intend to do. In other words the diagram always exists at a level of abstraction above the actual code. Every time I use them to try and describe exactly what I intend to do I end up using so much horizontal space and so many alt/loop frames that its not worth the effort.
So it may be possible in theory but has anyone every really used the diagram in this level of detail? If so can you provide an example please?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我有同样的问题，但当我意识到我的水平很低时，我重新阅读了以下内容：
I have the same problem but when I realize that I am going low-level I re-read this:
这都是相对的。 制作图表时，收益递减定律始终适用。 我认为展示对象之间的交互很好（objectA 初始化 objectB 并在其上调用方法 foo）。 但展示函数的内部结构是不切实际的。 在这方面，序列图无法捕获与代码相同深度的逻辑。 我会主张复杂的逻辑，你会想要使用流程图。
It's all relative. The law of diminishing returns always applies when making a diagram. I think it's good to show the interaction between objects (objectA initializes objectB and calls method foo on it). But it's not practical to show the internals of a function. In that regard, a sequence diagram is not practical to capture the logic at the same depth as code. I would argue for intricate logic, you'd want to use a flowchart.
我认为有两个问题需要考虑。
具体
当序列图用于传达单个具体场景（例如用例）时，它们是最好的。
当您使用它们来描述多个场景时，通常是为了显示用例中每条可能路径中发生的情况，它们很快就会变得复杂。
由于源代码在这方面就像一个用例（即一般描述而不是特定描述），因此序列图不太适合。 想象一下，扩展某个方法的调用图的 x 层，并在单个图表上显示所有信息，包括所有 if 和 if 。 循环条件..
这就是为什么正如您所说的“捕捉本质”如此重要。
理想情况下，序列图适合一张 A4/Letter 页面，任何更大的内容都会使图表变得笨重。 也许根据经验，将对象数量限制为 6-10 个，将调用数量限制为 10-25 个。
关注通信
序列图旨在突出通信，而不是内部处理。
当涉及到指定发生的通信（涉及方、异步、同步、立即、延迟、信号、调用等）时，它们非常具有表现力，但在内部处理时则不然（实际上只有操作）
此外，尽管您可以使用变量，但它远非完美。 顶部的对象是对象。 您可以将它们视为变量（即使用它们的名称作为变量），但这不是很方便。
例如，尝试描述链表的遍历，您需要使用序列图来密切关注某个元素及其前任元素。 您可以使用两个名为“当前”和“上一个”的“变量”对象，并添加必要的操作以使 current=current.next 和 previous=current 但结果很尴尬。
I think there are two issues to consider.
Be concrete
Sequence diagrams are at their best when they are used to convey to a single concrete scenario (of a use case for example).
When you use them to depict more than one scenario, usually to show what happens in every possible path through a use case, they get complicated very quickly.
Since source code is just like a use case in this regard (i.e. a general description instead of a specific one), sequence diagrams aren't a good fit. Imagine expanding x levels of the call graph of some method and showing all that information on a single diagram, including all if & loop conditions..
That's why 'capturing the essence' as you put it, is so important.
Ideally a sequence diagram fits on a single A4/Letter page, anything larger makes the diagram unwieldy. Perhaps as a rule of thumb, limit the number of objects to 6-10 and the number of calls to 10-25.
Focus on communication
Sequence diagrams are meant to highlight communication, not internal processing.
They're very expressive when it comes to specifying the communication that happens (involved parties, asynchronous, synchronous, immediate, delayed, signal, call, etc.) but not when it comes to internal processing (only actions really)
Also, although you can use variables it's far from perfect. The objects at the top are, well, objects. You could consider them as variables (i.e. use their names as variables) but it just isn't very convenient.
For example, try depicting the traversal of a linked list where you need to keep tabs on an element and its predecessor with a sequence diagram. You could use two 'variable' objects called 'current' and 'previous' and add the necessary actions to make current=current.next and previous=current but the result is just awkward.
就我个人而言，我仅使用序列图来描述不同对象之间的一般交互，即作为快速的“时间交互草图”。 当我试图更深入地了解时，一切很快就开始变得混乱......
我发现最好的妥协是一个“简化”的序列图，然后是对底层逻辑的清晰但深入的描述。
Personally I have used sequence diagrams only as a description of general interaction between different objects, i.e. as a quick "temporal interaction sketch". When I tried to get more in depth, all quickly started to be confused...
I've found that the best compromise is a "simplified" sequence diagram followed by a clear but in depth description of the logic underneath.
答案是否定的 - 它确实比源代码更好地捕获它！
至少在某些方面。 让我详细说明一下。
您 - 像大多数程序员一样，包括我 - 在源代码行中思考。 但软件最终产品——我们称之为系统——远不止于此。 它只存在于您的团队成员的脑海中。 在更好的情况下，它也存在于纸质或其他记录形式中。
有很多标准“视图”来描述该系统。 像 UML 类图、UML 活动图等。每个图都从另一个角度显示系统。 您有静态视图、动态视图，但在架构/软件文档中您不必就此止步。 您可以用自己的话呈现非标准视图，例如部署视图、性能视图、可用性视图、公司价值观视图、老板最喜欢的事物视图等。
每个视图捕获并记录系统的某些属性。
认识到源代码只是一种视图非常重要。 最重要的是，因为它需要生成计算机程序。 但它并不包含您系统的所有信息，无论是明确的还是隐含的。 （例如，程序模块之间的共享数据，仅通过离线用户活动连接。源中没有踪迹）。 它只是一个静态视图，对理解你的进程、你的生命呼吸程序的运行时动态几乎没有帮助。
观察者模式的经典示例。 特别是如果它被大量使用，你很难从源代码中理解系统机制。 这就是在这种情况下使用序列图的原因。 它比源代码更好地捕获系统的“动态逻辑”。
但是，如果您想详细了解某种业务逻辑，那么最好使用纯文本/源代码/伪代码等。您不必仅仅因为 UML 图是标准就使用它们。 您可以使用用例建模而无需绘制用例图。 始终选择最适合您和您的目的的视图。
The answer is no - it does capture it better then your source code!
At least in some aspects. Let me elaborate.
You - like the majority of the programmers, including me - think in source code lines. But the software end product - let's call it the System - is much more than that. It only exists in the mind of your team members. In better cases it also exists on paper or in other documented forms.
There are plenty of standard 'views' to describe the System. Like UML Class diagrams, UML activity diagrams etc. Each diagram shows the System from another point of view. You have static views, dynamic views, but in an architectural/software document you don't have to stop there. You can present nonstandard views in your own words, e.g. deployment view, performance view, usability view, company-values view, boss's favourite things view etc.
Each view captures and documents certain properties of the System.
It's very important to realize that the source code is just one view. The most important though because it's needed to generate a computer program. But it doesn't contain every piece of information of your System, nor explicitly nor implicitly. (E.g. the shared data between program modules, what are only connected via offline user activity. No trace in the source). It's just a static view which helps very little to understand your processes, the runtime dynamics of your living-breathing program.
A classic example of the Observer pattern. Especially if it used heavily, you'll hardly understand the System mechanis from the source code. That's why you use Sequence diagrams in that case. It captures the 'dynamic logic' of your system a lot better than your source code.
But if you meant some kind of business logic in great detail, you are better off with plain text/source code/pseudocode etc. You don't have to use UML diagrams just because they are the standard. You can use usecase modeling without drawing usecase diagrams. Always choose the view what's the best for you and for your purpose.
UML 图是指导方针，而不是严格的规则。
您不必精确地制作它们，也可以不精确地绘制它们。 详细信息如源代码，但是，如果您愿意，您可以尝试一下。
有时，可以做到，有时则不可能，因为系统的细节或复杂性，或者没有时间或细节来做到这一点。
干杯。
PD
有给猫吃的奶酪汉堡或金枪鱼汉堡吗？
U.M.L. diagrams are guidelines, not strictly rules.
You don't have to make them exactly & detailed as the source code, but, you may try it, if you want it.
Sometimes, its possible to do it, sometimes, its not possible, because of the detail or complexity of systems, or don't have the time or details to do it.
Cheers.
P.D.
Any cheese-burguer or tuna-fish-burguer for the cat ?