我想通过图表来表示我的程序的逻辑,因为程序非常复杂;我需要一种方法来向另一个人解释为什么以及如何在我的程序中发生某些事情。流程图是唯一的选择吗?
4 回答
在 UML 中,不同的图表用于不同的事物,使用不同的方法。考虑到我们倾向于倾向于面向对象的方法,我将解释不同的图表以及它们是如何工作的。
用例图——用例模型的重点是识别和定义系统必须支持的所有基本业务流程。这是从用户和系统的角度来看的。系统中的任何单个操作都可以在用例中使用,这将允许使用更多的解释性模型。
活动图- 这是一种用于描述用例图中发生的事情的工作流程图。它基本上是一种描述一个活动或多个活动的流程的视觉方法。
序列图- 这是显示系统或流程中不同对象之间通信的图表。序列图在分析中很重要,因为它们对于详细的系统设计和用户界面设计至关重要。我真的很喜欢这些,因为它们可以很好地了解系统中正在发生的事情。
状态机图- 这使您可以跟踪对象在其整个生命周期中的状态,从而深入了解对象的工作方式。这提供了如何在系统中有效地映射事件等的能力。
使用上述图表为分析和设计提供了很好的基础,并且应该注意,一旦创建了这些图表,它们不一定是完整的。在设计过程中,您将随着系统的发展改变这些图表。我希望这可以帮助你。以下是提到的不同图表的维基百科链接。
如果你需要一步一步地解释事情,那么流程图就是你所需要的。如果您可以在更高级别发言,则另一个选项可能是状态图。
每个程序的背后都有一个问题域,其中可能是一组由一群具有领域知识的人很好理解的问题,以及一个解决方案域,其中收集了解决此类问题的方法并用于处理问题。
要解释某事,您必须首先就问题域达成一致。如果您的问题领域是信号处理,并且要向不熟悉该领域的人进行解释,那么您已经干杯了。
然后您需要解释解决方案域(或参考工程手册中可能找到的一组众所周知的解决方案),以便您可以证明非常适合此特定问题和其他约束的特定解决方案选择是合理的放在答案上(在小型机器上运行,可以在一天内构建,等等)。如果您正在向其解释事情的人不理解快速傅立叶变换作为您选择的信号处理领域中问题的可能解决方案,那么您将无法解释解决方案,更不用说这是您最好的解决方案了选择。
一旦您通过了这两个障碍,那么流程图可能会有所帮助。其他各种类型的UML图等拐杖都是从各个角度解释解决方案的结构。哪种观点重要取决于解释的目的是什么。
关于流程图:虽然它们曾经很流行,但对于描述算法,伪代码通常就足够了。无法遵循伪代码的人也不太可能遵循大流程图。如果你的流程图很简单,你就不需要它。我已经 20 年没有认真使用过。大多数计算机科学文献似乎也没有使用它。
话虽如此,当人们想非常详细地了解一段实际代码在做什么时,尤其是出于自动化程序分析的目的,流程图(以“控制流”这个更高级的名称)仍然非常有用。请参阅COBOL 控制流图(请参阅此以获取解释)。很明显,您不想用它来向另一个人解释算法。