因為欣賞所以轉載，原文地址 http://blog.csdn.net/sunleap/article/details/4976993

開發的流程有以下幾步：

各個階段的UML圖

（1）需求階段是：用例圖

（2）分析階段是：類圖、序列圖

（3）設計階段：類圖、序列圖與平臺結合

業務建模工作步驟：

（1）選定業務單元

（2）識別業務執行者

（3）識別業務用例

（4）詳述業務用例

（5）建立業務物件模型

    類圖(Class Diagram)應該是使用的最多的一種UML圖。其語法並不複雜，可能只需要幾天時間就能掌握，但是其背後的面向物件(OO)思想卻是需要日積月累才能深刻理解。

1、OOA(Object-Oriented Analysis 面向物件分析)

2、OOD(Object-Oriented Design 面向物件設計)

3、OOP(Object-Oriented Programming 面向物件程式設計)

4、OOT(Object-Oriented Technology 面向物件技術)

PS：無論是開發人員還是分析人員，這幾種思想是必須要掌握的，作為開發人員來說，OO的思想，其深度和延伸內容可謂博大精深，值得花時間去學習。

    類可以視作一現實事物抽象出的統一的、相似的模型。

    物件可以看做是類的具體化，就像模具匯出的產品一樣。

    類圖就是描述類與類之間關係的圖。

案例：

1、識別出類。

2、識別出類的主要屬性。

3、畫出類之間的關係。

4、對各類進行分析、抽象、整理。

    兩個類之間有關係，但又不確定是什麼關係，可以用關聯關係表達。

PS：關聯關係如果出現數量上的對應可以寫上數字表示數量，可以用角色關係表示兩類分別處於什麼角色，單向關聯關係表示關聯是單向的，只能由關聯方找到被關聯方。在寫程式碼時，可以將其視作關聯類包含了被關聯類的一個引用。

    包含關係表示一個類包含另一個類。

PS：包含關係分為兩種，一種是弱包含關係，叫做聚合，為空心菱形，一種是強包含關係，叫做組合，為實心菱形。一開始可以將所有包含關係視作弱包含，當發現某些關係可以用強包含表示時，才轉為強包含關係。

    當一個類是另一個類的子類時，可以使用泛化關係。

PS：泛化關係通常也被稱作繼承關係，根據類的發現先後關係，如果是由父類匯出子類，這樣就可以說子類繼承父類，如果是由子類匯出父類，這樣就可以說父類泛化子類。

    當一個類可以實現某個抽象類時，可以使用實現關係。

PS：標識介面與類之間的關係用的比較多。

    當一個類需要另一個類協助時，可以用依賴關係表示。

    當某類使用或者包含自己時，可以使用遞迴關係。

    當發現兩個類之間的關係不能用一般關係來表示，這時候可以用關聯類來表示關係，這也就是三角關係。

PS：可以通過思考屬性是否恰當來識別出關聯類關係，列出兩類的關鍵屬性之後，思考這些屬性的屬性值是不是由該類本身就可以確定，如果不能兩類之間就可能有關聯類關係。

    如果說類圖代表了一類事物，那麼物件圖就代表著某個具體的事物。

現實世界被業務模型對映並且記錄下來，但 這只是原始需求資訊，距離可執行的程式碼還很遙遠，必須把這些內容再換成一種可以指導開發的表達方式。UML 通過稱之為概念化的過程（ Conceptual）來 建立適合計算機理解和實現的模型，這 個模型稱為分析模型（ Analysis Model）。分析模型介於原始需求和計算機實現之間，是一種過渡模型。分析模型向上映射了原始需求，計算機的可執行程式碼可以通過分析模型追溯到原始需求；同時，分析模型向下為計算機實現規定了一種高層次的抽象，這種抽象是一種指導，也是一種約束，計算機實現過程非常容易遵循這種指導和約束來完成可執行程式碼的設計工作。

事實上分析模型在整個分析設計過程中承擔了很大的職責，起到了非常重要的作用。繪製分析模型最主要的元模型有：

邊界類（boundary） 。邊界是面向物件分析的一個非常重要的觀點。從狹義上說，邊界就是大家熟悉的介面，所有對計算機的操作都要通過介面進行。從廣義上說，任何一件事物都分為裡面和外面，外面的事物與裡面的事物之間的任何互動都需要有一個邊界。比如參與者與系統的互動，系統與系統之間的互動，模組與模組之間的互動等。只要是兩個不同職責的簇之間的互動都需要有一個邊界，換句話說，邊界決定了外面能對裡面做什麼“事”。 在後續的章節中，讀者會感受到邊界的重要性，邊界能夠決定整個分析設計的結果。

實體類（entity） 。原始需求中領域模型中的業務實體映射了現實世界中參與者完成業務目標時所涉及的事物，UML 採用實體類來重新表達業務實體。實體類可以採用計算機觀點在不丟失業務實體資訊的條件下重新歸納和組織資訊，建立邏輯關聯，新增那些實際業務中不會使用到，但是執行計算機邏輯時需要的控制資訊等。這些實體類可以看作是業務實體的例項化結果。

控制類（control） 。邊界和實體都是靜態的，本身並不會動作。UML 採用控制類來表述原始需求中的動態資訊，即業務或用例場景中的步驟和活動。從UML 的觀點看來，邊界類和實體類之間，邊界類和邊界類之間，實體類和實體類之間不能夠直接相互訪問，它們需要通過控制類來代理訪問要求。這樣就把動作和物體分開了。考慮一下，實際上在現實世界中，動作和物體也是分開描述的。

讀者或許在小時候都玩過一個遊戲，每個同學發四張小紙條，在第一張紙條上寫上XXX 的名字，在 第二張紙條上寫上在什麼地方，在 第三張紙條上寫上一個動作，在 第四張紙條上寫一個物體，然後將這些字條分開放在四個箱子裡，再隨意地從這四個箱子裡各取一張紙條，就能組成很多非常搞笑的句子，例如張XX 在公園裡跳圓規之類的奇怪語句，一個班的同學常常笑得前仰後合。

遊戲雖然是遊戲，但說明了一個道理，只要有人、事、物和規則（定語），就能構成一個有意義的結果，無非是是否合理而已。分析類也是應用這個道理來把業務模型概念化的。由於所有的操作都通過邊界類來進行，能做什麼不能做什麼由邊界決定，所以邊界類實際上代表了原始需求中的“事”； 實體類則由業務模型中的領域模型轉化而來，它代表了現實世界中的“物”； 控制類則體現了現實世界中的“ 規則”， 也 就是定語；再 加上由參與者轉化而來的系統的“ 使用者”， 這 樣一來，“ 人”也有了。有了人、事、物、規則，我們就可以像那個遊戲一樣把它們組合成各種各樣的語句，只不過不是為了搞笑，所以不能隨意組合，而是要依據業務模型中已經描繪出來的用例場景來組合這些元素，讓它們表達特定的業務含義。

（1）業務模型：也稱企業模型，它為企業提供一個框架結構，以確保企業的應用系統與企業經常改進的業務流程緊密匹配。可以說，也就是說業務建模主要是從業務的角度而非技術角度對企業進行建模。典型的建模方法包括Zachman框架、ARIS HOUSE模型等，業務模型一般包括下面一些檢視：

（2）資料模型

（3）面向物件模型

（4）資料探勘模型