两天开会总结 ..收费系统 架构

每次开会，我都很高兴，不过没想到这次竟还是个持久战哈。

1月30号早8点开始上课，截止到昨天晚上12点，这两天的时间我们大部分时间都在南五小屋开会讨论关于机房收费管理系统的架构和相关知识的引用。

很早以前，每次开会，米老师和我们讨论的，都是宏观上的思想，不会细到编程代码里边去，多是因为那样会导致我们陷进去，理不出思路来。思想和技术同步，思想层次高了需要依仗技术上的实现，技术上的提升更离不开思想的高度，彼此相辅相成，米老师主抓我们的思想，而我们在机房实现的就是技术的提高了。

我以前认为这个机房收费管理系统就是使用面向对象（类、多态、继承、接口等）来做，现在看来也的确是那样的，可是有一点不同，通过这两天的讨论，我发现自己以前所想还只是部分面向对象，而非全部面向对象，既然面向对象相较面向过程等等好处更多，为什么不做成完全面向对象呢，这算是我这两天来的一个醒悟。（开会的时候还提到了对象集，针对数据库中每一条记录都实例为一个对象，这样用面向对象来处理这个细节；还有比如说学宇自己写的Hebernate框架，就是面向sql语句的。）

宏观上来看，我们用rose画的系统包图主要体现的就是系统架构情况，告诉软件开发人员这个系统是如何分层的，是如何将系统的繁杂关系分离开的，如何做到系统的强扩展，也使得开发人员之间的团结合作更加容易，更确定了一个共同努力的目标，同时这也凸显了存在的约束(很重要),就说我们UML建模的时候，需要用到五种关系（依赖è关联è聚合è组合è继承），既然关系划分开了，那么肯定有些许的不同，那么对于我们在建模图中表示的直线和箭头就承载着这五种关系，表示两端对象的关系，这其中还承载着一种约束，用米老师说的木匠做三腿板凳这其中的各个约束，就是使得系统有一个范围的约束，各个模块都在约束中完成自己的功能，也不至于组建之后的系统由于各个模块间缺乏约束合作，而分崩离析。

构建系统中的各个约束，这都会体现在UML建模中，将在图上体现的淋漓尽致，但是画图建模也是要详略得当，用例图等不必太细，而时序图倒是需要详细一点，并且个中要求都是要认真考究的，时序图做的细了，在后面实现系统的时候能帮我们很好的校验，差错。

并且这次开会，米老师问我们UML建模中的其他图，比如协作图，部署图等等，都有什么用？怎么用？(缘于我们的图里边有用例图、时序图、类图，而缺少后面的这些协作图等)，既然rose经过了大浪淘沙，现在还暂居主流，那么存在就有存在的道理。有何用，如何用，都是要在实践中、失败后总结的。

通过这两天开会，整天的架构明了了很多，今天又看了看自己画的图，和已经写的一些基础代码对照，之间的对应关系还是比较明了的。不过为了更好的把这段时间的学习贯穿起来，还是要奔着完全面向对象去做的，即使会对原来的东西改动很大，但是这是经验。米老师说，失败是我们的骄傲和资本，也是说出了我们积累经验的途径和过程。

接下来就要好好实现系统了。