1.一个好的源码程序员至少应该具备哪些条件?
2.什么是统一建模语言？
3.StarUML画时序图

一个好的程序员至少应该具备哪些条件?

       楼上的几位显然误会我的意思了，我并不是源码说不应当写文档加注释注重团队精神，看看下面的源码一篇文章，那位三天就写出UNIX的源码他需要写文档注释和团队精神吗，他用不着。源码哪个高手没有一点傲气和自信，源码当官 源码他之所以敢对用户说：拿到你想要的源码，然后滚蛋，源码你已经很幸运了！源码是源码因为他有这个资本。天才本就不循规蹈矩，源码那样他就不叫天才了。源码

       MIT BBS上说微软电话面试的源码一道题就是“Who do you think is the best coder,

       and why?”。我觉得挺有意思的源码，也来凑个热闹。源码排名不分先后。

       Bill Joy, 前任Sun的首席科学家，当年在Berkeley时主持开发了最早版本的BSD。他还

       是vi和csh的作者。当然，Csh Programming Considered Harmful 是另一个话题乐。据

       说他想看看自己能不能写个操作系统，就在三天里写了个自己的Unix, 也就是BSD的前

       身。当然是传说了，但足见他的功力。另一个传说是，年初的时候，DARPA让BBN在

       Berkley Unix里加上BBN开发的TCP/IP代码。但当时还是研究生的B伯伯怒了，拒绝把BBN

       TCP/IP加入BSD，因为他觉得BBN的TCP/IP写得不好。于是B伯伯出手了，端的是一箭封

       喉，很快就写出了高性能的伯克利版TCP/IP。当时 BBN和DARPA签了巨额合同开发TCP/IP

       Stack，谁知他们的代码还不如一个研究生的好。于是他们开会。只见当时B伯伯穿

       个T-shirt出现在会议室(当时穿T-shirt不象现在，还是相当散漫的哈)。只见BBN问：你

       怎么写出来的？而B伯伯答：简单，你读协议，然后编程就行了。最令偶晕倒的是，B伯

       伯硕士毕业后决定到工业界发展，于是就到了当时只有一间办公室的Sun, 然后他就把

       Sparc设计出来乐。。。象这种软硬通吃的牛人，想不佩服都不行的说。据Bill Joy的同

       事说，一般开会的时候B伯伯总是拿一堆杂志漫不经心地读。但往往在关键之处，B伯伯

       发言，直切要害，提出漂亮的构想，让同事们彻底崩溃。对了，他还是Java Spec和JINI

       的主要作者之一。

       John Carmack，ID Software的founder和Lead Programmer。上个月和一个搞图形的师兄

       聊天，他竟然不知道John Carmack, 也让偶大大地晕了一把。不过也许搞研究的和搞实

       战的多少有些隔吧。想必喜欢第一人称射击游戏的都知道J哥哥。年代初只要能在PC

       上搞个小动画都能让人惊叹一番的时候，J哥哥就推出了石破天惊的Castle Wolfstein,

       然后再接再励，doom, doomII, Quake...每次都把3-D技术推到极限。J哥哥的简历上说

       自己的专长是"Exhaust 3-D technology"，真是牛人之言不我欺的说。做J哥哥这样的人

       是很幸福的，因为各大图形卡厂家一有了新产品就要向他“进贡"

       ，不然如果他的游戏不支持哪种卡，哪种卡基本就会夭折乐。当初MS的Direct3D也得听

       取他的意见，修改了不少API。当然，J哥哥在结婚前十数年如一日地每天编程小时以

       上，宝塔怎么导入源码也是偶们凡人望尘莫及的。对了，J哥哥高中肆业(？)，可以说是自学成才。不过

       呢，谁要用这个例子来为自己学习不好辩护，就大错特错了。那 Leonardo Da Vinci还

       是自学成才呢(人是私生子，不能上学)。普通人和天才还是有区别的。对了，其实偶们

       叫“达分奇”是相当不对的，因为Vinci是地名，而Da Vinci就是从Vinci来的人的意

       思。换句话说，Leonardo Da Vinci就是“从Vinci来的Leonardo”的意思。叫别

       人“Da Vinci”就不知所谓乐。嗯，扯远了，打住。

       David Cutler，VMS和Windows NT的首席设计师，去微软前号称硅谷最牛的kernel开发

       员。当初他和他的手下在微软一周内把一个具备基本功能的bootable kernel写出来，然

       后说：“who can't write an OS in a week?"，也是牛气冲天的说。顺便说一句，D爷

       爷到NT3.5时，管理名开发员，自己还兼做设计和编程，不改coder本色啊。

       D爷爷天生脾气火爆，和人争论时喜欢双手猛击桌子以壮声势。 日常交谈fuck不离口。

       他面试秘书时必问："what do you think of the word 'fuck'?" ，让无数美女刹羽而

       归。终于有一天，一个同样火爆的女面对这个问题脱口而出："That's my favorite

       word"。于是她被录取乐，为D爷爷工作到NT3.5发布。

       Don Knuth。高爷爷其实用不着偶多说。学编程的不知道他就好像学物理的不知道牛顿，

       学数学的不知道欧拉，学音乐的不知道莫扎特，学Delphi的不知到 Anders Hejlsberg，

       或者学Linux不知道Linus Torvalds一样，不可原谅啊。为了让文章完整，就再罗唆几句

       吧。高爷爷本科时就开始给行行色色的公司写各种稀奇古怪的编译器挣外快了。他卖给别

       人时收一两千美元，那些公司拿了code，加工一下卖出去就是上万上十万。不过也没见高

       爷爷不爽过，学者本色的说。想想那可是年代初啊，高爷爷写编译器写多了，顺带就搞

       出了个 Attribute Grammar和LR(k)，大大地造福后人啊。至于高爷爷在CalTech的编程比

       赛(有Alan Kay得众多高高手参加)总是第一，写的Tex到年就code freeze，还附带2^n

       美分奖励等等都是耳熟能详的，偶就不饶舌乐。

       顺便说一下，高老大爷是无可争议的写作高手。他给Concrete Mathematics 写的前言可

       谓字字铿锵，堪为前言的典范。他的技术文章也是一绝，文风细致，解释精当，而且没

       有学究气，不失轻快跳脱。记得几年前读Concrete Mathemathics，时不时开怀大笑，让

       老妈极其郁闷，数据治理java源码觉得我nerdy到家，不可救药。其实呢，子非鱼，安知鱼之乐，更不知那

       完全是高爷爷的功劳。说到写作高手，不能不提Stephen A. Cook。他的文章当年就被我

       们的写作老师极力推荐，号称典雅文风的样本。库爷爷一头银发，身材颀长，总是面带

       谦和的微笑，颇有仙风道骨，正好和他的仙文相配的说。

       高爷爷其实还是开源运动的先驱。虽然他没有象Richard Stallman那样八方奔走，但他

       捐献了好多作品，都可以在网上看到，比如著名的Mathematical Writing，MMIXWare，

       The Tex Book等，更不用说足以让他流芳百世的Tex乐。

       Ken Thompson，C语言前身B语言的作者，Unix的发明人之一(另一个是Dennis M. Riche

       老大，被尊为DMR)，Belle(一个厉害的国际象棋程序)的作者之一, 操作系统Plan 9的主

       要作者(另一个是大牛人Rob Pike,

       前不久被google挖走了)。Ken爷爷也算是计算机历史上开天辟地的人物了。年还是

       计算机史前时代，普通人都认为只有大型机才能运行通用的操作系统，小型机只有高山

       仰止的份儿。至于用高级语言来写操作系统，更是笑谈。Ken爷爷自然不是池中物，于是

       他和DMR怒了，在年到间用汇编在PDP-7上写出了UNIX的第一个版本。他们并不

       知道，一场轰轰烈烈的UNIX传奇由此拉开了序幕。Ken爷爷在年又把Unix用C重写，

       于是C在随后年成就了不知多少豪杰的梦想和光荣。

       Ken爷爷还有段佳话： 装了UNIX的PDP-最早被安装在Bell Lab里供大家日常使用。很

       快大家就发现Ken爷爷总能进入他们的帐户，获得最高权限。Bell

       Lab里的科学家都心比天高，当然被搞得郁闷无比。于是有高手怒了，跳出来分析了UNIX

       代码，找到后门，修改代码，然后重新编译了整个UNIX。就在大家都以为“这个世界清

       净了”的时候，他们发现Ken爷爷还是轻而易举地拿到他们的帐户权限，百思不解后，只

       好继续郁闷。谁知道这一郁闷，就郁闷了年，直到Ken爷爷道出个中缘由。原来，代码

       里的确有后门，但后门不在Unix代码里，而在编译Unix代码的C编译器里。每次C编译器

       编译UNIX的代码，就自动生成后门代码。而整个Bell Lab的人，都是用Ken爷爷的C编译

       器。

       (6)Rob Pike, AT&T Bell Lab前Member of Technical Staff ，现在google研究操作系

       统 。罗伯伯是Unix的先驱，是贝尔实验室最早和Ken Thompson以及Dennis M. Ritche开

       发 Unix的猛人，UTF-8的设计人。他还在美国名嘴David

       Letterman的晚间节目上露了一小脸，一脸憨厚地帮一胖子吹牛搞怪。让偶佩服不已的

       是，罗伯伯还是年奥运会射箭的银牌得主。他还是视酷源码教程个颇为厉害的业余天文学家，设

       计的珈玛射线望远镜差点被NASA用在航天飞机上。他还是两本经典，The Unix

       Programming Environment 和 The Practice of Programming 的作者之一。如果初学者

       想在编程方面精益求精，实在该好好读读这两本书。它们都有中文版的说。罗伯伯还写

       出了Unix下第一个基于位图的窗口系统，并且是著名的blit终端的作者。当然了，罗伯

       伯还是号称锐意革新的操作系统，Plan9，的主要作者。可惜的是，Plan9并没有引起多

       少人的注意。罗伯伯一怒之下，写出了振聋发聩的雄文 Systems Software Research is

       Irrelevant，痛斥当下系统开发的不思进取，固步自封的弊病。虽然这篇文章是罗伯伯

       含忿出手，颇有偏激之词，但确实道出了系统开发的无奈：开发周期越来越长，代价越

       来越大，用户被统一到少数几个系统上，结果越来越多的活动是测量和修补，而真正的

       革新越来越少。

       就在罗伯伯郁闷之极的时候，google登门求贤来乐。如果说现在还有一家大众公司在不

       遗余力地把系统开发推向极致的话，也就是google乐。随便看看google的成果就知道

       了。具有超强容错和负载平衡能力的分布式文件系统GFS

       (现在能够用,台廉价PC搭起一个巨型分布系统，并且高效便宜地进行管理的系统

       也不多哈)，大规模机器学习系统(拼写检查，广告匹配，拼音搜寻。。。哪个都很牛的

       说)，更不用说处理海量并行计算的各式google服务了。Rob在System Software

       Research is Irrelevant里萧瑟地说现在没有人再关心系统研究的前沿成果了。想不到

       他错了，应为google关心。google网络了大批功成总是试图吸取系统研究的最新成果。

       想必Rob Pike在google很幸福。愿他做出更棒的系统。

       Dennis M. Ritchie, 既然Ken Thompson是我的偶像，新闻组上人称DMR的Dennis M.

       Ritchie自然也是，毕竟两人共同缔造了UNIX，而Dennis几乎独力把C搞大(当然，C的前

       身是B，而B是Ken Thompson一手做出来的)。两人年分享图灵奖，是有史以来少数几

       个因工程项目得奖的工程师(本来是唯一的一对儿，但Alan Kay才因为SmallTalk得奖，

       所以就成了唯二的乐) 一个人一生能做出一个卓越的系统已经不易，DMR的C和UNIX长盛

       不衰近年，至今生机勃勃，DMR此生可以无憾的说。

       D爷爷也算有家学渊源：他老爸在AT&T贝尔实验室工作了一辈子，并在电路设计方面卓有

       成就，还出了本颇有影响的书The Design of Switching Circuits，据说在交换理论和

       逻辑设计方面有独到的论述。当然，D爷爷和他老爸是不同时代的人：他老爸的研究成

       形于晶体管发明之前，而D爷爷的工作离了晶体管就玩儿不转乐。:-D

       不要看D爷爷搞出了C，其实他最爱的编程语言是Alef，在Plan9上运行，支持并行编程。

       Alef的语法和C相似，但数据类型和执行方式都和C大大不同。说到语言，D爷爷对后来

       人有非常中肯的建议：抱着学习的目的来开发你自己的语言，不要冀望于它被众人接

       受。这个建议不光对语言开发有用，也适用于其它大型系统的游资选股源码开发。别的不说，DMR后来

       领导自己的团队在年和分别推出了Plan9和Inferno操作系统，又用多少人知道

       呢？其实，D爷爷当初也没想过C会风行世界。他开发C的初衷和Eric S. Raymond

       在Cathedral and Bazaar里阐述的一样，就是要消除自己对现有工具的不爽之处。谁

       知D爷爷无心插柳，C竟然受到众多程序员的狂热拥戴，连D爷爷自己都大惑不解。在一次

       采访中D爷爷说大概那是因为C的抽象程度碰巧既满足了程序员的要求, 又容易实现。当

       然C一度是Unix上的通用语言也是原因。但不管怎么说，D爷爷对编程语言出色的审美意

       识奠定了C广为流传的基础。

       最后八卦一下。D爷爷的业余爱好和NBA大牛Karl Malone一样：开卡车。不过D爷爷更喜

       欢开NASCAR，而KM独爱巨无霸。J D爷爷自称心中不供偶像，如果一定要说一个，那就

       是Ken Thompson了。现在Ken爷爷退休当飞机教练去了，而D爷爷当了贝尔实验室系统开

       发部的头，整日忙于开支票。他俩合作年，屡屡创造历史。这段令人神往的佳话，也

       就长留你我心中乐。

       P.S., 很多人都以为Brian W. Kernighan是C的作者。其实BWK只是写了那本经典K&R C。

       据D爷爷说，他，Ken, 和Kernighan三人中，Kernighan最能写文章，他次之，而Ken写

       得最少；但说到编程，Ken爷爷才是当之无愧的老大。

       Edsger Wybe Dijkstra, 对，就是E.W. Dijkstra. 一提到EWD，很多人就会想起找最短

       路径的Dijkstra Algorithm，就好像一提到Sir. Tony Hoare，就想起Quick Sort一样。

       其实这些个算法不过是两个牛人在他们职业生涯中最琐碎的贡献。比如Dijkstra算法，

       无非是戴爷爷在年为了展示新计算机

       ARMAC的计算能力，初试身手的成果，属于他的算法处女作。据戴爷爷自述，他搞出最

       短路径算法的时候连纸笔都没用。当时他和他老婆在阿姆斯特丹一家咖啡厅的阳台上晒

       太阳喝咖啡，突然就把这个算法想出来乐。而且当时的算法研究还比较原始，牛人们忙

       着用计算机搞数值计算，对离散算法不屑一顾。那时连一个象样的专注于离散算法的专

       业期刊都没有。戴爷爷于是推迟发表这个算法。直到年，他才把这个算法发表

       在Numerische Mathematik的创刊号上，权为捧场。:-)

       EWD在多个领域牛气冲天，端的是理论和编程两手硬的高手。只不过他的很多工作比较

       深刻，学校的老先生们觉得本科生接受不了，不给本科生讲而已。

       戴爷爷大概因为最短路径算法一战成名，于是有人请他参加另一台计算机X1的设计工

       作，并且把设计实时中断系统的任务派给了他。现在看来实时中断也许不算什么，但要

       知到，X1前根本就没有实时中断的概念。实现它简直就是一场豪赌。戴爷爷起初还不情

       愿，但经不住项目负责人Bram和Carel的轮番 “吹捧”：我们知道实时中断让您工作变

       得非常困难，但象您这样的牛人肯定能做出来的说。结果戴爷爷被糖衣炮弹彻底击穿，

       接下了这个烫手山芋。两三年后，他不仅搞出了实时中断，还围绕这个写出了自己的博

       士论文，顺利戴上博士帽。

       让戴爷爷真正成名立万的还是在X1上开发的Algo，最早的高级语言之一。戴爷爷没日

       没夜地工作了8个月，就搞出了Algo，也因此获得了 年的图灵奖。因为Algo，

       戴爷爷发表了一篇石破天惊的文章：Recursive

       Programming，于是人们才知道，原来高级语言也可以高效地实现递归，原来从此以后，

       所有程序员都不可避免地和戴爷爷发明的一个词(应该说是概念)打交道：堆栈。

       而且Algo还让戴爷爷深入地思考多道程序设计的问题，最终发明了每个系统程序员

       都绕不开的概念：semaphore。当然，戴爷爷总是把他发明的概念严格形式化，极具科

       学家本色的说。和这些成就想比，他提出的吃饭的哲学家问题，也就没什么好说的了。

       说来好笑，当时的大学(忘了哪所了)还是觉得戴爷爷没有受过正统的数学训练，也不是

       专门搞数值分析的，所以最后不太情愿地给了他一个教职。这种小挫折并不能妨碍象戴

       爷爷这样的牛人创造历史。他一边教数值分析(:-D) ，一边开始开发一个新的操作系

       统，并培养计算机科学家。几年后，THE Multiprogramming

       System横空出世。THE是第一个支持松散耦合，显式同步的进程并由此使得严格证明系统

       没有死锁变得容易的操作系统。可惜戴爷爷任职的系不识货，还强行解散了他的研究小

       组(年戴爷爷给他的系主任说他得了图灵奖，系主任的第一反应是你们搞计算机就

       喜欢乱发奖)。这让戴爷爷相当郁闷，得了抑郁症。在极度郁闷之中，戴爷爷决定用写作

       来治疗自己的抑郁症。于是经典就诞生乐：Notes on Structured Programming。戴爷爷

       从此被尊为结构化编程的奠基人，而且他的抑郁症也被治好乐。

       EWD太牛，结果他的故事也太多。先到这里吧。起，他的故事就在美国发生了。

       Anders Hejlsberg，微软.NET的首席架构师，编程语言设计和实现的顶尖高手。他一手

       做出了 Turbo Pascal, 也是Delphi, J++(尤其是WFC)，C#, 和.NET的主要作者。这些作

       品的名字足以为他立传。作为一个程序员，我在这样的大师面前实在无语。生子当

       如Anders的说。李维的<>里已详细讲述了Anders的传奇故事，我就不用费舌了：

       /iexploiter/posts/.aspx

       Artima上有Anders谈C#的系列访谈。MSDN上有一段Anders导游的录像 。有兴趣可以去看

       看牛人的丰采。

什么是统一建模语言？

       统一建模语言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）表现实现方面的问题，包括源代码结构和运行时的实现结构.实现图分为两种，一种是表示代码自身结构的成分图，另一种是表示运行时系统结构的展开图.

StarUML画时序图

       星形UML工具因其对分析软件调用关系的强大支持，尤其适合用于源码的深入剖析。

       首先，打开星形UML，开始创建时序图的过程。

       在画图阶段，分为以下几个步骤：

       新建用户图标，它代表系统中的参与者或行为者，如客户端或服务器。

       接着，创建几个生命线（Lifeline），每个生命线代表系统中的实体或对象，可以是线程、进程或对象实例。

       然后，通过连接关系来展示事件或消息的流动，包括发送者和接收者之间的交互。这有助于理解数据和控制流。

       最后，添加图例，清晰标注各个元素的含义，使图示更具可读性和理解性。

       通过这样的步骤，星形UML的时序图能够有效地呈现和分析项目的调用逻辑。