氢原子百科 
统一建模语言（Unified Modeling Language，UML）是一种通用的标准化建模语言[1]，又称标准建模语言。它是一个支持模型化和软件系统开发的图形化语言[2]，面向对象设计，独立于任何具体程序设计语言，具有广泛的建模能力和坚实的理论基础[9]，能为软件开发的所有阶段提供模型化和可视化支持[10]，属于一个庞大的表示法体系[11]。
自1994年起，为达成建模语言统一效果，格雷迪·布奇（Grady Booch[4]）和吉姆·鲁姆博夫（Jim Rumbaugh[5]）将Booch 93和OMT-2统一了起来。1995年，在OOSE的创始人伊万·雅各布森（Ivar Jacobson[6]）加入开发后，统一建模语言的第一个公开版本发布，即UM 0.8。次年6月，统一建模语言推出0.9版本，自此正式改称为UML。至同年底，UML已经稳占面向对象技术市场85%的份额[11][12]。1997年1月，UML 1.0正式发布上线[13]。2003年6月，UML 2.0宣告完成[11]。该版本与UML1比较，有显著改进[14]。随后，UML不断更新迭代，于2017年12月发布了2.5版本。同时，UML也被ISO认定为标准，即ISO/IEC19501和ISO/IEC19595[8]。
统一建模语言的组织结构由构架、基本构造块（包含建模的事物、关系和图）以及实现特定目标的公共机制三部分组成[11]，建模类型分为功能模型、对象模型和动态模型三种，包括类图、用例图、顺序图等[15]。其建模能力比其他面向对象建模方法更强。它适合于一般系统的开发，对并行、分布式系统的建模尤为适宜[11]，已成功应用于电信、金融、电子、国防等领域之中[3]。
定义
统一建模语言利用视图、图、模型元素和通用机制等，从不同角度来观察和描述一个软件系统的体系结构，是一个庞大的表示法体系。作为一种建模语言，UML的定义包括UML语义和UML表示法两个部分[11]。
UML语义
UML语义是指描述基于UML、精确的元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。此外，UML还支持对元模型的扩展定义[16]。
UML表示法
UML的表示法定义了UML中使用的符号以及符号的表示方法，为开发者或开发工具使用这些图形符号和文本语法来进行系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上属于UML元模型的实例[16]。UML表示法分为通用表示和图形表示两部分组成[17]。
| 表示法 | 组成 | 简介 |
|---|---|---|
| 通用表示[17] | 字符串 | 表示有关模型的信息 |
| 名字 | 表示模型元素 | |
| 标号 | 赋予图形符号的字符串 | |
| 特定字串 | 赋予图形符号的特性 | |
| 类型表达式 | 声明属性变量及参数 | |
| 定制 | 一种用已有的模型元素来定义新模型元素的机制 | |
| 图形表示[18] | 用例图 | 用于表示系统的功能，并指出各功能的操作者 |
| 静态图 | 包括类图、对象图及包图，表示系统的静态结构 | |
| 行为图 | 包括状态图和活动图，用于描述系统的动态行为和对象之间的交互关系 | |
| 交互图 | 包括顺序图和合作图，用于描述系统的对象之间的动态合作关系 | |
| 实现图 | 包括构件图和配置图，用于描述系统的物理实现 |
主要特点
UML是一种定义良好、易于表达、功能强大且普遍适用的设计语言，它融入了软件工程领域的新思想、新方法和新技术，并支持软件开发的全过程。其主要特点表现为六点[19][20]。
UML为统一的建模语言：UML语言汲取了面向对象及一些非面向对象方法的思想，使用统一的元素及其表示符号，为用户提供无二义性的设计模型交流方法，早已被对象管理组织（OMG）认定为建模语言的标准[20]。
UML支持面向对象：UML支持面向对象的软件开发，支持面向对象思想的主要概念，所提供的图形元素能够简洁明了地表示这些概念及其关系[20]。
UML支持可视化建模：UML是一种图形化语言，它自然地支持可视化建模，用图形符号对系统建模。此外，UML还支持扩展机制，用户可以通过它自定义建模元素的各种属性[20]。
UML具备强大的表达能力：UML在演进的过程中提出了模板、进程和线程等新的概念，这些概念有效地支持了各种抽象领域和系统内核机制的建模。同时，UML强大的表达能力使它可以对各种类型的软件系统建模，包括商业领域的业务过程[20]。
UML独立于开发过程：UML支持系统与应用所有的开发过程，并支持系统与应用开发过程中的任一阶段[19]。
UML支持模型与代码之间的转换：模型可以被UML工具转化成指定的程序语言代码，程序语言代码也可以在UML工具的作用下转换为模型[19]。
目标
UML的目标是以面向对象图的方式来描述任何类型的系统[21]，促进面向对象工具市场的发展。具体来说，它的开发和运用是为了提供深度的可视化建模语言给用户，进而让用户能够发展和改变有意义的模型，同时也是为了提供可扩展性和专有化机制，使系统或应用在扩展时无需对核心概念进行修改。与此同时，UML的目的还包括了提供合理基础，以便人们理解标准。此外，UML还想应用于任何程序设计语言平台、工具平台以及软件开发的过程，完成与具体的实现和过程相分离，并追求持续升级迭代、高适应性和可用性、对高级概念的支持，欲达成与最优软件工程实践经验的相结合[11]。
为软件系统的开发提供可视化模型
在实际开发软件、编写代码的过程时，除了使用文本编辑表达式和算法外，大多数程序员仍要做一些简单的建模工作。如果不建立模型，软件系统中的某些东西很难用文本的编程语言来表达清楚，且可能导致代码的相关信息永远丢失，不利于后续的软件维护。但个人所做简单的模型并不利于交流，难被其他开发人员理解。而UML作为一种统一的、标准的建模语言，较好地解决了这一问题。UML符号具有定义良好的语言，不会引起歧义，使得交流更加方便。此外，UML作为可视化的建模语言，为系统提供了图形化的可视模型，使系统的结构变得直观、易于理解。利用UML为软件系统建立模型，既有利于交流，也有利于对软件的维护[14][22]。
规约软件系统的开发过程
规约（Specifying）意味着建立的模型是准确的、无歧义的、完整的[22]。UML定义了在开发软件系统过程中做出的所有重要的分析、设计和实现决策的规格说明[14]。
构造软件系统的实施框架
UML不是可视化的编程语言，但它的模型可以直接对应于各种各样的编程语言。简而言之，开发者可从UML的模型生成Java、C++等语言的编码，甚至能够生成关系数据库中的表[14]。从UML模型生成编程语言代码的过程被称为前向工程（Forward Engineering），从代码实现生成UML模型的过程被称为逆向工程（Reverse Engineering）。Rational Rose和Prosa等诸多CASE工具既支持前向工程，也支持逆向工程[22]。
为软件系统的产出建立文档
在软件的开发过程中，为软件系统建立清晰、完整、准确的文档是非常重要的。UML为描述需求、测试、项目规划活动和软件发布管理活动的建模提供了语言（即建模图形元素和符号），也可以为系统的体系结构及其所有细节建立文档[22]。
初步开发
20世纪80年代初期，面向对象分析和设计建模语言的数量从不到10种增加到了50多种。众多方法学家和语言创造者努力推广自己的产品并在实践中不断进行完善。然而每种方法各有长短，软件开发人员和用户不了解不同建模语言的优缺点及它们相互之间的差异，所以很难选择最适合各自要求的建模语言[11][7]。
在90年代，少数几种方法开始在一些关键性的项目中发挥作用，其中最引人注目的有Booch 93[注1]、OOSE[注2]和OMT-2[注3]等。此时面向对象方法已经成为软件分析和设计方法的主流，这些方法所做的最重要的尝试是在程序设计艺术与计算机科学之间寻求合理的平衡。因此，在客观上，极有必要在比较不同建模语言的优缺点及总结面向对象技术应用实践的基础上求同存异，达成建模语言统一效果。Grady Booch[注4]和Jim Rumbaugh[注5]在1994年开始致力于这一工作。他们首先将Booch 93和OMT-2统一起来，并于1995年10月发布了第一个公开版本，称为统一方法（Unitied Met hod）UM 0.8[11]。
改进完善
1995年秋，OOSE的创始人Ivar Jacobson[注6]加入开发，并采用了他的用例思想[注7]。经过Grady Booch、Jim Rumbaugh及Ivar Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML0.91。由于UM只是一种建模语言，而不是一种建模方法，自0.9版本起，正式改称为UML[11][7]。
1996年，一些机构将UML当作其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应，并倡议成立了“UML成员协会”，以完善、加强和促进UML的定义工作。当时，UML成员协会的成员有DEC、HP、I-Logix、Itellicorp、IBM等[8]。1996年底，UML已经稳占面向对象技术市场85%的份额[29]。1997年1月，UML 1.0发布。同年11月，OMG开始采纳UML作为其标准建模语言。从此，UML的相关开发、推广等工作交由OMG负责，同月还发布了UML 1.1[13]。然而由于这两个UML版本的提交过程比较仓促，所以其中还是存在了一些问题[11]。
1998年6月[12]，OMG的修订任务组提交了UML 1.2，它主要纠正了UML 1.1中的印刷和语法错误以及某些逻辑上的明显不一致，但是并没有涉及对重要技术的改进。1999年6月提交的UML 1.3是建模语言规范的第一个成熟版本[11]，这一版本修改了印刷和语法错误，解决了逻辑上的不完备性，修正了技术上的错误和疏漏，阐明了模糊的和有歧义的表述，并改进了文档的组织性和可读性[13]。
迭代发展
2001年5月，UML 1.4推出[11]。UML 1.4在UML 1.3的基础上进行了微小修改，除了修改技术上的错误、澄清有关细节外，更重要的是对扩展机制的图形表示、构件和制品（artifacts）以及协作和模式方面作出的改动[13]。2003年3月，UML 1.5发布[30]。同年6月于巴黎召开的OMG技术会议上，分析和设计专案小组投票通过了UML 2.0上层结构规范，至此UML 2.0宣告完成[11]。UML 2.0是比UML1有显著改进的新版本，此后4个UML 2.0规范相继形成，陆续进入ISO的标准化日程[14]。而在OMG的组织下，UML还经历了多次版本升级[8][31]。2017年12月，UML 2.5发布。同时，UML也被ISO认定为标准，即ISO/IEC19501和ISO/IEC19595[8]。
在完善过程中，UML吸收了百家之长，融合了来自很多其他面向对象方法的优点，如Meyer前置条件和后置条件、Odell分类、Shlaer-Meller对象生存周期等[32]。
| 发布时间 | UML版本 |
|---|---|
| 1995年10月 | UM 0.8[7] |
| 1996年6月 | UML 0.9[12] |
| 1996年10月 | UML0.91[7] |
| 1997年1月 | UML 1.0[13] |
| 1997年11月 | UML 1.1[13] |
| 1998年6月 | UML 1.2[12] |
| 1999年6月 | UML 1.3[11] |
| 2001年5月 | UML 1.4[11] |
| 2003年3月 | UML 1.5[30] |
| 2005年 | UML 2.0[12] |
| 2009年 | UML 2.2[12] |
| 2010年5月 | UML 2.3[8] |
| 2011年 | UML 2.4[32] |
| 2011年10月 | UML 2.4.1[32] |
| 2017年12月 | UML 2.5[8] |
组织结构
UML的组成结构直接奠定了UML的知识体系结构，一般包括了构造块、规则、公共机制以及体系结构四个部分。其中，前三个部分是对UML中存在的各个要素的抽象表现，UML体系结构则负责将其他三个组成构件有机地组织起来，从而形成一个完整的体系[33]。
构造块
UML中包括了两种基本构造块，即事物构造块和关系构造块。其中，事物构造块是模型中最具有代表性的抽象机制，一共包括结构事物、行为事物、分组事物及注释事物4大类；关系构造块用于表示模型元素之间相互连接的关系，较为常见的有依赖关系、关联关系、泛化关系和实现关系等[33]。
事物构造块
| 事物 | 简介 |
|---|---|
| 结构事物 | 即UML中的名词，是模型的静态部分，用来描述概念或物理元素。它又可分为类（Class）、对象（Object）、接口（lnterface）、主动类（Activeclass）、用例（Usecase）、协作（Collaboration）、构件（Component）和节点（Node）等，这些结构型事物均为构建UML的各种图模型提供了核心的实体基础[33] |
| 行为事物 | 即UML中的动词，是模型中的动态部分[33]，具体包含了交互和链接状态机两种元素。其中，交互是指实现某功能的一组结构事物之间的消息的集合，涉及消息、动作序列、链接；状态机是指描述事物或交互在生命周期内响应事件所经历的状态序列[34] |
| 分组事物 | 即UML中的容器，用来组织模型，使模型更加具有层次化与结构化特征[33]。其主要实现要素为包元素，包是把事物组织划分成不同组的一种分类规则，例如模型内部构件的归类方式或其他事物分组实现机制[9] |
| 注释事物 | 即UML中的解释部分，和代码中的注释语句一样，是用来对模型中的其他构造块进行解释说明的部分，也可以用来进一步地完善UML的其他事物块[33]。其本质上是文字的描述与说明[9] |
关系构造块
| 关系 | 简介 | 表示方式 | 图示 |
|---|---|---|---|
| 依赖关系 | 是指一个元素（依赖事物的提供者）的变化将影响到另一个元素（依赖事物的接收者）或向其提供信息。依赖的形式是多样的，针对不同的依赖形式，依赖关系有不同的变体 | 用由源模型指向目标模型的带实心箭头的虚线表示[11] |  |
| 关联关系 | 表示两个事物对象之间存在某种模型业务制约、交流关系，表现为事物之间一般性业务交互 | 这一关系用实线表示：当表示单向关联时，用实线加箭头；当表示双向关联时，仅用一根实线。此外，关联线的两边还可以带上关联对象的数量[9] |  |
| 泛化关系 | 即继承关系，用于描述父类与子类之间的关系[35]。这一关系属于从个性到共性的推导、抽象过程，其具体含义是：去除事物的个性特征、保留同类事物的共同属性[9] | 在UML图中，泛化关系用带空心三角形的直线来表示，空心三角形指向父类[35] |  |
| 实现关系 | 是用来规定接口和实现接口的类或者构建结构的关系。在该关系中，类实现了接口，类中的操作实现了接口中所声明的操作 | 在UML图中，类与接口之间的实现关系用带空心三角形的虚线来表示，空心三角形指向接口[35] |  |
规则
像其他语言一样，UML自有一套规则[36]。这些规则用来定义和支配基本构造块之间如何协作，其中包括命名、范围、可见性、完整性以及执行[37]。同时，UML的规则还暗示用户专注于最重要的分析、设计和实现问题，这些问题将促使模型随时间的推移而具有良好的结构[36]。
| 规则 | 简述 |
|---|---|
| 命名 | 为事物、关系和UML的图模型起名字，每一个名字都是一个标识符[37] |
| 范围 | 作用域与类相似，包括所有者作用域（Owner Scope）和目标作用域（Target Scope）两种类型[37] |
| 可见性 | 类和对象在封装性的同时，提供了一种外部可见的机制。UML在类的可见性中定义了公共可见性（Public）、保护可见性（Protected）、私有可见性（Private）和包（Package）的可见性[37] |
| 完整性 | 规定事物之间如何正确地、一致地彼此关联，相互作用[38] |
| 执行 | 明确动态模型如何模拟实际系统的运行[38] |
公共机制
统一建模语言的公共机制共4种，即规格说明（Specification）、修饰（Adornment）、通用划分（Common Division）和扩展机制（Extensibility Mechanism）[11]。 这些通用的公共机制，可贯穿于整个建模过程的方方面面[38]。
规格说明
UML不只是一个图形语言，还为每一个UML图形规定了文字说明的语法和语义。例如，一个类图标的背后必有一套说明，它提供了关于属性、操作、行为等的描述。通常使用UML的图标表示法可视化一个系统，使用UML的说明叙述该系统的细节[11]。
修饰
大多数的UML元素都有惟一的、直接的图形表示法，以此来表达该元素的最重要特征。除此之外，还可以对该元素加上各种修饰性说明，用于描述该元素其他方面的细节特征。例如，对于一个对象类，最基本的图形表示法是一个矩形，其中包含了类的名称、属性和操作。此外可以加上一些修饰，如可见性标记[11]。
通用划分
通用划分是一种保证不同抽象概念层次的机制，包括类和对象的划分、接口和实现的划分。其中，类和对象的划分保证了实例及其抽象的划分，使得对一组实例对象的公共静态和动态特征无需逐一管理、描述和实现。接口和实现的划分则保证了一系列操作的规约和不同类对该操作的具体实现[38]。
拓展机制
尽管UML已经是一套功能较强、表现力丰富的建模语言，但有时仍难以准确表达模型的许多细小方面。因此，UML的开发者们为UML设计了一种简单、通用的扩展机制。扩展机制能够应用于UML的各种建模元素之中[38]，可扩展UML，也可把UML用户化，更便于完成软件系统的开发工作[11]。
| 机制 | 简介 |
|---|---|
| 构造型（Stereotype） | 是在模型本身定义的一种模型元素，即扩展UML的语义，是在原有已定义的模型元素的基础上增加新的语义或限制，允许创造新的构造块。构造型是UML中一种用来对模型元素进行分类或标记的新模型元素，可以看作对已有元素进行的专有化，能有效防止UML变得过于复杂，同时也使得UML能够适应各种需求 |
| 标记值（Tagged） | 用来描述模型元素的特性，是存储有关元素任意相关信息的字符串。标记值可以附加在任何独立的元素上，包括模型元素和视图元素，提供了向元素添加特性的规格说明的方法 |
| 约束（Constraint） | 是用文字表达式扩展模型元素的语义，它允许增加新的规则或修改现有的规则。约束可以表达UML标记无法表现的限制和关系，规定某个条件或命题必须为真，否则该模型表示的系统无效 |
| 参考资料[11] | |
体系结构
UML的构架由5类视图组成，包括用例视图、逻辑视图、进程视图（并发视图）、构件视图（组件视图）和部署视图。这5类视图属于“4+1”视图模型，由菲利普·克鲁赫滕（Philippe Kruchten[39]）提出，从五个不同的视角来描述软件体系结构。每一个视图只关心系统的一个侧面，五个视图结合在一起才能反映系统的软件体系结构的全部内容。它们对于软件体系结构的可视化、详细描述、构造等方面都极为重要。每个视图都是某个特定方面对于整个系统描述的一个投影，结合起来可以完整描述整个系统，其中用例视图是描述系统功能的核心和其他视图的出发点[11][35]。
| 视图名称 | 含义 | 作用 | 适用对象 | 重要性 |
|---|---|---|---|---|
| 用例视图 （Use Case View） | 也被称为外部视图、用户视图、功能视图，包括用例图和活动图 | 描述系统的功能需求，找出用例和行为者 | 客户、分析者、设计者、开发者和测试者 | 为系统的中心，决定了其他视图的开发，用于确认和最终验证系统 |
| 逻辑视图 （Logical View） | 也被称为结构模型，包括类图、对象图等 | 描述如何实现系统内部的功能 | 分析者、设计者、开发者 | 描述了系统的静态结构和因发送消息而出现的动态协作关系 |
| 进程视图 （Process View） | 也被称为并发视图、动态视图，包括了状态图、时序图等 | 描述系统并发性，并处理这些线程的通信和同步 | 开发者、系统集成者 | 将系统分割成了并发执行的控制线程，同时还处理了这些线程的通信和同步 |
| 构件视图（Component View） | 也被称为组件视图、实现视图、物理视图，由构件图组成 | 描述系统代码的构件组织、实现模块以及它们之间的依赖关系 | 开发者 | 反映了系统如何划分软件构件以及如何进行编程 |
| 部署视图（Deployment View） | 也被称为配置视图，由部署图组成 | 描述系统的物理设备部署 | 开发者、系统集成者和测试者 | 反映了系统的物理设备连接和哪个程序或对象驻留在哪台计算机上运行 |
| 参考资料[11][35] | ||||
建模类型
在统一建模语言中，有三种主要的建模类型：功能模型、对象模型和动态模型。其中，功能模型有用例图，对象模型有类图、对象图、包图，动态模型有顺序图、活动图、状态图[15]。除此之外，UML还包括了组件图、部署图以及协作图[40][41]。
功能模型
功能模型是指从用户角度展示系统功能的模型[15]。在UML中，通过用例图建立实现用户需求的功能模型[42]。用例图（Use Case Diagram[16]）为用例[注8]、相关参与者[注9]及其关系的图形化表示，详细描述了参与者以及他们如何与软件系统交互，便于人们理解软件系统的范围和提供给参与者的功能[40]。用例模型的主要元素包括系统边界、用例及执行者（参与者），这些元素之间的关系主要有关联、扩展、包含、泛化等[42]。
在软件系统开发中，对于相关的不同人员，用例模型有着不同的作用，如为客户指明了系统的功能、帮助开发者理解系统功能等[42]。它从用户的角度切入，对系统的需求展开描述，是导出对象模型和动态模型的依据[43]。
对象模型
对象模型是对客观世界实体中对象及其相互之间关系的映射，描述了系统的静态结构[44]，采用对象、属性、操作、关联等概念来展示系统的结构和基础[15]。在系统分析阶段，对象建模的主要任务是建立问题域的概念模型。这个模型描述了现实世界中的类与对象以及它们之间的关系，而非实际的软件类或构件[43]。
对象模型用类符号、类实例符号、类的继承关系、聚集关系和关联关系等表示。有些对象具有主动服务功能，称为主动对象。当系统较复杂时，可以划分主题，画出主题图，以利于对问题的理解[44]。对象模型为建立动态模型和功能模型，提供了实质性的框架[45]。
| 模型 | 简介 | 图片 |
|---|---|---|
| 类图 （Class Diagram[16]） | 最流行的UML图之一，通过该图可看到类[注10]及其关系，展现了软件系统的结构。在类图中使用矩形来图形化地表示一个类，每个类最多可以包含三个部分。上面的部分显示类的名称，中间的部分包含类的属性，下面的部分详细说明了类的操作[1] |  |
| 对象图 （Object Diagram[16]） | 描述类图在某一时刻，类中对象相互之间的链接关系，相当于对类图在某时刻的一个快照。因为对象具有生命周期，不同时刻类图中的对象数目并不相同，因此，对应着同一幅类图，在不同时间会有不同的对象图。在描述系统的静态结构时，并不一定要绘制对象图，只有当需要反映某一时刻系统中对象相互之间的链接关系时，才需要画出对象图。对象图中的节点[注11]是对象，节点用矩形框表示[41] |  |
| 包图 （Package Diagram[16]） | 用于显示软件系统中包[注12]之间的依赖关系。软件系统越复杂，理解所有的模型就越困难。包图通过将元素进行分组，让人们看到依赖关系，使人可以更容易对大型、复杂的系统进行推断[40] |  |
动态模型
动态模型用以规范对象的行为[15]，表示瞬时系统、行为化系统的控制性质[46]，描述对象和关系的状态、状态转换的触发事件、对象的服务（行为）。其显示出对象在系统运行的不同时期、不同时刻的动态交互情况，对开发交互式系统起到了很重要的作用[42][47]。在UML中，使用各种行为图来表达系统的动态模型，如顺序图、活动图等[42][48]。
| 模型 | 简介 | 图片 |
|---|---|---|
| 顺序图 （Sequence Diagram[16]） | 反映对象之间消息传送的时序关系，由对象、对象生命线、对象激活期和对象之间传输的消息等图形要素构成。在顺序图中，参与交互活动的对象用矩形框表示[41] |  |
| 活动图 （Active Diagram[16]） | 让用户能以工作流的形式直观地表示一系列动作。它显示了一个控制流，类似于流程图。活动图可以用于建模，诸如业务流程、用例中的流和过程逻辑等内容[40] |  |
| 状态图 （State Diagram[16]） | 描述事物对象在其生存周期中所具有的各种状态，以及因事件激励状态的变化和相互关系。状态图中的节点是事物所处的状态；实心圆表示初始状态，带圆圈的实心圆表示结束状态。一副状态图中一般有一个初始态，以箭头表示状态的切换，在箭头上还标注了状态切换的激发条件[41] |  |
其他模型
模型简介图片组件图（Component Diagram）详细描述了系统组件之间的结构关系，有助于查看组件及其关系。在本质上，组件图描述了软件系统的组件是如何连接在一起的，这也是它们有时也被称为接线图的原因。此外，组件图可帮助识别软件系统中不同组件之间的接口，还能显现与接口相关的系统行为[40]部署图（Ceployment Diagram）表示了节点上工件[注13]的物理部署情况，用于显示架构中的软件元素，以及如何将它们部署到硬件元素上。部署图为用户提供了硬件和系统的拓扑视图[40]协作图（Collaboration Diagram[16]）描述了一组对象之间消息交互关系的协作结构，以对象作为节点，于存在消息交互关系的对象之间进行直线连接，并在直线上标注交互的消息名。协作图与顺序图是等价的，包含的信息量相同，其差别是描述的角度不同[41]
阶段过程
利用UML进行系统分析建模的过程主要包括静态建模和动态建模两个阶段。在UML的静态建模阶段，主要根据系统需求建立系统静态结构，对系统进行分析和描述。在UML的动态建模阶段，主要描述系统的动态行为，需要明确系统中各个对象的操作及变化状态，令静态对象拥有活跃性和可执行性[49]。
方法步骤
UML的建模方法步骤大致分为四步：第一，描述需求，进行需求分析；第二，根据需求建立系统的静态模型，以构造系统的结构；第三，展开详细设计，描述系统的行为，并对系统设计进行细化；第四，实现系统设计。这其中的第一步和第二步属于UML的静态建模机制，所建立的模型皆为静态模型，包括用例图、类图、包图、对象图、构件图和配置图等五种图形。而第三步则属于UML的动态建模机制，该步骤内所建立的模型包括状态图、活动图、顺序图和协作图四种图形，或可执行，或可表示执行时的时序状态或交互关系[50]。
| 分析与建模方法 | 实施的基本步骤 |
|---|---|
| 系统的用例图 |  |
| 系统的类图 |  |
| 系统的状态图 |  |
| 系统的序列图 |  |
| 系统的协作图 |  |
| 参考资料[21] |
建模工具
由于UML已经成为建模的国际标准，很多公司推出了支持UML的建模工具，最有影响、使用最广的是Rational公司旗下的ROSE，此外还有ArgoUML、IBM Rational Software Architect等，这些工具都给可视化建模带来了极大的便利[14][51]。
| 名称 | 简介 | 图片 |
|---|---|---|
| ROSE | 一种面向对象的统一建模语言的可视化建模工具，用于可视化建模和公司级水平软件应用的组件构造，属于能满足所有建模环境（Web开发、数据建模、Visual Studio和C++）灵活性需求的一套解决方案[15] |  |
| ArgoUML | 一个开源的、基于Java的UML工具，可以支持系统分析师、软件设计师和程序员的工作。该工具使用户能够创建、编辑和存储遵循UML1.3标准的UML图类型，为免费性工具，具有较多功能[52] |  |
| IBM Rational Software Architect | 简称“RSA”，一套设计与开发工具，构建在开放的、可扩展的Eclipse3.0平台之上，提供了灵活的插件扩展机制，同时支持UML到Java、C++、EJB的模型转化，并借助UML2.0技术实现了多种软件开发模式，可帮助开发团队创建更好的软件架构[53] |  |
应用领域
UML是在多种面向对象建模方法的基础上发展起来的软件建模语言[54]，它的应用范围非常广泛，可以描述许多类型的系统；也可以用于软件开发的各个阶段，从需求规格描述到系统完成后的测试与维护[17]。
不同类型系统的应用
UML可直接为面向对象软件系统创建模型，也可用来描述其他类型的软件系统、商业机构或过程，常见应用包括了信息系统、具有实时要求的工业系统或工业过程嵌入式实时系统、分布式系统、系统软件、商业系统等[55]。
| 系统 | 应用 |
|---|---|
| 信息系统 （Information System） | 向用户提供信息的储存、检索、转换和提交，处理存放在关系或对象数据库中大量具有复杂关系的数据 |
| 技术系统 （Technical System） | 处理和控制技术设备，如电信设备、军事系统或工业过程。它们必须处理设计的特殊接口，标准软件很少。技术系统通常是实时系统 |
| 嵌入式实时系统 （Embedded Real-time System） | 嵌入到其他设备如移动电话、汽车、家电上的硬件上执行的系统，通常是通过低级程序设计进行的，需要实时支持 |
| 分布式系统 （Distributed System） | 分布在一组机器上运行的系统，数据很容易从一台机器传送到另一台机器上，需要同步通信机制来确保数据完整性 |
| 系统软件 （System Software） | 定义了其他软件使用的技术基础设施。如操作系统、数据库和在硬件上完成底层操作的用户接口等，同时提供一般接口供其他软件使用 |
| 商业系统 （Business System） | 描述目标资源（人、计算机等）、规则（法规、商业策略、政策等）和商业中的实际工作（商业过程） |
| 参考资料[56] | |
软件开发过程中的应用
| 软件开发阶段 | 应用 |
|---|---|
| 需求分析 | UML的用例视图可以表示客户的需求，通过用例建模能够对外部的角色以及它们所需要的系统功能建模。角色和用例是用它们之间的关系、通信建模的，每个用例都指定了客户的需求。需求分析不仅针对软件系统，在商业过程里也要展开 |
| 系统分析 | 该阶段主要考虑所要解决的问题，针对问题域中的对象建模，不定义软件系统的解决方案的细节（如用户接口的类数据库等），可通过静态模型和动态模型来描述系统结构和系统行为，用UML的逻辑视图和动态视图来描述。其中，类图描述系统的静态结构，合作图、序列图、活动图和状态图描述系统的动态特征 |
| 系统设计 | 在分析模型基础上，考虑引入处理用户交互的接口类、处理数据的类等，从而提供用户接口、数据库操作等技术基础结构，为实现阶段提供了更详细的设计说明。分析阶段的领域问题类被嵌入在这个技术基础结构中 |
| 系统实现/构造 | 在这一阶段，设计阶段的类将被转换成某种面向对象程序设计语言的代码，可用构件图来描述代码构件的物理结构以及构件之间的关系，用配置图来描述和定义系统中软硬件的物理体系结构。在对UML表示的分析和设计模型进行转换时，最好不要直接把模型转化成代码，因为在早期阶段里模型是理解系统并对系统进行结构化的手段 |
| 测试 | 对系统的测试通常分为单元测试、集成测试、系统测试和接受测试四个不同级别，可使用类图进行单元测试，使用构件图、合作图进行集成测试，使用用例图进行确认测试，以验证测试结果是否满足用户的需求 |
| 参考资料[18][56] | |
在数据库设计中的应用
数据库设计即从需求到实现的过程，通常包括数据库建模和数据设计。前者着重解决逻辑数据模型和物理数据模型；而后者着眼于从整个需求的产生、业务过程、逻辑分析、物理数据库构建到数据库的开发的全过程。在这些过程中，都可以使用UML来进行，如使用用例图来描述系统功能以及支持业务处理环境的模型、使用活动图来显示处理流程等[56]。
装备维修训练系统分析与设计
在装备维修训练系统的实际开发应用中，将UML运用到分析与设计阶段，采用UML流程图对维修训练系统分析过程建模，并利用UML对保障性分析过程及维修训练设计过程建模，明确基本活动的节点、设计的一般过程，加强了对装备维修训练相关过程的理解和把握[57]。
柔性管理信息系统开发
在柔性管理信息[注14]系统的实际开发应用中，采用应用建模的方法，利用了UML完成系统的需求分析、概念设计和详细设计，构建出系统的需求模型、静态结构模型和动态的行为模型，加深用户对系统的开发平台、体系架构和实现功能的认识；同时根据用户意见，持续对系统的模型和文档进行修补，大幅减少系统实现阶段的工作量，有效应对用户的需求变更，并提高系统对企业环境的适应能力，进一步解决了企业需求“柔性”和管理信息系统自身“刚性”的矛盾问题[58]。
面向领域的电子商务系统建模
面向领域的电子商务系统建模机制利用UML的静态结构建模、动态行为建模等机制，围绕“数据交换”这一电子商务核心业务，将电子商务建模规范化，使之形成以UML用例模型为业务建模、UML活动图和泳道图为工作流建模、UML顺序图为业务过程建模、文档和UML类图为业务词汇表建模的体系。基于该体系建立的中国石油化工电子商务平台物资采购业务，在运营两年多后网上业务量已超过总业务量的50％[59]。
ArchiMate
ArchiMate是The Open Group为企业架构提供的开放和独立的建模语言，由不同的工具供应商和咨询公司提供支持。它提供了一组清晰的概念和架构域之间的关系，并提供了一个简单而统一的结构来描述这些域的内容。它是一种精简而简单的语言，其中的几个概念特意借鉴了UML，以提供一个简单的桥梁[60]。
SysML
SysML是一种通用图形建模语言，用于指定、分析、设计和验证复杂系统，这些系统可能包括硬件、软件、信息、人员、程序和设施。该语言为建模系统需求、行为、结构和参数提供了具有语义基础的图形表示，用于与其他工程分析模型集成。它表示了UML2的一个子集，具有满足UML对系统工程RFP的要求[61]。
UML for Systems Engineering RFP
UML for Systems Engineering RFP由OMG公司和国际系统工程委员会（INCOSE）联合开发，并由OMG公司于2003年3月发布。其规定了扩展UML以支持系统工程社区需求的要求[61]。
未来展望
参考资料 63
- 参考 1
- 参考 2
- Success Stories — uml
- ChatGPT之父提出新摩尔定律：宇宙智能数量每18个月翻一番 — 澎湃新闻
- 参考 5
- https://www.cnki.com.cn/Article/CJFDTotal-YHJS200520020.htm
- 参考 7
- 参考 8
- 参考 9
- 参考 10
- 参考 11
- 参考 12
- 参考 13
- 参考 14
- 参考 15
- 参考 16
- 参考 17
- 参考 18
- 参考 19
- 参考 20
- 参考 21
- 参考 22
- 参考 23
- 参考 24
- UML创始人Grady Booch 先生简介 — 新浪科技
- UML创始人James Rumbaugh 先生简介 — 新浪科技
- UML创始人Ivar Jacobson 先生简介 — 新浪科技
- 参考 28
- 参考 29
- 参考 30
- 参考 31
- 参考 32
- 参考 33
- 参考 34
- 参考 35
- 参考 36
- 参考 37
- 参考 38
- 参考 39
- 参考 40
- 参考 41
- 参考 42
- 参考 43
- 参考 44
- 参考 45
- 参考 46
- 参考 47
- 参考 48
- 参考 49
- 参考 50
- https://qikan.cqvip.com/Qikan/Article/Detail?id=5827288&from=Qikan_Search_Index
- https://dl.acm.org/doi/10.5555/1127351.1127354
- SOA 开发第二步 – 设计SOA架构 — IBM
- https://qikan.cqvip.com/Qikan/Article/Detail?id=41669570
- 参考 55
- 参考 56
- https://www.nstl.gov.cn/paper_detail.html?id=d0feda5f6d1553871846ead5c647c549
- https://www.zhangqiaokeyan.com/academic-journal-cn_journal-liaoning-technical-university-natural-science-edition_thesis/0201292882746.html
- https://www.cnki.com.cn/Article/CJFDTotal-SJSJ200411081.htm
- What is ArchiMate? — visual paradigm
- WHAT IS SYSML? — omgsysml
- 参考 62
- https://qikan.cqvip.com/Qikan/Article/Detail?id=HS724812020005001&from=Qikan_Search_Index
注释
- Booch 93[11]，亦称“Booch'93”，是Grady Booch在1993年提出的一种面向对象建模方法，它更注重工程的设计和构造阶段，在开发工程密集的应用方面具有优势[23]。
- OOSE方法是IvarJacobson在1994年提出的，其最大特点是面向用例，同时也对商业工程设计和需求分析提供了良好的支持[23]。
- OMT-2由James Rumbaugh等人提出，采用了面向对象的概念，并引入了各种独立于语言的表示符。该方法用对象模型、动态模型、功能模型和用例（use-case）模型，共同完成对整个系统的建模，所定义的概念和符号可用于软件系统开发的分析、设计和实施的全过程，系统开发人员不必在开发过程的不同阶段进行概念和符号的转换[24]。
- Grady Booch是统一建模语言的最初开发人员之一，也是多个Rational产品的最初开发人员之一，曾担任全世界许多复杂精深软件项目的架构师和架构指导，因在软件架构、软件工程和软件建模方面的杰出贡献而在国际上享有盛名，拥有“IBM 名士”“ACM Fellow”等荣誉称号[25]。
- James Rumbaugh是一名软件开发方法学家，提出了许多有关UML的概念。他对很多计算领域都有过研究，包括计算语义、编程生产力工具以及使用复杂算法和数据结构的应用程序。在纽约斯卡奈塔第的通用电气研发中心工作时，他开发了DSM面向对象的程序设计语言、状态控制树模型等。他曾与Rational的其他软件领袖一起工作在各个领域，比如Rational统一过程和实时开发方法学。在2003年IBM收购了Rational之后，他就一直致力于推动IBM建模工具的开发[26]。
- Ivar Jacobson是Objectory方法的发明者，也是瑞典Objectory AB公司的创始人。他曾担任Rational Business Engineering 部门的副总裁，负责UML的开发。Ivar Jacobson所创的用例驱动方法对整个OOAD行业影响深远，他因此而成为业界的一面“旗帜”。他撰写的书籍《面向对象的软件工程―一种用例驱动方法》获得了1992年计算机语言生产力奖[27]。
- 用例建模来源于面积对象建模技术，是Ivar Jacobson于20世纪六七十年代在爱立信公司开发AKE、AXE系列系统时发明的，被面向对象领域广泛采纳、并认定它是第二代面向对象技术的标志。用例模型为客户和开发者提供了一种契约，使用用例描述了系统的功能需求，模型化表示出系统的功能和系统的环境。在软件开发过程中，用例模型可以作为一种方式用来与系统的客户进行交流[28]。
- 用例是描述软件系统在响应系统用户（即参与者）请求时响应行为的文本表示[40]。
- 参与者是与系统交互的人或物的角色，可以是人、组织或者外部系统[40]。
- 类是用于在软件系统中创建对象的模板（蓝图），包括了保存对象状态的属性（成员变量）和表示行为的操作（方法）[1]。
- 节点是指用工件执行部署的计算资源，可以包含其他节点。节点有两种类型：设备节点和执行环境节点execution environment nodes（EENs）[40]。
- 包是模型的组织单位。一个复杂的系统模型需要分解成为多个部分，每一部分用包来表示。包也属于UML的一种模型元素，可以用来表示模型、子模型、系统和子系统等系统模型单位[41]。
- 工件是指物理性的信息片段，如源代码文件、二进制文件、脚本、数据库中的表或文档[40]。
- 柔性管理信息的定义包括两个方面的内容：首先是适应能力，是指当企业环境影响企业管理信息系统时，企业管理信息系统所表现出的对环境变化的适应性；其次是控制能力，是指企业管理信息系统对其外部环境的影响能力。柔性越大，管理信息系统的适应性以及对外部的控制能力越强[58]。