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

1、UML系统需求分析建模实例包括业务建模.原始需求某公司鉴于业务和员工的快速开展，为了提升整体任务效率，公司预备开发一套员工报账系统，取代原来的人工处置方式，更加方便的效力于员工 日常的账务操作。财务部门可以经过账务系统定期向各部门担任人反映账务统计情况，并设置和维护相关额度准那么。系统应该具有基于先进技术的操作界面。.原始需求愿景1. 为员工提供账务的自动化办理，提高办事效率，方便员工。2. 方便财务部门管理好账务信息。.涉众分析涉众解释期望员工公司的正式录用雇员通过网上办理账务业务申请，计算机控制流程部门经理部门负责人，负责审核员工提交的申请方便审核操作，通过计算机代替原来的手工审核方式。公

2、司主任公司负责人，负责 2 次审核员工提交的申请方便审核操作，通过计算机代替原来的手工审核方式，界面友好易用。财务主任公司财务部门负责人，负责发放报账款项通过计算机转账的方式替代原来的人为付款方式。.业务用例获取1定义： 业务用例从一个外部的，添加值的角度来描画一个业务过程。为了给这个业务的涉众发明价值，业务用例是超越组织边境的业务过程，很能够包括协作同伴和供应商。“业务用例：业务过程是描画这个业务的详细任务流的；一次涉众与实现业务目的的业务之间的交互。它能够包含手工和自动化的过程，也能够发生在一个长期的时间段中。“.业务用例VS系统用例业务用例模型系统用例模型不同之处范围业务用例着重于业务操

3、作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。白盒与黑盒业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现有”的业务用例模型，让其面向将要建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值，或者消除业务问题？什么角色和部门需要消失？系统用例几乎总是以黑盒形式编写的。它们描述了软件系统

4、之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。涉众业务用例图中，可以让业务参与者【业务执行者】和业务角色【业务工人】与业务用例进行交互。在系统用例图中，让参与者与用例进行交互。相同之处两者都有参与者。在业务用例图中，将一个参与者原型化为 。两者都有用例。在业务用例模型中，将一个用例原型化为 。在参与者与用例之间两者都有一个通信关联。业务用例和系统用例都能够包含、扩展，以及一般化关联。.面向对象分析与设计.业务用例获取2要获取用例就必需先得出边境，边境有了，那么边境外的业务主角就有 了，那么业务主角对这个边

5、境内的目的就是用例。.业务用例获取3以每个业务目的为一个边境，明确了哪些涉众与这一业务目的有关，他们作为业务主角站在这一边境外提出他们的期望，这些期望作为用例都是为实现这一业务目的效力的不符合这一业务目的的期望那么不被采用。.业务用例获取4获取方法资料、问卷、访谈、察看、调研竞争对手访谈实例：以员工账务效力边境为例，根据涉众分析报告和客户访谈得出的。假定员工对这个系统的期望和目的有经过计算机恳求报销业务，恳求借款 业务，这两个期望都是与员工账务效力这个特定的业务目的有关的，所以可以作为业务用例被纳入到员工账务效力边境之中。假设假设员工也可以参与管理账务信 息，那么得出的员工对系统的期望就不止这

6、两个，但是分析的时候要留意与员工账务效力这一业务目的相关的期望只需恳求报销业务和恳求借款业务两个，其他的期 望是与管理账务信息这个业务目的有关，该当被划分到管理账务信息边境中去。.一个疑问的解答貌似部门经理也有对员工账务效力边境有奉献啊，不是有参与审核吗，为啥部门经理审核账单就不能算一个业务用例呢？之所以会出现这个疑惑和 误区还是由于没有分清楚边境呵斥的。由于对于员工账务效力边境来说，处于该边境的之外的业务主角只需员工，而部门经理，公司主任，财务主任都是在这个边境 之内的，他们的任务都只是完成业务主角提出的业务用例的一个步骤，在这里他们作为业务工人无权提出业务用例，他们的职责可以在绘制用例场景

7、活动图的时候通 过泳道表达出来。.业务建模业务用例图业务用例实现场景【活动图或者时序图】业务规那么业务用例规约.业务用例实现场景报销恳求的业务用例场景活动图.系统需求建模系统用例图系统用例规约.方法：业务用例到系统用例的向下流动.系统用例确定映射直接将业务用例实现场景中的某个详细过程转换为系统用例笼统当业务场景中的备选用例不能直接被映射时，笼统得到。合并拆分演绎业务用例实现场景中没有这个用例，但是系统需求。.额外例子用电恳求业务用例场景.额外例子用电恳求业务用例场景.找用例引入计算机，降低用例粒度，进入系统模型的建立过程。系统用例可以从业务用例场景中推导出来，业 务用例场景普通描画为某某做什么

8、，某某做什么，这个某某做什么就是一个备选的系统用例，然后从备选用例中确定系统用例，分析过程如下：员工恳求报销，这是一个填写报账单的过程，是经过计算机完成的，可以直接映射成一个系统用例；部门经理审核报账单，这是经过计算机来操作决议能否经过审核，可以直接映射成一个系统用例；.找用例部门经理阐明填写回绝缘由，经过分析，这个备选用例其实是审核报账单的结果之一，也就是说审核报账单中包含了阐明回绝缘由这个行为，所以取消部门经理阐明填写回绝缘由的独立用例资历，将它作为部门经理审核报账单的包含用例。公司主任审核报账单，公司主任阐明填写回绝缘由同上。财务主任发放还款，这个备选用例能否能成为系统用例要看情况的，假

9、设财务主任是人为的发放现金或者人为的去银行汇款转账，那么没有经过计算机意思是该系 统进展操作，就不能算是一个系统用例；而假设财务主任是经过系统提供的转账功能汇款的话，那么就是一个系统用例。回想涉众分析报告后我们确定这可以成为 一个系统用例。.完成系统用例图.系统用例场景描画人机交互过程恳求报销.撰写用例规约和规那么用例图只是表达了用例的目的，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需求经过书写用例规约把这些需求表达出来。用例规约就是以用例方式组织的需求规约。.用例规约模板用例#用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。使用语境用例目标，是一个较长的描述，甚至包括触发条件。范围用例的设计范围，在设计时将系统作为一个黑盒来考虑。级别概要、用户目标、子功能三者之一。主执行者也就是该用例的主Actor，在此应列出其名称，并简要描述。项目相关人员利益项目相关人员利益项目相关人员名称项目相关人员取得的利益前置条件也就是激发该用例，所应该满足的条件。后置条件也就是该用例完成之后，将执行什么动作。成功保证描述当目标完成后，环境的变化情况。触发事件什么