领域模型

22
准则：属性与类的常见错误
• 常见错误：把应该是概念类的事物表示为属性 • 判别准则：如果我们认为某概念类X不是现实世 界中的数字或文本，那么X可能是概念类而不是 属性。
Sale store 或…? Sale Store phoneNumber
Flight destination
或…?
Flight
Airport name
23
准则：何时使用“描述”类建模
• 描述述(description class)包含描述其它事 物的信息。如：ProductDescription记录 Item的价格、图片和文字描述。命名方式： 项目-描述符
24
准则：何时需要描述类
1.需要有关商品或服务的描述，独立于任何商务或服务现有实例 2.删除其所描述事物(如Item)的实例后，导致信息丢失，而这些信息是需 要维护的，但是被错误地与所删除的事物关联起来 3.减少冗余或重复信息
29
观点：关联是否会在软件中实现
• 在领域建模中，关联不是关于数据流、数 据库外键联系、实例变量或软件方案中的 对象连接语句；关联声明是针对现实领域 从纯概念角度看有意义的关系。 • 这些关系的大部分将作为（设计模型和数 据模型中的）导航和可见性路径在软件中 加以实现。
30
应用UML:关联表示法
设计
图9-1 UP制品样例的影响
4
概念或 领域对象
Sales LineItem quantity 1..* 0..1
Records-sale-of 1
Item
*
Stocked-in
关联
Contained-in 1 Sale Store address name 1 Houses Paid-by 1 Payment amount 1..* Register Captured-on 1 1
Flight date number time Flies-to Airport 较差 1 name
*
Flight Described-by date time
FlightDescription 1 number
较好
*
*
Describes-flights-to 1 Airport name
图9-10 对其它事物的描述
Item description price serial number itemID 较差
ProductDescription description price itemID Describes 1 Item 较好
*
serial number
图9-9 关于其它事物的描述
25
示例：航空领域中的描述
• 在领域模型中要考虑如下关联：
– 如果存在需要保持一段时间的关系，将这种语 义表示为关联（“需要记住”的关联）。 – 从常见关联列表中派生的关联（见P115表9-2）
28
准则：为什么应该避免加入大量关联
• 节点间可以有(n*n(n-1))/2个关联 • 太多关联，会产生“视觉干扰，使图变混 乱。 • 要谨慎地增加关联线，并重点关注”需要 记住“的关联。
19
准则：报表对象-模型中是否要包括“票据”
• 一般来说，在领域模型中显示其它信息的报表并 没有意义，因为其所有信息都是源于或复制于其 他信息源的。这是排除它的理由 • 另一方面，就业务规则而言，票据有特殊的作用： 通常持有（纸质）票据的人有退货的权利。这是 在模型中要表示它的原因 在本次迭代中没有考虑退货，所以不应包括票据。 在解决“处理退货”用例的迭代中，再考虑将其 包含在内。
启发了对象 及其名称
UP 设计模型 面向对象开发者在创建软件类时受到真实世界领域的启发 因此，涉众所设想的领域与其在软件的表示之间的表示差异被 降低
图9-6 OO建模减小了表示差异
12
如何创建领域模型
1. 寻找概念类 2. 将其绘制为UML类图中的类 3. 添加关联和属性
13
如何找到概念类
• 找到概念类的三条策略
• 理解关键概念和词汇
11
动机：降低与OO建模之间的表示差异
UP领域模型 涉众对领域内重要概念的看法 Payment 领域模型中的Payment是概念， 但在设计模型中的Payment是软 件类。它们不是一回事，但前 者对后者的名称和定义有启发 作用。 这减少了表示差异 这是对象技术的主要思想之一 Payment amount: Money getBalance(): Money 1 Pays-for 1 date: Date startTime: Time getTotal(): Money ... Sale amount Sale 1 Pays-for 1 date time
20
准则：像地图绘制者一样思考：使用领域术语
• 使用地域中现有的名称。在图书馆模型中， 将顾客命名为“借书者”、“赞助者”等， 这是图书馆职员使用的术语。 • 排除无关或超出范围的特性 • 不要凭空增加事物
21
准则：如何对非现实世界建模
• 有些软件系统的领域与自然领域或业务领 域几乎没有类似之处，例如：电信软件。 • 此时需要高度的抽象，对常见的非OO设计 进行回顾，并且认真汲取领域专家所使用 的核心词汇和概念。 • 例如，电信软件的候选概念类：消息、连 接、端口、会话、路由、协议。
32
应用UML：角色
• 关联的每一端称为角色(role)。角色具有如 下可选项
– 多重性表达式 – 名称 – 导航
33
应用UML：多重性
多重性(mumltiplicity)定义了类A有多少个实例可以和类B的一 个实例关联 T 0或更多，“多” *
1..*
Store Stocks 1 Item
T
1或更多
经历状态变化的领域对象、 属性和关联
领域模型中某 些术语的细化
Operation: enterItem(…) Post-conditions: -... 操作契约
Cashier: … Item ID: … ... 词汇表
需求
领域中的 概念类会 给某些设 计中软件 类的名称 带来启示
设计模型 : Register enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) ... : ProductCatalog : Sale
3
UP制品关系示例 域模型 Sale date ... 1 1..* Sales LineItem quantity ... ...
业务建模
概念类、术语、概念、 属性、关联
用例模型 Process Sale 1. Customer arrives ... 2. ... 3. Cashier enters item identifier. 4.... 用例文本
17
准则：敏捷建模-绘制类图的草图
• 注意图9-8中UML类图的风格，让类框的底 部和右侧呈开放状态，以方便扩展。
18
准则：敏捷建模-是否要使用工具维护模型
• 在后期的草图设计中或编程中发现新的概 念类，是否需要更新早期的概念模型？视 情况而定 • 通常，进化的软件领域层对大部分重要术 语会给予提示，而且长生命期的OO分析领 域模型不会增加价值。
– Sale paid-by CashPayment
• 反面示例（动词短语没有增加意义），Sale Uses CashPayment
– Player is-on Square
• 反面示例（动词短语没有增加意义），Player Has Square
• 关联名首字母应该大写，因为关联表示的是实例之 间链接的类元。
26
关联(association)
• 关联是类（更精确也说，是这些类的实例）之间 的关系，表示有意义和值得关注的连接。 • 在UML中，关联被定义为“两个或多个类之间的 语义联系，涉及这些类元实例之间的连接。
关联
Register
Records-current 1 1
Sale
图9-11 关联
27
准则：何时表示关联
-"阅读方向箭头" -没有其他含义，只是表示阅读关联标记的方向 -通常省略(缺省：从左到右，从上到下）
Register
Records-current 1 0..1
Sale
关联名称
多重性
图9-12 关联的UML表示法
31
准则：在UML中如何对关联命名
• 以“类名-动词短语-类名”的格式为关联命名，其中 的动词短语构成了可读的和有意义的顺序。 • 例
*
1..40
T
1~40
角色的多重性
5
T
精确地为5
图9-13 关联的多重性
3, 5, 8
T
精确地为3，5或8
图9-14 多重性的取值
34
多重性是和语境有关的
Store 1 or 0..1 Stocks Item
*
多重性应该是“1”还是“0..1”？ 答案取决于我们使用模型时的关注点。典型的和实际的情形下，多重性表示了我们所关注的领域约束，如果这种关系 实现或反映在软件对象或数据库中，则我们期望能够在软件中对此进行校验。例如：某个商品可能已经售出或废弃， 因此商店中不会有库存。从这个观点来看，“0..1”是符合逻辑的，但是„ 我们关心这一观点吗？如果这一关系在软件中实现，我们可能希望确保一个Item软件实例总是和一个特定Store实例关 联，否则将在软件元素或数据中提示错误。 这个部分领域模型并非表示软件对象，但是多重性记录了约束，其实际值通常与我们在构建软件或数据库（反映了真 实世界领域）时所关注的有效性校验。从这个观点来看，“1”可能是恰当的值。
– 重用和修改现有模型。
• 在许多常见领域中都存在已发布的，绘制精细的领 域模型和数据模型
– 使用分类列表（见P104表9-1） – 确定名词短语。将对领域的文本描述中的名词 和名词短语作为候选的概念类或属性。（见 P106用例的文本描述）
14
示例：寻找和描述概念类(NextGen POS） • 根据分类列表衙名词短语分析，可以得到 该领域候选概念类的列表 • 根据迭代1所考虑的需求和简化的处理销售 用例，即基本的现金交易场景，可以得到 如P107所示的候选概念类的列表。 • 没有什么所谓“正确”列表。上述列表中 的抽象事物和领域词汇在一定程度上是随 意收集的，但都是建模者认为重要的。 • 实践中，可以不会创建文本列表，而是直 接绘制成UML类图。见图9-7.
软件制品，不属于领域模型
避
免
date time print()
Sale 软件类，不属于领域模型
图9-4 领域模型并非表示软件制品或类
7
“领域模型”的两个传统含义
• 含义一：领域模型是现实世界中对象的概 念透视图，而非软件透视图 • 含义二：软件对象的领域层。在表示层之 下的软件对象层是由领域对象组成的。领 域对象是表示问题领域空间事物的软件对 象，并且与“业务逻辑”或“领域逻辑” 方法相关 • 在本书中，用领域层(domain layer)来表示 第二种含义
15
Register
Item
Store
Sale
Sales LineItem
Cashier
Customer
Ledger
Cash Payment
Product Catalog
Product Description
图9-7 初始的POS领域模型
16
案例：Monopoly领域
图9-8 初始的Monopoly领域模型
sale-4
图9-5 概念类具有符号、内涵和外延
9
领域模型和数据模型是一回事吗
• 领域模型不是数据模型（持久化数据） • 在领域模型中不会排除没有明确要求记录 其相关信息的类，也不会排除没有属性的 概念类
– 在领域内充当纯行为角色而不是信息角色的概 论类也是有效的。
10
பைடு நூலகம்
动机：为什么要创建领域模型
8
什么是概念类
• 概念类是思想、事物或对象。更正式地讲，概念类 可以从其符号、内涵和外延来考虑。
Sale date time 概念符号:表示概念类的词语或图形
“Sale表示购买交易的事件、 具有日期和时间”。
概念内涵：概念类的定义
sale-1 sale-2
sale-3
概念外延：概念类所适用 的一组示例
第9章 领域模型 Domain Model
1
领域模型
• 领域模型是对领域内的概念类或现实中对 象的可视化表示 • 领域模型也称为概念模型、领域对象模型 和分析对象模型 • 领域模型是可以在业务建模科目中创建的 制品之一 • 领域模型是UP业务对象模型(BOM)的特化
2
领域模型
• 领域模型是OO分析中最重要的和经典的模 型。 • 确定一组概念类是OO分析的核心。（每次 早期迭代不超过几个小时的时间来完成这 项工作） • 领域模型的范围限定于当前迭代所开发的 用例场景，通过迭代不断演进。 • 领域模型与其它制品的关系见图9-1 • 领域模型的示例见图9-2
属性
date time 1
0..1
图9-2 部分领域模型：可视化字典
5
领域模型是软件业务对象图吗
在UML中，领域模型被描 述为一组没有定义操作的 类图
Sale dateTime
对领域内所关注的真实世界概念的可视化 并非表示软件类
图9-3 领域模型表示真实世界概念的可视化并非表示软件类
6
避
免
SalesDatabase