文章目录7.1用例需求分析7.2用例描述7.3构建用例关系
7.1基于用例的需求分析
用例分析是站在最终用户的角度审视系统及其特性，模型简单直接，提出后很受软件开发人员的欢迎。
用例总是与面向对象的方法一起讨论，用例在面向对象的标准建模语言UML中也具有中心地位。 但从严格意义上说，用例不是面向对象方法的产物，不包含面向对象思想，用例概念只是首先与面向对象方法一起被提出和广泛接受。
需求分析基本步骤：
从系统相关人员处获取候选需求
结合系统业务背景了解候选需求
捕获信息系统的功能要求(用例模型)
了解与功能要求相关的非功能要求或其他技术要求
包括以下内容：
1、分析和确定可以理解的用例
-确定参与者
-识别用例
-模型显示
2、详细完整地描述用例
-写用例规格说明
3、重构用例模型
识别用例之间的关系
-将用例分组
用例的概念
用例的创始人pbdldIvar Jacobson认为：
用例(use case )是一系列操作的说明，当系统执行这些操作时，这些操作将为特定参与者(actor )生成可观测的、有价值的结果。
简单了解一下信息系统的用例：
系统为XX用户提供的功能
支持业务活动完成的计算机操作功能
用户和计算机之间完整、简短的交互(人机交互，一个窗口/页面) ) ) ) ) )。
一个例子持续时间短，目的明确，有始有终
另一位代表人物GDDSB(Alistaircockburn )认为：
用例(use case )是各种系统受益人的行为契约。 行为包括对象的活动、操作和对象之间的交互。 每个用例实际上都代表一个用户目标，根据三个目标级别对用例进行分层：摘要级别、用户目标级别和子功能级别，以有效地了解用例的粒度。
所有用例都构成了系统的用例模型。 用例模型完全描述了系统从外部可见的行为。
用例和用例模型的意义：
1 .用例是系统需求(主要是功能需求)的规范化描述，用例模型是面向对象分析的重要输入
2、用例图和用例事件流描述集中体现了系统责任
3、通过用例绘制交互图。 交互图是用例的具体表现，其实现是基于对象与对象之间的联系。
图书馆系统用例识别参与者(Actor)
参与者是在系统之外与系统交互的。
1、使用系统的个人。
谁负责提供、使用或删除信息？
谁使用功能？
2、连接到系统的外部硬件。
例如，控制建筑物内温度的通风系统不断从传感器获取温度信息，传感器是参加者。
3、与该系统通信的其他信息系统。
例如，在对自动柜员机系统建模的情况下，中央银行系统是其参与者。 银行卡系统是销售系统的参与者
区分参与者和DFD的外部实体
只有在执行系统功能时与信息系统实时交互的人才被视为参与者
外部实体是指数据的来源和去向，提供数据的人不一定执行系统功能
新生手动填写个人信息，教务人员统一将数据录入学籍系统。 教务员是参加者。
如果学生直接在网上提交个人信息，则认为学生是参与者。
http://www.Sina.com/(primary actor )区分主要参与者和次要参与者，是功能最强大、最主要的用户，可以直接从系统获得可衡量的价值。 33558 www.Sina.com/(secondary actor )的需求驱动用例表示的行为和功能，在用例中起到辅助支持作用。
用例分析的重点是找到主要参与者。
-例如，在图书馆借阅/归还的用例中，首先需要考虑谁直接使用此功能，谁经常与系统交互。 图书管理员是直接操作者，他们的需求和变化对用例的影响最大。 因此，图书管理员是主要参与者。
查看参与者
在UML中，参与者使用小人符号。
参与者泛化
在某些情况下，参与者的角色具有共性，或者通常一个角色可以具有另一个角色的所有行为。
-例如，在超级系统中，值班经理可以完全充当收银员，值班经理可以拥有退货、更改事务等权利。
-“子角色”(subrole )可以继承父角色)的所有行为。
角色泛化通用化： http://www.Sina.com /
用例用于说明功能需求。
一个用例是与事件对应的系统的软件功能。
每个用例至少与一个参与者相关，用例名称必须准确地表示参与者希望提供给系统的具体功能。
的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、泛化关系（不推荐）
如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。
用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。
父用例通常是抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完整的，这一点与包含关系扩展关系不同。
用例图元素