第6章组织系统需求：用例描述和图.pptx

第6章 组织系统需求：用例描述和图;需求的分类;本章内容;6.1.1 用例的概念;Use Case的定义;用例的意义;用例是代表系统中各个相关人员之间就系统的行为所达成的契约。 例：在线银行系统的一些可能的用例： 浏览帐户余额 列出交易内容 划拨资金 支付帐款 登录 退出系统 编辑配置文件 买进证券 卖出证券;Use Case 驱动;9;10;用例建模的内容;1、识别参与者;区分参与者和外部实体;区分主要参与者和次要参与者;事件;参与者的表示;参与者的泛化;2、识别用例;用例的UML图形表示;区分用例和用例完成的步骤;区分业务用例和系统用例;客户提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。银行收到申请后，置于“申请档案”中，以申请号标识。 某公司内部工作岗位的提供：不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其他地区的HR领导???送消息，邀请员工们提出申请。然后，其他地区HR领导将招聘信息贴在公告板上。所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。;用例举例2;图书馆系统的用例图;进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。 扩展和包含关系就是用例模型中消除冗余的一种手段。 基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。;用例关系;基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。 包含用例是基本用例存在的必要条件 一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。 ;扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。 扩展用例的缺失不影响对基本用例的理解。 ;用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。 父用例通常是抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完整的，这一点与包含关系扩展关系不同。;30;用例的粒度;32;33;34;35;36;37;38;39;8.4.4 合理组织用例;错误的用例图举例;错误的用例图举例;课堂练习：用例建模;“旅店预定系统”初步用户需求;问题用例图1;问题用例图2;问题用例图3;1. 不恰当的“时间”参与者;2. 无效的参与者泛化;3. 错误的用例关系;3. 错误的用例关系;3. 错误的用例关系;4. “其他”用例？;5.参与者和用例间的关系;6. 用例粒度太小;用例规格描述常见错误;较为合理的用例图;8.4.2 用例的描述;1、用例规格说明（模板）Use Case Specification;2、用例与事件流（Flow of Activities）;3、用例与场景（Scenarios）;4、用例的前置条件和后置条件;用例的简要描述;对“取款”用例的非正式描述;对“取款”用例的完整描述;对“取款”用例的完整描述（续）;“借出图书”的用例描述;5、用例描述的双列格式;每个用例可绘制系统级顺序图;较为合理的用例规格说明1;较为合理的用例规格说明2;参与者：出纳员（主）、顾客 目标：完成一次商品销售和支付 触发条件：顾客带着所要购买的商品来到一个POS机终端 主事件流（主成功场景/基本路径）： 出纳员记录每项商品的信息 商品信息录入完毕后，系统计算商品价格总额 出纳员通知顾客商品总额 顾客支付现金，出纳员收取现金，计算找零并打印收据，系统记录交易情况 出纳员将收据交给顾客 备选事件流： 4a. 出纳员记录每项商品的信息顾客提供信用卡，请求信用卡授权服务机构验证信用卡，最后确认支付并记录支付信息 4a1. 信用卡支付请求被拒绝，要求顾客采用其他方式支付 4b. 顾客出示证件和支票，请求支票授权服务机构验证支票，最后确认支付，出纳员记录支票信息 4b1. 支票支付请求被拒绝，要求顾客采用其他方式支付;使用简单的语法，主语明确，语义易于理解 明确指出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制。 从俯视的角度来编写，指出参与者的动作，以及系统的响应，也就是第三者的角度。 显示过程向前推移，也就是每一步都有前进的感受。 显示执行者的意图而不是动作，否则不易理解用例的含义。不涉及界面细节，如按下XX按钮、输入x x键等。;包含合理的活动集，例如：挂号员提供挂号信息给系统，不用分别写各种信息。 使用“确认”、“验证”，而不是“检查是否”，“如果…否则”等，条件分支采用扩展场景。例如：系统确认读者借书资格有效。 ;9、春去春又回，新桃换旧符。在那桃花盛开的地方，在这醉人芬芳的季