1、课件1Chapter 9. The Design of Expert Systems專家系統設計流程專家系統設計流程课件2 本章節提出一整體建立實際專家系統的指引，而不是研究用的雛型系統 為了建立一符合成本效益和有效率的專家系統，我們將討論一些軟體工程的方法論课件3影響專家系統專案的因素 組織內部的影響 管理單位 決策者 使用單位 教育人事單位 軟體開發部門 組織外部的影響組織外部的影響： 客戶 供應商 協力廠商 政府主管機關课件4课件5建置專家系統專案建置專家系統專案選擇適當的範本：為什麼我們要建立專家系統?收益：收益是什麼?(資金, 效率, )工具：有哪些適合的工具可用來建立此系統?(LI
2、SP, CLIPS, KEE,PCPLUS, )花費：這系統的建製將花費多少?如果沒有人使用，這系統將是無用的课件6專案管理專案管理 （PROJECT MANAGEMENT）工作項目管理Activity Management產品設定管理Product ConfigurationManagement資源管理Resource Management規劃規劃排程排程紀錄紀錄分析分析產品管理產品管理變異管理變異管理擷取資源擷取資源最小化資源最小化資源瓶頸瓶頸分派需要的資源分派需要的資源預測資源預測資源需求需求專案管理工作項目课件7(1)工作項目管理 (Activity Management) 規劃 (P
3、lanning) 定義工作項目、優先順序 列出資源需求、訂定里程碑 執行過程 責任 排程 (Scheduling) 指定開始及結束時間 解決同樣優先權之工作排程衝突 紀錄 (Chronicling) 監視專案效率 分析 (Analysis) 分析以上相關的工作項目课件8(2)產品設定管理 (Product configuration management) 產品管理 (Product management) 管理產品之不同版本 變異管理 (Change management) 管理變異規劃及評估影響大小 指定適當人員引發變異 安裝新的產品版本课件9(3)資源管理 (Resource manag
4、ement)1. 預測資源需求2. 擷取需求3. 指定最佳資源使用效率的回應4. 提供適當且必要的資源以縮小專案瓶頸 课件10Feasibility Study(可行性研究可行性研究)Rapid Prototype(快速雛形設計快速雛形設計)Refined System ( - test)(調整修正系統調整修正系統)Field Testable ( - test)(導入領域測試導入領域測試)Commercial Quality System(商用系統品質設定商用系統品質設定)Maintenance and Evolution(系統維護與演進系統維護與演進)文件研究比較來顯示此專案是可文件研究比
5、較來顯示此專案是可行的行的快速地將想法、激起的熱忱和影響較高層的管快速地將想法、激起的熱忱和影響較高層的管理融合在一起理融合在一起知識工程師和專家根據真實問題做專家系統的知識工程師和專家根據真實問題做專家系統的內部測試內部測試由選定的使用者測試系統由選定的使用者測試系統 而不是知識而不是知識工程師或是專家工程師或是專家驗證和測試驗證和測試 使用者文件使用者文件 訓練訓練透過電話或是電子郵件快速的做使用者透過電話或是電子郵件快速的做使用者支援支援修正臭蟲修正臭蟲增進系統能力增進系統能力專家系統發展階段專家系統發展階段课件11可行性研究课件12快速雛形設計课件13商用品質設定壓力測試類別 方法說明
6、及範例 效果 大量運算 重複執行某項功能數萬次 驗證某些功能不會殘留一些額外的資訊於記憶體或硬碟暫存檔案之中，在數次執行後可能因為記憶體空間不足或是其他因素造成副作用。 大量運算 連續規則推論72小時 驗證某些功能不會殘留一些額外的資訊於記憶體或硬碟暫存檔案之中，在數次執行後可能因為記憶體空間不足或是其他因素造成副作用。 惡劣環境 將軟硬體系統置於高溫環境中在長時間運作的系統中，高溫工作的情況偶爾會發生，可以測試在此環境中系統的表現。 惡劣環境 將軟硬體系統置於低溫環境中 檢查硬體系統是否有訊號不正常之情況發生。 不正常操作 在操作過程中突然關閉系統檢查記憶體回復之情況是否如預期。 規則迴圈
7、(例如：A-B, B-C, C-A），造成規則迴圈的特殊錯誤。 檢驗系統是否針對此類邏輯錯誤具判斷能力。 课件14遞送問題 (The Delivery Problem) 應該在早期開發過程中考慮 在標準硬體上執行 最好要考慮花費 考慮與其他程式的通訊和協調课件15維護與演進 (Maintenance and Evolution) 比傳統程式更複雜 必須要有系統化和有效率的方法從使用者收集問題回報維護工作: 系統程式碼維護 系統功能維護 資料庫維護课件16發展階段的錯誤 (Errors in Development Stages)1. 專家的知識錯誤2. 語意錯誤3. 語法錯誤4. 推論引擎錯誤
8、5. 推論鏈錯誤6. 忽略的限制錯誤 人類專家了解系統的知識範圍和效能優雅地忽略的邊降低.课件17Expert專家Knowledge Engineer知識工程師Knowledge Base知識庫Inference Engine推論引擎Inference Chain推論鏈 專家的知識錯誤，例如不正確和不完整專家的知識錯誤，例如不正確和不完整的知識的知識 知識工程師和專家之間的語意錯誤知識工程師和專家之間的語意錯誤 由專家那擷取出的知識不完整由專家那擷取出的知識不完整表格語法錯誤表格語法錯誤由於不正確、由於不正確、 不完整的知識，和不確不完整的知識，和不確定性的規則和事實所導致的內容錯誤定性的規則
9、和事實所導致的內容錯誤 錯誤發生在推論引擎，和其他的專家系錯誤發生在推論引擎，和其他的專家系統工具軟體統工具軟體 由於不正確的規則優先權、規則的交互作由於不正確的規則優先權、規則的交互作用、和知識庫錯誤而導致的推論錯誤用、和知識庫錯誤而導致的推論錯誤 由於不單調的推論而導致錯誤由於不單調的推論而導致錯誤圖圖 6-3 專家系統主要的錯誤和起因專家系統主要的錯誤和起因课件18 軟體工程和專家系統軟體工程和專家系統軟體工程產品問題 高花費的發展高花費的發展過程過程多樣性的發展過多樣性的發展過程程程式設計師缺乏生產程式設計師缺乏生產力力文件文件計畫、需求、計畫、需求、和設計和設計軟體生軟體生命週期命週
10、期高花費的發展高花費的發展過程過程容易維護和可精容易維護和可精進的進的良好的文件良好的文件排程排程報告報告準時準時有成本效益有成本效益的的目標圖圖 6-4 軟體工程的方法論軟體工程的方法論课件19資料庫系統與專家系統的關係课件20傳統軟體專案概念课件21知識工程概念問題(problem) = 資料(data) + 未知資訊(unknown information)课件22專家系統專案與知識工程之間關係概念课件23部分專家系統軟體品質的評量部分專家系統軟體品質的評量給定正確輸入而有正確輸出給定正確輸入而有完整的輸出給定相同的輸入而有一致的輸出穩定，且不會常因為臭蟲而當機對使用者是合用的且最好是容
11、易使用地可維護的可增進的經過驗證去證明系統滿足使用者的需求經過測試後證明正確性和完整性有效率的课件24 可重複使用的程式碼用在其他的應用程式 容易移轉到其他的硬體/軟體環境 容易與其他軟體連接 容易理解的程式碼 精確的 優雅的在知識的邊緣降低 可以嵌入其他語言的能力 驗證知識庫 解釋機制课件251.維護成本 (Maintenance Costs)一般軟體 (Conventional software) - 60 80 % 的軟體花費 - 二到四倍原本的開發花費專家系統 (Expert systems) - 可能更糟2.瀑布模型 (Waterfall Model)一個傳統軟體開發的生命週期模型圖
12、6-5下一歩要完成什麼?下一階段要花多少時間完成?q專家系統的生命週期專家系統的生命週期课件26圖圖 6-5 軟體生命週期的瀑布模型軟體生命週期的瀑布模型系統可行性系統可行性確認確認軟體規劃及需求軟體規劃及需求確認確認確認確認確認確認單元測試單元測試產品驗證產品驗證系統測試系統測試重新確認重新確認使用及維護使用及維護實施實施整合整合發展發展產品設計產品設計細部設計細部設計生命週期-瀑布概念课件273.Code-and-Fix 模型比瀑布模型更實際不需要事先知道所有的資訊4.Incremental 模型瀑布模型的改良Top-down 方法容易測試、證實和驗證一個延伸整個開發過程的連續性快速雛型方
13、法建立雛型系統決定需求完成系統建制课件28助手等級同事等級專家等級規則規則規則主要的增加單一規則單一規則: 大量的增加大量的增加最初的雛型最初的雛型次要的增加次要的增加次要的增加课件295.螺旋模型 (Spiral Model)規劃 需求 設計 證實評價專家系統 測試 驗證 整合知識擷取驗證程式撰寫 驗證 測試圖圖 6-6一個專家系統開發過程的螺旋模型一個專家系統開發過程的螺旋模型课件30一個詳細的生命週期模型一個詳細的生命週期模型線性模型在圖 6-7 包含從規劃到系統評估的步驟 描述在系統開發過程中哪些點的功能將被評估 驗證和證實步驟可以在開發過程中平行處理 重要的是根據相同的步驟程序來維護
14、專家系統的品質课件31規劃規劃知識定義知識定義 知識設計知識設計程式開發程式開發和和完成系統完成系統知識驗證知識驗證系統評估系統評估來源定義來源定義和選擇和選擇擷取分析和擷取分析和 抽取抽取定義定義詳細的設詳細的設計計正規測試正規測試測試分析測試分析圖圖 6-7 專家系統開發生命週期的線性模型專家系統開發生命週期的線性模型工作規工作規劃劃 知識檢閱知識檢閱初步的資料初步的資料檢閱檢閱知識系統資知識系統資料檢閱料檢閱測試稽核檢測試稽核檢閱閱 最終檢最終檢閱閱知識底線知識底線設計底線設計底線產品底線產品底線课件321.問題分析，定義及工作規劃(Planning)產生正規的工作規劃 一些文件集用來導
15、引和評估開發流程表 6-2 课件33工作項目目標可行性評估 (Feasibility assessment)決定是否值得去建立此系統，且是否要導入專家系統技術資源管理 (Resource management)估計所需的人員、時間、資金、 軟體、 和硬體等資源。如何取得和管理這些資源?工作項目 (Task phasing)決定開發步驟中的工作項目和其順序工作進度 (Schedules)決定工作項目的開始和完成日期功能規劃(Preliminary functional layout) 根據所決定此系統的高階功能，定義什麼是此系統該完成的。此工作決定此系統的目的進階功能 (High-level r
16、equirements)用高階的名詞來描述這些系統的功能如何達成课件34動機與問題確認 資料導向 (Data driven) 由下而上專案 (Bottom-up project) 資料純化 (Data cleansing) 資料轉換 (Data transformation) 圖 6-13 目標導向 (Goal driven) 由上而下專案 (Top-down project) 兩階段 第一階段: 列出所有可能目標 (possible target list) 第二階段: 針對所有列出之目標架構階層關係，建立目 標階層（Targets hierarchy）课件35資料導向的問題確認流程 课件3
17、6可行性評估 定性分析 需求 資源、知識來源、支援人力 風險問題難易度如何 ?知識是否容易取得 ?專案人員能力是否足夠 ?發展之技術原理是否合理 ?技術是否容易維護 ? 定量分析 成本效益课件37專家系統專案計劃書計劃書項目內容說明專案名稱淺顯扼要的將整個專案欲解決的問題及解決方式說明。執行時間專案執行的時間規劃，包括資料蒐集整理、研究發展、系統建置、文件編撰、系統維護計劃擬定等時間。專案摘要概要的說明整個專案的目的及預計達成的成果，一般建議以兩百字到五百字左右的長度撰寫專案摘要。執行團隊/配合人員說明整個專案在進行中，執行團隊的名單及相關單位需要配合的人力。計劃內容欲解決的問題說明知識來源與
18、規劃專家系統知識的來源是專案的關鍵，如何規劃知識的來源，整理資料庫現有的資料特性及搭配領域專家的協助，以縮短建制知識庫的時間與減少可能的困難。導入技術背景及技術關聯說明說明預定導入的相關技術背景，此技術與組織原有技術之間的關聯，及未來新技術導入時的利基等詳細說明，以利技術團隊更清楚知道專案的技術里程碑。預期效益除了技術上的導入效益之外，對於使用單位產生的預期效益也是重要的評估資料。預期產出產品在預期效益之中特別可以釐清的產品列表。工時及採購清單預定支援的人力成本，預定採購品名清單。時程預估將每項技術研讀/研究/導入及預定產出成果或產品的時間說明清楚，並依據資料蒐集整理、研究發展、系統建置、文件
19、編撰、系統維護計劃擬定等項目訂定查核時間點（Check point）。课件382.知識定義，擷取及技術評估(Knowledge Definition) 定義專家系統所需的知識 包含兩個工作 定義知識來源 知識的選擇 (表 6-2) 知識擷取 分析和抽取 (表 6-3) 例如 Repertory Grids课件39工作項目 目的來源確認不考慮可利用性，誰或是什麼是知識來源？來源的重要性根據開發過程的重要性來界定來源知識的優先順序來源的可利用性依照可利用性的順序列出知識來源。書和其他文件一般說來比人類專家更容易取得來源選擇根據重要性和 可利用性選擇知識來源表 6-3 知識來源確認和選擇工作课件40
20、工作項目工作項目目的目的擷取策略指出用何種方法擷取出知識，例如專家面談、閱讀文件、規則歸納、知識表格等等知識元素確認挑選出特定且對於此生命週期有用的知識知識分類系統藉由開法者去分類和組織知識以幫助驗證和了解知識。採用階層化的群組詳細的功能規劃詳細指出此系統的功能能力；這比較屬於技術層面而初步的功能規劃比較屬於管理層面初步的流程控制描述此專家系統在一般情形下如何被執行。階段會對應到那些在群組裡面被活化或抑制的邏輯規則來控制執行流程课件41初步的使用者手冊從使用者的角度來描述系統。這個部分總是容易被忽略，但卻是相當重要的部分。為了越快速得到一些回饋，與使用者互動是相當重要的。如果他們不使用此系統，
21、這系統便是沒有價值的需求規格仔細地定義出這系統被預期要做的事情。此專家系統將根據這些需求被驗證知識底線為系統的知識設限。任何改變必須透過正式的改變請求。高階的知識現在已經是何下一步驟的知識設計表 6-4 知識擷取、分析和抽取工作3.系統分析及技術選定课件424.系統設計及發展 (Knowledge Design) 為了產生詳細的專家系統設計 兩個主要的工作：知識定義 (表 6-5)詳細的設計 (表 6-6) 例如CLIPS內部的事實結構 (在表 6-5)10不是很有意義（price 10） 好一點（gold price 10） 不錯课件43工作項目 目的知識表達指出知識要如何表達，例如規則、框
22、架、或是邏輯。主要是依據所選用專家系統工具是否支援詳細的控制結構指出三種一般性的流程控制。(1)假如系統內嵌有程序碼，這些程序碼如何被呼叫；(2)控制相關的規則群組在一個執行中的系統； (3)對規則的高層控制結構內部的事實結構用一種一致性的方法指出內部的事實結構來幫助了解初步的使用者介面規劃出初步的使用者介面。由使用者那獲得有關介面的回饋初步的測試規劃指出程式碼將如何被測試。定義測試資料、驅動測試，以及測試的結果如何被分析表 6-5 知識定義工作课件44工作項目工作項目 目的目的設計結構設計結構指出知識如何合理地被組織在知識庫中以及知識庫指出知識如何合理地被組織在知識庫中以及知識庫中含有什麼中
23、含有什麼實作策略實作策略指出系統該如何被實作指出系統該如何被實作詳細的使用者介面詳細的使用者介面當收到關於初步的使用者介面設計的回饋後，規劃當收到關於初步的使用者介面設計的回饋後，規劃出詳細的使用者介面出詳細的使用者介面 設計規格和報告設計規格和報告將設計過程文件化將設計過程文件化詳細的測試規劃詳細的測試規劃詳細指出程式碼如何被測試及驗證詳細指出程式碼如何被測試及驗證表 6-6詳細的知識設計工作课件455.系統開發，測試及客戶導入 (Code and Checkout)開始實際的程式實作表 6-7終止在 “test” readiness review” 去決定是否該專家系統已經準備好做下一個階
24、段的知識驗證课件46工作項目工作項目目的目的程式撰寫程式撰寫實作程式實作程式測試測試使用測試資料使用測試資料、 驅動測試驅動測試 、 和測試分析程序來和測試分析程序來測試程式碼測試程式碼列出程式碼列出程式碼產生包含註解產生包含註解，文件化的程式碼文件化的程式碼使用者手冊使用者手冊產生使用者手冊，如此專家和使用者可以有一些產生使用者手冊，如此專家和使用者可以有一些回饋意見對於此系統回饋意見對於此系統安裝安裝/ /操作手冊操作手冊撰寫系統的安裝撰寫系統的安裝/ /操作手冊操作手冊系統說明文件系統說明文件撰寫整體專家系統的功能、限制、撰寫整體專家系統的功能、限制、 問題等相關問題等相關文件文件表 6
25、-7程式碼和時間點工作课件476.知識驗證 (Knowledge Verification)測定系統的正確性、完整性和一致性兩個主要的工作：正規測試正規測試 (表表 6-8) 尋找尋找不正確的答案不正確的答案不完整的答案不完整的答案不一致的答案不一致的答案測試分析 (表 6-9)课件48工作項目目的測試程序實行正規測試程序測試報告將測試結果文件化工作項目目的結果評估分析測試結果建議撰寫建議和測試結論的相關文件表 6-8知識驗證步驟的正規測試工作表 6-9測試分析工作课件497.系統評估 (System Evaluation)總結如何根據建議作系統的改進和改正表 6-10假如有新的知識要加入，系統的驗證必須包含所有的知識一起執行 (包刮之前的和新加入的知識)课件50系統文件撰寫及整理文件摘要文件修改歷史紀錄專家訪談紀錄快速雛形發展版本控管程式原始碼及註解系統修正紀錄測試紀錄專案執行紀錄與計劃書之差異比較參考文獻及資料出處索引 课件51系統維護
