uml基础教程第三章用例图课件

1、第三章 用例图第1页，共97页。本章导读知道参与者、用例和关系的概念了解用例的粒度和规约掌握参与者和用例的确定关系第2页，共97页。思考学习以下内容 什么是用例？ 创建、包含和扩展用例等的思想 如何开始一个用例分析？ 如何表示一个用例模型？ 如何可视化用例之间的关系？第3页，共97页。【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。用户对系统的使用方式决定了系统如何设计和构造。用例是能够帮助分析员和用户确定系统使用情况的UML组件。一组用例就是从用户的角度出发对如何使用系统的描述。可以认为用例是系统的一组使用场景。用例图的主要要素是参与者、用例和关联。第4页，共97页。第5页，共9

2、7页。 用例图主要用于描述系统的行为及各种功能之间的关系，是描述参与者（Actor）与用例以及用例与用例之间关系的图。 用例图从用户和外部系统的角度，分析和考察系统的行为，并通过参与者与系统之间的交互关系描述系统对外提供的功能特性，用例图用于描述系统与外部系统及用户之间的交互。 UML的用例图由参与者、用例及它们之间的关系组成，它的表达方式为： 用例图 = 参与者 + 用例 + 关系 Use Case Diagram = Actor + Use Case + Relationship第6页，共97页。3.1 用例图的构成用例图可以用于描述系统的功能性需求和系统功能的使用环境。用例图可视化地描述

3、了系统外部的使用者（抽象为参与者）和使用者使用系统时系统为这些使用者提供的一系列服务（抽象为用例），并清晰地描述了：参与者和参与者之间的泛化关系；用例和用例之间的包含关系、泛化关系、扩展关系；用例和参与者之间的关联关系第7页，共97页。要用在用例图上显示某个用例：使用人形符号绘制一个参与者；绘制一个椭圆表示用例，将用例的名称放在椭圆的中心或椭圆下面的中间位置；使用带箭头或不带箭头的线段来描述参与者和用例之间的关系。第8页，共97页。举例：饮料销售机 假设你现在正着手设计一台饮料销售机。为了获得用户的观点，你会见了许多可能的用户以了解这些用户将如何与这台机器交互。 饮料销售机的主要功能是允许一个

4、顾客购买一罐饮料，很可能用户立刻就能告诉你一些有关的场景（换句话说就是用例），你可以给这组场景加上一个标签“买饮料”。下面我们来考察这个用例中每一种可能的场景。第9页，共97页。（1）用例“买饮料” 这个用例的参与者是买饮料的顾客。顾客将钱插入销售机触发了这个用例的场景被执行，然后用户进行选择。如果一切顺利，销售机内至少还存储有一罐被选择的饮料，则销售机会自动弹出这种饮料给顾客。 上面的“买饮料”场景是唯一可描述的场景么？。显然，我们立即会想到还有其他的场景。顾客所要购买的饮料销售机中可能没有。顾客投入的钱数不是刚好等于购买饮料所需要的钱。应该如何设计饮料销售机来处理这些场景呢？第10页，共9

5、7页。 先看看没有所需的饮料这个场景，它是用例“买饮料”的另一场景。可以把这个场景看成是用例执行时的一条可选路径。用例是由顾客在销售机中插入钱币所发起的。然后客户进行一个选择，销售机中至少要有一罐选择的饮料，如果没有，销售机就给顾客提示一个信息，告诉顾客没有这种品牌的饮料。没有所需饮料的场景第11页，共97页。 理想情况下，顾客看到这条消息后会立即选择其它品牌的饮料。销售机也必须提供给顾客取回原来的钱的选项。这表示，销售机应给顾客两种选择：让顾客选择另一种饮料并且给顾客提供这种饮料（如果这种饮料还有存货的话）或者让顾客选择退钱。 该场景的前置条件是顾客感到口渴，后置条件是顾客得到一罐饮料或者顾

6、客投入的钱被退回。第12页，共97页。 另一种“缺货”的场景。“指定品牌的饮料售完”消息显示在机器上，直到对这台机器补充为止。在这种情况下，用户不再输入钱了。销售机的客户可能更喜欢第一种场景：如果顾客已经投了钱，应该让顾客做另外一种选择而不是要机器退钱。“缺货”的场景第13页，共97页。紧接着让我们来看看“付款数不正确”的这个场景。顾客按照通常的方式发起了这个用例，并进行了一个选择。假设这是机器中备有选择的饮料。如果机器中刚好存有适合的零钱，那么机器就会退还零钱并交付饮料。如果机器中没有保存零钱，它将退还钱，并显示一条消息提示用户投入适当的零钱。 前置条件和前面场景一样，后置条件是顾客得到一罐

7、饮料和找回零钱或者按原款归还钱。“付款数不正确”的场景第14页，共97页。 另一种可能是机器的储备零钱一旦用光，就会在机器上显示一条小子告诉用户需要投入适当的零钱。直到对这台机器补充零钱为止，这条消息才会消失。第15页，共97页。（2）其他用例 已经从用户的观点考察了饮料销售机。除了这些用户外，当然还有其他人加入。供货人负责为销售机提供饮料，收款人（可能与供货人是同一个人）负责定期收集销售机中的钱。这说明至少需要建立两个用例：“供货”和“取钱”，这些用例细节可以通过与供货人和收款人交谈来获得。第16页，共97页。考虑“供货”用例。供货人发起这个用例是由于某个时间间隔到期所引起的。供货代表打开销

8、售机拉出销售机前面的架子，在架子上补满各种品牌的饮料。销售员还要在机器中加零钱。然后他放好销售机的前端架子，并锁好机器。 这个用例的前置条件是一个时间间隔的流逝，后置条件是供货人在机器中放置了新的待售饮料。“供货”用例第17页，共97页。还有一个“取钱”用例，同样也是因为一段时间的流逝，收款人发起了这个用例。它的前期工作步骤与”供货“一样，也是打开销售机前端架子。收款人从机器中取出钱，然后按照”供货“步骤，放回架子锁好机器。 这个用例的前置条件也是时间间隔的流逝，后置条件是收款人收到了钱。“取钱”用例第18页，共97页。3.1.1 参与者 参与者是用例的启动者，参与者处于用例的外部并且能够初始

9、化一个用例，但它并不是所描述系统的一部分，它可能是人或其他外界系统。 参与者是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。 每个参与者都可以参与一个或多个用例，每个用例也可以有一个或多个参与者。用一个小人表示：第19页，共97页。 特别注意：参与者并不仅仅是指一个人，它代表的是一个集合。也就是说，参与者（角色）是一个群体概念，代表的是一类能使用某个功能的人或事，不能将角色的名字表示成角色的某个实例（如，张三）。 参与者是启动用例的前提条件，先发送消息给用例，初始化用例后，用例开始执行，在执行过程中，该用例也可能向一个或多个角色发送消息第20页，共97页。参与者可

10、以分为两种类型：（1）主要参与者和次要参与者。 主要参与者指的是执行系统主要功能的参与者，次要参与者指的是使用系统次要功能的参与者。 标识出主要参与者有利于找出系统的核心功能。（2）发起参与者和参加参与者 发起参与者发起用例的执行过程，一个用例只有一个发起参与者，可以有若干个参与者。 在用例中标识出发起参与者是一个有用的做法。第21页，共97页。通过回答一些问题，可以帮助建模者发现角色：使用系统主要功能的人是谁（即主要角色）？需要借助于系统完成日常工作的人是谁？谁来维护、管理系统（次要角色），保证系统正常工作？系统控制的硬件设备有哪些？系统需要与哪些其它系统交互？对系统产生的结果感兴趣的人或事

11、是哪些？第22页，共97页。3.1.2 用例 用例是参与者可感受到的系统服务或功能单元。它定义了系统如何被参与者使用，描述了参与者为了使用系统所提供的某一完整功能而与系统发生的对话。 用例是站在用户的角度上（从系统的外部）来描述系统的功能。 当系统有很多参与者时，用例是捕获系统需求最好的选择。 所有用例都应有名称，建议使用动名词为用例命名。 用例名可以包括任意数目的字母、数字和除冒号以外的大多数标点符号，用例的名字是一个能准确描述功能的动词短语或动词词组。第23页，共97页。用例具有3个明显的特征： （1）用例表明的是一个类，而不是某个具体的实例 （2）用例必须由某一个参与者触发激活后才能执行

12、，即每个用例至少应该涉及一个参与者 （3）用例是一个完整的描述椭圆来表示用例第24页，共97页。“回顾”饮料销售机在前面的分析中，我们获得了系统中有3个用例，分别是“Buy soda（买饮料）”、“Restock（供货）”、“Collect（收款）”。参与者有Customer（顾客）、Suppliers Representative（供货代表）和Collector（收款人）。第25页，共97页。跟踪场景中的步骤 每个用例就是一组场景的集合，而每个场景又是一个步骤序列。而这些步骤在上图中并没有表现出来。通常也不用附加注释来说明这些用例。因为如果对每个用例都附加注释进行说明，则布图就很混乱。那么如

13、何并在哪里记录和跟踪这些场景中的步骤呢？第26页，共97页。用例图通常是供客户和开发组参考的一部分。每个用例中的场景在文档中要描述下列内容：发起用例的参与者用例的假设条件用例中的前置条件场景中的步骤场景完成后的后置条件从用例中获益的参与者 要说明一个场景中的步骤，还可以使用UML活动图对场景进行描述。第27页，共97页。通过询问下列问题就可发现用例：角色需要从系统中获得哪种功能？角色需要做什么？角色需要读取、产生、删除、修改或存储系统中的某种信息吗？系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件（功能）能干些什么？如果用系统的新功能处理角色的日常工作是简单化，还提高了工

14、作效率？系统当前的这种实线方法要解决的问题是什么？第28页，共97页。补充：子系统（visual Paradigm有）用来展示系统的一部分功能，这部分功能联系紧密。第29页，共97页。3.1.3 关系用例图之间的关系分为3种：用例和用例之间的关系；参与者和参与者之间的关系；用例和参与者之间的关系。第30页，共97页。一、用例之间的关系 一般情况下，能够在用例之间抽象出包含、扩展和泛化这3种关系。 包含即在一个用例中重用另一个用例在步骤； 扩展允许通过对已有用例增加步骤创建一个新的用例； 泛化指一个用例继承了另一个用例。 有时也会有分组的关系，分组是一组用例的简单组织方式。第31页，共97页。1

15、.泛化 用例的泛化是指一个父用例可被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。 在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系。 子用例还可添加、覆盖、改变继承的行为 在UML中，用例的泛化关系是从子用例指向父用例的三角箭头来表示。 当发现系统中有两个或多个用例在行为、结构和目的方面存在共性时，就可用泛化关系。 这时，可用一个新的用例来描述这些共有部分，这个新的用例就是父用例。第32页，共97页。 假设正在对一台饮料机建模，这台饮料销售机允许顾客选择买一罐饮料或是买一杯饮料。在这种情况下，“Buy Soda”就是一个父用例，“Buy a can of soda”

16、和“Buy a cup of Soda”就是子用例。用例之间的泛化关系建模与类之间泛化关系建模方法相同，用一条带空心三角形箭头的实线从子用例指向父用例。第33页，共97页。例： 飞机订票系统中，预订飞机票有两种方式，一种是通过电话预订，另一种是通过网上预订。继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。【箭头指向】：指向父用例第34页，共97页。2. 扩展(Extend) 有时我们可通过对已有用例增加一些额外的步骤来建立新的用例。（指用例功能的延伸，相当于为基础用例提供一个附加功能

17、） 在“供货”这个用例中，在给机器补充新饮料的时候，供货代表注意到有些品牌的饮料销售的好，有些品牌的饮料销售不好。在这种情况下，他不是简单的把所有品牌的饮料补充给机器，而是把一些销售情况下不太好的饮料取出来，用销售情况好的饮料来代替它们。同时供货代表还要在机器前修改饮料品种的指示牌。 如果我们把上述的步骤加入到“供货”用例，我们将得到一个新的用例，不妨称它为“根据销售情况供货”。这个新用例是对原用例的扩展，这种技术叫做扩展用例。第35页，共97页。 在一定条件下，把新的行为加入到已有的用例中，获得的新用例称为扩展用例（Extension），原有的用例称为基础用例（Base），从扩展用例到基础用

18、例的关系就是扩展关系。 扩展是两个用例之间的关系，它使得每个用例可以通过扩展用例向基础用例中添加额外的行为来扩展基础用例的功能。 用例的扩展机制允许从一个基础用例开始开发一个复杂的系统，并且能够在不改变基础用例的前提下向基础用例中扩展更多的行为。第36页，共97页。 一个基础用例可以拥有一个或多个扩展用例，这些扩展用例可以一起使用。 在UML中，扩展关系通过带箭头的虚线段加来表示，箭头指向基础用例。 扩展关系往往用于处理异常或构件灵活的系统框架。扩展关系还可用于处理基础用例中的那些不易描述的问题。第37页，共97页。【箭头指向】：指向基础用例第38页，共97页。例：图书馆紫系统中管理用例图，其

19、中基础用例是“用户管理”，扩展用例是是“用户级别设置”。 一般情况下，只需执行“用户管理”用例即可。但是如果要设置用户级别，就不能执行用例的常规操作了，如果去修改“用户管理”用例，就又增加了系统的复杂性。 此时，可以在基础用例“用户管理”中增加插入点，这样如果想设置用户级别，就执行扩展用例。第39页，共97页。举例：饮料销售机 上面提及的“Restock”用例是另一个用例“Reatock according to sales（根据销售情况供货）”的基础。不是简单地把各种品牌的听装饮料以同样的数目补充个饮料机器，供货代表要注意到用销售情况好的品牌来代替销售情况不好的品牌，并进行相应的补充。 在“

20、Restock”用例中，新步骤（关注销量并安排添货）发生在供货代表打开机器准备向机器中补充饮料时。因此在这个例子中，扩展点是“before filling the compartments（补充饮料）”。第40页，共97页。 与包含关系相似，可视化扩展关系也是用一条依赖线（带箭头的虚线），沿线上加上一个用双尖括号扩起来的“extend”关键字。在基用例中，扩展点出现在“Extension point”（如果有多个扩展点，就是“Extension points”）的下方。第41页，共97页。例： 图书管理系统中，在一切顺利的情况下，只需要执行”还书“用例即可。但是，如果借书超期或者书有所破损，借

21、书用户就要交纳一定的罚金。第42页，共97页。3. 包含(Include)包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。 在“供货”和“取货”用例中，也许你会发现会有一些相同的步骤。两个用例都以打开机器为起始点，以关闭和锁好机器为终点。能不能消除用例中的重复步骤呢？ 可以。方法是从各个步骤序列中抽取出公共步骤形成一个每个用例都要使用的附加用例。可以将“开机”和“拉出饮料架”这两个步骤合并为一个叫做“打开销售机”的用例，将“放回架子”和“锁机器”合并为一个叫做“关闭销售机”的用例。第43页，共97页。 有了这两个新用例，用例“供货”就可以用例“打开销售机”为开始，供货代表通过前面步骤

22、，以用例“关闭销售机”结束。类似地，用例“收款”也以“打开销售机”为开始，进行前面的步骤，以关闭“销售机”结束。 如上所述，“供货”和“收款”这两个用例都包含了新的用例。这种技术被称为“包含用例”。 包含关系指用例可简单地包含其它用例具有的行为，并把它所包含的用例行为作为自己行为的一部分。 在UML中，包含关系是通过带箭头的虚线段加来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。第44页，共97页。箭头指向】：指向分解出来的功能用例第45页，共97页。 在处理包含关系时，具体的做法是把几个用例的公共部分单独抽象出来成为一个新的用例。主要有以下的两种情况需要用到包含关系：

23、 一个用例的功能过多、事件过于复杂时，可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。 当多个用例用到同一段行为时，则可把这段共同的行为单独抽象为一个用例，然后让其他用例来包含这一用例。第46页，共97页。例： 有一个资源网站，维护人员要对网站的资源进行维护，包括添加资源、修改资源和删除资源。其中，添加资源和修改资源后都要对新添加的资源和修改的资源进行预览，用来检查添加和修改操作是否正确完成。第47页，共97页。包含关系和扩展关系也存在较大的区别： 基础用例的执行并不一定会涉及扩展用例，扩展用例只有满足一定条件时才会被执行。 而在包含关系中，当基础用例执行后，被包含用例是一定

24、会被执行的。 在扩展关系中，基础用例提供了一个或多个插入点，扩展用例为这些插入点提供了需要插入的行为。 而在包含关系中，插入点只能有一个。 即使没有扩展用例，扩展关系中的基础用例本身是完整的。 而对于包含关系，基础用例在没有被包含用例的情况下就是不完整的存在。第48页，共97页。 我们来细看“Restock”和“Collect”用例。这两个用例都从开锁和拉开销售机的门开始，都以关门和上锁结束。第1步建立了“Expose the inside（打开销售机）”用例，并且第2步创建了“Unexpose the inside（关闭销售机）”用例。“Restock”和“Collect”两者都包含了这两个

25、新用例。 要表达用例的包含关系，可以使用类之间依赖关系的表示符号，也就是连接两个类之间的虚线，箭头指向被依赖的类。在线上要加一个关键字，也就是用双尖括号扩起来的“include”。第49页，共97页。分组 在一些用例图中，用例图的数目可能非常多，这时就需要组织这些用例。这种情况在一个系统包含很多个子系统时就会出现。另一种可能是，当你按顺序和用户会谈，收集系统需求时，每个需求必须用一个单独的用例来表达。 最直接的方法是把相关的用例放在一个包中组织起来。第50页，共97页。二、参与者之间的关系 参与者与参与者之间的关系主要是泛化关系。泛化关系的含义就是把某些参与者的共同行为提取出来表示通用行为。

26、在UML图中，使用带空心三角箭头的实线表示泛化关系，箭头指向超类参与者。 在需求分析中，常常遇到用户权限的问题第51页，共97页。就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。箭头指向】：指向父用例第52页，共97页。三、参与者和用例之间的关系 参与者和用例之间属于关联关系(Association)。关联关系是双向的一对一的关系，这种关系表明了哪个参与者与用例通信。 用例图中参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主

27、动发起者，箭头所指方是对话的被动接受者。 如果不想强调对话中的主动与被动关系，可以使用不带箭头的线段。第53页，共97页。参与者与用例之间的通信，任何一方都可发送或接受消息。箭头指向】：指向消息接收方第54页，共97页。包含(include)、扩展(extend)、泛化(Inheritance) 的区别条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。对extend而言，延伸用例并不包含基础用例的内容，基础用例也

28、不包含延伸用例的内容。对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；第55页，共97页。例子第56页，共97页。四、系统边界 系统边界是指系统与系统之间的边界，这里的系统可认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。 用例图中的系统边界用来表示正在建模系统的的边界。边界内表示系统的组成部分，边界外表示系统外部。Visio建模工具可画出。 在项目开发过程中，边界是很重要的概念。系统与环境之间存在边界，子系统与其他子系统之间存在边界，子系统与整体系统之间存在边界。第57页，共97页。3.2 确定参与者 在获取用例前首先要确定系统的参与者

29、，确定参与者可从几方面来考虑，如书第44页 确定参与者时要注意几个问题，如书第44页所述。第58页，共97页。3.3 确定用例 确定用例的最好方法是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 当找到参与者之后，就可以根据参与者来确定系统的用例，主要是看各参与者如何使用系统，需要系统提供什么样的服务。第59页，共97页。3.4 用例的粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能就越多，反之则包含的功能越少。用例的粒度对于用例模型来说很重要。 在确定用例粒度的时候，应该根据系统具体问题具体分析。当大致确定用例个数后，就可以很容易确定用例粒

30、度的大小。第60页，共97页。3.5 用例规约 有时也要对每一个用例还需要有详细的描述信息，以便让其他人对于整个系统有更加详细的了解，这些信息包含在用例规约之中。 用例模型是由用例图和每个用例的详细描述用例规约所组成的。第61页，共97页。每个用例的用例规约应包含以下内容：（1）简要说明 对用例作用和目的的简要描述（2）事件流 包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。备选流描述的是用例执行过程中可能发生的异常和偶尔发生的情况。（3）用例场景 同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景。也可以说用例场景就是用例的实例。第62页，共97

31、页。（4）特殊需求 指的是一个用例的非功能性需求和设计约束。非功能性需求包括可靠性、性能、可用性和可扩展性等。设计约束可以包括开发工具、操作系统及环境、兼容性。（5）前置条件 执行用例之前系统必须所处的状态。 （6）后置条件 用例执行完毕后系统可能处于的一组状态。第63页，共97页。运用用例模型举例(网上论坛)一个基本的网上论坛系统，大致有如下的流程： 1、用户（一般为游客或注册会员）登录进入论坛，就某个帖子的主题展开讨论； 通过发帖功能发布新的主题； 通过回帖功能回复已有的主题； 通过搜索功能查找已有的主题； 2、 论坛管理员通过管理功能创建、编辑、删除论坛的板块；管理注册用户和管理帖子。第

32、64页，共97页。运用用例模型举例(网上论坛)一、理解领域 论坛的用户主要分为三种： 普通用户即游客； 论坛的注册会员； 论坛的管理员。 三者的身份不同，权限不同，所以具体的功能需求也不同。第65页，共97页。对普通用户来说，需要具有以下的两个功能：（1）无须注册即可以浏览论坛的信息，系统提供论坛文章的查询和阅读功能，即提供对应文章的标题信息以及详细内容。 （2）如果要想对某个主题发帖和回复，则该用户必须先注册成为论坛注册的会员。系统提供新会员的注册功能，在用户输入个人信息后，经检查注册信息有效后，将注册会员的信息保存到相应的数据库中。第66页，共97页。 对于注册会员，除了普通用户所有的功能

33、，还拥有以下功能 （1）要想针对主题发帖或回复必须是登录的注册用户。无论在进入论坛首页时还是在发帖和回帖时，进行登录都是可以的。注册会员在登录页面中要输入注册的用户账号和密码，通过身份验证才能获得发帖和回复的权限。 （2）注册会员可以针对某一主题发表帖子（文章）和修改发帖的内容。 （3）注册会员能够对某一个主图展开讨论，发表意见，并进行回复。 （4）注册会员可以修改自己的个人会员信息、修改密码、找回密码和注销。第67页，共97页。 对于论坛管理员来说，其功能范围包括以下内容： （1） 当网上论坛会员注册后，系统会在数据库中加入会员的资料，包括会员名称、会员密码、会员E-mail等个人信息。论坛

34、管理员对会员资料进行管理，可查看用户的基本信息、删除该用户的信息、修改会员的积分和排行等。 （2）根据不同的讨论内容，论坛管理员将整个讨论区划分成不同的板块，会员可以选择进入不同的讨论区，允许管理者对版块进行调整，删除不必要的版块，修改版块的名称、类型和数量，同时提供不同讨论区中包括文章数量的统计功能。 （3）论坛管理员能够对会员发表的帖子进行修改、删除内容反动或不健康的帖子、转移/指定/设置精华帖，控制帖子的点击率等操作。第68页，共97页。可构建出网上论坛的参与者包含以下4种：（1）用户。 泛指所有使用网上论坛系统的人，是专门抽象出来的一个参与者。（2）普通用户。 也就是游客，没有在论坛中

35、进行注册的用户，无权发帖和回帖，仅能浏览论坛文章。（3）注册会员。 已经注册成为论坛会员的用户，登录论坛后即可拥有发帖和回帖的权限。 （4）管理员。 拥有对本论坛进行设置管理、会员管理、板块管理、帖子管理和用户管理的权限。二、理解用户第69页，共97页。三、理解用例对普通用户来说，可通过本系统进行如下活动： 在网上论坛中进行注册成为注册会员。 在论坛中查询帖子（文章）。 在论坛中浏览帖子的具体内容。第70页，共97页。 对于注册会员，除了普通用户所有的功能，还可进行以下活动：登录网上论坛。在论坛中发帖和回复贴子，包括修改发帖的内容。修改个人注册信息，包括修改登录密码。在忘记登录密码时，可以找回

36、该密码。可以在线注销登录。第71页，共97页。对于论坛管理员，可以通过本系统进行如下的活动：对论坛会员进行管理，包括删除会员、设置会员等级、查询会员信息、添加会员等。对论坛的帖子进行管理，包括帖子置顶、设置精华贴、删除帖子、修改帖子等。对论坛板块分类进行管理，包括添加板块和删除板块等。登录到BBS网上论坛。第72页，共97页。第73页，共97页。 思考题1：1、发起一个用例的实体被称为什么？2、包含用例是什么含义？3、扩展用例是什么含义？4、用例和场景是同一概念么？第74页，共97页。思考题2系统管理员主要职责是管理用户、修改所有用户的密码、管理用户的权限，还可以浏览所有用户的信息。第75页，

37、共97页。思考题3根据如下关于电梯控制的问题描述，绘制一个用例图 每部电梯都有楼层按钮，每一楼层有一组。乘坐电梯的人可以按下楼按钮，按钮被按下时指示灯会闪亮，然后通知电梯运行到指定的楼层。等电梯到达指定楼层时，按钮停止指示灯闪亮。乘客在必要时可以按下紧急求助按钮，该按钮会自动发出求救信号。技术员可以通过一个控制按键激活或终止电梯的楼层按钮。出于安全方面的考虑，只有保安人员可以通过一个控制键打开地下室的电梯楼层按钮。所有电梯都是通过大厅前台的一个控制中心控制的。第76页，共97页。课后练习题画出银行取款过程的用例图。问题描述为：储户用存折取款，首先填写取款单，根据“ 银行卡”中的信息检验取款单与

38、存折，如有问题，将问题反馈给储户，否则，登录“储户存款数据库”，修改相应数据，并更新“银行卡”，同时发出付款通知，出纳向储户付款。第77页，共97页。实例讲解（一）建立项目与资源管理系统的用例图。 系统的主要功能是：项目管理、资源管理和系统管理。项目管理包括项目的增加、删除、更新等功能。资源管理包括对资源和技能的添加、删除和更新、系统管理包括系统的启动和关闭，数据的存储和备份等功能。第78页，共97页。 实例2 医院病房监护系统一、问题描述 为了对危重病人进行实时监护，随时了解病人病情，及时进行处理，建立病房监护系统。病症监视器安置在每个病床，通过网络将病人的病症信号（组合）实时传送到中央监护

39、系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统定期自动更新病历。第79页，共97页。请对系统需求进行分析！经过初步的需求分析，得到系统功能要求：1. 监视病员的病症（血压、体温、脉搏等）2. 定时更新病历3. 病员出现异常情况时报警。4. 随机地产生某一病员的病情报告。产生病情报告监视病情更新病历第80页，共97页。二、简单的需求分析说明对“医院病房监护系统”进行分析，确定系统的主要功能如下：

40、1. 病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。2. 中央监护系统将病人的病症信号分解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。3. 当病症信号异常时，系统自动更新病历并打印病情报告。4. 值班护士可以查看病情报告并进行打印。5. 医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。6. 系统定期自动更新病历。需求分析第81页，共97页。1. 通过以下6个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些

41、硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？三、建立系统的用例模型值班护士、医生、病人值班护士、医生系统管理员监护器,网络,报警系统标准病症信号库、病历库同(2)第82页，共97页。通过回答这6个问题以后，再进一步分析可以识别出本系统的4个角色：值班护士，医生，病人，标准病症信号库。角色描述模板：角色：病 人角色职责：提供病症信号角色职责识别：负责生成、实时提供各种病症信号。角色：值班护士角色职责：负责监视病人的病情变化角色职责识别： (1)使用系统主要功能 (2)对系统运行结果感兴趣角色:标准病症信号库角色职责：负责向系统提供病症信号的正常值

42、角色职责识别： (1)负责保持系统正常运行 (2)与系统交互角色：医 生角色职责：对病人负责，负责处理病情的变化角色职责识别： (1)需要系统支持以完成其日常工作 (2)对系统运行结果感兴趣第83页，共97页。. 识别用例回答下面的问题： 与系统实现有关的主要问题是什么？ 系统需要哪些输入/输出？这些输入/输出从何而来？到 哪里去？ 执行者需要系统提供哪些功能？ 执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？通过分析可以初步识别出系统的用例为： 中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。第84页，共97页。进一步将用例细化，即分解用例：1. 中央监护 分解:

43、a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。 b 比较信号 将病人的病症信号与标准信号比较 。 c 报警 如果病症信号发生异常（即高于峰值），发出报警信号。 d 数据格式化 将处理后的数据格式化以便写入病历库 。2. 病症监护 分解: e 信号采集 采集病人的病症信号。 f 模数转换 将采集来的模拟信号转换为数字信号。 g 信号数据组合 将采集到的脉搏，血压等信号数据组 合为一组信号数据。 h 采样频率改变 根据病人的情况改变监视器采样频率用例细化第85页，共97页。3.提供标准病症信号 i（此用例不分解）4. 病历管理 分解为：j 生成病历。将各种病症符号经过格

44、式化后，加上时间戳，存入病历库。k 查看病历。医生随时根据需要在计算机屏幕上查看病历。l 更新病历 。定时清理病历库，更新病历。m 打印病历。随时打印病历，作为医生诊断依据。5. 病情报告管理 分解为：n 显示病情报告 在显示器上显示病情o 打印病情报告 在打印机打印病情报告用例细化第86页，共97页。给出细化的用例图细化的用例图病人模数转化数据格式化值班护士报警信号采集比较信号标准病症信号库 医生信号数据组合采样频率改变提供标准病症信号生成病历查看病历更新病历打印病历显示病情报告打印病情报告分解信号第87页，共97页。用例名： 中 央 监 视执行者： 值班护士、医生目标： 对病人的病症信号进

45、行监测、处理，超过极限报警。功能描述：1.分解信号：将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。2.比较信号：将病人的病症信号与标准信号比较 。3.报警：如果病症信号发生异常（即高于峰值），发出报警信号。4.数据格式化：将处理后的数据格式化以便写入病历库 。其他非功能需求: 高可靠性、实时性主要步骤：按设定频率连续接收来自各病人的病症信号，并进行分解。将病人的病症信号与专家系统（标准病症信号库）中的标准信号进行比较判断是否超过极限值。若超过极限值，进行报警，并及时更新病历和打印病情报告。相关用例：病症监护、提供标准病症信号、病历管理、病情报告管理。相关信息：(优先级、性能、频执行率)：优先级：报警处理具有最高优先级3,一般病历管理为1,其他为2.性能：实时性、高可靠性频执行率：根据病情严重程度 1230次/小时用例“中央监护”描述模板 第88页，共97页。 实例讲解3 超市信息管理系统根据需求分析，系统包括