用例分析与用例图.ppt

业务用例与系统用例 识别用例 识别用例 关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例（场景） 场景-----用例的实例 简洁：参与者使用系统达到目标 识别用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 可观测：用例止于系统边界 系统 描述交互，而不是内在的系统活动 结果值：有意义的目标 √ 业务功能，而非系统处理 系统执行：结果值由系统生成 系统需要处理的，由系统生成 参与者观测：用户观点而非系统观点 用户观点 系统观点 用例粒度 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度-1 把步骤当用例 把系统活动当用例 × √ × 用例粒度-2 × “四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 用例粒度-3 用例粒度-4 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 用例粒度-5 灵活处理CRUD 可以把包含复杂交互的路径独立出去形成用例 用例关系 Include 提取公共步骤，便于复用 Extend 分离扩展路径 Generalization 同一业务目的的不同技术实现 包含关系 包含关系1 包含关系2 某些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时，基用例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或操作调用 软 件 工 程 软 件 工 程 概 论 * 参与者：系统的使用者 用例：代表系统向使用者提供的服务 * 系统的存在是因为：参与者有一些需要使用它来满足的目标 * 用户可以看见的，是由系统生成的 下图显示了用例间的包含关系。在图书管理系统中，用例“删除书籍”和“修改书籍信息”与用例“图书查询”之间是一种包含关系。不管是删除书籍还是修改书籍信息，都必须先进行该书籍的查询工作。 有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。 * * 事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。 * 事实上，基础用例没有扩展也是完整的，一个扩展用例反而改变了基础用例的事件流。扩展用例的行为是否被执行要取决于主事件流中的判定点。如果特定条件发生，扩展用例的行为才被执行。值得注意的是扩展用例的事件流往往也可以抽象为基础用例的备选流。 * 在图书管理系统中，假设有一个基础用例“还书”，规定了一般情况下的还书流程。但是，如果读者所借书籍超期，在还书的时候是要交纳罚金的，这时基础用例“还书”不能描述超期情况下的还书流程。如果修改基础用例，可能会增加基础用例的复杂性，因此可以考虑在基础用例中添加扩展点，特定条件是超期，如果满足特定条件，将执行“交纳罚金”这个扩展用例。 用例分析 与用例图 回顾 需求工程的六个阶段 需求获取、需求分析与协商、系统建模、需求规约、需求确认、需求管理 需求分析的概念 需求的类型与怎样获取需求 需求分析过程 需求规格说明书（SRS） 主要内容 基于用例的分析与设计 业务用例与系统用例 用例与用例关系 小结与实验 前言之一 软件开发过程中常见的场景 你这做的是什么东西！ 这个做还不错，不过好像不是我想要的。 我们这很混乱，你这个系统应该把我们的所有问题全部解决掉！ “弱弱”地问：“您到底想要什么？” 前言之二 需求分析与管理—软件开发过程中的“永远的痛” 基于用例的分析与设计 以用例为中心组织需求 用例 可用性 可靠性 网络协议 业务规则 …… 硬件接口 界面约束 性能 基于UML的分析与设计 使用UML过程的基本特征是：用例驱动，以体系结构为中心，反复，渐增式。 用例包含了功能描述，它们将影响后面所有阶段及视图。 用户视图 用例图 实现