UML系统需求分析建模实例(包括业务建模)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
业务用例图 业务用例实现场景【活动图或者时序图】 业务规则 业务用例规约
13
精品文档
业务用例实现场景
报销申请的业务用例场景活动图
14
精品文档
系统需求建模
系统用例图 系统用例规约
15
精品文档
方法：业务用例到系统用例的向下流 动
16
精品文档
系统用例确定
映射
直接将业务用例实现场景中的某个具体过程转 换为系统用例
业务用例进行交互。
两者都有参与者。在业务用例6图中，将一个参与者原型化为
精品文档
面向对象分析与设计
7
精品文档
业务用例获取（2）
要获取用例就必须先得出边界，边界有了，那么 边界外的业务主角就有 了，那么业务主角对这个 边界内的目标就是用例。
8
精品文档
业务用例获取（3）
以每个业务目标为一个边界，明确了哪些涉众与 这一业务目标有关，他们作为业务主角站在这一 边界外提出他们的期望，这些期望作为用例都是 为实现这一业务目标服务的（不符合这一业务目 标的期望则不被采纳）。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
4
精品文档
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
抽象
当业务场景中的备选用例不能直接被映射时， 抽象得到。
合并 拆分 演绎
业务用例实现场景中没17 有这个用例，但是系统精品文档
额外例子－用电申请业务用例场 景
18
精品文档
额外例子－用电申请业务用例场 景
19
精品文档
找用例（１）
引入计算机，降低用例粒度，进入系统模型 的建立过程。系统用例可以从业务用例场景 中推导出来，业 务用例场景一般描述为某某 做什么，某某做什么，这个某某做什么就是 一个备选的系统用例，然后从备选用例中确 定系统用例，分析过程如下：
系统用例着重于要设计的软件系 统。参与者如何与软件系统进行 交互？我们在系统用例说明中书 写的事件流应该足够详细，从而 用作编写系统测试脚本的出发点。
业务用例常常是以白盒形式编写的。它 们描述了被建模的组织中的人和部门之 间的交互。我们使用业务用例来说明在 “现有”业务模型中组织如何工作。然 后我们重构“现有”的业务用例模型， 让其面向将要建模的组织的未来设计。 我们需要创建什么新角色和部门来提供 更多价值，或者消除业务问题？什么角 色和部门需要消失？
• 因为对于员工账务服务边界来说，处于该边界的
之外的业务主角只有员工，而部门经理，公司主
任，财务主任都是在这个边界 之内的，他们的
工作都只是完成业务主角提出的业务用例的一个
步骤，在这里他们作为业务工人无权提出业务用
例，他们的职责可以在绘制用例场景活动图的时
候通 过泳道体现出来。 12
精品文档
业务建模
9
精品文档
业务用例获取（4）
• 获取方法
资料、问卷、访谈、观察、调研竞争对手
访谈实例：
以员工账务服务边界为例，根据涉众分析报告和客 户访谈得出的。假定员工对这个系统的期望和目标 有通过计算机申请报销业务，申请借款 业务，这两 个期望都是与员工账务服务这个特定的业务目标有 关的，所以可以作为业务用例被纳入到员工账务服 务边界之中。
如果假设员工也可以参与管理账务信 息，那么得出 的员工对系统的期望就不10止这两个，但是分析的时精品文档
11
精品文档
一个疑问的解答
貌似部门经理也有对员工账务服务边界有贡献啊， 不是有参与审核吗，为啥部门经理审核账单就不 能算一个业务用例呢？之所以会出现这个疑惑和 误区还是因为没有分清楚边界造成的。
UML系统需求分析建模实例 （包括业务建模）
1
精品文档
原始需求
某公司鉴于业务和员工的快速发展，为了 提升整体工作效率，公司准备开发一套员 工报账系统，取代原来的人工处理方式， 更加方便的服务于员工 日常的账务操作。 财务部门能够通过账务系统定期向各部门 负责人反映账务统计情况，并设置和维护 相关额度准则。系统应该具有基于先进技 术的操作界面。
2
精品文档
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
3
精品文档
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
员工申请报销，这是一个填写报账单的过程， 是通过计算机完成的，可以直接映射成一个 系统用例；
部门经理审核报账单，这是通过计算机来操
作决定是否通过审核，可以直接映射成一个
系统用例；
20
精品文档
找用例（２）
部门经理说明（填写）拒绝原因，经过分 析，这个备选用例其实是审核报账单的结 果之一，也就是说审核报账单中包含了说 明拒绝原因这个行为，所以取消部门经理 说明（填写）拒绝原因的独立用例资格， 将它作为部门经理审核报账单的包含用例。
系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用
务执行者】和业务角色【业务工人】与 例进行交互。
"业务用例：业务过程是描述这个业务的具体工 作流的；一次涉众与实现业务目标的业务之间 的交互。wenku.baidu.com可能包含手工和自动化的过程，也 可能发生在一个长期的时间段中。“
5
精品文档
业务用例VS系统用例
业务用例模型
系统用例模型
不同 范围 之处
白盒 与黑 盒
涉众 相同
业务用例着重于业务操作。它们表示实 现业务目标的业务中的具体工作流。业 务过程可能涉及手工和自动过程，并且 在一段长期的时间内进行。
公司主任审核报账单，公司主任说明（填 写）拒绝原因同上。
财务主任发放还款，这个备选用例是否能 成为系统用例要看情2况1 的，如果财务主任 精品文档
13
精品文档
业务用例实现场景
报销申请的业务用例场景活动图
14
精品文档
系统需求建模
系统用例图 系统用例规约
15
精品文档
方法：业务用例到系统用例的向下流 动
16
精品文档
系统用例确定
映射
直接将业务用例实现场景中的某个具体过程转 换为系统用例
业务用例进行交互。
两者都有参与者。在业务用例6图中，将一个参与者原型化为
精品文档
面向对象分析与设计
7
精品文档
业务用例获取（2）
要获取用例就必须先得出边界，边界有了，那么 边界外的业务主角就有 了，那么业务主角对这个 边界内的目标就是用例。
8
精品文档
业务用例获取（3）
以每个业务目标为一个边界，明确了哪些涉众与 这一业务目标有关，他们作为业务主角站在这一 边界外提出他们的期望，这些期望作为用例都是 为实现这一业务目标服务的（不符合这一业务目 标的期望则不被采纳）。
公司主任 公司负责人，负责 2 方便审核操作，通过计算
次审核员工提交的申 机代替原来的手工审核方
请
式，界面友好易用。
财务主任 公司财务部门负责人，通过计算机转账的方式替 负责发放报账款项 代原来的人为付款方式。
4
精品文档
业务用例获取（1）
定义：
" 业务用例从一个外部的，增加值的角度来描 述一个业务过程。为了给这个业务的涉众创造 价值，业务用例是超越组织边界的业务过程， 很可能包括合作伙伴和供应商。“
抽象
当业务场景中的备选用例不能直接被映射时， 抽象得到。
合并 拆分 演绎
业务用例实现场景中没17 有这个用例，但是系统精品文档
额外例子－用电申请业务用例场 景
18
精品文档
额外例子－用电申请业务用例场 景
19
精品文档
找用例（１）
引入计算机，降低用例粒度，进入系统模型 的建立过程。系统用例可以从业务用例场景 中推导出来，业 务用例场景一般描述为某某 做什么，某某做什么，这个某某做什么就是 一个备选的系统用例，然后从备选用例中确 定系统用例，分析过程如下：
系统用例着重于要设计的软件系 统。参与者如何与软件系统进行 交互？我们在系统用例说明中书 写的事件流应该足够详细，从而 用作编写系统测试脚本的出发点。
业务用例常常是以白盒形式编写的。它 们描述了被建模的组织中的人和部门之 间的交互。我们使用业务用例来说明在 “现有”业务模型中组织如何工作。然 后我们重构“现有”的业务用例模型， 让其面向将要建模的组织的未来设计。 我们需要创建什么新角色和部门来提供 更多价值，或者消除业务问题？什么角 色和部门需要消失？
• 因为对于员工账务服务边界来说，处于该边界的
之外的业务主角只有员工，而部门经理，公司主
任，财务主任都是在这个边界 之内的，他们的
工作都只是完成业务主角提出的业务用例的一个
步骤，在这里他们作为业务工人无权提出业务用
例，他们的职责可以在绘制用例场景活动图的时
候通 过泳道体现出来。 12
精品文档
业务建模
9
精品文档
业务用例获取（4）
• 获取方法
资料、问卷、访谈、观察、调研竞争对手
访谈实例：
以员工账务服务边界为例，根据涉众分析报告和客 户访谈得出的。假定员工对这个系统的期望和目标 有通过计算机申请报销业务，申请借款 业务，这两 个期望都是与员工账务服务这个特定的业务目标有 关的，所以可以作为业务用例被纳入到员工账务服 务边界之中。
如果假设员工也可以参与管理账务信 息，那么得出 的员工对系统的期望就不10止这两个，但是分析的时精品文档
11
精品文档
一个疑问的解答
貌似部门经理也有对员工账务服务边界有贡献啊， 不是有参与审核吗，为啥部门经理审核账单就不 能算一个业务用例呢？之所以会出现这个疑惑和 误区还是因为没有分清楚边界造成的。
UML系统需求分析建模实例 （包括业务建模）
1
精品文档
原始需求
某公司鉴于业务和员工的快速发展，为了 提升整体工作效率，公司准备开发一套员 工报账系统，取代原来的人工处理方式， 更加方便的服务于员工 日常的账务操作。 财务部门能够通过账务系统定期向各部门 负责人反映账务统计情况，并设置和维护 相关额度准则。系统应该具有基于先进技 术的操作界面。
2
精品文档
原始需求愿景
1. 为员工提供账务的自动化办理，提高办 事效率，方便员工。
2. 方便财务部门管理好账务信息。
3
精品文档
涉众分析
涉众
解释
期望
员工
公司的正式录用雇员 通过网上办理账务业务申 请，计算机控制流程
部门经理 部门负责人，负责审 方便审核操作，通过计算 核员工提交的申请 机代替原来的手工审核方 式。
员工申请报销，这是一个填写报账单的过程， 是通过计算机完成的，可以直接映射成一个 系统用例；
部门经理审核报账单，这是通过计算机来操
作决定是否通过审核，可以直接映射成一个
系统用例；
20
精品文档
找用例（２）
部门经理说明（填写）拒绝原因，经过分 析，这个备选用例其实是审核报账单的结 果之一，也就是说审核报账单中包含了说 明拒绝原因这个行为，所以取消部门经理 说明（填写）拒绝原因的独立用例资格， 将它作为部门经理审核报账单的包含用例。
系统用例几乎总是以黑盒形式编 写的。它们描述了软件系统之外 的参与者如何与将被设计的系统 进行交互。系统用例详细阐明了 系统需求。系统用例模型的目的 是从涉众的角度说明需求，而不 是设计如何满足需求。
业务用例图中，可以让业务参与者【业 在系统用例图中，让参与者与用
务执行者】和业务角色【业务工人】与 例进行交互。
"业务用例：业务过程是描述这个业务的具体工 作流的；一次涉众与实现业务目标的业务之间 的交互。wenku.baidu.com可能包含手工和自动化的过程，也 可能发生在一个长期的时间段中。“
5
精品文档
业务用例VS系统用例
业务用例模型
系统用例模型
不同 范围 之处
白盒 与黑 盒
涉众 相同
业务用例着重于业务操作。它们表示实 现业务目标的业务中的具体工作流。业 务过程可能涉及手工和自动过程，并且 在一段长期的时间内进行。
公司主任审核报账单，公司主任说明（填 写）拒绝原因同上。
财务主任发放还款，这个备选用例是否能 成为系统用例要看情2况1 的，如果财务主任 精品文档