基于ＤＯＤＡＦ的系統建模探討

摘要：建模技術是體系結構研究、系統分析與設計所采用的最重要的方法之一，統一建模語言(UML)是一種通用的可視化建模語言，目前已成為建模事實上的工業標準。簡要介紹UML靜態結構建模和動態建模機制，分析UML對美國國防部體系結構框架(DoDAF)描述的圖像化支持，綜合面向過程和面向對象的思想，提出基于DoDAF的建模過程，并結合超市購物系統的建模實例展示此過程。

關鍵詞：UML；體系結構框架；模型；系統建模

中圖分類號：TP311

文獻標識碼：B

文章編號：1004—373X(2008)04—059—04

隨著計算機技術的發展和大型、復雜系統軟件項目的開發需求，必須采取相應的技術手段支持不同階段、背景人員的交流。基于體系結構框架的可視化建模是目前被廣泛認可的解決大型復雜系統設計中存在的諸多問題的一種有效手段。統一建模語言(Unified Model Lan—guage，UML)是被對象管理組織OMG(0bject Manage—ment Group)正式采納的可視化建模語言的工業標準。至今，UML在學術界和工業界已得到普遍認可，被廣泛用來進行復雜系統各種成份的可視化描述、說明，以及構造系統模型和建立各種所需的文檔等，然而UML只是一種可視化的建模語言，UML只是一種表示的標準，UML不是過程和方法，但UML允許任何一種過程和方法使用他。美國國防部體系結構框架(Dept.of Defense Ar—chitecture Framework，DoDAF)給出了系統設計過程中體系結構模型的描述規則和指南，但他沒有給出具體的系統設計方法和建模過程。為此，本文在分析UML對DoDAF模型支持的基礎上，結合面向過程中功能分解和面向對象中以問題域中的事物為研究對象的思想，提出一種基于DoDAF的系統建模方法，并結合實例展示了建模過程。

1 UML對DoDAF模型的支持

1.1 DoDAF簡述

美國國防部(DoD)于2004年2月頒布了《DoD體系結構框架》的1.0版本，用于指導國防指揮控制系統和商業運作過程的體系結構描述。DoDAFE提出了體系結構描述的3個視圖：運作視圖(Operational View)、系統視圖(Systems View)和技術視圖(Technical Standards View)，并給出相應的26個描述性產品，分別從不同角度共同描述系統體系結構的構建和發展。對于特定的任務需求，DoDAF模型從不同角度闡述了系統設計中必須遵循的描述規范，包括：產品名稱、內容以及產品的開發、分析、比較與集成，力圖以統一的系統設計語言，產品名稱，數據單元和數據模型，防止系統設計中因不同描述所造成的錯誤理解和“煙囪式”重復建設，以有利于實現系統間共享信息的一致性，實現基于系統互操作性的復雜系統集成優勢。

1.2 UML對DoDAF模型的支持

UML 2.0加強了對結構化建模能力的支持，比如結構化類表現系統的結構更加清晰直觀，功能模塊化更好，端口語義的引入，提高了組件化的表現能力。結構化類更好地表現模塊的相關特征，復合結構圖更好地表現模塊的結構特征。結構化建模能力的加強更有利于表示系統結構單元分解，包括運作節點分解到運作單元，系統節點分解到系統單元及系統組件，是DoDAF模型OV－2，SV－1和SV－2的有效圖形描述。

在模型的動態方面，UML 2.0中的活動圖提供了更強的數據流的語義，可以用活動圖描述業務流程。帶數據流的活動圖，以及活動圖的分層和多維泳道的采用滿足DoDAF模型中OV－5和SV－4對功能分析描述的需要。在時序圖方面，應用參考可以使時序圖模塊化，利用這個機制可以描述頂層的交互概覽圖，以及建立更加復雜的時序圖，支持OV－6c和SV－10c。狀態機圖中引入入點和出點作為與外部的交互點，狀態機提高了狀態機的封裝能力，為OV－6b和SV－10b提供強有力的模擬驗證支持。表1描述UML對DoDAF中部分模型的圖形化支持。

2 基于DoDAF的建模過程

2.1基本思想

基于DoDAF的建模過程的基本思想是：將整個系統模型的構建劃分為若干階段進行，每一階段分別側重解決不同的建模問題，分別在不同的抽象層次、以不同的粒度對系統模型進行描述，由此保證系統模型可以由粗略到詳細逐步推進，從而減小系統模型設計的難度、復雜度以及風險；明確定義每一階段的實施步驟，使整個系統建模過程更為透明，更容易被理解和實施；為每個階段設置明確的結束準則，組織對系統模型的階段性評審，以有利于問題的及早發現和解決，而不僅是在整個設計完成后才一次性進行分析和驗證。

2.2 建模過程

根據系統架構過程，建模過程從主題系統的范圍、目的、預計用戶和運作環境人手，采用大粒度的系統分解，通過分析不同層次的場景，抽象出實現系統功能的類及對象，建立系統模型。系統模型的創建順序如下圖1所示。整個建模過程大致分為4個階段：

(1)創建運作分析模型。通過主題系統使命和相關知識領域信息收集，生成全視圖的描述(AV－1)。對主題系統和重要用例的分析，創建高層運作概念模型(OV－1)，確定該系統交互的外部系統和組織實體(即參與者或角色)，完成場景需求，建立帶有簡單的對象流(消息)活動模型(OV－5)，以及影響活動的運作規則(OV－6a)；在不同的活動場景中，識別出運作節點，通過類圖獲取，建立運作節點連接描述(OV－2)；分析OV－1中用例場景的涉眾(節點)，定義交互消息(OV－3)，著重于運作節點通過消息與主題系統交互的時序圖(OV－6c)表現用例的外部可見行為，而當這些行為是事件驅動時，用狀態圖建模(OV－6b)可以對理解該行為特別有用，而事件追蹤的模擬仿真需要邏輯數據的支持，從而創建邏輯數據(OV－7)；根據運作節點(OV－2)的關系建立組織關系模型(OV－4)。本階段以OV－1驅動，OV－5為過程，OV－2為核心，OV－6a／b／c提供驗證體制，循環往復逐步增加完善運作模型。

在本階段的第一次迭代中，首先是利用知識域和關鍵場景，采用面向過程的方法，進行系統分解，創建頂層概要模型。實踐證明，對較為復雜的系統進行功能分解，將系統分解為強內聚、松耦合的功能模塊，是降低系統建模復雜度的一個有效方法。需要再分解為自治的子系統，最后分解為層(也可以稱為子系統)。注意功能分解必須與面向對象技術緊密結合，以免陷入功能的過分分解和結構化設計的歧途。在后續的迭代建模中，逐步添加細節，遵循自頂向下、逐層細化的設計過程。

(2)創建需求分析模型。主要創建的模型是系統功能性描述模型(SV－4)和系統功能可追溯性矩陣的運作活動模型(SV－5)。通過上一階段運作分析，明確了系統行為所需要的必須功能和數據流，采用帶有泳道的活動圖，展示系統負責的活動以及數據對象的輸入輸出，建立由運作模型到系統模型的橋梁(SV－4)；建立運作活動(用例，場景)和實現所需行為的系統功能之間的可朔性(SV－5)。

(3)創建功能分析模型。主要創建的模型有系統接口描述(SV－1)、系統規則模型(SV－10a)，系統狀態轉換描述(SV－10b)，系統時間跟蹤描述(SV－10c)，系統信息交換矩陣(SV－6)，系統性能參數矩陣(SV－7)和物理數據模型(SV－11)。通過對SV－4分析以及OV－2模型，用含有類、位置和接口的類圖描述系統、系統節點和存在于他們內部及其間的接口，產生SV－1，對系統進行邏輯分解并將邏輯功能分配的物理組件上，同時可以對功能進行動態描述，以及由OV－6a／b／c到SV－10a／b／c的映射。本階段以SV－1的創建為核心，SV－6和SV－11為其提供數據支持，SV－10a／b／c為其提供驗證機制。

第四階段：創建系統實現模型。進一步完善SV－1，SV－6和SV－11，重點創建系統通信模型(SV－2)和系統矩陣(SV－3)。在實現公共接口邏輯和物理透視圖一致建模的基礎上，用復合結構圖和部署圖為物理節點及其相關的通信基礎構架建模，產生SV－2；為整個架構模型中的系統和子系統之間的關系建模產生SV－3。在系統實現模型的基礎上的，可用進行系統演進描述(SV－8)和系統技術預測(SV－9)，以及進一步的技術架構概要(TV－1)和技術標準預測(TV－2)。

需要說明的是，這4個階段在實際應用中具有典型的代表性，但卻不是每個階段的模型都要全部創建，應根據系統的規模和表現方面的具體情況而定。在實踐中，整個建模過程將呈現多次迭代性，在每次模型構建迭代結束之前，應組織對這一迭代的系統模型進行評審，評審的目的是對系統滿足功能和質量需求的潛在可能性做出評價。

3 基于DoDAF的超市購物系統建模分析

超市購物系統主要功能是通過有關設備完成顧客與超市的商品交易活動。根據面向過程思想所需要系統實現的業務為確認商品信息和收款交易，到頂層用例模型(OV－1)，識別出主題主體系統以及參與的角色和主要的業務場景，如圖2所示。通過活動圖描述(OV－5)，進行運作節點(OV－2)設計，運用動態模型(OV－6)和數據(OV－3)交互，逐步完善運作模型，同時生成(OV－7)。著重討論OV－5和OV－2的創建。

首先將用例作為實體，分析其場景及完成的活動。確認商品信息具體活動還包括讀取商品信息、計算商品總價和顯示商品信息與總價，而活動是有具體的運作節點參與，讀取商品信息由電子標簽閱讀器完成，計算總價由終端處理設備完成，顯示商品信息和總價由顯示器來完成。付款交易活動應包括確認帳號、購物交易和交易完成，然后根據這些活動可進一步分解，如確認帳號要求顧客提供帳號并檢查其有效性，購物交易包括處理交易的商品信息和刷新帳底等，交易完成時應打印發票，同時提示顧客交易完成。整個運作活動可以分層細化，逐步細分，可以用帶有分層的活動圖表示。如圖3所示確認商品信息的活動圖。

經過活動流程的分析，參與交互的運作節點、連通性和信息流逐步明顯，通過抽象分析得出功能單元即節點，用帶接口類圖和復合結構圖來表示，各節點能完成獨立的計算單元通過接口與其他節點進行信息交互，信息包括信息流和控制流，經過分析得到的運作節點如圖4所示。其中信息處理節點作為復合結構還可以進一步分解為信息的計算單元和信息的存儲單元，銀行系統作為一個外部系統，只提供有關的功能接口即可。

在OV－2的創建過程中，各節點的信息傳遞，可以通過時序圖進行描述不同的用例場景逐步明確，通過狀態機圖進行模擬驗證，完成信息機制，建立數據模型。每一步都有相應OV模型產生，從而使整個的建模過程成為一個相互驗證逐步遞增的整體。高質量的運作模型可以為需求分析模型創建提供有效的輸入，需求分析模型是運作分析模型到功能分析模型的過渡，至此功能分析模型經過運作分析模型和功能分析模型的映射初步明確形成，然后創建系統的實現模型，包括部署等。注意系統模型的建立是一個循環迭代的過程，隨著對信息的獲取更加廣泛與深入，系統模型的建立逐步演進和完善。

4 結 語

本文給出基于DoDAF的系統建模過程，充分利用UML靜態和動態建模機制的特點，使用UML從系統需求說明開始基于體系結構框架的基礎上逐層逐步為系統進行建模。采用統一建模語言，基于體系結構框架的系統建模在不同的階段可分別獲得關于系統不同層次、具有不同細節程度的模型，滿足不同人員從不同層次了解系統的需要，并有利于系統不同層次模型的重用。實踐證明，尤其是對于大型復雜系統，運用簡單明了的UML可視化圖形基于體系結構框架模型從不同角度將復雜系統表示出來，不僅可以為系統的分析、設計、維護及擴展提供有利的條件，還可提高系統的可重用性和可維護性，具有廣泛的應用前景。