UML參考手冊 第一部分 背景知識 第2章 模型的性質與目標 (轉)

UML參考手冊 第一部分 背景知識 第2章 模型的性質與目標 (轉)[@more@]UML參考手冊  
  第一部分 背景知識  

第2章 模型的性質與目標

　　本章將解釋什麼是模型，模型有何用途以及如何使用模型。本章還將解釋模型的不同層次：理想的，部分的和基於工具的。

2.1 什麼是模型
　　模型是用某種工具對同類或其他工具的表達方式。模型從某一個建模觀點出發，抓住事物最重要的方面而簡化或忽略其他方面。工程、建築和其他許多需要具有創造性的領域中都使用模型。
　　表達模型的工具要求便於使用。建築模型可以是圖紙上所繪的建築圖，也可以是用厚紙板製作的三維模型，還可以用存於中的有限元方程來表示。一個建築物的結構模型不僅能夠展示這個建築物的外觀，還可以用它來進行工程設計和成本核算。
　　的模型用建模語言來表達，如UML。模型包含語義資訊和表示法，可以採取圖形和文字等多種不同形式。建立模型的目的是因為在某些用途中模型使用起來比操縱實物更容易和方便。

2.2 模型的用途
　　模型有多種用途
1. 捕獲精確和表達專案的需求和應用領域中的知識，以使各方面的利益相關者能夠理解並達成一致
　　建築物的各種模型能夠準確表達出這個建築物在外觀、交通、服務設施、抗風和抗震，消費及其他需求。各方面的利益相關者則包括建築設計師、建築工程師、合同締約人、各個子專案的締約人、業主、出租者和市政當局。
　　軟體系統的不同模型可以捕獲關於這個軟體的應用領域、使用方法、試題手段和構造等方面的需求資訊。各方面的利益相關者包括軟體結構設計師、系統分析員、員、專案經理、顧客、投資者、最終和使用軟體的操作員。在UML中要使用各種各樣的模型。
2. 進行系統設計
　　建築設計師可以用畫在圖紙上的模型圖、存於計算機中的模型或實際的三維模型使自己的設計結果視覺化，並用這些模型來做設計方面的的試驗。建造、修改一個小型模型比較簡單，這使得設計人員不需花費什麼代價就可以進行創造和革新。
　　在編寫程式程式碼以前，軟體系統的模型可以幫助人員方便地研究軟體的多種構架和設計方案。在進行詳細設計以前，一種好的建模語言可以讓設計者對軟體的構架有全面的認識。
3. 使具體的設計細節與需求分開
　　建築物的某種模型可以展示出符合顧客要求的外觀。另一類模型可以說明建築物內部的電氣線路、管線和通風管道的設定情況。實現這些設定有多種方案。最後確定的建築模型一定是建築設計師認為最好的一個設計方案。顧客可以對此方案進行檢查驗證，但通常顧客對具體的設計細節並不關心，只要能滿足他們的需要即可。
　　軟體系統的一類模型可以說明這個系統的外部行為和系統中對應於真實世界的有關資訊，另一類模型可以展示系統中的類以及實現系統外部行為特性所需要的內部操作。實現這些行為有多種方法。最後的設計結果對應的模型一定是設計者認為最好的一種。
4. 生成有用的實際產品
　　建築模型可以有多種相關產品，包括建築材料清單、在各種風速下建築物的偏斜度、建築結構中各點的應力水平等。
　　利用軟體系統的模型，可以獲得類的宣告、過程體、使用者介面、、合法使用的說明、草案以及與其他單位技術競爭情況的對比說明。
5. 組織、查詢、過濾、重獲、檢查以及編輯大型系統的有關資訊
　　建築模型用服務設施來組織資訊：建築結構、電器、管道、通風設施、裝潢等等。除非利用計算機，否則對這些資訊的查詢和修改沒那麼容易。相反，如果整個模型和相關資訊均儲存在計算機中，則這些工作很容易進行，並且可方便地研究多種設計方案，這些設計方案共享一些公共資訊。
　　軟體系統用檢視來組織資訊：靜態結構檢視、狀態機檢視、互動檢視、反映需求的檢視等等。每一種檢視均是針對某一目的從模型中挑選的一部分資訊的對映。沒有模型管理工具的支援不可能使模型做得任意精確。一個互動檢視編輯工具可以用不同的格式表示資訊，可以針對特定的目的隱藏暫時不需要的資訊並在以後再展示出來，可以對操作進行分組、修改模型元素以及只用一個命令修改一組模型元素等等。
6. 經濟地研究多種設計過程中的解決方案
　　對同一建築的不同設計方案的利弊在一開始可能不很清楚。例如，建築物可以採用的不同的子結構彼此之間可能有複雜的相互影響，建築工程師可能無法對這些做出正確的評價。在實際建造建築物以前，利用模型可以同時研究多種設計方案並進行相應的成本和風險估算。
　　透過研究一個大型軟體系統的模型可以提出多個實際方案並可以對它們進行相互比較。當然模型不可能做得足夠精細，但即使一個粗糙的模型也能夠說明在最終設計中所要解決的許多問題。利用模型可以研究多種設計方案，所花費的成本只是實現其中一種方案所花費的成本。
7. 利用模型可以全面把握複雜的系統
　　一個關於龍捲風襲擊建築物的工程模型中的龍捲風不可能是真實世界裡的龍捲風，僅僅是模型而已。真正的龍捲風不可能呼之即來，並且它會摧毀測量工具。許多，激烈的物理過程現在都可以運用這種物理模型來研究和理解。
　　一個大型軟體系統由於其複雜程度可能無法直接研究，但模型使之成為可能。在不損失細節的情況下，模型可以抽象到一定的層次以使人們能夠理解。可以利用計算機對模型進行復雜的分析以找出可能的“問題點”，如時間錯誤和資源競爭等。在對實物做出改動前，透過模型研究系統內各組成部分之間的依賴關係可以得出這種改動可能會帶來哪些影響。

2.3 模型的層次
　　針對不同目的，模型可以採取各種形式及不同的抽象層次。模型中所包含的資訊量必須對應於以下幾種目的：
1. 指導設計思路
　　在專案早期所建立的高層模型用於集中利益相關者的思路和強調一些重要的選擇方案。這些模型描述了系統的需求並代表了整個系統設計工作的起點。早期的模型幫助專案發起者在把精力放在系統的細節問題之前研究專案可能的選擇方案。隨著設計工作的進展，早期模型被更為精確的模型所替代。沒有必要詳細儲存早期研究過程中的種種選擇方案和返工情況。早期模型的目的是幫助獲得思路。但最後得到的“思路模型”要在進行詳細設計前記錄下來。早期模型不需要達到實現階段的模型的精確程度，無須涉及有關係統實現的一套概念。建立這種模型只使用了　　UML定義的的一個子集，比後期的設計階段的模型使用的元件要少得多。
當早期模型發展到具有一定精度的完整的檢視模型時—例如，分析系統需求的模型—那麼要在開發過程進入下一階段時將其儲存下來。不斷向模型中填加資訊的增量式開發（在這種情況下開發的推理過程也要儲存和記錄）與一般的針對“死端點”進行研究直到得出正確的解決方案的隨意漫步式開發之間一個重要的區別。後一種情況通常使人不知怎麼著手，並且根本沒有必要對整個開發過程進行記錄儲存，除非遇到特殊情況需要對開發過程進行回溯。
2. 系統基本結構的抽象說明
　　在分析階段和初步設計階段所建立的模型以關鍵概念和最終系統的各種機制為中心。這些模型以某種方式與最終系統匹配。但是模型中喪失了細節資訊，在設計過程中必需顯式地補充這些資訊。使用抽象模型的目的是在處理區域性細節問題前糾正系統高層次的普遍問題。透過一個仔細的開發過程，這些模型可以發展成最終模型，該過程保證最終獲得的模型能夠正確實現初期模型的設計意圖。必須具備跟蹤能力來跟蹤從基本模型到完備模型的過程，否則無法保證最終系統正確包含了基本模型所要表達的關鍵特性。基本模型強調語義，它們不需要涉及系統實現方面的細節。有時確實會出現這種情況：在低層實現方面的差別會使邏輯語義模糊不清。從基本模型到最後的實現模型的途徑必須清晰和簡明，不論這個過程由程式碼生成器自動實現還是由設計者人工實現。
3. 最終系統的詳細規格說明
　　系統實現模型包含能夠建造這個系統的足夠資訊，它不僅要包括系統的邏輯語義和語法、演算法、資料結構和確保能正確完成系統功能的機制，而且還要包括系統製品的組織決定，這些製品對個人之間的相互協作和使用輔助工具來說十分必要。這種模型必須包括對模型元素進行打包的元件以便於理解和用計算機進行自動處理。這不是目標應用系統的特性，而是系統構造過程應具有的特性。
4. 典型或可能的系統範例
　　精心挑選的例項可以提高人們的觀察能力並使系統的說明和實現有實際效果。然而，即使有非常多的例子，也起不到一段詳細定義所起的效果。我們最終希望的是要讓模型能夠說明一般的情形，這也是程式程式碼所要做的事情。不過典型的資料結構、互動順序或生命歷程的例子對於理解複雜系統很有益處。必須小心使用例子。從邏輯上來說，從一大堆特例中歸納出最一般的情況是不可能的，但是大部分人思考某一問題時總是首先考慮一些被精心挑選出來的有關該問題的例子。範例模型僅是對模型的示例而不帶有一般性的描述，因此，人們會覺得這兩種模型之間有差異。範例模型一般只使用UML定義的元件的子集。說明型模型和範例模型在建模中都很有用。
5. 對系統全面的或部分的描述
　　模型可以完全描述一個獨立系統，並且不需要參考外部資訊。更通常的情況是，模型是用相互區別的、不連續的描述單元組織起來的，每個單元作為整體描述的一部分可以被單獨進行儲存和操縱。這種模型帶有必須與系統其他模型聯絡在一起的散件。因為這些散件具有相關性和含義，因此它們能夠與其他散件透過各種方式結合來構造不同的系統。獲得重用是一個好的建模方法的重要目標。
　　模型要隨時間發展變化。深度細化的模型源於較為抽象的模型，具體模型源於邏輯模型。例如，開始階段建立的模型是整個系統的一個高層檢視。隨著時間的推進，模型中增加了一些細節內容並引入了一些變化。再隨著時間的推進，模型的核心焦點從一個以使用者為中心的前端邏輯檢視轉變成了一個以實現為中心的後端物理檢視。隨著開發過程的進行和對系統的深入理解，必須在各種層次上反覆說明模型以獲得更好的理解，用一個單一視角或線性過程理解一個大型系統是不可能的。對模型的形式無所謂“正確和錯誤”之分 。

2.4 模型內容
1. 語義和表示法
　　模型包含兩個主要方面：語義方面的資訊（語義）和視覺化的表達方法（表示法）。
　　語義方面用一套邏輯元件表達應用系統的含義，如類、關聯、狀態、用例和訊息。語義模型元素攜帶了模型的含義即，它們表達了語義。語義建模元素用於程式碼生成、有效性驗證、複雜度的度量等，其視覺化的外觀與大多數處理模型的工具無關。語義資訊通常被稱作模型。一個語義模型具有一個詞法結構、一套高度形式化的規則和動態結構。這些方面通常分別加以描述（定義UML的文獻即如此），但它們緊密相關，並且是同一模型的一部分。
　　視覺化的表達方式以可使人觀察、瀏覽和編輯的形式展示語義資訊。表示方式元素攜帶了模型的視覺化表達方式，即語義是用一種可被人直接理解的方式來表達的。它們並未增添新的語義，但用一種有用的方式對加以組織，以強調模型的的排例。因此它們對模型的理解起指導作用。表示式元素的語義來自於語義模型元素。但是，由於是由人來繪製模型圖，所以表示式元素並不是完全來自於模型的邏輯元素。表示式元素的排列可能會表達出語義關係的另外含義，這些語義關係很不明顯或模稜兩可，以至於在模型中不能形式化地表達，但可給人啟迪模。
2. 上下文
　　模型自身是一個計算機系統的製品，被應用在一個給出了模型含義的大型語境中。這個包括模型的內部組織、整個開發過程中對每個模型的註釋說明、一個預設值集合、建立和操縱模型的假定條件以及模型與其所處環境之間的關係。
　　模型需要有內部組織，允許多個工作小組同時使用某個模型而不發生過多的相互牽涉。這種對模型的分解並不是語義方面所要求的—與一個被分解成意義前後連貫的多個包的模型相比，一個大的單塊結構的模型所表達的資訊可能會同樣精確，因為組織單元的邊界確定會使準確定義語義的工作複雜化，故這種單塊模型表達的資訊可能比包結構的模型表達得更精確。但是要想有效地工作於一個大的單塊模型上的多個工作組不彼此相互妨害是不可能的。其次，單塊模型沒有適用於其他情況的可重用的單元。最後，對大模型的某些修改往往會引起意想不到的後果。如果模型被適當分解成具有良好介面的小的子系統，那麼對其中一個小的、獨立的單元所進行的修改所造成的後果可以跟蹤確定。不管怎樣，將大系統分解成由精心挑選的單元所構成的層次組織結構，是人類千百年來所發明的設計大系統的方法中最可靠的方法。
　　模型捕獲一個應用系統的語義資訊，但還需記錄模型自身開發過程中的各種資訊，如某個類的設計者、過程的狀態和對各類人員的使用的規定。這些資訊至多是系統語義的外圍資訊，但對開發過程非常重要。因此，建立一個系統的模型必須綜合考慮兩方面。最簡便的實現方法是將資訊作為註釋加入到語義模型中—，即可以對模型元素用非建模語言進行任意描述。在UML中用文字字串來表示註釋。
　　文字編輯器或所使用的命令不是語言的一部分，同樣，用於建立和修改模型的命令也不是建模語言語義的一部分。模型元素的屬性沒有預設值，在一個特定的模型中，它們均具有值。然而，對於實際的開發過程，人們要求建立與修改模型時無須詳細說明有關的所有細節。預設值存在於建模語言和支援這種語言的建模工具的邊界處。在建模工具所使用的建立模型的命令中，它們是真正的預設值，儘管它們可能會超過單個的建模工具並使用者所期望的那樣成為建模工具所使用的通用語言。
　　模型不是被孤立地建造和使用的。它們是模型所處的大環境中的一部分，這個大環境包括建模工具、建模語言和語言、、計算機環境、系統具體實現方面的限制條件等等。系統資訊應該包括環境所有方面的資訊。系統資訊的一部分應被儲存在模型中，即使這些資訊不是語義資訊，例如專案管理註釋（在上面已經討論過）、程式碼生成提示、模型的打包、編輯工具預設命令的設定。其他方面的資訊應分別儲存，如程式和作業系統配置命令。即使是模型中的資訊，對這些資訊的解釋也可以位於多個不同地方，包括建模語言、建模工具、程式碼生成器、編譯器或命令語言等等。本書用UML自身對模型進行解釋。但是當進行系統的具體物理實現時，要用到其他用於解釋的資源，這些資源對UML來說是不可見的。
　　模型說明了什麼？
　　一個模型是一個系統潛在配置的發生器；系統是它的範圍，或值。按照模型來進行系統配置是一種理想化的情況。然而，有時模型所要求的種種條件在現實中無法實現。模型還是對系統含義和結構的一般性說明。這種描述是模型的範圍，或含義。模型總是具有一定的抽象層次。它包含了系統中的最基本的成分而忽略了其他內容。對模型來說，有以下幾方面需要考慮：
　　抽象和具體。 模型包含了系統的基本成分而忽略了其他內容。哪些是基本內容哪些不是基本內容需要根據建模的目的來判定。這不是說要把模型所含資訊的精度一分為二，即只有精確和不精確兩種情況。可能會存在一系列表達精度不同但逐漸提高的模型。建模語言不是程式設計語言。建模語言所表達的內容可能很不精確，因為多餘的詳細內容與建模目的無關。具有不同精度級別的模型可應用於同一個專案的各個階段。用於程式設計編碼的模型要求必須與程式設計語言有關。典型的情況是，在早期分析階段使用高層次的，表達精度低的模型。隨著開發過程的深入，所用的模型越來越細化，最終所使用的模型包含了大量的細節內容，具有很高的精度。
　　說明和實現。 一個模型可以告訴我們“做什麼”（說明），也可以告訴我們“一個功能是如何實現的———即怎麼做”（實現）。建模時要注意區分這兩方面。在花大量時間研究怎麼做之前很重要的一點就是要正確分析出系統要做什麼。建模的一個重要的側面是對具體實現細節進行抽象。在說明和實現之間可能有一系列相關關係，其中在某層次中的說明就是對它上一層次的實現。
闡述和舉例。 模型主要是描述性的。模型所描述的是一個個例項，這些例項僅是作為例子才出現在模型中的。大部分例項僅在執行的一部分時間中才存在。有時，執行例項自身是對其他事物的描述。我們把這些混雜物件稱做元模型（Metamodel）。更深一層次的看，認為任何事物不是描述性的就是例項性的，這種觀點是不符合實際情況的。某一事物是例項還是描述不是孤立區分的，與觀察角度有關，大部分事物都可以用多種角度來考察。
　　解釋的變更。 用一種建模語言對模型可能會有多種的解釋。可以定義語義變更點（semantic variation point）———可能會出現多種解釋的地方———給每一個解釋一個語義變更名，以便可以標識究竟使用了哪種解釋。例如，Smalltalk語言的使用者要避免在系統實現模型種出現多重繼承關係，因為Smalltalk語言不支援多重繼承。而其他程式設計語言使用者可能會在模型種使用多重繼承。語義變更點支援多種具體的實現過程