用例图

用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。

用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。

用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。

当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。

它将系统功能划分成对参与者（即系统的理想用户）有用的需求。

而交互部分被称作用例。

用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。

用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。

用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。

有时，可以将用例的实例引入到图中。

用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。

一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。

参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。

参与着由参与用例时所担当的角色来表示。

在UML中，参与者用名字写在下面的人形图标表示。

每个参与者可以参与一个或多个用例。

它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。

参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。

第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。

命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。

第二类参与者是其它的系统。

需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。

从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。

但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。

基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。

但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。

用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。

下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。

小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。

例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。

还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。

圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。

以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。

按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。

某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。

大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。

我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。

UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用？ (1)3、UML用例图的目的 (2)4、如何画用例图？ (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。

用例图展示了一个外部用户能够观察到的系统功能模型图。

用例图由主角，用例和它们之间的关系组成。

2、用例图怎么使用？要了解一个系统的动态，我们需要使用不同类型的图表。

用例图就是其中之一，其具体目的是收集系统的的需求和参与者。

用例图指定系统的事件和他们的流向。

但从未用例图描述了他们是如何实现的。

可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。

在这些图中使用的设计在一个非常高的水平。

那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。

一个结构良好的用例，还介绍了前置条件，后置条件和例外。

而这些多余的元素在执行测试时被用来制造测试的情况下。

用例都不是正向和反向工程，但他们仍然使用略有不同的方式。

同样是真实的逆向工程。

仍用例图的使用方式不同，使其逆向工程的一个候选。

在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。

所以下面的地方使用用例图：2.1.需求分析和高水平的设计。

2.2.模拟系统的上下文。

2.3.逆向工程。

2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。

用例图是用来收集系统的要求，包括内部和外部的影响。

这些要求大多是设计要求。

所以，分析一个系统时要收集其功能用例和确定参与者。

简单来说，用例图的目的如下：3.1.用例图用来收集系统的要求。

3.2.用例图用于获取系统的外观图。

3.3.用例图识别外部和内部因素影响系统。

3.4.用例图显示要求之间的相互作用是参与者。

4、如何画用例图？用例图被认为是高层次的需求分析系统。

因此，当系统的要求，分析被捕获在用例的功能。

用例图（User Case）用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。

下面逐一说明用例图中各种符号的意义：小人：对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。

小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。

例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。

还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。

圈圈：圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。

以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。

按着这样的读法，我们可以得到两句完整的句子：“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。

某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。

大框框：在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。

我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。

图书管理系统用例图：办理图书归还办理图书借阅查询图书相关信息设置读者权限更新图书信息图书管理员查询读者信息查询个人信息续借读者查询图书信息三、用列说明1.管理员办理图书归还（读者归还图书）：当读者归还图书时，图书管理员根据读者的借阅卡及所借图书书号，结合系统内读者信息记录，为读者办理归还事务。

办理图书归还：use case—01参与者：图书管理员，读者前置条件：图书管理员正常登录后置条件：无主干过程：1.读者提供自己的借阅卡号和图书号；2.管理员选择图书归还功能，输入读者提供的信息；3.系统检查信息是否正确，并显示读者借阅信息，提示是否超期借阅；4.管理员核对信息，若超期借阅，则转入超期罚款处理；否者向系统请求还书；5.系统接受请求，删除借阅记录，并更新图书可借阅数量。

分支过程：读者说明丢失图书，管理员转入图书丢失处理功能。

异常：读者提供的卡号及书号错误包含用列：无2.管理员办理图书借阅（读者借阅图书）：读者可以先查询图书信息，找到书后，向图书管理员请求借阅图书，图书管理员为读者办理图书借阅。

读者借阅图书：use case—02参与者：图书管理员，读者前置条件：图书管理员正常登录后置条件：无主干过程：1.读者到自助平台查询图书信息，找到图书；2.读者提供图书号和借阅卡号，管理员进入图书借阅功能，输入读者信息。

3.系统验证借阅卡的有效性和读者是否可继续借阅图书，无效则提示其原因，有效则显示读者的基本信息（包括照片），供管理员人工核对；4.管理员输入要借阅的书号，系统查阅图书信息数据库，显示图书的基本信息，供管理员人工核对；5.管理员最后提交借阅请求；6.系统接受则存储借阅纪录，并修改可借阅图书的数量；分支过程：无异常：借阅卡号或者图书号错误包含用列：无3.读者续借：读者可以在互联网进入系统续借图书。

读者续借：use case—03参与者：读者前置条件：读者正常登录后置条件：无主干过程：1.读者输入借阅卡号及密码，进入系统，选择借阅记录，再选择续借；2.系统检查是否超过规定续借次数，没有则系统更新读者借阅记录，超过则提示不可续借。

用例图实验报告用例图实验报告引言：用例图是一种用于描述系统功能和行为的图形化工具。

它可以帮助软件开发团队更好地理解系统的需求和功能，并在开发过程中进行有效的沟通和协作。

本实验旨在通过实际操作和分析，探讨用例图的基本概念、构建方法和应用场景。

一、用例图简介用例图是一种UML（统一建模语言）的图形化表示方法，用于描述系统的功能和行为。

用例图由用例、参与者和关系组成。

用例表示系统的功能需求，参与者表示与系统交互的角色，关系表示用例和参与者之间的关联。

二、用例图的构建方法1. 确定参与者：首先要明确系统的参与者，即与系统进行交互的角色或实体。

可以是人、其他系统或外部设备。

2. 确定用例：根据系统的功能需求，确定系统的用例。

用例应该是系统可以执行的具体功能或操作。

3. 建立关系：根据参与者和用例之间的交互关系，建立关联关系。

常见的关系有关联、包含、扩展和泛化等。

4. 完善用例图：根据实际需求，完善用例图的细节，如添加用例的描述、参数和返回值等。

三、用例图的应用场景1. 系统需求分析：用例图可以帮助开发团队更好地理解系统的功能需求，从而更准确地进行需求分析和设计。

2. 系统设计与开发：用例图可以作为系统设计的基础，帮助开发团队确定系统的功能模块和交互方式。

3. 测试与验证：用例图可以作为测试用例的基础，帮助测试团队设计和执行测试方案，并验证系统是否满足需求。

4. 系统维护与升级：用例图可以帮助系统维护团队理解系统的功能和行为，从而更好地进行系统维护和升级。

四、实验过程与结果在本次实验中，我们选择了一个在线购物系统作为实验对象。

首先，我们明确了系统的参与者，包括顾客、管理员和供应商。

然后，我们根据系统的功能需求，确定了一些用例，如登录、浏览商品、添加购物车、下单等。

接下来，我们建立了参与者和用例之间的关系，如顾客和管理员之间的关联关系、下单用例和支付用例之间的扩展关系等。

最后，我们完善了用例图的细节，添加了用例的描述和参数等。