订餐业务管理系统的需求描述
“Restaurant On Wheels”公司（下文简称 ROW 公司）是一家以面向团体客户提供电话订餐服务为主营业务的
餐饮企业。为减少投资风险，该公司自己并不生产外卖食品，而是与周边的多家餐馆建立合作关系，这种合作关
系允许 ROW 公司以批发价格和记帐支付的形式获得客户订购的各种套餐。每个季度 ROW 公司将根据合作餐馆
对外卖套餐的更新情况整理订餐目录，并将其送往各个注册的客户手中。ROW 有专门的市场营销人员推广公司
的服务，客户通过登记相应的联系信息即可获得注册资格，注册客户将获得具有唯一编号的订餐卡，并在每个季
度得到最新的订餐目录。当需要订餐时，客户通过电话说明自己的订餐卡号码、要订购套餐的目录编号及数量，
订餐员在核对必要信息后登记订餐内容，建立客户订单。对每一张客户订单要产生一张配送签收单以说明客户的
配送地址、联系电话、所订购的套餐名称、数量，以及按零售价计算出的应支付金额，同时订单中的由同一家合
作餐馆供应的订单项要汇总形成记帐单，说明要在该餐馆采购的套餐名称、数量和按批发价计算出的记帐金额，
记帐单支付给相应的合作餐馆，作为月底 ROW 公司与各家合作餐馆结帐的依据。每一个订单由一名配送人员执
行，配送人员通过记帐单到各家餐馆购买所订购数量的套餐，并按配送单将其送往指定的客户地址，客户支付现
金并签收配送单。每天配送员要与经理进行当天交易的现金结算。
ROW 公司的员工主要分为市场推广员、配送员、订餐员三类。工资对订餐员支付固定工资，对市场推广员
和配送员则在固定工资基础上再支付一定数额的奖金；市场推广员的奖金根据其推广的客户当月的订餐总金额进
行计算，配送员的奖金则按照他所执行的配送任务次数进行计算。目前随着 ROW 公司业务规模的逐步扩大，迫
切需要开发一个订餐业务管理系统以支持如下工作：
1. 维护与合作餐馆的联系
2. 维护与注册客户的联系
3. 管理每个季度所提供的套餐种类
4. 有效处理客户的订餐要求，生成执行订单的各种单据。
5. 管理员工信息，并自动计算月薪
6. 对每个月的销售情况、收支情况、结帐情况等信息进行统计。
7. ……
数据域分析与建模过程
1. 根据需求描述，寻找业务领域中的重要“事务”
合作餐馆、订餐目录、套餐产品、客户、订单、订单项（明细）、记帐单、配送单、市场推广员、配送员
2. 说明事物之间的关系，建立实体关系对
a) 合作餐馆——提供——套餐产品
b) 套餐产品——组成——订餐目录
c) 市场人员——推广——客户
d) 客户——下达——订单
e) 订单——包含——订单项
f) 配送员——执行——订单
g) 记帐单——采购——订单项
h) 记帐单——支付给——合作餐馆
i) ……
3. 考察每个实体关系对的基数、形态
4. 指定每个实体的属性
5. 复审实体关系模型
订餐业务管理系统的实体关系图模型
订餐
目录项
组成
订单项
明细
合作餐馆
注册客户
记帐单
1 n 提供1..n 1..1
包含
1..1
客户订单
配送人员 执行
0..n
1..1
地址
电话
转帐帐号
单位地址
电话
订餐卡号
1..1
1..n
订餐
0..n
订购数量
批发价格零售价格
名称 目录编号
1..1
1..n
1..1
采购
记帐金额
记帐日期
支付
0..n
订单日期
订单金额
文字介绍
图例
套餐产品
0..n
1..1
参照
市场人员
推广1..1
0..n
季度
订单ID
目录编号
支付餐馆ID
餐厅ID
供应餐厅ID
帐单ID
ROW 订餐业务管理系统的 OO 分析与建模
1. 用例分析
a) 用例是系统向使用者提供的某个完整的服务（功能）单元，用以处理在应用领域中可能发生的一种
实际情况。当这种情况发生时，用例被激活，此时“参与者”同系统中的用例构成一个“交互场景”
（执行过程），并最终产生一个符合“参与者”使用目的的结果。
b) 用例是“动态”的。它是“外部参与者”与“软件系统”对某种业务情况进行处理的“过程”。因此对于用
例的命名应该是“动词性”的，如“订餐处理”，“当日配送结算”。
c) 用例是“相对独立”的。即系统中的一个用例应该完成与“处理某种业务情况”有关的全部工作。要注
意，用例不是流程图，用例之间不是连续执行的，也不应该形成“紧密”的依赖关系。
2. 就 ROW 订餐系统而言，软件的应用领域中可能发生哪些”需要被处理的情况”，由“谁”负责使用系统的
“相应服务”进行处理呢？
需要被处理的业务情况（需求） 参与者 用例
客户打电话订餐 订餐员 订餐处理
客户打电话取消未执行的订单 订餐员 取消订餐
发展了新的客户，需要进行注册 市场推广员 客户注册
新的合作餐馆加盟 经理 注册合作餐馆
合作餐馆终止合作关系 经理 删除合作餐馆
每天下班前结算当天的订餐收入 经理、配送员 当日订餐结算
每个月底结算与各家合作餐馆的记帐金额 经理 当月记帐结算
每个月底对所雇佣的员工发工资 经理、员工 结算员工工资
…………
3. ROW 系统的用例图（……）
4. 用例文档（以用例“订餐处理”为例）
订餐员
员工
配送员
经理
合作餐馆
结算员工工资
注册合作餐馆
当月记帐结算删除合作餐馆
市场推广员
当日订餐结算
订餐处理
取消订餐
客户注册
客户
用例编号 UC_01 用例名 订餐处理
简述 处理注册客户的电话订餐
前置条件 订餐客户已在系统中注册，并获得了有效的订餐目录。订餐员通过执行“订餐”的菜单命令
激活该用例。
事件流 1． 系统显示订餐窗口
2． 餐员在订餐窗口中输入客户的订餐卡编号。
3． 系统显示出持卡客户的注册信息。
E2：该客户未在系统中注册，系统提示“卡号无效”，用例结束
4． 订餐员核对客户的注册信息。
E3：客户答复与注册信息不符，用例结束。
5． 订餐员输入用户订购的套餐产品编号。
6． 系统显示套餐名称及单价
7． 订餐员输入订购的数量。
X6：若用户订购多于一种套餐，返回 4。
7． 订餐员在窗口的列表中选择执行配送的配送员
8． 订餐员提交订餐信息。
9． 系统显示订单确认窗口，显示订单内容。
10．订餐员确认订单内容
E10：订餐员取消订单，用例结束。
11．系统保存订单
12．系统打印“签收单”
13．系统将订购套餐按“供应餐馆”分组，打印记帐单
后置条件 若用例执行成功，系统登记订单，打印相应的“记帐单”和“配送签收单”
5. 活动图——对用例文档建模（以用例“订餐处理”为例）
系 统订 餐 员
输 入 订 餐 卡 号
提 示 卡 号 无 效
[卡 号 无 效 ]
显 示 客 户 信 息
核 对 客 户 信 息
[核 对 失 败 ]
输 入 套 餐 编 号 显 示 套 餐 名 、 单 价
输 入 订 餐 数 量
[订 购 其 他 套 餐 ]
分 配 配 送 人 员
提 交 订 餐 内 容 弹 出 订 单 窗 口 显 示 订 餐 信 息[取 消 订 单 ]
保 存 订 单
[确 认 订 单 ]
打 印 签 收 单 分 组 打 印 记 帐 单
显 示 订 餐 窗 口
6. 系统静态结构分析
a) 静态结构分析即分析系统应由哪些事物构成，以及这些事物之间的关系。采用类图进行建模。
b) 一次性的确定完整系统的静态结构难度较大，通常以系统中的某个用例为范围，寻找参与到该用例
执行过程中的事物。
c) 分析系统“静态结构”可以采用“词性分类”、CRC（类职责协作）卡片等技术。可以通过分析用例文
档中交互过程描述寻找系统中的实体类，分析过程应该力求回答如下问题：
i. 当参与者完成了某个操作后，系统应该对应执行哪些动作；
ii. 系统执行这些动作时必须使用哪些数据，什么“事物”负责提供和管理这些数据；
iii. 系统执行的每个动作是什么“事物”的职责——简单的说就是“系统要干的活”应该由系统中的哪
个对象具体去干。
d) 分析过程举例
1． 系统显示订餐窗口
a) 这条信息说明系统内一定包含一种组成元素叫“窗口对象”
b) 窗口对象提供说明自身特征的数据，如窗口大小、位置、窗口表面的可视元素等。
c) 窗口对象至少包含一个职责，那就是“显示自己”
2． 系统显示出持卡客户的注册信息。
a) 系统要完成这个动作，要用到与客户有关的数据，这些数据是说明“窗口”特征的么？
很显然不是，所以系统内除了“窗口对象”以外一定还有其他的对象是提供和管理这部
分数据的——“客户”对象。
b) 窗口对象通过找到对应的“客户对象”获得需要显示的数据。从职责上看“窗口”必须承
担“显示客户信息”的职责，而“客户”对象则必须负责提供“注册信息”。
c) “窗口”和“客户”之间必须有联系，以确保“窗口”能找到“客户”。
3． 系统显示套餐名称及单价
a) 系统必须记下来用户要购买什么，“谁”负责从整体上保存和管理一次电话订餐所产生
的全部订购信息呢。——订单对象
b) 订单对象是由若干条订购信息组成的集合。这个集合中的每一条订购信息要说明买什
么套餐，买多少——这又构成了一个规模更小的独立组成部分“订单项”。
c) 每输入一个订单项要显示对应套餐的信息（名称、单价等），这部分信息谁提供——
套餐产品。
4． 订餐员在订餐窗口的列表中选择可用的配送人员
a) 系统中一定有“配送人员”对象。
b) 这个对象至少两个状态：可用或不可用
c) 这个操作步骤的目的是什么？要建立配送员和订单之间的联系。
5． 依次类推，我们还可以找到的对象包括：“订单确认窗口”、记帐单、合作餐馆等等。
6． 讨论：配送单是不是系统中必须包括的对象。确定的依据是什么？
a) “配送单”这个对象是不是提供和维护了系统工作过程中必须要使用到的，并且不能由
其他对象提供的数据？——从数据成员的角度上、配送单和订单一致。
b) “配送单”这个对象是不是提供了系统工作过程中必须要应用的职责（功能），并且这
个功能无法从其他对象中得到。事实上，“配送单”是系统打印给外部参与者的一张纸，
这张纸所参与的是配送员和客户在客户家里签收的手工过程（签收不是系统用例，不
是在系统中执行的动作）。
c) 基于上述原因及需求假设可以考虑将配送单不作为系统中的实体类。
e) 该用例范围内的主要实体类可通过如下类图表示，在系统分析阶段可以暂时省略系统中的边界类
（如界面等）和控制类等。
7. 交互过程分析
a) 交互过程分析的任务是将活动图中由系统完成的活动“拆解”成系统中的对象所完成的动作。
b) 通过系统静态结构分析，已经能够明确在某个用例范围内，涉及到哪些的种类的对象。交互过程就
是要表示出用例的执行过程中，这些对象是怎样协作的。
c) 为了简化交互分析过程，通常应该将用例执行过程中参与者与系统的每一次互动展开成一个交互片
断，在必要的情况下，最终将产生的多个交互片断整合成完整的一个交互图。
d) 实例分析过程——可以先把交互过程用文字进行叙述。
i. “订餐员”请求“订餐窗口”打开
1． 订餐窗口“询问”每个配送员的当前状态
2． 订餐窗口把“不忙”的配送员加到配送员列表中
3． 订餐窗口创建临时的“订单”
+Nam e : string
+Addr : string
+Phone : string
-......
Custom e
+ID : String
+Nam e : String
+SalePrice : float
+SupportPrice : float
-......
BoxFood
+ID : string
+Nam e : string
+Addr : string
+Phone : string
+BankAccounts : string
-.......
Restaurant
+ID : string
+Nam e : string
-IsBusy : bool
-......
配 送 人 员
+ID : string
+Price_Buy : float
+Price_Sale : float
+Date : Date
-.....
O rder
+Counts : int
O rderItem
CreditBill
1 *
1 *
下 达
1 *执 行
1
*
获 得
11
订 购
* 1
供 应
<<导 出 >>
订 餐 窗 口
订 餐 员
ShipM an
Open()
GetFreeing(&list)
Order
Create(state=temp)
GetID
SetDate(Now)
ii. “订餐员”输入客户的订餐卡号码
1． 订餐窗口请求“客户”提供自己的注册信息
2． 订餐窗口显示“客户”提供的注册信息
3． 订餐窗口要求“订单”建立与“客户”的联系
iii. 订餐员输入套餐编号、数量
1． 窗口建立“订单项”对象
2． 订单项关联套餐产品
3． 套餐产品请窗口显示套餐信息
4． 窗口让订单加入新创建的订单项
订 餐 窗 口
订 餐 员
Customer
GetCusInf(cID)
GetInf(cInf)
ShowCusInf(cInf)
Order
LinkToCus(cID)
订餐窗口
订餐员AddToOrder(FoodID, Counts)
Order
SetLink
OrderItem
oi=Create(F_ID, Cnt)
BoxFood
showFoodInf(me)
AddItem(oi)
