问如何将程序的设计可视化以便与其他人进行交流

EN

是否有特定的软件可用于您的程序的设计？

在我工作的地方，我们主要使用Visio。

如果是这样的话，请分享一些关于如何最有效地做到这一点的建议。

有流程图，用于程序流。对于程序组织，使用类似UML的(可能不严格符合UML标准，但没有人太担心这一点)的图表。

对于像你这样复杂的图表，使用一个工具来生成一个像这样的完整的系统图可能是一个很好的起点，只是为了了解事情的样子，但是我建议把它分解成许多小的图，也许是每个子系统的一个，你似乎已经包围了一个盒子。指向其他子系统的链接不应该指向这些系统中的模块，而应该指向子系统的名称。事实上，我认为在Visio中甚至可以在图表页之间创建链接，因此如果有人单击从一个复杂模块到另一个复杂模块的链接，他们就会直接被带到该模块。它还可能有助于在更高层次上创建一个图表--显示每个子系统之间的交互，而忽略每个较低级别的模块。

我会遵循类似的分而治之的策略来绘制这个系统的流程图。

试图在单个图中绘制这么大的系统是很困难的，如果结果太复杂，它很可能是无用的。我已经看过了，但是很难把它做好，他们不得不把它印在海报大小的纸上才能读懂。它贴在了4间面向走廊的隔间墙壁上，当一群分析人士聚集在它周围讨论可能的变化和影响时，它变得很烦人。到项目结束时，它已经覆盖了钢笔、铅笔和荧光标记.

UML是以图形方式表示程序的一个非常强大的选项。Grady和其他一组人写了一本很棒的书，名为“面向对象的分析与设计及其应用”，这本书非常严谨地介绍了OOAD，花了大约150页的时间讨论概念，然后再深入记谱。虽然在某些方面，图很容易理解而无需经过大量的训练，但是Booch在定义诸如复杂性、区分对象模型和类模型以及分类等概念方面是一位大师。有关复杂性的建议包括讨论几种工具，如算法分解、面向对象的分解、抽象、层次结构和封装。

重要的是要记住，您可能需要从多个角度来查看您的软件，以便能够捕获对象和类的静态结构和动态行为。类图将捕获一个或多个类的静态结构，而序列图将捕获两个或多个对象交互时的动态行为。Booch还将事物分解为结构图、行为图和交互图。

UML图

• 结构
  • 套餐
  • 班级
  • 组件
  • 部署
  • 对象
  • 复合结构

• 行为
  • 用例
  • 活动
  • 状态机

• 交互
  • 序列
  • 沟通
  • 互动概述
  • 计时

对于那些只能说出三到四个UML图的人来说，这应该是一个警钟。如果您在一周内每天花费一天或几个小时，您可能不太了解UML。通常，UML是四天课程，有时是面向对象分析的三到四天，然后是三到四天的面向对象设计。大学课程可以将其作为一个或多个学期课程教授，或者将其折叠成一个序列，用于遵循瀑布式软件生命周期(需求和分析(带有用例)、软件体系结构和/或设计(以及其他图表)、面向对象编程(使用Java、C++等)和测试(重新访问用例或状态图))。

马丁·福勒( Martin )有一本我喜欢的书，名为UML蒸馏，他在书中基本上列出了每种图表类型的模式，列出了它的名称、简短的描述、图表的示例以及弧、节点和装饰器的含义，最重要的是，何时使用它们。在他的介绍性材料中，他将UML描述为有三个应用程序:创建软件蓝图，作为生成代码的高级编程语言(有时是从代码中逆向工程师，或者在双向软件工程中前后转换)，或者我最喜欢的一个草图，帮助开发人员在设计的某些本地化和特定方面进行交流。

UML仇恨者在很多事情上都是正确的。例如，使用UML记录设计(在蓝图或编程语言模式中)可能涉及多少开销。他们有时会说，有工具的傻瓜仍然是傻瓜。对于一个没有经过充分培训的开发人员来说，跳入生成图是个坏主意，就像FORTRAN程序员开始用C++或Java从一个表中编写哪些语句是等价的一样。借助计算机辅助软件工程(CASE)工具的UML图表编辑器(CASE已经受了许多批评)，糟糕的设计人员有可能更快地完成大的糟糕的设计。

UML爱好者会指出，它允许我们以视觉和表达的方式交流我们的设计。由于我们以多种方式表示相同的设计，它为我们编写的代码提供了一个很好的预演。因为它是可见的，它促进了一种更快的与他人交流的形式(我们处理视觉信息的速度远远快于口头和间接，而不是文本)，并为我们提供了许多同行评议的机会。因为我们使用了多个视图，所以它允许我们在分层视图(如部署图、包图和类图)之间移动。我们可以在对象图中看到rest中的相同信息，在活动图和序列图中看到相同的信息。通过使用相关图，我们可以尽早发现问题的完整性和一致性，有时还可以使用像状态图一样容易生成的表示来在另一个图(如序列图)中发现所需的内容。

一般来说，有各种各样的工具来传达程序的设计。像UML和对象图这样的工具对您来说应该足够了。

还在需要时在代码中包含注释。