程序員眼中的UML(2)

--克服用例圖的恐懼

在實際工作中，大部分程序員很少接觸到需求分析，即使有需求分析，也是草草了事，沒有用正規的方式來表達，所以一般程序員使用用例圖的機會是不多的。但是卻又常常在各種媒體上看見用例圖，于是對一種常常出現，自己又不太熟悉的技術，會產生恐懼。如果說對MDA或者CORBA這樣的技術產生恐懼還是值得的話，對用例圖產生恐懼是非常不值的。因為MDA和CORBA這樣的技術也許要花上半年的時間才能夠初步了解，而克服用例圖恐懼癥，則只要不到一天的時間。

用例圖初感

UML是一組圖示符號的標準。所謂圖示符號，就是一組定義好的圖示，它們可以表達定義好的各種意思。用UML進行軟件建模，就是用規定好的符號畫圖，這些圖表達了開發人員腦中的軟件系統。用UML進行軟件建模，其難度并不比我們小時候上的美術課更難。在美術課上，一個圓形加上四根線條表示太陽，一個三角形加上一個矩形表示房子；同理，在UML的用例圖中，一個橢圓表示用例，一個小人表示參與者。我并不認為它們之間有質的區別，想到我對這種小學生畫圖課恐懼了幾年，不由得感到羞愧。

用例圖是UML的九個圖中較為重要和常用的一種圖。常常用于軟件開發的需求分析階段，也能用于軟件的系統測試階段。簡單的來說，用例圖是描述系統的外部視圖。

在開始設計一個軟件系統時（更廣義的情況下，可以用來設計任何系統），需要一種手段來發現系統的功能，用例圖雖然是圖示，但是這些圖示隱含了一種啟發系統功能的手段。其實所有的UML圖都只包含圖示和標準，并不包含方法，但是它們往往隱含了某種方法。UML和軟件開發方法的關系，很類似于漢字和語文的關系。

用例圖包含了三種基本的概念：用例、角色和系統。它們可以組合起來表達系統的外部視圖。而且這種表達方式是如此直觀和簡單。

第一張用例圖

畫用例圖是一件很簡單的事情，而且感覺還很舒適，因為用例圖簡潔、直觀。雖然用例圖不能像HelloWorld一樣運行，也不能生成代碼，不過畫一張清晰的用例圖還是很有成就感的。

我使用的工具是Eclipse+EclipseUML插件，功能不如Rose，但是是開源而且免費的（EclipseUML有free版也有企業版），而且效果也不錯。第一張用例圖如下：

可以看出圖中有一個系統（保險商務系統），兩個角色（客戶和保險銷售員）以及三個用例（簽訂保險單、銷售統計資料、客戶數據資料），另外還有四個連接線以及一個注釋。如果在紙上或者合適的工具中，畫這樣一張用例大概只需要五分鐘吧。不過僅僅畫出來是沒有意義的，需要弄清楚其背后真正的含義才行。

理解用例圖

可以這樣簡單的理解用例圖中的一些概念，系統（System）指的是軟件系統，它可以包含一些用例，并界定系統的邊界，邊界之內的屬于系統的功能和行為，邊界之外的則不是系統所關心的內容。系統規定了一個具有某些功能的黑盒子，在系統之外看到的僅僅是這個系統的功能，而不能看到系統的內部細節。這一點也是用例圖經常被用來做系統測試的原因。當然這些測試一般是黑盒測試。

角色（Actor）是與系統中的用例交互的一些實體，在實際情況中，角色可以是人，也可以是其他系統或者硬件設備。在畫用例圖的過程中，角色往往是第一個被確定的，因為系統或者用例在開始時是模糊的，但是參與系統的角色是最容易明晰的。有了角色之后，根據角色與系統的交互，以及角色要求的功能，可以進一步確定系統和用例。

用例（Use case）指的是系統的功能，它是系統某個功能的所有執行動作的集合。在UML圖示中它是一個橢圓，但是具體分析用例的時候需要給出這個用例的所有執行動作的步驟。例如上圖中的“簽訂保險單”用例，就可以分為幾個步驟：第一，客戶發出保險單請求；第二，系統給出保險單樣式表；第三，用戶填寫保險單樣式表；第四，系統檢查用戶提交的保險單格式是否規范；第五，如果不規范則返回第二步，如果規范則給保險單銷售員發出消息；第六，保險單銷售員填寫保險單；第七，保險單銷售員將填寫好的保險單加入數據庫，并將客戶資料輸入客戶數據庫。當然，以上步驟僅僅是我想象的，我還從來沒有見過什么“保險單”，這次過了一把癮。

連接（Assocation）是角色與用例的連接，表達此角色可以初始化此用例。 

注釋（Note）可以添加到任何地方，對用例圖的不同部分加以說明。

泛化、包含和擴展

泛化（Generalization）在面向對象的技術中無處不在，它的另一個名字也許更為著名，就是“繼承”。下圖給出了一個使用泛化的用例圖：

由此可知，在用例圖中，角色和用例都能夠泛化。角色的泛化/繼承很容易理解，因為角色本來就是類（Class），它是一種版型（stereotype）為Actor的類，所以角色的繼承直觀而自然。但是用例的繼承實際上分為兩種情況，并不是簡單的使用泛化，而是使用擴展（extended）和包含（include）兩種泛化的特例。

擴展用于子用例的動作步驟基本上和父用例的動作步驟相同，只是增加了另外的一些步驟的情況下。包含用于子用例包含了所有父用例的動作，它將父用例作為了自己的一個大步驟，子用例常常包含一個以上的父用例。如下圖：

小結

關于用例圖基本上也就是上面提到的這些內容了。當然，用例圖還常常和類圖、活動圖聯合使用，不過那些知識還是等其他知識完備了以后再說比較好。

我總結的畫用例圖的步驟如下：

l         確定系統，擬出系統的名稱，這個不難，例如電信計費系統；

l         找出所有與系統打交道的角色，角色要進行一些精簡和整合；

l         站在角色的立場想象系統應該提供的功能，將這些功能畫成系統中的用例；

l         對于每個用例給出詳細的動作步驟；

l         找出用例圖中角色、用例之間可能有的繼承、擴展或者是包含關系；

以我現在的理解能力，認為用例圖到此為止了。當然，我還可以想象，用例圖會用來啟發類圖的構建，例如用例圖中的某些部分（角色或者用例）會變成類圖中的類或者接口。另外，可以想象用例圖還可能會影響活動圖中的流程。

后記

讓我恐懼了好久的用例圖在今天便土崩瓦解了，心中卻彷佛有一點茫然，因為我記得自己無數次的對自己說“好忙啊，這個技術肯定要花很多時間，還是以后再學吧”類似的話。當我用C的時候對C++這樣說過，然后是Java、CORBA、JSP、XML、MDA、XMI、UML……

寫blog不僅僅是一種愛好，對我來說，更是一種最好的學習方法，當我讀小學的時候，班主任常常對我說“好記性不如爛筆頭”，我當時的理解是把事情用筆記下來比用腦袋背下來更加持久（腦袋是內存？紙筆是數據庫？）。但是，現在我理解到，要學習某個東西，最好的方法是用自己的語言把它表達出來，如果你能讓別人理解這個技術，你自己當然已經精通了。在我寫blog的過程中，常常會出現寫到一半的時候猛然領悟的情況，這是因為當你在選擇最佳的表達方式的時候，將你自己頭腦中一團亂麻的線索都理清了的結果。

有朋友留言說，自己計算機本科畢業，在計算機領域學習了八年，竟然看不懂我的blog。這個我認為很正常，讀本科的時候，所有同學都可以在一起討論問題、實習；等到上研的時候，同學對我說他的課題，我只能模糊的聽個大概，因為專業方向已經分開了；現在讀博了，同學要拉著我說他的課題，我只能明白是哪個領域里面的問題，往往對這個問題的描述都聽不懂了。這是因為研究方向已經非常精細的原因。我自問我的方向已經很大眾化了，如果研究圖像壓縮算法的話，那滿篇都是數學公式了；如果研究微電子技術，那么滿篇都是集成電路圖了。

還有一點，如果我感興趣的技術在網上已經能夠找到很好的資源，那么我不會動筆去寫blog了，我會把資料下載到硬盤就好了。例如XML技術，我的blog中只有兩篇，第一篇是“XML的本質討論”，總結出了別人看不到的XML本質，提出了一些新觀點；第二篇是“XSL：轉換從哪里開始”。其實XML技術淺顯易懂，我也有很多感想和心得，不過其中只有XSL在網上不能找到很好的總結資料，因此我寫了那一篇。這也是我堅持原創和創新的一點反映吧。對于那種狂貼別人資料的blog，我是不以為然的。我只喜歡原創或者第一手翻譯資料的blog。