替代面向对象_UML - 面向对象的困难解决了吗？

根据之前一系列的文章，要解决面向对象的困难我们需要这样一些方法：

• 一种把现实世界映射到对象世界的方法。
• 一种用对象世界描述现实世界的方法。
• 一种验证对象世界行为正确反映了现实世界的方法。

那么，UML是否解决了面向对象的困难或者说有没有提供我们需要的方法呢？

从现实世界到业务模型

这是把现实世界映射到对象世界的第一步。UML采用用例这一关键元素捕获了现实世界的人要做的事，再通过用例场景、领域模型等视图将现实世界的人、事、物、规则构成现实世界的元素用UML这种语言描述出来。而UML本身被设计成为一种不但适于现实世界理解，也适于对象世界理解的语言，所以用UML来描述现实世界这句话可以稍微换一下说法，变成：现实世界被我们用一种对象语言描述。

这不正是我们需要的把现实世界映射到对象世界的方法吗？看来我们找到了一种把现实世界映射到对象世界的方法。

从业务模型到概念模型

这是从对象世界描述现实世界的方法。当业务模型用分析类来描述的时候，我们实际上已经采用了对象视角。用例所代表的现实的业务过程，别“边界”、“控制”、“实体”以及“包”，“组件”等概念替代。而这些概念是可以被计算机理解的，是抽象化了的对象。现实世界千差万别的业务，都用“边界”、“控制”、“实体”这几个固定的元素来描述，也就是说，现实具体的业务被“抽象”成一个固定的概念。同时，这些概念还可以用“包”、“组件”等这些与现实世界毫不相关的纯计算机逻辑术语包装。这说明概念模型是计算机视角，或者说是对象视角的，而且这些对象视角的分析类所描述的信息是从映射了现实世界的业务模型转化而来的。

可以说，从业务模型到概念模型这一过程，正是我们需要的一种从对象世界来描述现实世界的方法。

从概念模型到设计模型

这是验证对象世界是否正确反映了现实世界的方法。“边界”、“控制”、“实体”这些对象化的概念，虽然计算机可以理解的，但它并不是真正的对象实例，即它们并不是可执行代码，概念模型只是纸上谈兵。真正的对象世界行为是由Java类、C++类、EJB、COM+等这些可执行代码构成的。然而缺少了从概念模型到设计模型这个过程，Java类也好、C++类也好，它们的行为是否正确凭什么去验证？设计类不是像孙悟空一样从石头缝里蹦出来的，而是用某种语言在某种特定规约的约束下“实例”化分析类的结果。换句话说，设计模型是概念模型在特定环境和条件下的“实例”化，实例化后的对象行为“执行”了概念模型描述的那些信息，因此设计模型得以通过概念模型追溯到原始需求来验证对象世界是否正确反映了现实世界。

看来，我们找到了一种验证对象世界是否正确反映现实世界的方法。

如果把三个模型的建立过程综合起来，则如下图，从中我们可以更清楚地看到面向对象的困难是如何在模型的转化过程中解决的。这一过程看来是有规律的、可推导的、可追溯的过程。

上图中引入了另一个概念，就是用例驱动。尽管没有细说，但相信你也能从中初步领略到用例是如何驱动整个开发过程的。