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