【问题标题】:Visual Representation of Program Logic程序逻辑的可视化表示
【发布时间】:2026-02-17 20:55:02
【问题描述】:

我想通过图表来表示我的程序的逻辑,因为程序非常复杂;我需要一种方法来向另一个人解释为什么以及如何在我的程序中发生某些事情。流程图是唯一的选择吗?

【问题讨论】:

    标签: diagram


    【解决方案1】:

    在 UML 中,不同的图表用于不同的事物,使用不同的方法。考虑到我们倾向于使用面向对象的方法,我将解释不同的图表以及它们是如何工作的。

    • 用例图 - 用例模型的重点是识别和定义系统必须支持的所有基本业务流程。这是从用户和系统的角度来看的。系统中的任何单个操作都可以在用例中使用,这将允许使用更多的解释性模型。

    • 活动图 - 这是一种用于描述用例图中发生的事情的工作流程图。它基本上是一种描述一个活动或多个活动的流程的视觉方法。

    • 序列图 - 这是显示系统或进程中不同对象之间通信的图表。序列图在分析中很重要,因为它们对于详细的系统设计和用户界面设计至关重要。我真的很喜欢这些,因为它们可以很好地了解系统中正在发生的事情。

    • 状态机图 - 这使您可以跟踪对象整个生命周期的状态,从而深入了解对象的工作方式。这提供了如何在系统中有效地映射事件等的能力。

    使用上述图表为分析和设计提供了很好的基础,需要注意的是,一旦创建了这些图表,它们不一定是完整的。在设计过程中,您将随着系统的发展改变这些图表。我希望这可以帮助你。以下是提到的不同图表的*链接。

    Use Case Diagram

    Activity Diagram

    Sequence Diagram

    State Machine Diagram

    【讨论】:

      【解决方案2】:

      流程图是一种流行的选择,通常适合非技术人员。

      如果您有兴趣提供更技术性的情况视图,UML 可能是更好的选择。

      A sequence diagram 展示了组件如何相互交互。

      【讨论】:

      • 还有用例图。但基于这个问题,我同意 - 流程图将是我的首选。
      【解决方案3】:

      如果您需要一步一步地解释事情,是的,流程图正是您所需要的。如果您可以在更高级别发言,则另一个选项可能是状态图。

      http://en.wikipedia.org/wiki/State_diagram

      【讨论】:

        【解决方案4】:

        每个程序的背后都有一个问题域,其中可能是一组被一群具有领域知识的人很好理解的问题,以及一个解决方案域,其中收集并使用解决这些问题的方法来处理问题。

        要解释某事,您必须首先就问题域达成一致。如果您的问题领域是信号处理,并且要向不熟悉该领域的人解释,那么您已经干杯了。

        然后您需要解释解决方案域(或参考工程手册中可能找到的一组众所周知的解决方案),以便您可以证明非常适合该特定问题和其他问题的特定解决方案选择是合理的可能对答案施加的限制(在小型机器上运行,可以在一天内构建,等等)。如果您正在向其解释事情的人不理解快速傅立叶变换作为您选择的信号处理领域中问题的可能解决方案,那么您将无法解释解决方案,更不用说这是您最好的解决方案了选择。

        一旦你克服了这两个障碍,那么也许流程图可能会有所帮助。其他各种类型的UML图等拐杖都是从各个角度解释解决方案的结构。哪种观点重要取决于解释的目的。

        关于流程图:虽然它们曾经很流行,但对于描述算法,伪代码通常就足够了。不能遵循伪代码的人也不太可能遵循大流程图。如果你的流程图很简单,你就不需要它。我已经 20 年没有认真使用过。大多数计算机科学文献似乎也没有使用它。

        话虽如此,当人们想要非常详细地了解一段实际代码在做什么时,尤其是出于自动化程序分析的目的,流程图(以“控制流”这个更高级的名称)仍然非常有用。 见a COBOL control flow graph(见this for an explanation)。很明显,您不想用它来向其他人解释算法。

        【讨论】: