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

.,UML系统需求分析建模实例（包括业务建模）,.,原始需求,某公司鉴于业务和员工的快速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理方式，更加方便的服务于员工日常的账务操作。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度准则。系统应该具有基于先进技术的操作界面。,.,原始需求愿景,1.为员工提供账务的自动化办理，提高办事效率，方便员工。2.方便财务部门管理好账务信息。,.,涉众分析,.,业务用例获取（1）,定义：业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供应商。“业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。“,.,业务用例VS系统用例,.,面向对象分析与设计,.,业务用例获取（2）,要获取用例就必须先得出边界，边界有了，那么边界外的业务主角就有了，那么业务主角对这个边界内的目标就是用例。,.,业务用例获取（3）,以每个业务目标为一个边界，明确了哪些涉众与这一业务目标有关，他们作为业务主角站在这一边界外提出他们的期望，这些期望作为用例都是为实现这一业务目标服务的（不符合这一业务目标的期望则不被采纳）。,.,业务用例获取（4）,获取方法资料、问卷、访谈、观察、调研竞争对手访谈实例：以员工账务服务边界为例，根据涉众分析报告和客户访谈得出的。假定员工对这个系统的期望和目标有通过计算机申请报销业务，申请借款业务，这两个期望都是与员工账务服务这个特定的业务目标有关的，所以可以作为业务用例被纳入到员工账务服务边界之中。如果假设员工也可以参与管理账务信息，那么得出的员工对系统的期望就不止这两个，但是分析的时候要注意与员工账务服务这一业务目标相关的期望只有申请报销业务和申请借款业务两个，其他的期望是与管理账务信息这个业务目标有关，应当被划分到管理账务信息边界中去。,.,.,一个疑问的解答,貌似部门经理也有对员工账务服务边界有贡献啊，不是有参与审核吗，为啥部门经理审核账单就不能算一个业务用例呢？之所以会出现这个疑惑和误区还是因为没有分清楚边界造成的。,因为对于员工账务服务边界来说，处于该边界的之外的业务主角只有员工，而部门经理，公司主任，财务主任都是在这个边界之内的，他们的工作都只是完成业务主角提出的业务用例的一个步骤，在这里他们作为业务工人无权提出业务用例，他们的职责可以在绘制用例场景活动图的时候通过泳道体现出来。,.,业务建模,业务用例图业务用例实现场景【活动图或者时序图】业务规则业务用例规约,.,业务用例实现场景,报销申请的业务用例场景活动图,.,系统需求建模,系统用例图系统用例规约,.,方法：业务用例到系统用例的向下流动,.,系统用例确定,映射直接将业务用例实现场景中的某个具体过程转换为系统用例抽象当业务场景中的备选用例不能直接被映射时，抽象得到。合并拆分演绎业务用例实现场景中没有这个用例，但是系统需要。,.,额外例子用电申请业务用例场景,.,额外例子用电申请业务用例场景,.,找用例（）,引入计算机，降低用例粒度，进入系统模型的建立过程。系统用例可以从业务用例场景中推导出来，业务用例场景一般描述为某某做什么，某某做什么，这个某某做什么就是一个备选的系统用例，然后从备选用例中确定系统用例，分析过程如下：员工申请报销，这是一个填写报账单的过程，是通过计算机完成的，可以直接映射成一个系统用例；部门经理审核报账单，这是通过计算机来操作决定是否通过审核，可以直接映射成一个系统用例；,.,找用例（）,部门经理说明（填写）拒绝原因，经过分析，这个备选用例其实是审核报账单的结果之一，也就是说审核报账单中包含了说明拒绝原因这个行为，所以取消部门经理说明（填写）拒绝原因的独立用例资格，将它作为部门经理审核报账单的包含用例。公司主任审核报账单，公司主任说明（填写）拒绝原因同上。财务主任发放还款，这个备选用例是否能成为系统用例要看情况的，如果财务主任是人为的发放现金或者人为的去银行汇款转账，那么没有通过计算机（意思是该系统）进行操作，就不能算是一个系统用例；而如果财务主任是通过系统提供的转账功能汇款的话，那么就是一个系统用例。回顾涉众分析报告后我们确定这可以成为一个系统用例。,.,完成系统用例图,.,系统用例场景描述人机交互过程,申请报销,.,撰写用例规约和规则,用例图只是表达了用例的目标，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例