序列图能真实地捕获与代码相同深度的逻辑吗?

我也有同样的问题,但当我意识到我要走低水平时,我会重新阅读:

你应该用 序列图 当你想看行为时 一次使用的多个对象 案例。序列图擅长 显示 对象;他们不太擅长 行为的精确定义。

如果你想看看 跨多个用例的单个对象, 使用A 状态图 . 如果你想要 从多方面看行为 案例或多线程,考虑 活动图 .

如果你想探索多重 快速的交互,你 也许更好 CRC卡 , 因为这样可以避免很多绘画和 擦除。拥有一个 crc卡会话探索设计 然后使用序列 捕获任何交互的图表 你以后要提到的。

[ 马丁·福勒的摘录 UML Distilled 书 ]

都是相对的。当绘制图表时,收益递减定律总是适用的。我认为展示对象之间的交互是很好的(objecta初始化objectb并在其上调用方法foo)。但是显示函数的内部并不实际。在这方面,序列图不适用于捕获与代码相同深度的逻辑。我主张复杂的逻辑,你应该用流程图。

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

成为混凝土

当序列图被用于传达给单个具体场景(例如用例)时,它们处于最佳状态。

当您使用它们来描述多个场景时,通常是为了显示用例中每个可能路径中发生的事情,它们会变得非常复杂。

由于源代码在这方面就像一个用例(即一般描述而不是特定描述),序列图并不适合。想象一下扩展某个方法的调用图的x级别,并在单个图上显示所有这些信息,包括所有if&loop条件。

这就是你所说的“抓住本质”如此重要的原因。

理想情况下,序列图可以放在一张A4/Letter的纸上,任何较大的都会使该图变得笨拙。也许根据经验,可以将对象数限制在6-10,调用数限制在10-25。

注重沟通

序列图的目的是突出显示通信,而不是内部处理。

当涉及到指定发生的通信(涉及方、异步、同步、立即、延迟、信号、调用等)时,它们非常有表现力,但当涉及到内部处理时(仅限于真正的操作)

而且,尽管你可以使用变量,但它并不完美。顶部的物体是物体。你可以把它们看作变量(即用它们的名字作为变量),但这并不方便。

例如,尝试描述一个链接列表的遍历,在这个链接列表中,您需要用序列图来标记一个元素及其前一个元素。您可以使用两个名为“current”和“previous”的“variable”对象,并添加必要的操作以使current=current.next和previous=current,但结果很尴尬。

就我个人而言,我只使用序列图来描述不同对象之间的一般交互,即作为一个快速的“时间交互草图”。当我试图深入的时候,所有的人都很快开始困惑…

我发现最好的折衷方案是“简化”序列图,然后对下面的逻辑进行清晰但深入的描述。

答案是否定的-它确实比你的源代码更好地捕获它! 至少在某些方面。让我详细说明一下。

你——像大多数程序员一样,包括我——用源代码行思考。但软件最终产品——我们称之为系统——远不止这些。它只存在于你的团队成员的脑海中。在更好的情况下,它也存在于纸上或其他文件形式。

有很多标准的“视图”来描述这个系统。与UML类图、UML活动图等类似,每个图都从另一个角度显示系统。您有静态视图和动态视图,但在体系结构/软件文档中,您不必仅限于此。你可以用自己的语言表达非标准视图,例如部署视图、性能视图、可用性视图、公司价值观、老板最喜欢的事物视图等。 每个视图都捕获并记录系统的某些属性。

认识到源代码只是一个视图是非常重要的。但最重要的是因为它需要生成一个计算机程序。但它不包含系统的每一条信息,也不显式也不隐式。(例如,程序模块之间的共享数据,仅通过离线用户活动连接。来源中没有任何痕迹)。它只是一个静态视图,对理解进程、呼吸程序的运行时动态几乎没有帮助。

观察者模式的典型例子。尤其是如果它大量使用,您将很难从源代码中理解系统机制。这就是在这种情况下使用序列图的原因。它比源代码更好地捕捉系统的“动态逻辑”。

但是,如果您的意思是某种非常详细的业务逻辑,那么最好使用纯文本/源代码/伪代码等。您不必仅仅因为它们是标准的就使用UML图。您可以使用UCEASE建模而不绘制用例图。总是选择对你和你的目的最有利的观点。

U.M.L.图表是指导原则,不是严格的规则。

你 不必将它们作为源代码进行详细说明 但是,如果你想的话,你可以试试。

有时,这是可能的,有时,这是不可能的,因为系统的细节或复杂性,或没有时间或细节去做。

干杯。

P.D. 有给猫吃的奶酪布格或金枪鱼布格吗?