用例模型.pptVIP

—用例图 需求模型—用例图 5.1 需求分析 5.2 用例图的基本概念 5.3 用例图中的关系 5.4 基于用例需求分析的建议 5.5 实例——网上选课系统的用例图 5.1 需求分析 面向对象的需求分析：定义用例的工作成为需求分析。 需求分析旨在建立系统的需求模型，通过用例图可视化表示。系统分析旨在建立系统的基本模型，既类图，必要时可以用其他图作为辅助模型。 需求分析是系统分析的基础，通常在系统分析前进行。 5.1 需求分析 面向对象需求分析的基本思路 发现所有的参与者 发现参与者所使用系统的每一项功能 把对每一项功能的使用情况都用用例表示出来，形成用例图。 5.2 用例图的基本概念 5.2.1 参与者（Actor） 5.2.2 用例（Use Case） 5.2.3 事件流 5.2.1 参与者(Actor) 参与者是在系统之外于系统进行交互的任何事物。参与者触发系统某项功能的执行(通过向系统输入某些信息，或请求系统输出某些信息)。 最常见的参与者 人（操作人员或系统的服务对象） 设备（监控系统的摄像头等信息采集器） 外系统 5.2.1 参与者(Actor) 如何发现参与者 谁要使用系统 使用系统哪部分 系统使谁受益 谁向系统提供输入 谁维护系统 系统使用的外部资源 与哪些其他系统交互 5.2.1 参与者(Actor) 参与者的特点 系统外部的一个实体 参与用例的执行过程 通过向系统输入或请求系统输入某些事件来触发系统的执行 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例 5.2.1 参与者(Actor) 参与者之间的关系 5.2.2 用例(Use Case) 用例(use case):是对系统某个功能的一组动作序列的描述，系统执行这些动作序列将产生一个对某个特定的参与者有特定价值的结果。用例表示系统外部可见的功能单元。 5.2.2 用例(Use Case) 如何发现用例：发现用例要和发现参与者结合进行。 参与者向系统请求什么功能 参与者需要修改、读取、创建、修改、撤销或存储系统的某些信息吗？ 系统状态改变时需要通知参与者吗？状态的改变代表了什么功能？ 影响系统的外部事件，哪个参与者通知系统 是否所有的用例都被发现了 5.2.3 事件流 事件流是系统完成需求行为的事件描述，应尽量写的详细。事件流通常包括4部分： 简要说明 前置条件 主事件流和异常事件流（错误流） 事后条件（并不是每个用例都有） 5.3 用例图中的关系 参与者和用例的关系 关联 用例和用例的关系 依赖 泛化 参与者和用例—关联 此处的关联表示的一条通信途径，存在于参与者和用例之间，提供用例和参与者之间的通信途径。 关联的方向，表示谁启动了通信 参与者和用例—关联 关联关系 表示 工具箱中： 模型图中：一条直线或者一条带箭头的直线 关联命名 一个动词或者一个动词短语，用于指明关系的类型或者目的。 用例间的关系 依赖关系 泛化 依赖关系 定义 存在于两个模型要素之间的一种使用关系，其中一个模型要素的改变将影响另一个模型要素 表示方法 工具箱和模型图中均表示为一个带箭头的虚线 画图时，拖动鼠标从客户到提供者画出关联关系 依赖关系 依赖的两种重要衍型 延伸(extends)，表明一个用例中的行为延伸了另一个用例中的行为，前者称为延伸用例，后者称为基用例。 包含(include)，表明一个用例中定义的行为包含了另一个用例中定义的行为。 依赖关系 依赖的两种重要衍型 延伸(extends) 依赖关系 依赖的两种重要衍型 包含(include) ② 泛化 用例之间的泛化关系 参与者之间的泛化关系 5.4 基于用例需求分析 最重要的工作就是对用例的描述 不需要过分深入系统内部细节 判断一个用例是否复杂的方法：能不能找到参与者。 运用最主要的概念(活动者、用例、2种关系) 用例的局限性 5.5 实例—网上选课系统的用例图 * 建立需求模型 关联关系表示通信途径 include * * * * *