用例图

用例图百科名片用例图就是由主角、用例以及它们之间的关系构成的图。

该图说明了用例模型中的关系。

简介用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。

用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。

将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。

用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。

ps: 提取出“名词”，画用例图构成用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

参与者参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。

因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。

还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。

比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。

参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

用例用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。

这是UML对用例的正式定义，对我们初学者可能有点难懂。

我们可以这样去理解，用例是参与者想要系统做的事情。

对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。

用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界系统边界是用来表示正在建模系统的边界。

边界内表示系统的组成部分，边界外表示系统外部。

系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。

顾客顾客用户2.1 用例建模技术2.1.1 参与者和用例参与者（actor ）是系统外部与系统有交互的任何事物，是为了完成一个事件而与系统交互的外部实体。

参与者主要用于描述系统的边界。

例如，向银行提交贷款申请的顾客；通过因特网访问预订系统查询座位情况的旅行社，等等。

在UML 中，参与者经常用人形符号表示，或者用类的构造型《actor 》表示，如图2-3所示。

图2-3 参与者的UML 表示符号参与者并不一定是系统的用户。

它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。

图2-4展示参与者是外部系统的例子。

图2-4参与者是外部系统的例子当参与者是人时，它是指一个与系统有交互的用户所扮演的角色。

一个参与者并不是指一个特定的人或一个特定的实体。

例如，参与者“顾客”是对顾客的概念建模，而不是对张三这个特定的顾客建模。

一个用例并不仅局限于一个参与者; 参与某用例的参与者可能是多个。

然而，一个用例况必须向至少一个参与者提供可度量的价值。

参与某用例的多个参与者各有不同的角色和职责：一些负责接收用例提供的价值，一些则负责向用例提供服务，其它则负责触发或初始化用例。

Ivar Jacobson[1992]将参与者划为两类：主要的和次要的。

主要参与者(primary actor)是从系统获得可度量价值的用户。

主要参与者的需求驱动了用例所表示的行为或功能。

如果他们的需求或角色发生了变化，那么系统将必须有重大的修改。

次要参与者(secondary actor)在用例中提供服务，并且不能脱离主要参与者而存在。

在图2-4所示的例子中，顾客是主要参与者，而客户关系系统则是次要参与者。

顾客<<Actor>>顾客 客户关系管理系统 （已有） 网上商店系统（要开发） 问卷调查系统 （已有）图2-5 抽象参与者的例子一些参与者只扮演概念上的角色，而另一些则更具体。

如图2-5所示，顾客共享用户的属性。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而交互部分被称作用例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

京胜校园软件综合实验室用例图用户登录用例图本图共有三个角色：operator、teacher、student，operator登录到管理员模块，teacher登录到指导教师模块，student登录到学生模块。

三大模块都可以实现退出功能。

学生模块用例图学生模块又分为四大模块：我的实训，我的课程，个人中心，资料中心（如图）。

我的实训我的实训又分为四个小模块：我的消息，通知公告，我的课表，我的实训（如图）。

1.我的消息学生可以查看收件箱和发件箱的信息，并且扩展发送消息、删除消息、回复消息三种功能。

2.通知公告3.我的课表4.我的实训。

我的课程我的课程里只有一个小的模块：我的课程（如图）。

1.我的课程在我的课程里可以查看我的课程，并且扩展功能：进入课程。

资料中心资料中心分为两个小模块：下载资料和链接资料1.下载资料学生选择某一文件，便能够查看要下载的资料，在此处可以下载。

2.链接资料个人信息分为两个小模块：我的资料和修改密码1.我的资料2.更改密码指导教师模块指导教师模块分为信息管理、资源管理、实训组织、课程组织、资料管理5个模块。

信息管理信息管理又分为实训计划和投稿信箱两个模块1.实训计划指导教师可以在此查看实训计划，并且实现查看统计（查看被通知者查看信息的情况）、添加通知、删除通知、修改通知、查询（通过标题查找）5大功能。

2.投稿信箱指导教师可以在此查看投稿信箱，并且实现查询（通过投稿标题查询）功能。

资源管理资源管理模块里包含一个小模块内容管理。

1.内容管理实训组织实训组织模块又分为我的课程、实训管理、成绩管理3个小模块。

1.我的课程指导教师可以查看自己的课程，并实现查询（时间段或全部）功能。

2.实训管理3.成绩管理指导教师可以在此处查看成绩，并能实现查询（学期、班级、课程）、编辑成绩2大功能，其中编辑成绩又可以实现查看成绩、删除成绩、添加成绩、导入成绩（、查询（成绩名称）5大功能课程组织课程组织模块包含一个小的模块：课程管理。

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

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

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

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

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

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

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

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

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

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

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