系统分析与建模1

面向对象编程的目标不是复用，而是提供了一种处理复杂性问题的方式。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统。

面向对象编程的困难

现实世界和对象世界的差距，即使面对简单的传统商业模式，我们仍有如下困惑：

• 对象是怎么被抽象出来的？现实世界和对象世界看上去差别是那么大，为什么要这么抽象而不是那么抽象？（Why）
• 对象世界由于其灵活性，可以任意组合，可是我们怎么知道某个组合就正好满足了现实世界的需求呢？什么样的组合是好的，什么样的组合是差的呢？（How）
• 抛开现实世界，对象世界是如此的难以理解。如果只给我一个对象组合，我怎么才能理解它表达了怎样的含义呢？（What）

要想跨越这道鸿沟，我们需要：

• 一种把现实世界映射到对象世界的方法
• 一种从对象世界描述现实世界的方法
• 一种验证对西那个世界行为是否正确反映了现实世界的方法

UML和UML背后的面向对象分析设计方法，架起了跨越这道鸿沟的桥梁。

1、从现实世界到业务模型

现实世界充满了杂乱无章的信息，要建立一个模型并不容易。建立模型的过程是一个抽象的过程，所以要建立模型，首先要知道如何抽象世界。如果站在很高的抽象层次，以高度归纳的视角看这个世界的运作，其本质无非是人、事、物和规则组成的。人是一切的中心，人要做事，做事就会使用一些物并产生另一些物，同时做事需要遵循一定的规则。人驱动系统，事体现过程，物记录结果，规则是控制。建立模型的关键就是弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，一个模型也就基本成型了。

• UML采用参与者（actor）元模型代表现实世界的“人”，是模型信息来源的提供者，是整个建模过得中心，也是第一驱动者。
• UML采用用例（use case）表示驱动者的业务目标，就是现实世界中的“事”。
• 这件事是怎么做的，依据什么规则，则通过业务场景（business scenario）和用例场景（use case scrnario）的UML视图描绘，这些场景是现实世界中的“规则”。
• 最后通过业务对象模型（business object model）的视图来说明在达成这些业务目标的过程中涉及到的事物，用逻辑概念来表示它们，并定义它们之间的关系。代表了现实世界中的“物”。

2、从业务模型到概念模型

现实世界被业务模型映射并记录下来，但是距离可执行代码还很遥远，UML通过概念化过程来建立适合计算机理解和实现的模型，称为分析模型。

分析模型向上映射了原始需求，向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束。

分析模型最主要的元模型有：

• 边界类（boundary）：任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。边界决定了外面能对里面做什么“事”。
• 实体类（entity）：实体类由业务模型中的领域模型转化而来，领域模型中业务实体映射了现实世界中参与完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。
• 控制类（control）：表述原始需求中动态信息，即业务或用例场景中的步骤和活动，体现了现实世界中的“规则”。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们不要通过控制类来代理访问要求。

最后根据业务模型中已经描绘出来的用例场景来组合这些元素，完成从业务模型都概念模型的转化。

3、从概念模型到设计模型

概念模型使我们获得了软件的蓝图，获得了建设软件所需要的所有组成内容，以及建设软件所需要的所有必要细节。接下来的工作就是建造或者购买所需的零部件。设计模型的工作就是建造零部件和组装的过程。

在大多数情况下，实现类可以简单地从分析类映射而来。在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XML文档或者其他带有持久化的类。