UML study resource

 

统一建模语言：http://baike.baidu.com/view/174909.htm?fromtitle=UML&fromid=446747&type=search

UML学习之四步走战略 

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://yunli.blog.51cto.com/831344/170507

最近几年，随着UML（Unified Modeling Language，统一建模语言）的不断完善，其已被广泛运用于软件行业。掌握UML是每一个软件开发人提升自己能力的一个重要内容。下面，我想谈一谈我对UML学习的一些想法。

UML是建立在面向对象的基础之上的，如果你是一名面向对象语言的软件开发人员，那么，学习UML将相对的容易。容易是指其中的很多概念我们已经很熟悉 了，比如类、属性、抽象等等。如果不是一名面向对象语言的开发人员，那么学习UML可能会相对的抽象，难度可能也就大一点。

学习UML的第一步是从网上找一些培训材料，在OMG（Object Management Group, UML规范的制定组织）的网站上就能找到一些很好的培训材料，一定要学习针对UML2.x的材料，请不要学习针对UML1.x的材料。在这些培训材料中， 通常不是讲授UML的全部内容，但是作为UML的实学者，这些内容作为开始是足够了的。通过学习，掌握UML有几种图，每种图的作用和应有场合是什么，每 一种图有哪些元素，等等。

第二步是，我们需要将学到的UML知识运用到我们的工作中。可能，我们的工作单位并不要求我们去用UML，但作为学习，我们需要自己找机会去练习。任何一 种东西，只有用多了（或说是模仿多了），我们才能更好的理解它，进而驾驭它。想想我们所使用的开发语言，我们一开始也不熟悉，但使用长了以后，对于应用问 题，我们很自然的（自然到成了自觉）知道如何用语言去实现所需的应用功能。在这一点上学习UML也是同样的，还是那句话“熟能生巧”。这一阶段我们可能需 要花较长的时间，而且，我们会碰到很多情况下，不知道所要表达的内容在UML中应当如何表达，这可以说是比较痛苦的过程，但别忘了，只有痛苦了我们才能真 正的学会。对于这一步，很重要的一点是，我们需要一个UML的工具，我知道的开源的有StarUML，但好像很长时间没有维护了，这一工具，可能不能很好 的遵循最新的UML规范。至于商业软件，那就多了，我比较喜欢用的比如Visual Paradigm for UML就很不错。其它的还有来自IBM的Rose Software Modeler（是Rational Rose的升级产品，其于Eclipse的），Telelogic TAU（现在也被IBM收购了）。对了，Rational Rose名气比较的大，我记得还有一本书是专门讲Rational Rose的，但这个工具太垃圾了，建议不要用，可以用前面提到的升级产品Rose Software Modeler。对于工具，需要注意的是：一定要求这一工具遵循UML2.x规范。对于工具，需要注意的是工具只是工具，其跟本还是UML，一旦掌握了 UML，其实什么工具用起来都一样。

第三步是，由于我们对于UML已经有了一定的基础，此时，我们可以通过查看UML规范来解惑。UML的规范主要分为两大部分：一步分是 Infrastructure，即基础结构；另一部分是Superstructure，即上层结构。规范可以从www.OMG.com上下载。在这一步 中，我们查看Superstructure就行了，对于我们所不知的内容，我们可以查看图所对应的章节，里面会解释每一个概念的意思是什么。UML规范组 织得还是很好的，很方便我们查看。另外，最为有用的是：每个个章节，都会有一个Diagram的小节，里面会给出一些例子，这有助于我们去学习。对了 UML2.x最大的变化除了对于图的种类有些变化外，还有一点就是给出了很多的例子，对于这一点OMG的解释是“给出大量的例子将有利于大家学习 UML”。

第四部是，如果你想进一步的了解UML，可以系统性的看一下UML的两部分规范。在阅读规范时，有一点需要注意的是，UML规范是用UML语言自己来描述 自己的，所以看起来一开始会有一点不习惯。如果对于UML没有基本的了解，请不要去看规范，否则你会发现一个“鸡和蛋的问题”：我们是因为不了解UML才 看UML规范的，可是UML规范却用UML语言解释UML规范。系统性的了解UML有利于我们掌握其它的以UML为基础的建模语言，比如，SysUML就 是取了UML当中的一步分进行扩展的一个建模语言。

我相信，看过了UML的规范后你对于面向对象当中的一些东西会有一个更为清晰、准确的理解，因为UML几乎解释了面向对象中的所有术语，这一点很有意思！

UML基础：统一建模语言简介

作者: Donald Bell  来源: IBM 

目录

1. 背景知识
2. 用例图
3. 类图
4. 序列图
5. 状态图
6. 活动图
7. 组件图
8. 部署图
9. 结束语

　　英文原文：UML basics: An introduction to the Unified Modeling Language

　　到了21世纪——准确地说是2003年，UML已经获得了业界的认同。在我所见过的专业人员的简历中，75%都声称具备UML的知识。然而，在 同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。通常地，他们将UML用作一个术语，或对UML一知半解。大家对UML缺乏理解的这 种状况，促进我撰写这篇关于UML 1.4的快速入门文章。当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。

　　背景知识

　　正如前面曾提到过的，UML的本意是要成为一种标准的统一语言，使得IT专业人员能够进行计算机应用程序的建模。UML的主要创始人是Jim Rumbaugh、Ivar Jacobson和Grady Booch，他们最初都有自己的建模方法（OMT、OOSE和Booch），彼此之间存在着竞争。最终，他们联合起来创造了一种开放的标准。（听起来是不 是很熟悉？这个现象类似J2EE、SOAP和Linux的诞生。）UML成为"标准"建模语言的原因之一在于，它与程序设计语言无关。（IBM Rational的UML建模工具被广泛应用于J2EE和.NET开发。）而且，UML符号集只是一种语言而不是一种方法学。这点很重要，因为语言与方法 学不同，它可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。

　　既然UML不是一种方法学，它就不需要任何正式的工作产品（即IBM Rational Unified Process术语中所定义的"工件"）。而且它还提供了多种类型的模型描述图（diagram），当在某种给定的方法学中使用这些图时，它使得开发中的 应用程序的更易理解。UML的内涵远不只是这些模型描述图，但是对于入门来说，这些图对这门语言及其用法背后的基本原理提供了很好的介绍。通过把标准的 UML图放进您的工作产品中，精通UML的人员就更加容易加入您的项目并迅速进入角色。最常用的UML图包括：用例图、类图、序列图、状态图、活动图、组 件图和部署图。

　　深入讨论每类图的细节问题已超出了这篇入门文章的范围。因此，下面仅给出了每类图的简要说明，更详细的信息将在以后的文章中探讨。

　　用例图

　　用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的"角色" （actors，也就是与系统交互的其他实体）关系，以及系统内用例之间的关系。用例图一般表示出用例的组织关系 —— 要么是整个系统的全部用例，要么是完成具有功能（例如，所有安全管理相关的用例）的一组用例。要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名 称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个角色（表示一个系统用户），可绘制一个人形符号。角色和用例之间的关系使用简单的线段来描 述，如图1所示。

 

图1：示例用例图

　　图字（从上到下）：CD销售系统；查看乐队CD的销售统计；乐队经理；查看Billboard 200排行榜报告；唱片经理；查看特定CD的销售统计；检索最新的Billboard 200排行榜报告；排行榜报告服务

　　用例图通常用于表达系统或者系统范畴的高级功能。如图1所示，可以很容易看出该系统所提供的功能。这个系统允许乐队经理查看乐队CD的销售统计 报告以及Billboard 200排行榜报告。它也允许唱片经理查看特定CD的销售统计报告和这些CD在Billboard 200排行榜的报告。这个图还告诉我们，系统将通过一个名为"排行榜报告服务"的外部系统提供Billboard排行榜报告。

　　此外，在用例图中，没有列出的用例表明了该系统不能完成的功能。例如，它不能提供给乐队经理收听Billboard 200上不同专辑中的歌曲的途径 —— 也就是说，系统没有引用一个叫做"收听Billboard 200上的歌曲"的用例。这种缺少不是一件小事。在用例图中提供清楚的、简要的用例描述，项目赞助商就很容易看出系统是否提供了必须的功能。

　　类图

　　类图表示不同的实体（人、事物和数据）如何彼此相关；换句话说，它显示了系统的静态结构。类图可用于表示逻辑类，逻辑类通常就是业务人员所谈及 的事物种类 —— 摇滚乐队、CD、广播剧；或者贷款、住房抵押、汽车信贷以及利率。类图还可用于表示实现类，实现类就是程序员处理的实体。实现类图或许会与逻辑类图显示一 些相同的类。然而，实现类图不会使用相同的属性来描述，因为它很可能具有对诸如Vector和HashMap这种事物的引用。

　　类在类图上使用包含三个部分的矩形来描述，如图2所示。最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说"方法"）。

图2：类图中的示例类对象

　　根据我的经验，几乎每个开发人员都知道这个类图是什么，但是我发现大多数程序员都不能正确地描述类的关系。对于像图3这样的类图，您应该使用带 有顶点指向父类的箭头的线段来绘制继承关系1，并且箭头应该是一个完全的三角形。如果两个类都彼此知道对方，则应该使用实线来表示关联关系；如果只有其中 一个类知道该关联关系，则使用开箭头表示。

图3：一个完整的类图，包括了图2所示的类对象

　　在图3中，我们同时看到了继承关系和两个关联关系。CDSalesReport类继承自Report类。一个CDSalesReport类与一 个CD类关联，但是CD类并不知道关于CDSalesReport类的任何信息。CD类和Band类都彼此知道对方，两个类彼此都可以与一个或者多个对方 类相关联。

　　一个类图可以整合其他许多概念，这将在本系列文章的后续文章中介绍。

　　序列图

　　序列图显示具体用例（或者是用例的一部分）的详细流程。它几乎是自描述的，并且显示了流程中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。

　　序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。

　　序列图的绘制非常简单。横跨图的顶部，每个框（参见图4）表示每个类的实例（对象）。在框中，类实例名称和类名称之间用空格/冒号/空格来分 隔，例如，myReportGenerator : ReportGenerator。如果某个类实例向另一个类实例发送一条消息，则绘制一条具有指向接收类实例的开箭头的连线，并把消息/方法的名称放在连 线上面。对于某些特别重要的消息，您可以绘制一条具有指向发起类实例的开箭头的虚线，将返回值标注在虚线上。就我而言，我总喜欢绘制出包括返回值的虚线， 这些额外的信息可以使得序列图更易于阅读。

　　阅读序列图也非常简单。从左上角启动序列的"驱动"类实例开始，然后顺着每条消息往下阅读。记住：虽然图4所示的例子序列图显示了每条被发送消息的返回消息，但这只是可选的。

图4：一个示例序列图

　　通过阅读图4中的示例序列图，您可以明白如何创建一个CD销售报告（CD Sales Report）。其中的aServlet对象表示驱动类实例。aServlet向名为gen的ReportGenerator类实例发送一条消息。该消息 被标为generateCDSalesReport，表示ReportGenerator对象实现了这个消息处理程序。进一步理解可发 现，generateCDSalesReport消息标签在括号中包括了一个cdId，表明aServlet随该消息传递一个名为cdId的参数。当 gen实例接收到一条generateCDSalesReport消息时，它会接着调用CDSalesReport类，并返回一个aCDReport的实 例。然后gen实例对返回的aCDReport实例进行调用，在每次消息调用时向它传递参数。在该序列的结尾，gen实例向它的调用者aServlet返 回一个aCDReport。

　　请注意：图4中的序列图相对于典型的序列图来说太详细了。然而，我认为它才是足够易于理解的，并且它显示了如何表示嵌套的调用。对于初级开发人员来说，有时把一个序列分解到这种详细程度是很有必要的，这有助于他们理解相关的内容。

　　状态图

　　状态图表示某个类所处的不同状态和该类的状态转换信息。有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图。只对"感兴趣的"状态的类（也就是说，在系统活动期间具有三个或更多潜在状态的类）才进行状态图描述。

　　如图5所示，状态图的符号集包括5个基本元素：初始起点，它使用实心圆来绘制；状态之间的转换，它使用具有开箭头的线段来绘制；状态，它使用圆 角矩形来绘制；判断点，它使用空心圆来绘制；以及一个或者多个终止点，它们使用内部包含实心圆的圆来绘制。要绘制状态图，首先绘制起点和一条指向该类的初 始状态的转换线段。状态本身可以在图上的任意位置绘制，然后只需使用状态转换线条将它们连接起来。

 图5：显示类通过某个功能系统的各种状态的状态图

　　图5中的状态图显示了它们可以表达的一些潜在信息。例如，从中可以看出贷款处理系统最初处于Loan Application状态。当批准前（pre-approval）过程完成时，根据该过程的结果，或者转到Loan Pre-approved状态，或者转到Loan Rejected状态。这个判断（它是在转换过程期间做出的）使用一个判断点来表示 —— 即转换线条间的空心圆。通过该状态图可知，如果没有经过Loan Closing状态，贷款不可能从Loan Pre-Approved状态进入Loan in Maintenance状态。而且，所有贷款都将结束于Loan Rejected或者Loan in Maintenance状态。

　　活动图

　　活动图表示在处理某个活动时，两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级 别的内部类操作进行建模。根据我的经验，活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等。这是因为与序列图相 比，活动图在表示上"不够技术性的"，但有业务头脑的人们往往能够更快速地理解它们。

　　活动图的符号集与状态图中使用的符号集类似。像状态图一样，活动图也从一个连接到初始活动的实心圆开始。活动是通过一个圆角矩形（活动的名称包 含在其内）来表示的。活动可以通过转换线段连接到其他活动，或者连接到判断点，这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一 个终止点（就像在状态图中一样）。作为一种选择，活动可以分组为泳道（swimlane），泳道用于表示实际执行活动的对象，如图6所示。

 

图6：活动图，具有两个泳道，表示两个对象的活动控制：乐队经理，以及报告工具

　　图字（沿箭头方向）：乐队经理；报告工具；选择"查看乐队的销售报告"；检索该乐队经理所管理的乐队；显示报告条件选择屏幕；选择要查看其销售报告的乐队；从销售数据库检索销售数据；显示销售报告。

　　该活动图中有两个泳道，因为有两个对象控制着各自的活动：乐队经理和报告工具。整个过程首先从乐队经理选择查看他的乐队销售报告开始。然后报告 工具检索并显示他管理的所有乐队，并要求他从中选择一个乐队。在乐队经理选择一个乐队之后，报告工具就检索销售信息并显示销售报告。该活动图表明，显示报 告是整个过程中的最后一步。

　　组件图

　　组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件（例如，库函数）的依赖关系。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次2上显示。

　　组件图的建模最适合通过例子来描述。图7显示了4个组件：Reporting Tool、Billboard Service、Servlet 2.2 API和JDBC API。从Reporting Tool组件指向Billboard Service、Servlet 2.2 API和JDBC API组件的带箭头的线段，表示Reporting Tool依赖于那三个组件。

图7：组件图显示了系统中各种软件组件的依赖关系

　　部署图

　　部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。

　　部署图中的符号包括组件图中所使用的符号元素，另外还增加了几个符号，包括节点的概念。一个节点可以代表一台物理机器，或代表一个虚拟机器节点 （例如，一个大型机节点）。要对节点进行建模，只需绘制一个三维立方体，节点的名称位于立方体的顶部。所使用的命名约定与序列图中相同：[实例名称] : [实例类型]（例如，"w3reporting.myco.com : Application Server"）。

　　图8：部署图

　　图字：由于Reporting Tool组件绘制在IBM WebSphere内部，后者又绘制在节点w3.reporting.myco.com内部，因而我们知道，用户将通过运行在本地机器上的浏览器来访问 Reporting Tool，浏览器通过公司intranet上的HTTP协议与Reporting Tool建立连接。

　　图8中的部署图表明，用户使用运行在本地机器上的浏览器访问Reporting Tool，并通过公司intranet上的HTTP协议连接到Reporting Tool组件。这个工具实际运行在名为w3reporting.myco.com的Application Server上。这个图还表明Reporting Tool组件绘制在IBM WebSphere内部，后者又绘制在w3.reporting.myco.com节点内部。Reporting Tool使用Java语言通过IBM DB2数据库的JDBC接口连接到它的报告数据库上，然后该接口又使用本地DB2通信方式，与运行在名为db1.myco.com的服务器上实际的DB2 数据库通信。除了与报告数据库通信外，Report Tool组件还通过HTTPS上的SOAP与Billboard Service进行通信。

　　结束语

　　尽管本文仅提供了对统一建模语言UML的简要介绍，但还是鼓励大家把从这里学到的基本信息应用到自己的项目中，同时更深入地钻研UML。已经有 多种软件工具可以帮助您把UML图集成到软件开发过程中，不过即使没有自动化的工具，您也可以使用白板上的标记或者纸和笔来手工绘制UML图，仍然会获益 匪浅。 

　　关于作者

　　Donald Bell 是 IBM 全球服务的一个 IT 专家，在那儿他和 IBM 的客户一起致力于设计和开发基于软件解决方案的 J2EE。

 

UML用例图总结

出处：http://blog.csdn.net/tianhai110

 

用例图主要用来描述用户、需求、系统功能单元之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

 

用例图所包含的元素如下：

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序列图总结

序列图主要用于展示对象之间交互的顺序。

序列图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

 

序列图中涉及的元素：

1.   生命线：

生命线名称可带下划线。当使用下划线时，意味着序列图中的生命线代表一个类的特定实体。

 

 

2.       同步消息

发送人在它继续之前，将等待同步消息响应

 

3.       异步消息

在发送方继续之前，无需等待响应的消息

 

4.       注释

 

5.       约束

约束的符号很简单；格式是: [Boolean Test]

 

 

6.       组合片段

组合片段用来解决交互执行的条件及方式。它允许在序列图中直接表示逻辑组件，用于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。

常用的组合片段有：

a.       抉择（Alt）

抉择用来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if..else..。

抉择在任何场合下只发生一个序列。可以在每个片段中设置一个临界来指示该片段可以运行的条件。else的临界指示其他任何临界都不为 True 时应运行的片段。如果所有临界都为 False 并且没有 else，则不执行任何片段。

 

 

 

b.       选项（Opt）

包含一个可能发生或不发生的序列

 

c.       循环（Loop）

片段重复一定次数。可以在临界中指示片段重复的条件。

 

d.       并行（Par）

 

 

下表列出了常用的组合片段：

片段类型	名称	说明
Opt	选项	包含一个可能发生或可能不发生的序列。可以在临界中指定序列发生的条件。
Alt	抉择	包含一个片段列表，这些片段包含备选消息序列。在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。else的临界指示其他任何临界都不为 True 时应运行的片段。如果所有临界都为 False 并且没有 else，则不执行任何片段。
Loop	循环	片段重复一定次数。可以在临界中指示片段重复的条件。 Loop 组合片段具有“Min”和“Max”属性，它们指示片段可以重复的最小和最大次数。默认值是无限制。
Break	中断	如果执行此片段，则放弃序列的其余部分。可以使用临界来指示发生中断的条件。
Par	并行	并行处理。片段中的事件可以交错。
Critical	关键	用在 Par 或 Seq 片段中。指示此片段中的消息不得与其他消息交错。
Seq	弱顺序	有两个或更多操作数片段。涉及同一生命线的消息必须以片段的顺序发生。如果消息涉及的生命线不同，来自不同片段的消息可能会并行交错。
Strict	强顺序	有两个或更多操作数片段。这些片段必须按给定顺序发生。

 

有关如何解释序列的片段

默认情况下，序列图表明可能发生的一系列消息。在运行的系统中，可能会出现您未选择显示在关系图上的其他消息。

以下片段类型可用于更改此释义：

片段类型	名称	说明
Consider	考虑	指定此片段描述的消息列表。其他消息可发生在运行的系统中，但对此描述来说意义不大。 在“Messages”属性中键入该列表。
Ignore	忽略	此片段未描述的消息列表。这些消息可发生在运行的系统中，但对此描述来说意义不大。 在“Messages”属性中键入该列表。
Assert	断言	操作数片段指定唯一有效的序列。通常用在 Consider 或 Ignore 片段中。
Neg	否定	此片段中显示的序列不得发生。通常用在 Consider 或 Ignore 片段中。

 

UML类图几种关系的总结

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

 

1.泛化(Generalization)

【泛化关系】：是一种继承关系,它指定了子类如何特化父类的所有特征和行为例如：老虎是动物的一种.

【箭头指向】：带三角箭头的实线，箭头指向父类

2.实现（Realization)

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

【箭头指向】：带三角箭头的虚线，箭头指向接口

3.关联（Association）

【关联关系】：是一种拥有的关系,它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子

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

【代码体现】：成员变量

【箭头及指向】：带普通箭头的实心线，指向被拥有者

 

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。

 

上图为自身关联：

 

4. 聚合（Aggregation）

【聚合关系】：是整体与部分的关系.如车和轮胎是整体和部分的关系.

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码体现】：成员变量

【箭头及指向】：带空心菱形的实心线，菱形指向整体

 

 

5. 组合(Composition)

【组合关系】：是整体与部分的关系.,没有公司就不存在部门      组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期

【代码体现】：成员变量

【箭头及指向】：带实心菱形的实线，菱形指向整体

 

 

6. 依赖(Dependency)

【依赖关系】：是一种使用的关系,所以要尽量不使用双向的互相依赖。

【代码表现】：局部变量、方法的参数或者对静态方法的调用

【箭头及指向】：带箭头的虚线，指向被使用者

 

 

 

各种关系的强弱顺序：

泛化= 实现> 组合> 聚合> 关联> 依赖

 

下面这张UML图，比较形象地展示了各种类图关系：