在軟體工程的全部實施過程中都採用模型的方式而非文字的表達方式來進行描述，這樣的實現過程稱之為全程建模。全程建模的特點是：模型相互之間是有關聯的，模型成為軟體工程過程各階段展現的主體而不是文字描述作為主體存在。通過建模的方式將原來純文字加圖形描述的各種文件模型化，使得從需求到程式碼能夠統一起來，實現需求的變動直接影響到程式碼的變化。提高程式碼對需求的有效性聯絡，同時，解決過去經常出現的：編碼改動，文件就失效的問題。
軟體建模方法有很多種，至今為止最廣泛使用的是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介面建模
見http://www.cnblogs.com/hobe/archive/2006/10/08/523861.html
未完待續......