下载文档原格式
UML的序列性图UML的序列图（Sequence Diagram）是一种用于描述系统中对象之间交互的图表工具。
它被广泛应用于软件开发过程中的分析和设计阶段，为软件项目团队成员提供了一种可视化的方式来理解和设计系统中的各个部分之间的通信。
在本文中，我们将详细介绍UML的序列图及其相关概念。
序列图是一种非常直观的图表工具，用于呈现系统中对象之间的交互。
在序列图中，每个对象被表示为一个矩形，矩形中包含该对象的名称。
对象之间的交互被表示为消息，每个消息都有一个箭头指向接收者对象。
此外，每个消息都有一个标签，用于表示消息的类型（例如，方法调用、返回等）。
序列图还可以包括参与者（Actor），它们表示与系统进行交互的外部实体。
序列图可以帮助团队成员更好地理解系统的运行方式。
通过序列图，设计人员可以了解每个对象如何与其他对象进行交互，以及它们之间的顺序和时间限制。
由于序列图具有直观性和易于理解的特点，因此它被广泛应用于软件开发项目的不同阶段，包括需求分析、设计和测试。
下面我们将介绍序列图中的一些重要概念和使用技巧：1. 对象序列图中的对象通常表示系统中的类或组件。
每个对象都有一个名称和一组可用的操作。
通常情况下，对象在序列图中表示为一个垂直的矩形，矩形中包含对象的名称。
2. 消息序列图中的消息表示对象之间的通信。
每个消息都有一个发送方和一个接收方，通常由一条箭头表示。
消息还可以包括一个标签，用于表示消息类型（例如，方法调用、返回等）。
在序列图中，消息通常表示为从发送方对象到接收方对象的垂直线。
3. 虚线在序列图中，一些线可能会是虚线，而不是实线。
虚线通常用于表示控制流或条件语句。
例如，如果一个对象只有在接收到某个消息时才会执行操作，那么这个操作被表示为一个虚线箭头。
4. 垂直参考线序列图通常使用垂直参考线来表示时间线。
这使得您可以更清晰地了解系统中对象之间的顺序和时间限制。
垂直参考线应该垂直于序列图。
5. 生命周期序列图通常还包括一个对象的生命周期。
浅谈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类图，有的读者反馈看不懂了，我们今天就来解决⼀哈。
什么是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 2012-11-30 16:42 2528人阅读评论(19) 收藏举报在面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(Stage Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) ，其中，“顺序图”与“协作图”表述的是相似的消息。
序列图(Sequence Diagram)强调的消息时间顺序的交互图，描述类系统中类与类之间的交互，它将这些交互建模成消息互换，换句话说，顺序图描述了类与类之间之间相互交换以完成期望行为的消息。
顺序图的特点是清晰，一个设计很好地顺序图从左到右、从上到下可以很好地表示出系统数据的流向，为接下来的系统设计做好铺垫。
协作图(Collaboration Diagram /Communication Diagram，也叫合作图)是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。
一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。
对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。
使用协作图来说明系统的动态情况。
1、序列图（顺序图）的知识点概要：点此看大图2、协作图知识点概要：点此看大图3：顺序图（1）先从图书馆借/还书角度了解顺序图从顺序图的流程中，清晰到了解程序的过程，十分清晰明了（2）从地铁购票的活动中来看顺序图根据机房收费系统来画的部分顺序图（3）：一般用户角度查询信息。
（4）：操作员注册新的学生账号（5）管理员的基本系统数据的的设定4、协作图（1）结合刚才的图书馆借/还书的过程。
根据序号可以发生的先后顺序（2）从地铁购票的角度来学习协作图（3）结合机房收费系统角度画的协作图一般用户查询信息：（4）操作员注册卡（5）管理员修改基本数据5、协作图与顺序图的区别和联系协作图和顺序图都表示出了对象间的交互作用，但是它们侧重点不同顺序图清楚地表示了交互作用中的时间顺序(强调时间)，但没有明确表示对象间的关系。
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注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
用例图：描绘不同系统用户群是如何同这个系统交互。
用例定义和描述用户从系统中获取价值的各种方法。
创建一个用例模型需要三个步骤：1 确定使用这个系统的人群2 确定这些人群是如何从系统中获取价值3 用一个简单易懂的视图来描述这些用户以及他们如何使用系统第一步：寻找参与者(actor)确定使用该系统的各种人群，一种人群称为参与者(actor)，使用这个系统或被这个系统使用的其他系统也是参与者。
参与者定义：指在某个系统的外部并和该系统交互的一群人或一个系统。
例：下列小组都是参与者1 银行客户和柜员分别是单独的参与者，因为他们有着不同的需求和权限2 大多数游戏系统中，男人和女人没必要分成单独的参与者3 学生和登记管理员是单独的参与者，有不同的需求和访问第二步：寻找用例(use case)系统为参与者提供一个独立的价值所采用的方式称之为用例.用例必须是集中的，并有一个明确的目标如果用例满足以下条件，则是集中的：1 用例应带来独立的好处2 可以用20-30个单词来描述这个好处3 参与者能通过一次会话完成该用例例：银行系统有输入帐号、选择帐号、取款、存款、选择源帐号、选择目标帐号、资金转移等功能，如果将这些动作都作为用例则显得太细，不能满足独立条件。
比如，没有一个用户会在选择一个帐号后就满意的离开！但是，如果只为一个用例---资金管理，则又显得太笼统。
好的用例应提供一个具体的用途！取款、存款、转账等都可以是好的用例，均提供了具体的用途！第三步描述参与者与用例UML中，参与者用棒形人表示，用例用带标记的椭圆来表示参与者指向用例的带箭头的实线表示这个参与者触发该用例，比如：利用用例描述需求：1 用例描述说明用例的概况和特征，比如，前置条件、后置条件、性能需求、安全要求、部署约束等。
前置条件—包括参与者启动这个用例之前必须完成的所有其他用例后置条件—包括这个用例对系统所作的所有改变部署约束—描述访问这个用例的所有约束2 事件流描述参与者在完成用例的过程中发生的一系列的交互行为。
A、Sequence Diagram（序列图）描述对象如何交互的。
并将重点放在消息序列上，描述消息如何在对象之间发送和接收的。
序列图有两个坐标轴：纵坐标显示时间，横坐标显示对象。
序列图横坐标上是和序列有关的对象，每个对象表示方法是写有对象名或类名的矩形，纵向的虚线表示对象在序列中执行的情况（发送和接收消息，对象的活动）。
对象之间的通信用水平的消息线来表示。
B、序列图的模型元素B.1、Actor（参与者）在序列图中Actor用于描述用户的角色。
用户发起事件流。
B.2、Lifeline（参与者）在互动时LifeLine是一个特别的参与者，它代表一个不同的连接元素。
它是一个实例。
B.3、Boundary（边界）Boundary用于为系统边界建模。
通常表示一个用户屏幕。
它是MVC模式（Model-View-Controller）中的View。
B.4、Control（控制）Control用于为一个控制实体建模。
它组织和安排其它活动和元素。
它是MVC模式（Model-View-Controller）中的Controller。
B.5、Entity（实体）Entity用于为存储或持久性机制建模。
它在系统中捕获信息和知识。
它是MVC模式（Model-View-Controller）中的Model。
B.6、Fragment（碎片）组合碎片表示为一块互动控制。
其相应的布尔条件是已知的相互作用的制约。
B.7、EndPoint（结束点）EndPoint表示序列中的丢失。
B.8、Diagram Gate（图片门）它是一个简单的图形化方式用于表明在互动碎片上的一个点可以流入或流出消息。
C、序列图的关系C.1、Message（消息）Message表明两个元素之间的信息流和控制流。
它可用在Timing图, Sequence图Communication图（不能用于Interaction Overview图）中用来表示系统行为。
若在两个类或实例化类之间，那操作的相关列表用于指定事件。
UML的九种模型图本⽂转⾃，仅供学习交流！⼀、作为⼀种建模语⾔，UML的定义包括UML语义和UML表⽰法两个部分。
UML语义：描述基于UML的精确元模型定义。
UML表⽰法：定义UML符号的表⽰法，为开发者或开发⼯具使⽤这些图形符号和⽂本语法为系统建模提供了标准。
这些图形符号和⽂字所表达的是应⽤级的模型，在语义上它是UML元模型的实例。
⼆、标准建模语⾔UML可以由下列5类图来定义。
⽤例图：从⽤户⾓度描述系统功能，并指出各功能的操作者。
静态图：包括类图和对象图。
类图描述系统中类的静态结构，不仅定义系统中的类，表⽰类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是⼀种静态关系，在系统的整个⽣命周期都是有效的。
对象图是类图的实例，⼏乎使⽤与类图完全相同的标识。
⼀个对象图是类图的⼀个实例。
由于对象存在⽣命周期，因此对象图只能在系统某⼀时间段存在。
⾏为图：描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图。
状态图描述类的对象所有可能的状态以及事件发⽣时状态的转移条件，状态图是对类图的补充，活动图描述满⾜⽤例要求所要进⾏的活动以及活动间的约束关系，有利于识别并进⾏活动。
交互图：描述对象间的交互关系，包括时序图和协作图。
时序图显⽰对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显⽰对象之间的交互；协作图描述对象间的协作关系，协作图跟时序图相似，显⽰对象间的动态合作关系。
除显⽰信息交换外，协作图还显⽰对象以及它们之间的关系。
如果强调时间和顺序，则使⽤时序图；如果强调上下级关系，则选择协作图。
实现图：包括组件图和部署图。
组件图描述代码部件的物理结构及各部件之间的依赖关系，组件图有助于分析和理解部件之间的相互影响程度；部署图定义系统中软硬件的物理体系结构。
采⽤UML来设计系统时，第⼀步是描述需求；第⼆步根据需求建⽴系统的静态模型，以构造系统的结构；第三步是描述系统的⾏为。
其中在第⼀步与第⼆步中所建⽴的模型都是静态的，包括⽤例图、类图、对象图、组件图和部署图等5种图形，是标准建模语⾔UML的静态建模机制。
UML序列图的消息组合与消息链接技巧UML（Unified Modeling Language）序列图是一种常用的软件设计工具，用于展示对象之间的交互和通信过程。
在序列图中，消息的组合和链接是非常重要的，它们能够清晰地展示对象之间的交互流程和消息传递方式。
本文将探讨UML序列图中的消息组合与消息链接技巧。
1. 消息组合技巧在UML序列图中，消息的组合方式可以通过箭头的形状和方向来表示。
常见的消息组合技巧有以下几种：1.1 同步消息同步消息表示对象之间的同步通信，即发送消息的对象等待接收消息的对象完成相关操作后才能继续执行。
在序列图中，同步消息通常用实心箭头表示，箭头的方向从发送消息的对象指向接收消息的对象。
1.2 异步消息异步消息表示对象之间的异步通信，即发送消息的对象不需要等待接收消息的对象完成相关操作就可以继续执行。
在序列图中，异步消息通常用空心箭头表示，箭头的方向从发送消息的对象指向接收消息的对象。
1.3 返回消息返回消息表示接收消息的对象向发送消息的对象返回结果或响应。
在序列图中，返回消息通常用虚线箭头表示，箭头的方向从接收消息的对象指向发送消息的对象。
1.4 自身消息自身消息表示对象自身的内部操作或状态改变。
在序列图中，自身消息通常用箭头从对象指向自己，并标注消息的描述。
2. 消息链接技巧在UML序列图中，消息的链接方式可以通过箭头的连线和顺序来表示。
常见的消息链接技巧有以下几种：2.1 顺序链接顺序链接表示消息的顺序执行，即后一个消息在前一个消息执行完成后才能执行。
在序列图中，顺序链接通常用直线连接两个消息。
2.2 并行链接并行链接表示消息的并行执行，即两个或多个消息可以同时执行。
在序列图中，并行链接通常用平行的虚线连接两个或多个消息。
2.3 条件链接条件链接表示消息的执行受到某个条件的限制，只有满足条件时才能执行。
在序列图中，条件链接通常用带有条件标签的虚线连接消息。
2.4 循环链接循环链接表示消息的循环执行，即消息会重复执行一定的次数或满足某个条件时才会停止执行。
UML——序列图案例总结序列图的主要⽬的：展⽰对象间交互的顺序。
详细介绍可以参考上⼀篇⽂章，序列图是⼀个⼆维图。
纵向是时间轴，时间沿着竖线向下延伸，横向轴代表了在协作中各个独⽴对象的类元⾓⾊，也称作⽣命线，当对象存在时，⾓⾊⽤⼀条虚线表⽰，当对象的过程处于激活状态时，⽣命线是⼀个双道线。
举例：1、⽣命线⽣命线名称可带下划线。
当使⽤下划线时，意味着序列图中的⽣命线代表⼀个类的特定实例。
2、同步消息发送⼈在它继续之前，将等待同步消息响应。
3、异步消息在发送⽅继续之前，⽆需等待响应的消息。
4、注释5、约束约束的符号很简单，中括号包括约束内容：[Boolean Test]6、组合⽚段组合⽚段⽤来解决交互执⾏的条件及⽅式，它允许在序列图中直接表⽰逻辑组件，⽤于通过制定条件或⼦进程的应⽤区域，为任何⽣命线的任何部分定义特殊条件和⼦进程。
<1>抉择（Alt）抉择⽤来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if...else...。
抉择在任何场合下只发⽣⼀个序列。
可以在每个⽚段中设置⼀个临界来指⽰该⽚段可以运⾏的条件。
else的临界指⽰其他任何临界都不为true时应运⾏的⽚段。
如果所有的临界都为false并且没有else,则不执⾏任何⽚段。
<2>选项（Opt）包含⼀个可能发⽣或不能发⽣的序列<3>循环（Loop）⽚段重复⼀定次数。
可以在临界中指⽰⽚段重复的条件。
<4>并⾏（Par）⼀个⽣命线中持续操作的部分下⾯还有⼏种常见的组合⽚段：1、Opt（选项）包含⼀个可能发⽣或可能不发⽣的序列。
可以在临界中指定序列发⽣的条件。
相对于OR2、Alt(抉择)包含⼀个列表，这些⽚段中包含备选信息序列。
在任何场合下只能发⽣⼀个序列。
可以在每个⽚段中设置⼀个临界来指⽰该运⾏的条件。
else的临界指⽰其他任何临界都不为True时运⾏的⽚段。
如果所有的临界都为False并且没有else,则不执⾏任何⽚段。
UML 2.0共有10种图，分别为表示系统静态结构的静态模型（包括类图、组合结构图、部署图），以及表示系统动态结构的动态模型（包括用例图、序列图、对象图、协作图、状态图、活动图、组件图），它们各用以表现不同的视图，如表1-1所示。
用例之间也可以存在包含、扩展和泛化等关系：
（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。
（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。
它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。
在以下几种情况下，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；
b.表明只在特定条件（如例外条件）下才执行的分支流；
c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
（3）泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。
当父用例能够被使用时，任何子用例也可以被使用。
如在图2.4中，订票是电话订票和网上订票的抽象。
UML序列图与状态图的对比与适用场景在软件开发过程中，UML（Unified Modeling Language）是一种常用的建模语言，它提供了多种图形表示方法，其中序列图和状态图是两种常见的图形表示方法。
本文将对UML序列图和状态图进行对比，并探讨它们的适用场景。
一、UML序列图UML序列图是一种用于描述对象之间交互的图形表示方法。
它展示了对象之间的消息传递和方法调用顺序，有助于理解系统的行为和交互。
序列图通常由对象、生命线、消息和控制流程等元素组成。
序列图主要用于描述系统的动态行为，特别适用于描述对象之间的时序关系。
通过序列图，开发人员可以清晰地了解系统中对象之间的交互过程，从而更好地进行系统设计和开发。
二、状态图状态图是一种用于描述对象的状态和状态之间的转换的图形表示方法。
它展示了对象在不同状态之间的转换过程，有助于理解系统的状态变化和行为。
状态图通常由状态、转换、事件和动作等元素组成。
状态表示对象在特定条件下的行为和属性，转换表示对象在不同状态之间的转换过程，事件表示触发状态转换的条件，动作表示状态转换时执行的操作。
状态图主要用于描述系统的状态变化和行为，特别适用于描述对象的生命周期和状态转换过程。
通过状态图，开发人员可以清晰地了解对象的状态变化和行为，从而更好地进行系统设计和开发。
三、对比与适用场景虽然序列图和状态图都是UML的图形表示方法，但它们在描述对象之间的关系和行为时有着不同的重点和适用场景。
序列图主要关注对象之间的交互和消息传递顺序，适用于描述对象之间的时序关系。
它可以帮助开发人员理解系统的动态行为，从而更好地进行系统设计和开发。
序列图通常用于需求分析和系统设计阶段，以及对系统进行调试和优化时的分析工具。
状态图主要关注对象的状态和状态之间的转换，适用于描述对象的生命周期和状态变化。
它可以帮助开发人员理解系统的状态变化和行为，从而更好地进行系统设计和开发。
状态图通常用于需求分析和系统设计阶段，以及对系统进行状态管理和控制时的分析工具。
UML 序列图来自: IBM Rational Edge现在是二月，而且到如今你或许已经读到、或听到人们谈论UML 2.0 ——包括若干进步的UML 的新规范，所做的变化。
考虑到新规范的重要性，我们也正在修改这个文章系列的基础，把我们的注意力从OMG 的UML 1.4 规范，转移到OMG 的已采纳UML 2.0草案规范（又名UML 2）。
我不喜欢在一系列文章的中间，把重点从 1.4 变为2.0 ，但是UML 2.0 草案规范是前进的重要一步，我感觉需要扩充文字。
由于一些理由，OMG 改良了UML 。
主要的理由是，他们希望UML 模型能够表达模型驱动架构（MDA），这意味着UML 必须支持更多的模型驱动的符号。
同时，UML 1.x 符号集合有时难以适用于较大的应用程序。
此外,为了要使图变成更容易阅读，需要改良符号元件。
（举例来说，UML 1.x 的模型逻辑流程太复杂，有时不可能完成。
对UML 2 中的序列图的符号集合的改变，已经在序列化逻辑建模方面取得巨大的进步)。
注意我上面所述的文字：“已采纳UML2.0草案规范。
”确实，规范仍然处于草案状态，但是关键是草案规范已经被OMG 采用，OMG是一个直到新标准相当可靠，才会采用它们的组织。
在UML 2 完全地被采用之前，规范将会有一些修改，但是这些改变应该是极小的。
主要的改变将会是在UML 的内部——包括通常被实施UML 工具的软件公司使用的功能。
本文的主要目的是继续把我们的重点放在基础UML图上；这个月，我们进一步了解序列图。
再次请注意，下面提供的例子正是以新的UML 2 规范为基础。
图的目的序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。
很象类图，开发者一般认为序列图只对他们有意义。
然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。
除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。
在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。
那种情况下，用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现，序列图在记录一个未来系统的行为应该如何表现中，非常有用。
在设计阶段，架构师和开发者能使用图，挖掘出系统对象间的交互，这样充实整个系统设计。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。
用例常常被细化为一个或者更多的序列图。
序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。
当把这个系统移交给另一个人或组织时，这个文档很有用。
符号既然这是我基于UML 2的UML 图系列文章的第一篇，我们需要首先讨论对UML 2 图符号的一个补充，即一个叫做框架的符号元件。
在UML 2中，框架元件用于作为许多其他的图元件的一个基础，但是大多数人第一次接触框架元件的情况，是作为图的图形化边界。
当为图提供图形化边界时，一个框架元件为图的标签提供一致的位置。
在UML 图中框架元件是可选择的；就如你能在图 1 和2 中见到的，图的标签被放在左上角，在我将调用框架的“namebox”中，一种卷角长方形，而且实际的UML 图在较大的封闭长方形内部定义。
图1: 空的UML 2 框架元件除了提供一个图形化边框之外，用于图中的框架元件也有描述交互的重要的功能, 例如序列图。
在序列图上一个序列接收和发送消息（又称交互），能通过连接消息和框架元件边界，建立模型（如图 2 所见到）。
这将会在后面“超越基础”的段落中被更详细地介绍。
图2: 一个接收和发送消息的序列图注意在图2 中，对于序列图，图的标签由文字“sd”开始。
当使用一个框架元件封闭一个图时，图的标签需要按照以下的格式:UML 规范给图类型提供特定的文本值。
（举例来说，sd代表序列图，activity 代表活动图，use case代表用例图）。
基础序列图的主要目的是定义事件序列，产生一些希望的输出。
重点不是消息本身，而是消息产生的顺序；不过，大多数序列图会表示一个系统的对象之间传递的什么消息，以及它们发生的顺序。
图按照水平和垂直的维度传递信息：垂直维度从上而下表示消息/调用发生的时间序列，而且水平维度从左到右表示消息发送到的对象实例。
生命线当画一个序列图的时候，放置生命线符号元件，横跨图的顶部。
生命线表示序列中，建模的角色或对象实例。
1 生命线画作一个方格，一条虚线从上而下，通过底部边界的中心（图3）。
生命线名字放置在方格里。
图3: 用于一个实体名为freshman的生命线的Student类的一个例子UML 的生命线命名标准按照如下格式:在如图3所示的例子中，生命线表示类Student的实体，它的实体名称是fres hman。
这里注意一点，生命线名称带下划线。
当使用下划线时，意味着序列图中的生命线代表一个类的特定实体，不是特定种类的实体（例如，角色）。
在将来的一篇文章中，我们将会了解结构化建模。
现在，仅仅评述序列图，可能包含角色（例如买方和卖方），而不需要叙述谁扮演那些角色（例如Bill和Fred）。
这准许不同语境的图重复使用。
简单拖放，序列图的实例名称有下划线，而角色名称没有。
图3 中我们生命线例子是一个命名的对象，但是不是所有的生命线都代表命名的对象。
相反的，一个生命线能用来表现一个匿名的或未命名的实体。
当在一个序列图上，为一个未命名的实例建模时，生命线的名字采用和一个命名实例相同的模式；但是生命线名字的位置留下空白，而不是提供一个例图名字。
再次参考图3，如果生命线正在表现Student类的一个匿名例图，生命线会是: “Stude nt”。
同时, 因为序列图在项目设计阶段中使用，有一个未指定的对象是完全合法: 举例来说，“freshman”。
消息为了可读性，序列图的第一个消息总是从顶端开始，并且一般位于图的左边。
然后继发的消息加入图中，稍微比前面的消息低些。
为了显示一个对象（例如，生命线）传递一个消息给另外一个对象，你画一条线指向接收对象，包括一个实心箭头（如果是一个同步调用操作）或一个棍形箭头（如果是一个异步讯号）。
消息/方法名字放置在带箭头的线上面。
正在被传递给接收对象的消息，表示接收对象的类实现的一个操作/方法。
在图4 的例子中，analyst对象调用ReportingSystem 类的一个实例的系统对象。
analyst对象在调用系统对象的getAvailableReports 方法。
系统对象然后调用secSyste m 对象上的、包括参数userId的getSecurityClearance 方法，secSystem 的类的类型是SecuritySystem。
2图4: 一个在对象之间传递消息的实例除了仅仅显示序列图上的消息调用外，图 4 中的图还包括返回消息。
这些返回消息是可选择的；一个返回消息画作一个带开放箭头的虚线，向后指向来源的生命线，在这条虚线上面，你放置操作的返回值。
在图 4 中，当getSecurityCl earance 方法被调用时，secSystem 对象返回userClearance 给系统对象。
当getAvailableReports 方法被调用时，系统对象返回availableReports。
此外，返回消息是序列图的一个可选择部分。
返回消息的使用依赖建模的具体/抽象程度。
如果需要较好的具体化，返回消息是有用的；否则，主动消息就足够了。
我个人喜欢，无论什么时候返回一个值，都包括一个返回消息，因为我发现额外的细节使一个序列图变得更容易阅读。
当序列图建模时，有时候，一个对象将会需要传递一个消息给它本身。
一个对象何时称它本身？一个纯化论者会争辩一个对象应该永不传递一个消息给它本身。
然而，为传递一个消息给它本身的对象建模，在一些情境中可能是有用的。
举例来说，图5 是图4 的一个改良版本。
图5 版本显示调用它的determineA vailableReports 方法的系统对象。
通过表示系统传递消息“determineAvailableReports”给它本身，模型把注意力集中到过程的事实上，而不是系统对象。
为了要画一个调用本身的对象，如你平时所作的，画一条消息，但是不是连接它到另外的一个对象，而是你把消息连接回对象本身。
图5: 系统对象调用它的determineAvailableReports 方法图5 中的消息实例显示同步消息；然而，在序列图中，你也能为异步消息建模。
一个异步消息和一个同步的画法类似，但是消息画的线带一个棍形矛头，如图6 所示。
图6: 表示传递到实体2的异步消息的序列图片段约束当为对象的交互建模时，有时候，必须满足一个条件，消息才会传递给对象。
约束在UML 图各处中，用于控制流。
在这里，我将会讨论UML 1.x 及UML 2. 0两者的约束。
在UML 1.x 中，一个约束只可能被分配到一个单一消息。
UML 1.x中，为了在一个序列图上画一个约束，你把约束元件放在约束的消息线上，消息名字之前。
图7 显示序列图的一个片段，消息addStudent 方法上有一个约束。
图7:UML 1.x 序列图的一个片段，其中addStudent 消息有一个约束在图7 中，约束是文本“[ pastDueBalance=0]”。
通过这个消息上的约束，如果应收帐系统返回一个零点的逾期平衡，addStudent 消息才将会被传递。
约束的符号很简单；格式是:举例来说，组合碎片(变体方案，选择项，和循环)然而，在大多数的序列图中，UML 1.x“in-line”约束不足以处理一个建模序列的必需逻辑。
这个功能缺失是UML 1.x 的一个问题。
UML 2 已经通过去掉“in-line”约束，增加一个叫做组合碎片的符号元件，解决了这一个问题。
一个组合碎片用来把一套消息组合在一起，在一个序列图中显示条件分支。
UML 2 规范指明了组合碎片的11 种交互类型。
十一种中的三种将会在“基础”段落中介绍，另外两种类型将会在“超越基础”中介绍，而那剩余的六种我将会留在另一篇文章中介绍。
（嗨，这是一篇文章而不是一本书。
我希望你在一天中看完这部分！）变体变体用来指明在两个或更多的消息序列之间的、互斥的选择。
3 变体支持经典的“if then else”逻辑的建模（举例来说，如果我买三个，然后我得到我购买的20% 折扣；否则我得到我购买的10% 折扣）。
就如你将会在图8 中注意到的，一个变体的组合碎片元件使用框架来画。
单词“a lt”放置在框架的namebox里。
然后较大的长方形分为UML 2 所称的操作元。
4 操作元被虚线分开。
每个操作元有一个约束进行测试，而这个约束被放置在生命线顶端的操作元的左上部。
