这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
UML提供的元素
- 第一参与者，UML采用称之为参与者(actor)的元模型作为信息来源提供者，参与者代表现实世界的“人”。参与者是模型信息来源的提供者，也是第一驱动者。
- 另外，在这个顾客就是上帝的时代，以参与者也就是“人”为中心还顺应了“以人为本”这一时代的要求，更容易获得客户满意度。
- 第二，UML采用称之为用例(use case)的一种元模型来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。这个业务目标就是现实世界中的“事”。而这件事是怎么做的，依据什么规则，则通过称之为业务场景(business scenario)和用例场景(use case scenario)的UML视图来描绘。这些场景便是现实世界的“规则”。
- 最后，UML通过称之为业务对象模型(business object model)的视图说明在达成这些业务目标的过程中涉及到的事物，用逻辑概念来表示它们，并定义它们之间的关系。业务对象模型则代表了现实世界中的“物”。
分析模型的元模型
- 事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有：
- 边界类(boundary)。边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。
- 实体类(entity)。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。
- 控制类(control) 。边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。
- 边界类实际上代表了原始需求中的“事”；实体类则由业务模型中的领域模型转化而来，它代表了现实世界中的“物”；控制类则体现了现实世界中的“规则”，也就是定语；再加上由参与者转化而来的系统的“用户”，这样一来，“人”也有了。
