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