信息系统分析与设计 第七章 用例建模

用例分析是站在最终用户的角度看待系统及其特性，模型简单直接，一经提出便受到软件开发人员的青睐。 用例总是和面向对象方法放在一起讨论，并且在面向对象标准建模语言UML中用例也具有中心地位。但严格意义上讲，用例并不是一个面向对象方法论的产物，不包含面向对象思想，只是因为用例概念最初是和面向对象方法一同提出并得到广泛接受而已。

需求分析基本步骤： 从系统涉众获取候选需求 结合系统业务背景理解候选需求 捕获信息系统功能性需求（用例模型） 捕获与功能需求相关的非功能性需求或其他技术性要求

包括： 1、分析并确定可以理解的用例 -识别参与者 -识别用例 -模型表示 2、详细、完整地描述用例 -书写用例规格说明 3、重构用例模型 -识别用例间的关系 -对用例进行分组

用例的概念 用例创始人雅各布森Ivar Jacobson认为： 用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（actor）产生可观测的、有价值的结果。

简单理解一个信息系统用例就是： 系统提供给XX用户的一项功能 一项计算机操作功能，能支持完成一项业务活动 用户与计算机之间的一次完整而简短的交互（人机交互，一个窗口/页面） 一个用例持续的时间很短，目的明确，有始有终

另一代表人物阿里斯代尔·科克伯恩（Alistair Cockburn）认为： 用例（use case）是各种系统受益人之间的一种行为契约。行为包括对象的活动、动作和对象之间的交互等。每一个用例实际上都代表了一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。

全部的用例构成了系统的用例模型。用例模型完整的描述了系统对外可见的行为。

用例和用例模型的意义： 1、用例是对系统需求（主要是功能需求）的规范化描述，用例模型是面向对象分析的关键输入 2、用例图及用例的事件流描述集中体现了系统责任 3、通过用例建立交互图。交互图就是用例的具体体现，其实现是以对象和对象间协作为基础的。

图书馆系统的用例 识别参与者(Actor) 参与者是系统之外与系统进行交互的任何事物。 1、使用系统的个人。 谁负责提供、使用或删除信息？ 谁将使用某项功能？ 2、系统所连接的外部硬件。 例如，控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。 3、与该系统进行通信的其他信息系统。 例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。银行卡系统是销售系统中的一个参与者

区分参与者和DFD的外部实体 只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者 外部实体是指数据的来源和去向，提供数据的人员不一定会执行系统功能 -新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。 -如果学生直接通过Web方式提交个人信息，则认为学生是参与者。

区分主要参与者和次要参与者 主要参与者（primary actor）是从系统中直接获得可度量价值的用户，功能最直接最主要的用户。 次要参与者（secondary actor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用。 用例分析的重点是要找到主要参与者。 -比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。

参与者的表示 在UML中，参与者使用小人符号：

参与者的泛化 在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。 -比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。 -子角色（subrole）可以继承父角色（superrole）的所有行为。 角色的泛化generalization： 识别用例(Use Case) 用例用来描述功能性需求。 一个用例就是系统的一项软件功能，对应于一个事件。 每个用例至少和一个参与者相关，用例名称要准确体现参与者希望系统提供的一项具体功能。

用例的UML图形表示 区分用例和用例完成的步骤 不能混淆用例和用例所包含的步骤。 -比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤。 -用例对应事件，即一项完整不可分割的功能。 用例的步骤不会作为一项单独的功能提供给参与者使用，它们以用例事件流的方式描述，或者是用例的子功能。

区分业务用例和系统用例 当针对整个业务领域建模时，需要使用业务用例 -比如学生“做毕设”、教师“指导学生毕设” -空调维修服务中，工人“上门维修”是最重要的业务用例 信息系统作为整个业务系统的一部分，只负责管理业务的部分功能，即有信息处理的那部分功能。（要明确信息系统的边界） -毕设系统中“提交论文”、“检查进度”，维修服务系统中“填写派工单”、“记录客户反馈”等明显可以作为信息系统用例

案例讨论1——人力资源 某集团公司在全国多个地区有分公司，集团内部招聘岗位发布流程如下：不论何时，某一分公司只要有职位空缺，该分公司的人力资源领导（后简称HRD）就会通知本公司的所有员工并给其它分公司的HRD发送消息，邀请员工们提出申请。其他分公司HRD收到消息后将招聘信息贴在公告板上，所有对此感兴趣的员工都可以向职位空缺分公司的HR领导发送申请。 案例讨论2——空调维修 空调维修服务系统 是否需要考虑客户成为该系统的用户？ Web在线服务系统：

用例图是对系统中的用例的高度概括和直观的表示，但没有细节。 应对每个用例进行文字的详细描述，从而准确定义“做什么”，即需求。 一个编写良好的用例应该具有很好的可读性，没有可读性的用例则一点用也没有。 用例的描述可以有多种格式，从随意的语言描述到定义严格的用例模板，可根据实际情况选择。

用例规格说明（模板）Use Case Specification -用例名称 -主要参与者/次要参与者 -简要描述 -前置条件 -后置条件 -主事件流（主要成功场景/基本路径） -备选事件流（扩展路径/替代流程/异常事件流） -特殊要求/非功能性需求 -发生频率

1、用例的前置条件和后置条件 前置条件（pre-condition）：表述在系统允许用例开始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。 -如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。 后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。 -一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。 某些用例可能没有前置条件或后置条件，比如“查询书目”，因为该用例执行后不会改变系统状态。

用例与事件流（Flow of Activities） 用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。 事件流的描述包括： -用例何时开始和结束 -用例何时与参与者交互（对话过程） -参与者与系统之间有什么对象或信息被交换 -该行为的主事件流和备选事件流

2、主事件流 主事件流是指能够满足目标的典型的成功路径。 -不包括条件及分支 -主成功场景/开心路径/基本路径 3、备选事件流 备选事件流是指除主事件流之外的各种可能失败情况、分支路径或扩展路径。 备选事件流的编号要与主事件流相对应。 用例描述的双列格式 （强调参与者与系统之间进行的交互，能更直观地显示对象的职责） 4、用例说明的书写准则 1、使用简单的语法，主语明确，语义易于理解 2、使用主动句式，明确指出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制。 3、从俯视的第三者的角度来编写，指出参与者的动作，以及系统的响应。 4、描述用户意图和系统职责，而不叙述具体操作动作和技术细节，如“按下XX按钮”、“打开数据库连接”等。 5、使用“确认”、“验证”，而不是“检查是否”，“如果…否则”等，条件分支利用备选事件流说明。例如：系统确认读者借书资格有效。

用例规格描述常见错误 用例描述中没有主参与者。 用例描述中只有参与者动作，没有系统动作。 事件流中的动作没有主语。 描述中有过多的用户操作细节，如按钮等界面元素的具体实现。 描述过低的目标级别。

5、非功能性需求 单个用例如果有非功能性需求，则可以在用例规约中列出，例如性能的要求、可靠性、易用性、输入输出手段的要求等。

案例——酒店预定 某公司要开发一个酒店预定系统，该酒店可对外开放豪华双人间、双人间、三人间和单人间，房间价格视情况可以调整，但周一到周五半价、周末全价的折扣不变。 对于客户请求，该系统应能根据请求预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型、入住日期和天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。 预定入住日期前旅店允许旅客取消预定，距离入住12小时以上可退回所有定金，否则定金不退还。 每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。

进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。 扩展和包含关系就是用例模型中消除冗余的一种手段。 但忌讳使用结构化的功能分解将用例分解成一些子用例、子子用例。 基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。

用例关系：

1、包含关系 经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。 基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。 -包含用例是基本用例存在的必要条件 一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。 比如“查询书目”用例既可以单独存在，也可以作为“预定图书”的包含用例。 2、扩展关系 表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例。 扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。 扩展用例的缺失不影响对基本用例的理解。

3、泛化关系（不推荐） 如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。 用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。 父用例通常是抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完整的，这一点与包含关系扩展关系不同。

用例图元素