UML 用例图、关系图、活动图
浅谈UML中常用的几种图
浅谈UML中常用的几种图1 UML简介2 UML常见图分类3 用况图（用例）4 类图简单类图使用举例5 其他辅助用图●时序图(顺序图)●协作图（Collaboration Diagram/communication Diagram）/通信图●状态图●活动图(Activity Diagram)6 组件图(ComponentDiagram)、配置图(Deployment Diagram)1 UML简介统一建模语言（Unified Modeling Language，UML）又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
‘UML感兴趣的可以阅读UML 1规范，包含了UML 的所有知识内容。
注：OMG, Object Management Group 对象管理组织2 UML常见图分类UML从考虑系统的不同角度出发，定义了用况图、类图、对象图、包图、状态图、活动图、序列图、通信图、构件图、部署图等10种图。
分类：面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。
“序列图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。
•静态结构图Static Structure Diagram•类图Class Diagram•对象图Object Diagram•用况图Use Case Diagram•交互图Interaction Diagram•顺序图Sequence Diagram•协作图Collaboration Diagram•状态图State chart Diagrams•活动图Activity Diagrams•实现图Implementation Diagrams•构件图Component Diagram•部署图Deployment Diagram3 用况图（用例）用例图，展现了一组用例、参与者（actor）以及它们之间的关系。
UML科普文，一篇文章掌握14种UML图
UML科普⽂，⼀篇⽂章掌握14种UML图前⾔上⼀篇⽂章写了⼀篇建造者模式，其中有⼏个UML类图，有的读者反馈看不懂了，我们今天就来解决⼀哈。
什么是UML？UML是Unified Model Language的缩写，中⽂是统⼀建模语⾔，是由⼀整套图表组成的标准化建模语⾔。
为什么要⽤UML？通过使⽤UML使得在软件开发之前，对整个软件设计有更好的可读性，可理解性，从⽽降低开发风险。
同时，也能⽅便各个开发⼈员之间的交流。
UML提供了极富表达能⼒的建模语⾔，可以让软件开发过程中的不同⼈员分别得到⾃⼰感兴趣的信息。
Page-Jones 在《Fundamental Object-Oriented Design in UML》⼀书中总结了UML的主要⽬的，如下：1. 为⽤户提供现成的、有表现⼒的可视化建模语⾔，以便他们开发和交换有意义的模型。
2. 为核⼼概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
3. 独⽴于特定的编程语⾔和开发过程。
4. 为了解建模语⾔提供⼀个正式的基础。
5. ⿎励⾯向对象⼯具市场的发展。
6. ⽀持更⾼层次的开发概念，如协作，框架，模式和组件。
7. 整合最佳的⼯作⽅法 (Best Practices)。
UML图有哪些？UML图分为结构图和⾏为图。
结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。
⾏为图⼜分活动图、⽤例图、状态机图和交互图。
交互图⼜分为序列图、时序图、通讯图、交互概览图。
UML图概览什么是类图？【概念】类图是⼀切⾯向对象⽅法的核⼼建模⼯具。
类图描述了系统中对象的类型以及它们之间存在的各种静态关系。
【⽬的】⽤来表⽰类、接⼝以及它们之间的静态结构和关系。
在类图中，常见的有以下⼏种关系。
泛化（Generalization）【泛化关系】是⼀种继承关系，表⽰⼦类继承⽗类的所有特征和⾏为。
【箭头指向】带三⾓箭头的实线，箭头指向⽗类。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明书画法和功能
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
UML 用例图、关系图、活动图
例如，一个银行系统中，有
一个“验证用户”用例，用 身份认证
于验证用户的合法性，它有
两 个 特 殊 的 子 用 例 ， 一 个 是 密码认证
指纹认证
“检查密码”，另一个是
“检查指纹”，它们都有父
用例“验证用户”的行为，
并且可以出现在父用例出现
的任何地方，还可以添加自
己的行为。
用例图实例
• 以前面图书信息管理系统为例，画出用例 图。先找出参与系统地的角色：
• 扩展关系——允许一个用例扩展另一个用
例的功能。例如，在图书信息管理系统中，
读者还书时，系统检查所还图书是否有预
订记录，如果有则执行“通知”用例。在
UML中扩展关系表示为箭头和《extend》形
式。
《extend》
还书
通知
管理员
读者
注意
• 使用关系和扩展关系之间的区别，A使用B 本质上是A一定使用B，同时增加自己的专 属行为；而A被用例B扩展是说明A是一个一 般用例，B是一个特殊用例，A在某些条件 下可能使用B。
（2）取消预订——本用例提供取消预订图书的功能。
（3）还书——完成还书任务，在还书是要检查所还的书是否超 期、是否有其他读者预订，有的话要通知预订者。
（4）借书——提供借阅书功能 。
• 分析这个用例图，发现“还书”用例应该 被扩展，因为在还书时检查所还图书是否 有预订记录，若有，则应该通知预订者前 来借书。
• 一个用例内部的具体处理细节是由其他图形工具描述 的，用例图只是反映系统的总体功能，以及与这些功 能的相关的角色。有些人可能在画“借书”用例时， 情不自禁地就考虑了“输入读者号和书号”，“检查 图书是否在库？”，“图书数量减1”，“添加读者借 书记录”等等，一旦考虑了这些细节，就会发现用例 图画不下去了。因此，读者注意用例图中不要考虑处 理细节。
UML概述ppt课件精选全文
注释体 用于对UML实体进行文字描述
注释连接
注释连接将注释体与要描述的实体相连。说 明该注释体是对该实体所进行2-
协作图（通讯图）
协作图表示一组对象间关系以及交互活动
协作图可以认为是对象图的扩展，它增加了一些符号用于表 示对象间的交互。协作图和顺序图具有同构性。
指向源同步 消息
表示对象间从目的对象向源对象发送同步消息
指向目的的 同步消息
表示对象间从源对象向目的对象发送同步消息
注释体
注释连接
-35-
示例：协作图
-36-
活动图
活动图：通过动作来组织，主要用于描述某一方法、机制或 用例的内部行为
主要使用场合：业务建模、用例分析
-37-
活动图元语-1
活动 组合活动
1997.1公布 UML 1.0 合作伙伴
业
公
意见
众 1996.6和1996.10 UML 0.9&0.91
化
反
馈 OOPSLA95 Unified Method 0.8
标
准
Booch93 OMT-2
化
Booch91 OOSE
OMT-1 其他方法 统
一
UML基本图
静态模型 (系类统图结 构) class diagrams
转移
用于说明两个对象间存在某种关系，如满足某 个条件并当某一事件发生时，对象将从一个状 态变迁到另一个状态并同时执行一些活动
注释体
注释连接
示例：状态图
顺序图
顺序图：主要用于显示对象间的交互活动，但没有明确的交 互环境和对象状态
主要使用场合：系统分析（用例分析）、设计
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注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
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各种图例—用例图、类图、状态图、包图、协作图、顺序图
UML各种图例——用例图、类图、状态图、包图、协作图、顺序图面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.∙决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型. dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.。
软件工程---UML动态分析-活动图
Make Plan
entry/ SetGoal
2020/5/4
26
动作流
与状态图不同，活动图的转换一般都不需要特 定事件的触发。
一个动作状态执行完本状态需要完成的动作后 会自发转换到另外一个状态。
2020/5/4
27
动作流
一个活动图有很多动作或者活动状态，
活动图通常开始于初始状态，然后自动转换到 活动图的第一个动作状态，一旦该状态的动作 完成后，控制就会不加延迟地转换到下一个动 作状态或者活动状态。
7
活动图与流程图的区别
⑴ 流程图着重描述处理过程，它
的主要控制结构是顺序、分支 和循环，各个处理过程之间有 严格的顺序和时间关系
找饮料 [ 发现咖啡 ]
活动图描述的是对象活动的顺序
把咖啡放入 滤器
关系所遵循的规则，它着重表 将滤器放入 现的是系统的行为，而非系统 机器
的处理过程。
往容器里加 水
开机器
活动图着重表现从一个活动到另一个活动的控制流， 是内部处理驱动的流程。
找饮料
[ 发现咖啡 ]
[ 没有咖啡 ] [ 发现可乐 ]
把咖啡放入 滤器
往容器里加 水
拿茶杯
拿可乐
将滤器放入 机器
[ 没有可乐 ]
开机器 冲咖啡
倒咖啡
喝饮料
2020/5/4
12
活动的图形表示
在UML中，活动表示成圆角矩形，与状态的圆角矩 形相比，活动的矩形的圆角更柔和，看上去接近椭 圆。
不能中断，一直运行到结束。 ⑶ 动作状态是瞬时的行为，它所占用的处理时
间极短，有时其至可以忽略。
2020/5/4
19
动作状态
动作状态有如下特点：
uml习题的名词解释
uml习题的名词解释UML（统一建模语言）习题的名词解释导语：统一建模语言（UML）作为一种广泛应用于软件工程领域的建模语言，被广泛应用于系统建模、软件开发和系统分析等方面。
本文将对UML习题中常见的名词进行解释，帮助读者更好地理解和应用UML。
1. 用例图（Use Case Diagram）用例图是一种将系统功能和与之相关的各个角色之间的关系进行图形化表示的方法。
它主要描述了系统中的各个用例（用户操作场景）以及用例之间的关系，用于展示系统的功能和参与者之间的交互。
2. 类图（Class Diagram）类图是一种静态结构图，用于表示系统中的类、类之间的关系以及属性和方法。
它能够展示系统中的对象、类和他们之间的关系，帮助开发人员进行系统设计和编码。
3. 序列图（Sequence Diagram）序列图是一种用于描述对象之间交互的图形化表示方法。
它主要展示了不同对象之间的消息传递顺序和时序，以及这些消息在交互中所扮演的角色。
4. 活动图（Activity Diagram）活动图是一种图形化表示系统中业务流程的方法。
它主要描述了系统中各个活动（任务）之间的顺序关系、执行顺序和条件分支等，用于展示系统中的业务过程和操作流程。
5. 状态图（State Diagram）状态图是一种用于展示系统中各个对象的状态和状态之间转换关系的方法。
它主要描述了对象在不同状态下的行为，以及对象在不同状态间如何转换的规则和条件。
6. 构件图（Component Diagram）构件图是一种用于描述系统中各个构件（组件）之间的关系和依赖的方法。
它主要展示了系统中的构件、构件之间的通信和依赖关系，有助于开发人员进行系统的模块化设计和组件复用。
7. 部署图（Deployment Diagram）部署图是一种用于描述系统中各个物理节点之间关系的方法。
它主要展示了系统中的硬件设备、软件分发和配置等方面的信息，帮助开发人员了解系统的部署情况和硬件支持。
UML用例图关系图活动图
取钱
《include》
《include》
查询
验证用户密码
更改密码
《include》
用例之间的关系（续）
? 扩展关系——允许一个用例扩展另一个 用例的功能。例如，在图书信息管理系 统中，读者还书时，系统检查所还图书 是否有预订记录，如果有则执行“通知” 用例。在UML中扩展关系表示为箭头和 《extend还》书 形式《e。xtend 》 通知
用例图练习
? 下面是关于一个公司的人事信息管理系统的需求的 简单描述, 建立其相应的用例模型 : 该人事管理系统 的用户是公司的人事管理干部 . 该系统具有人事档 案库, 保存员工的人事信息 , 包括姓名, 性别, 出生年 月, 健康状况, 文化程度, 学位, 职称, 岗位, 聘任时 间, 任期, 工资, 津贴, 奖罚记录, 业绩, 论著和家庭 情况等, 系统提供的基本服务有 人事信息的管理 , 包 括人事规定的调动与聘任 , 职称评定, 奖罚等, 并且 可以按照限查询人事信息 , 生成与输出统计报表 等. 该人事系统每月向公司的财务系统提供员工的工资 , 津贴等数据 .
外部系统和时间。
? 系统使用者是最重要的角色，例如，在图书信息管理系 统中的系统使用者有读者和图书馆的工作人员，包括采 购、编目和办公室的工作人员。
? 其他外部应用系统。 ? 硬件设备，不同的硬件设备具有不同的特性和不同的处
理方式。 ? 时间作为角色 ,经过一定的时间触发系统中的某个事件。
关系——角色与用例之间的关
管理员
读者
注意
? ?使用关系和扩展关系之间的区别， A使 用B本质上是 A一定使用 B，同时增加自己 的专属行为；而 A被用例B扩展是说明 A是 一个一般用例， B是一个特殊用例， A在 某些条件下可能使用B。
图书管理系统UML图
图书管理系统UML图案例：图书管理系统一、图书管理系统功能描述图书管理系统能够对图书进行注册登记，也就是将图书的基本信息（如编号、书名、价格、作者等）预先存入数据库中，供以后检索，并且能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。
同时，图书管理系统提高方便的查询方法。
如以书名、作者、出版社、出版时间等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式等信息。
图书管理系统提供对书籍进行预订的功能，也提供旧书销毁功能，对于淘汰、损坏、丢失的书名可及时对数据库进行修改。
图书管理系统能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。
总的来说，图书管理系统主要包含下列功能。
1）读者管理：读者信息的制定、输入、修改、查询，包括种类、性别、借书数量、借书期限、备注等。
2）书籍管理：书籍基本信息制定、输入、修改、查询，包括书籍编号、类别、关键词、备注。
3）借阅管理：包括借书、还书、预订书籍、续借、查询书籍、过期处理和书籍丢失后的处理。
4）系统管理：包括用户权限管理、数据管理和自动借还机的管理。
二、图书管理系统用例图确定参与者1.本系统的参与者包括两个：读者、管理员。
2.确定用例管理员包括的用例：1）登录系统：管理员可以通过登录该系统进行各项功能的操作。
2）书籍管理：包括对书籍的增删改查操作。
3）书籍借阅管理：包括借书、还书、预订、书籍逾期处理和书籍丢失处理4）读者管理：包括对读者的增删改查操作。
读者包括的用例：1）登录系统。
2）借书。
3）还书。
4）查询：包括对个人信息和书籍信息的查询业务。
5）预订：读者对书籍的预订业务。
6）逾期处理：书籍过期缴纳罚金等。
7）书籍丢失处理：对书籍丢失后的不同措施进行处理。
8）自动借书机的使用。
3.用例图三、图书管理系统用例规约借书用例规约1.用例名称借书UC01ID用例本用例描述读者通过管理员借书的过程。
企业综合信息管理系统UML需求建模(用例图+活动图)
2020/11/27
管理课件
5
（4）系统运行的软件、硬件环境 1）系统运行的软件环境 2）系统运行的硬件环境
3.6.2 确定系统范围和系统边界
1．进销存管理子系统的业务范围 2．进销存管理子系统的系统边界
3.6.3 确定执行者
“进销存管理子系统”有5个人执行者和2个系统执行 者，即“采购人员”、“销售人员”、“仓库管理 员”、“客户”、“公司经理”、“生产调度管理子 系统”和“财务管理子系统”。
管理课件
2
（2）采购管理
1）制定原材料（零部件）采购计划 2）与客户签订采购合同 3）检查合同履约率 4）库存管理部门对原材料进行入库验收、存储 5）财务管理部门支付货款
（3）库存管理
1）产品入库管理 2）原材料（零部件）入库管理 3）原材料（零部件）出库管理 4）产品出库管理 5）库存管理 6）采购管理部门组织采购 7）生产调度管理部门安排生产 8）财务管理部门对库存物资进行核算
1．“增加销售合同”用例
用例编号：04010101（共有4层用例图结构，每层用2位数字表 示， 采用8位编号。）
用例名： 增加销售合同 执行者: 人执行者：合同管理员、客户、公司经理。系统执
行者：“财务管理子系统”和Байду номын сангаас生产调度管理子系
统”。
目 的: 合同管理员将与客户签订的销售合同的详细内容录 入管理系统，用于对销售合同进行统计、查询、检查 是否履约等，监控正在履约的合同。
类 型： 端点、主要的、基本的 级 别： 一级
2020/11/27
管理课件
14
过程描述：
（1）合同管理员输入标识码（ID），系统识别标识码的有效
性；
（2）初始化一个新销售合同，设置各种处室标志；
UML的图和关系
3、导图概述
4、用例图（机房收费系统）
（二）、类图
1、定义:是由若干类关联在一起，反映系统 或者子系统组成结构的静态图。 2、简要介绍:类图的建模贯穿工程的分析和 设计阶段的始终。 类图是用来描述系统的静态部分。
3、导图概述
4、类图（机房收费系统）
（三）、对象图
1、定义:对象图描述一个系统在某个具体时刻 的静态结构。 2、简要介绍：对象图实际上就是类图的实例。 对象图表示一组对象及他们之间的联系，它是 系统的详细状态在某一时刻的快照，常用于表 示复杂类图的一个实例。 UML中对象图与类图具有相同的表示形式。 在UML中，对象图的使用相当有限，主要用于 表达数据结构的实例，以及了解系统在某个特 定时刻的具体情况。
3、导图概述
4、状态图（机房收费系统-注册）
（五）、活动图
1、定义：阐明业务用例实现的工作流程。 2、简要介绍：活动图是UML用于对系统的动 态行为建模的另一种常用工具，它描述活动的 顺序，展现从一个活动到另一个活动的控制流。 活动图在本质上是一种流程图。活动图着重表 现从一个活动到另一个活动的控制流，是内部 处理驱动的流程。 活动图描述的是对象活动的顺序关系所遵循的 规则，它着重表现的是系统的行为，而非系统 的处理过程。活动图能够表示并发活动的情形， 活动图是面向对象的。
3、导图概述
4、活动图（机房收费系统-注册）
（六）、序列图（又称顺序图，时序图）
1、定义：是对对象之间传送消息的时间顺序的可 视化表示。 2、简要介绍：序列图的目的在于描述系统中各个 对象按照时间的顺序的交互过程。 序列图将交互关系表示为一个二维图。纵向是时间 轴，时间沿竖线向下延伸。横向轴代表了在协作中 各独立对象的类元角色。类元角色用生命线表示。 当对象存在时，角色用一条虚线表示，当对象的过 程处于激活状态时，生命线是一个双道线。 消息用从一个对象的生命线到另一个对象生命线的 箭头表示。箭头以时间顺序在图中从上到下排列。
UML的九种模型图
UML的九种模型图本⽂转⾃，仅供学习交流！⼀、作为⼀种建模语⾔，UML的定义包括UML语义和UML表⽰法两个部分。
UML语义：描述基于UML的精确元模型定义。
UML表⽰法：定义UML符号的表⽰法，为开发者或开发⼯具使⽤这些图形符号和⽂本语法为系统建模提供了标准。
这些图形符号和⽂字所表达的是应⽤级的模型，在语义上它是UML元模型的实例。
⼆、标准建模语⾔UML可以由下列5类图来定义。
⽤例图：从⽤户⾓度描述系统功能，并指出各功能的操作者。
静态图：包括类图和对象图。
类图描述系统中类的静态结构，不仅定义系统中的类，表⽰类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是⼀种静态关系，在系统的整个⽣命周期都是有效的。
对象图是类图的实例，⼏乎使⽤与类图完全相同的标识。
⼀个对象图是类图的⼀个实例。
由于对象存在⽣命周期，因此对象图只能在系统某⼀时间段存在。
⾏为图：描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图。
状态图描述类的对象所有可能的状态以及事件发⽣时状态的转移条件，状态图是对类图的补充，活动图描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系，有利于识别并进⾏活动。
交互图：描述对象间的交互关系，包括时序图和协作图。
时序图显⽰对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显⽰对象之间的交互；协作图描述对象间的协作关系，协作图跟时序图相似，显⽰对象间的动态合作关系。
除显⽰信息交换外，协作图还显⽰对象以及它们之间的关系。
如果强调时间和顺序，则使⽤时序图；如果强调上下级关系，则选择协作图。
实现图：包括组件图和部署图。
组件图描述代码部件的物理结构及各部件之间的依赖关系，组件图有助于分析和理解部件之间的相互影响程度；部署图定义系统中软硬件的物理体系结构。
采⽤UML来设计系统时，第⼀步是描述需求；第⼆步根据需求建⽴系统的静态模型，以构造系统的结构；第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的，包括⽤例图、类图、对象图、组件图和部署图等5种图形，是标准建模语⾔UML的静态建模机制。
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 10 种图的总结
UML 2.0共有10种图，分别为表示系统静态结构的静态模型（包括类图、组合结构图、部署图），以及表示系统动态结构的动态模型（包括用例图、序列图、对象图、协作图、状态图、活动图、组件图），它们各用以表现不同的视图，如表1-1所示。
用例之间也可以存在包含、扩展和泛化等关系：
（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。
（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。
它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。
在以下几种情况下，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；
b.表明只在特定条件（如例外条件）下才执行的分支流；
c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
（3）泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。
当父用例能够被使用时，任何子用例也可以被使用。
如在图2.4中，订票是电话订票和网上订票的抽象。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
武当山旅游门户网站（ ） 分类信息
武当山旅游门户网站（ ） 分类信息
7.6 活动图
描述从一个活动到另一个活动的流程，用 于对系统的动态特性建模。在需求分析时 用活动图描述一个用例内部活动流的操作 步骤等。
认识活动图—图书馆图书信息管理系统借书活动图
武当山旅游门户网站（ ） 分类信息
用例图练习
下面是关于一个公司的人事信息管理系统的需求的 简单描述, 建立其相应的用例模型: 该人事管理系统 的用户是公司的人事管理干部. 该系统具有人事档 案库, 保存员工的人事信息, 包括姓名, 性别, 出生年 月, 健康状况, 文化程度, 学位, 职称, 岗位, 聘任时 间, 任期, 工资, 津贴, 奖罚记录, 业绩, 论著和家庭 情况等, 系统提供的基本服务有人事信息的管理, 包 括人事规定的调动与聘任, 职称评定, 奖罚等, 并且 可以按照限查询人事信息, 生成与输出统计报表等. 该人事系统每月向公司的财务系统提供员工的工资, 津贴等数据.
对象：活动流影响的实体对象。活动可能会改变 某个对象的状态，将活动影响的对象及其状态也 标识在活动图中，使得活动图表示的信息更加完 整。表示的符号为。用虚线表示哪个活动影响对 象的状态。 交接：是描述活动流如何从一个活动转移到下一 个活动的。表示符号是活动之间的箭头线。 决策：活动流中的分支判断点，在这点上根据条 件判断活动流走哪个分支路径。表示符号为菱形。
读者 流通组工作人员
读者信息
读者/图书编号 借书申请
检查读者 有效性
借书记录
读者无效/借书超期 读者无效
检查图书 有效性 图书无效 图书无效
图书信息
检查预订
预订记录
有预订
清除预订 记录
修改图书 信息
图书信息
创建借书 记录
借书记录
武当山旅游门户网站（ ） 分类信息
活动图中的主要图形元素
武当山旅游门户网站（ ） 分类信息
武当山旅游门户网站（ ） 分类信息
7.7 状态图
状态图用于对系统动态特征建模，主要是帮助理 解反应型对象的行为变化。一个反应型对象是这 样的对象，它的行为是通过对来自外部的事件作 出反应来刻画的。状态图中主要描述一个对象的 三种信息：
武当山旅游门户网站（ ） 分类信息
用例之间的关系
包含关系——包含关系 用于构造多个用例共同 的活动。例如，在ATM系 统中，取钱、查询、更 改密码等功能都需要验 证用户名和密码。这种 情况下应该将密码验证 功能独立出来，便于复 用、减少冗余。
取钱
《include》 《include》
还书 通知 管理员 读者
武当山旅游门户网站（ ） 分类信息
注意
使用关系和扩展关系之间的区别，A使 用B本质上是A一定使用B，同时增加自己 的专属行为；而A被用例B扩展是说明A是 一个一般用例，B是一个特殊用例，A在 某些条件下可能使用B。
武当山旅游门户网站（ ） 分类信息
武当山旅游门户网站（ ） 分类信息
注意
读者要注意状态图与活动图的区别，活 动图反映控制流程，状态图反映一个对 象的各个状态的变化。例如在图书管理 信息系统中，我们可以对“读者”对象、 “图书”对象的状态变化画出状态图； 而对借书、还书、采购这些活动画出活 动图。
武当山旅游门户网站（ ） 分类信息
武当山旅游门户网站（ ） 分类信息
7.5用例图—认识用例图
预定 取消 预定
关系
借书者
用例
查询
借书
还书
流通组工 作人员
角色
注意：图中的虚线是解释
武当山旅游门户网站（ ） 分类信息
7.5 用例图（续）
用例图：用于描述一组用例、角色以及 它们之间的关系。一个系统的用例图通 常是概要地反映整个系统提供的外部可 见服务和工作范围。 用例图的基本元素：用例、角色和关系。 进行需求分析时，通常将整个系统看作 一个黑盒子，从系统外部的视点出发观 察系统：它应该做什么？谁要它做？做 了以后的结果送给谁？这些正是用例图 要表现的。
身份认证
密码认证
指纹认证
武当山旅游门户网站（ ） 分类信息
用例图实例
以前面图书信息管理系统为例，画出用 例图。先找出参与系统地的角色： （1）读者 描述：可以查询图书；预订和取消预订图 书； （2） 工作人员 描述：帮助读者实现借书、还书、预订书、 取消预订、查询操作；
网上 查 取消 预定
还书
通知
借书
武当山旅游门户网站（ ） 分类信息
注意
在画用例图时要特别注意：用例图是系统分析、 设计和实现的一个最基础的图形，在初期是不一 定要考虑太多的处理细节。 一个用例内部的具体处理细节是由其他图形工具 描述的，用例图只是反映系统的总体功能，以及 与这些功能的相关的角色。有些人可能在画“借 书”用例时，情不自禁地就考虑了“输入读者号 和书号”，“检查图书是否在库？”，“图书数 量减1”，“添加读者借书记录”等等，一旦考虑了 这些细节，就会发现用例图画不下去了。因此， 读者注意用例图中不要考虑处理细节。
泳道：活动图中的分隔线，说明谁负责 执行该泳道中的活动。 开始状态：活动流的开始点。表示符号 为黑点。 活动：活动流可能由多个活动组成，一 个活动的表示符号为椭圆。 操作：一个活动可以有多个操作步骤， 这些操作可能发生在进入活动时、退出 活动时、活动内或特定的事件发生时。
武当山旅游门户网站（ ） 分类信息
用例或角色之间的继承关系
泛化关系——有时角色或用例之间存在 一种继承关系。例如，客户区分为公司 客户与个人客户，公司客户又区分为政 府机构和私人公司，这时，描述角色之 间的关系就可以用泛化关系表示。
客户
公司客户
个人客户
武当山旅游门户网站（ ） 分类信息
注意
用例之间的泛化关系就像类 之间的泛化关系一样，子用 例继承父用例的行为和含义。 例如，一个银行系统中，有 一个“验证用户”用例，用 于验证用户的合法性，它有 两个特殊的子用例，一个是 “检查密码”，另一个是 “检查指纹”，它们都有父 用例“验证用户”的行为， 并且可以出现在父用例出现 的任何地方，还可以添加自 己的行为。
状态图中的转移可以由三部分组成： 事件[条件]/动作
武当山旅游门户网站（ ） 分类信息
用例
在UML中用例的符号是一个椭圆，通常以 动词或短语来命名。 用例是软件开发的核心元素，需求是由 用例来表达的，界面是在用例的辅助下 设计的，类是根据用例来发现的，测试 数据是根据用例来生成的，整个开发的 管理和任务分配，也是依据用例来组织 的。用例简直太重要了！
武当山旅游门户网站（ ） 分类信息
分析这个用例图，发现“还书”用例应 该被扩展，因为在还书时检查所还图书 是否有预订记录，若有，则应该通知预 订者前来借书。 当欲借图书已全部被借出时，应该可以 转向“预订”用例。 读者可以直接从网上查询、预订或取消 预订图书。根据以上几点，画出初始的 用例图如下：
1)对象的各种状态； 2)引起状态变化的事件； 3)每个状态改变时所发生的动作。
认识状态图
还书/入库 还书[有预订]/入库
书到[有订单，发票]/验收
编目
[已编目]/入库
书库
预订 借出
[已编目]/入阅览室
阅览室
注销[已批准] /出库
注销
借书 [证件有效且库中有书] /出库 遗失/处罚
注销[已批准] /移出阅览室
并发活动
Action1
Action2
Action3
武当山旅游门户网站（ ） 分类信息
图书馆图书信息管理系统借书活动图的说明
图中有两个泳道，说明借书用例所涉及的角色有两个：读者和图书馆 工作人员。 读者以“借书申请”活动开始这个工作流，这个活动将读者编号和 图书编号传递给图书馆工作人员 工作人员检查“读者”类，看该“读者编号”是否存在； 然后检查读者的借书数量是否已经超出限制，如果读者编号有效， 并且借书数量没有超限，则检查图书是否在库中，否则，提示读者 “读者无效”。 如果欲借图书已经都被借出，则提示“图书已经被借出，是否预 订？” 当读者确认预订后，转去执行“预订处理”。 如果库中有欲借图书，则首先检查“预订记录”，如果该读者已经 预订了此书，则删除预订记录。 修改此书在库数量，创建“借书记录”，结束借书过程。
武当山旅游门户网站（ ） 分类信息
接下来我们从角色入手寻找用例。主要角色“读者”通过“流 通组工作人员”实现预订图书、取消预订、借书、还书等活动。 由此，可以找出下面的一些用例： （1）预订图书——本用例提供了预订图书的功能，读者可以通 过浏览器直接从网上预订图书；图书管理员也可以根据读者的 要求预订某本图书。 （2）取消预订——本用例提供取消预订图书的功能。 （3）还书——完成还书任务，在还书是要检查所还的书是否超 期、是否有其他读者预订，有的话要通知预订者。 （4）借书——提供借阅书功能 。
武当山旅游门户网站（ ） 分类信息
关系——角色与用例之间的关 系
通信关系——描述角色与用例之间的关系。 例如，当读者还书时，图书馆工作人员启 动系统的“还书”用例，进行还书处理。 用例也可以启动与角色的通信，例如，还 书时，如果该书有预订记录，则系统的 “通知”用例启动与读者的通信，通知读 者前来借书。
武当山旅游门户网站（ ） 分类信息
注意：
活动图描述多个角色之间的处理非常有 效，一张活动图只能有一个开始状态， 但可以有多个结束状态。 一个活动可以与多个实体对象相关，这 里的相关指的是一种访问操作。在上面 “借书”活动图中，“检查读者有效” 的活动，要访问“读者”对象和“借还 书记录”对象，检查“读者编号”的有 效性和读者借书数量。