业务用例
业务用例和系统用例
业务用例和系统用例在软件开发中，业务用例和系统用例是两个关键概念。
本文将从不同的角度介绍这两个用例类别。
一、业务用例业务用例是指描述业务需求的用例。
业务用例通常与实际业务过程中的角色、事件和功能有关。
通俗地说，业务用例就是对于业务人员来说，软件需要做些什么事情。
具体而言，业务用例的特点如下：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签退成功
显示会员当日出入金信息 下载成功，正常显示数据 进入出入金明细对账页面 显示会员当日出入金信息
下载成功，但有数据显示为红色，根据错误 描述如描述为【银行存在成功记录，交易没 有收到消息】时可进行手工调账 进入系统日结界面 提示划转成功 提示日结成功 进入会员账户余额上传页面 显示会员账户当日信息 交易中心：不显示数据 进入会员账户余额上传页面 显示会员账户当日信息 显示红色异常数据 进入账户明细页面 进入申请解约页面 提示申请成功 进入会员解约申请审核页面 弹出申请单信息 审核成功 进入会员解约申请复核页面
UML业务用例分析
使用OO方法建立商业模型必须先定义涉众。
商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。
人是一切的中心，人做事，做事产生物，规则限制人事物。
人驱动系统，事体现过程，物记录结果，规则则是控制。
无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。
本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。
90年代的大学课程讲的都是这些。
第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。
这也就是所谓的面向过程的分析模式。
第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。
这也就是现在的面象对象分析模式。
使用OO方法建立商业模型必须先定义涉众。
商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。
人是一切的中心，人做事，做事产生物，规则限制人事物。
人驱动系统，事体现过程，物记录结果，规则则是控制。
无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。
这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。
书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。
接下来，就是要将他们这些期望定义出来。
这个过程，就是业务用例获取的过程。
笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。
笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。
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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
OTT业务测试用例(2.1.0完整版)
OTT业务测试用例中通服福建邮科公司目录1业务流程测试 (3)1.1未开通状态 (3)1.1.1 正式账号订购 (3)1.2已开通状态 (4)1.2.1 终端绑定 (4)1.2.2 终端解绑 (15)1.2.3 换终端 (21)1.2.4 换帐号 (22)1.2.5 正式账号密码修改 (23)1.2.6 正式帐号账号变更 (23)1.2.7 正式账号停机 (24)1.2.8 正式账号退订 (25)1.2.9 帐号重复绑定 (26)1.2.10 终端重复绑定 (27)1.2.11 体验账号即将失效 (27)1.3正式账号停机状态 (30)1.3.1 终端绑定 (30)1.3.2 终端解绑 (30)1.3.3 换终端 (32)1.3.4 换帐号 (32)1.3.5 复机 (33)1.3.6 退订 (34)1.4拆机状态 (35)1.4.1 体验账号失效 (35)1.4.2 换帐号 (37)2设备管理测试 (39)2.1固件升级 (39)2.1.1 开机升级 (39)2.1.2 手动升级 (39)2.2应用升级 (40)2.2.1 TMC升级 (40)2.2.2 BMC升级 (41)2.3开机动画更新 (41)2.4恢复出厂配置 (42)1业务流程测试1.1 未开通状态1.1.1正式账号订购1.1.1.1营业厅订购➢场景用户到营业厅受理业务。
➢1.1.1.2网厅订购➢场景用户自购终端回家，在终端进行业务受理。
➢测试用例1.2已开通状态1.2.1终端绑定1.2.1.1正式账号1.2.1.1.1手机号(随机码验证)➢场景用户OTT业务(手机号订购)订购工单已竣工，进行终端绑定(随机码验证)并进行业务使用。
➢测试用例1.2.1.1.2手机号(业务密码验证)➢场景用户OTT业务(手机号订购)订购工单已竣工，进行终端绑定(业务密码验证)并进行业务使用。
➢测试用例1.2.1.1.3宽带号(非首次绑定)➢场景用户OTT业务(宽带账号订购)订购工单已竣工，进行终端绑定并进行业务使用。
业务流程类测试用例的设计
业务流程类测试用例的设计
最近做的这个系统是强调业务流程的，感觉和以前的纯功能的系统还是有区别，首先要做的是对业务需求的理解，在流程一致的前提下，再确定功能模块的正确与否。
在网上也参考了一些前辈的经验，感觉很有道理的。
业务流程测试用例编写原则以需求分析中的流程图做为编写测试用例的模型，坚持“测试驱动开发，用例指导结果，数据记录变化”的原则，灵活使用不同的方法制定测试用例。
业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。
业务用例可以不关注程序的界面，但一定要有数据的支持。
测试用例编写时要分开写，在编码前就应该确定业务流程用例，编码时进行系统功能测试用例的设计编写。
系统测试业务流程用例的目的在于验证软件最终数据的准确性.我们的软件体现为,手工数据与报表数据的一直性.用例与用例之间有着一定的关系,目的性十分明确。
在业务流程的分析上，我们应该得到以下信息：
1）系统的主流程是什么
2）条件备选流程是什么
3）数据流向是什么
4）关键的判断条件是什么
作为测试人员，在测试过程中要关注的是流程的走向是否正确，同时关注流程节点数值和输出值的变化来设计用例。
我觉得一个测试人员首先应该具有需求分析人员的能力（或者说要承担起需求分析的责任来），只有这样才会在整个项目中贯穿始终，而且最重要的是有助于测试的进行，测试时会更多的站在用户的角度去考虑，这样的系统才会是实际可用的。
业务逻辑测试用例
业务逻辑测试用例一、背景介绍随着电商的兴起，商品退换成为了一个常见的问题。
为了提升用户体验，商家需要建立一套完善的商品退换流程。
本文将以用户视角，介绍一种商品退换流程，并给出相应的业务逻辑测试用例。
二、商品退换流程1. 用户发起退换申请- 用户登录账号，并进入订单页面- 找到对应的订单，点击退换按钮- 选择退换商品的原因，并填写退款金额或换货信息- 提交退换申请2. 商家审核退换申请- 商家收到退换申请后，进入后台管理系统- 查看退换申请的详细信息，包括退换商品的原因和用户填写的退款金额或换货信息- 根据退换政策，判断是否同意用户的退换申请- 若同意，进入下一步；若不同意，给出拒绝理由并通知用户3. 用户退回商品- 用户收到商家同意退换申请的通知后，准备退回商品- 将商品按照商家提供的退回地址进行包装，并填写退货单- 将包裹送至快递公司，选择合适的运输方式并支付相应费用- 获取快递单号，并在系统中填写退货单号4. 商家收到退回的商品- 商家收到用户退回的商品后，进行验收- 检查退回商品的完整性和符合退换条件- 若商品符合退换条件，进入下一步；若不符合，联系用户并说明原因5. 商家完成退换流程- 商家根据用户的退款金额或换货信息，进行相应的处理- 若用户选择退款，商家在一定时间内将款项退回用户账户- 若用户选择换货，商家准备新的商品并发货- 商家将退款或换货的结果通知用户，并结束退换流程三、业务逻辑测试用例1. 用户发起退换申请- 测试用户能否成功登录账号- 测试用户能否找到对应的订单并点击退换按钮- 测试用户选择退换商品的原因是否成功，并能否填写退款金额或换货信息- 测试用户提交退换申请后，系统是否能正确处理并记录申请信息2. 商家审核退换申请- 测试商家能否收到退换申请的通知- 测试商家能否查看退换申请的详细信息- 测试商家能否根据退换政策判断是否同意申请，并能否给出拒绝理由- 测试商家同意退换申请后，系统是否能正确处理并通知用户3. 用户退回商品- 测试用户能否收到商家同意退换申请的通知- 测试用户是否能准备退回商品，并正确填写退货单- 测试用户能否选择合适的运输方式并支付相应费用- 测试用户是否能成功获取快递单号，并在系统中填写退货单号4. 商家收到退回的商品- 测试商家能否成功收到用户退回的商品- 测试商家能否正确进行退回商品的验收- 测试商家能否判断退回商品是否符合退换条件，并能否联系用户说明原因5. 商家完成退换流程- 测试商家能否根据用户的退款金额或换货信息，进行相应的处理- 测试商家是否能在规定时间内将款项退回用户账户- 测试商家是否能准备新的商品并成功发货- 测试商家能否将退款或换货的结果及时通知用户，并能否结束退换流程四、总结通过以上的业务逻辑测试用例，可以全面测试商品退换流程的各个环节是否正常运转，保证用户能够顺利完成退换申请并得到相应的处理结果。
图书管理系统-业务用例图
• 用例就是外部可见的系统功能。 • 用例包含了所必需的全部行为，即执行用例的主线 次序、标准行为的不同变形及一般行为下的所有异 常情况及其预期的反应。用例不是系统的功能需求 或规格说明，其目的是要展示所描述过程中的需求 情况。 • 用例的动态执行过程可以通过状态图、时序图、协 作图来描述。
用例的概念(Concept)
用例的泛化关系（Generalization）
• 在WebShop电子商城后台系统中购物用户支付货 款包括以下几种方式：网银支付、邮局汇款支付和 支付宝支付。因此，网银支付、邮局汇款支付和支 付宝支付与支付货款之间形成了泛化关系。
用例的包含关系（Include）
• 图书管理系统中还书时，需要检查是否超期，而 超期的检查主要是比较读者可用的借阅期限与实 际借阅期限。 • 图书管理系统中借书时，需要设定归还日期，而 归还日期为借阅日期加上读者可用的借阅期限。 • 可见借书和还书时都需要读取读者的借阅期限。 为此，我们提取一个读取借阅期限的用例，这个 用例可以被借书和还书复用。 • 借书、还书与读取借阅期限用例间的关系就是包 含关系。
在用例图中常使用泛化关系描述多个参与者之间的公共行为例如学院的老师分为专业教师和素质教师参与者之间的关系参与者之间的关系relationsrelations练习练习exerciseexercise识别图书管理系统中的参与者及其他们之间的关系用例usecaseusecase用例的概念用例的概念conceptconcept用例包含了所必需的全部行为即执行用例的主线次序标准行为的不同变形及一般行为下的所有异常情况及其预期的反应
参与者（Actor）
• 参与者一般可分为三类：
–具体的系统用户 –其他系统 –可运行的进程
业务用例与系统用例的关系
使用UML 进行业务建模：理解业务用例与系统用例的相似和不同之处•背景•业务用例模型与系统用例模型有什么相似之处？•业务用例模型与系统用例模型之间究竟有怎样的差异呢？•我应该为业务建模使用哪些UML 图？•业务用例模型和系统用例模型之间的关系是什么？•总结•注释•现在对本文进行讨论！参考资料本文来自于Rational Edge：学习有关业务用例与系统用例相似和不同之处的知识，包括应该使用什么样的UML 图，通过IBM Rational Software Architect 或者其它建模工具来建模这些用例。
绝大多数构架师都认为业务建模是开发软件解决方案中到一个非常重要的活动。
成功的解决方案会支持这个业务，它们能够解决业务问题并确保业务目标的实现。
当开发一个合理的业务模型以后，业务流程分析员能够探究不同业务改良的选项，比方取消多余的任务，使重复且平凡的任务或者容易出现的错误实现自动化操作。
IBM® Rational Unified Process®，或者RUP®，以及Unisys 3D Visual Enterprise，或者3D-VE，或者3D-VE,提供了一个系统化的方法，利用统一建模语言〔UML〕可以直观地表现业务模型，同时还可以派生出一个一致的且能够追溯到这个业务模型的起点系统用例模型。
这篇文章提供了RUP 业务建模的概述，并解决了以下的问题：•业务用例模型与系统用例模型有怎样的相似之处？•业务用例模型与系统用例模型有什么不同之处？•构建业务模型应该使用哪个UML 图？•业务用例模型与系统用例模型之间有什么关系？背景在谈论这个问题之前，我想解释一下为什么要挑选这个特殊的话题来写。
自从1990年我就作为一名软件构架师从事系统用例的工作。
当我是一名由Unisys Global Public Sector 开发的Integrated Justice Information Sharing (IJIS) 框架解决方案的总构架师时，还没有接触到业务用例，直到2002年。
业务用例——精选推荐
业务⽤例
业务⽤例
1、原型：数据导⼊：完成多种数据源（⽀持mysql，SQL server，oracle，excel，csv，标准word⽂档，acess数据库）多种格式数据导⼊，将数据导⼊到mysql数据库中。
2、⽤例图：
3、⽤例编号
数据导⼊
4、执⾏者
⽤户
5、前置条件
⽤户已经登录
6、后置条件
导⼊数据完毕
7、涉众利益
⽤户——希望⽅便，运⾏速度快，数据不会被修改
系统——数据格式规范
8、基本路径
1、⽤户打开系统
2、系统提⽰上传⽂件的位置
3、⽤户上传⽂件
4、系统识别⽂件格式
（1）、（⽂件格式符合⽂件格式）系统提⽰⽤户该⽂件符合⽂件格式
（2）、（⽂件格式不符合⽂件格式）系统提⽰⽤户该⽂件不符合⽂件格式
5、系统显⽰⽂件
6、⽤户操作⽂件（可以删除⽂件，将数据导⼊mysql数据库）
7、系统给出相应反应
（1）（删除⽂件）系统提⽰删除⽂件完毕
（2）、（数据导⼊mysql数据库）系统提⽰数据导⼊完毕
⽤户的：1,3,6
系统的：2,4,5,7
9、业务规则
导⼊的⽂件必须是mysql，SQL server，oracle，excel，csv，标准word⽂档，acess数据库⾥⾯的⽂件⾥必须包括字段和数据。
UML讲义--2业务建模(业务用例模型)
陈翔 财政部财政科学研究所
①
描述模型整体特征（续）
陈翔 财政部财政科学研究所
②
寻找业务参与者
所有的业务参与者在业务参与者包中定义。常见 的业务参与者包括客户、合作伙伴、供应商、工 商行政司法机构、下属机构、股东、单位外部的 信息系统；如果模型描述的是一个大单位的某一 部分，业务参与者也常常包括其他部门、其他部 门里的个人。对于每一个业务参与者要有一个简 短的描述，说明他的职责以及他为什么与单位交 互。对于业务参与者的命名，要反映他的角色。 对于外部信息系统，采用stereotype《IT》加以 区分，命名采用“IT----角色名”的形式，例如 “IT----金穗系统”。
3.2.1 Stakeholder Name
Customer Profiles 3.3.1 Customer Name 3.4 Customer Environment 3.5 Key Stakeholder or Customer Need 3.6 Alternatives and Competition 4. Business Modeling Objectives
陈翔 财政部财政科学研究所
⑤
Business Analysis Model 从业务工作者的角度定义业务过程， 从业务工作者的角度定义业务过程，该模 型定义了业务工作者在单位内部如何工作。 型定义了业务工作者在单位内部如何工作。 业务工作者所处理的事物——“业务类或对 业务工作者所处理的事物 业务类或对 应该通过属性关联或通过消息关联， 象”应该通过属性关联或通过消息关联， 从而产生业务过程期望的输出结果。 从而产生业务过程期望的输出结果。该模 型强调业务领域中的角色及其主动职责。 型强调业务领域中的角色及其主动职责。 在业务用例模型的流程描述中说明了what 在业务用例模型的流程描述中说明了 is done。而How the work is performed 。 在业务分析模型中说明。 在业务分析模型中说明。
- 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指纹识别和验证流程图。