扩展E-R模型方法研究

不得不说的是，数据库实在是个麻烦的东西，从昨天搞到今天下午，终于算是决定了正式ER模型1.0版了。但是即使模型决定了，我们的命途依旧多舛，各个表如何设计又困扰了我们整整一天，我还算好的，由于主要负责Cobol，所以这两天我只是参加一部分比较麻烦部分的讨论，负责数据库的那两位，看来已经是痛不欲生，近乎暴走，就差没口吐白沫了……
　　不过说来我也闲不得，这两天里我的主要任务就是看往届参赛队伍的Cobol源代码，对着满屏幕的大写字母看上半天也着实不是有意思的经历……不过也还是获益良多的，现在对我们的项目的Cobol程序结构已经大概有点思路了，提高代码质量的招数也学到了些。现在嘛，一边看代码，一边静待我痛不欲生的那天的来临，实在是一种很有意思的心理状态啊……
　　做过应用软件开发的朋友们大多都熟悉传统的开发生命周期：应用软件首先从业务分析员画在在纸上或者流程图工具中的业务草图开始，一个个功能被定义出来；然后交到开发人员手里，设计，编码，组装；接着应用软件又交付业务分析员做测试；业务人员按照当初设计草图勾勒的功能去测试，发现问题后报一个Bug，提请开发人员修改代码。反复多次，最后交付的软件很少有和设计100%契合的，大部分是业务人员与开发人员互相让步的结果。由业务人员直接参与测试，还是比较理想的情况，多数开发过程，测试由专门的测试人员按照他们对业务设计的理解做测试，他们对业务的理解又会同业务分析员以及开发人员有所偏差。

　　可以发现，整个应用软件的开发周期中，在交流沟通上，以及为纠正沟通产生的误解，花费了大量的人力物力。为了解决沟通的问题，特别是业务人员和技术人员之间的沟通，软件开发过程中引入了许多模型。模型能够在一定程度上对问题提供抽象，能够作为不同领域之间有效交流的共通符号。

　　说到模型，就会想到常用的数据库设计的ER模型，应用程序设计的UML，以及一些其他一些业务流程模型。随着软件开发工具的不断进步，许多模型只要能够提供完备的需求描述，完全能够直接产生应用的实现代码，而且也能够按照实现代码利用逆向工程产生对应的模型。这样的模型多数是来自于技术领域的模型，例如：ER模型和UML中的模型。模型和代码之间的双向工程，极大的方便了应用系统的设计和维护。相对于改变代码，对模型的更改更加迅速高效，而且避免手工编