UML的成功80％是因為類圖，提到UML的時候有90％的人想到了類圖，應(yīng)用UML的時候100％應(yīng)用了類圖。如果類圖和源代碼走到一起，肯定是要代碼抗釘耙的，因為論武功和智慧，類圖都高了那么一點點。
亂談類圖
如果說程序是一個人，那么類圖就是這個人的軀體。也就是說，光有類圖，一個程序已經(jīng)成型了，看上去很像那么一回事了。UML在刻畫程序的靜態(tài)結(jié)構(gòu)方面很成功，但是在刻畫程序的動態(tài)語義時很失敗，至今沒有一個好的解決方案，或者說，沒有一個能讓各方面都接受的方案。如果UML動態(tài)語義的問題解決了，那么MDA的目標(biāo)就真的達到了，模型可以完全代替代碼了。
目前的MDA工具，號稱模型代碼同步的，號稱代碼生成的，號稱PIM/PSM轉(zhuǎn)換的，大部分都只是和類圖打交道罷了。因為類圖和代碼之間的轉(zhuǎn)換是如此自然，以至于出現(xiàn)了Together這樣的工具，模型（類圖而已）和代碼是同步的。
類圖是程序的軀體，動作語義才是程序的靈魂，可惜UML在刻畫程序靈魂的事情上做得太不出色了。很多研究者僅僅把目光放在類圖上，類圖到代碼的生成幾乎已經(jīng)沒有什么可以研究了，還是抱住不放，在生成的代碼中加入約束、加入設(shè)計模式、加入持久化存儲等等。怒其不爭、哀其無志。想到自己也是其中的一員，不由臨表涕零。
類圖難點問題總結(jié)
類圖是非常容易學(xué)習(xí)的，因為它和面向?qū)ο缶幊淌菍\生兄弟，如今的程序員哪有不懂面向?qū)ο蟮模虼祟悎D對于他們，就如同奶瓶對于嬰兒一般。下面從硬盤中翻出一幅曾經(jīng)自己畫的類圖，相信大家一看便知：
類圖是一門易學(xué)難精的技術(shù)，正如面向?qū)ο蠹夹g(shù)一樣，一百個程序員九十九個都說自己懂面向?qū)ο螅钦嬲腴T的可能不到十個，真正精通的也許只有一個，這個人還往往不是中國人，唉～
自己重新學(xué)習(xí)UML的動機就來自于一次論文撰寫過程中，想查閱類圖的元模型圖，但是問遍同行，翻遍網(wǎng)絡(luò)，找不到合適的圖形或者描述，最后只能求救于OMG的UML規(guī)范。一查之下，大驚失色，原來很多東西原來都是懵懵懂懂，不甚了了。因此痛下決心，要弄懂類圖中的疑點。
翻看類圖，我發(fā)現(xiàn)有如下是疑點所在：
l Attribute和Property的關(guān)系如何？區(qū)別和共同點是什么？
l 完整的描述一個操作（Operation），需要多少東西？
l 類之間可以有關(guān)系（Relationship），關(guān)系可以是關(guān)聯(lián)（Association）或者泛化（Generalization），這個你知道么？
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)用場景如何？
l 類的實例化是對象，關(guān)聯(lián)的實例化是什么呢？
總結(jié)出了這些疑點要歸功于中文UML書籍的模糊和混亂，或者是翻譯者的語焉不詳。所以讓我在復(fù)習(xí)時找出了這么多的疑點。
要查閱資料，解決疑難，并舉例說明，起碼需要3，4天的時間，因此這篇隨筆就作為類圖的引文先發(fā)了。也希望志同道合者和我一起研究上面的問題。