構件行為模型的構造研究

收稿日期：2007-12-16；修回日期：2008-03-17

作者簡介：馬春燕，女，博士研究生，主要研究方向為基于組件的軟件工程及測試(xiaomai2006@gmail.com); 胡飛，男，教授，主要研究方向為軟件工程、實時系統、計算機測試與控制技術; 鄭小寧，男，高級工程師，主要研究方向為嵌入式系統、計算機測試與控制技術

（西北工業大學 軟件與微電子學院，西安710072）

摘 要：提出了基于UML構件規格說明自動構造構件行為模型的方法，并用一個實例對該方法進行了說明。該方法構造的構件行為模型包含狀態與狀態之間的轉換，接口操作作為狀態轉換弧上的輸入，能夠很好地體現接口的操作調用序列，因而可以作為構件測試的測試模型，對于構件的開發者和使用者進行構件的黑盒測試以及第三方構件的評估很有價值。

關鍵詞：構件；測試模型；統一建模語言構件規格說明；構件行為模型；自動構造

中圖分類號：TP311

文獻標志碼：A

文章編號：1001-3695(2008)10-3026-04

Construction of software component behavior models

MA Chun-yan， HU Fei，ZHENG Xiao-ning

（College of Software Microelectronics，Northwestern Polytechnical University，Xi’an 710072， China）

Abstract:This paper proposed an algorithm for automatic construction of software component behavior model from UML component and illustrated it by an example. The constructed model included states and transitions between states. The method was as transition label. The model presented possible component operation sequences. It could be a model based on which tests were to be generated. This algorithm is valuable for model-based software component testing which supplier and user carries and software component evaluation which the third party carries on.

Key words：component；testing model; UML component; software component behavior model; automatic construction

當今，一些復雜、大型的軟件系統逐漸采用構件裝配的方式來開發，構件的質量直接關系軟件系統的質量，因而構件測試問題變得尤為重要。針對構件的特點，人們提出了基于模型的構件測試方法[1~7]。它們用于產生測試用例的模型都有狀態節點以及節點之間的轉換，人們將這些模型統稱為構件的行為模型。上述研究都未給出如何創建構件的行為模型，構件行為模型的構造是基于模型的構件測試技術得以廣泛應用的基礎，若沒有系統的指導方法，行為模型的手工構造過程將會非常復雜，錯誤的構造可能導致構件模型與軟件的規格說明不一致，從而誤導測試結論。

1 UML構件案例

研究采納被廣泛認可的文獻[8]中的UML構件。它分為構件規格說明和接口規格說明兩部分。

1）接口規格說明 其接口信息模型和操作的規格說明是構造構件行為模型的基礎。每個接口都有一個接口信息模型，它是接口的操作可以引用構件對象屬性的一個類型模型，類型有對象類型和簡單數據類型，如文獻[1]中Account構件接口信息模型中的類型是簡單數據類型string和float。圖1所示IHotelMgt接口信息模型中的類型都是對象類型，包括Reservation、Room、Hotel、Customer、RoomType。

操作的規格說明定義了構件對象可以為客戶完成的一些服務和功能，包括操作的輸入參數、輸出參數，同時每個操作都有一個前置條件和后置條件。前置條件是操作實現功能所依賴的假設和保證；后置條件表示在條件滿足的情況下操作所做的契約保證，即構件對象狀態是如何改變的。依據信息模型的定義，由接口操作導致的構件對象狀態的所有變化都可以被操作的后置條件描述。用這種契約方式指定的操作規格說明隱含著滿足假設是客戶的責任，契約保證是操作提供者的責任。操作的前置條件和后置條件可以通過UML約束定義語言OCL來定義。例如，IHotelMgr接口中操作beginStay規格說明包含的前置和后置條件，如下所示：

beginStay(in resRef:String，out roomNumber:String):Boolean

pre:

reservation?exists(r|r.resRef=resRef)

not reservation?exists(r|r.resRef=resRef and r.claimed)

post:

Let

res=reservation?select(r|r.resRef=resRef)?asSequence?first in

result implies

res.claimed and roomNumber=res.room.number

由于篇幅所限，其他操作的前置、后置條件略。

2）構件規格說明 它提供接口類型的集合，包括接口集合和使用的接口集合。為了算法描述的方便，這里僅考慮單個接口的構件，如EJB構件。含有多個接口的構件的行為模型可以通過合并各個接口的行為模型而獲取。構件HotelMgt的規格說明如圖2所示，它提供一個接口IHotelMgt，本文將以該構件為例進行討論。

2 構件行為模型的構造方法

本文構造的構件行為模型CBM是一個五元式，即CBM=(S，O，δ，s0，f)。其中：S是構件運行狀態的有限集合；O狀態轉換標記的集合，是構件操作的集合；δ表示構件使用過程中構件狀態之間的轉換函數，δ：S×O∪{ε}→S，ε表示狀態之間的無條件轉換；s0∈S，是初始狀態，它代表構件激活的狀態；f∈S，是終止狀態，它代表構件終止執行時進入的狀態。

21 接口的行為信息表的定義

由接口的操作規格說明和信息模型建立一個與該接口的行為有關的接口行為信息表。每個操作占據一行，接口維護的每個屬性占據一列，表中的元素符號指示該屬性是如何參與操作的，本文定義以下幾種：

a） 空白。當前的操作行為沒有涉及該屬性。

b） 符號I。操作是創建構件對象的操作，它初始化構件所維護的屬性，即為對象類型的屬性創建一個對象或初始化基本數據類型的屬性值。

c） 符號S。操作改變構件屬性值。

d） 符號G。操作訪問構件屬性值。

e） 符號R。操作銷毀構件對象，即釋放構件對象的屬性內存。

定義1 接口行為信息表。設O代表接口中操作的集合，A代表接口維護屬性的集合，接口行為信息表TO×A×{‘I’， ‘S’ ， ‘G’， ‘R’}。其中： o∈O， a∈A，都有(o，a， ‘ ’)∈T 或(o，a， ‘I’)∈T或 (o，a， ‘S’) ∈T或 (o，a， ‘G’)∈T或 (o，a， ‘R’)∈T之一成立。同時，o∈O，I(o)，S(o)，G(o)，R(o)的交集為空。

I(o)={ a∈A | (o，a， ‘I’) ∈T }表示操作o初始化的屬性的集合

S(o)={ a∈A | (o，a， ‘S’) ∈T }表示操作o改變的屬性的集合

G(o)={ a∈A | (o，a， ‘G’) ∈T }表示操作o訪問的屬性的集合

R(o)={ a∈A | (o，a， ‘R’) ∈T }表示操作o銷毀的屬性的集合

如果接口維護的屬性是對象類型，操作對它的影響，沒有像對基本數據類型變量的影響直觀，要清楚地知道對象的屬性有哪些。當然，對象的屬性也可能是對象類型、信息模型與面向對象中的靜態類圖相似，類型與類型之間存在關聯關系。所以，在信息模型中，對象之間的關聯屬性可以轉換為對象的私有屬性來分析。例如rerservation對象的屬性有resRef:String，dates:DateRange，claimed:Boolean，customer:Customerroom:Room。其中后兩個屬性是rerservation和customer及room的關聯屬性。

22 接口操作模式及其值域

定義2 接口操作模式。它是若干屬性取值組合形成的一個等價類，設接口的行為信息表有n列和m行，即接口維護的屬性有n個：A={a1，a2，…，an}，接口提供的操作有m個：O={o1，o2，…，om}，若屬性的集合{ak1，ak2，…，aks}構成一個操作模式ek=[ak1， ak2，…，aks]。其中:s≥1， ks>ks-1>…>k1≥1，則必須滿足條件：o∈O。

a）對于構成操作模式的每個屬性aki (i=1…s)，一定有(o， aki， ‘I’) ∈T或 (o， aki， ‘S’)∈T或 (o， aki， ‘G’)∈T或 (o， aki， ‘R’)∈T之一成立;

b）對于aj { ak1， ak2，…，aks }， j=1…n，則有(o， aj， ‘ ’)∈T成立。

可以看出，接口操作模式的定義即其求解算法，根據接口信息模型，接口操作模式的求解可自動化，操作模式的劃分是基于對屬性集的操作，是構件對象的狀態發生變化的等價類。

算法1 求操作模式值域的算法。

設構件操作模式的集合為E，對于操作模式ek=[ak1，ak2，…，aks]∈E，設滿足條件1、2接口操作的集合為Ok={oi1，oi2，…，oiq}。其中：iq>iq-1>…>i1≥1，根據操作的后置條件，求取操作模式ek的值域的算法如下：

for j=1toq

{ 對于Ok中的每個元素oij

for t=1tos

{ 對于構成ek=[ak1，ak2，……aks]的每個屬性akt ；

操作oij對其狀態的改變的取值設為集合Akt ；

if(oij， akt， ‘I’) ∈T，則Akt={I};

if(oij， akt， ‘G’)∈T，則Akt={akt};

if(oij，akt，R’) ∈T，則Akt={R};

if (oij， akt， ‘S’)∈T，則根據操作oij的后置條件，概括該操作導致屬性akt的狀態變換，設該操作引起的屬性akt狀態的取值概括為b1，b2，…，br，則Akt ={b1，b2，…，br}，r>=1

}

對于操作oij，則模式ek的取值的集合為Bij= Ak1×Ak2…×Aks

}

并集Vk=Bi1∪ Bi2∪…∪Biq為模式ek的值域。

23 模式值的屬性定義

設已求得的接口操作模式ek=[ak1，ak2，…，aks]值域中的一個模式值為v，為了產生構件行為的狀態，筆者為每個操作模式的值定義了如下屬性：

定義3 v:On。它表示模式ek有合法的模式值v時，一定滿足其前置條件的操作的集合。

定義4 v:Ou。它表示模式ek有合法的值v時，對用戶而言不可達操作的集合，或當前的模式值不可能滿足其前置條件的操作的集合。

定義5 v:Oc。它表示模式ek有合法的值v時，可以改變模式ek的值v到其值域中其他值的操作的集合。

定義6 模式值轉換函數η。假設操作oi改變模式ek的值v為w，即oi∈v:Oc，則定義轉換函數η( oi，v， precondition)=w。其中：precondition是操作oi發生的前置條件，用OCL描述，若precondition=true，稱該轉換函數為無條件轉換，記為η( oi，v， ε)=w。

24 狀態的產生算法

算法2構件行為模型的狀態產生算法。

設構件操作模式的集合E={e1，e2，…，en}，各模式所對應的值域的集合V={v1，v2，…，vn}，接口提供的操作集合O={o1，o2，…，om}，最后產生的構件行為的狀態集合為S，則狀態的自動化產生算法如下：

a）求沖突的模式值對(v，v′)的集合C。設對任意模式ek和ei，它們的值域分別為Vk和Vi，對于v∈Vk和v′∈Vi，若滿足條件v:On∩v′:Ou≠或v:Ou ∩v′:On≠，則(v，v′)∈ C。

b）S =∏i=l..n Vi。

c）對任意的s∈S，若v∈s，v′∈s，并且 (v，v′)∈ C，則S=S-{s}。

d）增加一個初態s0和一個構件消亡的狀態f，則S=S+{s0 ，f}。

S就是最終所求得的構件行為狀態的集合。

25 求解狀態之間轉換的算法

算法3 狀態之間轉換產生的自動化生成算法。

a)對于初態s0，若狀態s={v1，v2，…，v|E|}滿足條件：存在模式值vi對應的模式ek=[ak1，ak2，…，aks]，vi={I，I，…，I}，構成vi的值中共有s個I，則存在無條件轉換δ(s0，ε)=s。

b)對于終態f，從它出發的所有轉換都為空，對于接口中的任意操作o，即δ(f，o)=。

c)對于每個狀態s=(v1，v2，…，v|E|)∈S-{ s0，f}，執行以下算法，求從它出發的轉換：

(a)空轉換。設s:Ou=∪v∈sv: Ou， o∈ s:Ou，則δ(s，o)= 。

(b)到其他非異常的轉換。設s:Oc=∪v∈sv: Oc-s:Ou，o∈s:Oc。

若操作o是構件的消亡操作，δ(s，o)= f；否則，則有δ(s，o)=(w1，w2，…，w|E|)。其中：若o∈vi:Oc，則有wi=η(o， vi， precondition) 或wi=η( o，vi， ε)；若ovi:Oc，則有wi= vi。

(c)循環轉換。s:Ol=O- s:Oc -s:Ou， o∈s:Ol，δ(s，o)=s。

至此，構造出構件的行為模型CBM=(S，O，δ，s0，E，f)。

26 小結

本文通過對十幾個構件案例(如RentalManager構件、AddressManager構件、LibraryManager構件、OrderManager構件等)進行分析，按照本文的算法，所生成的模型都能如實反映構件實際的行為。對于文獻[2]中Account構件，基于操作的規格說明，筆者也構造了它的行為模型，與文中假設提供的自動機模型完全相符。所以本文的方法是有效的。

本文方法的大部分工作都可以自動化，對于手工參與的部分，本文也給出了詳細的步驟和方法。影響方法結果正確性的因素是行為信息表的構造以及操作模式值域的求解，由于行為信息表的復雜度與構件維護的屬性和方法有關。從目前實際開發商銷售的構件來看，大多數構件的方法在幾十個左右，屬性和方法相比更少，所以，這與從頭開始構造構件的行為模型相比，是非常容易并且不容易出錯。

最終求得模型M可以利用編譯技術中對有限狀態機的確定化和最小化算法，對該行為模型進行確定化和最小化，以方便基于行為模型的構件測試。

3 案例分析

31 HotelMgt構件的行為信息表

HotelMgt構件的規格說明如圖1、2所示，它提供了一個接口IHotelMgt，該接口維護的屬性為reservations(即Reservation對象的集合)和hotels(即Hotel對象的集合)。為了構造行為信息表，首先將所有與接口維護的屬性相關聯的屬性都列出，這樣有助于填寫表中元素，然后，根據各操作的后置條件，構造的HotelMgt構件的行為信息如表1所示。為了內容描述的簡練，后續內容用o1代表操作IHotelMgt。

32 HotelMgt構件的操作模式和其值域

由表1和操作模式的定義，求得的操作模式的集合E={e1，e2，e3}。其中：e1=[reservations， hotels]，e2= [reservations]，e3= [hotels]。對于操作模式e1，滿足2.2節中條件1、2的操作的集合O1={IHotelMgt ， makeReservation ， remove};同理，對于e2，滿足條件的操作的集合O2={getReservation ， beginStay}；對于e3，滿足條件的操作的集合O3={getHotelDetails ， getRoomInfo}。

表1 接口IHotelMgt的行為信息表OAReservationshotelsOAReservationshotelso1: IHoteIMgtIIo5: getReservationGo2: getHoteIDetailsGo6: beginStaySo3: getRoomInfoGo7: removeRRo4: makeReservationLL

根據2.2節描述的算法1，求得的各個模式的值域如下：

模式e1的值域V1={ {I ， I}，{reservations+1 ， new_hotels[j]}，{R ， R}}

模式e2的值域V2= { {reservations}，{new_reservations[j]} }

模式e3的值域V3={ {hotels} }

屬性reservations和hotels都是集合，對集合的操作一般有添加(add)元素、刪除元素(delete)、更新(modify)某一元素值，所以，可以將操作引起的集合屬性ai狀態的取值概括為ai+1，ai-1和new_ai[j]。對于集合元素的更新，如果有更多的狀態，new_ai[j]還可以進一步細分。例如，一個構件有一個屬性lightswitchs是電燈開關lightswitch的集合，操作switch可以更新集合lightswitchs中對象lightswitch的intensity屬性值(intensity的取值共四個：off、dim、normal、bright)，那么操作switch引起的集合屬性lightswitchs狀態的取值概括為new_off、new_dim、new_normal、new_bright。

對于HotelMgt構件，操作makeReservation僅對hotels集合中元素hotel的roomType的有效性available修改為1，所以操作makeReservation引起的屬性hotels狀態的取值概括為new_hotels[j]，同理，操作beginStay僅對reservations集合元素re-servation的屬性claimed的值修改為true，所以操作beginStay引起的屬性reservations狀態的取值概括為new_reservation[j]，其它模式值的求解都顯而易見。

33 HotelMgt構件模式值的屬性

由構件HotelMgt的UML規格說明，操作getHotelDetails，getReservation的前置條件為true，beginStay的前置條件在第1章已描述。操作makeReservationhe和getRoomInfo前置條件為hotel→exists(h|h.id=res.hotel and r.room.roomType.nameincludes(res.roomType))。

根據2.3節描述的模式值屬性的定義，求得的各模式值的屬性如下：

a) 模式e1的模式值v11={I ， I}的各屬性:On=o2，o5，o7;Ou=o1，o6;Oc=o4，o7 ;η( o4，v11， precondition)=v12;η(remove， v12 ， ε)= v13。

b) 模式e1的模式值v12={ reservations+1 ， new_hotels[j]}的各屬性:On=o2，o5，o7;Ou=o1;Oc=o7;η(o7，v12，ε)= v13。

c) 模式e1的模式值v13={R ， R}的各屬性: On=; Ou=o2，o3，o4，o5，o6，o7;Oc=o1;η(o1，v13，ε)=v11。

d) 模式e2的模式值v21={reservations}的各屬性:On=o2，o5，o7;Ou=o1;Oc=o6;η(o6，v21，precondition) = v22。

e) 模式e2的模式值v22={ new_reservations[j]}的各屬性:On=o2，o5，o7;Ou=o1;Oc=o5;η(o5 ，v22 ， ε)=v21。

f) 模式e3的模式值v31={hotels}的各屬性:On=o2，o5，o7;Ou=o1;Oc=;η=。

34 HoltelMgt構件的狀態的產生

由算法2，HotelMgt構件的狀態求解過程如下：

a） 先求出沖突的模式對(v，v′)的集合C，C={ c1，c2，c3 }。其中：

c1= ({R，R} ， {reservations})

c2= ({R，R} ， {new_reservations[j]})

c3= ({R，R} ， {hotels})

b）S={s1，s2，s3，s4，s5，s6}。其中：

s1={{I，I}，{reservations}，{hotels}}

s2={{I，I}，{new_reservations[j]}，{hotels}}

s3={{reservations+1 ， new_hotels[j]}，{reservations}，{hotels}}

s4={{reservations+1 ， new_hotels[j]}，{new_reservations[j]}，{hotels}}

s5={{r，r}，{reservations}，{hotels}}

s6={{r，r}，{new_reservations[j]}，{hotels}}

c）其中:s5，s6是不滿足條件的狀態，S=S-{s5，s6}。

d）再增加一個初態s0和終態f，所以最終所求得的狀態的集合S={s0，s1，s2，s3，s4，f}。

35 HotelMgt構件的狀態轉換的集合

由算法3，HotelMgt構件狀態之間轉換的求解過程如下：

a）對于狀態s0，有無條件ε轉換：δ(s0，ε)= s1，δ(s0，ε)= s2；

b）從狀態s1出發的轉換δ(s1，o1)=，δ(s1，o2)=s1，δ(s1，o3)=s1，δ(s1，o4)=s3，δ(s1，o5)=s1，δ( s1，o6)=，δ( s1，o7)= f。

c）從狀態s2出發的轉換：δ(s2，o1)=，δ(s2，o2)=s2，δ(s2，o3)=s2，δ(s2，o4)=s4，δ(s2，o5)=s2，δ(s2，o6)=，δ( s2，o7)= f。

d）從狀態s3出發的轉換：δ(s3，o1)=，δ(s3，o2)=s3，δ(s3，o3)=s3，δ(s3，o4)=s3，(s3，o5)=s3，δ(s3，o6)=s4，δ(s3，o7)= f。

e）從狀態s4出發的轉換：δ(s4，o1)=，δ(s4，o2)=s4，(s4，o3)=s4，δ(s4，o4)=s4，δ(s4，o5)=s3，δ( s4，o6)=s4，δ( s4，o7)= f。

f）從狀態f出發的轉換為空。

由上述步驟，構造的IHotelMgt構件的行為模型CBM=(S，O，δ，s0，f)，進一步利用編譯技術中對有限狀態機的確定化和最小化算法，對M進行確定化和最小化，最終得到的行為模型如圖3所示。

4 結束語

在基于模型的黑盒測試中，研究的內容不僅是對使用的行為模型如何進行測試，而且行為模型的獲取也更為重要。文獻[9~15]通過使用動態建模的信息獲取系統級行為模型，從而進行軟件的集成測試。Whittaker[10]提出了手工構造行為模型系統的指導方法。在此基礎上，他的學生El-Far[9]提出了一個用操作模式描述軟件狀態空間的框架，給出了基于靜態的軟件規格說明自動構造軟件行為模型的方法，使得狀態和狀態之間的轉換的產生可以自動化。但是，該方法的實現有個前提，即軟件的操作模式、操作模式的值域以及操作模式值的各屬性值是已知的，然而，它們的手工求解相當困難。

在El-Far[9]等人研究的基礎上，本文提出了基于靜態的UML構件規格說明自動構造構件行為模型的方法，方法的自動化程度較高，生成的模型可直接用于構件的單元級測試。

由UML構件的靜態信息獲取構件行為模型的方法是新穎的，它同樣適用于由UML類的靜態信息獲取類行為模型，用于基于狀態模型的類測試。方法構造的行為模型可以作為構件測試的測試模型(如有限狀態機和馬爾可夫鏈等)使用。這樣，為了測試一個商用構件，僅要求UML構件規格說明，而且UML被用來對構件進行建模是目前流行的一種方法，很容易被構件開發商所接受和支持[16]。研究成果對于構件的開發者和使用者的黑盒測試以及第三方構件的評估都很有價值。

參考文獻：

[1]LIU W， DASIEWICZ P. Formal test requirements for component interactions[C]//Proc of IEEE Canadian Conference on Electrical and Computer Engineering. Edmonton:[s.n.]， 1999.

[2]BEYDEDA S， GRUHN V. An integrated testing technique for component-based software[C]//Proc of ACS/IEEE International Confe-rence on Computer Systems and Applications. 2001.

[3]GAO J， ESPINOZA R. Testing coverage analysis for software component validation[C]//Proc of Computer Software and Applications Conference. 2005:463- 470.

[4]GAO J， GOPINATHAN D. A systematic regression testing method and tool for software components[C]//Proc of the 30th Annual International Computer Software and Application Conference. 2006.

[5]KIM J. Automatic testing for software reuse[D]. Melbourne:[s.n.]，2003.

[6]SHUKLA R， STROOPER P， CARRINGTON D. A framework for reliability assessment of software components[C]//Proc of CBSE. Berlin， Heidelberg: Springer-Verlag ，2004:272-279.

[7]SHUKLA R， STROOPER P， CARRINGTON D. Tool support for statistical testing of software components[C]//Proc of the 12th Asia-Pacific Software Engineering Conference. 2005.

[8]CHESSMAN J， DANIELS J. UML components: a simple process for specifying component-based software[M]. Boston:Addison-Wesley， 2001.

[9]EL-FAR I K I. Automated construction of software behavior models [D].Florida: Institute of Technology Melbourne， 1999 .

[10]WHITTAKER J A. Stochastic software testing[J]. The Annals of Software Engineering， 1997，4:115-131.

[11]BEYER M，DULZ W，ZHEN F. Automated TTCN-3 test case generation by means of UML sequence diagrams and Markov chains[C]//Proc of the 12th Asian Test Symp. Los Alamitos:IEEE Computer Society， 2003:102-106.

[12]YAN Jing， WANG Ji，CHEN Huo-wang. Automatic generation of Markov chain usage models from real-time software UML models[C]//Proc of the 4th International Conference onQuality Software. 2004:22-31.

[13]RIEBISCH M， PHILIPPOW I. UML-based statistical test case gene-ration[C]//LNCS， vol 2591.[S.l.]: Springer， 2003.

[14]HUBNER M， PHILIPPOW I， RIEBISCH M. Statistical usage testing based on UML[C]//Proc of the 7th World Multiconferences on Systemics. 2003.

[15]顏炯， 王戟， 陳火旺. 基于UML的軟件Markov鏈使用模型構造研究[J]. 軟件學報，2005，16(8):1386-1394.

[16]ESPINDOLA A P， BECKER K， ZORZO A F. An extension to UML components to consider distribution issues in early phases of application development[C]//Proc of the 37th Hawaii International Confe-rence on System Sciences. Hawaii: IEEE， 2004.

[17]BERTOLINO A. Software testing research achievements， challenges， dreams[C]//Proc of Future of Software engineering Conference. 2007:85-103.