画用例图
用power designer画用例图方法
画用例图用例图组成：系统边界。
参与者。
用例。
关系。
参与者：Actor不是人，而是指参与用例时担当的角色。
如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。
怎样识别参与者呢？1. 是谁向系统提供的信息呢.2. 谁向系统获取信息。
3. 谁操作系统。
4. 系统使用哪些外部资源5. 系统是否和已经存在的系统交互系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度呢？用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。
用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。
对复杂系统可以划分为若干个子系统处理。
怎样获取用例呢？参与者希望系统执行什么任务？参与者在系统中访问哪些信息（创建、存储、修改、删除等）？需要将外界的哪些信息提供给系统？需要将系统的那个事件告诉参与者？如何维护系统？UML中的四种关系。
关联（association）包含（include）扩展（extend）泛化（generalization）关联关系描述参与者和用例之间的关系。
用单向箭头，表示谁启动用例。
每个用例都有角色启动，除了包含和扩展用例。
包含。
是指两个用例之间的关系。
其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。
如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。
上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。
且这三个用例和提取出的这个用例之间是包含的关系。
执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。
如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例扩展。
也是指两个用例之间的关系。
如何绘制用例图
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
用例图的画法及含义
⽤例图的画法及含义⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰：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⽽⾔，延伸⽤例并不包含基础⽤例的内容，基础⽤例也不包含延伸⽤例的内容。
UML绘制用例图和类图
淮海工学院计算机工程学院实验报告书课程名:UML理论及实践题目：实验二绘制用例图和类图班级：D计算机081学号：**********名：**一、实验目的与要求(1)理解actor、Use case的概念及作用，能标识Actor之间、Use case之间、Actor 和Use Case之间的关系;(2)理解类的内部结构及类间的关系(Association、Generalization、dependency、realize、Aggregation、composition,...)(3)学会应用Rose/RSA绘制Use case图和类图，在图中正确绘制各种图形元素、表示元素间的相互关系。
二、实验内容(1)可以以“图书信息管理”或"*****管理系统"为主题，绘制其Use case图和类图。
(2)要求所绘制的图形应与所描述的主题语义一致。
三、实验步骤1.以“网店管理系统”为主题，绘制其Use case图和类图。
2.描述绘制的Use case图和类图。
四、实验结果雇员图一网店管理Use Case图图中包含四个活动者：个人顾客、顾客、协作顾客、雇员。
包含五个Use case：分别为“浏览商品”、“添加商品”、“删除商品”、“商品选购”、“订货作业线”。
个人顾客、顾客、协作顾客之间存在泛化关联。
Use case “浏览商品”、“添加商品”、“删除商品”、“商品选购”存在包含关联。
顾客、雇员分别于五个Use case “浏览商品”、“添加商品”、“删除商品”、“商品选购”、“订货作业线”存在使用关联。
图二网上商店的类图矩形框“订货”、“订货作业线”、“顾客”、“个人顾客”、“协作顾客”、“雇员”、“产品”、均表示对象类。
将每个对象类图框分割成3个分隔框，其中分别列出了该对象类的类名、属性和操作。
例如在对象类“顾客”中，有两个属性name（顾客名）和address（地址），一个操作creditRating()（信誉度分级）。
需求中如何画用例图
需求中如何画用例图UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。
从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。
但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。
基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。
基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。
但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。
这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。
UML用例图的画法
一．UML简介UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。
其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
依我的理解用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1．用例图参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
高校毕业设计用例图
高校毕业设计用例图学生用例图:学生课题选择我的课题我的任务书开题材料论文提交网上答疑通知公告退选«扩展»我的开题材料«包括»提交开题材料«包括»修改个人信息个人信息管理«扩展»下载专区我的论文«扩展»答疑提交«包括»教师回复«包括»我的提问«包括»教师用例图：教师课题申报全院课题发布任务书选题管理通知公告网上答疑开题报告本组学生信息下载专区归档材料论文接收个人信息管理我的课题«扩展»被选课题«包括»未选课题«包括»我的任务书«扩展»回复答疑«包括»我的回复«包括»学生提问«包括»上传归档材料«包括»我的归档材料«包括»修改个人信息«扩展»管理员部分用例图1:管理员课题审核课题导入课题删除通知公告教师信息管理选题管理学生信息管理教师申报课题«包括»«包括»«包括»发布公告«包括»查看公告«包括»未选课题信息«包括»已选课题信息«包括»未选学生信息«包括»已选学生信息«包括»所有课题信息«包括»导出所有课题«包括»新建学生信息«包括»删除学生信息«包括»删除教师信息«包括»新建教师信息«包括»管理员部分用例图2:管理员数据库维护个人信息管理基础数据维护学生信息导入教师信息导入账户管理下载专区归档材料个人信息修改«扩展»时间设置«包括»专业设置«包括»学院设置«包括»数据库还原«包括»数据库备份«包括»教师密码重置«包括»学生密码重置«包括»文件下载«包括»文件管理«包括»文件上传«包括»下载学生信息模板«扩展»下载教师信息模板«扩展»实验小结:在这次实验中,老师带领我们进行毕业设计的需求分析,在做到功能分析的时候,我学到了用用例图来表示系统功能需求.在画用例图过程中体会了用例与用例之间的三种关系:包含,扩展,泛化.懂得了哪些用例之间需要用包含关系,哪些需要用到扩展关系,同时用例图要求简洁整齐美观.用例图是功能需求分析很实用的表示方法.此外还有类图,业务流程图,层次图等也可以用来表示功能需求,灵活搭配使用这些表示方法有利于清晰准确的表示系统功能需求.。
用例图的画法
1. 借阅者请求服务的用例
① 登录系统 ② 查询自己的借阅信息 ③ 查询书籍信息 ④ 预定书籍 ⑤ 借阅书籍 ⑥ 归还书籍
第27页，共33页。
2. 图书馆管理员处理借书、还书的用例
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
第28页，共33页。
3. 系统管理员进行系统维护的用例
① 识别系统外部的参与者。 ② 将类似参与者组织成泛化的结构层次。 ③ 在需要加深理解的地方，为每个参与者提
供一个构造型。 ④ 将参与者放入到用例图中，并说明参与者
与用例之间的通信路径。
第18页，共33页。
5.2.2 对需求建模
① 识别系统的外部参与者来建立系统的语境。 ② 考虑每一个参与者期望的行为或需要系统提供的行为。
用例图的画法
第1页，共33页。
5.1.1 概述
▪ 用例图显示谁将是相关的用户、用户希望系统提 供什么服务以及用户需要为系统提供的服务。
▪ 用例图最常用来描述系统以及子系统。
第2页，共33页。
5.1.1 概述
▪ 用例图包含6个元素： ① 参与者（Actor） ② 用例（Use Case） ③ 关联关系（Association） ④ 包含关系（Include） ⑤ 扩展关系（Extend） ⑥ 泛化关系（Generalization）
第5页，共33页。
确定参与者
▪ 如何寻找系统的参与者 ▪ 对参与者建模的过程中需要注意的问题
第6页，共33页。
参与者间的关系
▪ 在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。
▪ 参与者间的泛化关系示 例：
第7页，共33页。
5.1.3 用例
▪ 外部可见的系统功能单元。 ▪ 在不揭示系统内部构造的前提下定义连贯的
用例图含义及画法
用例图的含义及画法用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。
用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。
它将系统功能划分成对参与者（即系统的理想用户）有用的需求。
而交互部分被称作用例。
用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。
有时，可以将用例的实例引入到图中。
用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）1．参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。
参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。
参与着由参与用例时所担当的角色来表示。
在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。
它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。
命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
UML中的用例图绘制指南及注意事项
UML中的用例图绘制指南及注意事项引言：UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，用于描述系统的结构、行为和交互。
其中，用例图是UML中最常用的图之一，用于描述系统的功能需求和用户与系统之间的交互。
本文将为读者介绍UML用例图的绘制指南及注意事项，帮助读者更好地理解和运用这一工具。
一、用例图概述用例图是用例驱动开发方法的核心，它能够帮助开发人员和用户之间更好地沟通和理解需求。
用例图主要由参与者（Actor）、用例（Use Case）和关系（Relationship）三个要素组成。
参与者指的是系统的外部用户或外部系统，用例则表示系统的功能需求，关系则描述参与者和用例之间的交互关系。
二、绘制用例图的步骤1. 确定参与者：首先需要明确系统的各个参与者，包括用户和外部系统。
参与者应该是与系统有直接交互的实体，例如管理员、用户等。
2. 识别用例：根据系统需求，识别出系统的各个功能需求，每个功能需求可以看作是一个用例。
用例应该能够描述系统的一个具体功能或者一个用户场景。
3. 绘制参与者和用例：在绘制用例图时，首先绘制参与者，然后绘制用例，用椭圆形表示。
参与者和用例之间可以用直线连接。
4. 添加关系：根据实际情况，添加参与者和用例之间的关系，常见的关系有关联（Association）、包含（Include）和扩展（Extend）等。
5. 完善用例图：根据需要，可以添加用例的详细描述、前置条件和后置条件等信息，以便更好地理解和使用用例图。
三、用例图绘制的注意事项1. 简洁明了：用例图应该尽量简洁明了，避免过多的细节和冗余信息。
只保留关键的参与者、用例和关系，以便更好地传达系统的功能需求。
2. 层次清晰：用例图应该有良好的层次结构，将不同的用例和参与者分组显示，以便更好地组织和理解系统的功能模块。
3. 一致性：用例图应该与系统的需求文档和其他模型保持一致，避免出现冲突和矛盾。
1绘制用例图
就可以完成的任务。 用例强调了能够增加可见的或可度量的业务价值
EBP级别上的用例
一个EBP级别上的用例通常被称为
一个用户目标级别上的用例，以强
调用例应该帮助系统的用户来实现
自己的目标
解决
找出用户的目标
你想做什么？
方案
你的目标是什么？ 和过
系统分析师UML用例实战》介绍如 何通过用例掌握UML。《系统分析 师UML用例实战》的案例基于 Wesley和Richard两个角色叙述，从 两人开始接到一个书店系统的项目， 到动手建立用例模型，并且应用用 例技术来估算工时，系统记述了 UML用例的应用方法。
第1章 绘制用例图
《系统分析师UML用例实战》
收银员或顾客
目标
处理销售 处理销售
……
……
……
确定用例——EBP级别的用例
一个好的用例为参与者产生一种可以估 量的价值结果
描述参与者想要系统完成的事情
用例
一组用例是一个系统的用户能够使 用系统完成的不同任务
可以通过考虑在系统实现后参与者 能够用它来做什么，简单地草拟出 这次迭代的一组初步的用例
影响软件项目的因素
不充分的用户输入 13%
其其它它 505%0%
不完整需求 12%
员工不足 6%
变更需求 12%
技术技能不足 7%
用例到底用在哪？
What
How
Do
用用 例例 图描
述
“用例”先睹为快——用例图
接待员 前台 领班
餐饮管理系统 记录预约
取消预约 <<include>>
<<include>> 调换餐桌
高校毕业设计(论文)用例图
实验名称：功能需求分析课程名称需求工程题目毕业设计论文管理系统专业软件工程班级12级软件工程姓名张泽坤学号201240450133指导教师张国军2014年11月5日(完成时间)学生课题选择我的课题我的任务书开题材料论文提交网上答疑通知公告退选«扩展»我的开题材料«包括»提交开题材料«包括»修改个人信息个人信息管理«扩展»下载专区我的论文«扩展»答疑提交«包括»教师回复«包括»我的提问«包括»教师课题申报全院课题发布任务书选题管理通知公告网上答疑开题报告本组学生信息下载专区归档材料论文接收个人信息管理我的课题«扩展»被选课题«包括»未选课题«包括»我的任务书«扩展»回复答疑«包括»我的回复«包括»学生提问«包括»上传归档材料«包括»我的归档材料«包括»修改个人信息«扩展»管理员课题审核课题导入课题删除通知公告教师信息管理选题管理学生信息管理教师申报课题«包括»«包括»«包括»发布公告«包括»查看公告«包括»未选课题信息«包括»已选课题信息«包括»未选学生信息«包括»已选学生信息«包括»所有课题信息«包括»导出所有课题«包括»新建学生信息«包括»删除学生信息«包括»删除教师信息«包括»新建教师信息«包括»管理员数据库维护个人信息管理基础数据维护学生信息导入教师信息导入账户管理下载专区归档材料个人信息修改«扩展»时间设置«包括»专业设置«包括»学院设置«包括»数据库还原«包括»数据库备份«包括»教师密码重置«包括»学生密码重置«包括»文件下载«包括»文件管理«包括»文件上传«包括»下载学生信息模板«扩展»下载教师信息模板«扩展»实验小结:在这次实验中,老师带领我们进行毕业设计的需求分析,在做到功能分析的时候,我学到了用用例图来表示系统功能需求.在画用例图过程中体会了用例与用例之间的三种关系:包含,扩展,泛化.懂得了哪些用例之间需要用包含关系,哪些需要用到扩展关系,同时用例图要求简洁整齐美观.用例图是功能需求分析很实用的表示方法.此外还有类图,业务流程图,层次图等也可以用来表示功能需求,灵活搭配使用这些表示方法有利于清晰准确的表示系统功能需求.（注：可编辑下载，若有不当之处，请指正，谢谢!）。
用例图这样画，3步让你做需求分析有理有据
用例图这样画，3步让你做需求分析有理有据之前写《做产品，为什么要画这些图？》，介绍产品常用视图后，一直想深入介绍每一种图的用法，却生怕理解不到位，又不想当文字搬运工，迟迟不敢开写。
这次趁着打磨课程，逼自己猛啃几本书，结合这几年做产品的经历，总算提炼出自己的思路。
我首先要讲的是用例图，用例是 UML 中最重要的一个元素，后续分析流程、设计功能，都是围绕它展开的。
本文先介绍为什么要画用例图，再为你解读用例图知识，最后用一个案例演示如何画用例图。
文章有点长，不过相信你看完，对如何做需求分析会有新的认识。
一、用例图有啥了不起做产品前几年，我很少画用例图，直到做数据中台，碰到的需求更复杂，我重翻《大象：Thinking in UML》找灵感。
读到用例时，我恍然大悟，原来我放着用例这么好的法宝不用，简直暴殄天物。
后来，我从业务调研开始，用用例的分析方法，把业务研究透、描述出来，系统该做成怎样，脑海里渐渐清晰。
当然，并非每个需求都得画用例图，简单的需求完全可以不用牛刀。
1. 用户视角用例的设计之初，是希望我们别老在系统内执着功能，而是跳到系统外，以用户的眼光看系统，思考什么情况下给什么人提供什么支持。
如果我们学会了用例图的分析思想，理解它的表达逻辑，至少能试着站在用户的角度去看问题。
开启这种视角，才不会总用晦涩难懂的术语，将用户搞晕，才能用业务方的语言去沟通，真正以用户为中心去获取需求，转化为产品服务。
练习的办法，便是按用例的规则和方法，一点点做，逐渐转变思考的方式。
2. 场景化思维用例的另一个特点是，关注用户在什么情况下做什么事，这是典型的场景化思维。
这让我想起，以前给老妈换手机，要教会她使用，可让我头疼了。
每次跟她说，这是查号码、这是打电话、这是听歌、这是看视频等等，她都记不住。
我一度以为人年纪大了，记忆力不好，很难接受新东西。
后来，我反思自己，改变策略，只给她讲，她用手机会做的几件事情。
打电话，我只告诉她第一步按哪，第二步按哪，每一步有什么标记符号，再把常拨号码，设置成快捷键，每次只需一步操作。
软件设计过程中画用例图的步骤
用例图用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例图包含六个元素，分别是：参与者 (Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。
一．参与者（Actor）确定参与者在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。
（1）谁将使用该系统的主要功能。
（2）谁将需要该系统的支持以完成其工作。
（3）谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4）系统需要处理哪些硬件设备。
（5）与该系统那个交互的是什么系统。
（6）谁或什么系统对本系统产生的结果感兴趣。
二、用例（Use Case）识别用例用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。
系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。
识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。
使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。
用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。
这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1）特定参与者希望系统提供什么功能。
（2）系统是否存储和检索信息，如果是，由哪个参与者触发。
（3）当系统改变状态时，是否通知参与者。
（4）是否存在影响系统的外部事件。
（5）哪个参与者通知系统这些事件。
三、用例间的关系1．关联关系（Association）２．包含关系（Include）包含关系把几个用例的公共步骤分离成一个单独的被包含用例。
被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。
RationalRose画用例图
RationalRose画用例图实验一建立用况图一、实验目的1．熟悉用例图的基本功能和使用方法。
2．掌握如何使用建模工具绘制用例图方法。
二、预备知识Rational Rose 简介Rose模型（包括所有框图、对象和其他模型元素）都保存在一个扩展名为.mdl的文件中。
1. 环境简介1.1 Rational Rose可视化环境组成Rose界面的五大部分是浏览器、文档工具、工具栏、框图窗口和日志。
见图1-1。
图1-1：Rose界面●浏览器：用于在模型中迅速漫游。
●文档工具：用于查看或更新模型元素的文档。
●工具栏：用于迅速访问常用命令。
●框图窗口：用于显示和编辑一个或几个UML框图。
●日志：用于查看错误信息和报告各个命令的结果。
1.2浏览器和视图浏览器是层次结构，用于在Rose模型中迅速漫游。
在浏览器中显示了模型中增加的一切，如参与者、用例、类、组件等等。
Rose浏览器见图1-2。
浏览器中包含四个视图：Use Case视图、Logical视图、Component视图和Deployment视图。
点击每个视图的右键，选择new就可以看到这个视图所包含的一些模型元素。
图1-2：Rose浏览器1. 3框图窗口在图1-3所示的框图窗口中，我们可以浏览模型中的一个或几个UML框图。
改变框图中的元素时，Rose自动更新浏览器。
同样用浏览器改变元素时，Rose 自动更新相应框图。
这样，Rose就可以保证模型的一致性。
图1-3：框图窗口2.UML各类框图的建立2. 1建立用例图use case diagram从用例图中我们可以看到系统干什么，与谁交互。
用例是系统提供的功能，参与者是系统与谁交互，参与者可以是人、系统或其他实体。
一个系统可以创建一个或多个用例图。
●创建用例图（图2-1-1）在浏览器内的Use Case视图中，双击Main，让新的用例图显示在框图窗口中。
也可以新建一个包（右击Use Case视图，选择new→package，并命名），然后右击这个新建包的，选择new→use case diagram。
visio2020绘制用例图带图例
visio2020绘制用例图
1.Microsoft Office2020中打开Microsoft Visio 2020，在“新建当选择”软件和数据
库“，如图：2.然后选择“UML模型图”，点击右下方的“创建”，进入主页面，如图：
3.在左下角模型资源治理器中，“顶层包”上右键新建”子系统“，如图：
4.给新建的“子系统”命名，如图：
5.然后在新建的子系统上右击，选择”用例图“如图：
新建用例图后打开。
左上角工具栏显现经常使用工具，拖拽即可绘制用例图：6.选中需要自概念的元素，右键可查看具体自概念元素样式，包括连线方式，文本，线条
样式，填充，如图：
7.设置参与者与用例之间的关系：
a)在左侧工具栏当选择“用”工具如图
b)在用例图中拖动图标链接目标用例与参与者：
选中线条右键-》格式-》线条，设置箭头起点为无
c)双击连线。
修改构造型为空，可隐藏连线上的label
8.设置用例之间的扩展关系：
a)选中工具栏上的扩展按钮：
b)拖动到有扩展关系的用例上
c)选中线条右键-》格式-》线条。
设置虚线和起始箭头：
用例图图例说明
UML表示
含义，视具体情况而定。
用例图关系说明
出发用例成为扩展用例。
用例图-用例分层和用例文档
见附件1，2
我们以火车票订票系统为例：
顶层用例图，零级用例
对零级用例进行细化，该层为一级用例
对每个一级用例细化 1. 用户管理：注册， 登录，退出，密码找 回，信息查看，信息 修改，用户验证，用 户查询
2. 查询：时刻表，余票 ，联程规划，晚点
3. 订单：下单，取消订 单，修改订 单，订单查 询，预订
4. 票务：订票，取票， 改签，退票，车票查 询
5. 资金：付款，退款 ，查询到帐， 银行对账
6. 票池：入票，出票 ，查询票池， 修改票池
7. 维护：参数设置，词 典维护，拓扑管理，日 志查询，备份，恢复
用例文档
用例文档有多种形式，但共同目的都是为 了更详细的描述用例。 以下介绍比较典型的两种
用例图用例分层和用例文档用例图分层?当系统需求相对比较复杂时我们通常考虑使用分层的方法来描述用例?所谓分层法也是在其他领域经常用到的一种方法是在复杂的问题难以一次性解决的时候常采用的一种逐步细化简化问题的办法
用例图 用例分层和用例文档
用例图分层
当系统需求相对比较复杂时，我们通常考 虑使用分层的方法来描述用例 所谓分层法也是在其他领域经常用到的一 种方法，是在复ቤተ መጻሕፍቲ ባይዱ的问题难以一次性解决 的时候，常采用的一种逐步细化，简化问 题的办法。
用例图设计：根据需求,绘制用例图,明确系统功能和模块
用例图设计：根据需求，绘制用例图，明确系统功能和模块
章节一：引言
- 介绍用例图的作用和重要性
- 引出本文的目的和结构
章节二：用例图概述
- 解释用例图的概念和定义
- 说明用例图的组成部分：参与者、用例、关系
章节三：用例图设计的步骤
- 第一步：需求收集和分析
- 说明需求收集的方法和工具
- 强调需求分析的重要性
- 第二步：确定参与者
- 解释参与者的概念和作用
- 提供确定参与者的方法
- 第三步：识别用例
- 解释用例的概念和作用
- 提供识别用例的方法
- 第四步：确定关系
- 介绍不同类型的关系：包含、扩展、泛化
- 提供确定关系的方法
- 第五步：绘制用例图
- 提供用例图的绘制方法和工具
- 强调用例图的清晰性和准确性
章节四：用例图的实例分析
- 选择一个实际的场景进行分析
- 根据需求和步骤，逐步设计用例图
- 解释每个用例的功能和关系
章节五：用例图的验证和调整
- 强调用例图的验证和调整的重要性
- 提供验证和调整的方法和工具
- 解释如何根据反馈进行修改和改进
章节六：用例图的应用和扩展
- 介绍用例图在系统开发中的应用
- 解释用例图的扩展和演化的方法
- 提供进一步学习的资源和参考资料
章节七：总结
- 简要回顾本文的内容和结论
- 强调用例图设计的重要性和价值
- 鼓励读者进一步学习和实践用例图设计。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用例图。
组成：系统边界。
参与者。
用例。
关系。
参与者：Actor不是人，而是指参与用例时担当的角色。
如果一个角色的操作是由另一个角色代理完成的，请建立该角色到另外角色之间的依赖。
怎样识别参与者呢？
1. 是谁向系统提供的信息呢.
2. 谁向系统获取信息。
3. 谁操作系统。
4. 系统使用哪些外部资源
5. 系统是否和已经存在的系统交互
系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度呢？
用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。
用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。
对复杂系统可以划分为若干个子系统处理。
怎样获取用例呢？
参与者希望系统执行什么任务？
参与者在系统中访问哪些信息（创建、存储、修改、删除等）？
需要将外界的哪些信息提供给系统？
需要将系统的那个事件告诉参与者？
如何维护系统？
UML中的四种关系。
关联（association）
包含（include）
扩展（extend）
泛化（generalization）
关联关系
描述参与者和用例之间的关系。
用单向箭头，表示谁启动用例。
每个用例都有角色启动，除了包含和扩展用例。
包含。
是指两个用例之间的关系。
其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。
如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用力拉可以和这个用例建立包含关系。
上面的例子就是说查询、提款和转账三个用例都有一个一致的功能，所以将这个功能提取出来为一个用例。
且这三个用例和提取出的这个用例之间是包含的关系。
执行基本用例的时候也可以执行被包含的用例，被包含的用例也可以单独执行。
如果一个用例的功能太多时，可以用包含关系建模成两个或多个小用例
扩展。
也是指两个用例之间的关系。
一个用例可以被定义为基础用例的增量的扩展，称作为扩展关系。
扩展关系是把新的行为插入到已有的用例中方法。
基础用例即使没有扩展用例的执行不会涉及扩展用例，只有在特定的条件发生，扩展用例才被执行。
泛化（继承）。
一个用例和其几种情形的用例间构成泛化关系。
往往父用例表示为抽象用例。
任何父用例出现的地方子用例也可出现。
1 对用例的描述。
1. 用例图：只能描述系统的大概功能，是一种视图。
2. 用例描述：更详细地描述用例的功能。
2 用例描述的组成
用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，扩展点，后置条件。
事件流：就是用例执行时，由一序列活动组成的控制流。
基本事件流：对用例中常规、预期路径的描述。
扩展事件流：主要是对一些异常情况、选择分支进行描述。
前置条件：在用例启动时参与者（actor）与系统应置于什么状态。
后置条件：用例结束时系统应置于什么状态。
以上述的"新增书籍信息"为例，说明如何细化用例描述。
1. 用例的概要描述
用例名称：新增书籍（UCO1）
简要说明：录入新购书籍信息，并自动存储建档。
事件流：基本事件流和扩展事件流。
非功能需求
前置条件：用户进入图书管理系统。
后置条件：完成新书信息的存储建档。
扩展点：无
优先级：高（满意度 5 ，不满意度5 ）
2. 详细描述
基本事件流
∙图书管理员向系统发出"新增书籍信息"请求。
∙系统要求图书管理员选择要增加的书籍是计算机类还是飞信计算接类∙图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号。
∙图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本。
页数、定价。
是否有CD-ROM。
∙系统确认输入的信息中书名没有重名。
∙系统将所输入的信息存档建档。
扩展事件流。
∙ A 如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理员选择修改书名或取消输入。
∙A（1）图书管理员选择取消输入，则结束用例，不做存储建档工作。
∙A（2）图书管理员选择修改书名后，转到A。
如下例所示建立用例模型。
有一个业务需求如下，要求我们为其构件一个用例图。
1）系统可以供教师使用来为学生记录成绩。
2）系统根据需要创建报告卡。
1. 系统允许用户浏览记录的成绩。
首先这里面要问到的是：11）中教师可以记录学生信息，这就是说教师可以录入、修改和删除学生信息了。
22）中系统要创建报告卡，是谁来创建报告卡呢？这里就应该有权限的问题了，系统需要管理人员来来执行这项工作，另一个方面做系统的维护工作。
报告卡创建后干什么？管理人员检查其准确性之后，由教师来分发报告卡。
33）系统允许用户浏览成绩，是谁可以浏览成绩呢？是学生和老师。
2. 从中得到这个系统的参与者是：教师，学生，管理员。
主要用例：录入成绩。
更新成绩。
生成报告卡。
报告卡准确性。
分发报告卡。
浏览成绩。
要区分用例的优先级。
首先是：记录成绩，浏览成绩，更新成绩，生成报告，检查报告卡的准确性，分发报告卡。
细化每一个用例。
对"记录成绩"进行细化，下面是对该用例的主事件流。
∙首先是教师要确定录入哪些学的成绩。
∙系统中要确保学生在数据库中。
∙教师说明记录哪像作业的成绩。
∙系统开始数据库的一些事物。
∙系统为学生把作业加入到数据库中。
∙教师输入学生作业的成绩。
∙系统核对输入的成绩是否符合正确的范围和格式。
∙系统记录作业的成绩。
∙系统结束事物的处理。
∙系统提示教师成绩已经记录好。
从细分的用例中发现新的用例，并根据优先级重新排列。
机房收费系统的用例图。
1、首先是分析系统中的角色（Actor）。
谁向系统提供信息？-----学生
谁从系统获取信息？----学生、管理员、操作员、一般用户
谁操作这个系统呢？--一般用户、操作员、管理员。
谁维护这个系统呢？---管理员。
系统要使用的外部资源？---数据库。
系统是否和已经存在的系统交互？---好像没有。
从中找出这个系统的Actor---（学生、一般用户、管理员、数据库）
1. 基本Use case。
找出的参与者希望系统执行什么任务？
学生---去注册卡号，后充值，上机，下机，付钱，查看信息（查看自己的个人信息，上机信息，卡内的余额信息），不想用了就注销卡号。
（学生的需求是要通过系统用户对系统的操作来完成的。
所以学生和系统用户这两个角色之间是关联关系。
）
一般用户—主要是用这个系统来管理学生上下机。
可以登录到系统中去，后学生刷卡上机，显示上机的学生的记录，显示登录时间，查看学生上机状态，学生下机，显示下机时间和消费金额，可以修改自己的密码，查询余额。
操作员---主要是用这个系统为学生进行注册充值以及查询一些信息。
登录到系统中去，可修改密码，根据学生的要求使用系统来，注册，充值，退卡，注册后充值可以查看收取金额，学生基本信息维护，学生上机统计信息，最后退卡时，查看金额退还信息来退还相应的钱数。
最后可以查看老师和自己的工作记录。
管理员---登录到系统中去，可以修改密码以确保安全性。
利用这个系统可以对学生的上下机情况查看。
可以对一般用户和操作员的工作记录查看。
参与者在系统中访问哪些信息（创建、存储、修改、删除等）？
参与者在系统中需要访问
需要将外界哪些信息供给系统？
外界提供给本系统的信息是---学生信息、系统时间信息、系统用户信息。
需要将系统的哪个事件告诉参与者？
……无……
如何维护系统？
管理员负责对系统的维护-----基本数据的设定。
用例图如下所示：
学生和一般用户的用例图。
学生和操作员的用例图。
学生和管理员用例图所示：。