OO系统设计师之路--分析模型系列(3)--分析模型的调整和优化[从老博客搬家至此]

这一篇拖了很长时间，除了懒之外，另一个主要原因是一直找不到思路。想归纳一下自己的设计经验，找到一个相对容易学习的办法，结果总是不得要领。终于不得不承认设计工作是一项创造性的工作，是没有办法用什么固定的流程，普适的方法来完成的。除了知识和经验之外，个人的悟性恐怕也是影响设计好坏的原因之一。这篇文章写得很费劲，发现归纳出与具体需求无关的通用的一些方法真的很困难。相信对读者来说这篇恐怕是到目前为止最难懂的一篇了，因为太多的东西是只可意会不可言传的。如果让读者觉得困难了，只能说声抱歉，我已经尽力了。市面上所有有关设计的书目，无非是讲UML，讲OO原则，讲设计模式..这些要不就是理论，要不就是方法论，要不就是针对某一问题领域的解决方案。而当我试图总结普适的实践方法时，却发现非常的困难。我尽力而为，但仍免不了带着个人色彩以及具体化。最后，只能希望通过讲解一些关键点以及例子来给读者提供一些思路，提供一些借鉴意义。至于一个通用的设计方法，我彻底放弃了，相信那是一个不可完成的任务。或者说以我目前的能力，还不足以总结出这样的方法。

书归正传，这一篇讲如何调整和优化上一篇的分析模型草图。请注意我的用词是调整和优化，也就是说，大部分工作都是基于已经完成的工作的。细心的读者可能会发现，我一直试图说明的是，需求，分析，设计这些工作并非那么神秘，而是有一个程式化的过程。而我正希望整个过程越程式化越好，也希望读者都能找到适合自己组织和项目类型的程式。软件工程，既谓工程，必能遵循而重复。只有这样才能降低成本，压缩进度，减少沟通，提高质量。可重复的才有意义。然而从现在开始，这个程式将不复存在，个人的作用开始登上舞台了。

上一篇给出的草图，基本上是不动脑子的。照搬了业务实体，每个实体前加了一个控制类，只用了一个界面，整个过程只是把用例场景又重新模拟了一遍。有的读者要问，既然没有任何的改变，又没有分析的过程，那么做这个工作不是白费力么？实际上不是的，虽然是一个很简单的草图，但是我们已经完成了80%的工作，同时也为后面的工作打下了非常好的基础。这个草图用最简单最快速的方式把用例场景转化成逻辑场景，代表了从需求到设计的演变过程。再接下来的设计工作，只要不丢掉这个草图中的信息，不论怎么设计都保证能够满足需求，将会省掉接下来大量的验证工作而放心的在设计上下功夫。从效果上来说，草图虽然不一定出现在最终的设计成果里，但它的意义是显而易见的。

有读者对草图中的控制类用法提出不同意见。为什么要一个实体类一个控制类呢？全部用一个控制类不好吗？可以的。实际上在绘制草图的时候可以参考本组织所采用的框架来决定控制类的用法。控制类的使用是最为灵活的一个用法，但由于是草图的关系，草图的目的是用最快速最简单的方法来把需求转化到设计，再加上我个人觉得设计时由底向上比自顶向下要好（不容易遗露关键信息），也符合抽象是从特性向共性演变的特点，所以我个人习惯是先把控制类划到最小，再透过框架来抽象，而不是一开始就考虑框架问题。

笔者刚才说了，草图代表了需求的实现，是一个细节的表露。接下来的优化的调整，就以此为基础。主要的输入：草图，系统架构，业务规则，补充用例规约，