在軟件工程的全部實施過程中都採用模型的方式而非文字的表達方式來進行描述，這樣的實現過程稱之爲全程建模。全 程建模的特點是：模型相互之間是有關聯的，模型成爲軟件工程過程各階段展現的主體而不是文字描述作爲主體存在。通過建模的方式將原來純文字加圖形描述的各 種文檔模型化，使得從需求到代碼能夠統一起來，實現需求的變動直接影響到代碼的變化。提高代碼對需求的有效性聯繫，同時，解決過去經常出現的：編碼改動， 文檔就失效的問題。
軟件建模方法有很多種，至今爲止最廣泛使用的是UML。UML是 Unified Modeling Language，統一建模語言，主要由Booch、Rumbaugh及Jacobson三人提出，他們三人把自己分 別提出的建模方法Booch、OMT、OOSE融合爲一種方法稱爲UML。Booch在 《The Unified Modeling Language User Guide》中對UML的定義是“UML是對軟件密集型系統中的製品進行可視 化、詳述、構造和文檔化的語言”。可以簡單的理解UML是軟件建模的一種語言，它的特色是使用圖形化的方法來進行軟件建模。UML的特點如下：統一的標 準，UML已經被OMG接受爲標準的建模語言，而且越來越多的開發人員使用ULM語言進行開發；UML是支持面向對象技術的建模語言；可視化、表示能力強 大；獨立於過程，UML不依賴於特定的軟件開發過程；概念明確，建模表示法簡潔，圖形結構清晰，容易掌握和使用。
UML能夠用來爲系統進 行面向對象建模，但是並沒有指定應用UML的過程，它僅僅是一種語言，它是獨立於任何過程的。如果想要成功的應用UML一個好的過程是必要的。合理的過程 能夠有效的測度工作進度，控制和改善工作效率。RUP是一個很好的軟件過程，它的核心就是解決可操作性的問題，可以幫助開發人員完成使用UML全程建模的 問題。RUP雖好，但是RUP十分龐大對於一些小的項目實施起來比較困難。所以有很多人一直在探討敏捷建模的方法。本人蔘考了RUP、青潤的《軟件工程
之 全程建模實現》及尤克濱的《UML應用建模實踐過程》並結合自己的工作經驗形成敏捷建模的過程，在此將它分享出來，希望對大家有所幫助，另外也希望大家多 提包括意見，讓我成長。這個過程應用在以前我參與的一個軟件項目開發過程中，爲了方便表達將該系統稱爲A系統。下面的內容包括5節：需求模型、分析模型、 設計模型、物理架構模型、代碼導出。由於內容太長將分幾次上傳。
1 需求模型
1.1 用例模型
1. 用例及用例圖
用 例是一個角色使用系統的某項功能時交互過程的文字描述。用例的本質是系統中各個相關人員之間就係統的行爲所達成的契約，是系統的功能性需求。用例從使用系 統的角度描述系統中的信息，即站在系統外部觀看系統的功能，而不考慮系統內部對該功能的具體實現方式。用例描述了用戶提出的一些可能需求，對應一個具體的 用戶目標，用例可以促進與用戶溝通、理解正確的需求，同時也可以用來劃分系統與外部實體的界限，是面向對象系統設計的起點，是類、對象、操作的來源。用例 圖主要用於描述擬建系統和外部環境的關係。用例圖中主要包括用例、角色及用例間的關係。用例間的關係通常有包含、範化、擴展。
如何實現用例模型呢？用例圖包括角色、系統邊界、用例以及元素間的關聯。首先識別出角色，根據角色再識別用例。建立用例模型的主要工作
：找出角色；找出用例；描述用例；用例間的關係處理；驗證模型，通過這樣的一些步驟就可以建立用例模型。
2. 識別角色
角色不僅僅是使用系統的用戶也可以是硬件、外部系統等等。角色應該和系統具有交互行爲，即角色向用例發送消息或者接收用例反饋的消息。角色之間存在繼承關係。通過回答以下6個問題來識別A系統的角色：
（1）誰使用系統的主要功能。
回答：質監人員。
（2）誰需要系統的支持以完成日常工作。
回答：質監人員。
（3）誰負責維護、管理並保持系統正常運行。
回答：質量監督結構的管理員。
（4）系統需要應付哪些設備。
回答：不需要。
（5）系統需要和哪些外部系統交互。
回答：無。
（6）誰或什麼對系統運行結果感興趣。
回答：質監人員。
綜上所述我們分析出來的A系統角色有質監人員、管理員。
3. 識別用例
識別用例時由於角色已經識別出來，所以我們主要根據角色來識別用例，識別用例的人爲因素很大，不同的人針對同一個需求識別出的用例不一定是相同的，用例識別和經驗關係很大。我們以角色“管理員”爲例，根據這個角色來識別相關的用例。
（1）某個角色要求系統爲其提供什麼功能？該角色需要做哪些工作？
回答：管理員登錄軟件以後主要進行用戶管理。另外系統的新建數據庫、連接數據庫這些工作也主要由管理員來做。
（2）角色需要閱讀、創建、銷燬、更新或存儲系統中某些信息嗎？
回答：管理員需要創建、刪除、修改用戶信息，進行用戶管理。
將這個角色涉及到的用例進行分析得到和這個角色相關的用例：管理用戶、選擇數據庫、建立數據庫、登錄。採用類似的方法還可以分析出系統的其他用例。
4. 用例圖
通過上面的分析我們獲得初步的用例圖。我們還需要對用例進行拆分或合併。根據以上分析的結果繪製該軟件的用例圖。軟件的用例圖如圖1所示。
圖1 用例圖
1.2 用例描述
用 例描述是通過文字語言描述用戶的實際需求，用例採用自然語言描述角色和系統進行交互時雙方的行爲，不追求形式化的語言。用例描述沒有一個統一的標準，但一 般應該包括以下的內容：用例的目的；用例是怎樣啓動的；角色和用例之間的消息是如何傳送的；用例中除了主要路徑外，其他路徑是什麼；用例結束後系統的狀 態；其他需要描述的內容。表1是一個用例描述的示例。
表1 “選擇建設項目”用例描述
用例名稱：
選擇建設項目
綜述：
所有建設項目的數據保存在同一個數據庫中，當用戶登錄後需要選擇某個建設項目或者新建建設項目。
前置條件：
登錄成功，打算對某個項目進行操作
後置條件：
進入軟件主界面
基本操作流：
1、 系統提供已有建設項目供用戶選擇。
2、 用戶從系統提供的項目列表中選中某個建設項目。
3、 系統對當前選中的建設項目進行標識，進入主界面。
可選操作流：
可選流1：
1、系統提供查詢條件，查詢條件包括公里等級、項目名稱。
2、用戶輸入查詢條件
3、系統提供滿足條件的項目，如果用戶沒有輸入系統提示，並不進行查詢操作。
4、 用戶選中建設項目。
5、 系統對當前選中的建設項目進行標識，進入主界面。
可選流2：
1、 用戶選擇建設項目的界面上提供新建建設項目功能。
2、 系統提供新建建設項目頁面
3、 用戶輸入建設項目信息
3、系統導航到新建建設項目界面
1.3界面建模
在 青潤的《軟件工程之全程建模實現》一文中提出將界面設計作爲需要分析階段的一項工作。我以前也曾在需求分析階段進行了界面建模，並用界面模型和用戶進行交 流，取得了良好的效果。界面建模是需求工作中重要的步驟，同時又屬於設計工作的內容，所有很多人在爭論界面建模應該在什麼時間開始。我很贊同做將界面建模 放在需求分析階段，一方面軟件界面的需求也是用戶需求的一部分，另一方面使用界面模型和用戶交流系統的功能需求直觀、明確，用戶很容易理解。界面就結合自 己以前開發的一個項目談談軟件界面建模的事情。
1、界面設計的基本要求
* 界面設計要完整的體現出用戶需求的表現形式。
* 界面設計要美觀大方，一般來說界面設計的結果要符合用戶羣的習慣、感官、感覺。
* 界面設計中的交互操作過程要符合用戶習慣性的工作過程。
2、界面建模的主要工作
首 先確定界面元素，通常一個軟件界面的元素包括界面主顏色、字體顏色、字體大小、界面佈局、界面交互方式、界面功能分佈、界面輸入輸出模式等等。對用戶工作 效率有明顯影響的元素包括：輸入輸出方式、交互方式、功能分佈。界面元素所要達到的設計目的是讓最終用戶能夠獲得美感、提高工作效率、易於操作使用系統。 本項目的這個部分的工作由界面設計人員和美工協同完成，並且以界面設計規範的形式確定下來。
再次要通過對軟件的背景，使用的行業特點、用 戶的使用水平、喜好等方面的瞭解提出針對用戶的一些設計。考慮到本系統的用戶爲公路行業，計算機應用水平比較低，所以很多部分力求簡潔、明瞭，儘量提供用 戶操作、使用上的方便，很多地方儘量模擬用戶的手工操作，符合他們的使用習慣。比如在功能佈局上以工作流的方式來進行功能佈局，這樣用戶很清楚做完了這個 工作下一步應該怎樣做。另外我們專門設計數據錄入界面完全和用戶實際工作中的表格相同。
最後建立用戶界面模型，並且同用戶進行交互。這個 工作對於界面建模是很重要的，因爲用戶對於功能的需求相對是比較明確的，對於界面方面的需求卻比較模糊，但是當一個系統展現在他們面前的時候，他們卻有很 多的要求和想法，通過這個工作可以將用戶對界面的需求挖掘出來，而且也比較容易暴露設計中的缺陷。我們在設計完界面模型之後請用戶參與了我們的評審會，之 後根據用戶的意見進行了界面模型的修改。
3、建模工具
我選擇Visio作爲界面建模工具。Visio是微軟的一個圖表繪 制軟件。Visio的模具中提供了Windows界面元素和各種標註元素，能夠使我們很方便地建立Windows用戶界面模型。另外，Visio還提供了 比較好的發佈功能允許我們將Visio文檔發佈爲網頁格式。由於UML對界面建模支持的不好，所以使用UML建模工具進行界面建模比較難。
4、界面模型示例
這 個系統使用Visio來表達界面元素的佈局、功能分佈、交互方式等，對於不能在該模型中表達的某些內容（比如字體的大小等）用界面設計規範來表達。我們使 用該模型在前期階段和用戶進行交流，幫助測試人員瞭解系統功能。在後期階段將界面層對業務層的調用疊加在界面模型中，也就是在界面模型上指明在什麼情況下 調用哪個對象的什麼方法來實現用戶的請求，從而指導開發人員構築系統。這樣做，在某些方面和UML的動態建模機制有異曲同工之妙，而且更加直觀有效。
2 分析模型
分析是一個十分關鍵的過程，它是把需求轉化爲代碼實現的中間階段。軟件分析是將自然語言表達的軟件需求進一步進行解析的過程。軟件設計就是從分析到軟件實現的過程。
2.1 架構設計
1. 分層架構
架 構設計決定了各子系統如何組織以及如何協調工作。架構設計的好壞影響到軟件的好壞，系統越大越是這樣。在分解複雜的軟件系統時，經常使用的一種架構技術就 是分層。分層架構中最困難的問題就是決定建立哪些層以及每層的職責。分層結構的好處主要有：不需要去了解層的實現細節；可以使用另一種技術來改變基礎的 層，而不會影響上層的應用；可以減少不同層之間的依賴；容易制定出層標準；底下的層可以用來建立頂上層的多項服務；分層有利於標準化工作的執行。分層只是 將系統各種邏輯進行更有效的組織。分層架構的缺陷也不容忽視，層次不能封裝所有東西，有時候會帶來級聯修改；過多的層間數據傳遞會影響性能。
2. 兩層結構與三層結構
在 分層結構中比較常用的有兩層結構和以三層結構爲代表的多層結構。基於二層架構的應用通常稱爲Client/Server應用。很多情況下服務器提供的服務 僅僅是數據庫服務。在這種模式中客戶端負責訪問數據，完成業務邏輯處理、接收用戶的輸入及將結果向用戶展示。二層體系結構的主要不利之處是其業務邏輯沒有 從表示邏輯中分離開來，程序員很難在二層結構的應用中清楚地將業務邏輯從表示邏輯中分割出來，這樣就很難維護、改進，可擴展性差，也很難重用。
三 層體系結構以傳統客戶服務器模式爲基礎，將客戶程序和數據庫服務器的功能進一步分解，客戶程序僅根據需要提出數據請求，數據庫服務器也僅負責與數據存儲、 完整性控制等有關的任務，而數據加工、處理等業務邏輯，交於另一個獨立的部分來完成，這樣不僅減輕了服務器的負擔，也使前臺客戶程序更加獨立，僅注重於與 操作人員的交互和數據的單一處理，形成了表示層、業務層、以及數據層三層結構，其中業務層也稱爲中間層，執行中間層任務的計算機稱爲應用程序服務器。
與 傳統的兩層結構相比，三層最大的特徵是將業務層獨立了出來，從而提高了業務層的可複用性。在兩層結構中，用戶界面和業務處理流程放在一起，因此無法直接復 用業務處理的相關功能，也無法將業務處理功能進行靈活的部署。在三層結構中，表示層只處理用戶界面相關的功能，主要處理用戶和軟件的交互，表示層主要有 Windows圖形界面和基於Web的界面，主要職責就是爲用戶提供信息，以及把用戶的指令傳送給業務層。業務層複雜處理業務流程，是三層結構中最重要的 一層，可以對業務層進行靈活的部署，開發時也便於業務處理的開發和用戶界面的開發同時進行。針對於信息系，數據層的最大的邏輯就是存儲持久數據。
三 層結構的優點如下：減少客戶機的維護量，因爲前臺程序比較簡單；把企業邏輯封裝在通用的中間件應用服務器中，不同的客戶都可以共享同一個中間層，而不必每 個客戶都單獨實現企業規則，避免了重複開發和維護的麻煩。由於客戶程序相當瘦，無論是開發還是發佈，都變得簡單了。便於升級，當中間件升級的時候，客戶程 序可能不需要變化；實現了分佈式數據處理，把一個應用程序分佈在幾臺機器上運行，可以提高應用程序的性能，也可以把敏感部分封裝在中間件，爲不同的用戶設 置不同的訪問權限，增強了安全性。
3. 本軟件架構設計
在上述的二層結構和三層結構中，三層結構具有明顯的優勢，能很好 的實現業務與界面的分離，在一定程度上實現了重用和鬆耦合。本軟件的結構在三層架構的基礎上繼續改進，如圖2所示。表示層採用Windows界面，主要是 結合用戶的使用習慣及本項目開發人員的技能綜合考慮。數據庫採用微軟的SQL Server2000及MSDE，對於用戶網絡環境受限，本軟件只能單機安 裝的情況採用MSDE數據庫，其他情況採用SQL Server2000。 在基於數據庫系統的三層結構中，業務邏輯層不僅負責業務邏輯，而且直接訪問數 據庫，提供對業務數據的保存、更新、刪除和查詢操作。系統框架起到容器的作用向業務邏輯層提供服務，它還能夠被很好的重用，將一些基礎的公共的功能放在系 統框架層，這樣就沒有必要每個項目都從頭做起，可以重用以前的成果提高效率。目前該系統框架提供的服務主要有連接池、緩存、日誌、安全性、異常、訪問配置 信息等。
2.2 獲取分析類
類圖的獲取是一個不斷細化的過程，一般我們先從分析類開始。分析類是概念層面上的類，是進行類設計的基礎，獲取分析類是系統分析中一項很重要的工作。獲取分析類的是一個需要大量技巧的工作，我們主要根據用例描述來確定分析類。表2中列出的問題可以幫助我們識別用例中的類。
表 2 識別用例中類的問題
用例描述中出現了那些實體？
用例的完成需要哪些實體合作？
用例執行過程中會產生並存儲哪些信息？
用例要求與之關聯的每個角色的輸入是什麼？
用例反饋與之關聯的每個角色的輸出是什麼？
用例需要操作哪些硬設備？
比 如在“選擇建設項目”用例描述中對基本流的描述如下：“系統提供已有建設項目供用戶選擇。用戶從系統提供的項目列表中選中某個建設項目。系統對當前選中的 建設項目進行標識，進入主界面” 。通過對用例描述的分析可以確定出分析類“建設項目”。通過類似的方式對每個用例描述進行分析，可以獲得系統的分析類。 如圖3所示，就是我們對用例進行分析後獲得的系統的分析類。
2.3 用例 實現
獲 得分析類以後，我們就可以藉助分析類通過交互模型對用例如何實現進行描述。用例實現是一個由需求轉移到分析、設計的過程。用例描述了用戶的功能性需求，用 例實現藉助分析類以及他們之間的交互來描述用例被如何實現。可以看出使用UML從需求到分析、設計的過渡是很平滑的。在描述用例實現時我們可以使用活動 圖、順序圖、協作圖等方式。活動圖和協作圖可以互換，一般我們僅選擇其中的一種就可以了。由於篇幅的限制項目繼續以用例“選擇建設項目”爲例說明。
爲 了使這個用例能夠更加清晰，使用了圖4所示的“選擇建設項目”的活動圖對該用例加以描述。進入該用例後，系統提供所有建設項目及新建建設項目功能。此時用 戶可以瀏覽已經列出的建設項目進行選擇，或者使用查詢功能進行查詢，或者新建一個並不存在的建設項目，這些操作對應了基本流和可選流。由於用戶處理的建設 項目不多，所以將所有的建設項目都列出來。通過這樣的活動圖我們對用例“選擇建設項目”將有一個更清晰的認識。
下面的對用例實現的描述主 要採用了順序圖來描述，當然也可以同時使用協作圖進行描述。順序圖和協作圖都屬於交互圖，都是用於描述系統中對象之間的動態關係。兩者可以相互轉換，但是 兩者強調的重點不同，順序圖強調的是消息的時間順序，而協作圖強調的是參與交互的對象的組織。如果我們使用建模工具，創建了順序圖之後，工具可以幫我們自 動生成協作圖。
用例描述中描述的基本流、可選流可以通過順序圖來進行更加詳細的描述。對於用例“選擇建設項目”使用一個活動圖和三個順序圖來實現它的動態模型。“選擇建設項目”的用例描述中有一個基本流，兩個可選流。我們將選用3個順序圖分別描述這三個場景。
圖5 “選擇建設項目”基本流的順序圖
圖5 所示的順序圖，是“選擇建設項目”用例的基本流中對象之間的交互序列。在此順序圖中的對象有質監機構的工作人員、選擇建設項目窗體的一個實例、 TProject類的一個對象。用戶激活選擇建設項目窗體的一個實例。該窗體創建TProject類的一個對象。接着窗體調用對象方法，獲得的所有建設項 目，並且調用自身的方法將這些建設項目進行加載，供質監機構的工作人員選擇。用戶選擇了一個建設項目，窗體調用對象的方法將用戶選擇的建設項目標識爲當前 的建設項目，以後所有的操作將在這個建設項目上進行。
圖6 “選擇建設項目”可選流1的順序圖
圖6 所示的順序圖是選擇建設項目用例的“可選流1”中對象之間的交互序列。也就是用戶不使用系統列出的建設項目，而是查詢建設項目從中選擇。在此順序圖中的對 象有某個質監機構的工作人員、選擇建設項目窗體的一個實例、TProject類的一個對象。某個質監機構的工作人員激活選擇建設項目窗體的一個實例。該窗 體創建TProject類的一個對象。接着窗體調用對象方法，獲得的所有建設項目，並且調用自身的方法將這些建設項目進行加載，供質監機構的工作人員選 擇。某個質監機構的工作人員將查詢信息提供給窗體進行查詢，窗體調用對象的查詢方法獲得建設項目。窗體調用自身的加載方法，將查詢得到的建設項目加載到窗 體上，供質監機構的工作人員選擇。質監機構的工作人員選擇某個建設項目之後，窗體調用對象的方法將用戶選擇的建設項目標識爲當前的建設項目，以後所有的操 作將在這個建設項目上進行。
圖7 “選擇建設項目”可選流2的順序圖
圖7 所示的順序圖是“選擇建設項目”用例的可選流2中對象之間的交互序列。也就是不選擇建設項目而新建一個建設項目。在此順序圖中的對象有某個質監機構的工作 人員、選擇建設項目窗體的一個實例、TProject類的一個對象。某個質監機構的工作人員激活選擇建設項目窗體的一個實例。該窗體創建TProject 類的一個對象。接着窗體對象的方法，獲得所有的建設項目，並且調用自身的方法將這些建設項目進行加載，供質監機構的工作人員選擇。某個質監機構的工作人員 不進行選擇，新建建設項目，窗體調用對象的新建建設項目的功能。該功能在新建建設項目用例中描述。
2.4 整理分析類
整理分析類主要是依據用例實現部分的一系列的交互圖。我們已經獲得了分析類，在用例實現中我們在交互圖中使用了這些類。但是這些類還沒有屬性、職責。我們需要對他們進行整理，完成分析類的屬性、職責以及類之間的關係，並在類圖中將他們展示出來。
職責是分析類響應消息並完成特定功能的能力，包括對外提供服務和維護自身的信息。由於消息和職責存在着對應關係，根據消息就可以確定職責。在交互模型中對象之間的交互通過消息進行。將交互圖中將和該類有關的消息進行整理確定類的職責。
類之間並不是孤立的，利用類之間的關係就可以找到另一個類。利用協作圖中對象之間的連接就是分析類之間的關聯方式之一。分析類之間完整的關聯關係要根據所有事件序列中對象間的連接加以歸納。
屬性是分析類的基本內容。屬性的基本來源是用例的事件流描述。如果對分析類及方法的描述比較明確，屬性就比較容易獲取。要分析屬性也要結合分析類的方法，因爲職責會使用屬性去完成功能。
在整理分析類的過程中一定要注意分析類不僅僅參與了一個用例，它可能參與了很多的用例，因此在分析屬性、職責及類之間關聯的時候要考慮每個用例的情況，進行歸納總結。通過整理分析類繪製的類圖僅僅是分析階段的類圖還需要在後續階段繼續完善和細化。
圖8 分析類Project
圖8就是整理出的一個分析類Project類的示例，當然這個類不僅僅是從選擇建設項目這個用例獲取的信息，它是綜合了所有相關的用例分析的結果。
