第9章 领域模型

本文为《UML和模式应用(原书第3版)》读书笔记

---

UP制品关系样例

示例

下图是以UML类图表示法绘制的部分领域模型

什么是领域模型

• 领域模型是对领域内的概念类或现实世界中对象的可视化表示，是重要领域概念和词汇的可视化。领域模型也称为概念模型、领域对象模型和分析对象模型。
• 注意在UP中，术语“领域模型”指的是对现实世界概念类的表示，而非软件对象的表示。
• UP对领域模型的定义是，可以在业务建模科目中创建的制品之一。
• 领域模型是一组没有定义操作的类图，它提供给了概念透视图，可以展示：领域对象或概念类、概念类之间的关联、概念类的属性。
• 领域模型是可视化字典，表示领域的重要抽象、领域词汇和领域的内容信息，并对这些信息进行可视化和关联。
  

概念类

• 概念类是思想、事物或对象，它具有符号（表示概念类的词语或图形）、内涵（概念类的定义）和外延（概念类所使用的一组示例）。
• 领域模型不是数据模型，因此不会排除需求中没有明确要求记录其相关信息的类，也不会排除没有属性的概念类。
  

创建领域模型的动机

减少我们的思维与软件模型之间的表示差异；

领域模型创建步骤

寻找概念类

三条策略：1.重用和修改现有的模型；2.使用分类列表；3.确定名词短语；

使用分类列表
通过制作概念类候选列表来开始创建领域模型。

通过识别名词短语寻找概念类
在领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性，缺点是自然语言具有二义性和不精确性，一般与概念类分类列表一同使用。

绘制UML类图中的类

准则

• 让类框的底部和右侧呈开放状态，这样可以在发现新元素时方便地进行扩展。
• 如果模型需要更新和维护，则使用UML工具进行绘制。
• 在本次迭代中不涉及的事物应排除在外。
• 使用领域术语（例如领域中的参与者对某个事物的命名）。
• 非现实世界的建模需要高度抽象，例如电信交换机领域，有消息、端口、路由、协议等。
• 如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。 （例1销售和商店，商店不会被认为是数字或文本，而是一个合法实体、组织和占据空间的事物，因此store是概念类而不是sale的属性。）（例2航空和目的地机场，目的地机场是一种占据空间的大规模事物，因此是个概念而不是属性。）

描述类

• 包含描述其他事物的信息。例如记录价格、图片和文字描述等。
• 对象需要其他事物来记录其描述。
• 在以下情况需要增加描述类：1.需要有关商品或服务的描述，独立于任何商品或服务的现有实例。2.删除其所描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来。3.减少冗余或重复信息。

添加关联

• 关联是类（更精确地说，是类的实例）之间的关系，表示有意义和值得关注的连接。
• 在UML中，关联被定义为“两个或多个类元之间的语义联系，涉及这些类元实例之间的连接”。
• 关联表示了需要持续一段时间的关系，由于领域模型是从概念角度出发的，所以是否需要记录关联，要基于现实世界的需要，而不是基于软件的需要。例如收银员需要查询产品描述，但是不需要记住哪个收银员查询了哪个产品描述。
• 避免加入大量的关联，20个类可以有190条关联线，会使图变得混乱，应重点关注“需要记住”的关联。（n*（n-1））/2。
• 再领域建模过程中，大部分关联将作为设计模型和数据模型中的导航和可见性路径在软件中加以实现，但是添加关联是为了突出我们对重要关系的大致理解，而非记录对象或数据的结构。

关联表示法

连线

• 以“类名-动词短语-类名”的格式为关联命名，其中动词短语构成了可读的和有意义的顺序，诸如“拥有”、“使用”这样简单关联的名称是拙劣的，因为这种名称不会增强我们对领域的理解。（例如顾客使用现金，顾客通过现金完成支付）。
• 类元是首字母大写，因此关联名称以首字母开头。
• 关联本质上是双向的，但可以增加阅读导向箭头。

角色

关联的每一端称为角色

多重性

多重性定义了类A有多少个实例可以和类B的一个实例关联

两个类之间的多重关联

飞往和飞自是截然不同的关系，应该分别表示。

关联列表

属性

属性是对象的逻辑数据值。
- 当需求建议或暗示需要记住信息时，引入属性，例如商店需要名称和地址。
- 属性在类框图的第二格中表示。
- 完整语法：【可见性 名称：类型 多重性=默认值】（visibility name：type multiplicity = default {property-string}）。

• 大部分建模者会假设属性的可见性为私有的（-），因此通常不会显式地标出可见性符号。
• 一些属性需求（例如上图中middleName可以为空）可以写在词汇表（数据字典）中。
• 可以由其他信息导出的属性叫做导出属性，约定在属性名称前加以‘/’表示。
  
• 属性的类型应该是简单的数据类型，例如数字、布尔、时间和文本等，不应该是复杂的领域概念。

• 数据类型建模准则：
  

• 领域模型里的属性不应该用于表示概念类的关系，违反这一原则的常见情况是像在关系数据库设计中那样增加一种外键属性，用以关联两个类型。

• 对数量和单位建模（例如价格是13，重量是37，缺少了单位）。
  

  总结

  避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量建模工作，这些方式都应避免，这种过量的建模工作反而会导致分析停滞，每次迭代的领域模型建模时间不超过几个小时。