1.6 語義重用的Agent和組件

自從計算機科學出現以來，可重用性一直被認為是開發技術重點考慮的主要特性之一。針對創建可重用軟件單元的需求，先前的“過程”，以及后來出現的“類”都是最直接的反應，這么做的目的在于：

● 加速新系統的實現；

● 通過組合大量的現有組件，確保所實現系統的質量。

面向組件的軟件工程已經定義了采用組件構建系統過程中的大部分特性，并且確認了任何改進重用性的技術都應該考慮的三個概念：語義互操作性（Heiler，1995），語義的組合性（Pratt等，1999）和語義擴展性（Fankhauser等，1991）。這些概念的形式化定義在文獻中找不到，對這些概念的形式化描述一般需要“非組件元模型”的部分概念。通過考慮Agent元模型的基本要素，能夠給出這些概念的形式化定義。

1.語義互操作性

軟件組件的前期研究在很多方面已經認識到了語義互操作的問題，并且Agent社區也已經開始研究這個課題。例如，最近對于Web服務能力特征的研究工作就遵循了已有成果所給出的指導（McIlraith和Martin，2003）。但令人奇怪的是，至今仍沒有對語義的互操作性達成一致的定義，這個概念在不同的文獻中可能會有一些出入，使用不同的名字，甚至有的名字可能已經使用一段時間了。

組件的語義互操作性概念來自于對語法互操作性的合理擴展，如CORBA（以及DCOM和Java RMI等類似標準）所提供的互操作性。CORBA允許組件交換消息，并且就消息的語法達成一致。消息交換的語義是隱含的，即對一個CORBA接口方法的調用一般被隱含定義如下：方法的調用實際上就是方法本身的運行。但是并沒有提及這個調用的具體結果，也就是在方法結束運行后，執行方法的組件將會對外部世界產生什么樣的結果。這個結果被認為是針對特定應用的，并且完全依賴于程序員的。程序員負責讀接口文檔，并且決定何時以及如何調用方法。

語法互操作性抑制了組件的自動裝配，因為當客戶決定執行服務組件的方法時，并沒有提供手段去推導這個調用的結果。語義互操作就是采用方法調用結果的形式化描述，來實現對組件接口的擴展，從而允許客戶自主決定什么時候，以及如何來調用這個方法。

如果認為調用一個組件方法類似于要求Agent執行一個動作，那么就可以把上面的描述應用到Agent上。利用Agent的特征，能夠對語義互操作形式化如下（從客戶立場出發）：

給定兩個 Agent C 和 S∈acquaintanceC，它們被認為是語義互操作的，當且僅當：?g:GCg,GCdone(delegate_to(C,S,g))?KS GCdone(delegate_to(C,S,g))

這里delegate_to(C,S,g)是C的一種抽象行為，其結果是KCGSg。

這個定義闡述了：如果Agent C（在某個時間點上）想要實現目標g（GCg），并且它想要把這個目標委派給S（GCdone(delegate_(C,S,g))），那么S將知道這樣一個愿望（KS）。用這種方式，可以很容易地捕捉到所丟失的信息，這是語義互操作的核心。如果Agent有一個目標，那么它能把這個目標傳達給一個提供服務的Agent，而不會降低任何精度。目標的通信方式并不重要，唯一重要的結果就是通信需要將目標委派給服務提供者。

語義互操作的定義是從客戶的角度出發，因為C是g的發起者，但是并沒有提及S希望為一組可能的客戶提供服務。一個相似的定義是從服務者的角度出發，但是這樣的定義基本上等價于已經展示的，對它的討論將不會為實現本章增加更多的東西。

對語義互操作的定義有一個相當有趣的結果：如果考慮一個多Agent系統，其中的Agent僅僅打算進行語義互操作，那么具有“achieve”原語的基本ACL就已經夠用了。這一點也不奇怪，因為ACL的工作很容易通用化。

語義互操作的成果不僅是改進可重用性的一種方式，也是促進優化的一種可能方式。通過采用日常的語法進行互操作，一個Agent要求其他Agent執行動作從而實現目標，即利用向其他Agent委派任務來實現自己的目標。語義互操作充分利用了目標委派，這或許會促進交叉優化。

2.語義組合性

通過組裝Agent來實現MAS，不僅是Agent采用最佳方式進行通信的問題，還要允許它們能夠互相找得到。對于組合性來說，互操作性是必要但不充分的：語義互操作要求S∈acquaintanceC，我們需要對此進行詳述，以獲取完整的語義組合性。

在面向組件的軟件工程文獻中，語義組合性已經被研究了很長時間。它起始于關于對象組合性的著名研究成果，目前在面向方面（aspect oriented）的程序設計社區中很活躍。語義組合性所隱含的基本思想是，應該將組件所提供的一組服務自由組合，而不受以下限制：定位合適的服務提供者，接口與服務提供者之間不匹配等。這就要求被組合的組件不僅要有兼容的接口，而且要對世界做出一致性假定。語義組合性已經擴展到了Agent，可以通過使用與語義互操作相同的技術來使它更加形式化。如果不對Agent委派目標的方式加以限制，可以說兩個Agent在語義上是可以組合的，更加形式化的語義組合性定義如下：

給定一組n個Agent，MAS={A1,A2,A3,…, An}，它們被認為是滿足語義可組合的，當且僅當：

?C∈MAS,?g:GCg,?A∈MAS:slovesA(g)

GCdone(delegate(C,g))??S∈MAS:slovesS (g)，KS GCdone(delegate(C,S,g))這里slovesA是A所能解決的目標，delegate（C，g）是C的一種抽象行為，結果是KC(?X∈MAS:GXg)。

這個定義闡明了如果Agent C有一個目標，并且在MAS中有一個Agent S能夠實現這樣的目標，那么C可以把目標委派給S，而不會由于通信引起精確度的損失。用這種方式，能夠捕捉由于語義互操作引起的信息損失，而不需要C知道S。目標如何通信，與誰通信都不怎么重要，組合的最終結果是MAS中的一個Agent將會為C實現目標。

這個定義并不要求客戶在委派任務之前就知道服務提供者Agent，也不保證在委派以后知道被選中的提供者。這和明確選擇服務提供者的一般方法相兼容，因為這兩種方法都符合這個定義：客戶能根據它的目標來確認所選擇的服務提供者。例如，如果Agent C想要S幫助它實現目標j，那么C所實現的目標就是g=KSGCGSj。

3.語義擴展性

通過參看有關面向組件的軟件工程文獻，我們發現追求可重用性不僅要構造可重用的組件，還要使這樣的組件具有擴展性（Booch，1994）。擴展性主要提供了兩種關于重用的可能性：

● 新組件作為現有組件的擴展實現；

● 用一個不同的組件來代替現有組件，而不引起系統的其余部分發生變化。

傳統上認為第一種可能性是面向對象程序設計的基礎：它通過繼承和多態來支持創建新的對象類。這仍然是一種實現重用的好方式。但是第二種可能性現在更受推崇，因為它允許重用整個系統，而不僅是單個類。這種所謂的“基于框架的可重用性”依賴于這種可能性，即一個組件替代另一個組件時，系統（即框架）的其余部分沒有感覺到這樣的替代。

面向對象和面向組件的方法通過繼承和多態來實現基于框架的可重用性，因為它們假設，如果兩個組件屬于同一個類（即它們是同類型的），那么它們就是可以替代的。這很明顯是不夠的，尤其是類型等價的相互替代可能存在下列問題：這兩個類或許會提供同樣的方法，但是這些方法的語義，即組件對外部世界所做的，或許是完全不同的。換言之，這兩個類或許結構相同，但語義不同（Fankhauser等，1991）。

語義擴展背后的思想是，能夠用一個對初始組件的擴展版本來替代這個組件，同時保持操作語義不變，客戶仍然能夠像替代之前那樣操作。

考慮面向Agent的思想，并且利用在前面章節所介紹的形式化，可以將語義擴展性形式化定義如下：

定義（語義擴展性）：給定兩個Agent B和D，可以說D是B的一個語義擴展，當且僅當?g:slovesB(g) ? slovesD(g)

這個定義闡述了（在各個時間點上），B能解決的D也能解決，即從任何可能的客戶觀點出發，B所能提供的客戶感興趣的服務，D都能提供，那么它們是可以互相替代的。

如果我們把Agent看做是可重用的原子單元，那么語義擴展性與語義組合性一起將Agent的可重用性最大化。Agent可以根據它們的目標自由組合，并且可能被其他具有擴展能力的Agent所替代，最終實現完全重用，即由替代Agent完全構成MAS。

4.大致語義可重用性

我們已經討論的可重用性模型很明顯是理想化的，因為它并沒有提供支持組合和擴展的任何可操作性手段。然而，如果使goalsA和slovesA公開化和清晰化，那么語義組合性僅僅是把一個目標從客戶傳遞到服務提供者的問題，在最一般的情況下，這僅僅是個通信的問題。可以使用一個匹配Agent來將客戶同服務提供者聯系起來，或者依靠中間件基礎設施。在后一種情況中，可以使用元空間將目標從客戶提交給服務提供者，或者依靠直接的消息傳遞，程序員可以在客戶端進行明確的編碼。類似的，使slovesA公開和清晰化，能夠確保語義的可擴展性，因為客戶在從服務提供者S請求一項服務之前，總要檢查slovesA。

但是，goalsA和slovesA在大多數情況下不能被計算，只能依靠它們近似的公開和明確。組件和Agent提供了不同的近似，在重用性方面Agent比組件所具有的優勢正來自于這些不同的近似。ParADE框架（Bergenti和Poggi，2001）給出的語義可重用性大致如下：

（1）BA?KA：Agent的知識接近于Agent所相信的，即通過對環境感知運用穩定規則推導出來。

（2）IA?GA：Agent的目標近似于意圖，能夠從信念和計劃引擎所派生出來的規則計算出來。

（3）capabilitiesA?slovesA：Agent所能解決的目標近似于它行動的后續條件。這些后續條件考慮了Agent的狀態和行動完全施行以后的環境狀態。

組件的元模型依賴于更強的假設：

（1）stateA?KA：組件的知識接近于組件的狀態，即它的屬性值及與其他組件的聯系。（2）postcondition-of-next-callA?goalsA：組件的目標接近于包含所激發組件方法后續條件的集合。

（3）postconditio?slovesA：組件所能解決的目標接近于它的方法后續條件。這樣的后續條件在一個方法完全施行以后根據組件的狀態進行定義，但是并沒提及環境的狀態。

大致上，Agent比組件的可重用性更好，因為框架要素（如匹配Agent）負責使客戶和服務提供者之間的信息流暢通，對于如何執行它的工作有著更加精確的信息。

當組件方法的后續條件在方法完全施行后只考慮服務提供者的狀態時，Agent在語義可擴展性上比組件更好，因為它們使用能力描述標志來構成Agent周圍環境的條件。因此，出于確保語義擴展性的目的，Agent能夠為行動結果提供一個非常精確的信息。

討論：Agent不僅適用于非通用類型的應用（一般會用到“學習”和“自治性”這樣的高級特征），而且還是對其他成熟技術的一個有效替代。

● 為開發人員提供了比目前其他技術更高層次的抽象；

● 就可重用性而言比組件有著具體的好處。

第一點，采用更高層次的抽象工作，雖然有很明顯的好處，但也有一個普遍的缺點：緩慢的執行速度。為了能夠充分地利用Agent的可能性，需要實施一個具備推理能力的Agent模型，這種Agent可能速度比較慢。現今，這似乎并不是一個障礙，因為速度并不總是具有最高的優先權，例如對于市場而言，時效性及整體質量經常更加重要。就第二點而言，Agent需要為重用性的改善付出一定代價：速度會更慢。根據定義，使用目標委派取代任務委派會要求“手段—目的”推導，會面臨實施低速Agent的可能性。

在這兩種情況下，Agent的性能下降緩慢。可以選擇進行多少推理，也就是速度降低多少，這需要針對每個Agent進行考慮。也許會出于以下原因使用Agent：

● 特別復雜的情況，能受益于更高層次的抽象；

● 希望在許多不同的項目中自由地擴展和組合。

相反，如果對速度有迫切需求時，可以依靠反應Agent或組件。這種判斷標準應該是很好的，因為一個Agent越復雜，附加值越多，我們就越想重用它，以及采用它來構成其他Agent。而且，反應Agent與組件是完全等效的，因此使用面向Agent的方法來代替面向組件的方法并不會失去什么。