UML系统需求分析建模实例(包括业务建模)

系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用 务执行者】和业务角色【业务工人】与 例进行交互。 业务用例进行交互。
做专业的企业，做专业的事情，让自 己专业 起来。2 020年1 2月上 午12时3 5分20. 12.200: 35Dece mber 2, 2020
时间是人类发展的空间。2020年12月2 日星期 三12时 35分4 秒00:35: 042 December 2020
科学，你是国力的灵魂；同时又是社 会发展 的标志 。上午1 2时35 分4秒上 午12时 35分00 :35:042 0.12.2
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
使用语境
[用例目标，是一个较长的描述，甚至包括触发条件。]
范围
[用例的设计范围，在设计时将系统作为一个黑盒来考虑。]
级别
[概要、用户目标、子功能三者之一。]
主执行者
[也就是该用例的主Actor，在此应列出其名称，并简要描述。]
项目相关人员
项目相关人员
利益
利益
[项目相关人员名称]
[项目相关人员取得的利益]
合并 拆分 演绎
业务用例实现场景中没有这个用例，但是系统需要。
额外例子－用电申请业务用例场景
额外例子－用电申请业务用例场景
找用例（１）
引入计算机，降低用例粒度，进入系统模型的 建立过程。系统用例可以从业务用例场景中推 导出来，业 务用例场景一般描述为某某做什么， 某某做什么，这个某某做什么就是一个备选的 系统用例，然后从备选用例中确定系统用例， 分析过程如下：
两者都有参与者。在业务用例图中，将一个参与者原型化为
面向对象分析与设计
业务用 系统用 分析模
例
例
型
业务用例获取（2）
要获取用例就必须先得出边界，边界有了，那么 边界外的业务主角就有 了，那么业务主角对这个 边界内的目标就是用例。
业务用例获取（3）
以每个业务目标为一个边界，明确了哪些涉众与 这一业务目标有关，他们作为业务主角站在这一 边界外提出他们的期望，这些期望作为用例都是 为实现这一业务目标服务的（不符合这一业务目 标的期望则不被采纳）。
业务用例获取（4）
• 获取方法
资料、问卷、访谈、观察、调研竞争对手
访谈实例：
以员工账务服务边界为例，根据涉众分析报告和客户访谈 得出的。假定员工对这个系统的期望和目标有通过计算机 申请报销业务，申请借款 业务，这两个期望都是与员工 账务服务这个特定的业务目标有关的，所以可以作为业务 用例被纳入到员工账务服务边界之中。
员工申请报销，这是一个填写报账单的过程， 是通过计算机完成的，可以直接映射成一个系 统用例；
部门经理审核报账单，这是通过计算机来操作 决定是否通过审核，可以直接映射成一个系统 用例；
找用例（２）
部门经理说明（填写）拒绝原因，经过分析，这个备选 用例其实是审核报账单的结果之一，也就是说审核报账 单中包含了说明拒绝原因这个行为，所以取消部门经理 说明（填写）拒绝原因的独立用例资格，将它作为部门 经理审核报账单的包含用例。
系统用例着重于要设计的软件系 统。参与者如何与软件系统进行 交互？我们在系统用例说明中书 写的事件流应该足够详细，从而 用作编写系统测试脚本的出发点。
业务用例常常是以白盒形式编写的。它 们描述了被建模的组织中的人和部门之 间的交互。我们使用业务用例来说明在 “现有”业务模型中组织如何工作。然 后我们重构“现有”的业务用例模型， 让其面向将要建模的组织的未来设计。 我们需要创建什么新角色和部门来提供 更多价值，或者消除业务问题？什么角 色和部门需要消失？
天生我材必有用，千金散尽还复来。0 0:35:04 00:35:0 400:35 12/2/20 20 12:35:04 AM
安全象只弓，不拉它就松，要想保安 全，常 把弓弦 绷。20. 12.200: 35:0400 :35Dec-202-De c-20
得道多助失道寡助，掌控人心方位上 。00:35: 0400:3 5:0400: 35Wed nesday, December 02, 2020
"业务用例：业务过程是描述这个业务的具体工 作流的；一次涉众与实现业务目标的业务之间 的交互。它可能包含手工和自动化的过程，也 可能发生在一个长期的时间段中。“
业务用例VS系统用例
业务用例模型
系统用例模型
不同 范围 之处
白盒 与黑 盒
涉众 相同
业务用例着重于业务操作。它们表示实 现业务目标的业务中的具体工作流。业 务过程可能涉及手工和自动过程，并且 在一段长期的时间内进行。
UML系统需求分析建模实例 （包括业务建模）
原始需求
某公司鉴于业务和员工的快速发展，为了 提升整体工作效率，公司准备开发一套员 工报账系统，取代原来的人工处理方式， 更加方便的服务于员工 日常的账务操作。 财务部门能够通过账务系统定期向各部门 负责人反映账务统计情况，并设置和维护 相关额度准则。系统应该具有基于先进技 术的操作界面。
如果假设员工也可以参与管理账务信 息，那么得出的员 工对系统的期望就不止这两个，但是分析的时候要注意与 员工账务服务这一业务目标相关的期望只有申请报销业务 和申请借款业务两个，其他的期 望是与管理账务信息这 个业务目标有关，应当被划分到管理账务信息边界中去。
一个疑问的解答
貌似部门经理也有对员工账务服务边界有贡献啊， 不是有参与审核吗，为啥部门经理审核账单就不 能算一个业务用例呢？之所以会出现这个疑惑和 误区还是因为没有分清楚边界造成的。
感情上的亲密，发展友谊；钱财上的 亲密， 破坏友 谊。20. 12.2202 0年12 月2日星 期三12 时35分 4秒20. 12.2
谢谢大家！
业务用例图 业务用例实现场景【活动图或者时序图】 业务规则 业务用例规约
业务用例实现场景
报销申请的业务用例场景活动图
系统需求建模
系统用例图 系统用例规约
方法：业务用例到系统用例的向下流动
系统用例确定
映射
直接将业务用例实现场景中的某个具体过程转换为 系统用例
抽象
当业务场景中的备选用例不能直接被映射时，抽象 得到。
……
……Βιβλιοθήκη 前置条件[也就是激发该用例，所应该满足的条件。]
后置条件
[也就是该用例完成之后，将执行什么动作。]
成功保证
[描述当目标完成后，环境的变化情况。]
触发事件
[什么引发用例，例如时间事件。]
描述
步骤
活动
1
[在这里写出触发事件到目标完成以
及清除的步骤。]
2
[……]
3
扩展
步骤
分支动作
1a
[引起分支的条件]
• 因为对于员工账务服务边界来说，处于该边界的 之外的业务主角只有员工，而部门经理，公司主 任，财务主任都是在这个边界 之内的，他们的 工作都只是完成业务主角提出的业务用例的一个 步骤，在这里他们作为业务工人无权提出业务用 例，他们的职责可以在绘制用例场景活动图的时 候通 过泳道体现出来。
业务建模
[活动或子用例名称]
技术和数据变
化
1
[变化列表]
后记Ｉ－系统分析
员工报销申请 用例实现的分 析类时序图
后记II-系统分析
VOPC类图
后记II-系统设计
系统架构 选择什么框架 基于框架和架构的时序图
每一次的加油，每一次的努力都是为 了下一 次更好 的自己 。20.12. 220.12. 2Wednesday, December 02, 2020
每天都是美好的一天，新的一天开启 。20.12. 220.12. 200:35 00:35:0 400:35: 04Dec-2 0
人生不是自发的自我发展，而是一长 串机缘 。事件 和决定 ，这些 机缘、 事件和 决定在 它们实 现的当 时是取 决于我 们的意 志的。2 020年1 2月2日 星期三 12时35 分4秒 Wednes day, December 02, 2020
公司主任审核报账单，公司主任说明（填写）拒绝原因 同上。
财务主任发放还款，这个备选用例是否能成为系统用例 要看情况的，如果财务主任是人为的发放现金或者人为 的去银行汇款转账，那么没有通过计算机（意思是该系 统）进行操作，就不能算是一个系统用例；而如果财务 主任是通过系统提供的转账功能汇款的话，那么就是一 个系统用例。回顾涉众分析报告后我们确定这可以成为 一个系统用例。
安全在于心细，事故出在麻痹。20.12. 220.12. 200:35: 0400:3 5:04December 2, 2020
加强自身建设，增强个人的休养。202 0年12 月2日上 午12时 35分20 .12.220 .12.2
扩展市场，开发未来，实现现在。202 0年12 月2日星 期三上 午12时 35分4 秒00:35: 0420.1 2.2
完成系统用例图
系统用例场景－描述人机交互过程
申请报销
撰写用例规约和规则
用例图只是表达了用例的目标，这是远远 不够的。用例的背后封装了不同级别的相 关需求，我们需要通过书写用例规约把这 些需求表达出来。用例规约就是以用例方 式组织的需求规约。
用例规约模板（１）
用例#
[用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用 例的目标。]