专家系统设计流程课件

Chapter9.

TheDesignofExpertSystems

專家系統設計流程1课件Chapter9.

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

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

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

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

使用者文件

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

方法說明及範例

效果

大量運算

重複執行某項功能數萬次

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

連續規則推論72小時

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

惡劣環境

將軟硬體系統置於高溫環境中在長時間運作的系統中，高溫工作的情況偶爾會發生，可以測試在此環境中系統的表現。惡劣環境

將軟硬體系統置於低溫環境中

檢查硬體系統是否有訊號不正常之情況發生。

不正常操作

在操作過程中突然關閉系統檢查記憶體回復之情況是否如預期。

規則迴圈

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

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

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

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

由專家那擷取出的知識不完整表格語法錯誤由於不正確、不完整的知識，和不確定性的規則和事實所導致的內容錯誤

錯誤發生在推論引擎，和其他的專家系統工具軟體

由於不正確的規則優先權、規則的交互作用、和知識庫錯誤而導致的推論錯誤

由於不單調的推論而導致錯誤圖6-3專家系統主要的錯誤和起因17课件ExpertKnowledgeEngineerKnowle□軟體工程和專家系統軟體工程產品問題

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

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

包含從規劃到系統評估的步驟

描述在系統開發過程中哪些點的功能將被評估

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

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

一些文件集用來導引和評估開發流程表6-2

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

(Feasibilityassessment)決定是否值得去建立此系統，且是否要導入專家系統技術資源管理

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

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

35课件資料導向的問題確認流程35课件可行性評估定性分析

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

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

定義知識來源

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

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

(KnowledgeDefi工作項目

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

(KnowledgeDesign)

為了產生詳細的專家系統設計兩個主要的工作：知識定義(表6-5)詳細的設計(表6-6)例如CLIPS內部的事實結構(在表6-5)

不是很有意義（price10）好一點（goldprice10）不錯42课件4.系統設計及發展

(KnowledgeDesign)工作項目

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

目的設計結構指出知識如何合理地被組織在知識庫中以及知識庫中含有什麼實作策略指出系統該如何被實作詳細的使用者介面當收到關於初步的使用者介面設計的回饋後，規劃出詳細的使用者介面

設計規格和報告將設計過程文件化詳細的測試規劃詳細指出程式碼如何被測試及驗證表6-6詳細的知識設計工作44课件工作項目目的設計結構指出知識如何合理地被組織在知識庫中以及5.系統開發，測試及客戶導入

(CodeandCheckout)

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