應用介面產生器於介面開發流程之研究

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

應 用 介 面 產 生 器 於 介 面 開 發 流 程 之 研 究

A Study of Applying Interface Generator to Interface

Development Process

研

究 生：林靖哲

指導教授：陳登吉

教授

應用介面產生器於介面開發流程之研究

A Study of Applying Interface Generator to Interface

Development Process

研

究 生：林靖哲 Student：Ching-Che Lin

指導教授：陳登吉

Advisor：Deng-Jyi Chen

國

立 交 通 大 學

資

訊 科 學 與 工 程 研 究 所

碩

士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science July 2011

Hsinchu, Taiwan, Republic of China

i

應用介面產生器於介面開發流程之研究

學生：林靖哲 指導教授：陳登吉博士

國立交通大學資訊科學與工程研究所碩士班

摘要

隨著科技的進步，人機介面越來越普遍被應用在日常生活中，像是Wii, iPad。每當 有新辨識器推出的時候，軟體開發人員需要為這個辨識器撰寫一份介面程式，供銜接辨 識器與應用軟體。我們所知的介面程式的開發方式有二種。一是開發人員直接對介面程 式進行撰寫。二是利用程式產生器產生介面程式。第二種方法開發人員不需直接對介面 程式進行撰寫。相對的，需要了解介面產生器的使用方法以及該介面產生器所需的 specification code的規範。 本研究將針對上述兩種開發方式進行分析與比較，檢視兩種開發方式流程上的差異， 同時採用這兩種開發方式實際開發介面程式。透過實際的開發，了解介面程式開發所需 要的時間，並以COCOMO II模型搭配開發介面程式使用的程式碼行數估算開發所需時間 成本，佐證實際開發所需時間的合理性。由比較結果，得出以下結論：在本研究的環境 限制之下，透過介面產生器產生介面程式比直接撰寫介面程式，有更高的生產力。

ii

A Study of Applying Interface Generator to Interface

Development Process

Student: Ching-Che Lin

Advisor:Dr. Deng-Jyi Chen

Department of Computer Science and Information Engineering

National Chiao Tung University

Abstract

Nowadays, Human Computer Interface is widely used in life, like Wii, iPad. We need to development for recognizer an interface code for interface new recognizer and application when a new recognizer is released. There are two methods to development interface code. First, the program developers write interface program directly (Hardcode). Second, use the program generator to generate the interface code. The developers do not need to write interface program directly in the second method. The relatively, the developers need to understand how to use the interface generator, and how to write the specification code which interface generator needed.

In this study, we will analysis and comparison the above methods. View the different of these two methods of development process. Furthermore, these two methods will be used to actual development interface program. Via the actual development, understanding of the interface program development time required. And use the COCOMO II model to estimate the time required for development costs, support the development time required is

reasonable. Finally, we got the following conclusions. Under the constraint of this study, use the interface generator to generate interface code is more productive than hardcode.

iii

誌謝

本論文得以完成，感謝陳登吉老師的大力協助及孜孜不倦的指導，花費了許多時間 及精神，開發新的靈感、修正論文方向，並提供實驗室資源使用。感謝曾建超老師、蕭 嘉宏老師給予論文及口試上的指導。也感謝學長姐們的指導與鼓勵、同學之間的互相鼓 勵及學習、實驗室的學弟們的幫忙，讓我能夠順利的完成論文的寫作。 最後特別感謝我的家人，在這段時間頻繁來往台北、新竹，舟車勞頓。你們的支持 與鼓勵，是支持我努力下去的最大動力。

iv

目錄

摘要 ... i Abstract ... ii 誌謝 ... iii 目錄 ... iv 圖目錄 ... vi 表目錄 ... viii 一、緒論 ... 1 1.1 研究動機 ... 1 1.2 研究目的 ... 1 1.3 研究方法與步驟 ... 2 1.4 研究範圍與限制 ... 2 1.5 章節概要 ... 3 二、相關研究 ... 4 2.1 辨識器 ... 4 2.1.1 辨識器的選擇 ... 4 2.1.2 Wiimote的應用實例 ... 7 2.1.3 Wiimote的運作 ... 8 2.1.4 電腦端的辨識器–WiiGLE... 9 2.2 介面產生器 ... 10 2.2.1 介面產生器的選擇 ... 10 2.2.2 介面產生系統簡介 ... 12 2.2.3 介面產生系統應用在本研究的限制 ... 13 2.3 軟體成本估算模型 ... 14 2.3.1 選擇軟體成本估算模型 ... 14 2.3.2 介紹COCOMO II模型 ... 15 三、介面程式開發方法介紹與比較 ... 17 3.1 介面程式開發方法 1 – Hard code ... 17 3.1.1 開發流程 ... 17 3.1.2 特色 ... 18

3.2 介面程式開發方法 2 – Via Interface Generator ... 18

3.2.1 開發流程 ... 18

3.2.2 特色 ... 19

3.3 開發方法比較 ... 19

四、實際開發比較差異 ... 21

v 4.2 COCOMO II模型調整 ... 21 4.3 實際開發行數記錄與COCOMO II時間估算 ... 22 五、展示 ... 24 5.1 利用Hard code方式開發介面程式 ... 24 5.2 利用程式產生器的方式開發介面程式 ... 27 六、結論與展望 ... 32 6.1 結論 ... 32 6.2 展望 ... 32 參考文獻或資料 ... 33 附錄 ... 36

vi

圖目錄

圖1、Microsoft Speech Recognizer 使用畫面 ... 4

圖2、Simon使用畫面 ... 5 圖3、FingerWorks ... 5 圖4、HTC sense... 5 圖4、Wii ... 6 圖5、DataGlove ... 6 圖6、Kinect ... 6 圖7、Mgestyk ... 6 圖8、Wiimote應用於教學(電子白板) ... 7 圖9、Wii應用於復健I(平衡) ... 7 圖10、Wii應用於復健II ... 7 圖11、Wiimote應用於復健(腕部) ... 8 圖12、Wiimote應用於腕部復健的遊戲 ... 8 圖13、Wiimote藉藍芽傳遞偵測數據至電腦端概念圖 ... 8 圖14、Wiimote與其辨識器間的運作流程 ... 9 圖16、WiiGLE的辨識結果畫面 ... 10

圖17、Generic Interface Bridge系統架構流程圖 ... 12

圖18、直接撰寫開發方式開發流程 ... 17

圖19、使用介面產生器開發方式開發流程 ... 18

圖20、BlueSoleil(藍芽接收器)啟動畫面 ... 24

圖21、WiiGLE啟動 ... 25

圖22、WiiGLE Composite Recognizer ... 25

圖23、Wiimote連結成功 ... 26

圖24、選擇可辨識手勢群組 ... 26

圖25、辨識器辨識結果與應用軟體畫面展示 ... 27

圖26、Command composer 截圖 ... 27

圖27、Create new profile ... 28

圖28、設定前profile內容 ... 28 圖29、Profile讀入Command composer ... 28 圖30、新增目標應用軟體 ... 29 圖31、目標應用軟體新增成功 ... 29 圖32、新增目標應用軟體 ... 29 圖33、新增辨識結果對應指令視窗 ... 30 圖34、新增對應指令成功並回到Command composer主畫面 ... 30 圖35、所有對應指令設定完成 ... 30

vii

圖36、specification code 產出 ... 31 圖37、Generic Interface Bridge dll檔 產出 ... 31

viii

表目錄

表1、程式產生器分類列表(2000-2010) ... 11

表2、Waterfall Phase Distribution Percentages[20]... 16

表3、兩種開發方式差異比較表 ... 19

表4、開發人員實際用兩種方法開發介面程式所花費時間 ... 21

表5、開發人員實際用兩種方法開發介面程式所花費程式碼行數 ... 22

1

一、緒論

1.1 研究動機

隨著現今科技的進步，我們可以看到許多人機介面被應用在日常生活中，像是：運 動控制器(Wii)[34]、觸控式螢幕產品(平板電腦、智慧型手機)[38][39]、語音控制系統 [40][41]等等…，我們發現每當有新的辨識器出現時，開發人員就必須開發新的介面程式 用來銜接新的辨識器及應用軟體。 我們知道的介面程式開發方法有兩種，一種是直接撰寫介面程式的開發方法，另一 種就是透過程式產生器來產生介面程式的開發方法。 直接撰寫介面程式的開發方法，如同字面上的意思，就是由開發人員直接撰寫用於 銜接辨識器與應用軟體的介面程式碼。 透過程式產生器(由於本研究產生的程式為介面程式，其後統一稱之為介面產生器) 產生介面程式的開發方法[27]，則是需要撰寫介面產生器所需要，且具有一定格式規範

的程式碼(specification code)，然後由介面產生器讀取撰寫好的 specification code，自動 產生可銜接辨識器與應用軟體的介面程式，而非直接進行介面程式的撰寫。觀念上，就

像是利用lex 這種工具來產生 lexical analyzer 的方法，或像是利用 yacc 這個工具來產生

parser 的方法。

1.2 研究目的

雖然開發介面程式的方法不同，可是最終都還是必須達到能夠與應用軟體互動的目 的。本研究希望尋找利用不同的介面程式開發方法，在開發介面程式時的差異。所以， 本研究的主要目的，將以上一個章節所提及的兩種介面程式開發方法作為研究對象，試 圖尋找兩種介面程式開發方法(直接撰寫介面程式的開發方法、透過程式產生器產生介 面程式的開發方法)在開發介面程式時的差異。

2

1.3 研究方法與步驟

本研究的主要目的是尋找利用兩種不同的介面程式開發方法，在開發介面程式時的 差異。所以我們一開始先選定本研究所需要使用的辨識器、介面產生器。並加以修改， 成為符合本研究的工具。再進一步分析兩種開發流程的特色與差異，最後統計與比較利 用兩種開發方法，實際開發介面程式所需要的時間與程式碼規模。 這裡，我們在選定好作為範例的應用軟體[8]後，去信希望能取得該辨識器與應用軟 體之介面程式的開發時間(見附錄)，由於對方至今在尚無回信，本研究無可以比較的對 象，故本研究選擇了一個替代方案：使用軟體工程中的軟體開發成本估算模型[33]，來 進行軟體開發時間成本的估算，用以佐證實際開發介面程式所需時間的合理性。本研究 的步驟如下 1. 選擇本研究所使用的辨識器與介面產生器，且加以修改成為本研究可用之辨識器與 介面產生器。 2. 分析兩種介面程式開發方法的流程與差異比較。 3. 利用兩種介面程式開發方法，實際開發介面程式並尋找開發時間與程式碼規模的差 異，最後以軟體成本估算模型佐證實際開發時間的合理性。

1.4 研究範圍與限制

 辨識器 辨識器種類繁多，應用層面廣泛。本研究選擇的是以手勢辨識為基礎的辨識器。其 中手勢辨識亦包含有影像識別、加速度感應識別、觸碰式感應識別等…。所以更準 確的來說，本研究選擇的是利用加速度感應來辨識手勢的手勢辨識器。  應用程式 應用程式可選擇任一普通常見的軟體。而本研究選擇的是以醫療復健為基礎的應用 軟體，藉由遊戲的方式，活動使用者的腕部，已達到復健的目的。本研究並不探討 此應用軟體的醫療、成效等相關議題。  介面程式 用於銜接上述的辨識器及應用程式的程式，由介面程式了解辨識器的辨識結果，並 將此辨識結果轉換成應用程式能讀懂得資訊。  介面程式產生器 產生上述介面程式的程式產生器，避免介面程式重複開發所浪費的時間成本，節省 開發資源。

3 本研究僅探討有無利用介面產生器於 Windows 作業系統平台上開發介面程式，在流 程、時間及程式碼規模的差異。作業環境為 Windows 7 並可相容於 Windows XP。

1.5 章節概要

本研究共分為六個章節，各章節之內容摘要依序如下： 第一章：敘述本研究的研究動機、研究目的及研究方法與步驟。 第二章：相關研究探討，對本研究所選擇與使用的辨識器、介面產生器，以及其應用 與後期會使用的軟體成本模型作說明。 第三章：分析介面程式開發方法的流程與差異比較。 第四章：利用兩種介面程式開發方法實際開發介面程式，記錄開發時間與程式碼規模 並進行差異比較。 第五章：展示。 第六章：說明本研究的結果與未來尚可探討的議題。

4

二、相關研究

2.1 辨識器

市面上的辨識器種類十分多種[34][35][36][37][38][39][40][41]，有語音辨識器、手勢 辨識器、動作辨識器等等…，下面我們將針對上述提及的辨識器作簡單的介紹。

2.1.1 辨識器的選擇

 語音辨識器[40][41] 語音辨識器是將人類語音中的詞彙內容作為計算機可讀的輸入，採用分離字辨識或連續 語音辨識等方式，識別出使用者所說的詞彙[32]。其中分離字辨識法，就是在使用辨識 器時，每說一個詞彙，就必須停頓一次，讓電腦進行辨識的動作。如今，大部分的語音 辨識系統均採用連續語音辨識的方式，避免口音，說話速度、干擾的背景噪音所造成的 影響，進而辨識出使用者說出的詞彙之間的界線。而且辨識器中所提供的Context Free Grammar 也可用來解析辨識出的詞彙，進一步了解使用者所說的話的涵義。其產品例如： Microsoft Speech Recognizer[41], Simon[40].

5 圖2、Simon 使用畫面  手勢與動作辨識器[34][35][36][37][38][39] 依據手勢與動作辨識器的使用方式，又可進一步分為觸碰式辨識與非觸碰式辨識。  觸碰式[38][39]：須直接觸碰感應面板。藉由電容式或電阻式面板，感測使用者 手的接觸面與移動，進一步分析觸碰點位置的變化，其產品例如：

FingerWorks(ipad, iphone…), HTC touchFLO3d, HTC sense…均廣泛被使用在智慧 型手機、平板式電腦上。

圖3、FingerWorks 圖4、HTC sense

 非觸碰式[34][35][36][37]：非觸碰式的手勢辨識，不需要觸碰感應面板。相對

可能需要其他的感應設備，如加速度感應器(Wii)、光纖感應器(VPL DataGlove)、

6 圖4、Wii 圖5、DataGlove 圖6、Kinect 圖7、Mgestyk 在資料與產品的尋找過程中，我們發現動作感應及手勢辨識漸漸的成為辨識器的主 流之一，其中Wii 在 2005 年由日本任天堂公司所提出並產品化[34]，是屬於近年來較早 提出且商品化的辨識器，在開發資源上有著比較豐富的優勢。除了本身應用於遊戲上廣 為受歡迎之外，亦有許多論文及研究，探討將Wii 應用在不同的領域，例如：教學上的 電子白板[43]，或協助醫療復健的平衡訓練、手/腕部運動[3][4][5][6]等等…。 其中，將Wii 應用於醫療復健是個新鮮的領域，同時也是本研究有興趣的方向。故 本研究的辨識器選擇以Wii 控制器(Wiimote)為基礎的辨識器。

7

2.1.2 Wiimote 的應用實例

Wiimote 的應用，廣為人知的遊戲部分在此就不多加說明，此章節將針對 Wiimote 應用於教學上的電子白板以及醫療復健的運動作介紹。2008 年，Johnny Lee 於個人網站 [43]提出利用 Wiimote 中含有紅外線感測器與藍芽傳輸裝置的特性，與紅外線發射器及 電腦結合，藉由追蹤及判斷紅外線發射點的位置，做成簡單的電子白板，並同時將此技 術公開。由於該技術所需設備之價格低廉，時至今日已被使用於日常所見的教學中。 圖8、Wiimote 應用於教學(電子白板) 另外，國內外的醫院、研究機構也嘗試利用Wii 的遊戲或是 Wiimote 的機制，改善 病患在復健上的問題，除了可增加病患的興趣、提高參與復健的意願[7]之外，搭配專業 醫事人員的意見及協助，也可以達到復健的目的，作為傳統復健的另一種新選擇。

8 最後，本研究所選擇的是藉由偵測使用者腕部伸展運動，控制古典遊戲pong 中的 平板，使平板左右移動，目的在不讓小球掉落至平板之下，同時達到腕部復健的目的[8]。 同上章節之結論，本研究選擇以Wii 控制器為基礎的辨識器，並與醫療復健應用軟體作 結合，作為一個範例。 圖11、Wiimote 應用於復健(腕部) 圖12、Wiimote 應用於腕部復健的遊戲

2.1.3 Wiimote 的運作

Wiimote 本身包含了三向動作感應器、紅外線發射器及藍芽傳輸裝置，其中本研究 中所利用的是三向加速度動作感應器以及用來傳輸感測到的數據的藍芽傳輸裝置，使用 者在使用Wiimote 作出動作時，三向感應器用來偵測使用者動作的 x, y, z 軸的加速度， 根據感測到的數值，再藉由藍芽傳輸裝置，把感測到的數值，傳送到電腦的藍芽接收端， 電腦中的辨識器將會接收由藍芽傳送來的訊號，並加以解析，分析記錄下來的數值，判 斷使用者當下所作出的動作為何[1][2]。並將判斷結果送至介面程式，供介面程式參考。 圖13、Wiimote 藉藍芽傳遞偵測數據至電腦端概念圖

9

圖14、Wiimote 與其辨識器間的運作流程

2.1.4 電腦端的辨識器–WiiGLE

如同前面章節所提，Wiimote辨識器的資源非常豐富，像是WiiGLE[42], WiiGee[44],

Wiiremote, Wiiyourself…等等，此處我們選擇的電腦端的辨識器是WiiGLE。WiiGLE是由德 國University of Augsburg的 Human Centered Multimedia團隊開發。

它同時提供了動作感測及動作辨識的模組，在利用藍芽連線後，便可藉由x, y, z 三

向加速度感測器的數據，及時的反應給電腦端，也可利用Wii 的 B 鍵進行動作辨識。同

時，其他種類的辨識器很多只有提供到即時的動作感測，並不提供連續動作的辨識，或

是辨識器是運作在Linux 系統上，還有一些是因為藍芽裝置的相容性問題導致無法順利

使用[44]。另外 WiiGLE 內建提供了 DTW 分群法、Weka BayesNet 分群法、Weka Kstar 分

群法…等數種不同的分群法，用於識別使用者的動作。WiiGLE 也提供了使用者自建動作

10 圖15、WiiGLE 使用畫面 圖16、WiiGLE 的辨識結果畫面

2.2 介面產生器

本研究所需要的介面產生器必須符合兩個條件 1. 由於本研究會針對辨識器與應用軟體作修正，所以必須要能取得介面產生器的程式 原始碼 2. 介面產生器必須要產生能夠銜接辨識器與應用軟體的介面程式

2.2.1 介面產生器的選擇

首先我們收集了從2000 到 2010 年發表於 IEEE 與 ACM，有關程式產生器的期刊、論 文、產品並以其用途加以分類，大致上分成了  使用者介面程式產生器[45][46]  UML 程式產生器。[10][12][16]  硬體程式產生器[9][11][13][14][29][30]  編譯器程式產生器[28][48]  介面程式產生器[26][27]  其他[15][17][18][31][47]

11

綜合上述所蒐集到各種程式產生器的資料，可得表1。由表 1 得知，唯有介面程式產

生器類別中，Generic Interface Bridge[27]這份文獻及其產生器是符合我們的條件。Generic Interface Bridge 在概念上，可以產生兩個部分，一個是銜接前端辨識器的

Frontend-Interface，另一個是用來銜接後端應用軟體的 Backend-Interface，Generic Interface Bridge 系統藉由這樣的方式，銜接了辨識器與應用軟體。

再回到一開始選擇程式產生器條件的部分，由於本研究是需要取得介面產生器並利 用產生出來的介面程式銜接辨識器與應用軟體兩端，所以選擇以交大軟體工程實驗室所 提出並發表於期刊上的通用橋接介面系統[27](Generic Interface Bridge，以下簡稱 GIB)， 作為本研究的介面產生器。 類別 用途 程式原始碼 例 GUI code generator 使用現有的元件，以視 覺方式產生使用者圖 形介面 商業軟體 無法取得

Visual Studio, Borland C builder UML code generator 將UML 轉換成目標程 式碼 商業軟體 無法取得 ALTOVA, Actifsource, [10], [12], [16] Hardware code generator 由電路圖形的方式產 生cross-compiler 所需 程式或組合語言程式 商業軟體 無法取得 [9], [11], [13], [14], [29] Compiler code generator 產生compiler 所需的 lexical analyzer, syntactic analyzer

部分可取得 _{Lex, Flex, Yacc, bison…,} [28] Interface code generator 產生用於銜接 recognizer 與 application 的介面程 式

可取得 _{Generic interface bridge}

Others 程式語言wrapper 產生SQL 程式碼 其他… 部分可取得 Swig, [15], [17], [18], [31], [47] 表1、程式產生器分類列表(2000-2010)

12

2.2.2 介面產生系統簡介

本章節我們將針對GIB 系統[26][27]架構及其流程作簡單介紹，GIB 系統分為三大部

分，Frontend-Interface, GIB Kernel, Backend-Interface 三個部分，下面會分別對各模組的

功能作說明。圖17 為 GIB 系統的架構流程圖。

圖17、Generic Interface Bridge 系統架構流程圖  Frontend-Interface  Command composer 使用者於使用GIB 系統前，需先利用這個使用者介面模組，設定辨識結果所要 對應到的指令，並將其存於profile 中，最後產生 Frontend-Interface 的程式碼。  Command translation 用於銜接辨識器的部分，接收由辨識器所辨識出來的結果。比對profile 中是否 有以存在的辨識結果及其對應指令。並將該對應指令傳送到GIB Kernel 的部 分。  GIB kernel

 Lexical / Syntactic analyzer & Event Delegation

接受由Command translation 所傳遞來的指令，進行字彙及句法的分析，如該指

令通過分析後是屬於合法指令，則由接下來的Event Delegation 發出事件，通

13  Backend-interface

 Input-device emulator

接受由GIB Kernel 中 Event Delegation 部分所發出的事件，解析及判斷該指令是

要進行哪個硬體裝置的模擬(滑鼠或鍵盤)，找出負責相對應的硬體設備。

 Keyboard & mouse API

使用滑鼠、鍵盤的API 程式，實際模擬滑鼠的移動、點擊或鍵盤敲擊。

使用流程上：

1. 使用者在使用 GIB 系統前，先利用 Frontend-Interface 中的 Command composer 部分

進行判斷結果與對應指令的設定。並將其存於profile 中。

2. 接下來，使用者就可以利用辨識器進行操作，其操作過程經由辨識器辨識出結果後，

送到Command translation 比對是否存在該辨識結果的對應指令

3. 若相對應指令存在，則將該指令傳送到 GIB Kernel 進行字彙與句法的分析，如果該 指令合法，則由Event Delegation 發出事件。

4. 由 Event Delegation 所發出的事件將告訴 Backend-Interface 應該利用滑鼠或鍵盤的 API 程式指揮滑鼠、鍵盤進行什麼樣的動作與應用軟體互動。 使用者就利用這樣子的流程，藉由GIB 系統與應用軟體進行互動。

2.2.3 介面產生系統應用在本研究的限制

當我們實際取得GIB 系統並應用於本研究時，我們發現了原有 GIB 系統上的一些限 制，詳細情況如下：  座標圖層上座標位置對應錯誤 由於過去採用的是語音控制系統，並沒有簡單的移動控制，所以包含滑鼠的移動都 需要由口說指令來達成，所以定位的部分為求方便，是可以設定許多的Tag 作為座 標定位，方便移動到畫面中的某處，而這些Tag 都被放在名為 Stage 的圖層上。 可是這也造成了座標被固定的問題，在螢幕解析度或者視窗大小改變的時候，座標 並不會跟著改變，所以造成了座標偏移的問題。同時也導致了無法正確執行原有指 令執行時產生錯誤。  圖層造成的閃爍問題 同樣因為座標圖層的概念，物件座標等都置放在圖層上，然後再將圖層套用在應用 軟體上，又因.Net Framework 版本及程式本身問題，導致圖層無法順利透明化，產生 在使用應用軟體時的閃爍問題，遮蔽了原有的應用軟體，妨礙使用者執行應用軟體。  鍵盤模擬 原GIB 系統並未實踐鍵盤模擬。

14  LL(0) parser

原GIB 系統所採用的 parser 是 LL(0)的 parser，我們知道在 parser 中 LL(0)是需要 backtracking 的動作，效率低又花費時間，因此這邊改良過去所使用的文法，並將其

重新設計成LL(1)的 parser，希望能改善其執行效率。

 Command composer

原Command composer 的設計，針對對應指令的部分，是必須由開發人員直接鍵入

指令的方式來建構，如此一來對於不了解GIB 文法的人很難撰寫對應指令，且原

Command composer 並無提供錯誤檢查機制，也就是說即便了解了 GIB 文法，開發人

員還是有可能會製作出含有錯誤的指令且未被察覺。以上問題都對事後GIB 系統的 操作及執行，造成了一定的不穩定性。 關於上述的限制，我們都必須加以改善，GIB 系統才能順利的在本研究環境下執行。

2.3 軟體成本估算模型

由Ian Sommerville 的軟體工程[33]一書中提到，專案估算時，是需要評估軟體工程 師生產力的，這將有助於決定專案成本或時程，或是用來評估流程或技術的改善是否有 效。而評估軟體工程師生產力的度量標準，通常是以”與大小有關”(程式碼行數)、”與功 能有關”(功能點數與物件點數)的兩種度量方式。

2.3.1 選擇軟體成本估算模型

軟體工程中，用於估算軟體成本的模型有許多種，依據Magne Jørgensen and Martin

Shepperd 在 2007 年所發表的文獻[21]中可以發現，截至 2004 年，軟體成本估算方法大 致被分為Regression, Expert judgment, Work breakdown, Function point, Theory…等 12 種 不同的估算方法。

其中使用Regression方法的COCOMO II[20][25](COnstructive COst MOdel 2000)模型占 了49%，以及使用Function Point的FPA[24](Function Point Analysis)模型也占了 22%，此兩

種模型占了全部估算方法的70%以上，被廣泛使用。本研究選擇以此兩種模型進行分析，

選擇一種適合本研究的軟體成本估算模型。

首先，如同該文獻的歸類，COCOMO II 模型是一個以經驗為主的模型，這個模型是

從許多軟體專案收集資料，經過資料的分析後再找出最適用的公式。另外，在Lionel C.

15

COCOMO II 模型提供了非常多的參數，這其中包含了專案特型、開發硬體條件、開發人

員經驗與素質等等…，每一個參數都有相對應的數值範圍。藉由統計程式碼行數(Lines Of

source Code, LOC)代入適用的公式與正確的參數，COCOMO II 被廣泛應用於估算軟體開發 成本。使用此估算方式，估算者如何選擇參數數值，將會影響往後估算的結果。 再來，FPA 的估算方式，是以使用者的角度，計算專案程式的功能點數，來估算程 式的規模大小，進而估算軟體開發的成本，此方法並不參酌開發人員經驗、開發硬體環 境、開發工具的熟練度，專案的困難度等等…可能影響估算結果的控制變因。使用此估 算方式，功能點數的計算也會根據估算者的判斷和系統的種類而有所不同[33]。 其餘像是Expert judgment 的估算方式需要請到多位有經驗的專家來進行分析、估算， 本研究無法請到這樣的專家，故此方法亦不是用於本研究。 考慮本研究的許多不確定變因。因此本研究選擇的是COCOMO II 模型，利用參數的 方式調控各種變因，進而希望能達到準確估算開發時間成本的目的。

2.3.2 介紹 COCOMO II 模型

COCOMO 模型於 1981 年提出[25]，歷史悠久，中間經過改良，直到 2000 年推出最

新的COCOMO II.2000[20]版本。我們所採用的是 COCOMO II 的初期設計模型，可用在使

用者確認需求後，初步粗略估算軟體開發成本。COCOMO II 用於初期設計模型的估算公 式如下。

M

Size

A

Effort

=

×

B

×

₍₁₎

∑

=

+

=

5 1

01

.

0

91

.

0

j j

SF

B

(2)

FCIL

SCED

PREX

PERS

PDIF

RUSE

RCPX

M

=

×

×

×

×

×

×

(3) 公式(1)中常數係數 A，將由 COCOMO II 的統計資料作回歸分析得到。如公式(2)，指 數系數B 則由五個因素(Scale Factor)影響，包含過去經驗、開發彈性、風險程序的使用、 團隊向心力、軟體成熟度等。如公式(3)，M 則是依本研究特性而調整的乘數因子，可依 照產品可靠與複雜度(RCPX)、再利用需求(RUSE)、平台困難度(PDIF)、開發人員能力(PERS)、

16 開發人員經驗(PERX)、時程(SCED)、支援設備(FCIL)等…，7 個專案與程序的特性調整參數。 由於COCOMO II 模型是支援瀑布模型及螺旋狀模型進行軟體開發[20]，而瀑布模型 與螺旋狀模型的開發方式，其實包含了有以下部分。  Requirement specification  Design  Implementation  Integrate & Testing  Maintenance

從COCOMO II 的文獻[20]告訴我們，測試及整合階段比重應該在軟體大小成長時增

加，相對的，實作階段比重則應該在軟體增大時減少。同時該文獻及其他資料[19][22]

也顯示，近代軟體開發於各階段所占的比重如表2。

Phase Percentage

Plans & Requirements (LCCR-PRR) 7% Product design (PRR-PDR)

Detail design (PDR-CDR) Code and unit test (CDR-UTC) Integration & Test (UTC-SWAR)

17% 27%-23% 37%-29% 19%-31%

Transition (SWAR-SAR) 12%

表2、Waterfall Phase Distribution Percentages[20]

17

三、介面程式開發方法介紹與比較

本章節將介紹本研究所使用的兩種介面開發方法的流程，並加以比較。

3.1 介面程式開發方法 1 – Hard code

3.1.1 開發流程

如圖18，可以發現使用直接開發方式，開發人員首先必須取得辨識器的程式原始碼， 並加以閱讀、理解。再來才能著手撰寫介面程式。當介面程式撰寫完畢後，將針對不同 的辨識結果去設定不同的滑鼠鍵盤對應命令。設定完成後，才可交付給使用者使用。如 果使用者希望能夠修改辨識結果所代表的意義時，須回到之前的階段，請開發人員修改 程式原始碼。 圖18、直接撰寫開發方式開發流程

18

3.1.2 特色

由上述流程的介紹，可以發現以下特色。  開發人員採用直接撰寫介面程式的開發方法時，首先需要取得辨識器的程式原始 碼後，進行閱讀以及了解辨識器原始程式碼。  開發人員在撰寫介面程式或辨識結果對應動作時，必須要了解如何使用滑鼠及鍵 盤的API 程式  開發人員在決定辨識結果對應動作時，需要用hardcode 的方式撰寫，當使用者 想修改時，也必須去更動原始程式碼

3.2 介面程式開發方法 2 – Via Interface Generator

3.2.1 開發流程

如圖19，可以發現透過介面產生器產生介面程式的開發方式，開發人員不需要了解 及閱讀辨識器的程式原始碼。可是相對的要了解介面產生器的運作方式及其指令的建構。 再來需要的就是操作介面產生器並利用其內建功能建立辨識結果與指令的對應。最後產 生出介面程式，我們在將介面程式放到正確的位置後。即可交付給使用者進行操作。當 使用者希望修改辨識結果代表意義時，則請開發人員修改設定檔。 圖19、使用介面產生器開發方式開發流程

19

3.2.2 特色

 透過介面產生器的開發方式，必須要了解如何使用GIB 系統及 Specification code

的撰寫方法。

 開發人員因為不用直接撰寫介面程式的程式碼，所以在這裡不用了解如何使用滑

鼠及鍵盤的API 程式。

 介面程式的產生方式，在透過介面產生器的方式中，是讀取開發人員所撰寫的 Specification code，藉由 Specification code 中的設定，來產生介面程式。

3.3 開發方法比較

整理上述兩種開發方法的特色，可得表3。 表3、兩種開發方式差異比較表  閱讀及理解辨識器原始程式碼 相較於直接撰寫的開發方式，透過產生器的開發方式不需要直接閱讀辨識器的原始 程式碼；不過相對的，透過介面產生器的開發方式，必須要了解如何使用介面產生 器及Specification code 的撰寫方法。  滑鼠鍵盤API 的學習 相較於直接撰寫的開發方式，透過產生器的開發方式不需要了解如何使用滑鼠及鍵 盤的API 程式，因為在 GIB 中，滑鼠及鍵盤的指令是由開發人員設定，經過指令合 法性檢查後，動作的下達將交由Backend-interface 來進行，所以開發人員只需要寫

20  開發方式

最顯而易見的比較，就是直接撰寫的開發方式需要由開發人員直接撰寫介面程式的 原始程式碼，而使用介面產生器的開發方式，則需要了解如何使用介面產生器、並 撰寫Specification code，而非直接的撰寫程式碼。

21

四、實際開發比較差異

前面章節所提，我們選擇的是將Wiimote 應用於醫療復健的應用軟體作為本研究的 範例[8]，去信詢問數次，請教應用軟體的使用情況以及介面程式的開發時間，該文獻之 作者皆無回信(附錄)。所以本研究尋找了三位碩士級的研究生進行直接開發介面程式的 動作，並同時記錄下開發時間及開發的程式碼行數，以供判斷。最後佐以COCOMO II 模型，估算開發時間成本，驗證實際開發所花費時間的合理性。

4.1 實際開發時間記錄

如表4 我們可以看到，利用直接撰寫介面程式碼的開發方式，第一位開發人員使用 的大約為6 小時、第二位開發人員使用的時間大約為 8 小時、第三位開發人員使用的開 發時間大約為6 小時。以上開發時間均包含學習時間。綜合以上紀錄，三位開發人員的 平均開發時間為7 小時。 另外觀察到，如使用介面產生器的方式開發介面程式，第一位開發人員所花費的時 間為16 分鐘、第二位開發人員所花費的開發時間為 24 分鐘、第三位開發人員所花費的 開發時間為22 分鐘。三位開發人員平均開發時間為 20 分鐘。 表4、開發人員實際用兩種方法開發介面程式所花費時間

4.2 COCOMO II 模型調整

依據2.3.2 節中的分析，採用 COCOMO II 模型估算所需的開發成本，可套用公式(1)。

其中常數係數A，根據 COCOMO II 發明人 Boehm 從龐大的資料集所歸納出的結果，他

推薦在初期設計模式(early design model)時，此係數應為 2.94[33]。指數係數 B 則根據開

發彈性，使用風險解決程序，開發團隊向心力及組織流程成熟度而定，將會落在0.91~1.23

之間[33]。另外，乘數因子 M 是分別由 7 個專案特性所組成，我們作出下面的設定，直

22

PERX=Very High, SCED=Normal, FCIL=Extra High(代表數值詳見附錄)，並代入公式(3)。得 Effort 的公式如下：

19

.

0

94

.

2

×

×

=

B

KLOC

Effort

₍₄₎

同時透介面產生器開方發的乘數因子為RCPX=Normal, RUSE=Normal, PDIF=Low, PERS=Extra High, PERX=Low, SCED=Normal, FCIL=Extra High(代表數值詳見附錄)，並代入公 式(3)。得 Effort 的公式如下：

31

.

0

94

.

2

×

×

=

B

KLOC

Effort

₍₅₎ 另外，由於本研究僅占瀑布型開發流程的code 階段，根據 2.3.2 節的引用資料[20]， 故只取公式(4)(5)的 37%-29%，又程式規模並不算大、難度亦不算高，所以決定 code 階 段占全部成本的37% [20]，故我們重新得到一個公式如下。

%

37

×

= Effort

Effort

_coding (6)

4.3 實際開發行數記錄與 COCOMO II 時間估算

根據我們的紀錄，我們發現第一位開發人員開發介面所使用的程式碼行數大約是 328 行，第二位開發人員開發介面所使用的程式碼行數約為 281 行，第三位開發人員開 發介面所使用的程式碼行數約為262 行。三位開發人員平均開發介面所使用的程式碼行 數約為290 行。相對的，使用介面產生器產生介面程式的方法，是需要撰寫 specification code，又由於我們的應用軟體固定，所指定達成的動作也是固定的，所以三個開發人員 開發所使用的程式碼行數也較固定，都是16 行，得到三個開發人員平均開發的程式碼 行數為16 行。 表5、開發人員實際用兩種方法開發介面程式所花費程式碼行數

23

將程式碼行數(以千行為單位)套用公式(6)，以及 B 以 0.91 及 1.23 套用公式(6)後，

求算出Effort 的上下界。計算出來的 Effort 單位為人月(Man-Month)，為求比較方便，我

們再將此結果依COCOMO II 文獻[20]轉換成人時(1 Man-Month=152 Man-Hour)[20]。最後

我們發現利用COCOMO II 模型估算本研究的開發成本，直接撰寫的方式所估算出來的 Effort 大約在 6.8 小時至 10 小時。而透過介面產生器產生介面程式的開發方式，估算的 Effort 則需要 0.31 小時至 1.18 個小時。詳細計算過程如下。 直接撰寫開發方式 透過介面產生器開發方式 表6、利用 COCOMO II 模型估算的開發時間與實際開發花費時間列表 由以上的實際開發記錄，佐以COCOMO II 模型所估算的軟體開發成本，我們發現實 際開發時間落在估算的範圍之內。因此我們傾向相信這份實際開發結果的數據。不過， 本研究實驗數據樣本尚不足且各參數(包含前面所提的變數因子，以及人月人時的轉換、 coding 所占開發比重)的選擇也需要更精確，才能得到更為準確的數據。所以我們得到以 下結論，利用產生器開發的方式，比直接撰寫的方式有更高的生產力。

(

0.29

)

0.19 0.18[ ] 94 . 2 0.91 man month EffortUpperbound = × × ≈ −

(

0.016

)

0.31 0.005[ ] 94 . 2 1.23 man month Effort_Lowerbound = × × ≈ − hrs Effort

Time_Lowerbound = _Lowerbound ×37%×152≈6.8

hrs Effort

Time_Lowerbound = _Lowerbound ×37%×152≈0.31

(

0.29

)

0.19 0.12[ ] 94 . 2 1.23 man month EffortLowerbound = × × ≈ − hrs Effort

Time_Upperbound = _Upperbound ×37%×152≈10

hrs Effort

Time_Upperbound = _Upperbound ×37%×152≈1.18

(

0.016

)

0.31 0.02[ ]

94 .

2 0.91 man month

24

五、展示

展示我們將分為兩個部分。第一個部分，我們會展示利用直接撰寫介面程式開發方 式所開發介面程式，實際用於銜接辨識器與應用軟體時的互動情況。之後，我們將使用 介面產生器從撰寫specification code 到產生介面程式，到把介面程式建立成 dll 檔，最後 使用的時候同樣能達到操作應用軟體的目標。

5.1 利用 Hard code 方式開發介面程式

Step1.(打開 BlueSoleil) 首先我們先打開藍芽的接收器，這裡我們可以看到Wiimote 的裝置，選擇連線後， 電腦就可以接收到由Wiimote 傳送出來的訊號。 圖20、BlueSoleil(藍芽接收器)啟動畫面

25 Step2.(打開 WiiGLE)

再下來開起辨識器的程式，接收由接收器得到的訊號。

圖21、WiiGLE 啟動 Step3.(點選 Composite Recognizer)

這裡我們選擇Composite Recognizer 的部分，這樣可以同時進行被動辨識及主動辨

識。主動辨識就是當偵測到數值時即時進行的反應。被動辨識就是當我們按下Wiimote

的B 鍵時，進行數值的紀錄並辨識，以辨識使用者的動作。

26 Step4.(選擇 Wiimote & 點 Connection)

選擇要辨識器要連接的Wiimote，出現”Connect”字樣即代表與 Wiimote 的連線成功， 之後可以看到由辨識器偵測出來的數據。藉由這個數據辨識器就可以做出相對應的動作。 像是滑鼠的移動及點擊的動作。 圖23、Wiimote 連結成功 Step5.(選擇可辨識類別) 然後選擇可辨識的手勢類別，這樣就可以針對不同的可辨識手勢做出識別。 圖24、選擇可辨識手勢群組

27 Step6.(點開 Application & 展示)

接下來就可以進行操作。

圖25、辨識器辨識結果與應用軟體畫面展示

5.2 利用程式產生器的方式開發介面程式

Step1. (打開 Command composer)

首先我們藉由GIB 的 Command composer 進行辨識結果與指令對應的設定。

28 Step2. (建新 profile)

建立新的profile 檔。

圖27、Create new profile

當按下Create 後，Profile 資料夾下就會產生產生器所需要的 specification code 檔案。如

圖28 可見，除了該 profile 的命名，尚無任何資料。

圖28、設定前 profile 內容

Step3. 選擇目標的 profile 檔案後，點選 Load。便可把該 profile 讀入我們的 Command composer。由圖 29 框起來的部分也可以發現，當 profile 正確讀入時，該 profile 的正式

名稱也會被update 到使用者介面上。

29

Step4. 首先可以看到，該 profile 完全不含任何可互動的目標程式，所以我們先進行新增

的動作，將目標程式的名稱輸入Program Name 的欄位，同時點 Add。

圖30、新增目標應用軟體 如此一來，該辨識器的動作指令，就只會送到我們希望互動的目標程式。

圖31、目標應用軟體新增成功 Step5. 新增辨識結果對應指令，點選 Gesture Name 的 Add。

圖32、新增目標應用軟體

之後會出現一個彈跳視窗，包含了一個辨識結果所應該對應到的所有動作設定。像 是一個辨識結果有多少個動作組成、是滑鼠還是鍵盤的動作、及指令合成與檢查字彙句

法的機制。如圖33，標示 1 的地方為第一步，產生指令。標示 2 是第二步，進行指令合

30 圖33、新增辨識結果對應指令視窗 新增/更新完一道對應指令的畫面。 圖34、新增對應指令成功並回到 Command composer 主畫面 Step6 依序完成所有對應指令的設定。 圖35、所有對應指令設定完成 1 2 3

31

點選Save 將所有設定正式存入 profile 中。此時可觀察所產生的 specification code。

如圖36 所示，包含了對應應用軟體名稱，辨識結果名稱，辨識結果應對應的動作指令。

圖36、specification code 產出

此時，我們可以進行最後的步驟點選build，依據我們建立的 profile 產生實際的程

式碼(詳見附錄)，同時把該程式碼編譯成 dll 檔。其後將所需要的 dll 檔，搬移到應該放

的對應位置，即完成所有前置作業。

圖37、Generic Interface Bridge dll 檔 產出

之後的操作步驟，如同5.1 的步驟 1~6，此處便不再重複。最後我們可發現，利用

介面產生器所產生的介面程式，同樣可以銜接辨識器與應用軟體，並達到與直接撰寫介 面程式同樣的功能。而且所花費的時間，比起直接撰寫介面程式的方法要少上許多。

32

六、結論與展望

6.1 結論

首先，在進入結論之前，我們先回到本研究一開始的研究目的部分，本研究的目的 是在於尋找兩種介面程式開發方法(直接撰寫介面程式的開發方式、透過程式產生器產 生介面程式的開發方式)在開發介面程式時的差異 而由第三章的地方我們發現，兩種開發方式，在開發流程上的差異，像是直接撰寫 介面程式需要了解辨識器的原始程式碼、了解如何使用滑鼠鍵盤API 的部分，透過產生 器的方法需要了解如何撰寫specification code，介面產生器的使用方法，以及事後維護 上的困難度也不同。 第四章的地方，藉由實際開發介面程式的時間記錄，我們發現了兩種開發方式，開 發所需要的時間成本(這其中包含了實際開發時間以及學習時間)，同時也引用了軟體工 程中常用的軟體成本估算模型，COCOMO II 模型，利用程式碼的數量及各種參數的調整， 估算軟體開發所需要的時間成本，用於佐證實際開發所統計出來的時間是合理的。 第五章的部分，我們也用了兩種不同開發方式，分別開發的介面程式，實際運用在 本研究所選擇的辨識器與應用軟體作為實例。最後，兩者皆可達到同樣的使用目的。 因此我們得到了最後的結論，在本研究的環境限制下，利用介面產生器產生介面程 式的開發方式，比起直接撰寫介面程式的開發方式，是有更高的生產力。但確切數字， 尚須有更大量的數據統計，使實際時間統計能更公平、公正，以及更多準確且可用資訊， 如此COCOMO II 的估算也才能更加準確。

6.2 展望

本研究在此僅討論利用不同的介面程式開發方式後，介面程式開發效率上的比較， 並沒有對產生出來的程式碼品質作深入的探討，未來讓可針對此議題作發展。另外本研 究的開發環境是基於Windows 的環境作開發，未來可針對將介面產生器移植在不同的作 業平台下，可能會面臨的問題進行討論。最後本研究所使用的辨識器是手勢辨識器，人 機介面中尚有許多的辨識器可作討論，例如眼球追蹤辨識器等等…。

33

參考文獻或資料

1. Tian Seng Leong, Jeffrey Lai, Jeffrey Panza, Peter Pong, Jason Hong, Wii Want to Write: An Accelerometer Based Gesture Recognition System, ICREATE’09, pp. 4-7, Pan Pacific KL International Airport Hotel, Malaysia, November 2009.

2. Thomas Schlömer, Benjamin Poppinga, Niels Henze, Susanne Boll, Gesture recognition with a Wii controller, TEI’08, pp. 11-14, Bonn, Germany, Feb 2008

3. Guirao Aguilar, Julian, Breathing as user interface for pulmonary rehabilitation:

respiration tracking using Wii remote controller, University of Tromsø, Master’s Thesis, May 2010

4. Christian Schönauer, Thomas Pintaric, Hannes Kaufmann, Full body interaction for serious games in motor rehabilitation, AH’11, Tokyo, Japan, March 2011

5. Fraser Anderson, Michelle Annett, Walter F Bischof, Lean on Wii: physical rehabilitation with virtual reality Wii peripherals, Studies in Health Technology And Informatics, Vol. 154, pp. 229-234, Studies in Health Technology And Informatics 2010

6. Luc Geurts, Vero Vanden Abeele, Jelle Husson, Frederik Windey, Maarten Van Overveldt, Jan-Henk Annema, Stef Desmet, Digital games for physical therapy: fulfilling the need for calibration and adaption, TEI’11, Funchal, Portugal, 2011

7. Avinash Ramchandani, Kevin Carroll, Roel Buenaventura, Jason Douglas, Justin Liu, Wii-habilitation increases participation in therapy, Virtual Rehabilitation’08, pp. 69, Vancouver Convention & Exhibition Centre, Canada, 2008

8. Jilyan Decker, Harmony Li, Dan Losowyj, Vivek Prakash, Wiihabilitation: Rehabilitation of Wrist Flexion and Extension Using a Wiimote-based Game System, Rutgers University, GSET’09

9. Scharwaechter, Leupers, Ascheid, Meyr, Youn, Yunheung Paek, A code-generator generator for multi-output instruction, CODES+ISSS’07, pp. 131-136, Salzburg, Austria, 2007

10. Iris Groher, Stefan Schulze, Generating Aspect Code from UML Models, 4th _AOSD

Modeling with UML workshop, Boston, USA, 2003

11. Matsumoto T., Matsufuji S., Code generator Implementation on FPGA for an Optical ZCZ Code Using a Sylvester Type Hadamard Matrix, IWSDA’07, pp. 228-232, Chengdu, China, 2007

12. Usman M., Nadeem A., Tai-hoon Kim, UJECTOR: A Tool for Executable Code Generation from UML Models, ASEA’08, pp. 165-170, Hainan Island, China, 2008

13. Bharadwaj J., Chen W.Y., Chuang W., Hoflehner G., Menezes K., Muthukumar K., Pierce J. The Intel IA-64 compiler code generator, Mirco IEEE, Vol20, Issue5, pp. 44-53, 2000

34

RTPA Code Generator, CCECE’06, pp. 434-437, Ottawa, Canada, 2006

15. Fertalj K., Kalpic D., Mornar V., Source code generator based on a proprietary specification language, HICSS’02, pp. 3696-3704, Hawaii, USA, 2002

16. Fertalj K., Mario Brcic, A Source Code Generator based on UML Specification,

INTERNATIONAL JOURNAL OF COMPUTERS AND COMMUNICATIONS, vol2, issue1, pp. 10-19,2008

17. Torsten Grust, Manuel Mayr, Jan Rittinger, Sheriff Sakr, Jens Teubner, A SQL:1999 Code Generator for the Pathfinder XQuery Compiler, ACM SIGMOD’07, pp. 1162-1164, Beijing, China

18. Richards T., Walters E.K., Moss J.E.B., Paimer T., Weems C.C., Towards universal code generator generation, IPDPS’08, pp. 1-8, Miami, USA

19. Vu Nguyen, Barry Boehm, Phongphan Danphitsanuphan, A controlled experiment in assessing and estimating software maintenance tasks, Information and Software Technology, Vol53, issue6, pp. 682-691, 2011

20. Barry W. Boehm, Clark, Horowitz, Brown, Reifer, Chulani, Ray Madachy, Bert Steece, Software Cost Estimation with COCOMO II with Cdrom, Prentice Hall PTR, USA, 2000 21. Jorgensen M., Shepperd M., A systematic Review of software Development Cost

Estimation Studies, vol33, issue1, pp. 33-53, 2007

22. Ye Yang, Mei He, Mingshu Li, Qing Wang, Barry Boehm, Phase distribution of software development effort, ESEM’08, pp. 61-69, Kaiserslautern, Germany, 2008

23. Lionel C. Briand, Isabella Wieczorek, Resource Estimation in Software Engineering, ISERN Technical Report, 2001(appear in the second edition of the Encyclopedia of Software Engineering, Wiley, 2001)

24. Matson J.E., Barrett B.E., Mellichamp J.M., Software development cost estimation using function points, Software Engineering, Vol20, issue4, pp. 275-287, 1994

25. Boehm Barry W., Software Engineering Economics, Software Engineering, SE-10, issue1, pp. 4-21, 1984

26. Jan Karel Ruzicka, 連結語音辨識系統及應用軟體系統之介面語言之設計與實作，國立

交通大學，碩士論文，民國94 年

27. 彭士榮，蔣加洛，陳登吉，A Generic and Visual Interfacing Framework for Bridging the

Interface between Application Systems and Recognizers, Journal of Information Science and Engineering, vol22, issue5, pp. 1077-1091, 2006

28. Florian Brandner, Dietmar Ebner, Andreas Krall, Compiler generation from structural architecture descriptions, CASES’07, pp. 13-22, Salzburg, Austria, 2007

29. Markus Lorenz, Peter Marwedel, Phase Coupled Code Generation for DSPs Using a Genetic Algorithm, DATE’04, pp. 1270-1275, Paris, France, 2004

30. Boris D. Andreev, Edward L. Titlebaum, Eby G. Friedman, Orthogonal code generator for 3G wireless transceivers, GLSVLSI’03, pp. 229-232, Washington D.C., USA, 2003

35

31. Alessandro Bozzon, Sara Comai, Piero Fraternali, Giovanni Toffetti Carughi, Conceptual modeling and code generation for rich internet applications, ICWE’06, Palo Alto, USA, 2006

32. Ben Shneiderman, Catherine Plaisant, Designing the User Interface, 3 edition, Addison Wesley, 1997

33. Ian Sommerville, Software Engineering, 6th edition, Addison Wesley, 2001 34. Wii, http://wii.com/

35. Microsoft Kinect, http://www.xbox.com/zh-TW/kinect

36. G-speak, http://oblong.com/

37. Mgestyk, http://www.mgestyk.com/

38. FingerWorks, http://www.fingerworks.com/

39. HTC sense, http://www.htc.com/tw/htcsense/index.html

40. Simon, http://sourceforge.net/projects/speech2text/

41. Microsoft Speech Recognizer, Microsoft product. http://www.microsoft.com/

42. WiiGLE, http://mm-werkstatt.informatik.uni-augsburg.de/wiigle.html

43. Lee Johnny, Low-Cost Multi-point Interactive Whiteboards Using the Wiimote, http://johnnylee.net/projects/wii/

44. Wiigee, http://www.wiigee.org/

45. Microsoft Visual Studio, Microsoft product, http://www.microsoft.com/

46. Borland C Builder, Embarcadero product, http://www.embarcadero.com/

47. Swig, http://www.swig.org/

36

附錄

附錄一

原 GIB 系統限制–畫面展示

限制一圖例

37 限制五圖例

附錄二

LL(1) table

( ) [ ] move click press then int lclick lDclick rclick Keyin S - - 1 - 2 2 2 - - - - M - - - - 3 4 5 - - - - V 6 - - - - Var - - - 7 8 - - - mVar - - - 10 - - - - cVar - - - 11 12 13 - pVar - - - 14 Grammar Rule: S-> [ S then M V ] | M V

M -> move-to | click-by | press-key V -> ( Var )

Var -> mVar | cVar | pVar mVar -> int,int

cVar -> lclick | lDclick | rclick | … pVar -> {keyin}+

38

附錄三

詢問信件

信件一：

Dear all,

i am Donn, a student of NCTU.

Now i am working on my thesis, it call GIB (generic interface bridge), a kind of interface generator, i hope it to reduce development time if new recognizer publish.

i want to test it with other different recognizer, so i choose gesture recognizer(like wii/kinect...).

i found that you had developed the software with Wii sensor before and use it on rehabilitation. It’s interesting.

may i ask some question?

About how many time you work on this project for each parts.(sensor / interface / software / and others...)

Appreciate for your help. Best Regards,

Donn

信件二：

Dear all,

I am Donn, a student of NCTU. Sorry for disturbing again.

Now i am working on my thesis.

And I am interesting on the topic you wrote, Wiihabilitation.

I want to compare the develop time of interface if I do use interface generator or if I do not.

May I ask how much hours or days you spend on develop the interface between Wii and habilitation application?

Appreciate for your help. Best Regards,

39

附錄四

Specification Code

<!-- Auto-Generate by XmlWriter for GIB --> <trainner name="DemoThesis">

<target_program name="PingPongGame" type=""> <gesture>RightUp</gesture> <command>press-key (e)</command> <gesture>RightDown</gesture> <command>press-key (c)</command> <gesture>LeftUp</gesture> <command>press-key (q)</command> <gesture>LeftDown</gesture> <command>press-key (z)</command> </target_program> </trainner>

附錄五

COCOMO II.2000 Scale Factor Value and

Calibrated Early Design Model Values[20]

Scale Factors

Scale Factors Very Low Low Nominal High Very High Extra High

PREC 6.20 4.96 3.72 2.48 1.24 0.00 FLEX 5.07 4.05 3.04 2.03 1.01 0.00 RESL 7.07 5.65 4.24 2.83 1.41 0.00 TEAM 5.48 4.38 3.29 2.19 1.10 0.00 PMAT 7.80 6.24 4.68 3.12 1.56 0.00 Calibrated Values

Driver Extra Low Very Low Low Normal High Very High Extra High

RCPX 0.49 0.60 0.83 1 1.33 1.91 2.72 RUSE 0.95 1 1.07 1.15 1.24 PDIF 0.87 1 1.29 1.81 2.61 PERS 2.12 1.62 1.26 1 0.83 0.63 0.5 PREX 1.59 1.33 1.12 1 0.87 0.74 0.62 FCIL 1.43 1.3 1.1 1 0.87 0.73 0.62 SCED 1.43 1.14 1 1 1