软件工程--作图

     软工学习进行了一个多月，可是真正静下心来学习也不过一周左右吧，这段时间里给自己印象最深刻的就是作图了， 机房收费系统我们是先进行的编码，后学习软件工程对它来了一次回顾性的文档编写。

刚开始当然不知道这些图都是干啥用的，早在项目开始前就问师傅里面的图都用啥工具来画的，师傅给了一个叫做《亿图》的软件，各种模板都给提供了，异常兴奋，于是天马星空的开始了自己的作图旅程，结果到最后才发现，自己完全脱离了视频中的介绍，几乎没有按照作图规范来，最终70%的图都变成了废品。没办法，还是从基础上来了解一番吧：

数据流图：

从本质上理解它就是系统中数据流动的形式，并不涉及物理结构。即使貌似是物理事体的源节点与目的节点，也是跟系统本身没有关系的，就像下图中的学生一样：                                                            需要注意的是，除了与文件挂钩的数据流，每个都要有一个明确的名称，我想是因为文件名称本身就可以代表一种数据表现形式吧。 在加工比较复杂的情况下一般采取分层做数据流图的形式，就像一个抽象归类过程一样。面对一个庞大复杂的组织网络，当不需要了解他的具体内部操作时，用一个能够概括这类加工内容所有共性的名词来代表所有的加工，这样有利于分析时从全局角度出发。当然并不是分层次越多越好，随着层次的增加，处理机制将更加严格，从命名规范，父图与子图的平衡等都会有严格的界定，要知道，有时简单的事务并不需要将其复杂化。

数据字典（DD）：

数据字典，顾名思义，就是对有关数据名词的定义与解释说明。它可以是对数据流，数据项，文件等内容的定义。 既然是定义，则必定先将名称放到开头，然后介绍内部组成成分与结构，最后加一些描述性的形容词来做备注。
数据字典的使用与数据类图的使用时相辅相成的，数据流图清晰显示了数据流动与处理的过程，但这些名词是不容易被人们所理解的，加以数据字典就相当于对其加入了注释一般。

判定表&判定树

判定表比较适用于数目流程较多，判定复杂的流程当中。它将判断条件与操作至于二维表格当中，符合条件的用“对号”来表示，界面清晰易懂，便于查找。判定树以树杈结构的方式将选择与判断结构一图形化形式表现出来，较为清晰，但不适合过多的选择与结构化流程。                    
                       

实体联系图（E-R）&层次方框图

软件工程生命周期中少不了对对系统的分析，这时不光需要了解系统所涉及的实体与联系，这时实体联系图提供了较大的方便；除了这些还得结合软件系统所处的周边环境，像某个组织的结构等等，只有联系了这些，才能充分发挥软件系统的功用。                                                                                                   

系统模块图（sc）

计入软件设计阶段，对每个模块进行明确的界限划分，不仅对开发周期的估计，更对程序开发过程中的分工起到了关键性的作用。                                                                                          
                                                
从设计子模块中我们发现系统模块图的设计规则比较繁多，这也从另一个角度说明系统的模块不好划分，只有运用这些规范化的设计模式才能帮助我们明确划分出子模块。                                      

程序流程图

习惯于写程序的我们队程序流程图必然不陌生，说道程序流程，必然想到三大结构选择，循环，判断：                         

甘特图

甘特图是我们目前使用较少的图种了，在机房收费的第一遍文档编写过程中，只碰到了一次，它可以清晰的分析我们计划当中完成的事项与未完成事项。                             
自己也曾经参照网上的作图方法用Excel表格临摹了一幅：                                                

总结：

软件工程教会了我们在不同的软件开发周期站在不同的立场上去思考，每篇文档写作目的是为了什么，最终给谁看的，只有这样才能了解一个软件的开发过程。最重要的还是灵巧的学会用图去帮助思考，帮助解决问题。