三、 多媒體編輯工具系統需求分析
3.2 多媒體的組成與軟體需求
3.2.2 文字需求的轉換過程
根據多媒體組成的架構與視覺化呈現需求的基本元素與組成架構，我們 就可以根據分析文字需求，並且加以分類出符合上述的基本元素，就可以利 用編輯器編輯出以”視覺化劇情”來呈現需求。
我們首先來分析 ATM 提款功能的文字需求，我們發現我們可以將這份 需求所描述的內容經由簡單的分析流程[圖 16]，分成 4 個類別，分別為”人”、”
事”、”地”、”物”四個部分。
以下是我們分類的步驟:
(1) 首先，我們分析名詞部分的詞彙；例如，”客戶”、”ATM”、”提款卡”…
等。
(2) 接者我們分析有關動作行為的部分；例如，”插入提款卡”、”輸入密碼”、”
輸入提款金額”…等。
(3) 之後根據上述的簡單分析，將分析出來的元素放在適當的 4 個類別中。
銀行 ATM 系統需求(範例):
提款
客戶可以在 ATM 上提款，提款時先插入提款卡，輸入密碼。
若輸入密碼錯誤，系統會秀出密碼錯誤的訊息，若密碼正確，系統秀 出要使用者輸入提款金額數。客戶輸入金額，提款成功。若提款金額 大於帳戶金額，則系統秀出金額不足的錯誤訊息。
圖 16- 文字需求分析流程
場景(Scenes)、關聯(Relationships)、需求專案(Requirement Project)彼此做對 應而產生下列的對應結果。[圖 17]
圖 17- 視覺化呈現的需求的四個基本元素對應
3.3
3.3.1 編輯機制
根據上述的編輯流程，我們要如何設計一個方便使用者的編輯機制呢?
本系統以下列編輯機制提供使用者編輯:
(1) 將所有控制＂圖示化＂方式來編輯: 編輯時容易辨識、不需要記憶語法和指 令。
(2) 以拖拉及點擊的方式進行編輯: 不需手動撰寫程式碼即可完成編輯。
(3) 以對話表單(Dialog Form)來輸入參數: 以適當的 Dialog Form 來幫助使用著 輸入該指令的參數。
(4) 條列編輯的結果: 較直覺、方便閱讀。
3.3.2 系統功能
本系統在功能上，根據“Visual Software Requirements Definition Environment / Atsushi Ohnishi” 這篇研究做了下列的功能加強:
(1) 增加互動機制:
使用者透過互動行為(拖曳，click)，來表現需求的內容。
(2) Icon 定義彈性:
Icon 無特定意義，允許使用者在建構時給予特定角色。
(3) Icon 擴充容易:
擴充 Icon 時，只需將圖檔複製到特定 Icon 分類目錄即可。
(4) 產生條列式需求:
根據使用者編輯的流程，產生條列式需求，方便使用者總覽整個需求流程。
四、 多媒體編輯工具系統設計與實作
4.1 編輯畫面設計
根據上節，我們已經分析了”多媒體編輯工具系統”的編輯機制與編輯流程，
以下我們先來介紹本系統的編輯畫面:
(1) 主畫面: 主畫面分成三大部分:
功能鍵: 功能鍵包含了”編輯流程”，”撥放流程”，”變更背景”。
主要編輯區: 主要編輯區可讓使用者挑選背景，並從 icon 圖庫中 拖曳出所需的 icon 圖示，並移動到適當的位置。
分類 Icon:分類 icon 以 group 方式將使用者所常用的 icon 分類到 不同 tab 中。使用者可以切換 tab，以拖曳方式選去所需的 icon。
圖 19- 多媒體編輯工具系統主畫面 (2) 選定 Actor:
使用者從根據所需的 icon，以拖曳方式選取到編輯區。
分類 icon 區 主編輯區
編輯流程/撥放流程/
變更背景
圖 20- 多媒體編輯工具系統選取 actor (3) 編輯流程:依據不同的 Action 輸入不同的 Actor。
Action=RightClick:當 Action=RightClick 時，必須輸入 Actor 1, Actor 2, Menu 1, Menu 2, Actor3, Actor4，其中 Menu 1 代表使用者觸發後 會出現 Actor 3，Menu 2 代表使用者觸發後會出現 Actor 4。
拖曳
圖 21- 多媒體編輯工具系統定義流程(Action=RightClick)
Action=DoubleClick:當 Action=DoubleClick，使用者必須輸入 Actor 1,Actor 2 與 Actor 3。當使用者 double click Actor 1 時，會將 Actor 3 秀出。
圖 22 -多媒體編輯工具系統定義流程(Action=DoubleClick)
Action=DragDrop:當 Action=DragDrop，使用者必須輸入 Actor 1，
Actor 2 與 Actor 3。當使用者將 Actor 1 拖曳到 Actor 2 時，會秀出 Actor 3
圖 23-多媒體編輯工具系統定義流程(Action=DragDrop) (4) 播放互動流程:
圖 24- 多媒體編輯工具系統播放互動流程 (5) Script 預覽:
圖 25- Script 預覽
4.2 系統架構設計
上一小節，我們設計了系統的操作介面，但為了達到視覺化的編輯，使用者 不會有輸入文字程式碼的動作，因此系統要將使用者的編輯動作轉化成為系統所 能認知的描述。我們由以下的系統架構圖來說明各個原件的功能。[圖 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
4.3 系統 Class Diagram
frmMain: 為系統主要呈現視窗，提供使用者拖曳所需 icon 與進入 編輯或播放式窗。
frmEdit: 提供使用者編輯需求流程。
frmScript: 依據使用者編輯的流程所產生的 script 秀出，並將關鍵 字上色。
frmPlay: 依據使用者編輯的結果播放並與使用者操作產生互動。
modUtil: 提供各 form module 所需的 common method.
圖 29- System Class Diagram
4.4 系統 Sequence Diagram
圖 30 - System Sequence Diagram
五、 實作範例
5.1 範例
在這一節當中我們會以 ATM 提款流程為例子，介紹如何用我們的視覺化劇 情呈現需求編輯器實際編輯出需求的內容。
(1) 新增 icon:
使用者在本系統的目錄中建立 icon 分類目錄:
圖 31- 新增 icon (2) 選取 icon:
拖曳出使用者，提款機，提款卡，輸入鍵盤，money，錯誤訊息等圖示。
銀行 ATM 系統需求(範例):
提款
客戶可以在 ATM 上提款，提款時先插入提款卡，輸入密碼。
若輸入密碼錯誤，系統會秀出密碼錯誤的訊息，若密碼正確，系統秀 出要使用者輸入提款金額。客戶輸入金額，提款成功。若提款金額大 於帳戶金額，則系統秀出金額不足的錯誤訊息。
圖 32- 選取並拖曳 icon (3) 定義流程:
根據文字需求，以下列流程編排。
1.提款卡插入提款機，show 出輸入密碼畫面。
2.輸入密碼錯誤時，show 出錯誤訊息。
3.輸入密碼正確時，且提款成功時，show 出鈔票圖示。
圖 33-定義流程:提款卡插入提款機，show 出輸入密碼畫面
圖 34-定義流程:提款卡插入提款機，show 出輸入密碼畫面
圖 35-定義流程:輸入密碼錯誤時，show 出錯誤訊息
圖 36-定義流程:輸入密碼正確時，且提款成功時，show 出鈔票圖示
(4) 檢視 Script: Highlight 語法部分。
圖 37-檢視 Script (5) 播放流程:
1.Double click 使用者 icon，系統 show 出提款卡。
2.拖曳提款卡插入提款機，show 出輸入密碼畫面。
3.右鍵輸入密碼錯誤時，show 出錯誤訊息。
4.右鍵輸入密碼正確時，show 出輸入提款金額。
5.右鍵輸入餘額不足時，show 出錯誤訊息。
6.右鍵輸入時提款成功時，show 出金錢圖示。
圖 38-播放流程:Double click 使用者 icon，系統 show 出提款卡
圖 39-播放流程:拖曳提款卡插入提款機，show 出輸入密碼畫面
圖 40-播放流程:拖曳提款卡插入提款機，show 出輸入密碼畫面
圖 41-播放流程:右鍵輸入密碼錯誤時，show 出錯誤訊息
圖 42-播放流程:右鍵輸入密碼錯誤時，show 出錯誤訊息
圖 43-播放流程:右鍵輸入餘額不足時，show 出錯誤訊息
圖 44-播放流程:右鍵輸入時提款成功時，show 出金錢圖示
六、 結論
6.1 總結
利用互動式多媒體的來編輯以視覺化劇情呈現需求使的使用者與系統開發 人員之間的溝通更為自然與直覺，而編輯的方式也利用視覺化程式語言的特性，
利用圖示及拖曳方式進行編輯，使得不會文字程式語言的使用者也能編輯出具有
利用圖示及拖曳方式進行編輯，使得不會文字程式語言的使用者也能編輯出具有