机房收费系统合作版的报告

机房收费系统合作版算是初步完成，合作小组进行了会议讨论。会议主题如下：

1、 我们用到了哪些新知识

2、 我们对设计模式的理解有什么新的认识

3、 合作过程的困难与解决方案

4、 合作心得，下次合作的建议

5、 对系统的整体架构的理解

6、合作感受。

一、合作版用到的新知识——拓展知识面，温故而知新。

１、设计模式

观察者，模版，外观，装饰，策略，简单工厂，单例，抽象工厂

2、实体类集合



3、旧知识的新理解

反射，Treeview，循环，数组，

4、数据库

SQLserver的进一步认识， sql语句，Sql参数，

5、工具

数据库设计工具：powerdesigner。

原型设计工具：AxureRP。

UML 设计工具：Enterprise Architecct 。



二、对设计模式的理解的新认识——简单点说：痛并快乐着。

1、开始使用设计模式，总是不能很好的抽象，从大面上感觉很多东西都可以套进一个模式，很是窃喜，但是实际操作中，发现，有很多细节没有注意到，然后就得删减，就很郁闷。某个地方用到某个设计模式，总想在找一个相似的地方，然后共用一个模式，做到设计模式的合理利用，感觉抽象才有意义。有点生硬的使用。图设计出来，模式也加了，实际操作有难度，开始考虑为什么用这个设计模式，总是很难分析出这个模式的优缺点。

然后告诫自己“跳出去这个阶段，认识会更深点。”其实，心里还是纠结。

事后发现自己犯了一个错误：学设计模式是一回事，用设计模式又是一回事。我总是不能把学到的东西很好的消化。全局观把握不好，认识狭隘。到实际操作中，捉襟见肘的事就会很常见。

2、现在的认识就是：设计模式是解决一类问题而出现的解决办法。范围可大可小，而且在使用中，没有绝对的适用不适用，大家会发现，同一个问题，可能会有好几种解决办法，同样的一个问题可以用好几个设计模式来解决，孰优孰劣就看情况而定了。



三、合作中遇到的困难和解决办法

1、文档没有写好。

最大的问题就是文档没有写好。这是我个人的问题。

不知道文档该怎么写，特别是详细设计文档。总是按着自己的思路来，考虑不到文档是给别人看的。一些无意识忽略掉的东西，以为不重要，其实不然，别人有可能因为你的一个方法写错参数，而没有传对，整个系统就得需要调试半天，这是很正常的。

自己设计的逻辑，总以为别人跟自己一样懂，错。没有完全相同的两片树叶，何况人的想法，所以即使很简单的逻辑，也一定要写清楚。将一些可能的错误降低到最小。



2、沟通。

沟通很重要。

因为机房收费系统是小组合作开发之前已经做过的系统，大家都清楚需求和流程。也正是因为这样，大家在自己心中都有一个思维定式，把自己以前开发过程中处理问题的解决方案用到了，这样难免就会和另一个人发生冲突。这时候明白了师傅在合作前说过的一句话：组长怎么设计，组员就怎么做；组长怎么要求，组员就按要求来。在流程逻辑上如果没有偏差，合作小组就需要一个组长来选择。

开发完成后，意识到，这次合作开发主旨不在看小组的系统有多强大，目的在“以文档为驱动，锻炼和小组成员沟通的能力。”

我们这次合作开发并没有做好。这里的沟通就是文档的沟通，组长写明白文档，组员看的明白。通过这次合作，对文档的理解加深了。以前写文档都是找个模板，照葫芦画瓢，象征性的写文档，没有多大的实际意义。有了这次合作开发的经验，对文档的设计有了自己的看法，在系统完成两三天后，翻出自己的文档，发现有好多的不足。主要是不明白合作开发需要什么，这次跌跌撞撞的合作，渐渐清晰了文档的思路。



主要文档：需求文档，概要设计文档，数据库设计文档，详细设计文档。

需求文档： 用例分析必须清楚；要有系统原型。

让用户，合作组清楚系统的用途，看到系统的雏形。用户看到了用例，才可以知道是否符合自己的本意；话说：一张图抵得上千言万语，通看原型设计，才能更好的表达设计者设计的系统，开发人员，用户都可以一目了然的看清楚，并指出具体的不满。



概要设计文档：宏观设计的包图，接口说明，流程逻辑。

包图：表明系统设计的架构。

　　　　　　接口：层与层之间如何衔接，用到了什么技术，层之间调用等的说明。这里并不一定都是严格的接口，例如机房收费系统中ＵＩ层和BLL层之间加外观模式，这里外观严格意义上不是一个接口，但这里它相当于一个接口的作用。

流程逻辑：系统的运行流程要给出，好比一个开发地图，方便开发人员开发。



数据库设计文档：概念模型，逻辑+物理模型齐备。

数据库中的每个表在设计的时候除了要按照三范式来，还有一个重要的要求就是“按需求来设计”。

对于建表的个数，数据库中的三范式固然很好，但是要根据自己的实际需求，而不拘泥于三范式。打个比方，如果说学生和卡信息总是一起出现 ，这样的情况，或许就没有必要建两个表了。

概念模型：既然一个系统需要这么多张表，那么这几个表之间必然都存在关系。没有一个表是独立的。都可以通过主外键建立联系。这也是一个问题。如果把所有的表都联系起来，那么这个数据库的完整性是很好的，但是系统不大的话，这样关系太多，操作起来不方便。所以，在建立表之间的关系时要慎重。

物理+逻辑模型：物理模型和逻辑模型不一样，貌似现在的文档中物理模型和逻辑模型都混合写在了一起。这里需要导出的就是在数据库设计时的东西。一张一张关系表及存储空间等。



详细设计文档：类图的设计，时序图的流程。

类图的设计：各层的详细类图：参数，返回值等等。在每层中用到的设计模式，如何使用要详细说明。

时序图流程：各层之间，类与类之间的调用关系清晰。一个系统由若干个人完成，若是按照分层来进行分工的话，流程逻辑是必须要清晰的。各层的开发人员，根据时序图的逻辑，进行调用。这样才可以保证业务流程的完整性。

合作开发完后对文档的一些简单认识，有偏差，欢迎指正。