第5章 UML用例图要点课件.ppt

《第5章 UML用例图要点课件.ppt》由会员分享，可在线阅读，更多相关《第5章 UML用例图要点课件.ppt（55页珍藏版）》请在三一办公上搜索。

1、信息系统分析、设计与开发方法,第5章 功能强大的对象建模工具UML,用例图,UML有三个基本构造块：事物、关系和图。 通过关系把多个事物连接在一起，构成了图。其中，图可视化地描绘了系统某一方面的特征。一个图只能反映系统中某个侧面和特征，多个图结合在一起可以反映系统的某些侧面和多个特征。 在UML 2.0中共定义了13种图，比UML 1.0新增了3种。,5.2.3 用例图,5.2 UML包含的内容,UML2.0的图型,用例图主要用于为系统的功能需求建模，它主要描述系统功能，也就是从外部用户的角度观察，系统应该完成哪些功能。 用例图可以帮助开发人员以一种可视化的方式理解系统的功能需求，是后续的系统

2、分析与设计工作的依据。 用例图是对系统功能的一个宏观描述，画好用例图是由软件需求到最终实现的第一步，也是最重要的一步。,5.2.3 用例图,5.2 UML包含的内容,类图与用例图,5.2.3 用例图,5.2 UML包含的内容,由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。用例和参与者之间的对应关系叫做通信关联，它表示参与者使用了系统中的哪些用例。,5.2.3 用例图,5.2 UML包含的内容,要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个参与者（表示一个系统用户）

3、，可绘制一个人形符号。,5.2.3 用例图,5.2 UML包含的内容,参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。如果不想强调对话中的主动与被动关系，可以使用不带箭头的线段。,5.2.3 用例图,5.2 UML包含的内容,进行用例建模时，所需要的用例图数量是根据系统的复杂度来衡量的。对于较复杂的大中型系统，可能会需要几张甚至几十张用例图，可以使用包来对其进行有效管理。,5.2.3 用例图,5.2 UML包含的内容,在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。注意：包、注释都不是用例图的基

4、本组成要素，但在用例建模过程中可能会用到它们。,5.2.3 用例图,5.2 UML包含的内容,用例图的作用用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。,5.2.3 用例图,5.2 UML包含的内容,2. 用例图的作用,用例图的作用用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成

5、各种功能的，系统对于我们来说就是一个黑箱子。用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用例图中得到对于被定义系统的一个总体印象。,5.2.3 用例图,5.2 UML包含的内容,用例图主要包括3个部分：用例（User Case）参与者（Actor）关系,5.2.3 用例图,5.2 UML包含的内容,参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。 注意：参与者可以是人，也可以是外部系统或其它设备。,5.2.3

6、用例图-参与者,5.2 UML包含的内容,5.2.1 参与者,参与者有三大类：第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每一个系统中。第二类参与者是其他的系统。这类位于程序边界之外的系统也是参与者。第三类参与者是一些可以运行的进程。如时间，当经过一定的时间触发系统中的某个事件时，时间就成了参与者。,5.2.3 用例图-参与者,5.2 UML包含的内容,（1）使用系统主要功能的人是谁（即主要角色）？（2）需要借助于系统完成日常工作的人是谁？（3）谁来维护和管理系统（次要角色），保证系统正常工作？（4）系统控制的硬件设备有哪些？（5）系统需要与哪些其它系统交互？其它系统包括计算机

7、系统，也包括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类，一类是启动该系统的系统，另一类是该系统要使用的系统。（6）对系统产生的结果感兴趣的人或事是哪些？,如何确定参与者？,5.2.3 用例图-参与者,5.2 UML包含的内容,参与者间的关系由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。在UML图中，使用带空心三角箭头的实线表示泛化关系。,5.2.3 用例图-参与者,5.2 UML包含的内容,5.2.1 参与者,通过泛化关系可以减少参与者和

8、用例之间的关联的次数，简化用例模型。,用例（Use case）是从系统外部可见的行为，是参与者可以感受到的系统服务或功能单元。它定义了系统是如何被参与者使用的，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 用例最大的优点是站在用户的角度上（从系统的外部）来描述系统的功能。它把系统当作一个黑箱子，并不关心系统内部是如何完成它所提供的功能，表达了整个系统对外部用户可见的行为。,5.2.3 用例图-用例,5.2 UML包含的内容,用例的特征：用例必须由某一个参与者触发激活后才能执行，即每个用例至少涉及一个参与者。用例表明的也是一个类，而不是某个具体实例。用例描述的是它代表

9、的功能的各个方面，包含了用例执行期间可能发生的各种情况。用例是一个完整的描述。若其被分解成多个小用例，则仅当所有的小用例完成后才代表整个用例的完成。,5.2.3 用例图-用例,5.2 UML包含的内容,怎么识别用例？任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。当找到参与者之后可以根据参与者确定系统的用例，主要是看各参与者如何使用系统，需要系统提供什么样的服务。,5.2.3 用例图-用例,5.2 UML包含的内容,可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功

10、能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件？,5.2.3 用例图-用例,5.2 UML包含的内容,注意：用例的主要目的是帮助人们了解系统功能，便于开发人员与用户之间的交流，所以确定用例的一个很重要的标准就是用例应该易于理解。对于同一个系统，不同的人对于参与者和用例可能会有不同的抽象，这就要求在多种方案中选出最好的一个。,5.2.3 用例图-用例,5.2 UML包含的内容,2. 用例的粒度,用例的粒度用例的粒

11、度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。如果用例的粒度很小，得到的用例数就会太多。会造成用例模型过大和设计困难大大提高。反之，如果用例的粒度很大，那么得到的用例数就会很少，不便于进一步的充分分析。,5.2.3 用例图-用例,5.2 UML包含的内容,2. 用例的粒度,用例的粒度比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。,5.2.3 用例图-用例,5.2 UML包含的内容,用例描述 用例图只

12、能告诉我们系统应具有的功能及参与者，让用户对系统有一个总体的认识。而没有说明用例的执行过程。 因此，对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解。 UML是一套标准的图形语言，其中只提出了13种图，没有将用例描述考虑在内，也当然没有任何标准的用例描述格式了。,5.2.3 用例图-用例,5.2 UML包含的内容,用例描述 对用例的描述，可以使用自然语言，活动图和伪代码，也可以使用用户自己定义的语言。无论用什么形式，所描述的动作序列应该足够清晰，是其他人员易于理解。 在用例中只需要描述参与者和系统彼此对对方做了那些事，不需要描述怎么做。 最简单的用例描述，

13、至少会包含一条“基本流程（basic course）” ，用来描述正常的使用。 再者，有时会包含数条“可选流程（alternative course）” 用来描述错误的、异常的状况。 除此之外，用例描述格式可自由制定。,5.2.3 用例图-用例,5.2 UML包含的内容,3. 用例规约,按照国家电子信息行业标准面向对象的软件系统建模规范第三部分：文档编制的要求，下面给出用于描述用例的模板。(1) 用例名：通常用一个表示用例意图的动词对用例进行命名(2) 简述：对用例的简单描述，可以使一句话或几句话。(3) 参与者：列举参与用例的所有参与者。(4) 包含：如果有的话，列举该用例所包含的用例和包含

14、它的用例。(5) 扩展：如果有的话，列举该用例可以扩展的用例和扩展它的用例。(6) 继承：如果有的话，列举该用例的一般用例和特殊用例。(7) 前置条件：描述启动该用例所必须具备的条件。例如，用户必须登录成功。,5.2 UML包含的内容,5.2.3 用例图-用例,3. 用例规约,(8) 细节（事件流）：详细的描述交互序列。细节要描述参与者与用例的一步步的交互，每一步要提供充分的内容，用于说明涉及哪些实体、针对每个实体做了什么事，以及这一步的结果。若用例较为复杂，要区分出基本流程和可选流程。 (9) 后置条件：描述在用例结束时确保成立的条件。执行用例的目的是要产生一些预计的值或者状态，用后置条件明

15、确地标识执行该用例后的预期结果。(10) 例外：描述该用例执行过程中可能出现的意外情况。例如，没有查找出期望的数据而导致的计算终止。对于每个例外，应该知道它所发生的环境和应该采取的措施。 (11) 限制：描述执行用例的限制。例如，为用例分配的资源可能受到限制。还有，要求用例中必须保持某种条件为真，违反这些条件就会引起错误。例如，公司职员数量要为正数。(12) 注释：提供该用例的附加信息。,5.2 UML包含的内容,5.2.3 用例图-用例,注意：描述用例时，不需要把上述每一项都写出来，可根据需要进行相应的取舍。,例如：图书借阅系统中用例“借书”的详细描述：用例名：借书参与者：管理员前置条件：一

16、个合法的管理员已经登录到这个系统事件流：见下页后置条件：如果是有效借书，在系统中保存借阅纪录，并修改图书库存量和读者借书数量。,5.2 UML包含的内容,5.2.3 用例图-用例,A. 输入读者编号； 提示超期未还的借阅记录；B. 输入图书编号； If 选择“确定” then If 读者状态无效 或 该书已注销 或 已借书数=可借书数 then 给出相应提示； Else 添加一条借书记录； “图书信息表”中“现有库存量”-1; “读者信息表”中“已借书数量”1; 提示执行情况； Endif 清空读者、图书编号等输入数据； Endif If 选择“重新输入” then 清空读者、图书编号等输入数

17、据； Endif If 选择“退出”then 返回上一级界面； Endif返回A.等待输入下一条；,“借书”用例事件流,用例之间的关系有包含(include)、扩展(extend)和类属(generalization)三种关系。 包含关系 包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 在UML中，包含关系是通过带箭头的虚线段加字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。,5.2.3 用例图-用例关系,5.2 UML包含的内容,1. 包含关系,在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个

18、新的用例。主要有两种情况需要用到包含关系：第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。,5.2 UML包含的内容,5.2.3 用例图-用例包含关系,5.2 UML包含的内容,5.2.3 用例图-用例包含关系,5.2.3 用例图-用例包含关系,5.2 UML包含的内容,1. 包含关系,使用包含关系的优点：提高了用例模型的可维护性，当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有与其有关的用例。不但可以避免在

19、多个用例中重复描述同一段行为，还可以避免在多个用例中对同一段行为描述的不一致。,5.2.3 用例图-用例包含关系,5.2 UML包含的内容,扩展关系在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。,5.2.3 用例图-用例扩展关系,5.2 UML包含的内容,5.2.3 用例图-用例扩展关系,5.2 UML包含的内容,5.2.3 用例图-用例扩展关系,5.2 UML包含的内容,扩展关系和包含关系的不同：基础用例的执行并不一定会涉及到扩展用例，扩展用例只有在满足一定条件下才会被执

20、行。而在包含关系中，当基础用例执行后，被包含用例是一定会被执行的。即使没有扩展用例，扩展关系中的基础用例本身也是完整的；而对于包含关系，基础用例在没有被包含用例的情况下就是不完整的存在。,5.2.3 用例图-用例扩展关系,5.2 UML包含的内容,3. 泛化关系,类属关系类属关系指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是类属（泛化）关系。在用例的类属关系中，子用例继承了父用例所有的结构、行为和关系子用例是父用例的一种特殊形式,子用例还可以添加、覆盖、改变继承的行为。,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,在UML中，用例的类属关系通过一个三角

21、箭头从子用例指向父用例来表示。当发现系统中有两个或者多个用例在行为、结构和目的方面存在共性时，就可以使用类属关系。用新的用例来描述这些共有部分，这个新的用例就是父用例。,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,类属关系的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,类属关系与包含关系异同：相同：都可用来复用多个用例中的公共行为。区别：在类属关系中，所有的子用例都有相似的目的和结构，它们是整体上的相似。在包含关系中，基础用例在目的上可以

22、完全不同，但它们都有一段相似的行为，它们的相似只是部分的相似。,5.2.3 用例图-用例类属关系,5.2 UML包含的内容,3. 用例规约,很多软件系统在一开始都需要登录，若用户登录成功，则可进入系统。下面以一个学生学籍管理系统为例，描述四种登录方案。为了简单起见，我们只针对登录、选课、查看学分这 三项功能建立用例模型。,例题,由于选课和查看学分都需要登录，故专门设立一个 “登录”用例。若登录成功，则可以选课，也可以查看学分。,例题-方案一,该方案的缺点：必须要了解系统的其它模块才能描述清楚用例“登录”向系统增减功能时，也要修改用例“登录”的描述。选课和查看学分并不是登录的组成部分，用例“登录

23、”描述中的后半部分是与登录无关的。,用用例“选课”和“查看学分”可扩展用例“登录”。,例题-方案二,该方案比方案一对 “登录”用例的描述要清楚一些，但仍未解决方案一种存在的问题。,让所有的相关用例都包含用例“登录”。,例题-方案三,该方案的缺点：学生执行系统的每项功能都要先登录，可能要进行多次登录。,用例“登录”完全独立于其它用例。,例题-方案四,若使用该方案，必须在用例“选课”和“查看学分”中指定前置条件：只有登录成功后才能执行。,网络的普及带给了人们更多的学习途径，随之用来管理远程网络教学的“远程网络教学系统”也诞生了。“远程网络教学系统”的功能需求包括： (1)学生登录网站后，可以浏览课

24、件、查找课件、下载课件、观看教学视频。 (2)教师登录网站后，可以上传课件、上传教学视频、发布教学心得、查看教学心得、修改教学心得。 (3)系统管理员负责对网站页面的维护，审核不法课件和不法教学信息，批准用户注册。,练习题,（1）学生需要登录“远程网络教学系统”后才能正常使用该系统所有功能。如果忘记密码，可以通过“找回密码”功能找回密码。登录后学生可以浏览课件、查找课件、下载课件、观看教学视频，请画出学生参与者的用例图。,练习题,（2）教师登录“远程网络教学系统”后可以上传课件、上传教学视频课件、发布教学心得、修改教学心得。如果忘记密码，可以通过“找回密码”功能找回密码。请画出教师参与者的用例图。,练习题,