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

UML系统需求分析建模实例（包括业务建模）第一页，共三十页。原始需求某公司鉴于业务和员工的快速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理方式，更加方便的服务于员工日常的账务操作。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度准则。系统应该具有基于先进技术的操作界面。第二页，共三十页。原始需求愿景1.为员工提供账务的自动化办理，提高办事效率，方便员工。2.方便财务部门管理好账务信息。第三页，共三十页。涉众分析涉众解释期望员工公司的正式录用雇员通过网上办理账务业务申请，计算机控制流程部门经理部门负责人，负责审核员工提交的申请方便审核操作，通过计算机代替原来的手工审核方式。公司主任公司负责人，负责2次审核员工提交的申请方便审核操作，通过计算机代替原来的手工审核方式，界面友好易用。财务主任公司财务部门负责人，负责发放报账款项通过计算机转账的方式替代原来的人为付款方式。第四页，共三十页。业务用例获取（1）定义："业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供应商。“"业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。“第五页，共三十页。业务用例VS系统用例业务用例模型系统用例模型不同之处范围业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。白盒与黑盒业务用例常常是以白盒形式编写的。它们描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后我们重构“现有”的业务用例模型，让其面向将要建模的组织的未来设计。我们需要创建什么新角色和部门来提供更多价值，或者消除业务问题？什么角色和部门需要消失？系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。涉众业务用例图中，可以让业务参与者【业务执行者】和业务角色【业务工人】与业务用例进行交互。在系统用例图中，让参与者与用例进行交互。相同之处两者都有参与者。在业务用例图中，将一个参与者原型化为<<BusinessActor>>。两者都有用例。在业务用例模型中，将一个用例原型化为<<BusinessUseCase>>。在参与者与用例之间两者都有一个通信关联。业务用例和系统用例都能够包含、扩展，以及一般化关联。第六页，共三十页。面向对象分析与设计业务用例系统用例分析模型第七页，共三十页。业务用例获取（2）要获取用例就必须先得出边界，边界有了，那么边界外的业务主角就有了，那么业务主角对这个边界内的目标就是用例。第八页，共三十页。业务用例获取（3）以每个业务目标为一个边界，明确了哪些涉众与这一业务目标有关，他们作为业务主角站在这一边界外提出他们的期望，这些期望作为用例都是为实现这一业务目标服务的（不符合这一业务目标的期望则不被采纳）。第九页，共三十页。业务用例获取（4）获取方法资料、问卷、访谈、观察、调研竞争对手访谈实例：以员工账务服务边界为例，根据涉众分析报告和客户访谈得出的。假定员工对这个系统的期望和目标有通过计算机申请报销业务，申请借款业务，这两个期望都是与员工账务服务这个特定的业务目标有关的，所以可以作为业务用例被纳入到员工账务服务边界之中。如果假设员工也可以参与管理账务信息，那么得出的员工对系统的期望就不止这两个，但是分析的时候要注意与员工账务服务这一业务目标相关的期望只有申请报销业务和申请借款业务两个，其他的期望是与管理账务信息这个业务目标有关，应当被划分到管理账务信息边界中去。第十页，共三十页。第十一页，共三十页。一个疑问的解答貌似部门经理也有对员工账务服务边界有贡献啊，不是有参与审核吗，为啥部门经理审核账单就不能算一个业务用例呢？之所以会出现这个疑惑和误区还是因为没有分清楚边界造成的。因为对于员工账务服务边界来说，处于该边界的之外的业务主角只有员工，而部门经理，公司主任，财务主任都是在这个边界之内的，他们的工作都只是完成业务主角提出的业务用例的一个步骤，在这里他们作为业务工人无权提出业务用例，他们的职责可以在绘制用例场景活动图的时候通过泳道体现出来。第十二页，共三十页。业务建模业务用例图业务用例实现场景【活动图或者时序图】业务规则业务用例规约第十三页，共三十页。业务用例实现场景报销申请的业务用例场景活动图第十四页，共三十页。系统需求建模系统用例图系统用例规约第十五页，共三十页。方法：业务用例到系统用例的向下流动第十六页，共三十页。系统用例确定映射直接将业务用例实现场景中的某个具体过程转换为系统用例抽象当业务场景中的备选用例不能直接被映射时，抽象得到。合并拆分演绎业务用例实现场景中没有这个用例，但是系统需要。第十七页，共三十页。额外例子－用电申请业务用例场景第十八页，共三十页。额外例子－用电申请业务用例场景第十九页，共三十页。找用例（１）引入计算机，降低用例粒度，进入系统模型的建立过程。系统用例可以从业务用例场景中推导出来，业务用例场景一般描述为某某做什么，某某做什么，这个某某做什么就是一个备选的系统用例，然后从备选用例中确定系统用例，分析过程如下：员工申请报销，这是一个填写报账单的过程，是通过计算机完成的，可以直接映射成一个系统用例；部门经理审核报账单，这是通过计算机来操作决定是否通过审核，可以直接映射成一个系统用例；第二十页，共三十页。找用例（２）部门经理说明（填写）拒绝原因，经过分析，这个备选用例其实是审核报账单的结果之一，也就是说审核报账单中包含了说明拒绝原因这个行为，所以取消部门经理说明（填写）拒绝原因的独立用例资格，将它作为部门经理审核报账单的包含用例。公司主任审核报账单，公司主任说明（填写）拒绝原因同上。财务主任发放还款，这个备选用例是否能成为系统用例要看情况的，如果财务主任是人为的发放现金或者人为的去银行汇款转账，那么没有通过计算机（意思是该系统）进行操作，就不能算是一个系统用例；而如果财务主任是通过系统提供的转账功能汇款的话，那么就是一个系统用例。回顾涉众分析报告后我们确定这可以成为一个系统用例。第二十一页，共三十页。完成系统用例图第二十二页，共三十页。系统用例场景－描述人机交互过程申请报销第二十三页，共三十页。撰写用例规约和规则用例图只是表达了用例的目标，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例方式组织的需求规约。第二十四页，共三十页。用例规约模板（１）用例#[用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。]使用语境[用例目标，是一个较长的描述，甚至包括触发条件。]范围[用例的设计范围，在设计时将系统作为一个黑盒来考虑。]级别[概要、用户目标、子功能三者之一。]主执行者[也就是该用例的主Actor，在此应列出其名称，并简要描述。]项目相关人员利益项目相关人员利益[项目相关人员名称][项目相关人员取得的利益]…………前置条件[也就是激发该用例，所应该满足的条件。]后置条件[也就是该用例完成之后，将执行什么动作。]成功保证[描述当目标完成后，环境的变化情况。]触发事件[什么引发用例，例如时间事件。]描述步骤活动1[在这里写出触发事件到目标完成以及清除的步骤。]2[……]3扩展步骤分支动作1a[引起分支的条件][活动或子用例名称]技术和数据变化1[变化列表]第二十五页，共三十页。后记Ｉ－系统分析员工报销申请用例实现的分析类时序图第二十六页，共三十页。后记II-系统分析VOPC类图第二十七页，共三十页。后记II-系统设计系统架构选择什么框架基于框架和架构的时序图第二十八页，共三十页。谢谢2023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/102023/5/10第二十九页，共三十页。内容总结UML系统需求分析建模实例（包括业务建模）。UML系统需求分析建模实例（包括业务建模）。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度准则。方便审核操作，通过计算机代替原来的手工审核方式。业