UML系统建模与分析设计(3)-需求分析与用例建模

第三章

需求分析与用例建模

本章目的： 了解可行性研究与风险分析的方法 掌握可行性分析报告的书写格式 掌握客户需求分析的要点及需求分析规格说 明报告的书写格式 掌握通过绘制用例图及其正文描述来完成客 户需求分析的方法 掌握UML的用例模型建模方法

知识图谱

3.1 可行性研究与风险分析

3.13.1.1

可行性研究与风险分析经济可行性研究

进行开发成本的估算以及了解取得效益的评估，确定要开 发的项目是否值得投资开发。

1.系统成本费用分析 设备购置费用。 系统开发费用。 系统安装、运行和维护费用。 人员培训费用。

2.系统效益分析 经济效益：经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用(如操作人员数、工作时间、消耗的物资等)。

社会效益指使用基于计算机的系统后对社会产生的影响(如提高了办事效益，使用户满意等),通常社会效益只能定性地估计。4

3.1.2 技术可行性分析技术可行性主要根据系统的功能、性能、约束条件等，分 析在现有资源和技术条件下系统能否实现.具体包括：

1.风险分析分析在给定的约束条件下设计和实现系统的风险。采用不成熟的技术可能造成技 术风险；人员流动可能给项目带来风险；成本和人员估算不合理造成的预算风险。 风险分析的目的是找出风险，评价风险的大小，并有效地控制和缓解风险。

2.资源分析论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境。

3. 技术分析分析当前的科学技术是否支持系统开发的各项活动

反映系统动态特性： 综合系统的全部因素： 突出系统的重要因素： 结构简单：6

3.1.3 法律可行性分析研究系统开发过程中可能涉及到的合同、侵权、责任以 及各种与法律相抵触的问题。

3.1.4 开发方案可行性分析研究1. 提出待选方案 2. 评价待选方案 3. 确定开发方案

3.1.5

可行性分析报告文档格式

可行性研究报告应包括所提出的解决方案、方案的可行 性以及拟定的开发进度。可行性研究报告的组成部分：引言 、可行性研究前提、对现有系统的分析、所建议系统的技术 可行性分析、经济可行性分析、社会可行性分析、其他可供 选择方案、结论意见等。

3.2 客户需求分析与用例建模 1992年由Jacobson提出了Use case 的概念及 可视化的表示方法—Use case图，受到了IT界的 欢迎，被广泛应用到了面向对象的系统分析中。 用例驱动的系统分析与设计方法已成为面向对象 的系统分析与设计方法的主流。 用例模型由Jacobson在开发AXE系统中首先 使

用,并加入由他所倡导的OOSE和Objectory方 法中。用例方法引起了面向对象领域的极大关注。 自1994年Ivar Jacobson的著作出版后,面向对 象领域已广泛接纳了用例这一概念,并认为它是第 二代面向对象技术的标志。9

3.2 客户需求分析与用例建模 用例驱动是统一过程的重要概念，或者说整个软件生产过 程就是用例驱动的。分析、设计、实现、测试都是用例驱 动的，都是以实现用例为目标。 在这些开发过程中，开发人员首先捕获客户的需求，并以 用例的形式组织成用例模型。然后分析并设计系统来满足 这些用例，因此在用例模型之后就是分析模型，接着是设 计模型和实施模型。在实现了整个系统之后，还将根据用 例模型设计出测试模型来对系统进行验证。 这些模型之间并不是线性转变的，它们是一个迭代、增量 的开发过程。也就是在整个项目开发周期中，将会多次经 过这五个模型的迭代，每次都将越来越精化。

3.2.1

建造需求模型——用例建模

用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对 典型用例的分析，使开发者能够有效地了解用户的需求。

对于正在构造的新系统用例描述系统应该作什么? 对于已构造完毕的系统用例则反映了系统能够完成什么样的功能?

用例建模的主要目标是： 将需求规约变为可视化模型，并得到用户确认； 给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；

提供从功能需求到系统分析、设计、实现各阶段的度量标准； 为最终系统测试提供基准，据此验证系统是否达到功能要求； 为项目目标进度管理和风险管理提供依据。11

设置边界

用例图中包含系 统、角色和用例 贸易经理 等三种模型元素， 以及它们之间的 营销人员 关系。

更新帐目《使用》 《使用》

风险分析交易估价 进行交易

记帐系统 评价

《扩展》超越边界

销售人员

用例模型描述的是外部执行者(Actor)所理解的系统功能。 它描述了待开发系统的功能需求。 它驱动了需求分析之后各阶段的开发工作,不仅在开发过 程中保证了系统所有功能的实现,而且被用于验证和检测 所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。 用例模型由若干个用例图构成，用例图中主要描述执行 者和用例之间的关系。在UML中,构成用例图的主要元素 是用例和执行者及其它们之间的联系。

用例建模的步骤： 确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。

3.2.2 用例图图中的元素

包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1)包含关系 2)扩展关系 3)泛化关系 角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例

3.2.3

定义系统的边界和范围

系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。

定义系统：要定义系统的范围和边界1.定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。 2.定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。

3.2.4 确定执行者(参与者，角色)aActor

执行者(actor)是指在系统外部与系统交互的人或其他系统，它 以某种方式参与了系统内用例的执行。角色在UML中通常以一个 稻草人图符来表示。 执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 ： 1)其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2)硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁 系统时，IC卡读写器就是一个参与者； 3)时钟：当系统需要定时触发时，时钟就是参与者

角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统交换信息。

角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交流的起点。一个执行者可用启动多个用例，而一个用例也可以被 多个执行者启动。17

1.寻找和确定执行者通过向用户提问来识别角色： 谁使用系统提供的主要功能？(主要角色) 谁来维护、管理系统？(次要角色) 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？

!不能把目光只专著于人身上。18

ATM系统的Actor

1、谁使用ATM系统的主要功能(提款)?

答：储户

2、谁使用ATM系统的支持以完成日常工作任务？答：出纳员？还不肯定，先放在这里

3、谁来维护、管理并保持系统正常运行？答： ATM系统工程师，银行人员

4、该系统需要和哪些系统交互？

答：目前还不清楚5、ATM系统需要处理哪些设备？

答：信用卡6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户

储户

银行人员

信用卡

银行会计