领域模型

*
Store Stocks 1 1
*
Item
1 1..* Contained-in 1 Sale Logscompleted
*
1..*
Houses
1..* Register
*
Captured-on 0..1 1
Paid-by 1 CashPayment
1
1
Is-for 1 Customer
1
3 Works-on 1 Cashier
sale-4
图9-5 概念类具有符号、内涵和外延
9
领域模型和数据模型是一回事吗
领域模型不是数据模型（持久化数据） 在领域模型中不会排除没有明确要求记录 其相关信息的类，也不会排除没有属性的 概念类
– 在领域内充当纯行为角色而不是信息角色的概 论类也是有效的。
10
动机：为什么要创建领域模型
理解关键概念和词汇
反面示例（动词短语没有增加意义），Player Has Square
关联名首字母应该大写，因为关联表示的是实例之 间链接的类元。
32
应用UML：角色
关联的每一端称为角色(role)。角色具有如 下可选项
– 多重性表达式 – 名称 – 导航
33
应用UML：多重性
多重性(mumltiplicity)定义了类A有多少个实例可以和类B的一 个实例关联
17
准则：敏捷建模-绘制类图的草图
注意图9-8中UML类图的风格，让类框的底 部和右侧呈开放状态，以方便扩展。
18
准则：敏捷建模-是否要使用工具维护模型 在后期的草图设计中或编程中发现新的概 念类，是否需要更新早期的概念模型？视 情况而定 通常，进化的软件领域层对大部分重要术 语会给予提示，而且长生命期的OO分析领 域模型不会增加价值。
31
准则：在UML中如何对关联命名
以“类名-动词短语-类名”的格式为关联命名，其中 的动词短语构成了可读的和有意义的顺序。 例
– Sale paid-by CashPayment
反面示例（动词短语没有增加意义），Sale Uses CashPayment
– Player is-on Square
15
Register
Item
Store
Sale
Sales LineItem
Cashier
Customer
Ledger
Cash Payment
Product Catalog
Product Description
图9-7 初始的POS领域模型
16
案例：Monopoly领域
图9-8 初始的Monopoly领域模型
图9-9 关于其它事物的描述
25
示例：航空领域中的描述
Flight date number time Flies-to Airport 1 name
*
Flight Described-by date time
FlightDescription 1 number
*
*
Describes-flights-to 1 Airport name
43
导出属性
图9-21 在销售项目中记录售出的商品数量
44
准则：什么样的属性类型是适当
领域模型中属性的类型更应该是数据类型。十分常见的数据 类型包括：Boolean,Date,Number,Character,String, Time等， 其它常见的类型有Address,Color,Geometrics,Phone Numer,Social Security Number,Universal Product Code(UPC),SKU,ZIP，枚举类型等
20
准则：像地图绘制者一样思考：使用领域术语 使用地域中现有的名称。在图书馆模型中， 将顾客命名为“借书者”、“赞助者”等， 这是图书馆职员使用的术语。 排除无关或超出范围的特性 不要凭空增加事物
21
准则：如何对非现实世界建模
有些软件系统的领域与自然领域或业务领 域几乎没有类似之处，例如：电信软件。 此时需要高度的抽象，对常见的非OO设计 进行回顾，并且认真汲取领域专家所使用 的核心词汇和概念。 例如，电信软件的候选概念类：消息、连 接、端口、会话、路由、协议。
19
准则：报表对象-模型中是否要包括“票据”
一般来说，在领域模型中显示其它信息的报表并 没有意义，因为其所有信息都是源于或复制于其 他信息源的。这是排除它的理由 另一方面，就业务规则而言，票据有特殊的作用： 通常持有（纸质）票据的人有退货的权利。这是 在模型中要表示它的原因 在本次迭代中没有考虑退货，所以不应包括票据。 在解决“处理退货”用例的迭代中，再考虑将其 包含在内。
图9-13 关联的多重性
图9-14 多重性的取值
34
多重性是和语境有关的
图9-15 多重性是和语境有关的
35
应用UML：两个类之间的多重关联
*
Flight
Flies-to Flies-from
1 Airport 1
*
图9-16 多重关联
36
示例：NextGen POS中的关联
Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem 1 Recordsaccountsfor 1 Used-by Describes 1..* Ledger Product Catalog
14
示例：寻找和描述概念类(NextGen POS） 根据分类列表衙名词短语分析，可以得到 该领域候选概念类的列表 根据迭代1所考虑的需求和简化的处理销售 用例，即基本的现金交易场景，可以得到 如P107所示的候选概念类的列表。 没有什么所谓“正确”列表。上述列表中 的抽象事物和领域词汇在一定程度上是随 意收集的，但都是建模者认为重要的。 实践中，可以不会创建文本列表，而是直 接绘制成UML类图。见图9-7.
图9-10 对其它事物的描述
26
关联(association)
关联是类（更精确也说，是这些类的实例）之间 的关系，表示有意义和值得关注的连接。 在UML中，关联被定义为“两个或多个类之间的 语义联系，涉及这些类元实例之间的连接。
图9-11 关联
27
准则：何时表示关联
在领域模型中要考虑如下关联：
40
应用UML：属性表示法
图9-19 类和属性
41
更多表示法
在UML中，属性的完整语法是： visibility name:type multiplicity = default {property-string}
图9-20 UML属性表示法
42
准则：在哪里记录属性需求
middleName:[0..1]等是嵌入到领域模型的 需求或领域规则 建议把所有这种属性需求置于UP词汇表中 （UP词汇表可充当数据字典）
图9-17 NextGen POS部分领域模型
37
示例：Monopoly中的关联
图9-18 Monopoly部分领域模型
38
属性
属性(attribute)是对象的逻辑数据值 确定概念类的属性是有助的，能够满足当 前所开发场景的信息需求。
39
准则：何时展示属性
当需求(例如：用例)建议或暗示需要记住信 息时，引入属性。
22
准则：属性与类的常见错误
常见错误：把应该是概念类的事物表示为属性 判别准则：如果我们认为某概念类X不是现实世 界中的数字或文本，那么X可能是概念类而不是 属性。
Sale store 或…? Sale Store phoneNumber
Flight destination
或…?
Flight
Airport name
– 如果存在需要保持一段时间的关系，将这种语 义表示为关联（“需要记住”的关联）。 – 从常见关联列表中派生的关联（见P115表9-2） P115 9-2
28
准则：为什么应该避免加入大量关联
节点间可以有(n*n(n-1))/2个关联 太多关联，会产生“视觉干扰，使图变混 乱。 要谨慎地增加关联线，并重点关注”需要 记住“的关联。
可以用许多方法来表示对象之间的关系，外键是 其中的一种
图9-25 不要将属性作为外键
49
准则：对数量和单位建模
图9-26 对数量建模
50
示例：NextGen POS中的属性
Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem quantity 1..* Contained-in 1 Sale dateTime / total 1 Paid-by 1 CashPayment amountTendered 1 Logscompleted 1 Recordsaccountsfor 1 Used-by 1..* item ID description price Describes Ledger Product Catalog
8
什么是概念类
概念类是思想、事物或对象。更正式地讲，概念类 可以从其符号、内涵和外延来考虑。
Sale date time 概念符号:表示概念类的词语或图形
“Sale表示购买交易的事件、 具有日期和时间”。
概念内涵：概念类的定义
sale-1 sale-2
sale-3
概念外延：概念类所适用 的一组示例
29
观点：关联是否会在软件中实现
在领域建模中，关联不是关于数据流、数 据库外键联系、实例变量或软件方案中的 对象连接语句；关联声明是针对现实领域 从纯概念角度看有意义的关系。 这些关系的大部分将作为（设计模型和数 据模型中的）导航和可见性路径在软件中 加以实现。
30
应用UML:关联表示法
图9-12 关联的UML表示法
11
动机：降低与OO建模之间的表示差异
图9-6 OO建模减小了表示差异
12
如何创建领域模型
1. 寻找概念类 2. 将其绘制为UML类图中的类 3. 添加关联和属性
13
如何找到概念类
找到概念类的三条策略
– 重用和修改现有模型。
在许多常见领域中都存在已发布的，绘制精细的领 域模型和数据模型
– 使用分类列表（见P104表9-1） – 确定名词短语。将对领域的文本描述中的名词 和名词短语作为候选的概念类或属性。（见 P106用例的文本描述）
23
准则：何时使用“描述”类建模
描述述(description class)包含描述其它事 物的信息。如：ProductDescription记录 Item的价格、图片和文字描述。命名方式： 项目-描述符
24
准则： 准则：何时需要描述类
1.需要有关商品或服务的描述，独立于任何商务或服务现有实例 2.删除其所描述事物(如Item)的实例后，导致信息丢失，而这些信息是需 要维护的，但是被错误地与所删除的事物关联起来 3.减少冗余或重复信息
第9章 领域模型 Domain Model
1
领域模型
领域模型是对领域内的概念类或现实中对 象的可视化表示 领域模型也称为概念模型、领域对象模型 和分析对象模型 领域模型是可以在业务建模科目中创建的 制品之一 领域模型是UP业务对象模型(BOM)的特化
2
领域模型
领域模型是OO分析中最重要的和经典的模 型。 确定一组概念类是OO分析的核心。（每次 早期迭代不超过几个小时的时间来完成这 项工作） 领域模型的范围限定于当前迭代所开发的 用例场景，通过迭代不断演进。 领域模型与其它制品的关系见图9-1 领域模型的示例见图9-2
图9-22 使用关联而不是属性表示关系
45
准则：何时定义新的数据类型类
见P120表9-3
46
准则：通过关联而不是属性来表示 概念类之间的关系
图9-23 不要用属性表示复杂概念
47
应用UML：在何处描述这些数据类型类
Address Store 1 1 street1 street2 cityName ...
ItemID OK Product Description 1 1 id manufacturerCode countryCode
OK
ห้องสมุดไป่ตู้
Product Description itemId : ItemID
Store address : Address
图9-24 表示对象的数据类型特性的两种方式
48
准则：任何属性都不表示外键
3
图9-1 UP制品样例的影响
4
图9-2 部分领域模型：可视化字典
5
领域模型是软件业务对象图吗
在UML中，领域模型被描 述为一组没有定义操作的 类图
图9-3 领域模型表示真实世界概念的可视化并非表示软件类
6
图9-4 领域模型并非表示软件制品或类
7
“领域模型”的两个传统含义
含义一：领域模型是现实世界中对象的概 念透视图，而非软件透视图 含义二：软件对象的领域层。在表示层之 下的软件对象层是由领域对象组成的。领 域对象是表示问题领域空间事物的软件对 象，并且与“业务逻辑”或“领域逻辑” 方法相关 在本书中，用领域层(domain layer)来表示 第二种含义