基于UML的軍用軟件運(yùn)行剖面元模型研究?

孫 媛 唐金國(guó) 徐吉輝

（海軍航空工程學(xué)院科研部 煙臺(tái) 264001）

1 引言

最早的軟件運(yùn)行剖面（Operational Profile，OP）研究開始于1993年，Musa在IEEE發(fā)表了一篇題為《軟件可靠性工程中的運(yùn)行剖面》的文章。他將軟件運(yùn)行剖面定義為：運(yùn)行剖面是如何使用（軟件）系統(tǒng)的定量描述。它由一組運(yùn)行集組成，這組運(yùn)行集表現(xiàn)為一個(gè)系統(tǒng)的執(zhí)行及其發(fā)生的概率［1］。歐空局是這樣定義運(yùn)行剖面的：“對(duì)系統(tǒng)使用條件的定義，系統(tǒng)的輸入值都用其按時(shí)間的分布或按它們?cè)诳赡茌斎敕秶鷥?nèi)出現(xiàn)概率的分布來(lái)定義”［2］。運(yùn)行可理解為系統(tǒng)在短時(shí)間內(nèi)完成一個(gè)較大的邏輯任務(wù)，系統(tǒng)的任何功能實(shí)現(xiàn)最終都可分解到運(yùn)行上［3］。

Musa提出的軟件運(yùn)行剖面的構(gòu)造是一個(gè)自頂向下的層次結(jié)構(gòu)，他提出了一種五步OP開發(fā)方法，逐漸分解整個(gè)系統(tǒng)，并建立多個(gè)運(yùn)行剖面，如“客戶剖面”，“用戶剖面”，“系統(tǒng)模式剖面”，“功能剖面”等。其流程如圖1所示。在構(gòu)造運(yùn)行剖面時(shí)，需要充分分析軟件的各種模式和功能，分析完成這些功能所需的輸入數(shù)據(jù)，同時(shí)要分析在使用軟件時(shí)各種系統(tǒng)模式和功能發(fā)生的概率。構(gòu)造軟件的運(yùn)行剖面的方法是按照層次結(jié)構(gòu)，自頂向下地把使用軟件的輸入空間劃分為系統(tǒng)模式剖面，把系統(tǒng)模式剖面劃分為功能剖面，再把功能剖面劃分為運(yùn)行剖面。

運(yùn)行剖面的主要作用是能夠促進(jìn)可靠性的評(píng)估。運(yùn)行剖面能夠提高效率，增加可靠性，縮短開發(fā)時(shí)間。正如Musa所述：“使用運(yùn)行剖面指導(dǎo)軟件測(cè)試，能夠保證如果由于進(jìn)度約束導(dǎo)致測(cè)試終止，對(duì)最常用的操作測(cè)試最多，在給定的測(cè)試時(shí)間內(nèi)，可靠性水平將會(huì)達(dá)到最大［4］?！?/p>

2 軍用軟件運(yùn)行剖面的分類

軍用軟件系統(tǒng)本質(zhì)上是一個(gè)交互系統(tǒng)，為了實(shí)現(xiàn)其目的需要與不同類型的用戶，如人、其它硬件或軟件系統(tǒng)進(jìn)行通信。環(huán)境的多樣性需要特定的運(yùn)行剖面來(lái)描述這些相互作用。

在構(gòu)造軍用軟件運(yùn)行剖面的過(guò)程中，可以按照運(yùn)行剖面的特點(diǎn)，其分類如圖2所示。其中通用特性類用于區(qū)別OP的顯著特點(diǎn)，是大多數(shù)軍用系統(tǒng)中都具有的性質(zhì)。通用特性下的子類是相互獨(dú)立的。軟件邊界類用于對(duì)應(yīng)于區(qū)分一個(gè)特定的軟件與其他不相關(guān)的軟件，其子類與一些通用特性中的類密切相關(guān)。例如，輸入數(shù)據(jù)是與來(lái)源有關(guān)。其中，通用特性類和軟件邊界類是建立在對(duì)OP最基礎(chǔ)的理解上的。開發(fā)類主要是面向何時(shí)和如何進(jìn)行一個(gè)OP開發(fā)的問(wèn)題。

圖2 軟件運(yùn)行剖面分類圖

通用特性類分成輪廓、結(jié)構(gòu)、抽象層次、來(lái)源、場(chǎng)景、模式、配置和關(guān)鍵操作子類。其中，輪廓類是沿著給定的維度給出的一個(gè)橫截面的應(yīng)用視圖。在使用過(guò)程中，它包含了該維度的元素和這些元素發(fā)生的概率，一個(gè)OP可能包括一個(gè)或多個(gè)輪廓，它因此分成單輪廓OP，或多輪廓OP。結(jié)構(gòu)類包括樹、馬爾可夫鏈、概率事件流圖、集合等結(jié)構(gòu)，其體現(xiàn)了結(jié)構(gòu)中的元素（包括節(jié)點(diǎn)、轉(zhuǎn)換、輸入、事件等）出現(xiàn)的概率。抽象層次類體現(xiàn)了面向?qū)ο笾兄赜玫母拍?。?dāng)把軍用軟件系統(tǒng)視為一個(gè)產(chǎn)品時(shí)，在OP通常指相關(guān)的系統(tǒng)級(jí)測(cè)試，而目前大量的開發(fā)軟件產(chǎn)品主要是使用（重用）作為組件在其他產(chǎn)品和系統(tǒng)中，所以抽象層次類又可以分為系統(tǒng)級(jí)抽象層次類和組件級(jí)抽象層次類。來(lái)源類用于在OP中區(qū)分不同類型的輸入提供者，其子類包括硬件、軟件和人。場(chǎng)景類是一個(gè)用戶序列或外部產(chǎn)生的輸入（多序列的事件），完成一個(gè)特定的應(yīng)用程序的目標(biāo)。Shukla等開發(fā)使用實(shí)際使用數(shù)據(jù)OP的結(jié)構(gòu)［5］，Woit使用執(zhí)行前綴，指定OP一個(gè)模塊執(zhí)行的序列［6］，這些都是有感知的場(chǎng)景類，而馬爾可夫鏈，狀態(tài)機(jī)和狀態(tài)圖構(gòu)建OP序列信息，其模型沒(méi)有直接從序列信息來(lái)源，則屬于非感知場(chǎng)景類。模式類對(duì)應(yīng)于特定類型的軟件系統(tǒng)，例如管理員模式中，啟動(dòng)模式，安全模式，關(guān)閉模式等。配置類是指一個(gè)軟件系統(tǒng)的配置對(duì)應(yīng)于一個(gè)運(yùn)行（和測(cè)試）環(huán)境的設(shè)置。關(guān)鍵操作類是指軟件中最經(jīng)常使用的操作（或功能）的子系統(tǒng)或模塊。如果在OP中提供了明確的手段，用以解決關(guān)鍵的，但罕見(jiàn)的操作和功能的被稱為有意識(shí)的關(guān)鍵操作，否則，它是無(wú)意識(shí)的關(guān)鍵操作。

軟件邊界類分成執(zhí)行范圍類、外部錯(cuò)誤類和輸入數(shù)據(jù)類。執(zhí)行范圍類包括軟件的執(zhí)行層，如硬件平臺(tái)（提供基本的軟件執(zhí)行資源，如處理器和內(nèi)存）和操作系統(tǒng)軟件（管理的基本執(zhí)行資源，并提供更高級(jí)別的，如調(diào)度、同步和文件系統(tǒng)）。此外，執(zhí)行范圍包括其他系統(tǒng)和用戶任務(wù)。外部錯(cuò)誤類是指除了源于系統(tǒng)的執(zhí)行范圍之外的另一個(gè)重要類型的故障，可以在操作過(guò)程中的外部輸入接口的軟件應(yīng)用程序是一個(gè)外部錯(cuò)誤。輸入數(shù)據(jù)類定義為輸入變量的名稱、值、類型和它們需要滿足的約束。

開發(fā)類分為生命周期階段類和工具支持類。生命周期階段類又分為早期生命周期階段類和晚期生命周期階段類。理想情況下，一個(gè)OP的建設(shè)應(yīng)該發(fā)生在軟件開發(fā)生命周期的早期（在實(shí)施階段，最好是在需求分析階段），并逐步完善整個(gè)隨后的生命周期階段。在軟件系統(tǒng)已經(jīng)實(shí)現(xiàn)時(shí)，還應(yīng)該改善整個(gè)系統(tǒng)的壽命（例如操作、維護(hù)、升級(jí)、新的版本）。工具支持類是指提供運(yùn)算方法的工具，如果是通過(guò)自動(dòng)化工具的支持，被稱為自動(dòng)運(yùn)算工具支持類；否則，它被稱為非自動(dòng)化運(yùn)算工具支持類。

3 軍用軟件剖面元模型的建立

介紹了軍用軟件運(yùn)行剖面的概念后，采用OP元模型的方法對(duì)軍用軟件運(yùn)行剖面進(jìn)行UML化的表達(dá)。OP元模型的建立用以提高理解的各種概念，構(gòu)建的OP和這些概念之間的關(guān)系。

3.1 運(yùn)行剖面元模型

圖2所示的OP被表示為圖3中的元模型。圖3說(shuō)明了一個(gè)OP是由一個(gè)或多個(gè)剖面組成的。一個(gè)剖面有相關(guān)的結(jié)構(gòu)，并具有多個(gè)輸入。表1中對(duì)每個(gè)概念的定義，以及它們之間的重要關(guān)系進(jìn)行了詳細(xì)的描述。

圖3 運(yùn)行剖面元模型

可以在不同的抽象層次上定義一個(gè)OP，如系統(tǒng)級(jí)或組件級(jí)。通過(guò)環(huán)境可以將一個(gè)系統(tǒng)級(jí)的OP和一個(gè)組件級(jí)的OP聯(lián)系起來(lái)。環(huán)境是一組映射關(guān)系推導(dǎo)出基于這些映射關(guān)系的系統(tǒng)級(jí)OP，組件級(jí)OP進(jìn)行修正，從而將組件級(jí)OP映射到特定的系統(tǒng)中。應(yīng)用程序OP是一個(gè)或多個(gè)OP的集合，可能也包含一個(gè)執(zhí)行范圍剖面。一個(gè)應(yīng)用程序OP與源代碼相關(guān)。一個(gè)OP還需考慮關(guān)鍵操作，外部錯(cuò)誤，或輸入數(shù)據(jù)類。輸入數(shù)據(jù)又與它的變量名，值，數(shù)據(jù)類型，和輸入數(shù)據(jù)相關(guān)。

下面將對(duì)其中幾個(gè)重要的子類的元模型進(jìn)行分析。

3.2 執(zhí)行范圍類元模型

執(zhí)行范圍類包括軟件的執(zhí)行層次等硬件平臺(tái)（提供基本的軟件執(zhí)行資源，如CPU和RAM）和操作系統(tǒng)軟件（管理等基本行政資源和提供高級(jí)的調(diào)度、同步、和文件系統(tǒng)）。應(yīng)用程序NOP是指OP的軟件應(yīng)用程序的不同但駐留在同一臺(tái)計(jì)算機(jī)平臺(tái)上應(yīng)用程序。操作系統(tǒng)軟件是指“軟件”的集合?？刂朴?jì)算機(jī)程序的執(zhí)行等服務(wù)，并提供計(jì)算機(jī)資源分配、工作控制、輸入/輸出控制，電腦和文件管理系統(tǒng)。計(jì)算機(jī)硬件是指物理設(shè)備用于處理、存儲(chǔ)或傳輸?shù)挠?jì)算機(jī)程序或數(shù)據(jù)。設(shè)備驅(qū)動(dòng)器是指計(jì)算機(jī)程序控制外圍設(shè)備。有時(shí)也指重新格式化數(shù)據(jù)傳輸?shù)脑O(shè)備。

圖4 執(zhí)行范圍類元模型

表1 運(yùn)行剖面元模型

3.3 輪廓類運(yùn)行剖面元模型

配置類是指按照數(shù)量、定義及其各組成部分之間的相互聯(lián)系排列計(jì)算機(jī)系統(tǒng)或組件。配置的概念引出了配置剖面的概念［7］。配置剖面提供了應(yīng)用程序的各種配置發(fā)生的概率。發(fā)生的概率是元素用于定義OP（即輸入數(shù)據(jù)、事件、操作、功能）的發(fā)生概率。概率依賴是使用屬性定義的“條件”發(fā)生概率?！皸l件”是包含一組事件。集合的長(zhǎng)度表示前序事件的數(shù)量，因此“N”是N-conditional的值。如果長(zhǎng)度為零，發(fā)生的概率是無(wú)條件的。這將是代表與“φ”的一個(gè)條件。長(zhǎng)度決定在某種程度上接受的結(jié)構(gòu)剖面。長(zhǎng)度“1”表示需要一個(gè)馬爾可夫模型。發(fā)生的概率（Prob Occ）方法表示為Prob（），其具體屬性如表2所示。

圖5 輪廓類運(yùn)行剖面元模型

表2 發(fā)生的概率方法屬性表

場(chǎng)景是生成的用戶或外部輸入（主要是事件的序列）一個(gè)序列，完成一個(gè)特定的應(yīng)用程序的目標(biāo)。

約束條件：

C1：OP.Profile.Scenario

Events.isOrder=“ Y ”

模式代表了一個(gè)狀態(tài)或一組狀態(tài)［8］，模式也可以是一組分組為了方便分析的函數(shù)或操作執(zhí)行行為。模式形成系統(tǒng)模式剖面或過(guò)程模式剖面［9］。事件被定義為發(fā)生在一個(gè)特定的時(shí)間點(diǎn)，可能會(huì)導(dǎo)致應(yīng)用程序的狀態(tài)的變化。

屬性：is Ordered：Boolean｛default=N｝

指定是否事件是有序的。如果“Y”事件是有序的。如果“N”，事件是無(wú)序的。

外部硬件是外部計(jì)算機(jī)硬件組件的集合。所考慮的計(jì)算機(jī)硬件是正在運(yùn)行計(jì)算機(jī)硬件的應(yīng)用程序。外部軟件是運(yùn)行外部硬件和接口與應(yīng)用程序軟件組件的集合上。

3.4 結(jié)構(gòu)類元模型

樹對(duì)應(yīng)于一個(gè)有根標(biāo)記的樹，也就是說(shuō)，有一個(gè)根，標(biāo)記節(jié)點(diǎn)和從根直接延伸的邊。節(jié)點(diǎn)是樹結(jié)構(gòu)的頂點(diǎn)。分支是樹結(jié)構(gòu)的邊。來(lái)源是描述實(shí)體在原點(diǎn)的輸入驅(qū)動(dòng)軟件應(yīng)用程序。應(yīng)用程序主要是由人類活動(dòng)或系統(tǒng)輸入（如：人/HW/SW輸入）。此處發(fā)生概率的約束條件是：

圖6 結(jié)構(gòu)類元模型

C2：OP.Profile.Structure.MarkovChain.Transition Probability Of Occurrence.condition.size=［1］

C3：OP.Profile.Structure.MarkovChain.Transition Probability Of Occurrence.condition.type=previous state

基于狀態(tài)是指使用原始的狀態(tài)的結(jié)構(gòu)。馬爾可夫鏈?zhǔn)请S機(jī)變量的集合xt（指數(shù)的“t”貫穿0，1，…和xt表示系統(tǒng)的狀態(tài)指數(shù)“t”）的屬性。狀態(tài)被定義為“假設(shè)在給定時(shí)刻，定義特征的變量值”的應(yīng)用程序或組件。轉(zhuǎn)移定義為從一個(gè)狀態(tài)過(guò)渡到另一個(gè)地方的改變。轉(zhuǎn)移通常是由一個(gè)事件引起的。概率事件流程圖（PEFG）是具體的一個(gè)特定應(yīng)用程序的GUI模型，代表所有可能的序列事件，用戶可以執(zhí)行的GUI。邊緣節(jié)點(diǎn)EFG代表事件，直接代表了事件流兩個(gè)事件之間的關(guān)系，其分解的元模型如圖7所示。

圖7 概率事件流圖元模型

PEFG的邊是一個(gè)有向邊用來(lái)表示一個(gè)事件流的關(guān)系。例如，e1和e2之間的一條邊是指事件e2后立即調(diào)用事件e1。PEFG節(jié)點(diǎn)代表一個(gè)事件。PEFG表是一個(gè)子序列長(zhǎng)度k事件條件概率表。此處發(fā)生概率的約束條件是：

C4：OP.Profile.Structure.PEFG.Event

ProbabilityOfOccurrence.condition.maxsize=k

Harel狀態(tài)圖是指擴(kuò)展傳統(tǒng)的狀態(tài)轉(zhuǎn)換關(guān)系圖與必要的三要素，處理，分別用層次概念，并發(fā)通訊［10］。集合被定義為不同實(shí)體的集合。實(shí)體被定義為感興趣的元素。例如操作、事件、輸入數(shù)據(jù)等。其中來(lái)源類又可以分解成如圖8所示的元模型。

成員資格概率是指來(lái)源所屬的特定的組。其屬性：

圖8 來(lái)源元模型

Prob：Real，指發(fā)起人是某個(gè)團(tuán)體的成員的可能性。人指一個(gè)或多個(gè)應(yīng)用用戶，用戶是一個(gè)人，團(tuán)體，或機(jī)構(gòu)的員工?？蛻羰谦@取系統(tǒng)的人、團(tuán)體或機(jī)構(gòu)。硬件是所有硬件的類型的一個(gè)概括，其中包括計(jì)算機(jī)系統(tǒng)的內(nèi)部硬件的計(jì)算機(jī)接口。軟件是所有類型的軟件與計(jì)算機(jī)系統(tǒng)的相互作用的一個(gè)概括，包括安裝在計(jì)算機(jī)上的軟件。

4 結(jié)語(yǔ)

本文針對(duì)軍用軟件運(yùn)行剖面劃分的問(wèn)題進(jìn)行分析，對(duì)軍用運(yùn)行剖面進(jìn)行分類，采用UML圖的方法建立軍用軟件運(yùn)行剖面的元模型，詳細(xì)分析了執(zhí)行范圍OP、輪廓類OP、結(jié)構(gòu)類OP、來(lái)源類OP和輸入類OP之間的關(guān)系。研究的過(guò)程中也發(fā)現(xiàn)，隨著軟件系統(tǒng)的復(fù)雜性的增加，特別是由于增加了系統(tǒng)組件之間的相互作用和不同性質(zhì)的系統(tǒng)用戶（例如，基于網(wǎng)絡(luò)的或分布式系統(tǒng)），影響事件發(fā)生的概率因素變得復(fù)雜，運(yùn)行剖面的發(fā)展變得越來(lái)越有挑戰(zhàn)性。為了解決這些問(wèn)題，后續(xù)還需采用語(yǔ)言變量和模糊邏輯等方法對(duì)復(fù)雜系統(tǒng)結(jié)構(gòu)的相互作用的概率進(jìn)行深入的研究。

［1］J.D.Musa.Operational Profiles in Software-Reliablity En?gineering［J］.IEEE Software，1993，10（2）：14-32.

［2］何國(guó)偉，王瑋.軟件可靠性［M］.北京：國(guó)防工業(yè)出版社，1998.

HE Guowei，WANG Wei.Software Reliability［M］.Bei?jing：National Defence Industry Press，1998.

［3］黃松，端木怡婷，惠戰(zhàn)偉，等.基于運(yùn)行剖面的測(cè)試用例選擇改進(jìn)算法［J］.指揮信息系統(tǒng)與技術(shù)，2011，2（3）：78-82.

HUANG Song，DUANMU Yiting，HUI Zhanwei，et al.Test Cases Selection Algorithm Based on Operational Profile［J］.Modern Electronic Engineering，2011，2（3）：78-82.

［4］Carol smidts，ChetanMutha，et al.Software Testing with an Operational Profile：OP Definition［J］.ACM Comput.Surv，2014，46（3）：39.

［5］R.Shukla，D.Carrington，and P.Strooper.Systematic op?erational profile development for software components［C］//In Proc.of the 11th Asia-Pacific Software Engineering Conference（APSEC'04）.2004.528-537.

［6］D.M.Woit.Specifying Operational Profiles for Modules［C］//In Proc.of the 1993 ACM SIGSOFT International Symposium on Software Testing and Analysis（ISSTA'93）.1993：2-10.

［7］B.D.Juhlin.Implementing operational profiles to measure system reliability［C］//In Proc.of the 3rd International Symposium on Software Reliability Engineering（ISSRE'02），1992：286-295.

［8］J.A.Whittaker.and M.G.Thomason.A Markov chain model for statistical software testing［J］.IEEE Transac?tions on Software Engineering 1994，10：812-824.

［9］M.Gittens，H.Lutfiyya，and M.Bauer.An extended oper?ational profile model［C］//In Proc.of the 15th Internation?al Symposium on Software Reliability Engineering（ISSRE'04），2004：314-325.

［10］D.Harel.Statecharts：A visual formalism for complex sys?tems［J］.Science of Computer Programming 8，1987：231-274.