第一節　信息模型與建模

信息模型（information model）是一種用來定義信息常規表示方式的方法，通過使用信息模型，計算機系統可以對所管理的數據進行重用、變更和分享。信息模型獨立于具體技術，用于反映一個領域、機構或系統的信息基本狀況。使用信息模型的意義不僅在于對象的建模，同時也在于對象間相關性的描述。在多數情況下，信息模型以層次化的形式來表示［1］。

模型最主要的優點在于它可以將一個復雜問題分解為幾個可以控制的組成部分。建立衛生信息模型，可以使信息收集、記錄、整理、傳輸、分析、利用的每個環節上的人都能在概念上對數據有統一的理解，在格式上有統一的標準，從而實現語法上的互操作以及語義上的互操作。標準的信息模型，相當于為所有系統建立了統一的信息基礎框架，基于該框架的術語編碼、數據交換等都將具備一致的語義基礎。

一、建模原則

軟件建模正在成為一種普遍的技術，以幫助軟件工程師理解、設計軟件，并就軟件的各個方面與有關的涉眾進行溝通。這里的涉眾是指那些與該軟件有著明確或隱含利害關系的人或機構，例如用戶、買方、供應商、架構師、認證權威機構、評估人員、開發人員、軟件工程師，也許還有其他人員。雖然在文獻和實踐中有許多建模語言、符號、技術和工具，但是有一些統一的一般概念以某種形式適用于所有這一切。下面將介紹這些一般概念的背景知識［2，3］。

（一）建模原則

建模為軟件工程師提供了一種有組織的和系統化的方法，用于表示正在研究中的軟件的一些重要方面，這有助于就軟件或其構成元素作出決策，并將這些重要決策與涉眾群體中的其他人進行溝通。指導此類建模活動的一般原則有3個。

1.為要點建模

即使是好的模型通常也并不能表達軟件在各種可能的條件下的各個方面或功能特征。建模通常只涉及開發那些需要特定答案的軟件功能特征，這就需要抽取掉所有不必要的信息。這種方法保持了模型的可管理性和實用性。

2.提供視圖

建模是利用已經定義好的、在每個視圖中用于表達該模型的一組規則來為正在研究中的軟件提供一個全景視圖。這種視圖驅動的方法為模型確立了維度，例如結構視圖、行為視圖、時間視圖、組織視圖和其他相關視圖。使用適當的符號、詞匯、方法和工具，將信息組織到這些視圖中，可將軟件建模工作的重點放在與視圖相關的特定關注點上。

3.實現有效的通信

建模使用軟件的應用領域詞匯、建模語言和語義表達（換句話說，就是上下文含義）。當這些能夠嚴格且系統地使用時，這種建模會產生一種報告方法，從而促進軟件信息與項目涉眾的有效溝通。

模型是軟件組件的抽象或簡化。使用抽象方法的結果是，沒有任何一個單一的抽象能完全描述軟件組件。因此，不如說軟件模型是諸多抽象的集合，當把它們放在一起時，它們也只是描述選定的方面、構面或視圖，只描述那些需要作出明智決策并首先對創建該模型的原因作出響應的方面或視圖。這種簡化就會產生構成模型背景的一組假設，那么如果要重用這一模型，就要首先驗證這些假設，以建立重用模型在其新用途和其背景間的相關性。

（二）模型的屬性和表達

模型的屬性是模型的特征，用于在所選的建模符號和使用的工具中描述其完整性、一致性和正確性。模型的屬性包括如下幾個方面。

1.完整性

在模型中所有需求都達到得以實現及驗證的程度。

2.一致性

模型中的需求、斷言、約束條件、函數或組件描述等不存在任何沖突的程度。

3.正確性

模型滿足其需求和設計規范的程度，并且沒有缺陷。

構建模型是為了表示真實世界的對象及其行為，以回答有關軟件有望如何運行的特定問題。對模型進行質疑檢查，無論是通過探究、模擬，還是評審，都能暴露出模型和模型所涉及的軟件中的不確定性區域。這樣，這些有關需求、設計和/或實現的不確定性或未回答的問題隨后就可得到適當的處理和解決。模型的主要表達元素是實體。實體可以是具體事物（如處理器、傳感器或機器人）或抽象事物（如軟件模塊或通信協議）?？蓪⒛Ｐ蛯嶓w利用文字、連線或文本操作符與其他實體連接起來。模型實體的表達可以使用文本或圖形化建模語言來完成，建模語言類型都通過特定的語言構造來連接模型實體。實體的含義可以通過其形狀、文本屬性或兩者兼而有之來表示。一般來說，文本信息遵循特定于語言的句法結構。與使用這些實體和關系的上下文、結構或行為建模相關的精確含義取決于所使用的建模語言、應用于建模工作的設計嚴謹性、正在構建的特定視圖，以及可能附加特定符號元素的實體?？赡苄枰Ｐ偷亩鄠€視圖來捕獲軟件所需的語義。當使用自動化支持的模型時，可能要檢查模型的完整性和一致性。除有明確的工具支持之外，這些檢查的有用性在很大程度上取決于應用于建模工作的語義和語法嚴格程度。正確性通常通過模擬和/或評審來檢查。

（三）句法、語義和語用學

模型可能具有驚人的欺騙性。如果模型是一個缺失信息的抽象，那么可能會讓人產生從單個模型去正確理解軟件的錯覺。一個完整的模型（與建模工作相關的“完整”）可以是多個子模型和任何特殊功能模型的結合。在這個子模型集合中，與單個模型相關的檢查和決策可能是有問題的。理解建模構造的精確含義也很困難。建模語言是由句法和語義規則定義的。對于文本語言，語法是使用定義有效語言結構（如巴科斯-諾爾范式）的符號語法來定義的。對于圖形語言，語法是使用被稱為元模型的圖形模型定義的。與巴科斯-諾爾范式一樣，元模型定義圖形建模語言的有效語法結構；元模型定義了如何組合這些構造來生成有效的模型。

建模語言的語義詳細說明了模型中實體和關系的含義。例如，由一條線連接的兩個框的這類簡單關系圖可以有多種解釋。了解這些可能是對象關系圖，也可能是活動關系圖的框-線圖，可以幫助解釋這個模型。實際上，通常很好地理解選定的建模語言下的一個特定的軟件模型的語義，要了解所用的建模語言是如何表達模型中實體和關系的，要了解建模師的經驗基礎和建模所依據的上下文背景，以及是如何表示的。即使在信息不完整的情況下，意義也是通過抽象的模型來傳達的；語用學解釋了意義如何在模型及其上下文中體現，以及如何有效地與其他軟件工程師進行溝通。然而，仍然有一些實例需要在建模和語義方面保持謹慎。例如，必須檢查從另一個模型或庫導入的所有模型構成，以確定在新的建模環境下是否存在沖突的語義假設。應該檢查模型是否有文檔化的假設。雖然建模語法可能是相同的，但是模型在新環境（即不同的上下文）中可能意味著完全不同的東西。另外，考慮到隨著軟件的成熟和變化，可能會引入語義不一致，從而導致錯誤。隨著時間的推移，與模型各部分打交道的軟件工程師會越來越多，加上工具更新和可能的新需求，模型的某些部分有可能會表達與原始作者的意圖和初始模型上下文完全不同的含義。

（四）前置條件、后置條件和不變條件

當對功能或方法建模時，軟件工程師通常是從功能或方法執行前、中、后三種軟件狀態的一組假設開始的。這些假設對于功能或方法的正確運行是必不可少的，為便于討論，將其分為前置條件、后置條件和不變條件三組。

1.前置條件

在執行功能或方法之前必須滿足的一組條件。如果這些先決條件在功能或方法執行之前不成立，則功能或方法可能產生錯誤的結果。

2.后置條件

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

3.不變條件

在功能或方法執行之前和之后，運行環境中始終存在的一組條件。換句話說，就是一組不變的條件，這些不變條件對軟件和功能或方法的正確運行是相關和必要的。

二、模型類型

典型的模型是由若干子模型集合而成。每個子模型都是一個部分的描述，并且是為特定目的而創建的；它可以由一個或多個圖組成。這些子模型可以使用多種建模語言，也可使用單一建模語言。統一建模語言（UML）識別許多種建模圖。使用這些圖以及建模語言構件，可產生三種常用的模型類型：信息模型、行為模型和結構模型。

（一）信息建模

信息模型主要關注數據和信息。信息模型是一種抽象表示，用于標識和定義數據實體的一組概念、屬性、關系和約束。語義或概念信息模型通常用于從問題的角度為建模的軟件提供某種形式體系和上下文，而不關心該模型如何實際映射到軟件的實現。語義或概念信息模型是一種抽象，因此僅包括概念化信息的真實視圖所需的概念、屬性、關系和約束。語義或概念信息模型的后續轉換，就是軟件中實現的邏輯和物理數據模型的細化。

（二）行為建模

行為模型是確定和定義被建模軟件的功能。行為模型通常有三種基本形式：狀態機、控制流模型和數據流模型。狀態機向軟件模型提供的是已定義好的狀態、事件和轉換。軟件通過模型環境中發生的受保護或未受保護的觸發事件從一種狀態轉換到下一種狀態?？刂屏髂Ｐ兔枋鲆幌盗惺录绾问沽鞒瘫患せ罨蛲Ｓ?。數據流行為被歸類為一系列步驟，在這些步驟中，數據經過流程向數據存儲或數據接收器移動。

（三）結構建模

結構模型從軟件的各個組成部分說明軟件的物理或邏輯組成。結構建模在被實現或建模的軟件與將要在其中運行的環境之間建立已定義的邊界。在結構建模中使用的一些常見結構構造是實體的組合、分解、泛化和專門化；實體之間的相關關系和基數的確定；以及流程或功能接口的定義。UML為結構建模提供的結構圖包括類圖、組件圖、對象圖、部署圖和包圖。

三、模型分析

模型的開發為軟件工程師提供了一個研究、推理和理解與軟件相關的結構、功能、運行使用和組裝考慮事項的機會。需要對構建的模型進行分析，以確保這些模型足夠完整、一致和正確，以滿足涉眾的預期目標。下面的部分簡要描述了軟件模型通常使用的分析技術，以確保軟件工程師和其他相關的涉眾從模型的開發和使用中獲得適當的價值。

（一）完整性分析

為了使軟件完全滿足涉眾的需求，完整性是至關重要的——從需求獲取過程到代碼實現。完整性是指所有指定的需求是否都已得到實現和驗證的程度?？梢允褂媒Y構分析和狀態空間可達性分析等技術的建模工具檢查模型的完整性（這些技術確保狀態模型中的所有路徑都由一組正確的輸入到達）；可以使用檢查或其他評審技術人工檢查模型的完整性。這些分析工具產生的錯誤和警告信息，以及通過檢查或評審發現的錯誤和警告信息，表明可能需要采取糾正措施，以確保模型的完整性。

（二）一致性分析

一致性是模型不包含任何沖突的需求、斷言、約束、功能或組件描述的程度。通常，一致性檢查是通過使用自動化分析功能的建模工具來完成的；還可以使用檢查或其他評審技術人工檢查模型的一致性。與完整性一樣，這些分析工具產生的錯誤和警告信息以及通過檢查或評審發現的錯誤和警告信息表明需要采取糾正措施。

（三）正確性分析

正確性是模型滿足其軟件需求和軟件設計規范、不存在缺陷并最終滿足涉眾需求的程度。正確性分析包括驗證模型的語法正確性（即正確使用建模語言語法和構造）和驗證模型的語義正確性（即使用建模語言構造來正確表示建模對象的含義）。為了分析一個模型的語法和語義的正確性，可以自動化分析（如使用建模工具來檢查模型的語法正確性）或人工分析（使用檢查或其他評審技術）以便找到可能的缺陷，然后在軟件的發布之前刪除或修復已確認的缺陷。

（四）可追溯性

開發軟件通常涉及許多工作產品的使用、創建和修改，如計劃文檔、過程規范、軟件需求、圖表、設計和偽代碼、手寫和工具生成的代碼、手動和自動測試用例和報告，以及文件和數據。這些工作產品可以通過各種依賴關系（如應用、實現和測試）進行關聯。隨著軟件的開發、管理、維護或擴展，需要映射和控制這些可追溯關系，以證明軟件需求與軟件模型和工作產品的一致性。通常，可追溯性可改進軟件工作產品和軟件過程質量的管理；它還能向涉眾提供所有的需求均已得到滿足的保證?？勺匪菪允沟迷谲浖_發和發布之后進行變更分析成為可能，因為可以很容易地遍歷變更與軟件工作產品的關系來評估變更的影響。通常，建模工具會提供一些自動化或人工的方法來規范和管理模型和其他軟件工作產品中所表示的需求、設計、代碼和/或測試實體之間的可追溯性連接關系。

（五）交互分析

交互分析著重于實體之間的通信或控制流關系，這些實體用于在軟件模型中完成特定的任務或功能。此分析檢查軟件模型的不同部分，包括其他軟件層（如操作系統、中間件和應用程序）之間交互的動態行為。對于某些軟件應用程序來說，檢查計算機軟件應用程序和用戶界面軟件之間的交互也很重要。一些軟件建模環境為研究建模軟件的動態行為提供了模擬工具。逐步通過模擬，為軟件工程師提供了一個分析選項，以審查交互設計并驗證軟件的預期功能。