劉 婷 張江華 聶 強(qiáng) 李依林

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

1 引言

導(dǎo)引頭系統(tǒng)軟件是整個(gè)雷達(dá)導(dǎo)引頭項(xiàng)目研制中的重要環(huán)節(jié)，主要用于導(dǎo)引頭工作模式控制、數(shù)據(jù)處理、系統(tǒng)調(diào)試，以及與伺服系統(tǒng)、導(dǎo)彈控制系統(tǒng)的數(shù)據(jù)通信等。與常規(guī)軟件開發(fā)過程相比，雷達(dá)導(dǎo)引頭系統(tǒng)軟件對(duì)開發(fā)人員以及軟件開發(fā)過程管理都更加嚴(yán)格。常規(guī)雷達(dá)導(dǎo)引頭系統(tǒng)軟件開發(fā)一般采用面向過程的軟件開發(fā)流程實(shí)現(xiàn)。面向過程的程序設(shè)計(jì)方法將重點(diǎn)放在解決問題的方法或過程上，具有代碼效率高，程序結(jié)構(gòu)緊湊等優(yōu)點(diǎn)，但是隨著軟件系統(tǒng)功能日益復(fù)雜和開發(fā)規(guī)模的不斷增大，這種程序設(shè)計(jì)方法的弊端也逐漸暴露和突出:

a.軟件開發(fā)難度大。面向過程的程序開發(fā)模式采用自頂向下的程序設(shè)計(jì)來實(shí)現(xiàn)，把程序分解成若干個(gè)功能模塊和子功能模塊，這些模塊間存在大量的數(shù)據(jù)交互和功能調(diào)用，不利于軟件開發(fā)的多人協(xié)作，并使軟件開發(fā)過程隨著開發(fā)隊(duì)伍的增大變的越來越困難。

b.軟件可靠性差。在面向過程的程序開發(fā)中，大量的軟件測(cè)試均是在代碼全部完成后進(jìn)行，通過最后階段的系統(tǒng)聯(lián)調(diào)來判斷軟件是否存在問題?？梢钥闯鲇眠@種粗略的測(cè)試手段試圖去發(fā)現(xiàn)軟件存在的問題是極不可靠的，即使發(fā)現(xiàn)問題，在這個(gè)階段去修改程序也會(huì)浪費(fèi)極大的人力物力，從而延誤科研進(jìn)程。

c.軟件維護(hù)性差。利用面向過程的模式開發(fā)程序，一個(gè)簡(jiǎn)單功能的增加都會(huì)引起系統(tǒng)軟件架構(gòu)的調(diào)整，并且在新的程序架構(gòu)下需要對(duì)測(cè)試過的功能模塊再次調(diào)試測(cè)試。這樣無疑大大增加了軟件開發(fā)人員的工作量，不利于項(xiàng)目的進(jìn)展。

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

隨著以上缺點(diǎn)在雷達(dá)導(dǎo)引頭系統(tǒng)軟件開發(fā)過程中的日益暴露，已經(jīng)嚴(yán)重的影響著我們的科研進(jìn)度和工作，因此，尋找一種更適應(yīng)雷達(dá)導(dǎo)引頭系統(tǒng)軟件開發(fā)的方法是我們迫切需要解決的問題。

本文針對(duì)雷達(dá)導(dǎo)引頭系統(tǒng)軟件的特點(diǎn)，利用UML(統(tǒng)一建模語言)為導(dǎo)引頭系統(tǒng)建模，基于面向?qū)ο蟮乃枷耄瑢?duì)系統(tǒng)軟件的開發(fā)和設(shè)計(jì)實(shí)施分階段過程控制與管理。UML在系統(tǒng)模型設(shè)計(jì)與分析中具有很大的優(yōu)勢(shì)［1］:a.UML系統(tǒng)模型是面向?qū)ο蟮?b.UML系統(tǒng)模型可完全獨(dú)立于整個(gè)開發(fā)過程;c.UML系統(tǒng)模型是最易掌握和使用的;d.UML系統(tǒng)模型具有可視化，非常適于復(fù)雜系統(tǒng)的建模。綜上所述，UML已成為面向?qū)ο蠹夹g(shù)領(lǐng)域占主導(dǎo)地位的標(biāo)準(zhǔn)建模語言，能夠?qū)φ麄€(gè)開發(fā)過程提供靈活易讀一致的表達(dá)，表現(xiàn)出其強(qiáng)大的能力，融合了各種面向?qū)ο蟮慕ＵZ言的優(yōu)點(diǎn)，因此，具有非常廣闊的應(yīng)用前景。

2 UML原理簡(jiǎn)述

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

CIM-1:定義業(yè)務(wù)流程，產(chǎn)生業(yè)務(wù)用例模型。此階段是為了捕獲用戶的頂層功能需求。

CIM-2:分析業(yè)務(wù)流程，產(chǎn)生活動(dòng)圖。針對(duì)CIM-1中每一個(gè)業(yè)務(wù)用例，分析它的流程，并且繪制活動(dòng)圖。

CIM-3:定義系統(tǒng)范圍，產(chǎn)生系統(tǒng)用例圖。CIM-3生成的文件與前兩個(gè)階段生成的文件有如下關(guān)系:a.CIM-2活動(dòng)圖中的每一個(gè)動(dòng)作，都可能成為CIM-3的系統(tǒng)用例;b.CIM-1中的業(yè)務(wù)執(zhí)行者，以及CIM-2中的動(dòng)作負(fù)責(zé)人，都可能成為CIM-3的系統(tǒng)執(zhí)行者。

PIM-1:分析系統(tǒng)流程，產(chǎn)生系統(tǒng)用例敘述。PIM-1的主要工作是針對(duì)每一個(gè)系統(tǒng)用例，分析其內(nèi)部細(xì)節(jié)，并編寫詳盡得系統(tǒng)用例敘述。

PIM-2:分析業(yè)務(wù)規(guī)則，產(chǎn)生狀態(tài)圖。針對(duì)每個(gè)業(yè)務(wù)對(duì)象根據(jù)業(yè)務(wù)規(guī)則繪制出狀態(tài)圖。

PIM-3:定義靜態(tài)結(jié)構(gòu)，產(chǎn)生類圖。在這個(gè)階段需要用類圖來表達(dá)系統(tǒng)內(nèi)部的靜態(tài)結(jié)構(gòu)，需經(jīng)過以下步驟:a.根據(jù)前面生成的文檔獲得初步的靜態(tài)結(jié)構(gòu);b.分析PIM-2的狀態(tài)圖，為類增加屬性及操作;c.分析PIM-1搜集的窗體，為類增加更多的屬性;d.經(jīng)過下面PIM-4的序列圖，為類增加更多的屬性，并且描述操作的方法。

PIM-4:定義操作及方法，生成序列圖。此階段可以用序列圖來表達(dá)系統(tǒng)內(nèi)部一群對(duì)象合力完成某一個(gè)系統(tǒng)用例時(shí)，執(zhí)行期間的交互情形。程序員可按照序列圖的內(nèi)容，編寫出方法的源代碼雛形。

UML的七個(gè)系統(tǒng)模型始終貫穿于軟件開發(fā)的整個(gè)過程中，從需求分析、設(shè)計(jì)、實(shí)現(xiàn)直至最后的系統(tǒng)測(cè)試及維護(hù)。

3 基于UML的軟件系統(tǒng)建模

本文采用Rational Rose軟件工具按照UML的七個(gè)建模步驟對(duì)雷達(dá)導(dǎo)引頭系統(tǒng)軟件進(jìn)行建模。

3.1 業(yè)務(wù)用例建模

利用UML模型進(jìn)行面向?qū)ο蟮能浖_發(fā)中，通常采用業(yè)務(wù)用例模型來捕獲用戶最頂層的功能需求。通過對(duì)雷達(dá)導(dǎo)引頭系統(tǒng)軟件需求描述的劃分，對(duì)于外部導(dǎo)彈總體來說，雷達(dá)導(dǎo)引頭的主要功能可以劃分為三類:開機(jī)自檢功能、干擾檢測(cè)功能和目標(biāo)檢測(cè)功能。其中，完成每個(gè)功能的參與者均為雷達(dá)導(dǎo)引頭。圖1為導(dǎo)引頭系統(tǒng)的業(yè)務(wù)用例模型。

圖1 雷達(dá)導(dǎo)引頭系統(tǒng)業(yè)務(wù)用例模型

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

3.2 活動(dòng)圖建模

活動(dòng)圖是每個(gè)業(yè)務(wù)用例的邏輯過程。一個(gè)業(yè)務(wù)用例可以映射到多個(gè)活動(dòng)，一個(gè)活動(dòng)圖也可以被多個(gè)用例使用?；顒?dòng)圖很類似軟件的流程圖，但流程圖描述的是具體的程序設(shè)計(jì)，而活動(dòng)圖是概念級(jí)的?；顒?dòng)圖還可以表示并行的動(dòng)作，由于是概念級(jí)的控制流設(shè)計(jì)，所以活動(dòng)圖沒有流程圖的循環(huán)結(jié)構(gòu)［3］。下面針對(duì)目標(biāo)檢測(cè)業(yè)務(wù)用例分析其工作流程，由于目標(biāo)檢測(cè)主要分為目標(biāo)搜索、截獲和跟蹤等功能，其活動(dòng)圖見圖2。

圖2 目標(biāo)檢測(cè)功能活動(dòng)圖

活動(dòng)圖對(duì)于業(yè)務(wù)用例圖增加了限制或約束條件，來規(guī)定某一具體操作的使用條件和范圍。例如，導(dǎo)引頭進(jìn)入搜索模式，首先裝訂初始化參數(shù)，而天線掃描和二進(jìn)制積累檢測(cè)是并行的，最后執(zhí)行存儲(chǔ)記錄目標(biāo)信息;截獲模式中的所有操作都是按時(shí)間串行執(zhí)行的;跟蹤模式中的操作也分為串行和并行執(zhí)行順序。

3.3 系統(tǒng)用例建模

系統(tǒng)用例模型明確系統(tǒng)需求、范圍和作用，是系統(tǒng)設(shè)計(jì)和開發(fā)的基礎(chǔ)。用來描述用戶所有的功能需求，但不考慮實(shí)現(xiàn)細(xì)節(jié)。系統(tǒng)用例建模中，活動(dòng)圖中的每一個(gè)動(dòng)作都有可能成為系統(tǒng)用例;業(yè)務(wù)圖中的業(yè)務(wù)執(zhí)行者都可能是執(zhí)行者。根據(jù)這兩個(gè)原則圖3給出目標(biāo)檢測(cè)功能的系統(tǒng)用例圖。

圖3 目標(biāo)檢測(cè)功能系統(tǒng)用例圖

圖3是雷達(dá)導(dǎo)引頭軟件中目標(biāo)檢測(cè)的系統(tǒng)用例圖模型。在目標(biāo)檢測(cè)中，導(dǎo)引頭有5個(gè)功能用例，分別表示導(dǎo)引頭完成目標(biāo)檢測(cè)功能的幾個(gè)不同的工作模式，即搜索模式、截獲模式、跟蹤模式、記憶跟蹤模式和進(jìn)入盲區(qū)。在搜索、截獲和跟蹤用例中又細(xì)分為若干子用例，代表了在這些模式中需要完成的子功能。例如，在搜索用例中要實(shí)現(xiàn)參數(shù)裝訂、天線掃描、二進(jìn)制積累檢測(cè)以及目標(biāo)信息存儲(chǔ)記錄;截獲用例中完成參數(shù)裝訂、目標(biāo)匹配置天線和波門以及截獲波門內(nèi)確認(rèn)目標(biāo);跟蹤用例中完成參數(shù)裝訂、跟蹤濾波、AGC控制、切換信號(hào)體制、六相時(shí)鐘調(diào)整波門和跟蹤測(cè)角等功能。

3.4 系統(tǒng)用例敘述

系統(tǒng)用例描述是針對(duì)每一個(gè)系統(tǒng)用例，分析其內(nèi)部細(xì)節(jié)，編寫成系統(tǒng)用例敘述。表1以搜索用例中的二進(jìn)制積累檢測(cè)為例給出其系統(tǒng)用例簡(jiǎn)述。

表1 系統(tǒng)用例敘述

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

3.5 狀態(tài)圖建模

狀態(tài)圖是系統(tǒng)的動(dòng)態(tài)建模，用來描述系統(tǒng)的工作狀態(tài)以及引起狀態(tài)轉(zhuǎn)移的條件和規(guī)則。因此，狀態(tài)圖由若干狀態(tài)以及引起狀態(tài)轉(zhuǎn)移的條件和規(guī)則組成。通過狀態(tài)圖可以了解系統(tǒng)在整個(gè)生命周期的運(yùn)動(dòng)軌跡［4］。圖4為目標(biāo)檢測(cè)的狀態(tài)圖。

從圖4可以看出，狀態(tài)圖給出了目標(biāo)檢測(cè)中搜索模式、截獲模式、跟蹤模式、憶跟蹤模式和進(jìn)入盲區(qū)5個(gè)工作狀態(tài)是如何轉(zhuǎn)移的。比如，雷達(dá)導(dǎo)引頭在3次連續(xù)收到TZK指令后進(jìn)入搜索模式;搜索到目標(biāo)進(jìn)入截獲模式，截獲模式截獲到目標(biāo)進(jìn)入跟蹤狀態(tài)，否則回到搜索狀態(tài)。

3.6 類圖建模

類與對(duì)象是面向?qū)ο蠹夹g(shù)的基本元素，類是對(duì)本質(zhì)相同一類事物的抽象。在UML中，類與對(duì)象模型用類圖和對(duì)象圖來表示，屬于靜態(tài)建模的范疇。

面向?qū)ο蟪绦蛟O(shè)計(jì)與常規(guī)面向過程程序設(shè)計(jì)的重要區(qū)別是對(duì)象(或類)的封裝性。通過類(或?qū)ο?的這種封裝的屬性實(shí)現(xiàn)了對(duì)程序功能模塊的封裝，進(jìn)而使整個(gè)程序做到“高內(nèi)聚、低耦合”。正是這種特性使得軟件設(shè)計(jì)部件化成為可能，程序開發(fā)人員利用已開發(fā)好的軟件部件實(shí)現(xiàn)需要的功能，可以大大提高軟件開發(fā)的繼承性;另一方面，由于軟件開發(fā)可以大量繼承前期經(jīng)過充分驗(yàn)證的軟件部件，軟件的可靠性無疑也會(huì)大幅度提高。

我們根據(jù)目標(biāo)檢測(cè)的狀態(tài)圖，通過分析每個(gè)狀態(tài)的動(dòng)作，最終確定完成這些動(dòng)作需要構(gòu)造哪些類。

圖5中，我們構(gòu)造了8個(gè)類:目標(biāo)類、FPGA數(shù)據(jù)通訊類、伺服控制類、串口通訊類、導(dǎo)引頭模式切換類、跟蹤濾波類、AGC控制類和直流校正類。每個(gè)類都封裝了自己的數(shù)據(jù)和操作。

3.7 序列圖建模

僅利用類圖，仍然難免有些操作無法預(yù)先想到，為此，需要進(jìn)一步考察類的動(dòng)態(tài)結(jié)構(gòu)，即利用序列圖考察程序執(zhí)行時(shí)每一步驟需要執(zhí)行的具體操作。序列圖6通過描述對(duì)象之間發(fā)送消息的時(shí)間順序顯示對(duì)象之間的動(dòng)態(tài)協(xié)作，重點(diǎn)是對(duì)象間消息傳遞的時(shí)間順序。序列圖有兩個(gè)坐標(biāo)軸，橫坐標(biāo)軸顯示對(duì)象，縱坐標(biāo)軸顯示時(shí)間［5］。

根據(jù)靜態(tài)類圖和序列圖可以進(jìn)一步發(fā)現(xiàn)開發(fā)程序所需要使用的類，從而得到更完備的類圖。

到此為止，代碼編寫人員可依據(jù)導(dǎo)引頭系統(tǒng)的上述UML模型編寫出源代碼雛形。

4 結(jié)論

本文利用UML建模對(duì)雷達(dá)導(dǎo)引頭系統(tǒng)進(jìn)行面向?qū)ο蟮能浖_發(fā)與設(shè)計(jì)，降低了軟件開發(fā)難度，保證了軟件質(zhì)量，提高了軟件的可維護(hù)性和繼承性。目前，我們已成功將這項(xiàng)技術(shù)應(yīng)用于某雷達(dá)導(dǎo)引頭系統(tǒng)軟件的開發(fā)中，在傳統(tǒng)方法的1/4時(shí)間內(nèi)完成了整個(gè)系統(tǒng)軟件的設(shè)計(jì)和代碼編寫，并通過黑盒和白盒測(cè)試方法對(duì)程序模塊進(jìn)行了充分的測(cè)試，進(jìn)一步提高整個(gè)軟件系統(tǒng)的可靠性。下一步我們將逐步形成雷達(dá)導(dǎo)引頭軟件產(chǎn)品庫(kù)，進(jìn)一步提高代碼復(fù)用性，同時(shí)將此技術(shù)推廣至其它導(dǎo)引頭項(xiàng)目的軟件開發(fā)中。

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

［2］邱郁慧.系統(tǒng)分析師UML實(shí)務(wù)手冊(cè)［M］.機(jī)械工業(yè)出版社，2008.

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

［4］黃金晶，李文俊.利用UML的面向?qū)ο蠓治鼋＃跩］.常州信息職業(yè)技術(shù)學(xué)院學(xué)報(bào)，2011，10(5):13－15.

［5］陸波，華祖耀.面向?qū)ο蟮能浖こ膛c統(tǒng)一建模語言 UML［J］.電腦開發(fā)與應(yīng)用，2002，15(9):18－22.