UML图

内容

 [йљђи—Џ] 

• 1 历史
• 1.1 在UML 1.x之前
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 设计
• 2.1 软件开发方法
• 2.2 建模
• 3张图
• 3.1 结构图
• 3.2 行为图
• 3.2.1 交互图示
• 4 元建模
• 5 通过
• 6条批评意见
• 6.1 对UML 1.x的批评

历史[编辑来源|编辑]

面向对象的方法和符号的历史

UML从20世纪90年代后半期开始发展，它起源于80年代末和90年代初开发的面向对象的方法。时间轴（见图片）显示了面向对象建模方法和符号的历史亮点。

它最初是基于Booch方法、对象建模技术（OMT）和面向对象的软件工程（OOSE）的符号，它将这些符号整合为一种语言。^[5]

在UML 1.x之前[编辑来源|编辑]

1994年，Rational软件公司从通用电气公司聘请了James Rumbaugh，此后，该公司成为当时最流行的两种面向对象建模方法的来源。^[6]Rumbaugh的Object-modeling technique（OMT）和Grady Booch的方法。他们的努力很快得到了Ivar Jacobson的帮助，他是面向对象软件工程（OOSE）方法的创造者，于1995年加入Rational。^[1]

在这三人（Rumbaugh、Jacobson和Booch）的技术领导下，1996年组织了一个名为UML伙伴的联盟，以完成统一建模语言（UML）规范，并向对象管理小组（OMG）提出标准化建议。该合作伙伴还包括其他感兴趣的各方（例如HP、DEC、IBM和Microsoft）。UML伙伴的UML 1.0草案于1997年1月由该联盟向OMG提出。在同一个月里，UML合作伙伴成立了一个小组，旨在定义语言构造的确切含义，由Cris Kobryn主持，Ed Eykholt管理，以最终确定规范并与其他标准化工作相结合。这项工作的结果，UML 1.1，在1997年8月提交给OMG，并在1997年11月被OMG采用。^[1][7]

UML 1.x[编辑来源|编辑]。

在第一次发布后，成立了一个工作组^[1]来改进该语言，该工作组发布了几个小的修订版，即1.3、1.4和1.5。^[8]

它所产生的标准（以及原始标准）被指出是含糊不清和不一致的。^[9][10]

UML 2.x[编辑来源|编辑]。

2005年，UML 2.0主要修订版取代了1.5版，它是由一个扩大的联盟开发的，以进一步改进语言，反映其功能使用上的新经验。^[11]

尽管UML 2.1从未作为正式规范发布，但在2007年出现了2.1.1和2.1.2版本，随后在2009年2月出现了UML 2.2。UML 2.3在2010年5月正式发布。^[12]UML 2.4.1在2011年8月正式发布。^[12]UML 2.5于2012年10月作为 "进行中 "版本发布，并于2015年6月正式发布。^[12]

UML 2.x规范有四个部分。

1. 定义图及其模型元素的符号和语义的上层结构
2. 定义了核心元模型的基础设施，上层建筑是基于此的。
3. 用于定义模型元素规则的对象约束语言（OCL）。
4. 定义了UML 2图表布局的交换方式的UML图表互换。

这些标准的当前版本如下。UML上层建筑2.4.1版，UML基础设施2.4.1版，OCL 2.3.1版，以及UML图示互换1.0版。^[13]它继续由修订工作组更新和改进，他们解决语言的任何问题。^[14]

设计[编辑来源|编辑]

统一建模语言（UML）提供了一种在图表中可视化系统架构蓝图的方法（见图片），包括诸如以下元素。 ^[5]

• 任何活动（工作）。
• 系统的各个组成部分
• 以及它们如何与其他软件组件互动。
• 系统将如何运行
• 实体如何与他人互动（组件和接口）。
• 外部用户接口

尽管统一建模语言（UML）最初只用于面向对象的设计文档，但它已被扩展到涵盖更大范围的设计文档（如上所列），^[15]并在许多情况下被发现是有用的。^[16]

软件开发方法[编辑来源|编辑]

UML本身不是一种开发方法；^[17]但是，它被设计为与当时领先的面向对象的软件开发方法（例如OMT、Booch方法、Objectory）兼容，特别是与RUP兼容，它最初是在Rational软件公司开始工作时打算使用的。

造型[编辑来源|编辑]

区分UML模型和一个系统的图集是很重要的。一个图是一个系统模型的部分图形表示。这套图不需要完全覆盖模型，删除一个图也不会改变模型。模型还可能包含驱动模型元素和图的文档（如书面用例）。

UML图代表了系统模型^[18]的两种不同观点。

• 静态（或结构）视图：强调系统的静态结构，使用对象、属性、操作和关系。结构视图包括类图和复合结构图。
• 动态（或行为）视图：通过显示对象之间的协作和对象内部状态的变化，强调系统的动态行为。这种观点包括序列图、活动图和状态机图。

UML模型可以通过使用XML元数据交换（XMI）互换格式在UML工具之间进行交换。

图表[编辑来源|编辑]

UML 2有许多类型的图，它们被分为两类。^[5]有些类型表示结构信息，其余的表示一般的行为类型，包括一些表示交互的不同方面。这些图可以按层次进行分类，如下面的类图^[5]所示。

这些图都可能包含解释用法、约束或意图的注释或说明。

结构图[编辑来源|编辑]

结构图强调了被建模的系统中必须存在的东西。由于结构图代表了结构，它们被广泛地用于记录软件系统的软件结构。例如，组件图，它描述了一个软件系统是如何被分割成组件的，并显示了这些组件之间的依赖关系。

• 组件图
• 类图

行为图[编辑来源|编辑]。

行为图强调了被建模的系统中必须发生的事情。由于行为图说明了系统的行为，它们被广泛地用于描述软件系统的功能。作为一个例子，活动图描述了一个系统中各组件的业务和操作步骤活动。

• 活动图
• 用例图

交互图[编辑来源|编辑]

交互图是行为图的一个子集，强调被建模的系统中各事物之间的控制和数据流。例如，序列图显示了对象之间如何以信息序列的方式进行通信。

• 序列图
• 通信图示

元建模[编辑来源|编辑]

主要条款。元对象设施

元对象设施的说明

对象管理小组（OMG）已经开发了一个元建模架构来定义统一建模语言（UML），称为元对象设施（MOF）。^[19]元对象设施被设计成一个四层的架构，如右图所示。它在顶层提供了一个元元模型，称为M3层。这个M3模型是Meta-Object Facility用来构建元模型的语言，称为M2模型。

第二层元对象设施模型的最突出的例子是UML元模型，即描述UML本身的模型。这些M2模型描述了M1层的元素，因此也是M1模型。这些将是，例如，用UML写的模型。最后一层是M0层或数据层。它用于描述系统的运行时实例。^[20]

元模型可以使用一种叫做 "定型 "的机制来扩展。Brian Henderson-Sellers和Cesar Gonzalez-Perez在 "UML 1.x和2.0中定型机制的使用和滥用 "中批评说，这是不充分/不成立的。 ^[21]

收养[编辑来源|编辑]

UML在许多设计环境中被发现是有用的，^[16]以至于它在IT界几乎是无处不在的。 ^[22]

有时，它被当作设计的银弹，这导致了它在使用中的问题。对它的误用包括过度使用它（用它来设计系统代码的每一个小部分，这是没有必要的）和假设任何人都可以用它来设计任何东西（甚至那些没有编程的人）。^[23]

它被认为是一种大型语言，其中有许多结构。一些人（包括Jacobson）认为它有太多的结构，这阻碍了对它的学习（和使用）。^[24]

批评[编辑来源|编辑]

工业界对UML的常见批评包括^[4]：。

• 没有用。"与他们目前的、已经发展起来的做法和表述相比，[并没有]为他们提供优势"
• 太复杂了，特别是对于与客户的沟通。"不必要的复杂 "和 "不使用UML的最好理由是它对所有的利益相关者来说都是'可读的'。如果一个商业用户（客户）不能理解你的建模工作的结果，那么UML的价值有多大？"
• 需要保持UML和代码的同步，就像一般的文档一样

对UML 1.x的批评[编辑来源|编辑]

Cardinality符号

就像数据库Chen、Bachman和ISO ER图一样，类模型被指定为使用 "look-across "cardinalities，尽管一些作者（Merise, ^[25]Elmasri & Navathe^[26]等^[27]）更喜欢同侧或 "look-here "的角色以及最小和最大cardinalities。最近的研究者（Feinerer,^[28] Dullea等^[29]）表明，UML和ER图使用的 "look-across "技术在应用于阶数大于2的n-ary关系时，效果和连贯性都较差。

Feinerer说："如果我们在用于UML关联的look-across语义下操作，就会出现问题。Hartmann^[30]研究了这种情况，并展示了不同的转换如何以及为什么会失败。(虽然提到的 "减少 "是虚假的，因为3.4和3.5两张图实际上是一样的），还有 "正如我们将在接下来的几页看到的，横看竖看的解释引入了一些困难，这些困难阻碍了从二进制到n-ary关联的简单机制的扩展。"