語意分析方法

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

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 制定的標 準，製作成使用者語意文件。