都过了好久才看到,好**啊

  

  

好帖，让我不得不顶啊！！

刚在一个行业起步的时候，流程图还是有用的，至少可以帮助他加快理解，所以这个时候，很多工程师都会画画流程图，即使是抽象性的简易流程图，一般也会弄个草稿看看，但混一个行业时间长了后，即使不成高手只是一个熟手，一般也都不怎么画流程图了，因为他接受这个设计任务的时候，其实已经差不多把设计中需要的资源分配和系统开销计算的差不多了，真正动手的时候，无非就是把大脑中的思维变换成实际的代码而已，此时大家习惯的做法往往是写代码，再补图纸，补图纸的目的一般都不是给自己看的，呵呵，往往是企业文档整理、图纸规范的需要。<br /><br />但如果是一个大的项目，需要多小组协作写代码，那先写技术文档则是必须的了，单枪片马干基本就无所谓了，但在MCU这方面的编程，绝大多数还是靠个人英雄主义就能搞定的，呵呵，工程师希望自己能搞定这些，很多企业也都希望能由1~2个人，因为项目组人员比较精简的话，项目管理起来比较好做，而且电子产品的开发周期一般不长，电子产品开发周期太长的话，大家就只能喝西北风了，所以代码开发的时间也不会太长，这肯定和PC上很多软件有些差异，显然的是：因此造成不提前做技术文档反而比做技术文档的企业发展速度更快的现象。。。

为了赶工期而忽略掉文档的现象普遍存在。

  

同意,<br />让教科书见鬼去吧!

  

而是缺乏理论知识。<br />就比如按键，串口这样的初级东东，上过几天课堂的人都会画流程图，而且可以画得极为漂亮。可是动手做起来，才发觉用流程图做出来的程序经常和其它程序冲突。<br /><br />俺作为农民讲习所的讲师，是极其藐视画流程图的，因为程序是不能用流程图表达的，应该用层次图表达。<br />画流程图，是单细胞们干的事情。

用图形的方式来表达一个程序的流程，或者说是编程者的思想，确实是个很大的进步，但图形也会带来图形表达固有的缺陷，这个是没办法避免的~

记号下，改天看

  

留个号。

五、数据流图（DFD）<br /><br />1、数据流图简介<br /><br />前面介绍的三种程序规划方法，都是从算法的角度来分解程序的流程。然而，把程序或软件理解为算法是片面的。完整的理解是：“程序=数据结构+算法”。因此在程序规划的过程中，我们可以从另一个角度——数据的流向——来分析系统。<br /><br />这就是这一节要介绍的数据流图。<br /><br />数据流图，即DFD（data&nbsp;flow&nbsp;diagram），又被称为数据流程图。是软件需求分析阶段的重要描述手段。<br /><br />数据流图是从数据流向的角度来描写软件功能要求系统的组成和各部分之间联系的一种方法。它的具有直观、简洁等优点，软件开发人员及用户易于理解和接受。<br />

2、数据流图的4要素<br /><br />在匠人看到的一些资料文献中一般都把数据流图分解为外部实体（数据源和数据终点）、处理（加工）过程、数据流、数据存储（文件）等四部分。下面依次介绍：<br /><br />（1）外部实体：又被称为数据源（输入实体）和数据终点（输出实体）。代表了数据的外部来源和去处。也就是说，外部实体属于系统的外部和界面。它是独立于系统之外，但又和系统有联系的人或事物。<br /><br />（2）处理过程：是对数据进行加工的环节。这种加工处理包括算术、逻辑运算处理，或者进行数据变换。它用来改变数据值。每一个处理过程又包括了数据输入、加工和输出3个部分。<br /><br />（3）数据流：代表数据处理过程的输入或输出。数据流指示了数据在系统中的传递流向。<br /><br />（4）数据存储：代表数据保存的地方，它用来存储数据。系统处理从数据存储中提取数据，也将处理的数据返回数据存储。<br /><br />以上介绍的这四个部分又被称为数据流图的4要素。<br />

<H4>3、数据流图的画法</H4><br />在不同的文献中，对4个要素的定义和描述都不同，甚至连它们的画法也不完全统一。下面是数据流图的常见画法（参见图&nbsp;1.32：数据流图举例）：<br />&nbsp;<br /><img src="http://blog.21ic.com/UploadFiles/2008-9/272318290554.gif"><br />数据流图的画法没有完全统一的规范，不过这并不影响我们用这一工具来分析我们程序中的数据流向。

<H4>4、数据流图的应用</H4><br />&nbsp;<br />软件中除了“程序流程”这条显性的主线，还有另一条隐性的主线，就是“数据流向”。之所以说“数据流向”这条主线是隐性的，那是因为在系统中，对一个特定数据的输入、处理、存储、输出等过程，往往被分散在许多模块中。<br />&nbsp;<br />“数据流向”很难通过流程图来描述。甚至于你把流程图画的越详细，“数据流向”这条线索就越发显得不够清晰。这时，我们就可以考虑用数据流图来描述，使得“数据流向”显得脉络清晰。<br />&nbsp;<br />举一个例子，比如一个简单的温度检测与控制系统。整个过程包括以下几个步骤：<br />&nbsp;<H5>（1）CPU先对负温度系数温度传感器（NTC）进行AD转换，取得采样值，并对这个采样值做递推平均滤波。</H5><H5>&nbsp;</H5><H5>（2）然后利用查表方法，把上一步滤波后的采样值转变为温度值。为了消除抖动，需要进一步做消抖滤波。滤波后的结果即为当前的实际温度。</H5><H5>&nbsp;</H5><H5>（3）另一方面，通过人机界面的按键输入系统，取得系统的设定温度。</H5><H5>&nbsp;</H5><H5>（4）实际温度和设定温度分别送显，并把这二者做比较，决定加热控制继电器的状态（闭合/释放）。</H5><H5>&nbsp;</H5><br />整个系统虽然不复杂，但涉及到了数据的输入、加工、输出等诸多环节。这些操作牵涉到多个模块，包括：ADC模块、按键功能模块、滤波模块、显示模块、输出控制模块。<br />&nbsp;<br />这些功能如果用流程图来描述，将需要用到多张流程图；如果用数据流图来描述的话，则只需要一张图就能把整个数据流表达清楚。（参见图&nbsp;1.33：温度检测与控制系统数据流图）。<br />&nbsp;<br /><br /><img src="http://blog.21ic.com/UploadFiles/2008-9/272327837165.gif"><br />&nbsp;<br />在实际应用中，我们立足于描述一个实际问题，因此在画数据流图时可以不必太过于拘泥于某一个固定的规范。只要能把思路表达清楚就好。<br />&nbsp;

本贴最新战况：<br /><br />回复：116<br />点击：&nbsp;4509<br /><br />支持的请顶一下。好让俺有积极性继续写下去。&nbsp;

天天跟着看呢。支持！！！！支持原创!&nbsp;匠人手记学习中。

程序规划的方法有很多，流程图只是其中的一种。除了流程图，还有N-S图、PAD图、数据流图、层次图、状态迁移图（表）、真值表、数轴、等等。。。。。因此，我们后续要继续讲下去。也希望大家不要把目光局限在流程图上。<br /><br />欢迎所长、hotpower、HWM、圈圈等各路大虾继续发表真知灼见，兼听则明。也欢迎其他网友继续互动讨论。