业务用例示范
用例文档范例
用例文档用例编号UC001用例名称订餐参与者客户过程描述用例起始于用户想要订餐，客户点击系统提供的订餐功能键，系统显示可供选择的餐品信息，客户填写相应餐品的份数，并填好送餐地址、联系电话、送餐时间、其他要求（粗斜体字未必填内容）后，提交订单。
系统根据业务规则BR_E001Celerity营业时间规则，判断该订单是否在营业时间内，以及业务规则BR_E003 Celerity订餐时间和送餐时间间隔规则，判断该订单的送餐时间是否有效。
系统保存有效订单、废弃无效订单，并对客户进行反馈。
基本流程参与者的动作系统动作1）用例起始于用户想要订餐，客户通过UIC000客户专业功能页面，点击系统提供的订餐功能键。
2）系统通过UIC001客户订餐页面，显示可供选择的餐品信息。
3）客户通过UIC001客户订餐页面，填写相应餐品的份数，并填好送餐地址、联系电话、送餐时间、其他要求（粗斜体字未必填内容）后，提交订单。
4）系统根据业务规则BR_E001Celerity营业时间规则，判断新订单是否在营业时间内，以及业务规则BR_E003 Celerity订餐时间和送餐时间间隔规则，判断新订单的送餐时间是否有效。
5）系统保存有效订单，并通过UIC801订餐成功返回页面，对客户进行反馈。
分支流程第4步验证订单为无效状态时5）系统废弃无效订单，并通过UIC901订单无效返回页面对客户进行反馈。
6）客户可以通过UIC901订单无效返回页面选择重填或放弃。
7）系统根据用户的选择返回UIC001客户订餐页面，或UIC000客户专业功能页面。
用例编号UC004用例名称修改订单参与者客户过程描述用例起始于想要修改订单，客户点击系统提供的修改订餐功能键，系统对满足业务规则BR_C001客户订单修改规则的订单进行修改。
基本流程参与者的动作系统动作1）用例起始于想要修改订单，客户通过UIC000客户专业功能页面，点击系统提供的修改订单功能键。
2）系统将客户提交的满足业务规则BR_C001客户订单修改规则的未处理订单,通过UIC012客户修改订单页面显示出来。
难点讲解-业务用例与系统用例的区别以及include和extend的使用
业务用例与系统用例的区别所谓的“业务用例”和“系统用例”有什么区别呢？首先，业务用例和系统用例是相对而言的。
其次，业务用例和系统用例的研究对象不同。
以经典的银行为例。
我去银行开户：我在柜台前拿张空白的开户申请单，填写好我的信息，然后把我的身份证和填写好的申请单递给柜员（此处省去排队数十分钟等巨不爽事…）。
柜员接个单子，啪嗒啪嗒的把我的信息录入他们的系统。
一番折腾后，我面前的密码输入器提示我设置帐号的密码两次。
接着，他递出打印了信息的单子，让我签字确认。
我签字后递给他，他使劲敲上几个印章，然后把我的存折、身份证以及手续单递给我，并且告诉我办好了。
这是银行很简单很常见的服务，也可以说是银行的功能。
其实银行还有很多其它“功能”，比如存钱、取钱、挂失等等。
此时，我们其实是在把银行看作一个能提供很多“功能”的“系统”。
同时，在这个过程中，柜员一直在操作银行的软件系统，过程可能是这样的：柜员首选选择开户功能；软件系统要求柜员将我的信息录入，并选择开户类型（我在申请单上写的是活期）；软件系统可能会检查我的身份证号是否合法；软件系统为我生成一个银行帐号；软件系统会问柜员我是否要密码（我在开户申请单上注明了需要），所以软件系统提示我设定密码；软件系统将我的存折打印出来。
银行的软件系统给柜员提供了很多功能，除了开户当然也会有存钱、取钱、挂失等。
但这些功能是银行的软件系统提供给银行职员的。
这样我们综合上述两个过程来看，其实我们在研究两个层次的“功能”。
第一层次是银行提供给银行的客户的功能；第二层次是软件系统提供给银行职员的功能。
如下图所示：当我们对银行的业务进行建模时，我们会把银行看作一个整体，去研究银行会提供给客户哪些服务。
此时我们的研究对象是银行。
当我们对银行的软件系统进行建模时，我们把软件系统当作一个整体，去研究它需要提供哪些功能给银行的职员使用。
此时我们的研究对象是银行的软件系统。
这样我们为了区分起见，把前者称作“业务用例模型”；相对的，把后者称作“系统用例模型”。
用例及用例图案例
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统（或工作内容） – 帮助业务过程重建工程工作 – 帮助员工（小组内成员）充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例：预订变更 ●参与者：柜台工作人员 ●说明：
Ａ２：有冲突。
⑧系统添加新课程，并提示添加成功。
⑨系统回到管理主界面，显示所有课程，用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图，解决用例之间的冲突和重复。
15
案例3：
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例？ (2) 用例图在软件建模中的作用是什么？ (3) 用例之间存在那几种关系？ (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式？ (6) 什么叫事件流,作用是什么？
UML业务建模实例分析四例
UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
用例实例-基金模拟项目
投资人想自行上网下单买卖基金之前， 须向银行申办使用网上下单之服务项目
投资人可以向银行申请补发任一时段的投资 对账单
系统分析员问：看起来申购基金的流程应该是最重要的，那我们是不是就从这条流程开始谈？ 业务人员答：没问题。 系统分析员问：由于申购基金这条流程是由投资人启动的(请参照CIM-1的业务用例图)， 那是不是请你从投资人来银行申购基金开始讲起，让我知道流程中投资人主要会接触到哪些员 工(Worker)？还有，在流程中，投资人及员工主要会经历哪些重要的手续？ 业务人员答：一般是这样的，投资人来银行会向理财专员说明想要购买基金，理财专员会 先询问投资人是否曾经来本行购买过基金。如果投资人是首购，那就会先申办基金账户，有了 基金账户才能够买卖基金。 系统分析员问：“申办基金账户”是谁负责办理的？ 业务人员答：理财专员。理财专员会请投资人填写开户数据，然后把开户数据交由主管审 核。主管审核没问题之后，基金账户就开成了。 系统分析员决定将活动图分为两张，一张表达首购流程，另一张表达一般流程。系统分析 员记下了两个重要的动作之后，继续如下的访谈： 系统分析员问：基金账户跟一般的账户不同吗？ 业务人员答：不一样的，我们称一般的提存款的账户为“综存账户”，它主要会记录提存 交易和账户余额。基金账户是买卖基金的专用账户，主要记录基金交易、现值以及库存基金， 等等。 系统分析员问：所以说，投资人只要开了基金账户就可以买卖基金，不一定需要开综存账户。 业务人员答：理论上是这样没错，不过公司还是会要求投资人开综存账户。这是因为投资 人如果通过网上下单，公司会从投资人的综存账户里头转出申购款项，所以投资人不仅得开基 金账户，还得开综存账户。
最终其他用例
投资人可启动的系统用例
理财专员可启动的系统用例
主管可启动的系统用例 定时自动启动的系统用例
图书管理系统-业务用例图
• 用例就是外部可见的系统功能。 • 用例包含了所必需的全部行为，即执行用例的主线 次序、标准行为的不同变形及一般行为下的所有异 常情况及其预期的反应。用例不是系统的功能需求 或规格说明，其目的是要展示所描述过程中的需求 情况。 • 用例的动态执行过程可以通过状态图、时序图、协 作图来描述。
用例的概念(Concept)
用例的泛化关系（Generalization）
• 在WebShop电子商城后台系统中购物用户支付货 款包括以下几种方式：网银支付、邮局汇款支付和 支付宝支付。因此，网银支付、邮局汇款支付和支 付宝支付与支付货款之间形成了泛化关系。
用例的包含关系（Include）
• 图书管理系统中还书时，需要检查是否超期，而 超期的检查主要是比较读者可用的借阅期限与实 际借阅期限。 • 图书管理系统中借书时，需要设定归还日期，而 归还日期为借阅日期加上读者可用的借阅期限。 • 可见借书和还书时都需要读取读者的借阅期限。 为此，我们提取一个读取借阅期限的用例，这个 用例可以被借书和还书复用。 • 借书、还书与读取借阅期限用例间的关系就是包 含关系。
在用例图中常使用泛化关系描述多个参与者之间的公共行为例如学院的老师分为专业教师和素质教师参与者之间的关系参与者之间的关系relationsrelations练习练习exerciseexercise识别图书管理系统中的参与者及其他们之间的关系用例usecaseusecase用例的概念用例的概念conceptconcept用例包含了所必需的全部行为即执行用例的主线次序标准行为的不同变形及一般行为下的所有异常情况及其预期的反应
参与者（Actor）
• 参与者一般可分为三类：
–具体的系统用户 –其他系统 –可运行的进程
测试业务用例怎么写范文
测试业务用例怎么写范文测试业务用例的范文如下：
用例名称：登录功能验证
前置条件：用户已注册账号
用例编号：TC001
测试目的：验证登录功能是否正常
测试步骤：
1. 打开系统登录页面
2. 输入正确的用户名和密码
3. 点击登录按钮
4. 检查是否成功跳转到用户首页
预期结果：
1. 登录页面成功打开
2. 输入正确的用户名和密码后，登录成功
3. 成功跳转到用户首页
用例名称：添加商品到购物车
前置条件：用户已登录
用例编号：TC002
测试目的：验证添加商品到购物车功能是否正常
测试步骤：
1. 在商品列表页面选择一件商品
2. 点击“加入购物车”按钮
3. 检查购物车中是否添加成功
预期结果：
1. 商品列表页面成功打开
2. 点击“加入购物车”按钮后，提示商品已成功添加到购物车
3. 在购物车页面中出现了添加的商品。
业务用例
业务用例一、服务器端设计服务器软件管理系统完成所有人员的指纹采集，并且按照部门或者区域管理网络节点的地址，当发生异常现象时，管理系统能做出应急处理。
包括指纹管理、房间管理、权限管理以及用户管理等功能。
1.1用户权限设计权限管理部分即为系统中对每个门禁节点权限分配的管理，主要工作有门禁节点的人员分配、指纹分发以及在需要时清空门禁节点数据库等操作。
门禁节点的指纹库中所有指纹数据均由服务器端下发，门禁节点不具有自行指纹注册的功能。
指纹下发分为门禁节点的人员分配和指纹下发两步来完成。
第一步，先要进行人员分配，在选择好门禁节点的编号以后，向指定门禁节点添加要分配的人员。
第二步，选择好每个门禁节点的人员以后，进行指纹下发到节点的工作。
首先打开服务器，刷新房间号后再选择需要下发指纹数据的房间编号，最后选择人员及需要下发的指纹类型即可完成下发工作。
指纹下发完成以后，已分配权限的人员即可在指定的门禁节点打开门禁。
1.2指纹采集功能本系统为网络的指纹识别门禁管理系统，其中指纹为系统中唯一的身份认证技术。
所以在整个系统中指纹管理显得尤为重要。
指纹的管理主要包括指纹的采集、存储、删除等操作，以及对系统中所有人员的添加、更改、删除等操作。
指纹采集为本系统指纹数据登记的录入端，主要完成本系统中所有人员指纹数据的采集入库。
指纹采集与下发工作只可以在管理员权限下进行，对于普通用户则不具有指纹登记与下发功能。
本系统中指纹的采集部分设计主要分为两大模块：第一部分主要负责指纹模块基本的参数设置及模块功能实现，基本参数设置包括指纹模块的波特率、模块编号、安全级别等。
控制指纹模块实现的功能有指纹采集、验证、匹配、模板上传、模板下载、指定编号指纹数据删除等基本功能。
人员信息管理部分主要包括人员添加、人员修改、人员删除等基本功能。
第二部分为系统中人员信息的管理。
系统中有新的人员添加时，需要先在管理员权限下登录系统，完善人员基本信息后完成人员添加。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.1 软件是组织的零件业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”这个名字其实起得不好，应该更名为“组织建模”。
出于对过去叫法的尊重，本书依然称为“业务建模”。
做一做以下题目，可能会发现答案出乎你的意料。
很多时候我们把自己在开发的系统（现在流行叫××平台了）看得太重了，感觉没有我们开发的系统，组织就玩不转了。
其实，我们那牛×哄哄的系统也只是组织的一个零件，和组织厕所里的马桶没有本质区别。
组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人肉系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。
要改进组织的价值，不一定要开发软件，有时换人（也就是说，不是更换软件系统，而是更换人肉系统）更管用。
和一套软件系统的价格相比，也许雇用一名高级员工花费更多。
开发人员有时会有意无意把自己的系统想得太重要。
有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。
我问道：难道银行以前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其实想想就知道，银行已经成立多少年，贵公司才成立几年？所以，为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”——你做这个马桶是干什么的？为什么需求经常“容易变化”？根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上马磨合后发现问题，自然要改。
“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。
如果能正确运用业务建模技能，大多数假的需求变化会消于无形。
遗憾的是，不少开发团队在改进的时候给自己开错了药方，以为应该通过提升设计的弹性来应变。
设计是应对真正需求变化的手段，假的需求变化应该通过改进业务建模来应对。
如果东西拿到客户面前，客户说“好呀，正是我想要的！”，过了半年，客户又说“形势变了，这个东西要改一下。
”这是需求变了。
如果东西拿到客户面前，客户说“这不是我想要的！”，这时硬要说“需求变了”，脸皮有点厚了。
说起业务建模，很多人会联想到大企业、ERP、工作流….其实，所有类型的系统都可以使用业务建模技术来得到有价值的需求。
后文会看到各种领域的具体例子。
3.2【业务建模步骤1-1】：选定要改进的组织业务建模既然是研究组织，那么研究哪个组织呢？理论上来说，先研究整个世界，再慢慢缩小范围，一直到能定位我们要开发的的系统，但这显然太浪费了。
最佳的研究范围就是愿景波及的、需要改进的组织，它可能是一个公司、一个政府单位、一个部门、一间办公室、一个家庭、一群人……现在的许多系统，改进的组织是一个人群（如车友）而不是正式组织（如某公司）。
人群也是组织，组织也就是人群，业务建模的方法是一样的。
某公司是一帮人，车友也是一帮人，它们之间的区别仅在于有没有组织机构代码证而已。
某公司里有总经理、部门经理、普通职员……车友里有骨灰车友、发烧车友、入门车友……如何圈定这个最合适的研究范围，没有标准答案，可能要试很多次。
如果发现组织的绝大多数流程和改进不相干，说明选的范围可能太大了；如果发现很多要改进的地方未涉及，说明选的范围可能太小了。
以下是可以参考的几点思路：画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统…）包在里面。
例如：要开发一个企业内部员工训练平台，替换的责任大多属于人力资源部人肉系统的工作，这时可以把人力资源部作为研究对象：图3-1 把大多数系统圈在里面请注意上面的用词，“大多数责任可能被替换的系统”，而不是“大多数系统用户”。
因为此时待开发系统的边界尚未确定，不能先入为主地把某些人肉系统称为用户（而且前面我们说了，不是“用户”，而是“执行者”）。
系统要做的改进和训练专员的工作有关，不代表训练专员一定是该系统的执行者，也许人力资源总监会觉得取消所有的训练专员可能是更好的方案。
得到的结果其实就是老大所代表的那个组织，所以这个范围大小和老大的职权范围是相关的，如果老大只是人力资源总监，把整个公司作为研究对象就太大了；如果老大只是大学里面某个学院的院长，把整个大学作为研究对象就太大了。
互联网网站项目如何选择业务组织如果苍井老师购买了一套软件安装在她的电脑里，她会觉得这套软件是她的，但是，如果苍井老师觉得新浪微博很好用，她的认识就有些微妙的变化，会觉得新浪微博是新浪公司的。
开发人员在为探索互联网网站的需求而做业务建模时，也常会发生类似错误——要开发下一代互联网网站挑战新浪微博，所以把新浪公司作为研究对象？更正确的做法是把明星人群作为研究对象，思考如何做出更牛的网站来向大众辐射苍井老师们的魅力。
面向大众的互联网网站只不过是软件的另一种表现形式——不再是购买光盘或下载安装包到本地安装，而是免费或收费“租用”系统（前面也说了，“免费”并非真的免费，我们付出了最宝贵的时间）。
苍井老师碰到“新浪微博”，她只关心这个系统的功能和性能就够了，她会关心这个系统是新浪公司还是搜狐公司开发的？路上捡到的？还是外星人开发的？业务建模时应该研究的组织是该网站的目标人群，并非负责开发和维护这个网站的开发组织。
如果要改进的是运营网站的组织的内部运营工作，把网站组织作为研究对象就是合理的。
总之，病在谁身上，就给谁做检查。
实际工作中，经常会出现这样的现象：该研究目标人群时，建模人员却害怕去研究，千方百计要退回来研究网站组织。
例如，要思考微博需要添加什么新功能，应该去观察艺人的生活和工作，但这个太麻烦了，还是观察自己公司内部的运营吧！这就相当于在黑暗的地方丢了钥匙，却到明亮的地方找，因为这里亮堂，好找。
对松散的"目标人群"做业务建模，是创业很好的入手点。
例如，宅男找餐馆叫外卖这样一件事情，一端是“宅男”组织，一端是“餐馆”组织。
如何改进一家餐馆的流程，可能已经有很多人做过严肃的建模；如何让宅男的生活更美好，严肃建模的人就少得多，许多改进点只靠拍脑袋发现。
选定组织后，我们需要从两方面来研究它。
从外部看，组织是一些价值的集合，我们可以用业务用例图表示；从内部看，组织是一些系统的集合，我们可以用业务序列图来表示。
图3-2 组织的外观和内观3.3 【业务建模步骤1-2】：组织的业务用例图3.3.1 业务执行者首先来寻找组织的执行者，也就是业务执行者（Business Actor）。
业务执行者的定义是：在组织之外和组织交互的人群或组织。
以一家商业银行为研究对象，谁在外面和它打交道？储户来存钱，企业来贷款，人民银行要对它作监管…。
这些就是该商业银行的执行者。
图3-3 业务执行者业务执行者的图标是一个小人，头上有一道斜杠，这个带斜杠的小人实际上是一个执行者的构造型<<Business Actor>>的图形表示，Rational工具和EA里都有。
如果您使用的UML工具没有这个图形，可以用执行者的小人图标加上文本构造型<<Business Actor>>取代，或者不加构造型也无所谓，因为系统边界框已经表明了研究对象是一个组织，它的执行者自然是业务执行者。
3.3.2 业务工人和业务实体在寻找业务执行者时，有时会和组织内的人混淆，例如银行里面的营业员。
营业员在组织里面，不是业务执行者，我们称其为业务工人（Business Worker）——组织内的人肉系统。
业务执行者和业务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的，一个是组织可以替换的零件。
业务工人可能会被新的业务工人替换，但更多的可能是被新的业务实体（Business Entity）替换。
业务实体就是组织中的非人系统，例如银行的取款机、点钞机、营业系统。
在没有点钞机的时代，储户拿着一叠钞票到银行存钱，营业员需要凭着手感（界面层）一张张数，数的时候大脑（核心领域层）还要很快判断钞票的真伪。
点钞、数数的逻辑封装在营业员的大脑里，营业员非常累。
有了点钞机，营业员只需要把整叠钞票放进点钞机过一下，点钞机会负责辨认假钞和计数。
“验钞”、“数数”的责任和逻辑从人脑转移到了点钞机的大脑。
营业员轻松了，当然，银行也就不需要那么多营业员了。
图3-4 逻辑从营业员的大脑转到点钞机的大脑责任转移的思想对识别待开发系统的需求很有帮助。
开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。
这样，探索需求的思路就出来了。
我们画好现状的业务序列图，然后把待开发的系统作为一个新的业务实体空降到序列图中，寻找改进点，得到该业务实体的责任，就可以直接映射到待开发系统的用例。
图3-5 改进业务序列图，映射系统用例业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。
业务工人和业务实体放在名为“业务对象”的包里，作为类（Class）的一个构造型。
在识别业务执行者时，不需要画业务工人和业务实体，在接下来画业务用例的实现——业务序列图的时候加上就可以。
和业务执行者一样，如果您使用的工具没有<<Business Worker>>和<<Business Entity>>构造型，可以自己造，或者干脆不要构造型直接用类表示。
背后的思想是一样的：类之间通过协作实现用例。
业务工人和业务实体协作完成业务用例，系统类协作完成系统用例。
业务执行者是一个组织（或人群），而不是系统。
因为研究对象是组织，和它对应的概念也应该是组织。
下面的图是错的：图3-6 错误：把系统作为业务执行者应该把银行系统看作业务实体，在业务建模的类图、序列图里出现，正确的业务用例图如下：图3-7 正确：组织为组织提供服务3.3.3 识别业务执行者识别业务执行者时，可以这样思考：拿着摄像机对准组织的边界，谁上门找它办事？谁打电话给它？谁发邮件给它？它出门找谁办事？打电话给谁？发邮件给谁…可能就会找到它的供应商、客户……如果研究的组织是一个部门，那么其他部门就有可能成为它的执行者。
3.3.4 业务用例业务用例指业务执行者希望通过和组织交互达到的，而且组织能提供的价值。
以上面提到的商业银行为例，我们可以这样思考，储户到银行的目的是什么？可能是存款、取款、转账，得到银行针对储户的用例如下：图3-8 某商业银行针对储户的用例如果穿越回到三百年前，图3-8所示用例图依然适用。
业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。
三百年前，银行要实现“储户→存款”的用例，需要许多人肉系统（业务工人）一起协作，现在则变成了少数人肉系统（业务工人）和许多电脑系统（业务实体）之间的协作。