第4章用例视图.pptVIP

第4章 用例视图;;;;用例图 从系统外部来观察系统提供哪些服务或系统具有什么样的行为 优点 易于沟通 关注用户的目标，可以较准确地描述需求 用例图的元素 系统边界 用例 参与者 参与者、用例之间的关系;什么是参与者 系统外部 参与了用例的执行过程 参与者的类型 系统用户、外部系统、某些进程 如何确定参与者：P59 参与者的内部实现与用例无关 参与者之间的关系 ;用例解析 定义 用例实例、使用场景 用例是文本 用例仅表示功能性需求 ;P61;购买饮料 在客户选择并支付以后，自??售货机弹出饮料 定期检修 技师对自动售货机进行定期维护，使它能够保持良好的工作状态 修理 出现故障时，技师排除故障 放入货物 销售人员给自动售货机添加饮料;*;用例表示法 简述 详述：用例描述、用例叙述 用例执行过程的多样性与分类方法 主事件流（正常流、主成功场景） 这是用例描述最核心的部分，记载了整个用例正常的执行过程。 替代流（备选事件流） 如果期间有一些其他情况发生（小插曲），但仍不至于影响用例的成功执行 例外流（异常流） ;用例名称 简要说明 事件流 特殊需求 前置条件 后置条件 扩展点;使用肯定的陈述句 主语只能是Actor或系统 黑盒原则：只规定做什么，不追究如何做 替代流的编写方法 例外处理的编号 ;;参与者与用例之间的关系 是通信关系，即交互（交换信息） 用单向箭线表示Actor与UseCase的关系 启动者指向用例（主动） 用例指向支持者（被动） ;为什么要引入用例之间的关系 如果一个用例太复杂，将变得难于掌控与实现，因此需要将用例分解，来简化复杂度。 用例分解，然后通过用包含、扩展和泛化关系在小用例的基础上来构建复杂的用例。;安全会话和做交易这两个用例中都包含了验证密码这部分内容，它是一个行为序列（事件流），为了避免在这两个用例中重复地描述验证密码的行为序列，可以创建一个验证密码用例，然后在安全会话和做交易这两个用例中包含验证密码用例。;;P63,包含关系将一个用例合并到另一个用例的行为序列中。 UML表示 虚箭线指向包含用例，关系名：include 使用一：抽取公共用例 使用二：简化 ;;;扩展关系例;P64，扩展关系给用例（基用例）添加增量行为（扩展用例）。 扩展点：扩展点是基用例中的标记 说明在基本用例的某个位置（扩展点）时，如果条件满足，就会执行扩展用例 UML表示 虚箭线指向基用例，关系名：extend 扩展关系与替代流程 用替代流程表示可选的事件流是最简单的方法 只有在基用例不允许修改的情况下，使用扩展关系。;在基金模拟项目中，理财专员代客申购单笔基金时，并不是所有的申购都需要打印申购收执联，只有在投资人要求打印时，才执行。;;;比如“预定房间”或者“预定早餐”都有一套相同的服务规则，可以使用泛化描述。;;;;P62，父用例表示通用的行为序列，通过插入额外的步骤或细化步骤，子用例实例化父用例。 UML表示 与类的泛化一样;泛化与扩展 扩展事件流是临时附加到基用例事件流的某个位置上，是属于同一层的 泛化与包含 泛化和包含都是用于抽取用例的公共行为，但泛化关系要求父用例和子用例之间拥有“is-a -kind-of”关系，这样继承才有意义。 ;在线股票经纪人系统中有三种交易：交易债券、交易股票和交易期权，它们都有一些共同的执行步骤，如验证密码，但又有各自额外的步骤。;;生成订单;用例关系的作用 它只是组织和管理用例的一种方法 不影响需求，需求是通过编写用例描述来完成的，一定要分清重点 UseCase模型不是需求分析的全部 ;用例捕获需求的优势 强调了用户的目标和观点 简单通俗，便于用户参与 用例驱动的软件开发 用例的迭代 初始、细化、构造 从定义出发建模的步骤 从业务流程中识别系统用例 ;;用例的细化程度 围绕参与者的目标，以参与者要完成的任务为依据来划分或分解用例 系统执行用例将为参与者产生一个可观测的结果值 避免将用例的执行步骤识别为用例 ;你正在分析“在线旅行社系统”，遇到下面这些用例，使用泛化和包含关系绘制一张用例图。;请为图书馆工作人员的用例编写用例说明 借书处理、还书处理 选择一个编写用例说明;