使用 UML 建構代理人導向軟體工程之研究-以猜數字為例楊錦潭 1 簡世宇 2 1高雄師大共同科, 2資訊教育研究所 高雄市苓雅區和平一路 116 號 TEL: (07)7172930 ext 3514 E-mail:yangdavnknucc.nknu.edu.tw 摘要本文目的在於探討智慧型代理人如何透過 UML 進行代理人之分析設計與在 JADE(Java Agent Development Environment) 平台的實作，由於代理人導向程式語言 (Agent-Oriented Programming; AOP)是一種程式設計的新典範(Agent-Oriented Software Engineering; AOSE)。目前AOSE已然受到全球代理人研究者的矚目。本文以一簡單 而典型的代理人系統-猜數遊戲為例，說明代理人程式系統化開發程式過程,運用 建構物件系統模型的視覺化工具-UML搭配RUP的方法論，發揮UML擴充機制進而 發展符合AOSE的制式化開發流程。關鍵 詞AOP. JADE、智慧型代理人(In tellige nt Age nt)、UML一、 背景、円在時間點上智慧型代理人(In tellige nt Age nt; IA或簡稱代理人)正是人工智慧 的新顯學。由於傳統的人工智慧,並未實踐讓電腦真正的包含人類之智慧,再加上傳統的 人工智慧至今仍舊缺乏基本的軟體工程(Software Engineering)方法,讓人工智慧的 程式設計師可以依樣畫葫蘆的進行程式設計。因此, 許多人對人工智慧的失望也就 不言可喻了。目前的分散式網路應用程式(Distributed Web Application)環境所衍生 出來的問題是任何過去的軟體工程典範無法加以解釋或處理的,因為分散式網路應用 程式是由分散式的控制與資料在不同的地方,各行其是,但在共同執行一個任 務時,則是透過溝通的方式來達成目標; 由於其中每一部電腦的軟體都有它自己的任務 難免各任務之間產生衝突的情況。例如：網路頻寬、安全等資源、計算資源等等。目前 在國內代理人軟體已成功的被開發與應用於遠距教學1旅遊規劃2、電子商務3、等 等，但它是否可以演變成新典範之關鍵則有下列四個必要條件：(一) 、智慧型代理人的模式可真正解決網路上或分散式系統所衍生的問題，如果智慧型代理人可以大大提昇由舊典範辦不到或採用新典範下執行效率可以大幅提昇 時，則智慧型代理人的技術與模型典範將迅速在 5 年內取得軟體工程的主流地 位，請下物件導向程式技術典範目前龍頭的地位11 ,4。(二) 、既有系統(Legal system)與應用程式如何轉化成智慧型代理人的模式，如果既有應用程式只要外包住智慧型代理人的框架，則既有的應用程式不用重寫即可達成 原來的工作。(三) 、智慧型代理人必需提供標準的開發平台,如:由FIPA10所製訂開發平台,提供了AMS(Agent Management System), ACC(Agent Communication Channel), DF(Directive Facility) o未來如:美國In prise軟體大廠提供整合式開發環境，使低 階如:多執行緒(Multiple threading、代理人的溝通機制可以由開發平台來完成之， 如此一來,智慧型代理人程式設計師集中全力於應用程式的分析與設計。(四) 、代理人必需提供分析與設計模型:在物件導向程式技術典範下,UML提供視覺化分析與設計開發工具，而RUP(Rational Unified Process)7則是提供物件導向 設計的方法。UML開發工具就如傳統程式設計的流程圖作為檢驗撰寫程式的邏 輯, UML 則是為物件導向程式流程而設計軟體工具,符合由不同的使用者共 同可以確認規格、物件分析、物件設計的基礎。相同的道理，代理人必得提供如： Agent-UML的分析工具來協助代理人程式設計師開發代理人程式1。隨著對於應用代理人技術的需求日益增加，代理人導向的軟體也愈趨龐大且複 雜。為有效應用代理人技術，系統化開發程序有其必要性。因此本文將以代理人技術實 作一猜數遊戲系統為例，說明如何有系統地完成分析、設計及在 JADE(Java Agent Development Environment)4 實作一代理人導向軟體。而所謂代理人的定義，如今仍然眾 說芸芸12，但基本上代理人應具有立即反應(Reactivity )自主性(Autonomy )目 標導向(Pro-activity )及合作(Cooperation )等四項特性。本文針對物件導向技術中常用的塑模語言UML結合其固有的擴充機制，因為UML 提供具有良好定義的元素名詞、對應符號及使用的語法，以方便使用者從物件導向的觀 點建構相關的模型。二、 猜數遊戲的代理人系統本系統內有兩類代理人，一為猜數遊戲管理者( Guessing Game Manager Agent， 簡稱GGMA)，另一則是遊戲回應者(Game Respo nder Age nt，簡稱GRA)GGMA 負責主導整個猜數遊戲的進行，包括出題、找尋回應者、猜數過程並記錄，及顯示最後 結果。因此,GGMA與GRA主要任務分別是負責進行出題與猜題,GRA透過互動與 GGMA相同配合，共同完成整個遊戲，在本系統之外可以有多個GRA卻只能有一個 GGMA。共演算法如表2-2所示，而其執行結果如圖2-1。GGMA主要虛擬碼：max = random(2000);answer = random(max);send max to GRA;finish = false;repeatwait for guess from GRA;if (answer guess) then level = “higher”； finish = false; if (answer guess) then level = “lower” ; finish = false; if (answer = = guess) then level = “bingo” ; finish = true; until finish = = trueendGRA的主要虛擬碼：wait for max of GGMA;start_num = 0;end_num = max;guess = max / 2;send guess to GGM 代wait for call for proposal(cfp) from GGMA;finish = false;repeatif (level = = “bingo”)then answer = guess; finish = true; else if (level = = “higher”)then start_num = guess; finish = false; if (level = = “lower”)then end_num = guess; finish = false; guess = (start_num + end_num) / 2;send guess to QA;wait for level from GGMA;until finish = = trueendAA1 alubasnb:1099/JADE表2-2: GGMA與GRA的演算法Agent QAalubasnb:1099/JADE 啓動！開始出題答案是：了50AA1 alubasnb:1099/JADE :最大値爲何？QAalubasnb:1099/JADE : 1200AA1 alubasnb:1099/JADE :我猜 600QAalubasnb:1099/JADE :再髙一點！AA1 alubasnb:1099/JADE :我猜 900QAalubasnb:1099/JADE :再低一點！AA1 alubasnb:1099/JADE :我猜 750QAalubasnb:1099/JADE :恭喜你，答對了山!Agent AA1 alubasnb:1099/JADE 啓動！AA1 alubasnb:1099/JADE :最大彳直爲何？ QAalubasnb:1099/JADE :最大値爲 1200AA1 alubasnb:1099/JADE :我猜 600QAalubasnb:1099/JADE :再高一點！AAlalubasnb:1099/JADE :我猜 900QAalubasnb:1099/JADE :再低一點！AAlalubasnb:1099/JADE :我猜 75QQAalubasnb:1099/JADE :答對了!答案是 750圖2-1:GGMA與GRA之實際執行情形這個系統包含上述代理人的四項特性。例如GGMA會對於環境的變化，好比說GRA的出現，有所反應為立即反應 系統可以存在多個GRA，而GRA是否接受GGMA的邀請卻可各自決定即是自主性。GGMA所有活動均朝向完成猜數遊戲的目的而前 進，為目標導向，而整個目的需要 GGMA 和 GRA 相互配合則是互助合作。二、 系統實作步驟在物件導向技術中，透過 RUP 軟體開發主要步驟不外乎找出系統需求、物件 導向分析、物件導向設計、系統實作與測試等四項步驟，其又以前三項為建構抽象化模 型的主要工作，可以獨立於開發平台及程式語言之外。本文將以猜數遊戲為例，說 明如何系統化分析、設計及實作一代理人導向軟體。（一）、系統需求 所有軟體系統開發，一開始委託方需和開發者必須就軟體應有功能達成共識，即 為系統需求。系統需求為所有參予者共同制定，其中包括電腦專家及其它領域的人士。 為促進彼此之間的溝通，採用一通俗易懂的方式來描述需求規格為合理有效率的做 法。在UML中，通常由繪製使用案例圖示（Use-Case Diagram ）出發，逐一找出應 有的軟體功能。（二）、使用案例圖示使用案例圖示主要由參與者（Actors ）和使用案例（Use Case ）兩種圖示元素所 構成。參與者可以是真實世界中的人、物或外部系統，而使用案例則表示系統可提供的 主要功能。整個使用案例圖示係從參與者和系統之間的互動來定出系統需求。在 UML 中參與者通常不在開發範圍之內，其主要功能在完成使用案例的定義。轉 到AOP的領域時，參與者有可能消失而由自訂樣版模式（Stereotype ）的 類別取而代之，因此屬於系統的一部份。原有的使用案例則用於描述代理人之間應完成 的主要功能，整體圖示如圖 3-2。從圖 3-1 中可以了解，系統內主要有 GGMA 及 GRA 兩種代理人，分別需完成選擇回應者及猜數遊戲兩個使用案例。 GGMA 及 GRA 在兩個使用案例中，各有其不同角色，分別使用UML中的註釋（Note ）加以說明。圖3-1猜數遊戲使用案例圖示圖3-2代理人導向分析觀念(三) 、角色描述Jenning(2000)提出以系統(System )出發，代理人導向分析應有的觀念，如圖 3-2。一個代理人在系統的運作過程中可以扮演著不同的角色，好比一個人在社會的情 況一樣。當初步決定應有的使用案例及代理人之後，可以先從代理人在每個使用案例中 扮演的角色著手，找出應有的相關屬性，稱角色網要，從而建構出角色模型( Roles Model )整合同一代理人的多個角色可完成代理人類別的定義，這屬於分析及設計階 段的工作。角