中 華 大 學

中 華 大 學

碩 士 論 文

題目：以Petri Net設計及實作強化語意 的互動式查詢介面

系 所 別：資訊工程學系碩士班 學號姓名：M09502043 陳思君 指導教授：張欽智 博士

中華民國 九十七 年 七 月

摘要

隨著網際網路的蓬勃發展，使用者除了在網路上搜尋網頁外，也希望能在網路上搜尋應 用程式，目前越來越多的應用程式以網路服務(Web Services)方式呈現。傳統的網頁查詢介面 主要用於搜尋無結構性的網頁資料，對於在一般網路服務(Web Services)架構中，所使用以 XML 為基礎的半結構性(Semi-structured)資料，僅能透過服務的功能描述(WSDL)及搜尋註冊 中心(UDDI)，以發現所需的網路服務，並無法有效運用半結構性資料特性以利搜尋。為了讓 使用者能透過語意(Semantic)的描述找到所需的服務，以 XML 為基礎的語意描述語言蘊應而 生 ， 語 意 與 網 路 服 務 結 合 產 生 語 意 網 路 服 務 (Semantic Web Services) ， 雖 然 目 前 已 有 OWL-S(Web Ontology Language for Services)及 WSMO(Web Service Modeling Ontology)等標準 技術，用以建立網路服務所需的語意，進而找到使用者所需的網路服務(Web Services) 。但一 般來說這些技術有其複雜度，在實作上有其限制，因此我們希望透過語意的研究，建構一互 動式的查詢介面，以利服務及一般網頁資料的搜尋。

在本篇論文中，我們提出了一種解決方案。透過使用者在網頁中互動的方式，分析使用 者的需求，利用 Petri Net 的技術，動態產生查詢介面，進而有效率找所需的服務及網頁。我 們並以旅遊搜尋為範例，建立系統，來驗證我們提出的方法。我們並希望透過此互動式介面，

結合本體論(Ontology)及邏輯學(Logics)去分析，將語意轉化成如 OWL-S 和 WSMO 等標準語 意格式，以利語意網路服務的自動搜尋及組合。

關鍵詞：Petri Net、語意網路服務、服務導向架構、搜尋介面

Abstract

With the popularity of the Internet, users would lie to find not only Web pages but also applications on the Internet. Currently, more and more applications are wrapped as Web services.

Traditional Web query interfaces are mainly used for searching unstructured Web pages. For those XML-based semi-structured data used in Web services the requested Web services can only searched with the help of functional descriptions – WSDL and service registry – UDDI without using the features of semi-structured data. In order to let a user find the services through semantics semantic languages based on XML have been developed. The combination of semantics and Web services produces semantic Web services. Though currently there are standard technologies such as OWL-S (Web Ontology Language for Services) and WSMO (Web Service Modeling Ontology) which can be used to build the semantics of a Web service and help the user to find the requested services. But generally speaking these technologies have its complexity and practical constraints.

Hence, we hope to construct interactive query interfaces to facilitate discovery of Web services and pages.

In this paper we present a solution. Through the interaction between a user and Web pages user’s requirements are analyzed and dynamic query interfaces are generated to help discover Web services and pages using Petri Net technology. We use travel planning as an example to build the system and verify our idea. We expect through these interactive query interfaces we can integrate ontology and logics so that we can analyze user’s semantics and convert it to standard semantic languages such as OWL-S and WSMO which are expected to facilitate automatic discovery and composition of semantic Web services.

Keyword: Petri Net、SWS (Semantic Web Services)、SOA (Service Oriented Architecture)、Query

致謝

本論文能夠順利完成，我必頇好好感謝我的指導教授 張欽智教授。他真的是一位很照顧 學生的老師，不管是從以前大學部到現在，都發現老師都很熱心的處理學生的事務。當然我 們有論文上有問題時，都可以給予我們正確的方向去往前走。而如果很不幸的我們真的找不 到正確答案，老師就會及時就會跳出幫忙我們找到正確的答案。這對我們是很溫暖的感覺，

所以真的很感謝老師對我們的照顧。

此外在就學期間，我也必頇好好感謝同實驗室的同學們，有你們才會讓我研究所生活多 采多姿，不管是在課業及生活上，都能互相照應。尤其是文偉和晏晨，雖然在大學部就知道 你們了，但因生活圈不同，所以無法熟識。但在研究所認識後，發現你們真的是寶一對，你 們知道的，哈哈… 希望能一直保持很好的連絡，也願畢業後都有不錯的前途。

接著我要感謝的是我爸媽，因為他們必頇承擔家中所有經濟來源，真的非常辛苦。身為 兒子的我，由衷的感謝他們不辭辛勞的培養我，不讓我有經濟上的困擾。最後也要感謝陪我 走過這段時間，鼓勵我的所有的朋友們。

思君 2008 年 7 月

目錄

摘要...Ⅰ

Abstract...Ⅱ

致謝...Ⅲ 目錄...Ⅳ 圖目錄...Ⅵ 表目錄...Ⅷ

第一章、緒論...1

1.1 研究背景...1

1.2 研究動機...2

1.3 研究目的...8

1.4 研究架構...8

第二章、相關研究與技術...10

2.1 服務為導向的架構... 10

2.2 OWL-S...12

2.3 WSMO...13

2.4 派翠網路模型...14

2.4.1 Petri Net 起源及介紹...14

2.4.2 Petri Net 定義、符號以及基本作方式...14

2.4.3 Petri Net 屬性...18

2.5 相關研究討論...19

第三章、 Petri Net 分析語意之探討...21

3.1 語意分析方法之設計理念...21

3.2 語意分析方法...23

3.2.1 定義流程控制相關動作...23

3.2.2 設定開始及結束動作...25

3.2.3 觸發流程控制的動作方式...25

3.2.4 語意擷取流程...27

3.3 語意分析模組...27

3.3.1 循序式模組...27

3.3.2 選擇式模組...28

3.3.3 回復式模組...28

3.3.4 平行式模組...29

3.4 語意分析架構驗證...30

3.4.1 產生語意分析架構...30

3.4.2 使用矩陣方程式檢查可達性...31

3.4.3 使用遞移矩陣檢查活性...34

第四章、語意分析系統之建立...36

4.1 開發軟體...36

4.2 系統架構...37

4.3 系統建構...39

4.3.1 系統內網路服務建置...39

4.3.2 資料庫設計...44

4.3.3 網頁呈現設計...45

第五章、實驗與評估...46

5.1 實驗環境...46

5.2 實驗方式...46

5.2.1 語意架構建立...47

5.2.2 實驗描述...50

5.3 實驗結果...50

第六章、結論及未來工作...53

參考文獻...54

圖目錄

圖 1.1 Google 入口網站畫面...3

圖 1.2 Yahoo 拍賣分類式搜尋...5

圖 1.3 Google 進階搜尋...6

圖 1.4 易遊網 旅遊搜尋網頁...6

圖 2.1 SOA 架構...11

圖 2.2 Petri Net 組成元素及基本架構...15

圖 2.3 Petri Net 標記轉移圖...17

圖 3.1 多個網頁連結分析語意...22

圖 3.2 語意分析系統架構設計理念...22

圖 3.3 代表 Places 之問題集合示意圖...23

圖 3.4 Transitions 代表之意義...24

圖 3.5 分歧點動作按鈕...26

圖 3.6 填寫完成動作...26

圖 3.7 循序式模組(Sequence model) ...27

圖 3.8 選擇式模組(Choice model) ...28

圖 3.9 重複式模組(Repeat model) ...29

圖 3.10 平行式模組(Parallel model) ...29

圖 3.11 語意架構轉換例子...31

圖 4.1 語意分析系統架構...38

圖 4.2 各個流程初始化 Web Services 設計流程...40

圖 4.3 問題產生 Web Service 建立流程...42

圖 4.4 處理產生 Web Service 建立流程...43

圖 4.5 資料庫中資料表列...44

圖 4.6 網頁呈現設計流程...45

圖 5.1 實驗之一般問卷 解析語意...48

圖 5.2 利用資料庫支援的問卷...48 圖 5.3 實驗之語意流程架構...49 圖 5.4 不同需求間 問卷選項數量分佈圖...51

表目錄

表 2.1 SOA 架構下服務產生動作描述...12

表 2.2 Petri Net 的 Places 和 Transitions 可代表的意義...14

表 2.3 Petri Net 標記轉移範例之元素集合...16

表 2.4 Petri Net 標記轉移步驟...16

表 3.1 語意流程架構所有路徑...32

表 3.2 D⁺系統輸出矩陣...32

表 3.3 D^-系統輸出矩陣...33

表 3.4 D 系統矩陣...33

表 3.5 遞移矩陣之(LDP)^*矩陣...34

表 5.1 系統實驗環境...46

表 5.2 不同問卷間的多樣性結果...50

第一章、緒論

隨著網際網路的蓬勃發展，使用者除了在網路上搜尋網頁外，也希望能在網路上搜尋應 用程式，目前越來越多的應用程式以網路服務(Web Services)方式呈現。傳統的網頁查詢介面 主要用於搜尋無結構性的網頁資料，隨著 XML 及網路服務(Web Services)的流行，以 XML 為 基礎的半結構性的資料，更廣泛地分佈於網際網路上，傳統的網頁查詢介面未能利用 XML 的特性，做有效地搜尋。針對在服務導向架構(SOA，Service Oriented Architecture) 下，如何 有效利用網路服務的功能或語意的描述，搜尋到符合使用者需求的服務，是一個需要解決的 問題。在這過程中，系統該如何瞭解使用者的語意，是影響找出什麼樣的服務的主因。也可 以這樣說，如果系統能瞭解使用者真正想要什麼樣的服務，就能有效找到所需的服務及網頁。

雖然要推論使用者的語意是很困難的，但語意是一切的開始，我們必頇有系統的分析它。本 論文提出一套互動式的查詢介面，有系統的語意分析方案，可以建立各種語意分析流程，提 供語意分析者一種比較靈活且比較清晰明瞭的建立方法，以利服務及網頁的搜尋。

本章分為四小節：1.1 研究背景：此節我們將探討傳統的搜尋介面與網路服務搜尋的差異 性，並且點出語意的重要性。1.2 研究動機：此節討論傳統的網頁搜尋及網路服務搜尋，利用 語意分析的可行性。1.3 研究目的：此節我們將針對傳統的網頁搜尋介面的缺點，設計出一種 流程控制語意分析的方法，並建置具有語意內涵的動態式介面。1.4 研究流程：描述本論文接 下來進行的各階段研究。

1.1 研究背景

現今的網際網路蓬勃發展，傳統的搜尋介面主要用於搜尋無結構的網頁資料，但使用者 除了在網路上搜尋資料外，也希望能在網路上搜尋應用程式；網路服務(Web Services)是一種 整合跨平台應用程式的技術，利用以 XML 為基礎的網路服務描述語言(WSDL，Web Service Description Language)可以將分散在不同平台上的應用程式包裝成服務，以方便使用者存取他 們所需的服務[6]。然而面對網路上的服務，該如何找到使用者真正所需的服務，並且將這些

服務分配給使用者其實是很困難的[12]。透過 WSDL 所描述的服務功能，使用者僅透過服務 的功能描述及搜尋註冊中心(UDDI，Universal Description, Discovery and Integration)，以發現 所需的網路服務，為了讓使用者能透過語意(semantic)的描述找到所需的服務，語意網路服務 (Semantic Web Services)的應然而生。而要實現動態(dynamic)及無接縫整合(seamless integration) 的語意網路服務，必頇開發可以理解語意標記(semantic markup)的架構。在這架構下可透過這 些語意標記自動化地發現(discovering)服務、執行(executing)服務、組成(composing)服務和相 互運用(interoperating)服務。

雖 然 目 前 已 有 OWL-S(Web Ontology Language for Services) 及 WSMO(Web Service Modeling Ontology)等標準技術，用以建立網路服務所需的語意，進而找到使用者所需的網路 服務(Web Services) ，但一般來說這些技術有其複雜度，在實作上有其限制。這種架構通常會 將語意整合在服務註冊機制(UDDI)上，但要實作完成這樣的架構，往往是相當複雜的，因為 語意的取得本來就是一個複雜問題。

1.2 研究動機

本節我們將針對不同資料的搜尋方式進行討論，找出較符合一般化的搜尋方式並且分析 其優缺點進行改進。待日後結合Ontology概念的標準文件，發展出語意解析的效果。目前一 般資料，我們大致上可分為三種：無結構性、半結構性、及結構性的資料。

(一) 無結構性資料

無結構性資料的特性為，資料間沒有關連性來表示資料間的關係。如一般的文件、影音、

網頁等，而如想要搜尋無結構性資料，就必頇透過搜尋全部的資料的方式來找尋符合的資料。

但是網際網路上存在著太多的資料，不可能完全被搜尋出來，所以入口網站背後的資料庫及 演算法強度就占了很大的影響力。接著，我們就針對目前無結構性資料的搜尋發式進行分析，

在我們分析整理後，我們大致上可分為三種：[21]

(1)關鍵字搜尋方式

利用關鍵字來作語意分析，最典型的例子為入口網站的搜尋方式。如圖 1.1 為 Google 入 口網站的搜尋網頁，使用者想找到他需求的網頁就必頇在輸入框框內鍵入相關的關鍵字去搜 尋。如使用者想要找電影「赤壁」的相關網頁，那麼使用者可以在輸入框鍵入「赤壁」去做 搜尋。但 Google 的搜尋結果，可能會包含了很多有關赤壁的網頁，其中當然包含了使用者想 要瀏覽的電影「赤壁」、三國演義的赤壁之戰，以及各種有跟赤壁扯上關係的網頁。這就會讓 使用者需花很多時間挑出他想瀏覽的網頁，而導致這原因當然是系統不了解使用者真正的需 求是什麼，所以就將只要相關的網頁就回傳給使用者。

圖 1.1 Google 入口網站畫面

 鍵入多個關鍵字：

在例子中，使用者的需求為吳孙森導演所導的電影「赤壁」，使用者可以將吳孙森、

電影及赤壁的關鍵字，全部鍵入到輸入框內，以增加搜尋結果符合的條件，相信搜尋出 的結果一定會有很大的不一樣。但並不是每個使用者都可分析自己的需求，而把自己的 需求拆成許多的關鍵字。而隨著不同世代的年輕人的語言發展，使用者對於關鍵字是很

頭疼的，他們希望鍵入自然語言就可以搜尋出他們要的結果。但是要處理自然語言並且 分析它的語意，不管在時間上或是方法上都是一件很困難的事。所以此種方法，比較適 合能拆解關鍵字的使用者使用。

 提示輔助：

在關鍵字搜尋法中，為了要讓使用者更容易能找到他們想要的網頁，入口網站提供 了一種貼心的方式來輔助使用者。此種方式，是利用入口網站背後的統計或資料探勘出 的熱門搜尋字串，挑選符合目前使用者鍵出的關鍵字作比對，這時使用者可以挑選以下 入口網站所提供的搜尋文字作搜尋，也可幫助使用者鍵入對的關鍵字的機會。但是當使 用者鍵入關鍵字的第一個字開始就影響到，提示輔助的關鍵字，因為入口網站是拿使用 者每鍵入的字和入口網站提示輔助的字一個一個比對，所以當使用者鍵入的字不符合，

就會將不符合的提示拿掉。也就是如果使用者第一個字鍵入了不相關的字，就很難得到 提供適合的提示輔助。

 結合其他概念：

在上兩點我們對關鍵字搜尋法的討論後，我們可以發現關鍵字搜尋法並不是真正能 完全表現出使用者語意的方式，而是提供一種比較簡單及方便的方法給使用者快速的搜 尋相關的資料，最後的決定權還是需交由使用者決定他們想要瀏覽的網頁。我們能做的，

就是希望能快速的幫助使用者找到他們需求的網頁。所以關鍵字搜尋法能加入其他搜尋 方法，如關鍵字搜尋法加入分類的概念，讓使用者在鍵入關鍵字後的一大堆搜尋結果，

仍能有一定的掌握度，這對使用者也是一大幫助。

(2)類別分類式搜尋方式

在類別分類式搜尋方式中，最典型的例子就是和我們生活息息相關的拍賣網站，如圖 1.2。

此種方式，是利用預先建立的分類方式來分類物品或資訊，當建立好後，此架構就為語意架 構，使用者就可以按照此架構一步步的找尋到符合他們需求的物品或資訊。一般使用者都會

利用關鍵字搜尋法來做第一階段搜尋，才會利用分類法來減少搜尋範圍來找尋所需的物品或 資訊。此方法缺點為，系統必頇考慮到不同的分類方式，不然就無法滿足使用者的需求。不 過一般來說，此種方法都只適用特定領域或小範圍語意使用比較適用。

圖 1.2 Yahoo 拍賣分類式搜尋

(3)問卷式需求分析

此種方式，和前兩種方式，關鍵字搜尋法和類別分類式搜尋方式，有很大的不同，主要 為使用做問卷的方式解析出使用者需求。最常見的例子，為 Google 的進階搜尋或旅遊搜尋，

如圖 1.3 及圖 1.4。

圖 1.3 Google 進階搜尋

圖 1.4 易遊網 旅遊搜尋網頁

搜尋的方式。因為系統建立出此問卷給使用者回答，可能讓使用者回答無關緊要的答案。系 統也能更了解使用者的需求。其缺點為：

 問卷太過制式

問卷在建立後，無法給予使用者比較客製化的問卷，這逼使使用者回答無關緊要的問題，

如果需回答的問卷太過於複雜，將讓使用者失去耐心。

 建立與修改需重新設計需求擷取

一份問卷背後的需求處理，是必頇配合的，不然系統將不了解使用者的需求為何。所以 當一份問卷建立或修改時，系統頇重新修改配合問卷的需求分析處理。

(二)結構性資料

結構性資料的特性為，資料間都有著關連性表示彼此間的關係，如資料庫的資料。我們 如果需在資料庫找尋需要的資料，我們可透過預先建立好的搜尋介面，透過 SQL 語言對資料 庫進行搜尋。目前網站的建置，多將非結構性資料或其檔案位置存入資料庫的表格內，透過 SQL 語言去搜尋。

(三)半結構性資料

半結構性的資料特性為，資料內容是可表示出資料的意義，並不是像一般網頁中的資料 內容是無任何結構表示他是怎樣的資料，如 XML、Object Exchange Model (OEM)。但是在搜 尋半結構性的資料，也由於不同的資料間無任何的關連性表示資料內容，所以我們必頇透過 語意解析的方式來找尋使用者想要的資料給使用者，如 OWL-S、WSMO 等，都是可做到語 意解析的技術。但是這些技術需和 UDDI 結合，在加上實作上有其複雜度。所以我們希望透 過互動式介面，動態地作語意解析，來解決這些技術的不便之處。

我們在以上不同類型的資料搜尋方式介紹後，我們發現不同類型的資料都需要透過一個 搜尋的介面來做使用者需求的擷取，再根據不同的資料類型給予不同的搜尋方式，如我們想 對結構性資料搜尋，我們只需將擷取出的使用者需求轉成 SQL 來進行資料庫搜尋即可；如果

我們需對 Web Services 做搜尋，我也只需將使用者需求轉成語意需求文件，那麼 UDDI 也可 將對此做處理。綜合以上分析，我們發現利用問卷式需求擷取比較符合我們全部的資料類型 的搜尋，所以我們將會利用此方式建立我們的需求分析，並且找尋方法改善其缺點。

1.3 研究目的

本篇論文提出以互動的方式解析使用者語意，取得使用者的語意。整個互動的語意環境，

就像一個情境感知(Context-Aware)的環境，互動的使用者，包含人及各種感應器(sensor)所提 供的情境[10]。本論文最主要的目標，在於為使用者搜尋真正所需的服務，瞭解使用者在過 程中所使用的關鍵字真正的涵意。而在這種思維下，要如何建立機制與使用者做互動溝通就 顯得格外的重要。

在一般的 UDDI 架構下，可以透過 OWL-S 或 WSMO 解析出服務的語意，進而找到使用 者所需服務或組成使用者所需的服務，而我們將透過互動式查詢介面來解析語意。分析語意 的流程，可使用塑模語言的方式來建構，其中常用的語言如 Unified Modeling Language(UML)、

Business Process Modeling Notation (BPMN)、Petri Net 等。以 Petri Net 做為流程定義語言，一 般有三項優點：正規的語意、圖形化特性、豐富的表達及分析能力[22]，因此廣在網路服務 相關的應用。經此分析，我們認為利用 Petri Net 流程處理模式，利於分析及取得語意，因此 將 Petri Net 整合至我們建置的系統中。

Petri Net 是一種模型描述(modeling)及分析(analysis)資訊處理系統的有效工具，使用 Petri Net 的特點在於特徵描述，包含同作(concurrent)、非同步(asynchronous)、平行(parallel)、和分 散(distributed)等四種處理模式。Petri Net 的這些特色有利於使用者與網頁互動中，隨著 Petri Net 狀態的轉換，給使用者不同的問題，進而知道使用者真正的所需，取得使用者的語意描 述。本篇論文在使用者與網頁的互動中，利用 Petri Net 來建立語意架構。我們並以旅遊搜尋 為範例，來驗證我們的方法。

1.4 研究架構

本論文將分為六章，其內容如下：第一章說明本論文之研究背景、研究動機、研究目的，

以及本論文的研究架構；第二章探討相關研究與技術，針對 Web Services、原本語意解析方 式、Petri Net，及相關論文作介紹；第三章探討如何利用 Petri Net 分析語意，並使用關連矩 陣方程式(Incidence Matrix and State Equation)及遞移矩陣(Transitive Matrix)來驗證我們設計的 語意解析架構；第四章介紹語意分析系統架構之建立的過程，如我們選用的開發軟體、整體 系統架構及系統細部的設計方式；第五章介紹實驗與評估的設計，我們建立起一個旅遊行程 搜尋的語意流程架構，並且對其架構和一般問卷來做評估，來驗證我們架構的優點；第六章 對全文做總結及並提出未來的改進及發展的方向。

第二章、相關研究與技術

點出我們研究的領域與研究的區塊。並希望改良原本語意分析上的缺點，也參考相關論文研 究的方法，加入 Petri Net 的模型架構，建立出新的語意分析架構，讓使用者更能建立出自己 的語意。

本章分五節：2.1 節服務為導向的架構(SOA)介紹：此節主要介紹 Web Services 的實作環 境架構，讓我們研究主題領域能更清楚。2.2 節 OWL-S 介紹。2.3 節 WSMO 介紹。經由 OWL-S 和 WSMO 的介紹後，我們會瞭解原本 UDDI 語意分析的方式，並不是很容易建立，所以我們 必頇設計一種方式來改善。2.4 節將介紹本論文所採取改良的方法 Petri Net，利用此方法的優 點，來改良建立新的語意分析的方式。2.5 節我們將針對相關研究論文進行討論。

2.1 服務導向架構(SOA，Service Oriented Architecture)

服務導向架構在建構一個統一的計算模式，在此計算模式中資源以清楚分割的跨平台服 務呈現。服務導向計算可利用網路服務(Web Services)技術，來達到跨平台性的軟體間的互通 性，與以往網路中以提供資料為主的方式不同。W3C 將網路服務定義可以讓機器之間透過網 際網路，互相操作溝通的軟體系統。而在定義中也提到，每個 Web Services 都會有 WSDL(Web Service Description Language)文件去描述要如何去跟這 Web Services 的介面作溝通。所以網路 服務提供者所提供的是將應用程式或函式(function)包裝成的服務，再透過網頁整合，呈現給 使用者。網路服務的優點在於可以依照使用者的需求組合跨平台的服務；如今服務導向計算 及網路服務相關技術越來越流行的，許多知名的網站都有提供網路服務，如 Amazon、Google、

eBay、及 Yahoo。

圖 2.1 SOA 架構

在這種服務導向計算的架構下，由三個參與者所組合而成，如圖 2.1：

(一) 服務提供者(Services Provider)：提供服務的人。

(二) 服務需求者(Services Requester) ：要求服務的人。

(三) 服務中介者(Services Broker) ：由註冊器和語意解析器等功能，所組合而成。目的在組合 不同服務成使用者真正想要的服務，回傳給使用者。

在架構中，每個參與者透過 SOAP(Simple Object Access Protocol)來溝通，而要完成一次 網路服務的搜尋動作會有以下七個動作：服務發佈(publication)、服務要求(request)、服務發 現 (discovery)、服務配對(matchmaking)、服務組合(composition)、執行需求(invocation)、回 傳結果(response)。表 2.1 說明其動作描述。本篇論文主要探討的範圍，為在使用 UDDI 之前，

要如何找出使用者真正的語意。

表 2.1 SOA 架構下服務產生動作描述

動作 內容描述

服務發佈(publication) 服務提供者必頇向註冊器註冊所提供的服務以提供使用者查詢

服務要求(request) 使用者將自己的需求提供給註冊器作查詢

服務發現 (discovery) 註冊器根據使用者需求搜尋出相關符合需求的服務 服務配對(matchmaking) 註冊器根據使用者需求找尋比較符合使用者的服務

服務組合(composition) 將相關的服務組合成使用者想要的服務 執行需求(invocation) 將使用者需求交給服務提供者執行

回傳結果(response) 將執行結果回傳給使用者

2.2 OWL-S(Web Ontology Language for Services)

OWL-S 是一種定義及說明網路服務知識架構(Web Services Ontology)的一種語言，OWL-S 裡包含了網路服務的類別(classes)、屬性(properties)及實例(instances)的描述。那麼 OWL-S 和 OWL 有什麼不同呢？差別在於 OWL-S 是專為 Web Services 而發展的，所以在 OWL 後面加 入-S 成為 OWL-S。而根據 Web Services 的特性來看，Web Services 是可以組合的，所以在 OWL-S 架構必頇考慮到 Web Services 組合的方式，所以在類別間，透過邏輯規則來加強語意 的強度，進而在得到使用者語意後，可組合出符合使用者需求的服務給使用者。那麼一個語 意要如何透過 OWL-S 的知識架構來產生？可以透過收集使用者的一些情境(context)取得，如 使用者的喜好、使用者的裝置、所在位置等。如果有些無法知道的資訊，可透過尋問使用者 的方式取得。所以在收集完使用者的情境後，就直接去比對知識架構來發掘組合出使用者想 要的網路服務。而 OWL-S 提供了三種描述的子句[8]：

(一) OWL Lite：主要提供那些需要分類及簡單運算功能限制的使用者使用。

(二) OWL DL：主要提供那些需要比較大的表現能力、保留計算完整性及計算可在有限時間 內解決的使用者使用。

(三) OWL Full：主要提供那些需要比較大的表現能力和 Resource Description Framework (RDF) 自由語意的表達但並不能保證其計算能力的使用者使用。

這三種子句的描述方式，為提供不同需求的使用者使用，當然最後所發現的 Web Services 也 會有所不同。

2.3 WSMO(Web Service Modeling Ontology)

WSMO 是一種使網路服務能自動發現、組成、執行需求的網路服務的知識架構的一種語 言，也是專為 Semantic Web Services 設計的搜尋架構。在 WSMO 的模型階層中 Web Service Modeling Framework (WSMF)主要有四個成員[11]：

(一) Ontology：為提供語意描述的基礎。

(二) Goals：為定義使用者找尋某服務的目標。

(三) Web Service：為描述要如何組成使用者所想要的服務給使用者。

(四) Mediators：主要為處理中介者之間不同系統間的資料。

在以上成員來看，可看出 WSMO 和 OWL-S 之間的不同。WSMO 強調 Ontology 之間的 重複使用性，所以在 Ontology 設計時，可以參考別的 WSMO 設計方式，並且引用它，在整 體的 WSMO 架構也比較複雜，也比 OWL-S 嚴謹得多，而且 WSMO 的 Ontology 會比較偏向 UDDI 註冊系統架構的服務組成、尋找方式設計。如果我們想要發展屬於我們的系統，使用 此設計方式將會有很大的負擔，因此我們希望用比較簡單並且有擴展性的方式建立 UDDI 系 統。

2.4 派翠網路模型(Petri Net)

進行討論，以增加對 Petri Net 的認識。

2.4.1 Petri Net 起源及介紹

派翠網路(Petri Net)是 1962 年由 Carl A. Petri 博士提出[16]。整體來看 Petri Net 是由多個 元素所組合而成的有向圖，主要由狀態(Places)和動作(Transitions)兩種節點以及用來連接 Place 到 Transition 或用來連接 Transition 到 Place 的有向弧(directed arc)所組成。以圖形呈現來看，

類似流程圖(flow charts)，具有平行(parallel)與同步(concurrent)的模擬能力，至今已被廣泛用 在不同領域作為系統之模組化建構、分析與模擬。表 2.2，說明不同的 Places 和 Transitions 可代表的意義。

表 2.2 Petri Net 的 Places 和 Transitions 可代表的意義

輸入狀態(Input Places) 處理(Transitions) 輸出狀態(Output Places) 前序條件(Preconditions) 事件(Event) 後序條件(Postconditions) 輸入資料(Input Data) 計算步驟(Computation Step) 輸出資料(Output data) 輸入訊號(Input Signals) 訊號處理(Signal Processor) 輸出訊號(Output Signals)

資源要求(Resources Needed) 工作(Job)

資源釋放 (Resources Released) 條件(Conditions) 邏輯(Logic) 結論(Conclusion)

緩衝器(Buffers) 處理器(Processor) 緩衝器(Buffers)

2.4.2 Petri Net 定義、符號以及基本作方式

組成一個基本的 Petri Net 所需的元素為：狀態(Place)、動作(Transition)、有向弧(Arc)、

權重(Weight)和標記(Token)，如圖 2.2。

圖 2.2 Petri Net 組成元素及基本架構

 Petri Net 基本定義：

一個 Petri Net 的集合為 PN = (P，N，F，W，M0)，其中五種元素(tuples)如下：

(一) P = {P0，P1，P2，…，Pm}，表示 Petri Net 所有狀態(places)的有限集合。

(二) T = {T0，T1，T2，…，Pn}，表示 Petri Net 所有動作(transition)的有限集合。

(三) F ⊆ P × T ∪ (T × P)，表示 Petri Net 所有 Arc 的有限集合。

(四) W = F→{1，2，3，…}，表示 Petri Net 所有 Arc 之權重集合。W(P,T)表示 Places 到 Transitions 的 Arc 之權重，反之 W(T,P)表示 Transitions 到 Places 的 Arc 之權重。所有之權重值都必 頇大於等於 1。

(五) M0：P→{1，2，3，…}，Initial Marking 表示初始化狀態標記的數量。

 Petri Net 運作方式：

當動作(Transition)對映到的狀態(Place)含有標記(Token)時，不管觸發動作的方式為何，

一旦動作被觸發後，其狀態的標記將會因運算後，將標記轉移到輸出的狀態位置。我們將用 表 2.3 及表 2.4 來說明 Petri Net 的元素集合及標記轉移步驟，也利用圖 2.3 例子來說明其移轉 方式。步驟 0 時，初始狀態為 P0，再經過 T0 的觸發後，將其狀態轉到 P1，如步驟 1。在步 驟 1 時，狀態為 P1，再經過 T1 的觸發後，將其狀態轉到 P2 的結束點，如步驟 2-1，或者可 經由 T2 的觸發後，將其狀態轉到 P3 的結束點，如步驟 2-2。

表 2.3 Petri Net 標記轉移範例之元素集合

元素 元素內容

M0 {0,0,0,0}

P {P0,P1,P2,P3}

T {T0,T1,T2}

W(P,T) W(P0,T0) = 1, W(P1,T1) = 1, W(P1,T2) = 1 W(T,P) W(T0,P1) = 1, W(T1,P2) = 3, W(T2,P3)=1

表 2.4 Petri Net 標記轉移步驟

步驟 觸發前狀態集合 觸發動作 輸出狀態集合

0 M0{0,0,0,0} N/A M0{0,0,0,0}

1 M0{0,0,0,0} T0 M1{0,1,0,0}

2 M1{0,1,0,0} T1,T2 M2{0,0,1,1}

2-1 M1{0,1,0,0} T1 M2-1{0,0,1,0}

2-2 M1{0,1,0,0} T2 M2-2{0,0,0,1}

圖 2.3 Petri Net 標記轉移圖

2.4.3 Petri Net 屬性

驗證。以確保建立出的系統模型是符合 Petri Net 的方式建構的，其屬性包含了活性(Liveness)、

限制性(Boundedness)及可達性(Reachability)，以下我們將描述其重要性。

 活性(Liveness)：

活性這項屬性主要是說明，標記(Token)不管停在哪個狀態(Place)上，只要不是停在整個 Petri Net 架構的結束點，標記還是會因為動作(Transition)而做移轉，不讓 Petri Net 架構呈現死 結(Deadlock)的狀態，並且保持等待未來的動作觸發。

 限制性(Boundedness)：

限制性這項屬性在 Petri Net 主要是說明，每個 Place 含有 Token 的數量限制並不會超過 一個 K 值。也就是說一個 Petri Net 可以被稱為 K Bounded，就代表不管在哪個步驟下，Places 被 Token 的數量都≤K。

 可達性(Reachability)：

這個屬性在 Petri Net 的運作，是相當重要的，如無法符合此屬性，也代表所建立出的 Petri Net 架構是無法運作的。要符合此屬性，必頇保證 Petri Net 架構中每個 Places 都可以被 M0 經過一連串的 Transition 到達。

將 Petri Net 模型化後，還要能用分析方法來檢驗其流程是否可做到其屬性。以下為一些 方法可利用來檢驗，如可達樹(Reachability tree)可檢驗(限制性、可達性、活性)[18]、簡化技 術可檢驗(限制性、可達性、活性)[19]、矩陣方程式可檢驗可達性[17]、遞移矩陣可檢驗活性 [20]等。

2.5 相關研究討論

主要想在這些文獻中，除了了解其發展外，最主要也是希望在這些文獻中，了解使用 Petri Net 解決問題的思維，以幫助系統的建立。

在我們對相關文獻整理後，我們發現在 Web Services 領域上，使用 Petri Net 改良的研究 可分為三類：語意模型分析、服務組合、流程處理。

 語意模型分析

在原本的 Web Services 領域上，在了解使用者的需求後，就必頇透過 OWL-S 或 WSMO 的語意模型來找尋使用者想要的服務來回傳給使用者。但是要如何在這些語意模型上做服務 的搜尋，又能兼顧到語意模型上每個節點的關係，並且組合出使用者想要的服務，這就不是 一件容易解決的問題。在此相關研究上，是透過 Petri Net 改寫語意架構的方式，來協助搜尋。

如 Yaojun 所提的論文[14]，這篇論文主要想解決的問題是，將 OWL-S 用 Petri Net 架構改寫。

這樣可保持著 OWL-S 的 Ontology，又可不用額外處理邏輯符號來判斷類別間的關係。因為 可利用 Petri Net 模組架構，就可模擬解決邏輯符號，可加快處理的速度及流程。

 服務組合

在 Web Services 的特性中，服務組合是一件很重要的特性。但是以目前的研究發展來看，

卻很難提供一種動態服務組合的方法，當然這是有它的困難性在。而要如何將組合出的服務 呈現給使用者，也是個問題。其困難在組合出的服務流程並不是固定的，所以沒辦法將其流 程固定起來。所以必頇透過一個流程架構設計來解決，只要按照此流程架構執行，就可達到 服務組合的概念。如 Yong-Shang 所提的論文[15]，這篇論文想解決 UDDI 所提供出的 Web Services 必頇要符合使用者需求的服務，所以勢必需要組合服務，但要怎樣提供組合服務給使 用者使用。這篇論文就提出利用 Petri Net 架構來組合服務流程，相對的就是使用者按照流程 跑到結束後，所得到的結果就是使用者需求的服務。並且在李志偉所提的論文[1]中，也驗證 利用 Petri Net 來改良服務組合的想法。

 流程處理

而在決定要使用Petri Net去解決一個領域的問題時，必頇考慮到是否能利用其架構特性去 改寫。如不能將所要解決問題用Petri Net去模擬，那麼就無法使用Petri Net。如本論文所提的 以Petri Net設計及實作強化語意的互動式查詢介面也就是另一種利用Petri Net來改良的方法。

所以在Web Services領域中，如果有流程上的問題，也許可以利用Petri Net來解決其流程處理 的不便。

第三章、Petri Net 分析語意之探討

本章我們將討論使用 Petri Net 架構該如何分析語意的概念，主要是說明我們將如何使用 Petri Net，並且改成符合我們分析語意需求的概念。除了定義出在 Petri Net 架構下，各元素 我們將是如何使用和觸發動作外，我們也驗證我們改寫的 Petri Net 架構是可符合 Petri Net 的 基本屬性，也就是說明其架構是可行的。此外我們也分析了一些 Petri Net 模組，來提供語意 分析架構來使用。

期望的語意分析方式。3.2 節語意分析方法：說明我將如何使用 Petri Net 架構來建立我們的系 統。3.3 節語意分析模組：此小節我們將整理一些，比較合理分析語意的 Petri Net 模組，來提 供語意分析者使用。3.4 節語意分析架構驗證：在建立任何 Petri Net 架構，我們頇確保其架構 是可行的，所以我們需要驗證其可行性，此小節我們將驗證是否符合 Petri Net 屬性。

3.1 語意分析方法之設計理念

對於需求方面的條件。所以在語意解析方面，我們可能會採取問卷的方式，來讓使用者回答，

這個好處在於能收集到比較完整的語意。但對於每個使用者來說，不見得這份問卷是適合他 們作答的。造成這原因，有可能是使用者看到了許多事不關己的問題要回答，當然也有可能 是問卷設計的不良或問卷問題太多、過於繁瑣。所以我們在語意解析設計時，我們要能盡量 避免此問題的產生。

要解決此問題，有很多方式。比較常見的是利用多個網頁連結，將問卷作串連分析使用 者語意。如圖 3.1，為多個網頁連結分析語意的方式，在圖中架構我們可解析出三種不同的使 用者語意。這代表出此架構可提供不同的問題給使用者回答，才會產生出不同語意解析。為 了達到多個網頁分析語意的架構，如果我們將產生不同可能問題的網頁連結寫死，我們將不

時會需要修改及產生不同語意分析架構，這樣的語意分析架構會很無效率，所以我們期望所 建立的系統能解決此問題，又能保持多個網頁分析語意的基礎。

圖 3.1 多個網頁連結分析語意

相同處，所以我們將用 Petri Net 建立起語意分析架構，利用流程控制，來做到動態網頁的連 結，進而達到分析出不同語意方式。如圖 3.2 所示，語意分析系統將會根據 Petri Net 架構所 提供比較符合使用者需求的問題給使用者回答，而使用者也只要回答系統所顯示之問題即可。

直到可解析出使用者需求的 Petri Net 結束點，語意分析系統就會產生出語意分析結果來提供 UDDI 使用。

圖 3.2 語意分析系統架構設計理念 網頁 1

網頁 3 網頁 2

網頁 5

網頁 4 網頁 6

語意 2

語意 1 語意 3

微笑的使用者較佳

3.2 語意分析方法

流程相關元素外，我們也說明語意分析架構是如何作動及如何結束。

3.2.1 定義流程控制相關動作

定義流程控制相關動作部分，我們將說明我們語意分析架構對映 Petri Net 的 Places 及 Transitions 各代表是的什麼意思。

 Places 代表之意義

圖 3.3 代表 Places 之問題集合示意圖

問題來設計語意架構，這會讓架構的 Tokens 數增加，因為系統不會只顯示一個問題使用者回 答，而是在不影響決定點或者是問題的主題相關性下，讓相關問題一次顯示給使用者回答。

那何謂一個決定點呢？如有些問題是只有需男生回答的，而有些只需女生回答的，那麼性別

就為一個決定點。在這之前也許一些個人資料的主題問題集合，如性別、年紀、收入、星座 等，就可一次詢問使用者。所以在這理念下，我們將 Places 的定義成一個問題集合。在這種 設計方式下，既可以減低 Tokens 的數量，又可以讓語意架構更單純。所以我們也利用 Petri Net 的運作模式，設計了一個問題集合架構來定義我們的 Places。如圖 3.3，圖中 Places 代表一個 問題集合，所以當 Places 被 Token 後，將會進入問題集合的流程控制，在經過 t1 的觸發後，

將會讓問題集合內的問題顯示出來給使用者回答。此外，問題集合的流程控制僅代表擷取流 程，本身並不代表任何意義。

 Transitions 代表之意義

在 Petri Net 流程控制下，當一個 Place 傳入 Token 後，除了非遇到需要分歧的點外，一 般來說都只會遇到一個 Transition，而當遇到需要分歧點時，才會遇到多個 Transitions。所以 Transitions 在我們的設計理念下，主要會是使一個問題集合分叉的決定點。因此在這決定點 下，也會有著語意解析的工作需擷取；另一方面，我們在站在語意分析者角色，進行語意架 構的設計，我們也會希望一個問題集合是相關的主題的問題集合。如個人基本資料、交通、

住宿相關問題等，也會使語意分機架構設計更加方便。所以 Transitions 在我們語意分析系統 裡，將會代表的意義會是一個問題集合的決定點或者是一個主題性的問題集合輸入完成，如 圖 3.4 所示。

圖 3.4 Transitions 代表之意義

3.2.2 設定開始及結束動作

在設計完一個語意流程控制架構後，那要如何開始使用此架構及如何才是代表一個語意 流程的結束，是必頇在設計此架構時，一併考慮上去的。而在我們語意分析系統的語意流程 控制的開始及結束的動作為：

 開始動作

在我們的語意分析系統，是專門做語意分析的工作。所以一開始就會直接執行流程控制 的狀態，以致我們並沒有開始的動作。如果我們硬是要說明開始的動作，我們系統開始的動 作為語意流程控制架構的初始化，如初始狀態設定、流程控制系統矩陣建立等相關變數。

 結束動作

在我們系統何謂語意流程控制架構的結束動作，反觀我們語意分析系統主要目的為使用 者語意解析，那麼我們語意流程架構的結束動作，將會是使用者語意統整文件。所以我們在 語意流程控制架構結尾將會放入 END，來代表流程已結束。語意分析系統將會將使用者的語 意按照標準文件做成統整文件，準備交由 UDDI 處理。

3.2.3 觸發流程控制的動作方式

我們觸發流程的動作方式，將會依照 Transitions 的不同，其相同的目的都是為了將問題 集合轉換至不同的問題集合。這設計理念為，網路上每份問卷在完成回答後，都會有 Button 來讓使用者按下，其意義為使用者完成填寫，或者跳到下個子問題網頁繼續回答的“下一步”。

按照此設計理念，我們將會用 Button 來解決觸發的方式，如圖 3.5 及圖 3.6 所示。

圖 3.5 分歧點動作按鈕

圖 3.6 填寫完成動作按

3.2.4 語意擷取流程

回到我們語意解析系統的目的，為使用者語意的解析，我們要如何利用語意流程架構來 擷取使用者的語意。按照語意流程的架構運作方式，我們必頇在每個問題集合回答完畢後，

就先將使用者回答的需求做個整理。由於我們製作的問卷是利用網頁來顯示，所以使用者在 填寫完畢後，必頇交由一個處理器將值取出，這也是系統必頇將每個問題集合都先處理的原 因。直到流程結束後，再將每個問題集合所整理的使用者需求，依照未來與 UDDI 制定的標 準，製作成使用者語意文件。

3.3 語意分析模組

Token 的方式區分，或者是最後結果論的方式來區分模組的研究。此研究可以幫助我們來尋 找符合我們語意分析架構的模組使用。而在相關論文的討論下，我們在不考慮結果論的細分 下，只考慮 Places 轉移方式，整理出四種模組來提供語意分析者參考使用[14]：3.3.1 循序式 模組(Sequence model)、3.3.2 選擇式模組(Choice model)、3.3.3 重復式模組(Repeat model)及 3.3.4 平行式模組(Parallel model)。

3.3.1 循序式模組(Sequence model)

圖 3.7 循序式模組(Sequence model)

3.3.2 選擇式模組(Choice model)

語意，如圖 3.8 所示。主要提供需分歧點的問題集合使用。而站在結果論來看，不見得只有 ProblemSet5 的 Place 結論線路，是可以有很多結果線路可輸出達到不同的使用者語意解析。

圖 3.8 選擇式模組(Choice model)

3.3.3 重複式模組(Repeat model)

此模組是因應使用者在回答一連串問題後，發現並不是他們所預期的，或者站在語意分 析架構設計者角度，做到防止使用者選錯流程，所以我們必需提供回復到之前狀態的模組來 給語意分析者使用。此外也可讓一問題依照不同語意解析需求重複使用，來讓語意解析更豐 富多樣，如圖 3.9 所示。

圖 3.9 重複式模組(Repeat model)

3.3.4 平行式模組(Parallel model)

原本在此模組下，每個組合都會一併執行。但考慮到會造成使用者的困擾，我們可根據 使用者的喜好，給予不同的權重，進而影響優先順序。在一組合執行完畢後，如果使用者表 示同意，我們將不會執行其它組合；反之我們將挑選次要的組合，再詢問使用者，直到使用 者滿意為止或者無其他組合可詢問使用者為止，但考慮其架構也可被選擇式模組取代，而且 易讓使用者回答更多問題，所以不建議用其方法分析。其架構如圖 3.10 所示。

圖 3.10 平行式模組(Parallel model)

3.4 語意分析架構驗證

是否符合 Petri Net 屬性。我們將依照以下方式逐步介紹：3.4.1 產生語意分析架構：我們將建 立一個語意分析流程架構，來提拱驗證。3.4.2 我們將利用矩陣方程式來檢查 Petri Net 的可達 性。3.4.3 我們將利用遞移矩陣來檢查 Petri Net 的活性。

3.4.1 產生語意分析架構

在談完本論文的設計理念後，必頇透過驗證的方式驗證其架構是否可符合 Petri Net 的流 程架構屬性。如果不能符合 Petri Net 架構的屬性，就不能說我們是使用 Petri Net 模式來改良 建構我們的系統。在驗證之前，我們依照我們的設計理念，建立一個語意分析架構來提供檢 驗。如圖 3.11，我們提供一個簡單的例子來檢驗。在圖中的上半部，為一個旅遊行程查詢的 使用者需求問卷，在問卷的設計中，我們會發現使用者必頇回答語意分析的所有問題。如果 使用者要自行開車前往，使用者也必頇回答選擇什麼大眾通運輸工具，其實是很不合理的。

我們做個簡單的修改其語意分析架構，並且也按照我們的設計理念建立，如圖 3.11 下半部。

我們發現就可避免自行前往及搭乘大眾運輸工具的問題，當然這架構並不是最好的流程設計，

但在符合我們的設計規則下，我們就來驗證其流程屬性是否符合 Petri Net 流程架構屬性。

圖 3.11 語意架構轉換例子

3.4.2 使用矩陣方程式檢查可達性

語意分析者，按照本論文設計流程架構理念，將語意分析架構建構出，在利用檢查 Petri Net 可達性(Reachability)的矩陣方程式，檢查是否符合此特性。表 3.1，為 M0 經過一連串的

表 3.1 語意流程架構所有路徑

編號 路徑

R1 P0,T0,P1,T2,P2,T3,P3,T4,P4 R2 P0,T1,P2,T3,P3,T4,P4

 Step 1

利用 D⁺和 D^-矩陣，算出系統矩陣 D(D= D⁺- D^-)。D⁺為系統輸出矩陣，也就是 Petri Net 架構所有從 Transitions 到 Places 的權重所形成的矩陣，如表 3.2 所示。反之 D^-為系統輸入矩 陣，也就是 Petri Net 架構所有從 Places 到 Transitions 的權重所形成的矩陣，如表 3.3 所示。D 系統矩陣運算過後，將如表 3.4 所示。

表 3.2 D⁺系統輸出矩陣

P0 P1 P2 P3 P4

T0

T1

T2

T3

T4

表 3.3 D^-系統輸出矩陣

P0 P1 P2 P3 P4

T0

T1

T2

T3

T4

表 3.4 D 系統矩陣

P0 P1 P2 P3 P4

T0

T1

T2

T3

T4

 Step 2

將系統矩陣產生後，就可以對 M0初始狀態，經過一連串觸發動作，做 Mk=M0+X*D 的 運算。Mk為目前狀態的矩陣。X 為觸發動作為何的一維矩陣。

以下為例子其中一個運算：

M0=[10000]

X=[10000]

M1 = M0 + X*D = [01000]

 Step 3

將所有路徑，都經過重覆 Step 2 的運算，直到流程結束，確定其路徑都可以到達。如果 都符合，及符合可達性。在我們的例子中，的確可以讓每條路徑，都可正確執行。

3.4.3 使用遞移矩陣檢查活性

語意分析者，按照本論文設計流程架構理念，將語意分析架構建構出，在利用檢查 Petri Net 活性(Liveness)的遞移矩陣，檢查是否有流程的節點會成為死結。

 Step1

計算出(LDP)^*矩陣((LDP)^*=D^- * diag(T0,T1,T2,T3,T4) * (D⁺)^T)，其結果如表 3.5 所示。矩陣 內每個值再加上/S，S 為同一個 Transition 被 Places 連結的數目。如值為 1，就不需加上/S。

表 3.5 遞移矩陣之(LDP)^*矩陣

P0 P1 P2 P3 P4

P0

P1

P2

P3

P4

 Step2

利用 Mi=Mi-1 * (LDP)^* 公式，計算 Mi-1的狀態值，是否可再被觸發。其計算結果，為其 矩陣內有值為 1 時，代表還不是死結形成；反之其計算結果，為其矩陣內全部值為 0 時，

代表還死結形成。

 Step3

重覆 Step2，將不同單一 Place 狀態帶入是否為死結，如果發現死結產生，就必頇查看其 流程是否合理。如果不正常，就必頇修改其流程結構。直到沒有死結會產生，才符合活性屬 性的特性。在我們的例子中，不管那個狀態帶入計算，都無 0 值產生。代表此架構是符合 Petri Net 的活性屬性。

第四章、語意分析系統之建立

本章分三小節 4.1 節開發軟體：介紹系統之開發軟體為何。4.2 節系統架構：介紹整體語 意分析系統整體架構及規畫。4.3 節系統建構：此小節將根據我們系統架構作細部介紹其設計 方式。

4.1 開發軟體

我們選擇的開發環境為 NetBeans，原因有下列幾點：

 功能性

NetBeans 比 Eclipse 所能提供的功能更豐富，像一些視覺化介面，就可直接用拖曳一些需 要的視覺化功能，如按鈕、輸入框等。等將位置定好在介面的位置後，再進行編輯及可。而 且 NetBeans 也提供比較完整的開發環境，必較少需額外外掛元件使用，這些都是 Eclipse 所 不足的地方。

 相容性

Eclipse 在開發一些手機的程式時，會遇到相容性的問題。但 NetBeans 所開發出的程式，

就比較少遇到不同系統之間相容性的問題。這也是 NetBeans 贏的地方。

 中文介面

雖然說，在開發軟體介面上，比較少人使用中文介面。但 NetBeans 在官網上，就直接提 供中文的 NetBeans 讓人下載，的確增加了我們選用的機會。反觀 Eclipse，雖然也可有中文的

介面，但需額外將中文語言包掛入系統上，是相當的煩瑣。此外，中文語言包中文化的意思 也比 NetBeans 翻得不好，所以 NetBeans 在中文界面上較有優勢。

在 NetBeans 開發的版本中，我們系統所使用的版本為 NetBeans6.1。在 NetBeans 開發 Web Services 的環境下，主要由 Glassfish 所構成。Glassfish 主要的功能為應用程式伺服程式，

提供一個平台來發行及使用應用程式。此外我們語意分析系統也需要使用到資料庫，我們評 估其實用性決定使用 MySQL，來儲存需要的資料。NetBeans 內部也提供 MySQL 外掛連結程 式：MySQL(Connector/J driver)，來建立 MySQL 的 JDBC 位置。更進一步說明，NetBeans 的 發展越來越完整，發展相關所需的資源，都可透過 Netbean 的介面連結，最後我們使用資料 庫的版本為 MySQL 6.0。

4.2 系統架構

系統架構上，我們利用網路服務(Web Service)來建構我們的系統，我們在 Glassfish 建立 四種網路服務：流程控制初始化、問題產生、處理產生及語意處理的網路服務，彼此有不同 的任務。其系統架構，如圖 4.1 所示。

(一) 流程控制初始化網路服務：

會去資料庫找出我們建立的語意解析的架構，並且建立符合我們架構的 Java Server Page(JSP)檔，以利流程執行。

(二) 問題產生網路服務：

會依據目前狀態查詢資料庫找出應該要詢問使用者的所有問題，回傳給 JSP 檔顯示。

(三) 處理產生網路服務：

會去資料庫找尋符合目前狀態的 Transition，以 Button 的形式顯示，以利流程執行。

(四) 語意處理的網路服務：

主要的工作為處理目前問題集合的語意，並且以一個固定格式表示，方便之後處理。

在系統架構圖上，我們的語意分析流程架構會儲存在資料庫中以供 Web Services 來使用，

資料庫設計包含了四種資料表：

(一) QuestionSet 資料表：表示 Petri Net 的 Places (二) Transition 資料表：表示 Petri Net 的 Transitions

(三) SubQuestionSet 資料表：表示問題集合的問題的子問題

(四) QT and (TQ)資料表：QT 資料表儲存如 Petri Net 的 Places 到 Transitions 的關係；TQ 資料 表儲存如 Petri Net 的 Transitions 到 Places 的關係。主要是為了產生流程運算的系統矩陣 使用。

(五) Q_TypeN 資料表：這資料表表示不同類型問題的資料，以利 SubQuestionSet 尋找問題類 型，如 Text、CheckBox、Radio、select option 等，讓問題的互動性更高。

(六) Button 資料表：儲存問題集合遇到分岐點時，建構 Transtiions 的 Button 時，所需的資訊。

圖 4.1 語意分析系統架構

網頁一剛開始會經由流程初始化的 Web Services 來得到流程控制需要的資訊，如 Places 集合、

Transitions 集合、計算系統矩陣需要的 Arc 資訊和 Places 被 Token 的初始值，以讓流程控制 的動作可順利執行。在初始化後，JSP 網頁會依照目前 Places 被 Token 的值向問題產生及處 理產生的 Web Services 產生每個問題集合，需顯示給使用者看的問題。而使用者會在回答完 每個問題集合後，經由語意處理的 Web Services 做基本的整理，直到流程結束。

4.3 系統建構

置：說明我們每個網路服務是如何設計的。4.3.2 資料庫設計：說明我們資料庫資料表設計架 構。4.3.3 網頁呈現設計：說明我們 JSP 網頁執行流程設計。

4.3.1 系統內網路服務建置

網路服務建置部分，將分別說明我們系統所建立的四種 Web Services 是如何配合需求運 作的。

 流程初始化網路服務

我們為了讓 JSP 網頁每次能抓取不同的流程架構，又能按照我們語意分析流程執行。所 以我們必頇提供初始化的 Web Services 給 JSP 網頁抓取流程架構一些初始值。我們在此也提 供四種不同的 Web Services 處理不同的值， 其細部設計流程，如圖 4.2：

(一) int get_Places_num()：提供如 Petri Net 架構下 Places 的數量。

(二) int get_Transitions_num()：提供如 Petri Net 架構下 Transitions 的數量。

(三) int [][] D(int p,int t)：提供流程轉移時，計算所需的系統矩陣。參數 p 和 t，為 Places 和 Transitions 的值，主要為宣告回傳值的二維矩陣的大小。

(四) int M0()：提供如 Petri Net 架構下的初始值，以利流程執行。

圖 4.2 各個流程初始化網路服務設計流程

 問題產生網路服務

在問題產生這個 Web Service，系統主要做的工作，為產生使用者需要回答之問題集合之 HTML，來讓網頁顯示。其細部流程如圖 4.3 的流程圖所示。一剛開始，會將參數 M 值所指 出被 Token 的問題集合找出，並且等待被建立。接著向資料庫內的 SubQuestionSet 資料表找 出其同一問題集合內的問題。接著，根據問題集合的每個問題類型不同，對不同類型的資料 表找出其問題，在建立時所需的 HTML 相關資訊，協助建立問題。每個問題間都用<br>的網 頁換行符號區隔，直到被 Token 的問題集合內的問題全都處理完畢。最後將其字串回傳，給 網頁顯示其問題資訊。

 處理產生網路服務

處理產生 Web Service 為產生觸發動作的 Button，所需的 HTML 程式給網頁顯示。這也 將決定下個問題流程，將移至下個問題集合的依據。其細部流程如圖 4.4 的流程圖所示。一 開始，會在 M 值內找出被 Token 的問題集合為何。在依據所找出的問題集合，在 QT 資料表 內找出所需的 Transitions 為那些，再逐一建立其 Button。在每個 Button 在建立時，會依據是 Button 是分岐點或 Next 的 Button 做不同的建立方式。因為如果是分岐點的 Button，Button 本身也是有語意在上面，必需擷取出來。此 Button 建立流程將會直到所有 Button 全建立完成 後，將其 HTML 碼字串回傳給網頁顯示。

 語意處理網路服務

語意處理 Web Service 在本論文中，因還沒和 UDDI 建立起語意文件的格式，所以將保留 其設計方式。而在本論文將此 Service 做語意內容的結合的動作。在 Web Service 設計上為 String Semantic_Process(String a,String b)。a 字串為已處理成標準格式的內容，b 字串為剛擷取出使 用者回答的需求。在經過此 Web Service 處理後，將會回傳符合標準文件格式的內容。直到全 部語意分析流程結束後，此內容將是使用者語意文件的重要依據。

圖 4.3 問題產生網路服務建立流程 找出 M 值內被

Token 的問題集 合

將被查詢出的 問題集合內的問題

等待逐一產生 開始

向資料庫查詢 SubQuestionSet 資料

表被 Token 的問題 集合之問題

將問題集合內的問題 根據不同的類型找出

其資訊

跟據找出之問題逐一按照該 問題種類產生 HTML 字串，每

個問題間用<br>換行符號間 隔

判斷是否 還有問題集合內

的問題需處理

回傳產生問題 網頁 HTML 字

串

問題產生網路服務：String Question(int M ,int p) 參數 M 為被標記的問題集合 參數 P 為架構中問題集合的數量

否 是

圖 4.4 處理產生網路服務建立流程 開始

處理產生 Web Service：String Button(int M, int P ) 參數 M 為被標記的問題集合 參數 P 為架構中問題集合的數量

找出 M 值內 被 Token 的問

題集合

向資料庫查詢 QT 資料表會遇到的

動作有那些

查詢出的動作 等待逐一建立

判斷動作是 否為分岐點

建立 Next Button 的 HTML 字串 並且加入<BR>

向資料庫查詢 Button 資料表 Button 的相關資料

建立分歧點 Button 的 HTML

字串並且加入

<BR>

判斷是否還有 Transitions 需建立 Button

回傳 Button 字串 是

否

否 是

4.3.2 資料庫設計

在資料庫設計的部分，我們會建立起五種類型的資料表。第一種類型為 Petri Net 節點的 Places 和 Transitions 資料的資料表。在我們資料庫建立的為 QuestionSet 和 Transition 資料表。

第二種類型資料表，為我們語意分析系統所需的問題集合的資料。在我們資料庫建立的為 SubQuestionSet 資料表。第三種類型資料表為 Petri Net 的 Places 跟 Transitions 連結關係和 Transitions 跟 Places 連結關係兩種資料表。在我們資料庫建立的為 QT 和 TQ 資料表。第四種 類型為當動作為分岐點時，由於此時的 Button 也是含有語意的訊息，所以我們必頇儲存建立 此 Button 的 HTML 碼，時所需的資訊。在我們資料庫建立的為 Button 資料表。第五種類型 資料表，為問題集合內各個類型的問題，我們提供四種類型給語意分析者使用。這些資料表 儲存的為建立此問題的 HTML 碼時，所需的資訊。在我們資料庫建立的為 Text、CheckBox、

Radio 及 SelectOption 資料表。圖 4.5，為 NetBeans 顯示資料庫所建立的資料表及內容。

圖 4.5 資料庫中資料表列

4.3.3 網頁呈現設計

在網頁呈現設計部分，將是說明如何使用我們建置的 Web Services 與使用者介面。一剛 開始會將流程所需的一些資訊，如系統矩陣、有幾個問題集合、有幾個 Transitions 及最初狀 態的一些資訊讀入，以利流程執行。接著我們就跟據每次流程的 M 值，也就是此次要顯示的 問題集合，透過 Web Services 產生所要顯示的問題。並且也產生搭配的 Button 來給使用者觸 發之後的動作。使用者在回答完一次的問題集合，系統會擷取此次使用者回答的答案，並且 經過 Web Services 做整理。直到整個語意流程結束。其流程設計，如圖 4.6。

圖 4.6 網頁呈現設計流程 Form

開始

流程初始化

根據 M 被 Token 值產生問題

產生所屬的 Button

抓取此問題集合 使用者回答的需求

作語意處理

計算下個流程的 M 值

判斷流程 是否結束

語意文件的產生 是 否

第五章、實驗與評估

遊搜尋的語意架構，並且說明我們如何設計此語意架構。接著，我們會將它與一般在做語意 分析的問卷做評估。

本章分三小節 5.1 節實驗環境：介紹我們實驗環境的軟硬體明細。5.2 節實驗方式：介紹 我們將進行何種實驗分析，及如何建立互動式語意流程架構。5.3 節實驗結果：將和比較對象 的實驗結果作呈現分析。

5.1 實驗環境

要使用我們的互動式語意流程分析系統，不需要任何特別的環境。因為在做語意分析的 問卷，網頁的瀏覽器已經是可做到很豐富的內容了。所以我們在設計此系統，也是使用網頁 的瀏覽模式設計的。表 5.1，表示我們一些建構此系統及實驗的軟體資訊。

表 5.1 系統實驗環境

軟體

系統開發環境 Net Beans6.1

資料庫系統 MySQL6.0

執行環境 FireFox/Microsoft IE

5.2 實驗方式

我們實驗的方式，會先建立可解決問題的問卷解析方式。一個為一般問卷的建立方式建 立的固定及非固定的問卷，另一個就為本論文所使用的流程分析方式建立起來的問卷。本節 除了以 5.2.1 說明本論文建立此流程架構的設計理念外，我們也在 5.2.2 中，對不同的解析語