應用模型驅動架構於多平台導引精靈程式開發 - 政大學術集成

全文

(1)國立政治大學資訊科學系 Department of Computer Science National Chengchi University 碩士論文 Master’s Thesis. 立. 政治大. ‧ 國. 學. 應用模型驅動架構於多平台導引精靈程式開發. ‧. Apply Model-Driven Architecture to. y. Nat. n. al. er. io. sit. the Development of Multi-Platform Wizards. Ch. engchi. i n U. 研究生: 郭建宏指導教授: 陳正佳. 中華民國一○一年一月 January 2012. v.

(2) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(3) 應用模型驅動架構於多平台導引精靈程式開發 Apply Model-Driven Architecture to the Development of Multi-Platform Wizards. 研究生：郭建宏. Student：Kuo Chien-Hung. 指導教授：陳正佳. Advisor：Chen Cheng-Chia. 立. 政治大. ‧ 國. 學. 國立政治大學資訊科學系. ‧. 碩士論文. A Thesis. er. io. sit. y. Nat. al. n. v i n submitted to Department of Computer Science Ch engchi U National Chengchi University. in partial fulfillment of the Requirements for the degree of Master in Computer Science. 中華民國一○一年一月 January 2012.

(4) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v.

(5) 應用模型驅動架構於多平台導引精靈程式開發. 摘要導引精靈(wizard)是一種用來收集用戶端資料的互動式使用者介面應用程式，常被廣泛的使用在軟體系統裡，也是大多數應用程式常見的功能之一。導引精靈的使用不僅簡化了複雜的資料收集過程，也可以避免資料的遺漏以確保收集資料的. 政治大還可以提高資料收集的正確性，所以導引精靈對於應用程式的資料收集是相當有立. 完整性；此外在資料收集的過程中導引精靈所提供的適當提示與即時資料驗證，. 用的。. ‧ 國. 學. 本研究的目標是開發一個模型驅動的導引精靈開發系統，希望能在相同或不. ‧. 相同的時間裡快速建構多平台導引精靈程式。我們提出的系統稱為MoDWiz，它實. y. Nat. 現了應用「模型驅動架構(MDA)」於多平台導引精靈開發的所有工具支援。為了. er. io. sit. 讓使用者建構自己的(平台無關)導引精靈模型，MoDWiz不僅提供了用以規範導引精靈的超模型，還制定一個特定領域語言WDL以作為此超模型的具體語法。此外，. al. n. v i n Ch 由於WDL的制定，我們得以提供專屬的編輯器以輔助使用者進行導引精靈模型的 engchi U. 編輯。目前MoDWiz支援三種執行平台的導引精靈開發，分別為網頁應用程式、 Eclipse與Java。而根據MDA理論，我們必須制定的三種平台超模型均已內含於 MoDWiz。除此之外，MoDWiz的工具鏈還包括用來將平台無關導引精靈模型轉換成符合每一個特定平台導引精靈模型的M2M工具，以及將每一個特定平台導引精靈模型轉換成相對應實作的M2T工具。所有MoDWiz的工具與WDL編輯器程式均實作為 Eclipse 外掛程式，因此能夠與Eclipse平台高度整合。當利用WDL編輯器完成導引精靈模型的製作之後，使用者只需透過簡單的滑鼠點擊就可以完成導引精靈程式的實作。 i.

(6) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. ii. i n U. v.

(7) Apply Model-Driven Architecture to the Development of Multi-Platform Wizards Abstract A wizard is an interactive user interface program used to collect data from the user. It is widely used in software systems and is a common part of most applications. Not only does the use of wizards modularize and simplify complex data collection process, but it can also avoid data missing and ensure data integrity. Furthermore, during the. 政治大. process of data collection, since a wizard can provide tips and instant data validation it can also improve the correctness of collected data. As a conclusion, it is very. 立. beneficial to use wizards in an application.. ‧ 國. 學. The goal of this research is the development of a model-driven wizard generation system (MoDWiz) that can be used to help rapid construction of multi-platform. ‧. wizards to be developed at different or the same time. MoDWiz is our solution to the problem of applying OMG's model-driven architecture (MDA) to the development of. sit. y. Nat. multi-platform wizards. In order for the user to construct his (platform independent) wizard model, MoDWiz provides not only a wizard metamodel but also a domain. io. a. er. specific language (DSL) called WDL as a concrete syntax of the metamodel. Owing to. n. i v editor to help the user the availability of WDL, we are l able to provide also a friendly to edit his wizard models.. n U MoDWiz supports en g c h ati present. Ch. three platforms: eclipse. platform, web application platform and plain Java platform. Accordingly metamodels of wizards for these platforms have to be defined and indeed have been provided in MoDWiz. Apart from these, MoDWiz's tool chain includes also M2M tools, which could transform every platform independent wizard model into a corresponding PSM model for each platform, as well as M2T tools, which could transform every platform specific wizard model into a corresponding implementation. All of MoDWiz's tools and wizard editor are implemented as eclipse plug-ins and thus are highly integrated with eclipse. As a result it is very easy to get a wizard implementation by simple mouse clicks once its model has been constructed using MoDWiz.. iii.

(8) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. iv. i n U. v.

(9) 謝誌在政大資科研究所的三年半裡，是我求學生涯中收穫最豐富的時期。在這期間讓我了解到付出與得到的或許不一定能成正比，但如果什麼都不做，就得不到任何東西。在研究的過程中也是如此，沒有試過怎麼知道這個方法可不可行呢? 在學習過程中幸蒙. 陳正佳老師的耐心教誨，包括對於研究方向的訂定、基. 本觀念的建立以及最後研究目標的實現與論文撰寫，各階段都受益匪淺。在論文口試期間，承蒙淡江大學資訊與圖書館學系歐陽崇榮老師，以及世新大學資訊. 政治大. 管理學系鄭武堯老師的鼓勵，並指引學生由不同的角度看待本研究成果在應用. 立. 上的可能性、指明學生論文上的疏漏之處，使得本論文可更臻完善。接著感謝實. ‧ 國. 學. 驗室裡的每一位學長，在我研究過程中遇到困難時給予我意見與鼓勵，啟發我在. 程中遇到瓶頸心情低落時，陪我一起打球聊天。. Nat. sit. y. ‧. 論文研究與寫作上的諸多想法，也感謝其他實驗室的同學與學弟妹，在我研究過. 最後是感謝我的家人，爸爸、姊姊、阿姨與小阿姨，因為有他們的關懷與支. er. io. 持，才能讓我將大部分的時間專注於學業與研究工作上，完成此項研究。特別是 a. n. iv l C n 徐秀菊女士，從台南來台北求學的這幾年，非常地感謝她就像我的 hengchi U. 我的阿姨 -. 媽媽一樣，對我無微不至的照顧，讓我在台北也能有一個像家一樣溫暖的地方，謝謝你。. 郭建宏僅致於政治大學資訊科學研究所中華民國一○一年一月. v.

(10) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. vi. i n U. v.

(11) 目錄摘要 ................................................................................................................................. i Abstract ......................................................................................................................... iii 謝誌 ................................................................................................................................ v 1 ......................................................................................................................................1 研究問題 ........................................................................................................................1 1.1. 研究背景與動機......................................................................................... 1. 1.2. 研究目的..................................................................................................... 3. 章節架構..................................................................................................... 6. 學. 1.4. ‧ 國. 1.3. 政治大論文貢獻與特色立......................................................................................... 5. 2 ......................................................................................................................................7. ‧. 相關研究 ........................................................................................................................7 Model-Driven Architecture, MDA......................................................... 7. 2.2. Eclipse 平台與相關工具....................................................................... 11. y. sit. v. Eclipse ........................................................................................11. 2.2.2. Eclipse Modeling Framework, EMF ........................................13. 2.2.3. Xtext ............................................................................................15. n. 2.2.1. Ch. engchi. i n U. 模型轉換工具........................................................................................... 16 2.3.1. 2.4. al. er. io. 2.3. Nat. 2.1. Xtend ............................................................................................16. 相關系統回顧........................................................................................... 19. 3 ....................................................................................................................................23 系統架構與實作 ..........................................................................................................23 3.1. 系統架構................................................................................................... 24. 3.2. 系統實作................................................................................................... 25 vii.

(12) 3.2.1. 超模型的建立 ............................................................................. 25. 3.2.2. 模型的轉換 ................................................................................. 26. 4 ................................................................................................................................... 31 導引精靈結構分析與超模型 ..................................................................................... 31 4.1. 平台無關導引精靈 ................................................................................... 31. 4.2. 平台專屬導引精靈 ................................................................................... 35 4.2.1. 網頁應用程式導引精靈模型 ..................................................... 35. 4.2.2. Java 導引精靈模型 ................................................................... 39. 4.2.3. 政治大 Eclipse 導引精靈模型 ............................................................. 44 立. 5 ................................................................................................................................... 49. ‧ 國. 學. 導引精靈模型轉換 ..................................................................................................... 49 模型與模型之間的轉換規則 ................................................................... 49. y. sit. io. 5.1.3. Eclipse 導引精靈模型轉換規則 .............................................. 59. 5.2.1. 網頁應用程式導引精靈模型轉換範本 ..................................... 64. 5.2.2. Java 導引精靈模型轉換範本 ................................................... 64. 5.2.3. Eclipse 導引精靈模型轉換範本 ............................................. 65. al. v i n Ch 模型與程式碼之間的轉換規則 ............................................................... 63 engchi U n. 5.2. Java 導引精靈模型轉換規則 .................................................... 54. er. 5.1.2. 網頁應用程式導引精靈模型轉換規則 ..................................... 50. Nat. 5.1.1. ‧. 5.1. 6 ................................................................................................................................... 67 系統操作 ..................................................................................................................... 67 6.1. 執行環境與系統安裝 ............................................................................... 67. 6.2. 導引精靈描述語言(WDL) ......................................................................... 69. 6.3. MoDWiz 系統操作流程 .............................................................................. 72 viii.

(13) 7 ....................................................................................................................................77 結論與未來研究方向 ..................................................................................................77 7.1. 結論........................................................................................................... 77. 7.2. 未來研究方向........................................................................................... 78 7.2.1. 條件式導引精靈結構 ..................................................................78. 7.2.2. 客製化文件 ..................................................................................79. 參考文獻 ......................................................................................................................81. 政治大附錄 B Java 導引精靈範本 ........................................................................................91 立附錄 A 網頁應用程式導引精靈範本 .........................................................................83. 附錄 C Eclipse 導引精靈範本 ..................................................................................97. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. ix. i n U. v.

(14) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. x. i n U. v.

(15) 圖目錄圖 1.1：一般程式的開發流程 ......................................................................................2 圖 1.2：一般程式的開發流程應用於多平台導引精靈程式開發 ..............................2 圖 1.3：MDA 系統的開發架構.....................................................................................3 圖 1.4：應用 MDA 於多平台導引精靈程式開發........................................................3. 圖 2.1：MDA 概念圖[01] ..............................................................................................8. 政治大圖 2.3：XMI in MDA ....................................................................................................10 立. 圖 2.2：以 MOF 為基礎的四層 MDA 架構圖..............................................................9. 圖 2.4：Eclipse 平台架構圖........................................................................................12. ‧ 國. 學. 圖 3.1：MoDWiz 系統架構 .........................................................................................23. ‧. 圖 3.2：MDA 的模型關係圖.......................................................................................25. y. Nat. sit. 圖 3.3：模型與模型之間的轉換意識圖....................................................................27. n. al. er. io. 圖 3.4：模型與程式碼之間的轉換意識圖 ................................................................28. Ch. engchi. i n U. v. 圖 4.1：平台無關的導引精靈超模型 ........................................................................32 圖 4.2：平台無關導引精靈的 Ecore 模型.................................................................34 圖 4.3：平台專屬的網頁應用程式導引精靈超模型 ................................................36 圖 4.4：平台專屬的網頁應用程式導引精靈 Ecore 模型.........................................39 圖 4.5：平台專屬的 Java 導引精靈超模型 ...............................................................40 圖 4.6：平台專屬的 Java 導引精靈 Ecore 模型 ........................................................43 圖 4.7：平台專屬的 Eclipse 導引精靈超模型...........................................................45 圖 4.8：平台專屬的 Eclipse 導引精靈 Ecore 模型....................................................48. xi.

(16) 圖 5.1：網頁應用程式導引精靈的頁面結構轉換示意圖 ....................................... 50 圖 5.2：TextInput 的網頁應用程式導引精靈轉換示意圖 ....................................... 51 圖 5.3：MultipleChoice 的網頁應用程式導引精靈轉換示意圖 .............................. 52 圖 5.4：Dialog 的網頁應用程式導引精靈轉換示意圖 ............................................ 52 圖 5.5：GroupQuestion 的網頁應用程式導引精靈轉換示意圖.............................. 53 圖 5.6：Question 裡 helpmsg 屬性的網頁應用程式導引精靈轉換示意圖 ............ 53 圖 5.7：Validation 的網頁應用程式導引精靈轉換示意圖 ...................................... 54. 政治大圖 5.9：TextInput 的 Java 導引精靈轉換示意圖 ...................................................... 55 立圖 5.8：Java 導引精靈的頁面結構轉換示意圖 ....................................................... 54. 圖 5.10：MultipleChoice 的 Java 導引精靈轉換示意圖(1)....................................... 56. ‧ 國. 學. 圖 5.11：MultipleChoice 的 Java 導引精靈轉換示意圖(2)....................................... 57. ‧. 圖 5.12：Dialog 的 Java 導引精靈轉換圖示意 ......................................................... 57. y. Nat. 圖 5.13：GroupQuestion 的 Java 導引精靈轉換示意圖 ........................................... 58. er. io. sit. 圖 5.14：ErrorMessage & Validation 的 Java 導引精靈轉換示意圖 ........................ 58 圖 5.15：Eclipse 導引精靈的頁面結構轉換示意圖 ................................................. 59. al. n. v i n Ch 圖 5.16：TextInput 的 Eclipse 導引精靈轉換示意圖 ................................................ 60 engchi U 圖 5.17：MultipleChoice 的 Eclipse 導引精靈轉換示意圖 ....................................... 61 圖 5.18：Dialog 的 Eclipse 導引精靈轉換示意圖..................................................... 62 圖 5.19：GroupQuestion 的 Eclipse 導引精靈轉換示意圖 ...................................... 62 圖 5.20：Question 裡 helpmsg 屬性的 Eclipse 導引精靈轉換示意圖 ..................... 63 圖 5.21：Validation 的 Eclipse 導引精靈轉換示意圖............................................... 63. 圖 6.1：MoDWiz SDK Plugin 安裝 .............................................................................. 68 圖 6.2：Eclipse 已安裝的 Plugins 內容...................................................................... 69 圖 6.3：Question 的顯示樣式 ................................................................................... 71 xii.

(17) 圖 6.4：WDL 導引精靈程式範例 ...............................................................................73 圖 6.5：MoDWiz 導引精靈產生器 .............................................................................74 圖 6.6：Eclipse 導引精靈程式範例............................................................................74 圖 6.7：Java 導引精靈程式範例 ................................................................................75 圖 6.8：網頁應用程式導引精靈程式範例 ................................................................76. 圖 7.1：線性導引精靈流程 ........................................................................................78 圖 7.2：條件式導引精靈流程 ....................................................................................79. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. xiii. i n U. v.

(18) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. xiv. i n U. v.

(19) 表目錄表 1.1：一般程式開發流程與 MDA 之比較................................................................4. 表 2.1：基本 Xtend 程式結構 ....................................................................................17 表 2.2：Create 函式範例 ............................................................................................18 表 2.3：Rich Strings 範例 ...........................................................................................19 表 2.4：MoDWiz 與相關系統[07]之比較 ..................................................................21. 政治大. 表 6.1：宣告一個導引精靈程式的語法 ....................................................................70. 立. 表 6.2：宣告一個導引精靈頁面的語法 ....................................................................70. ‧ 國. 學. 表 6.3：宣告一個 Question 與 GroupQuestion 的語法 ............................................71 表 6.4：宣告一個 help 與 validation 的語法.............................................................72. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. xv. i n U. v.

(20) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. xvi. i n U. v.

(21) 1. 研究問題. 立研究背景與動機. ‧ 國. 學. 1.1. 政治大. ‧. 在許多電腦應用程式中，都會需要從使用者端進行資料收集，然而由於使用者對於系統. sit. y. Nat. 資料型態與格式的無知，因此通常無法正確而且完整的輸入系統所需的資料。此外對電. io. er. 腦來說，不同的資料型態與輸入格式容易造成資料的辨識與存取上的困難，因此如果電腦能在使用者進行資料輸入的同時給予適當的導引與提示，不但可以提高資料的可用性，. al. n. v i n Ch 也可以增加使用者資料輸入的便利性。基於此種原因大多的應用程式都會採取此種與使 engchi U 用者互動的方式進行資料收集。利用此方式進行資料收集的互動程式我們稱之為「導引. 精靈」（Wizard）。導引精靈程式的使用，不但可以把複雜的資料收集過程變得簡單，還可以減少資料收集過程中資料的遺漏以確保資料的完整性，並且在導引使用者輸入資料的同時提供適當提示與資料的驗證，也可以增加資料收集的正確性。由於導引精靈能提供一個有效率的方式來進行資料收集，因此在許多不同的平台上都會需要用到導引精靈，但想要在不同的平台上開發導引精靈程式卻是一件複雜且具重複性的工作。圖 1.1 顯示了一般程式的開發流程，一般的程式開發首先是系統需求的分析，接著進行系統分析也就是針對使用者的需求對程式進行功能上的設計，以及整個系 1.

(22) 圖 1.1：一般程式的開發流程。統的流程規劃，這是一種與平台無關的分析。接著進行系統的設計，特別針對執行平台的特性進行個別的設計，這是一種與平台相關的分析，最後才是依平台執行的程式語言進行程式碼的撰寫。將一般程式開發流程應用於多平台導引精靈開發時，如圖 1.2 顯示，可以發現程式開發者必須在同一平台上對不同軟體系統進行多次的系統設計，而每一次. 政治大. 的系統設計都是極類似且具重複性的；當需要開發新的導引精靈程式時，就必須在每一. 立. 個平台針對此精靈程式再進行一次系統設計；有新的平台加入則必須對每一個既有導引. ‧ 國. 學. 精靈程式在新的平台上進行系統設計；導引精靈程式需要版本更新時，程式開發者就必須再重頭進行一次程式開發流程。綜合以上分析，我們發現在多平台上進行多個系統開. ‧. 發時，其過程充滿重複性，而 MDA[01]的主要目的就是希望能免除和類似系統在多平台. Nat. sit. y. 上開發的重複性，因此本研究嘗試應用 MDA 的概念進行導引精靈程式的開發，希望可以. n. al. er. io. 有效降低所需程式的分析與設計上的重複性進而減輕精靈程式開發的複雜度。. Ch. engchi. i n U. v. 圖 1.2：一般程式的開發流程應用於多平台導引精靈程式開發。. 2.

(23) 1.2. 研究目的. 圖 1.3：MDA 系統的開發架構。模型驅動架構（Model-Driven Architecture, MDA）[01]，是由 OMG（Object Management Group）[02]所提出的系統開發架構，主要的概念是以模型作為系統開發的核心，至於. 政治大發者必須先對應用領域進行分析，設計出符合特定應用領域的「平台無關超模型」立. 實作以及其他相關軟件則由此模型推演而生。圖 1.3 為 MDA 系統的開發架構圖，系統開. ‧ 國. 學. （Platform Independent Metamodel, PIMM）作為使用者進行標的領域模型(PIM)開發的標準，接著系統開發者還須對採用的執行平台進行分析，以便建立屬於標的執行平台. ‧. 的「平台專屬超模型」（Platform Specific Metamodel, PSMM），用以作為標的執行. sit. y. Nat. 平台系統模型(PSM)描述的標準。最後建立相關的系統輔助工具，讓使用者在完成系統. al. er. io. 的模型(PIM)設計後，只需透過輔助模型轉換工具，即可立即產生符合特定執行平台的. v. n. 系統模型(PSM)，接著再透過程式碼產生器，就可以自動產生對應平台的程式碼實作。. Ch. engchi. i n U. 圖 1.4：應用 MDA 於多平台導引精靈程式開發。 3.

(24) 應用 MDA 於多平台導引精靈程式開發時，如圖 1.4 所示，必須先建構導引精靈的 PIMM 作為所有導引精靈的開發標準，接著對不同的執行平台建構導引精靈的 PSMM 作為特定平台導引精靈的描述標準，最後建構相關的電腦輔助工具與程式碼產生器，完成導引精靈開發系統的建構。由於此開發架構是將設計好的 PIM 透過電腦輔助工具轉換成 PSM 自動完成系統的設計，也就是說程式開發者只須進行一次特定平台的系統設計並且將輔助工具建立好，就可以完成所有精靈程式對此平台的系統設計。因此當有新的導引精靈程式加入時，完成 PIM 設計就可以馬上透過輔助工具自動進行系統的設計(產生 PSM)；新. 政治大程式需要進行修改時，只需修改 PIM 再透過輔助工具產生新的 PSM 即可，不必全部都重立的平台加入時只須進行一次的系統設計，就可以完成對所有精靈程式的系統設計；精靈. 新來過。透過表 1.1 的比較可以發現，使用 MDA 進行系統的開發，只需對每一個執行平. ‧ 國. 學. 台作一次系統設計建立 PSMM 即可，相對的一般程式開發流程，則會被開發程式的個數. ‧. 所影響，因此 MDA 有效的減少對平台設計的重複性與程式開發的複雜度。. Nat. sit. y. 所以本研究的目的是遵循 OMG 的模型驅動架構，開發一個模型驅動的導引精靈開發. n. al. er. io. 系統，我們將此開發出來的系統稱為 MoDWiz。利用 MoDWiz 我們可以同時或不同時的快速建構多平台導引精靈程式。. Ch. *將 M 個系統開發於 N 個平台上時. engchi. i n U. v. 一般開發流程. MDA. 系統分析次數. M次. M次. 系統設計次數. M*N 次. N次. 加入新系統(M+1)的系統設計次數. N次. 零次. 加入新平台(N+1)的系統設計次數. M次. 一次. 系統更新. 須重頭來過. 只需修改 PIM. 表 1.1：一般程式開發流程與 MDA 之比較。 4.

(25) 1.3. 論文貢獻與特色. 本論文研究，主要是在Eclipse平台上建立多平台導引精靈程式開發系統，透過模型驅動架構（Model-Driven Architecture, MDA）作為系統的核心理論，簡化在多個平台上開發導引精靈程式的過程，以下是本系統的貢獻與特色: •. 建立包括「平台無關」與「平台專屬」的導引精靈超模型，以便於對導引精靈系統進行塑模設計。 . 平台無關導引精靈超模型主要是用來描述導引精靈程式的目的、結構與行為，. 政治大. 可作為一般導引機靈模型的描述規範。. 立. 平台專屬導引精靈超模型則是用來描述導引精靈程式在某個特定平台上執行. 學. ‧ 國. . 的特性，可作為特定平台導引精靈模型的描述規範，在本系統裡的導引精靈執. 提供完整的導引精靈程式開發輔助工具，包括「平台無關導引精靈的特定領域語言」. y. Nat. io. . sit. 與「模型的轉換規則建立」：. 為了方便使用者輸入或編輯平台無關導引精靈模型，我們設計了一個專屬的特. n. al. er. •. ‧. 行平台共有三種，其中包含網頁應用程式平台、Eclipse 平台與 Java 平台。. Ch. i n U. v. 定領域語言(WDL)並提供了類似 Java JDT 的 WDL 專屬編輯環境，提高使用者對導引精靈模型的編輯效率。 . engchi. 建立「平台無關」與「平台專屬」導引精靈模型之間的轉換規則，讓程式開發者能夠透過我們的程式開發輔助工具，自動將平台無關導引精靈模型轉換成符合特定執行平台的平台專屬導引精靈模型。. . 最後是建立每一個平台專屬導引精靈模型的程式碼產生器，透過程式碼產生器自動產生符合各執行平台的導引精靈程式。. 5.

(26) 1.4. 章節架構. 首先是第一章節介紹本研究的動機與目的，接著第二章節介紹本次研究使用到的相關理論與技術，包括 MDA(Model-Driven Architecture) [01]系統架構與 Eclipse[03]開發平台，以及相關的模型開發工具 EMF(Eclipse Modeling Framework)[04]、Xtext[05] 與模型轉換工具 Xtend[06]，最後是既有系統回顧。接著第三章節介紹本系統的架構與實作，系統架構說明如何將 MDA 架構應用於多平. 政治大 Plug-ins 模型開發工具進行系統的實作。接著第四章節介紹一般導引精靈與特定平台導立. 台導引精靈程式開發系統，系統實作則是說明如何透過 Eclipse 平台與 Eclipse 相關的. ‧ 國. 學. 引精靈的結構分析與如何建構符合其規範的導引精靈超模型。接著第五章節介紹如何透過模型轉換將平台無關的導引精靈模型轉換成可執行的特定平台導引精靈程式，詳細說. ‧. 明模型的轉換規則包括「模型與模型之間的轉換規則」與「模型與程式碼之間的轉換規. sit. y. Nat. 則」兩個部分。. n. al. er. io. 接著第六章節介紹如何在 Eclipse 平台上，利用我們的多平台導引精靈開發系統. i n U. v. MoDWiz(MOdel-Driven WIZard Generating system)，進行多平台導引精靈程式開發的. Ch. engchi. 操作流程。最後在第七章節提出我們的結論與未來研究方向。. 6.

(27) 2. 相關研究. 立. 政治大. ‧ 國. 學. 此章節主要介紹本次研究使用到的相關理論與技術，本研究希望以 MDA 做為多平台導引精靈程式開發的核心理論，並利用 Eclipse[03]做為系統開發的主要平台，所以首先會. ‧. 介紹 MDA 的概念與具體的架構，接著是 Eclipse 平台與相關工具的介紹包括 EMF(Eclipse. y. sit. n. al. er. io. 後是既有系統回顧。. Nat. Modeling Framework)[04]與 Xtext[05]，還有模型轉換的相關工具介紹 Xtend[06]，最. 2.1. Ch. engchi. i n U. v. Model-Driven Architecture, MDA. 現今的軟體開發均是以程式碼為中心，亦即所有的系統分析與系統設計的結果均混合於程式碼之內。由於程式碼的分離程度不足無法區分何者屬於平台無關的部分，以及何者為與平台相關的程式碼，因此重複使用性低為了解決此問題，OMG組織提出了MDA架構希望能改善此問題。從程式語言的抽象化程度來看，早期低階的組合語言（assembly language）是透過「組譯器」（assembler）將程式碼轉換成硬體可以執行的機器碼。而高階的程式語言（例如C/C++, Java）則是透過「編譯器」（compiler）將程式碼轉換成組合代碼（assembly code），再透過組譯器的支援轉換成機器碼。到近期的MDA架 7.

(28) 構，主要是利用建立模型的方式進行程式的設計，然後透過「模型編譯器」（model compiler）將模型轉換成一般的高階語言程式碼，再透過編譯器的支援得到可執行的機器碼，所以MDA架構將系統開發的中心由高階語言的程式往上提升至更抽象化的模型層次。再從可重複使用性來看，早期的組合語言以巨集（macro）的方式來達到重複使用的效果，而在高階語言裡則以函數（function）的方式來進行，直到物件導向程式設計（Object-Oriented Programming）的出現，才以類別（class）的資料結構來達到程式. 政治大. 碼的重複使用性。從巨集到類別的使用其主要的目標都是往如何提高模組化、抽象化的. 立. 設計理念去發展，藉此來降低程式碼之間的相依性並且提高互通性，所以MDA使用模型. ‧ 國. 學. 的方式來提高程式的抽象化層次與重複使用性，希望能讓程式開發者能更專注在使用者的需求上進行程式的設計與開發，降低直接進行程式碼撰寫的負擔。. ‧. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 2.1：MDA 概念圖[01] 。 MDA的主要概念是以模型作為系統開發的核心，如圖2.1所示，在進行系統分析時利用一個互通的模型標準描述語言，如UML[08]、MOF[09]或Ecore[10]等模型語言，來進 8.

(29) 行整個系統的描述與設計，其主要目的是希望不要被特定的模型描述方式所限制，接著再利用相關的模型工具，將模型自動轉換成符合各個平台特性的程式碼，如Java、.NET 或Web Services等。並且希望能夠透過MDA的系統開發的流程，將它應用在不同領域裡，提供一個快速且有效率的方式產生各種相關的應用程式為最主要的目的，讓就算是不懂 Java語言的程式開發者，也能寫出Java程式。. 立. 政治大. ‧. ‧ 國. 學. io. sit. y. Nat. n. al. er. 圖 2.2：以 MOF 為基礎的四層 MDA 架構圖。. Ch. engchi. i n U. v. MDA 的基礎架構，如圖 2.2 所示，主要是由一個超模型架構（ Meta-Modeling Architecture）與幾個OMG制定的相關模型標準所組成，超模型架構主要是以抽象化的程度來做區分的標準，分為四層越上層表示抽象化的程度越高，從最上層開始分別是M3 層（meta-metamodel）、M2層（metamodel）、M1層（model）與最下層的M0層（instance），相關的模型標準包含UML（Unified Modeling Language）、MOF（Meta-Object Facility）與XMI（XML Metadata Interchange）[11]。 M3層主要是定義整個超模型架構的標準，也就是所謂的Metametamodel，所有的 Metamodel(超模型)都必須符合他的規範。為此OMG提出了MOF（Meta-Object Facility）來做為Metamodel的標準。MOF本身具有自我描述的能力，可以定義自己與所有的超模型， 9.

(30) 但除了MOF之外，EMF（Eclipse Modeling Framework）[04]裡的Ecore模型也是常被用來定義超模型。M2層Model，指的是所有使用MOF定義的Metamodel，主要是用來規定模型的種類、屬性、格式與關聯性，並且限制模型的描述範圍。其中最常被使用的Metamodel 就是UML，是由OMG所提出的圖形化模型語言，由於UML是一種開放式的方法，並且在對大範圍且複雜的系統進行模型化已有不錯的效果，因此漸漸的成為被大家公認的一種標準。M1層Model，指的是利用在M2層定義出來的Metamodel，將欲開發的程式以Model的方式加以描述。M0層Model包含的則是M1層Model的實例（instances）。如果與一般程. 政治大設計出來的類別 (class) 或程式，至於 M0物件則是程式執行所產生的實例，至於立. 式語言來對應的話，Metamodel就是程式語言(如C/C++、Java)，而Model則是程式語言. Metametamodel則相似於定義語言的文法描述系統。. ‧ 國. 學. 在整個超模型架構中，對於模型資料的儲存與各層之間訊息的互通，XMI（XML. ‧. Metadata Interchange）扮演著一個極重要的角色，當MDA的系統開發者將相關的模型. Nat. sit. y. 設計完成後，必須對相關的模型資料進行儲存。XMI定義了符合MOF規定的相關對應關係，. n. al. er. io. 如圖2.3所示，屬於M2 Layer的Metamodel與XML Schema之間的對應關係，以及屬於M1. i n U. v. Layer的Model與XML文件檔案之間的對應關係。透過這樣的關係建立，可以把建立好的. Ch. engchi. 模型轉換成XML檔，以利於提高儲存與讀取的便利性。. 圖 2.3：XMI in MDA.. 10.

(31) MDA的系統開發流程，必須先從使用者的角度對應用領域進行分析，然後利用UML、 MOF、或Ecore等模型語言建立應用領域的「平台無關超模型」（Platform Independent Metamodel, PIMM）做為使用者進行系統模型(PIM)開發的標準。接著對相關的執行平台進行分析與定義建立「平台專屬超模型」（Platform Specific Metamodel, PSMM）作為特定平台系統模型(PSM)描述的標準，每一個PSMM都會對應到特定的程式語言或執行平台（例如Java、Web Application…等），這樣的系統開發方式減少了系統與實作平台之間的相依性。最後利用模型轉換工具建立PIMM與PSMM之間對應關係的轉換規則，將. 政治大計，接著對PSMM設計專屬的程式碼產生器，即可將PSM自動轉換成特定平台的系統實作。立使用者設計好的PIM轉換成符合某個特定執行平台的PSM，這樣就可以自動完成系統的設. 透過這樣方式進行系統開發，使用者只需要專注在系統的需求上進行系統分析即可，減. ‧ 國. 學. 少了系統設計與程式碼撰寫的負擔。. ‧. Nat. sit. io. al. n. 2.2.1 Eclipse. y. Eclipse 平台與相關工具. er. 2.2. Ch. engchi. i n U. v. Eclipse是由IBM公司提出的Java整合開發環境（Integrated Development Environment, IDE），其主要目的是取代IBM原先的Java商業開發工具VisualAge for Java。在2001年 11月時，IBM把部分的原始碼開放出來，並成立了相關的非營利性Eclipse基金會與 eclipse.org網站，希望提供一個開放並且免費的IDE。由於IBM 對於Eclipse平台的開放態度與Eclipse本身強大的擴充機制，使得Eclipse成為目前最多程式開發者所使用的 Java程式開發平台。但除了Java語言的開發之外，也有許多程式開發者透過外掛程式（plug-ins）的使用來進行其他語言的撰寫，如C/C++、PHP或XML…等。. 11.

(32) 立. 政治大. 圖 2.4：Eclipse 平台架構圖。. ‧ 國. 學. 圖2.4為Eclipse平台架構圖，一般當提到Eclipse時，通常指的是Eclipse軟體開發. ‧. 工具（Software Development Kit, SDK）主要包含Java IDE與其他的相關輔助開發工. sit. y. Nat. 具，然而Eclipse SDK則是由多個Project組成，其中包含Eclipse Platform、JDT（Java. io. er. Development Tools）與PDE（Plug-in Development Environment）。Eclipse Platform 是建構所有開發環境的基礎，由許多的元件（例如Workbench、Workspace、Help和Debug…. al. n. v i n C h Client Platform）則是所有元件中的一個子集 RCP（Rich engchi U. 等）所組成，其中Eclipse. 合也是Eclipse的基礎平台。Eclipse Platform包含了建構一個IDE所需的基礎功能，因此所有的相關工具與應用都必須建構在此之上，所以JDT與PDE就是建構在此之上的 plug-in。 Eclipse平台的成功關鍵在於擁有強大的擴充機制，透過擴充點（extension point）的概念，提供其他plug-in程式一個擴充的框架，Eclipse本身提供了許多的擴充點，讓程式開發者可以依照自己的需求安裝各種相關的plug-in，並且將其整合到Eclipse平台上，使得所有的程式開發過程都能在Eclipse平台上就可以完成，每一個plug-in程式也能提供自己的擴充點，以便讓其他的plug-in程式也能擴充在此之上。相對的由於 12.

(33) Eclipse所有的標準、規格和原始碼都是開放的，使得程式開發者也能利用Eclipse提供的PDE自行設計與開發符合自己需求的plug-in，除了供自己使用外也可以讓其他程式開發者使用。基於這樣的概念，Eclipse讓每一個程式開發者都能擁有屬於自己專用的 IDE。. 2.2.2 Eclipse Modeling Framework, EMF Eclipse Modeling Framework是屬於Eclipse Modeling Projects[04]裡的核心專案，. 政治大. 主要目標是以一個結構化的模型來描述相關的工具與應用程式，進一步產生整個程式框. 立. 架的Java程式碼。對於原本就有物件導向建模概念的程式開發者來說，可以不必拋棄原. ‧ 國. 學. 本舊有的模型概念，直接透過EMF的使用會讓原本的建立模型方式變的更有效率與正. ‧. 確。. sit. y. Nat. 一般建模的格式通常是利用UML所定義的圖形化標準模型來建立，對於整個建模的. io. er. 過程，往往需要花費很多的時間在物件導向分析與設計（Object Oriented Analysis and. al. Design, OOA/D）上。對EMF來說UML提供了過多的模型格式，因此EMF以UML作為基礎自. n. v i n Ch 己定義了一套模型的描述語言，嚴格的來說EMF所定義的模型描述語言可以算是UML裡的 engchi U 一個子集合，簡單的定義了「classes」模型與相關的「attributes」及「relations」，. 藉此提供一個較低成本的建模方式供程式開發者使用。 EMF利用XMI（XML Metadata Interchange）作為模型定義的標準格式，程式開發者可以透過以下幾種方式來建立模型: •. 直接建立XMI文件，透過XML或一般文字編輯器進行編輯. •. 透過圖形化的模型編輯器，例如Rational Rose. •. 利用「Annotated Java Interfaces」進行模型特性的描述. •. 利用XML Schema描述一系列的模型規格 13.

(34) EMF另一個強大的地方在於，就算只透過其中一種方式進行模型的建立與設計，還是可以藉由EMF裡的轉換工具互相進行轉換，例如使用圖形化模型編輯器建立的模型，也可以轉換成Annotated Java Interfaces或XML Schema的描述方式。 EMF包含了三個基礎的架構：核心架構、EMF.Edit架構與EMF.Codegen架構：核心架構提供了一個基本的模型描述規格，以及在執行時對模型的需求提供支援，包括模型狀態變更時的通知機制、支援預設的 XMI 序列式模型儲存格式與利用 EMF 提供的「reflective API」對一般通用的EMF物件進行操作；EMF.Edit架構，利用一些通用且. 政治大. 可以重複使用的Eclipse classes作為建立EMF的模型編輯器的基礎，例如編輯器允許EMF. 立. 的模型利用「JFace viewer」與「property sheet」將物件的內容、名稱或是各種屬性. ‧ 國. 學. 資料加以呈現，還包含一些模型圖型化編輯所需的API；EMF.Codegen架構的主要功能是，在建構一個完整的模型編輯器時，EMF.Codegen必須滿足編輯器的所有需求，例如進行. ‧. Java語言編輯時就必須將編輯器與Eclipse JDT作連結。. y. Nat. io. sit. 對於 OMG 組織所提出的 MOF 架構來說，MOF 與 EMF 是一個極為類似的東西。但事實. n. al. er. 上，EMF 則是對 MOF 架構進行了實作後的產物，整個 EMF 的發展過程是透過對許多模型. Ch. i n U. v. 開發工具的實作與使用累積而成。也可以把 EMF 想像成是對 MOF 的核心 API 進行一個有. engchi. 效率的 Java 語言實作，但為了避免混淆，在 EMF 裡與 MOF 相似的超模型核心就稱做「Ecore」。在目前 MOF 2.0 的提案中，比較像是原本 MOF 模型架構裡的一個子集合，所以稱作「EMOF」（Essential MOF）。EMOF 與 Ecore 之間的差異在於，EMOF 比 Ecore 來的更為精簡並且對於命名的方式也有些不同，但 EMF 還是可以對 EMOF 進行明確的序列化讀寫。在 Eclipse 平台上對於 EMF 的使用相當廣泛，並且發展出越來越多的模型工具都是以 EMF 為基礎進行開發，因此我們也以 EMF 裡的 Ecore 模型來做為本系統的主要建模格式，建立「平台無關」與「平台專屬」的導引精靈超模型。 14.

(35) 2.2.3 Xtext Xtext[05]是在 2006 年，發表於 openArichitectureWare 專案裡。接著在 2008 年正式屬於 Eclipse Modeling Framework 專案裡的其中一個部份，並且由 itemis 組織進行開發與維護。在 2010 年 6 月正式推出 Xtext 1.0 版本，Xtext 主要是對於已經擁有一套自定的語言，卻缺乏相關工具支援的程式開發者，可以在短時間內透過 Xtext 建構一個以 Eclipse 平台為基礎，類似 Java JDT 的程式編輯環境，並且也是用於一般通用程式語言與特定領域語言(Domain-Specific Language, DSL)的開發。所以簡單來說，Xtext 是一. 政治大. 套提供程式開發者快速建構自定語言編輯環境的開發工具。. 立. Xtext 提供程式開發者利用一組特定領域語言與 APIs，對一般通用程式語言進行多. ‧ 國. 學. 方面的描述，藉此讓利用 Xtext 設計的語言能夠在 JVM 上執行。在程式碼編譯的部分，. ‧. 可以在獨立的 Eclipse 或 OSGi 上進行編譯，也可以在任何 Java 環境下進行，其中包含解析器、程式碼產生器和解譯器…等，最後 Xtext 所有的執行單元都必須以 EMF 為基礎. y. Nat. io. sit. 進行整合，這樣使得 Xtext 能有效率的利用在其他 EMF 相關工具上，例如 GMF(Graphical. n. al. er. Modeling Project)。透過上述的執行架構，程式開發者可以在 Eclipse 上建構一個專. Ch. i n U. v. 為某種語言客製化的語言開發環境，並且在試圖改變一些編輯環境的配置時都會變得相. engchi. 當容易。Xtext 的核心語法是利用文字式的模型編輯方式進行 EMF 模型定義，並且利用 ANTLR-generated parser 對編輯好的模型語言進行語法的分析，ANTLR(ANother Tool for Language Recognition)是利用 LL(*)方式進行語法分析，目前透過 ANTLR 支援的程式碼產生器，產生的語言包含 Java、C、C#，Objective-c、Python 與 Ruby。. 15.

(36) Xtext 使用較輕量的依賴注入(Dependency injection, DI) 架構 Google Guice，藉此連結了整個程式語言以及開發環境的基礎功能。所謂的依賴注入是透過抽象介面的使用，來打破兩個類別之間依賴的關係，也就是將原本兩個類別的依賴關係，轉移到抽象介面與兩個類別之間的關係，使得兩個類別之間不再有依賴關係產生。透過依賴注入的使用，能夠降低程式碼之間的耦合度，以利於提供程式開發者一個高度客製化的程式編輯環境。相對於一般程式語言的開發，語言與編輯環境大多是分開進行設計的，先有語言本. 政治大. 身才有編輯器，然而 Xtext 顛覆了一般程式語言開發的過程，提供程式開發者在進行相. 立. 關程式語言開發與設計的同時也可以進行編輯環境的設計，讓編輯器的開發變的是簡單、. ‧ 國. 學. 快速且有效率的，因此我們利用 Xtext 來建構平台無關導引精靈的特定領域語言以及以 Eclipse 平台為基礎的專屬 IDE，藉此當作整個系統的輸入。. ‧ y. Nat. io. al. n. 2.3.1 Xtend. sit. 模型轉換工具. er. 2.3. Ch. engchi. i n U. v. Xtend 是隨著 Xtext 2.0 一起釋出並且整合於 Xtext 中，用來進行模型轉換的重要工具， Xtend 是一種靜態型別(statically-typed)的程式語言，能夠緊密的與 Java Virtual Machine 進行整合並且在上面執行，所謂的靜態型別是指，對於變數的型別檢查是在程式編譯時期的語意分析中所進行。Xtend 並非想取代 Java 語言，而是與 Java 保持一種高度互動的關係，Java 可以直接對 Xtend 的方法與函數進行呼叫，並且對於 Xtend 的編輯環境也與 Eclipse 上的 JDT 進行整合，所以 Xtend 與 Java 兩者是可以同時存在的， Xtend 相對於 Java 語言增加了以下幾個概念：. 16.

(37) •. 提供先進的型別推測方法，減少使用者對於 type signatures 的描述。. •. 完全支援 Java 的 Generics 程式寫作，包含所有的一致性與轉換規則。. •. 支援且提供簡潔的 Closures 匿名函式描述語法。. •. 允許進行運算子多載(operator overloading)的程式寫作。. •. 提供功能較強大的 switch expression。. •. 在 Xtend 裡沒有 statements 的描述，全部都是 expression 的描述。. •. 對於範本的 expressions 描述，提供智慧的空白區域處裡。. •. 對於外部方法(methods)的使用，利用 inject 的方式引入。. •. 學. •. 提供 multiple dispatch，又名 polymorphic method invocation。. ‧ 國. •. 政治大對於物件屬性的存取語法，提供了 getter 與 setter 的存取方式。立. 編輯完成的 Xtend 模型轉換程式會被轉換成一般的 Java 程式而非 bytecode。. ‧. 表 2.1 為 Xtend 的基本程式結構，乍看之下容易讓人誤以為是 Java 程式，一個基. Nat. sit. y. 本的 Xtend 程式從 package 的宣告開始，接著是 import 的引用區塊，最後是 class 的. n. al. er. io. 定義，class 裡包含的是一些函式、模型轉換規則或模型範本的描述。事實上 Xtend 的. i n U. v. class 與函式會被自動轉換成 Java 的 class 與方法，並且儲存於對應的 Java package 裡。. Ch. engchi. 01 package edu.nccu.cs.wta.pimwizarddsl 02 import java.util.* 03 class MyClass { 04 def String first(List<String> elements) { 05 return elements.get(0) 06 } 07 } 表 2.1：基本 Xtend 程式結構。. 17.

(38) 對於 Xtend 的相關語法，表 2.1 在 class 裡的是定義一個基本的函式，以保留字「def」開始接著是回傳值型別與函式名稱完成一個函式的定義，Xtend 提供先進的型別推測方法，所以回傳值型別是可以省略的。在 Xtend 裡對於函式類型加入了「Dispatch 函式」與「Create 函式」的概念；一般函式的 binding works 對於參數的限制通常是靜態的參數型別，但有些時候這並非是我們想要的，尤其當我們的參數具有多型(polymorphic) 的特性時，所以 Dispatch 函式主要是用來產生一組 overloaded functions polymorphic，在程式執行時根據每一個不同的參數型別，再來決定哪一個多載的函式要被呼叫，透過. 政治大. 在「def」後面加入保留字「dispatch」來進行 Dispatch 函式的建立。. 立. Create 函式在 Xtend 裡主要是用來進行模型的轉換，當我們需要產生多個新的物件，. ‧ 國. 學. 並透過現有的物件給予初始值的時候，一般的程式寫作模式會需要兩個或兩個以上的函式來完成此動作，但透過 Create 函式的使用可以大大簡化程式碼的複雜度。表 2.2 為. ‧. Create 函式的範例，複製一個新的 Person 物件，透過在「def」後面加入保留字「create」. Nat. sit. y. 的使用來建立 Create 函式，target 代表的是新宣告的 Person 物件，接著在函式裡進行. al. n. 物件。. er. io. 新物件的初始化，最後此 Create 函式會以 Person 作為回傳值型別，並且回傳 target. Ch. engchi. i n U. v. 01 def create target：new Person() copy(Person p) { 02 03 }. target.name = p.name. 表 2.2：Create 函式範例。最後是 Xtend 的程式碼產生器建構方式，Xtend 利用「Rich Strings」來進行模型轉換範本的描述，Rich Strings 允許可閱讀的字串內容進行串聯，不再只是片段單行的描述，表 2.3 為 Rich Strings 的範例，產生一個 Java Class 的範本，利用兩個「'''」 18.

(39) 分別代表 Rich Strings 的開頭與結尾，在進行模型範本描述的過程中，也可以加入條件式來增加範本內容的靈活性，條件式的語法是利用「«」與「»」來進行條件式的描述，最後 Rich Strings 會被轉換成有效的字串串聯，並且以 Java 的 CharSequence 作為回傳值型態進行回傳。. 01 def toClass(Entity e) '''. 政治大 «member.toMember» 立 «ENDFOR». 學. 06 07 08 09 '''. package «e.packageName»; «e.placeImports» public class «e.name» { «FOR e.members». }. 表 2.3：Rich Strings 範例。. Nat. sit. y. ‧. ‧ 國. 02 03 04 05. io. er. 與一般的模型轉換語言相比 Xtend 同時支援了模型轉換規則與模型範本的撰寫，並且 Xtend 的程式語法也與 Java 相似，讓原本就熟悉 Java 語言的程式開發者能夠更容易. al. n. v i n 上手，更重要的是 Xtext 與 XtendC進行整合，使得 U 能夠直接存取利用 Xtext 設計 h e n g c h iXtend. 的 DSL 模型，讓 Xtext 模型程式設計更加便利。. 2.4. 相關系統回顧. 此篇論文 Using Domain-Specific Modeling to Generate User Interfaces for Wizard[07]主要是討論，有哪些要素是建構一個導引精靈程式所必須的，以及如何使用 DSML（Domain-Specific Modeling Language）來描述與定義導引精靈，並進一步產生相關的導引精靈程式，最後以ASL（Application Specification Language）[14]為例 19.

(40) 設計相關的ASL導引精靈實作。超模型的設計與建立主要是利用MDE（Model-Driven Engineering）[15]的概念，對導引精靈進行超模型需求的分析，以決定那些部分是需要被定義出來，並且將導引精靈主要分成兩類：「Plain Wizards」與「Guided Wizards」： Plain Wizard Plain Wizard 是一種連續性的導引精靈頁面集合，彼此之間是以一個接著一個的方式作連接，不允許跳躍的情況發生，對於這一類型的超模型分類，必須處理每一個不同頁面之間的連接方式、資料傳遞的方式、橫跨不同頁面的資料儲存以及頁面的 GUI 設計，. 治政並且此類型的導引精靈在模型被建立的同時，只會存在著一條單一的執行路徑。大立 ‧ 國. 學. Guided Wizard. ‧. Guided Wizard 延伸連續性頁面的概念並且與「expert system」[16]有較相近的關係，所謂的 expert system 就是試圖對某個問題提出一組答案，並且沒有一個明確的正. y. Nat. io. sit. 解，所以對程式開發者來說，在建立 Guided Wizards 時，必須包含許多預先定義好的. n. al. er. 執行路徑集合，並且由使用者來決定下一個導引精靈頁面。因此在建立 Guided Wizards. Ch. i n U. v. 超模型時，都必須將上述的幾個因素考慮進去，除此之外，作者還加入了「控制流程要. engchi. 素」（control flow element）的概念，主要是用來對使用者輸入的資料進行分析，然後再來決定是否有跳躍的情況發生。在建立模型工具的部分，主要是使用 GME（Generic Modeling Environment）[17] 建模工具進行 DSML 模型的建立，GME 的超模型語言主要是以 UML 作為類別圖形表示法的基礎與 OCL[18]進行 UML 限制規則的描述，對於模型範例的編輯則會根據超模型的規範，自動產生特定領域模型的編輯環境，並且以 XML 作為模型的主要儲存格式，GME 主要是透過 Microsoft COM (Component Object Model) [19]技術建立具有模組化且可擴充架構的開發環境。 20.

(41) 在程式碼產生器的部分，並沒有明確的表示使用哪種工具進行撰寫，只提到使用模型編譯器能產生與模型對應的 HTML 程式碼，並且在導引精靈程式產生的過程中必須注意每一個導引精靈頁面的格式、順序與資料的傳遞，但透過此程式碼產生器產生的 HTML 網頁，目前只能實現基本所需的網頁格式，對於頁面的排列與頁面之間的連接關係並無法透過此程式碼產生器實現，主要的遇到的挑戰是需要自動建立在模型裡不同類型物件的連接機制。此相關系統[07]與本系統 MoDWiz 之比較，如表 2.4 所示，MoDWiz 主要是使用 EMF[04]. 政治大. 的 Ecore 模型來做為超模型的建構標準，而相關系統[07]則是使用 UML 來做為超模型的. 立. 建構標準。MoDWiz 系統提供了導引精靈的平台無關精靈超模型，做為一般導引精靈程式. ‧ 國. 學. 的描述標準，並且提供導引精靈的描述語言 WDL 與 WDL 編輯器，提高使用者對導引精靈模型的編輯效率，對於導引精靈的 PIM 模型提供 M2M 工具，自動轉換成符合特定執行平. ‧. 台的 PSM 模型，這些都是相關系統[07]所沒有提供的。另外在 PSMM 方面，MoDWiz 支援. Nat. sit. n. al. er. io. 的執行平台。. y. 了三種執行平台，其中包含 WebApp、Eclipse 與 Java，而相關系統[07]只提供一種 WebApp. Metametamodel. Ch. MoDWiz. engchi. i n U. v. 相關系統[07]. Ecore. UML. PIMM. Wizard PIMM. 無. DSL. WDL. 無. DSL Editor. WDL Editor. 無. M2M 工具. 有. 無. PSMM. 有. 有. 支援平台. WebApp、Java、Eclipse. WebApp. 程式碼產生器(M2T 工具). 有. 有. 表 2.4：MoDWiz 與相關系統[07]之比較。 21.

(42) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 22. i n U. v.

(43) 3. 系統架構與實作. 立. 政治大. ‧ 國. 學. 此章節將針對本系統的架構與實作進行說明。首先介紹的是系統架構，說明如何將MDA 應用於多平台導引精靈程式開發系統上；接著是系統的實作，介紹如何透過Eclipse平. ‧. 台與Eclipse相關的Plug-ins模型開發工具，進行多平台導引精靈程式開發系統MoDWiz. n. al. er. io. sit. y. Nat. 的實作。. Ch. engchi. i n U. 圖 3.1：MoDWiz 系統架構。 23. v.

(44) 3.1. 系統架構. 圖 3.1 為利用 MDA 架構建立的多平台導引精靈程式開發系統架構圖，我們將它命名為 MoDWiz(MOdel-Driven WIZard Generation System)，MoDWiz 主要包含以下幾個部分： •. 平台無關導引精靈超模型(Wizard PIMM)：此超模型主要是用來描述導引精靈程式的目的、結構與行為，所以必須先對一般導引精靈程式進行平台無關的分析，接著建立超模型作為一般導引機靈模型的描述規範，並且本系統主要是以此超模型描述的導引精靈模型作為系統的輸入。. •. 政治大. 導引精靈描述語言(WDL)：為了方便導引精靈模型的編輯，我們為 Wizard PIMM 提. 立. 供了一個專屬的具體語法稱之為 WDL(Wizard DSL)。WDL 及其相關編輯器的制定，. ‧ 國. 學. 讓程式開發者能夠更簡單快速的描述待開發的導引精靈。. 平台專屬導引精靈超模型(Wizard PSMM)：此超模型主要用來描述導引精靈程式在. ‧. •. 某個特定平台上執行的特性，所以必須先針對導引精靈程式在不同的執行平台上的. y. Nat. io. sit. 執行特性進行分析，然後建立符合各個執行平台的超模型，作為特定平台導引機靈. n. al. er. 模型的描述規範。目前 MoDWiz 支援三種執行平台的導引精靈開發，分別為網頁應用程式、Eclipse 與 Java。 •. Ch. engchi. i n U. v. 模型與模型之間的轉換：在 MDA 的概念中，平台專屬模型(PSM)主要是透過輔助模型轉換工具自動產生，所以在本系統裡自動產生平台專屬模型的方法，是透過「模型與模型之間的轉換」（Model to Model Transformations, M2M）將平台無關導引精靈模型(PIM)轉換成符合特定執行平台的平台專屬導引精靈模型。. •. 模型與程式碼之間的轉換：本系統的輸出，也就是平台專屬超模型的程式碼產生器的建構，在本系統裡透過「模型與程式碼之間的轉換」（ Model to Text Transformations, M2T）將平台專屬導引精靈模型轉換成符合特定執行平台的程式碼，完成利用 MDA 架構於多平台導引精靈程式的開發。. 24.

(45) 3.2. 系統實作. 系統的實作主要是利用 Eclipse 作為主要的系統開發平台，並且藉由 Eclipse 上的相關模型開發工具 Xtext 與 Xtend 進行開發與設計，其中實作的部分包含「超模型的建立」與「模型的轉換」:. 3.2.1 超模型的建立. 政治大. MDA開發架構主要是以「模型」（Model）為基礎來描述整個程式，也就是將程式抽象化. 立. 成一個具體模型，只保留一般程式的屬性和行為等資訊，在不失一般性的情況下包含整. ‧ 國. 學. 個程式的細節。將模型進一步的歸納與抽象化則會得到「超模型」（Metamodel），所謂的超模型是指負責用來描述模型的模型，用以規定模型的屬性與格式，每一個模型都. ‧. 有屬於自己的超模型並且符合它。超模型再抽象化則會得到「超超模型」. Nat. sit. y. （Meta-Metamodel），所謂的超超模型是負責用來定義超模型的標準，並且擁有自我描. er. io. 述的能力，圖3.2為MDA的模型關係圖。. al. n. v i n Ch 所以本系統的模型實作，主要是針對一般的導引精靈程式與導引精靈在不同執行平 engchi U. 台的執行方式進行分析，然後分別建立「平台無關」與「平台專屬」的導引精靈超模型：. 圖 3.2：MDA 的模型關係圖。. 25.

(46) 平台無關導引精靈平台無關導引精靈的超模型實作(詳細過程請參照4.1節)，主要是利用Xtext特定領域於言開發工具來進行建構，並且透過Xtext建構的超模型主要是以EMF的Ecore模型作為超模型的建構標準，由於本系統是以平台無關導引精靈模型作為系統的輸入，所以利用Xtext建立平台無關導引精靈超模型的同時，也可以針對超模型設計專屬的特定領域語言WDL(詳細的WDL編輯方式請參照6.2節)，並且Xtext還能夠對此特定領域語言快速建構一個以Eclipse平台為基礎，類似Java JDT的特定領域語言編輯環境，藉此提高使用. 政治大. 者對平台無關導引精靈模型的編輯效率。. 立. 平台專屬導引精靈. ‧ 國. 學. 平台專屬導引精靈的超模型實作，主要也是利用Xtext特定領域於言開發工具來進. ‧. 行建構，但不同的地方在於利用Xtext建構的平台專屬導引精靈超模型，不需要再設計. sit. y. Nat. 專屬的特定領域語言，目前建立在本系統裡的平台專屬導引精靈超模型共有三種，包括. n. al. er. io. 網頁應用程式、Eclipse與Java的平台專屬導引精靈超模型(詳細過程請參照4.2節)。. Ch. i n U. v. 在整個系統裡模型扮演著一個極重要的角色，可以把它形容成是整個系統的核心，. engchi. 並且每一個模型之間都有存在著一些關係，如何將這些關係做適當的連結與建立，就必須透過接下來模型轉換的方式來達成。. 3.2.2 模型的轉換 MDA希望讓程式開發者只需專注在導引精靈程式的功能與架構上進行分析，並且建構出符合使用者需求的導引精靈模型即可，其餘的平台系統設計與程式碼撰寫只需透過CASE 工具就可以自動完成，所以模型的轉換過程就是MDA用來達到程式開發自動化的主要方式，其中包含「模型與模型之間的轉換」和「模型與程式碼之間的轉換」。 26.

(47) 所以本系統的模型轉換實作主要分成兩個部分，第一部分是對平台無關導引精靈與建構在本系統裡的平台專屬導引精靈建立轉換規則，另一部份是建立每一個平台專屬導引精靈的程式碼產生器：模型與模型之間的轉換在進行模型與模型之間的轉換之前，必須先建立好模型彼此之間轉換的規則(詳細的模型轉換規則請參照5.1節)，然後再透過模型轉換語言進行轉換規則的撰寫，模型轉換規則的實作主要是利用Xtext裡所提供的Xtend模型轉換工具，最後依據定義好的規則來進行模型轉換。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3.3：模型與模型之間的轉換意識圖。圖3.3為模型與模型之間的轉換意識圖。Source Model為程式開發者利用平台無關導引精靈特定領域語言設計好的導引精靈模型，作為此模型轉換的輸入，此模型必須符合上層的導引精靈PIMM的規範，接著再上去就是必須符合本系統的Meta-metamodel Ecore。Target Model是經由轉換後得到的導引精靈模型，此模型必須符合上層的特定平台導引精靈PSMM的規範，同樣的再上去就是符合本系統的Meta-metamodel Ecore。對於利用Xtend轉寫的模型轉換規則，則必須符合Xtend語法的規定。 27.

(48) 以四層的MDA架構來看，模型與模型之間的轉換主要是利用Xtend建立，屬於M2 Layer 裡PIMM與PSMM之間的導引精靈模型轉換規則，然後以M1 Layer裡的Source Model作為輸入，依照建立好的模型轉換規則產生符合某執行平台特性的導引精靈模型，也就是 Target Model。模型與程式碼之間的轉換在進行模型與程式碼之間的轉換之前，必須先設計好模型的轉換範本 (templates)(詳細的模型轉換範本請參照5.2節)，然後再透過模型轉換語言建立模型與. 治政模型範本之間的轉換關係，模型範本的轉換實作主要是利用Xtext裡所提供的Xtend模型大立轉換工具，最後依據定義好的模型範本來進行模型範本轉換。 ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 3.4：模型與程式碼之間的轉換意識圖。圖3.4為模型與程式碼之間的轉換意識圖。Source Model為程式開發者經由模型與模型之間的轉換過程中，從平台無關導引精靈模型得到的特定平台導引精靈模型，作為此模型轉換的輸入。Source Code是經由模型範本轉換所產生的導引精靈程式，此程式碼必須符合執行平台的規範。對於利用Xtend轉寫的模型範本轉換規則，則必須符合 Xtend語法的規定。 28.

(49) 以四層的MDA架構來看，模型與程式碼之間的轉換主要是利用Xtend建立，屬於M2 Layer裡PSMM的導引精靈模型轉換範本，然後以M1 Layer裡的Source Model作為輸入，透過模型範本的轉換規則產生符合執行平台特性的導引精靈Source Code。接下來我們將在第四、第五及第六章節，分別對「平台無關」與「平台專屬」的導引精靈超模型建立、導引精靈模型的轉換規則建立及多平台導引精靈開發系統的操作流程，作進一步更詳細的說明。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 29. i n U. v.

(50) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. 30. i n U. v.

(51) 4. 導引精靈結構分析與超模型. 立. 政治大. ‧ 國. 學. 此章節將對於一般導引精靈與特定平台導引精靈的結構進行分析，並且建構符合其規範的超模型，在多平台導引精靈程式開發系統裡，我們可以把超模型形容成是整個系統的. ‧. 核心，因此對於建立超模型的要求，希望可以是簡潔扼要的涵蓋整個導引精靈程式與多. n. al. er. io. sit. y. Nat. 執行平台的特性。. 4.1. 平台無關導引精靈. Ch. engchi. i n U. v. 對於平台無關導引精靈的分析主要是專注在導引精靈應有的目的、結構與行為上進行分析，最後訂定規則也就是建立超模型，讓所有的導引精程式都能夠符合其規範。導引精靈的目的就是準確的收集到想要收集到的資料，透過對問題加入輔助性的訊息引導與對資料進行驗證的過程，來提高收集資料的可用性；導引精靈的結構大多是以多個導引精靈頁面所組成，並且藉由頁面對資料的收集進行分類，或者透過頁面的先後順序來訂定收集資料的順序；對於收集資料的行為主要是利用問問題的方式讓使用者輸入答案，並且把大問題細分成多個小問題，使用者能夠更直覺性的進行回答，快速且易懂的了解該輸入什麼樣的資料。 31.

(52) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.1：平台無關的導引精靈超模型。. 32.

(53) 圖 4.1 為建構好的平台無關的導引精靈超模型，超模型主要分成三個部分其中包含結構模型、問題描述模型與資料驗證模型：結構模型結構模型主要以 iWizard 、iPage 與 iPageName 三個類別進行定義，iWizard 為整個導引精靈模型描述的起始點，導引精靈會包含一至多個 iPage 來對資料收集的問題進行簡單的分類，每一個 iPage 裡所包含的內容，就是資料收集者對於想要收集的資料進行個別設計的問題，最後是 iPage 之間連接關係的建立，每一個 iPage 名稱都必須利用. 治政 iPageName 進行宣告，並且每一個名稱都是唯一的，iWizard 大會有順序的對每一個頁面名立稱進行收集，當作每一個 iPage 的執行順序。當完成 iPage 的資料輸入之後系統即可依 ‧ 國. 學. 據執行順序，連結到下一個 iPage 繼續進行資料的收集直到最後一個，完成整個資料收. io. sit. y. Nat. 問題描述模型. ‧. 集的過程。. n. al. er. 問題描述模型主要以 Question 、 SingleQuestion 、 GroupQuestion 、 TextInput 、. Ch. i n U. v. MultipleChoice、Dialog 與 MenuItem 七個類別進行定義，其中 Question 是定義一個問題. engchi. 的父類別，並且宣告了兩個子類別 SingleQuestion 與 GroupQuestion 繼承他，然而在 GroupQuestion 裡主要還是以多個 SingleQuestion 所組成，SingleQuestion 是用來定義資料收集方式的主要模型，因此我們再對它進行分類，並分別宣告三個類別繼承它： •. TextInput：一般文字輸入型的問題。. •. MultipleChoice：是一種有固定答案的問題，並且每一個問題裡面都會包含一至多個答案選項，每一個選項都以 MenuItem 進行描述。. •. Dialog：需要與底層作業系統或平台有所互動的問題，例如檔案、顏色與字形的選擇，或更一般化的物件選擇。. 33.

(54) 最後 Question 裡的 helpmsg 屬性，在資料收集的過程中並非每一個題目都可以使所有用戶明確的了解想要收集資料的內容，因此適時地利用 helpmsg 提供額外輔助性訊息對於不熟悉的用戶來說是必要的。資料驗證模型資料驗證模型是以 Validation 與 ErrorMessage 兩個類別進行定義，由於模型對於邏輯運算的描述相當弱，因此 Validation 主要的內容是以文字敘述的方式來描述該如何進行資料的驗證，並且當資料驗證過程發生錯誤時必須適時的利用 ErrorMessage 提出錯誤訊息。. 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.2：平台無關導引精靈的 Ecore 模型。. 34.

(55) 圖 4.2 為利用 Xtext 建構平台無關導引精靈超模型時，所產生對應的 Ecore 模型，由於 Xtext 所有的執行單元都必須以 EMF 為基礎進行整合，藉此才能讓 Xtext 更有效率的利用在其他 EMF 相關工具上，利用 Xtext 建構 DSL 的過程，主要是以文字式的模型定義方式，進行平台無關導引精靈的 Ecore 模型編輯與符合此超模型的 DSL 結構設計。. 4.2. 平台專屬導引精靈. 政治大進行資料收集的過程，然後制定導引精靈程式在特定平台上的描述規則並且建立符合平立對於特定平台導引精靈的分析主要是專注在，如何在特定平台上建立一個導引精靈程式. ‧ 國. 學. 台特性的超模型，其中執行平台的特性包含使用者圖形介面描述、程式語言的使用與執行的方式…等，接下來將介紹三個建立在本系統上的平台專屬導引精靈超模型:. ‧. Nat. io. sit. y. 4.2.1 網頁應用程式導引精靈模型. n. al. er. 網頁應用程式導引精靈主要是利用互動式的網頁來呈現，並透過一般的網頁瀏覽器即可. Ch. i n U. v. 執行。對於網頁的結構與圖形使用者介面主要是利用 HTML(Hyper Text Markup. engchi. Language)[13]來進行描述，HTML 並不是程式語言而是一種標記語言(markup language)，藉由許多的標記標籤(markup tags)對網頁結構與圖形使用者介面進行定義，但利用 HTML 所描述的是一種比較靜態的網頁與使用者進行互動的方式欠佳，所以常會使用 JavaScript[20]來增加 HTML 網頁動態效果的呈現，JavaScript 是一種廣泛使用在用戶端網頁程式開發的腳本語言，也就是說在用戶端的瀏覽器上即可執行，不必再透過其他伺服器的支援。因此在立在本系統上的網頁應用程式導引精靈主要是利用 HTML 與 JavaScript 所建構而成。. 35.

(56) 立. 政治大. ‧. ‧ 國. 學. n. er. io. sit. y. Nat. al. Ch. engchi. i n U. v. 圖 4.3：平台專屬的網頁應用程式導引精靈超模型。. 36.

(57) 圖 4.3 為建構好的平台專屬的網頁應用程式導引精靈超模型，超模型主要分成三個部分其中包含頁面結構模型、使用者介面模型與輔助元件模型：頁面結構頁面結構模型主要以 Web、WPage、WPageName、ComponentSet 與 Component 五個類別進行定義，Web 為描述整個網頁應用程式導引精靈的主要類別，因此 Web 會包含一至多個 WPage 頁面，但 WPage 並非一般的網頁格式，而是一個收集導引精靈頁面內容的集合，Web 會透過 AJAX(Asynchronous JavaScript and XML)[23]技術對 Web. 治政進行非同步性的 WPage 頁面資料轉換，藉此來完成導引精靈頁面轉換的目的。每一個大立 WPage 裡會包含一至多個 ComponentSet，在此定義的 ComponentSet 主要目的是收集在 ‧ 國. 學. WPage 上，描述一個資料收集問題所需的元件集合，所以 ComponentSet 裡包含的是多. ‧. 個以 Component 作為父類別的使用者介面元件與輔助元件的集合。最後是 WPage 之間連接關係的建立，每一個 WPage 的名稱都必須以 WPageName 進行宣告並且是唯一的，. y. Nat. n. al. er. io 使用者介面元件. sit. 接著 Web 會有順序的進行收集，當作每一個 WPage 交換的順序。. Ch. engchi. i n U. v. 使用者介面元件主要以 UIComponent、Label、TextArea、Select、Option、Input 與 FieldSet 七個類別進行定義，其中 UIComponent 是定義一個使用者介面元件的父類別並且繼承 Component，所以 Label、TextArea、Select、Input 與 FieldSet 都必須繼承 UIComponent。使用者介面元件主要是用來具體呈現在網頁上進行資料收集的方式，並且以 HTML 常使用到的圖形使用者元件標籤為主，以下將會介紹幾個我們定義的使用者介面元件類別: •. Label：在網頁上給予其他的使用者元件定義一個文字標籤。. •. TextArea：定義一個多行數的文字輸入區塊，區塊大小可以透過 TextArea 的屬性加以定義。. 37.