第四章 餐馆系统的业务模型
陈立岩陈立岩
业务模型（Business Modelling）
• 软件开发的早期阶段
• 输入:
– 非形式化的规格说明
• 活动:
– 创建用例模型（use case model）
– 创建领域模型（domain model）
– 创建词汇表（ glossary）
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
非正式需求
原有功能原有功能
采用手工预约单：
• 预约的信息
– 姓名和电话号码
– 就餐者人数
• 调换餐桌
• 取消预约作注释
• 未预约顾客（‘Walk-in’）
– 就餐人数
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
用例建模
• 第一次迭代应该只交付足够使系统提供某些确
实有商业价值的核心功能。
• 定义基本功能—建立初始用例图
• 系统应取代手工预约单
用例建模的步骤
1.识别用例的步骤
找出系统边界和范围
识别参与者
确定每个参与者所期望的系统行为
找出用例
2.定义初始用例图
识别用例——第一步：系统边界
考虑构造系统时，你所需要做的第一件事情是确定系
统的边界在哪里，需要定义什么是系统的组成部分
（系统的边界内）和什么是系统的外部（系统边界外）
。
系统边界是定义由谁或什么（参与者）使用系统，系
统能够为哪些参与者提供什么特定利益（用例）。
系统边界绘制为方框，标有系统名称，参与者绘制在
边界外部，用例绘制在边界内部。
识别用例—第二步：识别参与者
谁或什么使用该系统？
谁对某个特定功能感兴趣？
谁负责支持和维护系统？
系统有哪些外部资源？其它还有哪些系统将需
要与该系统进行交互？
参与者-Actors
• 人与系统进行交互时能够担任的不同角色 eg:
– 接待员Receptionist (makes bookings)
– 领班Head waiter (assigns tables etc)
• 一个用户在不同的时间可以扮演一个或多个角
色
• 顾客不是参与者
识别用例—第三步：描述用例
• 建立一组用例，使系统的用户能够使用系统完
成的不同的任务。
• 餐馆预约系统需完成的主要任务:
1 记录一个新的预约信息
2 取消一个预约信息
3 记录一位顾客的到来
4 将一位顾客的餐桌从一张餐桌移到另一张餐桌
（“调换餐桌”）
建立初始用例图（Use Case
Diagrams）
• 以图解的形式概括系统中的不同参与者和用例，
并显示哪些参与者能够参与哪些用例。
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
用例描述模板，见上章
用例描述没有统一的标准模板，可采用与
项目一致的格式。
从实用上，应更重视编写完整的和可理解
的事件路径，而不是按指定的模板填写每
个部分。
基本事件路径
• 正常交互的情况下的路径—不中断。
• 记录预约
1 接待员输入要预约的日期
2 系统显示该日的预约
3 有一张合适的餐桌可以使用：接待员输入顾客的
姓名、电话、预约的时间、用餐人数和餐桌号
4 系统记录并显示新预约。
可选事件路径
• 记录预约—没有可用的餐桌:
1 接待员输入要求的预约日期；
2 系统显示该日的预约；
3 没有合适的餐桌可以使用，用例终止
例外事件路径
• 记录预约—餐桌过小
1 接待员输入要求的预约日期；
2 系统显示该日的预约；
3 接待员输入顾客的姓名电话预约时间，用餐人数
和餐桌号
4 用餐人数多于餐桌容纳的人数，系统询问是否继
续预约
5 如果回答 “否”, 用例将不进行预约而终止
6 如果回答“是”, 预约将被输入，并附有一个警告
标志。
用户界面原型（可选）
• When writing use cases, it is useful to
have a rough idea of the planned user
interface
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
组织用例模型
记录到达：基本事件路径
（１）领班输入当前日期
（２）系统显示当天的预约
（３）领班确认一个选定的预约已经到达
（４）系统对此进行记录并更新显示器，将顾客
标记为已经到达。
记录到达—没有提前预订：可选事件路径
（１）领班输入当前日期
（２）系统显示当天的预约
（３）系统中没有记录该顾客的预约，领班输入
预约时间、人数和餐桌号，创建一个未预约登
记；
（４）系统记录并显示新预约。
以上两个用例存在共享功能
Use Case 包含
• 把共享部分分离出来组成一个新用例—显示预
约（Display Bookings）:
1 用户输入一个日期
2 系统显示当日的预约
• 更改“记录预约”用例，可以这样写:
1 接待员执行 ‘显示预约’用例
2 接待员输入……
3 系统记录和显示新预约
Use Case 包含
• 一个用例和它所包含的其他用例之间的关系，在用例图
中用一个连接两个用例的虚线箭头表示，称为依赖。
参与者泛化
一般参与者和特殊参与者之间的泛化关系。
参与者泛化把两个或多个参与者的公共行为分离出来成为父参与者。
¡ 接待员和领班都可以执行“显示预约”的用例；
¡ 描述一个新参与者—员工（staff）表达泛化；
¡ 接待员和领班被看作“员工”的特殊情况。
The ‘extend’ Dependency
• Use case extension is shown with a
dependency
何时使用高级特征
仅在简化模型并使模型易于理解时才使用高级特征。
用例最好是简单的。必须对于利益相关人和建模者都
是可访问的。
通常利益相关人仅需要一点培训和指导就能够容易地
理解参与者和用例。
利益相关人发现掌握参与者泛化更加困难。
太多〈include〉使得理解用例模型更加困难。
利益相关人对〈entend〉的理解相当困难。
很多建模者令人吃惊地错误理解〈extend〉的语义。
应该避免使用用例泛化，除非使用抽象父用例。
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
Complete Use Case Diagram
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
领域建模
在第四章中，UML表示法建立对象模型（学习建立
类图的画法和问题表达）
本节的核心思想：定义领域模型，提供建模的方法
或建模观点。
领域模型是OO分析中最重要的和经典的模型
领域模型（Domain Model），也称为概念模型、领
域对象模型，我们在对项目进行分析的时候，往往
会创建相应的领域模型。
寻找业务领域中的名词，建立类图和对象图。
领域模型包括：概念、关联、属性
领域模型的相关概念
1.概念：
概念类：表示在现实世界环境中具有意义的实体或概
念。
领域模型：是对业务术语进行描述，产生现实世界概
念类的一种表示。通常，采用类图表示，以显示最重
要的业务概念和他们之间的关系。
2.领域模型组成：
概念类
概念类之间的关系
概念类的属性（暂不包含操作，在以后考虑）
为什么需要领域模型？
理解关键概念和词汇
为进入设计阶段得到一些启示
现实世界与软件实现之间的过渡
建立领域模型
包括以下四步：
概念类的识别
在领域模型中描述这些概念类
建立类关联关系
添加必要的属性
建立领域模型
包括以下四步：
概念类的识别
在领域模型中描述这些概念类
建立类关联关系
添加必要的属性
1.概念类的识别
识别策略：
①使用概念类分类列表
②识别名词短语
策略1：概念类的分类列表（部分）
物理或具体对象
事物的实际、描述和规范
位置
交易
交易项目人的角色
组织
事件
策略2：根据名词短语识别找出概念类
即：识别有关用例文本描述中的名词和名词短语，
将它们作为候选的概念类或属性。
• 记录预约
1 接待员输入要预约的日期
2 系统显示该日的预约
3 有一张合适的餐桌可以使用：接待员输入顾客的姓名、
电话、预约的时间、用餐人数和餐桌号
4 系统记录并显示新预约。
建立领域模型
包括以下四步：
概念类的识别
在领域模型中描述这些概念类
建立类关联关系
添加必要的属性
建立候选概念类：
顾客、预定
顾客和预定建模：
Customer
Reservation
name
phoneNumber
1 *Make
建立候选概念类：
顾客、预定
Customer
Reservation
name
phoneNumber
1 *Make
covers
date
Time
places
Customer Reservation
name
phoneNumber
1 *Make
covers
date
time
table
places
*
1
{Reservation for the same
Table must not overlap}
WalkIn
covers
date
time
1
*
Booking
covers
date
time
table
places
WalkIn Reservation Customer
name
phoneNumber
* 1Make
{Reservation for the same
Table must not overlap}
* 1
本章内容
建立用例模型
非正式的需求
用例建模
描述用例（系统的用例编写，基本的事件路径）
组织用例模型（调整优化用例图）
完成用例模型（用例图的第二次迭代）
建立领域模型
建立词汇表
术语表
预约（Booking）：分配一张餐桌给用餐者进餐.
用餐人数（Covers）：预约将来用餐的人数。
顾客（Customer）：进行预定的人
用餐者（Diner）：在餐馆用餐的人
位子（Places）:在一张特定餐桌能够就座的用
餐人数。
预定（Reservation）：提前预约一个特定时间
的餐桌。
未预约（Walk-in）：没有提前进行的预约。
Thank You!
