構件的服務模式規約

摘要： 基于用戶需求和構件服務在匹配情況下的等價性考慮，從方法調用序列角度給出了服務的定義；依據方法之間的關聯性分析，給出了服務模式的概念和確定構件服務模式的方法；最后給出了構件的服務模式規約。通過建立服務模式規約，從構件提供者角度提供了一種確定構件匹配有效性的方法。

關鍵詞：軟件構件； 構件服務； 服務模式； 服務模式規約； 匹配有效性

中圖分類號：TP311文獻標志碼：A

文章編號：1001－3695(2008)04－1073－02

構件組裝式的軟件開發實現了構件開發與軟件開發的分離，使得構件提供者專注于構件的內部功能和接口的設計；而構件使用者通過了解構件的接口，專注于構件的選擇及組裝，從而提高軟件開發效率。但是，基于構件的軟件開發技術仍有許多問題亟待解決，如構件檢索的效率。構件檢索效率主要包括查準率、查全率和響應速度。由于構件設計與組裝工作的分離，使得構件化軟件的組裝、測試工作也更加復雜[1]。

構件規約是構件提供者與使用者之間重要的交流信息，它是構件使用者了解構件接口功能的惟一途徑。因此，規約中構件描述的精確性和完備性對于構件的易用性（包括檢索、適配以及測試）有重要影響。構件規約應該提供構件使用者所需要的信息[2]。但是目前的構件規約對于構件能夠提供的服務缺乏一些必要信息的描述，如構件匹配即服務的有效性等。

本文的基本思想是：提供者基于其對構件源代碼、內部結構及功能的把握，從構件在應用中可能的上下文關系角度確定一個服務應該遵循的模式，從構件提供者角度給出服務模式規約，可以快速實施構件的檢索匹配，保證構件匹配的有效性。本文工作基于如下假設：使用者的需求和構件提供的服務在兩者匹配情況下是等價的。從構件使用者的角度，一個具體的需求就是可以使用哪個或哪些構件接口提供的服務；而對于構件而言，構件的哪個或哪些接口提供的服務可以響應使用者需求。

1三種常見的構件規約

目前，依據描述內容的不同，構件規約主要有三種形式：接口規約（interface specification）、行為規約（behavior specification）和非功能性規約（non－function specification）。由于構件的非功能性描述比較復雜，目前研究的重點主要集中于前兩者。

1）接口規約

構件接口規約是關于構件接口的語法描述，如接口名稱、類型、屬性等，提供用戶理解和使用構件的基本信息，其描述簡單并易于實現。在接口規約中，一個構件提供一組被命名的接口（或類型），每個接口命名一組操作，每個操作有零個或多個輸入/輸出參數及相關聯的語法規約。接口規約的典型例子是CCM（CORBA component model）中對構件的描述，CCM為CORBA構件定義了多種接口[3]。但是接口規約缺乏對構件內部邏輯的描述，所以其對構件的描述是初步的。

2）行為規約

行為規約可看做是接口規約的擴展，是對構件操作語義的描述。一個構件實現一組接口；接口由一組操作組成；一組前置條件和后置條件與操作相關聯。行為規約包括實例不變式、操作的前置條件和后置條件、一般斷言、循環變量和循環不變式[4，5]。行為規約一般采用基于一階謂詞邏輯的進程代數來描述，也有使用UML等來描述的。Michihiro利用一個特殊的代數行為規約Projection－style來描述構件行為。該規約包括構件規約和通信規約兩個部分，用于描述構件的樹結構如事件模式、靜態結構和動態結構[6，7]。Eriksson利用UML的協作、序列和狀態圖來描述構件的行為[8]。

3）非功能性規約

目前對非功能性規約的研究剛剛開始，如Steffen用mea－surement的概念表達系統的非功能性，定義了四種非功能規約，即內在規約、外部規約、資源規約和容器規約，分別描述構件實現屬性、一個服務的屬性、資源屬性和與非功能屬性相關的容器行為[9]。Franch認為非功能性信息包括非功能性屬性、非功能性行為和非功能性需求。非功能性屬性包括用于描述和評價該軟件的屬性，如所屬領域、類別、適用范圍等；非功能性行為是所有值的指派；非功能性需求則涉及到的所有約束[10]。

目前，上述構件規約的主要不足是對構件可能被應用的環境缺乏考慮，沒有一種有效的描述形式對構件匹配的有效性進行驗證。

2構件的服務模式規約

2．1基本概念

為了便于描述，本文采用如下結構描述一個構件、構件接口及接口中的方法：

comp_1（interface_1，…，interface_n），名字為comp_1，包含n（可以是1）個用戶可視接口。

interface_i（func_1，…，func_m），名字為interface_i的接口提供m個可調用的方法（或功能）。該接口的所有方法構成一個集合，記做method_i。

func_i（input，output，mexpresions），名字為func_i的方法，包含輸入、輸出及相關約束條件（包括調用方法必須滿足的前置、后置條件）。

一個構件能夠提供的一個服務可以用定義1描述。

定義1服務構件接口中若干方法組成的一個有序調用序列稱做構件的一個服務。

一個構件所有接口中的方法集合記做method_all，則method_all=method_1∪method_2∪…∪method_n（“∪”表示集合的并運算）。

設|method_all|=N，則所有方法可能組成的有序序列個數為N!+…+2!+1。顯然，并不是所有的方法有序序列都構成服務，因為在構件設計期間，根據構件的功能設計規范，方法之間的關聯關系已經確定，即若干個方法之間通過協作（依賴）提供相應的對外服務。因此，構件提供者依據構件的功能設計規范，分析方法之間的關聯關系，進而確定合理的方法有序序列即構件服務。

定義2頭方法（head）和尾方法（tail） 一個調用序列中的起始方法和結束方法。

定義3方法依賴（function dependence） 方法func_i依賴于func_ j當且僅當序列中出現func_i時必有func_ j是其直接或間接的前驅，記為func_ j→func_i。

定義3強調的是這樣一個事實：當一個方法被調用時，與之相依賴的其他方法會同時被調用。

根據定義2，在一個方法調用序列中，所有其他方法都依賴于頭方法，稱為頭方法依賴；而尾方法依賴于序列中的其他方法，稱為尾方法依賴。

定義4服務模式（service pattern），即構件的服務必須滿足的序列約束，是一個三元組（H，T，R）。其中：H是可作為調用序列頭方法的方法集合；T是可以作為調用序列尾方法的方法集合；R是調用序列中除了頭方法依賴和尾方法依賴之外存在的方法依賴。

2．2創建服務模式的方法和遵循的原則

為了給出一個構件的服務模式，構件提供者需要對構件接口中的每一個方法實施確認下面三個問題：

a）該方法能否作為一個服務（調用序列）的頭方法？

b）該方法能否作為一個服務（調用序列）的尾方法？

c）除了作為服務的頭或尾方法外，該方法的調用依賴于哪些方法？

按照上述三個問題要求實施的操作過程就構成了創建一個構件的服務模式的方法步驟。

本文創建的服務模式遵循如下原則：服務應該滿足構件的功能設計規范；服務模式體現構件服務的有效性特征。

示例：一個自動機描述的構件video，提供的方法如圖1所示。根據功能設計規范，構件video提供play（播放），vol_up、vol_down（音量調節），bright_up、bright_down（亮度調節），pause（暫停），stop（停止）等功能方法。

構件video要提供一個完整的服務，這些方法之間具有下列關聯關系：a）任意一個調用序列中，play是服務的起始調用方法，而stop是結束調用方法；b）在序列中間如果調用了pause，則其后會有play調用，即有pause→play； c）如果調用了vol_up或vol_down或bright_up或bright_down，則它們可出現在序列中除了起始和結束位置外的任意一個位置。

根據上述分析，構件video的服務模式是（H，T，R）。其中：H={play}，T={stop}，R={pause→play}。

根據得到的video服務模式，調用序列{play，pause，bright_up，play，stop}、{play，bright_up，bright_down，stop}是有效的構件服務，而{pause，stop}就不構成服務。

2．3服務模式規約

在2.1和2.2節的基礎上，對構件的服務模式進行如下規約：

service pattern {

head－functions： //頭方法集合H

function－name，interface－name; //方法及所在接口

……

tail－functions： //尾方法集合T

function－name， interface－name;

……

dependces： //方法依賴集合R

〈function－name1，function－name2〉;

//表示function－name1→function－name2

……

}

根據服務模式定義，規約包含三個部分：head－functions聲明可用做服務（方法序列）頭的方法集合，并聲明該方法所在的接口；tail－functions對應尾方法集合聲明；dependces對應除了頭方法和尾方法依賴之外的其他方法依賴聲明。

3結束語

隨著軟件規模的擴大和復雜程度的提高，構件化軟件復用

開發技術以及軟件開發自動化成為適應軟件發展趨勢的主流開發技術。但是構件技術（如模型、規約方法）沒有一個統一的標準，這阻礙了構件化軟件開發技術的廣泛應用。提高構件的易用性是亟待研究解決的問題。

本文從提供者角度，依據構件的功能設計規范對構件可能提供的服務（對應于被應用環境）進行了模式分析。構件的服務模式規約可以作為目前常用構件規約的一種擴充，對于自動化實現構件服務的有效性驗證提供了一種可能。本文通過服務模式規約的方式，最大程度擴展了構件提供者對于構件使用者服務需求的一種預測，而不是針對某一個具體的服務。其優點是：a）對構件提供者，通過構件方法之間的依賴性分析，了解構件可能行為以及運行方式，這對于生成有效測試用例、實施構件行為測試是有幫助的；b）從構件使用者角度，自己的需求應該盡可能地與構件的功能設計規范一致，而構件服務模式正是構件功能設計規范的邏輯體現，有助于提高需求與構件之間的匹配有效性。

參考文獻：

[1]HARROLD M J. Testing: a roadmap[C]//Proc of International Conference on Software Engineering. New York: ACM Press， 2000:35－46.

[2]LUDERS F， LAU K K， HO S M. Specification of software components[M]//Building reliable component－based software systems.[S.l.]: Artech House， 2002.

[3]OMG. CORBA component v3.0 formal/02－06－65[R/OL]. http://www.omg.org/technology/documents/corba－spec－catalog.htm.

[4]HOLLOWAY C M， BUTLER R W. Impediments to industrial use of formal methods[J]. IEEE Computer， 1996，29(4):25－26.

[5]FINNEY K. Mathematical notation in formal specification: too difficult for the masses?[J]. IEEE Trans on Software Engineering， 1996，22(2):158－159.

[6]MASTSUMOTO M， FUTATSUGI K. Highly reliable component－based software development by using algebraic behavioral specification[C]//Proc of the 3rd IEEE International Conference on Formal Engineering Methods. Washington DC: IEEE Computer Society， 2000:35－43.

[7]MATSUMOTO M， FUTATSUGI K. Simply observable behavioral specification[C]//Proc of the 6th Asia－Pacific Software Engineering Conference. Washington DC: IEEE Computer Society， 1999:460－467.

[8]ERIKSSON H E， PENKER M. UML toolkit[M]. New York: Wiley， 1997.

[9]ZSCHALER S. Towards a semantic framework for non－functional specifications of component－based systems[C]//Proc of the 30th EUROMICRO Conference. Washington DC: IEEE Computer Society， 2004:92－99.

[10]FRANCH X. Systematic formulation of non－functional characteristics of software[C]//Proc of the 3rd International Conference on Requirements Engineering: Putting Requirements Engineering to Practice. Washington DC: IEEE Computer Society， 1998:174－181.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”