[精选]UML系统需求分析建模实例(包括业务建模)9008.pptx
《[精选]UML系统需求分析建模实例(包括业务建模)9008.pptx》由会员分享,可在线阅读,更多相关《[精选]UML系统需求分析建模实例(包括业务建模)9008.pptx(29页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、UML系统需求分析建模实例(包括业务建模)原始需求某公司鉴于业务和员工的快速发展,为了提升整体工作效率,公司准备开发一套员工报账系统,取代原来的人工处理方式,更加方便的服务于员工 日常的账务操作。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况,并设置和维护相关额度准则。系统应该具有基于先进技术的操作界面。原始需求愿景1.为员工提供账务的自动化办理,提高办事效率,方便员工。2.方便财务部门管理好账务信息。涉众分析涉众涉众解解释期望期望员工公司的正式录用雇员通过网上办理账务业务申请,计算机控制流程部门经理部门负责人,负责审核员工提交的申请方便审核操作,通过计算机代替原来的手工审核方式。
2、公司主任公司负责人,负责 2 次审核员工提交的申请方便审核操作,通过计算机代替原来的手工审核方式,界面友好易用。财务主任公司财务部门负责人,负责发放报账款项通过计算机转账的方式替代原来的人为付款方式。业务用例获取(1)定义:业务用例从一个外部的,增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值,业务用例是超越组织边界的业务过程,很可能包括合作伙伴和供应商。“业务用例:业务过程是描述这个业务的具体工作流的;一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程,也可能发生在一个长期的时间段中。“业务用例VS系统用例业务用例模型用例模型系系统用例模型用例模型不同之处范围业
3、务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程,并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互?我们在系统用例说明中书写的事件流应该足够详细,从而用作编写系统测试脚本的出发点。白盒与黑盒业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现有”的业务用例模型,让其面向将要建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值,或者消除业务问题?什么角色和部门需要消失?系统用例几乎总是以黑盒形式编写的。
4、它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求,而不是设计如何满足需求。涉众业务用例图中,可以让业务参与者【业务执行者】和业务角色【业务工人】与业务用例进行交互。在系统用例图中,让参与者与用例进行交互。相同之处两者都有参与者。在业务用例图中,将一个参与者原型化为。两者都有用例。在业务用例模型中,将一个用例原型化为。在参与者与用例之间两者都有一个通信关联。业务用例和系统用例都能够包含、扩展,以及一般化关联。面向对象分析与设计业务用例系统用例分析模型业务用例获取(2)要获取用例就必须先得出边界,边界有了,那么边界外的
5、业务主角就有 了,那么业务主角对这个边界内的目标就是用例。业务用例获取(3)以每个业务目标为一个边界,明确了哪些涉众与这一业务目标有关,他们作为业务主角站在这一边界外提出他们的期望,这些期望作为用例都是为实现这一业务目标服务的(不符合这一业务目标的期望则不被采纳)。业务用例获取(4)获取方法资料、问卷、访谈、观察、调研竞争对手访谈实例:以员工账务服务边界为例,根据涉众分析报告和客户访谈得出的。假定员工对这个系统的期望和目标有通过计算机申请报销业务,申请借款 业务,这两个期望都是与员工账务服务这个特定的业务目标有关的,所以可以作为业务用例被纳入到员工账务服务边界之中。如果假设员工也可以参与管理账
6、务信 息,那么得出的员工对系统的期望就不止这两个,但是分析的时候要注意与员工账务服务这一业务目标相关的期望只有申请报销业务和申请借款业务两个,其他的期 望是与管理账务信息这个业务目标有关,应当被划分到管理账务信息边界中去。一个疑问的解答貌似部门经理也有对员工账务服务边界有贡献啊,不是有参与审核吗,为啥部门经理审核账单就不能算一个业务用例呢?之所以会出现这个疑惑和 误区还是因为没有分清楚边界造成的。因为对于员工账务服务边界来说,处于该边界的之外的业务主角只有员工,而部门经理,公司主任,财务主任都是在这个边界 之内的,他们的工作都只是完成业务主角提出的业务用例的一个步骤,在这里他们作为业务工人无权
7、提出业务用例,他们的职责可以在绘制用例场景活动图的时候通 过泳道体现出来。业务建模业务用例图业务用例实现场景【活动图或者时序图】业务规则业务用例规约业务用例实现场景报销申请的业务用例场景活动图系统需求建模系统用例图系统用例规约方法:业务用例到系统用例的向下流动系统用例确定映射直接将业务用例实现场景中的某个具体过程转换为系统用例抽象当业务场景中的备选用例不能直接被映射时,抽象得到。合并拆分演绎业务用例实现场景中没有这个用例,但是系统需要。额外例子用电申请业务用例场景额外例子用电申请业务用例场景找用例()引入计算机,降低用例粒度,进入系统模型的建立过程。系统用例可以从业务用例场景中推导出来,业 务
8、用例场景一般描述为某某做什么,某某做什么,这个某某做什么就是一个备选的某某做什么就是一个备选的系统用例系统用例,然后从备选用例中确定系统用例,分析过程如下:员工申请报销,这是一个填写报账单的过程,是通过计算机完成的,可以直接映射直接映射成一个系统用例;部门经理审核报账单,这是通过计算机来操作通过计算机来操作决定是否通过审核决定是否通过审核,可以直接映射成一个系统用例;找用例()部门经理说明(填写)拒绝原因,经过分析,这个备选这个备选用例其实是审核报账单的结果之一用例其实是审核报账单的结果之一,也就是说审核报账单中包含了说明拒绝原因这个行为,所以取消部门经理说明(填写)拒绝原因的独立用例资格,将
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 精选 UML 系统 需求 分析 建模 实例 包括 业务 9008
限制150内