系統架構

整個系統的主要模組分別為文件產生器（Document Generator）、文件追蹤機制

（Document Tracing Mechanism）、品質管理（Quality Management）、品質評估模型

（Quality Evaluation Module）與品質報告（Reporting），如圖 27 所示。

圖27 系統架構圖

各模組的功能說明如下：

(1) 文件產生器（Document Generator）

依照定義的文件格式與上傳的文件資料，產生 HTML（HyperText Markup Language）與 PDF（Portable Document Format）格式的製作過程文件，提供以 線上瀏覽的方式查看文件，或是利用可列印文件的方式輸出整份文件。

(2) 文件追蹤機制（Document Tracing Mechanism）

依照製作過程文件之間的關聯資訊，協助在文件之間進行追蹤，當有追蹤 的需求時，則先透過此模組開啟所有相關的文件，再依其內容分別定位到相關 的設計元件。

(3) 品質管理（Quality Management）

管理及記錄所有的品管活動，藉由直接審視製作過程文件的內容，確認設 計內容是否符合需求，並且針對所有發現的品質問題提出矯正措施。

(4) 品質評估模型（Quality Evaluation Module）

運用品質評估模型衡量多媒體教材的品質狀態及預估多媒體教材製作完 成時的品質。

(5) 品質報告（Reporting）

匯集品質管理記錄的品質問題與矯正措施，以及運用品質評估模型所得到 的多媒體教材的品質狀態，產生品質報告。

4.3.3 文件產生器

一般文件產生的方式可以分為輸入（Input）、轉換（Transform）、輸出（Output）三 個步驟，如圖28 所示。

圖28 一般的文件產生方式

輸入方面必須先依據資料的內容設定好文件的格式，接著就可以針對不同的資料內 容來產生文件。由於多媒體教材的製作過程文件需要支援多媒體檔案的呈現，因此對於 應用在多媒體教材製作過程的文件產生器，我們提出的文件產生方式則如圖29 所示。

圖29 提議的文件產生方式

其中，輸入部分的資料內容是以XML（Extensible Markup Language）作為儲存格 式，以方便解析文件，及在各系統模組之間傳遞資訊。文件的排版與格式設定則使用

格式。

轉換的部分則是運用現有的JAXP（Java API for XML Processing）模組來處理 XML 的資料，並依照XSLT 的格式定義，將 XML 轉換為 HTML 的文件。而 PDF 的部分，

則需要再多一層轉換的工作，也就是利用 JAXP 模組先輸出 XSL-FO（XSL Formatting Objects）的文件，然後再透過 Apache FOP（Formatting Objects Processor）套件，協助 將文件轉換成 PDF 的格式。

而多媒體檔案則由使用者以壓縮檔的方式整包上傳到系統後，再由系統依照對應的 目錄結構進行解壓縮。

在此文件轉換的架構中，最重要的部分在於如何設定每一個資料在文件中的位置，

特別是如何安排多媒體檔案的呈現方式，而這些都是在文件格式設定的步驟來完成。設 定文件格式時，必須依照 XML 的文件定義檔（XML Schema）來安排每一個資料在文 件中的呈現方式，並利用XPath（XML Path Language）呈現在 XSLT 的文件中，如圖 30 所示。

圖30 文件格式設定方式

針對XML Schema 文件中的 Complex element，我們將以 loop 的結構來表示，以顯 示節點下的所有資料，而在轉換成XSLT 的文件時，則以 XSLT 語法中的 <for-each/> 來 呈現；Simple element 則以文字的方式直接顯示出來，而在轉換成 XSLT 時，就利用

<value-of/> 的方式來呈現。

而為了支援多媒體檔案的呈現，在Simple element 的部分，我們另外設計一個 Object 的型態，當文件中的資料如果是一個多媒體檔案的名稱且要用多媒體檔案的方式來呈現 時，則在做格式設定的時候，就需要選擇用Object 的型式來顯示，接下來系統就會特別

由於檔案名稱中的副檔名是一個可以很容易且快速辨別檔案型態的方式，所以針對 Object 型態的資料，系統將會在 XSLT 的文件中，加入 <choose/> 的語法，以實際依照 多媒體檔案的副檔名判斷其檔案類型，並嵌入這個多媒體檔案對應的播放語法，讓多媒 體檔案可以正常地顯示，如圖31 所示。

圖31 Object 型態資料處理方式

4.3.4 文件追蹤機制

文件之間要能彼此進行追蹤，很重要的一點是要知道文件中的資料是什麼。雖然 XML 是一份可以解釋自己資料內容的文件，但當我們將 XML 文件轉換為 HTML 的格 式時，基本上已移除了它的標籤名稱的資訊，只將資料的部分顯示出來而已，無法由產 生的 HTML 文件知道原來的資料是什麼。因此我們利用 XPath 的型式，以書籤的方式 將原來XML 文件中的標籤資料，嵌入在最後產生的 HTML 文件中，以便辨識文件中的 資訊，如圖32 所示。

而文件關聯的設定，同樣是透過 XPath 來做連結。假設文件 A 與文件 B 是彼此相 關的，而且我們希望在瀏覽文件 A 的時候，就可以隨時追蹤到文件 B 中的資訊，因此 我們需要設定文件A 中的「/A/b/id」的資料可以對應到文件 B 中的「/B/id」的資料，並 將這個關聯的資訊儲存在資料庫中，等到實際產生資料時，就可以依照資料的內容進行 追蹤。

此時假設我們對文件A 中「/A/b/id」是 001 的資料有興趣，我們就可以透過之前設 定的關聯，找到文件B 中「/B/id」這個 XPath，接著再到文件 B 中找出「/B/id」之值是 001 的資料，即可達到文件追蹤的功能。

圖33 文件追蹤方式

4.3.5 品質管理

最後談到品質管理的部分，因為我們希望可以讓專案成員直接在製作過程文件上檢 視及追蹤問題，但是我們在文件中加上的書籤資訊可能會有重複的情形發生，因此對於 文件中的每一個品質問題，則需要同時儲存資料在文件中呈現時的座標值，以確定品管 團隊所描述的問題是指文件中那一個部分的資料，如圖34 所示。

圖34 品質問題的記錄方式

由於我們需要記錄每一個品質問題出現在文件中的位置，因此在每次進行品質審核 之前，則必須將這個時點的文件先做快照（snapshot），接著再針對複製出來的文件進行 品質審核。

而如果在品質審核的過程中有發現任何品質問題時，專案經理則必須進行追蹤及提 出解決方法。當修正完成且確認所有的問題都有對應的矯正措施之後，就可以交由品管 團隊再度進行審核，此時同樣由系統將此時點的文件做一次快照，品管團隊再依照複製 的文件進行審核，如圖35 所示。

圖35 品質審核方式

最後確認文件中的所有的設計內容都有符合品質的標準時，即完成這個階段的品管 活動。