uml用例图笔记 - 360文档中心

UML用例和用例图

h
18
主要内容
基本概念：Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流： • 1、系统显示ID和密码窗口； • 2、顾客键入ID和密码，然后按OK键； • 3、系统验证顾客ID和密码，并显示个人信息窗口； • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码，然
后按OK键； • 5、系统验证用户是否为老顾客； • 6、系统显示可以卖的商品列表； • 7、顾客在准备购买的商品图片上单击，并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则：尽可能写的“充分”，而不是追求写的形式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮； • 8、系统通过库存系统验证要购买的商品是否有足够库存； • …….（后续描述省略）
问题：对用户界面的描述过于详细，对于需求文档来说，详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case：Buy Something • 参与者：Customer • 主事件流： • 1、顾客使用ID和密码进入系统； • 2、系统验证顾客身份； • 3、顾客提供姓名、地址、电话号码； • 4、系统验证顾客是否为老顾客； • 5、顾客选择要购买的商品和数量； • 6、系统通过库存系统验证要购买的商品是否有足

UML用例图描述

用例“系统管理员登录”的描述
用例名称
系统管理员登录
标识符001用Fra bibliotek描述系统管理员通过设置的用户名和密码登录到学生管理系统
参与者
系统管理员
优先级
1
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
如果管理员登录成功，则可以对学生基本信息进行管理，包括录入，删除，修改，查询学生基本信息，并且可修改自己的密码；如果管理员登录不成功，则不能对学生基本信息进行操作。
2.系统管理员无用户名先进行注册，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
3.系统管理员忘记用户名和密码，通过手机动态密码进行验证，找回密码，再输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
被泛化的用例
无
被包含的用例
查学生基本信息
被扩展的用例
无
用例“查学生基本信息”的描述
基本操作流程
1.系统管理员进入学生管理系统
2.系统管理员输入用户名和密码
3.系统管理员提交输入信息
4.系统对系统管理员输入的用户名和密码进行有效性检查
5.系统管理员对学生基本信息进行操作
可选操作流程
1.系统管理员输入正确的用户名和验证码，错误的密码无法顺利登录，重新输入正确的用户名和密码顺利登录，并对学生基本信息进行操作
用例名称
查学生基本信息
标识符
002
用例描述
系统管理员输入要查看的学生的基本信息，系统显示该学生的详细信息
参与者
系统管理员
优先级
2
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
系统管理员输入学生的基本信息，可查看学生的详细信息

UML用例图-商家

二、角色：商家图表1子系统:我是商家2.1用例名：店铺设置2.1.1用例名：店铺信息设置行为者：商家前置条件：商家进入店铺设置项的店铺信息设置系统界面描述：（1）商家进入系统界面后，点击“店铺信息设置”按钮，页面将会出现系统中所存在的店铺信息设置的基本信息，商家可以选择“新增”按钮，查看店铺填写的信息并进行添加。

（2）若未完成店铺信息添加，可以选择“保存”按钮，下次可接着填写。

（3）对于信息状态为“未提交”的信息，商家可以选择“修改”按钮对暂存的信息进行修改，商家也可选择“删除”按钮，删除暂存的信息。

（4）若完成填写并通过系统校验，商家可以点击“提交”按钮，将店铺信息提交并完成填报。

说明：若对店铺信息的增删改未通过系统检验，无法提交后置条件：商家可完善店铺信息设置并能获取2.1.2用例名：版式设置行为者：商家前置条件：商家进入店铺设置项的版式设置系统界面描述：（1）商家进入系统界面后，点击“版式设置”按钮，页面将会出现系统中所存在的版式设置的基本信息，商家可以选择“更换”按钮，对店铺的模板和主题进行替换。

（2）若商家未进行“保存”设置，无法更改版式和标题（3）若商家点击“保存”按钮，店铺的模板和主题就会更新说明：未进行系统检验的不能替换版式的更新后置条件：商家可修改店铺的版式进行美化，也可以更新店铺的主题2.2用例名：交易管理2.2.1用例名：订单查看行为者：商家前置条件：商家进入交易管理项的订单查看系统界面描述：（1）商家进入系统界面后，点击“订单查看”按钮，页面将会出现系统中所存在的订单。

（2）商家可以点击“买家订单”按钮查看买家付款的订单；（3）商家可点击“售货订单”按钮，查看“发货的订单”和“已发货的订单”；（4）商家点击“交易订单”按钮，查看“已成功的订单”，“未成功的订单”和“退款中的订单”。

（5）商家可以点击“评价”按钮，对发货进行交易评价。

说明：生成的订单若不能打印成信息不能查看后置条件：商家可获得收获的订单对买家要求进行修改2.2.1.1用例名：交易评价行为者：商家—会员前置条件：商家进入交易评价界面描述：（1）商家点击“会员的交易评价或追加评价”按钮，可看到商品的评价信息（2）商家点击“回复交易评价或追加评价”按钮，可对会员进的评价行评价说明：交易评价或追加评价必须建立在商家—会员商品交易成功的基础上后置条件：商家可对评价的商品适当的添加受益的产品2.2.2用例名：发货管理2.2.2.1用例名：物流定制行为者：商家前置条件：商家进行交易管理项转向发货管理中的物流定制界面描述：（1）商家进入系统界面后，点击“物理定制”按钮，页面将会出现系统中所能浏览的库存物品，可点击“查看”按钮，查看客户的物流服务。

UML中数据流图，用例图，类图，对象图，角色图，活动图，序列图详细讲述保存供参考

UML中数据流图，⽤例图，类图，对象图，⾓⾊图，活动图，序列图详细讲述保存供参考这个⽂章，是我在急需的情况下在园⼦⾥搜索到的，原创作者是：DO-websoftware,为了⾃⼰看⽅便，所以复制到我的空间，希望原创者不要介意哦~~~~很详细的介绍，对我的帮助很⼤，谢谢哦。

类图，对象图，⾓⾊图：⼀、UML中基本的图范畴：在 UML 2 中有⼆种基本的图范畴：结构图和⾏为图。

每个 UML 图都属于这⼆个图范畴。

结构图的⽬的是显⽰建模系统的静态结构。

它们包括类，组件和（或）对象图。

另⼀⽅⾯，⾏为图显⽰系统中的对象的动态⾏为，包括如对象的⽅法，协作和活动之类的内容。

⾏为图的实例是活动图，⽤例图和序列图。

⼆、UML中的类图：1.类图的表⽰：类的 UML 表⽰是⼀个长⽅形，垂直地分为三个区，如图 1 所⽰。

顶部区域显⽰类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。

描述：顶部区域显⽰类的名字。

中间的区域列出类的属性。

底部的区域列出类的操作。

当在⼀个类图上画⼀个类元素时，你必须要有顶端的区域，下⾯的⼆个区域是可选择的（当图描述仅仅⽤于显⽰分类器间关系的⾼层细节时，下⾯的两个区域是不必要的）。

·类名：如果是抽象类，则采⽤斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式name : attribute type = default value 如 balance : Dollars = 0，这是带有默认值的表达形式·类⽅法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。

UML8种图——银行系统

银行系统UML 图一、用例图1.银行职员用例图登录管理账户修改账户2.客户与银行职员用例图Bank取款转账二、类图holder:String number:int type:Stringname:String ID:int数目：日期：数目：日期：ID:intname:String数目：日期：三、时序图1.登录时序图:LoginForm :MainForm Clerk2.创建登录对话框4.系统身份验证5.通过创建主界面2.存款时序图Clerk:MainForm:WithdrawForm:Account:Deposit2.请求存款操作3.修改账户时序图Clerk:LoginForm:QueryForm:AccountForm:Customer:Account1.进入主界面2.请求查询账户3.创建查询界面4.提交账号5.获得指定账户的信息6.创建账户界面7.修改账户信息8.更新账户信息9.更新账户信息Clerk:LoginForm :QueryFormCreateAccountAccount:Customer四、活动图1.银行职员登录活动图提示错误信息验证信息进入主界面N2.取款活动图验证账户是否存在且有效修改账户信息保存交易记录创建交易记录不存在或无效3.转账活动图提示错误信息验证账户是否存在且有效创建交易记录保存交易记录修改账户信息通知另一银行五、状态图六、协作图1.修改账户协作图提示错误信息验证账户是否存在且有效创建交易记录保存交易记录修改账户信息通知另一银行2.删除账户协作图Clerk:QueryForm:LoginForm七、系统组件图八、系统部署图。

UML（2）-用例图

UML（2）-⽤例图通过⽤例来捕获系统需求，然后结合参与者进⾏系统功能需求的分析和设计。

由参与者、⽤例及它们之间关系构成的⽤于描述系统功能的动态视图称为⽤例图。

⼀个椭圆，⽤例的名字可以放在椭圆的中⼼或椭圆下⽅的中间位置表⽰⼀个⽤例。

参与者⽤⼈型符号表⽰。

两者之间的关系⽤带箭头的线段描述，其中箭头所指⽅为被动接受者（可以⽤不带箭头的线段描述不带主被动关系）。

要注意的是：箭头的⽅向并不是指信息流的⽅向。

参与者与⽤例之间的信息流默认存在，是双向的。

（⼀）⽤例图的作⽤⽤例图的主要作⽤是描述参与者和⽤例之间的关系，帮助开发⼈员可视化的了解系统功能。

传统的需求表述⽅式是Software Requirment Specification（软件需求规约，SRS），采⽤功能分解⽅式来描述系统功能，将系统功能分解到各个系统功能模块中，然后通过描述每个模块的功能来达到描述整个系统功能的⽬的。

软件需求规约容易混淆需求和设计的界限，导致需求分析包含部分概要设计；通过分割了的系统功能难于表现实现⼀个完整的系统服务。

⽤例图可视化的表达了系统的需求，且把需求与设计分离开。

（⼆）⽤例图构成（1）参与者（Actor）参与者指存在于系统外部且直接与系统进⾏交互的⼈、系统、⼦系统或类的外部实体的抽象。

通过⼈形图来表⽰参与者，参与者的名字在图的下⽅。

参与者是⼀种⾓⾊，⽽不是具体的⼈或事物本⾝。

参与者之间的关系主要是泛化关系，也就是继承关系。

继承关系通过空⼼三⾓箭头的实线段表⽰。

（2）⽤例（Use Case）⽤例是参与者可以感受到的系统服务或功能单元。

它是以⽤户的⾓度上来描述系统功能。

参与者与⽤例之间的关系是关联关系，也称为通信关联。

参与者是⼀种⾓⾊，⽤例不是具体实例，⽽是表⽰⼀个类。

⽤例包含的系统功能有⼤有⼩，这就是⽤例的粒度，粒度⼤，⽤例包含的功能多。

⽤例的粒度重要的是⼀个度。

它决定了⽤例模型级的复杂度，也决定了每个⽤例内部的复杂度。

2.设计模式常用的UML图分析（用例图、类图与时序图）

2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。

2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。

⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。

1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。

不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。

系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。

系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。

箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。

⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。

⽗⽤例通常是抽象。

箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。

表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。

注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。

图书馆管理系统UML用例图

图书馆管理系统系统描述、用例图及用例描述
姓名：***
学号：**********
班级：2012级网工班
图书管理系统是应用于图书馆的人机互动系统。

该系统使图书馆变得信息化，它能有效协作图书馆的工作人员管理图书馆的各项信息，同时还能方便读者快速地查询、借阅和归还图书，极大地提高了图书馆的管理效率和服务质量。

二、用例图：
1
2
3
4
5
6
主要参与人系统管理员
次要参与人无
前置条件以系统管理员身份登录系统。

后置条件图书信息中增加一条信息。

基本操作流程 5.系统管理员登录系统。

6.系统管理员选择新增、修改或删除读者信息。

7.系统管理员对读者信息进行修改。

8.保存操作。

可选流程保存之前可自行取消操作。

四、领域类图
7
五、术语表
读者
持有图书证的在校学生。

图书馆工作人员
包括图书管理员和系统管理员，有账号作为身份标识。

图书管理员主要负责引导读者借阅和归还书籍，负责收取逾期罚金。

而系统管理员主要负责图书信息和读者信息的更新。

信息管理
由图书管理员进行，读者管理主要包括新增、修改和删除读者信息。

图书管理主要包括新增、修改和删除书籍信息。

数据存储
是整个图书管理系统的数据中心，在数据库中存储各项和书籍有关的活动，包括工作人员信息、读者信息、书籍信息、借书还书记录等。

六、借书活动图
8
9。

UML九种图之用例图和类图

UML九种图之⽤例图和类图前⾔近期写UML⽂档，看视频的时候感觉掌握的还能够，当真正写⽂档的时候才发现不是⼀件easy的事。

写⽂档⾃⼰⼜翻开⾃⼰的笔记看了⼀遍⼜⼀遍。

以下就给⼤家介绍⼀下我画的⼏张图：⽤例图1. ⽤例图的构成（⽤例，⾓⾊，关系）⽤例：指功能的描写叙述⾓⾊：触发起某种事件关系：⽤例图的关系（依赖，泛化，关联）2. ⽤例图的作⽤（1）⽤例视图是整个UML设计的关键，影响到整个UML设计的过程（2）⽤例模型驱动了需求分析后各个阶段的开发（3）⽤例模型⽤于需求分析阶段，表明了开发⼈员和⽤户针对需求达成的某种共识注意⼏个keyword：开发⼈员，⽤户，共同商讨达成某种共识3.设计原则将系统看做⿊盒⼦，从⽤户⾓度理解系统，不须要考虑某个功能是怎样实现的。

仅仅须要考虑系统由谁来运⾏和怎样交互和运⾏。

以下是我画的⽤例图：以⽤户的权限为基础画出来的。

类图1.类图的构成类、接⼝、协作、关系、包2.类的构成2.类图的作⽤类图⼀般在具体设计过程中出现，主要⽤来描写叙述系统中各个模块中类之间的关系，包含类或者类与接⼝的继承关系，类之间的依赖、聚合等关系。

通过类图，就能实际的把系统中的各个类，即对象描写叙述清楚，下⼀步就是依照这个具体的设计编码了。

3.类图的设计Use case——>class（要点，抽象名词得到类）——>确定类的属性和⽅法——>属性是静态⾏为描写叙述，⽅法是动态⾏为的描写叙述——>正确表达类与类之间的关系以下是我对机房收费系统设计的类图，理解的不是⾮常清楚，可定存在诸多问题，希望⼤家积极指正。

以上是我看完UML之后对⽤例图和类图的理解，感觉理解的不是⾮常清楚，若有什么问题希望⼤家积极指正。

StarUML详解（Copy）

StarUML详解（Copy）UML(Unified Modeling Language) -- 早期笔记37⼈收藏此⽂章,发表于5天前(2012-08-16 18:42) , 已有541次阅读共个评论UML学习笔记系统的创建步骤：分析、设计与实现⽐例在分析阶段，需向⾏业专家请教，需要问问⾃⼰，谁是系统的最终⽤户UML（统⼀建模语⾔）是⼀种系统建模⽅法，有两个主要构件 -- 结构图和⾏为图⼯具：⼀、⽤例图1、说明1.1 ⽤例图说明的事谁要使⽤系统以及他们使⽤该系统可以做些什么？<业务需求>1.2 解析⼀个⽤例图，我们可以发现它包含4个基本组件：系统参与者⽤例(功能)关系另外可以通过在⽤例前⾯加上包名和两个冒号来确定该⽤例是属于哪个包的。

如：staff::mechanic。

如果⽤多个参与者与⽤例之间有同⼀关系，可以重新考虑为⽤户选择的在系统中扮演的⾓⾊的名称。

使名称更为⼴泛化，以⼀个参与者取代重复的参与者。

2、包含⽤例图⽤虚线和箭头连接，起始处为包含⽤例，终⽌处为被包含⽤例。

包含关系⽤于表⽰⽤例为执⾏其功能从其他⽤例引⼊功能。

（重⽤某些功能）教师必须记录成绩，更新成绩。

这两个⽤例都从⼀个⽤例包含了⼀项为save grades的公⽤功能，成绩总会被保存。

3、扩展关系（继承）表⽰⽤例可以通过其他⽤例得到扩展Notify guardians ⽤例是添加到save grades 功能中的⼀项功能。

与包含关系相⽐，⽤例必须包含被包含⽤例，⽽扩展关系则有是否使⽤被扩展功能的选择权。

4、创建⽤例图步骤找出系统中的参与者和⽤例区分⽤例的优先次序细分每个⽤例（描述）建⽴⽤例模型结构建⽴⽤户界⾯的原型PS：软件开发过程泛化⼆、活动图⽤于⾯向对象的系统的不同组件之间建模⼯作流1、作⽤进⼀步规划⽤例标识⽤例的前后条件发现新⽤例2、组件：活动，指⽰动作状态，指⽰系统当前状态（在StarUML⾥⾯，状态和活动是同⼀个标识，其实状态图应该是⼀个矩形四个⾓为⼩圆弧）转意，显⽰从⼀种状态到另⼀种状态的控制流UML描述了两个特殊状态，即开始状态和结束状态。

UML旅店管理系统用例图、用例规约

UML旅店管理系统⽤例图、⽤例规约
⼀.旅店管理系统⽤例图
⼆．⽤例规约
1.预定房间
1 .1简要说明
本⽤例允许客户预订旅店的未被预订的房间，系统提供未被预订的房间的信息列表。

1.2 先置条件
客户进⼊旅店管理系统，并选择预订房间功能。

1.3 事件流
（1）基本事件流
A 客户选择要预订的房间的类型，双⼈间或单⼈间。

B 根据客户选择的房间类型，从所有该类型房间中，筛选未被预定的房间，将这些房间的信息列表显⽰，供客户查询。

C 客户选定房间，并输⼊要预订的天数。

（2）备选事件流
A 客户所需要类型的房间已全部被预订，则提⽰客户，该类型房间已全部被预订，询问客户是否选择另⼀类型的房间。

B ⽤户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发⽣冲突，则系统提⽰，该房间在哪些⽇期⾥已被预订，并询问当前客户是更换房间还是修改预订天数。

1.4 后置条件
A 客户选择房间和预订天数并确认后，系统要求客户输⼊客户信息，包括客户的姓名、地址、联系电话、有效证件号。

另外，系统将计算出客户需要缴纳
的定⾦和总费⽤，并显⽰出来。

B 客户重新选择房间类型，或修改天数，则刷新⽤户界⾯。

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设置到你的⽂档上；这样当你在⽤例图上双击项⽬时，就会打开相关联的⽂档。

UML 用例图、关系图、活动图

网上查询读者扩展预定扩展
查询图书馆工作人员取消预定
还书
通知
借书
武当山旅游门户网站（）分类信息
注意

在画用例图时要特别注意：用例图是系统分析、设计和实现的一个最基础的图形，在初期是不一定要考虑太多的处理细节。一个用例内部的具体处理细节是由其他图形工具描述的，用例图只是反映系统的总体功能，以及与这些功能的相关的角色。有些人可能在画“借书”用例时，情不自禁地就考虑了“输入读者号和书号”，“检查图书是否在库？”，“图书数量减1”，“添加读者借书记录”等等，一旦考虑了这些细节，就会发现用例图画不下去了。因此，读者注意用例图中不要考虑处理细节。
武当山旅游门户网站（）分类信息
注意：

活动图描述多个角色之间的处理非常有效，一张活动图只能有一个开始状态，但可以有多个结束状态。一个活动可以与多个实体对象相关，这里的相关指的是一种访问操作。在上面 “借书”活动图中，“检查读者有效” 的活动，要访问“读者”对象和“借还书记录”对象，检查“读者编号”的有效性和读者借书数量。
状态图中的转移可以由三部分组成：事件[条件]/动作
武当山旅游门户网站（）分类信息
角色

角色是指与系统交互的人或物。角色可以有四种类型：系统的使用者、硬件设备、外部系统和时间。

系统使用者是最重要的角色，例如，在图书信息管理系统中的系统使用者有读者和图书馆的工作人员，包括采购、编目和办公室的工作人员。其他外部应用系统。硬件设备，不同的硬件设备具有不同的特性和不同的处理方式。时间作为角色,经过一定的时间触发系统中的某个事件。
认识活动图认识活动图图书馆图书信息管理系统借书活动图图书馆图书信息管理系统借书活动图借书申请检查读者有效性读者信息借书记录读者无效图书无效检查图书有效性检查预订预订记录清除预订记录图书信息借书记录修改图书信息创建借书记录图书信息读者无效借书超期图书无效有预订读者流通组工作人员读者图书编号活动图中的主要图形元素活动图中的主要图形元素泳道

UML各种图总结-精华

UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。

一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。

静态图分为：用例图，类图，对象图，包图，构件图，部署图。

动态图分为：状态图，活动图，协作图，序列图。

1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。

2、软件的功能。

从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。

2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。

在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。

各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。

例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。

2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。

双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。

UML有关用例图知识及用例关系

UML有关⽤例图知识及⽤例关系1. 如何识别⽤例任何⽤例都不能在缺少参与者的情况下独⽴存在。

同样，任何参与者也必须要有与之关联的⽤例。

所以识别⽤例的最好⽅法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。

可以通过以下问题来寻找⽤例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者⼜是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发⽣的事件是否通知参与者？ (5)是否存在影响系统的外部事件。

2.⽤例的粒度⽤例的粒度指的是⽤例所包含的系统服务或功能单元的多少。

⽤例的粒度越⼤，⽤例包含的功能越多，反之则包含的功能越少。

如果⽤例的粒度很⼩，得到的⽤例数就会太多。

反之，如果⽤例的粒度很⼤，那么得到的⽤例数就会很少。

如果⽤例数⽬过多会造成⽤例模型过⼤和引⼊设计困难⼤⼤提⾼。

如果⽤例数⽬过少会造成⽤例的粒度太⼤，不便于进⼀步的充分分析。

3.⽤例规约对于每⼀个⽤例，我们还需要有详细的描述信息，以便让别⼈对于整个系统有⼀个更加详细的了解，这些信息包含在⽤例规约之中。

每⼀个⽤例的⽤例规约都应该包含以下内容： (1)简要说明:对⽤例作⽤和⽬的的简要描述。

(2)事件流:事件流包括基本流和备选流。

基本流描述的是⽤例的基本流程，是指⽤例“正常”运⾏时的场景。

(3)⽤例场景:同⼀个⽤例在实际执⾏的时候会有很多不同的情况发⽣，称之为⽤例场景，也可以说⽤例场景就是⽤例的实例。

(4)特殊需求: 特殊需求指的是⼀个⽤例的⾮功能性需求和设计约束。

特殊需求通常是⾮功能性需求，包括可靠性、性能、可⽤性和可扩展性等。

例如法律或法规⽅⾯的需求、应⽤程序标准和所构建系统的质量属性等。

(5)前置条件: 执⾏⽤例之前系统必须所处的状态。

例如，前置条件是要求⽤户有访问的权限或是要求某个⽤例必须已经执⾏完。

(6)后置条件:⽤例执⾏完毕后系统可能处于的⼀组状态。

02 UML用例图基础知识

表示符号
表示参与者与用例之间的通信，任何一方都可发送或接收消息。
uc 继承关系，子用例将继承基用例的所有行为、关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。
泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。 uc Use Case Model
参与者总是处在正在建模的系统的外部，不是系统
的组成部分，是与系统、子系统或类发生交互的外部用户、进程或其他系统。
参与者有3大类，即系统用户、与本系统交互的其他系统和一些可以运行的进程。
名称
说明
人
即用户，是最常用的参与者。例如，汽车租赁公司的汽车租赁者，即客
户。
其他的系统
在当前的项目范围外，建立与其他系统的接口。该类位于程序边界之外
注：任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的
用例。
2）用例图形表示
在UML中，用例使用一个椭圆来表示，用例的名称写在椭圆里，如下图所示：
3）用例命名
用例是从用户的角度来描绘系统的功能，是根据所执行的实例来命名的，通常情况下，用例名是一个短语，例如浏览帐户、登陆系统等。命名的基本原则有以下几种：
一、什么是用例图（Use Case Diagram）二、用例图的组成三、用例建模技术
用例图也称为用户模型图，是由软件需求分析到最终实现的第1步，它是从用户的角度来描述系统功能，描述人们希望如何使用一个系统。用例图显示谁将是相关的用户、用户希望系统提供什么服务，以及用户需要为系统提供的服务。
线上标注<u<c Usee CaxsetMoedenl d>>)，箭头从子用例指向基用
例。

UML之用例图

初学UML之-------用例图分类：UML Modeling2007-10-16 04:37 58803人阅读评论(48) 收藏举报一．UML简介UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。

它融入了软件工程领域的新思想、新方法和新技术。

它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。

在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。

其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二．用例建模简介用例建模是UML建模的一部分，它也是UML里最基础的部分。

用例建模的最主要功能就是用来表达系统的功能性需求或行为。

依我的理解用例建模可分为用例图和用例描述。

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

用例描述用来详细描述用例图中每个用例，用文本文档来完成。

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

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

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

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

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

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

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

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