文档介绍：需求分析与用例建模
2018/7/31
1
软件工程方法
用例用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
用例驱动是统一过程的重要概念,或者说整个软件生产过程就是用例驱动的。分析、设计、实现、测试都是用例驱动的,都是以实现用例为目标。
在这些开发过程中,开发人员首先捕获客户的需求,并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例,因此在用例模型之后就是分析模型,接着是设计模型和实施模型。在实现了整个系统之后,还将根据用例模型设计出测试模型来对系统进行验证。
这些模型之间并不是线性转变的,它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中,将会多次经过这五个模型的迭代,每次都将越来越精化。
1 客户需求分析与用例建模
2018/7/31
2
软件工程方法
建造需求模型——用例建模
用例建模技术,用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析,使开发者能够有效地了解用户的需求。
对于正在构造的新系统用例描述系统应该作什么?
对于已构造完毕的系统用例则反映了系统能够完成什么样的功能?
用例建模的主要目标是:
将需求规约变为可视化模型,并得到用户确认;
给出清晰、一致的关于系统做什么的描述,确定系统的功能要求;
提供从功能需求到系统分析、设计、实现各阶段的度量标准;
为最终系统测试提供基准,据此验证系统是否达到功能要求;
为项目目标进度管理和风险管理提供依据。
2018/7/31
3
软件工程方法
用例图中包含系统、角色和用例等三种模型元素,以及它们之间的关系。
贸易经理
风险分析
进行交易
交易估价
更新帐目
《使用》
《使用》
《扩展》
营销人员
超越边界
评价
销售人员
记账系统
设置边界
2018/7/31
4
软件工程方法
用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。
用例模型由若干个用例图构成,用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。
2018/7/31
5
软件工程方法
确定系统的范围和边界;
确定系统的执行者和用例;
对用例进行描述;
定义用例之间的关系;
审核用例模型。
用例建模的步骤:
2018/7/31
6
软件工程方法
确定执行者(参与者,角色)
执行者(actor)是指在系统外部与系统交互的人或其他系统,它以某种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图符来表示。
执行者类型:参与者不仅可以由人承担,还可以是其它系统、硬件设备、甚至是时钟:1)其它系统:当系统需要与其它系统交互时,如ATM柜员机系统中,银行后台系统就是一个参与者;2)硬件设备:如果系统需要与硬件设备交互时,如在开发IC卡门禁系统时,IC卡读写器就是一个参与者;3)时钟:当系统需要定时触发时,时钟就是参与者
角色与系统交互:角色向系统发送消息、从系统接受消息、或是与系统交换信息。
角色与用例:角色往往是发现新用例的基础,同时也是分析员和用户交流的起点。一个执行者可用启动多个用例,而一个用例也可以被多个执行者启动。
2018/7/31
9
软件工程方法

通过向用户提问来识别角色:
谁使用系统提供的主要功能?(主要角色)
谁来维护、管理系统?(次要角色)
谁需要借助于系统完成日常工作任务?
系统需要控制的硬件设备有哪些?
系统需要与其他哪些系统交互?
系统从哪儿得到信息?
对系统产生的结果感兴趣的人或事是哪些?
!不能把目光只专著于人身上。
2018/7/31
10
软件工程方法