上上個星期，應國防某單位要求，希望由我們利用 EA(Enterprise Archiect) UML 工具，藉由一個案例，來展示在順應 DoDAF 規格下，如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖，以及又該如何導出到實作，尤以後者，對他們很困擾，一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具，因為 EA 其中一個 Plugin 產品，稱為 MDG for DoDAF-MODAF，兩者的搭配，應用的是 UML Profile 機制，可以充分完整支援 DoDAF 1.5 的設計規格。 說真的，工具沒啥好介紹的，況且席間諸多長官與教授們問最多的問題就是有沒有 “自動化” 的機制，可以從某一個 View 的設計圖，自動轉化到另外一個 View 的設計圖。這個… 我總覺得他們研究的方向會不會有問題？ 我只能反問：1. 如果規則明確，例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話，那麼工具當然可以支援。 (可想而知的答案是，當然沒有那種必然明確的規則) 2.能不能轉到程式碼？ 這些我都覺得都不是問題耶，前提是有沒有那種確定的規則？ 有趣的是，他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具，也沒有支援他們 “心目中” 的自動化啊。 所以我開玩笑的說，好吧，把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價，用來委託我們開發那個自動化的 Transform 機制，保證可以幫你們生的出來，不過前提是要能給我們明確的轉換規則。 🙂

我可不會想賺工具的錢啦，要能懂得設計符合 DoDAF 架構規格的系統，要具備的是軟體設計基礎功夫的底子；要能有整體性的架構觀，要知道什麼時候該封裝、什麼時候該打開，分析系統的內部；要懂得如何把一個看起來好像很大的系統(關於系統的定義，可不一定指軟體系統，在這種大格局下，包括企業單位，都可能是一個系統)，該如何大題小作；又懂得那個時候該具焦在某一個焦點上，然後小題大作。 這一種整體性的設計思維，正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是，我們可以協助國防某單位，如何具備能具有規劃 DoDAF 架構設計的技能(Skill)，與相關軟體設計的基礎功夫，以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主，如果可以的話，規劃成一個外包的專案更是好，然後從實作的過程中帶著學習，作中學的效果會更好的。 不過前提是，我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統，一般當然就是出個題目了，這一向是我個人最為意願的了，比較容易在短時間內取得雙方之間彼此的信賴與共識；也比較現實，會就會，不會的話早一點出局，最不囉唆了。 喔，還有，這是繼我十餘年前從志願役中尉預官退伍後，再一次能回到軍中，為國效勞的好機會呢，哈。 😀

由於國防某單位最近忙了些，等了幾星期，還是沒拿出案例讓我們來演練，所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢，這個案例是沒有與軍事任何單位有關連(正因如此，才能拿出來公開分享)，完全是充滿想像；也沒有軍事專家的協助，所以需求必然是謬誤百出。不過這也不是什麼困擾，因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助，那麼就很容易可以調整修正，來符合正確的需求了。

整整花了四天的時間，投入了約 2.3 個人力，以一個我們所想像創造出來的案例，也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統，透過偵測與防衛系統，發現到敵人即將進軍來襲時，是如何即時協同陸、海、空三軍暨後勤補給中心，來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔，甚至連那個表達 OV-1 的概念視圖，都還是請美工畫出來的呢，效果十足！ 老實說，個人對我們團隊能在如此短的時間內，就能規劃出如此大的架構格局，甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 “潘朵拉密盒”，可說是成就感十足，也算頗引以為傲。

圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯！ 在座許多高級長官以及教授們在會後的許多問題透過我們的解說，也算能得到合理的解釋。也讓許多中、上尉的資訊官們，見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的)，所以到是可以藉由公開發表這一個案例，除了展示是如何實現 DoDAF 規格，並大概解釋一下每一個 View 的 精要(essential)設計意涵為何，同時也算是藉由此，來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

對了，還是要簡單說明一下 DoDAF/MoDAF 架構框架到底是幹什麼呢？ DoDAF(Department of Defense Architecture Framework) 是美國國防部、MoDAF(UK Ministry of Defence Architectural Framework) 則是大英國協軍方的規格。 其目的旨在規範承包包括武器、資訊技術系統等的外包廠商，透過多個層次的角度(Multiple Views)，能夠以標準化、一致性，來組織包括企業架構(Enterprise Architect)，以及系統架構(System Architecture，這裡意指資訊系統)，而能有具標準、一致性、多層次的設計視圖與文件等符合軍事要求的規格。 DoDAF/MoDAF (因為國軍主要仍以美軍的規範為主，所以整個架構規格，均以 DoDAF 為主，但其實兩者的規格差不多)的規格是公開的，可以自由下載來研究參考的，下列鍊結提供了這些規格的說明與下載位置：
　o DoDAF Wiki。
　o MODAF Wiki。
　o DoDAF 1.5 Volume 1(pdf)。
　o DoDAF 1.5 Volume 2(pdf)。
　o DoDAF 1.5 Volume 3(pdf)。
　o DoDAF 1.0 Deskbook。

至於關於如何使用 MDG for DoDAF/MoDAF Plugin (前提是要先安裝 EA UML Tool)，參考 這裡。
安裝完這個 Plugin 的好處是可以看到完整的 DoDAF 案例。(雖然我覺得裡面有些視圖的設計不太正確，但還是需要參考這個工具所提供的案例，才能知道如何使用 EA 工具來規劃設計。)

圖 2、 EA-DoDAF 所提供的 DoDAF 樣版(Template)

DoDAF 主要包括了兩個大層次： Operation View and System View。 Operation View 包括從 OV-1 到 OV-7； System View 包括從 SV-1 到 SV-11。 在我們所演練的案例內的設計產出擷取部分精要的設計視圖，參考下面兩個表。

我想爾後就會針對我們所設計每一個 View 的設計視圖，來簡單地說明該視圖的設計意涵為何。 另外，我們並沒有表達 TV (Technical View)，主因在於這個 View 幾乎都只是表達技術規格的詳細文件報告而已。

對啦，一個有趣的問題可以思考看看。參考一下底下這張是給指揮官層級看的概念視圖(OV-1, Conceptual View)。考驗一下，作為一個架構師(Architect)，看到這張圖的時候，是否可以腦海中馬上浮現，可以如何以 UML 2.0 規格中的那一張設計圖來設計表達呢？ (提示一下，即使從如此大的概念視圖，也要能看得出你要規劃的系統那個整體(Whole)是什麼？ 誰會觸發這個系統的反應？ 這個系統有無外部系統的支援？ 系統內部的組成主要結構元素為何？ )

圖 3、 EA-DoDAF 範例中的 OV-1 概念視圖