UML的成功80％是因?yàn)轭悎D，提到UML的時(shí)候有90％的人想到了類圖，應(yīng)用UML的時(shí)候100％應(yīng)用了類圖。如果類圖和源代碼走到一起，肯定是要代碼抗釘耙的，因?yàn)檎撐涔椭腔?，類圖都高了那么一點(diǎn)點(diǎn)。

如果說(shuō)程序是一個(gè)人，那么類圖就是這個(gè)人的軀體。也就是說(shuō)，光有類圖，一個(gè)程序已經(jīng)成型了，看上去很像那么一回事了。UML在刻畫(huà)程序的靜態(tài)結(jié)構(gòu)方面很成功，但是在刻畫(huà)程序的動(dòng)態(tài)語(yǔ)義時(shí)很失敗，至今沒(méi)有一個(gè)好的解決方案，或者說(shuō)，沒(méi)有一個(gè)能讓各方面都接受的方案。如果UML動(dòng)態(tài)語(yǔ)義的問(wèn)題解決了，那么MDA的目標(biāo)就真的達(dá)到了，模型可以完全代替代碼了。

目前的MDA工具，號(hào)稱模型代碼同步的，號(hào)稱代碼生成的，號(hào)稱PIM/PSM轉(zhuǎn)換的，大部分都只是和類圖打交道罷了。因?yàn)轭悎D和代碼之間的轉(zhuǎn)換是如此自然，以至于出現(xiàn)了Together這樣的工具，模型（類圖而已）和代碼是同步的。

類圖是程序的軀體，動(dòng)作語(yǔ)義才是程序的靈魂，可惜UML在刻畫(huà)程序靈魂的事情上做得太不出色了。很多研究者僅僅把目光放在類圖上，類圖到代碼的生成幾乎已經(jīng)沒(méi)有什么可以研究了，還是抱住不放，在生成的代碼中加入約束、加入設(shè)計(jì)模式、加入持久化存儲(chǔ)等等。怒其不爭(zhēng)、哀其無(wú)志。想到自己也是其中的一員，不由臨表涕零。

類圖是非常容易學(xué)習(xí)的，因?yàn)樗兔嫦驅(qū)ο缶幊淌菍\生兄弟，如今的程序員哪有不懂面向?qū)ο蟮模虼祟悎D對(duì)于他們，就如同奶瓶對(duì)于嬰兒一般。下面從硬盤(pán)中翻出一幅曾經(jīng)自己畫(huà)的類圖，相信大家一看便知：

類圖是一門(mén)易學(xué)難精的技術(shù)，正如面向?qū)ο蠹夹g(shù)一樣，一百個(gè)程序員九十九個(gè)都說(shuō)自己懂面向?qū)ο?，但是真正入門(mén)的可能不到十個(gè)，真正精通的也許只有一個(gè)，這個(gè)人還往往不是中國(guó)人，唉～

自己重新學(xué)習(xí)UML的動(dòng)機(jī)就來(lái)自于一次論文撰寫(xiě)過(guò)程中，想查閱類圖的元模型圖，但是問(wèn)遍同行，翻遍網(wǎng)絡(luò)，找不到合適的圖形或者描述，最后只能求救于OMG的UML規(guī)范。一查之下，大驚失色，原來(lái)很多東西原來(lái)都是懵懵懂懂，不甚了了。因此痛下決心，要弄懂類圖中的疑點(diǎn)。

翻看類圖，我發(fā)現(xiàn)有如下是疑點(diǎn)所在：

l         Attribute和Property的關(guān)系如何？區(qū)別和共同點(diǎn)是什么？

l         完整的描述一個(gè)操作（Operation），需要多少東西？

l         類之間可以有關(guān)系（Relationship），關(guān)系可以是關(guān)聯(lián)（Association）或者泛化（Generalization），這個(gè)你知道么？

l         關(guān)聯(lián)有七種：普通關(guān)聯(lián)、遞歸關(guān)聯(lián)、限定關(guān)聯(lián)、或關(guān)聯(lián)、有序關(guān)聯(lián)、三元關(guān)聯(lián)、聚合（聚合和組合），各自有什么含義？用法如何？

l         關(guān)聯(lián)類（Association Class）的含義如何？應(yīng)用場(chǎng)景如何？

l         類的實(shí)例化是對(duì)象，關(guān)聯(lián)的實(shí)例化是什么呢？

總結(jié)出了這些疑點(diǎn)要?dú)w功于中文UML書(shū)籍的模糊和混亂，或者是翻譯者的語(yǔ)焉不詳。所以讓我在復(fù)習(xí)時(shí)找出了這么多的疑點(diǎn)。

要查閱資料，解決疑難，并舉例說(shuō)明，起碼需要3，4天的時(shí)間，因此這篇隨筆就作為類圖的引文先發(fā)了。也希望志同道合者和我一起研究上面的問(wèn)題。