《第4章用例和用例图ppt课件》由会员分享，可在线阅读，更多相关《第4章用例和用例图ppt课件（51页珍藏版）》请在金锄头文库上搜索。
1、第4章用例和用例图 4 1用例和用例图的概念 用例模型的基本组成部分有用例 角色 或参与者 和系统 用例用于描述系统的功能 也就是从用户的角度来说 系统具体应包含哪些功能 帮助分析人员理解系统的行为 它是对系统功能的宏观的 整体的描述 一个完整的系统通常包含许多用例 每个用例具体说明应完成的功能 参与者是指那些与系统进行交互的外部实体 通常它是系统的一个用户 但它也可以是其它系统或硬件设备 总之凡是需要与系统进行交互的任何实体都可以称作参与者 用例往往必须向参与者传递一些数值 这些数值是参与者在系统中获得的信息 4 1用例和用例图的概念 使用用例的主要目的是 1 明确系统应具备什么功能 这些功
2、能是否满足客户的基本需求 并与系统开发人员达成一致 2 为系统的功能提供清晰一致的描述 用例模型应用于系统开发的整个过程 为后阶段的系统设计和开发工作打下良好的基础 3 为系统测试打下基础 可以用于验证最终实现的系统所完成的功能是否符合客户的最初需求 4 通过从需求的功能用例出发跟踪进入到系统中具体实现的类和方法 可以检查其是否正确 例如 通过下面这种方法可以简化对系统的修改和扩展 首先修改用例模型 针对受到影响的用例 找到相应的系统设计和实现部分 对其进行相应的修改即可 4 1用例和用例图的概念 用例图 UseCaseDiagram 是显示一组用例 参与者以及它们之间关系的一种图 用例图在U
3、ML中是非常特别的图形元素 它描述了用户希望如何使用一个系统 通过用例图可以知道谁将是系统相关的用户 他们希望系统提供什么样的服务 以及他们需要为系统提供的服务 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求 分析产品所需的功能和动态行为 用例图常用来对需求进行建模 用例图在系统的整个分析 设计和开发阶段是非常重要的 它的正确与否直接影响到客户对最终实现的产品的满意度 用例图被广泛使用在各种开发活动中 但它最常用于描述系统以及子系统 4 1用例和用例图的概念 图4 1用例图 4 1 1参与者 参与者 也可以称为角色 Actor 是系统外部的一个人或者物 它以某种方式参与了系统的执行
4、过程 参与者不是特指人 是指系统以外的 在使用系统或与系统交互中所扮演的角色 因此参与者可以是人 可以是事物 也可以是时间或其他系统等等 还有一点需要注意的是 参与者不是指人或事物本身 而是表示人或事物在系统中所扮演的角色 例如 张明是图书馆的管理员 他参与图书管理系统的交互 这时他既可以作为管理员这个角色参与管理 也可以作为借书者向图书馆借书 在这里张明扮演了两个角色 是两个不同的参与者 即管理员和借阅者 因此 在 图书管理系统 中 借阅者 和 系统管理员 都是参与者 4 1 1参与者 例4 1 客户给销售员发来传真订货 销售员下班前将当日订货单汇总输入系统 谁是系统的参与者 分析 根据参与
5、者的定义可知 此系统的参与者是销售员 4 1 1参与者 例4 2 在需求分析中常见的权限控制问题 一般的用户只可以使用一些常规的操作 如查询等 而管理员除了常规操作之外还需要进行一些系统管理工作 如一些关键数据的增加 删除 修改等 操作员既可以进行常规操作又可以进行一些配置操作 4 1 1参与者 例如 在 图书管理系统 中 可以认为 读者 是 学生读者 和 教师读者 的泛化 而 学生读者 还可以具体化为 本科生读者 和 研究生读者 同样 图书管理员 也是 采购员 编目员 及 借阅人员 的泛化 图4 3表示出了参与者之间的泛化关系 4 1 1参与者 图4 3图书管理系统参与者之间的泛化关系 4
6、1 2用例 需求获取 RequirementElicitation 是需求分析阶段的主体部分 其主要的工作就是要建立待开发系统的模型 而用例就是用于建立这种模型的最好方法 用例最初由IvarJackboson博士提出 后来被融合到UML的规范之中 成为描述需求的标准化体系 用例是代表系统中各个项目相关人员之间根据系统的行为所达成的契约 用例描述了在不同条件下 针对某一项目相关人员的请求 系统对其作出的响应 也就是说用例指的是对一组动作的描述 系统通过执行这些动作将对用例的参与者产生可以看到的结果 用来描述参与者可以感受到的系统服务或功能 4 1 2用例 例如 在图书管理系统中 用户可以进行 查
7、询图书的基本信息 借书 以及 还书 管理员可以对图书的基本信息进行管理 如 新增图书信息 修改图书信息 删除图书 等等操作 即这些操作都是系统提供的服务 功能 因此 这些都可以独立成为一个用例 执行这些操作的都是人 即参与者 用例在UML中通常用一个椭圆图形符号来表示 如图4 4所示 图4 4用例符号 4 1 2用例 例如 在文字处理程序中 置正文的字体为宋体 是一个用例 在图书管理系统中 新增图书信息 借书 和 还书 也是用例 在超市管理系统中的 进货 也是一个用例 如图4 5所示 在这里可以看出 用例可大可小 有的用例可能比较简单 而有的可能就很复杂 如 置正文的字体为宋体 这个用例就比较
8、简单 很容易实现 但是对于 进货 和 借书 这样的用例相对就比较复杂 可能需要花一些时间才能够实现 图4 5用例 4 1 3用例描述 从软件开发的角度 用例就是需求的文字性描述 主要是说明系统如何工作的功能性或行为性需求 用例图只是简单地用图形的方式描述了一下系统 实际上 用例是文本形式 不是图形 用例是作为人与人之间 尤其是没有受过专门培训的人员之间互相交流的一种手段 因此 编写用例的首选形式通常是简单的文本 因此对于每个用例 还需要有详细的说明 这样就可以让别人对这个系统有一个更加详细的了解 这时我们就需要写用例描述 4 2用例之间的可视化表示 用例除了与参与者有关联关系外 用例之间也存在
9、着一定的关系 如泛化关系 包含关系 扩展关系等 4 2 1包含关系 包含关系指的是两个用例之间的关系 其中一个用例 称为基本用例 baseusecase 的行为包含了另一个用例 称为包含用例 inclusionusecase 的行为 也就是说基本用例会用到包含用例 表示基本用例中重用包含用例中的步骤 在UML图中 使用带虚线箭头表示 并在线上标有 如图4 7所示 4 2 1包含关系 图4 7包含关系 4 2 2扩展关系 扩展 extend 关系的基本含义与泛化关系类似 extend关系是对基本用例的扩展 基本用例是一个完整的用例 即使没有子用例的参与 也可以完成一个完整的功能 extend的基
10、本用例中将存在一个扩展点 只有当扩展点被激活时 子用例才会被执行 在扩展关系中 对于扩展用例 extensionusecase 有更多的规则限制 即基本用例必须声明若干 扩展点 extensionpoint 而扩展用例只能在这些扩展点上增加新的行为和含义 扩展关系是从扩展用例到基本用例的关系 它说明扩展用例定义的行为如何插入到基本用例定义的行为中 也就是说 扩展用例并不在基本用例中显示 4 2 2扩展关系 图4 8扩展关系 4 2 3泛化关系 泛化关系指的是一般与特殊的关系 当多个用例共同拥有一种类似的结构和行为的时候 可以将它们的共性抽象成为父用例 其它的用例作为泛化关系中的子用例 在用例的
11、泛化关系中 子用例是父用例的一种特殊形式 子用例继承了父用例所有的结构 行为和关系 用例之间泛化关系如图4 9所示 4 2 3泛化关系 图4 9泛化关系 4 2 4分组关系 在一些用例图中 用例的数目可能很多 这时就需要把这些用例组织起来 这种情况在一个系统包含很多子系统时就会出现 另一种可能就是 当你按顺序和用户会谈 收集系统需求时 每个需求必须用一个单独的用例来表达 这时就需要某种方式来对这些需求进行分类 最直接的方法就是把相关的用例放在一个包中组织起来 一组用例可以放在一个文件夹中 4 3用例图建模技术及应用 在传统的软件开发方法和早期的面向对象开发方法中 描述系统的功能需求都是使用自然语言 这样的做法使得系统没有一个统一的格式 随意性很大 容易产生理解上的歧义和不准确性 使用UML的用例图模型来做系统的需求 这些问题就得到了很好地解决 在前面已经详细地介绍了用例 用例图以及相关的一些概念 下面将利用上面的基础知识 结合具体的案例 图书管理系统 根据系统的需求 创建用例图模型 4 3用例图建模技术及应用 1 识别出系统中的角色和用例 1 如何从系统中识别出角色获取系统用例首先要找出系统的角色 如何识别系统的角色 可以从系统要完成的业务中识别系统的角色
