第6章 业务建模
——信息系统建设的前奏
第6章 业务建模
第6章 业务建模 2
模型的种类 模型的用途
业务模型 业务过程、工作流、组织
需求模型 需求捕获和沟通
架构模型
对正在构建的系统的高层次的理解，不同软件系统之
间的交互、开发者之间交流系统设计信息
应用模型 系统内底层设计架构
数据库模型 设计数据库的结构和数据库如何与应用交互
第6章 业务建模
第6章 业务建模 3
第6章 业务建模
第6章 业务建模 4
本章主要讲解的重点：
什么是业务模型
为什么要对业务建模
建模的范围
UML如何改进业务
如果使用UML对业务建模
UML业务用例模型
业务分析模型
业务模型
第6章 业务建模 5
简单地讲，业务模型(business model)是对业务的抽象表示，
它从业务的不同侧面提供了一个简化的视图。
一个业务可以用不只一种“业务模型”表示。
不同的业务模型强调不同的业务特征或业务概念，同时隐藏了业
务的其他方面。
通过这种方式，可以只关注想要处理的那部分业务的相关信息。
第6章 业务建模 6
业务过程模型展示
的是为执行一个给
定的业务功能而产
生的活动流(典型
的活动发生在企业
内部，参见右图)。
第6章 业务建模 7
假设要构造一个信息技术(IT)系统，那么需要什么视图呢?
需要能够捕获到下列事物的结构和相互间交互的模型：
业务的组织或部门。
业务的利益相关人——顾客、工作者、业务伙伴等等。
业务运作产生的业务功能，不论是为了顾客的需要还是为了企
业内部的需要。
满足业务功能所需的业务资产。
对于地理上分散的业务，还包括前面列出的条目对应的地理位
置。
事实上一个业务往往是地理上分散的，业务的这种地理分布
性经常被忽视，以致于给业务和业务系统的实现带来非预期
的复杂性和严重制约。
第6章 业务建模 8
“总之，业务模型说明了企业的功能，企业做什么，如何
做和何时做。业务模型应该强调架构，也就是说业务模型
除了要解释各种时间流，即架构中模型元素的动态行为，
还要强调企业的静态结构”。
这些模型应该展示出今天已经存在的业务信息，以及明天
你所需要的业务信息。
业务模型反映的内容确实是个庞大事业。要做到描述中的
所有事情需要投入大量的时间和资源。这也说明了为什么
大部分公司都企图为公司的业务建立一个全面综合的模型。
业务建模通常在企业的部门或子部门等更小的范围和更具
体的策略层面内进行。此外，业务模型总是用于达到一个
具体的业务目标，消除明显的业务缺陷或者严重的业务问
题。
为什么要对业务建模
第6章 业务建模 9
有许多原因促使建立业务模型。这些原因包括从高层的业
务规划到实际运行的IT系统。我们对其中几项进行考察。
大部分企业都有一个任务陈述。如果没有这样的任务陈述，它们
至少也有正式书面形式或非书面形式陈述的企业视点。如何知道
你的公司为了达到这一视点而进行组织的呢?如何应对市场变化所
带来的业务变更?什么系统需要变更?这些变更如何影响企业中的
其他系统?
如果不了解你目前的状况、需要达到的目标和为了达到这
个目标需要做什么，那么你就不可能完成或者改善你的任
务。建立一个好的业务模型可以解决这些问题。
第6章 业务建模 10
案例
我曾为一家公司工作，帮助这家公司制订一个三年规划。这个规
划的基本目的是用来理解企业如何组织它的各个部门，以满足不
断变化的顾客需求，建立新的业务目标，如何制订财政预算来实
现业务的变更。我们成立了一个由多人组成的工作小组：副总裁、
部门负责人、资深雇员和几位IT专业人员，其他人员因需补充。
我们经常会谈，并尝试采用著名的方法学，以快速制订出企业的
三年规划。我们关注的焦点是这个方法学中的业务规划阶段，以
及如何设计新的业务结构和业务操作。
频繁的会议持续了好几周。业务部门的成员发言、方法学专家协
调、速记员记下了大量的会议记录，但是没有完成任何预定的目
标。这种工作方式的典型模式是“前进一步，后退两步”。在截
止日期日益临近的情况下，一位工作组成员将我拉到一旁并对我
说：“你知道一些关于UML的资料，能用你知道的帮助我们做点
什么吗?”
第6章 业务建模 11
就这样，我邀请副总裁和他的两名助理到房间里，同他们探讨他
们的企业。我并没有试图教会他们如何使用UML，但是在谈话的
过程中，我担当了绘图师的角色，绘制了一些业务用例图
(business use case diagram，本章的后面对业务用例图有详细介绍
)。这些图引发了一场关于本企业各部门、其他企业、政府机关和
顾客的详细讨论。在讨论中我们很快发现了影响工作组工作进度
的根源——这三位资深的企业领导各自掌管企业的不同部门，但
是对这些部门的整体运作方式却没有达成共识。
这种问题太常见了。这些业务部门的人员精明能干，可以很好地
领导自己的部门。但是他们对部门间的整体运作缺乏完整的理解。
使用了用例图后，解决这个问题只用了三天的时间，相比之下，
之前的工作方式却在几周都没有取得明显的进展。
第6章 业务建模 12
案例启示：
在对业务做出调整前，你必须理解现在的业务。
必须理解未来的业务，以便明确以后的发展目标。
没有人能够充分理解或完全记住大规模业务的所有方面。
不要给业务部门的人员灌输过多的技术术语和技术工具。这些是
协调员(模型设计师)应该掌握的。业务人员只需负责业务运营，
建模工作由模型设计师负责。
可视化的业务模型，即使是很简单的模型、也会为讨论和解决业
务问题提供“焦点”。
第6章 业务建模 13
建模对未来业务的规划运作大有益处。在开发新系统的同时，
不得不对提供业务支持的既有系统进行维护和改造。在规划中，
“遗产系统(legacysystem)”的继承是一项最终必须完成的任务。
然而，除了几个仍在公司供职的职员以外，这些遗产系统对其
他人来说都是神秘的。仅仅了解系统对外提供的服务，这对遗
产系统的维护和改造是不够的，还需要理解系统详细的内部细
节。将遗产系统的内部细节知识传授给其他接管系统的人对于
遗产系统的升级和维护至关重要。但是多长时间要进行一次这
样的传授呢?另外，遗产系统的文档常常是过期失效的。因此，
这种知识传授通常只能在系统的“物理实现层”进行，通过将
源代码移交给后来的程序员来完成维护任务。最终的结果是，
用这样的传授方式，后来的程序员可能理解了代码，但是却没
有理解代码实现的完整业务功能。即使在最理想的情况下，这
种做法也是费时和低效的。如果要为遗产系统建立公共的系统
模型，那么一种可被广泛理解的语言绝对是很好的辅助工具。
业务建模的范围
第6章 业务建模 14
大部分情况下，业务或系统的开发本质上是灵活多变的。
尽管这样的灵活策略在短期甚至较长时期内能够奏效，但
是最终得到的是交互不良的功能或者整体和部分存在冗余
的多个系统。这些系统具有灵活多样性，但是它们组成一
个整体后不能满足业务或顾客的需要。
因此，从理论和学术上讲，你应该对全部业务建立模型。
第6章 业务建模 15
在启动任何项目的开发工作之前首先获得一个完整的、全
面的模型是很重要的。然而在实践中，这件事情是最难完
成的，其中既有技术原因也有行政管理上的原因。虽然如
此，在下列情况下，对全部业务建立模型的任务值得去完
成：
如果有一个拱形的目标，这个目标要求转换所有的业务或大部分
业务。
如果有一个项目或者一组不相关的项目，这些项目需要几年才能
完成。
如果正在增加一个独一无二的或者前所未有的业务功能。
如果正在对一部分业务进行重组，这部分业务与其他业务之间或
外部业务之间存在复杂关系。
第6章 业务建模 16
换句话说，如果计划是庞大的、复杂的或长期的，那么建
立一个完整的业务模型是值得投资的。这样做有很多益处：
获得了对业务的正确和公认的理解(明确表达被公认了的知识，将
避免走许多弯路)。
可以更有效地控制复杂性(不要忘记，复杂性随着业务功能或系统
之间关系的增多而呈几何级数增长)。
明确了业务变更的起点。
为管理大型项目或多个项目奠定了可靠的基础。
可以建立起所有权和财务职责。
UML如何帮助我改进业务
第6章 业务建模 17
当获得了一个已有业务系统的模型后，就可以确保所有的
利益相关人理解当前的业务活动。然而，这个模型需要被
各方一致地理解。
使用UML作为公共建模语言确保了这种一致的理解。
使用一个简洁的UML模型，能够找出以下要改进的方面：
无效之处。
性能问题。
冗余过程。
不正确的或者存在冲突的业务规则。
暴光(例如，一些业务或者系统的风险环节)。
需要巩固、提高或进行其他改进的方面。
未充分利用的或过度利用的系统或人员。
注意：人也是业务系统中的一部分。你不仅要对业务内容建立
模型，还要对业务活动中的人的角色和职责建立模型。
如何使用UML对业务建模
第6章 业务建模 18
考虑下面三个彼此相关的问题，是使用UML进行业务建模
的良好起点：
你与谁做生意?
他们希望与你做什么样的生意，或者反过来说，你希望与他们做
什么样的生意?
你的业务如何满足他们的需要?
这三个简单问题决定了业务操作的上下文背景。
举个例子，比方说你正在经营一个零售商店。那么你与谁
做生意?哪些人、公司或者系统与你有生意来往?对零售商
店来说，与你做生意的实体应该包括传统的零售顾客
(Retail Customer)、运输公司、货源供应商、信用卡公司
(Credit Company)，等等。所有这些人、企业和系统都在
你的业务中扮演了一个角色。他们被称为业务参与者
(business actor)。
第6章 业务建模 19
业务参与者(business actor)如同现实世界中的演员一样，他
们都扮演了各自的角色，参见下图：
零售顾客(RetailCustomer)、信用卡公司(CreditCompany) 、零售
商(Salesperson)
第6章 业务建模 20
为什么要与这些业务参与
者打交道?因为什么原因
要同他们做生意?在零售
业务中，业务参与者可能
希望做以下几件事：
购买产品。
退货。
提交产品给顾客。
提交产品给你的零售商店。
给顾客开帐单。
其他。
既然知道了业务参与者想要
做什么，就需要了解商店如
何满足他们的需要?要为这些
业务参与者提供什么样的服
务或业务功能?零售业务中的
一些典型业务功能可能包括：
零售。
开帐单。
仓库管理。
货物运输。
第6章 业务建模 21
这些都是业务参与者如何参与你的业务的具体案例。在
Rational统一过程(Rational Unified Process)中，这些案例
被称为业务用例(business use case)，参见下图。
UML业务用例模型
第6章 业务建模 22
结合业务参与者和业务用例这两种模型元素，可以为业务
创建业务用例模型(business use case model)。
业务用例图
业务用例图说明了业务操作的上下文背景。它描述了业务
的外部实体(业务参与者)、业务内部实体(业务用例)以及两
者之间的关系。
“业务用例图说明了业务的预期功能，它是用于识别外部
实体的角色和组织内可交付产品的一个基本输入”。
业务用例图是业务的上下文视图。
如下图所示：
第6章 业务建模 23
第6章 业务建模 24
业务用例图中的带箭头实线表示业务参与者和业务用例之
间的关联(association)。
关联表明被连接的模型元素之间存在某种关系。
箭头方向从发起活动的模型元素指向被发起的模型元素。
在上面的例子中，“Salseperson(售货员)”使用(也就是发起)了
业务用例“ProcessSale(销售处理)”。
一个关联可以没有方向箭头，这样的关联表示双向的通信路径。
第6章 业务建模 25
从技术上讲，参与者到用例之间的关联线是不允许出现方
向箭头的。然而，在设计现实世界的系统时，这种与UML
标准之间的无关紧要的偏差自然有它的价值所在。在一个
中等的系统中，比如说系统中有6个用例，你很可能很容易
地找出十几个参与者。在大型系统或者企业级系统(系统的
系统)中，可能包含更多的用例。使用箭头可以让你很快看
清哪些参与者是主动的(发起了用例)，那些元素是被动的
(不是发起了用例，而是为参与者提供了某种服务)。
第6章 业务建模 26
参与者之间的关联也是不允许的，但是在现实世界中，一
个参与者确实与其他参与者之间存在直接通信关系，特别
是参与者是人的场合。绘制出参与者之间的关联线也是重
要的，这些关联线可以使你正确的表达业务操作。看到参
与者之间的关联线后，会促使你决定关联所代表的参与者
之间的交互是否不存在或者应该自动隐含——这是业务系
统和系统架构的重要设计决策。
第6章 业务建模 27
吸取教训
1. 使用UML的目的是清晰地表达设计，不足为了盲目符合UML标
准的规格说明。
2. 如果你“创造性”地使用UML并达到了1中的目标，这样最好不
过。但是要当心：不要完全重新定义UML的语义或者用别人不
能正确解释的用法使用UML元素。换句话说，就是要倍加小心。
第6章 业务建模 28
在确立了业务用例之后，下一步需要定义这些用例的含义。
决不能假定地认为每个人都已经了解了用例的业务功能或者知道这些
用例能够做些什么。
明确地表达用例的内容，应该为每个业务用例编写一个简短的功能描
述。
这个描述应该是一个总体性陈述：
业务用例是什么，它的内容是什么以及为什么要有这样的内容(也
就是说用例的“任务”是什么)，何时使用这个用例，以及其他与
这个用例有关的具体信息。
用例的描述篇幅只需要一到两段就足够，只要每个人都能够读懂业务
用例的目的。
用例规约
第6章 业务建模 29
举一个例子，对一个名为“account management(帐户管理
)”的用例，可以进行如下的描述：
帐户管理(Account Management)：本业务用例为小型商业企业和
零售顾客提供服务，可以在一个分店内进行，在正常的营业时间
内发生，执行与帐户存取有关的操作。这些操作包括新建和销毁
一个帐户、转帐、修改帐户注册信息和合并帐户。该用例不包括
帐户查询、存款、退款或在线业务。
一旦用例描述得到了一致的认同，它就可以作为进一步明
确业务用例的具体内容的上下文背景。进一步明确用例需
要——活动图（activity diagram）。
活动图
第6章 业务建模 30
既然已经明确了要和你打交道的人员、业务以及组织，你
为了满足他们的需要而提供的服务，现在就需要理解他们
之间如何交互以提供这些服务。每个业务用例背后隐藏的
细节是什么?以业务用例Process Sale为例，实际生活中一个
顾客是如何购买一件零售产品的呢?需要经历哪些步骤以及
这些步骤由谁完成?这个交易可以按照下面描述的过程进行：
1. 顾客进入商店，挑选要购买的产品。
2. 顾客向售货员出示挑选的产品。
3. 售货员扫描产品条码(对所有的产品重复这个过程)。
4. 售货员报告商品总价。
5. 售货员向顾客询问付款方式。
6. 顾客支付购买商品的费用。
7. 售货员认可支付的费用。
8. 收据和产品交给顾客。
第6章 业务建模 31
或者也可能是：
1. 顾客进入商店，挑选要购买的产品。
2. 顾客向售货员出示挑选的产品。
3. 售货员向顾客询问付款方式。
4. 如果顾客选择了信用卡支付，顾客需要将他的信用卡提交给售货
员(如果不选择信用卡支付方式，则转到第6步继续执行)。
5. 售货员刷卡收费。
6. 售货员扫描产品条码(对所有的产品重复这个过程)。
7. 售货员报告商品总价。
8. 如果选择信用卡支付方式，顾客授权支付(否则，顾客提供现金，
售货员认可支付的费用)。
9. 收据和产品交给顾客。
第6章 业务建模 32
甚至也可能是：
1. 顾客进入商店，挑选要购买的产品。
2. 顾客自己在产品条码扫描机中插入信用卡。
3. 顾客扫描产品条码(对所有的产品重复这个过程)。
4. 扫描机自动报告商品总价。
5. 顾客授权支付。
6. 支付被售货员确认。
7. 收据交给顾客。
从上面的例子可以看到，同样一笔交易可以采取多种不同
的方式。这也是为什么人们要对工作流程达成一致的原因。
真实世界中可视化的工作流模型就显得十分重要。活动图
以一种容易学习和容易被理解的方式描绘了工作流程。
第6章 业务建模 33
用一个活动图描述交易过程的第一种可能的工作流程。
活动图展示出业务参与者和业务元素之间的交互：
1. 顾客进入商店，挑选要购买的产品。
2. 顾客向售货员出示挑选的产品。
3. 售货员扫描产品条码(对所有的产品重复这个过程)。
这三个步骤构成了Process Sale业务用例的活动图的开始部分。
第6章 业务建模 34
注意：是“Process Sale业务用例”的活动图的开始部分。
第6章 业务建模 35
从图中可以看到两个业务参与者的名字(Retail Customer和
Salseperson)出现在图中的两列的最上方。
图中的列被称为泳道(swimlane)。在UML 中这些列叫作划分
(partition)。
一列中的任何活动(activity，图中的椭圆型结点)都是由该列顶部标
记的人、组织或系统执行的。
注意在UML2．0中，这些节点被称为动作(action)。
UML2．0中同时有一个被称为活动的模型元素，UML2．0中的
活动可以包括动作和控制节点，用于描述动态行为。
活动流从开始状态(start state，图中的实心圆)开始，沿着箭头的指
向进行。
第6章 业务建模 36
即使只有活动图的开始部分，这部分活动图也能展示出需要工
作小组进一步讨论的区域。
如：
o 上述活动流中包含了售货员扫描产品条码的活动。
o 是否选用条码扫描机是系统的实现决策，现在就作出选用
条码扫描机这样的实现决策在系统开发过程中似乎显得为
时过早。
o 一般地说，过早的制订实现决策是不明智的。也有许多零
售商店不使用条码扫描机。他们采用人工输入的方式记录
商品价格。这些图能够帮助你在开发过程的早期，在昂贵
的系统实现阶段开始之前权衡实现决策。
o 事实上，如果条码扫描机出现故障，售货员可能会人工记
录产品价格(或者执行令人恐怖的“价格检查”)。这里出
现了第一例可选流(alternate flow)。
在绘制最初的活动图时，一个好的策略是首先绘制最理想场景
下的活动流，然后为先前的活动流增加后来新发现的可选场景。
？
第6章 业务建模 37
继续下面的活动：
4. 售货员报告商品总价。
5. 售货员向顾客询问付款方式。
第6章 业务建模 38
注意：Retail Customer泳道中的 “customer acknowledgment
(顾客认可)”活动是什么?
在最初的活动流里没有这个活动。
在绘制活动图的过程中，我们意识到工作流中直接从第4步到第
5步在实际中是不正确的（或者说是不完善的）。
如果这样做是正确的，为什么活动流已经进行到了由售货员
向顾客询问付款方式时售货员才报告商品总价呢?售货员报告
商品总价的原因是为了给顾客一次提出质疑的机会。顾客没
有钱支付怎么办?如果条码扫描机上显示的商品总价与顾客根
据商品标签上的价格计算的结果不一致怎么办?
这些图为我们质疑工作流(文字描述看上去可能很精确，但是绘
成图表后却发现了错误)的正确性和合理性提供了机会，使可选
流进入了我们的考虑范围。
第6章 业务建模 39
继续下面的工作流：
6. 顾客进行支付。
7. 售货员接受支付。
在图中，加入了支付活
动。
可以从图中看到，这样
的业务流程显然非常简
单。这条工作流是基于
支付方法的(现金、信用
卡、馈赠卷、优惠卡，
等等)。
第6章 业务建模 40
继续下面的流程：
8. 产品和收据交给顾客。
首先交给顾客什么呢，是
收据还是顾客购买的产品?
在本例中，这是无关紧要
的问题。两个活动可以平
行进行。
两个活动的平行进行在活
动图中是通过使用同步点
(synchronization，图中的
水平加黑条)表示的。
从同步点出发的两个活
动流可以彼此独立地进
行。
两个(或多个)活动流进入
一个同步点，则意味着
所有活动流都完成后，
工作流程才能继续。
第6章 业务建模 41
图中还增加了一个结束活动(terminating activity)，即“顾客离
开商店”。这个活动似乎没有什么用途，但是它确实澄清了一
些事实，即：
结束活动(terminating activity)使你明确地观察到业务参与者
和业务用例之间的交互是如何终止的。
此外，如果本例中的商店是一个网上在线商店，顾客离开商店
具有许多业务和应用设计上的含义。
例如，当顾客离开了网上在线商店(也就是离开了这个商店的
Web站点)，商店还不能立即将产品送至顾客手中，而是要在
业务流中增加一个履行网上交易的活动，并且要修改相应的
付款活动，因为要考虑到产品运输和手续费用。商店也不能
给顾客开出正式的收据，但是可以立即通过电子邮件给顾客
寄送一张电子收据。活动流的结束要用终止状态(end state，
图中公牛眼形状的符号)明确地在图中表达出来。
第6章 业务建模 42
工作流的结束可能会引发一个问题：
为什么不为“Give Receipt to RetailCustomer”和“Give
Product to Retail Customer”这两个流增加一个公共的出口同
步点，以确保顾客只有在获得了商品和收据后才能离开?
这个问题很值得思考。
问题的答案取决于你对业务操作的期望。你是否希望执行某些
动作来确保顾客在没拿到产品和发票之前不能离开(一些商店确
实在顾客离开之前要检查商品收据)?
如果是这样的话，增加一个同步点是一个很好的想法。
如果你的业务操作不执行这样的动作，那么增加同步点就是
不正确的。
这些问题是简单的文本描述很难反映出的问题。可视化的模型
可以更好地揭示事物和事物之间的关系，反映出简单文字描述
所不能表达的关注焦点。
第6章 业务建模 43
第6章 业务建模 44
可选流
开发上面的简单的活动图引发了业务用例“Process Sale”的工作
流中需要解决的几个问题。这个活动图中有许多可能的可选流：
条码扫描机出现故障，只得人工录入商品价格。
条码扫描机出现故障，售货员不知道商品价格，逐一检查每项
商品的价格。
顾客不认可商品总价，顾客的钱不够，取消交易。
顾客不认可商品总价，顾客的钱不够，从顾客挑选的商品中扣
除一件或几件商品。
顾客不认可商品总价，认为价格不对，重新对商品定价。
顾客不认可商品总价，不愿意多付钱，取消交易。
用户选择的付款方式不被商店接受(例如，商店只接受信用卡付
费)。
等等。
这些可选流可以用判定点(decision point，图中的菱形图元)描绘。
第6章 业务建模 45
在图中展现
了判定点是
如何用于表
示条码扫描
机出现故障
后可能的可
选流。
第6章 业务建模 46
总之：
业务用例图展示了业务的上下文，也就是业务内部和外部的事物
各自是什么。业务用例图说明了哪些人或系统与业务发生交互关
系。它捕获了业务和外部世界之间的接口。
活动图描述了关于业务如何操作的基本工作流。它详细定义了业
务和业务参与者之间的接口(interface)。它帮助你理解人或系统是
如何与业务交互的、理解交互的过程以及执行的活动。采用活动
图，你可以对如何完成一项任务获得基本的理解。
第6章 业务建模 47
注意：业务规则
业务规则(business rule)是施加在业务活动中的策略、约束或其他
规则。
例如，“一个存款帐户最多只能有两个户主”就是一条业务规则。
活动图的开发，意味着业务规则也同时显式或隐含地开始被开发。
业务规则将在开发活动图和顺序图(sequence diagram)的过程中开
始出现，并最终在类图(class diagram)即系统设计阶段成型。
所以：必须清楚地意识到现在正在建立和执行业务规则。
业务分析模型
第6章 业务建模 48
确立了业务的外部参与者的职责之后，接着会问：
为了提供业务参与者需要的内部服务，我的业务应该做什么?
为了提供这些服务，需要使用哪些人员、资产、信息…?
现在，假设已经完成了零售商店的“Process Sale”、“Bill
Customer”、“Manage lnventory”和“Ship Order”等用例
的业务用例建模。
通过考察业务用例图和用例的活动图，可以确定都有哪些
业务内部人员参与了这些活动。
第6章 业务建模 49
业务工作者需要使用业务资产履行他们的职责。下图描绘
了零售商店中的一些资产，或者说是业务实体(business
entity)。
这些业务内部参与人员被称为业务工作者(business worker)
，下图列出了零售商店的业务工作者。
第6章 业务建模 50
业务工作者和业务实体是通过业务分析模型(business
analysis model)来表达的。
业务分析模型是关于业务工作者与其他业务工作者、业务
参与者和业务实体如何联系以完成业务过程(即业务用例)的
内部视图。
业务用例模型和活动图给出了建立业务分析模型的初始信
息。接着要设计业务的内部操作，也就是说，设计企业内
部的操作。
第6章 业务建模 51
在例中，从模型知道：顾客要购买产品（“Product”是业务实体）。
这样，可以推断出必须要维护一个产品目录(也是一个业务实体)。
因此，需要一个存货工管理和维护这个产品目录。假设业务模型
中规定了顾客可以订购一批产品，并且要装船运输。那么就还需
要一个“Shipping Worker(运输工，一个业务工作者)”制定
“Shipping Schedule(运输计划，一个业务实体)”和“Inventory
Worker(仓库工，一个业务工作者)”按照“Order(订单，一个业务
实体)”发货。
第6章 业务建模 52
满足上述需求的一个业务对象图(business object diagram)如上
图所示。从技术上讲，这应该是一个类图。然而，因为典型的
类图与此有很大不同(使用了不同的图标)，为了避免引起混淆，
称之为业务对象图。之所以使用这个名字，是因为它描述了那
些执行业务功能的事物(对象)。
业务对象图是业务分析模型的一部分，它展示了系统中静态的
人员和事物。
在上图中，存在一种关联——聚集(aggreagtion，用一端带有空
菱形标记的关联线表示)。
聚集表明了一个事物是另一个事物的一部分。在上图中，一个产品是
一个订单的一部分。
第6章 业务建模 53
为了更清晰地表示关联，可以在关联端注明参与关联的事
物的数量。这个数量叫做多重性(multiplicity)。
在本例中，“product”和“order”的关联关系中，“product”
一端标注的多重性是“1..*”，这表示一个订单可以包含“1至多
个”产品(星号表示多个)。关联的另一端标住了一个“1”，说明
一个产品只能是一个订单的一部分。多重性既可以用一个数字表
示(例如，5)，也可用一个范围表示(例如0—12，含义是0至12个事
物可以同时参与一个关联，又如7-*，表示从7至无穷多数量的关
联参与者)。
第6章 业务建模 54
注意：“要对什么建模?”
在对一个事物建模时必须仔细地解释清楚模型描述了这个事物的
哪个侧面。
在前面的例子中，提到产品是订单的一部分。上图所展示的并不
是物理“产品”和物理“订单”。只是对订单所列的产品中所包
含的信息建模。例如，在现实生活中，产品的信息也许记录在产
品装箱单中。如何表示这种关系呢?通过使用关联来表示这种关系。
对这种关系的另一种解释是包含(containment)，指的不是物理的
包含，而是逻辑包含关系。如果要表示物理包含关系，就要使用
组成聚集(composition aggregation，它与聚集关联的图形标记类
似，只是关联端的菱形标记由空心变为实心)。聚集与组成有什么
区别呢?
在组成关系中，一个产品只能存在于一个订单中(换句话说，你
和我不能同时获得同一件物理产品)。在聚集关系中，我们两个
人的装箱单中可以包含同一件产品。
第6章 业务建模 55
顺序图
前面介绍的业务对象图，捕获了企业内部的静态事物的交互关系。
下一步要建立的是这些事物随时间的推移所经历的动态交互，这
是通过名为顺序图(sequence diagram)的一种UML交互图
(interaction diagram)描述的。
顺序图显示了一个给定场景下所有模型元素按照时间顺序发生的
所有交互。
第6章 业务建模 56
顺序图是一个二维图形。
顺序图中水平方向为对象维，沿水平方向排列的是参与交互的对
象。
对象间的排列顺序并不重要，但一般把表示参与者的对象放在
图的两侧，主要参与者放在最左边，次要参与者放在最右边(或
表示人的参与者放在最左边，表示系统的参与者放在最右边)。
顺序图中的垂直方向为时间维，沿垂直向下方向按时间递增顺序
列出各对象所发出和接收的消息。
第6章 业务建模 57
顺序图中包括的建模元素有：
对象(参与者实例也是对象)、生命线(lifeline)、控制焦点(focus of
control，FOC)、消息(message)等。
顺序图中对象的命名方式主要有3种(协作图中的对象命名方式也
一样)，如图所示。
第6章 业务建模 58
生命线在顺序图中表示为从对象图标向下延伸的一条虚线，
表示对象存在的时间。
控制焦点是顺序图中表示时间段的符号，在这个时间段内，
对象将执行相应的操作。控制焦点表示为在生命线上的小
矩形。
控制焦点可以嵌套，嵌套的控制焦点可以更精确地说明消息的开
始和结束位置。
第6章 业务建模 59
另外与控制焦点相关的概念是激活期(activation)。
激活期表示对象执行一个动作的期间，即对象激活的时间段。
根据定义可以知道，控制焦点和激活期事实上表示的是同一个意
思。
第6章 业务建模 60
利用前面已经建立的模型所包含的信息，下面要说明一个电话销售
的处理过程(仍然首先只考虑最理想的场景)。
首先，顾客打电话给售货员，然后售货员收集和记录顾客信息。
第6章 业务建模 61
从上到下阅读(时间线是从上到下的)上面的顺序图，可以看到顾
客首先打电话给售货员，而售货员需要收集顾客的有关信息。
图中的箭头说明了模型元素之间交互流的方向，每个模型元素
下方的垂直线叫作生命线(lifeline)，表示时间的流逝。
因此，需要建立“Customer(顾客)”这样一个新的业务实体，
这个顾客是与前面所讲的作为业务参与者的顾客是不同的。
o 业务参与者是系统外部的实体，而业务实体是系统内部的
实体，它担当了真实顾客的一个代理(proxy)。也就是说，
它是真实顾客的一个代表。
• 在系统实现中，作为代理的顾客很可能就是顾客信息数据库中的一
条数据库记录)。
售货员询问顾客的个人信息，并将这些信息添加到业务实体
Customer中。
在此，增量的和逐步求精的建模过程如何导致了系统中更
多的关键元素被逐一识别和发现。
第6章 业务建模 62
顾客接着订购各种产品，见下图。这需要售货员创建一个订单，
并将产品信息记录在订单中。对所有产品都要重复这个过程。订
单完成了，总价被计算出来后提供给顾客。
在图中有一个递归(recursive)消息：“Calculate Total Price(计算
总价)”，这个消息从Order的生命线出发并且指向它自身。该消
息表明订单知道自己应该计算总价并且知道如何计算。这看上
去是一个不寻常的情形——一个订单能够计算自己的价格?但是
在面向对象的系统里，这种情形是很普遍的。通常一个职责需
要被指派给拥有完成该职责所需信息的元素(或对象)。这样设
计系统，可以将信息封装在一个元素中。
第6章 业务建模 63
第6章 业务建模 64
接着，顾客向售货员提供信用卡信息，售货员将信用卡信息存储
至业务实体Customer中，并将该业务实体、商品总价及订单信息
发送至信用卡公司(之前没有被识别出的一个业务参与者)。
见下图：
注意，图中是如何将关键信息，如名字、信用卡号、有效期和
总价作为消息“Verify Credit Information”的参数传递给信用
卡公司的。
信用卡公司认可了这些信息，订单号传递给顾客。从这个过程可
以看到，业务模型的进一步开发是如何引出一些关键的业务细节
的，而这些细节在之前的建模中容易被遗漏。事实上，这样的建
模方式在本质上是反复迭代的过程。
第6章 业务建模 65
第6章 业务建模 66
从顺序图中，还可以较容易地找到进一步细化业务过程的
着手点。
考虑上图所示的顺序图。对这个图的审慎思考，可以发现：
在订单中添加产品信息之前，应该检查仓库中是否有这种产品的
存货。
这一过程可以容易地通过在顺序图中增加新的业务实体
“Inventory(仓库)”和与之有关的消息而实现。
将信用卡信息存储至Customer对象是另一个值得考虑细化的设计。
尽管这样的设计看起来很合理，但是如果经过仔细分析就会发
现，这样的设计意味着需要增加与信息的更新、删除和报告有
关的操作过程。或者在每购买一件商品后将信息反复转储至
Cusotomer对象?
第6章 业务建模 67
案例——一点小小的启示：
前一段时间我们与一位顾客致力于使用UMI进行数据库设计。在最后
一天，我正准备去参加最后一次会议，但是发现我租的一辆小汽车和
其他三辆汽车被破门扒窃(清晨8点，宾馆门前)，车里所有的东西都被
盗了——行李、便携式电脑和所有的东西都不见了。我仅剩下一部手
机。我打电话报了警。警察赶来后，录口供，保持现场，让灰尘继续
覆盖着我租的那辆车，为的是日后查验指纹，等等。会后我赶到机场，
完成了关于盗窃案的书面陈述，然后坐飞机回到家里。
几天之后，我意识到我还没有向出租公司交纳这几天的租车费。于是
我给租车公司的客户服务部门打电话解释我所遇到的情况，彬彬有礼
的经纪人表示愿意很高兴地帮助我。然后她问“我可以知道你的租车
协议号吗?”。我只能告诉她我所有东西都被盗了。我不知道协议号，
甚至连租车协议书都没有。她提出了一个解决问题的办法。她说我应
该回到机场的租车处去，那里的人可能还有租车协议书的存档。我可
以从那里查到协议号，然后再给她打电话。这样她就可以知道协议号，
并且能够帮助我付费了。难道让我飞回亚特兰大的机场租车处取回协
议号然后再告诉她?显然这是不大可能的。
第6章 业务建模 68
从这件事可以看出，尽管租车公司的单独系统(预定、出租、顾客
服务系统可以很好地完成各自的任务，但是他们并没有采取一致
的步骤去满足业务需要(例如，付款)。每个单独的系统并没有共
享它们业务中最重要的一项信息——租车协议号。这家公司没有
对顾客缺少租车协议号时的业务用例(例如，汽车被盗、帐单错误
等)建模(客观上存在这样的用例)。租车协议号很容易在顺序图中
反映出来，因为它跨越了许多业务功能。因此，租车公司的系统
不能有效地协同操作。
吸取教训
1. 不仅要对业务的物理实体(如人员、事物等)建模，还要对业务的
操作建模。
2. 要对业务系统建立模型，这样才能理解系统间的协同操作。
3. 要充分考虑到系统提供服务的过程中可能的不同交互方式。
4. 不要在无人看管的汽车中遗留任何东西。
第6章 业务建模 69
总之：
业务分析模型描述了业务的内部实体为了完成业务功能需要如何
做。
业务对象模型显示了在完成业务功能的过程中哪些人使用哪些事
物。
顺序图说明了所有的模型元素在各种不同的业务场景之下如何交
互。
所有这些图从整体上反映了业务在响应来自外部世界的请求的过
程中的内部视图。
总之，业务用例模型和业务分析模型描绘了“如何用过程
来描述业务，这些过程通过不同类型的资源对象之间的协
作达到过程的目标” 。
小结
第6章 业务建模 70
业务建模过程：
