需求分析-用例建模

1、软件工程第2章需求分析 高俊涛 副教授用例模型(UseCase Model)参与者：与系统交互的事物。用例：描述参与者如何使用系统以实现某个目标。用例模型：描述系统的组合行为。参与者（Actor） 用例（Use Case） 2.3 需求分析技术：功能分析用例模型举例用户发短信打电话查找电话2.3 需求分析技术：功能分析如何识别参与者?在系统之外，透过系统边界与系统进行有意义交互的任何事物都是参与者。举例：与系统交互的用户与系统交互的外部系统与系统交互的外部硬件参与者的角色角色类型行为启动者起动用例的执行外部服务者在用例中向系统提供服务接收者从用例接收信息帮助者（代理）为其他参与者与系统的交互提

2、供支持如何识别用例？用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。 Jacobson通俗地，用例是参与者利用系统所要达到的目标用户打电话用例的要点价值结果用例的结果形成有意义的目标执行者可见采用业务语言，从用户观点描述一组用例实例用例的实例也称为场景：是执行者使用系统的一个特定情节或用例的一条执行路径。例如：通过输入电话号码拨打电话的场景通过查打电话号码簿拨打电话的场景通过查打电话号码簿拨打电话,电话打到一半电话欠费的场景 建立用例模型的参考原则用例是短文用例可以是一个场景，包括动作和交互用例可以是一组场景，描述不同场景下的行为。这种书写

3、格式可以在任何时候描述有变化的行为，例如黑盒需求，业务流程，系统设计说明。用例里不要有系统设计用例里不要有界面设计用例里不要有测试用例应该描述行为需求用例的主场景最好不要超过9步用例的最大价值不在于主场景，而在于备选行为。用例建模的步骤确定系统的范围和边界确定执行者确定用例对用例进行描述定义用例之间的关系审核用例模型 用例是文档，而非制图！用例的文字描述应包括以下内容用例的目的（功能）；该用例在什么情况下被哪个参与者启动执行；用例与参与者之间交互哪些消息来通知对方作出决定；交互的主消息流及因此被使用或修改的实体；用例中可供选择的异常事件流；用例的结束标志：给参与者返回一个可识别的值举例：用例名

4、称：学生选课执行者：学生目的：完成一次学生选课的完整过程类型：主要的，基本的级别：一级过程描述：学生输入学号/密码，系统识别账户的有效性；对学生进行注册识别；浏览本学期预开课程；选择学生自己要上的课程并确认；退出系统，系统给出所选课程列表及相应学分合计异常事件流：账户有效性检查失败，允许学生重新输入（最多次机会）注册识别失败，没有注册（未交学费）的学生不能选课选择课程确认失败，所选几门课程在时间上发生冲突，系统提示重选用例图用户发短信输入电话号码打电话查找电话包含关系：用例A的行为包含了用例B的行为。用例B描述在多个用例中都有的公共行为。 扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明

5、为扩展用例定义的行为如何插入到为基本用例定义的行为中。在以下几种情况下，可使用扩展用例：a.表明用例的某一部分是可选的系统行为；b.表明只在特定条件（如例外条件）下才执行的分支流。泛化关系：A指向B，表示B是A的一种。发彩信2.3 需求分析技术：功能分析查看通话时间用例间关系-include包含用例的行为插入到基本用例中的一个位置。当遵循基本用例说明的用例实例到达基本用例中定义了包含关系的位置，它就将改而遵循包含用例的说明。一旦执行完包含用例，用例实例就将在基本用例中它先前停止的地方重新开始。教师维护学生成绩录入成绩修改成绩删除成绩用例的包含关系的要点1.包含用例本身是不完整的，它必须拥有基本

6、用例以保证完整性。2.包含用例本身并不知道自己何时或是否被包含。因此，它不能依赖任何包含它的用例。3.被包含的用例一定可以被另外的用例包含(即共用性和独立性)4.从工程角度上，包含关系用于系统分析时共性功能的合并、抽取。5.包含关系通常在用例建模后期而不是前期被发现。描述包含关系应在基本用例的行为序列中定义要插入包含用例的位置。要定义该位置，可以引用基本用例事件流中的特定步骤或分支流。用例扩展关系的概念一个用例的实例可能增加了一些附加的行为，这些附加的行为在另一个用例中定义，扩展定义了这两个用例之间的关系。基本用例可以单独存在，但是在一定的条件下，它的行为可以被另一个用例的行为扩展。当一个用例

7、有多个可选系统行为时，可以用扩展关系对其进行扩展，使得基本用例的不同子流程能在不同的情形下以扩展用例的形式被激活。通过这种方式，可以把可选行为从必须行为中分离出来。用例扩展关系的概念基本用例 扩展点具有条件扩展用例执行返回用例间关系-extends扩展用例可以有基本事件流和备选事件流。用例实例通过扩展到底会采取哪条路径，这不仅取决于在执行之执行扩展前发生的事件，而且还取决于执行扩展时在与主角的交互中发生的事件执行扩展 。用例执行扩展实例一旦执行了扩展，它就会在基本用例的中断点处继续执行基本用例。执行扩展一个扩展用例可以有多个插入段，每个插入段都与自己在基本用例中的扩展点相关。用例实例将继续执行

8、基本用例，并持续到扩展关系中指定的下一个扩展点为止。在此点上，它将执行扩展用例的下一个插入段。这会重复进行，直到执行完最后一个插入段为止。教师查询学生成绩导出查询结果打印查询结果包含关系与扩展关系的区别包含关系1. 当在两个或多个独立用例重复自已并希望避免重复时2. 在基本用例上插入附加行为并具有明确的描述3. 包含用例作为基本用例自身行为的一部分4. 包含关系是无条件的 扩展关系1. 当表述关于正常行为的一个变化情况时2. 在基本用例上插入基本用例不能说明的扩展部分3. 扩展用例作为基本用例的增量扩展4. 扩展用例是按条件要求执行的包含关系与扩展关系的区别包含关系1. 包含用例是共用的用例2

9、. 一个基本用例可以有多个包含用例。3. 一个包含用例可以包含在若干基本用例中。4.很难在包含关系上对系统进行维护修改。扩展关系1. 扩展用例不是共用的用例2. 把可选行为从必须行为中分离出来3. 有条件地扩展已有用例的行为。4. 基本用例可以独立于扩展用例单独存在。5. 适合于功能需求的增加(基本用例的增量扩展)注意I业务语言而非技术语言发票，洗衣机，工作业绩C+，字段，.net,AJAX注意用户观点而非系统观点旅行者订票查看今日航班旅行者处理订票显示今日航班注意-用例命名：动词名词尽量少用弱动词弱名词弱动词：进行使用复制加载重复弱名词：数据报表表格表单系统会掩盖真正的业务！注意-把步骤当用

10、例用户输入用户名用户登陆验证用户名和密码注意-避免使用CRUD管理员删除用户修改用户查看用户增加用户注意-一个用例背后可能隐藏很多数据操作减少库存量减少账户金额创建发货信息结账谢 谢【典型题1-1-1】 （2005下半年试题3）当 时，用例是捕获系统需求最好的选择。A系统具有很少的用户B系统具有很少的接口C系统算法复杂，功能单一D系统有很多参与 者【典型题1-1-2】 （2005下半年试题4） 现有两个用例UC1和UC2。其中UC2是一个完整的用例，可被实例化，而UC1需要UC2中的事件流才可被实例化，且 UC1指定了使用UC2的精确位置，则UC1和UC2间的关系是“ ”。 AincludeBextendCgeneralizeDcall 【典型题1-1-3】 （2006下半年试题32） 用例从用户角度描述系统的行为。用例之间可以存在一定的关系。在“某图书馆管理系统”用例模型中，所有用户使用系统之前必 须通过“身份验证”。“身份验证”可以有“密码验证”和“智能卡验证”两种方式。“身份验证”、“密码验证”和“智能卡验证”之间是 关系。 A关 联B包含C扩展D泛化 【典型题 1-1-8】 （2007下半年试题1）