软件工程用例模型.pptVIP

用例模型(use case modul) 在UML中，一个用例模型由若干个用例图(use case diagram)描述。 用例图是用于显示一组用例、参与者以及它们之间关系的图。 用例图的组成 用例（Use Case） 参与者（Actor） 关系（Relationship） 系统（System） 用例图的应用 用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和外部可见行为。 借助用例图，用户可以参与前期的系统分析与设计。 用例图对开发的意义 用例建模技术 识别参与者时需要思考的问题 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 例1：识别参与者 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 寻呼台系统用例图 参与者的泛化 参与者之间也可以象类一样存在泛化或者依赖关系。 识别用例时需要思考的问题 每个参与者的任务是什么 由参与者将要创建、存储、改变、删除或读取系统中的信息吗 什么用例会创建、存储、改变、删除、或读取这个信息 参与者需要通知系统外部的变化吗 需要通知参与者系统中正在发生的事情吗 什么用例将支持和维护系统 所有的功能需求都能被用例执行吗 识别用例的注意事项 注意事项： 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 命名规则 粒度大小 要点：用例止于系统边界 要点：用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 要点：用例的粒度(1) 最常犯错误：粒度过细，陷入功能分解。过细的粒度，一般都会导致技术语言的描述，而不再是业务语言。 把步骤当用例 把系统活动当用例 要点：用例的粒度(2) “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 要点：用例的粒度(2) 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 邮件服务器用例图 识别用例间的关系 用例之间的关系有三种：扩展关系、使用关系和泛化关系。 使用（Include） 即在一个用例中重用另一个用例中的步骤。 扩展关系（extend） 扩展用例是在原用例的基础上增加新的步骤序列形成的。 原用例被称为基用例（base use case）。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点（extension points）。 扩展关系 VS 包含关系 在扩展关系中，基用例不必知道扩展用例的任何细节，事实上基用例没有扩展也是完整的，只有特定的条件发生了，扩展用例的行为才被执行。 而包含关系则不同，没有被包含的用例，包含用例则不完整。 泛化关系（generalization） 例3：用例之间的关系 例4：识别用例关系 某电话公司决定开发一个管理所有客户信息的交互式网络系统。系统功能如下： 浏览客户信息：任何使用Internet的网络用户都可以浏览电话公司所有的客户信息（包括姓名、住址、电话号码等）。 登录：电话公司授予每个客户一个帐号。拥有授权帐号的客户可以登录系统。 修改个人信息：客户登录系统后，可以对个人信息进行修改。 删除客户信息：只有公司的管理人员才可以删除不再接受公司服务的客户的信息。 【问题】在需求分析阶段，采用用例图描述系统功能需求，如下图所示，请指出图中的A、B、C和D分别是哪个用例？ 电话公司客户管理系统用例图 电话公司客户管理系统用例图 用例的描述 三种常用形式 摘要 简介的一段式概要，通常用于主成功场景 非正式 非正式的段落格式。用几个段落覆盖非正式场景 详述 详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保障。 用例描述是文本形式的。 对用例摘要式描述 非正式形式的样例项目用例 详述形式的用例模板内容 详述形式的样例项目用例 整理后的用例图 用例的可视化描述 练习1： 网络在线售票订位系统的功能如下： 参与者：客户、系统操作人员、系统维护人员 各参与者的行为有： 1、客户：执行在线订位、查询目前订位状况、在线执行付费处理（信用卡付费）、在线个人定位查询。 2、系统操作人员：执行在线订位、查询目前