基本困惑
来源：某软件设计说明书提纲：
1> 模块层次关系，用图表和文字描述模块内部各层次之间的控制与被控制关系。
2> 模块流程，用流程图表示模块的主要控制流程、处理流程及数据流程。
但是，我一直怀疑这个软件设计说明书模板是个“假的”，不知道从哪里鼓捣来的！当然自身水平欠佳，不能很好的使用该模块也是有很大可能的！
好久的一个后来，验证了上边的那个所谓的模板的确是一个“太面向过程的模板”，而我要做的是面向对象设计，本来就是菜鸟，又被指错了路，回想起来感觉“我太难了”。再后来我将更多的精力放在了UML学习上，并总结了一句话 “设计(说明书)不优美，必定谈不上是好设计!”。
零散概念
数据流和控制流的区别是什么 仅做部分参考，与要讨论的问题关系不大。
在软件设计或设计文档的编写过程中，你需要哪些图表来表述自己的设计思路呢？一个结构化的软件设计它的设计文档应该长什么样子？数据流图？程序流程图？UML活动图状态图?UML类图？UML交互图？
数据流图
数据流程图，数据流图，我认为他们是一个东西，但可爱的是在百科上他们却各占词条。在学习初期读过一位大哥的总结，也有所启发，后来结合百科等其他资料，理解大约如下。总的来说：
数据流图是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。在结构化开发方法中，数据流图是需求分析阶段产生的结果。
在大多软件设计资料中，不区分数据流程和数据流程图的含义，她们都是“数据流图”。如果非要区分，那么数据流程图应该是一种传统意义上的流程图，更偏向于visio中的那种基本流程框图。
数据流图不是传统的流程图或框图，数据流也不是控制流。数据流图是从数据的角度来描述一个系统，而框图是从对数据进行加工的工作人员的角度来描述系统。
DFD显示系统将输入和输出什么样的信息，数据如何通过系统前进以及数据将被存储在何处。它不显示关于进程计时的信息，也不显示关于进程将按顺序还是并行运行的信息，而不像传统的关注控制流的结构化流程图，或者UML活动工作流程图，它将控制流和数据流作为一个统一的模型。
软件工程数据流图画法，请参考。
层次图
Here,我们先不讨论要求在层次图中构建控制关系是否合理，先谈个小纠结，当给一个小小的字模块绘制层次图时，可能需要将子模块接口的概念体现到层次图中 ! 但这么做，层次图与类图相差无几啦！
类结构与层次关系，有这么一种情况：两个类在处理上是针锋相对的，如读操作和写操作，但常常他们是放在同一个目录下的，这样在绘制层次图时，我也很愿意将他们放置在一层，但有个问题，关系将变得很难表示，尤其是很难表示控制关系！
面向过程设计
Here主要谈下面向过程设计与面向对象设计的区别，目的在于理解“模板让你用图表描述系统内部各层次之间的控制与被控关系”。这里"层次"一词，是否在面向独享设计中，是一个偶尔或是完全不合群的词？
- 以五子棋的实现为例，试图说明谈一个设计的流程和层次的最佳场景…-
面向过程的设计思路就是分析问题步骤：开始游戏，黑子先走，绘制画面，判断输赢，轮到白子，绘制画面，判断输赢，返回步骤2，输出最后结果。
面向对象设计的基本思路则是，整个五子棋系统可以分为如下类或对象：黑白双方，负责接受用户输入。棋盘系统，负责绘制画面。规则系统，负责判定诸如犯规输赢等。
面向过程把每个步骤分别用函数实现，整个设计的“流程性”、“层次性”都是很直接的，也很容易理解。但是对于面向对象设计来说，上述两种性质，并不那么明显。OO方法采用对现实世界的自然映射，当现实业务流程变化时，软件有强大的应对需求变化的能力。
- 再来看下边一段官话（from UML活动图）
活动图被引入 UIML 中是有争议的，因为活动图实际上描述的是业务流程，是一种过程化的分析方法。《UML大象P105》因为在面向对象的眼中是没有业务流程这种东西的，所谓流程只不过是在某个外部力量推动下对象之间相互交流的一个过程，它只是“瞬时”的。如果从活动图的观点来描述业务，实际上是不能直接看到对象是如何发挥作用的。
泳道流程图，这里并不是要说UML活动图，而是流程图范畴的泳道图，它使用VISIO-跨职能流程图形状，来进行绘制。第一次研究到这里想用它，是为了表述一种跨（任务）线程的任务调度、交互关系，及任务间共享资源的竞争处理(尽管这可能不太合适，但当时就这么用了)。