軟件建模正在成為一種普遍的技術來幫助軟件工程師理解，

圖9.1。軟件工程模型和方法知識領域主題的分解

工程師，并與適當的利益攸關方溝通軟件的各個方面。利益攸關方是指那些對軟件有明確或隱含興趣的人(例如，用戶、買方、供應商、架構師、認證機構、評估者、開發人員、軟件工程師，也許還有其他人)。

雖然在文獻和實踐中有許多建模語言、表示法、技術和工具，但是有一些統一的通用概念以某種形式應用于它們。以下各節提供這些一般概念的背景知識。

1.1建模原則

建模為軟件工程師提供了一種有組織的和系統的方法，用于表示正在研究的軟件的重要方面，促進關于軟件或要素的決策，并將這些重要的決策傳達給利益攸關方團體中的其他人。指導此類建模活動的一般原則有三個:

對基本要素進行建模:好的模型通常不會在所有可能的條件下代表軟件的每個方面或特性。建模通常只涉及開發那些需要特定答案的軟件方面或特性，抽象掉任何不重要的信息。這種方法使模型保持可管理和有用。

提供透視圖:建模使用一組定義好的規則來表達每個視圖中的模型，從而提供正在研究的軟件的視圖。視圖驅動方法為模型提供了維度(例如，結構視圖、行為視圖、時間視圖、組織視圖，以及其他相關視圖)。將信息組織到視圖中，使用適當的符號、詞匯表、方法和工具，將軟件建模工作集中在與視圖相關的特定關注點上。

實現有效的溝通:建模使用軟件的應用領域詞匯、建模語言和語義表達(換句話說，環境中的意思)。當嚴格和系統地使用時，此建模將產生一種報告方法，它將促進軟件信息與項目利益攸關方的有效交流。

模型是軟件組件的抽象或簡化。使用抽象的一個結果是沒有單一的抽象完全描述一個軟件組件。相反，軟件的模型被表示為抽象的集合，當這些抽象集合在一起時，它們只描述選中的方面、透視圖或視圖——只描述那些需要做出明智的決定并首先對創建模型的原因作出響應的方面、透視圖或視圖。這種簡化導致了一組關于放置模型的環境的假設，這些假設也應該被捕獲到模型中。然后，在復用模型時，可以首先驗證這些假設，以建立被復用模型在其新用途和環境中的相關性。

1.2模型的屬性和表達

模型的屬性是一個特定模型的顯著特征，用于在所選擇的建模符號和所使用的工具中描述其完整性、一致性和正確性。模型的屬性包括:

完整性:所有需求在模型中被實現和驗證的程度。

一致性:模型不包含沖突的需求、斷言、約束、功能或組件描述的程度。

正確性:模型滿足其需求和設計規范以及無缺陷的程度。

模型被構建來代表真實世界的對象和它們的行為，以回答關于軟件如何被期望運行的具體問題。詢問模型——通過探索、模擬或回顧——可能會暴露模型和模型所引用的軟件中的不確定區域。這些關于需求、設計和/或實現的不確定性或未回答的問題可以得到適當的處理。

模型的主要表達式要素是實體。實體可以表示具體工件(例如，處理器、傳感器或機器人)或抽象工件(例如，軟件模塊或通信協議)。模型實體使用關系(換句話說，目標實體上的行或文本操作符)連接到其他實體。模型實體的表達可以使用文本或圖形化的建模語言來完成;這兩種建模語言類型都通過特定的語言構建連接模型實體。實體的意義可以由它的形狀、文本屬性或兩者同時表示。一般來說，文本信息遵循特定于語言的句法結構。與使用這些實體和關系的環境、結構或行為建模相關的精確含義依賴于所使用的建模語言、應用于建模工作的設計嚴密性、被構建的特定視圖，以及可能附加特定符號要素的實體。可能需要模型的多個視圖來捕獲軟件所需的語義。

當使用自動化支持的模型時，可能會檢查模型的完整性和一致性。除了顯式工具支持之外，這些檢查的有用性在很大程度上取決于應用于建模工作的語義和語法的嚴格程度。正確性通常通過模擬和/或評審來檢查。

1.3語法、語義和語用學

模型可能具有驚人的欺騙性。模型是一種缺少信息的抽象，這一事實可能會導致人們產生一種錯誤的感覺，認為從單個模型就可以完全理解軟件。一個完整的模型(“完整”相對于建模工作而言)可以是多個子模型和任何特殊功能模型的聯合。在這個子模型集合中，對單個模型的檢查和決策可能會有問題。

理解建模構建的精確含義也很困難。建模語言是由語法和語義規則定義的。對于文本語言，語法是使用定義有效語言結構(例如，巴克斯-納爾形式(BNF))的符號語法來定義的。對于圖形化語言，語法是使用稱為元模型的圖形化模型定義的。與BNF一樣，元模型定義了圖形化建模語言的有效語法結構;元模型定義了如何組合這些構建來生成有效的模型。建模語言的語義指定附加到模型中捕獲的實體和關系的意義。例如，由一條線連接的兩個盒子組成的簡單圖表可以有多種解釋。知道盒子被放置和連接的圖表是一個對象圖或活動圖可以幫助解釋這個模型。

作為一個實際問題,通常有一個好的理解一個特定的軟件模型的語義建模語言選擇,如何建模語言是用來表達模型中實體和關系,建模者的經驗基礎和建模的環境中進行表示。即使在不完整的信息存在的情況下，也可以通過抽象來傳達意義;語用學解釋了如何在模型及其環境中體現意義，并有效地與其他軟件工程師溝通。

然而，仍然有一些實例需要注意建模和語義。例如，必須檢查從另一個模型或庫導入的任何模型部件，以確定在新建模環境中存在沖突的語義假設;這可能并不明顯。應該檢查模型是否有文檔化的假設。雖然建模語法可能是相同的，但是模型在新環境中可能意味著完全不同的東西，這是一個不同的環境。另外，考慮到隨著軟件的成熟和變更，可能會引入語義不和諧，從而導致錯誤。隨著時間的推移，隨著工具的更新和可能的新需求，許多軟件工程師都在工作于一個模型部分，模型的一部分有機會表示與原始作者的意圖和初始模型環境不同的東西。

1.4前置條件、后置條件和不變量

建模功能或方法時，軟件工程師通常從一組關于軟件在功能或方法執行之前、期間和之后的狀態的假設開始。這些假設對于函數或方法的正確操作是至關重要的，并且被分組，作為一組先決條件、后置條件和不變量進行討論。

先決條件:在執行函數或方法之前必須滿足的一組條件。如果這些先決條件在函數或方法執行之前不保持，該函數或方法可能會產生錯誤的結果。

后置條件:在函數或方法成功執行后保證為真的一組條件。通常，后置條件表示軟件的狀態如何改變，傳遞給函數或方法的參數如何改變，數據值如何改變，或返回值如何受到影響。

不變量:操作環境中的一組條件，在函數或方法執行之前和之后保持不變(換句話說，不變)。這些不變量對軟件和函數或方法的正確操作是相關和必要的。

審核編輯：湯梓紅