在绘制该时序图的过程中我们得到了关键对象以及这些对象的方法，接下来把这些对象及其方法绘制在一个图里，定义出他们的关系，就得出了分析类静态图：

(这个图其实有点小问题，就是这个矩形元素代表的是设计类而不是分析类，分析类的形状应该是绘制时序图那时候的圆形，也没有 void 这个语言层次的东西，我用的建模工具是 EA ，不知道的是工具不支持在分析类中绘制方法，还是我自己没找到。反正 rose 中是可以的)

用分析类对象实现用例场景的过程就是类的推导过程，现在我们已经得到初试的类及其方法，虽然看上去还很粗糙，但已经脱离了需求视角，进入系统设计的视角了。

这些分析类就是我们进行系统设计的基础了，分析类结合采用的具体框架（比如SSH），架构等，就可以推导出设计类，产生设计模型了。

推导设计类的过程由于要结合具体框架，可能要实现某某接口，继承某个抽象类等原因，这里就不说了，等过段时间我再新写一篇文章来说吧。由于我工作中的项目采用 SSH框架，所以我曾经疑惑觉得怎么没有看到 Action 类啊，Service类呢， pojo呢，DAO呢，没看到啊！后来才恍然醒悟，哦，原来所处的抽象层次不同，分析模型的抽象层次比设计模型高，不涉及到具体的框架，架构，语言等实现方式，所以在这个抽象层次上，可以不去考虑实现细节，屏蔽掉无关的信息，而专注于通过分析类的3种对象之间的交互来实现需求，为需求到设计之间搭建桥梁，设计模型就是在分析模型的基础上结合具体框架，架构，语言等实现方式实例化分析模型的过程。完整而全面的分析模型就可以作为系统概要设计文档了。

其实我个人觉得，从业务模型到设计模型（中间可能还有概念模型），到分析模型，再到设计模型，这种建模的过程就是一个降低抽象层次和边界粒度的过程，类似于我们要描述一个东西，比如汽车，我们可以这样说：站在汽车这个抽象层次上，我们看到的是车身，轮胎等边界；降低抽象层次到车身上，我们面对的有方向盘，发动机，座位等边界；站在发动机这个抽象层次上，我们看到的是引擎，活塞等边界......这个抽象层次可以一直延伸下去，采用这种自顶向下的方法把一个事物描述清楚。抽象层次的好处是无论站在哪个层次上都只需要面对有限的复杂度和结构，从而帮助我们理解清楚这个层次上的对象是如何工作的。边界和抽象层次是相伴的，不同的抽象层次面对的边界粒度就不同。编程中所谓的“针对接口编程”，其实也就是把对对象的认识附加在接口这个边界上，我们只要清楚他能做什么就可以，不需要降低边界粒度去考虑具体实现方式，这样才带来了具体实现可替换的灵活性。

这篇文章就写到这里吧，感觉要再往下写，我目前也是有心无力了，毕竟以我自己目前的能力能写出这么多来也是不容易了，虽然本问中的案例非常简单，但是这种面向对象的分析思路都是一样的。

福州这两天天气好热，我把周末两天都拿来写这篇文章了，都是窝在宿舍里，边吹空调边写。其实一个项目要面对的问题远不止本文所讲，比如要针对某个问题建立领域模型，例如权限系统等，本文也省略了业务规则的分析，尽管如此，我觉得已经基本把自己想要说的表达出来了，以我目前的水平，能说这么多也算有个交代了，至少我觉得自己已经找到了通往面向对象分析的大门了。路漫漫其修远兮啊......

最后引用面向对象大师Grady Booch在2004年IBM Developer Works Live！大会的访谈中讲过的一段流传甚广的话作为本文的结尾吧：“我对面向对象编程的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂性问题的方式。这个问题可以追溯到亚里士多德：您把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统——我认为，这才是面向对象编程运动的真正胜利”。

原文：http://blog.csdn.net/FcBayernMunchen/archive/2010/08/15/5813667.aspx

本文链接：http://www.blueidea.com/tech/program/2010/7926.asp　

出处：CSDN
责任编辑：bluehearts

上一页 面向对象分析过程案例实战 [5] 下一页

◎进入论坛网络编程版块参加讨论