用例和用例图讲课教案

1、用例和用例图4.1.1 用例 Use Case 系统、子系统或类与外部参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。 简单理解为用例就是系统的功能。 用例分析可以认为是对系统功能的分解。 用例是代表系统中各个项目相关人员之间根据系统的行为用例是代表系统中各个项目相关人员之间根据系统的行为所达成的契约。用例描述了在不同条件下，针对某一项目所达成的契约。用例描述了在不同条件下，针对某一项目相关人员的请求，系统对其作出的响应。也就是说用例指相关人员的请求，系统对其作出的响应。也就是说用例指的是对一组动作的描述，系统通过执行这些动作将对用例的是对一组动作的描述，系统通过执行这些动作

2、将对用例的参与者产生可以看到的结果。用来描述参与者可以感受的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服务或功能。到的系统服务或功能。 4.1.1 用例 例如，在图书管理系统中，用户可以进行“查询图书的基本信息”，“借书”以及“还书”，管理员可以对图书的基本信息进行管理，如“新增图书信息”、“修改图书信息”，“删除图书”等等操作。即这些操作都是系统提供的服务（功能），因此，这些都可以独立成为一个用例。执行这些操作的都是人（即参与者）。 用例在UML中通常用一个椭圆图形符号来表示。如图4.4所示。 用例1图4.4 用例符号 4.1.1 用例 例如，在文字处理程序中，“置正文的字体为

3、宋体”是一个用例，在图书管理系统中“新增图书信息”、“借书”和“还书”也是用例，在超市管理系统中的“进货”也是一个用例，如图4.5所示。在这里可以看出，用例可大可小，有的用例可能比较简单，而有的可能就很复杂，如“置正文的字体为宋体”这个用例就比较简单，很容易实现，但是对于“进货”和“借书”这样的用例相对就比较复杂，可能需要花一些时间才能够实现。 置正文的字体为宋体借 书还 书图4.5 用例4.1.1 用例 怎样确定用例的粒度？（用例规模的大小） 用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定 用例是系统级的、抽象的描述，不是细化的（考虑的是“做什么what”，而不是“怎样做h

4、ow”） 对复杂的系统可以划分为若干子系统处理4.1.1 用例 怎样识别用例怎样识别用例 参与者需要从系统中获得参与者需要从系统中获得什么什么功能？参与者需要做功能？参与者需要做什什么么？ 参与者读取、产生、删除、修改或存储系统的参与者读取、产生、删除、修改或存储系统的哪些哪些信信息？息？ 需要将系统的需要将系统的哪个事件哪个事件告诉参与者？告诉参与者？ 需要将外界的需要将外界的哪些哪些信息提供给系统？（输入、输出信信息提供给系统？（输入、输出信息）息） 采用采用什么什么实现方法满足特殊要求？实现方法满足特殊要求？图书管理系统的用例图图书管理系统的用例图4.1.2 参与者 参与者（参与者（也称

5、为角色或活动者，角色或活动者，Actor）是系统外部的一个）是系统外部的一个人或者物，它以某种方式参与了系统的执行过程。参与者人或者物，它以某种方式参与了系统的执行过程。参与者不是特指人，是指系统以外的，在使用系统或与系统交互不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还需要注意的是，参与者不可以是时间或其他系统等等。还需要注意的是，参与者不是指人或事物本身，而是表示人或事物在系统中所扮演的是指人或事物本身，而是表示人或事物在系统中所扮演的角色。角色。 例如，张明

6、是图书馆的管理员，他参与图书管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里张明扮演了两个角色，是两个不同的参与者，即管理员和借阅者。 因此，在“图书管理系统”中“借阅者”和“系统管理员”都是参与者。4.1.2 参与者 Actor 系统外部的参与者，可以是用户、外部硬件、其他系统。4.1.2 参与者 【例4-1】客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。谁是系统的参与者？ 分析：根据参与者的定义可知，此系统的参与者是销售员。4.1.2 参与者 【例4-2】在需求分析中常见的权限控制问题，一般的用户只可以使用一些常规的操作，如查

7、询等，而管理员除了常规操作之外还需要进行一些系统管理工作，如一些关键数据的增加、删除、修改等，操作员既可以进行常规操作又可以进行一些配置操作。4.1.1 参与者 例如，在“图书管理系统”中，可以认为“读者”是“学生读者”和“教师读者”的泛化，而“学生读者”还可以具体化为“本科生读者”和“研究生读者”；同样，“图书管理员”也是“采购员”、“ 编目员”及“借阅人员”的泛化。 读者学生教师本科生研究生4.1.2 参与者 怎样识别参与者怎样识别参与者 谁使用系统的主要功能？谁使用系统的主要功能？ 谁需要系统的支持以完成日常工作任务？谁需要系统的支持以完成日常工作任务？ 谁从系统获取信息？谁从系统获取信

8、息？ 谁负责维护和管理系统以保证其正常工作？谁负责维护和管理系统以保证其正常工作？ 系统需要使用哪些外部硬件设备？（系统启动打印机、系统需要使用哪些外部硬件设备？（系统启动打印机、扫描仪）扫描仪） 系统需要和哪些外部系统交互？（跨行转账的外部银系统需要和哪些外部系统交互？（跨行转账的外部银行系统、时间到了定时启动系统某功能）行系统、时间到了定时启动系统某功能）在在图书管理系统图书管理系统中，中，“图书管理员图书管理员”和和“读者读者”为为系统的执行者。系统的执行者。“图书管理员图书管理员”负责使用系统的主负责使用系统的主要功能，要功能，“读者读者”从系统中获取所需的信息。从系统中获取所需的信息

9、。4.1.2 参与者 理解理解 Actor不是指人，而是指代表某一种特定功能不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个的角色，因此同一个人可能对应很多个Actor。Actor也可以指外部系统和设备。也可以指外部系统和设备。 如果一个活动者的操作是由另外一个活动者代如果一个活动者的操作是由另外一个活动者代理完成的，可以建立该活动者到另外活动者的理完成的，可以建立该活动者到另外活动者的依赖（或关联）关系。依赖（或关联）关系。4.1.2 参与者 识别参与者4.2 关系 用例除了与参与者有关联关系外，用例之间也存在着一定的关系，如泛化关系、包含关系、扩展关系等。 关联（acc

10、ociation） 包含（include） 扩展（extend） 泛化（generalization）4.2.1 关联关系 关联（关联（accociation） 每个用例都有活动者启动（每个用例必须和一每个用例都有活动者启动（每个用例必须和一个活动者关联，有一个活动者来参与），个活动者关联，有一个活动者来参与），除包除包含和扩展用例含和扩展用例 无论用例和活动者是否存在双向数据交流（无无论用例和活动者是否存在双向数据交流（无论是参与者提供信息给系统，还是从系统获取论是参与者提供信息给系统，还是从系统获取信息），关联总是由活动者指向用例，只用单信息），关联总是由活动者指向用例，只用单向箭头。向箭

11、头。4.2.2 包含关系 包含（包含（include） （是一种依赖关系，加了版型（是一种依赖关系，加了版型） 包含关系指的是两个用例之间的关系，其中一个用例包含关系指的是两个用例之间的关系，其中一个用例（称为基本用例）的行为包含了另一个用例（称为包含（称为基本用例）的行为包含了另一个用例（称为包含用例）的行为。也就是说基本用例会用到包含用例。用例）的行为。也就是说基本用例会用到包含用例。 在在UML图中，使用带虚线箭头表示，并在线上标有图中，使用带虚线箭头表示，并在线上标有。 箭头方向由基本用例指向被包含用例；箭头方向由基本用例指向被包含用例； 执行基本用例时，每次都必须调用被包含的用例（吃

12、饭执行基本用例时，每次都必须调用被包含的用例（吃饭前洗手）；前洗手）； 被包含用例也可以单独执行；被包含用例也可以单独执行；4.2.2 包含关系包含关系 包含关系示例包含关系示例删除图书修改图书信息图书管理员查询图书4.2.2 包含关系 包含（包含（include） 一个用例功能过多，可分解成小用例，构成包含依赖一个用例功能过多，可分解成小用例，构成包含依赖 本例中，被包含用例不能单独执行，没有本例中，被包含用例不能单独执行，没有Actor直接指向直接指向它们它们4.2.3 扩展关系 扩展（extend）关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整

13、的功能。extend的基本用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 在扩展关系中，对于扩展用例有更多的规则限制，即基本用例必须声明若干“扩展点扩展点”（extension point），而扩展用例只能在这些扩展点上增加新的行为和含义。扩展关系是从扩展用例到基本用例的关系，它说明扩展用例定义的行为如何插入到基本用例定义的行为中。也就是说，扩展用例并不在基本用例中显示。借阅者还书查询图书交罚款4.2.3 扩展关系 扩展（extend） （是一种依赖关系，加了版型） 一个用例在某些扩展点上扩展另一个用例的功能，构成新用例；箭头方向由扩展用例指向被扩展用例（即箭头方向由扩展用例

14、指向被扩展用例（即基本用例）基本用例）； 扩展用例依赖于被扩展用例（基本用例），只是部分片段组成，不是完整的独立用例，无法单独执行； 扩展用例不一定每次都被执行和调用。（吃饭前也可以不洗手），而被包含用例每次必修执行。 肯定没有活动者指向扩展用例，因为扩展用例依赖基本用例。4.2.4 泛化关系 泛化（generalization） 一个用例和其几种情形的用例间构成泛化； 往往将父用例用抽象用例（abstract）表示（即，父用例往往是虚的，真正用的是子用例。）4.2.4 泛化关系 泛化关系指的是一般与特殊的关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其它

15、的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。借阅者查找图书精确查找模糊查找4.3 用例图 用例图是被称为参与者的外部用户所能观察到的系统功能用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。的模型图。 用例图列出系统的用例和系统外的用例，并显示哪个参与用例图列出系统的用例和系统外的用例，并显示哪个参与者参与了哪个用例的执行（或称为发起了哪个用例）。者参与了哪个用例的执行（或称为发起了哪个用例）。 用例图多用于静态建模阶段用例图多用于静态建模阶段(主要是业务建模和需求建模主要是业务建模和需求建模)。 显示系统

16、和外部实体（Actor）交互的图事物名称解释UML表示参与者参与者(Actor)在系统外部与系统直接交互的人或事物在系统外部与系统直接交互的人或事物(如另一如另一个计算个计算机系统或一些可运行的进程机系统或一些可运行的进程)。我们需要注意的。我们需要注意的是：是：1.参与者是角色而不是具体的人，它代表了参与者是角色而不是具体的人，它代表了参与参与者在与系统打交道的过程中所扮演的角色。所者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应系统的多个参与者。不同的用户也可以只对应于一个参与

17、者，从而代表同一参与者的不同应于一个参与者，从而代表同一参与者的不同实例。实例。2.参与者作为外部用户参与者作为外部用户(而不是内部而不是内部)与系统发生与系统发生交互作用，是它的主要特征。交互作用，是它的主要特征。3.在后面的顺序图等中出现的在后面的顺序图等中出现的“参与者参与者”，与此，与此概念相同，但具体指代的含义，视具体情况而概念相同，但具体指代的含义，视具体情况而定。定。用例用例(Use Case)系统外部可见的一个系统功能单元。系统的功能系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交

18、换的消息所表达个或多个参与者之间交换的消息所表达 。创建。创建新用例，确认候选用例和划分用例范围的优秀法新用例，确认候选用例和划分用例范围的优秀法则则-“WAVE”测试测试(见附录见附录) 4.3.1 用例图中的事物用例图中的事物 4.3.2用例图中的关系用例图中的关系 关系关系解释解释图图参与者参与者与用例与用例之间的之间的关系关系关联关联表示参与者与用例之间的交互，通信途径。表示参与者与用例之间的交互，通信途径。(关联有时候也用带箭头的实线来表示，这样关联有时候也用带箭头的实线来表示，这样的表示能够显示地表明发起用例的是参与的表示能够显示地表明发起用例的是参与者。者。)用例之用例之间的关间

19、的关系系包含包含箭头指向的用例为被包含的用例，称为包含箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基用例。包含用例用例；箭头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。种条件；其执行并不会改变基用例的行为。 include扩展扩展箭头指向的用例为被扩展的用例，称为扩展箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基用例。扩展用例用例；箭头出发的用例为基用例。扩展用例是可选的，如果缺少扩展用例，

20、不会影响到是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。会执行，并且其执行会改变基用例的行为。参与者参与者之间的之间的关系关系泛化泛化发出发出箭头的箭头的事物事物“is a”箭头指向的箭头指向的事物事物。泛泛化关系是一般和特殊关系，发出箭头的一方化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般代表特殊的一方，箭头指向的一方代表一般一方。特殊一方继承了一般方的特性并增加一方。特殊一方继承了一般方的特性并增加了新的特性。了新的特性。extend 4.3.3 用例图的

21、例子例子实例实例1 参与者之间的泛化关系参与者之间的泛化关系 参与者：经理，安全主管，保安：经理，安全主管，保安 用例：管理人事，批准预算，批准安：管理人事，批准预算，批准安全证书，监视周边全证书，监视周边 在参与者之间不存在泛化关系的情况在参与者之间不存在泛化关系的情况下，各个参与者参与用例的情况分别是：下，各个参与者参与用例的情况分别是：经理参与用例管理人事和批准预算；安全经理参与用例管理人事和批准预算；安全主管参与用例批准安全证书；保安参与用主管参与用例批准安全证书；保安参与用例监视周边。由于安全主管与经理，安全例监视周边。由于安全主管与经理，安全主管与保安之间泛化关系的存在，意味着主管

22、与保安之间泛化关系的存在，意味着安全主管可以担任经理和保安的角色，就安全主管可以担任经理和保安的角色，就能够参与经理和保安参与的用例。这样，能够参与经理和保安参与的用例。这样，安全主管就可以参与全部安全主管就可以参与全部4个用例。但经理个用例。但经理或者保安却不能担任安全主管的角色，也或者保安却不能担任安全主管的角色，也就不能参与用例批准安全证书。就不能参与用例批准安全证书。实例实例2 用例之间扩展和包含关系用例之间扩展和包含关系 用例的上下文是：短途旅行但汽车的油不足以应付全部路用例的上下文是：短途旅行但汽车的油不足以应付全部路程。那么为汽车加油的动作在旅行的每个场景程。那么为汽车加油的动作

23、在旅行的每个场景(事件流事件流)中中都会出现，不加油就不会完成旅行。吃饭则可以由司机决都会出现，不加油就不会完成旅行。吃饭则可以由司机决定是否进行，不吃饭不会影响旅行的完成。定是否进行，不吃饭不会影响旅行的完成。实例3. 航空售票的用例图参与者参与者(actor)：clerk，监督员，信用卡，监督员，信用卡服务商，信息亭服务商，信息亭用例用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales参与者参与者Clerk参与参与(或称发起或称发起)Buy tickets和和Buy Subscription 两个用例

24、两个用例(关联关系关联关系)。这两个用例的事件流都包含这两个用例的事件流都包含Make charges用例用例(包含关系包含关系)。系统由：系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。组成。该系统主要包含：该系统主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales这几个功能。这几个功能。该系统主要面向的用户该系统主要面向的用户(参与者参与者)：clerk，监督员，信用卡服务商，信息亭。监督员，信用卡服务商，信息亭。 信息亭 Clerk Bu

25、y tickets Buy Subscription 信用卡服务商 Make charges 监督员 Survey sales 参与者 用例 Box Office 系统 关系 4.3.43.4用例图- -习题习题右图中的参与者有？右图中的参与者有？ (a) 1 (b) 2 (c) 3(d) 4右图中的用例有？右图中的用例有？(a) 1(b) 2(c) 3(d) 42和和3之间是什么关系？之间是什么关系？5和和6呢？呢？(a) 扩展，包含扩展，包含 (b) 包含，扩展包含，扩展5缺少了缺少了3仍然是个完整的用例？仍然是个完整的用例？(a) 是的是的(b) 不是不是4能够参与能够参与2吗？吗？1能

26、够参与能够参与5吗？吗？(a) 可以，不可以可以，不可以 (b) 不可以，可以不可以，可以习题答案：1、(a)(d) 2、(b)(c) 3、(b) 4、(b) 5、(b)4.4 用例图建模技术及应用 下面将利用上面的基础知识，结合具体的案例“图书管理系统”，根据系统的需求，创建用例图模型。 1. 识别出系统中的角色和用例 （1）如何从系统中识别出参与者参与者 获取系统用例首先要找出系统的角色。如何识别系统的角色？可以从系统要完成的业务中识别系统的角色。4.4 用例图建模技术及应用 通过与用户的交流，让用户回答一些问题来识别参与者参与者。可以参考以下问题： 谁将使用系统的主要功能？谁将使用系统的

27、主要功能？ 谁需要系统的支持以完成其日常工作任务？谁需要系统的支持以完成其日常工作任务？ 谁负责维护、管理并保持系统正常运行？谁负责维护、管理并保持系统正常运行？ 系统需要处理哪些硬设备？系统需要处理哪些硬设备？ 系统需要和哪些外部系统交互？系统需要和哪些外部系统交互？ 系统运行产生的结果谁比较感兴趣？系统运行产生的结果谁比较感兴趣？ 这几个问题的答案往往包括了所有与系统相关的用户。进一步分析这些用户，以及他们在系统中承担的作用就可以得到角色。4.4 用例图建模技术及应用 图书管理系统涉及读者信息管理、借阅信息管理、图书信息管理等多方面的信息管理。系统的使用对象为图书管理员和读者。 在图书管理

28、系统中，图书管理员要为每个读者建立借阅账号，用于记录读者的个人基本信息和图书的借阅信息；读者的账号信息建立成功后，给读者发借阅证，这时读者就可以凭借该借阅证进行图书的借阅，或是通过网络进行图书信息的查询和检索。4.4 用例图建模技术及应用 读者在借阅图书借阅图书时，需要出示借阅证，输入借阅证号，验证借阅证的有效性及是否可续借，无效则向读者提示原因，如，“卡号不对”，“已借满，不能续借”等，有效则显示读者的基本信息，读者提出借阅申请后，管理员对借阅的图书进行登记。 相应的，当读者归还图书归还图书信息时，也需要对借阅证进行有效性的验证，如果不对，给读者提示相应的信息，验证通过后，显示读者的基本信息

29、和借阅的图书信息等；读者向管理员归还图书，管理员验证无误后，删除读者对该书的借阅信息，如果超期，则读者需要缴纳一定的罚款才能归还。4.4 用例图建模技术及应用 此外，当涉及到图书信息变更时，例如，新增图书信息或是图书毁坏程度很大需要报损不能再使用时，图书管理员就需要将图书进行入库或是注销处理。同理，当有新增的借阅者或是要注销借阅者信息时也要做相应的处理。4.4 用例图建模技术及应用 （2）如何从系统中识别用例用例 1.用例的获取是需求分析阶段的主要任务之一。但对于一个大系统，要直接列出用例清单常常是十分困难的。这时可先列出角色清单，再对每个角色列出它的用例，问题就会变得容易得多。在识别出了角色

30、之后，就可以通过回答下述问题来帮助识别用例.4.3 用例图建模技术及应用 【例4-3】对图书管理系统进行需求分析以及第一部分得出的角色，可以得出每个角色相应的需求： 其中图书管理员可实现如下操作： 增加、删除和修改图书基本信息； 增加、删除和修改读者信息； 借书、归还图书记录的管理； 查询读者基本信息、图书的基本信息。4.3 用例图建模技术及应用 借阅图书用例描述 借阅图书是图书管理系统中的一项基本功能，当读者能有效的登录到系统后就可以浏览图书的信息，进行借阅。 还书用例描述 还书是借书的逆过程，即要归还读者借阅的图书 。 新增图书用例描述 注销图书用例 图书管理系统中对图书进行管理，图书有可

31、能因为某些原因而损坏，不能再使用时，需要将其注销 。4.3 用例图建模技术及应用 2. 区分用例优先次序 某些用例必须在其他用例之前完成，因为它们之间要相互依赖。例如，在系统借阅图书之前，必须记录图书的基本信息。因此很明显新增图书是最重要的用例。 3.构建用例图模型 将已确定并细化的角色和用例放入用例图中。此时，再借助包含、扩展和泛化的关系给出用例之间的结构模型。4.3 用例图建模技术及应用 【例例4-4】图书管理系统用例图图书管理系统用例图 图书管理系统按其业务功能分成读者管理、图书图书管理系统按其业务功能分成读者管理、图书管理、借书、还书和用户管理等几部分，这些职管理、借书、还书和用户管理

32、等几部分，这些职能对应于系统不同组织部门。能对应于系统不同组织部门。 （1）系统参与者）系统参与者 图书管理系统针对的对象是读者，图书管理员可图书管理系统针对的对象是读者，图书管理员可以对图书信息进行管理。图以对图书信息进行管理。图4.10是图书管理系统是图书管理系统参与者分析的用例图。其中，参与者参与者分析的用例图。其中，参与者“读者读者”是是抽象角色。抽象角色。4.3 用例图建模技术及应用借阅者教师学生图书管理员图4.10 系统角色4.3 用例图建模技术及应用 （2）图书管理）图书管理 图书馆中的图书根据需求进行更新是一项日常业务，因此图书馆中的图书根据需求进行更新是一项日常业务，因此在设

33、计该系统时，也要为此设计用例，管理员成功登陆图在设计该系统时，也要为此设计用例，管理员成功登陆图书管理系统的书籍信息管理子系统，可以进行图书的新书书管理系统的书籍信息管理子系统，可以进行图书的新书入库、删除、修改等。入库、删除、修改等。 删除图书修改图书信息图书管理员查询图书新增图书图图4.11 图书管理用例图图书管理用例图4.3 用例图建模技术及应用图书管理员还书交罚金检查借阅证的合法性还 书借 书图4.12 图书借阅和归还用例图 4.3 用例图建模技术及应用System图书管理员读者读者管理借阅管理借书还书图书管理新增图书注销图书查询图书丢失罚款超期罚款借阅记录查询增加读者删除读者图4.1

34、3 图书管理系统整体用例图4.3 用例图建模技术及应用 【例例4-5】超市进销存管理系统用例图超市进销存管理系统用例图 （1）超市进销存系统的需求）超市进销存系统的需求 超市进销存系统的需求共包含销售管理、库存管超市进销存系统的需求共包含销售管理、库存管理、订货管理和统计分析几部分：理、订货管理和统计分析几部分： 销售管理销售管理 售货员接收顾客订购，输入顾客购买的商品，计售货员接收顾客订购，输入顾客购买的商品，计算总价。算总价。 顾客付款并接收清单。顾客付款并接收清单。 售货员保存顾客购买商品的记录清单。售货员保存顾客购买商品的记录清单。4.3 用例图建模技术及应用 库存管理库存管理 库存管

35、理员每天进行盘点一次。库存管理员每天进行盘点一次。 库存管理员当发现库存商品有损坏时，及时到相库存管理员当发现库存商品有损坏时，及时到相关部门报损。关部门报损。 在供应商的商品到货时，库存管理员首先检查商在供应商的商品到货时，库存管理员首先检查商品是否合格，并将合格的商品入库处理；当商品品是否合格，并将合格的商品入库处理；当商品进入卖场时，进行商品出库处理。进入卖场时，进行商品出库处理。 经理、订货员根据需要进行库存商品的模糊查询经理、订货员根据需要进行库存商品的模糊查询或详细查询。或详细查询。4.3 用例图建模技术及应用 订货管理订货管理 订货员用新商品供应商信息更新供应商数据库的订货员用新

36、商品供应商信息更新供应商数据库的信息。信息。 订货员统计库存商品是否低于库存下限，然后制订货员统计库存商品是否低于库存下限，然后制作订货单。作订货单。 统计分析统计分析 经理能够使用系统的统计功能，了解商品销售情经理能够使用系统的统计功能，了解商品销售情况、库存情况、供应商情况，以便进行合理的营况、库存情况、供应商情况，以便进行合理的营销策略。销策略。 经理按市场情况适时变动商品价格。经理按市场情况适时变动商品价格。4.3 用例图建模技术及应用 （2）建立超市进销存系统的用例图模型）建立超市进销存系统的用例图模型 超市进销存管理系统按其业务功能分成订超市进销存管理系统按其业务功能分成订货管理、

37、销售管理、库存管理和统计分析货管理、销售管理、库存管理和统计分析四部分，这些功能对应于系统的不同组织四部分，这些功能对应于系统的不同组织部门。部门。4.3 用例图建模技术及应用 系统角色员工管理员售货员库存管理员统计分析员订货员图4.14 超市进销存系统参与者之间的泛化关系4.3 用例图建模技术及应用 超市进销存管理系统的顶层用例图超市进销存管理系统的顶层用例图售货员销售管理订货员订货管理库存管理统计查询身份验证库存管理员统计分析员员工4.3 用例图建模技术及应用 销售管理子系统的用例图销售管理子系统的用例图售货员顾客提取商品信息打印购物清单更新商品信息更新销售信息计 价图4.16 销售管理子

38、系统的用例图4.3 用例图建模技术及应用 订货管理子系统的用例图订货员订货管理统计订货商品制作订单图4.17 订货管理子系统的用例图4.3 用例图建模技术及应用 库存管理子系统的用例图库存管理员处理盘点处理报损管理设置商品入库更新供应商信息商品信息修改特殊商品设置图4.18 库存管理子系统的用例图4.3 用例图建模技术及应用 统计分析子系统的用例图统计分析子系统的用例图统计分析员查询商品信息查询销售信息查询供应商信息查询缺货信息查询报损信息查询特殊商品信息图4.19 统计分析子系统的用例图4.3 用例图建模技术及应用 身份验证子系统的用例图员工身份验证修改员工信息找回密码图4.20 身份验证子

39、系统的用例图4.4 用例描述用例描述 用例名称用例名称 应该与用例图相符合，并写上其相应的编号应该与用例图相符合，并写上其相应的编号 简要说明简要说明 每个用例应有一个相关说明，描述该用例的作用，应每个用例应有一个相关说明，描述该用例的作用，应注意语言简要，使用用户能够阅读的自然语言注意语言简要，使用用户能够阅读的自然语言 前提条件前提条件 是执行用例之前必需满足的条件，例如前提条件可能是执行用例之前必需满足的条件，例如前提条件可能是另外一个用例已经执行、或者用户具有运行当前用是另外一个用例已经执行、或者用户具有运行当前用例的权限。例的权限。 后置条件后置条件 用例结束后执行的动作，比如一个用

40、例结束后必需运用例结束后执行的动作，比如一个用例结束后必需运行另外一个用例。并不是每个用例都有后置条件。行另外一个用例。并不是每个用例都有后置条件。 主事件流和其他事件流主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描用例的具体细节在主事件流和其他事件流中描述。事件流描述执行用例功能的具体步骤。事述。事件流描述执行用例功能的具体步骤。事件流关注系统做什么，而不是怎么做，它是从件流关注系统做什么，而不是怎么做，它是从用户角度写成的。用户角度写成的。 主事件流和其他事件流包括如下方面：主事件流和其他事件流包括如下方面： 用例如何开始用例如何开始 用例的各种途径用例的各种途径 用例的主

41、流程用例的主流程 用例主事件流或其他事件流的变形用例主事件流或其他事件流的变形 错误流错误流4.4 用例描述用例描述-事件流事件流 主事件流主事件流 其他事件流其他事件流用例名称用例名称借阅图书借阅图书用例编号UC002用例说明借阅者如果想从系统中借书，参与者借阅者前置条件借阅者成功登录图书管理系统事件流1.输入借阅证号如果正确则提示“输入密码”如果不正确则提示“输入有误，请重新输入！”2.输入密码如果成功登录，则显示读者可借阅的图书信息，并提示超期未还的图书信息如果失败，则提示“密码有误！”3.输入要借阅的图书编号如果该读者已经借满，提示“已经借满，请先归还！”如果可以正常借阅，提示“确定要

42、借阅该书吗？”4.读者点击“确定”，则增加一条借阅记录后置条件借阅图书成功后，在图书管理系统中保存该借阅记录借阅图书用例描述借阅图书用例描述用例分析步骤用例分析步骤 确定系统的边界，找出系统外部的参与者和外部确定系统的边界，找出系统外部的参与者和外部系统；系统； 确定每个参与者所希望的系统行为，命名为用例；确定每个参与者所希望的系统行为，命名为用例； 把一些公共的系统行为分解为新的用例，供其他把一些公共的系统行为分解为新的用例，供其他用例引用，构成用例间的用例引用，构成用例间的包含包含关系；关系； 把一些变更的行为分解为扩展用例；把一些变更的行为分解为扩展用例； 编制用例的脚本，对用例进行描述

43、；编制用例的脚本，对用例进行描述； 绘制用例图；绘制用例图； 把特殊情况的用例画成单独的子用例图。把特殊情况的用例画成单独的子用例图。实例推荐方案 PK 可选方案优化练习 网上选课系统网上选课系统网上选课系统网上选课系统选课事件流错误流实例：在线选修课程管理系统实例：在线选修课程管理系统以在线选修课程管理系统在线选修课程管理系统为例来介绍怎样使用Rational Rose 进行UML可视化建模。最终递交三个文件：regist.mdl, regist.sql, VB的代码或Java的代码。需求分析需求分析1.大学教师选择本学期要教授的课程，每位教师最多只能上报4门课程。2.教师选课结束后，教务管

44、理人员进行协调和确认教师的课程，并创建本学期的课程目录表，向学生公布。3.学生填写课程选修表，每个学生最多选修4门课程；每门选修课程的学生数最多为30人，最少为5人。人数达到30人时，停止学生登记注册此门课程；4.学生选课结束后，系统自动取消人数少于5人的课程。5.学生按最终的课程表到财务处办理收费手续（billing system）。6.教师可查询所教课程的学生花名册(roster)。7.教务管理人员维护学生、教师和课程的信息。1.使用Rational Rose 创建执行者(Actors)右击browser框中的Use Case View包，弹出快捷菜单；选择NewActor项；输入执行者的名字；(如出错，可用Rename命令更改)注册选修课程的学生Student ；教授选修课程的教师Professor ；教务管理人员Registrar -必须汇总选修课程情况，制作课程表；教务管理人员必须维护关于课程、教师和学生的所有信息； 财务管理系统Billing System-从本系统中取出收费信息。2使用Rational Rose 创建用例(Use Case)右击browser框中的U