第一篇：(用例图)Use Cases总结
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下：
1.参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2.用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3.子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
4.关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所示：
a.关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b.泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
c.包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d.扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
e.依赖(Dependency)
以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
【箭头指向】：指向被依赖项
5.项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上：
然后把项目-》属性 的Hyperlink设置到你的文档上；
这样当你在用例图上双击项目时，就会打开相关联的文档。
6.注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance)的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
一个用例图示例：
牢骚：
感觉用例图还不成熟，并不能很好地表达系统的需求，没有UML背景的用户几乎不知道画的是些什么。
其次，包含关系、扩展关系的箭头符号竟然是同样的箭头，仅靠上方写个文字来加以区别，翻译成其他语言的话，几乎就不知道代表什么意思。扩展关系的箭头朝向也很难理解，为何要指向基用例，而不指向扩展用例。
VS2010添加的“项目”元素，是个很好的创新，能够在用例图中关联word, excel这些文档。但为什么不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要画蛇添足地加一个元件，仅仅为了提供个链接功能。
用例描述表：
鉴于用列图并不能清楚地表达功能需求，开发中大家通常用描述表来补充某些不易表达的用例，下图的表给大家提供一个参考：
第二篇：UML用例图总结
UML用例图
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：
4、泛化(generalization)泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：
上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1)系统整体用例图
(商品用例图)
（购买信息用例）
(用户资料用例)
按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!
转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈无条件发生：肯定发生的；
⒉有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。
第三篇：Uml用例图心得（精选）
Uml用例图心得
序言：用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下：
1.参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2.用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
3.子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
4.关系
用例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所示：
a.关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
b.泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
c.包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】：指向分解出来的功能用例
d.扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
e.依赖(Dependency)
以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。
【箭头指向】：指向被依赖项
5.项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上：
然后把项目-》属性 的Hyperlink设置到你的文档上；
这样当你在用例图上双击项目时，就会打开相关联的文档。
6.注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance)的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
一个用例图示例：
第四篇：会议管理系统用例图
会议管理系统类图
审批会议安排信息审批会议成本信息部门经理审批用户角色变更申请信息审批会议室变更信息审批会议设备变更信息
用例名称： 参与者： 主事件流：(1)(2)(3)(4)
了解会议信息了解会议邀请信息了解部门会议成本信息与会者了解当前角色信息申请成为会议组织者
了解与会者提案信息了解会议室预订信息了解会议成本信息预订会议设备会议组织者取消会议组织者角色了解会议设备预订信息预订会议室创建会议信息
管理用户角色信息管理会议设备信息统计会议成本会议室管理员管理会议室信息审批会议室预订信息
了解会议信息部门经理了解会议邀请信息<
管理用户角色信息了解会议成本审批信息<
第五篇：图书管理系统用例图
图书管理系统 UML建模与设计模式
实验报告
计算机与信息工程学院
一、实验目的
在熟悉用例概念与应用的基础上，掌握用例模型的建立，包括： 1．掌握用例图的建立。
2．掌握用例描述文档的编写。3．掌握建模工具的使用。
二、实验内容
根据以下需求设计一个图书馆管理系统的用例图模型，包括：用例图和主要用例的描述文档。
基本功能要求：
图书管理：新书登记，图书查询，图书注销； 借阅管理：借书，还书，查询今日到期读者；
读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；
报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。
系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。
三、实验思想
（1）分析系统需求；
（2）确定系统参与者：读者、图书管理员、图书管理系统；（3）确定系统用例；
四、实验结果 借阅人用例图：
图书系统管理员用例图： 图书管理员用例图：
1．用例名称： 登录
用例描述：根据用户输入的用户名和密码判断用户的身份，赋予相应的权限。前置条件：无
后置条件：根据用户所有的权限进入相应的操作界面。基本操作流程： 输入用户名 2 输入密码 校验密码是否正确。根据用户身份进入相应的操作界面。
可选流程：如果密码不正确，提示重新输入密码；
如果用户名不正确，提示没有此用户。2.用例名称：查询图书
用例描述：由读者进行操作，查询图书馆中有没有需要图书，如果有，显示该图书编号、书名、作者、出版日期、当前借阅状态等信息。前置条件：以顾客身份登录 后置条件：无 基本流程： 以读者身份登录。输入图书的名称或作者名称。显示相关图书的信息。
可选流程：如果没有该图书，返回提示信息：“没有找到图书”。3．用例名称：借书
用例描述： 由图书管理员把读者的借书卡的条码读入计算机，再将读者所选图书的条码读入计算机，在不超过读者允许借书的情况下，累计该读者所借的书；否则提示超过借书数量。
前置条件：以图书管理员的身份登录系统。后置条件：图书信息中相应记录的还书日期值做改变；将借书明细加入借书记录中。
基本操作流程： 以图书管理员身份登录系统。2 进入借书功能。录入读者的借书卡条码。4 识别读者类别，提示读者可以借阅图书的数量及借阅时间
等。如果允许借阅，继续4，否则提示已达到借书数量。5 录入图书的条码，显示该图书的信息。6 还有其他图书，重复步骤3。7 保存操作。
可选流程 在保存之前，可以取消操作。4．用例名称：续借
用例描述： 由图书管理员把读者的借书卡的条码读入计算机，计算机显示读者所借图书及状态，选定需要续借的图书，系统提示还书时间，保存操作。前置条件：以图书管理员的身份登录系统。后置条件：图书信息中相应记录的还书日期值做改变；将续借明细加入借书记录中。
基本操作流程： 以图书管理员身份登录系统。2 进入续借功能。录入读者的借书卡条码。计算机显示读者所借图书及状态。如可以续借则选定需要续借的图书；否则提示无法续借。6 系统提示还书时间。7 保存操作。
可选流程：在保存之前，可以取消操作。
5.用例名称：还书
用例描述： 由图书管理员把图书的条码读入计算机，系统显示该书的读者资料，提示是否超出借阅期限。如未超出则显示还书成功；如超出则计算罚金。前置条件：以图书管理员的身份登录系统。
后置条件：图书信息中相应记录的状态值做改变；将还书明细加入还书记录中。基本操作流程： 以图书管理员身份登录系统。2 进入还书功能。3 录入读者的借书卡条码。系统显示该书的读者资料，提示是否超出借阅期限。5 如未超出则显示还书成功；如超出则计算罚金。
可选流程: 在保存之前，可以取消操作。
6.用例名称：新书登记
用例描述：由图书管理员将新书的信息录入计算机中，进行保存。前置条件：以图书管理员的身份登录系统。后置条件：图书信息中增加一条记录。基本操作流程： 以图书管理员的身份登录系统。2 进入新书登记功能。3 输入新书的相应信息。4 保存操作。
可选流程：在保存之前，可以取消操作。
7.用例名称：修改或注销图书
用例描述：由图书管理员修改图书的信息或注销图书，进行保存。前置条件：以图书管理员的身份登录系统。后置条件：图书信息中相应记录更新或删除。基本操作流程： 以图书管理员的身份登录系统。2 进入图书管理功能。选定需要修改或删除的图书。4 修改图书的相应信息或删除图书。5 保存操作。
可选流程：在保存之前，可以取消操作。
8.用例名称：增加读者
用例描述：由图书管理员将新读者的信息录入计算机中，进行保存。前置条件：以图书管理员的身份登录系统。后置条件：读者信息中增加一条记录。基本操作流程： 以图书管理员的身份登录系统。2 进入读者管理功能。输入新读者的相应信息，设置读者类别。4 保存操作。
可选流程：在保存之前，可以取消操作。
9.用例名称：修改或删除读者 用例描述：由图书管理员修改读者的信息或删除读者，进行保存。前置条件：以图书管理员的身份登录系统。后置条件：读者信息中相应记录更新或删除。基本操作流程： 以图书管理员的身份登录系统。2 进入读者管理功能。3 录入读者的借书卡条码，查询读者，确定需要修改或删
除的读者。修改读者的相应信息或删除读者。5 保存操作。
可选流程：在保存之前，可以取消操作。
五、实验心得
完成用例图之后，给我最大的感受就是一定要把课堂上学到的知识用到实践中。以前总觉得老师在上课讲的东西很简单，当真正操作起来的时候，才发现没那么容易，将课堂知识运用到实践中才是真正掌握了知识。
点击咨询 