下载文档原格式
电子商务系统UML图汇总1 引言1.1 项目背景信息化是当今世界发展的大趋势，是推动经济社会发展和变革的重要力量。
随着信息化时代的到来，信息传播发生了深刻的变革，人们的工作方式、生活方式乃至思维方式都发生了前所未有的改变，各行各业都在顺应这一时代变革加强信息化建设。
谁能在信息化变革时期先人一步，就能获得先机，抢占鳌头。
传统的销售方式是商家把商品放在店铺里供顾客挑选，店铺的规模、位置等客观因素影响着商店的客流量，并且商品的存放与销售需要人力进行管理，雇员的工资、店面的租金等又增加了成本，顾客也不能迅速找到所需要的商品，而开一个网上商店只需要一个可以存放商品的仓库，比租一个店面能节省很多，也不需要太多的人力来管理，不会因为商店的面积影响客流量，客户足不出户就能买东西，并且很容易就能找到所需要的商品。
近年来，随着Internet的迅速崛起，互联网已日益成为收集提供信息的最佳渠道并逐步进入传统的流通领域。
于是电子商务开始流行起来，越来越多的商家在网上建起在线商店，向消费者展示出一种新颖的购物理念。
网上购物系统作为B2B，B2C（Business to Customer，即企业对消费者），C2C（Customer to Customer，即消费者对消费者)电子商务的前端商务平台，在其商务活动全过程中起着举足轻重的作用。
本文主要考虑的是如何建设B2C 的网上购物系统。
网上购物是一种具有交互功能的商业信息系统，它向用户提供静态和动态两类信息资源。
所谓静态信息是指那些比经常变动或更新的资源，如公司简介、管理规范和公司制度等等；动态信息是指随时变化的信息，如商品报价，会议安排和培训信息等。
网上购物系统具有强大的交互功能，可使商家和用户方便的传递信息，完成电子贸易或EDI交易，这种全新的交易方式实现了公司间文档与资金的无纸化交换【1】。
可行性研究建设Web平台系统的必要性取决于需求的迫切性和实现的可能性。
可行性并不等于可能性，它还包括必要性，如果领导或管理人员对信息的需求并不迫切或各方面的条件不具备，就是不具备可行性。
UML的信息流图随着软件开发领域的不断发展，越来越多的企业和组织选择采用UML（统一建模语言）来进行项目管理和开发。
UML是一种通用的建模语言，可以为软件和系统开发提供支持。
其中一种UML图表就是信息流图，它可以用来显示系统中不同对象之间的信息流动情况。
本文将介绍信息流图的基本概念、组成和应用。
一、信息流图的概念信息流图是UML中的一个图表，用于显示系统中不同对象之间的信息流动。
UML定义了两种不同类型的信息流图：活动图和顺序图。
活动图通常用于描述业务流程或工作流程，而顺序图则用于表示任务或动作之间的流程。
在信息流图中，不同的形状代表了不同的对象，而箭头则表示信息流动的方向。
信息流图不仅可以用于软件设计，还可以用于概念模型和业务流程的建模。
二、信息流图的组成1.对象信息流图的对象是指流程中出现的所有元素，可以是人、系统、设备等。
UML定义了一些标准符号来表示对象，如矩形用于表示人或系统，圆圈用于表示设备等。
2.活动活动是流程中的一个步骤，通常代表一个动作或任务。
活动可以是手动或自动执行的，也可以是并行或顺序执行的。
活动用带圆角矩形的形式表示。
3.控制流控制流用于描述流程中活动的执行顺序和控制流程的流动。
控制流通常用箭头表示，箭头的方向代表了活动的执行顺序。
4.数据流数据流用于描述信息在系统中的流动情况。
数据流可以是文本、数字或其他形式的数据，通常用带箭头的直线表示。
箭头的方向表示数据流动的方向。
5.决策节点决策节点用于描述不同条件下的流程分支。
决策节点通常用菱形来表示，其中每个分支对应一个不同的方向箭头。
6.合并节点合并节点用于将不同分支的流程集成回来。
合并节点通常用菱形来表示，其中每个入口对应一个不同的箭头。
三、信息流图的应用信息流图是一种常用的UML图表，可以用于软件开发、业务流程描述和系统设计等领域。
以下是信息流图的一些应用：1.系统设计信息流图可以用于显示不同对象之间的信息流动情况，从而帮助系统设计师设想出一个合理的结构。
UML的流程图UML是一种面向对象的统一建模语言，用于快速地描述软件系统的结构、行为和交互。
而流程图是UML中的一种图形语言，用于对系统中的流程进行描述和设计。
本文将为大家介绍UML流程图的概念、种类、结构和使用方法。
概念UML流程图，也称UML活动图，是一种图形化的表示算法、流程和业务过程的工具，它可以直观地表达系统中的任务、动作、决策和控制流程。
UML流程图常用于软件开发过程中的需求分析、业务流程设计、系统架构设计等领域。
种类UML流程图包含四种基本类型：1.基本活动图基本活动图可以用来表示操作的顺序或并行方式，其中每个操作都是基本动作，例如读取、写入、计算等。
基本活动图通常用于领域建模和系统流程的初步设计。
2.流程状态图流程状态图是对系统中复杂操作的一种表示，可以用来展示操作的状态和转换方式。
流程状态图主要包括状态、转换和起始状态，它通常用于描述系统中的复杂业务流程。
3.并发活动图并发活动图可以用来表达系统中多个处理程序的并发执行过程，它通常使用平行线表示并发执行的多个处理程序。
4.条件活动图条件活动图是一种用于表示系统中动态交互的活动图，其中条件是关键的组成部分。
条件活动图通常用于强制执行程序在满足一定条件的情况下才能执行，例如软件开发中经常用到的循环结构和分支结构等。
结构UML流程图的结构由一系列基本元素组成：1.开始节点开始节点，在UML流程图中表示整个活动图的起点。
一般情况下，开始节点在活动图的左侧上方，使用一个表示圆圈中心的空心点表示。
2.结束节点结束节点，在UML流程图中表示整个活动的结束点。
一般情况下，结束节点位于活动图的右侧下方，使用一个表示实心点的圆圈表示。
3.动作节点动作节点是一种执行操作的元素，可以进行计算、赋值、IO操作等。
动作节点在UML流程图中通常用长方形表示。
4.决策节点决策节点用于表示一个条件分支，并根据条件的结果选择一个或多个分支行动。
在UML流程图中，它通常使用菱形表示。
·单向关联在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。
一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。
如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。
简单的说就是OverdrawAccountReport中包含了BankAccount属性，而BankAccount中不需要包含OverdrawnAccountsReport对象6.聚合的表示：聚合是一种特别类型的关联，用于描述“总体到局部”的关系。
在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。
你想到的问题在小组里交流，每举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。
轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。
在这个实例中，Wheel类实例清楚地独立于Car类实例而存在。
然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。
举例来说，考虑公司与部门的关系。
公司和部门都建模成类，在公司存在之前，部门不能存在。
这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
注意：聚合与普通的关联的区别在于：普通的关联可能只是一个简单的“包含、引用”关系，关联和被关联类之间在逻辑概念上不一定有紧密的联系，而聚合则不同，它表示的是一种内在关系紧密，相互依存，相互包含的概念，其中的一部分是构成另外一部分的不可或缺的成分。
·基本聚合有聚合关系的关联指出，某个类是另外某个类的一部分。
在一个聚合关系中，子类实例可以比父类存在更长的时间。
为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。
图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。
体系结构设计模型的表示方法体系结构设计模型的表示介绍体系结构设计模型是建立软件系统架构的关键步骤之一。
在设计过程中，如何准确地表示和展示系统的架构是十分重要的。
本文将介绍几种常用的体系结构设计模型的表示方法。
1. UMLUML（统一建模语言）是一种常用的软件工程建模语言，用于表示和描述系统的架构。
UML提供了多种图表，如用例图、类图、组件图、部署图等，能够很好地表示系统的结构和关系。
•用例图：用于描述系统功能和用户之间的交互。
•类图：用于描述系统中的类和它们之间的关系。
•组件图：用于描述系统中的模块和它们的依赖关系。
•部署图：用于描述系统的物理架构和部署方案。
2. 架构图架构图是一种更高层次的表示方法，它能够直观地展示系统的组成部分和它们之间的关系。
常见的架构图包括：•静态结构图：用于表示系统的静态组成，如层次结构图、模块图、包图等。
•动态行为图：用于表示系统的动态行为，如时序图、活动图等。
•部署图：用于描述系统的物理架构和部署方案。
3. 代码注释代码注释是一种简单而直接的体系结构表示方法。
通过在代码中添加注释，可以解释和说明代码的结构和设计思路。
代码注释可以采用各种规范和工具，如Javadoc、XML注释等。
4. 文档文档是另一种常用的体系结构表示方法。
通过编写详细的文档，可以描述系统的组成部分、接口细节、设计原理等，从而帮助人们理解和使用系统。
5. 绘图工具绘图工具是一种辅助工具，可以帮助开发人员创建和编辑各种类型的图表。
常见的绘图工具有Visio、Draw.io、Lucidchart等，它们提供了丰富的图形库和编辑功能，能够高效地创建和修改系统架构图。
总结在体系结构设计过程中，合适的表示方法能够更好地帮助开发人员理解和描述系统的架构。
本文介绍了几种常用的体系结构设计模型的表示方法，包括UML、架构图、代码注释、文档和绘图工具。
开发人员可以根据实际需求选择合适的表示方法，从而更好地设计和开发软件系统。
1.用例图：用例图是从用户的观点描述系统的功能，它由一组用例、参与者以及他们之间的关系组成他将系统的一个功能描述成一系列事件，这些事件最终对参与者产生有价值的可观测结果参与者（Actor）：代表与系统交互的外部实体用例（Use-Case）：表示系统能提供的功能，如：登录，查询等关联关系：当参与者与用列进行交互时，用例与参与者之间有关联关系，用一条直线表示这种关系参与者之间可能存在泛化关系，类似的参与者可以用泛化关系组成一般与特殊的层析结构如：经理初次之外，用例之间还存在一定的关系，具体包括包含（include）、扩展（extend）、泛化（Generalization）等3种关系（1）包含关系一个复杂系统中，不同用例之间可能存在一些相同的行为，这时可将这些相同的行为提取出来单独组成一个用例。
当其他用例使用该用例时，用例之间便形成了包含关系包含关系用带关键字<<include>>的虚线来表示，虚线指向被包含的用例注册新用户（2）扩展关系在用例的执行过程中，可能会出现异常行为，也可能在不同的流程分支中选择执行，这时可将异常行为或可选分支抽象成一个单独的扩展用例，它与主用例之间形成扩展关系扩展关系用带关键字<<extend>>的虚线表示，箭头指向被扩展的用例注册（3）泛化关系与参与者之间的泛化关系一样，用例之间的泛化关系是描述用例之间一般与特殊关系的，不同的子用例代表了父用例的不同实现方法。
密码找回2.类图类图描述系统的静态结构，表示系统中的类、类与类之间的关系以及类的属性和操作类用一个矩形方框表示，方框被分成3部分，最上面显示类名，中间部分显示类的属性，最下面显示类的操作类之间的关系包括关联、聚合、泛化、依赖等类型关联（Association）是一种结构定义，表达模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义链的描述，使用一条连接在两个类之间的实线表示，关系的每一端用数字表示关系的重数。
软件系统的建模的方法和介绍软件系统建模是将现实世界中的问题抽象表示为计算机能够理解和处理的形式的过程。
它是软件开发过程中的关键步骤之一，可以帮助开发团队更好地理解问题领域，并以一种可视化的方式来描述系统的结构和行为。
下面将介绍几种常见的软件系统建模方法。
1. 面向对象建模方法：面向对象建模是一种基于对象的方法，它将问题领域分解为多个独立的对象，并描述它们之间的关系和行为。
常用的面向对象建模方法包括UML（统一建模语言）和领域模型（Domain Model）等。
UML是一种广泛应用的面向对象建模语言，它提供了用于描述系统结构、行为和交互的图形符号和语法规则。
2. 数据流图（Data Flow Diagram, DFD）建模方法：数据流图是描述软件系统中数据流动的图形化工具。
它将系统分解为一系列的功能模块，通过数据流和处理过程之间的关系来描述系统的结构和行为。
数据流图主要包括外部实体、数据流、处理过程和数据存储等基本元素。
3.结构化建模方法：结构化建模是一种基于流程的建模方法，它主要通过流程图和结构图来描述系统的结构和行为。
流程图用于描述系统中的控制流程和数据流动，结构图用于描述系统中的数据结构和模块关系。
常见的结构化建模方法包括层次图、树形图和PAD（程序设计语言图）等。
4.状态图模型：状态图是一种描述系统状态和状态转换的图形化工具。
它主要包括状态、转移和事件等元素，用于描述系统中的各种状态及其变化过程。
状态图可以帮助开发团队清晰地理解系统的状态转换规则和事件响应机制。
5.时序图和活动图：时序图和活动图是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注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
·单向关联在一个单向关联中，两个类是相关的，但是只有一个类知道这种联系的存在。
一个单向的关联，表示为一条带有指向已知类的开放箭头（不关闭的箭头或三角形，用于标志继承）的实线。
如同标准关联，单向关联包括一个角色名和一个多重值描述，但是与标准的双向关联不同的时，单向关联只包含已知类的角色名和多重值描述。
简单的说就是OverdrawAccountReport中包含了BankAccount属性，而BankAccount中不需要包含OverdrawnAccountsReport对象6.聚合的表示：聚合是一种特别类型的关联，用于描述“总体到局部”的关系。
在基本的聚合关系中，部分类的生命周期独立于整体类的生命周期。
举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。
轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。
在这个实例中，Wheel类实例清楚地独立于Car类实例而存在。
然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期 -- 这称为合成聚合。
举例来说，考虑公司与部门的关系。
公司和部门都建模成类，在公司存在之前，部门不能存在。
这里Department类的实例依赖于Company类的实例而存在。
让我们更进一步探讨基本聚合和组合聚合。
注意：聚合与普通的关联的区别在于：普通的关联可能只是一个简单的“包含、引用”关系，关联和被关联类之间在逻辑概念上不一定有紧密的联系，而聚合则不同，它表示的是一种内在关系紧密，相互依存，相互包含的概念，其中的一部分是构成另外一部分的不可或缺的成分。
·基本聚合有聚合关系的关联指出，某个类是另外某个类的一部分。
在一个聚合关系中，子类实例可以比父类存在更长的时间。
为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。
图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，其中的一个类是另一个类的构成成分。
菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。
·组合聚合组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。
注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。
7.反射关联的表示：类也可以使用反射关联与它本身相关联。
起先，这可能没有意义，但是记住，类是抽象的。
当一个类关联到它本身时，这并不意味着类的实例与它本身相关，而是类的一个实例与类的另一个实例相关。
图描绘的关系说明一个Employee实例可能是另外一个Employee实例的经理。
然而，因为“manages”的关系角色有 0..*的多重性描述；一个雇员可能不受任何其他雇员管理。
三、UML中的对象图：实例的记号和类一样，但是取代顶端区域中仅有的类名，它的名字是经过拼接的: Instance Name : Class Name 如 Donald : Person因为显示实例的目的是显示值得注意的或相关的信息，没必要在你的模型中包含整个实体属性及操作。
相反地，仅仅显示感兴趣的属性及其值是完全恰当的。
UML 2 也允许在实体层的关系/关联建模。
绘制关联与一般的类关系的规则一样，除了在建模关联时有一个附加的要求。
附加的限制是，关联关系必须与类图的关系相一致，而且关联的角色名字也必须与类图相一致。
四、UML中的角色图：建模类的实例有时比期望的更为详细。
有时，你可能仅仅想要在一个较多的一般层次做类关系的模型。
在这种情况下，你应该使用角色记号。
角色记号类似于实例记号。
为了建立类的角色模型，你画一个方格，并在内部放置类的角色名及类名，作为实体记号，但是在这情况你不能加下划线。
注意：角色图和对象图的一个明显区别就是：对象图每个对象名称下面都加了下划线，而角色图没有以下是：序列图序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。
很象类图，开发者一般认为序列图只对他们有意义。
然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。
除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。
在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。
那种情况下，用例常常被细化为一个或者更多的序列图。
组织的技术人员能发现，序列图在记录一个未来系统的行为应该如何表现中，非常有用。
在设计阶段，架构师和开发者能使用图，挖掘出系统对象间的交互，这样充实整个系统设计。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。
用例常常被细化为一个或者更多的序列图。
序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。
当把这个系统移交给另一个人或组织时，这个文档很有用。
Java应用程序由许多类所构成，是Java实现面向对象应用程序的核心。
类图主要描述Java应用程序中各种类之间的相互静态关系，如类的继承、抽象、接口以及各种关联。
要利用UML设计Java应用程序，仅仅使用类图来描述这些静态关系，利用可视化工具，要实现Java应用程序的代码自动生成，是远远不够的。
我们还必须描述各种类相互之间的协作关系、动态关系，如时间序列上的交互行为。
其中UML序列图就是用来描述类与类之间的方法调用过程（或消息发送）是如何实现的。
一、UML中的新元素－框架：在UML 2中，框架元件用于作为许多其他的图元件的一个基础，但是大多数人第一次接触框架元件的情况，是作为图的图形化边界。
当为图提供图形化边界时，一个框架元件为图的标签提供一致的位置。
在UML 图中框架元件是可选择的。
除了提供一个图形化边框之外，用于图中的框架元件也有描述交互的重要的功能, 例如序列图。
在序列图上一个序列接收和发送消息（又称交互），能通过连接消息和框架元件边界，建立模型（如图 2 所见到）。
对于序列图，图的标签由文字“sd”开始。
当使用一个框架元件封闭一个图时，图的标签需要按照以下的格式：图类型图名称。
UML 规范给图类型提供特定的文本值。
（举例来说，sd代表序列图，activity代表活动图，use case代表用例图）。
二、UML中的序列图：序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。
在项目的需求阶段，分析师能通过提供一个更加正式层次的表达，把用例带入下一层次。
那种情况下，用例常常被细化为一个或者更多的序列图。
序列图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。
用例常常被细化为一个或者更多的序列图。
序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。
序列图的主要目的是定义事件序列，产生一些希望的输出。
重点不是消息本身，而是消息产生的顺序；不过，大多数序列图会表示一个系统的对象之间传递的什么消息，以及它们发生的顺序。
图按照水平和垂直的维度传递信息：垂直维度从上而下表示消息/调用发生的时间序列，而且水平维度从左到右表示消息发送到的对象实例。
1.生命线：生命线画作一个方格，一条虚线从上而下，通过底部边界的中心（图3）。
生命线名字放置在方格里。
UML 的生命线命名标准按照如下格式: 实体名:类名生命线名称带下划线。
当使用下划线时，意味着序列图中的生命线代表一个类的特定实体，不是特定种类的实体（例如，角色）。
序列图的实例名称有下划线，而角色名称没有。
一个生命线能用来表现一个匿名的或未命名的实体。
当在一个序列图上，为一个未命名的实例建模时，生命线的名字采用和一个命名实例相同的模式；但是生命线名字的位置留下空白，而不是提供一个例图名字。
2.消息体：为了显示一个对象（例如，生命线）传递一个消息给另外一个对象，你画一条线指向接收对象，包括一个实心箭头（如果是一个同步调用操作）或一个棍形箭头（如果是一个异步讯号）。
消息/方法名字放置在带箭头的线上面。
正在被传递给接收对象的消息，表示接收对象的类实现的一个操作/方法。
返回消息是可选择的；一个返回消息画作一个带开放箭头的虚线，向后指向来源的生命线，在这条虚线上面，你放置操作的返回值。
为了要画一个调用本身的对象，如你平时所作的，画一条消息，但是不是连接它到另外的一个对象，而是你把消息连接回对象本身。
三、UML中的约束：约束的符号很简单；格式是: 【Boolean Test】四、UML中的新元素－组合碎片（变体方案、选择项、循环）：一个组合碎片用来把一套消息组合在一起，在一个序列图中显示条件分支。
1.变体：变体用来指明在两个或更多的消息序列之间的、互斥的选择。
一个变体的组合碎片元件使用框架来画。
单词“alt”放置在框架的namebox里。
然后较大的长方形分为 UML 2 所称的操作元。
操作元被虚线分开。
每个操作元有一个约束进行测试，而这个约束被放置在生命线顶端的操作元的左上部。
如果操作元的约束等于“true”，然后那个操作元是要执行的操作元。
图 8作为一个变体的组合碎片如何阅读的例子，显示序列从顶部开始，即bank对象获取支票金额和帐户结余。
此时，序列图中的变体组合碎片接管。
因为约束“[balance >= amount]”，如果余额超过或等于金额，然后顺序进行bank对象传递 addDebitTransaction 和storePhotoOfCheck 消息给account对象。
然而，如果余额不是超过或等于金额，然后顺序的过程就是bank传递addInsuffientFundFee 和 noteReturnedCheck 消息给account对象，returnCheck 消息给它自身。
因为“else”约束，当余额不大于或者等于金额时，第二个序列被调用。
在变体的组合碎片中，不需要“else”约束；而如果一个操作元，在它上面没有一个明确的约束，那么将假定“else”约束。
2.选择项：一个选择项用来为简单的“if then”表达式建模。
（例如，如果架上的圈饼少于五个，那么另外做两打圈饼）。
选择项组合碎片符号与变体组合碎片类似，除了它只有一个操作元并且永不能有“else”约束以外（它就是如此，没有理由）。
要画选择项组合，你画一个框架。
文字“opt”是被放置在框架的 namebox 里的文本，在框架的内容区，选择项的约束被放置在生命线顶端上的左上角。
然后选择项的消息序列被放在框架的内容区的其余位置内。
注意：变体用于为if then else建模，选择项用于为if then建模，因为只有一个分支，所以不能出现[else]以下是：用例图：用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。
