程序員眼中的UML(3)

--類圖，就是比你高一點(diǎn)

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

亂談?lì)悎D

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

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

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

類圖難點(diǎn)問題總結(jié)

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

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

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

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

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

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

后記

周末了，想偷懶了，結(jié)果適得其反，剛剛完成這篇blog就停電了，后面的幾百字全沒了。這一點(diǎn)告訴我們，持久化存儲(chǔ)是多么重要啊～