第3章 用例图.ppt

第3章 用例图（Use case） 冯国奇 gqfeng@mail.neu.edu.cn 主要内容 概述 参与者 用例 习题案例 概述 用例图的含义 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的视图称为用例图。 概述 用例图的作用 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。 Use Case 对开发的意义 概述 用例图特点 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。 概述 用例图的组成 用例（Use Case） 参与者（Actor） 关系(Relationship) 在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。 参与者 参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他系统的理想化概念。 参与者可以是人,也可以是外部计算机系统和外部进程。 作为外部用户与系统发生交互作用，这是参与者的特征。 在系统的实际运作中，一个实际用户可能对应系统的多个参与者。 不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。 参与者 每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用（因此也与用例所在的系统或类发生了交互作用） 参与者的内部实现与用例是不相关的,参与者可以被一组定义它的状态的属性充分描述。 识别参与者的方法 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理）哪些硬设备 系统需要和哪些外部系统交互 谁（或什么）对系统运行产生的结果（值）感兴趣 时间、气温等内部外部条件 参与者可以非人 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。 这里的Actor 是小猪。 思考：识别参与者？ 寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑； 1、机票购买者通过登录网站购买机票，机票购买者就是actor 3、如果机票购买者通过呼叫中心的自动语音预订机票，那么呼叫中心就成了机票预订系统的一个actor 参与者 参与者之间也可以象类一样存在泛化或者依赖关系。 在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享。 用例 用例是外部可见的一个系统功能单元。 这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。 用例 在模型中,每个用例的执行独立于其他用例 虽然在具体执行一个用例功能时由于用例之间共享对象的缘故可能会造成本用例与其他用例之间有这样或那样的隐含的依赖关系。 每一个用例都是一个纵向的功能块，这个功能块的执行会和其他用例的执行发生混杂。 用例 用例用一个名字在里面的椭圆表示，用例和与它通信的参与者之间用实线连接。 用例 识别用例 任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 用例识别方法 可以通过以下问题来寻找用例： 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 什么用例将支持和维护系统？ 是否存在影响系统的外部事件。 识别用例的注意事项 注意事项： 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 要点：用例止于系统边界 由参与者发起 用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 要点：用例的粒度(1) 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度(2) 把步骤当用例 把系统活动当用例 要点：用例的粒度(3) “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？