聊聊 DoDAF/MoDAF 規格與實作議題

上上個星期,應國防某單位要求,希望由我們利用 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 這個算是軍中資訊人員們的 “潘朵拉密盒”,可說是成就感十足,也算頗引以為傲。

ea_dodaf_demo
圖 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 工具來規劃設計。)

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

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

AV-1
— 架構總覽文件報告。
OV-4
— 組織關係圖。
OV-1
— 高階層次概念視圖。
OV-5
— 企業層級使用案例圖。
— 作業活動圖。
OV-2
— 作業節點連結設計圖。
OV-6
— 作業活動狀態圖。
— 作業活動循序圖。
OV-3
— 作業資訊交換矩陣表。
SV-1
— 系統介面概觀設計圖。
SV-4
— 系統使用案例圖。
— 系統循序圖。
SV-2
— 系統介面規格設計圖。
SV-5
— 系統與作業活動關係矩陣。
— 服務與作業活圖關係矩陣。
SV-3
— 系統與系統的關係矩陣。
— 系統與服務的關係矩陣。

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

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

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

文章導覽

   

共有 12 則迴響

  1. Hello 杭州樓梯:
    從個人的角度,以及從實作的觀點來看,這些模型的確沒有什麼作用。 🙂
    但若是大型系統,尤其是 Dodaf 所揭露如此大格局的,那麼架構的規劃就必要囉。

  2. hello Kenming Wang,

    System Architect 10.0.22是能做这种转换的,但是转换得到的模型个人感觉没有太大应用价值,
    一般都会需要推倒重来-_-!

    从楼上各位发言内容中学到了很多,谢谢^_^

  3. Hello Bear:

    很謝謝您的說明與諸多的經驗談與中肯的建議。 🙂

    個人在上一篇的回覆其實說的很清楚:
    重點是在 “架構規劃與實作的整合 Skill”,不是擺在工具上。 我想再補充一點吧,也不會把重點擺在要順應那些什麼規格有的沒的。或者再說的更明一點, UML, BPMN, SysML(我並不知道這是什麼) 等,都是工具,就是工具而已。

    我們的焦點是擺在 “如何解決問題,並提供具體的解決方案。”。

    對於若要承接專案之類的,當然如您所說的,就是 Vendor 的為難之處,包括其它諸多因子,如政治面等; 而我在文內已提及,我們的角色是顧問性質,並沒有許多 Vendor 承接專案的諸多包袱與為難之處。

    文字的說明,往往不容易表達清楚,可能 Bear 您也不容易瞭解我們的方向。您所提及的問題,我們也大概知道,甚至在我們從事顧問事業這一條路來說,一路走來,不知道有多少朋友們警告過我們對於軟體專案承接的太多難點等等問題。這些,我們多少都是知道的。 🙂

    個人在文內,傾向探討的是,DoDAF 主要構面的設計產出,以及其重點的說明,應該算是純軟體設計的分享吧。

    不過,您可以在個人網站的迴響內給予您這麼多的忠告與建議,真的是相當感謝。 若是有能見面的場合機會時,也相當歡迎能針對 DoDAF 等議題交換一些看法,我請個客,喝喝咖啡聊聊天。 個人比較喜歡 “單純” 一點,即使沒有得到任何案子,我大概也不會有什麼難過或失望的。 🙂

  4. Sorry,
    請恕我多言了,
    我也不CARE工具啦,
    實在是軍方的案子不好作~
    以下則是個人多言了
    …Orz..
    如果這個案子委方的前提(範圍)是”軟體架構”的規劃是單純得多,
    但說到要符合DoDAF規格的話…
    DoDAF定義的”整合架構”範圍和參與的人員就不應只有軟體開發人員了哦!
    下列3點提供參考:
    (1)DoDAF定義的整合架構,最低需求要交付(或發展)7個核心架構資料元素:
    AV1、AV2、OV2、OV3、OV5、SV1、TV1。
    (2)ABM(Activity-Based Methodology)定義的整合架構,最低需求要交付8個核心架構資料元素:
    OV2、OV3、OV4、OV5、SV1、SV4、SV5、SV6。
    (3)實務上”Defense Acquisition Review Journal,August,April-July,2005.”其中1篇文章提及發展”ABCS, Army Battle Command Systems Version 6.4″的檢討(摘譯):
    架構導向發展的專案,最低限度作戰人員要發展OV1、OV2、OV3、OV6c,
    而工程人員要發展SV1、SV2、SV6、SV10c。
    就第(3)點來看,DoDAF的開發技術會混用Modeling Standards,
    只用UML(支援軟體工程)可能會有所不足,
    因此notation尚有BPMN(支援企業塑模)、SysML(支援系統工程)
    其中BPMN、SysML兩者皆為物件導向(用來取代結構化的IDEF)。
    所以說,vendor 要設計符合DoDAF規格的系統,
    真的是很難ㄚ~

  5. Hello Bear:
    T牌支持 DoDAF 的開發案例,我們也看過。 🙂
    我無意拿 EA 與 T牌工具來比較,對我們來說,這意義一點都不大,在文內已說明這一點。
    對我們而言,任何一套能支持 DoDAF 規格的工具,我們都可以配合,重點是在架構規劃與實作的整合 Skill,而不是擺在工具上。 🙂

  6. Hello Johnnyl:
    文內的例子是隨便舉的,但挺訝異的, Telelogic 可以從 OV2 轉 OV5?
    這樣代表 OV2 確實有明確的規則轉到 OV5 囉?
    若是這樣的話,我們就確實可以寫 Transform Script 從 OV2 轉 OV5 了。 ^^

  7. 個人也是EA的愛用者,也用過T牌,實在個有所長。
    軍事案例建議可參考美國海軍武力網(FORCEnet) http://forcenet.navy.mil/architecture/av.htm
    它一開始就使用T牌建立DODAF的AV,OV,SV,TV。
    而說到DODAF可說是應美軍武獲三大決策系統而生,使用者的需求與其欲達成之能力,經JCIDS(Joint Capabilities Integration & Development System)的需求產生機制具體化,同時發展國防科技專案,提供所須的技術建議,結合兩者後,在 PPBE(Planning, Programming, Budgeting and Execution)制度支持下,開啟武獲計畫,進入武獲管理制度(Defense Acquisition)來籌獲軍事裝備或武器系統(包含軟體)。
    所以真正的問題是,國軍的武獲系統與美軍並不相同,要發展自已的AF才是。(但是没有人才,人才因為精進案跑得跑,躲得躲…)
    另外EA的定位應只是軟體工程階段,但是T牌會那麼貴的原因,也是因為它企圖包含需求工程,系統工程,軟體工程等各階段參與武器系統開發的人員都能用,因為開發一項武器系統與單純開發一套軟體大不同。
    因此,T牌要能支援DODAF當然要包山包海。

  8. Well.. 重點應該不在工具吧, T牌的我也用過, 重要的是真的有 consultant 及案例可以實做出來. 不然我們成天在說精實, 系統化, 不都是用口說說的而已… 真希望我們國防部能有效率點…

  9. OV-2(作業節點連結) 轉 OV-5(作業活動流程)

    System Architect, which from Telelogic, can do that

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *