雷達導引頭系統軟件工程化的實現范文

本站小編為你精心準備了雷達導引頭系統軟件工程化的實現參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

UML原理簡述

在軟件系統開發過程中主要應用到CIM(ComputationIndependentMod-el)和PIM(PlatformIndependentModel)階段的UML模型，CIM聚焦于軟件系統外部需求及功能，不涉及軟件系統的結構和細節，屬于概要設計階段;PIM聚焦于軟件系統的內部細節但不涉及系統的具體平臺，屬于詳細設計階段。具體包括以下七個步驟:CIM-1:定義業務流程，產生業務用例模型。此階段是為了捕獲用戶的頂層功能需求。

CIM-2:分析業務流程，產生活動圖。針對CIM-1中每一個業務用例，分析它的流程，并且繪制活動圖。

CIM-3:定義系統范圍，產生系統用例圖。CIM-3生成的文件與前兩個階段生成的文件有如下關系:a．CIM-2活動圖中的每一個動作，都可能成為CIM-3的系統用例;b．CIM-1中的業務執行者，以及CIM-2中的動作負責人，都可能成為CIM-3的系統執行者。

PIM-1:分析系統流程，產生系統用例敘述。PIM-1的主要工作是針對每一個系統用例，分析其內部細節，并編寫詳盡得系統用例敘述。

PIM-2:分析業務規則，產生狀態圖。針對每個業務對象根據業務規則繪制出狀態圖。

PIM-3:定義靜態結構，產生類圖。在這個階段需要用類圖來表達系統內部的靜態結構，需經過以下步驟:a．根據前面生成的文檔獲得初步的靜態結構;b．分析PIM-2的狀態圖，為類增加屬性及操作;c．分析PIM-1搜集的窗體，為類增加更多的屬性;d．經過下面PIM-4的序列圖，為類增加更多的屬性，并且描述操作的方法。

PIM-4:定義操作及方法，生成序列圖。此階段可以用序列圖來表達系統內部一群對象合力完成某一個系統用例時，執行期間的交互情形。程序員可按照序列圖的內容，編寫出方法的源代碼雛形。UML的七個系統模型始終貫穿于軟件開發的整個過程中，從需求分析、設計、實現直至最后的系統測試及維護。

基于UML的軟件系統建模

本文采用RationalRose軟件工具按照UML的七個建模步驟對雷達導引頭系統軟件進行建模。

1業務用例建模

利用UML模型進行面向對象的軟件開發中，通常采用業務用例模型來捕獲用戶最頂層的功能需求。通過對雷達導引頭系統軟件需求描述的劃分，對于外部導彈總體來說，雷達導引頭的主要功能可以劃分為三類:開機自檢功能、干擾檢測功能和目標檢測功能。其中，完成每個功能的參與者均為雷達導引頭。圖1為導引頭系統的業務用例模型。開機自檢是需要雷達導引頭判斷自身是否有故障;干擾檢測是要求雷達導引頭能夠判斷外部是否存在有源干擾;目標檢測要求雷達導引頭能夠完成目標的搜索、截獲和跟蹤并輸出指導信息。由于目標檢測功能是雷達導引頭工作的主要功能，下面我們以目標檢測為例來講述如何利用UML對雷達導引頭系統軟件建模。

2活動圖建模

活動圖是每個業務用例的邏輯過程。一個業務用例可以映射到多個活動，一個活動圖也可以被多個用例使用。活動圖很類似軟件的流程圖，但流程圖描述的是具體的程序設計，而活動圖是概念級的。活動圖還可以表示并行的動作，由于是概念級的控制流設計，所以活動圖沒有流程圖的循環結構。下面針對目標檢測業務用例分析其工作流程，由于目標檢測主要分為目標搜索、截獲和跟蹤等功能，其活動圖見圖2。活動圖對于業務用例圖增加了限制或約束條件，來規定某一具體操作的使用條件和范圍。例如，導引頭進入搜索模式，首先裝訂初始化參數，而天線掃描和二進制積累檢測是并行的，最后執行存儲記錄目標信息;截獲模式中的所有操作都是按時間串行執行的;跟蹤模式中的操作也分為串行和并行執行順序。

3系統用例建模

系統用例模型明確系統需求、范圍和作用，是系統設計和開發的基礎。用來描述用戶所有的功能需求，但不考慮實現細節。系統用例建模中，活動圖中的每一個動作都有可能成為系統用例;業務圖中的業務執行者都可能是執行者。根據這兩個原則圖3給出目標檢測功能的系統用例圖。圖3是雷達導引頭軟件中目標檢測的系統用例圖模型。在目標檢測中，導引頭有5個功能用例，分別表示導引頭完成目標檢測功能的幾個不同的工作模式，即搜索模式、截獲模式、跟蹤模式、記憶跟蹤模式和進入盲區。在搜索、截獲和跟蹤用例中又細分為若干子用例，代表了在這些模式中需要完成的子功能。例如，在搜索用例中要實現參數裝訂、天線掃描、二進制積累檢測以及目標信息存儲記錄;截獲用例中完成參數裝訂、目標匹配置天線和波門以及截獲波門內確認目標;跟蹤用例中完成參數裝訂、跟蹤濾波、AGC控制、切換信號體制、六相時鐘調整波門和跟蹤測角等功能。

4系統用例敘述

系統用例描述是針對每一個系統用例，分析其內部細節，編寫成系統用例敘述。表1以搜索用例中的二進制積累檢測為例給出其系統用例簡述。系統用例簡述主要由用例名稱、用例編號、用例圖、用例簡述、主要流程和例外流程組成。主要流程和例外流程是對系統用例的詳細設計描述，也是代碼編寫人員在編寫代碼時的主要依據。相比于傳統方法的軟件任務書只籠統的提出功能性要求，基于UML模型的系統用例以及簡述不但詳細并且準確描述出軟件模塊的具體功能，還可供項目管理者和編程人員正確的估算代碼編寫的工作量，合理的安排工作進度。

5狀態圖建模

狀態圖是系統的動態建模，用來描述系統的工作狀態以及引起狀態轉移的條件和規則。因此，狀態圖由若干狀態以及引起狀態轉移的條件和規則組成。通過狀態圖可以了解系統在整個生命周期的運動軌跡。圖4為目標檢測的狀態圖。從圖4可以看出，狀態圖給出了目標檢測中搜索模式、截獲模式、跟蹤模式、憶跟蹤模式和進入盲區5個工作狀態是如何轉移的。比如，雷達導引頭在3次連續收到TZK指令后進入搜索模式;搜索到目標進入截獲模式，截獲模式截獲到目標進入跟蹤狀態，否則回到搜索狀態。

6類圖建模

類與對象是面向對象技術的基本元素，類是對本質相同一類事物的抽象。在UML中，類與對象模型用類圖和對象圖來表示，屬于靜態建模的范疇。面向對象程序設計與常規面向過程程序設計的重要區別是對象(或類)的封裝性。通過類(或對象)的這種封裝的屬性實現了對程序功能模塊的封裝，進而使整個程序做到“高內聚、低耦合”。正是這種特性使得軟件設計部件化成為可能，程序開發人員利用已開發好的軟件部件實現需要的功能，可以大大提高軟件開發的繼承性;另一方面，由于軟件開發可以大量繼承前期經過充分驗證的軟件部件，軟件的可靠性無疑也會大幅度提高。我們根據目標檢測的狀態圖，通過分析每個狀態的動作，最終確定完成這些動作需要構造哪些類。圖5中，我們構造了8個類:目標類、FPGA數據通訊類、伺服控制類、串口通訊類、導引頭模式切換類、跟蹤濾波類、AGC控制類和直流校正類。每個類都封裝了自己的數據和操作。

7序列圖建模

僅利用類圖，仍然難免有些操作無法預先想到，為此，需要進一步考察類的動態結構，即利用序列圖考察程序執行時每一步驟需要執行的具體操作。序列圖6通過描述對象之間發送消息的時間順序顯示對象之間的動態協作，重點是對象間消息傳遞的時間順序。序列圖有兩個坐標軸，橫坐標軸顯示對象，縱坐標軸顯示時間。根據靜態類圖和序列圖可以進一步發現開發程序所需要使用的類，從而得到更完備的類圖。到此為止，代碼編寫人員可依據導引頭系統的上述UML模型編寫出源代碼雛形。

結論

本文利用UML建模對雷達導引頭系統進行面向對象的軟件開發與設計，降低了軟件開發難度，保證了軟件質量，提高了軟件的可維護性和繼承性。目前，我們已成功將這項技術應用于某雷達導引頭系統軟件的開發中，在傳統方法的1/4時間內完成了整個系統軟件的設計和代碼編寫，并通過黑盒和白盒測試方法對程序模塊進行了充分的測試，進一步提高整個軟件系統的可靠性。下一步我們將逐步形成雷達導引頭軟件產品庫，進一步提高代碼復用性，同時將此技術推廣至其它導引頭項目的軟件開發中。

作者：劉婷張江華聶強李依林單位：西安電子工程研究所