blocks|key|1189618|text|都是相对的。在绘制图表时，收益递减的规律总是适用的。我认为显示对象之间的交互很好(objectA初始化objectB并在其上调用foo方法)。但是，展示函数的内部结构是不实际的。在这方面，序列图不实用于捕获与代码相同深度的逻辑。我想说的是复杂的逻辑，你应该使用流程图。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189619|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|862280|text|就我个人而言，我只使用序列图来描述不同对象之间的一般交互，即作为一个快速的“时间交互草图”。当我试图深入了解的时候，大家很快就开始困惑.|type|unstyled|depth|inlineStyleRanges|entityRanges|data|862281|我发现，最好的折衷方法是“简化”序列图，然后是对下面的逻辑进行清晰而深入的描述。|862282|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|857900|text|我也有同样的问题，但当我意识到自己正在走向低谷的时候，我重读了一遍：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|857901|当您想查看单个用例中多个对象的行为时，应该使用序列图。序列图擅长于显示对象之间的协作；它们不太擅长行为的精确定义。
如果希望跨许多用例查看单个对象的行为，请使用状态图。如果您想查看跨许多用例或多个线程的行为，请考虑一个活动图。
如果您想快速地探索多种不同的交互方式，那么使用CRC卡可能会更好，因为这样可以避免大量的绘图和擦除。让CRC卡会话来探索其他设计方案，然后使用序列图来捕获您以后想要参考的任何交互操作，这通常是非常方便的。
[摘自马丁·福勒的https://rads.stackoverflow.com/amzn/click/com/0321193687书]|blockquote|offset|length|style|BOLD|857902|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0321193687^0|0|N|3|28|3|31|3|3T|4|6A|1K|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@$E|S|F|T|G|H]|$E|U|F|V|G|H]|$E|W|F|X|G|H]|$E|Y|F|Z|G|H]]|9|@$E|10|F|11|1|12]]|A|$]]|$1|I|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|J|$K|$5|L|M|N|A|$O|P]]]]

I have the same problem but when I realize that I am going low-level I re-read this: 

<blockquote>
 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 <a href="https://rads.stackoverflow.com/amzn/click/com/0321193687" rel="noreferrer" rel="nofollow noreferrer">UML Distilled</a> book]
</blockquote>

blocks|key|857917|text|答案是否定的-它确实比你的源代码更好地捕捉它！至少在某些方面。让我详细说明一下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|857918|你--喜欢大多数程序员，包括我--在源代码行中思考。但是软件的最终产品--让我们称之为系统--远不止这些。它只存在于您的团队成员的脑海中。在更好的情况下，它也存在于纸上或其他书面形式。|857919|有很多标准的“观点”来描述这个系统。与UML类图、UML活动图等类似，每个图都从另一个角度显示系统。您有静态视图、动态视图，但是在架构/软件文档中，您不必就此停止。您可以用自己的话表示非标准视图，例如部署视图、性能视图、可用性视图、公司价值视图、老板最喜欢的事物视图等。每个视图捕获并记录系统的某些属性。|857920|非常重要的是要认识到源代码只是一个视图。最重要的是，因为它需要生成一个计算机程序。但它并不包含系统的所有信息，也不是显式的或隐含的。(例如，程序模块之间的共享数据，仅通过脱机用户活动连接的数据)。源中没有任何痕迹)。这只是一个静态的视图，对于理解你的过程，你的呼吸程序的运行时动态几乎没有什么帮助。|857921|观察者模式的一个典型例子。特别是如果它被大量使用，您将很难从源代码中了解系统的机制。这就是为什么在这种情况下使用序列图的原因。它比源代码更好地捕捉了系统的“动态逻辑”。|857922|但是，如果您指的是某种非常详细的业务逻辑，那么您最好使用纯文本/源代码/伪代码等等，而不必仅仅因为UML图是标准的而使用它们。您可以使用usecase建模而无需绘制usecase图。总是选择对你和你的目的最有利的观点。|857923|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

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.

blocks|key|1189833|text|我认为有两个问题要考虑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1189834|成混凝土|1189835|当序列图被用于向单个具体场景(例如用例)传递时，它们处于最佳状态。|1189836|当您使用它们来描述多个场景时，通常是为了通过一个用例显示在每个可能的路径中发生了什么，它们会变得非常复杂。|1189837|因为在这方面，源代码就像一个用例(即一般的描述而不是特定的描述)，所以序列图是不合适的。想象一下，扩展某个方法的调用图的x级，并在一个图上显示所有这些信息，包括所有的if+&循环条件。|1189838|这就是为什么正如你所说的“捕捉精华”是如此重要。|1189839|理想情况下，顺序图适合于单个A4/字母页，任何更大的内容都会使图表变得难以处理。也许根据经验，将对象的数量限制在6-10个，调用的次数限制在10-25个。|1189840|注重沟通|1189841|序列图的目的是突出通信，而不是内部处理。|1189842|在指定发生的通信(涉及各方、异步、同步、即时、延迟、信号、呼叫等)时，它们非常有表现力。但是当涉及到内部处理时却不是这样(只有实际操作)|1189843|而且，尽管您可以使用变量，但这还远远不够完美。顶部的物体是，嗯，物体。您可以将它们视为变量(即使用它们的名称作为变量)，但这并不十分方便。|1189844|例如，尝试描述链接列表的遍历，其中需要用序列图保持元素及其前身的标签。您可以使用两个名为“current”和“previous”的“变量”对象，并添加必要的操作来生成current=current.next和previous=current，但是结果非常尴尬。|1189845|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|19|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1A|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Y|$]]

I think there are two issues to consider.

<h2>Be concrete</h2>

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 &amp; 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.

<h2>Focus on communication</h2>

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.

blocks|key|190598|text|UM.L.图是指南，而不是严格的规则。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|190599|您不需要将它们精确地作为源代码，但是，您可以尝试它，如果您想要的话。|190600|有时，因为系统的细节或复杂性，或者没有时间或细节去做，这是可能的，有时是不可能的。|190601|干杯。|190602|警察。给猫吃奶酪或金枪鱼吗？|190603|entityMap^0|0|J|0|F|J|0|0|15|0|0|3|0|0|E|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|O|$]]

U.M.L. diagrams are guidelines, not strictly rules.

You don't have to make them exactly &amp; 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 ?

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?

Can a Sequence Diagram realistically capture your logic in the same depth as code?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我一直使用UML序列图，并且熟悉UML2符号。但我只用它们来捕捉我想要做的事情的本质。换句话说，图表总是存在于实际代码之上的抽象级别上。每次我使用它们来精确地描述，，我打算做什么，我最终都会使用如此多的水平空间和如此多的alt/循环框架，这是不值得的。因此，在理论上这是可能的，但是否有人真的在这个层次的细节中使用了这个...

问序列图能否以与代码相同的深度真实地捕获您的逻辑？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问序列图能否以与代码相同的深度真实地捕获您的逻辑？EN