用例图

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

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

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

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

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

而交互部分被称作用例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⽤例图-包含、扩展、泛化
⽤例图=参与者+⽤例
参与者在图中表⽰为⽕柴⼈⼀样,⼈、物、系统都能分为参与者
⽤例通常使⽤圆形来表⽰.
参与者去使⽤⽤例这个功能
⽤例和⽤例之间的关系有⼏种情况:
包含:⼀个⽤例有时会包含另⼀个⽤例,在图中使⽤虚线和箭头来表⽰
就像是借书->查书,想要借书,就必定要进⾏查书,所以说借书⽤例包含查书
扩展关系:分俩种情况:⼀种是可选,⼀种是特殊.
扩展关系有时候就像if⼀样,当发⽣⼀些情况的时候,或者你想额外做什么的时候,从原实例扩展出⼀个新的实例应对特殊情况或者额外可选操作,则说新 实例是扩展于原实例的.
特殊:扩展关系是被扩展⽤例的⼀种特殊情况,就⽐如扩展⽤例是有时候会发⽣的特殊情况,如迟到和上课,迟到就是由上课扩展的⽤例.
可选:可选的操作,是由原来的实例扩展出来可选的操作,就⽐如取票和打印凭证,
可以说必定发⽣⽤<<include>>(包含),可能发⽣使⽤<<extend>>(扩展)
泛化关系<<generalization>>,⼀般使⽤实现+空三⾓形来表⽰.
泛化⼀般指的就是⼀般和特殊的关系,就像是⽗类和⼦类的关系,如同er图的超类,⼦类是⼀种特殊的⽗类类型
就⽐如缴费⽤例和线上缴费、线下缴费之间,线上缴费和线下缴费就是缴费⽤例的⼦类,由⼦类指向⽗类的<<generalization>>关系. 泛化关系就是描述⽤例的⼀般和特殊关系.。

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

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

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

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

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

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

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

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

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

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

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

UML功能模型（⽤例图）在UML系统开发中有三个主要的模型：功能模型（从⽤户⾓度展⽰系统的功能，包括⽤例图）、对象模型（采⽤对象，属性，操作关联等概念展⽰系统的结构和基础，包括类图、对象图、包图）、动态模型（展⽰系统的内部⾏为，包括序列图，活动图，状态图）。

下⾯就说⼀说功能模型——⽤例图。

⽤例图是UML建模的⼀部分，也是UML⾥⾯最基础的部分，最主要的功能就是⽤来表达系统的功能性需求或⾏为。

⽤例图是由软件需求分析到最终实现的第⼀步，它描述⼈们如何使⽤⼀个系统，是尾部参与者所能观察到的系统功能模型图，该图呈现了⼀些参与者和⼀些⽤例，以及它们之间的关系，主要⽤于对系统、⼦系统或类的功能⾏为进⾏建模，⽤画图的⽅法来完成。

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

⽤例图包含留个元素：参与者、⽤例、关联关系、包含关系、扩展关系、泛化关系。

参与者（Actor）：系统外部的⼀个实体，参与⽤例执⾏过程，通过向系统输⼊或请求系统输⼊某些事件来触发系统的执⾏。

参与者的种类概括为三种：系统⽤户、与所建造的系统交互的其他系统以及⼀些可以运⾏的进程。

注意：参与者表⽰⼈和事物与系统发⽣交互时所扮演的⾓⾊，⽽不是特定的⼈或特定的事物；每个参与者需要⼀个具有业务⼀样的名字；⼀个⼈或事物在与系统交互时，可以同时或不同时扮演多个⾓⾊。

⽤例（Use Case）：⽤例是对⼀个活动者使⽤系统的⼀项功能是所进⾏的交互过程的⼀个⽂字描述序列，是系统、⼦系统或类和尾部参与者交互动作序列的说明，包括可选的动作徐磊嗯哼会出现异常的动作序列。

⽤例是岱庙系统各种各个项⽬相关⼈员之间就系统的⾏为所达成的契约，软件开发过程是⽤例驱动的。

⽤例粒度（规模⼤⼩）。

关联关系（Association）：表⽰参与者⽤例之间进⾏通信包含关系（Include）：客户⽤例可以简单地包含提供者⽤例具有的⾏为，并把他所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。

调⽤⽤例执⾏到包含点，然后执⾏传递给被调⽤⽤例，当被调⽤⽤例完成时，控制在次返回调⽤⽤例。

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

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

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

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

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

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

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

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

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

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

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