系統架構設計

上一小節，我們設計了系統的操作介面，但為了達到視覺化的編輯，使用者 不會有輸入文字程式碼的動作，因此系統要將使用者的編輯動作轉化成為系統所 能認知的描述。我們由以下的系統架構圖來說明各個原件的功能。[圖 26]

圖 26- 多媒體編輯工具系統架構

我們可以看到，此系統最主要有 2 大部分，分別是 User Interface 與 ”後端 控制元件” (Backend Controller)。以下針對”後端控制元件”做一個詳細的介紹:

(1) Scenario Editor:

為流程編輯原件，主要功能是讓使用者編輯需求流程。

(2) Script Generator:

負責辨識需求流程，並根據定義的語法將辨識後的結果轉化成定義的 script language。

(3) Scripts:

一個 Scripts 暫存區，儲存經由 Script Generator 所產生的 Scripts。

(4) Interpreter:

Script Language 的直譯器，Interpreter 會將從 Scripts 讀入的程式碼解 譯成相對應的動作行為與角色。

(5) Mediator:

根據 Interpreter 所解譯出的互動行為及角色，到 Icon Resource 中取出 對應的角色。當使用者進行撥放或互動行為時，則負責中央控管 actor 之間的互動，而非由各自 actor 彼此交錯控制互動行為。

(6) Icon Resource:

Icon 的儲存中心，提供 icon 分類儲存，並提供使用者在編輯時所需 要的 icon。

舉一個例子，使用者根據”Icon Resource”這個原件所提供的 icon，透過介面 拖曳選取，接下來利用”Scenario Editor”所提供的編輯劇情功能，編輯出條列式 的流程並轉交給”Script Generator”處理。經由”Script Generator”將條列式流程轉譯 成為定義的”Scripts”後便完成了編輯動作。當使用者進行播放功能時，系統 將 ”Scripts” 經 由 ”Interpreter” 轉 譯 成 系 統 的 控 制 程 式 ， 透 過 ”Mediator” 來 控 制 icon(actor)之間的互動行為。

回顧視覺化呈現的需求的四個基本元素-演員(Actor)、場景(Scenes)、關聯 (Relationships)、需求專案(Requirement Project)我們可以將上述的系統元件的功能 做個對應。演員與場景都是透過 Icon Resource 來提供、關聯就是使用者透過本 系統設計出的劇情，並轉換成 actor 之間的互動並由 script 紀錄、而專案需求則 是透過透過本系統設計出的某一段劇情。

4.2.1 系統語法定義

“Script Generator” 將條列式的流程透過定義的語法規則，將其轉換 成”Scripts”；以下介紹本系統所定義的語法。

以下是透過上述定義的語法所編輯出的 script 範例:

在本系統中的兩個主要的元件”Interpreter”與”Mediator”是根據

軟體工程領域中的設計樣式(Design Pattern)[12,14,15]為基礎應用於本系統的實 作中。

我們分別簡單的探討這兩個設計模式是如何在本系統中應用:

(1) Interpreter Pattern:

利用自訂的語言來表現程式要執行的內容，但是執行時必須先經過翻譯程式分 析自訂語言並執行，這個翻譯程式稱作"直譯器"。使用此 pattern 前必須先定義好 語言規格，例如常見的 BNF(Backus-Naur Form)用來描述程式語言的文法。以下

program

drag actor_a actor_b actor_c right_click actor_c

mouse_over actor_a

drag actor_b actor_d actor_e end

<program> ::= program <command>* end

<command> ::=<actor><actor><action><actor>

<actor> ::= actor<id>

<id> ::= a|b|c|…|z|0|1|2|…|9||A||B|C|…|Z|

<action> ::= drag | right_click | double _lick | mouse_over

是”Interpreter” design pattern 的 UML class diagram[圖 28]。"AbstractExpression"

一個抽象的 expression，定義 interpret 這個方法的介面。"TerminalExpression"非 終點的表示式，"NonterminalExpression"終點表示式。"Context"則提供文法解析 所需要的方法。

圖 27- Interpreter class diagram (2) Mediator Pattern:

利用仲介者物件來封裝一系列關於物件交互行爲，負責調節、傳遞的工作。

在組織物件工作的同時，物件彼此之間可能相互依賴，這就使得物件之間的耦合 性相對的提高，最差的情況下，所有的物件都知道彼此的存在，這會使得系統的 重用性降低。以本系統為例，當使用者定義各個 actor 之間的互動行為後，彼此 並無直接耦合關聯，因為所有 actor 都是可以重用的元件，因此，必須將彼此的 直接關聯性透過仲介者來處理。以下是”Mediator” design pattern 的 UML class diagram。[圖 28]

圖 28- Mediator class diagram