程序逻辑的可视化表示

Question

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

Answer 1

在UML中，不同的图表适用于不同的事物，使用不同的方法。考虑到我们倾向于倾向于面向对象的方法论，我将解释不同的图表及其工作原理。

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

• 活动图 - 这是一种工作流程图，用于描述用例图中的内容。它基本上是一种描述活动流程或多种活动的直观方法。

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

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

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

Use Case Diagram

Activity Diagram

Sequence Diagram

State Machine Diagram

Answer 2

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

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

A sequence diagram显示了组件如何相互作用。

Answer 3

如果您需要逐步解释问题，那么流程图确实是您需要的。如果您可以在更高级别发言，则另一个选项可能是状态图。

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

Answer 4

在每个程序的背后都是一个问题领域，其中可能是一组知识渊博的人员和解决方案领域很好理解的问题，其中收集解决此类问题的方法并用于处理问题。

要解释一些事情，您必须首先就问题域达成一致。如果您的问题域是信号处理，并且解释是针对不熟悉域的人，那么您已经干了。

然后，您需要解释解决方案领域（或者参考工程手册中可能找到的一组众所周知的解决方案），这样您就可以证明特定选择的解决方案非常适合这个特定问题和其他问题。可能存在于答案上的约束（在小型机器中运行，可以在一天内构建，等等）。如果您正在解释事物的人不理解快速傅里叶变换作为您选择的信号处理领域中的问题的可能解决方案，那么您将无法解决该解决方案，更不用说这是您的最佳选择了选择。

一旦你通过了这两个障碍，然后也许一个流程图可能会很有帮助。诸如各种类型的UML图之类的其他拐杖都是关于从各种角度解释解决方案的结构。哪个视角很重要取决于解释的目的是什么。

关于流程图：虽然它们很受欢迎，但为了描述算法，伪代码通常足够好。无法遵循伪代码的人也不太可能遵循大流程图。如果您的流程图很简单，那么您不需要它。我没有在20年内认真对待过一个。大多数计算机科学文献似乎都没有使用它。

说到这一点，当人们想要非常精细地理解实际代码片段正在做什么时，特别是出于自动程序分析的目的，流程图（在更好的名称“控制流程”下）仍然非常有用。 请参阅a COBOL control flow graph（并参阅this for an explanation）。很明显，你不想用这个来向另一个人解释算法。