基于UML的雷達導引頭系統軟件工程過程

劉 婷 張江華 聶 強 李依林

(西安電子工程研究所 西安 710100)

1 引言

導引頭系統軟件是整個雷達導引頭項目研制中的重要環節，主要用于導引頭工作模式控制、數據處理、系統調試，以及與伺服系統、導彈控制系統的數據通信等。與常規軟件開發過程相比，雷達導引頭系統軟件對開發人員以及軟件開發過程管理都更加嚴格。常規雷達導引頭系統軟件開發一般采用面向過程的軟件開發流程實現。面向過程的程序設計方法將重點放在解決問題的方法或過程上，具有代碼效率高，程序結構緊湊等優點，但是隨著軟件系統功能日益復雜和開發規模的不斷增大，這種程序設計方法的弊端也逐漸暴露和突出:

a.軟件開發難度大。面向過程的程序開發模式采用自頂向下的程序設計來實現，把程序分解成若干個功能模塊和子功能模塊，這些模塊間存在大量的數據交互和功能調用，不利于軟件開發的多人協作，并使軟件開發過程隨著開發隊伍的增大變的越來越困難。

b.軟件可靠性差。在面向過程的程序開發中，大量的軟件測試均是在代碼全部完成后進行，通過最后階段的系統聯調來判斷軟件是否存在問題。可以看出用這種粗略的測試手段試圖去發現軟件存在的問題是極不可靠的，即使發現問題，在這個階段去修改程序也會浪費極大的人力物力，從而延誤科研進程。

c.軟件維護性差。利用面向過程的模式開發程序，一個簡單功能的增加都會引起系統軟件架構的調整，并且在新的程序架構下需要對測試過的功能模塊再次調試測試。這樣無疑大大增加了軟件開發人員的工作量，不利于項目的進展。

d.軟件繼承性差。面向過程的程序開發模式下，系統軟件的功能模塊之間呈現著“高耦合”狀態，模塊之間功能存在的大量的交叉，這樣不利于代碼復用，降低了軟件的繼承性。

隨著以上缺點在雷達導引頭系統軟件開發過程中的日益暴露，已經嚴重的影響著我們的科研進度和工作，因此，尋找一種更適應雷達導引頭系統軟件開發的方法是我們迫切需要解決的問題。

本文針對雷達導引頭系統軟件的特點，利用UML(統一建模語言)為導引頭系統建模，基于面向對象的思想，對系統軟件的開發和設計實施分階段過程控制與管理。UML在系統模型設計與分析中具有很大的優勢［1］:a.UML系統模型是面向對象的;b.UML系統模型可完全獨立于整個開發過程;c.UML系統模型是最易掌握和使用的;d.UML系統模型具有可視化，非常適于復雜系統的建模。綜上所述，UML已成為面向對象技術領域占主導地位的標準建模語言，能夠對整個開發過程提供靈活易讀一致的表達，表現出其強大的能力，融合了各種面向對象的建模語言的優點，因此，具有非常廣闊的應用前景。

2 UML原理簡述

UML是用模型來描述系統的結構或靜態特征以及行為或動態特征的，它從不同的視角為系統的架構建模形成系統的不同視圖。在軟件系統開發過程中主要應用到CIM(Computation Independent Model)和PIM(Platform Independent Model)階段的UML模型，CIM聚焦于軟件系統外部需求及功能，不涉及軟件系統的結構和細節，屬于概要設計階段;PIM聚焦于軟件系統的內部細節但不涉及系統的具體平臺，屬于詳細設計階段。具體包括以下七個步驟［2］:

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的七個系統模型始終貫穿于軟件開發的整個過程中，從需求分析、設計、實現直至最后的系統測試及維護。

3 基于UML的軟件系統建模

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

3.1 業務用例建模

利用UML模型進行面向對象的軟件開發中，通常采用業務用例模型來捕獲用戶最頂層的功能需求。通過對雷達導引頭系統軟件需求描述的劃分，對于外部導彈總體來說，雷達導引頭的主要功能可以劃分為三類:開機自檢功能、干擾檢測功能和目標檢測功能。其中，完成每個功能的參與者均為雷達導引頭。圖1為導引頭系統的業務用例模型。

圖1 雷達導引頭系統業務用例模型

開機自檢是需要雷達導引頭判斷自身是否有故障;干擾檢測是要求雷達導引頭能夠判斷外部是否存在有源干擾;目標檢測要求雷達導引頭能夠完成目標的搜索、截獲和跟蹤并輸出指導信息。由于目標檢測功能是雷達導引頭工作的主要功能，下面我們以目標檢測為例來講述如何利用UML對雷達導引頭系統軟件建模。

3.2 活動圖建模

活動圖是每個業務用例的邏輯過程。一個業務用例可以映射到多個活動，一個活動圖也可以被多個用例使用。活動圖很類似軟件的流程圖，但流程圖描述的是具體的程序設計，而活動圖是概念級的。活動圖還可以表示并行的動作，由于是概念級的控制流設計，所以活動圖沒有流程圖的循環結構［3］。下面針對目標檢測業務用例分析其工作流程，由于目標檢測主要分為目標搜索、截獲和跟蹤等功能，其活動圖見圖2。

圖2 目標檢測功能活動圖

活動圖對于業務用例圖增加了限制或約束條件，來規定某一具體操作的使用條件和范圍。例如，導引頭進入搜索模式，首先裝訂初始化參數，而天線掃描和二進制積累檢測是并行的，最后執行存儲記錄目標信息;截獲模式中的所有操作都是按時間串行執行的;跟蹤模式中的操作也分為串行和并行執行順序。

3.3 系統用例建模

系統用例模型明確系統需求、范圍和作用，是系統設計和開發的基礎。用來描述用戶所有的功能需求，但不考慮實現細節。系統用例建模中，活動圖中的每一個動作都有可能成為系統用例;業務圖中的業務執行者都可能是執行者。根據這兩個原則圖3給出目標檢測功能的系統用例圖。

圖3 目標檢測功能系統用例圖

圖3是雷達導引頭軟件中目標檢測的系統用例圖模型。在目標檢測中，導引頭有5個功能用例，分別表示導引頭完成目標檢測功能的幾個不同的工作模式，即搜索模式、截獲模式、跟蹤模式、記憶跟蹤模式和進入盲區。在搜索、截獲和跟蹤用例中又細分為若干子用例，代表了在這些模式中需要完成的子功能。例如，在搜索用例中要實現參數裝訂、天線掃描、二進制積累檢測以及目標信息存儲記錄;截獲用例中完成參數裝訂、目標匹配置天線和波門以及截獲波門內確認目標;跟蹤用例中完成參數裝訂、跟蹤濾波、AGC控制、切換信號體制、六相時鐘調整波門和跟蹤測角等功能。

3.4 系統用例敘述

系統用例描述是針對每一個系統用例，分析其內部細節，編寫成系統用例敘述。表1以搜索用例中的二進制積累檢測為例給出其系統用例簡述。

表1 系統用例敘述

系統用例簡述主要由用例名稱、用例編號、用例圖、用例簡述、主要流程和例外流程組成。主要流程和例外流程是對系統用例的詳細設計描述，也是代碼編寫人員在編寫代碼時的主要依據。相比于傳統方法的軟件任務書只籠統的提出功能性要求，基于UML模型的系統用例以及簡述不但詳細并且準確描述出軟件模塊的具體功能，還可供項目管理者和編程人員正確的估算代碼編寫的工作量，合理的安排工作進度。

3.5 狀態圖建模

狀態圖是系統的動態建模，用來描述系統的工作狀態以及引起狀態轉移的條件和規則。因此，狀態圖由若干狀態以及引起狀態轉移的條件和規則組成。通過狀態圖可以了解系統在整個生命周期的運動軌跡［4］。圖4為目標檢測的狀態圖。

從圖4可以看出，狀態圖給出了目標檢測中搜索模式、截獲模式、跟蹤模式、憶跟蹤模式和進入盲區5個工作狀態是如何轉移的。比如，雷達導引頭在3次連續收到TZK指令后進入搜索模式;搜索到目標進入截獲模式，截獲模式截獲到目標進入跟蹤狀態，否則回到搜索狀態。

3.6 類圖建模

類與對象是面向對象技術的基本元素，類是對本質相同一類事物的抽象。在UML中，類與對象模型用類圖和對象圖來表示，屬于靜態建模的范疇。

面向對象程序設計與常規面向過程程序設計的重要區別是對象(或類)的封裝性。通過類(或對象)的這種封裝的屬性實現了對程序功能模塊的封裝，進而使整個程序做到“高內聚、低耦合”。正是這種特性使得軟件設計部件化成為可能，程序開發人員利用已開發好的軟件部件實現需要的功能，可以大大提高軟件開發的繼承性;另一方面，由于軟件開發可以大量繼承前期經過充分驗證的軟件部件，軟件的可靠性無疑也會大幅度提高。

我們根據目標檢測的狀態圖，通過分析每個狀態的動作，最終確定完成這些動作需要構造哪些類。

圖5中，我們構造了8個類:目標類、FPGA數據通訊類、伺服控制類、串口通訊類、導引頭模式切換類、跟蹤濾波類、AGC控制類和直流校正類。每個類都封裝了自己的數據和操作。

3.7 序列圖建模

僅利用類圖，仍然難免有些操作無法預先想到，為此，需要進一步考察類的動態結構，即利用序列圖考察程序執行時每一步驟需要執行的具體操作。序列圖6通過描述對象之間發送消息的時間順序顯示對象之間的動態協作，重點是對象間消息傳遞的時間順序。序列圖有兩個坐標軸，橫坐標軸顯示對象，縱坐標軸顯示時間［5］。

根據靜態類圖和序列圖可以進一步發現開發程序所需要使用的類，從而得到更完備的類圖。

到此為止，代碼編寫人員可依據導引頭系統的上述UML模型編寫出源代碼雛形。

4 結論

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

［1］何春俐.建模語言UML的研究［J］.機械管理開發，2010，25(1):177－178.

［2］邱郁慧.系統分析師UML實務手冊［M］.機械工業出版社，2008.

［3］王巖.基于UML的慣導軟件需求分析，戰術導彈控制技術［J］.2011，28(2):22－26.

［4］黃金晶，李文俊.利用UML的面向對象分析建模［J］.常州信息職業技術學院學報，2011，10(5):13－15.

［5］陸波，華祖耀.面向對象的軟件工程與統一建模語言 UML［J］.電腦開發與應用，2002，15(9):18－22.