我们来分析一下上面的草图。首先，这幅草图大家可以看到，所有的实体类没有做任何变动，直接照搬了业务实体(领域模型)，所谓的控制类，只是机械的在每一个实体前加了一个控制器，边界类只用了一个。至于过程，更是和用例场景一模一样，只不过形式不同而已，改用了计算机术语。这个例子只有一个用例
场景，如果有多个，每个场景画一次，重复用到的类直接拖过去，能用的方法直接用，还没有的就加上，总之忠实的实现这些用例场景就好了。整个过程很简单，很程式化，对吗？不用脑子都能做。尽管如此，我们仍然得到了一个分析模型的静态图，就象下面这样：
小提示：在做分析模型时，从时序图开始做，需要用到一个分析类时，就转到类图中创建这个类，再从左边的树形列表里把类拖到时序图上。从一个对象画一条表示交互消息的箭头到另一个对象后，右键点击线条，选择\，再输入操作名，这时Rose会在线上标明这个操作名称的同时在对应的类上创建这个方法。这样，在绘制时序图的同时也生成了静态类图。最后再把类之间的交互用线连起来表示这个关联关系，静态图就完成了。
? 分析模型静态图
再来一个小提示：rose对中文的支持不好，因此上面的图中类下面无法完整的显示用中文写的方法名，不过双击open sepcification对话框能正确显示。相信大家注意到我所有贴上来的图文字都是仿宋体而不是通常用的宋体，这是因为在字符集里，宋体并没有被限定为GB2312，所以当把rose里的图全选并拷贝到画图或WORD里时会文字会变成乱码。大家一定也遇到过这种情况吧？一个小技巧就是用仿宋字体，预先设定字体或者全选（crtl+A会吧），再菜单format->font，选仿宋，你可以看到在仿宋字体后面带了GB2312的字样^_^。这样就不用先屏拷再剪切，再拷贝到word里了。用word2003的朋友幸运了，没有这个问题。
不可否认，这个类图很粗糙，但是一个系统原型已经出来了。我们得到了可以完全实现需求的一些类，主要的类方法也有了。如果你想偷懒的话，直接把它转换成设计类图，把中文方法名改为英文，再把领域模型文档（不记得了回头查以前的文章）中提到的实体属性填入，就已经可以交付开发了。因为需求已经实现了，类有了，方法有了，类属性有了，别忘了在用例分析过程中已经用静态HTML做了系统原型，因此界面也有了。一切开发需要的东西都全了。比如我们用Strus+hibernate架构，一个实体类就是一个POJO，一个控制类就是一个action，至于界面，在静态HTML里填入java代码改成JSP呗。如果你是一个开发人员，把这个图给你，相信你也会觉得开发这个需求是很明确很简单的事吧？呵呵，成就真不小，可是仔细想想，我们甚至都没有动脑子啊！真是的，我们没有动脑子，居然就做了一个设计，恩!？可事实就是这样，谁说分析设计就一定要动脑子？不动脑子就不能做设计吗？就不能体现一个设计师的价值吗？设计的目的是什么？漂亮？好看？采用了很多新技术？体现了设计师的高明手段和渊博知识？NONONO！设计的目的是为了实现需求不是吗？如果需求就是这样简单，我们已经实现了，还能不动脑子，干嘛做那没事找抽型的，老板又不因此少付一分钱工资，能少干点活儿不好吗？很多设计师因为懂得几个设计模式，总要想方设法弄上去，把简单的问题弄复杂，好象只有这样才能体现他的价值。爱因斯坦说宇宙的法则是简洁的才是最美的，设计也是如此。设计师的真正价值，是用最简单，最好懂，最简洁的设计完成最复杂的要求，而不是相反！一项技术，正因为能够被大多数人掌握才能流行，否则就只能呆在实验室里，不是吗？ 话扯远了，忍不住又抨击了一下过度设计，很不幸被抨击的对象也包括以前的自己^_^。好吧好吧，我知道尽管你会同意我的话，你还是会在心里嘀咕，如果设计就只有这一点东西，连脑子都不用动，那设计师也太好干了吧？分析模型如果就只有这一点内容，还要专门写个系列文章，这个作者也是个欺世盗名的吧？ 呵呵，为了抚平你的失望，我告诉你。之所以我们没动脑子，是因为系统分析员们经过用例分析系列中的卓越工作，给我们打下了如此坚实的基础，才使得我们的工作简单到了不用动脑子的地步。你还得感谢UML用一套很好的方法，让你可以轻而易举的从需求转化到类设计。你已经站在巨人的肩膀上了，所以就一边儿偷着乐吧。
乐完了还得回到现实。在很多情况下，事情并没有这么简单。这个粗糙的分析模型虽然可以工作，但的确有很多可以优化的地方。不用担心你会因为做了一份简单而不用动脑子的工作而失去饭碗。因为下一篇，我们将会讨论怎么样，从哪些方面，以及如何依据补充规约，系统架构以及维护要求等来优化和调整这个模型。这下设计师有用武之地了，学习到的知识和积累的经验要发挥作用了，失落的自我价值也能体现了。为了证明设计师不是混吃喝的并且保住饭碗，敬请期待下篇，分析模型的优化和调整。
草图代表了需求的实现，是一个细节的表露。接下来的优化的调整，就以此为基础。主要的输入：草图，系统架构，业务规则，补充用例规约，系统原型。主要的输出：调整后的分析模型，子系统，组件视图和部署视图（针对分布式应用而言）。
这一篇拖了很长时间，除了懒之外，另一个主要原因是一直找不到思路。想归纳一下自己的设计经验，找到一个相对容易学习的办法，结果总是不得要领。终于不得不承认设计工作是一项创造性的工作，是没有办法用什么固定的流程，普适的方法来完成的。除了知识和经验之外，个人的悟性恐怕也是影响设计好坏的原因之一。这篇文章写得很费劲，发现归纳出与具体需求无关的通用的一些方法真的很困难。相信对读者来说这篇恐怕是到目前为止最难懂的一篇了，因为太多的东西是只可意会不可言传的。如果让读者觉得困难了，只能说声抱歉，我已经尽力了。市面上所有有关设计的书目，无非是讲UML，讲OO原则，讲设计模式..这些要不就是理论，要不就是方法论，要不就是针对某一问题领域的解决方案。而当我试图总结普适的实践方法时，却发现非常的困难。我尽力而为，但仍免不了带着个人色彩以及具体化。最后，只能希望通过讲解一些关键点以及例子来给读者提供一些思路，提供一些借鉴意义。至于一个通用的设计方法，我彻底放弃了，相信那是一个不可完成的任务。或者说以我目前的能力，还不足以总结出这样的方法。 书归正传，这一篇讲如何调整和优化上一篇的分析模型草图。请注意我的用词是调整和优化，也就是说，大部分工作都是基于已经完成的工作的。细心的读者可能会发现，我一直试图说明的是，需求，分析，设计这些工作并非那么神秘，而是有一个程式化的过程。而我正希望整个过程越程式化越好，也希望读者都能找到适合自己组织和项目类型的程式。软件工程，既谓工程，必能遵循而重复。只有这样才能降低成本，压缩进度，减少沟通，提高质量。可重复的才有意义。然而从现在开始，这个程式将不复存在，个人的作用开始登上舞台了。
上一篇给出的草图，基本上是不动脑子的。照搬了业务实体，每个实体前加了一个控制类，只用了一个界面，整个过程只是把用例场景又重新模拟了一遍。有的读者要问，既然没有任何的改变，又没有分析的过程，那么做这个工作不是白费力么？实际上不是的，虽然是一个很简单的草图，但是我们已经完成了80%的工作，同时也为后面的工作打下了非常好的基础。这个草图用最简单最快速的方式把用例场景转化成逻辑场景，代表了从需求到设计的演变过程。再接下来的设计工作，只要不丢掉这个草图中的信息，不论怎么设计都保证能够满足需求，将会省掉接下来大量的验证工作而放心的在设计上下功夫。从效果上来说，草图虽然不一定出现在最终的设计成果里，但它的意义是显而易见的。