第三章 協力式設計系統模式


協力式設計系統,就是整合知識庫(經驗性知識)及數學運算(程序性程式)的解題方法。在本章將詳述協力式設計系統架構的需求,包括了數學運算與經驗知識的分離、透明的知識表示法、一致的運作方式、平順的資料流向與機會式的推理過程。本研究是以黑板架構作為系統的整合工具,而黑板的基本架構則由推理機制、黑板與知識庫所組成的,其系統是以物件導向的形式來表示,本章亦說明了黑板架構的控制物件、解題物件、行為物件與外部程式物件的知識與使用方式,並在最後舉出分別為以FORTRAN與C語法所寫成的兩個程式實例說明外部程式的運作流程。

3.1 協力式設計架構的要件

  

 3.1.1 數學運算與經驗知識架構的分離

一個典型的結構設計系統內含兩大類的知識:運算性知識與經驗性知識。運算性知識是有關數值計算分析及有限元素法;這是結構工程的一般性專業知識,通常又稱為深層知識(deep knowledge)。另一方面,經驗性知識是指特殊問題領域內以經驗為主體的表層知識(surface knowledge)。而協力式設計模式便是要利用此兩種不同的知識。然而,因為知識分類及系統維護的原因,在程式中完全保持兩者架構的分離是很重要的;而研究的目的不只是以專家系統聯合數種特別的分析程式,而是發展一個能夠整合知識庫系統及程序性程式的一般性設計模式。所以,清楚的分離數學運算與經驗性知識是建築一個一般性結構設計及分析協力式系統的首要考量。

 

 3.1.2 透明的知識表示法

  為了實現彈性化及透明化的知識表示,在結構設計中使用的不同形式知識,應該能夠經由分析、組織的程序以明確的知識表示法形成個別單元。但是組成運算程式的概念及它們彼此之間的相互關係是什麼呢?還有它們如何與符號推理的經驗知識組合在一起?在有關知識表示的文獻中,對此類問題已有所描述。總而言之,明確的宣告性知識表示是解決這些問題的關鍵,而且詳細的表示方式是本論文的重要研究內容。

 

 3.1.3 一致的運作方式

設計的過程由各種不同形式的設計動作組合而成(見1.2節);它應能適當地使用任何該用的知識,但是,各個設計動作在運作及表示上應該是一致的。在系統的控制表層上以一貫的方式處理經驗性與數學運算動作,並保持控制與領域知識的獨立是非常重要的。

 3.1.4 平順的資料流向

因為不同的設計動作也許使用不同的軟體環境,例如設計房屋建築的ETABS及設計預力橋樑的STDS等商用軟體。在一般的設計當中,資料應該是很平順地在整個系統當中流通。每一個設計動作都需要從系統的資料架構中取得資訊,同時本身的設計結果亦需儲存於一特定的資料形式中,以便其他設計動作也能夠使用。因此,一般性資料架構的定義與組織是有其必要的;而且建立資料在不同環境之下的輸出與輸入管道也是必需的。

 3.1.5 機會式的推理過程

在圖1-1中,整個設計流程中的每一個步驟所形成的設計空間,通常大到不適宜作搜尋式的解題。因此,「設計分解」是常用的一種縮減設計空間的方法,也就是可以把原來的問題同時以一組較小的問題來取代。利用此設計分解的過程,在協力式設計系統中,設計可以被分成好幾個次級的副工作,而且從事各別工作的知識被單獨存於系統當中。此系統便利用這樣的方式發展每一個副工作的設計解答。然而,個別副工作的複雜程度及彼此之間的相互影響,仍然使得設計成為一個反覆的過程。以此過程產生的設計必須要符合規範的限制,如有不能滿足限制條件的狀況,則相關的設計必須修改。這樣的過程可能要重覆好幾次,一直到出現了可以接受的設計為止。 經驗性或數值運算性的設計方式適用於不同類別的設計。在每個類別內,設計又能進一步地分解成副工作,每個副工作可適合使用不同的設計方法。協力式設計系統應該能夠在這個階層使用上變換不同的設計方式。在理想上,每個副工作要能夠達到既可使用經驗性法則又可使用數學程序運算。且系統要有彈性,根據目前的設計狀況及所有的最佳知識為每個設計副工作,機動地挑選出一個最適合的設計動作。

3.2 黑板系統架構

在黑板式架構下,解決一個結構設計問題所需的知識被分解、組織成個別的單元,這些知識單元稱之為知識源。相關之知識源又可組成知識模組,代表同類的領域知識或相同目標的解題技巧。整個專家系統即由數個知識模組以分享知識庫的方式所構成。為了去搜尋問題的解答,每一個知識源都只能修改更正一個總體的資料結構(也就是黑板系統中之黑板),同時以最佳之行為來回應黑板上的計劃。 協力式架構系統有兩個主要的知識模組:經驗啟發式與數學運算式(見圖3-1所示)。經驗啟發模式的知識表示方面是有關問題領域及問題解決階段。而數學運算模式是使用程序性程式的設計計算、分析、執行、組織等等。 本研究的結構分析是以FORTRAN及C語言的程序性程式作例題測試。而經驗知識程式編寫部分是以王人牧博士所發展的整合型黑板式專家系統為藍本[21,22],知識語法介面以KEE與Common Lisp符號語言工具所編寫完成。

  

 3.2.1 黑板系統簡介

  本節以比喻的方式來說明黑板式系統解題行為之特性。整個黑板系統架構與本研究有關部分見圖3-2所示。以下就對於黑板系統作詳細的介紹。 黑板系統的架構下,解決運作模式可用下面這個簡單的比喻來加以說明。與建築一間房屋一樣,整個系統可當成是一個房屋建造小組,當要建造時承包商便招集木工、水泥匠、水管工人、電氣工人等各種工人在一起。它的組成有下列幾種[23]: 1. 知識源:就像一群有專業領域知識的人才,如木工、水泥匠、水管工人及電氣工人等。他們彼此並不了解對方的技術及知識,但都是要達到同一個目的,就是把房子完工。 2. 控制器:就像是個承包商,他必須要告訴水管工人要在電氣工人配線之前就要完成安裝管子的工作。 3. 黑板:由建築房屋的藍圖、詳細施工流程及工地所組成,所有的問題及解決的答案都寫在施工流程計劃上。一個解題發展(建屋),有可能要更改工地上的施工流程計劃。舉個例子,水管工人可能發現六吋的水管放不進藍圖所設計的三吋孔內,這時候水管工人便可以依據他們的知識告知建築師修改藍圖。

當水泥匠完成房子的基礎、木工完成房屋的架構,都是完成工作的一個狀態。其他的專家(水管工人、電氣師傅)要隨時注意工地上(黑板)的狀態,當輪到該他們工作的時候,就依情況增加水管或配線的工作。例如水管工人,他們沒有辦法直接與水泥匠、木工或電氣工人交談(因為彼此的專業技術不同);他們必需隨時注意黑板(檢視工地上的狀況,並依施工流程計劃的步驟施工)然後解決他們的問題,完成房子裡屬於他們的部份(安裝水管)。當他們的工作結束後,那麼水管工人便完工而離開了。 也就是說每個工人手中可能有一個或一個以上的建造可能,但在整個建造團體中沒有任何一個工人可單獨完成整個工程,不過每個工人都有建築整個房屋某部份的能力,此外每個工人都很清楚自己可以做什麼工作,當本身可解決的工作出現時便會做事前準備,完成待命的工作。 在同一時間中,可能有好幾個工人同時發現並表示自己可解決目前的工作,此時承包商就依據藍圖上的建造步驟及工地上的狀況,挑選出一個適合目前工作的工人(假如此工人有超過一個以上的建造可能的話,只有一個建造動作將中選,例如油漆粉刷工人可能有粉刷樓板與牆壁兩種動作),而被挑中的工人便在藍圖(黑板)上描述他所能解決的問題,並且執行他的工作。承包商依據目前的建造情況,機動地從不同的工人中選擇一個工人來完成一部份的工作。在整個建造過程中的每個步驟,任何一個工人皆有可能被挑選出來。所以,整個建造房屋小組表現出共同合作與機會式的工作風格。 。

 3.2.2 推理機制

推理機制包括了排程器(scheduler)與監控器(monitor)。房屋建造小組中的承包商就是排程器;而建築師就是黑板的監控器。房屋建造小組中每一個工人被稱為知識源(knowledge source),簡稱為KS;而建造動作則被稱為知識源啟用記錄(knowledge source activation record,KSAR)。每個知識源在黑板系統中都表現一種解決問題的知識,每個知識源(工人)知道自己在什麼時候可工作,同時當它被執行時也知道自己應該採取什麼樣的工作。因此,當有多於一種的建造情況出現時,知識源就可產生多個KSAR,每個KSAR代表同一知識來源下,根據特殊黑板狀況所產生的不同設計選擇。 建屋中的承包商是系統中的排程器,它縱觀整個建造工程,在每一個建造工作中,由所有可行的方案中選擇一個知識源活動記錄來完成這階段的工作,而排程器所做的決定是基於被採用的KSAR是否與現階段的工作策略相符合。在這個系統中,沒有預先設定執行的順序。工作策略是以計畫(plan:如完成房屋建設)和目標(goal:如完成安置水管、裝配電線、水泥基礎、粉刷牆壁等等)來表示,一個目標代表了系統評估KSAR的一個建造考量,而一個計畫則是由一連串表示工作策略的建造目標所構成,計畫中的每一個目標都代表了一個工作目的。黑板上可同時存在數個計畫,代表不同考量下的工作方針。一個整體的評價須由其對黑板上所有計畫的綜合評分來決定,KSAR的評分是以一個數字來表示,其範圍在零到一百之間(零代表了不適合而一百代表完全合適)。在每一個解題循環中,排程器選擇評分最高的來執行(使用者也可以推翻系統的建議,選擇不同的KSAR)。建築師即是系統中的推理監控器,它不斷注意黑板上計畫和目標的狀況,並維護己完成設計事實的一致性。

 3.2.3 黑板

黑板是一個集中的資料結構,它負責儲存在設計過程中所產生的資訊,是黑板系統中各單元間資料交流的媒介。所有的設計資訊都是以黑板系統中的物件來儲存。舉例來說,房屋藍圖、樓間計劃圖、管線配置圖、工址計劃圖等等,都是代表房屋建造的概念。而黑板系統中的黑板結構可分成控制黑板(control blackboard)與設計資訊黑板(design information blackboard)兩種黑板,見圖3-2所示。 § 控制黑板:集合計畫、以及目標這兩種類型的控制物件(control object)所組成。黑板上的控制物件代表了系統的解題策略與設計考量。 § 設計資訊黑板:包含了由各個設計知識源在設計過程中所產生的解題物件(solution object)、行為物件(action object)及外部程式物件(foreign program object)等。

 3.2.4 知識庫

知識庫可分為兩類的知識模組;一類為經驗知識,包括:設計產生器(design generator)、限制檢覆器(constraint checker)、回溯發起器(backtracking provoker)、與重設計修正器(redesign adviser);另一類為數值運算程式介面(外部程式物件),包括:外部程式執行器(foreign program executor)、輸入檔建構器(input file constructor)、輸出檔資料讀取器(output file reader)。數值運算程式介面的知識庫詳述在下個章節;以下為經驗知識方面的知識庫討論。 1. 設計產生器: 設計產生器的功能(function)在於利用設計知識來產生設計值。在此模組的知識源有能力來對相同的設計變數使用不同的領域知識(包括設計分析、設計計算、設計的經驗性法則…等),來產生不同的設計值。 2. 限制檢核器: 限制檢核器知識模組是用來確認限制條件的狀態。當發現限制條件無法滿足時,系統便會在黑板上發出"維修未滿足限制條件"(fix constraint violation)的目標,用來提醒黑板系統去做設計修正。 3. 回溯起發器: 回溯起發器這個知識模組在設計失敗後,開始再設計程序。它控制了黑板系統回溯的階層。某些目前存在黑板上的設計值就會被取消,當黑板中有未滿足(unsatisfied)的限制條件出現時,此知識源便會被誘發。 當此知識源被誘發後,系統便會依循未滿足的限制條件,束制成所有可能影響此限制條件的每個設計值。如此,使用者在重新設計時,便可選擇特定設計物件中特定的值,以用來控制回溯的階層。當此回溯起發器被執行時會浮現一個表格,讓使用者在表格中選擇一個與目前未滿足限制有關的的設計值。如此一來,KEE中的維正系統便會因這個設計值是未設計完全的(此時設計值已被移走之故)而回溯重新設計此設計值,以維持設計相互關係的正確性。此時黑板系統中的維正系統(truth maintenance system,簡稱TMS)就會重新設定黑板的狀況,而且所有的知識源都會根據新的黑板狀況再一次競爭以解決問題。 4. 重設計修正器: 重設計修正器這個知識模組的功能,主要是用在重新設計時,建議新的設計值,它有別於回溯起發器,前者是用來建議什麼設計值需要修改,後者則是建議如何修改設計值。重設計修正器是在回溯起發器將設計值從解答黑板中移走時才被誘發,並做出一些修正設計的動作。 在另一方面,外部程式介面的知識模式是執行並存取外部程序性程式的資料及轉換設計(或分析)的結果到目前的設計工作。其黑板的知識庫由外部程式執行器(foreign program executor)、輸入檔建構器(input file constructor)、輸出檔資料讀取器(output file reader)三種組成數值運算程式介面。如圖3-3所示

1. 輸入檔建構器(input.file.constructor):

輸入檔建構器主要用在為外部程式的輸入檔作準備。在黑板上的設計結果與在知識庫裡面的事實都有可能要包含在這個資料檔內。輸入檔建構器根據外部程式的需要,取得黑板上之設計值,以程式要求的格式建立資料輸入檔案。目前一般的程序性程式都有其一定的輸入檔格式,而輸入檔建構器便是由儲存在外部程式物件中的資訊,依一般化的形式來建構輸入檔。

2. 外部程式執行器(foreign.program.executor):

有了外部程式的輸入檔之後,其KS便能在黑板上出現(表示其可工作),外部程式執行器就根據在知識庫中儲存的外部程式物件而去執行外部程式。而執行的結果便存放在各別的輸出檔當中。如圖3-3所示的execute.one.program實例便可以執行可工作的外部程式。

3. 輸出檔資料讀取器(output.file.reader):

  為了與其他知識模組共同分享執行外部程式後所得的結果,就需要把資料放在黑板上,且要對應到設計物件的屬性當中。輸出檔資料讀取器從執行外部程式所產生的資料檔中取出有用的資訊,並變更設計黑板上之設計值。如圖3-3所示的read.output.file.data實例便是讀取外部程式所計算出來的值。

3.3 系統知識的表示方式

協力式設計系統是以物件導向(或框架式)的方法進行。不同領域的知識建立在不同的知識庫中,並且其特性可以在彼此之間共用。例如一般皆可使用到的資料建立在「ddis-concept」知識庫中,其他的知識庫皆可繼承其特性;而有關懸臂橋知識的部份則放在「c-bridge」知識庫中。資料類別的形式與實例的繼承是依據存放在不同階層的知識庫中以物件導向取得。此表示法會把具有相同特性的物件歸成一類別,彼此間藉由繼承的特性而擁有共同的資料結構與方法,最後就是由這些類別組成整個系統,將專家知識完整地表達出來。 在系統中幾乎所有的知識都存放在最低階層的物件裡(例如物質物件、設計動作、計劃、目標、限制及外部程式物件等)。圖3-4說明了協力式設計動作物件包含了各別基本的知識,每一個物件的形式對於設計物件的類別或知識,定義特別的值及程序。所以知識庫是由事先定義的物件形式(如設計物件、變數、限制、方法、計劃、經驗及數值運算程式)所組成的。 在本論文,知識庫設計系統的數種工作提供知識表示的基本方案。系統中,有一個明確的表示法既包含了經驗與數值運算知識,此節詳細地描述了有關數值運算程式在合作設計的資訊。 其中,知識的表示方法包含了有控制物件、解題物件、行為物件與外部程式物件,如圖3-2所示,以下便詳細地介紹各物件的性質。

 3.3.1 控制物件(Control Objects)

  黑板中的控制物件是用來定義黑板系統中控制解題策略與方法的知識。當某一個控制物件被控制黑板所採用時,黑板系統就用包含在此控制物件的資訊來對KSAR進行評估與排序。它把特別領域的知識源分別出來,由黑板的知識庫以機會式的方式表現出解題的狀況。由建築房屋的例子為:承包商要由所需的狀態選擇一個工作,就像在同一個房間內不能同時裝配電線,安置水管與鋪設石膏板。控制的人就要告訴水管工人要在配電線之前完成。而此物件就是以計劃及目標來控制黑板解題形式;以下是就目標與計畫兩種控制物件作簡述: 1. 目標(Goals): 是用來評估KSAR優先次序的最基本物件。它可以是一個計畫中的一部分或是一個獨立的目標;如完成安置水管、裝配電線、水泥基礎、粉刷牆壁等等,每一個都是一個目標。 2. 計劃(plans): 代表黑板系統的解題策略。計畫中詳細陳述有哪些需要完成的目標,這個設計計畫中每個目標的設計值皆能滿足所有的限制條件,此計劃便完成,並結束工作。例如油漆粉刷的計劃就包含了粉刷牆壁、樓板及屋頂等目標。

 

 3.3.2 解題物件(Solution Objects)

  解題物件是用來掌控在設計過程中所產生的設計資料,它們包含了以下幾種類型: 1. 實際物件(physical object): 用來表示實際設計問題中的物件,在知識庫中設計物件(design object)這個類別(class)的實例(instance),便表示系統所需設計的實際物件。 2. 變數物件(variable object): 用來代表設計過程中一些設計計算或檢覈限制條件所需的變數。除了在設計物件與知識上使用一般的物件導向模式外,黑板系統更使用了物件導向設計規範模式[24]。所有的邏輯敘述與變數在設計標準下都被表示成物件(object),而這些物件稱為資料項(data item)。每一個內含的資料項都有自己的值、資料型式、以及用來決定本身值的方法(method)。 3. 限制物件(constraint object): 包括了強度限制條件(strength constraint),幾何限制條件(geometric constraint)與使用者自選限制條件(user specified constraint),此三者代表不同類別的設計要求。強度限制條件代表了結構設計中,設計強度方面的限制條件;幾何限制條件則代表了設計時,幾何形狀方面的限制條件;而使用者自選限制條件為使用者附加的限制條件。

 3.3.3 行為物件(Action Objects)

在黑板系統中,設計知識是以知識源物件儲存於知識庫中。而實際在設計資料黑板中所執行的物件,則是為那些被誘發的知識源所產生的知識源啟用記錄,如圖3-2所示。以下為知識源(KS)與知識源啟用記錄(KSAR)之簡述。 1. 知識源(KS): 在每個知識源中都詳述了設計行動的使用時機、它的背景變數如何確認、與它應採取什麼行動‥‥等資料。每一個知識源在黑板系統中都視為具有相同機會的競爭者,在每一次的設計週期中,這幾類的知識源都會彼此競爭,而同一類別中的知識源也會視本身是否能解決目前黑板上所告示的問題來彼此競爭,這也就是黑板式系統機會式推理的由來。就像建造房子目前需要灌製基礎,此時就應該由水泥工人出來建造;但他只是未建造作準備而已,並未真正建造。所以知識源並不是解決問題的動作,而是能夠解決問題的狀態。 2. 知識源啟用記錄(KSAR): KSAR是由被誘發的知識源所產生的。KSAR才是真正改變黑板問題狀態的行為物件。黑板系統允許一個被誘發的知識源可以依本身背景變數的組數來產生相同組數的KSAR,這樣簡化了知識源的敘述式並可在同一個知識源中描述許多不同的設計選擇。KSAR是由誘發的知識源與確認後的背景變數組合而成的。由相同知識源所產生的數個KSAR可以因變數確認的不同而有不同的名稱。KSAR的屬性大部份都由其來源知識源中繼承而來。

 3.3.4 外部程式物件(Foreign Program Objects)

外部程式物件是用來掌控執行外部程式所需要的資料,包括測試所需的輸入檔資料是否存在,然後執行,產生輸出檔後再將所需的解答取回。與數值運算程式有關的知識存在於知識庫的外部程式物件中。系統中預先定義的物件與它們的階層關係如圖3-5所示。在合作設計系統中,實例由階層知識樹的末端產生,它們是數值運算相關資訊表示的基礎。底下就是這些物件類別的詳細描述: § 外部程式物件(foreign.program.object):是最上層的根類別。其有一個屬性path會被下層的子類別使用,以字串儲存檔案或程式的路徑。也有方法(method)可被子類別的物件所使用。在這個物件中也設定了一個可以判斷path所給的檔案在UNIX環境中是否存在的方法,就是probe-file。 § 檔案(file):是系統中儲存檔案輸入/輸出相關知識之封裝性物件的上部類別。positions是所有檔案物件用來儲存檔案中需要處理資料所在行與列位置的屬性。在這個物件中也設定了一個拷貝檔案的方法,提供所有檔案實例物件使用,就是copy-file。 § 輸入檔(input.file):是file的一個子類別。input.file的一個實例代表一個對應的外部程式的輸入資料檔案,而且其包含了如何組成此檔案的相關資訊。input.file有個屬性叫做values-required,它儲存的是一對對的物件屬性串列。串列中每一個物件屬性值都將經由運算程式介面知識模組中的「輸入檔建構器」寫入檔案裡面。而檔案內屬性值的位置是依positions這個繼承的屬性以成對之行與列位置的串列來表示。而positions及values-required這兩個串列的長度要相同,因為他們的元素是一對一的關係(values-required的值要存入positions所指的這個位置)。 § 輸出檔(output.file):是file的一個子類別。output.file的一個實例代表一個外部程式執行後的輸出檔案,且其包含了如何從此檔案取得相關資訊的知識。output.file有個從file繼承的屬性叫做positions,在這屬性內儲存了一對對行與列座標的串列。每一對行與列位置都代表了運算程式介面知識模組中的「輸出檔資料讀取器」,所需讀取的設計值在檔案中的行與列座標位置。指定取回的值存放於output.file的value-designations屬性中以一對對的物件屬性串列來表示。也就是設計值由檔案中取回,存在黑板上之設計物件的屬性內;與input.file相似,positions及values-designations這兩個串列的長度要相同,因為他們的元素是一對一的關係(value-designations的值要從positions所指的這個位置取得)。 § 參數(parameter):是一個物件類別,儲存要執行外部程式所需要的參數資料。parameter有個屬性叫做value-form,描述了所需參數的來源。value-form可以為系統中任何資料項(data item)所定義的物件,可以是一個檔案物件、一個函數運算式或是一個特定的值(例如一個明確的數值,文字字串等等)。當需要參數的值時,預先定義的方法便會評估value-form以得到此值。在這個物件中也設定了一個測試value-form內所填的參數是否存在的方法,提供給所有實例物件使用,就是value?。 § 程式(program):是所有外部程式物件的原型。當本身子類別的實例在知識庫中被表示出來時,協力式系統便認為它們是能夠以數值運算程式介面來做運算的設計程式。path這個繼承屬性指出外部程式檔案的路徑名稱。program的input-files屬性儲存一個(或多個)input.file的物件,可以聯結到程式的輸入檔資料指定的路徑。同理,寫在output-files屬性的output.file物件名稱是用來指定程式執行後輸出檔的路徑名稱與如何處理程式輸出值的相關資訊。known-design-values及unknown-design-values這兩個屬性是宣告什麼值應該在黑板上,而且什麼值在執行程式之前不應在黑板上。這兩個屬性的值是以一對對物件屬性所形成的串列組成。通常,known-design-values的值是準備輸入檔所需的設計值,而unknown-design-values的值是外部程式所能計算的設計值。外部程式執行器知識模組就是使用這兩個屬性值去組成設計動作的先決條件。 § 編譯程式(compiled.program):是program的一個子類別。它從program繼承所有的屬性與方法。本物件有一附屬之方法(method)實際在UNIX環境下送出執行外部程式的指令提供給所有程式實例物件使用,就是execute-program。 § 原始程式(source.program):是program的一個子類別。它與其他類別程式的區分在於本身有處理程式編譯的資訊與方法。 § 無參數的程式(program.without.parameter):是program的一個子類別。它代表一個不需給予任何參數而能夠執行的外部程式,注意,本系統支援多重繼承,一個程式物件的實例通常屬於兩個程式的類別(例如一個程式可同時屬於compiled.program與program.without.parameter兩個類別)。 § 參數性程式(program.with.parameter):是program的一個子類別。它代表一個外部程式需要在指令後直接接有參數才能執行。本物件有一個arguments的屬性,以parameter物件形式儲存外部程式的參數。它有一個方法(method)能對arguments中的每一個parameter物件傳送訊息以決定所有的參數是否存在及能否計算其值。

3.4 系統KSAR評估

利用目前在控制黑板上的計畫與目標物件中的控制知識來評估KSAR,控制知識存於目標中的評估函數(FUNCTION)。所以每個在執行議程上的KSAR都會依現階段目標中評估函數這個屬性值,個別評估其相對評分。評分公式如下: 第五章圖5-4中,RUN.SECTION.TYPE.C.PROGRAM的評分為36.24,其計算過程如下: 目前控制黑板上的啟用目標(active goal)有下列五個: (1) CANTILEVER.BRIDGE.DESIGN.PLAN(權重weight=5)的設計目標CANTILEVER.BRIDGE.DESIGN(權重=5)。 (2) CANTILEVER.BRIDGE.DESIGN.SUBPLAN.1(權重=5)的設計目標DESIGN.SEGMENTS(權重=5)。 (3) FOREIGN.PROGRAM.PLAN(權重=10)的設計目標CALCULATE.SEGMENT.SECTION(權重=10)。 (4) 系統內建目標FAVOR.CONTROL.ACTIONS(權重=8) 每個目標對run.section.type.c.program個別的評分為: (1) CANTILEVER.BRIDGE.DESIGN的評分為45。 (2) DESIGN.SEGMENTS的評分為45。 (3) CALCULATE.SEGMENT.SECTION的評分為45。 故系統對run.section.type.c.program的總評分為:

3.5 外部程式運作流程

 3.5.1 外部程式介面的表示

系統中執行設計動作的知識存放在知識庫裡的知識源物件當中。在設計資訊黑板上的設計動作物件是啟動知識源而產生的KSAR(知識源啟發記錄)。 在外部程式介面知識模組內的設計動作都是標準的行為物件。每一個物件都包含了有關本身設計行為的資訊,例如:設計時機、變數束制、設計進行以及設計重要性等。觸發及執行數值運算程式的資訊可以在以宣告性方式儲存於知識庫中的外部程式物件內找到。外部程式介面包含了能夠依這些外部程式物件而調整其設計行為的一般性知識源。

 3.5.2 外部程式運作知識源簡介

  協力式設計系統中的每個知識源皆代表了與外部程式交流的特別知識。因此,本研究之外部程式介面知識模組乃是將外部程式相關的知識,利用系統的知識表示法加以撰寫成知識源。以下就簡述「外部程式介面」foreign.program.interface所包含的領域知識源。 外部程式介面: 包括有三個子類別(見圖3-3),分別為foreign.program.executor、input.file.constructor及output.file.reader。其中execute.one.program是屬於foreign.program.executor這個類別下知識源;而read.output.file.data是屬於output.file.reader這個類別下知識源。其主要的功能分別為執行、輸入及讀取外部程式,以下就列兩個知識源的內容來介紹不同知識源的用法。 (a) execute.one.program:本知識源是屬於foreign.program.executor的實例,代表了是否能夠執行外部程式相關的條件及知識。 1 誘發條件(trigger﹒conditions):是一連串由LISP語言編寫的條件式,其功能是用來判別知識源的適用性。當誘發條件的值為真(true)時,這個知識源就會被誘發並進行例証的動作,注意在誘發條件中不得使用背景變數。本知識源中,敘述了當program有實例(instance,執行檔案)時,便能誘發execute.one.program這個知識源。 2 背景變數(context﹒variable):用來從知識源產生KSAR的單一變數或多組的變數對。這些變數在知源誘發後便被指定成特定的值,在本身知識源中的KSAR都被替換成此背景變數。這些變數通常被定義成附有"$"符號的名稱。在每個知識源中除了誘發條件以外的屬性都可以使用背景變數。如本知識源中的敘述為:"在program類別中的實例(instance,執行檔案)都被指定為背景變數,例如本例有section.type.c.program、constant.d.seg.property. program、longitudinal.profile.program、section. type.fortran.program、segment.number.length. program及variable.d.seg.property.program等(詳見圖3-6所示)。 3 名稱產生器(name﹒generator):用來轉譯由知識源所產生的KSAR的名稱。當知識源可產生超過一個以上的KSAR時,此屬性就變得相當重要。因為系統在名稱產生器沒有值時會以知識源的名稱來代替,而多組相同名稱的KSAR會在黑板中造成混淆,以致造成系統錯誤。例如本知識源的名稱產生器為(run $program),當背景變數被指定為section.type.c.program後,這個KSAR的名稱就會變成為:run.section.type.c.program。 4 先決條件(precondition):當KSAR由知識源產生後,知識源中的此項屬性就會變成這些KSAR的先決條件,即確認先決條件被滿足的KSAR才有被執行的可能。如本知識源中,當每個外部執行物件的can-be-executed-p屬性回應true時,先決條件才會滿足,所以只要是每個KSAR的can-be-executed-p屬性回應true時,KSAR便會出現在黑板的知識庫上 5 執行動作(action﹒code):是一個LISP語法的敘述,代表KSAR執行解決黑板問題的動作,此動作是在KSAR被確定執行後,才會發生作用。本知識源中,會準備背景變數所指定程式的輸入檔,並且執行依本身實例中path屬性所填寫的外部程式名稱。 6 優先權(priority):代表知識源的優先權大小。此屬性的值可為常數或由LISP語言所寫的程式(注意:程式所傳回的值必須是一個數字)。優先權的大小代表了知識源在不同狀況下的重要性,同時也是黑板系統用來評估評分的要素之一。優先權的值域範圍為從0到100,數值愈高代表重要性愈大。本例中,優先權為常數90。 7 狀態(status):此屬性的值不是為"可動作的"(operative)就是為"不可動作的"(inoperative)。如果知識源的狀態是不可動作的,那麼在解題過程中,系統便不會考慮使用此知識源。 以下介紹output.file.reader的知識源:read.output.file.data,著重於重要屬性誘發條件、先決條件、背景變數、名稱產生器與執行動作。 (b) read.output.file.data:本知識源是屬於output.file.reader的實例,代表了當執行過外部程式後要取回輸出檔計算值的條件及知識。 1 誘發條件(trigger﹒conditions):本知識源的誘發條件為,當output﹒file這個類別中有任何一個實例(instance,輸出的檔案)存在時,read.output.file.data知識源便被誘發。 2 背景變數(context﹒variable):這個知識源的背景變數($property)敘述為:"把output.file物件下的每一個實例(instance,輸出的檔案)指定為背景變數"。 3 先決條件(precondition):本知識源中,會測試依背景變數$property所指定的值(輸出檔)是否已存在,如果此時找到此輸出檔,這個KSAR的先決條件才會滿足,也才有被執行之可能。 4 名稱產生器(name﹒generator):黑板系統根據背景變數之名稱以及名稱產生器中之敘述將產生read $property data的這個KSAR在黑板的知識庫上。 5 執行動作(action﹒code):一個LISP語法的敘述,代表KSAR執行解決黑板問題的動作,此動作是在KSAR被確定執行後,才會發生作用。本知識源中,會從背景變數所指定的輸出檔中依本身知識源所定義的put-value-&-values-designations這個方法取值,並放入特定的屬性內。 6 優先權(priority):代表知識源的優先權大小。此屬性的值可為常數或由LISP語言所寫的程式(注意:程式所傳回的值必須是一個數字)。優先權的大小代表了知識源在不同狀況下的重要性,同時也是黑板系統用來評估評分的要素之一。優先權的值域範圍為從0到100,數值愈高代表重要性愈大。本例中,優先權為常數90。 7 狀態(status):此屬性的值不是為"可動作的"(operative)就是為"不可動作的"(inoperative)。如果知識源的狀態是不可動作的,那麼在解題過程中,系統便不會考慮使用此知識源。

 3.5.3 外部程式物件實例

在此舉出兩個外部程式物件實例,其中一例為執行時程式不需要參數:segment.number.length.program(也就是直接由程式呼叫輸入檔);另一例為執行時直接給予程式所需之值,而不呼叫輸入檔:section.type.c.program,詳見圖3-6所示。其中第一個例子是以FORTRAN語言寫成的;而第二個例子是以C語言所寫成的。 舉例一 § segment.number.length.program(節塊數目及長度的外部程式物件):此物件包括下列的屬性 (1) PATH (path and name) Values: "~/fortran/seg-profile.exe" (2) INPUT-FILES(input file slot name) Values: segment.number.length.in (3) OUTPUT-FILES(output file slot name) Values: segment.number.length.out (4) KNOWN-DESIGN-VALUES(values we have known) Values: (CANTILEVER.BRIDGE top-slab-thickness) (5) UNKNOWN-DESIGN-VALUES(values we required) Values: (CANTILEVER.BRIDGE segment-number) (6) VALUE-EXIST-P(test the value exist or not) ValueClass: method Value: 當known-design-values的值(頂板厚)存在,而unknown-design-values的值(節塊數目)不存在時,此方法便回應true;否則則回應nil。此屬性提供了知識源execute.one.program的先決條件(precondition)判斷是否誘發KSAR。 (7) PREPARE-INPUT(write values to input files) ValueClass: method Values: 當value-exist-p回應true時,此方法便將程式所須的輸入檔依物件本身已定義的values-required屬性之值存入positions所指的位置上。 而此程式物件又需聯結到檔案物件(FILE object),其中包括了輸入檔物件(segment.number.length.in)及輸出檔物件(segment.number.length.out)兩個物件,如圖3-6所示: § segment.number.length.in(節塊數目及長度的輸入檔物件): (1) PATH(path and name) Values: "~/fortran/seg-profile.in" (2) POSITIONS(value's position in input file) Values: (1 1) (3) values-required(the require value of input file) Values: (CANTILEVER.BRIDGE span-length) (4) WRITE-INPUT-OUT(write values to input files) ValueClass: method Values: 取出values-required所指定的值填入positions所指定的位置。 § segment.number.length.out(節塊數目及長度的輸出檔物件): (1) PATH(path and name) Values: "~/fortran/seg-profile.out" (2) POSITIONS(value's position in output file) Values: (1 1) (1 5) (3) VALUES-DESIGNATIONS(the designation slot values write to) Values: (CANTILEVER.BRIDGE segment-number)、(CANTILEVER.BRIDGE segment-length)。 (4) PUT-TO-POSITION-&-VALUE-DESIGNATION(get the output file values and assert to designation slot) ValueClass: method Values: 自外部輸出檔取出positions所指定位置之值,並填入values-required所對應屬性的槽(slot)中。 舉例二 § section.type.c.program:(橫斷面性質的外部程式物件):此物件包括下列的槽(slots): (1) PATH Values: "~/c/sectionc.exe" (2) ARGUMENTS(require arguments for program) Values: values (3) CAN-BE-EXECUTED-P(test KSAR can be executed) Values: 此例當value-exist-p回應true,而且外部程式的輸出檔不存在,並且value?回應true三個條件皆滿足後,便回應true,所以知識源execute.one.program便誘發此KSAR,並出現在黑板上。 (4) INPUT-FILES Values: nil (5) OUTPUT-FILES Values:section.type.c.out (6) KNOWN-DESIGN-VALUES Values: (CANTILEVER.BRIDGE bridge-width)、(CANTILEVER.BRIDGE construction-method)、(CANTILEVER.BRIDGE longitudinal-profile) (7) UNKNOWN-DESIGN-VALUES Values: (CANTILEVER.BRIDGE bridge-section) 因為此程式物件之資料直接由參數提供,所以沒有輸入檔物件,而只有參數物件(parameters)與輸出檔物件(section.type.c.out)。見圖3-6所示: § values(橋樑寬物件): (1) VALUE-FORM Values: bw(橋寬,系統定義的映射資料項) (2) VALUE? (test the value-form slot has values) ValueClass: method Values: 是一個計算參數值的方法(method),當前一點value-form的值bw計算出有值時,此方法便回應(true),否則便回應(nil)。 § section.type.c.out(橫斷面性質的輸出檔物件): (1) PATH Values:"~/c/section.out" (2) POSITIONS Values: (1 1) (2 1) (5 1) (7 1) (9 1) (11 1) (3) VALUES-REQUIRED Values: (CANTILEVER.BRIDGE bridge-section)、(CANTILEVER.BRDIGE section-width)、(CANTILEVER.BRDIGE bottom-slab-width)、(CANTILEVER.BRDIGE web-thickness)、(CANTILEVER.BRDIGE web-spacing) (4) PUT-TO-POSITION-&-VALUES-DESIGNATION Values: 此方法將values-designation的值從外部程式的輸出檔以positions這個屬性所指的位置取回。

 3.5.4 設計動作(KSAR)運作實例

  在此舉出前述的section.type.c.program這個計算橫斷面性質程式的KSAR作介紹,敘述此KSAR是如何運作: 1. 當橋樑寬度、橋樑建構方法、縱斷面形式(known-design-values這個屬性所填的值)為已知,而橋樑橫斷面性質(unknown-design-values所填的值)為未知時,則此section.type.c.program內的方法(method):can-be-executed-p則回應true,否則回應nil。 2. 當section.type.c.program內的方法(can-be-executed-p)回應true時,則execute.one.program這個知識源(見圖3-3所示)將被啟動,在program下所有物件凡是符合先決條件(precondition),都會被誘發成為KSAR,並將出現在黑板上,即為run.section.type.c.program。則此時execute.one.program所定義的execute-parameter-program方法將會被觸動。因此例不須輸入檔,故write-input-file-out這個方法並不被觸動。並執行path屬性內所指定的路徑中的檔案:"~/c/sectionc"。 3. 而當外部程式的輸出檔產生後(橋樑寬度、節塊寬度、底板寬度、腹板寬度及腹板間距已知,但未讀入知識庫物件的屬性�堙^,則run.section.type.c.program物件便從黑板上去除;此時create.segment.output.file.obj物件便在output.files的子類別egment.property.out物件下依所得的節塊數建出15組節塊性質的實例,此時便是誘發了15組的KSAR。每個KSAR被選擇執行時則其put-to-position-&-value-designation.designations這個方法都被執行,並將輸出檔的值取回依每個KSAR的屬性的positions所指定的位置存放至各別values-designations所指定的槽(slot)內。 4. 當section.type.c.program內的value-designations(slot)所指定的值皆填入後,read.output.file.data內的先決條件便不滿足,所以read.section.type.c.out.data便從黑板上跳走,進而執行下一個設計動作。

 
摘要 目錄 第一章 第二章 第四章 第五章 第六章 參考文獻

回我的論文