不知道现在还有多少人在研究软件工程，这个物欲横流、急功近利的年代，软件开发向来总是被进度套牢的一帮苦兄弟玩命的过程（向我这样的执著的人除外）。
忽然捡起本破旧的可怜的《软件工程导论》，大致浏览了一下。一个套路，先从“软件危机”讲起，然后开始一本正经的布道，讲一个完整的项目过程大概需要经历：
1、可行性研究---
2、需求分析---
3、概要设计---
4、详细设计---
5、编码&&单元测试---
6、综合测试---
7、软件维护---
总之，软件工程的基本目标是优质、高产。每一个阶段都要有必须的文档和相关说明。之所以发明这个咚咚，无非就是要制造一个理论，希望这个理论能够节省成本，降低代价而以。
这个理论创造的这些咚咚，总体上看上去，眼里面看到的。就是一堆一堆的图，比如可行性研究阶段的系统流程图和数据流图；需求分析阶段的ER图；概要设计阶段的Yourdon提出的结构图；详细设计阶段的pad图、jackson图；最近才进入测试，维护阶段。
90年代初，面向对象之风一夜吹遍全世界，几乎所有的专业程序员都希望这个东西能够给自己带来革命性变革，这项技术企图以oo思想统治每个人的世界观。很快，随之出现面向对象的分析方法（ooa/ood）：先以booch提出的名为Booch方法和Runbaugh提出的OMT技术，后来又出现oose的方法，当然还有其它不知名的更多方法。面对这么些错综复杂的技术，用户啥眼了，于是，大家揭竿而起发明了一个新的标准UML，使这些技术综合得以统一起来，现在已经发布到UML2.0。
有了UML，一切都变得异常标准和简单。项目中死死抓住核心“4+1视图”不放，犹如一把尚方宝剑。需求分析中引入“用例模型”来捕捉和组织用户的需求；设计阶段采用“交互图”、“顺序图”来描述各个细节的层次和协作关系。
总之，虽然还不知道现在的软件企业到底有多少真真实实的在推崇UML，但是UML确实一个得来不易的东西，对于软件项目建设的标准性建设大有帮助，可以跟踪开发项目从需求调研到测试和维护的各个阶段进行有效的支持。