第2章软件开发方法与技术(功能模型—用例图)分析.ppt

第2章 用例图 §2.1 用例图（Use-Case Diagram） §2. 2 参与者（Actor） §2．4 用例与事件流 §2．5 用例间的关系 §2．5 用例图的应用 * 用例图是参与者（Actor）所能观察到的描述系统功能视图，它 通过用例（Use-Case）来捕获系统的需求。 其中： 1.用例图描述了待开发系统的功能需求，是软件产品外部特性描 述的视图； 2.用例图是从用户的角度而不是从开发者的角度描述软件产品的 需求，分析产品所需的功能和动态行为； 说明：需求来源于问题域，需求的目的是把问题域中的“问题”提 炼成系统责任，用例图就是描述系统责任的良好工具。 ? 问题域：指被开发系统的应用领域，即在现实世界中这个系统所 涉及的业务范围。 ? 系统责任：指被开发系统应该具备的职能。即在计算机世界中这 个系统所涉及的业务范围。 3.它是由软件需求到最终实现的第一步，它驱动了需求分析之后 的各阶段的开发工作； 4.它是描述系统的动态模型，即是5个UML动态视图之一; 其中,5个UML动态视图是: “用例图”、“状态图”、“活动图”、“时序图”、“协作图” 5．它描述了一组用例、参与者以及它们之间的关系，因此用例图 包括以下3方面内容： (1) 用例（Use case） (2) 参与者（Actor） (3) 关系（Relationship ） ?关联关系（Association ） ?泛化关系（Generalization ） ?依赖关系（Dependence ） 如图： Actor UseCase Relationship 6.用例图中也可以有注释和约束，还可以有包(Package) 参与者 (Actor) 是指系统以外的，需要使用系统或与 系统交互的实体（如：人、设备、外部系统等） UML中参与者的表示形式： ActorName 说明： 1.在构造用例图时，为获取“用例”，首先要确定系统的 参与者（Actor），可以根据以下问题来寻找系统的 参与者： (1) 谁是系统的主要用户？ (4) 谁管理、维护系统？ (2) 谁从该系统获得信息？ (5) 与该系统交互的是什么系统？ (3) 谁向系统提供信息？ (6) 系统从那里获得信息？ 2.在确定“参与者”过程中，记住以下要点。 (1)参与者对于系统而言总是外部的，因此它们在你的 控制之外。 (2)参与者直接同系统交互，这可以帮助定义系统边界 (3)参与者表示人和事物与系统发生交互时所扮演的角 色，而不是特定的人或特定的事物。 (4) 一个人或事物在与系统发生交互时，可以同时或不 同时扮演多个角色。 (5) 每一个参与者需要有一个具有业务一样的名字。 (6) 每个参与者必须有简短的描述，从业务角度描述参 与者是什么。 §2. 3 用例（Use case） 用例（Use case）是参与者(Actor)可以感受到的一项系统责任或功能单元。 说明： 1.用例定义了系统责任和完整的功能，描述了参与者使 用系统所提供的一项完整功能时而与系统所进行的交 互过程（一段对话），该过程可用一组文字描述序列 来表达。 2.用例从建立模型的角度可描述如下： 用例=用例元素(图形符号)+事件流(文字描述序列) UML中用例元素表示为： 3.用例是对系统行为的动态描述，它可以促进开发人员 与用户沟通，理解正确的需求； 4.用例可以划分系统与外部实体的界限，是系统设计的 起点，是类、对象、操作的来源。 5.基于参与者，可以通过回答下述问题来帮助识别用例： (1) 每个参与者的任务是什么? (2) 有参与者将要创建、存储、改变、删除、或读取系 统中的信息吗? (3) 什么用例会创建、存储、改变、删除、或读取这个 信息？ (4) 参与者需要通知系统外部的突然变化吗? (5) 需要通知参与者系统中正在发生的事情吗? (6) 什么用例将支持和维护系统? 例：某图书馆开发一个图书管理系统，该系统要求实现下列功能： (1) 读者查询（直接通过外部终端进行） 读者查询图书，通过书的种类、出版社、书名、作者等方式查询；读者查询借阅图书情况，通过姓名和图书证号等方式查询。 (2) 读者借书（通过工作