1.TiKV 源码解析系列文章（十四）Coprocessor 概览
2.能帮我详细解释一下Web2．0么?
3.什么是统一建模语言？

TiKV 源码解析系列文章（十四）Coprocessor 概览

       本文将简要介绍 TiKV Coprocessor 的基本原理。TiKV Coprocessor 是 TiDB 的一部分，用于在 TiKV 层处理读请求。通过引入 Coprocessor，TiKV 可以在获取数据后进行计算，从而提高性能。h5测试小游戏源码

       传统处理方式中，TiDB 向 TiKV 获取数据，然后在 TiDB 内部进行计算。而 Coprocessor 则允许 TiKV 进行计算，将计算结果直接返回给 TiDB，减少数据在系统内部的传输。

       Coprocessor 的概念借鉴自 HBase，其主要功能是对读请求进行分类，处理包括 TableScan、IndexScan、Selection、Limit、TopN、Aggregation 等不同类型请求。其中，DAG 类请求是最复杂且常用的类型，本文将重点介绍。

       DAG 请求是由一系列算子组成的有向无环图，这些算子在代码中称为 Executors。DAG 请求目前支持两种计算模型：火山模型和向量化模型。在当前的 TiKV master 上，这两种模型并存，但火山模型已被弃用，因此本文将重点介绍向量化计算模型。

       向量化计算模型中，所有算子实现了 BatchExecutor 接口，其核心功能是 get_batch。算子类型包括 TableScan、IndexScan、Selection、Limit、TopN 和 Aggregation 等，它们之间可以任意组合。

       以查询语句“select count(1) from t where age>”为例，展示了如何使用不同算子进行处理。本文仅提供 Coprocessor 的概要介绍，后续将深入分析该模块的源码细节，并欢迎读者提出改进意见。

能帮我详细解释一下Web2．0么?

       历史很重要。对一个技术的学习也应当从历史出发，通过其在时间形成历史的流变，得以知晓现状，甚至能够预知未来。

       那Web 1.0是什么呢？

       他们说，记得静态HTML的WWW时代么？

       （那个时代的WWW应用、人们的Web体验、对社会的影响如何？）

       那么动态HTML和静态HTML下的Web相比，是多少版本？1.5？对了，他们是真这么叫的。

       （在效果和影响上，与1.0相比，扩展和加深多少？）

       要呈现的数据存储在数据库中，通过Web服务端的程序，应用户的请求，取出数据，加上事先设计的模板，动态的生成Html代码，发送到用户的浏览器那里。

       他是1.0系列，应为用户在浏览器中所见和Web 1.0一样，它有0.5的升级，因为数据不是事先制作并发布，而是动态生成，和用户的需要交互生成。

       那好，在加0.5，到Web 2.0，变化是在哪里呢？

       （看到了正在崛起的和改变的，会继续朝着什么方向改变互联网和社会呢？）

       更新：关于各个版本的差别，看看亚马逊的例子。

       事情没有那么幸运，Web 2.0并不是鸿蒙os文件源码一个具体的事物，而是一个阶段，是促成这个阶段的各种技术和相关的产品服务的一个称呼。所以，我们无法说，Web 2.0是什么，但是可以说，那些是Web 2.0。

       WikiPedia的Web 2.0条目下列出了这些条件：

       * CSS 和语义相关的 XHTML 标记

       * AJAX 技术

       * Syndication of data in RSS/ATOM

       * Aggregation of RSS/ATOM data

       * 简洁而有意义的 URLs

       * 支持发布为 weblog

       * RESTian (preferred) 或者 XML Webservice APIs

       * 一些社会性网络元素

       必须具备的要素有：

       * 网站应该能够让用户把数据在网站系统内外倒腾。

       * 用户在网站系统内拥有自己的数据

       * 完全基于Web，所有的功能都能透过浏览器完成。

       （以上内容引用自英文版维基百科）

       虽然这只是一家之言，不过，对于其中谈到的几个要素，大家还是公认的。

       - 基于RSS/ATOM/RDF/FOAF等XML数据的同步、聚合和迁移。

       数据不再和页面和网站混粘在一起，它独立了，它跟着用户走。这是Web 2.0的很重要特征。这也是为什么Blog是Web 2.0的代表的原因。在网志上，常主角的是相互独立的一则则的网志。

       独立，然后有物理表现。现在，就能让他们活跃起来。透过对XML数据的处理，这些内容能被自由的组合，被各种应用程序，不论是Web程序还是桌面程序等呈现和处理。

       当然，最重要的是背后的人。

       - 社会性因素。

       内容跟着人走，内容又能够被用户自由的组合，也就是说，用户能够自由的借助内容媒介，创建起一个个的社群，发生各种社会性的（网络）行为。

       此外还有标签以及建立在开放标签系统之上的Folksonomy。

       - 第三个公认的因素是开放API，这个技术性稍强些，得另花时间研习，可以先看看例子：amazon、flickr、google map等。

       从Web应用的产品/服务生产者角度来说，该如何创建Web 2.0的产品呢？

       重要的是要抓住这么几点，一个是微内容（这里有定义），一个是用户个体。除了这两个最基本的之外，还可以考虑社群内的分享以及提供API。

       微内容：英文是microcontent。用户所生产的任何数据都算是微内容，比如一则网志，评论，，收藏的书签，喜好的音乐列表、想要做的事情，想要去的地方、新的朋友等等。这些微内容，充斥着我们的生活、工作和学习，它的数量、重要性，还有我们对它的依赖，并不亚于那些道貌岸然、西装革履的正统文章、论文、书籍。

       对微内容的重新发现和利用，是互联网所开创的平等、民主、自由风气的ex指标公式源码自然衍生，也是互联网相关技术消减信息管理成本之后的一个成果。

       我们每天都生产众多的微内容，也消费着同样多的微内容。对于Web 2.0来说，如何帮助用户管理、维护、存储、分享、转移微内容，就成了关键。

       用户个体。对于Web 1.0的典型产品/服务来说，用户没有具体的面貌、个性，它只是一个模糊的群体的代名词而已。但是对于Web2.0的产品和服务来说，用户是个实实在在的人。Web 2.0所服务的，是具体的人，而不是一个如同幽灵般的概念。并且，这个人的具体性，会因为服务本身而不断地充实起来。

       如何为这个具体的个体服务，是Web 2.0设计的起点。

       因此，一类可以被称作Web 2.0的产品/服务将是这样：

       服务于用户个体的微内容的收集、创建、发布、管理、分享、合作、维护等的平台。

       其他的呢？恐怕就设计到好些人提到的，微内容的XML表现；微内容的聚合；微内容的迁移；社会性关系的维护；界面的易用性等等。

       以及是否就是开源、参与、个人价值、草根、合作等等？

       Web2.0是许多方面起头并进又相互牵连的一个新的阶段的到来。因此，不同的人，有着不同的看法。那么，对于Web开发人员来说，Web2.0意味着什么呢？

       他们说Web2.0阶段，Web是一个平台，或者说，Web正在变得可编程，可以执行的Web应用。野心家们设想这个它的终极目标是Web OS。

       Web 1.0时候，Web只是一个针对人的阅读的发布平台，Web由一个个的超文本链接而成。现在的趋势发生了变化，Web不仅仅是Html文档的天下，它成了交互的场所。

       Web 2.0 Conference网站的横幅引用Jeff Bezos的话说“Web 1.0 is making the internet for people，web 2.0 is making the internet better for computers”。

       具体来讲，他们说Web成为一个开发环境，借助Web服务提供的编程接口，网站成了软件构件。

       这些，就是Web Service的目标吧，信息孤岛通过这些Web Service的对话，能够被自由构建成适合不同应用的建筑来。

       一些例子：del.icio.us、flickr、a9、amazon、yahoo、google、msn等提供的编程接口衍生出的各种应用。

       为什么要开放APIs，这涉及到集市中的商业方面的技术策略。当然，球会体育源码还有更深层的原因，那是什么呢？

       这种交互不仅体现在不同的网站服务之间，同时还体现在用户和Web之间在浏览器上的交互。这也是为什么在美味书签的收藏中Web2.0和AJAX如此相关的一个原因。

       在Web页面上使用桌面程序有的那些便利，真的是很享受的事情。这恐怕也是Web可编程的一个方面，Web页面不再是标记和内容混合那样的简单，它就是一个可以编程的地方（是这样理解吧？）

       有人反对说，AJAX的使用对搜索引擎不友好，只有Web 1.0的站长才关心这个事情吧，在Web 2.0时候，站长应该关心的是用户参与的便利、用户的自由度，至于搜索，有RSS/ATOM/RDF等，更本用不着操心，Google不是已经顺应这个趋势，让大家主动提交了么？

       可编程的第三个方面，是否在于Web应用和桌面应用之间的无缝连接趋势的出现？类似这里说的“从工具上，是由互联网浏览器向各类浏览器、rss阅读器等内容发展”

       编程的一个重要目的是对数据的操作，因此，对于网站来说，除了Web Service接口之外，最近为简便方式就是将内容以RSS/RDF/ATOM格式，或者有意义的XHTML格式输出，同时实现内容和表现的分离。

       [Web 2.0是个历史学的概念，而非是个技术性的概念，它是对Web发展历史断代的成果。对这个概念的梳理，能帮助我更好的把握互联网正在发生的技术与文化。]

       中文网志圈谈论的Web 2.0内容摘要：

       - “Web 2.0是用来研究现象、发现规律的东西，不是用来招商引资、搭台唱戏的东西。当越来越多的互联网应用采取与用户互动的方式，越来越多的内容是由用户产生，越来越多的用户参与到互联网创造的过程中的时候，其实它代表了一种新的思潮。在这种思潮之下，一些新的技术开始出现，一些古老技术重新焕发了生机。随便你怎么表述这样一种现象，但现象本身是实实在在存在的，不管是叫它Web 2.0，还是社会化互联网。”[Keso：老冒给Web 2.0浇了一桶冷水]

       - “我觉得最有价值的一个是， web应用的数据格式开始逐渐出现了交换“标准”...这些标准...更加容易被机器自动化处理...能帮助人更好地过滤和定制化信息。其次，更多的服务将以web service的形式来提供，...这使得web 服务可以被互相集成， 从而诞生更多新的服务...人的重要性被提高了。过去web更多注重在信息提供， 而现在的越来越多的应用更加关注人，也就是所谓“社会性”。此外web的可用性改进正在被越来越重视...”[老冒：朝web 2.0泼点冷水]

       - “我认为Web x.x是人们为了区别不同时代Web的发展而使用的，而这些概念也是经过归纳出来的结果。抓住对方向，如Wikipedia中所提到的朝向互动及社会网络的方向发展，不论应用何种技术，只要能达到目的都是很好的。甚至作为一般的使用者，都可以不去理会Web x.x的讨论，因为我们都已经在使用这些技术或网站了。”[图书馆观点：Web 2.0]

       - “RSS逐渐成为在线内容提供服务的标准发行平台。Blog以及user-generated内容的兴起。My Yahoo提供的RSS整合型服务。同时提出了值得密切关注的一些发展中领域，其中包括搜索技术，个性化，User-Generated内容（包括 blog，评论，图像和声音），音乐，短视频和Accessibility(易访问性）”[Owen：Mary Meeker新作 - 关于Digital World的炒股源码大全图解发展报告的摘取]

       - “我们谈论的Web2.0带给我们的是一种可读写的网络，这种可读写的网络表现于用户是一种双通道的交流模式，也就是说网页与用户之间的互动关系由传统的“Push”模式演变成双向交流的“Two- Way Communication”的模式。而对于Web服务的开发者来说，Web2.0带来的理念是服务的亲和力，可操作性，用户体验以及可用性。”[Owen：BaCKpACK-体验可读写的Web服务]

       - “web 2.0是一种可以被分发的信息概述，web文档被格式化成了web数据。我们不会再看到不同旧地信息，现在我们所注意到是一种聚合、再混合内容的工具。”[songzhen：也说Web 2.0的翻译]

       - “从这些应用中可以看到：如果基于传统的HTML，同样的功能实现将变得非常复杂和不稳定，数据的再生产和交换成本是很高的。所以：RSS这个标准最终要的贡献就是使得互联网的大部分网站变得可编程：类似的例子还有Blog中的：TrackBack Ping等机制，这些机制都是依赖XML/RPC实现的。当初为Lucene设计一个RSS/XML的接口也是为了这个初衷，它使得全文检索服务可以轻松的嵌入到各种应用中，通过关键词将各种内容之间实现更丰富的关联(Well Referenced)。”[车东：RSS，简单协议使得互联网可编程]

       - “聚合的可能性以及如何更好地聚合（通常来说，更好的聚合应该基于个人知识管理和人际关系管理）很显然应该成为新一代或者说web2.0架构的核心之一。还有，你会重新发现，恰好是分散带动了聚合，聚合促进了分散，通过聚合的思维，互联网的网络状变得越来越丰富和密集，web2.0就变得越来越有趣味，它将web1.0时代的硕大节点即门户网站不断消解，去努力创造一个更加和谐的自然网络图谱。”[Horse：rss，聚合的无数可能]

       - “新的web2.0网站都依赖于用户参与、用户主导、用户建设”。[Horse：Web 2.0这个词]

       - Keso：Web 1.0与Web 2.0的区别

       - “表面上看，Bloglines取代了门户，成为一个新的中心，但这里有一个重大的区别。门户是只读的，它带有某种锁定的性质。你可以离开门户，但你无法带走门户的内容。Bloglines则完全不同，你觉得它好用，就会继续使用，有一天你不再喜欢Bloglines，你完全可以导出你的OPML，到另一个 RSS订阅网站，或者干脆用客户端软件浏览同样的内容。所以，像Bloglines这样的网站，是可写的，你可以导入，也可以导出。就像你对信息拥有选择权，对服务提供商也同样拥有选择权，没有人可以锁定你，主动权在你自己手上。”[Keso：再说信息选择权]

       - “Flickr、del.icio.us、Bloglines等Web 2.0服务，通过开放API获得了很多有趣、有用的想法，并借助外部的力量，让用户获得了更好的体验。更多大公司也加入到开放API的潮流中，Google、Yahoo!、Amazon、Skype。Google桌面搜索今年3月才开放API，很快就产生了大量的创造，大大扩充了可搜索的文件格式。”[Keso：开放API]

       - “归纳：web1.0天天谈门户，web2.0谈个人化；web1.0谈内容，web2.0谈应用；web1.0商业模式，web2.0谈服务；web1.0谈密闭、大而全，web2.0大家谈开放、谈联合；web1.0网站中心化，web2.0谈个人中心化；web1.0一对一，web2.0谈社会性网络；web1.0不知道你是狗，web2.0你去年夏天干了什么我一清二楚甚至想要干什么呢。。。”[van_wuchanghua：发现了N.HOOLYWOOD，我还知道你今年夏天要干什么]

       - “我认为Web2.0有下面几个方面的特性: 个性化的传播方式. 读与写并存的表达方式. 社会化的联合方式.标准化的创作方式. 便捷化的体验方式. 高密度的媒体方式．”[飞戈：Web2.0与未来的网络]

       - “用RAILS写的网站带有典型的读写网络的特征：RAILS创建的三个架构中的ACTIVE RECORD这个模块中，如果你读读它最重要的基类 ActiveRecord::Base，你会发现有CREAT,EDIT,SAVE,DESTROY这些方法已经天然包含在内了，这让实现一个数据库的CRUDS行为变得如此简单。由于这些类的方法直接和网页的名称映射到一起，这使得网页本身就像一个可以编缉的数据库的数据项。”[Blogdriver：RUBY ON RAILS，wEB2.0世界新生的创造力]

       - “Greasemonkey一定名列前茅。这个通过User Script就能修改任何网页输出效果的插件极大的提高了用户阅读的自主性，一推出就引起了轰动，同时也引来了不少争议。”[Webleon：platypus，完全可写的互联网]

       - “Web1.0到Web2.0的转变，具体的说，从模式上是单纯的“读”向“写”、“共同建设”发展；从基本构成单元上，是由“网页”向“发表/记录的信息”发展；从工具上，是由互联网浏览器向各类浏览器、rss阅读器等内容发展；运行机制上，由“Client Server”向“Web Services”转变；作者由程序员等专业人士向全部普通用户发展；应用上由初级的“滑稽”的应用向全面大量应用发展。 ”[Don：Web 2.0概念阐释]

       Web 2.0阶段的一个重要特征是开放，和Web初期的开放有很大不同，有以下几种突出的表现：

       内容方面。

       - 内容的创作共用授权。它的广谱和可选择性，让它具有了足够的生命力。CC先是在网志圈中广泛采用，后来许多商业公司也纷纷采用CC方式（比如BBC）；先是文本世界采用，后来逐渐推广到了多媒体世界，比如音频、视频、Flash动画等等。一场自由的文化（free culture）运动在各个方面悄然铺开。

       - 内容来源方面的开放。和早期的Web阶段相比，由于使用相关设备的成本降低，利用相关技术的门槛减低，人们可以自由生产并发布各种内容，比如文本信息，比如语音记录，比如视频录制等。信息的生产和传播不再仅仅是商业资本或者技术精英的特权。在Web的新阶段，原来在商业、技术与大众之间的信息生产和传播的落差被削平。消除信息垄断和去中心化已经成为可能。不仅如此，信息的生产和消费的模式也发生了变化，从原来的生产/消费的对立，变成了参与式的信息集市。

       Web主体方面。

       - 商业网站也渐渐采取了开放的、参与的模式。除了内容上的CC授权出现之外。原来并不外露的内容，也随着blog、podcasting等的兴盛而对外开放。一些网站还在技术层面开放，比如开放源代码，比如开放APIs（编程接口），让自己成为一个平台，让用户可以参与衍生产品的创造，用户本身也是产品的生产者。不仅是内容、技术层面，在鼓励用户的参与上，也有相应的开放出现，比如一些新闻网站的RSS源的输出、引用通告（trackback）功能的采纳、blogthis便利的提供，无一不是让用户参与到内容生产、传播的各个环节。

       - 个人信息层面的开放。有开放，才有交流，才有社会行为和形态产生。个人内容的开放是与一类Web 2.0服务的兴起有关。它涵盖了内容（文本、声音、影像、视频）、关系、行为等等。

什么是统一建模语言？

       统一建模语言UML述评

       邵维忠 梅宏

       摘 要 最近由美国Rational公司发起并与其它十几家公司共同推出的“统一建模语言”UML在OO领域受到广泛的关注.文中首先介绍UML产生的背景及其主要内容，然后评论它对OO建模技术的积极影响以及可能存在的问题.UML是一种表达能力丰富的、强有力的建模语言；然而，目前还不能断定它将取代现有的各种面向对象的分析与设计方法.因为它只是一种建模语言，而不是一种方法；其复杂性可能成为它赢得大量用户的障碍.

       关键词 面向对象，建模方法，建模语言

       中图法分类号 TP

       REVIEW OF THE UNIFIED MODELING LANGUAGE(UML)

       SHAO Wei-Zhong and MEI Hong

       (Department of Computer Science & Technology,Peking University,Beijing )

       Abstract The Unified Modeling Language(UML), published by Rational Software Corporation and other UML partners, is attracting wide attention in the area of object technology. The historical background and the main contents of UML are introduced and then its significance, positive influence and some possible problems are discussed. UML is an expressive and powerful modeling language; however, it cannot be concluded that it would replace all existing object-oriented analysis and design methods. The reason is that UML is only a modeling language rather than a method, and its excessive complexity might become an obstacle to win a great number of users.

       Key words object-orientation, modeling method, modeling language

       1 UML的背景

       由于面向对象的分析与设计（OOA/OOD）方法的重要性日益突出，人们对它的研究、开发和应用的热情也在不断升高.在年，以专著、论文或技术报告等形式提出的OOA/OOD方法或OO建模语言有近种，到年，其数量增加到种以上.各种方法的出现都对OOA/OOD技术的研究与发展作出了或多或少的新贡献.这种“百花齐放”的繁荣局面表明面向对象的方法与技术已得到广泛的认可并成为当前的主流.然而多种方法的同时流行也带来一些问题：各种OOA和OOD方法所采用的概念既有许多共同部分也有一定的差异（例如许多方法在OO基本概念基础上各自提出了一些扩充概念，字面上相同的概念其语义解释也不尽相同）；在表示符号、OOA模型及文档组织等方面差别则更为明显.这种情况往往使一些新用户在进行建模方法及工具的选择时感到难以决策，也不利于彼此之间的技术交流.

       鉴于这种情况，年同在美国Rational软件公司工作的G.Booch和J.Rumbaugh认为，应该把他们各自提出的方法（Booch方法〔1〕和OMT〔2〕）结合起来，形成一种统一方法.该年月他们开始了这一工作，并于年月公开发布了第一个版本，即Unified Method 0.8.年秋OOSE〔3〕的提出者I.Jacobson加入了Rational软件公司，于是也加入了这一行列.G.Booch，J.Rumbaugh和I.Jacobson共同认为，提出一种统一的建模语言有以下3个理由：第1，他们各自提出的方法在演化中已经有互相结合的趋向；第2，走向统一将带来市场方面的好处；第3，有助于改进他们各自的方法，以获得更多的学习者并解决一些以往在他们各自的方法不能很好解决的问题.

       为确定一套用于分析与设计的表示符号，他们遇到了一些需要权衡的问题.一是问题范围的界定.比如；是否应包括需求规约？（回答是，应部分地包括）；是否应包括可视化编程语言？（回答为“否”）.二是必须在表达能力和简单性之间作出折衷.表示法过于简单将使解决问题的能力受到限制，过于复杂则将使普通的开发者不知所措.三是在他们原先的3种方法基础上进行联合，也使他们必须顾忌对原有方法的改动大小；改动过大将引起老用户的混乱，沿用原先的东西则将失去作出改进并嬴得更多新用户的机会.从UML的文献中谈到的这些问题看，UML的提出不是单纯从学术和技术的立场寻找一种最合理的方案，而是必须考虑到与公司、老用户和原先各种方法有关的一些实际背景.

       不管怎样，他们作出了在这种背景下他们认为最好的权衡，于年6月和月先后发布了UML 0.9和0.版本.从此时起，“统一方法”改称为“统一建模语言” （unified modeling language）.因为确切地讲，它并不是一种面向对象的建模方法，而是一种面向对象的建模语言.它只是给出一套用于建模的元素及表示符号并定义了它们的语义，而不是讲述如何进行系统建模.正如M.Fowler在专门介绍UML的著作〔4〕中指出的：“UML被称作建模语言，而不是一种方法.至少从原则上讲，大部分方法是由一种建模语言和一种过程共同组成的.其中建模语言是一种（以图形方式为主的）表示符号，用来表达人们的设计；过程则是对进行这种设计应采取哪些步骤所提出的建议.”M.Fowler的这本书是以UML1.0版本为背景写作的，G.Booch，I.Jacobson和J.Rumbaugh亲自为该书作序.这至少可以表明，该书对UML的这种总体评价是得到其缔造者认可的.

       年，Rational准备向对象管理组织（Object Management Group，简称OMG）申请将UML作为一种标准建模语言.为此创立了UML伙伴组织，包括Rational本身共有家公司加入.他们推出了UML1.0版，于年1月提交到OMG作为初步的提案申请.年另有几家公司分头向OMG提交自己的建模语言提案申请.于是，UML伙伴组织把这些公司也吸收到自己的行列中来.为了反映这些新成员的意见，又对UML1.0进行了修改，于年9月1日产生了UML1.1并提交到OMG，同年月被OMG采纳.目前UML1.1是最新版本，但不是最终版本，因为还在继续进行修改.到UML1.1发布时止参加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提供了6份文件，均以UML伙伴组织中家公司的名义联合印发.本节首先简略地介绍这些文件，下一节将对其中的UML表示法指南作较详细的介绍.

       （1） UML概要（UML Summary）：是对UML的概括介绍，包括其动机、目标、范围、历史与现状.

       （2） UML语义（UML Semantics）：定义了UML的语义.定义采用了形式化技术，但并不是完全形式化的规约.对语法结构给出了精确的规约，对其动态语义则是用自然语言描述的.UML的语法是一种与表示符号无关的抽象语法，它可以映射到不同的符号体系中.尽管没完全形式化，但其定义方式也颇为复杂：采用了4级元模型体系结构，文本的篇幅达到余页.在该文件的2.2节介绍了模型的4个级别，即：

       ① 元-元模型（meta-metamodel）：元模型的基础体系结构，定义一种说明元模型的语言.

       ② 元模型（metamodel）：元-元模型的一个实例，定义一种说明模型的语言.

       ③ 模型（model）：元模型的一个实例，定义一种语言来描述信息领域.

       ④ 用户对象（user object）：模型的一个实例，定义一个特定的信息领域.

       对各级模型元素的定义方式是，首先给出它的抽象语法（采用UML的类图表示法描述元素之间的关系），然后给出其形式化规则（采用正文和对象约束语言），最后描述其语义（采用准确的正文）.按这种方式总共定义了个元素，划分到3个部分和9个包（package）中分别加以定义.

       （3） UML表示法指南（UML Notation Guide）：该文件给出UML的可视化表示法，通过例子给出模型元素的图形表示符号，详见下一节.

       （4） 对象约束语言规约（Object Constraint Language Specification）：该文件定义并介绍了一种对象约束语言（简称OCL），其用途是用来说明一些在图形化的系统模型中不能充分表达的建模信息.它是一种形式化的语言，但容易书写和阅读.作为一种建模语言，它并不表示实现方面的问题.就是说，它是用来对模型作详细说明的，而不是可编译执行的.

       （5） 用于软件工程对象过程的UML扩充（UML Extension for Objectory Process for Software Engineering）：针对软件工程中的要求，定义了一些UML的扩充概念.例如，将模型分为Use Case模型、分析模型、设计模型和实现模型4种，对每一种扩充的模型概念给出其定义.它并未介绍面向对象的开发过程，也不讲在过程中如何运用UML.文件内容很短，只有5页.

       （6） 用于业务建模的UML扩充（UML Extension for Business Modeling）：定义了用于业务建模的一些UML扩充概念，与上一个文件相似，只是它的扩充是针对一般业务处理建模，而不是对软件工程的.该文件也很短.

       3 UML表示法指南

       该文件给出UML的可视化表示法，通过例子给出模型元素的图形表示符号.从系统模型这一级别上看，UML表示法由9种图构成，它们是：

       静态结构图（Static Structure Diagram），其中包括类图（Class Diagram）和对象图（Object Diagram）；

       Use Case图 （Use Case Diagram）；

       顺序图（Sequence Diagram）；

       协作图（Collaboration Diagram）；

       状态图（Statechart Diagram）；

       活动图（Activity Diagram）；

       实现图（Implementation Diagram），其中包括成分图（Component Diagram）和展开图（Deployment Diagram）两种图.

       尽管UML文件称“UML表示法指南定义了表示法并提供了例子”，但确切的说法应该是：该文件对建模元素的表示法给出了一般的文字描述，其图形的画法是通过例子表现的，并没有给出一般的图示.本文大部分插图是参照M.Fowler的著作〔4〕的作法从一般意义上给出的.

       UML定义了一些在各种图中常用的元素，例如String（串）、Name（名）、Label（标签）、Keyword（关键词）、Expression（表达式）、Note（注释条）等，并给出它们的表示符号，例如关键词由一个被书名号括起的串表示，注释条用一个折起一角的长方形内的正文表示.在各种图中用来对一组模型元素打包的元素叫做“包”（Package），其表示法是用一个大的方框围起这组元素，并在角上用一个小框给出包的名字.

       此外，UML还定义了一些称作“扩充机制”的元素.这种元素可以附加到其它模型元素之上，将原有的建模元素特化成一种语义较特殊的新变种，或者表示出它们的某些细节.这些元素可以起到对表示法进行扩充或细化的作用，它们是：

       Constraint（约束）：约束是模型元素之间的一种语义关系，它说明了某种条件和某些必须保持为真的命题.其表示法是在大括号{ }之间用一种工具能识别的语言（如UML提供的OCL）写出表示条件的正文串.

       Comment（注释）：注释是写在注释条表示符号（折起一个角的长方形）之内的正文串.所使用的语言应易于人的理解，不必考虑被工具理解.

       Element Property（元素特征）：用来显示模型元素的一些附带特征，如属性、关联、目标值等.其表示法是在大括号{ }内写出形式为 关键词=值 的正文串，多个串之间彼此用逗号隔开.

       Stereotype（版式）：用来附加到其它模型元素之上，将原有的建模元素特化成一种语义较特殊的新变种.带有版式的建模元素可看作原先建模元素的一个子类，它在属性、关系等方面与原先的元素形式相同，但用途更为具体.板式是用书名号《 》括起来的关键字表示的.上述概念的表示法如图1所示.

       图1 图元素、包和扩充机制

       以下分别介绍各种图以及图中用到的建模元素与表示法.

       （1） 静态结构图

       静态结构图包括类图（class diagram）和对象图（object diagram）.“类图是静态结构模型的图形化示图.”“类图是（静态）声明的模型元素集合.”关于对象图，该文献中说道：“对象图是实例的一种图形，包括对象和数据的值，静态的对象图是类图的一个实例；它显示了在一个时间点上系统细节状态的一个快照”.该文献又指出：“对象图的用处是很有限的”，“工具没有必要支持独立形式的对象图.类图能包括对象，一个有对象而没有类的类图便是一个‘对象图’.不过这个术语对于刻画在各种方式下可能达到的特殊用法还是有用的”. 静态结构图中用到的各种建模元素的表示法如图2所示，以下分别加以介绍.

       图2 静态结构图中的建模元素表示法

       Class（类）：类是对具有相似的结构、行为和关系的一组对象的描述.UML对类提供了3种图形表示符.第1种是细节抑制方式，只在一个方框中给出类名；第2种是分析级细节方式，在上、中、下3栏分别给出类名、属性名与类型、操作名；第3种是实现级细节方式，给出更多的细节.

       Name Compartment（名字栏）：定义了类符号的名字栏的书写规范.

       List Compartment（列表栏）：定义了类符号的属性栏和操作栏的书写规范.

       Attribute（属性）：规定了属性的写法，以及以下3种可见性符号：“+”表示public（公共），“#”表示protected（保护），“-”表示private（私有）.

       Operation（操作）：规定了操作的写法，采用与属性相同的3种可见性符号.

       Type vs. Implementation Class（类型与实现类）：这是将版式关键词《type》或《implementation class》附加到类表示符号之上，并在属性栏和操作栏中给出属性与操作的定义细节而得到的两种较特殊的类元素.其中“类型”刻画一个对象可能采用然后又放弃的可变规则；“实现类”定义了在用一种语言实现时对象的物理数据结构与过程.以下7种表示符号都是用这种方式得到的.

       Interface（接口）：接口是对一个类或其它实体（诸如包这样的大单位）的对外可见操作的说明，它不说明实体的结构.其表示法很像类符号，但没有属性栏；在名字栏中加关键词《interface》，在操作栏填写接口定义.

       Parameterized Class（Template）（参数化类，又称模板）：它是带有一个或多个未绑定的形式参数的类，因此它定义一个类家族，将参数与一个实际值绑定便说明了其中一个类.参数化类的表示法是在类符号的右上角加一个虚线框，框内中说明各个形参的不同实现类型.

       Bound Element（绑定元素）：它的作用是将模板的参数与实际的值联系（绑定）.其表示法是用文字说明模板的参数值表.

       Utility（实用程序）：以类的形式声明的一组全局变量与过程.它不是一种基本构造，而是一种编程便利设施.其表示法是在类符号的类名栏中标以关键字《utility》.

       Metaclass（元类）：即类的类，它的实例是类.其表示法是在类名栏中加关键词《metaclass》.

       Class Pathname（类路径名）：用以表示对一个类的引用.表示法是在引用这个类的地方（在其它包中）以符号“∷”指出被引用的类名.

       Importing a Package（引入一个包）：表明在一个包中可以引用另一个包中的类.这是一种特殊的依赖（dependency）关系.其表示法是在dependency符号（虚箭头）上旁加关键字《import》.

       Object（对象）：对象是类的一个特殊实例.UML给出的对象表示法是一个只有两栏的方框.名字栏填写对象（实例）名并指出它所属的类名.属性栏中给出每个属性的值.

       Composite Object（组合对象）：由一些紧绑在一起的部分所构成的高层对象，它是组合类（composite class）的实例.用含有两栏的方框表示，在上栏填写组合对象名并指出其类名，在下栏画出它的各个部分对象.

       Association（关联）：分为二元关联和多元关联，在以下的条目中分别介绍.

       Binary Association（二元关联）：是两个类之间的关联（包括从一个类到它自身的关联这种特殊情况）.其表示法是用一条实线连接两个类符号.这条线可根据绘图时的方便画成平直的、斜的或弯曲的.也可由若干段组成.线的端点与类符号相接的地方叫作关联端点，端点附近可以注明一些有用的信息，表明关联的不同情况（稍后介绍）.整个关联也可以带有一些附加信息，包括：关联名（association name），通过这样的命名表明关联的作用；关联类（association class）符号，和普通的类符号相同，但必须附着在一个关联上，用于表明关联的属性与操作.这些东西都是任选的、非强制的.

       AssociationEnd（关联端点）：关联端点不是独立的元素，它是关联的一部分，用于表明关联的一些细节内容.一部分细节内容通过在关联端点旁边附加一些字符或图形来表示，包括多重性（multiplicity）、有序性（ordering）、限制（qualifier）、角色名（rolename）、可变性（changeability）、可见性（visibility）.另一些细节是通过关联线端点的不同形状来表示的，包括：开放形的箭头表示可导航性（navigability），即表示从关联一端的对象实例能够找到另一端与它关联的对象实例；空心的菱形箭头表示聚合（aggregation），即表示关联一端的对象实例是另一端对象实例的组成部分；实心的菱形箭头表示强形式的聚合关系，称作组装（composition）.

       Multiplicity（多重性）：在关联端点上标注数字（表示具体的数量）或“*”号（表示多个），以表明本端有多少个对象实例与另一端的对象实例相关联.

       Qualifier（限制），在关联的一端与类符号相接口的地方画一个矩形框，框中给出一些属性值指明关联另一端的对象符合什么条件才有资格与本端的对象关联，它是关联的一部分，而不是类的一部分.

       Association Class（关联类），用于表明一个关联带有类的特征（包括属性和操作），用普通的类符号表示，附着在关联线上.

       N-Ary Association（多元关联），3个以上的类之间的关联.其表示法是从一个菱形向各个相关联的类符号画出连接线.

       Composition（组装）按UML的说法，composition是aggregation的形式之一，它表示整体对部分有很强的拥有关系和相同的生存时间.其表示法是在关联线的端点加一个实心的菱形箭头.

       Link（链），链是关联的一个实例，表明两个对象之间的联系.其表示法是在两个对象实例之间画一条直线.

       Generalization（一般化）：“是较为一般的元素和与之完全一致而又增加了更多信息的较为特殊元素之间的分类学关系.” 此概念和大部分OO技术文献中所讲的“继承关系”或“一般特殊关系”基本相同，不过，UML的generalization除用于表示类之间的关系外还用于包、Use Case和其它元素.表示法有两种方式.一种是共享方式，在一般元素的符号旁边画一个三角形，从三角形的底边引出一条连线，而这条连接有若干分枝，分别连向各个特殊元素；另一种是分散式，在一般元素的符号旁边画多个三角形，每个三角形的底边画出引向一个特殊元素的连线.在连线旁边可以加一个文字标注，叫做discriminator（鉴别器），标明是按什么进行分类的.

       Dependency（依赖）：UML对dependency的语义是这样定义的：“指出两个（或多个）模型元素之间的语义关系.其涵义只涉及这些元素本身而不涉及他们的实例.它指出在这种依赖中对目标元素的一个改变可能需要对源元素的一个改变.”依赖有以下几种：

       trace-Trace：在不同的表意层次上表示同一概念的两个元素之间的一种历史连接.

       refine-Refinement：两个有映射（未必完全）关系的元素之间的历史或衍生连接.

       use-Usage：为了一个元素的正确实现或功能履行需要另一个元素出现.

       bind-Binding：将模板参数绑定到一个实际的值，以创建一个非参数化元素.

       依赖的表示法是在两个模型元素之间画一条带箭头的虚线，旁边可以标明该依赖关系属于以上哪一种，也可加一个名字.UML表示法指南在介绍dependency时没有谈到它与message（消息）的概念有什么联系和区别.UML的“消息”、“消息流”等概念分别用于顺序图和协作图（详见后文），而不用于类图.但是M.Fowler在文献〔4〕中作了这样的解释：“对类而言，dependency可以为如下几种理由而存在：一个类向其它类发送消息；一个类以其它类作为其数据的一部分；一个类提及其它类作为对一个操作的参数.”

       Derived Element（派生元素）：派生元素是可以从其它元素计算出来的元素.尽管它没有增加语义信息，但是有了它可以更清楚或者更有利于设计.其表示法是在派生元素的名字前加一条斜线“／”.

       （2） Use Case图

       “use case图用于表现活动者与use case之间的关系.”“use case模型表现一个系统或一个类对于系统外部的交互者的功能.”UML定义了如下几种构成use case图的元素(如图3).

       图3 Use Case图

       Use Case：一个use case是一个系统或一个类提供的紧凑的功能单元，它是由系统与一个或多个外部交互者（即活动者）之间交换的消息序列以及系统执行的活动共同体现的.

       Actor（活动者）：活动者是直接与系统交互的外部对象所扮演的角色.

       Use Case Relationship（use case关系），包括如下3种关系：communicates（通信），这是活动者与use case之间仅有的关系，是活动者对use case的参与；extends（延伸），从use case A到use case B的延伸关系表明B的实例（在延伸说明的特殊条件下）可能包含了在A中说明的行为；uses（使用）：从A到B的使用关系表明A的实例也包括了在B中说明的行为.

       （3） 顺序图

       UML给出了两种形式的交互图（Interaction Diagram），一种叫顺序图，另一种叫协作图.它们基于相同的基本信息但强调不同的方面.顺序图（Sequence Diagram）展示按时间顺序排列出来的交互.特别是，它展示对象在其“生命线”上参加的交互和它们按时间顺序交换的消息.它不展示对象之间的关系.顺序图所表示的交互是一组在对象之间为产生所要求的操作或结果而进行合作时所交换的一组消息.顺序图有简单形式和详细形式两种画法，后一种画法与OOSE〔3〕等著作介绍的交互图大体一致——在水平方向展示各个参加交互的对象，垂直方向表示时间；整个平面显示各个对象之间进行交互的时间及空间关系，顺序图如图4所示.用于顺序图的建模元素有：

       图4 顺序图

       Object Lifeline（对象生命线）：一条垂直的虚线，用于展示对象在从创建到撤消的时间范围内所扮演的角色.

       Activation（活动期）：展示对象直接地或通过其下级过程执行一个活动的时间段.

       Message（消息）：消息是对象之间的一次通信，用于传送信息并期望发生某种活动.消息的接收是一种事件.

       Transition Time（过渡时间）：消息发送或接收所用的时间.二者可能相同也可能不同.

       （4） 协作图

       协作图（Collaboration Diagram）是UML所说的另一种交互图，它表示在一些对象之间组织的操作和它们之间的链.与顺序图不同的是，协作图表示的是对象角色之间的关系，而不表示时间顺序.协作图描绘了在特定上下文中一组相关对象之间的协作，以及这组对象为产生所要求的操作或结果而进行协作时所交换的一组消息.协作图的图形表示以对象为结点，结点之间既有表示消息的箭头连线，也有表示关联的连线.消息连线有3种，分别表示调用、控制流和异步3种不同的消息，但仍有一些不能表示的情况，如阻塞（balking）和超时（time out）等，需要用一些进一步扩充的表示符号.协作图中使用的关联符号也包括多种不同的端点情况，如qualifier和composition等等.协作图如图5所示.

       图5 协作图

       UML表示法指南为协作图定义的概念或建模元素有：Collaboration（协作）、Collaboration Content（协作内容）、Interaction（交互）、Pattern Structure（模式结构）、Collaboration Role（协作角色）、Multiobject（多对象）、Active Object（主动对象）、Message Flows（消息流）、Creation/Destruction Markers（创建/折构标记），这里不再一一介绍.

       （5） 状态图

       状态图（Statechart Diagram）在UML中也称作状态机，它表现一个对象或一个交互在整个生存期内接受剌激时的状态序列以及它的反应与活动.它附属于一个类或一个方法.建立状态图所用的建模元素有：State（状态）、Composite State（复合状态）、Substate（子状态）、Event（事件）、Simple Transition（简单转换）、Complex Transition（复杂转换）、Nested State（嵌套状态）、Sending Message（发送消息）、Internal Transition（内部转换）等.状态图及其有关元素的表示法和现有的大部分OOA／OOD方法大同小异，这些不再详述.

       （6） 活动图

       活动图（Activity Diagram）是状态图的变种，它的状态表示操作所执行的活动（activity），其转换（transition）是由操作的完成而触发的.它表示了一个过程本身的状态机，过程是对类中一个操作的实现.构成活动图的元素有：Action State（活动状态）、Decision（判断）、Swimlane（泳道，在图中画出来就象游泳池中的泳道，把各个活动组放在不同的泳道中以便更加清晰）、Action-Object Flow Relationship（活动-对象流关系，表示一个活动与有关对象之间的消息和输入/输出关系）、Control Icon（控制图符，表示信号的发送与接收）等.活动图如图6所示.

       图6 活动图

       （7） 实现图

       实现图（Implementation Diagram）表现实现方面的问题，包括源代码结构和运行时的实现结构.实现图分为两种，一种是表示代码自身结构的成分图，另一种是表示运行时系统结构的展开图.