基于UML的軟件設計全過程
前段時間把一個界面框架完成了，今天基于這個框架開發一個小模塊，在這里把這個模塊設計的全過程記錄下來，希望大家討論并指正。
起因
公司交給我一個任務，為測試員寫一個手機模擬界面，以方便她們的手機短信測試。過去她們都是用MC4J直接調用公司服務器的MBean服務來模擬進行測試，以驗證我們整個系統平臺。這種測試主要是檢查收發短信是否正常，而我的要做的工作就是，讓她們在測試的時候更方便更直觀。
需求
我和測試員陳MM（也就是軟件的使用者）約定了一個時間，大家一起來討論這個軟件的需求。
1. 首先，我大概了解了一下她們的測試工作，知道我要做個什么東東。
2. 然后我回去思考了一下，再次找她詳細了解其測試的具體步驟，并在一張白紙上以UML用例圖的方式，記錄下需求的功能。用例是什么？用例就是需求，就是你的軟件應該具有的功能，當然用例圖只是概括性的對功能進行了描述。
3. 最后，我坐在我的電腦前開始用MagicDraw UML來畫用例圖（我不喜歡用Rose，那玩意太笨重了，界面友好性也不好）。在畫用例圖的時候，我發現了一些隱含的功能，這些是陳MM在和我做需求時沒有考慮到的（注：開發者應該為用戶挖掘隱含需求）。我和陳MM一一確定了這些我新發現的需求，最后得到如下的用例圖。
a. 手機前臺測試操作的用例圖
b. 后臺管理
#p#
界面設計
接下來是界面設計。既然是手機模擬，我很自然就拿我的motorola手機的操作界面來做參考。不過這里應該注意到，手機操作環境和電腦操作環境不盡相同（比如說電腦有鼠標，還有鍵盤可以輸入文字），所以沒有必要唯妙唯肖的完全模枋，還是以使用者操作方便為主。
界面設計是很重要的一步，不要一上來就寫程序，一定要先做到心中有個大概，否則返工的可能性就很大。而且，把界面拿出來給客戶看，客戶也就能做到心中有數，還能盡早提出一些新需求和意見來。千萬不要等到軟件做完了再拿給客戶看，到時客戶看了如果要修改，那就做太多白費工了。
由于軟件界面相對簡單，陳ＭＭ基本沒有提修改意見，但這不是個好兆頭。不過極限編程就是要擁抱變化不是^_^。咱不怕她改，只要大致的界面她能定下來就行了。
界面我喜歡用Visio來畫，當然也聽說有人喜歡用ＶＢ來快速構建界面原型的，看個人喜好了。整個界面如下：
這個是后臺管理界面
類圖
類圖反映了軟件的數據模型。在設計數據模型，我參考了界面設計圖和用例圖，找出一個個的類。然后參照用例圖的一個個功能，設計出了各類的屬性和方法。設計初始的類圖當然不可能很詳細，但至少應該看到個大概。有錯誤不要緊，后期可以慢慢修正，但大體關系就算定下來了。
Neil（公司ＣＴＯ，一個40歲左右的真正的資深程序員）說：看一個軟件的設計主要看兩個類：類圖和時序圖。類圖確定了軟件數據模型的靜態關型，時序圖則是數據模型的動態關系。
類圖如下，看英文大致可以知道類／屬性／方法的含義和作用了，就不一一介紹了。
#p#
時序圖
時序圖是本文最后一個圖，時序圖表明了用例圖中各功能的實現方案，同時也反應了類圖中各類的交互關系。以后程序的邏輯和時序圖基本一致。不過，有些人會去畫得很詳細的時序圖，詳細到都快趕上偽代碼級別了，我覺得這沒必要。我把時序圖看做反映自己思路的大概過程，所以也就畫個大概。
我認為時序圖要簡潔易懂，這樣以后你的后繼維護者，拿到這個軟件的時序圖（當然也包括用例圖、類圖），就能明白你的大概設計思路。另外，畫時序圖也能整理自己的思路，同時還可以對類圖的設計進行驗證。在畫這個時序圖的過程中，我就糾正了在類圖中的幾處考慮不周的地方。
總結：時序圖可以（１）整理思路（２）驗證類的設計（３）是很好的軟件文檔，對維護者理解代碼很有幫助。
這里僅給出其中幾個時序圖（實際上我也沒有把用例都畫完，有些類似的簡單的，就忽略了）
a. 新增一個手機號碼
b. 關機
c. 開機
d. 發送短信
到這里設計階段就完成了，用時一天。下一步是編碼，將應用ＴＤＤ先寫測試代碼的方式來寫代碼，下次再介紹了。
【編輯推薦】
