每日一得

key words:軟件設計 建模 UML

這篇文章以前就看到了，后來再想看的時候居然找不到了，感覺寫的不錯，作為想把軟件開發往深里整地朋友有借鑒作用。

轉自這里

前段時間把一個界面框架完成了，今天基于這個框架開發一個小模塊，在這里把這個模塊設計的全過程記錄下來，希望大家討論并指正。

一、起因

公 司交給我一個任務，為測試員寫一個手機模擬界面，以方便她們的手機短信測試。過去她們都是用MC4J直接調用公司服務器的MBean服務來模擬進行測試， 以驗證我們整個系統平臺。這種測試主要是檢查收發短信是否正常，而我的要做的工作就是，讓她們在測試的時候更方便更直觀。

二、需求

我和測試員陳MM（也就是軟件的使用者）約定了一個時間，大家一起來討論這個軟件的需求。

1、首先，我大概了解了一下她們的測試工作，知道我要做個什么東東。

2、然后我回去思考了一下，再次找她詳細了解其測試的具體步驟，并在一張白紙上以UML用例圖的方式，記錄下需求的功能。用例是什么？用例就是需求，就是你的軟件應該具有的功能，當然用例圖只是概括性的對功能進行了描述。

3、最后，我坐在我的電腦前開始用MagicDraw UML來畫用例圖（我不喜歡用Rose，那玩意太笨重了，界面友好性也不好）。在畫用例圖的時候，我發現了一些隱含的功能，這些是陳MM在和我做需求時沒有考慮到的（注：開發者應該為用戶挖掘隱含需求）。我和陳MM一一確定了這些我新發現的需求，最后得到如下的用例圖。

（1）手機前臺測試操作的用例圖（說明：include是指某用例包含(include)子用例）


?（2）后臺管理



三、界面設計

接下來是界面設計。既然是手機模擬，我很自然就拿我的motorola手機的操作界面來做參考。不過這里應該注意到，手機操作環境和電腦操作環境不盡相同（比如說電腦有鼠標，還有鍵盤可以輸入文字），所以沒有必要唯妙唯肖的完全模枋，還是以使用者操作方便為主。

界 面設計是很重要的一步，不要一上來就寫程序，一定要先做到心中有個大概，否則返工的可能性就很大。而且，把界面拿出來給客戶看，客戶也就能做到心中有數， 還能盡早提出一些新需求和意見來。千萬不要等到軟件做完了再拿給客戶看，到時客戶看了如果要修改，那就做太多白費工了。

由于軟件界面相對簡單，陳ＭＭ基本沒有提修改意見，但這不是個好兆頭。不過極限編程就是要擁抱變化不是^_^。咱不怕她改，只要大致的界面她能定下來就行了。

界面我喜歡用Visio來畫，當然也聽說有人喜歡用ＶＢ來快速構建界面原型的，看個人喜好了。整個界面如下：




這個是后臺管理界面




四、類圖

類圖反映了軟件的數據模型。在設計數據模型，我參考了界面設計圖和用例圖，找出一個個的類。然后參照用例圖的一個個功能，設計出了各類的屬性和方法。設計初始的類圖當然不可能很詳細，但至少應該看到個大概。有錯誤不要緊，后期可以慢慢修正，但大體關系就算定下來了。

Neil（公司ＣＴＯ，一個40歲左右的真正的資深程序員）說：看一個軟件的設計主要看兩個類：類圖和時序圖。類圖確定了軟件數據模型的靜態關型，時序圖則是數據模型的動態關系。

類圖如下，看英文大致可以知道類／屬性／方法的含義和作用了，就不一一介紹了。






五、時序圖

時序圖是本文最后一個圖，時序圖表明了用例圖中各功能的實現方案，同時也反應了類圖中各類的交互關系。以后程序的邏輯和時序圖基本一致。不過，有些人會去畫得很詳細的時序圖，詳細到都快趕上偽代碼級別了，我覺得這沒必要。我把時序圖看做反映自己思路的大概過程，所以也就畫個大概。

我認為時序圖要簡潔易懂，這樣以后你的后繼維護者，拿到這個軟件的時序圖（當然也包括用例圖、類圖），就能明白你的大概設計思路。另外，畫時序圖也能整理自己的思路，同時還可以對類圖的設計進行驗證。在畫這個時序圖的過程中，我就糾正了在類圖中的幾處考慮不周的地方。

總結：時序圖可以（１）整理思路（２）驗證類的設計（３）是很好的軟件文檔，對維護者理解代碼很有幫助。

這里僅給出其中幾個時序圖（實際上我也沒有把用例都畫完，有些類似的簡單的，就忽略了）

（１）新增一個手機號碼


（２）關機

（３）開機

（４）發送短信




到這里設計階段就完成了，用時一天。下一步是編碼，將應用ＴＤＤ先寫測試代碼的方式來寫代碼，下次再介紹了。

作者簡介

陳剛，廣西桂林人，著作有《Eclipse從入門到精通》
您可以通過其博客了解更多信息和文章：http://www.ChenGang.com.cn
版權聲明：本博客所有文章僅適用于非商業性轉載，并請在轉載時注明出處及作者的署名。