UML系统需求分析建模实例包括业务建模.pptx

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