UML學習_1_模型

一、模型

1.基本概念

    模組化：是将現實世界中的某種事物用某種形式(數學公式、圖形、表格... ... )抽象的表示的過程（自己定義的，不一定準确）。

2.需求階段

2.1.需求擷取

2.1.1.業務模組化

    【http://wiki.mbalib.com/wiki/%E4%B8%9A%E5%8A%A1%E5%BB%BA%E6%A8%A1， 業務模組化】。

    （1） 什麼是業務模組化

　　業務（Business）--是指商業（或非商業）組織及其運作的活動流程。

　　模組化（Modeling）--是指人類對事物進行的一種可視化抽象活動，目的是為了揭示事物的本質和規律。

　　有了上述兩個詞的概念，就不難了解"業務模組化"的定義了。

     業務模組化是指對商業（或非商業）組織及其運作的流程進行的模組化過程。

      最常見的商業組織就是企業，是以，針對商業組織的業務模組化一般就指對企業的組織及其業務過程進行模組化。

      很多人一聽到或說到，就了解成使用者需求分析的一部分，其實這是對業務模組化錯誤認識。需求分析有自己獨立的流程。

      業務模組化的結果并不是需求（它隻是需求的輸入），它是反映了業務組織的靜态的和動态的本質抽象特征。

      業務模組化因而是對業務組織的靜态特征和動态特征進行抽象化的過程。

     靜态特征包括：業務目标、業務組織結構、業務角色、業務成果等。

      動态特征主要指：業務流程。

     業務模組化并不一定需要與資訊化或計算機技術硬扯上關系，除非想把流程的某些環節或所有整個流程進行自動化運作，但這也隻是業務模型中的一種手段或優化，不應喧賓奪主。

     是以嚴格來說，業務模組化與計算機模組化無關，它隻是業務領域的一個模型，通過業務模型可以得到業務範圍，幫助需求人員了解客戶業務，并在工務層面上和客戶達到共識【大象--Thinking in UML，P61】。

    （2）業務模組化的分類

    【http://wiki.mbalib.com/wiki/%E4%B8%9A%E5%8A%A1%E5%BB%BA%E6%A8%A1， 業務模組化】。

　　大概可分為兩類：

• 以企業整體業務為對象，面向業務過程的模組化。

• 以問題域為對象，面向KPI的模組化。

    （3）業務模組化的思路與步驟

    【http://wiki.mbalib.com/wiki/%E4%B8%9A%E5%8A%A1%E5%BB%BA%E6%A8%A1， 業務模組化】。

　　以企業業務為例：

• 明确業務領域所在的業務體系，業務領域在體系中的作用，與其他業務領域的關系。

• 明确業務領域内的主要内容、業務目标、服務對象，建構領域内的業務層次。

• 明确各業務的背景、目标、内容。

• 明确各業務的流轉順序。

• 明确各業務節點的5W1H。

• 明确各業務中業務規則的算法。

• 明确各業務輸入、輸出的資料以及參考的資料。

• 明确各業務的業務主角與業務角色。

2.1.2.業務模型

     需求擷取階段。

     需求是技術無關的。在需求階段讨論技術是沒有任何意義的。那隻會讓你的注意力分散。技術的實作細節是在後面的分析、設計階段才需要考慮的事情。而在業務模組化階段，不但要保證需求的技術無關性，還要保證你的需求不要深入細節，因為在業務模組化階段，最重要的事情就是為了了解業務的全貌，深入細節會浪費時間和精力【http://blog.csdn.net/11t/archive/2004/10/26/152621.aspx， 軟體和需求的實踐，P17】。

2.1.3.領域模型

      領域模型：領域模型是一組圖，這些圖有助于定義出現在用例中的術語。這些圖顯示了問題中的關鍵對象以及他們之間的聯系。認識到領域模型是一種描述工具，用來幫助人們記錄他們的決策以及互相之間的交流是非常重要的【靈活軟體開發：原則、模式與實踐，P443】。

領域模型中使用一種稱為<<type>>或<<stereotype>>的實體。<<type>>或<<stereotype>>代表了對象可以充當的角色，可以具有方法和屬性，也可以具有和其它<<type>>實體的關聯。但是<<type>>或<<stereotype>>不代表設計意義上的類或者對象，不代表軟體元素，也不直接映射到代碼。僅表示一個用于問題描述的概念實體【靈活軟體開發：原則、模式與實踐，P443】。

2.2.需求分析

2.2.1.用例模組化

      用例是一種描述系統需同需求的方法，使用用例的方法來描述系統需求的過程就是用例模組化。

2.2.2.用例模型

      需求分析階段。

      用例模型是系統既定功能及系統環境的模型，它可以作為客戶和開發人員之間的默契。用例是貫穿整個系統開發的一條主線。同一個用例模型即為需求工作流程的結果，可當作分析設計工作流程及測試工作的輸入使用。

系統模組化有很多種方法，每種模組化方法可以滿足不同的目的。用例模型最主要的作用是将系統行為傳達給客戶或最終使用者。是以，模型必須易于了解。

      需求分析仍然多采用自然語言，如果采用形式化語言，和使用者溝通将成為一個大問題，這意味着客戶在開發軟體前必須先進行形式化語言教育訓練，這是不現實的。自然語言對需求分析最大的弊病就是它的二義性，是以不得不對需求分析中采用的語言進行某些限制【http://blog.csdn.net/11t/archive/2004/10/26/152621.aspx， 軟體和需求的實踐，P5】。

除了語言的二義性外，注意不能使用計算機術語。需求分析最重要的是和使用者溝通，可是多半使用者不是計算機的專業人士，如果在需求分析中使用計算機術語，就會造成使用者了解上的困難【http://blog.csdn.net/11t/archive/2004/10/26/152621.aspx，軟體和需求的實踐，P5】。

3.系統分析階段

     系統分析階段。

3.1.分析類

      分析模型是采用分析類，在系統架構和架構的限制下，來實作用例場景的産物。在OO之路的第一部裡，我們說用例和用例場景規定了業務範圍和要求，如果分析類完全實作了這些用例和場景，我們就能肯定的說分析類已經滿足了需求。分析類有：

• 邊界類(boundary)

• 實體類(entity)

• 控制類(control)

     再加上實作用例場景需要的actor類，共四種。

      分析模型是高層次的系統視圖，在語義上，分析類不代表最終的實作。它是計算機系統元素的高層抽象。上述的四個分析類可以完全模拟計算機的執行過程。分析類具體化以後産生真正的實作類，即所謂的設計類，也就是大多數設計師所說的類圖。

     分析模型正是OO設計的核心，設計類隻是OO的實作手段。

     分析模型是MVC模式的經典應用。從分析類的名稱就可以看出來。"商業系統無論多複雜，無論什麼行業，其本質無非是人，事，物， 規則。人是一切的中心，人做事，做事産生物，規則限制人事物。人驅動系統，事展現過程，物記錄結果，規則代表控制。無論OO也好，UML也好，複雜的表面 下其實隻是一個簡單的規則，系統分析員弄明白有什麼人，什麼人做什麼事，什麼事産生什麼物，中間有什麼規則，再把人，事，物之間的關系定義出來，商業模組化 也就基本完成了。"

      根據這一段話，再對比分析類的名稱，想想MVC模式，讀者應該能夠發現分析類在OO和商業目标中精妙的對應關系：人，事，物，規則 ，actor、boundary、entity、control。這就是為什麼筆者說分析模型是OO設計的核心。

3.2.什麼是分析模型

      【OO系統設計師之路--分析模型， coffeewoo】。

      為什麼要用分析模型？現在絕大多數系統的産生過程并沒有用分析模型，也照樣運作，而且在RUP裡，分析模型也隻是一個Optional的過程，并非強制過程。

      的确如此，這可能也是為什麼大多數設計師并不用分析模型的原因。有讀者要問，分析模型完全實作用例場景是以可以證明設計滿足需求，那麼我用設計類來實作用例場景，也可以同樣證明，分析模型又有何用呢？

      這正是分析模型要存在的原因。

3.2.1.分析模型意義

      分析類不代表實作，它具化成設計類以後才是實作。分析類是系統元素的高層抽象。

      有經驗的設計師，特别是那些擅長于使用設計模式的設計師們都知道，OO系統要保持擴充能力，複用性要好，要把變更影響控制在小範圍内，就要應用高層次的抽象，用高層次的抽象接口來 表達系統行為，而把具體實作delay到子類，配置文檔，甚至運作期去。所有的設計模式，不論采取了怎樣的技巧，均是為了這些目的。

      分析模型對系統設計來說也同樣延續了這樣的思想，用四個高度抽象的分析類來表達系統行為，而把實作delay到設計類中去。這些抽象透明于實作方式，也透明于實作語言，它表達的核心觀點是系統架構，業務實作模式和規範，需求可回溯的驗證。

      比如，我們用一個實體分析類表達了某個業務實體，在分析模型中我們定義了所有針對該實體的互動和存取操作，對分析模型這個層次的抽象來說已經完整表達了計算機系統對業務需求的模拟實作。但其實這時并未真正的實作這個業務需求，一直到具化成設計類後，根據開發語言特性、架構、規範等等要求，這個實體分析類可被具化成一個或多個SDO，POJO，EntityBean，可以用Hibernate，可以用 Webshpere BO，也可以用Weblogic XMLbean...等等。完全可以根據實際需要來确定實作方式和語言，是以實作得以delay，這就帶來了OO擴充和複用的潛在能力。并且這時設計師已經不用擔心具化出的設計類是否會脫離需求，它們已經在分析模型層次被驗證，而能專心考慮系統實作所要求的那些特性。

3.2.2.分析模型松耦合

      為什麼要用分析類而不是設計類去驗證需求呢？這是由于抽象層次更高，分析類比設計類驗證需求的工作量以及可能的變化都要少很多。

      比如針對登入要求，如果用分析類來表達，我們隻需要向登入control類發一條登入請求就OK了。而設計類由于與實作方式相關，并且已經具化到了實作，是以根據安全驗證方式不 同，LDAP，CA，SSL，或應用伺服器不同，登入方式和方法都不同，并且可能是很多個步驟，例如 getUser()、getRole()、getGroup()、register()...，你願意用這麼多說明才能表示已經驗證了一個簡單的登入要求 嗎？如果更換了安全模式呢？更換了應用伺服器呢？這在現實情況中也很常見，對分析類來說，由于抽象層次高于實作方式，是以繼續有效，而設計類卻必須更改。這就是為什麼要用分析模型來驗證需求的原因之一。

      較真的讀者或許會說，安全模式變了，就算不為了驗證需求，設計類本身也不得不改，這看起來沒什麼必然因果關系啊？考慮一下，在一個項目組裡，當一份設計文檔被share到負責各個摸塊的開發小組時，各小組對該文檔都形成了一個共同的認識。如果這個認識是基于分析模型而不是設計模型的，當安全模式改變，對負 責安全子產品的開發小組來說，他可以改變他負責的設計類而無需通知其它小組。因為從分析模型的層次來看，一切都沒有改變。 這與大家熟悉的設計類中更換了類實作而保持接口不變的道理是一樣的，隻要接口不變就無須通知任何人。 而如果這個共識是基于設計模型的，一點小的改變都需要通知到各個小組，因為各小組的認識是基于類名，方法名的，改動了，能不通知他人麼？從OO角度來說， 這就是松藕合和緊藕合的差别。

      從上面的例子可以看出分析模型比設計模型要穩定得多，是以用它來驗證和表達系統到需求的映射是很好的。這有助于在開發過程中當實作類變來變去，一個類改為兩個，突然又加了一個設計模式（這種情形非常的常見吧？）時，保持系統到需求映射的穩定，同時也就保持了一個穩定的系統視圖和業務架構。對開發小組來說，不會因為這些變動影響到他們對系統整體的認識。

3.2.3.分析模型抽象能力

      分析模型較高的抽象層次有助于讓人們更容易了解系統行為。由于與實作無關，是以可以用大白話來表達系統互動過程，比如對于登入要求，我們可以直接用"登入 ()"來表示這個系統請求，相比于設計類中的getUser()、getRole()、getGroup()之類的方法名，分析模型明顯要直白得多。而開發人員對系統行為良好的了解顯然會對開發有着很大的幫助。 在一個項目比較複雜，而且是多個Team橫向合作的情況下，分析模型顯得更加有效。因為它的簡潔和穩定，會讓各個開發組減少細節溝通的成本。

      最後，如果你所做的項目并非一次性項目，而是基于一個行業，不斷的有相似或相同的單子，更打算長期立足于這個行業，做精做深，形成完整的行業解決方案的話，分析模型更是必須要考慮的。在你的組織面對同行業不同客戶時，可能無法保證所有客戶都選擇同樣的語言，同樣的軟體平台，有着同樣的業務要求。在設計模型的層次上，這必然導緻很多個不同的實作版本。面對這麼多不同的版本，如何去維護一個"統一的行業解決方案"呢？正如上面所述，由于分析模型抽象層次高于實作方式和實作語言，你可以用分析模型來維護這一個方案。還是登入的例子，雖然客戶們可能有的用LDAP，有的用CA，将來可能還有新的模式，但對于分析 模型來說，安全子產品始終可以保持一緻。這将非常有利于随着各個項目的進行，對分析模型的逐漸維護，而形成一個統一的，穩定的架構和行業解決方案，而針對不 同的客戶要求，又可以提供不同的實作包。

3.3.怎麼做分析模型

      【OO系統設計師之路--分析模型， coffeewoo】。

      分析模型是系統的高層抽象，是高于實作語言和實作方式的。是以在做分析模型過程中，要跳出固有的Java思維，C++思維，同時也暫時不要考慮設計模式的應用，而專心的，用OO思維把四個分析類的職責和互動，以及它們之間的關系定義清楚。

如果說用例分析大部分情況下是程式化的（筆者正希望它是程式化的）， 那麼你會發現，分析模型大部分工作也是程式化的。

4.系統設計階段

      系統設計階段。

4.1.設計模型

5.模型比較

5.1.用例模型、分析模型

      【http://blog.3snews.net/?6633， 區分用例模型、分析模型和設計模型】

• 用例模型使用客戶的語言進行描述；

          分析模型使用開發人員的語言進行描述

• 用例模型是系統的外部視圖；

          分析模型是系統的内部視圖；

• 用例模型通過用例來構造，提供外部視圖的結構；

          分析模型通過構造型的類或包來構造，提供内部視圖的結構；

• 用例模型用于客戶和開發人員簽合同時，明确系統應該和不應該做什麼；

          分析模型為開發人員所用以了解如何構造系統，即怎樣設計和實作系統

• 用例模型中需求可能存在備援和不一緻等問題；

          分析模型中需求不可能存在備援和不一緻等問題

• 用例模型捕獲系統的功能包括對架構重要的功能；

          分析模型概述如何實作系統功能，包括對架構層重要的功能，是設計階段的切入點

• 用例模型定義早分析模型中進一步進行分析的用例；

          分析模型定義用例實作，每個用例實作代表對用例模型中一個用例的分析。

5.2.分析模型、設計模型

      【http://blog.3snews.net/?6633， 區分用例模型、分析模型和設計模型】

• 分析模型是概念模型，因為是系統的一個抽象并回避了實作問題；

         設計模型是實體模型，因為它是實作的藍圖。

• 分析模型對設計是通用的，即适用于多種設計；

          設計模型對設計不是通用的，針對特定的實作

• 分析模型不太形式化；

         設計模型比較形式化

• 分析模型開發費用比較低；

         設計模型開發費用比較高，是5倍的分析模型

• 分析模型層數少；

         設計模型層數多

• 分析模型勾畫系統的設計輪廓，包括系統架構；

         設計模型是進行系統的設計，包括系統架構；

• 分析模型不需要在整個軟體生命周期内做維護；

         設計模型需要在整個軟體生命周期内做維護；

• 分析模型定義作為構造系統基本輸入的架構，包括建立設計模型；

         設計模型在盡可能保持需求模型所定義結構的前提下構造系統。