Tìm hiểu và phát triển công cụ chuyển mô hình RTL

111
Mục lục
Lời cam đoan ỉ
Lời cảm ơn ii
Mục lục iii
Danh sách hình vẽ V
Danh sách bảng vi
1 Mở đầu 1
1.1 Đặt vấn đ ề 1
1.2 Phạm vi nghiên cứ u 2
1.3 Cấu trúc khóa lu ậ n 2
2 Cơ sở lý thuyết 4
2.1 Phát triển phần mềm hướng mô hình 4
2.1.1 Mô hình và siêu mô hình

5
2.1.2 Ngôn ngữ mô hình h ó a

6
2.2 Chuyển mô hìn h 7
2.3 Ngữ pháp đồ thị ba (TG G s)

9
2.4 Tích hợp OCL và Triple Rules

12
3 Đảm bảo chất lượng chuyển mô hình 15
3.1 Ngôn ngữ RTL 15
3.1.1 Đặc tả ngôn ngữ R T L

16

3.1.2 Thực thi chuyển với R T L 19
3.2 Đảm bảo chất lượng chuyển mô hình R T L

20
3.2.1 Kiểm chứng chuyển

20
3.2.2 Hợp lệ chuyển

21
4 Cài đặt và thực nghiệm 22
4.1 Case stu d y 22
4.1.1 M etamodels

22
4.1.2 Một số tiếp cận chuyển

25
4.2 Đặc tả luật c hu y ể n 25
4.3 Các dẫn xu ấ t 30
4.4 Tính đúng đắn của chuyển

32
5 Kết luận và hướng phát triển 36
5.1 Công việc liên q u an 36
5.2 Kết l u ậ n 36
5.3 Kết quả thu đ ư ợ c 38
5.4 Hướng phát t r i ể n 38
Tài liệu tham khảo 39
Phụ lục 42

A Đặc tả RTL của bài toán chuyển giữa biểu đồ hoạt động UML và
đặc tả CSP 43
B Luật TGG kết hỢp với OCL 46
c Pré-, Postconditions chuyển tiến 48
V
Danh sách hình vẽ
2.1 Phương pháp phát triển phần mềm hướng mô hình 4
2.2 Các tầng của U M L 6
2.3 Ví dụ chuyển từ biểu đồ lớp - bảng quan hệ dữ l i ệ u

7
2.4 Ví dụ graph và typed g ra p h

9
2.5 Ví dụ về Triple Graph

10
2.6 Ví dụ về Triple Rule 11
2.7 Ví dụ về một bước chuyển khi áp dụng dẫn xuất chuyển tiến 13
3.1 Cú pháp ngôn ngữ RTL

16
3.2 Luật chuyển ClassToTable đặc tả sử dụng R T L 17
3.3 Cú pháp RTL mở rộ n g

18
3.4 Thực thi luật TGG bằng OCL: (1) bằng cách khai báo ràng buộc
OCL pre- và postconditions, (2) bằng chuỗi các lệnh U SE

18

3.5 Thực thi luật chuyển ClassToTable 19
4.1 (1) Metamodel của biểu đồ hoạt động; (2) Ví dụ biểu đồ hoạt động 23
4.2 (1) Metamodel của đặc tả CSP; (2) Ví dụ đặc tả C S P

23
4.3 Ví dụ hệ thống cứu hộ giao thông

24
4.4 Luật chuyển InitialNode 26
4.5 Luật chuyển ActionNode 27
4.6 Luật chuyển FinalNode 28
4.7 Luật chuyển Decision2Node

28
4.8 Luật chuyển Decision3Node

28
4.9 Luật chuyển ForkN ode 29
4.10 Luật chuyển Join N ode 29
4.11 Luật chuyển M ergeNode

29
4.12 Chuỗi các lệnh USE chuyển đổi Action trong chuyển ti ế n

30
4.13 Trạng thái mô hình khi áp dụng chuyển tiến 31
4.14 Biểu đồ hoạt động bài toán cứu hộ giao thông 32
4.15 Đặc tả CSP bài toán cứu hộ giao th ô n g 33
4.16 Kiểm chứng chuyển 33
4.17 Precondition cho dẫn xuất chuyển tiến của luật trafoActionNode . . 34

4.18 Postcondition cho dẫn xuất chuyển tiến của luật trafoActionNode . 34
vi
BANG KŸ HIÊU VÀ CÂC CHÜ VIET TAT
Tùf viét tat Tùf chuân
Diên giâi
BACs
Boolean Application Condi
tions
CSP Communicating Sequential
Processes
MDE Model Driven Engineering
Kÿ nghê hiïông mô hînh
MDD
Model Driven Development
Phât triên phàn mèm huông
mô hïnh
OMG
Object Management Group
To chute dura ra câc chuân cho
xây dung câc hê thong huông
doi tUdng
TGG
Triple Graph Grammar
Ngô phâp do thi ba
Triple rule Triple rule
Luât do thi ba
OCL
Object Constraint Language
Ngôn ngô rang buôc doi tUdng
UML

Unified Modeling Language
Ngôn ngô mô hïnh hôa thong
nhât
USE UML-Based Specification
Environment
Moi trudng dâc ta hê thong
dua trên UML
QVT Query /View / Transformation
RTL Restricted Graph Transfor
mation Language
Ngôn ngô chuyen mô hïnh RTL
1
Chương 1
Mở đầu
1.1 Đặt vấn đề
Trong phát triển phần mềm hiện nay, phương pháp phát triển phần mềm hướng
mô hình nổi lên như một giải pháp hiệu quả nhằm nâng cao đáng kể tốc độ phát
triển cũng như chất lượng phần mềm. Trong phương pháp này, mô hình được xem
như trung tâm tại tất cả các bước để xây dựng phần mềm, và thao tác chuyển mô
hình chính là trái tim của toàn bộ phương pháp. Chuyển mô hình có thể được áp
dụng trong các ngữ cảnh khác nhau: (1) biểu diễn mối quan hệ giữa các góc nhìn
khác nhau của một hệ thống, (2) phản ánh một mô hình từ một mô hình miền
khác nhằm phục vụ việc phân tích mô hình, và (3) đạt được một sự ánh xạ giữa
các mô hình trên các ngôn ngữ khác nhau. Trong những ngữ cảnh đó, các ngôn
ngữ chuyển cần phải đạt được sự mềm dẻo và tính chính xác trong cách biểu diễn.
Hiện nay có nhiều phương pháp tiếp cận cùng với các công cụ đã được nghiên
cứu và đề xuất để giải quyết bài toán chuyển mô hình [3]. Phương pháp tiếp cận
Query/View/Transformation (QVT) được xem như một tiêu chuẩn trong vấn đề
chuyển mô hình [16]. ở bài báo [12], các tác giả đã xây dựng ngôn ngữ ATL dựa
trên hướng tiếp cận QVT. Đây là công cụ đã và đang được sử dụng rộng rãi trong

công nghiệp phát triển phần mềm. Phương pháp tiếp cận thứ hai cũng đang thu
hút được sự quan tâm nghiên cứu và phát triển mạnh mẽ là hướng tiếp cận chuyển
đồ thị. Một số công cụ dựa trên chuyển đồ thị chỉ hỗ trợ chuyển một chiều như các
tác giả ở bài báo [20] đã thực hiện; một số khác dựa trên Triple Graph Grammars
(TGGs) hỗ trợ chuyển hai chiều giữa các mô hình [19]. Ngoài ra, các tác giả ở bài
báo [4, 2] còn đề xuất cách tiếp cận để đảm bảo tính đúng đắn của chuyển.
Luận văn này tiếp tục nghiên cứu giải pháp đã đề xuất tại [4]. Trong đó, sự tích
hợp giữa Triple Graph Grammars [19] và ngôn ngữ ràng buộc đối tượng OCL [22]
được thực hiện nhằm tăng khả năng biểu diễn và nâng cao chất lượng chuyển mô
hình. Sự kết hợp này tạo lên ngôn ngữ RTL 1 và được hiện thực hóa dựa trên nền
tảng OCL. Các ràng buộc OCL được đưa vào ngôn ngữ RTL nhằm: (1) biểu diễn
1RTL viết tắt của Restricted Graph Transformation Language
2
và thực thi các luật chuyển tiến, chuyển lùi, chuyển đồng tiến hóa và chuyển tích
hợp, (2) đảm bảo tính đúng đắn của chuyển. Đặc biệt, ngôn ngữ RTL được biểu
diễn dưới dạng văn bản và được hiện thực hóa bởi USE [5] thông qua các câu lệnh
USE. Theo đó, tính đúng đắn của chuyển có thể được đảm bảo bằng cách kiểm tra
ràng buộc invariants của chuyển và cặp ràng buộc tiền điều kiện và hậu điều kiện
tại mỗi bước chuyển. Tính tự động hóa của chuyển cũng được cải tiến thông qua
việc bổ sung cấu trúc điều khiển vào ngôn ngữ RTL. Để giải thích chi tiết hơn về
ngôn ngữ RTL cũng như vấn đề kiểm tra tính đúng đắn của chuyển, chúng tôi đã
áp dụng RTL để giải quyết hai bài toán chuyển: chuyển mô hình giữa biểu đồ lớp
UML [9] và biểu đồ quan hệ dữ liệu RDBMS; và chuyển giữa biểu đồ hoạt động
UML [9] và đặc tả CSP [11].’
1.2 Phạm vi nghiên cứu
Luận văn tập trung tìm hiểu ngôn ngữ chuyển mô hình RTL và kiểm tra tính đúng
đắn của chuyển thực hiện bởi ngôn ngữ này. Việc mở rộng ngôn ngữ RTL được
xem xét đến như một giải pháp làm tăng tính tự động của chuyển. Tính đúng đắn
của chuyển cũng được nâng cao thông qua: (1) cải tiến cặp ràng buộc tiền điều
kiện và hậu điều kiện tại mỗi bước chuyển, (2) xem xét sử dụng chuyển tích hợp

để kiểm tra tính đúng đắn của mô hình đích theo luật chuyển đã được định nghĩa.
Nhằm làm rõ ngôn ngữ chuyển RTL và vấn đề đảm bảo chất lượng của chuyển
RTL, chúng tôi áp dụng giải quyết một số bài toán chuyển mô hình. Bài toán
chuyển mô hình giữa biểu đồ lớp UML (UML class diagram) và biểu đồ quan hệ
dữ liệu (relationship database System) được thực hiện như một chuyển đơn giản
nhằm giải thích các khái niệm cơ sở, cách thức hoạt động của ngôn ngữ RTL. Với
mục tiêu đó, chúng tôi chỉ xem xét chuyển những thành phần cơ bản của hai loại
mô hình này. Ví dụ, vấn đề chuyển biểu đồ lớp với các lớp kết hợp, các lớp có
quan hệ kế thừa, quan hệ thành phần - bộ phận tạm thời chưa được xem xét đến.
Chuyển thứ hai được thực hiện trong luận văn này là chuyển mô hình giữa biểu đồ
hoạt động UML (UML activity diagram) và đặc tả CSP. Trong đó, chúng tôi chỉ
xem xét các thành phần cơ bản của biểu đồ hoạt động. Một số luật chuyển khó
thực hiện ở ví dụ này chưa được xử lý. Với luật chuyển DecisionNode, thứ tự các
điều kiện trong luật thay đổi có thể dẫn đến các kết quả khác nhau, vấn đề tương
tự xảy ra khi chuyển JoinNode. Chi tiết về ví dụ chuyển này đã được chúng tôi
nghiên cứu và làm rõ ở bài báo [15].
1.3 Cấu trúc khóa luận
Luận văn được tổ chức như sau. Chương 1 đặt vấn đề tại sao chúng ta cần thực
hiện chuyển mô hình và cần kiểm tra tính đúng đắn của chuyển, giới hạn phạm
3
vi nghiên cứu của luận văn, và cấu trúc của luận văn. Chương 2 nhắc lại cơ sở lý
thuyết cho bài toán chuyển mô hình và đảm bảo tính đúng đắn của chuyển, vấn đề
đảm bảo chất lượng chuyển mô hình với ngôn ngữ RTL được làm rõ ở Chương 3.
Tương tự như kiểm thử phần mềm, chúng ta cũng cần kiểm tra chuyển qua hai
bước chính là kiểm chứng và hợp lệ chuyển. Trong phần này, chúng tôi mở rộng
ngôn ngữ RTL để tăng tính tự động hóa cho chuyển, cùng với các phương pháp
để kiểm tra tính đúng đắn của chuyển. Chương 4 giải quyết bài toán chuyển giữa
biểu đồ hoạt động UML và đặc tả CSP sử dụng ngôn ngữ RTL. Tính đúng đắn
của chuyển này được kiểm chứng thông qua ngôn ngữ OCL kết hợp với sự hỗ trợ
của công cụ USE. Luận văn kết thúc với một số công việc liên quan, kết quả đạt

được và một số hướng phát triển tiếp theo ở Chương 5.
4
Chương 2
Cơ SỞ lý thuyết
Chương này giới thiệu về cơ sở lý thuyết cho luận văn. Mở đầu chương,
chúng tôi giới thiệu về phương pháp phát triển phần mềm hướng mô hình.
Phương pháp này hướng đến việc giải quyết các yêu cầu phần mềm dựa
trên việc xây dựng và thao tác trên các mô hình. Hai công việc chính cần
thực hiện khi phát triển theo hướng này là biểu diễn mô hình và thao tác
với các mô hình. Ngôn ngữ mô hình hóa UML được tổ chức OMG đưa ra
và thống nhất như một quy chuẩn cho việc xây dựng các mô hình. Trong
đó, hai khái niệm cần quan tâm khi biểu diễn mô hình là mô hình và siêu
mô hình. Qua mỗi giai đoạn phát triển, các mô hình được biến đổi, làm
mịn thông qua bước chuyển đổi tự động hoặc bán tự động. Hai phương
pháp chuyển mô hình đang được nghiên cứu và phát triển rộng rãi là
Query/View/Transformation và chuyển đồ thị. Trong luận văn, chúng tôi
tập trung nghiên cứu giải pháp dựa trên hướng tiếp cận chuyển đồ thị,
cụ thể chuyển dựa trên ngữ pháp đồ thị ba (TGGs).
2.1 Phát triển phần mềm hướng mô hình
Hiện nay, phát triển phần mềm hướng mô hình nổi lên như một phương pháp giúp
cải thiện đáng kể tốc độ cũng như chất lượng phát triển phần mềm. Phương pháp
này tập trung xây dựng các mô hình nhằm biểu diễn hệ thống dưới các góc nhìn
khác nhau, từ góc nhìn trừu tượng như các biểu đồ ca sử dụng đến các biểu đồ
chi tiết như các mô hình phân tích. Các mô hình thường được biểu diễn một cách
trực quan, thể hiện được đa dạng các góc nhìn hệ thống.
Computation Platform Platform
Independent
1

>

Independent
1

>
Specific
Model Model Model
Analysis Model Design Model Basic code skeleton
Hình 2.1: Phương pháp phát triển phần mềm hướng mô hình
5
Hình 2.1 thể hiện ba nhóm mô hình chính khi phát triển phần mềm hướng mô
hình, ở những mô hình đầu tiên được tạo ra, chúng ta thường chưa cần quan tâm
tới vấn đề yêu cầu sẽ được tính toán, giải quyết như thế nào. Vì vậy, những mô
hình này được đặt trong nhóm mô hình độc lập tính toán. Một ví dụ điển hình
cho loại mô hình này là biểu đồ ca sử dụng. Trong đó, mô hình chỉ ra những yêu
cầu cần giải quyết, sự liên quan giữa các khối chức năng. Câu hỏi yêu cầu được
xử lý như thế nào sẽ được trả lời qua nhóm mô hình độc lập nền tảng. 0 nhóm
mô hình này, luồng xử lý nghiệp vụ, chi tiết về cách thức thực hiện được mô tả.
Tuy nhiên, việc mô tả này dừng lại ở một mức độ trừu tượng, mô tả chung cho tất
cả các nền tảng. Ví dụ cho nhóm mô hình này là các biểu đồ phân tích như biểu
đồ lớp, biểu đồ tuần tự. Biểu đồ nhóm này quy định cho chúng ta cách thức thực
hiện nhưng không bắt buộc chạy trên nền tảng nào. Nhóm mô hình thứ ba là mô
hình nền tảng chỉ định. Mô hình này được xây dựng cho từng nền tảng cụ thể, ví
dụ .NET, JAVA Mã chương trình là một ví dụ điển hình cho loại biểu đồ này.
Giữa các nhóm biểu đồ này, các công cụ chuyển đổi được sử dụng nhằm tăng tính
tự động hóa. Trong mỗi loại biểu đồ cũng có thể có những bước chuyển làm mịn
dần các biểu đồ.
2.1.1 Mô hình và siêu mô hình
Mô hình là một khái niệm khó có thể định nghĩa được một cách rõ ràng và đầy
đủ. Đã có nhiều định nghĩa về mô hình được đưa ra. Trong đó có hai định nghĩa
được đề xuất tại [17] và [14]. Định nghĩa trong MDA [14] nói rằng: "Mô hình là

một dạng miêu tả của (một phần của) một hệ thống viết trên một ngôn ngữ được
định nghĩa một cách rõ ràng. Ngôn ngữ ở đây là một ngôn ngữ với cú pháp và ngữ
nghĩa rõ ràng và có thể tự động biên dịch được bởi máy tính". Còn tổ chức OMG
đưa ra khái niệm mô hình trong [17] như sau: "Mô hình là một sự biểu diễn lại
một cách biểu diễn một thứ gì đó một cách tương tự hoặc một cách biểu diễn khác
của nó. Mô hình đó lưu lại các khía cạnh khác nhau của của đối tượng cần được
mô hình từ một điểm của góc nhìn và làm đơn giản hơn hoặc bỏ qua những phần
không cần xem xét tới ".
Theo OMG định nghĩa trong [17], siêu mô hình là sự miêu tả của một mô hình.
Việc xây dựng siêu mô hình được gọi là kỹ thuật metamodeling. Để xây dựng siêu
mô hình, cần phân biệt được hai khái niệm mô hình và siêu mô hình và mối liên
quan giữa chúng.
Mô hình phản ảnh sự trừu tượng của một đối tượng nào đó trong thực tế, trong
khi siêu mô hình cũng là một sự trừu tượng nhưng là sự trừu tượng cho chính mô
hình. Nói cách khác, một mô hình là một thể hiện của siêu mô hình. Mối quan hệ
giữa mô hình và siêu mô hình được giải thích thông qua ví dụ ở Hình 2.2. Hình vẽ
chỉ ra các tầng mô hình khác nhau của UML [8], mỗi một tầng là một thể hiện của
6
M3 (MOF)
Class
/A Tx
r \ \s
^ ^ I X
ôinstanceửfằ ôĂnstainceOfằ ôins
itanceOfằ
M2 (UML)
Attribute
T
Class
~7T~

classifier
Instance
Ê
ôinstahceOfằ
\
ôinstaneeOfằ ôĂnstanộeOfằ

M1 (User model)
Video
title : String ^
/
/
/
ôsnaò^hotằ _
ôinstaViceOfằ
\
\
\
ôinstajiceOfằ
: Video
title = "2001 : A Space Odyssey"
MO (Run-time Instances) aVIdeo
Hinh 2.2: Cõc tng cỹa UML
tng ngay trờn nử. Tng MO chỹa cõc dụi tỹdng khi hờ thụng dang chay, v ton
tai trong thỹc tộ, vi du aVideo nụi vố mot doan phim thỹc tộ. Tng Ml chỹa cõc
mụ hùnh. Khõi niờm Video dỹdc dinh nghùa vdi mot thuục tinh title. Mụi thnh
phn thuục tng MO luụn l mot thộ hiờn cỹa mot thnh phn ụ tng Ml: aVideo
l mot thộ hiờn cỹa Video. Tỹdng tu nhtù võy, mụi thnh phn ụ tng Ml l mot
thộ hiờn cỹa mot thnh phn tng M2. M2 dUục goi l tng mụ hùnh cỹa mụ hùnh
(hay siờu mụ hùnh). Cuoi cựng l tng M3: mụ hinh cỹa mụ hùnh M2. Dõy l mỹc

trỹu ttfụng cao nhõt cỹa UML - metametamodel.
2.1.2 Ngụn ngtù mụ hùnh hụa
Mụ hùnh cn phõi diùục biộu diờn triùdc khi cụ thộ thao tac trờn nụ. Mụi mụ hùnh
dtfỗJc biộu diờn thụng qua ngụn ngỹ mụ hùnh hụa. Ngụn ngỹ mụ hùnh hụa duỗợc
dinh nghùa trong [14] nhu sau: "Mụt ngụn ngỹ mụ hinh hụa l mụt ngụn ngỹ vụi
cỷ phõp v ngỹ nghùa rụ rang, phự hdp de cụ thờ tỹ dụng bien dich bõi mõy tinh
Dinh nghùa ny chợ ra rang ngụn ngỹ mụ hùnh hụa phõi dỹục dinh nghùa mot each
rụ rang giụng nhỹ ngụn ngỹ lõp trùnh. Dieu ny l cn thiột vù theo k nghờ hỹdng
mụ hùnh, cõc mụ hùnh sờ dỹỗJc xỹ l bụi cõc cụng eu mõy tinh mot each tỹ dụng.
Cỹng theo dinh nghùa trờn, mot ngụn ngỹ mụ hùnh hụa bao gom hai gục nhin
chinh l cỷ phõp v ngỹ nghùa. Cỷ phõp cỹa mot ngụn ngỹ mụ hùnh hụa cụ thộ
dỹục biộu diờn dỹửi dang k hiờu dụ thi hoọc dang tỹ khụa, ngụn ngỹ khi do ln
lỹụt dỹỗJc goi l ngụn ngỹ mụ hùnh hụa dang do thi v ngụn ngỹ mụ hùnh hụa dang
7
văn bản. Ngữ nghĩa của một ngôn ngữ mô hình hóa được xem dưới hai góc nhìn
tĩnh và động [13]: Ngữ nghĩa tĩnh tương ứng với các luật hình thức cho các mô
hình, trong khi ngữ nghĩa động thể hiện ý nghĩa của mô hình.
Metamodeling là một kỹ thuật để định nghĩa cú pháp cho ngôn ngữ mô hình
hóa. Kỹ thuật này được sử dụng rộng rãi để định nghĩa cú pháp trừu tượng của
ngôn ngữ mô hình hóa UML - ngôn ngữ mô hình hóa được sử dụng phổ biến hiện
nay. Metamodeling cho phép chúng ta xây dựng một mô hình hướng đối tượng của
cú pháp trừu tượng của một ngôn ngữ. Một siêu mô hình biểu diễn các thành phần
của ngôn ngữ như lớp và mối quan hệ giữa các lớp sử dụng thuộc tính (attributes)
và các mối liên hệ (associations).
2.2 Chuyển mô hình
Bước tiếp theo sau khi đã biểu diễn được các mô hình là thao tác với các mô hình
đó. Trong phát triển hướng mô hình, thao tác với mô hình chủ yếu là chuyển mô
hình. Việc chuyển mô hình sẽ làm tăng tốc độ và tính đúng đắn của phần mềm.
Class model
Person

Int: personlD
String: name
Rules
V
Table
Person
person ID
name
Rules
SQL
V
CREATE TABLE Person
{ PersonID NUMBER(IO) PRIMARY KEY,
name VARCHAR2(50) NOT NUL
}___________________________________
Hình 2.3: Ví dụ chuyển từ biểu đồ lớp - bảng quan hệ dữ liệu
Hình 2.3 mô tả một ví dụ về việc áp dụng chuyển mô hình trong phát triển
phần mềm. Khi xem xét các mô hình, ta thấy rằng giữa các mô hình có những sự
tương đồng nhất định. Sự tương đồng này có thể được tổng hợp lại và biểu diễn
dưới dạng các luật chuyển. Trên Hình 2.3, ta thấy ba dạng mô hình được biểu diễn.
8
Biểu đồ lớp biểu diễn dạng trực quan của một đối tượng Person. Tiếp theo là một
dạng khác của đối tượng này: dạng Table khi xem xét đối tượng dưới góc độ quan
hệ dữ liệu. Và dạng cụ thể nhất của đối tượng Person ở đây là các câu lệnh SQL.
Tại đây, chúng ta nhận thấy có thể áp dụng hai bước chuyển để thu được các câu
lệnh SQL từ một biểu đồ lớp. Luật chuyển đồ thị định nghĩa sự tương ứng giữa
biểu đồ lớp và biểu đồ quan hệ dữ liệu, và giữa biểu đồ quan hệ dữ liệu và các câu
lệnh SQL.
Các bài toán chuyển mô hình cũng đòi hỏi phải đáp ứng một số những yêu cầu
riêng. Thứ nhất đó là tính đúng đắn của mô hình phải được đảm bảo. Mỗi mô

hình phải thỏa theo metamodel của nó. Ràng buộc OCL được định nghĩa trong
mỗi metamodel phải được thỏa mãn. Ví dụ, với chuyển mô hình từ biểu đồ lớp
sang biểu đồ quan hệ dữ liệu, mô hình nguồn phải thỏa mãn metamodel của biểu
đồ lớp; mô hình đích phải thỏa mãn metamodel của biểu đồ quan hệ dữ liệu; ràng
buộc OCL định nghĩa của hai metamodel phải luôn đúng. Ví dụ, ràng buộc: "Mỗi
lớp phải có ít nhất một thuộc tính " được biểu diễn dưới dạng OCL như sau:
context Class inv hasAtLeastOneAttr: attrs->size() > 0
Ngoài ra, các bài toán chuyển mô hình còn phải đảm bảo tính hợp lệ của
chuyển. Thông thường, bài toán hợp lệ chuyển được thực hiện bằng cách kiểm tra
chuyển trên một tập các dữ liệu đầu vào và đầu ra mong muốn, sau đó so sánh
kết quả thu được với đầu ra mong muốn để có thể kết luận được chuyển có hợp
lệ hay không. Hiện nay bước hợp lệ chuyển thường không thể hoàn toàn tự động:
Người mô hình hóa thường phải định nghĩa đầu vào và đầu ra mong muốn (gọi là
testcase), sau đó so sánh kết quả thu được với đầu ra mong muốn để có được kết
luận về tính đúng đắn của testcase. Quá trình này thường thực hiện bán tự động,
testcase có thể được sinh tự động, việc thực hiện so sánh kết quả có thể được biểu
diễn một cách trực quan, sự khác nhau giữa kết quả thu được với kết quả mong
đợi có thể được đánh dấu.
Bài toán chuyển mô hình được nghiên cứu và giải quyết theo hai hướng chính:
QVT và chuyển đồ thị. Theo hướng tiếp cận QVT, nhiều công cụ đã được xây
dựng và ứng dụng rộng rãi trong công nghiệp. ATL là một công cụ điển hình cho
hướng tiếp cận này [12]. Ó hướng tiếp cận này, các luật chuyển được xây dựng
dựa trên metamodel kết hợp với các ràng buộc OCL. Do đó, các luật chuyển được
biểu diễn một cách rõ ràng, hỗ trợ kiểm chứng mô hình. Tuy nhiên, hướng tiếp
cận này gặp phải khó khăn khi cần chuyển đổi hai chiều. Hướng tiếp cận thứ hai
là phương pháp chuyển đồ thị. Trong đó, các luật được biểu diễn dựa trên cơ sở
toán học chặt chẽ, luật chuyển được biểu diễn ở dạng trực quan, dễ hiểu. Một số
công cụ dựa trên chuyển đồ thị chỉ hỗ trợ chuyển một chiều như các tác giả ở bài
báo [20] đã thực hiện; một số khác dựa trên Triple Graph Grammars (TGGs) hỗ
trợ chuyển hai chiều giữa các mô hình [19]. Ngoài ra, các tác giả ở bài báo [4, 2]

còn đề xuất cách tiếp cận để đảm bảo tính đúng đắn của chuyển.
9
2.3 Ngữ pháp đồ thị ba (TGGs)
Ngữ pháp đồ thị ba (TGGs) đã được đề xuất lần đầu trong bài báo [19]. Mục đích
nhằm dễ dàng miêu tả các chuyển đổi phức tạp trong kỹ nghệ phần mềm. TGG
cho phép chúng ta chỉ ra sự ánh xạ giữa hai ngữ pháp đồ thị hay sự liên hệ giữa
các thành phần trong hai đồ thị. Sự ánh xạ này đạt được bằng cách bổ sung các
thành phần kết nối giữa các thành phần trong hai đồ thị đó. Do đó, một đồ thị ba
có chứa ba phần của luật tương ứng với ba phần nguồn, phần kết nối và đích. Từ
một luật đồ thị ba, chúng ta có thể có được các luật dẫn xuất mới cho ngữ cảnh
chuyển tiến, chuyển ngược, chuyển đồng tiến hóa và chuyển tích hợp.
Ngữ pháp đồ thị ba cho phép chúng ta đặc tả sự tương ứng giữa hai loại mô
hình khác nhau. Sức mạnh của TGG không chỉ thể hiện ở khả năng biểu diễn mối
quan hệ giữa hai loại mô hình, mà các đặc tả đó còn thể hiện các hành động thực
thi để một mô hình có thể chuyển đổi sang một mô hình khác. TGGs có thể được
sử dụng cho nhiều ngữ cảnh khác nhau như (1) chuyển từ mô hình nguồn sang mô
hình đích hoặc ngược lại, (2) kiểm tra, tính toán sự đồng bộ giữa hai mô hình đã
tồn tại, và (3) duy trì sự nhất quán giữa hai mô hình ngay cả khi chúng thay đổi
độc lập với nhau.
Chuyển đồ thị dựa trên TGGs bao gồm các khái niệm chính: Graph, Type
Graph, Triple Graph, Triple Graph Morphism, và Triple Graph Grammar [4].
Định nghĩa 2.1. Graph, Type graph
Hình 2.4: Ví dụ graph và typed graph
Hình 2.4 chỉ ra một ví dụ về ‘graph’ và ‘typed graph’. Trong đó, mô hình ở
phần (3) là một Graph, metamodel được coi như một Type graph định nghĩa cấu
trúc của biểu đồ hoạt động. Trên ví dụ, khối (1) là dạng biểu diễn trực quan của
10
một biểu đồ hoạt động. Mô hình này được xây dựng dựa trên metamodel của
biểu đồ hoạt động. Dạng biểu diễn đơn giản của metamodel thể hiện ở khối (2).
Metamodel này là một biểu đồ lớp, chỉ ra sự liên kết giữa các lớp đối tượng. Dạng

trừu tượng của khối (1) được chỉ ra ở khối (3). Đây là một biểu đồ đối tượng, gồm
các đối tượng và liên kết tạo thành một đồ thị (graph).
Định nghĩa 2.2. Triple Graph, Triple Graph Morphism
Hình 2.5: Ví dụ về Triple Graph
ĐỒ thị ba là một đồ thị bao gồm ba đồ thị thành phần: SG, CG, TG tương ứng
với các đồ thị nguồn, kết nối và đích cùng với hai ánh xạ đồ thị SG := CG ->• SG
và to CG —> TG tạo thành dạng G — SG % CG TG. Một ánh xạ đồ
thị ba m = (s,c,t) : G —> H giữa hai đồ thị ba G = (SG 4^ CG % Tơ) và
G = (SH sơ- CH A TH) bao gồm ba ánh xạ đồ thị: a : SG SH, c : CG -> CH
và t : TG —> TH s o SG = SỊỊ ° c và t o tũ = tu ° c. Các đồ thị ba kết hợp với các
ánh xạ của nó tạo thành một dạng đồ thị ba. Hình 2.5 biểu diễn một Triple Graph
có chứa một biểu đồ hoạt động cùng với các thành phần kết nối để sinh ra đặc tả
CSP. Ba phần của đồ thị từ trái sang phải tương ứng là các phần nguồn, kết nối
và đích trong đồ thị ba.
Định nghĩa 2.3. Triple Graph Grammar
Một luật ba tr = L R bao gồm hai đồ thị ba L và R và một ánh xạ đồ thị
ba tr thỏa mãn:
L = {SL
tr s
H - (SR
ÍL
tr
SL
s c
„ tR m
SR
CR
Cho một luật triple rule tr = (s,c,t) : L —► R, một đồ thị ba G và một ánh xạ
đồ thị ba m = (sm, cm, tm) : L —)■ G được gọi là triple match m, một bước chuyển
11

tr — G = £ ĩĩ từ G tới triple graph H được cho bởi ba đối tượng SH, CH và TH
với ánh xạ SJI := CH —>■ SH và ÍH := CH —> TH. Ánh xạ n = (sra, cn,tn) được gọi
là comatch.
SL <- CL - TL
G =
tr
Một ngữ pháp đồ thị ba là một cấu trúc TGG = (TG, s, Tiỉ) trong đó TG là một
triple type graph, s là đồ thị ban đầu, và TR = tri, tr2, trn là tập các luật triple
rules. Ngôn ngữ đồ thị ba của TGG là một tập {G|3 chuyển đồ thị ba s ==> G}
Hình 2.6: Ví dụ về Triple Rule
Hình 2.6 biểu diễn một ví dụ về luật triple rule. Luật này nằm trong tập luật
chuyển từ biểu đồ hoạt động sang đặc tả CSP. Chi tiết về ví dụ cùng với đặt tả
đầy đủ luật chuyển sẽ được chúng tôi mô tả chi tiết ở Chương 4.
Từ định nghĩa một cú pháp đồ thị ba TGG — (S,TR,T, Á), chúng ta có tập các
ngôn ngữ VL = (VLs,VLc,VLt) với VLs, VLC và VLt tương ứng là các ngôn ngữ
nguồn, kết nối và đích. Các ngôn ngữ này ánh xạ tương ứng với ba phần của đồ
thị ba trong VL. Qua những ngôn ngữ này, có một số dẫn xuất chuyển đổi có thể
thực hiện được: chuyển tiến, chuyển lùi, chuyển tích hợp và chuyển đồng tiến hóa.
Định nghĩa 2.4. Chuyển tiến
Chuyển tiến được định nghĩa như sau: Cho một đồ thị Gs <EVLS. Một chuyển
tiến từ Gs đến Gt là một sự tính toán để định nghĩa đồ thị Gt eV L t thông qua
dẫn xuất s Ạ (Gg 4- Gc GT)
12
Định nghĩa 2.5. Chuyển lùi
Cho một đồ thị Gt £ VLị. Một chuyển lùi từ Gt đến Gs là một sự tính toán
để định nghĩa đồ thị Gs EVLS thông qua dẫn xuất s Ạ (Gs «— Gc —ì Gt)
Định nghĩa 2.6. Chuyển tích hợp
Cho một đồ thị Gs £ VLS và Gt £ VLị. Một sự tích hợp mô hình là một sự
tính toán của Gs và GT để định nghĩa một dẫn xuất s 4> (Gs •(— Gc ->■ Gt )
Định nghĩa 2.7. Chuyển đồng tiến hóa

Cho Es £ VLS và ET eV L t là các đồ thị thể hiện phần nguồn và đích của đồ
thị ba E. Một chuyển đồng tiến hóa từ (Es, ET) sang (Fs, Ft) là một sự tính toán
để định nghĩa các đồ thị Fs &VLS và Ft eV L ị thông qua dẫn xuất (Es £- Ec —»■
Et) =>■ (Fs £- Fc —>• Ft).
Định nghĩa 2.8. Các luật dẫn xuất
Mỗi luật tr = L —> R dẫn xuất tới các luật tiến, luật lùi và luật tích hợp như
sau:
(SR
S°SL
ỉd
(.SR
CL TL)
, t
__
ÍR
CR — TR)
SR
Luật tiến trF
(,SL
s
(.SR
SL
toíi
CL — + TR )
id
__
tR
*

CR — TR)

SR
Luật lùi trB
(,SR
S°SL
id
(.SR
_ _ t o
ƠL — í TR )
id
__
tiỉ

ơi? — Ti?
Siỉ
Luật tích hợp tri
Cho mô hình ban đầu Gs, mô hình Gt của chuyển tiến có thể được định nghĩa
bằng một loạt các dẫn xuất với luật tiến như sau:
(Gs ^ S c ^ S t ) iầ ỉ^ i (Gs ^ G c ^ G t )
với trFị là luật tiến dẫn xuất từ trị.
Tương tự, dẫn xuất của luật lùi được định nghĩa như sau:
{Ss<-SC ^ S T) (Gs <- Gc —> Gt )
với trBị là luật lùi dẫn xuất từ trị.
Dẫn xuất của luật tích hợp:
{Gs ^ S c ^ G t ) (Ọs <-Gc Gt )
với trlị là luật tích hợp dẫn xuất từ trị.
Hình 2.7 mô tả một bước chuyển tiến khi áp dụng luật chuyển ở Hình 2.6. Các
thành phần đánh dấu (++) trên hình chỉ ra những thành phần được bổ sung sau
khi áp dụng luật.
2.4 Tích hợp OCL và Triple Rules
Ngôn ngữ OCL được thêm vào các luật triple rule dưới dạng các ràng buộc. Việc

tích hợp này giúp tăng khả năng biểu diễn luật triple rule.
13
Hình 2.7: Ví dụ về một bước chuyển khi áp dụng dẫn xuất chuyển tiến
Định nghĩa 2.9. OCL Application Conditions
OCL application conditions của một luật triple rule bao gồm các ràng buộc
OCL cho các mô hình nguồn, đích và phần trung gian của luật triple rule. BACs
trong LHS và RHS của luật triple rule là tiền điều kiện và hậu điều kiện được định
nghĩa tương ứng như sau:
• BACpre = BACsl u BACcl u BACtl
• BACpost = BACsr u BACcr u BACtr
• BAC — [BACpre, BACpostị
với BACXX : XX e { ‘SL’/S R ’/C L ’/C R ’/T L ’/T R ’ } là BACs trong LHS và RHS
của phần nguồn, đích và phần trung gian của luật triple rule; BACpre và BACpost
tương ứng là tiền điều kiện và hậu điều kiện của luật triple rule.
Định nghĩa 2.10. Application Condition Fulfillment
Một triple rule với BACs là một tập tr — (L, R, BAC) với BAC bao gồm các
ràng buộc OCL. Một triple graph H được dẫn xuất từ một triple graph G bởi luật
triple rule
tr = (L, R, BAC) và một triple match m:
• H nhận được bởi (L -»■ R, m) và
• BAC được đáp ứng hoàn toàn trong luật G A H
với r : L —>■ R là một luật nhận được từ tr bằng cách xem xét các triple graphs
LHS và RHS.
Tiền điều kiện và hậu điều kiện của các luật dẫn xuất
Cho một triple rule tr. Tiền điều kiện của các luật dẫn xuất từ tr được định
nghĩa như sau:
• BAC%1 = BACgto u BACqL u BACỈfL
14
• BAƠ£ ? = B A C fL u B A C $l u BA C ịĨR,
. B A C £ ị = BA C ga, u B y i c g i u BACĨ£R^

Hậu điều kiện của các luật dẫn xuất được định nghĩa như sau:
• B A C Ị* = BAC%g, u Ì M C & u ¿ M C ? R
• B A C Ị* = BAC%„ u BAC%r u BA C ỈfRít
• = ^ C s s . u A 4 C & * u B A C Ĩb,
• BAC^re, BAC^re, BAC^ị tương ứng là tiền điều kiện của các luật dẫn xuất
chuyển tiến, chuyển lùi và chuyển tích hợp; BACịra^t, BACịr0ft, BACỰjst là hậu
điều kiện của các luật dẫn xuất tương ứng.
• BACịrx : XX e { ’Sư , ’SR ’, ’Cư, ’CR’, ’T ư, ’TR ’ } là BACs trong các phần
LHS, RHS của luật triple rule tr.
• BAC^Ríi:,BAC^R^B AC ^Ríf là BACs ngoại trừ các phần với ’ũpre’ trong SR,
CR và TR
15
Chương 3
Đảm bảo chất lượng chuyển mô hình
Phần này giới thiệu cách tiếp cận của chúng tôi cho vấn đề chuyển và đảm bảo
chất lượng chuyển mô hình dựa trên TGGs. Ngôn ngữ chuyển mô hình RTL được
định nghĩa dựa theo hướng tiếp cận chuyển mô hình sử dụng TGGs kết hợp với
ràng buộc OCL làm cơ sở [4].
3.1 Ngôn ngữ RTL
Hiện nay, nhiều công cụ chuyển mô hình dựa trên TGG đã được nghiên cứu và phát
triển [18]. Những công cụ này chia sẻ một nền tảng lý thuyết chung. Tuy nhiên, sự
thực hiện là khác nhau về cách biểu diễn, khả năng áp dụng luật, tính hiệu quả
và các thuật toán thực hiện (lựa chọn và xác định thứ tự thực hiện luật). Một số
công cụ tiêu biểu phát triển dựa trên TGG như MoTE [10], TGG Interpreter [6, 7],
và eMoflon [1], Bài báo [18] so sánh ba công cụ này dựa trên một số tiêu chí cho
chuyển mô hình và chỉ ra ưu, nhược điểm của từng công cụ. eMoflon thích hợp
để người dùng tương tác với chuyển, MoTE/eMoflon có thể sử dụng cho các mô
hình lớn và những trường hợp đòi hỏi tính hiệu quả. MoTE/TGG Interpreter là
lựa chọn tốt cho việc cập nhật tăng dần; TGG Interpreter và eMoflon hỗ trợ một
số tính năng nâng cao của TGG cho các trường hợp yêu cầu tính biểu diễn cao.

Ngôn ngữ RTL được định nghĩa dựa theo hướng tiếp cận chuyển mô hình sử
dụng TGGs làm cơ sở [4]. Hướng tiếp cận chuyển dựa trên TGGs có nhiều ưu điểm
như: khả năng đặc tả luật chuyển, hỗ trợ chuyển đổi hai chiều. Tuy nhiên, TGGs
gặp phải vấn đề về kiểm chứng chuyển. RTL đã kết hợp được luật chuyển TGGs
và ngôn ngữ ràng buộc đối tượng OCL để giải quyết vấn đề trên. Phương pháp kết
hợp TGGs và OCL đã được chúng tôi thảo luận ở Phần 2.4.
Ngôn ngữ RTL là một ngôn ngữ khai báo và được đặc tả dưới dạng văn bản. Các
luật chuyển TGG được hiện thực hóa bởi RTL thông qua chuỗi các lệnh USE [5]
( USE command sequences) kết hợp với ràng buộc OCL pre- và postcondition.
16
3.1.1 Đặc tả ngôn ngữ RTL
Hình 3.1 chỉ ra cấu trúc ngữ nghĩa của ngôn ngữ RTL. Đặc tả RTL được xây dựng
dựa trên đặc tả của các luật TGGs đi kèm với biểu thức OCL: TGGsSzOCLPattern.
Một luật chuyển được bắt đầu với tên luật ruỉeName. Nội dung của luật chuyển
được đặc tả thành ba phần riêng biệt thông qua các từ khóa ‘checkSource’, ‘check-
Target’ và ‘checkCorr’ tương ứng với ba phần trong luật TGG: Nguồn, Đích và
Kết nối. Trong mỗi phần lại được chia ra làm hai phần Left và Right. Chúng ta có
thể dễ thấy được RTL đặc tả sáu phần riêng biệt của luật TGGs. Mỗi phần đó có
dạng ngữ nghĩa như sau:
TGGhOCL Pattern — {object : Class_i
{object!, objects) : Association_j
['o c L _ c ondition _k]}
Trong đó có các phần: khai báo tập các đối tượng (ví dụ object là một đối tượng
của lớp Class_ỉ); quan hệ giữa các đối tượng {objectl và object2 được biểu diễn
bởi lớp Association j)-, phần cuối là ràng buộc OCL đi kèm chỉ ra ràng buộc cho
các đối tượng trong phần này của luật. Sự tương ứng giữa các thành phần trong
mô hình nguồn và đích được thể hiện thông qua những đường liên kết giữa các
đối tượng của phần ‘checkSource’ với ‘checkCorr’ và ‘checkTarget’ với ‘checkCorr’.
Đường liên kết này được đặc tả trong thành phần ‘checkCorr’.
rule <ruleName>

[mode NONDELETINGIEXPLICT]
checkSource(
<TGGs&OCL Pattern>
){
<TGGs&OCL Patterns»}
checkTarget(
<TGGs&OCL Pattern>
){
<TGGs&OCL Pattern>}
checkCorr(
<Ext TGGs&OCL Pattern>
){
<Ext TGGs&OCL Pattern>}
end
Hình 3.1: Cú pháp ngôn ngữ RTL
Ngôn ngữ RTL cho phép đặc tả thành phần thể hiện sự liên kết giữa các thành
phần mô hình nguồn và mô hình đích trong ‘checkCorr’. Thành phần liên kết này
được đặc tả như sau:
[object_s, objectT) as {role_S, role_T) in object_C : Class_C
Trong đó, s, c, T tương ứng với nguồn, kết nối và đích. Thông qua đặc tả này,
chúng ta sẽ đạt được metamodel của thành phần kết nối.
17
Hình 3.2: Luật chuyển ClassToTable đặc tả sử dụng RTL
Hình 3.2 chỉ ra một ví dụ luật chuyển đặc tả sử dụng ngôn ngữ RTL: luật
chuyển giữa một Class và một Table trong bài toán chuyển giữa biểu đồ lớp UML
và biểu đồ quan hệ dữ liệu. Phần (2) của Hình 3.2 là đặc tả dạng RTL của luật
triple rule ở phần (1).
Ràng buộc OCL được đưa vào mỗi luật chuyển dưới dạng invariant ở cả Nguồn,
Đích và Kết nối. Đó có thể là invariant kiểm tra tính toàn vẹn của từng mô hình,
hoặc là một ràng buộc về thuộc tính giữa các đối tượng nguồn và đích. Điều này

sẽ góp phần giải quyết vấn đề đảm bảo tính đúng đắn của luật chuyển cũng như
tính toán vẹn của mô hình nguồn và mô hình đích khi sử dụng TGGs. Ví dụ luật
Class2Table ở Hình 3.2, ràng buộc đặt ra là Class phải có thuộc tính is_persistent
là ‘true’; Thuộc tính name của Table sinh ra phải giống với thuộc tính name của
Class tương ứng.
Cú pháp RTL mở rộng
Trong luận văn, chúng tôi mở rộng ngôn ngữ RTL cho phép người mô hình hóa
định nghĩa một cấu trúc điều khiển cho chuyển, cấu trúc mở rộng được định nghĩa
như hình 3.3.
Cú pháp mở rộng được thực hiện tương tự các ngôn ngữ lập trình. Trong đó có
các lệnh điều khiển như vòng lặp (multiApplication), điều kiện (restrictedApplica-
tion) hoặc thực thi một lệnh cụ thể (singleApplication). Các điều kiện tại các lệnh
điều khiển được đặc tả sử dụng ngôn ngữ OCL oclExpression. Người mô hình hóa
có thể định nghĩa cấu trúc điều khiển theo mong muốn cho từng bài toán cụ thể.
Có thể áp dụng cấu trúc điều khiển này cho các ngữ cảnh chuyển tiến, chuyển lùi,
chuyển đồng tiến hóa hoặc chuyển tích hợp. Qua đó, chuyển đồ thị qua ngôn ngữ
RTL có thể thực hiện hoàn toàn tự động.
18
- <transformation> ::= transformation <trafolD>
direction forward | backward | integration | co-evolution l^vnchronization
{[< matchl D:=>]<ruleAppiication >;}
{tggRulcDofinition}
trong do:
- <ruleApplicaUon> ::= <simpleApptication> \ <multiApplication>
| <setectedApplication> \ <restrictedAppiication>
- <simpleAppiication> ::= <rulelD>()
- <multiApplication> ::= do {<ru!eApplication>‘} while (<oclExpression>)
- restricted Application^ :: = if (<ocl Expression >)'{'
{< ruteAp p iication> ; ]
T

- selectedAppfiçatipn ::= apply(<ruleld> | <oclExpression>];
Hình 3.3: Cú pháp RTL mở rộng
Hình 3.4: Thực thi luật TGG bằng OCL: (1) bằng cách khai báo ràng buộc OCL pre- và postconditions,
(2) bằng chuỗi các lệnh USE
19
3.1.2 Thực thi chuyển vđi RTL
Khi thực thi chuyển RTL, mỗi ngữ cảnh chuyển đổi được xem như một loại đặc
biệt của mô hình hành vi (model behavior). RTL được thực thi theo hai góc nhìn:
Khai báo các ràng buộc OCL pre- và postcondition trong từng thao tác chuyển,
và chuỗi các lệnh USE để hiện thực hóa các thao tác chuyển.
Hình 3.4 chỉ ra cách thức thực thi một luật chuyển RTL [4], Ý tưởng chính ở
đây là sự ánh xạ tương ứng giữa hệ thống chuyển đồ thị và hệ thống hướng đối
tượng: (1) đồ thị tương ứng với trạng thái của hệ thống, (2) một luật chuyển đồ thị
tương ứng với một sự tương tác trong ngữ cảnh thực thi một hành động, (3) LHS
và RHS của một luật tương ứng một hình ảnh về hệ thống dưới dạng tiền và hậu
điều kiện của sự tương tác tương ứng. Trong đó, luật TGG được hiện thực bởi
chuỗi các dòng lệnh USE: bao gồm các thao tác cơ sở như tạo mới, hủy đối tượng;
thêm, xóa liên kết giữa chúng hoặc thay đổi thuộc tính của đối tượng. LHS và RHS
sẽ được kiểm tra thông qua biểu thức OCL tương ứng: tiền điều kiện và hậu điều
kiện.
pre trafoClass2T able_forwT rafo_pre:
«precondition»
context C2T inv: self.t.name=self.c.name
-m atchSR : Tuple(theClassA:Class)
let theClassA: Class = matchSR.theClassA in
—S_precondition
theClassA.nameoocl Undefined (String) and
theClassA.is persistent=true
______________
«invariants»

:Class
name:=,person'
is_persi stent:-true'
attribute :DataType
namei-age' name:='int'
«postcondition»
post trafoClass2T able_forwT rafo_post:
:Class
++
Table
namei-person'
is_persistent:-true'
c2t1 :C2T
namei-person’
¡Attribute :DataType
namei-age'
name:='int'
A2C rule
-matchSR: Tuple(theClassA:Class)
let theClassA:Class = matchSR.theClassA in
-T_postcondition
(Table.alllnstances - Table.alllnstances@pre)
>exists(theTableA|
-C_postcondition
¡Class
o
¡Table
name^'person'
c2t1 :C2T
name^'person'

is_persistent:='true'
¡Attribute ¡DataType
name:-age'
name:='int'
:Column
a2c:A2C — name:='age'
type:='int'
Hình 3.5: Thực thi luật chuyển ClassToTable
Hình 3.5 thể hiện việc áp dụng chuyển tiến cho ví dụ chuyển từ biểu đồ lớp
sang biểu đồ quan hệ dữ liệu. Trạng thái (1) chúng ta có một biểu đồ lớp đơn
giản với một Class có thuộc tính name là ‘person’ cùng với một lớp Attribute có
tên ‘age’. Áp dụng bước chuyển ở Hình 3.2 để thu được mô hình ở trạng thái (2).
20
Bước chuyển này tạo ra hai thành phần mới được đánh dấu (++). Tại bước chuyển
này, ràng buộc tiền điều kiện và hậu điều kiện được thực hiện trước và sau các
thao tác chuyển. Tương tự, trạng thái (3) là kết quả sau khi áp dụng chuyển
AttrìbuteToColumn trên trạng thái (2). Mỗi trạng thái (1),(2),(3) được coi như
hình ảnh tại một thời điểm của hệ thống. Kết quả cuối cùng bao gồm mô hình
nguồn, mô hình đích cùng với thành phần trung gian định nghĩa sự tương ứng giữa
hai mô hình.
3.2 Đảm bảo chất lượng chuyển mô hình RTL
Ngôn ngữ RTL hỗ trợ một số giải pháp nhằm đảm bảo chất lượng chuyển mô hình
thông qua kết hợp các luật triple rule và ngôn ngữ ràng buộc OCL.
3.2.1 Kiểm chứng chuyển
ở phần này, chúng tôi chỉ tập trung kiểm chứng ngữ cảnh chuyển tiến. Các ngữ
cảnh chuyển khác như chuyển lùi, chuyển đồng tiến hóa hoặc chuyển tích hợp có
thể đạt được theo cách tương tự. Bài toán kiểm chứng chuyển tiến như sau. Cho
hai metamodel MMs, MMt . Cho mô hình nguồn Ms thỏa mãn metamodel MM s.
Cho một hệ thống chuyển TGG: TGGS = (5, TR) đặc tả bởi ngôn ngữ RTL. Thông
qua chuyển tiến, chúng ta thu được mô hình Mt . Yêu cầu đặt ra làm sao kiểm

chứng được mô hình Mt được định nghĩa đúng.
• Kiểm tra ràng buộc invariants của chuyển. Ở định nghĩa luật chuyển
TGG, chúng tôi đã định nghĩa thêm các thành phần trung gian chỉ ra sự tương
ứng giữa thành phần mô hình nguồn và mô hình đích. Vậy yêu cầu đầu tiên
là sự ánh xạ giữa các thành phần phải đúng theo luật triple rule. Luật TGG
định nghĩa sự liên kết từ thành phần trung gian đến các thành phần của mô
hình nguồn và đích. Sau khi chuyển đổi, những liên kết này được kiểm tra sự
tồn tại, đảm bảo các thành phần, liên kết đã được sinh đầy đủ theo đặc tả
luật. Một ràng buộc khác cũng cần kiểm tra là sự tương ứng giữa các thuộc
tính của các đối tượng. Ràng buộc này được định nghĩa qua ràng buộc OCL
invariants. Ví dụ với luật chuyển ClassToTable, yêu cầu thuộc tính name của
Class và Table phải giống nhau. Ràng buộc này biểu diễn dưới dạng OCL như
sau:
context C2T inv: self.t.name=self.c.name
• Kiểm tra tính toàn vẹn của các mô hình. Ngoài các ràng buộc cho thành
phần trung gian, bản thân các mô hình cũng phải thỏa mãn metamodel của
chính nó. Tuy nhiên, các ràng buộc cho mỗi mô hình chỉ được kiểm tra khi
mô hình đã được chuyển đổi hoàn toàn và có thể không đúng ở một trạng thái
21
trung gian nào đó. Các ràng buộc này thường được biểu diễn dạng ỉnvariants.
Ví dụ trong biểu đồ quan hệ dữ liệu có ràng buộc: “Mỗi bảng có ít nhất một
cột làm khóa chính”. Ràng buộc này biểu diễn dạng OCL như sau:
context Table inv hasPrimary: self.priKey->size() > 0
• Kiểm tra ràng buộc tiền điều kiện, hậu điều kiện tại mỗi bước
chuyển. Theo cách kết hợp ràng buộc OCL và các luật triple rule ở Phần 2.4,
mỗi bước chuyển được kiểm chứng thông qua cặp ràng buộc tiền điều kiện và
hậu điều kiện. Với từng ngữ cảnh chuyển cụ thể, cặp ràng buộc này được tự
động sinh từ đặc tả RTL. Việc kiểm tra cặp ràng buộc này sẽ đảm bảo bước
chuyển được thực hiện đúng theo đặc tả. Ví dụ cụ thể về cặp ràng buộc được
thể hiện ở Hình 3.5.

3.2.2 Hợp lệ chuyển
Phần này tập trung làm rõ khả năng hợp lệ chuyển của ngôn ngữ RTL. Tính năng
này được thực hiện một cách bán tự động.
• HỢp lệ chuyển thông qua chuyển tích hợp. Thông thường, chúng ta
thường định nghĩa testcase để hợp lệ chuyển. Testcase bao gồm mô hình nguồn
Ms và mô hình đích mong muốn Mt - Sau đó, cần kiểm tra mô hình đích sinh
ra m 't có giống với mô hình mong muốn Mt hay không. Thay vì phải định
nghĩa mô hình đích mong muốn Mt , chúng tôi áp dụng ngữ cảnh chuyển tích
hợp để hợp lệ mô hình đích M'rp. Thông qua ngữ cảnh chuyển tích hợp, một sự
ánh xạ giữa mô hình nguồn và mô hình đích được tạo ra. Qua đó, người mô
hình có thể kiểm tra thành phần nào đang ánh xạ không đúng.
• Kiểm tra biểu thức OCL tại các trạng thái hệ thống. Sau mỗi bước
chuyển, chúng ta sẽ thu được một trạng thái của hệ thống bao gồm các thành
phần của cả mô hình nguồn, mô hình đích và các thành phần trung gian.
Chúng ta có thể áp dụng các biểu thức OCL để kiểm tra trạng thái hiện thời.
Với sự hỗ trợ của công cụ USE, các thành phần trong câu truy vấn OCL được
nhấn mạnh. Qua đó, người mô hình hóa có thể dễ dàng kiểm tra luật được
thực hiện đúng hay chưa.