UML - 从业务模型到概念模型

现实世界被业务模型映射并记录下来，但这只是原始需求信息，距离可执行的代码还很遥远，必须把这些内容再换成一种可以指导开发的表达方式。UML通过称之为概念化的过程（Conceptual）来建立适合计算机理解和实现的模型，这个模型称为分析模型（Analysis Model）。分析模型介于原始需求和计算机实现之间，是一种过度模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求；同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。

事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有：

• 边界类（boundary）：边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。只要是两个不同职责的簇之间的交互都需要有一个边界，换句话说，边界决定了外面能对里面做什么“事”。

• 实体类（entity）：原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。

• 控制类（control）：边界和实体都是静态的，本身并不会动作。UML采用控制类表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问需求。这样就把动作和物体分开了。考虑一下，实际上在现实世界中，动作和物体也是分开描述的。

或许小时候都玩过一个游戏，每个同学发四张小纸条，在第一张纸条上写上XXX的名字，在第二张纸条上写上在什么地方，在第三张纸条上写上一个动作，在第四张纸条上写一个物体，然后将这些字条分开放在四个箱子里，在随意地从这四个箱子里各取一张纸条，就能组成很多非常该校的句子，例如张XX在公园里跳圆规之类的奇怪语句，一个班的同学常常笑得前仰后合。

游戏虽然是游戏，但说明一个道理，只要有人、事、物和规则（定语），就能构成一个有意义的结果，无非是是否合理而已。分析类也是应用这个道理来把业务模型概念化的。由于所有的操作都通过边界类来进行，能做什么不能做什么由边界决定，所以边界实际上代表了原始需求中的“事”；实体类则由业务模型中的领域模型转化而来，它代表了现实世界中的“物”；控制类则体现了现实世界中的“规则”，也就是定语；再加上由参与者转化而来的系统的“用户”，这样以来，“人”也有了。有了人、事、物、规则，我们就可以像之前那个游戏一样把它们组合成各种各样的语句，只不过不是为了搞笑，所以不能随意组合，而是依据业务模型中已经描绘出来的用例场景来组合这些元素，让它们表达特定的业务含义。

另外，在这个阶段，还可以对这些分析类在不同的视角上进行归纳和整理。以表达软件要求的一些信息。例如包、组件和节点。软件架构和框架也通常在这个阶段产生。

下图展示了从业务模型到概念模型的转化过程：

经过概念模型的转换，业务模型看起来对计算机来说可理解了。但是要真正可执行的计算机代码，我们还有一步要走。我们需要将概念化模型实例化，即再次转化为计算机执行所需的设计模型。