國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
31
4
導引精靈結構分析與超模型
此章節將對於一般導引精靈與特定平台導引精靈的結構進行分析，並且建構符合其規範 的超模型，在多平台導引精靈程式開發系統裡，我們可以把超模型形容成是整個系統的 核心，因此對於建立超模型的要求，希望可以是簡潔扼要的涵蓋整個導引精靈程式與多 執行平台的特性。
4.1 平台無關導引精靈
對於平台無關導引精靈的分析主要是專注在導引精靈應有的目的、結構與行為上進行分 析，最後訂定規則也就是建立超模型，讓所有的導引精程式都能夠符合其規範。導引精 靈的目的就是準確的收集到想要收集到的資料，透過對問題加入輔助性的訊息引導與對 資料進行驗證的過程，來提高收集資料的可用性；導引精靈的結構大多是以多個導引精 靈頁面所組成，並且藉由頁面對資料的收集進行分類，或者透過頁面的先後順序來訂定 收集資料的順序；對於收集資料的行為主要是利用問問題的方式讓使用者輸入答案，並 且把大問題細分成多個小問題，使用者能夠更直覺性的進行回答，快速且易懂的了解該 輸入什麼樣的資料。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
圖 4.1：平台無關的導引精靈超模型。
‧
結構模型主要以 iWizard 、iPage 與 iPageName 三個類別進行定義，iWizard 為整個 導引精靈模型描述的起始點，導引精靈會包含一至多個 iPage 來對資料收集的問題進行 簡單的分類，每一個 iPage 裡所包含的內容，就是資料收集者對於想要收集的資料進行 個別設計的問題，最後是 iPage 之間連接關係的建立，每一個 iPage 名稱都必須利用 iPageName 進行宣告，並且每一個名稱都是唯一的，iWizard 會有順序的對每一個頁面名 稱進行收集，當作每一個 iPage 的執行順序。當完成 iPage 的資料輸入之後系統即可依 據執行順序，連結到下一個 iPage 繼續進行資料的收集直到最後一個，完成整個資料收 集的過程。
問題描述模型
問 題 描 述 模 型 主 要 以 Question 、 SingleQuestion 、 GroupQuestion 、 TextInput 、 MultipleChoice、Dialog 與 MenuItem 七個類別進行定義，其中 Question 是定義一個問題 的父類別，並且宣告了兩個子類別 SingleQuestion 與 GroupQuestion 繼承他，然而在 GroupQuestion 裡主要還是以多個 SingleQuestion 所組成，SingleQuestion 是用來定義資料 收集方式的主要模型，因此我們再對它進行分類，並分別宣告三個類別繼承它：
• TextInput：一般文字輸入型的問題。
• MultipleChoice：是一種有固定答案的問題，並且每一個問題裡面都會包含一至多個 答案選項，每一個選項都以MenuItem 進行描述。
• Dialog：需要與底層作業系統或平台有所互動的問題，例如檔案、顏色與字形的選 擇，或更一般化的物件選擇。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
34
最後 Question 裡的 helpmsg 屬性，在資料收集的過程中並非每一個題目都可以使所有用 戶明確的了解想要收集資料的內容，因此適時地利用 helpmsg 提供額外輔助性訊息對於 不熟悉的用戶來說是必要的。
資料驗證模型
資料驗證模型是以 Validation 與 ErrorMessage 兩個類別進行定義，由於模型對於邏 輯運算的描述相當弱，因此 Validation 主要的內容是以文字敘述的方式來描述該如何進 行資料的驗證，並且當資料驗證過程發生錯誤時必須適時的利用 ErrorMessage 提出錯誤 訊息。
圖 4.2：平台無關導引精靈的 Ecore 模型。
‧
Language)[13]來進行描述，HTML 並不是程式語言而是一種標記語言(markup language)，藉由許多的標記標籤(markup tags)對網頁結構與圖形使用者介面進行定義，但利用 HTML 所描述的是一種比較靜態的網頁與使用者進行互動的方式欠佳，所以常會使用 JavaScript[20]來增加 HTML 網頁動態效果的呈現，JavaScript 是一種廣泛使用在用戶 端網頁程式開發的腳本語言，也就是說在用戶端的瀏覽器上即可執行，不必再透過其他 伺服器的支援。因此在立在本系統上的網頁應用程式導引精靈主要是利用 HTML 與 JavaScript 所建構而成。