业务用例
业务用例和系统用例
业务用例和系统用例在软件开发中，业务用例和系统用例是两个关键概念。
本文将从不同的角度介绍这两个用例类别。
一、业务用例业务用例是指描述业务需求的用例。
业务用例通常与实际业务过程中的角色、事件和功能有关。
通俗地说，业务用例就是对于业务人员来说，软件需要做些什么事情。
具体而言，业务用例的特点如下：1.业务用例是面向业务人员的，其中的术语和业务流程需要清晰易懂。
2.业务用例描述的是“是什么”，而不是“怎么做”。
3.业务用例通常与现有业务流程紧密相关，与系统实现方式无关。
4.业务用例需要由业务人员参与编写和审查。
除了以上特点，业务用例还具有一些构成要素。
例如：用例名称、参与角色、前置条件、流程步骤、后置条件、异常流程等。
这些要素可以帮助编写人员更加清晰地描述业务需求。
二、系统用例系统用例是针对软件系统的用例。
系统用例描述的是对系统的输入、处理和输出。
通俗地说，系统用例就是对于软件开发人员来说，软件如何实现业务需求。
具体而言，系统用例的特点如下：1.系统用例是面向开发人员的，其中的术语和技术细节需要精准明确。
2.系统用例描述的是“如何做”，而不是“做什么”。
3.系统用例与现有的技术环境和开发方式密切相关，但不必考虑业务流程。
4.系统用例需要由开发人员参与编写和审查。
系统用例也有一些构成要素。
例如：用例名称、参与者、输入、处理、输出等。
这些要素可以帮助开发人员更好地实现业务需求。
三、业务用例与系统用例之间的关系业务用例和系统用例往往对应着同一个业务流程。
从业务人员的角度来看，他们需要的是一个能够高质量完成业务流程并达到业务目标的系统。
从技术人员的角度来看，他们需要用系统用例来说明如何实现业务流程。
因此，业务用例和系统用例可以说是互相依存的关系。
在实际软件开发中，业务用例往往是与用户需求相关的，它们通常是在需求分析阶段编写的。
通过编写业务用例，我们可以更好地理解用户需求和业务流程。
而系统用例则是在需求分析后，进入系统设计阶段才开始编写。
业务用例示范
3.1 软件是组织的零件业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”这个名字其实起得不好，应该更名为“组织建模”。
出于对过去叫法的尊重，本书依然称为“业务建模”。
做一做以下题目，可能会发现答案出乎你的意料。
很多时候我们把自己在开发的系统（现在流行叫××平台了）看得太重了，感觉没有我们开发的系统，组织就玩不转了。
其实，我们那牛×哄哄的系统也只是组织的一个零件，和组织厕所里的马桶没有本质区别。
组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人肉系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。
要改进组织的价值，不一定要开发软件，有时换人（也就是说，不是更换软件系统，而是更换人肉系统）更管用。
和一套软件系统的价格相比，也许雇用一名高级员工花费更多。
开发人员有时会有意无意把自己的系统想得太重要。
有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。
我问道：难道银行以前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其实想想就知道，银行已经成立多少年，贵公司才成立几年？所以，为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”——你做这个马桶是干什么的？为什么需求经常“容易变化”？根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上马磨合后发现问题，自然要改。
“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。
如果能正确运用业务建模技能，大多数假的需求变化会消于无形。
遗憾的是，不少开发团队在改进的时候给自己开错了药方，以为应该通过提升设计的弹性来应变。
难点讲解-业务用例与系统用例的区别以及include和extend的使用
业务用例与系统用例的区别所谓的“业务用例”和“系统用例”有什么区别呢？首先，业务用例和系统用例是相对而言的。
其次，业务用例和系统用例的研究对象不同。
以经典的银行为例。
我去银行开户：我在柜台前拿张空白的开户申请单，填写好我的信息，然后把我的身份证和填写好的申请单递给柜员（此处省去排队数十分钟等巨不爽事…）。
柜员接个单子，啪嗒啪嗒的把我的信息录入他们的系统。
一番折腾后，我面前的密码输入器提示我设置帐号的密码两次。
接着，他递出打印了信息的单子，让我签字确认。
我签字后递给他，他使劲敲上几个印章，然后把我的存折、身份证以及手续单递给我，并且告诉我办好了。
这是银行很简单很常见的服务，也可以说是银行的功能。
其实银行还有很多其它“功能”，比如存钱、取钱、挂失等等。
此时，我们其实是在把银行看作一个能提供很多“功能”的“系统”。
同时，在这个过程中，柜员一直在操作银行的软件系统，过程可能是这样的：柜员首选选择开户功能；软件系统要求柜员将我的信息录入，并选择开户类型（我在申请单上写的是活期）；软件系统可能会检查我的身份证号是否合法；软件系统为我生成一个银行帐号；软件系统会问柜员我是否要密码（我在开户申请单上注明了需要），所以软件系统提示我设定密码；软件系统将我的存折打印出来。
银行的软件系统给柜员提供了很多功能，除了开户当然也会有存钱、取钱、挂失等。
但这些功能是银行的软件系统提供给银行职员的。
这样我们综合上述两个过程来看，其实我们在研究两个层次的“功能”。
第一层次是银行提供给银行的客户的功能；第二层次是软件系统提供给银行职员的功能。
如下图所示：当我们对银行的业务进行建模时，我们会把银行看作一个整体，去研究银行会提供给客户哪些服务。
此时我们的研究对象是银行。
当我们对银行的软件系统进行建模时，我们把软件系统当作一个整体，去研究它需要提供哪些功能给银行的职员使用。
此时我们的研究对象是银行的软件系统。
这样我们为了区分起见，把前者称作“业务用例模型”；相对的，把后者称作“系统用例模型”。
采购业务用例图课件
02
用例图基础
用例图定义与功能
定义：用例图（Use Case Diagram）是统一建模语 言（UML）中的一种图表 类型，用于描述系统的功 能需求和与之交互的外部 实体。
功能
• 展示参与者（Actors） 如何与系统进行交互。
• 描述系统将执行的主要 功能以及这些功能之间 的关系。
用例图符号与表示
企业通过对潜在供应商 进行评估、比较，选择 合适的供应商，并与其 建立合作关系。
企业与供应商协商、谈 判，就采购物资的价格 、质量、交货期等条款 达成协议，并签订采购 合同。
企业按照采购合同的要 求，向供应商下达采购 订单，并督促供应商按 时交货。同时，企业需 对采购物资进行验收、 入库等操作。
企业根据采购合同和采 购订单，与供应商进行 货款结算，并处理可能 发生的退货、索赔等问 题。
采购业务用例图课 件
contents
目录
• 采购业务概述 • 用例图基础 • 采购业务用例图分析 • 采购业务用例图的优化和改进
01
采购业务概述
采购业务定义与重要性
定义
采购业务是企业为满足自身生产和运营所需，通过与供应商 协商、谈判、签订合同等方式，购买原材料、零部件、设备 等物资的一系列活动。
重要性
采购业务是企业运营的基础，它直接关系到企业的生产成本 、产品质量和市场竞争力。一个高效、规范的采购业务能够 为企业降低成本、提高产品质量、增强市场竞争力，从而为 企业的发展奠定坚实基础。
采购业务流程简介
需求确定
供应商选择
采购合同签订
采购执行
采购结算
企业根据生产计划、市 场需求等因素，确定所 需采购的物资种类、数 量、质量等要求。
用例及用例图案例
用例及用例图-案例
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 业务用例模型
业务用例模型业务用例模型：业务用例模型描述一个业务的流程以及它们与外部各方（如客户和合作伙伴）之间的交互。
解释由业务用例和主角构成的模型的主要目的是说明客户和合作伙伴是如何开展业务的。
直接与客户或合作伙伴相关的活动以及与外部各方并不直接相关的支持和管理任务都可以在模型中给出。
模型以业务用例（相当于我们常说的“流程”）的形式对业务进行说明。
登记处的主角和用例。
业务用例的不同类型当考查业务中的活动时，您至少可以确定三类工作，它们对应着三种业务用例类型。
第一类是在商业上比较重要的活动，常称为业务流程。
第二类是在商业上不太重要的活动，但必须进行这些活动来保证业务正常运转。
系统管理、清洁和安全等工作就是这类活动的示例。
该业务用例具有支持的性质。
第三类是管理工作。
具有管理性质的业务用例所显示的工作影响如何管理其他业务用例以及该业务和其所有者的关系。
通常，管理类型的业务用例概括地描述了CEO 和业务用例中工作人员之间的关系。
它还说明了业务用例是如何被开发和“启动”（实例化）的。
在餐馆中，核心业务用例是市场营销(Marketing) 和用餐服务(Serving Dinner)，而采购(Purchasing Supplies) 是支撑业务用例。
请注意，有时候您当作核心业务用例的用例在其他业务中会成为支撑业务用例。
例如，在软件开发公司中，软件开发是核心业务用例；而在银行或保险公司中，它却是支撑业务用例。
一个业务有多个业务用例一个业务有多个业务用例。
多个不同业务用例的实例或一个业务用例的多个实例并行执行的情况是很正常的。
一个用例实例可以遵循的路径的数目几乎是没有限制的。
这些不同的路径代表了工作流程说明中用例实例的各种选择。
根据具体事件和情况，用例实例可以沿着多种可能路径中的一种进行下去，例如：●来自主角的输入。
●一条业务规则。
在对业务用例建模时，您可以假定用例实例可以在不互相冲突的情况下同时进行。
在业务开发的这个阶段，您应该侧重于业务应该作些什么。
(干货)产品经理必备的十张图
（干货）产品经理必备的十张图一、用例图用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。
用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。
主要分为系统用例图和业务用例图。
业务用例图主要是从业务的视角出发，通过业务建模并且对业务进行描述。
整体来说就是基于角色端需要操作模块的集合。
用户端需要操作的模块，实际上就是APP展示的模块。
当然只是通过角色进行区分。
需要注意的是，业务用例图主要是针对用户在产品中需要操作的事情为主。
下图就是售票产品用户需要去做哪些事情。
系统用例图主要是根据业务用例图分析得到的。
针对于业务用例图的用户行为分析后，从系统侧去建立对应的模块。
系统用例图是从使用者的角度，描述对应用户能使用产品做什么。
这样的好处，是让我们时刻以用户为中心，思考产品和功能。
很多小伙伴在做产品的时候，经常不能站在用户角度去思考问题，而往往站在了业务角色侧去考虑产品。
而系统用例图更好帮助产品经理规避了这点。
下图就是针对于上面售票产品用户侧需要做的事情，整理了用户侧和系统侧对应做的模块清单。
再举一个电商产品的系统用例图：业务用例图主要是针对于用户侧需要做什么？（同样，如果这个版本迭代涉及到的功能比较多，可以考虑业务用例图画一下用户在这个迭代版本中需要做什么）系统用例图是根据业务用例图中用户的操作，来把功能分配给用户和系统。
尤其是结合用户画像，哎哟！香得很……实用指数：★★★（三颗星）二、结构图结构图是指以模块的调用关系为线索，用自上而下的连线表示调用关系并注明参数传递的方向和内容，从宏观上反映软件层次结构的图形，结构图分建筑图和组织结构图。
结构图是在产品经理工作流中很重要的一步。
万丈高楼平地起，平地起前画架构。
而结构图搭建一旦确定，就不能更改了。
除非只有推倒重来。
所以必须在结构图之前一定要思考清楚，否则后面一直在填坑，对技术来说，可能需要走上重构的不归路。
银行接口业务测试用例(最新)
6 会员账户余额上传不成功 单击左下角【上传数据】
1 解约成功
2 解约成功
3 解约成功
3 解约成功
4 解约成功 22
5 解约成功 6 解约成功
会员登录交易前台，单击我的平台-资金管理-账户明细 点击【申请解约】 如该会员在交易中心账户中的余额为0，单击【申请解约】 登录交易后台，单击结算管理-结算银行-会员解约申请审核 选择该条申请信息，单击左下角【审核通过】按钮 点击【审核】按钮 单击结算管理-结算银行-会员解约申请复核
选择该条预付款信息，单击左下角【审核】按钮 单击【确认】按钮
13 6 与供应商结算成功 7 与供应商结算成功 8 与供应商结算成功 9 与供应商结算成功
10 与供应商结算成功
单击结算管理-凭证管理-凭证审核 选择该条预付款信息，单击左下角【审核】按钮 单击【确认】按钮 选择该条预付款信息，单击左下角【审核】按钮
11
8 会员出金成功 9 会员出金成功 10 会员出金成功
1 会员出金不成功 2 会员出金不成功 3 会员出金不成功 4 会员出金不成功 5 会员出金不成功 12 4 会员出金不成功 5 会员出金不成功 6 会员出金不成功 7 会员出金不成功 8 会员出金不成功 9 会员出金不成功 10 会员出金不成功
选
银
行：服务仍处于开启状态，可以进行出入金
操作
进入出入金明细对账页面
接case11出金成功 接case11出金成功 接case15签退成功
显示会员当日出入金信息 下载成功，正常显示数据 进入出入金明细对账页面 显示会员当日出入金信息
下载成功，但有数据显示为红色，根据错误 描述如描述为【银行存在成功记录，交易没 有收到消息】时可进行手工调账 进入系统日结界面 提示划转成功 提示日结成功 进入会员账户余额上传页面 显示会员账户当日信息 交易中心：不显示数据 进入会员账户余额上传页面 显示会员账户当日信息 显示红色异常数据 进入账户明细页面 进入申请解约页面 提示申请成功 进入会员解约申请审核页面 弹出申请单信息 审核成功 进入会员解约申请复核页面
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
业务用例
一、服务器端设计
服务器软件管理系统完成所有人员的指纹采集，并且按照部门或者区域管理网络节点的地址，当发生异常现象时，管理系统能做出应急处理。
包括指纹管理、房间管理、权限管理以及用户管理等功能。
1.1用户权限设计
权限管理部分即为系统中对每个门禁节点权限分配的管理，主要工作有门禁节点的人员分配、指纹分发以及在需要时清空门禁节点数据库等操作。
门禁节点的指纹库中所有指纹数据均由服务器端下发，门禁节点不具有自行指纹注册的功能。
指纹下发分为门禁节点的人员分配和指纹下发两步来完成。
第一步，先要进行人员分配，在选择好门禁节点的编号以后，向指定门禁节点添加要分配的人员。
第二步，选择好每个门禁节点的人员以后，进行指纹下发到节点的工作。
首先打开服务器，刷新房间号后再选择需要下发指纹数据的房间编号，最后选择人员及需要下发的指纹类型即可完成下发工作。
指纹下发完成以后，已分配权限的人员即可在指定的门禁节点打开门禁。
1.2指纹采集功能
本系统为网络的指纹识别门禁管理系统，其中指纹为系统中唯一的身份认证技术。
所以在整个系统中指纹管理显得尤为重要。
指纹的管理主要包括指纹的采集、存储、删除等操作，以及对系统中所有人员的添加、更改、删除等操作。
指纹采集为本系统指纹数据登记的录入端，主要完成本系统中所有人员指纹数据的采集入库。
指纹采集与下发工作只可以在管理员权限下进行，对于普通用户则不具有指纹登记与下发功能。
本系统中指纹的采集部分设计主要分为两大模块：第一部分主要负责指纹模块基本的参数设置及模块功能实现，基本参数设置包括指纹模块的波特率、模块编号、安全级别等。
控制指纹模块实现的功能有指纹采集、验证、匹配、模板上传、模板下载、指定编号指纹数据删除等基本功能。
人员信息管理部分主要包括人员添加、人员修改、人员删除等基本功能。
第二部分为系统中人员信息的管理。
系统中有新的人员添加时，需要先在管理员权限下登录系统，完善人员基本信息后完成人员添加。
人员添加后即可对新添加的人员录入指纹，指纹录入成功后选择指纹的属性对指纹进行入库。
录取完成以后即可将指纹下发至门禁节点，以实现人员权限的分配。
整个工作流程如图下所示：
否
图1-1指纹录入流程图
1.3人员信息管理
要进行用户管理则必须首先在管理员权限下登录系统，用户管理主要分为新用户注册、用户密码更改、用户浏览。
只有在管理员权限下可以增添新的用户。
在增添注册新用户时需要确定用户名、用户密码、用户权限等基本信息。
用户权限的选择有管理员、普通用户两种权限。
新用户注册以后，即可用已注册的登录名登录进入本系统。
如果新注册用户权限为管理员，即可注册新的用户，也可以对其他用户权限进行管理。
如果新用户的权限为普通用户则在用户管理界面下只具有密码修改权限。
1.4房间信息管理
门表的设置主要用来完成房间编号和节点IP地址的连接。
由于系统中要实现服务器到门禁节点指纹数据模板的下发，又由于系统中服务器与门禁节点之间的通信是通过TCP/IP协议实现，所以下发指纹数据时必须选中门禁节点的IP地址。
为了系统方便对所有门禁节点的统一管理，所以将门牌号与门禁节点的IP 地址对应起来，在指纹下发过程中直接选中门牌号即可将指纹数据下发至指定的门禁结点。
1.5指纹下发操作
系统中有新的人员添加时，需要先在管理员权限下登录系统，完善人员基本信息后完成人员添加。
人员添加后即可对新添加的人员录入指纹，指纹录入成功
后选择指纹的属性对指纹进行入库。
录取完成以后即可将指纹下发至门禁节点，以实现人员权限的分配。
整个工作流程如图所示：
否
图1-2指纹录入流程图
1.6实时监控实现
实时的监测系统可提高系统的安全性。
在本系统中服务器下发指纹时会将下发的指纹类型、指纹注册存储到数据库中。
门禁结点正式运行以后，当门禁节点识别到有指纹输入时对指纹进行处理后控制电锁的开关状态。
如果开锁成功时，在开锁同时门禁结点通过网络将识别到的指纹编号上传到服务器。
服务器对门禁节点上传的编号进行查询判断，当指纹类型为常用指纹或者备用指纹时服务器只将记录写入日志文件，当指纹类型为特殊指纹时服务器在写入日志文件的同时还会提示管理人员有用户非法进入房间。
系统日志主要包括进入日期、时间、人员以及所进入的房间编号等信息。
正常工作是系统如下图所示：
二、门禁结点设计
2.1硬件设计
指纹门禁的节点的硬件部分主要包括：单片机最小系统、指纹采集模块、串口通信电路、网络通信部分、开关按钮、供电系统组成。
其结构框图如图2-1所
示：
图2-1单节点硬件结构图
2.1.1主控芯片选择
STC12C5A60S2系列单片机是宏晶科技生产的单时钟/机器周期(1T)的单片机，是高速/低功耗/超强抗干扰的新一代8051单片机，指令代码完全兼容传统8051，但速度快8-12 倍。
内部集成MAX810专用复位电路，2路PWM，8路高速10位A/D转换(250K/S，即25万次/秒)，针对电机控制，强干扰场合。
并且STC12C5A60S2系列有双串口，后缀有S2标志的才有双串口，RxD2/P1.2(可通过
寄存器设置到P4.2)，TxD2/P1.3(可通过寄存器设置到P4.3)。
所以本系统中选则STC12C5A60S2作为主控器来实现指纹模块和网口转串口的同时通信。
本系统芯片选用DIP40封装，引脚排列如图2-2所示。
图2-2单片机引脚图
2.1.2指纹模块
本系统中选择乙木公司的X2-1020指纹识别模块作为本系统中的指纹识别处理单元，该模块可用USB和串口两中通信方式进行控制，具有控制简单快捷，稳定性好等优点。
指纹模块在本系统中主要用作服务器端指纹的录入，以及在门
禁结点的指纹识别、处理及在主控器的控制下完成指纹模块内部的指纹对比等工作。
主处理器尺寸
图2-3指纹模块主处理器
指纹模块通信过程:
在本模块的通信过程中所有指令的发送、接收必须要遵循一发一收的原则，主控器(Host)在没有收到应答时，不可以向目标模块(TARGET)发送指令。
主控器指纹模块
图2-4通信过程
注：通信过程中，所有的指令发送接收必须遵循一收一发原则，主控器在没有收到应答时，不可以响指纹模块(TARGET)发送指令。
2.1.3网络模块
单片机上网卡模块、串口转网络服务器，即USR-TCP232-T24系列产品是用来将TCP网络数据包与单片机RS232/RS485/RS422接口数据透明传输的设备，产品体积小，功耗低搭载RAM处理器，速度快，稳定性高。
USR-TCP232-T型号产品为插针式封装，2KV电磁隔离的RJ45接口，小体积的TCP/IP串口模块。
技术规格
表2-1网口转串口模块技术参数表
引脚说明如下
表2-2网口转串口模块引脚定义表
2.2嵌入式软件设计
2.2.1接收指纹数据包流程
门禁节点的软件部分主要实现的功能有控制指纹模块进行指纹采集、指纹注册、指纹比对等操作，并根据指纹匹配结果控制电子锁的开关状态，同时将匹配到的
模板编号发送至服务器端。
另外还要完成从串口接收到由服务器端发送的指纹模板数据，并通过串口2将接受的指纹模板存入指纹模块。
下位机软件主流程图如图2-5所示：
图2-5下位机软件主流程图
2.2.2验证指纹开锁过程
门禁节点在无上位机控制操作的情况下，长期工作于指纹识别状态，当检测到有指纹输入时。
指纹模块采集指纹数据并合成指纹数据模板，之后将合成的数据模板与模块指纹库中的指纹数据进行比对，输出比对结果。
其工作流程如下图所示：
图2-6指纹识别和验证流程图。