美國國防部體系架構框架（DoDAF ）使用的 IBM Rational 方法
構建複雜系統要求具有了解並管理複雜關係的特別能力。徹底地瞭解企業架構 2 對有效的設計、實現、部署和演進系統的維護是至關重要的。一個完整的與該架構相符的模型是對該理解的關鍵 —— 並且對於減少風險及管理系統的複雜性是必要的。DoDAF 內容爲我們提供了一個觀察在增量地定義系統時所利用的體系結構的“ 窗口” 。
已生成的符合 DoDAF 的報告支持對主要的面向任務的系統的贊助及籌款的搜索。然而，通過在系統生命週期的早期描述系統架構，系統工程團隊可以從該投資中瞭解到更加多的價值。例如，您越早識別出集成挑戰和運作依賴，您就會更有效地達成關鍵的決策。
IBM Rational 用集成產品的方式全面支持 DoDAF ，這些產品是證實了的系統工程過程（Rational Unified Process® for Systems Engineering ，或稱 RUP-SE ），和設計用來簡化發現、描述、實現，和演進多種與 DoD 運作任務相關的複雜企業架構的功能。
IBM Rational 工具明顯地符合 DoDAF 的規範，建立在 IBM Rational 的基於 Eclipse 的建模解決方案上，包括 IBM Rational Software Architect® 、IBM Rational Software Modeler® ，和 IBM Rational Systems Developer™ 。整個系統開發團隊能夠使用用於需求管理的 IBM Rational RequisitePro® 、用於配置管理的 IBM Rational ClearCase® 、用於變更管理的 IBM Rational ClearQuest® ，及其他 IBM Rational 產品。Ready for Rational Partners 所提供的擴展功能和插件進一步增強了 Systems Modeling Language (SysML) 建模和基於狀態機的可執行模型的能力。
遵守 DoDAF 的最佳途徑不需要系統開發的主要工作之外的工作。IBM Rational 方法將 DoDAF 產品與整個體系結構建模工作合併起來，讓 DoDAF 視圖來表示一個演進的企業架構，該架構是與實現此架構的系統相符合且起源於 這個系統的。
如同任何複雜的活動一樣，學習利用 DoDAF 創建並維護企業架構需要對系統工程的原則，及有關 DoDAF 知識的熟練運用。IBM Rational 能夠很好的提供服務，並優化您的工作。本文餘下的部分向您介紹了 DoDAF 並舉例說明了如何在描述企業體系結構的情況下滿足符合 DoDAF 的需求。
關鍵的 DoDAF 要素
DoDAF 着重於對運作企業的重要架構要素之間的關係進行建模。符合 DoDAF 模型的核心要素是節點（nodes ） 、需求線（needlines ） 、服務（services ） ，以及信息交換（information exchanges ） 。總的來說，這些實體描述了運作企業中重要活動的結構和分配。
·節點 —— 系統、參與者，和工作人員 。DoDAF 的本質要素是節點，表示邏輯或物理實體（工作人員、系統，或子系統），在企業的內部或外部運行，其任務是以某種方式與一個或多個企業要素交互。節點是組成運作企業的複雜系統架構和設計的基礎。架構將更着重於節點之間的關係，而設計更多地處理單個節點的結構和行爲。因此，DoDAF 的主要目標 —— 以及對運作企業的架構建模的好處 —— 是描述節點可以通過其進行協作以完成任務的一種方式。在 DoDAF 中，我們處理三種節點：在運作視圖（OV ）中所描述的並表現參與者、工作人員，和系統的聯合的運作節點（operational nodes ） 、作爲實現運作節點行爲的邏輯要素的系統（systems ） ，及表示貯存邏輯系統或子系統的物理要素或位置的系統節點（system nodes ） 。
·需求線 —— 關係及依賴 。在 DoDAF 中，協作的運作節點之間的關係表示爲需求線（needlines ） 。每一條需求線都表示出一個節點向另一個節點提供一個或多個在運行上必要的服務和相關信息的需求。需求線是抽象的，因爲它們可能表示單個的服務或信息交換，或者一組服務或信息交換。不論在哪種情況下，需求線都舉例說明了，一個運作節點依賴於另一個節點來獲得服務或信息，並指定了服務或信息流動的方向。
·服務 —— 重要的運作功能 。服務表示一個節點給予另一個節點的一個或多個可運行的重要功能。每種服務還隱式或顯式地表示節點之間的信息傳遞，並且可能被描述爲一個消息或運作。
·信息交換 —— 所傳遞信息的特徵 。信息交換與一組功能性的和非功能性的需求相關，表現出獲取、傳遞或使用信息所受的約束的特徵。
複雜系統開發的最佳實踐
通過把所需的 DoDAF 內容的生產與精心設計企業架構（EA ）及其相關需求的整個過程無縫地合併在一起，您可以有效地去除複雜系統開發中可感知到的遵從 DoDAF 所帶來的負擔。此外，您可以利用在 DoDAF 產品中獲得的非常寶貴的工程信息來減少系統開發中成本和進度安排的風險。
詳細設計架構的結構和行爲的 IBM Rational 方法是基於已證實的原則的。“ 系統工程的六條原則” 是一些實用的指導方針，它們爲很好地管理系統的演進提供了基礎。它們強調了開發複雜系統的組織應該關注的關鍵領域。它們還使組織能夠評估難題，並分析其原因。
·分解系統，而不是需求 。在進入下一更低層之前，開發一個抽象層次。明確地精心設計用例及所獲得的行爲。務必不僅考慮邏輯架構，還要考慮架構的物理或面向位置的方面。爲所描述的每個抽象層次查明並編制邏輯和物理架構之間的關係。對下一個更低抽象層重複操作，直至架構能足以滿足開發組織的需求。
·即要分離又要集成 。爲所描述的每個抽象層分析黑盒及白盒視圖。爭取平衡兩種觀點以避免某一方向上的過度行爲。分離太多會導致功能分解和相關的集成問題，太過強調集成，您會有錯過重要功能問題的危險。
·系統和組件應協作，開發團隊也應該這樣 。需要協作的組件和系統/ 子系統的開發人員依賴於全面的相關性知識。開發人員如果不協作，您就會增加集成失敗的風險。
·規範貫穿架構中 。您應該瞭解每個抽象層上的需求，並利用它們導出在每個抽象層上協作的要素功能。
·在生命週期中要減少風險並增加價值 。當各種資源可以用來實現此原則時，就能減少成功的障礙。
·開發組織應該考慮產品架構 。開發團隊技能的最佳實踐要求在整個迭代過程中將責任從一個角色移到另一個角色。組織具有多重互補技能的團隊提供了更多的管理靈活性，並且爲組織增加了全面的個人能力。
風險管理推進了企業架構開發的整個過程。嚴格地應用迭代過程，並使用標準的符號，如統一建模語言（Unified Modeling Language ，UML ）會形成在連續的更低層抽象層次上的對系統結果和行爲的多種觀點的全面可視化表示。循環地對子系統定義層和內部設計應用這些原則可形成一個完整、一致的架構工程模型。而這又爲複雜系統的設計、實現、開發、管理，和受控的演進提供了基礎。
符合 DoDAF 模型的組織結構
DoDAF 構成了視圖周圍的架構信息。
全視圖(AV) 產品的目的是提供在運作企業環境中的主題系統的全景透視圖，並說明了拱型的關係，如 Concept of Operation (CONOPS) 和關鍵任務目標及策略，以及架構上的重要術語的整合的詞典。
運作視圖 (OV) 着重於主題系統的表面上可見的結構和行爲。此視圖描述了運作節點及其關係，並確定反映任務需求的依賴，因而爲企業定義和演進提供全部的環境。
認識到內部結構和行爲是 系統視圖(SV) 的焦點，它將功能和非功能需求（來自運作視圖）的嚴格分配合併到邏輯和物理系統要素和接口上。
技術標準視圖 (TV) 中反映出對企業的運作架構的標準約束，並描述了系統的當前和未來狀態。
圖 1 ：DoDAF 視圖間的關係
DoDAF 視圖內及之間的一致性是關鍵的。DoDAF 視圖的最佳推導要求多重抽象層次（即，系統分解）之間建模的一致性。當我們深入到架構模型中，向企業的連續抽象層次中循環地應用嚴格的系統架構發現過程時，我們對要素有了更多的瞭解，並可能使用其他方法來表示其特徵。例如，最初我們可能用用例或環境圖的方式來表示滿足用戶需求的複雜系統。當我們對所支持的活動（系統白盒行爲）有更多的瞭解時，我們可能增加類、活動，和/ 或序列圖來反映額外的細節。在一個圖中作爲參與者進行描述的節點（nodes ） 在其它圖中可能更適合表示爲類或對象。組成子系統的類運作的集合可能實現服務（services ） 。
在確定對每個核心 DoDAF 要素建模有多好時，您必須首先了解該要素下的必要語義，以及所有可應用的約束條件，然後在給定的整個工程工作環境中應用恰當的表示法。此環境包括建模工作的風險、複雜性、工具、表示法，和目標。
生成 DoDAF 視圖的全部過程是迭代 且增量的 。隨着對架構信息的獲取更加廣泛與深入，所有視圖（AV-1 和 AV-2 ）在進行着演進。將 AV-1 用作基礎，分析運作企業的架構的交互以及主題系統，這導致發現了系統和運作節點之間的高層交互。完全地描述這些高層關係是運作視圖的着重點。
只有在您充分了解了外部系統行爲（在企業層）之後，您才能繼續詳細描述系統視圖。這是我們開始設計並組織爲全面的開發提供基礎的內部行爲和子系統交互的地方。這裏，我們還將協調多種讓我們通過聯合實現的實踐和用例流來處理必要的運作行爲的物理和 邏輯實現的觀點。
所有視圖產品
下面表格簡要地描述了所有視圖產品，以及您創建它們的順序。
|
產品 |
標題 |
描述 |
表示 |
創建順序 |
|
AV-1 |
概述和總結信息 |
文本文檔，描述了主題系統的範圍、目的、預計用戶，和運作環境。提供對企業性質，以及企業如何與主題系統交互的全面瞭解。支持對系統使用的戰略上的觀察。 |
參考模型的文本文檔。 |
1 |
|
AV-2 |
整合的字典 |
用於描述架構的所有術語的定義。提供一組標準的參考術語，保持體系結構所有的客戶所瞭解的含義是一致的。 |
存儲模型，基於存儲庫的文本，可導出 XML 。 |
進行中 |
DoDAF 所有視圖(AV) 產品概述了在主題系統演進過程中開發、部署，並管理這些系統所處於的環境。這個概述描述了任務目標、策略、運作概念，及運作的一般環境，和相關的專門術語。
AV-1 ：概述和總結信息
AV-1 是對運作環境和要在演進的系統中實現的任務功能的文字概述。其焦點是需要在該環境內建立的主題系統或企業。Relevant Concepts of Operations (CONOPS) 和策略在抽象層次上表示出來，適用於執行的領導來簡化決策的制定。AV-1 的內容表現出獲取必要商業驅動的指導或觀察，以及正在開發的主題系統的需求。
需求方或開發組織可能準備 AV-1 ，儘管，同所有 DoDAF 視圖產品一樣，與擁有廣泛的運作經驗的問題領域專家 (SME) 的實質交互是必要的。以此處描述的方法，您可以利用文字處理器生成 AV-1 文檔並將參考鏈結與包含可視化 DoDAF 產品的模型相關聯。
AV-2 ：整合的字典
AV-2 表示一個簡單的，但對系統和軟件開發很必要的概念。通過建立一個與架構相關的定義和可能模糊的術語的單一集中的詞彙表，就可以充分地滿足對含義的一致性和清晰性的需求。
IBM Rational 方法將由 IBM Rational 的基於 Eclipse 的建模工具，包括 IBM Rational Systems Developer 、IBM Rational Software Architect ，和 IBM Rational Software Modeler ，所管理的模型存儲庫中的集成字典的不斷演進的版本合併起來。在您生成模型要素時，您可以將要素合併到 IBM Rational 的基於 Eclipse 的建模工具中的工程信息中（您隨時都可以從這些信息中提取 AV-2 ）。所有與 DoDAF 原型相關的圖形化模型要素可以以此方式自動獲取。您需要手動地添加文本參考，或者通過一些其他的工具，如 IBM Rational RequisitePro ，訪問它們。
運作視圖產品
DoDAF 運作視圖是由各種產品組成的，這些產品提供了對整個企業環境中的主題系統的外部結構和行爲的多種觀點。在這些視圖中，我們描述了系統及其角色之間的交互，系統所需的任務目標，及爲了實現那些目標的必要依賴和交互。
OV 的焦點是影響該任務的那些需求和功能。系統視圖 (SV) 說明了 OV 是如何實現的。下面的表格簡要地說明了 OV 產品，並建議了一個創建這些產品的順序。
|
產品 |
標題 |
描述 |
表示 |
創建順序 |
|
OV-1 |
高級運作概念圖 |
運作概念的圖形抽象，支持企業的任務。 |
高級的抽象圖形，企業環境圖（Enterprise Context Diagram ），企業用例圖（Enterprise Use-Case Diagram ） |
1* |
|
OV-2 |
運作節點連接描述 |
運作節點、活動、連通性，和信息流。 |
帶有需求線和 IO 實體的企業環境圖 |
4** |
|
OV-3 |
運作信息交換矩陣 |
節點間交換的信息及信息的屬性。 |
貯存模型的文本矩陣，可導出 XML |
4** |
|
OV-4 |
命令關係圖表 |
命令、控制，和運作組織之間的協調關係。 |
帶有組織要素的自由形式的圖 |
2** |
|
OV-5 |
活動模型 |
活動、活動間的關係、I/O 、約束條件，及執行活動的機制。 |
針對每個企業用例的活動圖 |
2** |
|
OV-6a |
運作規則模型 |
識別影響運作活動的業務規則和過程約束條件。 |
模型約束（OCL/SysML ），參考模型的功能及非功能的需求 |
2** |
|
OV-6b |
運作狀態轉換描述 |
識別事件和運作序列之間的關係。 |
狀態轉移圖 |
4** |
|
OV-6c |
運作事件/ 跟蹤描述 |
識別追溯到場景或關鍵活動的外部可視的運作序列和動作。 |
序列圖 |
3 |
|
OV-7 |
邏輯數據模型 |
結構化的數據關係，支持信息的運作交換。 |
指示 IO 實體及其關係的類圖 |
5 |
* OV-1 的內容首先開始，但到 OV-2 完成時才能完成 OV-1 的圖形。
** 這些產品不是連續地相依賴的，可以按別的順序創建，否則這些產品將是相互依賴的且要共同地開發。
*** 狀態轉移圖是可選地用於構建對需要特殊處理的複雜事件的關鍵的實時響應。
圖 2 的活動圖中顯示了可能生成產品的順序。所提議的順序是基於建立在上面談論的系統工程的六個原則之上的架構的發現過程的。依照此順序，您可以有效地生成符合 DoDAF 的產品，而不用減少定義企業架構的主要任務。
圖 2 ：生成 DoDAF AV 和 OV 產品的推薦順序
OV-1: 高級運作概念圖
OV-1 簡明扼要地傳達了運作企業環境中的主題系統的範圍。OV-1 圖形描述是出自畫家之手的產品，反映來自多個源的內容。OV-1 的主要信息來源是 AV-1 概要和總結（Overview and Summary ）文檔，即運作環境圖（Operational Context Diagram ），和企業用例圖（Enterprise Use-Case Diagram ）。我們以主題系統開始繪製企業用例圖，並確定所有與該系統交互的外部系統和組織實體。我們將這些交互要素描繪爲參與者或角色。然而，爲每個歸就於參與者的運作目標向圖中加入用例。在適當的位置加入 UML « 通信» 原型的關聯。
許多參與者或角色在組織要素中協作，爲了滿足任務的需求。向組織要素聚集參與者或角色可以使得識別出運作節點，利用類圖來獲取，即指定的運作環境圖。系統架構師和其他SME 與圖形畫家合作繪製出 OV-1 圖（參見圖 3 ）中的運作環境圖，爲適合執行層的觀衆。由於此圖與在開發的系統有關，所以它爲運作企業的外部可視架構的構建提供了基礎。該圖的內容會隨着獲取的更多信息及生成的額外的 DoDAF 產品而演進的。
圖 3 ：OV-1 高層次圖形
在多個參與者表示運作節點中的過程的地方，您可能需要將與那些參與者相關的角色集合到一起。隨後由運作節點（參與者集合）和該系統之間集合的交互，或需求線來表示參與者與主題系統之間的交互。與那些參與者相關的 IO 實體也與指定的運作節點關聯起來。
OV-2: 運作節點連接描述
OV-2 確定併爲運作節點之間的運作依賴建模。DoDAF 將這些依賴定義爲需求線（needlines ） 。有兩種主要的確定需求線的方法：
1. 確定企業用例圖中每個« 通信» 關聯中所表現出來的依賴的本質，並指定相應的需求線。給需求線一個定向的組件，使其能從消費者（對於該關係）導航到服務或信息的提供者。
2. 等到您開始詳述用例流和場景並在 OV-6c 序列圖（見下）中獲得它們的時候。這裏，您可以確定具體的對象或角色交互，這可以將其提到有代表性的需求線上。
第一種選擇是手動過程，由於需要某種層次的工程/ 或架構分析。第二種選擇是讓您利用 IBM Rational 的基於 Eclipse 的建模工具的一些功能來自動地由手動生成的序列圖中的內容填充需求線（和 OV-3 Information Exchange Requirements ，或 IERs ）。後一種方法擁有保證 OV-2 、OV-3 ，和 OV-6c 之間的一致性的額外優勢，因爲它們將來源於同樣的模型信息。
一條需求線可能代表許多信息交換或服務依賴。因此，一旦您確定了任意兩個環境圖要素之間的需求線，就不適合再添加指向同一方向的需求線了。圖 4 例舉了針對 OV-2 示例的需求線。
圖 4 ：帶有需求線的 OV-2 示例
點擊此處放大
注意： UML 2.0 引入了新的分類器，協作（Collaboration ）。與協作相關的語義爲您提供了更有力地描述關係的潛能。您可以指定關聯任務、模式、模板和相關參數。您還可以將與協作相關的信息例示爲協作事件，進一步指定每個可能的 IER 。增大帶有類和複合結構圖（分別參照協作集協作事件）的 DoDAF 表示的極小集是值得的。UML 語言參考手冊 4對這些 UML 要素進行了全面的討論。
OV-3: 運作信息交換矩陣
OV-3 是共同地表示 OV-2 的需求線的 IER 矩陣。通過參考 OV-6c 的內容，可以利用 IBM Rational Systems Developer 設計和開發工具自動地生成 OV-3 。OV-3 矩陣中的每一行表示一個 IER ，由在 OV-6c 序列圖的交互中的角色和對象間轉移的數據的特徵組成。矩陣爲每組交互並交換信息的對象或角色確定截然不同的 IER 。具體的 IER 特徵與非功能需求或設計約束相關。每個 IER 的內容都表示 OV-6c IO 實體類（見下）的實例，在此，屬性表示 DoDAF 需要的數據特徵。因此，矩陣中的每個信息要素都應該追溯到邏輯數據模型（Logical Data Model ），即 OV-7 。
OV-3 強調架構中交換的信息的邏輯和運作特性。它不打算極力地獲取信息交換的所有細節，而是作爲一種幫助您瞭解重要交換的重要方面的機制。圖 5 舉例說明了適當的詳細級別。5 此內容要追溯到補充的或非功能的需求。
|
需求線標識符 |
IER 標識符 |
信息要素描述 |
生產者 |
消費者 |
|
|
|
信息要素名稱和標識符 |
通過節點名稱和標識符發送通過活動名稱和標識符發送 |
通過節點名稱和標識符接收通過活動名稱和標識符接收 |
|
需求線標識符 |
IER 標識符 |
事務特性 |
性能屬性 |
信息保證 |
安全 |
|
|
|
任務場景 UJTL 或 METL 事務類型觸發事件必需的互用性層臨界性 |
週期性時間性 |
訪問控制可用性保密性分發控制完整性 |
責任性保護（類型名稱，持續時間，日期）分類分類警告 |
圖 5 ：OV-3 信息交換矩陣示例
點擊此處放大
OV-4: 命令關係圖表
OV-4 爲影響到企業運作架構的組織實體及企業系統之間的關係建模。具體的組織要素可能作爲候選角色，即組成 OV-6c （見下）的交互圖中的運作節點的實例。OV-4 由自由形式的圖表示，在該圖中，組織要素可能作爲 OV-6c 序列圖中運作節點的實例的候選。
注意： 一些實施者已經選擇創建該圖，但幾乎沒有顯示出 OV-4 和餘下的 DoDAF 視圖之間的映射。
OV-5: 角色和指責圖
OV-5 闡明瞭與完成運作企業環境中的關鍵任務目標有關的角色、責任，和執行順序。OV-5 是運作企業的外部可視行爲的圖形表示，由分配到組件系統的活動流表示。爲了使行爲和支持數據之間緊耦合，還提供與這些活動相關的重要數據流。結合需求和用例規範的文字內容的 OV-5 較大地提高了系統工程團隊的能力，以確保企業架構及方式（以此方式支持任務）的運作透視圖中的完整性、明確性，和一致性。
OV-6a: 運作規則模型
OV-6a 獲取對用於達到運作企業的環境和主題系統中的任務結果的運作過程的約束。以文字形式獲取信息並編製成文檔形式。向組織的信息接收者提供模板。OV-5 活動圖中的決策點應該反映那些規則的示例。一些內容可能適用於用 SysML 或 對象約束語言 (OCL) 進行表示，並用於證實建模工具生成的工件。然而，該視圖的主要產品是一個文檔。
OV-6b: 運作狀態轉換描述
當一個或多個關鍵架構要素的行爲是事件驅動時，用狀態圖建模可以對理解該行爲特別有用。此處這個方法證明是有效的，生成 OV-6b 。
OV-6c: 運作事件/ 跟蹤描述
OV-6c 描述了外部可視的行爲，即對於與企業用例（見下）相關的每個流和場景來說，從主題系統的觀點看行爲是可見的。您可以利用着重於運作節點（參與者）通過消息與主題系統交互的序列圖來獲取該信息。這些信息表示相關的運作節點對主題系統的請求，或系統向一個或多個那樣的節點的請求。任何作爲那些請求一部分的交換的信息（例如，參數）都由一個 IO 實體類的實例表示。
確定了節點系統關係和相關的信息內容之後，您可以自動生成 OV-2 和 OV-3 所必需的內容。在您確定每種依賴關係之前，通過分析在消息發送者和接受者之間確定的交互和參數向企業環境圖（見上）中添加需求線。
圖 6 舉例說明了一個 OV-6c 產品。
圖 6 ：OV-6c 運作事件/ 跟蹤描述
點擊此處放大
OV-7 邏輯數據模型
OV-7 反映了用於達到企業用例中所表達的功能的關鍵信息的結構和流。此產品的內容應該直接歸因於 OV-6c 構建過程中確定的 IO 實體。
系統視圖產品
包含運作架構的系統必須協作，用以實現運作視圖中指定的任務功能，這些我在第 1 部分文章中提到了。系統視圖（sv ）產品的用途是提供在考慮中的系統的多種透視圖。這些視圖描述了系統的結構並表明如何與企業架構的其他要素相互作用。
各種 sv 產品是從主題系統架構的白盒擴展得來的，這確定了爲了達到所期望的行爲必須相互作用的系統的邏輯和物理組件。這些系統（邏輯組件）和系統節點（物理組件） 是原型的類，並且由系統環境圖表示。這些要素之間的關係表現出創建 sv-10c 序列圖（見下）時所指定的運作或請求消息。其他 sv 產品提供更多關於物理和邏輯系統接口、系統交互，和在運作企業環境下系統的有計劃的演進。
表 1 羅列並描述了系統視圖產品並推薦了一個創建它們的合理順序。後面的部分更詳細地介紹了 sv 的每一種產品。
|
產品 |
標題 |
描述 |
表示 |
創建順序 |
|
SV-1 |
系統接口描述 |
在節點內部和節點之間確定系統和系統組件及其接口。通過實現公共接口的邏輯和物理透視圖的一致建模。 |
含有類、位置，和接口的類圖 |
3 |
|
SV-2 |
系統通信描述 |
爲物理節點及其相關的通信基礎構架建模。 |
複合結構圖 部署圖 |
6 |
|
SV-3 |
系統矩陣 |
爲企業整個架構的環境中的系統和子系統之間的關係建模。 |
存儲模型文本矩陣 導出 XML |
5 |
|
SV-4 |
系統功能描述 |
確定系統行爲及與該行爲相關的信息流。 |
每個系統用例的活動圖 |
8 |
|
SV-5 |
系統功能可溯性矩陣的運作活動 |
將系統內部行爲（實現）映射到運作外部活動上（規範）。 |
存儲模型文本矩陣 |
9 |
|
SV-6 |
系統信息交換矩陣 |
詳細說明系統要素之間的信息交換，包括應用程序和分配給那些要素的硬件。 |
存儲模型文本矩陣 |
10 |
|
SV-7 |
系統性能參數矩陣 |
描述系統要素的性能特徵。 |
存儲模型文本矩陣；導出 XML |
11 |
|
SV-8 |
系統演進描述 |
描述朝着指定的未來實現增加的已計劃的演進。 |
帶有時間線的進度安排或項目計劃 |
12 |
|
SV-9 |
系統技術預測 |
描述很可能影響系統的當前或指定的未來狀態的新興技術。 |
文本文檔 |
13 |
|
SV10a |
系統規則模型 |
描述業務需求或運作任務需求所利用的影響系統功能的約束。 |
也許有或者許沒有合併到模型中（OCL/SysML ）的架構約束 ；模型參考文本文檔中的功能和非功能需求 |
1 |
|
SV-10b |
系統狀態轉換描述 |
描述系統對事件的響應。 |
狀態轉移圖 |
** |
|
SV-10c |
系統時間/ 跟蹤描述 |
根據實現了反映 OV-6c 中確定的行爲的運作場景或關鍵活動的運作序列和活動，描述內部系統行爲。 |
行爲的邏輯和物理實現的序列圖 |
2 （邏輯的） |
|
SV-11 |
物理數據模型 |
描述數據存儲和移動的物理實現。 |
類圖指明模式到 OV-7 中邏輯數據要素的關係 |
7 |
** 狀態轉移圖可選擇地用於爲對需要特殊處理的複雜事件的關鍵實時的響應建模。
sv-1 ：系統接口描述
sv-1 爲主題系統的內部架構創建了基礎。它描述了系統、系統節點，和存在於它們內部及其間的接口。這樣，sv-1 提供了運作視圖和系統視圖之間的聯接。這要求對系統進行邏輯分解並將邏輯功能分配到物理組件上。該視圖中的分類器表示對應運作視圖中確定的每個系統用例流 或場景（源於對主題系統的運作或消息）的邏輯和物理版本的序列圖中的對象。
我們開始來確定構成主題系統的候選邏輯要素。最初的發現過程可能是憑直覺並且根據領域經驗。此處，重點是開始考慮可能構成邏輯子系統的組件。這些可 能最終成爲子系統，甚至是基本的，但該差別還不重要。之後，由於用例的流下和聯合實現的活動，我們給那些爲了實現指定行爲而分配了邏輯功能的要素確定餘下 的位置（以及當我們爲邏輯要素髮現一個需求時的附加邏輯要素）。由該信息，我們可以將序列圖中指示的運作分配給接口，每一個都是由邏輯（類）和物理（位 置）要素實現的。sv-1 圖包含類、位置、接口，和那些系統及系統節點之間的連接。
sv-2 ：系統通信描述
sv-2 稱爲系統通信描述。目的是反映物理節點（位置）及其通信基礎架構，sv-2 是由複合結構圖，一種 uml 2.0 的工件，表示的。複合結構圖表示爲一個明顯地連接到與角色相關的通信口上的角色或對象的容器（參見圖 1 ）。由於潛在的容量和各種與通信連接相關的信息，將這些模型要素與需求存儲庫，如 ibm rational requisitepro® ，中的實體相關聯，利用屬性值作爲支持信息是可取的。
圖 1 ：描述了物理節點及其通信基礎架構的複合結構圖
sv-3 ：系統矩陣
sv-3 是存在於系統分解的任意指定層次中的系統到系統關係的矩陣視圖。至少，矩陣應該確定哪個系統與其他系統有關。必要時，您還可以包含與那些關係的特徵有關的 附加內容。您能從 sv-10c 序列圖中顯示的行爲的邏輯和物理實現中建立起來的關係得到生成 sv-3 的信息內容。
sv-4 ：系統功能描述
sv-4 描述了支持需要的系統行爲所必需的功能和需要的數據流。它採用帶有分配給負責活動的系統要素的分區的活動圖的形式。向活動流中加入對象流，目的是指示指定 的活動所必需的數據對象的輸入和輸出。sv-4 的信息內容提供了另一種來自帶有消息和參數的 sv-10c 序列圖的信息視圖。
sv-5 ：運作活動到系統功能可溯性矩陣
sv-5 提供了運作活動（例如，用例流、場景）和實現了所需行爲的系統功能（運作）之間的可溯性。我們用該信息生成一個列出運作節點、它們必須支持的運作，及那些 運作的實現的分層列表。理論上您要擴展這些內容，包含那些共同協作影響實現的系統或子系統，並且包含發送到那些系統或子系統的消息或運作。
sv-6: 系統信息交換矩陣
sv-6 是一個數據交換矩陣，類似於第 1 部分文章中所描述的 ov-3 ，表示主題系統的組件系統和子系統之間的基於行爲的交互。您可以利用 ibm rational 基於 eclipse 的建模工具，通過獲得 sv-10c 的內容來自動地生成 sv-6 。每個矩陣行表示一個數據交換，由 sv-10c 序列圖中的一個交互中的角色或對象之間所傳遞的數據的特徵所組成。矩陣爲每對交互並交換信息的對象或角色確定一個唯一的數據交換。特定的數據交換特徵與非 功能的需求或設計約束相關。每個信息交換需求（information exchange requirement ，ier ）的內容表示一個數據對象的具體實例，此處，屬性表示 dodaf 所需的數據特徵。
sv-6 強調所交換信息的邏輯和運作特徵。該產品的目的不是盡力獲得體系結構中所交換信息的所有細節，而是要幫助我們瞭解交換的最重要的方面。表 2 和表 3 顯示了相關信息內容的實例，取自 dodaf 規範。 1 此內容要追溯到補充的或非功能的需求。
sv-7 ：系統性能參數矩陣
sv-7 描述了對於有效達到主題系統的任務目標很關鍵的特徵。該信息可以以表格、圖表，或矩陣最好地表示出來。應用領域決定着該視圖的特定內容。在 dodaf 規範中可以得到一個概念的實例作爲參考資料。一個聯合實現表格（joint realization form ）特別爲該意圖而設計，稱爲系統運作規範，還可以通過 ibm rational software services 得到。當完成時，您應該將 sv-7 存儲在與模型相關的文檔文件夾中，或者存儲爲 ibm rational requisitepro 中的可跟蹤的需求文檔。
圖 2 ：系統運作規範表格（sv-7 ）
sv-8 ：系統演進描述
sv-8 是不斷演進的企業環境中系統演進的計劃或進度方案。sv-8 是由調度工具獲取的，如 microsoft project 。關鍵的里程碑是關於對系統的結構和/ 或行爲的變更的增量式的實現。我們推薦將與進度相關的文件存儲在與基於 eclipse 的模型相關的文檔文件夾中。
sv-9 ：系統技術預測
sv-9 確定了很可能影響到系統在其企業環境中的結構或行爲的新興技術。理論上說，您要將技術上增量的變更與 sv-8 中的里程碑聯繫起來，從而簡化整個決策制定和企業管理。
sv-10a ：系統規則模型
sv-10a 獲取限制滿足運作目標所涉及的系統或子系統的行爲的約束。信息以文本形式獲取並以文檔形式生成。您要利用適合組織觀衆的模板來獲取信息。
區別商業規則/ 約束和需求是具有挑戰性的。在這點上，我們應該銘記，活動圖中的決策點應該反映那些規則的具體實例。有一些內容可能適用於用 sysml 或對象約束語言（object constraint language ，ocl ）來表達，並且用於驗證建模工具中的架構工件。然而，該視圖的主要產品是文檔。sv-10a 類似於 ov-6a （第 1 部分文章中所描述的），但反應更低層的系統分解。如同 ov-6a 一樣，我推薦您使用文檔及一個有關的需求管理工具，像 ibm rational requisitepro 。
sv-10b ：系統狀態轉換描述
當一個或多個關鍵架構要素的行爲是事件驅動時，用狀態圖建模在理解該行爲方面特別有用。此處這個方法證明是有效的，生成 sv-10b 。
sv-10c ：系統事件/ 跟蹤描述
sv-10c 爲 ov6c 中確定的每個運作描述了主題系統的內部行爲。我們使用序列圖着重於利用消息交互的系統/ 子系統和系統節點。這些消息表示由相關的系統、子系統，或 系統節點做出的對系統/ 子系統/ 系統節點的請求。運作規範存在於運作視圖的層次中，並且在系統視圖中實現。您通過選擇擁有運作的類、單擊鼠標右鍵，並選擇 dodaf > create operation realizations 來爲實現創造結構。任何作爲那些請求一部分（例如，參數）而交換的信息由 io 實體類的實例表示。每個消息交互還表示一個數據交換，並用於填充 sv-6矩陣。您通過選擇 dodaf > create sv-6 來創建該內容。矩陣顯示在 sv-6 選項卡中。
sv-11 ：物理數據模型
sv-11 是 ov-7 （第 1 部分中所描述的）的補充。我麼使用一個類圖來表示存儲 ov-7 邏輯數據模型和 sv-4 的數據對象所表示的信息所必需的數據庫模式關係。
技術標準視圖產品
技術標準視圖提供了指導或約束系統視圖中描述的系統的實現的指導。在增量地開發系統，用以滿足運作視圖中指定的任務目標的情況下，tv 反映出制定設計決策所依靠的標準和限制因素。
tv 描述了適用於當前體系結構（tv-1 ）和該體系結構演進（tv-2 ）的標準，如表 4 中所描述的。
tv-1 ：技術架構概要文件
tv-1 描述了可能影響運作企業的現有標準和運作約束。dodaf 規範提供了一個示例模板，暗示利用基於文本的文檔可以最好地獲得該信息。我推薦您進一步結合具體標準和它們所影響的架構要素之間的關係，利用像 ibm rational requisitepro 這樣的需求管理工具。您可以將標準的具體特性存儲爲該標準的屬性，以便可溯性的建立成爲一個相當簡單的過程。
tv-2 ：標準技術預測
tv-2 描述了隨着運作企業及其組件系統演進的過程中可能影響到它及其體系結構的潛在的和新興的標準及運作約束。在該產品中獲取了兩類信息：
- 對 tv-1 中提到的標準或約束所進行的預期的變更
- 對標準或與提供新的系統和功能的企業的演進相關聯的新標準所進行的變更
除了追蹤性對於那些屬於上面所述後者範疇實體的 sv-8 和 sv-9 是必需的以外，獲取此信息的方法與 tv-1 的一樣。
結束語
在第二部分文章中，我已經介紹了擴展並補充了第一部分中所介紹的運作視圖（ov ）中獲取的信息的 dodaf 系統視圖（sv ）和技術標準視圖（tv ）產品。我已進一步地介紹了隨着我們從抽象功能到具體的邏輯和物理表示，不斷增加地精心設計企業架構，系統工程團隊 能夠如何利用 dodaf 產品的內容。
一個健壯、可伸縮的過程，外加適當的自動化足以推動在集中的模型存儲庫中的一致的架構內容的開發。這樣的存儲庫提供了對更大的開發組織和運作企業中 的關鍵決策制定者必不可少的實現。ibm rational 通過將已證實的系統工程過程和一個強大的、集成工具集進行整合，將在格式良好的系統架構模型的環境中對遵從 dodaf 產品的創建進行自動化來支持dodaf 的遵從。