1、 - 7 - 第二章 相關研究探討 2.1 軟體工程領域 2.1.1 重構 重構一詞，已知最早在一九九年，由 William F. Opdyke 和 Ralph E. Johnson 共同 提出，代表在不改動程式的外在表現下，改寫程式以增進其可讀性並簡化結構【10】 。 重構在程式碼層次，提供一次性的相關構造物（Artifact）自動同步變動服務，因而得以 為我們建立許多可高度重用的、系統化的改寫程式準則。常見的程式重構技術有封裝屬 性（Encapsulate Field） 、萃取方法（Extract Method） 、一般化型態（Generalize Type） 、 提升所屬繼承層級（Pul
2、l Up） 、降低所屬繼承層級（Push Down）以及改名（Rename Package/Type/Method/Field/Variable, etc.）等等【10】 。 在系統演進（Evolving）的過程裡，有多種變更系統設計的作法，重構僅是其中之 一，但它強調的是不影響系統的產出。因此，重構力求忠於原味般的精確，必定以 識別項（Identifier）完全匹配的構造物，做為變更設計的起點，以不影響程式語意為前 提。 起源於程式設計的重構，本質就是資料結構上的重組（程式碼即為剖析樹Parse Tree資料結構） ，其他結構化資料當然也適用包括結構化的自然語言文件。 【10】 特別提到了在
3、程式設計以外，自然語言以及生物基因組（Genome）層次的重構，顯現 - 8 - 講求嚴謹結構的重構和非結構化處理為主的自然語言之間，其實也不見得必為楚河漢 界。 2.1.2 資料連結（Data Binding） 雙向工程同步，講的是模型與模型間的資料同步。另外有個比雙向工程同步更一般化、 歷史也相當悠久的研究議題資料連結【11】 【12】問題同樣累積了不少成果， 值得借鏡。資料連結問題，是研究物件與物件間的資料，如何藉由連結技術而維持同步。 譬如 Beans 連結（Beans Binding，JSR 295【11】 ）便是針對 Java Beans 物件提出的資料 連結同步標準；而在 Ecl
4、ipse 平台上，也有其專屬的資料連結架構JFace 資料連結 （JFace Data Binding，JDB【12】 ） ，JDB的連結對象甚至允許型態更廣泛的物件。 基本上，這些架構的運作，皆符合模型視界控制器（Model-View-Controller， MVC） 樣式；來源端即模型，目的端即視界，而連結兩端、監控兩端、維持資料同步 的，就屬控制器了。半自動雙向工程系統 CODEX【13】 ，也是以 MVC樣式運作半自動 雙向工程，更加說明了資料連結與雙向工程間的異曲同工之妙。 另外，若比喻為規則系統，則資料連結架構，可以看作是一個簡單的同步規則系統： 來源端資料的異動與否，可以看做前提
5、（Antecedent） ，而目的端資料的異動便成了結 論（Consequent） ；來源與目的端的資料同步，剛好就是前提匹配直接帶動結論套用， 是非常直覺的規則運作模擬。像 JDB支援抽象化的來源與目的物件，更有可能成功模擬 複雜的規則前提與結論。但要是我們的同步規則系統再複雜一些，還能處理建議型 的前提匹配與結論套用（即資料來源和目的端是間接、不立即同步的，隔著一層建議做 緩衝） ，那勢必還要進行一番不小的調適工程。 2.1.3 模型 作為物件的範本、準則，模型在工業上，代表大量生產的第一步；在知識上，則是一以 貫之、舉一反三的開始。模型之於系統，猶如藍圖之於建築、或塑膠賞玩之於鋼鐵巨械
6、或血肉之軀。模型是最終結果的抽象化，將有特別意義的部份自結果中抽取出來、特別 - 9 - 強調，以方便大量生產，或人們理解，因此平面模型往往搭配圖形化，如建築藍圖。此 特性對軟體系統同樣成立，當軟體模型有圖型化加持，開發者的思考變得立體化、意象 化、更生活化；不同層次的需求藉由圖、文分離，讓開發者也不再迷失於茫茫原始碼大 海。 挾著圖形化的優勢，模型越來越受軟體開發者的重視與青睞，如物件經理團 （Object Management Group，OMG）所制定的 UML【9】 ，便是集常用軟體模型語言於一身的超 大規模模型語言標準。可是就在同時，抽象化與圖形化也對低階的電腦處理器帶來處理 障礙，
7、因此為了使軟體模型具有實用價值，高階模型與低階可執行碼間的轉換，順勢成 了關鍵議題。 至於這樣的轉換，若不希望等有了模型產出後才考慮如何進行，而是希望能夠適應 所有模型產出而自動進行，則勢必要事先開發出一套目標模型語言和目標程式語言間的 轉換系統，亦即對模型的解釋模型（Meta-model） 進行處理，而這個解釋模型，就 是我們通稱的語言（Language） 。要是再進一步，希望任何語言之間的轉換系統，都能 自動產生，達到系統開發的理想世界，就得抽象再抽象，前去探討語言的解釋模型 解釋解釋模型（Meta-meta-model） ，或解釋語言（Meta-language）這便是解 釋物件設施（M
8、etaObject Facility，MOF【14】 ） 的目的。MOF藉著在解釋語言層次， 定義眾語言的異同之處，搭起語言間的永久橋樑。往後只要新語言加入同一個解釋語言 家庭，藉著定義出和其他語言間的異同關係，則新語言和其他語言間的轉換關係，也就 馬上透過解釋語言自動建立了。此時或許已有讀者看出，這模型與解釋模型的關係，似 乎仍可繼續遞迴下去，這種遞迴的關係，正是模型驅動建構（Model Driven Architec- ture，MDA【15】 ）的立論基礎。 以上述的模型導向系統開發和模型轉換概念為核心，漸漸也帶動起了模型驅動軟體 開發（Model-Driven Software Dev
9、elopment，MDSD【16】 ） （或簡稱模型驅動開發， Model-Driven Development，MDD，或模型驅動工程，Model-Driven Engineering，MDE 【17】 ）這門學問。 - 10 - 2.1.4 模型轉換 軟體系統的模型，就好比系統的 X光照片、斷層掃描圖、血液分析報告、或者建築藍圖 等等，從各式各樣不同角度觀察同一個系統。模型轉換，則為了各種角度觀察者的不同 喜好、需求而存在。模型轉換的數學意義，通常是可逆的若且惟若（If and only if） ， 即雙向工程所追求的同步。目前常見的模型轉換技術，通常是轉換不同抽象層次的模 型，還可依模型
10、轉換和模型編輯是否可同時進行，再分成線上（即時）或離線（批次） 轉換。 現代化 IDE必備的 UML物件類別圖原始碼雙向工程、以及【18】中的 UML 至 ESCM 等，便是典型的線上轉換。TXL【19】 、MDA、UMLX【20】 、ATLAS 轉換語言 （ATLAS Transformation Language，ATL【21】 ）與 IBM模型轉換框架（Model Trans- formation Framework，MTF【22】 ）等，則多從探討離線轉換出發。而 MOF 2.0之查 詢檢視轉換規格（MOF 2.0 Query/View/Transformation Specifica
11、tion，MOF QVT 【23】 ） ，則同時保留了線上與離線轉換的可能性。離線轉換的可擴張性（Scalability）較 低，若複雜系統在每次的微小修改後，都要進行全面、費時的批次轉換以確保同步， 將大大降低開發者的生產力。 目前已有如此多的模型轉換語言，嘗試在更廣的範圍，實現自動雙向工程。利用轉 換語言將模型轉換自動化，除了降低撰寫新模型的成本，間接提高既有模型的重用性 外，同時也避免了人為轉換的冗工與失誤，確保不同模型間具有一致性，減少產出的系 統內含矛盾之可能性。但是，越多的轉換語言被發明，也意味著需要越多的專家人力或 開發者教育訓練，對中小型開發團隊而言，幾乎是無法承受之重，因而侷
12、限了高品質系 統開發的推廣。 2.1.5 圖（Graph）轉換 要談模型轉換，就很難不提圖轉換。圖轉換的動機，較早是源於自動機（Automata）研 究，因自動機本身或其運行狀態，便可用圖的形式表示，故自動機的運作順勢成了 狀態（圖）與狀態（圖）間的變遷，即圖與圖間之轉換。圖轉換研究的核心，是探討如 - 11 - 何藉由次圖（Sub-graph）轉換規則的套用，在維持套用前後整圖語意正確性的前提下， 自動且正確地完成整圖間的轉換。著名的圖轉換實作技術或系統，有參數圖文法 （Attributed Graph Grammar，AGG【24】 ）和 Alloy【25】等。 無論圖或模型轉換技術原先發
13、明動機為何，兩者其實是可互通的。模型轉換技術進 展至目前，和圖轉換技術有相當密切關係；這是因為即使如模型這般強大的資料結構， 到底還是一種圖 ，故模型轉換到底還是圖轉換的延伸。因此，有堅實數學、邏輯基 礎的圖轉換理論，往往成為實現模型轉換的第一人選；TIGER【26】 、GROOVE【27】 、 CODEX以及 Eclipse的官方計畫 VIATRA2【28】 ，都是尋求這類實現的系統。 圖轉換雖然為模型轉換奠定了自動化的理論基礎，簡化了模型轉換的設計，但若加 進了模型內容包含大量自然語言這個不確定因素，則想要自動關聯這些自然語言文 字內容與模型圖語意，進而實現自動化轉換，現階段仍屬困難。 2
14、.1.6 自動化雙向工程 雙向工程【29】 ，顧名思義是指兩種不同方向軟工行為的結合：順向工程與逆向工 程。順向工程就是一般我們開發軟體的進行方向，由分析至設計以迄實作、測試、部署 等等。在軟體開發的過程中，我們多從事順向工程以完成系統。但當我們為了舊系統改 版或升級，而去試著了解舊系統時，我們便是在進行逆向工程。兩種行為並非互斥，且 遠比我們想像中更常同時並存於一個開發計畫中。 只是雙向工程的意義，要比純粹結合兩種方向來得深遠多了。之所以要進行雙向工 程，主要目標，還是為了維繫這雙向旅程兩端所代表的，仍是同一個系統，或稱讓兩端 同步，譬如維持原始碼端與二進位碼端的同步。有了同步的系統表達，開
15、發人員便可以 專注在他擅長、熟悉的一端工作，或許不同端有不同的專家，開發著不同的區塊，最後 卻還能結合成一個完整的系統。 自動化雙向工程，則企圖要讓電腦代勞雙向工程，包括接管傳統雙向工程中最受人 埋怨的瑣碎、機械化動作，以及改善人工同步容易產生的疏失。傳統雙向工程的自動化， - 12 - 多發生在設計與實作階段之間，如物件類別設計與原始碼實作，目前檯面上主流的 IDE 系統，像是 Eclipse、NetBeans【30】 、微軟 Visual Studio【31】 、Borland JBuilder【32】 與 Enterprise Architect 【33】 等等，皆已具備這類自動化雙向工
16、程功能。 Visual Paradigm 【34】的需求設計階段順向工程功能，還能從文字敘述產生使用案例，進而產生物件 類別等更細的設計，不過該功能尚無法以即時且自動的方式運行，也還無法反向操作 （由 設計到需求） ，離實現需求設計階段的自即雙工仍有段距離。 近年來，持續進步中的自動化雙向工程技術，已開始脫離傳統範疇，將觸角伸向更 廣的領域作嘗試。許多 IDE開始提供類似網頁超連結（Hyperlink）的機制，可連結模型 元素、檔案、網頁等等資源，以作為這些資源間雙向工程的同步基礎，在將來同步更新 時發揮提醒作用。如【13】便提到系統在高階數學模型、低階爪哇模型、更低階中間語 言模型與網頁文件
17、說明間之同步，這標誌著將模型轉換、圖轉換應用於自動化雙向工程 的里程碑。 然而，上述的超連結機制尚屬陽春，幾乎仍需開發者自行連結，IDE鮮少事先提示 開發者可連結之處。而隨著系統越複雜，連結需求越多，開發者越來越無法負荷人工連 結，且大量的人工連結工作也容易使開發者從主要的工作分心，導致開發者顧此失彼而 心生厭倦。再者，以模型轉換、圖轉換實現的雙向工程，也有轉換語言複雜的現象，反 而使處在真正應用端的應用領域專家不易使用。因此，自動化雙向工程，甚至自即雙工 技術，目前仍待持續開發，是一塊蓬勃發展中的領域。 2.2 自然語言斷詞領域 由 IBM 所主導的國際化統一碼元件（Internationa
18、l Components for Unicode，ICU 【35】 ） ，是一個開放原始碼計畫，目的是以開放、可攜、標準化的精神，開發、提供能 支援全球各地自然語言統一碼（Unicode）使用的相關軟體函式庫。ICU在 C/C+和 Java 兩大語言平台上分別實作，提供 ICU4C 與 ICU4J 兩種主要版本。另外，還有 ICU4JNI 版本，藉由提供可呼叫 ICU4C 字元集轉換與校對函式庫的 Java 應用程式設計介面 - 13 - （Application programming interface，API） ，讓使用者在 Java 下也能享用更高效率的字 元集轉換與校對功能。 ICU
19、函式庫中包含了自然語言斷詞器物件類別，該物件類別的一大特色，是針對複 合字（Compound word）斷詞部署了以字典為基礎（Dictionary-based）之斷詞法 。目 前 ICU4J 在以字典為基礎的斷詞功能方面，僅支援泰文（Thai）和德文兩種自然語 言，英文部分雖開始進行測試，然尚未成功。ICU4J 下的斷詞器com.ibm.icu.text. BreakIterator 物件類別，後來納入 Java 標準，成為 Java 自然語言處理函式庫的一 員 java.text.BreakIterator 物件類別。 【36】 2.3 人工智慧領域 2.3.1 知識本體與概念搜尋 知識本
20、體，根據格魯伯（Gruber, T. R.）於一九九三年所定義，是針對一些有興趣的領 域，所分享出來的對其了解，這通常會導致誕生一個內含物件類別（概念） 、關係、函 數、公理以及實例的集合。 （譯自【37】 ） 。由【37】同時可以看出，知識本體從哲學 層次走入資訊科技應用，是源於要讓電腦代理人（Agent）或機器人認識這個世界，以 及讓他們之間的溝通有個標準。不論代理人或者機器人，都是人工智慧與電腦邏輯領域 的顯學，於是乎知識本體的應用研究，立刻便和電腦邏輯緊密結合了。 知識本體與推論的應用領域，近幾年來越見寬廣，尤其是在全球資訊網 （World Wide We b，WWW）方面。譬如在增進
21、搜尋引擎表現的文件分類方面，有所謂建議上層共 用知識本體（Suggested Upper Merged Ontology，SUMO） 的基礎知識本體標準化計畫， 透過概念的標準化，再與其它知識如 Wo r d N e t 連結，將使關鍵字搜尋進化至概念搜尋 （Concept search【38】 ） 。此時，搜尋結果將不再只是符合我們所鍵入的字詞而已， 更有可能符合我們心裡所想的意思 。 【39】 - 14 - 2.3.2 WordNet Wo r d Ne t 是在心理學家喬治米勒（George A. Miller）指導下，結合其他多名語言學、 電腦科學與心理學家專長，由普林斯頓大學（Pri
22、nceton University）認知科學實驗室 （Cognitive Science Laboratory）持續開發中的免費、公開大型英語詞彙資料庫（Lexical database） ，目前進展到版本 3.0【3】 。不同於一般辭典（或電子辭典） ，Wo r d N e t 更顯得 結構化，可以提供一般辭典所沒有的、語言學（Linguistics）上的語意式、關聯式查詢； 例如較一般辭典涵蓋更廣的同義詞查詢，以及泛義上位詞（Hypernym） 、特義下位 詞（Hyponym） 、成分詞（Meronym） 、合成詞（Holonym）等等查詢【40】 。 同義詞集合（Synset）是 Wo
23、r d N e t 資料庫的獨特儲存單元。英語下的四大詞類（Part of Speech，POS）名詞（Noun） 、動詞（ Ve r b） 、形容詞（Adjective）和副詞（Adverb） 在 Wo r d N e t 中各自有其 Synset 群，每個 Synset不跨詞類，都是一個同義詞的集合， 用以表達獨特的同義概念；Synset 彼此之間再以概念語義（Conceptual-semantic）和詞 彙關係（如前一段末所舉的泛義上位詞、特義下位詞、成分詞、合成詞等等）互相 連結，這樣便形成了一個字詞（或概念）間以語意相連的網絡，而我們可以順著這些網 絡連結，進行語意關聯式的字詞概念導
24、航、查詢。這樣的網絡結構，便相當適合計算 語言學（Computational Linguistics）和自然語言處理之用。 【3】 Wo r d Ne t 除了底層資料庫，也開發有關聯導航查詢的介面；原生的查詢 API 以 C 語言寫成，另有網頁查詢介面以方便人們直接在網路上瀏覽。在眾多第三方的協助下， 現在，在 Java 程式下也可以輕鬆地使用 Wo r d N e t；例如，麻省理工學院（Massachusetts Institute of Technology）所開發的 Java 詞網介面（Java Wordnet Interface，JWI【41】 ） ， 以及 SourceF 下的
25、Java詞網函式庫（Java WordNet Library，JWNL【42】 ）計 畫等，均提供了純 Java 撰寫的物件化存取 API，不但使 Wo r d Ne t 也有了可享受 Java跨 平台可攜好處的版本，同時隱藏 Wo r d N e t 較繁雜的資料庫格式，也更方便物件導向 （Object-oriented）開發者來利用。其中的 JWI，是截至目前為止較為活躍的計畫。 - 15 - 2.3.3 資訊擷取與知識發現 傳統人工智慧的主流是知識本體與語意推論，例如以命題邏輯（Propositional Logic 【43】 ） 、一階邏輯（First-order Logic【43】
26、）或描述邏輯（Description Logic【43】 ）等語 言，來表示這個世界的知識、規則，並進行推論。 這些先寫好規則、由上而下（Top-down）的先知型人工智慧演算法，相當依賴複雜 的專家邏輯指導。近幾十年來，隨著電腦硬體或平行運算效能進步，與擁有成本的大幅 降低，以大量樣本資料觀察為基礎的統計型、由下而上型（Bottom-up）人工智慧開始 興起，現今最炙手可熱的統計型人工智慧技術非資訊擷取（Information Retrieval【44】 ） 莫屬，當紅的全球資訊網搜尋引擎 Google【45】 ，便是這項技術的最佳代言人。 資訊擷取技術，植基於由統計學支撐的共生理論（Co-
27、occurrence Theory） ： 若兩項 目常常共同出現在一個單元當中，且出現之情形突破了事先定義的門檻，則我們有理由 相信，在他倆間存在強烈之關聯（或相似性） 。 （譯自【37】 ） 。資訊擷取以斷詞技術， 自茫茫資料海中取出關鍵項目（若這片資料海是一份純文字文件，則關鍵項目就是 我們在搜尋引擎領域相當熟悉的關鍵字 ） ，然後再發展出各式各樣處理關鍵項目的演 算法，以判斷文件的相似度。 透過資訊擷取技術的進展，使網際網路資料搜尋起了革命性的改變；改變的核心， 來自於資訊科技不再只是幫人們做地毯式的搜尋，獲得改善的結構化搜尋，甚至可以幫 人類發掘資料和資料間的關聯而這不正是知識的源頭麼
28、？因此有人認為，資訊擷取 只是暖身，下一步就是知識發現（Knowledge Discovery） 、萃取知識本體：搭配同時 漸趨成熟的資料掘礦（Data Mining）與機器學習（Machine Learning）等其他統計型人 工智慧技術，全球資訊網所蘊藏的大量知識，將得以更輕易地被發掘出來。 在 【37】 中曾提及利用資訊擷取技術，可輔助產生知識本體，進而實現 概念搜尋 ； 而所謂概念 ，其實不也正是知識的分類？資訊擷取所企求的分類？統計型人工智慧 和傳統的先知型人工智慧，正從知識金字塔的上下兩端，逐步接近，透過兩者互補，人 工智慧將越來越聰明、越來越經濟、越來越普及、越來越有人性。 -
29、16 - 2.4 Eclipse相關技術 Eclipse 是個多元化的 IDE 平台，除了延伸自傳統 IDE 的多樣程式語言支援外，更致力 朝先進的整合開發平台邁進，包括支援重構、視覺化圖形化系統開發、MDA 等等， 都是近年來 Eclipse 相關社群研發的重點。這裡我們舉斷詞技術、Eclipse 塑模計畫 （Eclipse Modeling Project【46】 ） 、Eclipse塑模框架（Eclipse Modeling Framework， EMF【47】 ） 、圖形化編輯框架（Graphical Editing Framework，GEF【48】 ） 、GMF及 其裝飾服務（De
30、coration Service【4】 ）來介紹。 2.4.1 程式碼斷詞技術 在程式碼的用詞中，其實也存在大量的自然語言成份，這是另一個斷詞技術發揮的 領域。與自然語言較為不同的是：若扣掉註解部分，則在現代 Java系統開發過程中，對 自然語言使用量最大的部分，當屬依駱駝命名法（CamelCase【49】 ，即複合字內的次 字串sub-string以大寫起首）或底線（ _ ，underscore）分隔命名法及其變型，而 生產出來的大量複合字識別項。 Eclipse 下有IWordDetector【50】 ，是個具有高度彈性的斷詞器介面，設計用來 搭配可掃瞄、剖析（Parse）Java程式碼的
31、WordRule【50】詞掃瞄規則架構。IWord- Detector 提供了擴充建構複合字斷詞器的基礎，不過目前還未發現公開的駱駝命名斷 詞器實作類別。 Java 開發工具集（Java Development Tools，JDT【51】 ） 則是讓 Eclipse 平台成為 Java IDE 的核心部件，提供包括程式碼編輯器在內等眾多 Java 開發輔助工具。JDT 的 Java 程式碼編輯器搜尋器，便支援以駱駝命名巡覽（Navigate）搜尋識別項；不過， 這種支援在目前似乎還是以供 JDT內部使用為主。JavaSourceViewerConfigura - tion【52】物件類別儲存了
32、 JDT 在執行階段原始碼（程式碼）的顯示組態，提供有 RuleBasedScanner 程式碼掃描器；但我們在該掃描器的內建規則中，也都尚未發現 包括以上斷詞規則在內，可供外界重複利用的相關公開資訊。 - 17 - 2.4.2 Eclipse塑模計畫 梭是一套處理模型的工具，且模型資訊同步引擎基本上也是一個自動、即時的模型 轉換系統，所以我們需要加強聚焦在塑模的領域。既然 Eclipse 是梭系統將要棲身 的平台之，則在 Eclipse 上的塑模研究進展，更是絕對不能放過的焦點。 Eclipse 塑模計畫集 Eclipse下所有塑模相關研究之大成，是 Eclipse官方正在進行的 一級（To
33、p-Level）計劃，旗下子計畫族繁不及備載，有研究基礎模型結構的 EMF，以 及與系統開發流程息息相關的通用塑模工具集（或稱通用塑模科技群） （Generative Modeling Tools【53】或 Generative Modeling Technologies【46】 ，GMT） ，而 GMT 也 正是一個多子多孫模型轉換語言大家族，諸如 UMLX、 ATL、 VIATRA2 等等的發源地。 2.4.3 EMF 塑模在系統開發中扮演了越來越吃重的角色，因此一套好的 IDE，理當也要提供好 的塑模環境不僅要有圖形化模型編輯環境，更要在系統模型的邏輯正確性上同步下 功夫。在這樣的需求下
34、，EMF便應運而生。與 GMF 在視覺層次支援各式各樣模型的策 略不同，EMF 著重在提出自己的一套塑模辦法，以邏輯層次的正確性、高效率模型開 發與原始碼生成為特色，至於視覺表達的層次，則就借用 UML 已有的豐富符號，不再 費力閉門造車。 EMF 包含三個部份：一是核心 EMF，提供 Ecore 這個跨平台塑模語言，以及相關 的 Ecore 模型存取機制包括 Java 存取，及以 XML 方式存取的XML 解釋資料交 換（XML Metadata Interchange，XMI【54】 ） ；EMF.Edit提供生成 Ecore 模型編輯器所 需的相關函式庫，包括與 Eclipse JFac
35、e GUI 整合、支援復原重複（Undoredo）編輯 機制等等的函式庫；EMF.Codegen 則是負責將以 Ecore 表達的平台中性模型（Platform Independent Model，PIM） ，生成最終的 Java 平台原始碼（包括 Ecore模型及其編輯器） ， 而這個 PIM 與 Java間的生成對應關係，也再度利用了 Ecore 來表示，稱為genmodel ， 頗有靜態 MDA編織模型（Weaving Model）的味道，最後，透過範本（Template）方式 處理 genmodel，產生可執行的程式原始碼。EMF 使系統開發者不必再把主要心思放在 - 18 - 枝節末
36、微的程式碼，而改放在較高階、宏觀的 Ecore 系統設計、架構層次，簡單創造出 規劃更完善的高品質系統。 不過，受限於 Ecore 的定義，目前 EMF 僅在結構型（Structural）模型，且主要是 物件類別模型方面的支援較為齊全。但 EMF.Codegen 所提供的部分 Java 實作，在執行 階段可自動確保模型的一致性，並增進模型運作的效能，這對 Java程式設計師而言已是 相當大的便利。 誠如模型為實物之母 ，EMF 形塑了 Eclipse 世界的基礎，就像基本元素一般， 萬物遂由此而大發生。由 EMF 衍伸出的各式各樣技術開發需求，其規模之大，促成了 EMF科技群（Eclipse
37、Modeling Framework Technologies，EMFT【55】 ）計畫；旗下譬 如模型交易（Model Transaction，MT【56】 ）技術，便是專為高效存取 Ecore 模型與聯 絡 Eclipse塑模環境而開發，其支援多緒 Ecore 模型存取、批次化 EMF事件通知、整合 管理高階的包裹化模型編輯與低階的 Eclipse全域資源（Resource）變更復原重複等 等。 2.4.4 GEF與 GMF GEF 提供一般化的圖形編輯器框架 API，便於在 Eclipse 上建構高階、應用領域的圖形 編輯器，如 Swing GUI 編輯器、UML 編輯器、HTML編輯器
38、、甚至辦公室文件編輯器 等等。 GEF 以階層式的 MVC 樣式規劃、設計，如圖 二-1；其中模型是由各領域專 家提供、以 Java 物件一般化的領域模型（Domain model） ； 視界由領域模型元素對應 之 IFigure 圖形元件構成，IFigure 符合 Eclipse平面繪圖、顯示之 Draw2D規格； 控制 器則由 EditPart 組成，每個 EditPart 都是一個編輯調控單元，負責提供編輯功能、控 制領域模型元素與 IFigure 保持同步。要完成一個 GEF 編輯器，必須完成 IFigure 與領域 模型元素物件間之對應，以及操作 EditPart 以處理實際發生的模
39、型編輯行為（包括與編 輯器工具調色盤，PaletteTool，間之互動） 。 - 19 -雖然 GEF 已封裝起 Eclipse的低階二維繪圖與編輯器運作機制，簡化不少編輯器製 作流程；但對各領域的塑模專家而言，該領域模型才是他們的專長，要具體理解 IFigure、 EditPart 和工具調色盤，以真正使用它們之間的互動 API 實作出編輯器，等於進入另一 個新領域，得從零學起，障礙不低。GEF 雖是一般圖形編輯器玩家的強大武器，但也是 讓圖形化塑模專家眼花的一堆零件。 圖 二-1 GEF（上）與 GMF（下）的模型視界控制器架構，整理自【4】 。 - 20 - GMF 正是為克服這個障礙而
40、生，它建立在 GEF 之上，提供整合、更高階、模型層 次的圖形化塑模框架，善用 EMF 優勢，以 Ecore 模型取代 Java API 為框架主要介面。 為了利用 EMF， GMF 將領域模型進一步分離出符號型 （Notational） 與語意型 （Semantic） 兩部分。語意型部分仍是 GEF 可接受的 Java 物件模型，但現在，使用者改為面對符號 型部份，符號型部份採用 Ecore 為解釋模型，用來描述領域模型的圖形化符號並封裝 IFigure，藉此減少使用者直接接觸低階、惱人的 Java 物件模型、EditPart、IFigure等等。 GMF 架構與 GEF差異如圖 二-1。
41、這下使用者就可以 Ecore 描述領域模型、圖形化定義（Graphical Definition）與工具 調色盤定義（Tool Definition） ，以 genmodel 描述這些模型、定義與 EditPart之對應，接 下來便可經 EMF.Codegen 轉換，生成 Java物件模型、EditPart 實作和 IFigure，以繼續利 用 GEF 機制實際進行編輯器的產出與運作。運用 GMF 的開發流程如圖 二-2。可以把 大部分時間花在和較高階的 Ecore互動，領域專家的負擔減輕不少了。 圖 二-2 典型的 GMF編輯器開發流程，取自【5】 。 - 21 - 2.4.5 GMF裝飾服
42、務 與 JDT 和多數塑模工具相同，為了以視覺化、圖形化的友善方式，適時提示關於待編輯 模型物件的資訊，GMF 也提供了所謂的裝飾服務（或稱裝飾員服務， org.eclipse.gmf.runtime.diagram.ui.services.decorator【57】 ，這識 別項也是該服務主包裹的名稱） ，如圖 二-3。裝飾服務與 GMF 編輯器連結，藉由服務 下設定的裝飾員提供者（IDecoratorProvider） ，以其 provides(IOperation operation)布林方法判斷裝飾時機點，在時機點來臨時，在其 createDecora- tors(IDecorator
43、Target decoratorTarget)方法中安裝裝飾員（IDecora- tor） ，並對合乎支援條件的裝飾目標（IDecoratorTarget） ，覆上或移除影像 （Image）圖形（IFigure）裝飾（IDecoration） 。 【58】 【59】 圖 二-3 GMF裝飾服務下，提供第三方服務承包商實作使用的主要物件類別與介面，以及彼此間的互動 關係，取自【4】 。 - 22 - 以 Java 介面（Interface）型式設計的裝飾服務，其實就是一個服務外包的窗口；而 外顯裝飾員提供者（Presentation Decorator Providers，正式識別代號 org.
44、eclipse.gmf.runtime.diagram.ui.decoratorProviders【57】 ）這個 Eclipse 延伸點（Extension Point） ，則是窗口的另一部分。實作服務細節的第三方服務承 包商（通常是解釋模型GMF 編輯器的設計者）可透過這個延伸點，向 GMF 註冊裝 飾員提供者這個服務提供者（Service Provider，IProvider【60】 ） ，而承包商實 作的其他裝飾員 、 裝飾目標 、 裝飾等等成員，則能間接被裝飾員提供者呼 叫、使用到，最後合力完成裝飾工作。 利用擴充延伸點，註冊外包服務提供者，這不只是 GMF，也是 Eclipse 下
45、的標準做 法。延伸點也可作為分享、使用特定 Java 函式庫的入口代表，讓 Eclipse 只載入延伸點 宣告需要的特定函式庫物件類別，這樣就可以在 Eclipse 啟動時，省下掃描、載入所有 函式庫物件類別的而白費的系統資源與時間。 GMF 的呼叫服務承包商機制，在執行階段也負責自動、適時地篩選已載入編輯器 的模型物件，再透過 provides(IOperation operation)和 createDecora- tors(IDecoratorTarget decoratorTarget)兩約定方法，供編輯器的外掛套件 判斷該元素是否需要裝飾。在複雜的 Eclipse與 GMF 環境下，這種封裝起來的編輯器監 聽機制，既可省下第三方外掛套件開發者自行撰寫篩選機制的時間，也能把篩選機制的 效能最佳化等問題，留給最熟悉 Eclipse與 GMF 的官方開發團隊，讓彼此在擅長的領域 分工合作。
