模型驅動架構之 Query/View/Transformation 技術研究

(1)

國立臺東大學資訊管理學系碩士班碩士論文

模型驅動架構之

Query/View/Transformation 技術研究

研究生：陳亮聿撰指導教授：辛信興教授

中華民國一 ○ 二年六月

(2)

(3)

(4)

謝誌

時光飛逝，待在臺東的時間已經六年了，從18 歲高中畢業後即進入到臺東大學就讀，在這好山好水的地方完成我的學士學位以及碩士論文，真的是人生當中非常值得回味與紀念的事。

如今，論文以及口試已順利完成，非常感謝辛信興老師給我的鼓勵和指導，

由於老師悉心的教導讓我在程式碼的研究領域有所發揮，不時的討論並且指點我正確的方向，學會如何面對各種困難與挑戰以及解決問題的方法，這不僅是研究生涯中最大的收穫，相信在未來也能學以致用。同時也要感謝口試委員夏則智老師與陳宜檉老師在論文研究期間不吝的給予指導並提供寶貴意見，讓我的研究更加完善。

感謝研究所的同學依稀、欣怡、文馨、清欽、建堯、政勳、愷奇，一起參與活動、上課、作報告並分享學習意見，互相扶持與督促，能夠在學習生涯中遇見你們，真的非常開心。另外也要感謝一路上一直支持我的家人，能夠在學校課業忙碌之中，給予我生活上的關心和幫助，也為我打氣加油，成為我學習的動力。

此外，在這裡也要感謝中華扶輪教育基金會，不僅是獎助學金上的資助，藉由獎助學金加入了扶輪社獎學生聯誼會，讓自己能夠有機會認識到更多不同學校的優秀人才，得到更多的人脈，一起交流，一起學習並分享，對於研究過程中幫助甚大，非常謝謝扶輪社給予我們這些年輕學子擁有更好的學習環境以及提供多元的學習方式，最後，特別感謝臺東大學，提供良好的學習環境，在這美麗的後山當中學習，給予我向前的動力。

陳亮聿謹誌國立臺東大學資管系碩士班 2013 年 6 月

(5)

中文摘要

模型驅動架構（Model Driven Architecture, MDA）已經成為物件導向分析與設計的趨勢，MDA建構Query/View/Transformation (QVT)技術來提升模型的自動化轉換程度，將系統分析所產出的模型以QVT程式進行轉換，最終產生程式碼。

但其轉換過程複雜，且大部分QVT研究針對特定問題做片段式的探討，目前研究中較少對三層式軟體，完整探討介面層、應用軟體層與資料層的轉換過程，並驗證其可行性。因此本研究先對QVT語言進行介紹，說明如何以QVT描述轉換規則，並實際對三層式軟體進行平台獨立模型（Platform-Independent Model, PIM）

至特定平台模型（Platform-Specific Model, PSM）的模式轉換，最後以Borland Together驗證QVT程式碼的可行性，並探討轉換過程中所發生的相關問題及QVT 的優缺點。

關鍵字：模型驅動架構、Query/View/Transformation技術、平台獨立模型、特定平台模型

(6)

Abstract

Model Driven Architecture (MDA) has become the trend in the field of object-oriented systems analysis and design (OOAD). MDA created Query/View/Transformation (QVT) to raise the automatic level of model transformations. Models of OOAD can be transformed into the next-level models, and finally into code. However, the transformation is complex, and QVT studies mostly focus on specific research questions. Few studies have examined the feasibility of implementing 3-tiers applications using MDA, and demonstrated the transformation process of user interface, application, and data tiers. First, this study introduces the QVT techniques, and shows how to express transformation rules using the QVT language. Then, we create a 3-tiers application, and implement the transformation from the Platform-Independent Model to the Platform-Specific Model. Finally, we demonstrated this case by using Borland together, and discuss related questions occurred during the study.

Keywords : Model Driven Architecture, Query/View/Transformation, Platform-Independent Model, Platform-Specific Model

(7)

目錄

謝誌 ... I 中文摘要 ...II ABSTRACT ... III

第一章 緒論 ...1

1.1 研究背景與動機 ...1

1.2 研究目的...2

1.3 研究方法與流程 ...2

1.4 研究範圍與限制 ...3

1.5 論文架構...4

第二章 文獻探討 ...5

2.1 U^NIFIEDM^ODELINGL^ANGUAGE...5

2.1.1 類別圖 ...7

2.1.2 Meta Object Facility (MOF)...10

2.2 模型驅動架構... 11

2.2.1 MDA 的 CASE 轉換軟體 ...13

2.3 QVT 轉換技術介紹 ...14

2.3.1 Object Constraint Language...15

2.3.2 QVT 相關研究 ...15

2.4 QVT 基本語法 ...16

2.4.1 基本操作語法與變數 ...16

2.4.2 基本型態描述 ...17

2.4.3 運算式 ...17

2.4.4 條件判斷式語法描述 ...18

2.4.5 集合類型 ...19

2.5 QVT 轉換語法 ...19

2.5.1 main 程序 ...19

2.5.2 轉換函數之語法 ...20

2.5.3 用於轉換函數主體之相關語法 ...20

2.6 Q^UERY函數、WHEN子句與RESOLVE新增語法 ...21

2.6.1 Query 函數語法 ...22

2.6.2 when 子句 ...22

2.6.3 resolve 新增語法 ...24

2.7 轉換程式碼的基本架構 ...24

2.7.1 Meta-Model 的定義 ...26

(8)

2.7.2 轉換進入點 ...26

2.7.3 toSchema 函數 ...26

2.7.4 toEntityInitial 函數 ...27

2.8 小結...28

第三章 QVT 轉換規則 ...29

3.1 模式轉換規則：自然語言表示法 ...29

3.2 模式轉換規則：QVT 語言表示法 ...30

3.2.1 使用者介面層之轉換規則 ...31

3.2.2 企業邏輯層之轉換規則 ...35

3.2.3 資料層轉換規則 ...40

第四章 轉換個案 ...46

4.1 個案之PIM...46

4.2 個案之PIM 至 PSM 轉換 ...48

4.2.1 介面類別轉換 ...48

4.2.2 控制類別轉換 ...50

4.2.3 實體類別轉換 ...51

4.2.4 介面類別與控制類別關聯線之轉換 ...54

4.2.5 控制類別與實體類別關聯線之轉換 ...55

第五章 展示與驗證 ...57

5.1 建立個案之PIM 類別圖 ...57

5.1.1 建立專案與類別圖 ...57

5.1.2 類別圖屬性型別定義 ...61

5.2 建立QVT 轉換檔 ...72

5.2.1 在專案中新增個案之 QVT 程式 ...72

5.2.2 專案執行 QVT 轉換檔 ...74

5.3 結果展示...77

第六章 結論與建議 ...79

6.1 結果分析...79

6.2 研究成果與貢獻 ...81

6.3 未來研究方向...82

參考文獻 ...83

附錄 ...86

(9)

表目錄

表1.UML 圖形種類及說明 ...6

表2. 類別間關聯關係表示符號...9

表3.MDA 轉換工具列表 ...14

表4. 過去學者之QVT 研究 ...15

表5.QVT 基本資料型態 ...17

表6.QVT 基本運算符號 ...17

表7.B^OOLEAN、I^NTEGER/R^EAL基本運算...18

表8. 字串基本運算 ...18

表9. 集合表達類型 ...19

表10. 使用者介面轉換規則...29

表11. 企業邏輯轉換規則...30

表12. 後台資料庫轉換規則...30

表13.P3 規則與其對應語法 ...33

表14.P4 規則與其對應語法 ...34

表15.B1 規則與其對應語法 ...35

表16.B2、B3 規則與其對應語法 ...36

表20.D1 規則與其對應語法 ...41

(10)

圖目錄

圖1. 研究流程 ...3

圖2.UML 圖形架構圖 ...6

圖3. 類別圖之三個元件 ...8

圖4.MOF 架構 ...10

圖5. 類別圖之MOF 架構 ... 11

圖6.MDA 軟體發展生命週期 ...12

圖7.MOF 中 MDA 的轉換架構 ...13

圖8.QVT 語言的關係架構 ...15

圖9. 進入點之語法說明 ...20

圖10. 轉換函數之語法說明...20

圖11. 新增集合變數之語法說明圖...21

圖12. 初始部分直接呼叫函數之語法說明...21

圖13.Q^UERY函數語法...22

圖14.^WHEN子句程式碼...23

圖15.^RESOLVE使用之語法 ...24

圖16. 轉換程式碼之架構 ...25

圖17.BÔRLANDTÔGETHER軟體平台中MÊTA-MÔDEL的定義 ...26

圖18. 轉換進入點MAIN程序 ...26

圖19.^TOS^CHEMA函數程式碼...27

圖20.^TOE^NTITYI^NITIAL函數程式碼 ...28

圖21.P1 規則之轉換圖 ...31

圖25.B1 規則之轉換圖 ...35

圖26.B2、B3 規則之轉換圖 ...36

圖30.D1 規則之轉換圖 ...41

圖34. 網路購物商店個案之PIM ...46

圖35. 網路購物商店個案之PSM...48

圖36. 個案使用P3 規則之轉換圖 ...49

(11)

圖38. 個案使用B1 規則之轉換圖 ...50

圖40. 個案使用D1 規則之轉換圖 ...52

圖47. 在B^ORLANDT^OGETHER平台中建立新的UMLP^ROJECT...57

圖48. 在B^ORLANDT^OGETHER平台中完成UMLP^ROJECT的建立...58

圖49. 在BÔRLANDTÔGETHER平台中建立新的PÂCKAGE...59

圖50. 在B^ORLANDT^OGETHER平台中建立類別圖 ...60

圖51. 在B^ORLANDT^OGETHER平台中建立類別圖屬性 ...61

圖52. 在B^ORLANDT^OGETHER平台中建立P^ROFILEP^ROJECT...62

圖53. 新增P^ROFILEP^ROJECT內元素...63

圖54. 在P^ROFILEP^ROJECT內新增S^TEREOTYPE與其關聯線...64

圖55. 在P^ROFILEP^ROJECT內建立PALETTE CONTRIBUTION與其關聯線...65

圖56. 在P^ROFILEP^ROJECT內設定所擴充的圖形...66

圖57. 佈署P^ROFILEP^ROJECT至B^ORLANDT^OGETHER中...67

圖58. 在UMLP^ROJECT內引用P^ROFILEP^ROJECT...68

圖59.UMLP^ROJECT完成P^ROFILEP^ROJECT的引用 ...69

圖60. 使用P^ROFILE所擴充之型別 ...70

圖61.B^ORLANDT^OGETHER平台中完成之PIM...71

圖62. 新增檔案至B^USINESSP^ROJECT...72

圖63. 建立QVT 檔至 B^USINESSP^ROJECT...73

圖64. 選擇來源模型B^OOK進行轉換 ...74

圖65. 選擇執行轉換語言檔...75

圖66. 選擇目標模型存放位置...76

圖67. 完成轉換後左側目錄圖...77

圖68. 本研究實作轉換之PSM 結果圖 ...78

(12)

第一章緒論

1.1 研究背景與動機

Unified Modeling Language (UML)是目前進行系統分析與設計所廣泛使用的一種塑模技術，其擁有統一以及視覺化的特點。相較於使用文字描述，圖形化技術讓使用者、系統分析師與程式設計師等更容易理解，使資訊更有效率的傳遞，

進而加速整個系統分析的過程。雖然UML提供一致的表達型態讓開發人員進行系統塑模，但是所產出的模型無法自動轉出程式碼，僅能做為開發人員在開發系統時的參考。因此，許多程式設計師傾向直接撰寫程式碼，省略系統塑模工作，

或系統塑模未確實執行，導致系統分析結果與最終程式碼不一致；或在分析階段中，將系統的邏輯與實作平台結合，但此舉將造成系統在未來轉移實作平台的困難，其原因在於所塑模出的系統邏輯已經與實作平台相結合，導致必須重新進行分析以及塑模的情形發生，而在後續階段才進行修正，所花費的成本相當大[8]。

針對上述問題，因此Object Management Group (OMG)提出了模型驅動架構

（Model-Driven Architecture, MDA），MDA把系統開發視為是模型建構與模型轉換的過程。開發生命週期中每一階段的產出都以UML模型的方式表現，再利用 QVT(Query/View/Transformation)轉換語言對模型進行自動化轉換，最終產出程式碼。QVT建構在一個四個層次的Meta-model架構上，許多研究指出QVT與其 Meta-model的複雜度已經對MDA的實現造成影響[6]，而且QVT包含多種技術規格也提高QVT實作上的難度，例如Object Constraint Language (OCL)與Meta Object Facility (MOF)，目前大部分QVT研究僅針對特定問題做片段式的探討，

少有研究以QVT對三層式系統的介面層、應用軟體層與資料庫層進行完整的轉換研究。目前已經有非常多的系統採用三層式架構，本研究成果將有助於業界實務上進行MDA系統開發的參考，對學界進一步探討MDA在三層式系統的模式轉換上也能提供初步的可行性驗證。

(13)

1.2 研究目的

基於上述研究背景與動機，本研究將對QVT作完整介紹、說明如何以QVT 描述轉換規則、並以三層式系統個案進行模式轉換，最後以Borland Together驗證所產出的QVT程式之可行性，再以該個案探討以QVT進行模式轉換的優缺點。

1.3 研究方法與流程

本論文採用研究與開發(Research and Development, R&D)之研究方法 [24]，

亦即研究在MDA 架構下使用 QVT 語言轉換 UML 模型，並以此方法撰寫 QVT 轉換程式碼，藉由程式碼的開發過程發現問題，並藉由解決問題的過程中探討如何以QVT 表達模式轉換規則，並探討 QVT 的困難點，如此反覆進行。

本研究之研究流程如圖1，分成理論架構的研究、程式碼研究以及範例實作三個部分。理論方面以文獻回顧的方式瞭解UML中圖形的分類與應用、MDA的運用與QVT語言架構，並瞭解如何在MDA架構下，運用QVT語言進行UML模型的轉換。基於理論方面以及相關資料的分析後，開始進行QVT程式碼的研究與撰寫，並使用UML模型進行測試轉換，反覆測試QVT轉換程式。再建立一個三層式系統的轉換個案，並且在Borland Together軟體平台上進行實作，最後提出研究結論，敘述本研究成果、貢獻與未來研究方向。

(14)

探討研究背景、動機、目的

文獻探討

1. QVT技術架構研究 2. QVT語法研究

3. 以QVT語言撰寫轉換規則

轉換程式測試

個案應用與分析

撰寫論文

Borland Together個案實作探討研究背景、動機、目的

文獻探討

1. QVT技術架構研究 2. QVT語法研究

3. 以QVT語言撰寫轉換規則

轉換程式測試

個案應用與分析

撰寫論文

Borland Together個案實作

圖1. 研究流程 1.4 研究範圍與限制

(1) MDA模式轉換可能涉及各種UML圖形之間的轉換，本研究僅探討類別圖之間的轉換過程。

(2) 不同的 PSM 可能需要不同的轉換規則，本研究僅探討範例中針對 HTML、PHP以及MySQL之特定技術的轉換規則。

(3) 由於系統開發之轉換規則有無限多種可能，因此，本研究以辛信興[32]的轉換規則為探討範圍。

(15)

1.5 論文架構

本文總共分成六個章節，第一章描述研究背景、動機與研究目的；第二章是文獻探討，介紹UML中使用到的圖形、MDA技術以及QVT轉換技術與架構，並介紹OCL；第三章介紹如何以QVT表達模式轉換規則。第四章則是利用第三章所介紹的轉換規則之QVT程式碼，建立一個三層式系統範例進行演練，第五章以 Borland Together進行QVT的案例轉換實作，最後展示結果，第六章為結論及建議，描述研究成果、研究貢獻及未來研究建議。

(16)

第二章文獻探討

本章節介紹UML、MDA與QVT轉換技術架構，其中包含MOF與OCL的相關說明，最後介紹QVT基本語法以及整體程式碼架構。

2.1 Unified Modeling Language

UML 是 1995 年由 Booch 與 Rumbaugh 提供給 OOPSLA(Object-Oriented Programming System, Language and Applications)的統一方法（Unified Method），

之後再加入了Jacobson的研究後正式命名為UML，UML是一種視覺化的塑模語言[31]，使用模型與圖示表達系統的分析結果，UML 0.9和0.91版的文件期待UML 成為一套用來建立系統模型的通用性語言，即UML可以表達許多不同種類與目的之模型，就像人們使用程式語言或自然語言一樣[20]。UML已經成為軟體需求塑模分析與設計的標準語言[17]。UML以MOF為基礎提供一致性的說明，讓使用者在進行系統分析有統一的表達方式，進而解決過去各個使用者表達方式不同的問題[27]。UML也提供了擴充功能，讓使用者能針對UML不足之處加以定義擴充[28]，亦即profile技術。UML將提供的圖形技術分成兩大類：行為圖以及結構圖（如圖2）。

(17)

UML圖

結構圖

行為圖

類別圖

元件圖

部署圖

輪廓圖套件圖

活動圖

使用個案圖

狀態圖

互動圖

循序圖

溝通圖

時序圖

互動概觀圖複合結構圖

物件圖

UML圖

結構圖

行為圖

類別圖

元件圖

部署圖

輪廓圖套件圖

活動圖

使用個案圖

狀態圖

互動圖

循序圖

溝通圖

時序圖

互動概觀圖複合結構圖

物件圖

圖2. UML 圖形架構圖

行為圖用來描述系統或是企業的行為特徵，包含活動圖、狀態圖、使用個案圖與互動圖，其中互動圖裡面又包含了溝通圖、互動概觀圖、循序圖以及時序圖；

結構圖則是描述系統的靜態資訊，包含類別圖、複合結構圖、元件圖、部署圖、

物件圖以及套件圖[2]，相關說明整理如表1，並針對本研究使用的類別圖形再進一步說明。

表1. UML 圖形種類及說明

圖形種類功能說明

使用個案圖以使用者的觀點來描述系統使用者與系統之間的

互動關係。

類別圖類似於資料庫中的ER圖，類別圖表示了系統中存

在的物件型態（或稱類別）及各物件型態之間的靜態資料結構與邏輯關係，也包含了類別之屬性、操作與類別間連接之限制等。

物件圖用來描述一系統於某個特定時間點之靜態資料結

構。

循序圖用以描述系統運作時物件之間的互動行為，並著

重以時間之先後順序為主軸來表達物件之間訊息傳遞的處理程序。

溝通圖表達相關物件間的連結結構，並能同時展現物件

間之訊息傳遞活動。

(18)

表1. UML 圖形種類及說明（續）

狀態圖表示物件在其生命週期中的狀態變化，狀態圖以

微觀物件為主，細分物件所發生的各項事件，並表達物件生命週期之狀態轉變及活動結果。

活動圖表達使用個案中一系列事件的流程，即工作流程

和所需的作業活動，以及執行某一作業行為中之活動、轉換與條件等。

元件圖說明系統設計過程中，各類別與物件的配置及敘

述軟體元件間的組織架構合相依關係。

部署圖用來說明系統在實際應用時各軟硬體（例如處理

器）元件如何部署在實體環境中的配置與安排等。

套件圖用來表達系統中套件或元素的組織方式，描述套

件與套件的相依性。

時序圖著重在物件間訊息傳遞的時間關係，用以顯示詳

細的時間資訊，藉由狀態與時間軸、時間尺規等符號來表達物件在不同時間點上的狀態改變。

互動概觀圖該圖形主要以活動圖的方式呈現，結合了互動

圖，說明主要的活動與控制流，細部的活動則以互動圖（包含循序圖、時序圖、溝通圖）來表示。

複合結構圖用來表達某個類別或元件在執行時期中所有的參

與者（包含類別、物件、介面等）彼此如何互相合作完成某一個特定的任務。

輪廓圖能針對現存的Meta-Model來進行擴充，始其適用於不同用途，包含調整UML之Meta-Model以適用不同平台（例如J2EE或.NET）或領域（例如企業流程塑模）。

2.1.1 類別圖

類別是物件導向系統裡最重要的組成元素，UML 中最主要使用到的圖形也是類別圖[15]，用來表示系統中物件的類型以及類型間之間關係，其包含了類別之屬性、操作與類別間連接之應遵守的限制等。類別圖的類別包含：實體類別

（Entity Class）、介面類別（Boundary Class）以及控制類別（Control Class）：

 實體類別（Entity Class）：負責存放需要儲存的資訊，除了可以存入永久的資訊外，也可以暫存資訊，例如搜尋結果[30]，實體類別通常可以在事件流或是互動圖中找出。並使用在企業某領域的專業術語來為實體命名，例如在交通票券訂購系統中，「班次」這個類別就是實體類別。

(19)

 介面類別（Boundary Class）：介面類別指的是介於系統與外界之間的類別，

包含了所有的表單、報表、硬體介面，以及和其他系統的溝通介面。

 控制類別（Control Class）：負責其他類別的操作結果的傳遞，將訊息傳送給其他類別，或是將工作指派給其他類別，例如將介面類別中的表單資訊儲存至實體類別中。

類別以圖形呈現的話，是將類別描繪成一長方形。並包含了三個元件：類別名稱、屬性與操作，其各自擁有自己的長方形區塊（如圖3），以下分別介紹這三個元件。

類別操作（）

類別屬性類別名稱

類別操作（）

類別屬性類別名稱

圖3. 類別圖之三個元件

 類別名稱：每一個類別均有名稱，以便區分，通常類別名稱的第一個英文字母必須大寫，並以一個單數名詞來為類別命名，例如：Teacher 或 Book。

 類別屬性：屬性用來表達物件之狀態、性質或特徵，透過這個性質的實例可以存取某個區間的值。一個類別可能包含不限數目的屬性，甚至也可以沒有任何屬性。屬性可以只表示其名稱，或是有初始值的訂定。屬性所代表的是系統裡某些事物的性質，例如：班機（Flight）類別裡包含了座位（Seat）

屬性。

 類別操作：操作是描述類別的主要行為，以函數的方式呈現，擁有輸入值與輸出值。

(20)

類別與類別之間擁有關聯關係，在物件導向系統裡分成了相依

（Dependency）、一般化（Generalization）、關聯（Association）與實現化（Relization）

四種關係[9]，其表達圖形如表 2，並分別介紹之。

表2. 類別間關聯關係表示符號

類別間關係關聯線符號

相依關係

關聯關係

一般化關係

實現化關係

 相依關係：是一種使用的關係，用以表達一個類別會使用到的其他類別，且被使用之類別的改變可能會影響到使用它的類別，反之則不一定，關係的箭頭方向是由使用類別指向被使用類別。

 關聯關係：屬於一種靜態的結構關係，描述類別與類別之間的連結。在 UML 最常見的就是關聯關係，定義了一個類別如何連結其他類別的物件。關聯關係意味著一個類別之物件知道另一類別之物件的存在[9]。在關聯關係中，

需表達有多少物件參與此關聯，與ER 模式中的基數相同，稱為關聯多重性，

分為三種：一對一（1：1）、一對多（1：N）以及多對多（N：N）。

 一般化關係：類似於 JAVA 中類別的繼承關係，其父類別的屬性被繼承於子類別中，子類別除了繼承父類別的屬性外，還具有自己的屬性，且對於繼承父類別的屬性可以變更或延伸屬性內容，但不可減少或隱藏父類別的屬性。

 實現化關係：與一般化關係類似，表示一個類別去實作另一個類別所指定的行為，實現化關係是介面與實作之間的關係。

(21)

2.1.2 Meta Object Facility (MOF)

MOF是OMG用來描述OCL 、QVT與UML 的基礎， MOF由Meta-Class 與 Meta-Association等類似於類別圖與關聯線所組成的集合[5]，其定義UML模型的基本元素、語法以及結構，MOF本身被設計為四個層次的架構（如圖4），M0屬於資料層，用來描述具像的資料；M1層用來描述M0層，例如以類別圖描述M0 層的實體資料；M2層用來描述M1層使用的UML圖形；最上層M3則包含OMG所定義的Meta MetaModel構造集合，描述M2層中UML圖形的結構及語言，屬於最抽象的部分。

Meta-meta-model

Meta-Model

Model

Domain M3

M2

M1

M0

Instance of Instance of Instance of

OMG

UML

UML Model

Data Meta-meta-model

Meta-Model

Model

Domain M3

M2

M1

M0

Instance of Instance of Instance of

OMG

UML

UML Model

Data

圖4. MOF 架構

圖 5舉例說明 UML 類別圖在 MOF 架構下的交互關係，M3 層中的 Class 是 OMG 定義的類別圖形構造集合；M2 則根據這個集合描述出屬性以及類別之 Meta-Model；M1 透過描述的屬性以及類別塑模出類別圖，M0 屬於描述類別圖中屬性資料部分。

(22)

Class

Attribute Class

Title:String Book Title:String

Book

Title=‘ABC’

M0 M1 M2

M3

<<instance of>>

<<instance of>> <<instance of>>

圖5. 類別圖之 MOF 架構 2.2 模型驅動架構

OMG在2001年提出MDA開發模式，其關鍵是將軟體開發過程中每個階段的產出設為下一階段的輸入，MDA發展生命週期與其它的開發模式並無太大不同，在流程方面一樣由需求→分析→設計→程式撰寫→部署，主要強調的差別在於各階段的產出是由電腦可理解的正規模式表達[2]，主要是使用UML，通常包含動態的循序圖和靜態的類別圖，以及OCL來呈現[29]。圖6說明MDA軟體發展週期的內容與產出，MDA在需求階段主要的產出大部分為文字，也是就是 Computation Independent Model (CIM)，透過分析，將該階段的產出建構出 Platform-Independent Model (PIM)，一樣的，PIM是進行低階設計的輸入，之後產出Platform-Specific Model (PSM)，而PSM是進行程式編輯的輸入，該階段的產出為程式碼。

(23)

需求

分析

低階設計

程式編輯

測試

部署

PIM

PSM

Code

Code CIM

MDA 流程

主要流程產出

需求需求

分析分析

低階設計低階設計

程式編輯程式編輯

測試測試

部署部署

PIM

PSM

Code

Code CIM

MDA 流程

主要流程產出

圖6. MDA 軟體發展生命週期

MDA總共有四個主要的核心模式：CIM、PIM、PSM與Code[21]，說明如下：

 CIM：代表著軟體生命週期中的需求模型。

 PIM：一種抽象的模型，該模型與開發技術以及實作平台無關，是分析與設計結果的重要產出，根據需求描述，將企業運作的觀點描述成一個軟體系統，並且不涉及開發與運作之平台。

 PSM：屬於一種特定平台的模型，該模型相依於軟體的開發技術。對於某一種PSM而言，只有具備該特定平台知識的開發者才能理解，主要是以開發工具的架構來描述軟體系統，因此一個PIM可以轉成一個或多個PSM[12]，因為系統可能由數種技術開發而成。

 Code：代表了實作的模型，表示在PSM所設計與平台相關的運行程式碼。

MDA是在MOF模型的架構下執行轉換（圖7），在M2層定義並且在M1執行轉換，透過M2層Meta-Model的定義，將M1層的來源PIM轉換為PSM，並且也以 UML模型表示，由於來源模型與目標模型都是屬於M1層的模型，並擁有自己的 Meta-Model，因此整個轉換過程中，包含了四種不同的模型：來源模型（Source

(24)

Model）、來源模型的Meta-Model（Source Meta-Model）、目標模型（Target Model）、目標模型的Meta-Model（Target Meta-Model）。

執行轉換轉換定義 OMG MOF

UML Meta-Model

UML Model

Data M3

M2

M1

M0

OMG MOF

UML Meta-Model

UML Model

Data 執行轉換

轉換定義 OMG MOF

UML Meta-Model

UML Model

Data M3

M2

M1

M0

OMG MOF

UML Meta-Model

UML Model

Data

圖7. MOF 中 MDA 的轉換架構 2.2.1 MDA 的 CASE 轉換軟體

在MDA 中每一個轉換（例如 PIM 轉換 PSM）都需要有清楚的定義並藉由 CASE 軟體來執行轉換，而目前已經有不少 CASE 工具軟體可支援 MDA 的轉換

（表3），市面上大致可分為 Open Source Tools 與 Commercial Tools 兩種 [4]。比較知名的有Borland Together、Power Designer 與 Rational Rose。Borland Together 為Borland 公司所開發的一個整合型 CASE 工具，支援 UML 2.0 版的圖形，也支援圖形轉換程式碼的功能以及 OCL 的語法檢測 [3]，而本研究使用 Borland Together 來進行 QVT 的語法檢測並執行 PIM 模型的轉換。

(25)

表3. MDA 轉換工具列表

Open Source Tools Commercial Tools

AndroMDA (J2EE code generation) ArcStyler (MDA tool from Interactive Objects)

ATL (Eclipse plugins) iQgen 3.0 (Template-based generator) GMT (Generative Model Transformer) MCC (Model Component Compiler,

J2EE)

KMF (Kent Modeling Framework) MDWorkbench (Text and model transformation toolset)

Middlegen (Database driven code

generator) MetaEdit+ (Modeling and Metamodeling tool)

ModFact (MOF Repository and

QVT-like engine) Model-in-Action (code generation and model to model transformation) MOFScript (Eclipse plugin) OptimalJ (PSM transformations,

integrated UML tool) MTF (IBM Model Transformation

Framework Power Designer MTL Engine (Integrates with Netbeans

MDR amd Eclipse EMF) Rational Rose OpenArchitectureWare

(Template-based generator framework) SosyInc (Modeler and Transformation Engine)

OpenMDX (Integrates with several

tools, J2EE, .Net) Together XDoclet (Attribute based code

generation tool for J2EE Xactium XMF Mosiac (Model-based mapping, generation and execution tool)

2.3 QVT 轉換技術介紹

為了實現UML模型的MDA自動化轉換，OMG在2002年制定QVT技術，針對 UML的模型進行轉換。理論上，CIM可以透過QVT程式轉換為PIM，PIM也可以透過QVT程式轉換為PSM，QVT主要是在OCL的標準下所發展的語言。QVT主要由三種語言組成：Relations、Core以及Operational Mappings（如圖8）[25]。

Relations語言是以宣告式語法描述轉換規則、類似資料庫的SQL語言，簡稱 QVT-R。Operational語言則是以命令式語法描述轉換規則，類似Java語言的語法，

簡稱QVT-O。Black Box用來支援非OMG標準的轉換方式，主要是以其他語言例如XSLT進行轉換。

(26)

Operational Mappings

Relations

Core

Black RelationsToCore Box

Transformation Operational

Mappings

Relations

Core

Black RelationsToCore Box

Transformation

圖8. QVT 語言的關係架構 2.3.1 Object Constraint Language

OCL在1997年由IBM公司所發展，原來是應用在其保險部門的商業塑模語言，目前由OMG制定為擴充UML資訊的標準語言，應用在UML模型的邏輯限制 [11] [34]，其使用的原因主要在於進行系統分析與設計時，UML圖形對企業需求無法提供精確、完整的描述，例如描述類別圖中屬性的額外限制與操作描述。以往表達限制是使用自然語言表達，但以自然語言表達較不精準，電腦對於自然語言也無法完全了解，會導致結果發生模糊之情況[26]。而OCL即為一種易讀且易寫的正式語言，可以明確描述系統規格中的限制。

2.3.2 QVT 相關研究

本研究歸納過去一些學者在應用 QVT 轉換方面的研究（表 4），藉此了解 QVT 目前的研究應用。

表4. QVT 相關研究 (Gardner, Griffin, Koehler, &

Hauser, 2003)[16]

針對QVT規格書提出建議，並交互比較討論其亮點，基於作者本身的實際轉換經驗，建議其標準制定。

(Graham, 2004)[18] 在MDA架構下，探討QVT在開發過程中的有用性與複雜性，並以圖形化的方式描述QVT 應用於UML模型至Java程式碼的轉換架構。

(27)

表4. QVT 相關研究（續）

(Greenyer & Kindler, 2007)[19] 探討Triple Graph Grammars (TGGs) 與QVT 兩者的轉換架構以及使用語法，並比較其相同與相異之處。

(Kurtev, 2008)[22] 總結開發人員對於一般轉換個案所遇到的問題以及關鍵要求，並描述了QVT目前的架構、規範和問題，對於架構中的三個子語言簡單說明並歸納目前可用的轉換工具。

(Laarman, 2009)[23] 探討 QVT 與 ATL 的轉換結構與編譯方式，

並在 ATL 的編譯器上執行 QVT 轉換，實現兩者的兼容性與互相操作性。

(Barendrecht, 2010)[7] 使用QVT 語法轉換一種描述計算過程與模擬物理過程的系統模型（hybrid automata），將其Compositional Interchange Format (CIF) 模型轉換為Ariadne 模型。

(Bosems , 2011)[10] 探討 ATL 與 QVT 兩種方法的轉換，並建構出數學模式比較兩者的轉換效率。

(Dongen, 2012) [13] 提出一種以視覺化的方式表達QVT 轉換模型的方法，藉以了解來源模型與目標模型元素之間的關係。

對於過去研究的整理，發現部分研究僅片段式的比較語法之間的不同，或是建立小型個案用以驗證不同語法之間的轉換效率，少有研究以三層式的系統架構進行完整的個案轉換探討。

2.4 QVT 基本語法

本節介紹 QVT 基本語法，其包含 QVT 的基本操作語法與變數、基本資料型態、運算式以及集合類型語法，做為進一步介紹轉換語法的基礎。

2.4.1 基本操作語法與變數

QVT 中常用的操作語法為"."符號，通常應用在物件上，呼叫物件之中所包含的屬性，與Java 語言中的"."一樣，例：下列表示將 The type of the column 字串存至 myColumn 之 type 屬性。

(28)

myColumn.type := 'The type of the column';

QVT 中常用的基本變數有 result 與 self，result 代表目標模型之參照，存放著轉換結果並回傳至目標模型，例：下列表示Method 函數回傳結果將存放置目標模型之參照result 中。

result := MethodA();

而self 為則本身之參照，可用來呼叫函數或是物件，例：下列表示將本身之 name 存至新增變數 mySting 中。

var myString := self.name;

2.4.2 基本型態描述

QVT常用的資料型態有Boolean(布林)、Integer(整數)、Real(實數)、String(字串)，表5列出QVT常用的資料型態以及其範例值。

表5. QVT 基本資料型態

型態範例

Boolean True, false

Integer 1, 2, 3, -7, 48, 25518, ...

Real 2.3, 9.65, 3.141, ...

String 'Hello World', 'Apple'

2.4.3 運算式

QVT提供對基本資料型態執行運算的操作，表6是Integer、Real、Boolean與 String的基本運算符號。表7是Boolean、Integer/Real的基本運算。表8是字串的基本運算。

表6. QVT 基本運算符號

型態執行操作

Integer +, -, *, /

Real +, -, *, /

Boolean and, or, xor,not,if-then-else

String substring()

(29)

表7. Boolean、Integer/Real 基本運算

陳述式描述說明回傳型態

a or b 如果a 或有一者為真回傳 true Boolean a and b 如果a 和 b 同時為真回傳 true Boolean a xor b A 或 b 中僅有一者為真回傳 true Boolean

not a 回傳a 的否定值 Boolean

a = b 如果a 和 b 的值相同回傳 true Boolean a <> b 如果a 和 b 的值不相同回傳 true Boolean a implies b 如果a 為真則 b 應該也為真 Boolean a < b 如果a 的值小於 b 的值回傳 true Boolean a > b 如果a 的值大於 b 的值回傳 true Boolean a <= b 如果a 的值小於等於 b 的值回傳 true Boolean a >= b 如果a 的值大於等於 b 的值回傳 true Booleam a + b 回傳a 加 b 的值 Integer or

Real a - b 回傳a 減 b 的值 Integer or

Real a * b 回傳a 乘 b 的值 Integer or

Real

a / b 回傳a 除 b 的值 Real

表8. 字串基本運算

字串運算式描述說明回傳型態

String.size() 計算字串的字元數 Integer String.toLower() 字串轉小寫 String String.toUpper() 字串轉大寫 String String.substring(int,int) 傳回字串中指定位置間的子字串 String String1 = string2 判斷字串是否相等 Boolean String1 <> string2 判斷字串是否不相等 Boolean

2.4.4 條件判斷式語法描述

QVT可以使用if-else運算，描述方法為：if （判斷式） then （敘述） else

（敘述） endif，例：下列表示將來源name字串值做判斷並更改其值。

if name = 'String'

(30)

then

'VARCHAR2'

else

name

endif

2.4.5 集合類型

QVT的轉換規則經常會作用在同一類型的元素上，例如類別圖中的類別元素一併適用某一轉換規則。QVT因此提供集合運算函數方便開發人員進行集合運算，其相關函數如表9。

表9. 集合表達類型

型態描述說明

Set() 表示在集合中沒有重複的元素

Sequence() 表示是Bag，但元素有次序性

Bag() 表示在集合中可以存在重複的元素

OrderedSet() 表示是Set，但元素有次序性 2.5 QVT 轉換語法

本研究使用QVT-O將來源模型轉換至目標模型，以下介紹轉換相關語法。

2.5.1 main 程序

QVT程式進入點由main程序開始執行，main程序包含輸入(來源模型)與輸出參數(目標模型)。圖9是main程序的撰寫語法，括弧內的in表示後面的model是來源模型，A是來源模型的Meta-Mode，B是目標模型的Meta-Model。

(31)

mapping main(in model: A): B {

進入點來源模型之 Meta-Model

目標模型之Meta- Model 進入點為main程序

mapping main(in model: A): B {

進入點來源模型之 Meta-Model

目標模型之Meta- Model 進入點為main程序

圖9. 進入點之語法說明 2.5.2 轉換函數之語法

轉換函數以mapping關鍵字開頭(如圖10)，首先定義來源模型Meta-Model之參數(A)，接著命名函數名稱(A2B)，最後定義目標模型Meta-Model參數(B)。開發人員藉由撰寫mapping函數定義轉換規則，mapping函數支援階層式呼叫，可以在mapping函數呼叫其他mapping函數以完成轉換規則的需求。

mapping A::A2B() : B {

來源模型之 Meta-Model

目標模型之 Meta-Model 函數名稱

mapping A::A2B() : B {

來源模型之 Meta-Model

目標模型之 Meta-Model 函數名稱

圖10. 轉換函數之語法說明

2.5.3 用於轉換函數主體之相關語法

轉換函數主體語法分成init初始部分與object目模模型內容部分，init初始部分是針對來源模型中的元素進行運用，例如將來源模型中的元素新增至一集合變數，以便在object部分呼叫函數進行轉換（如），或是將來源模型中的元素直接呼叫其他轉換函數進行轉換（如圖12）；object部分則是針對目標模型的內容進

圖11

(32)

行定義，例如定義目標模型名稱或是將其元素呼叫其他轉換函數（如圖11）。

mapping A::A2B() : B{

init{

var d :=

A.propOfA.oclAsType(C) ->asOrderedSet();

} object{

name := 'A2BModel';

propOfB += d.C2D();

} }

新增變數d

A.propOfA即來源模型A中之元素，藉由oclAsType語法取出A 模型中之C模型，並以有次序集合方式（asOrderedSet）存放至變數d中。

以字串型態定義目標模型名稱為 A2BModel。

將初始部分新增之d變數呼叫C2D函數存放至目標模型 B元素中（propOfB）。

mapping A::A2B() : B{

init{

var d :=

A.propOfA.oclAsType(C) ->asOrderedSet();

} object{

name := 'A2BModel';

propOfB += d.C2D();

} }

新增變數d

A.propOfA即來源模型A中之元素，藉由oclAsType語法取出A 模型中之C模型，並以有次序集合方式（asOrderedSet）存放至變數d中。

以字串型態定義目標模型名稱為 A2BModel。

將初始部分新增之d變數呼叫C2D函數存放至目標模型 B元素中（propOfB）。

圖11. 新增集合變數之語法說明圖 mapping A::A2B : B {

init{

result := create(propOfA1,propOfA2);

result.propOfB += self.propOfA3.C2D();

} }

result語法為目標模型B之參照，可重複儲存轉換內容並回傳至B模型中。

呼叫一個名稱為 create 的轉換函數，並傳入來源模型A中之兩個元素（propOfA1 、 propOfA2 ）後將轉換結果放至模型B。

模型 A 中之元素

（ propOfA3 ）呼叫 C2D函數後將轉換結果傳入模型B 中之元素

（propOfB）。

self語法為本身之參照，也就是來源模型A。

mapping A::A2B : B { init{

result := create(propOfA1,propOfA2);

result.propOfB += self.propOfA3.C2D();

} }

result語法為目標模型B之參照，可重複儲存轉換內容並回傳至B模型中。

呼叫一個名稱為 create 的轉換函數，並傳入來源模型A中之兩個元素（propOfA1 、 propOfA2 ）後將轉換結果放至模型B。

模型 A 中之元素

（ propOfA3 ）呼叫 C2D函數後將轉換結果傳入模型B 中之元素

（propOfB）。

self語法為本身之參照，也就是來源模型A。

圖12. 初始部分直接呼叫函數之語法說明

2.6 Query 函數、when 子句與 resolve 新增語法

QVT語言提供了Query判斷函數、when子句以及resolve新增語法的使用 [25]，Query屬於獨立的判斷函數，在需要時進行呼叫並且傳回結果值，讓程式

(33)

可以進行條件判斷以決定轉換方式。其運作是將一個或多個來源傳入值後，經由函數中的判斷式或是計算，產生結果並且回傳計算值[7]。而when子句能在轉換來源模型前進行限制宣告，只有在when子句中所宣告的關係成立，轉換才會進行，而resolve語法屬於新增功能，將對應到的來源模型元素新增至目標模型中，

達到轉換之目的，底下分成三個小節分別介紹使用語法。

2.6.1 Query 函數語法

轉換模型的過程中，可能會需要對來源模型的內容進行判斷，以便執行不同的轉換程序，例如來源類別圖中的屬性型態透過判斷式if-else，轉換成不同的目標類別圖屬性型態，圖13是Query函數的語法，其架構包含函數名稱、傳入值、

回傳值以及內容條件判斷式。寫法以query為開頭，接著定義函數名稱（change）

以及傳入值（String）與回傳值（String），內容部分透過if-else語法的判斷，當Query 函數傳入字串為A時，就改變成B並回傳；傳入C時，就改變成D並回傳，else後則將條件不適合的傳入值以原值回傳，最後再加上endif的結束語句。

query change(in name : String) : String{

if name = 'A' then 'B' else

if name = 'C' then 'D' else name endif

endif }

函數名稱傳入值回傳值

if-else條件判斷式

endif結束語句

query change(in name : String) : String{

if name = 'A' then 'B' else

if name = 'C' then 'D' else name endif

endif }

函數名稱傳入值回傳值

if-else條件判斷式

endif結束語句

圖13. Query 函數語法

2.6.2 when 子句

when子句是用來作為判斷轉換操作是否被執行的條件。圖14是when子句語

(34)

法與其呼叫之query判斷函數，在參考Meta-Model定義來源模型(A)與目標模型(B) 後，加上when子句可以對來源模型加以限制，當when子句中所呼叫的query函數回傳值為false時，後面所定義的轉換操作將不會執行，並且回傳空值。

mapping A::A2B() : B when{self.hasClasses()}

{...}

query A::hasClasses() : Boolean {

name ='Customer_Data' or name='Order_Data' or name='Bag_Data' or name='Lunch_Data';

}

函數名稱

判斷來源模型名稱是否符合

函數回傳值函數名稱輸入模型A之

Meta-Model參數，代表針對來源模型A進行限制。

當when子句中為false時，主體

內容將不會轉換並回傳空值。 self語法為本身

之參照，也就是來源模型A。

呼叫hasClasses判斷函數 mapping A::A2B() : B when{self.hasClasses()}

{...}

query A::hasClasses() : Boolean {

name ='Customer_Data' or name='Order_Data' or name='Bag_Data' or name='Lunch_Data';

}

函數名稱

判斷來源模型名稱是否符合

函數回傳值函數名稱輸入模型A之

Meta-Model參數，代表針對來源模型A進行限制。

當when子句中為false時，主體

內容將不會轉換並回傳空值。 self語法為本身

之參照，也就是來源模型A。

呼叫hasClasses判斷函數

圖14. when 子句程式碼

(35)

2.6.3 resolve 新增語法

resolve語法以新增的方式將來源模型元素轉換至目標模型中，圖15為resolve 之使用語法，在init初始部分由於resolve語法所新增的元素是放置在目標模型B中

（result），因此resolve必須輸入B模型之Meta-Model參數，使目標模型型態與新增模型型態相符合，轉換才能正確執行，而object則定義新增模型之內容。

mapping A::A2B() : B { init {

result := self.resolve(B)-> any(true);

} object {

name := self.name;

} }

將新增之B模型名稱定義與來源模型名稱相同

（self.name）。

使用resolve語法輸入與目標模型相同之Meta-Model 參數，並放至目標模型結果中

（result）。

目標模型result 變數不接收集合類型，因此使用 any(true) 將 resolve 新增的模型集合轉成單一類型。

mapping A::A2B() : B { init {

result := self.resolve(B)-> any(true);

} object {

name := self.name;

} }

將新增之B模型名稱定義與來源模型名稱相同

（self.name）。

使用resolve語法輸入與目標模型相同之Meta-Model 參數，並放至目標模型結果中

（result）。

目標模型result 變數不接收集合類型，因此使用 any(true) 將 resolve 新增的模型集合轉成單一類型。

圖15. resolve 使用之語法 2.7 轉換程式碼的基本架構

本節以一個簡單的轉換範例，在上述語法的基礎上，簡述其轉換程式碼，以了解QVT的程式架構。本範例的來源模型為UML的類別圖，而目標模型為資料庫的實體資料表，其QVT轉換程式碼主要包含三個部分（圖16），程式碼首先定義Meta-Model（方框1），接著執行轉換進入點main（方框2），在main內部呼叫函數將模型轉換（方框3），以下分別對此3部分分別進一步說明。

(36)

metamodel 'http://www.borland.com/together/erPhysical';

metamodel 'http://www.borland.com/together/uml';

metamodel 'http://www.borland.com/together/uml20';

mapping main(in model: uml::together::Model): erPhysical::Model { schemas +=

model.allInstances(uml::kernel::packages::Package).toSchema();

}

mapping

uml::kernel::packages::Package::toSchema() : erPhysical::Schema{

init {

var classes :=

self.ownedMembers.oclAsType(uml20::classes::Class);

}

name := self.name;

visibility := self.visibility;

entities += classes.toEntityInitial();

}

mapping

uml20::classes::Class::toEntityInitial() :erPhysical::Entity { init {

result :=

self.resolve(erPhysical::Entity)->any(true);

} object {

name := self.name;

} }

1

2

3

}

mapping

uml::kernel::packages::Package::toSchema() : erPhysical::Schema{

init {

var classes :=

}

name := self.name;

}

mapping

result :=

} object {

name := self.name;

} }

1

2

3

圖16. 轉換程式碼之架構

(37)

2.7.1 Meta-Model 的定義

MDA轉換是在MOF的架構下執行，程式碼必須先定義來源模型與目標模型的Meta-Model(M2層)。以Borland Together軟體平台為例，程式碼先匯入三個 Borland Together所提供的Meta-Model（erPhysical、uml、uml20）(圖17)，QVT 程式才能依據Meta-Model進行轉換。

圖17. Borland Together 軟體平台中 Meta-Model 的定義

2.7.2 轉換進入點

程式轉換以main程序為起點（如圖18），並在main程序中輸入來源模型之 Meta-Model 參數，該範例為 uml::together::Model ；並定義輸出目標模型之 Meta-Model參數，該範例為erPhysical::Model，main程序主體叫toSchema函數進行來源模型的轉換。

}

圖18. 轉換進入點 main 程序

2.7.3 toSchema 函數

toSchema 函數中首先定義了來源模型之 Meta-Model 參數

（ uml::kernel::packages::Package ）與輸出目標模型之 Meta-Model 參數

(38)

（erPhysical::Schema）(圖19)， init部分透過oclAsType(uml20::classes::Class)將 ownedMembers裡的圖形鎖定在類別圖，並存放至classes變數中，以便在object部分呼叫函數進行轉換。object部分則是定義轉換目標模型erPhysical::Schema中的 name與visibility，以及將init部分所新增的classes變數呼叫toEntityInitial函數進行轉換並存放至entities中。

mapping

uml::kernel::packages::Package::toSchema() : erPhysical::Schema when { self.hasClasses() }

{ init {

var classes :=

}

object {

name := self.name;

}

圖19. toSchema 函數程式碼

2.7.4 toEntityInitial 函數

toEntityInitial函數輸入來源為類別圖，輸出為實體資料表，在init部分使用 resolve語法並輸入新增模型之Meta-Model參數（erPhysical::Entity）（圖20），並放入目標模型的結果中（result ），表示目標模型將新增實體資料表

（erPhysical::Entity），object則將新增的實體資料表之名稱進行定義，達成轉換之目的。

(39)

mapping

result :=

}

object erPhysical::Entity { name := self.name;

} }

圖20. toEntityInitial 函數程式碼

2.8 小結

透過本章節文獻探討，了解物件導向分析中UML的類別圖形、MDA的轉換架構與QVT的技術架構，並藉由QVT基本語法與架構之介紹，進一步應用在模型轉換上，了解模型轉換是從大範圍至小範圍依序使用函數呼叫的方式，階層式的進行轉換[13]，在主要進入點中定義目標模型的內容外，也鎖定其來源模型中的元素集合並呼叫其他函數進行轉換，例如轉換一個擁有屬性的類別圖，程式碼首先定義進入點為類別圖後，在主體內容呼叫函數對類別圖所包含的屬性進行轉換，而被呼叫的函數中可能又會呼叫其他函數來針對屬性中的元素做轉換，QVT 就是依此規則一層一層的將來源模型轉換至目標模型中。

(40)

第三章 QVT 轉換規則

本章以第二章的QVT語言為基礎，說明如何將以自然語言表示的模式轉換規則以QVT程式表達。由於模式轉換規則有無限種需求與可能，本研究以辛信興 [32]所制定的PIM至PSM轉換規則為範圍，其包含三部分：使用者介面轉換規則、

企業邏輯轉換規則與後台資料庫轉換規則。於3.1節介紹轉換規則，3.2節是規則的QVT程式碼。

3.1 模式轉換規則：自然語言表示法

下述規則係針對三層式架構系統，使用者端是網頁介面（HTML）、應用程式伺服器端採用PHP、資料庫端採用MySQL，其使用者介面詳細轉換規則如表 10、企業邏輯詳細轉換規則如表11以及後台資料庫轉換規則如表12。

表10. 使用者介面轉換規則

No 轉換規則

P1. 框架集合（Frameset）透過指標類別（Targets）指引，當 Client Page 使用到框架集合時，其內容會透過指標的存取顯示在框架集合中。

P2. 在 Client Page 中所有 form 型式的元素將產生出一類別圖，其型別命名為 Form，與 Client Page 擁有 Composition 關聯以及與 Server Page 擁有 Dependency 關聯。

P3. 當 PSM 為 HTML 技術平台，將 PIM 中的介面類別轉換為 Client Page 至 PSM；介面類別當中的屬性型別轉換為與 HTML 相對應的屬性型別至 Client Page 中。

P4. PIM 中從控制類別到介面類別的 Dependency 關聯線將在 PSM 產出一個由 Server Page 到 Client Page 的 Dependency 關聯線，其中 Server Page 由控制類別產生，Client Page 由介面類別產生。

(41)

表11. 企業邏輯轉換規則

No 轉換規則

B1. 將 PIM 中控制類別轉換成 Server page 類別圖至 PSM。

B2. 在 PIM 中控制類別的所有屬性，都將會轉換為相對應的屬性至 PSM。

B3. 在 PIM 中控制類別的所有屬性型別，都將會轉換為相對應的屬性型別至 PSM。

B4. 在 PIM 中控制類別的所有操作，都將會轉換為相對應的操作至 PSM。

B5. 在 PIM 中的 Non-persistent entity class 將會轉換為 JavaBean 類別圖至 PSM 中，而Non-persistent entity class 當中的屬性將轉換至 JavaBean 類別圖中且型別轉換為與PSM 相對應的平台。

B6. 在 PIM 中控制類別與 Persistent entity class 之間的關聯線會轉換為從 Server page 類別圖連結至 Table 類別圖的 Dependency 關聯線。

表12. 後台資料庫轉換規則

No 轉換規則

D1. 當 PSM 為關聯資料庫技術時，將 PIM 中的 Persistent entity class 轉換成 Table 類別圖至 PSM，Persistent entity class 中的屬性型別轉換為與關聯資料庫技術相對應的屬性型別至PSM 中。

D2. 當 PSM 為關聯資料庫技術時，將 PIM 中的 Association class 轉換成 Table 類別圖至PSM，Association class 中的屬性型別轉換為與關聯資料庫技術相對應的屬性型別至PSM 中。

D3. 在 PIM 中兩個 Persistent entity class（類別 A 與類別 B）與其之間多對多的關聯關係所產生的Association class（類別 C），將會轉換為三張Table 類別圖，類別A 轉成 Table A；類別 B 轉成 Table B；類別 C 轉成 Table C，其多對多關聯線將轉換為兩條關聯線：Table A 連結至 Table C 的一對多關聯線，與Table B 連結至 Table C 的一對多關聯線。

D4. 在 PIM 中 Persistent entity class 將轉換為 Table 類別圖，其關聯線將以相同基數轉換至PSM 中。

3.2 模式轉換規則：QVT 語言表示法

本節針對使用者介面層之轉換規則、企業邏輯層之轉換規則與資料層之轉換規則，逐一說明轉換規則，並展示相對應的QVT程式碼。

(42)

3.2.1 使用者介面層之轉換規則

規則P1

規則P1將介面類別產生出 Frameset 以及 Target 兩個類別與連結至 Client Page 的關聯線，其轉換規則以圖形化方式呈現如，由於本研究在撰寫 QVT-O 的語法上其轉換方式為先對應來源圖形後再執行轉換，對於PIM 中未出現的圖形，

無法對應並執行轉換，故僅以圖形化的方式呈現。

來源模型目標模型

P1 規則

圖21. P1規則之轉換圖規則P2

規則P2將介面類別中 Form 型式的元素產生出 Form 型態的類別圖與連結至 Client Page 以及 Server Page 的關聯線，其轉換規則以圖形化方式呈現如，由於本研究在撰寫QVT-O 其轉換方式為先對應來源圖形後再執行轉換，對於 PIM 中未出現的圖形，無法對應並執行轉換，故僅以圖形化的方式呈現。

P2 規則

圖22. P2規則之轉換圖

(43)

規則P3

規則P3將介面類別轉換為 Client Page，並將其包含之屬性型別轉換至 HTML 相對應的型別，其轉換規則以圖形化方式呈現如圖 23，所對應之 QVT 程式如表13。首先以名稱為 toClass 的函數轉換類別圖，函數定義來源模型為類別圖，

目標模型也是類別圖，在 init 程式區塊使用 resolve 語法新增類別圖至目標模型中，而在object 程式區塊定義目標類別圖名稱為 self.name，也就是與來源類別圖名稱相同，並將來源類別圖型別stereotypes 傳入 PHPstereotype 函數，該函數判斷當來源為介面類別時，將之改變為 Client class 並回傳，達到轉換之目的。此外，由於類別圖型別以集合類型儲存，該函數中包括傳入值傳出值以及判斷，都以集合方式進行。最後在object 程式區塊呼叫 toAttributes 函數進行屬性的轉換。

toAttributes 函數用以轉換屬性以及其型別，函數定義來源為屬性，目標模型也為屬性，在init 程式區塊使用 resolve 語法新增屬性至目標類別圖中，object 程式區塊定義目標屬性名稱與來源相同，屬性的type 則呼叫 uml2PHP 的 query 判斷函數，傳入來源的屬性型別與名稱，經轉換後傳出 PHP 的型別，例如，當來源屬性型別為String 時，將之改變為 VARCHAR2 並且回傳，達到更改屬性型別之目的。

P3 規則

圖23. P3規則之轉換圖

(44)

表13. P3規則與其對應語法

P3：當 PSM 為 HTML 技術平台，將 PIM 中的介面類別轉換為 Client Page 至 PSM；介面類別當中的屬性型別轉換為與 HTML 相對應的屬性型別至 Client Page 中。

mapping uml20::classes::Class::toClass(): uml20::classes::Class{

init {

result := self.resolve(uml20::classes::Class)-> any(true);

} object {

name := self.name;

stereotypes+= PHPstereotype(self.stereotypes);

attributes+= self.ownedAttributes.toAttributes();

} }

query PHPstereotype(in name: OrderedSet(String)): OrderedSet(String){

if name = 'Boundary class'->asOrderedSet() then 'Client Page'->asOrderedSet() else

if name = 'Persistent entity class'->asOrderedSet() then 'Table'->asOrderedSet() else

if name = 'Association class'->asOrderedSet() then 'Table'->asOrderedSet() else

if name = 'Non-persistant entity calss'->asOrderedSet() then 'JavaBean'->asOrderedSet() else

if name = 'Control class'->asOrderedSet()

then 'Server Page'->asOrderedSet() else name->asOrderedSet() endif

endif endif endif endif }

mapping uml20::kernel::Property::toAttributes() : uml20::kernel::Property {

init {

result := self.resolve(uml20::kernel::Property)-> any(true);

} object {

name := self.name;

type := object uml20::kernel::PrimitiveType {

name := uml2PHP(self.type.name,self.name);

} }

}

query uml2PHP(in name : String,in propertyname:String) : String{

if name = 'String' then 'VARCHAR2' else if name = 'Character' then 'CHAR' else

if name = 'Integer' then 'NUMBER(10,0)' else if name = 'Date' then 'DATE' else

if name = 'Image' then 'VARCHAR2' else

(45)

表13. P3 規則與其對應語法（續）

if (name = 'Button' and propertyname <> 'CheckOut') then 'href' else

if (name = 'Button' and propertyname = 'CheckOut') then 'Input(button)'

else name endif

endif endif endif endif endif endif }

規則P4

P4規則將擁有 Dependencies 關聯線的類別圖進行轉換，其轉換規則以圖形化方式呈現如圖 24，所對應之 QVT 程式如表 14。toDependencies 函數定義來源模型為Dependencies 關聯線，目標也是 Dependencies 關聯線，init 程式區塊將來源Dependencies 關聯線所連結之 supplier 呼叫 toClass 函數轉換類別圖，並存放至新增變數LinkSupplier 中；Object 程式區塊則是將新增變數 LinkSupplier 放至目標Dependencies 關聯線中的 supplier，達成轉換。

圖24. P4規則之轉換圖表14. P4規則與其對應語法

P4：PIM中從控制類別到介面類別的Dependency關聯線將在PSM產出一個由 Server Page到Client Page的Dependency關聯線，其中Server Page由控制類別產生，Client Page由介面類別產生。

mapping uml::kernel::CoreDependency::toDependency() : uml20::classes::Dependency{

init{

var LinkSupplier :=

supplier.oclAsType(uml20::classes::Class).toClass();

} object{

P4 規則