美國國防部體系架構(gòu)框架（DoDAF ）使用的 IBM Rational 方法構(gòu)建復(fù)雜系統(tǒng)要求具有了解并管理復(fù)雜關(guān)系的特別能力。徹底地了解企業(yè)架構(gòu) 2 對有效的設(shè)計(jì)、實(shí)現(xiàn)、部署和演進(jìn)系統(tǒng)的維護(hù)是至關(guān)重要的。一個(gè)完整的與該架構(gòu)相符的模型是對該理解的關(guān)鍵 —— 并且對于減少風(fēng)險(xiǎn)及管理系統(tǒng)的復(fù)雜性是必要的。DoDAF 內(nèi)容為我們提供了一個(gè)觀察在增量地定義系統(tǒng)時(shí)所利用的體系結(jié)構(gòu)的“ 窗口” 。 已生成的符合 DoDAF 的報(bào)告支持對主要的面向任務(wù)的系統(tǒng)的贊助及籌款的搜索。然而，通過在系統(tǒng)生命周期的早期描述系統(tǒng)架構(gòu)，系統(tǒng)工程團(tuán)隊(duì)可以從該投資中了解到更加多的價(jià)值。例如，您越早識別出集成挑戰(zhàn)和運(yùn)作依賴，您就會更有效地達(dá)成關(guān)鍵的決策。 IBM Rational 用集成產(chǎn)品的方式全面支持 DoDAF ，這些產(chǎn)品是證實(shí)了的系統(tǒng)工程過程（Rational Unified Process? for Systems Engineering ，或稱 RUP-SE ），和設(shè)計(jì)用來簡化發(fā)現(xiàn)、描述、實(shí)現(xiàn)，和演進(jìn)多種與 DoD 運(yùn)作任務(wù)相關(guān)的復(fù)雜企業(yè)架構(gòu)的功能。 IBM Rational 工具明顯地符合 DoDAF 的規(guī)范，建立在 IBM Rational 的基于 Eclipse 的建模解決方案上，包括 IBM Rational Software Architect? 、IBM Rational Software Modeler? ，和 IBM Rational Systems Developer? 。整個(gè)系統(tǒng)開發(fā)團(tuán)隊(duì)能夠使用用于需求管理的 IBM Rational RequisitePro? 、用于配置管理的 IBM Rational ClearCase? 、用于變更管理的 IBM Rational ClearQuest? ，及其他 IBM Rational 產(chǎn)品。Ready for Rational Partners 所提供的擴(kuò)展功能和插件進(jìn)一步增強(qiáng)了 Systems Modeling Language (SysML) 建模和基于狀態(tài)機(jī)的可執(zhí)行模型的能力。 遵守 DoDAF 的最佳途徑不需要系統(tǒng)開發(fā)的主要工作之外的工作。IBM Rational 方法將 DoDAF 產(chǎn)品與整個(gè)體系結(jié)構(gòu)建模工作合并起來，讓 DoDAF 視圖來表示一個(gè)演進(jìn)的企業(yè)架構(gòu)，該架構(gòu)是與實(shí)現(xiàn)此架構(gòu)的系統(tǒng)相符合且起源于 這個(gè)系統(tǒng)的。 如同任何復(fù)雜的活動一樣，學(xué)習(xí)利用 DoDAF 創(chuàng)建并維護(hù)企業(yè)架構(gòu)需要對系統(tǒng)工程的原則，及有關(guān) DoDAF 知識的熟練運(yùn)用。IBM Rational 能夠很好的提供服務(wù)，并優(yōu)化您的工作。本文余下的部分向您介紹了 DoDAF 并舉例說明了如何在描述企業(yè)體系結(jié)構(gòu)的情況下滿足符合 DoDAF 的需求。 DoDAF 著重于對運(yùn)作企業(yè)的重要架構(gòu)要素之間的關(guān)系進(jìn)行建模。符合 DoDAF 模型的核心要素是節(jié)點(diǎn)（nodes ） 、需求線（needlines ） 、服務(wù)（services ） ，以及信息交換（information exchanges ） ?？偟膩碚f，這些實(shí)體描述了運(yùn)作企業(yè)中重要活動的結(jié)構(gòu)和分配。 · 節(jié)點(diǎn) —— 系統(tǒng)、參與者，和工作人員 。DoDAF 的本質(zhì)要素是節(jié)點(diǎn)，表示邏輯或物理實(shí)體（工作人員、系統(tǒng)，或子系統(tǒng)），在企業(yè)的內(nèi)部或外部運(yùn)行，其任務(wù)是以某種方式與一個(gè)或多個(gè)企業(yè)要素交互。節(jié)點(diǎn)是組成運(yùn)作企業(yè)的復(fù)雜系統(tǒng)架構(gòu)和設(shè)計(jì)的基礎(chǔ)。架構(gòu)將更著重于節(jié)點(diǎn)之間的關(guān)系，而設(shè)計(jì)更多地處理單個(gè)節(jié)點(diǎn)的結(jié)構(gòu)和行為。因此，DoDAF 的主要目標(biāo) —— 以及對運(yùn)作企業(yè)的架構(gòu)建模的好處 —— 是描述節(jié)點(diǎn)可以通過其進(jìn)行協(xié)作以完成任務(wù)的一種方式。在 DoDAF 中，我們處理三種節(jié)點(diǎn)：在運(yùn)作視圖（OV ）中所描述的并表現(xiàn)參與者、工作人員，和系統(tǒng)的聯(lián)合的運(yùn)作節(jié)點(diǎn)（operational nodes ） 、作為實(shí)現(xiàn)運(yùn)作節(jié)點(diǎn)行為的邏輯要素的系統(tǒng)（systems ） ，及表示貯存邏輯系統(tǒng)或子系統(tǒng)的物理要素或位置的系統(tǒng)節(jié)點(diǎn)（system nodes ） 。 · 需求線 —— 關(guān)系及依賴 。在 DoDAF 中，協(xié)作的運(yùn)作節(jié)點(diǎn)之間的關(guān)系表示為需求線（needlines ） 。每一條需求線都表示出一個(gè)節(jié)點(diǎn)向另一個(gè)節(jié)點(diǎn)提供一個(gè)或多個(gè)在運(yùn)行上必要的服務(wù)和相關(guān)信息的需求。需求線是抽象的，因?yàn)樗鼈兛赡鼙硎締蝹€(gè)的服務(wù)或信息交換，或者一組服務(wù)或信息交換。不論在哪種情況下，需求線都舉例說明了，一個(gè)運(yùn)作節(jié)點(diǎn)依賴于另一個(gè)節(jié)點(diǎn)來獲得服務(wù)或信息，并指定了服務(wù)或信息流動的方向。 · 服務(wù) —— 重要的運(yùn)作功能 。服務(wù)表示一個(gè)節(jié)點(diǎn)給予另一個(gè)節(jié)點(diǎn)的一個(gè)或多個(gè)可運(yùn)行的重要功能。每種服務(wù)還隱式或顯式地表示節(jié)點(diǎn)之間的信息傳遞，并且可能被描述為一個(gè)消息或運(yùn)作。 · 信息交換 —— 所傳遞信息的特征 。信息交換與一組功能性的和非功能性的需求相關(guān)，表現(xiàn)出獲取、傳遞或使用信息所受的約束的特征。 復(fù)雜系統(tǒng)開發(fā)的最佳實(shí)踐 通過把所需的 DoDAF 內(nèi)容的生產(chǎn)與精心設(shè)計(jì)企業(yè)架構(gòu)（EA ）及其相關(guān)需求的整個(gè)過程無縫地合并在一起，您可以有效地去除復(fù)雜系統(tǒng)開發(fā)中可感知到的遵從 DoDAF 所帶來的負(fù)擔(dān)。此外，您可以利用在 DoDAF 產(chǎn)品中獲得的非常寶貴的工程信息來減少系統(tǒng)開發(fā)中成本和進(jìn)度安排的風(fēng)險(xiǎn)。 詳細(xì)設(shè)計(jì)架構(gòu)的結(jié)構(gòu)和行為的 IBM Rational 方法是基于已證實(shí)的原則的。“ 系統(tǒng)工程的六條原則” 是一些實(shí)用的指導(dǎo)方針，它們?yōu)楹芎玫毓芾硐到y(tǒng)的演進(jìn)提供了基礎(chǔ)。它們強(qiáng)調(diào)了開發(fā)復(fù)雜系統(tǒng)的組織應(yīng)該關(guān)注的關(guān)鍵領(lǐng)域。它們還使組織能夠評估難題，并分析其原因。 · 分解系統(tǒng)，而不是需求 。在進(jìn)入下一更低層之前，開發(fā)一個(gè)抽象層次。明確地精心設(shè)計(jì)用例及所獲得的行為。務(wù)必不僅考慮邏輯架構(gòu)，還要考慮架構(gòu)的物理或面向位置的方面。為所描述的每個(gè)抽象層次查明并編制邏輯和物理架構(gòu)之間的關(guān)系。對下一個(gè)更低抽象層重復(fù)操作，直至架構(gòu)能足以滿足開發(fā)組織的需求。 · 即要分離又要集成 。為所描述的每個(gè)抽象層分析黑盒及白盒視圖。爭取平衡兩種觀點(diǎn)以避免某一方向上的過度行為。分離太多會導(dǎo)致功能分解和相關(guān)的集成問題，太過強(qiáng)調(diào)集成，您會有錯(cuò)過重要功能問題的危險(xiǎn)。 · 系統(tǒng)和組件應(yīng)協(xié)作，開發(fā)團(tuán)隊(duì)也應(yīng)該這樣 。需要協(xié)作的組件和系統(tǒng)/ 子系統(tǒng)的開發(fā)人員依賴于全面的相關(guān)性知識。開發(fā)人員如果不協(xié)作，您就會增加集成失敗的風(fēng)險(xiǎn)。 · 規(guī)范貫穿架構(gòu)中 。您應(yīng)該了解每個(gè)抽象層上的需求，并利用它們導(dǎo)出在每個(gè)抽象層上協(xié)作的要素功能。 · 在生命周期中要減少風(fēng)險(xiǎn)并增加價(jià)值 。當(dāng)各種資源可以用來實(shí)現(xiàn)此原則時(shí)，就能減少成功的障礙。 · 開發(fā)組織應(yīng)該考慮產(chǎn)品架構(gòu) 。開發(fā)團(tuán)隊(duì)技能的最佳實(shí)踐要求在整個(gè)迭代過程中將責(zé)任從一個(gè)角色移到另一個(gè)角色。組織具有多重互補(bǔ)技能的團(tuán)隊(duì)提供了更多的管理靈活性，并且為組織增加了全面的個(gè)人能力。 風(fēng)險(xiǎn)管理推進(jìn)了企業(yè)架構(gòu)開發(fā)的整個(gè)過程。嚴(yán)格地應(yīng)用迭代過程，并使用標(biāo)準(zhǔn)的符號，如統(tǒng)一建模語言（Unified Modeling Language ，UML ）會形成在連續(xù)的更低層抽象層次上的對系統(tǒng)結(jié)果和行為的多種觀點(diǎn)的全面可視化表示。循環(huán)地對子系統(tǒng)定義層和內(nèi)部設(shè)計(jì)應(yīng)用這些原則可形成一個(gè)完整、一致的架構(gòu)工程模型。而這又為復(fù)雜系統(tǒng)的設(shè)計(jì)、實(shí)現(xiàn)、開發(fā)、管理，和受控的演進(jìn)提供了基礎(chǔ)。 DoDAF 構(gòu)成了視圖周圍的架構(gòu)信息。全視圖(AV) 產(chǎn)品的目的是提供在運(yùn)作企業(yè)環(huán)境中的主題系統(tǒng)的全景透視圖，并說明了拱型的關(guān)系，如 Concept of Operation (CONOPS) 和關(guān)鍵任務(wù)目標(biāo)及策略，以及架構(gòu)上的重要術(shù)語的整合的詞典。 運(yùn)作視圖 (OV) 著重于主題系統(tǒng)的表面上可見的結(jié)構(gòu)和行為。此視圖描述了運(yùn)作節(jié)點(diǎn)及其關(guān)系，并確定反映任務(wù)需求的依賴，因而為企業(yè)定義和演進(jìn)提供全部的環(huán)境。 認(rèn)識到內(nèi)部結(jié)構(gòu)和行為是 系統(tǒng)視圖(SV) 的焦點(diǎn)，它將功能和非功能需求（來自運(yùn)作視圖）的嚴(yán)格分配合并到邏輯和物理系統(tǒng)要素和接口上。 技術(shù)標(biāo)準(zhǔn)視圖 (TV) 中反映出對企業(yè)的運(yùn)作架構(gòu)的標(biāo)準(zhǔn)約束，并描述了系統(tǒng)的當(dāng)前和未來狀態(tài)。 圖 1 ：DoDAF 視圖間的關(guān)系 DoDAF 視圖內(nèi)及之間的一致性是關(guān)鍵的。DoDAF 視圖的最佳推導(dǎo)要求多重抽象層次（即，系統(tǒng)分解）之間建模的一致性。當(dāng)我們深入到架構(gòu)模型中，向企業(yè)的連續(xù)抽象層次中循環(huán)地應(yīng)用嚴(yán)格的系統(tǒng)架構(gòu)發(fā)現(xiàn)過程時(shí)，我們對要素有了更多的了解，并可能使用其他方法來表示其特征。例如，最初我們可能用用例或環(huán)境圖的方式來表示滿足用戶需求的復(fù)雜系統(tǒng)。當(dāng)我們對所支持的活動（系統(tǒng)白盒行為）有更多的了解時(shí)，我們可能增加類、活動，和/ 或序列圖來反映額外的細(xì)節(jié)。在一個(gè)圖中作為參與者進(jìn)行描述的節(jié)點(diǎn)（nodes ） 在其它圖中可能更適合表示為類或?qū)ο?。組成子系統(tǒng)的類運(yùn)作的集合可能實(shí)現(xiàn)服務(wù)（services ） 。 在確定對每個(gè)核心 DoDAF 要素建模有多好時(shí)，您必須首先了解該要素下的必要語義，以及所有可應(yīng)用的約束條件，然后在給定的整個(gè)工程工作環(huán)境中應(yīng)用恰當(dāng)?shù)谋硎痉?。此環(huán)境包括建模工作的風(fēng)險(xiǎn)、復(fù)雜性、工具、表示法，和目標(biāo)。 生成 DoDAF 視圖的全部過程是迭代 且增量的 。隨著對架構(gòu)信息的獲取更加廣泛與深入，所有視圖（AV-1 和 AV-2 ）在進(jìn)行著演進(jìn)。將 AV-1 用作基礎(chǔ)，分析運(yùn)作企業(yè)的架構(gòu)的交互以及主題系統(tǒng)，這導(dǎo)致發(fā)現(xiàn)了系統(tǒng)和運(yùn)作節(jié)點(diǎn)之間的高層交互。完全地描述這些高層關(guān)系是運(yùn)作視圖的著重點(diǎn)。 只有在您充分了解了外部系統(tǒng)行為（在企業(yè)層）之后，您才能繼續(xù)詳細(xì)描述系統(tǒng)視圖。這是我們開始設(shè)計(jì)并組織為全面的開發(fā)提供基礎(chǔ)的內(nèi)部行為和子系統(tǒng)交互的地方。這里，我們還將協(xié)調(diào)多種讓我們通過聯(lián)合實(shí)現(xiàn)的實(shí)踐和用例流來處理必要的運(yùn)作行為的物理和 邏輯實(shí)現(xiàn)的觀點(diǎn)。 下面表格簡要地描述了所有視圖產(chǎn)品，以及您創(chuàng)建它們的順序。
DoDAF 所有視圖(AV) 產(chǎn)品概述了在主題系統(tǒng)演進(jìn)過程中開發(fā)、部署，并管理這些系統(tǒng)所處于的環(huán)境。這個(gè)概述描述了任務(wù)目標(biāo)、策略、運(yùn)作概念，及運(yùn)作的一般環(huán)境，和相關(guān)的專門術(shù)語。 AV-1 ：概述和總結(jié)信息 AV-1 是對運(yùn)作環(huán)境和要在演進(jìn)的系統(tǒng)中實(shí)現(xiàn)的任務(wù)功能的文字概述。其焦點(diǎn)是需要在該環(huán)境內(nèi)建立的主題系統(tǒng)或企業(yè)。Relevant Concepts of Operations (CONOPS) 和策略在抽象層次上表示出來，適用于執(zhí)行的領(lǐng)導(dǎo)來簡化決策的制定。AV-1 的內(nèi)容表現(xiàn)出獲取必要商業(yè)驅(qū)動的指導(dǎo)或觀察，以及正在開發(fā)的主題系統(tǒng)的需求。 需求方或開發(fā)組織可能準(zhǔn)備 AV-1 ，盡管，同所有 DoDAF 視圖產(chǎn)品一樣，與擁有廣泛的運(yùn)作經(jīng)驗(yàn)的問題領(lǐng)域?qū)＜?span lang='EN-US'> (SME) 的實(shí)質(zhì)交互是必要的。以此處描述的方法，您可以利用文字處理器生成 AV-1 文檔并將參考鏈結(jié)與包含可視化 DoDAF 產(chǎn)品的模型相關(guān)聯(lián)。 AV-2 ：整合的字典 AV-2 表示一個(gè)簡單的，但對系統(tǒng)和軟件開發(fā)很必要的概念。通過建立一個(gè)與架構(gòu)相關(guān)的定義和可能模糊的術(shù)語的單一集中的詞匯表，就可以充分地滿足對含義的一致性和清晰性的需求。 IBM Rational 方法將由 IBM Rational 的基于 Eclipse 的建模工具，包括 IBM Rational Systems Developer 、IBM Rational Software Architect ，和 IBM Rational Software Modeler ，所管理的模型存儲庫中的集成字典的不斷演進(jìn)的版本合并起來。在您生成模型要素時(shí)，您可以將要素合并到 IBM Rational 的基于 Eclipse 的建模工具中的工程信息中（您隨時(shí)都可以從這些信息中提取 AV-2 ）。所有與 DoDAF 原型相關(guān)的圖形化模型要素可以以此方式自動獲取。您需要手動地添加文本參考，或者通過一些其他的工具，如 IBM Rational RequisitePro ，訪問它們。 DoDAF 運(yùn)作視圖是由各種產(chǎn)品組成的，這些產(chǎn)品提供了對整個(gè)企業(yè)環(huán)境中的主題系統(tǒng)的外部結(jié)構(gòu)和行為的多種觀點(diǎn)。在這些視圖中，我們描述了系統(tǒng)及其角色之間的交互，系統(tǒng)所需的任務(wù)目標(biāo)，及為了實(shí)現(xiàn)那些目標(biāo)的必要依賴和交互。 OV 的焦點(diǎn)是影響該任務(wù)的那些需求和功能。系統(tǒng)視圖 (SV) 說明了 OV 是如何實(shí)現(xiàn)的。下面的表格簡要地說明了 OV 產(chǎn)品，并建議了一個(gè)創(chuàng)建這些產(chǎn)品的順序。
* OV-1 的內(nèi)容首先開始，但到 OV-2 完成時(shí)才能完成 OV-1 的圖形。 圖 2 的活動圖中顯示了可能生成產(chǎn)品的順序。所提議的順序是基于建立在上面談?wù)摰南到y(tǒng)工程的六個(gè)原則之上的架構(gòu)的發(fā)現(xiàn)過程的。依照此順序，您可以有效地生成符合 DoDAF 的產(chǎn)品，而不用減少定義企業(yè)架構(gòu)的主要任務(wù)。
圖 2 ：生成 DoDAF AV 和 OV 產(chǎn)品的推薦順序 OV-1: 高級運(yùn)作概念圖 OV-1 簡明扼要地傳達(dá)了運(yùn)作企業(yè)環(huán)境中的主題系統(tǒng)的范圍。OV-1 圖形描述是出自畫家之手的產(chǎn)品，反映來自多個(gè)源的內(nèi)容。OV-1 的主要信息來源是 AV-1 概要和總結(jié)（Overview and Summary ）文檔，即運(yùn)作環(huán)境圖（Operational Context Diagram ），和企業(yè)用例圖（Enterprise Use-Case Diagram ）。我們以主題系統(tǒng)開始繪制企業(yè)用例圖，并確定所有與該系統(tǒng)交互的外部系統(tǒng)和組織實(shí)體。我們將這些交互要素描繪為參與者或角色。然而，為每個(gè)歸就于參與者的運(yùn)作目標(biāo)向圖中加入用例。在適當(dāng)?shù)奈恢眉尤?span lang='EN-US'> UML ? 通信? 原型的關(guān)聯(lián)。 許多參與者或角色在組織要素中協(xié)作，為了滿足任務(wù)的需求。向組織要素聚集參與者或角色可以使得識別出運(yùn)作節(jié)點(diǎn)，利用類圖來獲取，即指定的運(yùn)作環(huán)境圖。系統(tǒng)架構(gòu)師和其他 SME 與圖形畫家合作繪制出 OV-1 圖（參見圖 3 ）中的運(yùn)作環(huán)境圖，為適合執(zhí)行層的觀眾。由于此圖與在開發(fā)的系統(tǒng)有關(guān)，所以它為運(yùn)作企業(yè)的外部可視架構(gòu)的構(gòu)建提供了基礎(chǔ)。該圖的內(nèi)容會隨著獲取的更多信息及生成的額外的 DoDAF 產(chǎn)品而演進(jìn)的。 圖 3 ：OV-1 高層次圖形 在多個(gè)參與者表示運(yùn)作節(jié)點(diǎn)中的過程的地方，您可能需要將與那些參與者相關(guān)的角色集合到一起。隨后由運(yùn)作節(jié)點(diǎn)（參與者集合）和該系統(tǒng)之間集合的交互，或需求線來表示參與者與主題系統(tǒng)之間的交互。與那些參與者相關(guān)的 IO 實(shí)體也與指定的運(yùn)作節(jié)點(diǎn)關(guān)聯(lián)起來。 OV-2: 運(yùn)作節(jié)點(diǎn)連接描述 OV-2 確定并為運(yùn)作節(jié)點(diǎn)之間的運(yùn)作依賴建模。DoDAF 將這些依賴定義為需求線（needlines ） 。有兩種主要的確定需求線的方法： 1. 確定企業(yè)用例圖中每個(gè)? 通信? 關(guān)聯(lián)中所表現(xiàn)出來的依賴的本質(zhì)，并指定相應(yīng)的需求線。給需求線一個(gè)定向的組件，使其能從消費(fèi)者（對于該關(guān)系）導(dǎo)航到服務(wù)或信息的提供者。 2. 等到您開始詳述用例流和場景并在 OV-6c 序列圖（見下）中獲得它們的時(shí)候。這里，您可以確定具體的對象或角色交互，這可以將其提到有代表性的需求線上。 第一種選擇是手動過程，由于需要某種層次的工程/ 或架構(gòu)分析。第二種選擇是讓您利用 IBM Rational 的基于 Eclipse 的建模工具的一些功能來自動地由手動生成的序列圖中的內(nèi)容填充需求線（和 OV-3 Information Exchange Requirements ，或 IERs ）。后一種方法擁有保證 OV-2 、OV-3 ，和 OV-6c 之間的一致性的額外優(yōu)勢，因?yàn)樗鼈儗碓从谕瑯拥哪Ｐ托畔ⅰ?span lang='EN-US'> 一條需求線可能代表許多信息交換或服務(wù)依賴。因此，一旦您確定了任意兩個(gè)環(huán)境圖要素之間的需求線，就不適合再添加指向同一方向的需求線了。圖 4 例舉了針對 OV-2 示例的需求線。
圖 4 ：帶有需求線的 OV-2 示例 注意： UML 2.0 引入了新的分類器，協(xié)作（Collaboration ）。與協(xié)作相關(guān)的語義為您提供了更有力地描述關(guān)系的潛能。您可以指定關(guān)聯(lián)任務(wù)、模式、模板和相關(guān)參數(shù)。您還可以將與協(xié)作相關(guān)的信息例示為協(xié)作事件，進(jìn)一步指定每個(gè)可能的 IER 。增大帶有類和復(fù)合結(jié)構(gòu)圖（分別參照協(xié)作集協(xié)作事件）的 DoDAF 表示的極小集是值得的。UML 語言參考手冊 4 對這些 UML 要素進(jìn)行了全面的討論。 OV-3: 運(yùn)作信息交換矩陣 OV-3 是共同地表示 OV-2 的需求線的 IER 矩陣。通過參考 OV-6c 的內(nèi)容，可以利用 IBM Rational Systems Developer 設(shè)計(jì)和開發(fā)工具自動地生成 OV-3 。OV-3 矩陣中的每一行表示一個(gè) IER ，由在 OV-6c 序列圖的交互中的角色和對象間轉(zhuǎn)移的數(shù)據(jù)的特征組成。矩陣為每組交互并交換信息的對象或角色確定截然不同的 IER 。具體的 IER 特征與非功能需求或設(shè)計(jì)約束相關(guān)。每個(gè) IER 的內(nèi)容都表示 OV-6c IO 實(shí)體類（見下）的實(shí)例，在此，屬性表示 DoDAF 需要的數(shù)據(jù)特征。因此，矩陣中的每個(gè)信息要素都應(yīng)該追溯到邏輯數(shù)據(jù)模型（Logical Data Model ），即 OV-7 。 OV-3 強(qiáng)調(diào)架構(gòu)中交換的信息的邏輯和運(yùn)作特性。它不打算極力地獲取信息交換的所有細(xì)節(jié)，而是作為一種幫助您了解重要交換的重要方面的機(jī)制。圖 5 舉例說明了適當(dāng)?shù)脑敿?xì)級別。 5 此內(nèi)容要追溯到補(bǔ)充的或非功能的需求。
圖 5 ：OV-3 信息交換矩陣示例 OV-4: 命令關(guān)系圖表 OV-4 為影響到企業(yè)運(yùn)作架構(gòu)的組織實(shí)體及企業(yè)系統(tǒng)之間的關(guān)系建模。具體的組織要素可能作為候選角色，即組成 OV-6c （見下）的交互圖中的運(yùn)作節(jié)點(diǎn)的實(shí)例。OV-4 由自由形式的圖表示，在該圖中，組織要素可能作為 OV-6c 序列圖中運(yùn)作節(jié)點(diǎn)的實(shí)例的候選。 注意： 一些實(shí)施者已經(jīng)選擇創(chuàng)建該圖，但幾乎沒有顯示出 OV-4 和余下的 DoDAF 視圖之間的映射。 OV-5: 角色和指責(zé)圖 OV-5 闡明了與完成運(yùn)作企業(yè)環(huán)境中的關(guān)鍵任務(wù)目標(biāo)有關(guān)的角色、責(zé)任，和執(zhí)行順序。OV-5 是運(yùn)作企業(yè)的外部可視行為的圖形表示，由分配到組件系統(tǒng)的活動流表示。為了使行為和支持?jǐn)?shù)據(jù)之間緊耦合，還提供與這些活動相關(guān)的重要數(shù)據(jù)流。結(jié)合需求和用例規(guī)范的文字內(nèi)容的 OV-5 較大地提高了系統(tǒng)工程團(tuán)隊(duì)的能力，以確保企業(yè)架構(gòu)及方式（以此方式支持任務(wù)）的運(yùn)作透視圖中的完整性、明確性，和一致性。 OV-6a: 運(yùn)作規(guī)則模型 OV-6a 獲取對用于達(dá)到運(yùn)作企業(yè)的環(huán)境和主題系統(tǒng)中的任務(wù)結(jié)果的運(yùn)作過程的約束。以文字形式獲取信息并編制成文檔形式。向組織的信息接收者提供模板。OV-5 活動圖中的決策點(diǎn)應(yīng)該反映那些規(guī)則的示例。一些內(nèi)容可能適用于用 SysML 或 對象約束語言 (OCL) 進(jìn)行表示，并用于證實(shí)建模工具生成的工件。然而，該視圖的主要產(chǎn)品是一個(gè)文檔。 OV-6b: 運(yùn)作狀態(tài)轉(zhuǎn)換描述 當(dāng)一個(gè)或多個(gè)關(guān)鍵架構(gòu)要素的行為是事件驅(qū)動時(shí)，用狀態(tài)圖建?？梢詫斫庠撔袨樘貏e有用。此處這個(gè)方法證明是有效的，生成 OV-6b 。 OV-6c: 運(yùn)作事件/ 跟蹤描述 OV-6c 描述了外部可視的行為，即對于與企業(yè)用例（見下）相關(guān)的每個(gè)流和場景來說，從主題系統(tǒng)的觀點(diǎn)看行為是可見的。您可以利用著重于運(yùn)作節(jié)點(diǎn)（參與者）通過消息與主題系統(tǒng)交互的序列圖來獲取該信息。這些信息表示相關(guān)的運(yùn)作節(jié)點(diǎn)對主題系統(tǒng)的請求，或系統(tǒng)向一個(gè)或多個(gè)那樣的節(jié)點(diǎn)的請求。任何作為那些請求一部分的交換的信息（例如，參數(shù)）都由一個(gè) IO 實(shí)體類的實(shí)例表示。 確定了節(jié)點(diǎn)系統(tǒng)關(guān)系和相關(guān)的信息內(nèi)容之后，您可以自動生成 OV-2 和 OV-3 所必需的內(nèi)容。在您確定每種依賴關(guān)系之前，通過分析在消息發(fā)送者和接受者之間確定的交互和參數(shù)向企業(yè)環(huán)境圖（見上）中添加需求線。 圖 6 舉例說明了一個(gè) OV-6c 產(chǎn)品。
圖 6 ：OV-6c 運(yùn)作事件/ 跟蹤描述 OV-7 邏輯數(shù)據(jù)模型 OV-7 反映了用于達(dá)到企業(yè)用例中所表達(dá)的功能的關(guān)鍵信息的結(jié)構(gòu)和流。此產(chǎn)品的內(nèi)容應(yīng)該直接歸因于 OV-6c 構(gòu)建過程中確定的 IO 實(shí)體。 系統(tǒng)視圖產(chǎn)品 包含運(yùn)作架構(gòu)的系統(tǒng)必須協(xié)作，用以實(shí)現(xiàn)運(yùn)作視圖中指定的任務(wù)功能，這些我在第 1 部分文章中提到了。系統(tǒng)視圖（sv ）產(chǎn)品的用途是提供在考慮中的系統(tǒng)的多種透視圖。這些視圖描述了系統(tǒng)的結(jié)構(gòu)并表明如何與企業(yè)架構(gòu)的其他要素相互作用。 各種 sv 產(chǎn)品是從主題系統(tǒng)架構(gòu)的白盒擴(kuò)展得來的，這確定了為了達(dá)到所期望的行為必須相互作用的系統(tǒng)的邏輯和物理組件。這些系統(tǒng)（邏輯組件）和系統(tǒng)節(jié)點(diǎn)（物理組件） 是原型的類，并且由系統(tǒng)環(huán)境圖表示。這些要素之間的關(guān)系表現(xiàn)出創(chuàng)建 sv-10c 序列圖（見下）時(shí)所指定的運(yùn)作或請求消息。其他 sv 產(chǎn)品提供更多關(guān)于物理和邏輯系統(tǒng)接口、系統(tǒng)交互，和在運(yùn)作企業(yè)環(huán)境下系統(tǒng)的有計(jì)劃的演進(jìn)。 表 1 羅列并描述了系統(tǒng)視圖產(chǎn)品并推薦了一個(gè)創(chuàng)建它們的合理順序。后面的部分更詳細(xì)地介紹了 sv 的每一種產(chǎn)品。
** 狀態(tài)轉(zhuǎn)移圖可選擇地用于為對需要特殊處理的復(fù)雜事件的關(guān)鍵實(shí)時(shí)的響應(yīng)建模。 sv-1 ：系統(tǒng)接口描述 sv-1 為主題系統(tǒng)的內(nèi)部架構(gòu)創(chuàng)建了基礎(chǔ)。它描述了系統(tǒng)、系統(tǒng)節(jié)點(diǎn)，和存在于它們內(nèi)部及其間的接口。這樣，sv-1 提供了運(yùn)作視圖和系統(tǒng)視圖之間的聯(lián)接。這要求對系統(tǒng)進(jìn)行邏輯分解并將邏輯功能分配到物理組件上。該視圖中的分類器表示對應(yīng)運(yùn)作視圖中確定的每個(gè)系統(tǒng)用例流 或場景（源于對主題系統(tǒng)的運(yùn)作或消息）的邏輯和物理版本的序列圖中的對象。 我們開始來確定構(gòu)成主題系統(tǒng)的候選邏輯要素。最初的發(fā)現(xiàn)過程可能是憑直覺并且根據(jù)領(lǐng)域經(jīng)驗(yàn)。此處，重點(diǎn)是開始考慮可能構(gòu)成邏輯子系統(tǒng)的組件。這些可 能最終成為子系統(tǒng)，甚至是基本的，但該差別還不重要。之后，由于用例的流下和聯(lián)合實(shí)現(xiàn)的活動，我們給那些為了實(shí)現(xiàn)指定行為而分配了邏輯功能的要素確定余下 的位置（以及當(dāng)我們?yōu)檫壿嬕匕l(fā)現(xiàn)一個(gè)需求時(shí)的附加邏輯要素）。由該信息，我們可以將序列圖中指示的運(yùn)作分配給接口，每一個(gè)都是由邏輯（類）和物理（位 置）要素實(shí)現(xiàn)的。sv-1 圖包含類、位置、接口，和那些系統(tǒng)及系統(tǒng)節(jié)點(diǎn)之間的連接。 sv-2 ：系統(tǒng)通信描述 sv-2 稱為系統(tǒng)通信描述。目的是反映物理節(jié)點(diǎn)（位置）及其通信基礎(chǔ)架構(gòu)，sv-2 是由復(fù)合結(jié)構(gòu)圖，一種 uml 2.0 的工件，表示的。復(fù)合結(jié)構(gòu)圖表示為一個(gè)明顯地連接到與角色相關(guān)的通信口上的角色或?qū)ο蟮娜萜鳎▍⒁妶D 1 ）。由于潛在的容量和各種與通信連接相關(guān)的信息，將這些模型要素與需求存儲庫，如 ibm rational requisitepro? ，中的實(shí)體相關(guān)聯(lián)，利用屬性值作為支持信息是可取的。 圖 1 ：描述了物理節(jié)點(diǎn)及其通信基礎(chǔ)架構(gòu)的復(fù)合結(jié)構(gòu)圖 sv-3 ：系統(tǒng)矩陣 sv-3 是存在于系統(tǒng)分解的任意指定層次中的系統(tǒng)到系統(tǒng)關(guān)系的矩陣視圖。至少，矩陣應(yīng)該確定哪個(gè)系統(tǒng)與其他系統(tǒng)有關(guān)。必要時(shí)，您還可以包含與那些關(guān)系的特征有關(guān)的 附加內(nèi)容。您能從 sv-10c 序列圖中顯示的行為的邏輯和物理實(shí)現(xiàn)中建立起來的關(guān)系得到生成 sv-3 的信息內(nèi)容。 sv-4 ：系統(tǒng)功能描述 sv-4 描述了支持需要的系統(tǒng)行為所必需的功能和需要的數(shù)據(jù)流。它采用帶有分配給負(fù)責(zé)活動的系統(tǒng)要素的分區(qū)的活動圖的形式。向活動流中加入對象流，目的是指示指定 的活動所必需的數(shù)據(jù)對象的輸入和輸出。sv-4 的信息內(nèi)容提供了另一種來自帶有消息和參數(shù)的 sv-10c 序列圖的信息視圖。 sv-5 ：運(yùn)作活動到系統(tǒng)功能可溯性矩陣 sv-5 提供了運(yùn)作活動（例如，用例流、場景）和實(shí)現(xiàn)了所需行為的系統(tǒng)功能（運(yùn)作）之間的可溯性。我們用該信息生成一個(gè)列出運(yùn)作節(jié)點(diǎn)、它們必須支持的運(yùn)作，及那些 運(yùn)作的實(shí)現(xiàn)的分層列表。理論上您要擴(kuò)展這些內(nèi)容，包含那些共同協(xié)作影響實(shí)現(xiàn)的系統(tǒng)或子系統(tǒng)，并且包含發(fā)送到那些系統(tǒng)或子系統(tǒng)的消息或運(yùn)作。 sv-6: 系統(tǒng)信息交換矩陣 sv-6 是一個(gè)數(shù)據(jù)交換矩陣，類似于第 1 部分文章中所描述的 ov-3 ，表示主題系統(tǒng)的組件系統(tǒng)和子系統(tǒng)之間的基于行為的交互。您可以利用 ibm rational 基于 eclipse 的建模工具，通過獲得 sv-10c 的內(nèi)容來自動地生成 sv-6 。每個(gè)矩陣行表示一個(gè)數(shù)據(jù)交換，由 sv-10c 序列圖中的一個(gè)交互中的角色或?qū)ο笾g所傳遞的數(shù)據(jù)的特征所組成。矩陣為每對交互并交換信息的對象或角色確定一個(gè)唯一的數(shù)據(jù)交換。特定的數(shù)據(jù)交換特征與非 功能的需求或設(shè)計(jì)約束相關(guān)。每個(gè)信息交換需求（information exchange requirement ，ier ）的內(nèi)容表示一個(gè)數(shù)據(jù)對象的具體實(shí)例，此處，屬性表示 dodaf 所需的數(shù)據(jù)特征。 sv-6 強(qiáng)調(diào)所交換信息的邏輯和運(yùn)作特征。該產(chǎn)品的目的不是盡力獲得體系結(jié)構(gòu)中所交換信息的所有細(xì)節(jié)，而是要幫助我們了解交換的最重要的方面。表 2 和表 3 顯示了相關(guān)信息內(nèi)容的實(shí)例，取自 dodaf 規(guī)范。 1 此內(nèi)容要追溯到補(bǔ)充的或非功能的需求。 sv-7 ：系統(tǒng)性能參數(shù)矩陣 sv-7 描述了對于有效達(dá)到主題系統(tǒng)的任務(wù)目標(biāo)很關(guān)鍵的特征。該信息可以以表格、圖表，或矩陣最好地表示出來。應(yīng)用領(lǐng)域決定著該視圖的特定內(nèi)容。在 dodaf 規(guī)范中可以得到一個(gè)概念的實(shí)例作為參考資料。一個(gè)聯(lián)合實(shí)現(xiàn)表格（joint realization form ）特別為該意圖而設(shè)計(jì)，稱為系統(tǒng)運(yùn)作規(guī)范，還可以通過 ibm rational software services 得到。當(dāng)完成時(shí)，您應(yīng)該將 sv-7 存儲在與模型相關(guān)的文檔文件夾中，或者存儲為 ibm rational requisitepro 中的可跟蹤的需求文檔。 圖 2 ：系統(tǒng)運(yùn)作規(guī)范表格（sv-7 ） sv-8 ：系統(tǒng)演進(jìn)描述 sv-8 是不斷演進(jìn)的企業(yè)環(huán)境中系統(tǒng)演進(jìn)的計(jì)劃或進(jìn)度方案。sv-8 是由調(diào)度工具獲取的，如 microsoft project 。關(guān)鍵的里程碑是關(guān)于對系統(tǒng)的結(jié)構(gòu)和/ 或行為的變更的增量式的實(shí)現(xiàn)。我們推薦將與進(jìn)度相關(guān)的文件存儲在與基于 eclipse 的模型相關(guān)的文檔文件夾中。 sv-9 ：系統(tǒng)技術(shù)預(yù)測 sv-9 確定了很可能影響到系統(tǒng)在其企業(yè)環(huán)境中的結(jié)構(gòu)或行為的新興技術(shù)。理論上說，您要將技術(shù)上增量的變更與 sv-8 中的里程碑聯(lián)系起來，從而簡化整個(gè)決策制定和企業(yè)管理。 sv-10a ：系統(tǒng)規(guī)則模型 sv-10a 獲取限制滿足運(yùn)作目標(biāo)所涉及的系統(tǒng)或子系統(tǒng)的行為的約束。信息以文本形式獲取并以文檔形式生成。您要利用適合組織觀眾的模板來獲取信息。 區(qū)別商業(yè)規(guī)則/ 約束和需求是具有挑戰(zhàn)性的。在這點(diǎn)上，我們應(yīng)該銘記，活動圖中的決策點(diǎn)應(yīng)該反映那些規(guī)則的具體實(shí)例。有一些內(nèi)容可能適用于用 sysml 或?qū)ο蠹s束語言（object constraint language ，ocl ）來表達(dá)，并且用于驗(yàn)證建模工具中的架構(gòu)工件。然而，該視圖的主要產(chǎn)品是文檔。sv-10a 類似于 ov-6a （第 1 部分文章中所描述的），但反應(yīng)更低層的系統(tǒng)分解。如同 ov-6a 一樣，我推薦您使用文檔及一個(gè)有關(guān)的需求管理工具，像 ibm rational requisitepro 。 sv-10b ：系統(tǒng)狀態(tài)轉(zhuǎn)換描述 當(dāng)一個(gè)或多個(gè)關(guān)鍵架構(gòu)要素的行為是事件驅(qū)動時(shí)，用狀態(tài)圖建模在理解該行為方面特別有用。此處這個(gè)方法證明是有效的，生成 sv-10b 。 sv-10c ：系統(tǒng)事件/ 跟蹤描述 sv-10c 為 ov6c 中確定的每個(gè)運(yùn)作描述了主題系統(tǒng)的內(nèi)部行為。我們使用序列圖著重于利用消息交互的系統(tǒng)/ 子系統(tǒng)和系統(tǒng)節(jié)點(diǎn)。這些消息表示由相關(guān)的系統(tǒng)、子系統(tǒng)，或 系統(tǒng)節(jié)點(diǎn)做出的對系統(tǒng)/ 子系統(tǒng)/ 系統(tǒng)節(jié)點(diǎn)的請求。運(yùn)作規(guī)范存在于運(yùn)作視圖的層次中，并且在系統(tǒng)視圖中實(shí)現(xiàn)。您通過選擇擁有運(yùn)作的類、單擊鼠標(biāo)右鍵，并選擇 dodaf > create operation realizations 來為實(shí)現(xiàn)創(chuàng)造結(jié)構(gòu)。任何作為那些請求一部分（例如，參數(shù)）而交換的信息由 io 實(shí)體類的實(shí)例表示。每個(gè)消息交互還表示一個(gè)數(shù)據(jù)交換，并用于填充 sv-6 矩陣。您通過選擇 dodaf > create sv-6 來創(chuàng)建該內(nèi)容。矩陣顯示在 sv-6 選項(xiàng)卡中。 sv-11 ：物理數(shù)據(jù)模型 sv-11 是 ov-7 （第 1 部分中所描述的）的補(bǔ)充。我么使用一個(gè)類圖來表示存儲 ov-7 邏輯數(shù)據(jù)模型和 sv-4 的數(shù)據(jù)對象所表示的信息所必需的數(shù)據(jù)庫模式關(guān)系。 技術(shù)標(biāo)準(zhǔn)視圖產(chǎn)品 技術(shù)標(biāo)準(zhǔn)視圖提供了指導(dǎo)或約束系統(tǒng)視圖中描述的系統(tǒng)的實(shí)現(xiàn)的指導(dǎo)。在增量地開發(fā)系統(tǒng)，用以滿足運(yùn)作視圖中指定的任務(wù)目標(biāo)的情況下，tv 反映出制定設(shè)計(jì)決策所依靠的標(biāo)準(zhǔn)和限制因素。 tv 描述了適用于當(dāng)前體系結(jié)構(gòu)（tv-1 ）和該體系結(jié)構(gòu)演進(jìn)（tv-2 ）的標(biāo)準(zhǔn)，如表 4 中所描述的。 tv-1 ：技術(shù)架構(gòu)概要文件 tv-1 描述了可能影響運(yùn)作企業(yè)的現(xiàn)有標(biāo)準(zhǔn)和運(yùn)作約束。dodaf 規(guī)范提供了一個(gè)示例模板，暗示利用基于文本的文檔可以最好地獲得該信息。我推薦您進(jìn)一步結(jié)合具體標(biāo)準(zhǔn)和它們所影響的架構(gòu)要素之間的關(guān)系，利用像 ibm rational requisitepro 這樣的需求管理工具。您可以將標(biāo)準(zhǔn)的具體特性存儲為該標(biāo)準(zhǔn)的屬性，以便可溯性的建立成為一個(gè)相當(dāng)簡單的過程。 tv-2 ：標(biāo)準(zhǔn)技術(shù)預(yù)測 tv-2 描述了隨著運(yùn)作企業(yè)及其組件系統(tǒng)演進(jìn)的過程中可能影響到它及其體系結(jié)構(gòu)的潛在的和新興的標(biāo)準(zhǔn)及運(yùn)作約束。在該產(chǎn)品中獲取了兩類信息：
除了追蹤性對于那些屬于上面所述后者范疇實(shí)體的 sv-8 和 sv-9 是必需的以外，獲取此信息的方法與 tv-1 的一樣。 結(jié)束語 在第二部分文章中，我已經(jīng)介紹了擴(kuò)展并補(bǔ)充了第一部分中所介紹的運(yùn)作視圖（ov ）中獲取的信息的 dodaf 系統(tǒng)視圖（sv ）和技術(shù)標(biāo)準(zhǔn)視圖（tv ）產(chǎn)品。我已進(jìn)一步地介紹了隨著我們從抽象功能到具體的邏輯和物理表示，不斷增加地精心設(shè)計(jì)企業(yè)架構(gòu)，系統(tǒng)工程團(tuán)隊(duì) 能夠如何利用 dodaf 產(chǎn)品的內(nèi)容。 一個(gè)健壯、可伸縮的過程，外加適當(dāng)?shù)淖詣踊阋酝苿釉诩械哪Ｐ痛鎯熘械囊恢碌募軜?gòu)內(nèi)容的開發(fā)。這樣的存儲庫提供了對更大的開發(fā)組織和運(yùn)作企業(yè)中 的關(guān)鍵決策制定者必不可少的實(shí)現(xiàn)。ibm rational 通過將已證實(shí)的系統(tǒng)工程過程和一個(gè)強(qiáng)大的、集成工具集進(jìn)行整合，將在格式良好的系統(tǒng)架構(gòu)模型的環(huán)境中對遵從 dodaf 產(chǎn)品的創(chuàng)建進(jìn)行自動化來支持 dodaf 的遵從。 |
|
|
