软工学习进行了一个多月，但是真正静下心来学习也只是一周左右吧，这段时间里给自己印象最深刻的就是作图了， 机房收费系统我们是先进行的编码，后学习软件project对它来了一次回想性的文档编写。
刚開始当然不知道这些图都是干啥用的，早在项目開始前就问师傅里面的图都用啥工具来画的。师傅给了一个叫做《亿图》的软件，各种模板都给提供了，异常兴奋。于是天马星空的開始了自己的作图旅程，结果到最后才发现，自己全然脱离了视频中的介绍，差点儿没有依照作图规范来，终于70%的图都变成了废品。
没办法，还是从基础上来了解一番吧：
数据流图：
从本质上理解它就是系统中数据流动的形式。并不涉及物理结构。即使貌似是物理事体的源节点与目的节点。也是跟系统本身没有关系的。就像下图中的学生一样：
须要注意的是。除了与文件挂钩的数据流，每一个都要有一个明白的名称，我想是由于文件名本身就能够代表一种数据表现形式吧。
在加工比較复杂的情况下一般採取分层做数据流图的形式。就像一个抽象归类过程一样。面对一个庞大复杂的组织网络，当不须要了解他的详细内部操作时，用一个可以概括这类加工内容全部共性的名词来代表全部的加工。这样有利于分析时从全局角度出发。当然并非分层次越多越好，随着层次的添加，处理机制将更加严格。从命名规范，父图与子图的平衡等都会有严格的界定，要知道，有时简单的事务并不须要将其复杂化。
数据字典（DD）：
数据字典，顾名思义，就是对有关数据名词的定义与解释说明。它能够是对数据流，数据项，文件等内容的定义。
既然是定义。则必然先将名称放到开头，然后介绍内部组成成分与结构，最后加一些描写叙述性的形容词来做备注。
数据字典的使用与数据类图的使用时相辅相成的，数据流图清晰显示了数据流动与处理的过程，但这些名词是不easy被人们所理解的。加以数据字典就相当于对其增加了凝视一般。
判定表&判定树
判定表比較适用于数目流程较多，判定复杂的流程其中。它将推断条件与操作至于二维表格其中，符合条件的用“对号”来表示，界面清晰易懂。便于查找。
判定树以树杈结构的方式将选择与推断结构一图形化形式表现出来，较为清晰，但不适合过多的选择与结构化流程。
实体联系图（E-R）&层次方框图
软件project生命周期中少不了对对系统的分析，这时不光须要了解系统所涉及的实体与联系。这时实体联系图提供了较大的方便。除了这些还得结合软件系统所处的周边环境。像某个组织的结构等等，仅仅有联系了这些。才干充分发挥软件系统的功用。
系统模块图（sc）
计入软件设计阶段，对每一个模块进行明白的界限划分，不仅对开发周期的预计，更对程序开发过程中的分工起到了关键性的作用。
从设计子模块中我们发现系统模块图的设计规则比較繁多，这也从还有一个角度说明系统的模块不好划分。仅仅有运用这些规范化的设计模式才干帮助我们明白划分出子模块。
程序流程图
习惯于敲代码的我们队程序流程图必定不陌生。说道程序流程，必定想到三大结构选择。循环，推断：
甘特图
甘特图是我们眼下使用较少的图种了，在机房收费的第一遍文档编写过程中，仅仅碰到了一次，它能够清晰的分析我们计划其中完毕的事项与未完毕事项。
自己也以前參照网上的作图方法用Excel表格临摹了一幅：
总结：
软件project教会了我们在不同的软件开发周期站在不同的立场上去思考，每篇文档写作目的是为了什么，终于给谁看的。仅仅有这样才干了解一个软件的开发过程。最重要的还是机灵的学会用图去帮助思考，帮助解决这个问题。
