專家系統(tǒng)設(shè)計流程課件

Chapter9.

TheDesignofExpertSystems

專家系統(tǒng)設(shè)計流程1課件Chapter9.

TheDesignofExpe本章節(jié)提出一整體建立實際專家系統(tǒng)的指引，而不是研究用的雛型系統(tǒng)為了建立一符合成本效益和有效率的專家系統(tǒng)，我們將討論一些軟體工程的方法論2課件本章節(jié)提出一整體建立實際專家系統(tǒng)的指引，而不是研究用的雛型系影響專家系統(tǒng)專案的因素組織內(nèi)部的影響管理單位決策者使用單位教育人事單位軟體開發(fā)部門組織外部的影響：

客戶供應(yīng)商協(xié)力廠商政府主管機關(guān)3課件影響專家系統(tǒng)專案的因素組織內(nèi)部的影響3課件4課件4課件建置專家系統(tǒng)專案選擇適當?shù)墓牨荆簽槭颤N我們要建立專家系統(tǒng)?收益：收益是什麼?(資金,效率,…)工具：有哪些適合的工具可用來建立此系統(tǒng)?(LISP,CLIPS,KEE,PCPLUS,…)花費：這系統(tǒng)的建製將花費多少?如果沒有人使用，這系統(tǒng)將是無用的5課件建置專家系統(tǒng)專案選擇適當?shù)墓牨荆菏找妫汗ぞ撸夯ㄙM：如果沒有人專案管理（PROJECTMANAGEMENT）工作項目管理ActivityManagement產(chǎn)品設(shè)定管理ProductConfigurationManagement資源管理ResourceManagement規(guī)劃排程紀錄分析產(chǎn)品管理變異管理擷取資源最小化資源瓶頸分派需要的資源預(yù)測資源需求專案管理工作項目6課件專案管理（PROJECTMANAGEMENT）工作項目管(1)工作項目管理(ActivityManagement)規(guī)劃(Planning)定義工作項目、優(yōu)先順序列出資源需求、訂定里程碑執(zhí)行過程責任排程(Scheduling)指定開始及結(jié)束時間解決同樣優(yōu)先權(quán)之工作排程衝突紀錄(Chronicling)監(jiān)視專案效率分析(Analysis)分析以上相關(guān)的工作項目7課件(1)工作項目管理(ActivityManagement(2)產(chǎn)品設(shè)定管理(Productconfigurationmanagement)產(chǎn)品管理(Productmanagement)管理產(chǎn)品之不同版本

變異管理(Changemanagement)管理變異規(guī)劃及評估影響大小指定適當人員引發(fā)變異安裝新的產(chǎn)品版本8課件(2)產(chǎn)品設(shè)定管理(Productconfigurati(3)資源管理(Resourcemanagement)預(yù)測資源需求擷取需求指定最佳資源使用效率的回應(yīng)提供適當且必要的資源以縮小專案瓶頸

9課件(3)資源管理(Resourcemanagement)預(yù)FeasibilityStudy(可行性研究)RapidPrototype(快速雛形設(shè)計)RefinedSystem(-test)(調(diào)整修正系統(tǒng))FieldTestable(-test)(導(dǎo)入領(lǐng)域測試)CommercialQualitySystem(商用系統(tǒng)品質(zhì)設(shè)定)MaintenanceandEvolution(系統(tǒng)維護與演進)文件研究比較來顯示此專案是可行的快速地將想法、激起的熱忱和影響較高層的管理融合在一起知識工程師和專家根據(jù)真實問題做專家系統(tǒng)的內(nèi)部測試由選定的使用者測試系統(tǒng)–而不是知識工程師或是專家驗證和測試

使用者文件

訓練透過電話或是電子郵件快速的做使用者支援修正臭蟲增進系統(tǒng)能力專家系統(tǒng)發(fā)展階段10課件FeasibilityStudyRapidPrototy可行性研究11課件可行性研究11課件快速雛形設(shè)計12課件快速雛形設(shè)計12課件商用品質(zhì)設(shè)定—壓力測試類別

方法說明及範例

效果

大量運算

重複執(zhí)行某項功能數(shù)萬次

驗證某些功能不會殘留一些額外的資訊於記憶體或硬碟暫存檔案之中，在數(shù)次執(zhí)行後可能因為記憶體空間不足或是其他因素造成副作用。大量運算

連續(xù)規(guī)則推論72小時

驗證某些功能不會殘留一些額外的資訊於記憶體或硬碟暫存檔案之中，在數(shù)次執(zhí)行後可能因為記憶體空間不足或是其他因素造成副作用。

惡劣環(huán)境

將軟硬體系統(tǒng)置於高溫環(huán)境中在長時間運作的系統(tǒng)中，高溫工作的情況偶爾會發(fā)生，可以測試在此環(huán)境中系統(tǒng)的表現(xiàn)。惡劣環(huán)境

將軟硬體系統(tǒng)置於低溫環(huán)境中

檢查硬體系統(tǒng)是否有訊號不正常之情況發(fā)生。

不正常操作

在操作過程中突然關(guān)閉系統(tǒng)檢查記憶體回復(fù)之情況是否如預(yù)期。

規(guī)則迴圈

(例如：A->B,B->C,C->A），造成規(guī)則迴圈的特殊錯誤。

檢驗系統(tǒng)是否針對此類邏輯錯誤具判斷能力。13課件商用品質(zhì)設(shè)定—壓力測試類別方法說明及範例效果大量運算遞送問題(TheDeliveryProblem)應(yīng)該在早期開發(fā)過程中考慮在標準硬體上執(zhí)行最好要考慮花費考慮與其他程式的通訊和協(xié)調(diào)14課件遞送問題(TheDeliveryProblem)應(yīng)該在維護與演進(MaintenanceandEvolution)比傳統(tǒng)程式更複雜必須要有系統(tǒng)化和有效率的方法從使用者收集問題回報維護工作:系統(tǒng)程式碼維護系統(tǒng)功能維護資料庫維護15課件維護與演進(MaintenanceandEvoluti發(fā)展階段的錯誤(ErrorsinDevelopmentStages)專家的知識錯誤語意錯誤語法錯誤推論引擎錯誤推論鏈錯誤忽略的限制錯誤–人類專家了解系統(tǒng)的知識範圍和效能優(yōu)雅地忽略的邊降低.16課件發(fā)展階段的錯誤(ErrorsinDevelopmentExpert專家KnowledgeEngineer知識工程師KnowledgeBase知識庫InferenceEngine推論引擎InferenceChain推論鏈

專家的知識錯誤，例如不正確和不完整的知識

知識工程師和專家之間的語意錯誤

由專家那擷取出的知識不完整表格語法錯誤由於不正確、不完整的知識，和不確定性的規(guī)則和事實所導(dǎo)致的內(nèi)容錯誤

錯誤發(fā)生在推論引擎，和其他的專家系統(tǒng)工具軟體

由於不正確的規(guī)則優(yōu)先權(quán)、規(guī)則的交互作用、和知識庫錯誤而導(dǎo)致的推論錯誤

由於不單調(diào)的推論而導(dǎo)致錯誤圖6-3專家系統(tǒng)主要的錯誤和起因17課件ExpertKnowledgeEngineerKnowle□軟體工程和專家系統(tǒng)軟體工程產(chǎn)品問題

高花費的發(fā)展過程多樣性的發(fā)展過程程式設(shè)計師缺乏生產(chǎn)力文件計畫、需求、和設(shè)計軟體生命週期高花費的發(fā)展過程容易維護和可精進的良好的文件排程報告準時有成本效益的目標圖6-4軟體工程的方法論18課件□軟體工程和專家系統(tǒng)軟體工程產(chǎn)品問題高花費的發(fā)展過程多樣資料庫系統(tǒng)與專家系統(tǒng)的關(guān)係19課件資料庫系統(tǒng)與專家系統(tǒng)的關(guān)係19課件傳統(tǒng)軟體專案概念20課件傳統(tǒng)軟體專案概念20課件知識工程概念問題(problem)=資料(data)+未知資訊(unknowninformation)21課件知識工程概念問題(problem)=資料(data)+專家系統(tǒng)專案與知識工程之間關(guān)係概念22課件專家系統(tǒng)專案與知識工程之間關(guān)係概念22課件部分專家系統(tǒng)軟體品質(zhì)的評量給定正確輸入而有正確輸出給定正確輸入而有完整的輸出給定相同的輸入而有一致的輸出穩(wěn)定，且不會常因為臭蟲而當機對使用者是合用的且最好是容易使用地可維護的可增進的經(jīng)過驗證去證明系統(tǒng)滿足使用者的需求經(jīng)過測試後證明正確性和完整性有效率的23課件部分專家系統(tǒng)軟體品質(zhì)的評量給定正確輸入而有正確輸出23課件可重複使用的程式碼用在其他的應(yīng)用程式容易移轉(zhuǎn)到其他的硬體/軟體環(huán)境容易與其他軟體連接容易理解的程式碼精確的優(yōu)雅的在知識的邊緣降低可以嵌入其他語言的能力驗證知識庫解釋機制24課件可重複使用的程式碼用在其他的應(yīng)用程式24課件1.維護成本(MaintenanceCosts)一般軟體(Conventionalsoftware)-60~80%的軟體花費-二到四倍原本的開發(fā)花費專家系統(tǒng)(Expertsystems)-可能更糟2.瀑布模型(WaterfallModel)一個傳統(tǒng)軟體開發(fā)的生命週期模型圖6-5下一歩要完成什麼?下一階段要花多少時間完成?專家系統(tǒng)的生命週期25課件1.維護成本(MaintenanceCosts)專家系統(tǒng)圖6-5軟體生命週期的瀑布模型系統(tǒng)可行性確認軟體規(guī)劃及需求確認確認確認單元測試產(chǎn)品驗證系統(tǒng)測試重新確認使用及維護實施整合發(fā)展產(chǎn)品設(shè)計細部設(shè)計生命週期--瀑布概念26課件圖6-5系統(tǒng)可行性確認軟體規(guī)劃及需求確認確認確認單元測試3.Code-and-Fix模型比瀑布模型更實際不需要事先知道所有的資訊4.Incremental模型瀑布模型的改良Top-down方法容易測試、證實和驗證一個延伸整個開發(fā)過程的連續(xù)性快速雛型方法建立雛型系統(tǒng)

決定需求完成系統(tǒng)建制27課件3.Code-and-Fix模型建立雛型系統(tǒng) 決定需求完成助手等級同事等級專家等級規(guī)則規(guī)則規(guī)則主要的增加單一規(guī)則:大量的增加最初的雛型次要的增加次要的增加次要的增加28課件助手等級同事等級專家等級規(guī)則規(guī)則規(guī)則主要的增加單一規(guī)則:大5.螺旋模型(SpiralModel)規(guī)劃需求設(shè)計證實評價專家系統(tǒng)測試驗證整合知識擷取驗證程式撰寫驗證測試圖6-6一個專家系統(tǒng)開發(fā)過程的螺旋模型29課件5.螺旋模型(SpiralModel)規(guī)劃評價專家系統(tǒng)一個詳細的生命週期模型線性模型在圖6-7

包含從規(guī)劃到系統(tǒng)評估的步驟

描述在系統(tǒng)開發(fā)過程中哪些點的功能將被評估

驗證和證實步驟可以在開發(fā)過程中平行處理

重要的是根據(jù)相同的步驟程序來維護專家系統(tǒng)的品質(zhì)30課件一個詳細的生命週期模型線性模型在圖6-730課件規(guī)劃知識定義知識設(shè)計程式開發(fā)和完成系統(tǒng)知識驗證系統(tǒng)評估來源定義和選擇擷取分析和抽取定義詳細的設(shè)計正規(guī)測試測試分析圖6-7專家系統(tǒng)開發(fā)生命週期的線性模型工作規(guī)劃知識檢閱初步的資料檢閱知識系統(tǒng)資料檢閱測試稽核檢閱最終檢閱知識底線設(shè)計底線產(chǎn)品底線31課件知識定義知識設(shè)計程式開發(fā)知識驗證系統(tǒng)評估來源定義和選擇擷取1.問題分析，定義及工作規(guī)劃(Planning)產(chǎn)生正規(guī)的工作規(guī)劃

一些文件集用來導(dǎo)引和評估開發(fā)流程表6-2

32課件1.問題分析，定義及工作規(guī)劃(Planning)產(chǎn)生正規(guī)的工工作項目目標可行性評估

(Feasibilityassessment)決定是否值得去建立此系統(tǒng)，且是否要導(dǎo)入專家系統(tǒng)技術(shù)資源管理

(Resourcemanagement)估計所需的人員、時間、資金、軟體、和硬體等資源。如何取得和管理這些資源?工作項目(Taskphasing)決定開發(fā)步驟中的工作項目和其順序工作進度(Schedules)決定工作項目的開始和完成日期功能規(guī)劃(Preliminaryfunctionallayout)根據(jù)所決定此系統(tǒng)的高階功能，定義什麼是此系統(tǒng)該完成的。此工作決定此系統(tǒng)的目的進階功能

(High-levelrequirements)用高階的名詞來描述這些系統(tǒng)的功能如何達成33課件工作項目目標可行性評估決定是否值得去建立此系統(tǒng)，且是否要導(dǎo)動機與問題確認資料導(dǎo)向(Datadriven)由下而上專案(Bottom-upproject)資料純化(Datacleansing)資料轉(zhuǎn)換(Datatransformation)圖6-13目標導(dǎo)向(Goaldriven)由上而下專案(Top-downproject)兩階段第一階段:列出所有可能目標(possibletargetlist)第二階段:針對所有列出之目標架構(gòu)階層關(guān)係，建立目標階層（Targetshierarchy）34課件動機與問題確認資料導(dǎo)向(Datadriven)34課件資料導(dǎo)向的問題確認流程

35課件資料導(dǎo)向的問題確認流程35課件可行性評估定性分析

需求資源、知識來源、支援人力風險問題難易度如何?知識是否容易取得?專案人員能力是否足夠?發(fā)展之技術(shù)原理是否合理?技術(shù)是否容易維護?定量分析成本效益36課件可行性評估定性分析 36課件專家系統(tǒng)專案計劃書計劃書項目內(nèi)容說明專案名稱淺顯扼要的將整個專案欲解決的問題及解決方式說明。執(zhí)行時間專案執(zhí)行的時間規(guī)劃，包括資料蒐集整理、研究發(fā)展、系統(tǒng)建置、文件編撰、系統(tǒng)維護計劃擬定等時間。專案摘要概要的說明整個專案的目的及預(yù)計達成的成果，一般建議以兩百字到五百字左右的長度撰寫專案摘要。執(zhí)行團隊/配合人員說明整個專案在進行中，執(zhí)行團隊的名單及相關(guān)單位需要配合的人力。計劃內(nèi)容欲解決的問題說明知識來源與規(guī)劃專家系統(tǒng)知識的來源是專案的關(guān)鍵，如何規(guī)劃知識的來源，整理資料庫現(xiàn)有的資料特性及搭配領(lǐng)域?qū)＜业膮f(xié)助，以縮短建制知識庫的時間與減少可能的困難。導(dǎo)入技術(shù)背景及技術(shù)關(guān)聯(lián)說明說明預(yù)定導(dǎo)入的相關(guān)技術(shù)背景，此技術(shù)與組織原有技術(shù)之間的關(guān)聯(lián)，及未來新技術(shù)導(dǎo)入時的利基等詳細說明，以利技術(shù)團隊更清楚知道專案的技術(shù)里程碑。預(yù)期效益除了技術(shù)上的導(dǎo)入效益之外，對於使用單位產(chǎn)生的預(yù)期效益也是重要的評估資料。預(yù)期產(chǎn)出產(chǎn)品在預(yù)期效益之中特別可以釐清的產(chǎn)品列表。工時及採購清單預(yù)定支援的人力成本，預(yù)定採購品名清單。時程預(yù)估將每項技術(shù)研讀/研究/導(dǎo)入及預(yù)定產(chǎn)出成果或產(chǎn)品的時間說明清楚，並依據(jù)資料蒐集整理、研究發(fā)展、系統(tǒng)建置、文件編撰、系統(tǒng)維護計劃擬定等項目訂定查核時間點（Checkpoint）。37課件專家系統(tǒng)專案計劃書計劃書項目內(nèi)容說明專案名稱淺顯扼要的將整個2.知識定義，擷取及技術(shù)評估

(KnowledgeDefinition)定義專家系統(tǒng)所需的知識包含兩個工作

定義知識來源

知識的選擇(表6-2)知識擷取

分析和抽取(表6-3)例如RepertoryGrids38課件2.知識定義，擷取及技術(shù)評估

(KnowledgeDefi工作項目

目的來源確認不考慮可利用性，誰或是什麼是知識來源？來源的重要性根據(jù)開發(fā)過程的重要性來界定來源知識的優(yōu)先順序來源的可利用性依照可利用性的順序列出知識來源。書和其他文件一般說來比人類專家更容易取得來源選擇根據(jù)重要性和可利用性選擇知識來源表6-3知識來源確認和選擇工作39課件工作項目目的來源確認不考慮可利用性，誰或是什麼是知識來源？工作項目目的擷取策略指出用何種方法擷取出知識，例如專家面談、閱讀文件、規(guī)則歸納、知識表格等等知識元素確認挑選出特定且對於此生命週期有用的知識知識分類系統(tǒng)藉由開法者去分類和組織知識以幫助驗證和了解知識。採用階層化的群組詳細的功能規(guī)劃詳細指出此系統(tǒng)的功能能力；這比較屬於技術(shù)層面而初步的功能規(guī)劃比較屬於管理層面初步的流程控制描述此專家系統(tǒng)在一般情形下如何被執(zhí)行。階段會對應(yīng)到那些在群組裡面被活化或抑制的邏輯規(guī)則來控制執(zhí)行流程40課件工作項目目的擷取策略指出用何種方法擷取出知識，例如專家面談、初步的使用者手冊從使用者的角度來描述系統(tǒng)。這個部分總是容易被忽略，但卻是相當重要的部分。為了越快速得到一些回饋，與使用者互動是相當重要的。如果他們不使用此系統(tǒng)，這系統(tǒng)便是沒有價值的需求規(guī)格仔細地定義出這系統(tǒng)被預(yù)期要做的事情。此專家系統(tǒng)將根據(jù)這些需求被驗證知識底線為系統(tǒng)的知識設(shè)限。任何改變必須透過正式的改變請求。高階的知識現(xiàn)在已經(jīng)是何下一步驟的知識設(shè)計表6-4知識擷取、分析和抽取工作3.系統(tǒng)分析及技術(shù)選定41課件初步的使用者手冊從使用者的角度來描述系統(tǒng)。這個部分總是容易被4.系統(tǒng)設(shè)計及發(fā)展

(KnowledgeDesign)

為了產(chǎn)生詳細的專家系統(tǒng)設(shè)計兩個主要的工作：知識定義(表6-5)詳細的設(shè)計(表6-6)例如CLIPS內(nèi)部的事實結(jié)構(gòu)(在表6-5)

不是很有意義（price10）好一點（goldprice10）不錯42課件4.系統(tǒng)設(shè)計及發(fā)展

(KnowledgeDesign)工作項目

目的知識表達指出知識要如何表達，例如規(guī)則、框架、或是邏輯。主要是依據(jù)所選用專家系統(tǒng)工具是否支援詳細的控制結(jié)構(gòu)指出三種一般性的流程控制。(1)假如系統(tǒng)內(nèi)嵌有程序碼，這些程序碼如何被呼叫；(2)控制相關(guān)的規(guī)則群組在一個執(zhí)行中的系統(tǒng)；(3)對規(guī)則的高層控制結(jié)構(gòu)內(nèi)部的事實結(jié)構(gòu)用一種一致性的方法指出內(nèi)部的事實結(jié)構(gòu)來幫助了解初步的使用者介面規(guī)劃出初步的使用者介面。由使用者那獲得有關(guān)介面的回饋初步的測試規(guī)劃指出程式碼將如何被測試。定義測試資料、驅(qū)動測試，以及測試的結(jié)果如何被分析表6-5知識定義工作43課件工作項目目的知識表達指出知識要如何表達，例如規(guī)則、框架、或工作項目

目的設(shè)計結(jié)構(gòu)指出知識如何合理地被組織在知識庫中以及知識庫中含有什麼實作策略指出系統(tǒng)該如何被實作詳細的使用者介面當收到關(guān)於初步的使用者介面設(shè)計的回饋後，規(guī)劃出詳細的使用者介面

設(shè)計規(guī)格和報告將設(shè)計過程文件化詳細的測試規(guī)劃詳細指出程式碼如何被測試及驗證表6-6詳細的知識設(shè)計工作44課件工作項目目的設(shè)計結(jié)構(gòu)指出知識如何合理地被組織在知識庫中以及5.系統(tǒng)開發(fā)，測試及客戶導(dǎo)入

(CodeandCheckout)

開始實際的程式實作表6-7終止在“test”readinessreview”去決定是否該專家系統(tǒng)已