2_设计用例图的案例929教程讲解.ppt

UML用例图 功能模型 在面向对象方法学中，可以使用UML提供的用例图进行需求分析和建立功能模型。 也把用用例图建立起来的系统模型称为用例模型。 使用用例模型代替传统的功能说明，能更好地获取用户需求，它所回答的问题是“系统应该为每个用户做什么”。 用例模型描述的是外部行为者所理解的系统功能。 用例图 用例图源于Jacobson的OOSE方法，它通过用例来捕获系统的需求，再结合参与者进行系统功能需求的分析和设计。 用例图由参与者、用例、系统边界和关联组成。 用例和参与者之间的对应关系称为通信关联（Communication Association）。 使用用例图来描述系统，主要弄清楚三方面内容: 参与者——与系统交互的人或物。是向系统输入或系统输出的对象。用一个小人图形表示。 用例——系统的一个功能。用椭圆表示。 用例和参与者之间的关系——用带箭头的线段来描述。 箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。 用例图—参与者 参与者（Actor）是指存在于系统内部并直接与系统进行交互的实体。 参与者是用户相对系统而言所扮演的角色。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。 参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。 参与者虽然可以代表人或事物，但参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。 用例图—参与者 参与者的确定： 系统开发出来后，使用系统主要功能的是谁？ 谁需要借助系统来完成日常工作？ 系统需要从哪些人或其他系统中获取数据？ 系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统交互？ 系统是由谁来维护和管理的，以保证系统处于工作状态？ 系统控制的硬件设备有哪些？ 谁对本系统产生的结果感兴趣？ 注意寻找参与者时不要只考虑使用计算机的人！ 用例图—参与者 参与者间的关系 用例图—系统边界 系统边界是指系统与系统之间的界限。 系统与环境之间存在边界，子系统与其他子系统之间存在边界，子系统与整体系统之间也存在边界。 用例图中的系统边界用来表示正在建模系统的边界，边界内表示系统的组成部分，边界外表示系统的外部。 使用Rose画图并不画系统边界，采用Visio画图，用方框表示系统边界。 系统边界不一样，它的参与者就会发生很大变化。搞清系统边界才能更好地确定系统的参与者和用例。 用例图—用例 用例和参与者之间也有关系，这种关系属于关联关系，是双向的一对一关系，表明了哪个参与者与用例通信。 同一个系统由于用例的粒度不同，不同人会产生不同的用例模型。 用例图—用例 用例的识别 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是，参与者又是如何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 是否存在影响系统的外部事件？ 建立用例模型两种思路 1、找到每个Actor在系统中的功能，然后将所有Actor的功能合并为一张用例图。 ——见案例1 2、将一个大系统划分为几个子系统，为每个子系统分别建立用例图。 ——见案例2 原则 Somebody do something模式 1 单一场景 一个用例只为说明一件事 2 简单原则 简洁无歧义 3 唯一性 只关心如何 不关心能不能 活用include 和extends 建立用例模型案例1 详细用例建模过程举例：学生注册管理系统 识别参与者： 教师、学生、注册管理员、收费系统 确定用例： 与教师有关的用例 选择课程--选择所教的课程，并获得学生名册 登记成绩--在学期结束时，提交学生的课程成绩。 与学生有关的用例 注册课程--在学期开始进行选课注册，允许在一段时间内更改或删除，课程目录系统提供当前学期的所有可选课程列表 查看成绩单--学生可以查看以前学期的电子成绩单。 与注册管理员有关的用例 维护课程信息--在系统中增加、修改和删除课程信息； 维护学生信息--在系统中增加、修改和删除学生信息； 维护教师信息--在系统中增加、修改和删除教师信息。 关闭注册--删除少于3人的课程，并由付费系统通知学生缴费。 与安全性要求有关的用例 登录--使用此系统的人员需要进行登录，以验证其身份和权限。 请大家绘制 注意： 在用例图中，只能展示系统大的功能模块，对功能的细节部分无法展示，如“每个学生可以选择不超过4门课程，同时指定2门候选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消”这样的细节可以在用例图中为某个用例添加上“注释”。 建立用例模型案例2 详细用例建模过程举例：学生信息管理系统 识别参与者： 学生、教师、校领导、系统管理员 确定