很多编程语言支持多种编程范式例如C++、Objective-C等就都支持面向对象编程、过程化编程等，而后产生的Java、C#等都是完全面向对象的。目前流行的脚本语言Python和Ruby本身就是面向对象的，Perl 5、PHP 4中也加入了面向对象的特性。
面向对象的方法比起以往的方式具有更好的可维护性、扩展性、复用性。通过将需求中稳定的对象封装成类，将较易改变的数据封装成属性，最易变化的功能封装成方法，提供高效稳定的基础；通过继承、关联、封装等手段，搭建起类库、框架等重用机制，使得开发变得更加方便快捷；也更符合人们的思维习惯。
项目或者产品的情况比较复杂，规模比较大需要用图形抽象地表达比较复杂的概念，增强设计的灵活性、可读性和可理解性，保证大规模开发的协同合作。另外，方便暴露深层次的设计问题，降低开发风险，也是有必要有一种比较好的表述的。而且，和业务人员进行交流，明确业务流程和功能需求时，也需要一种能够高效一致的交流工具，这时候，这些图形和符号就是一种有用的工具。
如果你只是做一个很小的或者功能比较单一流程比较简单的项目。例如做一个合同管理，主要功能是录入合同的数据，做一些增删改查的基本操作，使用的人员也不多，就那么几个，似乎也可以不用UML来进行系统的分析表述，或者只需要在有必要的时候选择性的做一些类图、用例图、顺序图来描述清楚局部的问题也就可以了。
但是复杂的、大型的、 长期演进的项目，还是很有必要使用UML这种标准的分析设计工具的。UML如果采用 Rational统一过程来作为软件开发模式的话是必不可少的工具。如果采用XP（轻量级）、CMMI（重量级）等开发模式时，就不是必须的了,用各类编辑工具如word来画一些图例来表达你的思想也是可以的。不过大规模应用和产品不管使用轻量级还是重量级的软件方法一般都推荐使用UML。UML的基本常识
统一建模语言（UML，英语：Unified Modeling Language）是非专利的第三代建模和规约语言。
UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。
UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。
UML集成了Booch，OMT和面向对象软件工程的概念，将这些方法融合为单一的，通用的，并且可以广泛使用的建模语言。
UML打算成为可以对并发和分布式系统的标准建模语言。
UML正在成为实际上的工业标准。
UML的工具
UML是在多种面向对象建模方法的基础上发展起来的建模语言，常见的建模工具Rational Rose，Microsoft Visio，Enterprise Architect，其中EA功能最强大。也有很多的开源软件和free的软件提供UML的实现：
ArgoUML，UML设计工具
Dia，可绘制流程图以及包含UML在内的多种图形
Umbrello，强大而又界面友好的UML工具。是KDE的一部分。
UMLet，用Java实现的UML简单绘图工具
Unimodeler，Linux下支持9种UML图和向量打印的工具
astah*，Java和UML开发者环境
Jumli，用Java实现，支持C++/C#/Java以及解析/生成源代码
omondo UML，Eclipse的UML插件，提供有限功能的免费版（需注册）和完整的商业版
Poseidon for UML，专业UML工具，提供免费的社区版（Community Edition）。从开源项目ArgoUML而来。
Violet是为学生、教师以及只需要快速创建简单UML的应用者而设计的工具，GPL授权。
UML的定义和架构
UML定义有两个部分组成：语义和表示法。语义是自然语言描述，表示法定义了UML的可视化标准表示符号，它决定UML是一种可视化的建模语言。为了更好的从不同角度观察系统，UML定义了“视图”。视图是对系统模型的投影，侧重于描述系统某一个方面。
视图的划分种类没有严格的规定，但是比较流行是4+1划分，这种划分也可以视为是UML的架构，如上图所示：
逻辑视图，描述系统中类、接口及模式等结构相关的内容。
实现视图，描述系统中的构件、文件、资源等相关的实现管理内容。
进程视图，描述系统的并发性、性能、规模等相关信息。
部署视图，描述系统如何配置、安装、执行等信息，包括硬件的分布、通信等内容。
用例视图，描述系统外部特征、系统功能。4+1中的1就是指用例视图，其他视图都是描述系统内部的各方面特征，用例视图是描述系统外部特征的，是以用户角度来描述功能需求的。
UML的基本构成
UML主要是有三个主要元素组成：
基本构造块，组织构造块的规则，运用于UML中的公共机制。
1.基本构造块有三种：事物、关系、图。
2.组织构造块的规则有：命名，作用域、可见性、完整性、执行。
3.公共机制：规则说明、修饰、通用划分、扩展机制。
下面我们就来简单介绍一下这些抽象的内容。
事物
事物分好为多种例如结构事物、行为事物、分组事物、注释事物。具体的事务包括：类、接口、协作、用例、主动类、构件、节点、交互、状态机、包、注释等。
类
说明一系列拥有相同的属性，操作，方法，关系，行为的对象集。一个类就代表了被建模系统中的一个概念。根据模型种类的不同，此概念可能是现实世界的（对于分析模型），或还可能含有算法和计算机实现的概念（对于设计模型）。
如上图所示，顾客账户这个类有名称，状态等属性；购物车、订单等操作；有新建账户、关闭账户等方法。
对于对象集的数据结构及行为的描述称为类。类用于声明变量，作为变量值的对象必须属于一个类，该类应与声明该变量的类兼容--也就是说，该类必须是声明变量的类或其后代类。类还用来实例化对象。一个创建操作生成给定类的一个新实例。
如图，类是用一个包括类名、属性、操作的矩形来表示。
接口
接口是类、构件或没有内部结构说明的其他实体（包括包等汇总单元）的外部可见的操作的描述符。
每个接口仅描述实际类的行为的有限部分。
一个类可以支持多个接口，效果上或互斥，或覆盖。
接口没有实现，缺少属性、状态和关联；它只有接收的信号和操作，接口可以有泛化关系，
子接口有其祖先的全部操作和所接收的信号。接口可有泛化关系。
例如上节提到的新建账户就是一个接口，用来实现顾客账户这个特定类为顾客创建新账户的行为。
接口是用包括一个圆形加一条直线来表示。
协作
协作描述了在一定的语境中一组对象以及用以实现某些行为的这些对象间的相互作用。它描述了为实现某种目的而相互合作的“对象社会”。
协作中有在运行时被对象和连接占用的槽。协作槽也叫做角色，因为它描述了协作中的对象或连接的目的。
类元角色表示参与协作执行的对象的描述；关联角色表示参与协作执行的关联的描述。
类元角色是在协作中被部分约束的类元；关联角色是在协作中被部分约束的关联。
协作中的类元角色与关联角色之间的关系只在特定的语境中才有意义。
通常，同样的关系不适用于协作外的潜在的类元和关联。
一个协作可以包含一个或多个交互，每个交互描述了一系列消息，协作中的对象为了达到目标交换这些消息。系统中的对象可以参与一个或多个协作。
虽然协作的执行通过共享对象相连，但是对象所出现的协作不必直接相关。
协作表示潜藏于计算过程中的三个主要结构的统一，即数据结构、控制流和数据流的统一。
用例
一个用例是一个连贯的功能性单元，由一个用消息的顺序来显示的类元（一个系统，子系统，或类）提供，这些消息与动作被系统执行的同时在系统和一个或更多个外部使用者（表现为参与者）间交换。用例的目标是要定义类元（包括一个子系统或整个系统）的一个行为，但并不显示类元的内部结构。每个用例说明一个类元提供给它的使用者的一种服务，也即一种对外部可见的使用类元的特定方式。它描述由某用户以用户和类元间交互的观点来初始化的完整的顺序，以及由类元执行的响应。这里的交互只包括系统与参与者之间的通讯。内部行为和实现是隐藏的。
如上图所示用例图中用例是用一个包括用例名字的椭圆形来表示。如果用例的属性和操作必须被显示出来，可以将用例绘制成一个带有关键字use case的矩形类元。
主动类
主动类的实例是主动对象，主动类的构造型是进程和线程。一个主动对象不在另一个线程、栈帧或状态机内运行。在整个系统的执行中，它具有独立的控制期。从某种定义来说，它是一个线程。一个传统的操作系统进程最好等同于一个主动对象。操作系统线程可以由或不由主动对象实现。
上图表示一个工厂自动化系统的三个主动对象：一个机器人、一个炉子和一个工厂管理者，其中管理者是一个控制对象。三个对象都同时存在和执行。工厂管理者在步骤1初始化一个控制线程，这个线程会分成两个分别由炉子和机器人执行的并发控制线程（A1和B1）。当每一个执行完毕，就合并到工厂管理者的步骤2。每个对象仍然存在且保持状态直到下一个事件到来。
构件
构件是定义了良好接口的物理实现单元，它是系统中可替换的部分。每个构件体现了系统设计中特定类的实现。良好定义的构件不直接依赖于其他构件而依赖于构件所支持的接口。在这种情况下，系统中的一个构件可以被支持正确接口的其他构件所替代。
构件具有它们支持的接口和需要从其他构件得到的接口。接口是被软件或硬件所支持的一个操作集。通过使用命名的接口，可以避免在系统中各个构件之间直接发生依赖关系，有利于新构件的替换。构件视图展示了构件间相互依赖的网络结构。构件视图可以表示成两种形式，一种是含有依赖关系的可用构件（构件库）的集合，它是构造系统的物理组织单元。它也可以表示为一个配置好的系统，用来建造它的构件已被选出。在这种形式中，每个构件与给它提供服务的其他构件连接，这些连接必须与构件的接口要求相符合。
构件用一边有两个小矩形的一个长方形表示，它可以用实线与代表构件接口的圆圈相连。
节点
节点是表示计算资源的运行时的物理对象，通常具有内存和处理能力。节点可能具有用来辨别各种资源的构造型，如CPU、设备和内存等。节点可以包含对象和构件实例。
节点用带有节点名称的立方体表示，可以具有分类（可选）。
节点间的关联代表通信路径。关联有用来辨别不同路径的构造型。节点也有泛化关系，将节点的一般描述与具体的特例联系起来。
对象在节点内的存在用嵌套在节点符号内的对象符号来表示。如果这样的表示不方便，对象符号可以包含表示它所在节点名称的 location标签。节点间对象或构件实例的迁移也可以表示出来。交互
说明对象或其他实例是如何传递消息的，交互在合作的语境中定义。
合作中的对象或其他实例为了完成某一任务（如执行一个操作）而通过信息交换来进行通信。信息可以包括信号、调用。为完成一个特定目的而进行的信息交换的模式称为交互。
交互用顺序图或合作图表示，两种图都能表示合作的执行。顺序图明确地表示了合作的行为，包括信息的时间顺序以及方法激活动的显式表示。但顺序图只表示参与的对象而不表示它们与其他对象的关系和属性。因此，它不能全面表示合作的语境视图。合作图表示交互的完整语境，包括对象及其关系，因此对设计更为适用。
上图是一个顺序图。
状态机
对象或者交互在其声明周期里为响应事件而经历的状态的顺序的声明，连同它的响应事件。状态机附加在一个源类，合作或者方法上，声明源元素实例的行为。状态机是一个状态和转换的图，描述了某类元的实例对事件接收的响应。一个完整的状态机是一个已经被分解为子状态的复合状态。如果一个状态是活动的，那离开这个状态的转换可能会激发，引起一个动作的执行，使得一个状态代替原来的状态。状态机的结构和状态的转换对可以并发活动的状态施加了限制。简单的说，如果一个顺序复合状态处于活动，只有一个互斥的直接子状态必须处于活动。如果一个并发复合状态处于活动，每个直接子状态都必须处于活动。
上图是一个顾客登录情况的状态图。
包
一个包元素对外的可见性可以通过在该元素的名字前面添加可见性标志来加以说明（'+'表示公共，'-'表示私有，'#'表示被保护）。可以画出包符号之间的关系以显示包中的一些元素之间的联系。特别的，包之间的依赖关系（不同于授权依赖关系，比如访问和导入）表明元素之间存在一种或多种的依赖关系。
包是用带有包名称的一大一小两个矩形来表示。
上图是一个订单处理子系统的包结构图。
注释
表示备注或者其他文本信息的符号，例如方法体或者约束。
注释表示为右上角向下折的矩形。其中有不能有UML翻译的文本，或者文本的扩展（如嵌入文件）。注释可以为不同的模型元素提供信息，如备注、约束、方法等。通常不会明确说明其解说的元素类型，但可以从格式和使用中看出来。可用虚线与元素相连。如注释解释多个元素，虚线指向每个元素。注释可以有关键字来说明其意义，如关键字constraint说明这是约束。
上图是右下角为一个顺序图的注释。
关系
UML中的关系有4种：依赖、关联（包括聚合、复合）、泛化、实现。下面我们来了解一下这4种关系。
依赖
两个元素之间的一种关系，其中一个元素（服务者）的变化将影响另一个元素（客户），或向它（客户） 提供所需信息。它是一种组成不同模型关系的简便方法。
依赖关系是表示一个或几个模型中两个元素间关系的语句。它可以将几种不同的元素结合起来。好像生物学中用"无脊椎动物"结合所有不是"脊椎动物"的不同门的生物。
关联和泛化关系满足依赖关系的一般定义，但是它们有各自的模型表示法和含义，通常不被视为依赖关系。实现关系有独立的表示法，但是被视为依赖关系。
有几种不同的依赖关系：抽象、绑定、组合、许可、使用。
关联
如果几个类元的实例之间有联系，那么这几个类元之间的语义关系即关联。
关联是两个或多个特定类元之间的关系，它描述了这些类元的实例的联系。参与其中的类元在关联内的位置有序。在一个关联中同一个类可以出现在多个位置上。关联的每个实例（链接）是引用对象的有序表，关联的外延即这种链接的一个集合。在链接集合中给定的对象可以出现多次，或者在关联的定义允许的情况下可以在同一个链中（在不同的位置）出现多次。关联将一个系统组织在一起，如果没有关联，那只有一个无连接类的集合。
二元关联用连接两个类边界的实线路径表示，n元关联用菱形表示，菱形通过路径与每个参与到其中的类连接，路径的多个端点可以连接到一个独立的类。
泛化
泛化是两个同类的可泛化元素之间的直接关系。其中一个元素被称为父，另一个为子。对类而言，父称为超类（superclass）,子成为子类。父所说明的直接实例带有所有子的共同特点，子所说明的实例是上述实例的子集，不仅有父的特征，还有独有的特征。
泛化是一种反对称关系。按照一个方向转变成为父，另一个方向引向子。在父方向上经过一个或几个泛化关系的元素称为祖先；在子方向上经过一个或几个泛化关系的元素称为子。不允许出现泛化环，一个类不能既是自己的祖先又是自己的后代。
在最简单的情况下，类（或者其他可泛化元素）有单一的父。在复杂情况下，子有多个父。子继承了父的所有结构、行为和约束，称为多重继承（或者多重泛化）。父元素对子元素有可视性。
关联、类元、状态、事件和合作都可以泛化。
类元之间的泛化关系表示为子元素（如子类）到父元素之间的实线路经，路径指向更广泛的元素的一端带有空心的三角形。
实现
定义某事物是如何构造、计算的。例如，类是类型的实现；方法是操作的实现。对比：说明。实现和说明之间是实现关系。
用可执行的媒介（如程序设计语言、数据库、数字化硬件）描述系统功能的一个步骤。对实现而言，必须产生下层的决策以使设计适合具体的实现媒介，并与环境相适应（每种语言有各自的限制）。
如果设计得好，实现的决策将是局域性的，任何决策不会影响系统的全局。这一步由实现层模型捕捉，特别是静态图和代码。对比：分析、设计、实现和配置。
这是真正码农们必须干的活，无论什么系统，多大多小。
图的种类
图是UML可视化最重要的载体。先列个清单供大家参考：
1.功能模型：从用户的角度展示系统的功能。用例图，对用户/系统的交互关系建模。用脚本和情形的形式来定义行为，要求和约束。
2.对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础。
类图，用来定义模型基本建立模块，类型、类和构成完整模型的一般素材。
对象图，显示结构元素的实例间如何关联，以及在运行时如何使用。
复合结构图，提供一种对元素结构进行分层的方法，着重体现元素内部细节，结构和关系。
构件图，用来构造复杂结构，通常由一个或多个类构成，并提供一个定义明确的接口。
部署图，显示现实环境中重要物件的物理配置。
包图，用来将模型划分成不同逻辑容器或“包”，并描述它们之间的交互关系。
3.动态模型：展现系统的内部行为，用来记录在一个模型内部，随时间的变化，模型执行的交互变化和瞬间的状态；并跟踪系统在真实环境下如何表现，以及观察系统对一个操作或事件的反应，以及它的结果。
活动图，广泛使用于定义基本程序流程和在一般化过程中，记录判断点和动作。
状态图，对于了解模型执行时的瞬时状态，即模型的运行状态是重要的。
协作图，显示协作实例中，对象间实时消息和通信的网络结构与顺序。
顺序图，与通信图联系紧密，并在垂直时间线上显示对象间消息传递的顺序。
时序图，融合顺序图和状态图，提供观察对象随时间变化的状态和改变这个状态的消息。
交互概览图，融合活动图和顺序图，使交互部分容易与判断点和流程结合。
下面我们来介绍几个常用的图。
用例图
用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。表示处于同一系统中的参与者和用例之间的关系的图，称之为用例图，目的是显示哪个参与者参与了哪个用例的执行。
一个用例图是一个包括参与者、由系统边界（一个矩形）封闭的一组用例、参与者和用例之间的关联、用例间的联系以及参与者的泛化等的图。
上图是一个用例图，分别表示了顾客和网站管理员参与的账户管理相关用例的交互作用。
类图
类图，用静态视的方式表示声明的（静态的）模型元素，比如类、类型及其元素及相互关系。类图包含一些具体的行为元素，如操作，但是它们的动态特征是在其他图中表示的，例如状态图。
上图是购物网站的简单类图示例。
对象图
对象图显示某时刻对象和对象之间的关系。一个对象图可看成一个类图的特殊用例，实例和类可在其中显示。
对于对象图来说无需提供单独的形式。类图中就包含了对象，所以只有对象而无类的类图就是一个"对象图"。然而，"对象图"这条短语在刻画各方面特定使用时非常有用。
上图是购物网站顾客购买书籍时，一个对象图示例。
构件图
表示构件类型的组织以及依赖关系的图。
构件图表明了软件构件之间的依赖关系，包括源代码构件，二进制代码构件和可执行代码构件。软件模块可以用一个构件来表示。
有些构件存在于编译时，有些存在于连接时，有些存在于执行时，有些在多种场合存在。一个编译时构件只在编译时有意义。在这种情况下运行时构件是可执行的程序。
上图是一个使用asp.net架构开发网站购物系统的构件图。
部署图
表示运行时过程节点结构、构件实例及其对象结构的视图。构件代表代码单元在运行时的表现。不作为运行时内容的构件不出现在部署图中，而是在构件图中表示。部署图表现实例；构件图表现构件类型的定义。
部署图含有用通信链相连的节点实例。节点实例包括运行时的实例，如构件实例和对象。
部署图有描述符形式和实例形式。
实例形式（前文已经介绍过）表现了作为系统结构的一部分的具体节点上的具体构件实例的位置。这是部署图的常见形式。
描述符形式说明哪种构件可以存在于哪种节点上，哪些节点可以被连结，类似于类图。
上图是一个网站购物系统实例形式的部署图。
活动图
活动图是强调计算过程中顺序的和并发步骤的状态机。活动图通常出现在设计的前期，即在所有实现决定前出现，特别是在对象被指定执行所有活动前。
这种图是状态机的特例，在它当中状态代表活动的执行，就像一个计算或真实世界不间断的操作，而转换由操作的完成触发。活动图可以附属于操作和用例的实现。
几种速记表示法也适用于活动图，如：活动状态、分支、合并、泳道、对象流状态、状态类、信号发送和信号接收表示法和延迟事件。
上图是一个顾客在购物网站下了订单后，网站的活动图示例。
顺序图
顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。
上图是购物网站顾客新建账户的顺序图。
状态图
一个状态图显示一个状态机或者状态机的一部分。状态用状态符号表示，转换用连接状态符号的箭头表示。
状态图表示法是David Hard 发明的, 并且结合了莫而机(有关进入的动作)和米里机(有关转换的动作)的各个方面，而且增加了嵌套状态和并发状态的概念。
上图是一个系统登录过程的状态图。
规则
1.命名：为事物、关系和图等起名。
2.作用域： UML成员所定义的内容起作用的上下文环境。某个成员在每个实例中代表一个值，还是代表这个类元的所有实例的一个共享值，由上下文决定。
3.可见性：UML成员能被其他成员引用的方式。如类中属性或操作定义存储权限，加前缀：+ (公用)、- (私用)、# (保护)。
4.完整性：UML成员间互相连接的合法性和一致性。
5.执行：UML成员在运行时的特性。
命名
用于标识模型元素的字符串。
名字是一种标识符--用某种程序设计语言预先定义的有限的字符序列。实现方法可以规定名字的格式，例如不得包含某种符号（如标点符号），还可以规定初始规则等等。
名字是在命名空间内定义的，如包或者类。命名空间中，名字在其所在的语义组内必须是唯一的，如类元、状态、属性等；不同组内的名字可以迭代（但是也应该避免）。每个命名空间属于更大的命名空间。嵌套的名字及其外部名字以至最外层元素的名字可以用一个名字路径串表示。
所有有名字的元素都在命名空间内声明，它们名字的范围也是该命名空间。顶级的命名空间是包
名字表示为字符串。名字通常单独列为一行。规范的名字格式包括字符、数字、下划线。
可见性
一个枚举，其值（公有的，受保护的，或私有的）说明了它所涉及的模型元素是否在其命名空间的外部可见。可见性声明了建模元素引用一个元素的能力，此元素与引用元素处于不同的命名空间。可见性是一个元素和包含它的容器之间的联系的一部分，容器可以是包、类或某个其他的命名空间。有三个预定义的可见性。
公有的：任一元素，若能够访问容器，则也能够访问包容器指出的元素。任一元素，若能够访问容器，则也能够访问包容器指出的元素。
受保护的：只有容器中的元素或包容器的子孙能够访问指出的元素，其他元素不能引用或使用它。只有容器中的元素或包容器的子孙能够访问指出的元素，其他元素不能引用或使用它。
私有的：只有包容器中的元素能够访问指出的元素。其他元素，包括包含体的子孙的元素，都不能引用或使用它。只有包容器中的元素能够访问指出的元素。其他元素，包括包含体的子孙的元素，都不能引用或使用它。
可见性用放在模型元素前的一个特定的关键字或一个标记符来表示。+ (公用)、- (私用)、# (保护)。
公共机制
1.规则说明：在UML中，每个模型元素的图形表示法之后都存在一个规约，它以文字的形式描述基本模型元素的语法和语义。如，在类的图符之后就有一个全面描述该类所拥有的属性、操作和行为的规约；在视图上，类的图符可能仅展示了部分规约。UML的图形表示法可视化地描述系统，而UML的规约则用来描述系统的细节。
2.修饰：在图的模型元素上添加修饰，可为模型元素附加一定的语义。如，类的图形符号展示了类名、操作和属性这些最重要的信息。但也可以给类增添修饰符以给出类规约的细节。如，用斜体类名表示它是抽象类，用+和#表示属性和操作的可见性。UML众多的修饰符中，注释是一种最重要的并且能单独存在的修饰符，它是附加在模型元素或元素集上用来表示约束或注解 信息的图形符号。
3.通用划分：UML提供了事物的抽象的描绘和具体的实例两种两分法表达，被称为通用划分。对象和类使用同样的图形符号。类用长方形表示，并用名字加以标识，当类的名字带有下划线时，则它代表该类的一个对象。两分法：接口和实现的两分划分。接口定义一种协议，实现是此协议的实施。UML里这样的接口与实现的两分划分包括接口/类或组件、用例和协同，以及操作和方法。
4.扩展机制：
衍型：对UML的词汇的扩展，用于创建与已有的模型元素相似且针对特定问题的新种类的模型元素。用书名号括起来的名字表示，其位置在其他元素之上。
标记值：对UML元素的特性的扩展，用于在模型元素的规约中创建新的信息。用花括号括起来的字符串表示，其位置在其他元素之下。
约束：对UML元素的语义的扩展，用于增加新规则或修改已有规则。用花括号括起来的字符串表示，且放在所关联的元素附近或通过依赖关系连接相应元素。
扫一扫
8782
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
