05-需求技巧.pptVIP

用例图 【例】为了更清晰地描述包含与被包含关系，在描述用例的基本事件流中，只需引用被包含用例即可，如用例基本流描述的第8步： 用例名称：查询帐户余额 基本流 用户插入信用卡 系统读取信用卡信息 用户输入密码 系统验证密码合法性 用户选择查询 系统查询帐号余额 用户查看帐号余额 包含用例“打印回执” 退出系统，用户取回信用卡 用例图 扩展(extend)，扩展（extend）关系如下图所示，基础用例中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例（Extension）的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 用例图 【例】对于电话业务，可以在打电话业务上扩展出一些增值业务如：呼叫等待和呼叫转移，而这2个用例在打电话过程中并不一定会被使用。可以用扩展关系将这些业务的用例模型描述如图。 用例图 也可以将打电话用例按下面的文字进行描述： 用例名称：打电话 基本流： 用户拔号 建立通话链路 通话 挂机 扩展点：“增值业务”扩展点在基本流步骤1扩展出来 用例名称：呼叫等待 该用例在“增值业务”扩展点上扩展出来，它扩展了打电话用例。 基本流： 如果应答方正忙，系统用铃声提示应答方并保持拔号呼叫。 用例名称：呼叫转移 该用例在“增值业务”扩展点上扩展出来，它扩展了打电话用例。 基本流： 如果应答方无应答，按应答方设置的方式转移呼叫。 用例图 泛化，泛化又称为继承，当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。 用例图 【例】执行交易是一种交易抽象，执行行证券交易都是一种特殊的交易形式，用例图如图 用例图 用例泛化关系中的事件流如下： 用例名称：执行交易 基本流： 用户登录。 系统验证用户身份。 用户选择交易。 系统展示交易类型。 用户选择交易类型。 系统展示用户的可用帐号。 用户选择帐号。 系统执行交易。 系统显示交易结果。 用例名称:执行证券交易 该用户是执行交易用例的一个子用例。 基本流： 用户登录。 系统验证用户身份。 用户选择交易。 系统展示交易类型。 用户选择交易类型。 系统展示用户的可用帐号。 用户选择帐号。 系统执行交易，根据用户选择的交易类型，系统分别执行定价买入、定价买出…。 系统显示交易结果，除父用例中的操作步骤外，系统计算该用户的帐号平衡情况。 用例图 用例规约。用例图是立足用户场景的描述，为具体的需求提供了上下文信息，是用户与开发人员沟通的纽带。用例图只能使它的读者快速、大概地了解整个系统的需求，并不能准确、详尽地表达用户场景，为了弥补用例图的不足，必须引用另外的工件来进一步细化，它叫《用例规约》。用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。 用例图 1、基本流，基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。建议用以下格式来描述基本流： 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述：参与者向系统提交了什么信息；系统对参与者提交的信息有什么样的响应。 用例图 【例】火车票订购管理系统中申请订票用例的基本流如下： 用例名称：申请订票 火车票订购管理系统中，申请订票是整个系统工作流程的第一步，它提供学生在线提交订票信息，当火车票订购管理人员得到这些订票信息后才能进行下一步的工作安排。 参与者：学生。 基本流： 参与者申请订票。 系统展示申请订票界面。 参与者填写火车票预定信息(包括：学号[学号只能是长度为9位的数字]、姓名[不允许出现数字或特殊字符]、联系方式[数字，最大长度为13]、预定日期[日期格式：如2010-05-25]、目的地[只允许汉字]、车次[由字母和数字组成且最大长度为5位]、车票张数[只能为数字]、是否服从调配) 。 参与者请求提交预定火车票信息。 系统保存预定火车票信息。 用例图 除了使用文本化方式描述用例外，还可以使用活动图描述用例，如图： 用例图 2、备选流，备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在