1、第五章 用例图,学习内容,什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的关系 使用Rose创建用例的步骤说明,什么叫用例图,1. 用例图的含义,由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。 要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。,什么叫用例图,在用例建模中，为了更
2、加清楚的描述用例或者参与者，会使用到注释。,什么叫用例图,2. 用例图的作用 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。,用例图的构成要素,1. 参与者 参与者（Actor）是指存
3、在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。 在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。,用例图的构成要素,2. 参与者间的关系 由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。 泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。,用例图的构成要素,3. 系统边界 在项目开发过程中，边界
4、是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。 系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。,用例的重要元素,1. 识别用例 任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)
5、参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。,用例的重要元素,2. 用例的粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。,用例的重
6、要元素,比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。,我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。,用例的重要元素,3. 用例规约 对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。 每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情
7、况发生，称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。,用例之间的关系,1. 包含 包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分
8、。在UML中，包含关系是通过带箭头的虚线段加字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。,用例之间的关系,包含关系代表着基础用例会用到被包含用例，具体的讲就是将被包含用例的事件流插入到基础用例的事件流中。需要注意的是，包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)。,用例之间的关系,在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系： 第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽 象成为一个用例，然后让其他用例来包含这一用例。 第二，某一个用
9、例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。,用例之间的关系,2. 扩展 在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。 一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。,用例之间的关系,3. 泛化 用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。 在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。 子用例还可
10、以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。,用例之间的关系,泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。在这里，银行柜台存款和ATM机存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存款”和“ATM机存款”为子用例。,5.3.3用例图实例,例1 建立项目与资源管理系统的Use case图,系统的主要功能是：包括项目管理，资源管理和系统管理三大管理功能。 1. 项目管理包括项目的增加、删除、更新。 2. 资源管理包括对资源和技能的添加、删除和更新。 3.系统管理包括系统的启动和关闭，数据的存储和备份等
11、功能。,说明：技能表示人力资源。,1. 分析确定系统的执行者(角色),到确定,到确定,项目管理员、资源管理员、系统管理员、备份数据系统。,项目管理，资源管理和系统管理。,2. 确定用例,3. 对用例进行分解，画出下层的Use case图,角色描述模板,还应画出相应的执行者描述模板及用例描述模板。,对上层的用例进行分解,并将执行者分配到各层次的Use case图中。,用例名： 功能描述： 主要步骤： 相关用例： 相关信息：(优先级 性能,频度),用例描述模板,例1 项目与资源管理系统（PRMS）,Use Case图可以自顶而下不断精化，抽象出不同层次的Use Case图。,注：这里的“技能”是指
12、人力资源。,例1 项目与资源管理系统（PRMS）,应用举例例2医院病房监护系统,一、问题描述 为了对危重病人进行实时监护，随时了解病人病情，及时进行处理，建立病房监护系统。 病症监视器安置在每个病床，通过网络将病人的病症信号（组合）实时传送到中央监护系统进行分析处理。 在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。 系统根据医生的要求随时打印病人的病情报告，系统定期自动更新病历。,请对系统需求进行分析！,经过初步的需求分析，得到系统功能要求： 1. 监视病
13、员的病症（血压、体温、脉搏等） 2. 定时更新病历 3. 病员出现异常情况时报警。 4. 随机地产生某一病员的病情报告。,例2 医院病房监护系统,监视病情,更新病历,二、简单的需求分析说明 对“医院病房监护系统”进行分析，确定系统的主要功能如下： 1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。 2. 中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。 3. 当病症信号异常时，系统自动更新病历并打印病情报告。 4. 值班护士可以查看病情报告并进行打印。 5. 医生可以查看病情报告，要求打印病情报告，
14、也可以查看或要求打印病历。 6. 系统定期自动更新病历。,需求分析,1. 通过以下六个问题识别角色 (1)谁使用系统的主要功能？ (2)谁需要系统的支持以完成日常工作任务？ (3)谁负责维护，管理并保持系统正常运行？ (4)系统需要应付（或处理）哪些硬设备？ (5)系统需要和哪些外部系统交互？ (6)谁（或什么）对系统运行产生的结果（值）感兴趣？,需求分析,三、建立系统的用例模型,值班护士、医生、病人,值班护士、医生,系统管理员,监护器,网络,报警系统,标准病症信号库、病历库,同(2),通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。 角色
15、描述模板：,角色描述,. 识别用例,回答下面的问题： 与系统实现有关的主要问题是什么？ 系统需要哪些输入/输出？这些输入/输出从何而来？到 哪里去？ 执行者需要系统提供哪些功能？ 执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？,通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：,通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：,进一步将用例细化，即分解用例： 1. 中央监护 分解: a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。
16、 b 比较信号 将病人的病症信号与标准信号比较 。 c 报警 如果病症信号发生异常（即高于峰值），发出报警信号。 d 数据格式化 将处理后的数据格式化以便写入病历库 。 2. 病症监护 分解: e 信号采集 采集病人的病症信号。 f 模数转化 将采集来的模拟信号转化为数字信号。 g 信号数据组合 将采集到的脉搏，血压等信号数据组 合为一组信号数据。 h 采样频率改变 根据病人的情况改变监视器采样频率。,用例细化,3.提供标准病症信号 i（此用例不分解） 4. 病历管理 分解为：j 生成病历 k 查看病历 l 更新病历 m 打印病历 5. 病情报告管理 分解为：n 显示病情报告 在显示器上显示病
17、情 o 打印病情报告 在打印机打印病情报告,用例细化,给出细化的用例图,细化的用例图,练习一：请画出学生信息管理系统的用例图,“学生信息管理系统” 功能性需求包括以下内容： （1）系统管理员登录后可以对班级的基本信息进行增加、删除、修改、查询等操作。学校领导登录后可以对班级基本信息进行查询操作。 （2）教师登录后可以对学生的考试成绩进行录入、删除、修改、查询等操作。学生登录后可以对考试成绩进行查询操作。 （3）学生登录后可以了解所有选修课程的具体信息，可以根据自己的需要选择不同课程。系统管理员登录后可以增加、修改、查询、删除选修课程。 （4）系统管理员可以对账号进行创建、设置、查看、删除等操作
18、。,练习二 图书管理系统系统分析及用例图,图书管理系统能够为一定数量的借阅者提供服务。每个借阅者能够拥有唯一标识其存在的编号。图书馆向每一个借阅者发放图书证，图书证中包含每一个借阅者的编号和个人信息。系统通过一个单独的程序为借阅者提供服务，不需要管理人员的干预，这些服务包括提供查询图书信息、查询个人信息服务和预定图书服务等。 当借阅者需要借阅书籍、归还书籍时需要通过图书管理员进行，也就是说借阅者不直接与系统交互，而是图书管理员充当借阅者的代理与系统交互。当借阅者借阅的图书数量超过限制时，不运行借阅者再进行借阅。当借阅者借阅的图书超过一定的期限时，需要对其进行处罚。借阅图书时需要图书证作为凭据，归还时不需要。 系统管理员负责系统的管理维护工作，维护工作包括图书的添加、删除和修改，书目的添加和删除，借阅者的添加、删除和修改，并且系统管理员能够查询借阅者、图书和图书管理员的信息。 查询图书可以通过图书的名称或图书的ISBN/ISSN号进行查找,请简单分析需求，创建系统用例模型,
