• 沒有找到結果。

中 華 大 學

N/A
N/A
Protected

Academic year: 2022

Share "中 華 大 學"

Copied!
61
0
0

加載中.... (立即查看全文)

全文

(1)

中 華 大 學 碩 士 論 文

適用於服務導向架構的情境推理系統 A Context Reasoning System on

Service-Oriented Architecture

系 所 別:資訊工程學系碩士班 學號姓名:M09602033 黃偉峰 指導教授:張欽智 博士

中 華 民 國 九十九 年 八 月

(2)

摘要

由 於 網 路 服 務 (Web Services) 技 術 的 導 入 , 服 務 導 向 架 構 (Service-oriented Architecture)成為發展迅速的跨平台的計算架構。在情境感知(Context-aware)的環境中,

各式的裝置需在不同計算環境中運作,結合網路服務提供適當的解決方案。如何在情境 感知的環境中發展可結合網路服務的推理機制,建構實用的系統,是本篇研究的主題。

在本篇論文中,我們提出應用於行動裝置以規則為基礎的情境推理系統,提供使用 者在當時的環境下得到最適當的服務及資訊,我們主要利用 JAVA Expert System Shell (JESS)、Microsoft UDDI 開發工具與案例式推理去實作我們系統。JESS 是用 JAVA 語言 發展出來的規則為基礎的專家系統,在 JESS 中主要分為規則庫、事實庫、推理機三大 部分所組成;在規則庫中主要存放相關的知識以及推導的規則,事實庫存放已知的基本 事實和即時從情境中所得到的事實,推理機是連結規則庫與事實庫進行推論,透過 JESS 推理機所推理的出的結果,再透過服務導向架構傳送到 Microsoft UDDI 要求合適的服務,

系統最後藉由案例式推理找到相似的案例並加以修正,提供給使用者更多元與更適合的 服務。

最後以課堂教學為範例,來說明本系統如何幫助老師課堂上的教學與學生學習,並 進一步的去驗證我們提出的方法。當一個學生可能在課堂上打瞌睡或是沒有專心在聽老 師講解,我們可以收集學生的生理的資訊,如呼吸、心跳、血壓,傳送到推理系統中的 JESS 進行推論,並推論出這位學生並不專心在於課堂上,接著去搜尋所需的服務,並 將建議的服務呈現在計算裝置上讓老師選擇,例如:傳遞訊息到學生的行動裝置上,打 出燈光或產生震動提醒學生要專心上課,或者提供學生有興趣的資訊;如選擇自動模式,

系統直接採用系統推理出最適當的服務。

關鍵字: 情境感知、網路服務、服務導向架構、Jess、Rule-base

(3)

Abstract

Because of the introduction of Web service technology, the service-oriented architecture (SOA) has become a rapid developing interoperating platform. In a context-aware environment various devices need to cooperate in different computing environments. It is an appropriate solution to combine Web services with context-aware computing. To develop a feasible reasoning system that can be operated on SOA is the main topic of this thesis.

In this paper, a rule-base context reasoning system on SOA is proposed. The system aims at offering users the most appropriate services and information according to the situation.

JAVA Expert System Shell (JESS), Microsoft UDDI, and case-based reasoning are used to implement a rule-base context reasoning system. JESS is a rule-based expert system developed by JAVA. There are three parts in JESS: rule-base, fact-base, and inference engine.

The rule-base stores relevant knowledge and inferring rules. The fact-base stores the facts which are fundamental and acquired from the environment. Inference engine infers by connecting rule-base and fact-base. The results of inference engine will be sent to Microsoft UDDI to acquire appropriate services. Then the system will find similar case by case-based reasoning and modify it to offer users more variable and appropriate services.

We take a classroom example to explain how this system helps teaching and learning in class. JESS could infer that a student is drowsy or distracted in class from collecting the student’s physiological information such as breath, heart beats, and blood pressure, and then suggest which services are needed on teacher’s computing devices. Then the teacher could choose the most appropriate service such as sending messages to the student’s devices, turning on a focus light, or making vibration to remind the student to concentrate on his lesson or offering interesting information. If the automatic mode is selected, the system will take the most appropriate service which is derived by the system.

Keywords: Context-awareness, Service-Oriented Architecture (SOA), Web Services,

Rule-base

(4)

致謝

終於準備結束學生的生涯了,在研究所這 3 年多的時間內、非常感謝我的指導教授 張欽智老師的細心教導,不論是在研究上的指引、還是遇到問題時的協助,讓我可以順 利的完成學業以及論文。老師也不只有扮演在我們學業上的指導角色,老師幽默風趣的 個性、就如同日常生活中的同伴一樣融洽好相處,讓我們有許多的歡笑以及樂趣。

而在研究所的這段時間內,很榮幸的可以和小巨人以及紅月一起共同研究、努力,

當然還有一起用力玩樂,讓我真正認識了你們,當然還有幫了我許多忙的學弟泫廷、新 隆。以及因緣際會之下到了計算機中心打工而認識了德沛,讓我有了許多新體驗、新感 受,也真的很高興可以認識在研究所生活中的這群朋友們。

最後,我很感激我的家人,在我的後面默默的支持者我,不論是實質上的還是心靈 上的幫助,都讓我可以無慮的完成漫長的學業路程,扶持者我走至人生另一階段的開始,

這份恩情將永記在我心中,感謝你們。最後再一次謝謝所有的人,因為你們,我才會有 如此多采多姿的生活。

(5)

目錄

摘要 ... I ABSTRACT ... II 致謝 ... III 目錄 ... IV 表目錄 ... VI 圖目錄 ... VII

第一章 緒論 ... 1

2.1 研究背景與動機 ... 1

2.2 研究目的 ... 2

2.3 論文架構 ... 2

第二章 相關文獻與技術探討 ... 3

2.1 網路服務以及其相關研究 ... 3

2.2.1 行動網路服務 ... 4

2.2.2 服務導向架構 (Service-Oriented-Architecture) ... 5

2.2 推理技術 ... 7

2.2.1 規則邏輯 (Rule logic) ... 8

2.2.2 知識架構 (Ontology) ... 8

2.2.3 案例式推理 (Case-Based Reasoning,CBR) ... 9

2.3 個人化技術 ... 11

第三章 系統架構與研究方法 ... 13

3.1 系統設計簡介與分析 ... 13

3.2 系統架構設計 ... 14

3.3 JESS 推理模組 ... 17

3.4 服務選取模組 ... 20

3.4.1 Microsoft UDDI ... 20

3.4.2 權重加權與排序模組 ... 22

3.4.3 個人化喜好度 (User Preference Matrix) ... 24

3.5 案例式推理模組 ... 26

第四章 系統範例實作 ... 28

4.1 系統開發環境 ... 28

4.2 系統情境與功能 ... 29

4.2.1 課堂學習情境資訊 ... 30

(6)

4.2.2 Web Service 分布與設計 ... 31

4.2.3 系統功能 ... 33

4.2.4 實驗步驟與流程 ... 34

4.3 實驗執行與成果 ... 36

第五章 系統實驗與分析 ... 42

5.1 精確度與召回率分析比較 ... 42

5.2 實驗結果分析與探討 ... 45

5.3 整體系統架構比較 ... 48

第六章 結論與未來展望 ... 50

參考文獻 ... 51

(7)

表目錄

表 2-1 網路服務與行動網路服務特性比較 ... 4

表 2-2 各種推理技術比較(以計算資源高低排序) ... 8

表 2-3 歷年來學者對 Ontology 的定義 ... 9

表 2-4 使用者行為程度[4] ... 11

表 2-5UPM 運作的範例[4] ... 12

表 2-6 UPM 結果[4] ... 12

表 3-1 tModel 屬性表 ... 22

表 3-2 LVW 權重量表[19] ... 24

表 3-3 UMP 參數表 ... 25

表 3-4 教室情境屬性 ... 27

表 4-1 伺服端開發環境 ... 28

表 4-2 使用端開發環境 ... 29

表 4-3 網路服務開發環境 ... 29

表 4-4 網路服務屬性表 ... 31

表 4-5 網路服務分類表 ... 32

表 5-1 UDDI 測驗結果 ... 43

表 5-2 UPM 與 CBR 加入 UDDI 測驗結果 ... 44

表 5-3 系統程式特點表 ... 49

(8)

圖目錄

圖 2-1 服務導向架構 ... 5

圖 2-2 SOAP 文件範例 ... 6

圖 2-3 WSDL 文件範例 ... 7

圖 3-1 系統架構圖 ... 15

圖 3-2 JESS 基礎架構 ... 18

圖 3-3 知識架構 ... 18

圖 3-4 以 JESS 語法所制定規則 ... 19

圖 3-5 規則以 XML 語法所描述 ... 19

圖 3-6 Microsoft UDDI 2.0 介面 ... 21

圖 3-7 Microsoft UDDI 2.0 搜尋介面 ... 21

圖 3-8 LVW 與其他設定模組 UPM 精確度比對[19] ... 25

圖 4-1 情境資源 ... 30

圖 4-2 UDDI 服務搜尋 ... 32

圖 4-3 UDDI 服務註冊 ... 33

圖 4-4 系統實驗流程圖-學生 ... 34

圖 4-5 系統實驗流程圖-老師 ... 35

圖 4-6 系統登入畫面、老師與學生主畫面 ... 36

圖 4-7 學生資訊介面 ... 37

圖 4-8 學生詳細資訊 ... 37

圖 4-9 教室情境介面 ... 37

圖 4-10 虛擬教室情境資訊 ... 37

圖 4-11 個人化選項 ... 38

圖 4-12 更新個人化設定 ... 38

圖 4-13 服務名稱查詢介面 1 ... 38

圖 4-14 服務名稱查詢介面 2 ... 38

圖 4-15 服務提供者查詢介面 1……….39

圖 4-16 服務提供者查詢介面 2……….39

圖 4-17 技術模型名稱介面 1 ... 39

(9)

圖 4 -18 技術模型名稱介面 2 ... 39

圖 4-19 UPM 查詢介面 1 ... 40

圖 4-20 UPM 查詢介面 2 ... 40

圖 4-21 顯示事件發生 ... 40

圖 4 -22 系統提供服務選項 ... 40

圖 4-23 網路服務 1 ... 41

圖 4-24 網路服務 2 ... 41

圖 4-25 網路服務 3 ... 41

圖 4-26 回饋機制介面 ... 41

圖 5-1 精確度與召回率定義 ... 42

圖 5-2 各種搜尋方法精確度比較圖 ... 44

圖 5-3 各種搜尋方法召回率比較圖 ... 45

圖 5-4 服務名稱查詢精確度 ... 45

圖 5-5 服務提供者名稱查詢精確度 ... 45

圖 5-6 技術模型名稱精確度 ... 46

圖 5-7 服務名稱查詢召回率 ... 47

圖 5-8 服務提供者名稱查詢召回率 ... 47

圖 5-9 技術模型名稱召回率 ... 48

(10)

第一章 緒論

隨著時代的進步,科技的日新月異,行動裝置的運算能力大幅的提升與無

線網路的迅速發展,使用者可以藉由行動裝置透過網路尋找所需要的網路服務,

但是要如何依照目前所發生的情況,從眾多且繁雜的網路服務(Web Service)中選 取所需要的服務,此課題是許多研究者所努力達成的一個目標。

在 1.1 節說明本論文的研究背景與動機,1.2 節說明本論文目的,1.3 節介紹 本論文的章節架構。

2.1 研究背景與動機

近年來行動裝置能力大幅提升,不管是運算能力、螢幕尺寸大小、傳輸速度 與運作時間都跟以往的行動裝置相差甚多,加上網際網路的快速成長因此只是透 過網際網路所取得的文件網頁也慢慢的無法滿足使用者的需求,網路服務(Web Service)的技術也因此產生。

但是隨著時間、地點、人物的等不同所產生的情境資訊所需求的網路服務也 有所不同,而所謂情境是指不論在任何時間、地點可以用來描述實體特徵的資訊 就稱之為情境(2000, Dey and Abowd)[22],這也包括人與系統之間的互動、網路 速率和個人喜好等等,但是要如何依照以當下的情境中,從眾多且繁雜的網路服 務中過濾與選取所需要的網路服務並將選擇的網路服務透過行動裝置進行存取,

是本篇論文所要探討與研究的重點與主題。

我們使用推理技術與個人化模組來過濾多餘的網路服務;在目前應用在情境 推理中的推理技術包括了規則邏輯、模糊邏輯、類神經網路等等,但是每種推理 技術都有一定的限制與特殊情況,所以單一的推理技術並不能通用於每一種的情 境中(在第二章節中會詳細介紹每種推理技術),在這我們使用規則邏輯與案例式

(11)

推理來實現本系統所要達成的目的。

2.2 研究目的

本篇論文的主要研究目是提出適用於服務導向架構的情境推理系統,讓使用 者不需要浪費許多的時間來選擇網路服務,讓使用者可以即時取得符合需求的服 務與資訊。

在本篇論文中,我們建立一個課堂教學的虛擬環境,透過行動裝置上的感應 器去得知當時情境的資訊如:時間、溫度、地點等等,配合網路資訊與行動裝置 上的個人喜好設定形成基本的情境資訊,利用以規則邏輯為推理技術進行推理找 出當時情境環境的狀態,以產生的推理結果為依據去搜尋網路服務,配合個人化 模組避免搜尋到不必要且不相關的網路服務,最後使用服務導向架構解決資料整 合與跨平台問題。

2.3 論文架構

本論文中一共分為六章。第一章為論文研究的緒論,說明我們的研究為何、

為何要研究此論文、與此論文的研究方法。第二章為論文相關技術與文獻探討,

我們會針對本篇論文中所提及的相關技術與研究,依序探討說明。第三章為系統 架構,此章節為本論文的核心,說明我們研究當中所提出的系統架構流程與研究 方法。第四章為系統範例實作,以 Microsoft Visual Studio 為主要開發平台開發 出我們所提出的系統,分別針對各使用者的身分提供個別化的服務並且應用在課 堂教學環境中。第五章為系統評估,針對我們所提出的研究方法,細部討論當中 細節,藉以比較與驗證我們所提出的方法。第六章為結論與未來展望,針對本篇 論文作總結,並討論未來可進一步的研究方向。

(12)

第二章 相關文獻與技術探討

在本章節中,將概述本篇論文所運用的相關知識與技術,從網路服務開始,

說明架構與相關應用,接下來介紹現今較常被學者使用的推理技術與個別推理技 術優缺點與運用範圍並且介紹知識架構與如何運用在推理技術之中,最後說明個 人化技術的運用與原理,藉由本章節可以更進一步了解網路服務、知識架構與推 理技術的知識背景。在 2.1 節中簡介服務導向計算與網路服務的相關知識和基本 技術。在 2.2 節中將介紹目前各種推理方法所運用領域、耗費資源、與優缺點比 較。2.3 節則會介紹我們所選用個人化技術相關背景、定義與演算法。

2.1 網路服務以及其相關研究

網路服務是一種整合跨平台應用程式的技術,透過標準的 Web 通訊協定及 開放式標準(例如:HTTP、SOAP、和 XML)提供服務,只要透過 URL 就可以辨識 並存取網路上所提供的服務。而網路服務也可以作為提供服務的元件,用來建構 分散式架構系統,實現動態整合、平衡負擔等優點,讓不同平台使用不同語言建 置的系統透過網路服務輕易達到整合的效果,解決資訊與程式整合時所會遭遇互 通性的問題。簡單的說,網路服務把程式資料化並且在網際網路上提供給各個系 統或應用程式所使用。網路服務的特性包括:重複使用性、獨立性、物件導向性、

及內部處理等四大特色。

網路服務主要包含了 XML、WSDL、SOAP、UDDI 等標準技術規格。網路 服務經由 WSDL 所定義與描述功能並透過 SOAP 來傳遞訊息,達成電腦或程式 之間的溝通,而使用者經由 UDDI 來搜尋網路服務。下面會將詳細介紹這些標準 技術規格。

(13)

2.2.1 行動網路服務

網路服務的快速發展和行動網路的普及化,這兩種技術的結合,這種將網路 服務運用在行動網路上就稱做「行動網路服務」(Mobile Web Services,MWS)[6],

MWS 和 WS 有其差異性如表 2-1 所示。

在人手一機的時代中,行動網路服務能提供客戶個人化的服務在多樣化的行 動裝置上,雖然行動網路服務有行動網路環境和行動裝置的限制,但在情境感知 的環境中多行動網路服務的運作,然而個人化的特性卻是一般的網路服務所缺乏 的,且網路服務和行動網路服務的行動網路環境和行動裝置的限制,會隨著時間 慢慢縮小差距,所以選擇行動網路服務當作是我們提供的服務。

表 2-1 網路服務與行動網路服務特性比較

網路服務(WS) 行動網路服務(MWS)

可攜帶性 低 高

可靠度 高 低

運算能力 高 低

連線品質 高 低

資料傳送量 高 低

資料傳送頻率 高 低

時間和地點 資訊依賴性

低 高

個性化 低 高

(14)

2.2.2 服務導向架構 (Service-Oriented-Architecture)

「服務導向架構」(Service-Oriented-Architecture,SOA)是一種架構模型,主 要由服務需求者、服務仲介者與服務提供者這三種部分所構成,個別扮演的角色 與功能如圖 2-1:

圖 2-1 服務導向架構

1. 服務需求者(Service Provider):當系統或是使用者需要某些服務,將要求服 務的規格和條件輸入到服務仲介者進行搜尋,在從服務仲介者得知哪些服務 可以提供,借由 SOAP(Simple Object Access Protocol)在從服務提供者得到服 務;而 SOAP 是以 XML 為基礎的通訊協定,是編譯網路服務所需的要求或 回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間 傳輸資料的一種機制。

2. 服務仲介者(Service Broker):主要由註冊機制所扮演,目的是為了接收服務 需求者給提出的要求去尋找有註冊的網路服務中,哪一個網路服務是最符合 需求者的要求,將網路服務的資訊傳給服務需求者。

3. 服 務 提 供 者 (Service Provider) : 將 自 己 本 身 所 提 供 的 服 務 資 訊 借 由 WSDL(Web Service Description Language)在服務仲介者中進行註冊,並以

(15)

SOAP 提供服務資訊給服務需求者,WSDL 稱為網路服務描述語言,以 XML 為基礎的一種語言,用來描述網路服務功能並且說明如何存取與使用網路服 務。

使用服務導向架構建立互通性的計算模式並且資源可以清楚地分割並以跨 平台服務來呈現,解決企業的異質應用程式的整合問題,藉此達到資訊整合的目 的[2][12] ,圖 2-2 與圖 2-2 為 SOAP 與 WSDL 文件範例。

圖 2-2 SOAP 文件範例

(16)

圖 2-3 WSDL 文件範例

2.2 推理技術

人工智慧是新興的學科之一,相關的研究工作在第二次世界大戰後迅速的展 開,直到 1956 年正是被命名為「人工智慧」。推理技術在人工智慧領域中是非 常重要的議題,幾乎所有的人工智慧都會使用到推理,也因此推理技術也可以是 人工智慧的基本技術,到目前為止也有許多的推理技術被運用於情境推理中,而 對於推理的研究也往往涉及對邏輯的研究,因為邏輯是人腦思維的規律,也是推 理的理論基礎。目前常見的推理技術如表 2-2。

(17)

表 2-2 各種推理技術比較(以計算資源高低排序)

推論技術 應用情境 計算資源

規則邏輯 推論低、高階情境 低

模糊邏輯 推論不確定因子之環境 中低

知識架構 OWL 為基礎之情境建模與推論 中

貝氏網路推論 不確定情境之建模與推理偶發性情境 中高

類神經網路 情境認知與預測 高

案例式推理 例外情境之推論 高

2.2.1 規則邏輯 (Rule logic)

在生活中不論在任何地方都有相關的規則存在,例如交通、買賣、學習都有 屬於自己特定領域的規則,規則邏輯就是將某個領域中的相關知識與因果關係制 定成規則,當作規則邏輯推論時的基礎和理論,與事實進行推論。就以規則邏輯 特性進行推論的優點是:

1. 當資料完備也就是在規則明確且充足之下,容易被推論出結果而推論結果的 正確性也較高

2. 規則邏輯所使用的語法跟其他推論技術較淺顯易懂,是使用者或是系統普遍 所能理解的推論方法

2.2.2 知識架構 (Ontology)

知識架構(Ontology)源自於哲學一詞主要探討存有本身,即一切現實事物的 基本特徵。在人工智慧中,知識架構藉由概念與概念之間的關聯來描述人類腦中 所擁有的知識,知識架構的主要目標是獲得相關領域知識,提供該領域的工同理

(18)

解和認可的詞彙,而近代學者對於知識架構的定義如表 2-3

表 2-3 歷年來學者對 Ontology 的定義

時間 學者 定義

1993 T.R.Gruber Gruber Ontology 是一種可以概念化的規格 1995 Guarino & Giaretta Ontology 是概念化的描述

1997 Borst

可定義為被共享的概念化的一個形式的規格 說明

1997 Swartout ed al

知識架構是一種階層式的構造,可以用來描述 一個領域與作為知識庫的架構與基礎

1998 Guarino 是對於概念化的明確表達

1999 William and Austin

Ontology 是用於描述或表達某一領域知識的一 組概念或術語,可用以組織知識庫較高層次的 知識抽象,也可用來描述特定領域的知識

知識架構的架構主要有「物件」(Object)、「屬性」(Value)、與「關係」(Relation) 等,並且以階層式架構去描述某領域知識中的概念或是實體。採用知識架構進行 推論不但可以利用語意的推論得到精確的資訊,更可以得到相似概念並且增加推 理的範圍,可以讓準確率(Precision rate)與召回率(Recall rate)大幅的提升[15]。本 篇論文利用知識架構描述出課堂學習的物體關係,藉由這些關係和屬性去制訂相 關的規則並且存放在規則庫中。

2.2.3 案例式推理 (Case-Based Reasoning,CBR)

案例式推理主要是由過去發生類似的實例作為推理時的參考,去尋求解決問 題的依據,而使用案例式推理的前置條件是必頇收集與問題有關的案例並集合 成一案例庫,這樣才能解決發生特殊事件發生時案例式推理能從案例庫中找到相

(19)

似的案例並加以修正,成為解決問題的方法[1][5]。而許多學者也認為案例式推 理會包含下列四種循環過程:

1. 檢索(Retrieve):從案例庫找出最相似的個案。

2. 再利用(Reuse):利用案例的經驗和方法,去解決新的問題。

3. 修改(Revise):檢索最相似的個案,修改所提供的解決方法。

4. 回存(Retain): 將新的解決方案儲存案例庫,以供將來再使用。

在許多的案例式推論系統的推理流程會包含下列 9 個步驟:

1. 案例蒐集

2. 建立案例資料庫 3. 決定案例索引方式 4. 案例擷取

5. 問題描述 6. 定義相似性 7. 案例比對 8. 案例修正 9. 案例測詴

每種推理技術都有個別的優缺點和應用的領域如表 2-3,我們選擇使用規則 邏輯的與案例式推理技術來實作我們的系統,原因是希望在行動裝置上能將運算 的時間與消耗的資源縮短到最小,讓使用者可以即時的得到結果而不會因為時間 問題而導致結果與當時情境有所落差。

(20)

2.3 個人化技術

個人化技術在情境感知系統中扮演不可或缺的角色,在相同的情境環境之下 所需求的服務或是資訊會隨著不同的使用者而有所不同,因此要如何設計一個以 使用者為中心並且依照使用者不同的喜好推理出所需要的服務與資訊的系統是 非常重要的,同時這也是本篇論文所注重的重點。

在本篇論文中我們參考權重加權法與電子商務網站中具有代表性的用戶行 為模式與各項行為的喜好值程度,利用使用者個人的偏好、註冊的資訊以及使用 者的行為形成使用者喜好矩陣(User Preference Matrix,UPM),來記錄與追蹤每 位使用者對各種類型服務的喜好變化[4][7];我們以[4]中所提到的 UPM 範例為 大家講解,UPM 為 n t 的矩陣,n 為使用者編號,t 為商品編號,UPM 透過 使用者的行為來進行運作,使用者行為如表 2-54 所敘,以一個例子來說明 UPM 的運行,假設 UMP 的商品為”流行”、”財經”、”動漫”、”休閒”,且起始值都為 0,

透過表 2-5 所描述的動作我們可以得到使用者的興趣排序為:休閒 > 流行 > 動 漫 > 財經,如表 2-6。

表 2-4 使用者行為程度[4]

使用者行為 喜好值 行為描述

喜歡 +4 使用者指示出他喜歡的商品

購買 +3 使用者購買商品

查詢 +2 使用者查詢商品

瀏覽 +1 使用者瀏覽商品

無 +0 使用者沒有改變任何自己的喜好資

不喜歡 -4 使用者指示出他不喜歡的商品

(21)

表 2-5UPM 運作的範例[4]

使用者-1 UPM 運作

註冊

瀏覽財經類資訊 指示出不喜歡財經類 瀏覽動漫類資訊 查詢休閒類資訊 瀏覽流行類資訊 指示出喜好休閒類 瀏覽流行類資訊 購買流行類商品

並新增使用者-1 的喜好度欄位 W12 = W12 + 1 = 1

W12 = W12 - 4 = -3 W13 = W13 + 1 = 1 W14 = W14 + 2 = 2 W11 = W11 + 1 = 1 W14 = W14 + 4 = 6 W11 = W11 + 1 = 2 W11 = W11 + 3 = 5

表 2-6 UPM 結果[4]

項目(t) UID(n)

流行 財經 動漫 休閒

使用者-1 5 -3 1 6

使用者-2 4 0 13 5

使用者-3 3 11 0 8

(22)

第三章 系統架構與研究方法

在本章中,是本篇論文最主要的部分,將會說明在論文中所設計的系統細節,

包括了系統架構、系統流程、以及推理機制與個人化服務等等核心觀念,讓大家 能夠充分了解了本篇論文所提出的研究與方法。

3.1 系統設計簡介與分析

本篇論文主要研究的目標為,利用外在的情境資訊進行使用者行為推理,推 理系統方面我們以規則邏輯(Rule-logic)與案例式推理(Case-Based Reasoning)進 行推理,而推理結果配合上個人化技術與 UDDI 進而搜尋到最適合使用者情況與 喜好的服務[11][14][17],而使用者只需透過行動裝置就可以得到所需要的服務。

在此系統的建置上,JESS 為實作規則邏輯的推理機制並且定義了事實庫與規則 庫,UDDI 方面我們則是實際架設 Microsoft UDDI 當作我們的服務註冊中心,加 入我們的個人化系統 UMP 與 LVW 和利用排名機制形成服務搜尋模組,而案例 式推理則是利用相似案例提供與推薦使用者其他選擇,最後系統應用在課堂學習 中。

根據上面的系統設計簡介,以及第二章節的相關文件與技術後,大略可以分 析出我們的系統架構中需要那些重要的技術:

1. 知識架構技術:知識架構的主要目的在於能將某個領域概念化,用物體之間 的關係形成樹狀架構,因此知識架構可以獲取該領域的知識與資訊,我們利 用這一項特性去制訂課堂學習的相關規則去幫助我們的推理系統,使得推理 結果更加的快速與精確。

2. 情境推理技術:大量的資訊並不能描述出使用者和環境的情況,相反的太多 不必要的資訊還會造成不必要的負擔,但是我們可以用這一些大量的資訊配

(23)

合情境推理技術去得知現在的情境狀況,不但將資訊升級為知識,同時也可 以將不必要的資訊進行過濾。

3. 網路服務技術:我們利用網路服務的跨平台特性來解決在伺服端與使用端在 不同開發平台的問題,不但提供開發者更多的開發環境,而且達到服務重複 使用的概念。

4. 個人化技術:本系統是以使用者為中心進行運作與推理,因此如何提供使用 者所喜好的資訊、以及相關性的服務,就必頇透過一些機制或是技術來達到 每位使用者都擁有屬於自己合適的服務與資訊。

3.2 系統架構設計

在系統架構中,我們依據 3.1 節中分析所必頇具備技術,分別使用知識架構 技術、情境推理技術與網路服務技術等技術組成並協調,整體架構圖如圖 3-1。

從系統架構分析,我們將整體系統主要分成四個部分,分別是 JESS 推理系模組、

知識庫、服務選取模組和案例式推理模組,以下為系統運作的流程。

(24)

圖 3-1 系統架構圖

1. 系統透過智慧型行動裝置在外在環境中獲取大量的感應資料和個人資料與喜 好,例如:時間、地點、身高和體重等等,系統將這一些大量情境資源進行 整合並且傳送給 JESS 推理系統進行推理。

2. JESS 藉由與事實庫與規則庫進行匹配推理,將低階情境轉變成高階情境,而 推理系統可以將無關的資訊進行過濾過多的不相關的服務並且將資料轉化成 資訊再進一步的轉化成有用的知識。

3. 利用 JESS 推理系統進行服務選取的搜尋依據,並且將服務導向架構技術

(25)

(Service-Oriented-Architecture)加入至我們此模組中,讓使用者可以隨時隨地 的得到服務提供者所提供的服務,除此之外在服務選取模組中我們還加入了 個人化技術,利用服務回饋機制與調查去記錄與分析使用者的喜好並且以喜 好度的高低去排序相關服務排名,讓我們除了可以找到符合當時情況的資訊 也可以找到最適合使用者的個人服務。

4. 如果使用者在服務選取模組中沒有搜尋到想要或是不合適的服務,系統可以 藉由案例式推理找到其他使用者的所發生相關的案例並去加以修正,讓系統 可以提供使用者更多元和正確的服務。

5. 在案例式推理模組中,我們計算現在的情境資源跟情境儲存庫中所存放的案 例的相似度,利用相似度判斷是否有類似的案例,如果有類似案例的話進行 案例修正,如果此時的案例是沒有發生過而且在服務選取模組中並沒有找到 適合的服務,此時我們將會進行服務組合[13]的動作。但是現在服務組合還 是具有挑戰性的議題,因此在本系統的服務組合引擎以最基本與簡單的靜態 組合來構成,利用網路服務的 input 與 output 進行比對產生所需要的服務給使 用者。

6. 最後使用者使用完服務後,系統將會透過回饋機制來追蹤與記錄與使用者的 喜好與服務評價,一方面可以幫助服務選取模組進行個人化所需要的依據,

也可以幫助案例式推理模組。

(26)

3.3 JESS 推理模組

JESS (JAVA Expert System Shell)是由 JAVA 所開發並以規則為基礎的專家 系統,JESS 也擁有許多獨特的特性如支援正向和逆向推理,可以在系統運行環 境下直接使用 Java 的類別庫,使用 Java 中的各種資料結構和方法,因此採用 Jess 語言所開發的專家系統具有良好的移植性、嵌入性[16][18][22]。

專家系統是人工智慧研究中的一個分支,它運用 AI 的表達與推理方法,把 領域知識結合起來,以進行判斷,並下決策,是人工智慧用來解特殊領域問題的 產物,他必頇具備以下特性:

1. 知識庫(knowledge base)儲存專家用以解決問題的知識。

2. 推理機(inference mechanism)用以控制推理過程。

3. 使用者介面(user interface)乃是提供使用者友善的解釋說明及諮詢功能之 介面。

4. 知識擷取介面(knowledge acquisition interface)乃是提供編輯、增修知識 庫功能之介面。

5. 工作記憶區(working memory)儲存推理過程中之事實。

JESS 主要分為三個部分所組成分別為事實庫、規則庫與推理機,主要由推 理機中的 Rete 演算法去跟事實庫和規則庫進行推論,在演算法部分, Rete 擅常 快速的比對,在每次比對的循環當中,他只搜尋有變動過的地方,並非將每一筆 事實與每條法則做比對,靜態的資料因為沒有更改而被忽略,因此執行效率較高 但是相對的,他所佔用的資源也比其他專家系統較多,可以算是用空間換取時間 的演算法,簡單的說 Rete 演算法利用了專家系統中時間冗餘性和結構相似性這 兩種特點,大大的減少所需要的計算時間,JESS 整體的架構如圖 3-2。

(27)

圖 3-2 JESS 基礎架構

圖 3-3 知識架構

(28)

本篇論文是以課堂教學為範例,因此所要推理的事項與因素跟學生、老師和 教室有密切的關聯,因此我們利用知識架構的特性,將課堂學習這一塊領域概念 化,如圖 3-3 為知識架構圖,而藉由知識結構的建立,可以得知在學習領域中各 個物件的關聯與限制,因此可以依照這些的關聯去制訂推論的規則,如圖 3-4。

在 Jess 中,規則的表達形式沿用了 CLIPS 的語法結構,也提供了一些語法來 控制規則後果的操作流程,如使用 if...then...else 和 while...do...語句。JESS 是支 援前向與逆向推論,前向推論的原理跟 CLIPS 使相同的,逆向的推論中採用 if...than…else 的結構,而 JESS 規則的推論為以 if 前提 then 為結論的形式,當 if 成立時會執行 then 內容中的行為,在本篇論文中我們將規則以 XML 的方式存儲 在資料庫中如圖 3-5 進行存取。

圖 3-4 以 JESS 語法所制定規則 圖 3-5 規則以 XML 語法所描述

Example :

借由人物與地點去推論現在情況 ,若有學生在教室裡的體溫、收縮壓或舒張壓 超越一般人的範圍,我們可以推論這位學生的身體情況有問題,提供老師學生的 相關資訊與教室資訊,我們以 JESS 制定相關的規則如下。

(29)

(bind ?centigrade centigrade)

(deftemplate person_centigrade (slot centigrade)) (defrule find-sick-people

(person_centigrade (centigrade ?centigrade)) (test (or (< ?centigrade 36.3)( > ?centgrade 37.2)) =>

(assert (people sick) )

3.4 服務選取模組

服務選取模組主要目的是從 UDDI (2.1.5 節)眾多服務當中,依照需求選取出 一組合適的網路服務。而 UDDI 搜尋法就類似是關鍵字分類搜尋法,搜尋時需要 知道明確的服務名稱、分類並符合文法,而且只能簡單比對 WSDL 的規格,回 覆可能的服務,但是往往無法選出最適合的服務,所以在實用性上並不高,因此 有不少的研究在強化 UDDI 服務搜尋不足與選擇的正確性,因為在搜尋結果中,

通常只要服務者需求能夠與 WSDL 相符,服務就會被挑選出來,因此這樣可能 會造成搜尋結果有過多的情況發生,因此在服務選取模組中我們還加入了一些個 人化技術來幫助使用者過濾不必要的服務和能得到所使用者真正想要的服務。

3.4.1 Microsoft UDDI

在本篇論文中我們以 Microsoft UDDI 為服務選取模組中的主要開發工具,

他是由 Microsoft 所制定與發行;Microsoft UDDI 在 Microsoft Server 2003 中是屬 於選擇性元件[3],可提供企業內部或在生意夥伴間使用的 UDDI 功能[21]。

Microsoft UDDI 是標準型的 XML 網頁服務,可讓企業程式開發人員直接透過 其開發工具及商務應用程式來有效地公佈、發現、共用及重覆使用網頁服務,如

(30)

圖 3-6。

圖 3-6 Microsoft UDDI 2.0 介面

Microsoft UDDI Business Registry 主要提供了以下三種搜尋方式如圖 3-7,分 別為:

1. 以服務名稱(Service)

2. 以服務提供者名稱(Provider) 3. 以技術模型名稱(tModel)

圖 3-7 Microsoft UDDI 2.0 搜尋介面

(31)

在上述三種搜尋方法中,以服務名稱和服務提供者名稱搜尋方式是程式開發 者常用而且眾所皆知的搜尋方式,而什麼是以技術模型名稱來進行搜尋,技術模 型(tModel)是指描述技術細節的資料結構,其內容是 UDDI 核心資料框架較複雜 的一個結構,它有些類似詮釋資料(Metadata)的作用[2],由於取用一個網路服務 所需要的基本資訊,已經在 BindingTemplate 的結構中定義,但實務上僅知道網 路服務所在的位址是不夠的,此時還需要獲知一些夠具體的資料,例如:參數的 型態及順序、回應的格式、使用協定、採用的安全機制等等。換句話說,tModel 使得這一些描述細節就像是在資料庫中的一個 Table,功能則類似查詢一個字典 表 3.1 為 tModel 屬性。

表 3-1 tModel 屬性表 Name tModel 名稱(唯一且必要元素) Description 簡短的 tModel 用途描述。

OverviewDoc

用於容納與 tModel 元素互相關聯的遠端描述或使用說 明,是註冊的關鍵資料之一,其中包含一系列的 URL,

透過這些 URL 可以得到 tModel 的具體技術規範。

IdentifierBag 用於記錄 tModel 附屬識別字的名字及其對應值。

CatagoryBag 用於標記 tModel 的特定分類資訊的名稱及其對應值。

3.4.2 權重加權與排序模組

在權重加權與排序模組中,主要的目的就是對註冊中心中所選取的服務在跟 使用者所個別設置的喜好度進行排序,藉此選取符合需求與最合適使用者的服務 [9]。在此模組當中所需要的資料為使用者設定的需求,而使用者對服務的屬性 權重加權法公式 3.1 如下:

(32)

(3.1) :使用者對第 i 個服務的偏好

:使用者對第 j 個屬性的要求 :第 個服務的第 個屬性

我們將所選取的服務進行權重加權之後,利用所算出的值進行服務的排序選 取排名的服務,如此一來不但可以依照使用者的偏好與習慣更可以過濾大量的有 相關性但是卻不符合使者習慣的服務,大大的減少使用者考慮要使用哪一種服務 的時間。

在權重加權這部分我們透過使用者需求,使用者可自行決定各項服務功能屬 性的權重分數,利用內積公式,算出網路服務分數進行排序;我們所制定的權重 分別為 Microsoft UDDI 搜尋方法與 Web Service 所共有的屬性當作權重項目,如 服務名稱、服務敘述與服務數量等等,而權重分數為 1 到 10 由使用者自行決定,

系統會以權重最高的查詢法進行搜尋,之後再以學生對於網路服務的要求對網路 服務進行查詢是否符合使用者所需。

Example :

假設某一位學生對於 Microsoft UDDI 搜尋方法中偏好服務名稱查詢所設權重為 8、

服務提供者名稱權重為 6 和技術模型名稱權重為 5,而服務名稱查詢是三種方法 中權重最高,系統會以服務名稱查詢對 UDDI 進行查詢,對服務名稱權重 6 、 服務敘述 8 進行權重加權。

(33)

3.4.3 個人化喜好度 (User Preference Matrix)

然而只依靠權重加權法來進行個人化服務是不夠的,權重加權法是可以過濾 和與篩選使用者所需要的服務,但是卻不能確認使用者真正的認為權重加權法所 推薦的服務是屬於他們所想要且喜歡的服務。

因 此 在 本 篇 論 文 中 我 們 利 用 在 2.4 節 中 介 紹 的 使 用 者 喜 好 矩 陣 (User Preference Matrix,UPM),來記錄與追蹤每位使用者對各種類型服務的喜好變化,

並且參考在[19]中提出喜好度的權重參數,進行符合本模組個人化設計,由於喜 好度權重參數設定會影響 UPM 的準確性,因此在此部份我們採用 Large Variation Weight distribution without Dislike behavior (LVW)設定模組如表 3-2,LVW 是經 由 10 至 1000 人次、進行固定 100 次的商務網站訪查,以及固定 100 人次、進行 10 至 1000 次的商務網站訪查的 UPM 準確性,UPM 更可以達到接近 99%的超高 準確性,如圖 3-8。

表 3-2 LVW 權重量表[19]

使用者行為 LVW 權重值

Query and like +12

Purchase +9

Query and no change +6

Browse +3

Query and dislike 0

(34)

圖 3-8 LVW 與其他設定模組 UPM 精確度比對[19]

在此模組中我們將依據 UMP 與 LVW 的概念,透過使用者註冊會員之後與 進行系統操作時,所執行的查詢服務、是否使用服務、使用次數與使用者給予的 服務評分來追蹤行用者行為,設計一套使用者喜好公式,透過此方法可以自動收 集與判斷使用者的行為,並可以動態的調整使用者喜好的機制系統,喜好者公式 如(3.2),公式參數對照表如表 3-3。

= (12) ql + (9) qn + (6) p + (3) k (3.2)

表 3-三-3 UMP 參數表

意義 變數名

查詢並喜好 ql (Query and like) 查詢並無喜好 qn (Query and no change)

服務查詢次數 k

服務使用次數 P

服務喜好度

使用者 ID i

服務 ID j

(35)

Example :

若有使用者在本系統環境中與課程相關的網路服務留下的行為記錄為:『查詢有 關數學函式兩次並且給予不錯的評價,並且使用服務一次』,所以該使用者在課 程相關的網路服留下的喜好程度值計算為:

= (12)ql + (6)qn + (9)p + (3)k

= (12)2 + (6)0 + (9)1 + (3)2 = 24 + 0 + 9 + 6 = 39

3.5 案例式推理模組

案例式推理(Case-Base Reasoning,簡稱 CBR)主要是以先前的案例作為解決 日後問題的參考,其方法是先收集與問題有關的案例並集合成一案例庫,當要解 決特定問題時,從案例庫中挑選與問題類似的案例做為參考,並經過適當的修正 後,成為目前問題的解決方案[11][20]。

本篇論文加入 CBR 主要目的是當新的問題產生時,並不是由一條條的原理 及法則來解決問題,而通常是運用在過去的記憶中,曾經發生過的類似經驗來解 決類似的問題,利用過去相似問題個案累積的經驗中推導出相關知識,以重複應 用於新問題上,達到知識再利用的目的。而如何從案例庫中得到最類似的案例,

往往關係到之後的結果也是 CBR 重要關鍵之一,在本篇論文中我們採用了 Kwong、Smith 與 Lau 於 1997 提出之相似性演算法[5][8],在由相似性高的案例 中加以改善,並且排名,相似度演算法如下(3.3):

( )

| |

(3.3) n : 屬性個數

(36)

:各屬性權重

:輸入案例第 個屬性值

:案例庫中第 個案例中的第 個屬性

( ):輸入案例與案例庫第 個案例相似度

我們利用案例發生時,記錄使用者當時的情境資訊與教室環境當時的情境,

如地點、濕度與時間當作 CBR 的屬性,配合使用者設定屬性權重加以分析比較,

最後所分析的結果配合使用者的喜好度加以修改,如此一來系統不但可以透過相

關推理成功的案例,解決所面臨問題,也可以藉此改良解決問題的品質我們以當時 教室與學生的情況屬性如表和表3-4。

表 3-4 情境環境屬性

學生情境 屬性類別 教室情境 屬性類別

性別 Int 分貝 Float

所在地點 String 溫度 Float

分貝 String 濕度 Float

體溫 Float 光度 Int

心跳 Float

收縮壓 Int 舒張壓 Int

(37)

第四章 系統範例實作

在這一章中,我們將會利用在第三章裡所提供出來的概念,以課堂教學為 環境並且當作情境資訊範例,來實作出我們的系統。在 4.1 節中,我們說明系統 架構的設定環境,並且情境教學後端的相關網路服務給 API 端呼叫引用。在 4.2 並採用的課堂範例來實作為我們的系統情境主軸,設計各種項目、類型、喜好資 訊給學生查詢。在 4.3 節中我們會有系統的執行與結果畫面作展現。

4.1 系統開發環境

在本篇論文中,系統後端所使用的開發環境主要分為伺服端,使用端與網路 服務,整個系統以 Microsoft Visual Studio 2008 為伺服端與使用端的主要開發工 具,配合 Windows Mobile 6 進行模擬測詴,而網路服務開發平台則是不限任何 的開發工具,因此我們只列出我們開發網路服務的工具與使用語言,詳細的資料 如表 4-1~4-3。

表 4-1 伺服端開發環境

硬體

CPU Intel Xeon ,3.2GHz 主機板 Asus NCCH-DL 記憶體 4GB DDR

網路卡 Intel(R) PRO/1000 CT

軟體

作業系統 Windows Server 2003, Enterprise Edition

開發平台 Microsoft Visual Studio 2008 、NetBeans IDE6.1 開發程式語言 C#、VB、C++與 Java

UDDI Microsoft UDDI v2.0.2128.1 資料庫 Microsoft SQL Server 2005

(38)

表 4-2 客戶端開發環境

PC 硬體

CPU Intel Core2 Quad CPU 2.4GHz 記憶體 2GB - DDR 667

網路卡 Realtek Gigabit Ethernet

PC 軟體

作業系統 Windows 7 企業版

開發平台 Microsoft Visual Studio 2008 網頁開發 ASP.NET

開發程式語言 C#

PDA 軟體

作業系統 Windows Mobile 6 Professional 開發平台 Visual Studio 2008

開發語言 C#

表 4-3 網路服務開發環境

開發工具 使用語言

Microsoft Visual Studio 2008 C#、VB 與 C++

NetBeans IDE6.1 Java

我們利用 Windows Server 2003 R2 當作主要伺服端的開發環境,並且在此電 腦上建立 UDDI 與許多網路服務,而這一些網路服務使用不同語言所建構而成,

透過 IIS 6.0 來發佈網路服務,藉此來實驗網路服務的相容性與跨平台性;使用 端則是使用一般電腦所使用的作業系統 Window 7 為開發環境。

4.2 系統情境與功能

我們所設計的系統主要是應用在課堂教學的情境中,透過我們的系統,可以 讓使用者透過手持 PDA,得到符合當時情境的相關網路服務,而所搜尋到的網 路服務也會隨著使用者的不同做更動,其中情境資訊的項目也會在 4.2.1 小節詳 細說明。應另外在系統功能方面上,包括了各類型的服務、以及服務組合的應用,

都在 4.2 小節會加以細說。

(39)

4.2.1 課堂學習情境資訊

圖 4-1 情境資源

由於情境資源是大量且複雜如圖 4-1,如果一次把大量的資訊交給系統,不 但會造成系統必頇花費額外的時間處理,也會增加系統不必要的負擔,因此我們 將課堂教學情境主要分成三種情境,分別是教師情境資訊、學生情境資訊與教室 情境資訊,這三種情境資訊分別功能為:

1. 教師情境資訊:老師個人資訊、個人規定事項與擅長科目,老師具有權限查 看學生個人資訊與教室環境,並且可以依照情境的不同更動教室裡的電器設 定。

2. 學生情境資訊:學生的個人資訊、喜好興趣與個人設定,學生可以查看老師 所公布的資訊、老師交談與搜尋服務。

3. 教室情境資訊:教室裡電器設備的紀錄如溫度、濕度與分貝等等…。

(40)

我們利用這三種主要的情境資訊去建構我們的情境案例資料庫,紀錄老師或 學生在哪一種情況發生時去搜尋哪一些相關的服務,包含老師或學生的健康狀態、

個人資料與當時的教室情境資訊與所搜尋的網路服務資訊。

4.2.2 Web Service 分布與設計

在本篇論文中我們採用了服務導向架構,利用網路服務(Web Service)的跨平 台性讓使用者可以使用所需要的服務,服務提供者也可以在任何平台所撰寫的網 路服務都可以被使用者所搜尋與使用,在表 4-4 中我們列出本系統利用網路服務 重要的屬性與功能。

表 4-4 網路服務屬性表

屬性名稱 功能

ServiceKey

網路服務在 UDDI 具有一組服務金鑰,服務金鑰是唯一的並且用 於程式設計查詢。

BusinessKey

網路提供者所具有的提供者金鑰,提供者金鑰是唯一的並且用於 程式設計查詢。

TModelKey

所制定的技術模型所具有的金鑰,技術模型金鑰是唯一且用於程 式設計查詢。

AccessPoint

取存網路服務的路徑,其中 URL 類型可以為 http、https、ftp 等 等。

ServiceInfo 網路服務詳細資料提供了服務名稱及簡要說明。

由於本論文是應用在課堂教之中,所以我們在 Microsoft UDDI 中建立 70 個 網路服務進行搜尋,在這 70 個網路服務中我們設計不同方法與類型的服務,並 且加入有缺陷或不完整的網路服務,目的是用來確認我們的推理機制是否正確,

網路服務的性質與個數如表 4-5。

(41)

表 4-5 網路服務分類表

WS 數目 損壞數目 有敘述 無敘述 無技術模 型名稱

有重複名稱

課堂 24 1 22 2 5 有

生活 29 4 21 8 5 有

交通 9 2 8 1 5 有

健康 7 0 6 1 3 有

其他 1 0 0 0 0 無

總數 70 7 57 12 18

除了可以利用行動裝置進行存取網路服務,我們也額外架設網站,讓其他使 用者也可透過此網站得到網路服務,並且也可以讓服務提供者藉由此網站進行註 冊網路服務,如圖 4-2 與 4-3。

圖 4-2 UDDI 服務搜尋

(42)

圖 4-3 UDDI 服務註冊

4.2.3 系統功能

我們的系統功能上,包括有情境推理、資訊查詢、服務選取、個人化服務、

服務組合、意見回饋、等服務功能,這些功能本身也就是 Web Service。藉由系 統提供的各項資訊服務介面讓使用者自行查詢、瀏覽、使用各類服務,系統也可 以根據所在使用者的所在情境、UPM 的喜好度,篩選出使用者可能需要且適合 的服務,我們分析本系統並且歸納出的以下三點主要功能:

1. 推理機制:系統可以利用 JESS 推理系統與案例式推理進行情境推理,JESS 推理系統可以將資料資訊化,將低階情境轉化成高階情境;案例式推理則是 可以利用情境案例資料庫裡其他案例進行推理與學習,利用這兩種不同的推 理系統來幫助我們過濾和搜尋所需要的服務。

2. 服務選取:得知使用者所在的情境,但是要如何取得服務,我們利用服務導 向架構與網路服務去實現此功能,讓使用者可以隨時隨地的搜尋與取得所要 的服務。

3. 個人化系統 :利用使用者的個人設定與使用者喜好矩陣 (User Preference Matrix,UPM)組成個人化系統,讓不同的使用者都可以獲得符合自己喜好的 服務與資訊。

(43)

4.2.4 實驗步驟與流程

用戶在開始使用本系統時必頇先登入本系統,或者進行第一次登入的註冊服 務,此服務將會新建此用戶的個人資料與偏好設定,在這我們的登入身分有分為 老師與學生差別在 4.2.1 中有作敘述。學生進入至系統主頁面後,用戶將可以自 行選擇各種所需的服務與更改個人設定,同時學生登入系統後 JESS 推理模組就 會開始進行運作,並且隨時隨地的監控使用者狀況;在服務選取方面使用者有三 種選擇,直接搜尋、個人化搜尋與案例式自動搜尋服務,學生使用過服務後進入 回饋模組之中,如圖 4-4。

圖 4-4 系統實驗流程圖-學生

(44)

在老師部分,首先老師也是必頇先登入系統,系統會產生主要頁面給老師 , 同時系統也啟動 JESS 推理模組,跟學生不同的部分是,學生只能自我監測,但 是老師可以監測全班同學的情況,還有一部分是老師可以對教室環境進行監控,

並且更改教室內的器材設定,例如:JESS 推理模組偵測到有一位學生身體不適,

同時也偵測到教室的溫度過低,系統傳送現在教室與學生的情況給老師,老師可 以藉由系統回傳的情況,對教室的溫度作調整,如圖 4-5。

圖 4-5 系統實驗流程圖-老師

(45)

4.3 實驗執行與成果

本節將會利用圖案方式,展現出我們的實驗以及實作的結果畫面,分成使用 者的使用介面,以及展現個人化的服務,及老師特有服務功能介紹、介面語言等 等。

, 圖 4-四-6 系統登入畫面、老師與學生主畫面

圖 4-6 為系統的主要登入頁面,圖左的功能為讓使用者登入並且判斷使用者 登入身分;圖中為老師登入介面,主要進行對學生與教室情境的監測與搜尋網路 服務;圖右為學生登入介面,學生可以進行教室環境查尋、自我健康檢測與搜尋 網路服務。

老師與學生介面的最大差別在於,我們設定老師帳號可以觀看學生的個人資 訊,所以在老師介面中可以查詢全部學生資訊(如圖 4-7)或是單一查詢學生個人 詳細資訊(如圖 4-8)。

(46)

圖 4-7 學生資訊介面 圖 4-8 學生詳細資訊

老師與學生也可以對教室情境進行查詢,查詢介面如圖 4-9,查詢結果如 圖 4-10 所示。

圖 4-9 教室情境介面 圖 4-10 虛擬教室情境資訊

(47)

圖 4-11 與圖 4-12 為個人化設定介面,在此我們個人化設定為使用者偏好哪 一種查詢方法與服務的要求,如服務有無敘述、提供者與技術模型擁有服務數量 等等…。

圖 4-11 個人化選項 圖 4-12 更新個人化設定

圖 4-13 服務名稱查詢介面 1 圖 4-14 服務名稱查詢介面 2

(48)

在本系統中我們將 Microsoft UDDI 加入到行動裝置中如圖 4-13~圖 4-18,讓 使用者可以進行網路服務查詢的功能。

圖 4-15 服務提供者查詢介面 1 圖 4-16 服務提供者查詢介面 2

圖 4-17 技術模型名稱介面 1 圖 4-18 技術模型名稱介面 2

(49)

在本系統中我們也加入個人化系統,系統藉由使用者的設定與 UPM 的行為 追蹤(3.3.3 節)並且加以排序如圖 4-19~圖 4-20。

圖 4-19 UPM 查詢介面 1 圖 4-20 UPM 查詢介面 2

當老師登入系統後,系統會自動監測學生或老師情況並且給予適合的服務。

圖 4-21 顯示事件發生 圖 4-22 系統提供服務選項

(50)

在本系統中我們將許多現有的網路服務與自己所撰寫的網路服務註冊在我 們所建置的 UDDI 中,提供使用者搜尋與使用如圖 4-23~4-25,最後使用者透過 圖 4-26 的回饋介面來提供意見與服務評價。

圖 4-23 網路服務 1 圖 4-24 網路服務 2

圖 4-25 網路服務 3 圖 4-26 回饋機制介面

(51)

第五章 系統實驗與分析

在本章節裡,我們將會比較本系統所提出的以 Web Service 為服務的系統架 構,利用本論文中所採用 Microsoft UDDI 搜尋服務時所產生的精確度(Precision) 與召回率(Recall)為對照組,去探討情境推理與個人化喜好度推理服務系統及其 它個人化的機制,分析對使用者是否會有明顯的影響。在 5.1 節中將會根據使用 者實際操作系統服務所產生的結果計算產生的精確度與召回率。在 5.2 節分析與 討論中,我們將討論使用者操作系統服務的實驗結果,並分析優缺點為何。最後 在 5.3 節將會分析採用 Web Service 架構系統的執行效能優點。

5.1 精確度與召回率分析比較

我們利用檢索系統中常見的精確度與召回率去衡量本系統搜尋網路服務的 好壞並進行比較,好的檢索系統所搜尋到的相關文件資料越多越好,不相關文件 資料則是越少越好,精確度和召回率是衡量資訊檢索系統性能最重要的參數,精 確度與召回率的定義如圖 5-1:

圖 5-1 精確度與召回率定義

(52)

精確度(Precision):用檢索到相關文件檔數作為分子,所有檢索到的文件資 料總數作為分母。

召回率(Recall):用檢索到相關文件檔數作為分子,所有相關文件資料總數作 為分母。

我們以 Microsoft UDDI 所提供的三種搜尋服務方法(3.3.1 節)所得到的精確 度與召回率為實驗對照組,來驗證本篇論文所提出的方法。對照組數據產生方法 經由 20 位同學進行測驗,再使用者使用系統之前,使用者可以先選擇自己所處 於的情境資訊,我們提供的情境有學生情境與教室情境;學生情境共有 6 種情況 分別為無聊、吵鬧、平靜、睡覺、室外與隨機,提供使用者選擇;教室情境分別 有吵鬧、平靜、炎熱、寒冷與隨機讓使用者選擇,經由所選擇的情境環境作為實 驗時的所模擬的情境狀況,在實驗時我們記錄使用者所查詢的資訊並確認使用者 所需的服務為何在計算出當時的精確度與召回率。

在對照組的測驗中並無包含個人化技術與推理技術輔助進行服務的搜尋,單 純讓使用者對 Microsoft UDDI 進行查詢,測驗結果如表 5-1,另一方面在比較組 中我們加入個人化與使用案例式推理加入至 UDDI三種搜尋方法之中進行測驗,

在此測驗中,再以 20 位同學進行測驗,測驗結果如表 5-2;在實驗結果中我們分 統計在實驗對照組與測詴組對課堂服務、生活服務、交通服務與健康服務(分類 與數量如表 4-5)的精確度與召回率,各種方法的精確度與召回率直方圖如圖 5-2 與圖 5-3。

表 5-1 UDDI 測驗結果

Services Search Provider Search tModel Search Domain Precision Recall Precision Recall Precision Recall

Class 0.7658 0.6131 0.1768 0.4818 0.3333 0.6843 Life 0.3667 0.2714 0.2770 0.2964 0.3571 0.5117 Traffic 0.8 0.5 0.1400 0.3334 0.8 0.4445 Health 1 0.5714 0.0856 0.3 1 0.5714 Average 0.7331 0.4890 0.1699 0.3529 0.6226 0.5530

(53)

表 5-2 UPM 與 CBR 加入 UDDI 測驗結果

Service Search Provider Search tModel Search Domain Precision Recall Precision Recall Precision Recall

Class 0.8491 0.6131 0.206 0.504 0.3333 0.7516 Life 0.467 0.2714 0.4286 0.32 0.4283 0.6118 Traffic 1 0.625 0.1916 0.3705 1 0.4445 Health 1 0.5714 0.1625 0.3968 1 0.5714 Average 0.8290 0.5202 0.2471 0.3978 0.6904 0.5948

圖 5-2 各種搜尋方法精確度比較圖

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Services

Services+UPM+CBR Provider

Provider+UPM+CBR Tmodel

TModel+UPM+CBR

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Services

Services+UPM+CBR Provider

Provider+UPM+CBR Tmodel

Tmodel+UPM+CBR

(54)

圖 5-五-3 各種搜尋方法召回率比較圖

5.2 實驗結果分析與探討

在 5.1 節中我們統計了 Microsoft UDDI 三種搜尋方法與加入 UPM 與 CBR 的精確度與召回率,接下來我們將個別分析加入 UPM 與 CBR 跟原本搜尋方法 的差異性。

圖 5-4 服務名稱查詢精確度

圖 5-5 服務提供者名稱查詢精確度

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Services

Services + UPM+CBR

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Provider

Provider+UPM+CBR

(55)

圖 5-6 技術模型名稱精確度

圖 5-4、圖 5-5 與圖 5-6 分別代表以三種服務查詢方法的精確度比較圖,在 圖 5-4 中我們可以發現服務名稱查詢原本精確度平均有 70%以上的準確度,原因 是使用者使相關的關鍵字,所查詢的服務大都是具有相關性,因此服務名稱查詢 是三種搜尋方法中精確度最高的;在服務提供者名稱查詢方面,我們一共設計 5 個服務提供者,而不同的提供者所提供的服務都不盡相同,有些提供者提供很多 與多元的服務,但是有些提供者卻只提供單一領域的服務,如 E113_RedMoom 專門提供書局方面服務,而 CHU_E113 卻是各種領域服務都有提供,因此只要 是使用者不是選擇特定的服務提供者名稱所提供的服務,搜尋服務精確度是不理 想的;在技術模型方面,我們主要定義 4 種技術模型提供查詢,有些技術模型的 定義是比較廣泛,使用者可能看到只是知道大概的服務類型,但是有些定義是比 較狹小且精確讓使用者一看到技術模型的名稱就清楚知道裡面網路服務大約是 哪一種並且知道是不是自己所想要的,因此在圖 5-6 中我們可以看到技術模型有 些精確度很高但是有些卻也有不理想的數據;但是在原本的 Microsoft UDDI 服 務查詢方法中是沒有過濾是否可以正常連接網路服務的機制,在本系統中我們強 制將使用者設定為只要連接服務失敗或者是跟使用者所設定的偏好權重相差太 大就不提供給使用者,因此我們可以過濾不必要的服務,將搜尋服務數量減少但 是相關的服務卻還會保留,提升各種搜尋服務精確度。

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Tmodel

Tmodel+UPM+CBR

(56)

在召回率方面,影響各種搜尋方法的因素與精確度類似,而我們提升召回率 的方法為利用案例式推理來得到相似的服務,這一些服務可能是相同性質但是服 務名稱卻不盡相同,或是在相關服務在不同的服務提供者中,或是沒有註冊到技 術模組的相關服務,經由不同的使用者在相同的情境但是在不同搜尋方式下所選 取的服務形成新的情境案例,系統藉由這一些案例推薦相似服務給使用者,藉此 提升搜尋服務召回率,如圖 5-7、圖 5-8 與圖 5-9。

圖 5-7 服務名稱查詢召回率

圖 5-8 服務提供者名稱查詢召回率

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Services

Services+UPM+CBR

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Provider

Provider+UPM+CBR

(57)

圖 5-9 技術模型名稱召回率

5.3 整體系統架構比較

本系統使用服務導向架構,由系統實作的網路服務部分由 C#、VB、JAVA 三種程式語言所撰寫,這也就明確的說明本系統架構是具有跨平台的特性,不論 對未來新平台或新語言、及現有舊系統的服務也都能夠繼續沿用我們在 Microsoft UDDI 所註冊的網路服務,展現了高度的可擴展性;由於本系統架構是由許多的 Web Service 組合成,透過遠端的網路服務執行複雜或大量的計算工作,所以在 系統整體的反應時間上也會有比較快的回應,而 Client 端的裝置也不需要有較高 等級的硬體設備,並且可以降低客戶端系統大量運算時的電源消耗,而 Web Service 也提升了程式的重複使用性,不管對客戶端、服務端,還是開發人員都 是有利的。而本系統也具有推理機制可以隨時監控學生學習情況並且有效減少不 必要的服務,而且具備個人化的功能讓每位使用者都可以得到自己所想要的服務。

表 5-3 為本系統程式特點整理。

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Class Life Traffic Health

Tmodel

Tmodel+UPM+CBR

(58)

表 5-3 系統程式特點表

本系統程式

傳統系統程式 (不具 Web Service 以及

SOA 架構)

跨平台性 有 無

客製化 容易 複雜

可擴展性 高 低

功能選擇性 有 較少

應用程式大小 小 大

程式重複利用性 高 低

推理功能 有 較少

(59)

第六章 結論與未來展望

在本論文中提出適用於服務導向架構的情境推理系統,其最主要目的是利用 推理機制及服務導向架構建構出一套推理機制結合 Web Service 的模型,藉由此 模型可以協助人們在各種情境下提供用戶當下所需要的服務以及資訊。而在系統 範例實作中也以課堂教學作為情境劇本,建構出一套具有情境感知的系統服務,

系統藉由 JESS 推理模組監控使用者狀況,使用者也可以透過服務導向架構取得 網路服務並且系統針對使用者查詢、選取網路服務系統加入個人喜好度機制,而 實驗數據也證實擁有個人喜好度資訊有助於使用者在使用情境服務時的效果,並 且能夠依據用戶的行為動態修正用戶的喜好度,而本論文另一目標就是以 Web Service 來建構出本情境推理系統,也由實驗結果證實 Web Service 跨平台特性可 以幫助客戶端的負載、減少程式開發、維護人員的負擔等。

在未來中,我們將加入不同的推理方式如: 模糊理論、類神經網路等方法以 應變不同的情況,可以使推理系統可以更加強大與精確與快速,讓系統不只只有 當事件發生後才可以偵測事件的發生而是具備預測事件發生的功能;在服務選取 模組方面將加入服務組合與管理部分,讓使用者可以充分利用網路服務,在服務 組合方面達到半自動化或更進一步的自動化組合服務讓使用者可以獲得更多、功 能更強、更多元的網路服務,最後在未來中會加入更加精確的回饋機制。

(60)

參考文獻

[1] 余家祥 (2001),以案例式推理建構建築工程成本估算系統,國立中央大學 土木工程學系研究所營建管理組

[2] 林傑斌、林清源、張太平 (2009),SOA 服務導向架構原理/方法/實務,文魁 [3] 施威銘研究室 (2006),Microsoft Windows Server 2003 R2 架站實務,旗標 [4] 許世宗、張欽智 (2009),利用情境擷取及情境感知網路服務的智能購物環

境,資訊與管理應用研討會,元培科技大學

[5] 郭天耀 (2000),以案例式推理作生產力診斷,國立成功大學工業管理研究 所碩士論文

[6] 陳晏晟、張欽智 (2008),利用分群機制在點對點的網路上共享行動網路服 務,International Conference on Digital Content, Chungli Taiwan

[7] 黃國豪、葉書桓 (2001),電子商務網站中具時間效應之消費者喜好相似度 模型,第一屆製商整合研討會

[8] 董其鈞 (2000),案例式推理應用於營建工程爭議調解之研究,國立交通大 學土木工程學系研究所營建管理組碩士論文

[9] 蔡文偉、張欽智 (2008),使用者為中心的適性化網路服務選擇機制,第二 屆資訊科技學術與應用研討會

[10] Po-Hao Chang, Gul Agha (2007), Towards Context-Aware Web Applications, DAIS 2007, LNCS 4531, pp. 239–252

[11] David W. Aha (1998), The Omnipresence of Case-Based Reasoning In Science And Application, Knowledge-Based Systems, pp.261-273

[12] Eunhoe Kim, Jaeyoung Choi (2007), A Context-Awareness Middleware Based on Service-Oriented Architecture, UIC 2007, LNCS 4611, pp. 953–962

[13] Choonhwa Lee, Sunghoon Ko, Seungjae Lee, Wonjun Lee, and Sumi Helal (2007), Context-Aware Service Composition for Mobile Network Environments, UIC 2007, LNCS 4611, pp. 941–952

[14] Donghai Guan, Weiwei Yuan, Seong Jin Cho, Andrey Gavrilov, Young-Koo Lee

參考文獻

相關文件

本刊“98 年第 3 季(7~9 月)就業服務統計資訊"主要資料來源為「行政院

本刊“99年第3季(7~9月)就業服務統計資訊"主要資料來源為「行政院勞

1-1-2 結合外 展、據點人 力,強化機動 性、便利性服 務優勢,提供 各項在地求職 求才服務。..

2006 年第三季本 澳經濟錄得 11.4%的實質 增長及 17.1%的名義增長,主 要是由私 人投資及服務出口所 帶動。外地需求方面,博彩服務出口仍錄得不

學校危機處理小組的事前準備 附件 1:支援服務機構電話一覽表 附件

本彙集輯錄了多篇學校經驗分享的文章,闡述「管理與組織」範疇的各項全校 參與訓育及輔導工作模式的重點,請參閱教統局網頁,索引: 本局向學生及家 長提供的服務 &gt;

已參加政府主辦或委辦之 教保員、訓練員、生活服務 員、照顧服務員、家庭托顧 服務員、臨時及短期照顧服 務員或個人助理相關訓練

專業選修 至少應選修28學分(含模組選修10學分) 模組類別 社會照顧服務、兒少與家庭社會工作 自由學分