Thinking in UML（第一章）

UML（Unified Modeling Language）即统一建模语言。是一种建模用的语言。

    UML定义了一些建立模型所需要的、表达某种特地含义的基本元素，这些元素称为元模型，相当于语言中的基本词汇，例如用例、类等。另外，UML还定义了这些元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界；这些规则和图形称为表示法或视图（View），相当于语言中的语法。学习UML无非是掌握基本词汇的含义，在掌握语法，通过语法将词汇结合起来形成一篇有意义的文章。

从现实世界到业务模型
从理论上说，建立模型是指通过对客观事物建立一种抽象的方法，用来表征事物并获得对事物本身的理解，再把这种理解概念化，并将这些逻辑概念组织起来，形成对所观察的对象的内部结构和工作原理的便于理解的表达。

建立模型的关键就是弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人事物之间的关系定义出来，一个模型也就基本成型了。

那么UML是不是提供了这样的元素来为现实世界建立模型呢？是的。

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

人、事、物、规则就是这样被模型化的。

从业务模型到概念模型

UML通过称之为概念化的过程来建立适合计算机理解和实现的模型，这个模型称为分析模型（Analysis Model）。分析模型介于原始需求和计算机实现之间，是一种过度模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求；同时分析模型向下为计算机的实现规定了一种高层次的抽象，这种抽象是一种指导也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。

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

• 边界类（boundary）

。里外的事物交互需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。边界决定了外面能对里面做什么“事”。

• 实体类（entity）

。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。

• 控制类（control）

。边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，及业务或用例场景中的步骤和活动。边界类和边界类之间、实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。

分析类将业务模型概念化，由于所有的操作都通过边界类来进行，能做什么不能做什么由边界决定，所以边界类实际上代表了原始需求中的“事”，实体类代表了现实世界中的“物”，控制类是“规则”，再加上参与者转化而来的系统“用户”，这样一来，人、事、物、规则都有了，就可以依据业务模型中已经描绘出来的用例场景来组合这些元素，让给它们表达特定的业务含义。

从概念模型到设计模型

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

本作品采用《CC 协议》，转载必须注明作者和本文链接