生成uml需要哪些词汇和语法信息？
邵伟中梅红
最近，由美国Rational公司发起，其他十几家公司联合推出的统一建模语言(UML)在OO领域引起了广泛关注。本文首先介绍了UML的背景和主要内容，然后评述了它对面向对象建模技术的积极影响和可能存在的问题。UML是一种强大的建模语言，具有丰富的表达能力。但目前还不能断定它会取代现有的各种面向对象的分析和设计方法，因为它只是一种建模语言，而不是方法；它的复杂性可能会成为它赢得大量用户的障碍。
面向对象，建模方法，建模语言
中国图书馆分类号TP311
统一建模语言综述
邵伟中和洪梅
(计算机科学与工程系；技术，北京大学，北京100871)
由Rational软件公司和其他UML合作伙伴发布的统一建模语言(UML)在对象技术领域引起了广泛的关注。介绍了UML的历史背景和主要内容，讨论了它的意义、积极影响和可能存在的问题。UML是一种表达能力强、功能强大的建模语言；然而，不能断定它会取代所有现有的面向对象的分析和设计方法。原因是UML只是一个建模的顾岚时代，而不是一种方法，其过度的复杂性可能会成为赢得大量用户的障碍。
关键词面向对象，建模方法，建模语言
1 UML的背景
由于OOA/OOD方法的重要性日益突出，人们对其研究、开发和应用的热情也日益高涨。1989年，以专著、论文或技术报告形式出现的OOA/OOD方法或OO建模语言近10种，到194年，OOA方法的数量已经增加到50多种。各种方法的出现或多或少为OOA/OOD技术的研究和发展做出了新的贡献。这种蓬勃发展的局面表明，面向对象的方法和技术已经得到了广泛的认可，并成为目前的主流。然而，各种方法的同时流行也带来了一些问题:各种OOA和OOD方法所采用的概念有许多相似之处，也有一些不同之处(例如，许多方法在同一部分)，在表示符号、OOA模型和文档组织方面的差异就更加明显，这往往使得一些新用户在选择建模方法和工具时难以做出决策，也不利于他们之间的技术交流。
针对这种情况，1994年在美国Rational软件公司工作的G.Booch和J.Rumbaugh认为应该把他们各自的方法(Booch方法[1]和OMT [2])结合起来，形成一个统一的方法。他们在那年六月开始这项工作。并且在1995，10公开发布了第一个版本，也就是统一方法0.8.1995秋OOSE的发起人I . Jacobson[3]加入了Rational软件公司，也因此加入了这个行列。G.Booch、J.Rumbaugh和I.Jacobson。提出统一建模语言的原因有三:No.1，各自的方法在进化中得到了结合；第二，走向统一会带来市场利益；第三，有助于改进各自的方法，从而获得更多的学习者，解决过去各自的方法不能很好解决的一些问题。
为了确定一组用于分析和设计的符号，他们遇到了一些需要权衡的问题。第一，问题范围的界定。比如说；需求规格应该包括在内吗？(答案是肯定的，应该是部分收录)；是否应该包含可视化编程语言？(答案是“没有”)。第二，需要在表达能力和简洁之间做出妥协。太简单的表示会限制解决问题的能力，太复杂会让普通开发者无所适从。第三，他们必须在他们原来的三种方法的基础上进行组合，这也使他们担心对原来方法的改变的大小。太大的改变会造成老用户的困惑，如果保留原有的东西，就会失去做出改进和赢得更多新用户的机会。根据UML文献中提到的这些问题，UML的提出并不是简单地从学术和技术的立场上寻找最合理的解决方案，而是必须考虑到一些与公司、老用户和原有方法相关的实际背景。
无论如何，他们在这种背景下做了他们认为最好的权衡，分别在10的6月和6月发布了UML版本0.9和0.91。从此，“统一方法”被更名为“统一建模语言”，因为它并不完全是一种面向对象的建模方法。这是一种面向对象的建模语言。它只是给出了一组用于建模的元素和符号，并定义了它们的语义，而不是告诉如何对系统建模。正如M.Fowler在他关于UML的书[4]中指出的，“UML被称为建模语言，而不是方法。至少原则上，大多数方法都是由一个建模语言和一个过程* * *。建模语言就是其中之一。该流程是对设计中应采取哪些步骤的建议。”M.Fowler的这本书是以UML1.0为背景编写的，G.Booch、I.Jacobson和J.Rumbaugh亲自为书作序。这至少可以说明书中对UML的这种总体评价是得到其创始人认可的。
1996年，Rational准备向对象管理小组(OMG)申请使用UML作为标准建模语言。于是成立了UML的合作伙伴组织，包括Rational本身* * *和12家公司加入进来。他们推出了UML1.0版本。在1997中，作为初步提案申请提交给OMG。1997中，其他几家公司分别向OMG提交了自己的建模语言提案申请。因此，UML伙伴组织将这些公司吸收到他们的行列中。为了反映这些新成员的意见，对UML1.0进行了修订。Uml 1.1产生于1997年9月1并提交给OMG，OMG在同年采用了它。目前UML1.1是最新版本，但不是最终版本。因为还在修改中。截至UML1.1的发布，以下17家公司参与了UML联合行动:Rational Software，Microsoft，Hewlett-Packard，Oracle，Sterling Software，MCI Systemhouse，Unisys，ICON Computing，IntelliCorp，i-Logix，IBM，ObjectTime，Platinum Technology，Ptech，Taskon，Reich Technologies和Softeam。
2 UML内容概述
根据UML文档，“统一建模语言(UML)是软件系统产品规格说明的可视化构造和文档化语言，也可用于业务建模和其他非软件系统。”UML1.1提供了六个文档，都是以UML伙伴组织中17公司的名义联合发布的。本节先简要介绍这些文档，下一节再介绍。
(1) UML概要:是对UML的一般性介绍，包括它的动机、目标、范围、历史和现状。
(2) UML语义:定义了UML的语义。该定义采用了形式化技术，但不是完全形式化的规范。语法结构被精确地描述，其动态语义用自然语言描述。UML的语法是与符号无关的抽象语法，它可以映射到不同的符号系统。虽然不是完全形式化的，但是，它的定义相当复杂:采用了四级元模型架构，文本长度达到160页以上。在本文件的第2.2节中，介绍了模型的四个级别，即:
元模型:元模型的基本架构，定义了描述元模型的语言。
元模型:元-元模型的一个例子，它定义了一种描述模型的语言。
模型:元模型的一个例子，它定义了一种描述信息领域的语言。
④用户对象:模型的一个实例，定义了一个特定的信息域。
各级模型元素的定义如下:首先给出其抽象语法(使用UML类图表示描述元素之间的关系)，然后给出其形式化规则(使用文本和对象约束语言)，最后描述其语义(使用精确文本)。这样一共定义了118个元素，分为3个部分，9个包。
(3) UML符号指南:该文档给出了UML的可视化表示，并通过实例给出了模型元素的图形化表示符号。详情见下一节。
(4)对象约束语言规范(Object Constraint Language Specification):本文档定义并介绍了一种对象约束语言(Object Constraint Language，OCL)，用于解释一些在图形系统模型中无法完全表达的建模信息。它是一种正式的语言，但是很容易写和读。作为建模语言，并不意味着实现问题。换句话说，它是用来详细解释模型的，而不是用来编译模型的。
(5)软件工程目标过程的UML扩展:根据软件工程的需求，定义了一些UML扩展概念。例如，模型分为四种类型:用例模型、分析模型、设计模型和实现模型。给出了每个扩展模型概念的定义。它没有介绍面向对象的开发过程，也没有谈到如何在过程中使用UML。文件内容很短，只有5页。
(6)业务建模的UML扩展:定义了一些业务建模的UML扩展概念，与前面的文档类似，只是它的扩展是针对一般的业务处理建模，而不是软件工程。文件也很短。
3 UML符号指南
本文档给出了UML的可视化表示，并通过实例给出了模型元素的图形化表示符号。从系统模型的层次来看，UML表示由九种图组成，它们是:
静态结构图，包括类图和对象图；
用例图；
序列图；
协作图；
状态图图表；
活动图；
实现图，包括组件图和部署图。
虽然UML文档中说“UML符号指南定义了符号并提供了实例”，但确切的说法应该是:文档给出了建模元素符号的一般描述，其图形的绘制用实例表示，没有给出一般的图。本文中的大部分插图都是参照M.Fowler的书[4]的做法，在一般意义上给出的。
UML定义了各种图中一些常用的元素，如字符串(名称)、标签(标号)、关键字(关键字)、表达式(表达式)、注释(注释栏)等。，并给出了它们的表示符号。例如，关键字由包含在书名中的字符串表示。注释栏由一个角折叠的矩形中的文本表示。在各种图中，用来封装一组模型元素的元素称为“包”，用一个大方框把这组元素围起来，用角上的小方框给出包的名称来表示。
此外，UML还定义了一些称为“扩展机制”的元素。这些元素可以附加到其他模型元素上，将原来的建模元素特殊化为具有特殊语义的新变体，或者表达它们的一些细节。这些元素可以起到扩展或细化表示的作用。它们是:
约束:约束是模型元素之间的语义关系，解释了某种条件和一些必须保持为真的命题。它的表示就是在大括号之间用工具(比如UML提供的OCL)可以识别的语言写一个表示条件的文本字符串。
注释:注释是写在注释栏的符号(一个角折叠的矩形)中的文本字符串。使用的语言应该是人们容易理解的，不管是否被工具理解。
元素属性:用于显示模型元素的一些附带特性，如属性、关联、目标值等。它的表现形式是用大括号把文本字符串写成keywords = values的形式，多个字符串之间用逗号隔开。
原型(Stereotype ):用于附加到其他模型元素上，将原始模型元素专门化为具有特殊语义的新变体。带有布局的模型元素可以看作是原始模型元素的一个子类，在属性和关系上与原始元素具有相同的形式，但在使用上更加具体。图版类型由书籍名称中包含的关键字表示。上述概念的表示如图1所示。
图1图元素、包和扩展机制
下面分别介绍各种图以及图中使用的建模元素和表示。
(1)静态结构图
静态结构图包括类图和对象图。"类图是静态结构模型的图形表示.""类图是(静态)声明的模型元素的集合."关于对象图，文档中说:“对象图是一个实例的图，包括对象和数据的值，静态对象图是类图的一个例子。它显示了系统在某个时间点的详细状态的快照”。文档还指出“对象图的用处非常有限”，“工具不需要支持独立的对象图”。类图可以包含对象，一个包含对象但没有类的类图是一个“对象图”。然而，这一术语仍然有助于描述可能以各种方式实现的特殊用法”。静态结构图中使用的各种建模元素的表示如下图所示。
图2静态结构图中建模元素的表示
类:类是一组具有相似结构、行为和关系的对象的描述。UML为一个类提供了三种图形表示。1是一种隐藏细节的方法，在一个框中只给出类名。第二种方法是分析级详细方法，在上、中、下三列分别给出类名、属性名和类型、操作名；第三种是实现级细节方法，给出了更多的细节。
名称区间:定义类符号名称列的书写规范。
列表区:定义类符号的属性列和操作列的编写规范。
Attribute:指定attribute和后面三个可见性符号的书写方法:“+”表示公共，“#”表示受保护，“-”表示私有。
操作:指定操作的书写方式，采用三个与属性相同的可见性符号。
类型与实现类:这是两个特殊的类元素，通过在类符号上附加布局关键字“类型”或“实现类”，并在属性列和操作列中给出属性和操作的定义细节而获得。其中，“类型”描述了一个对象可能采用然后抛弃的可变规则；“实现类”定义了一个对象在语言中实现时的物理数据结构和过程。以下七个符号都是这样得到的。
接口:接口是对类或其他实体(如包)的外部可见操作的描述。它没有描述实体的结构。它的表示类似于类符号，但是没有属性列。在名称列中添加关键字“接口”，在操作列中填写接口定义。
参数化类(Template):它是一个具有一个或多个未绑定形参的类，所以它定义了一个类族，并将形参与一个实际值绑定，以解释其中一个类。参数化类的表示就是在类符号的右上角加一个虚线框，在这个框里解释了每个形参的不同实现类型。
绑定元素:其功能是将模板的参数与实际值关联(绑定)。它的表现就是用文字解释模板的参数值表。
实用程序:以类的形式声明的一组全局变量和过程。它不是一个基本结构，而是一个编程工具。它的表示在类符号的类名列中用关键字“utility”标记。
元类:一个类的类，它的例子是一个类。其表现就是在类名列中添加关键字“元类”。
类路径名:用于表示对类的引用。符号是在引用这个类的地方用符号“∷”表示被引用的类名(在其他包中)。
导入包:表示可以在一个包中引用另一个包中的类。这是一种特殊的依赖关系。它的表现形式是将关键字“import”添加到依赖符号中(虚线箭头)。
对象:对象是一个类的特殊实例。UML给出的对象表示是一个只有两列的盒子。“名称”列中填入了对象(实例)的名称，并指明了它所属的类名。每个属性的值在属性列中给出。
复合对象:由一些紧密联系的部分组成的高级对象，是复合类的一个例子。它由一个有两列的方框表示。在上栏填写复合对象的名称并注明其类名，在下栏画出其各个零件对象。
关联:分为二元关联和多元关联，下面几项分别介绍。
二元关联:是两个类之间的关联(包括一个类到自身的关联的特例)。它的表现形式是用实线连接两个类符号。这条线可以根据作图方便画成直线、斜线或曲线，也可以由几段组成。线的端点与类符号相交的地方称为关联端点，在端点附近可以标注一些有用的信息。指出关联的不同情况(稍后描述)。整个关联还可以携带一些附加信息，包括:关联名称，表示关联的作用；关联类符号与普通类符号相同，但必须附加到一个关联中，以指示该关联的属性和操作。这些东西是可选的，不是强制性的。
AssociationEnd:关联端不是一个独立的元素，而是关联的一部分，用来展现关联的一些细节。一些细节是通过在联想端旁边附加一些字符或图形来表达的。包括多样性、排序、限定符、角色名、可变性和可见性。其他细节用关联线端点的不同形状来表示，包括:空心箭头表示可导航性，表示可以找到关联一端的对象实例。空心菱形箭头表示聚合，表示关联一端的对象实例是另一端的对象实例的组件；实心菱形箭头表示一种很强的聚集形式，称为组合。
多重性:在关联的端点上标记一个数字(代表一个特定的数字)或*号(代表多个)，以指示有多少个对象实例与另一端的对象实例相关联。
限定符，在关联的一端与类符号接口的地方画一个矩形框，并在框中给出一些属性值来表示关联另一端的对象满足什么条件才能与这一端的对象关联。它是协会的一部分，而不是班级的一部分。
关联类用于表示一个关联具有类的特征(包括属性和操作)，用普通的类符号表示，并附加在关联线上。
n元关联，三个以上的类之间的关联，用从菱形到每个相关类符号画连线来表示。
根据UML，组合是聚合的形式之一，意味着整体与部分有很强的关系，并且具有相同的生存时间。它的表现是在关联线的末端添加一个实心菱形箭头。
Link(链)是关联的实例，表示两个对象之间的联系。它的表现就是在两个对象实例之间画一条直线。
泛化:“是一个更一般的元素和一个与之完全一致的更特殊的元素之间的分类学关系，增加了更多的信息。”这个概念与大多数OO技术文档中提到的“继承关系”或“一般特殊关系”基本相同，然而，UML的泛化不仅用于表示类之间的关系，还用于包、用例等元素。有两种表达方式。一种是* * *享受法，在一般元素的符号旁边画一个三角形，从三角形的底部画一条连线，这个连线有几个分支，分别连接到每个特殊元素；另一种是去中心化的，在一般元素的符号旁边画多个三角形，每个三角形的底部画一条线通向一个特殊元素。可以在该行旁边添加一个名为discriminator的文本标签，以表明什么是机密。
依赖:UML对依赖的语义定义如下:“指出两个(或多个)模型元素之间的语义关系。它的含义只涉及这些元素本身，而不涉及它们的实例。它指出，对该依赖关系中的目标元素的更改可能需要对源元素进行更改。有以下几种依赖关系:
痕迹-痕迹:在不同表意层次上代表同一概念的两个元素之间的历史联系。
细化-细化:两个元素之间具有映射(不一定完整)关系的历史或派生连接。
用途-用法:一个要素的正确实现或功能表现需要另一个要素。
Bind-Binding:将模板参数绑定到实际值，以创建非参数元素。
依赖关系的表示是在两个模型元素之间画一条带箭头的虚线，在依赖关系所属的旁边，或者加上一个名字。《UML符号指南》在介绍依赖关系时并没有谈到它与消息概念的联系和区别。“消息”和“消息流”等UML概念分别用于序列图和协同绘图(见后面)。然而，M.Fowler在参考文献[4]中解释道:“对于一个类来说，依赖关系的存在可能是由于以下原因:一个类向其他类发送消息；一个类将其他类作为其数据的一部分；一个类引用其他类作为操作的参数。
派生元素:派生元素是可以从其他元素计算出来的元素。虽然没有加入语义信息，但是可以更清晰或者更有利于设计。它的表现形式是在派生元素的名称前加一个斜杠“/”。
(2)用例图
"用例图用来表达参与者和用例之间的关系.""用例模型向系统外的交互者表达系统或类的功能."UML定义了组成用例图的下列元素(如图3所示)。
图3用例图
用例:用例是由系统或类提供的一个紧凑的功能单元，它通过系统与一个或多个外部交互者(即活动者)之间交换的消息序列以及系统执行的活动来体现。
参与者:参与者是由直接与系统交互的外部对象扮演的角色。
用例关系包括以下三种关系:通信，是活动者和用例之间唯一的关系，是活动者对用例的参与；扩展，从用例A到用例B的扩展关系表明B的实例(在扩展描述的特殊条件下)可能包含A中描述的行为；用途:从A到B的使用关系表明A的实例也包括B中描述的行为.
(3)顺序图
UML给出了两种形式的交互图，一种叫做序列图，另一种叫做协作图。它们基于相同的基本信息，但强调不同的方面。序列图显示了按时间顺序排列的交互。特别是，它显示了对象在其生命线上参与的交互以及它们按时间顺序交换的消息。它不显示对象之间的关系。序列图表示的交互是对象协作产生所需操作或结果时交换的一组消息。序列图有两种绘制方式:简单形式和详细形式。后一种画法与OOSE [3]等著作介绍的交互图基本一致——横向和纵向展示参与交互的物体。整个平面显示了对象之间交互的时空关系，序列图如图4所示。用于序列图的建模元素有:
图4序列图
对象生命线:显示对象在从创建到撤销的时间范围内所扮演的角色的垂直虚线。
激活:显示对象直接或通过其下属流程执行活动的时间段。
消息:消息是对象之间的通信，用于传递信息和期望某种活动。消息的接收是一个事件。
传输时间:发送或接收一条消息所需的时间。两者可以相同，也可以不同。
(4)协作图
协作图是UML提到的另一种交互图，它表示一些对象之间组织的操作以及它们之间的链。与序列图不同，协作图表示的是对象角色之间的关系，而不是时间顺序。协作图描述了特定上下文中一组相关对象之间的协作。以及当这组对象协作产生所需的操作或结果时交换的一组消息。协作图的图形表示以对象为节点，既有表示消息的箭头线，也有表示节点间关联的连接线。消息线有三种，分别代表三种不同的消息，分别是调用、控制流和异步，但是还有一些情况是无法表示的，比如balking和time out。需要一些进一步扩展的符号。协作图中使用的相关符号还包括许多不同的端点情况，如限定符和组合等。协作图如图5所示。
图5协作图
UML符号指南为协作图定义的概念或建模元素包括协作、协作内容、交互、模式结构、协作角色、多对象、活动对象、消息流和创建/销毁标记，这里不做介绍。
(5)状态图
状态图在UML中也称为状态机。它代表了一个物体或一个相互作用在整个一生中受到刺激时的状态序列，以及它的反应和活动。它被附加到一个类或方法上。用于建立状态图的建模元素有:状态(state)、复合状态(compound state)、子状态(Substate)、事件(Event)、简单变迁(Simple Transition)、复杂变迁(Complex Transition)、嵌套状态(Nested State)、发送消息(Sending Message)、内部变迁等。状态图及其相关元素的表示与大多数现有的OOA/OOD方法类似，在此不再赘述。
(6)活动图
活动图是状态图的变体。它的状态指示操作执行的活动，它的转换由操作的完成触发。它表示流程本身的状态机。进程是一个类中操作的实现。构成活动图的元素有:动作状态、决策、泳道(泳道像游泳池一样画在图中，每个活动组放在不同的泳道中，使之更清晰)、动作-对象流关系(活动-对象流关系，表示一个活动与相关对象之间的消息和输入/输出关系)、控制图标(表示信号的发送和接收)等。活动图如图6所示。
图6活动图
(7)实现图
实现图显示了实现的问题，包括源代码结构和运行时实现结构。实现图有两种，一种是显示代码结构的组件图，另一种是显示运行时系统结构的扩展图。
组件图显示了源代码、二进制代码和可执行代码等软件组件之间的依赖关系。/ca & gt；