1、基于UML的軟件設計全過程統一建模語言（UML是 Unified Modeling Language的縮寫）是用來對軟件密集系統進行可視化建模的一種語言。UML為面向對象開發系統的產品進行說明、可視化、和編制文檔的一種標準語言。本文將要介紹一個基于UML的軟件設計全過程，希望能對你有所幫助。    前段時間把一個界面框架完成了，今天基于這個框架開發一個小模塊，在這里把這個模塊設計的全過程記錄下來，希望大家討論并指正。    起因    公司交給我一個任務，為測試員寫一個手機模擬界面，以方便她們的手機短信測

2、試。過去她們都是用MC4J直接調用公司服務器的MBean服務來模擬進行測試，以驗證我們整個系統平臺。這種測試主要是檢查收發短信是否正常，而我的要做的工作就是，讓她們在測試的時候更方便更直觀。    需求    我和測試員陳MM（也就是軟件的使用者）約定了一個時間，大家一起來討論這個軟件的需求。    1. 首先，我大概了解了一下她們的測試工作，知道我要做個什么東東。    2. 然后我回去思考了一下，再次找她詳細了解其測試的具體步驟，并在一張白紙上以UML用例圖的方式，記錄下

3、需求的功能。用例是什么？用例就是需求，就是你的軟件應該具有的功能，當然用例圖只是概括性的對功能進行了描述。    3. 最后，我坐在我的電腦前開始用MagicDraw UML來畫用例圖（我不喜歡用Rose，那玩意太笨重了，界面友好性也不好）。在畫用例圖的時候，我發現了一些隱含的功能，這些是陳MM在和我做需求時沒有考慮到的（注：開發者應該為用戶挖掘隱含需求）。我和陳MM一一確定了這些我新發現的需求，最后得到如下的用例圖。    a. 手機前臺測試操作的用例圖    b. 后臺管理   界

4、面設計    接下來是界面設計。既然是手機模擬，我很自然就拿我的motorola手機的操作界面來做參考。不過這里應該注意到，手機操作環境和電腦操作環境不盡相同（比如說電腦有鼠標，還有鍵盤可以輸入文字），所以沒有必要唯妙唯肖的完全模枋，還是以使用者操作方便為主。    界面設計是很重要的一步，不要一上來就寫程序，一定要先做到心中有個大概，否則返工的可能性就很大。而且，把界面拿出來給客戶看，客戶也就能做到心中有數，還能盡早提出一些新需求和意見來。千萬不要等到軟件做完了再拿給客戶看，到時客戶看了如果要修改，那就做太多白費工了。 &

5、#160;  由于軟件界面相對簡單，陳基本沒有提修改意見，但這不是個好兆頭。不過極限編程就是要擁抱變化不是_。咱不怕她改，只要大致的界面她能定下來就行了。    界面我喜歡用Visio來畫，當然也聽說有人喜歡用來快速構建界面原型的，看個人喜好了。整個界面如下：這個是后臺管理界面    類圖    類圖反映了軟件的數據模型。在設計數據模型，我參考了界面設計圖和用例圖，找出一個個的類。然后參照用例圖的一個個功能，設計出了各類的屬性和方法。設計初始的類圖當然不可能很詳細，但至少應該看到個大概。有錯誤不

6、要緊，后期可以慢慢修正，但大體關系就算定下來了。    Neil（公司，一個40歲左右的真正的資深程序員）說：看一個軟件的設計主要看兩個類：類圖和時序圖。類圖確定了軟件數據模型的靜態關型，時序圖則是數據模型的動態關系。    類圖如下，看英文大致可以知道類屬性方法的含義和作用了，就不一一介紹了。    時序圖    時序圖是本文最后一個圖，時序圖表明了用例圖中各功能的實現方案，同時也反應了類圖中各類的交互關系。以后程序的邏輯和時序圖基本一致。不過，有些人會去畫得很詳細的時序圖

7、，詳細到都快趕上偽代碼級別了，我覺得這沒必要。我把時序圖看做反映自己思路的大概過程，所以也就畫個大概。    我認為時序圖要簡潔易懂，這樣以后你的后繼維護者，拿到這個軟件的時序圖（當然也包括用例圖、類圖），就能明白你的大概設計思路。另外，畫時序圖也能整理自己的思路，同時還可以對類圖的設計進行驗證。在畫這個時序圖的過程中，我就糾正了在類圖中的幾處考慮不周的地方。    總結：時序圖可以（）整理思路（）驗證類的設計（）是很好的軟件文檔，對維護者理解代碼很有幫助。    這里僅給出其中幾個時序圖（實際上我也沒有把用例都畫完，有些類似的簡單的，就忽略了）    a. 新增一個手機號碼