(Luận văn thạc sĩ) ngôn ngữ chuyển mô hình RTL (restricted graph transformations language)

MỤC LỤC
TÓM TẮT ............................................................................................................ ii
BẢNG KÝ HIỆU VÀ CÁC CHỮ VIẾT TẮT ................................................... iii
DANH SÁCH HÌNH VẼ .................................................................................... iv
MỞ ĐẦU .............................................................................................................. 1
Chương I Cơ sở lý thuyết cho chuyển mô hình ................................................... 2
1.1 Phát triển hướng mơ hình ............................................................................... 2
1.1.1 Khái niệm về mơ hình ................................................................................. 4
1.1.2 Các chuẩn hướng tiếp cận MDD ................................................................. 5
1.1.3 Kiến trúc MDA............................................................................................ 6
1.2 Tổng quan về chuyển mơ hình ....................................................................... 7
1.2.1 Các thuật ngữ trong chuyển mơ hình .......................................................... 8
1.2.2 Một số giải pháp sử dụng ngôn ngữ chuyển ............................................... 9
1.3 Tổng kết chương .......................................................................................... 10
Chương II Ngơn ngữ chuyển mơ hình RTL ....................................................... 11
2.1. Cơ sở hình thức cho RTL ............................................................................ 11
2.1.1 Kiến thức cơ sở về văn phạm đồ thị ba ..................................................... 12
2.1.2 Luật chuyển TGGs ràng buộc OCL .......................................................... 14
2.2. Cú pháp của RTL ....................................................................................... 22
2.3. Thực thi chuyển ........................................................................................... 23
2.4. USE hỗ trợ RTL .......................................................................................... 24
Chương III Thực nghiệm chuyển mơ hình với RTL .......................................... 26
3.1 Bài tốn chuyển UML sang CSP ................................................................. 26
3.1.1 Metamodel của biểu đồ hoạt động UML .................................................. 26
3.1.2 Metamodel của CSP .................................................................................. 28
3.2 Phương thức chuyển ..................................................................................... 29
3.3. Kết quả chuyển UML2CSP ......................................................................... 31
3.3.1 Xây dựng luật: ........................................................................................... 31
3.3.2 Áp dụng luật chuyển cho ví dụ cụ thể ....................................................... 37
3.4 Tổng kết chương .......................................................................................... 38
KẾT LUẬN ........................................................................................................ 40

TÀI LIỆU THAM KHẢO .................................................................................. 41
PHỤ LỤC ........................................................................................................... 42
A. XÂY DỰNG MƠ HÌNH VÀ LUẬT CHUYỂN ĐỔI................................... 42
B. MÃ SINH CỦA LUẬT ................................................................................. 49
i


BẢNG KÝ HIỆU VÀ CÁC CHỮ VIẾT TẮT
Từ viết tắt

Từ chuẩn

Diễn giải

MDA

Model Driven Architecture

Kiến trúc hướng mơ hình

MDD

Model-Driven Development

Phát triển hướng mơ hình

MOF

Meta-Object Facility

Một chuẩn của OMG

OMG

Object Management Group

Tổ chức quản lý đối tượng

OCL

Object Constraint Language

Ngôn ngữ ràng buộc đối tượng

UML

Unified Modeling Language

Ngơn ngữ mơ hình hóa thống
nhất

RTL

Restricted

graph Ngơn ngữ chuyển mơ hình giới

transformations language

hạn

TGG

Triple graph grammar

Văn phạm đồ thị ba

CSP

Communicating

sequential Tiến trình giao tiếp tuần tự

processes

iii


DANH SÁCH HÌNH VẼ
Hình 1.1: Ví dụ về hệ thống phân cấp metamodel bốn lớp của UML[3] ............. 5
Hình 1.2 Mơ hình mối quan hệ ở mức metamodel ............................................... 8
Hình 2.1 Luật chuyển đồ thị ba và bước chuyển với luật chuyển tiến ............... 14
Hình 2.2 : Mơ hình khái niệm bên trái tương ứng với mơ hình thiết kế bên phải ....... 15
Hình 2.3: Chuyển đổi dưới dạng biểu đồ như một metamodel .......................... 15
Hình 2.4: Luật chuyển ba addAssociation tích hợp OCL ................................... 17
Hình 2.5: Ví dụ điều kiện áp dụng OCL ............................................................. 18
Hình 2.6: Ví dụ việc áp dụng điều kiện OCL cho luật ba ................................... 19
Hình 2.7 : Luật chuyển ba và dẫn xuất luật chuyển ba ....................................... 21
Hình 3.1 Metamodel của biểu đồ hoạt động UML [5] ....................................... 27
Hình 3.2: Ví dụ một biểu đồ hoạt động............................................................... 27

Hình 3.3: Biểu đồ hoạt động UML biểu diễn trên USE...................................... 28
Hình 3.4: Metamodel của CSP[5] ....................................................................... 29
Hình 3.5: Luật trafoInitialNode........................................................................... 31
Hình 3.6 Luật trafoFinalNode ............................................................................. 32
Hình 3.7 Luật trafoActionNode .......................................................................... 33
Hình 3.8 Luật trafoDecisionNode ....................................................................... 34
Hình 3.9 Luật trafoForkNode .............................................................................. 35
Hình 3.10 Luật trafoMergeNode ......................................................................... 36
Hình 3.11 Luật trafoJoinNode............................................................................. 37
Hình 3.12 Ví dụ chuyển mơ hình từ biểu đồ hoạt động UML sang CSP ........... 39

iv


MỞ ĐẦU
Các hệ thống phần mềm ứng dụng hiện đang phát triển rất nhanh và ngày
càng phức tạp đòi hỏi chúng ta phải có các phương pháp để cải thiện tốc độ phát
triển và chất lượng của ứng dụng đó. Một trong những hướng tiếp cận đang rất
được quan tâm trong phát triển phần mềm là phát triển hướng mô hình(MDD).
Đã có nhiều phương pháp phát triển dựa trên hướng tiếp cận này như AGG,
ATL, QVT[10]. Mỗi phương pháp đều đưa ra đề xuất xây dựng ứng dụng dựa
trên những góc nhìn khác nhau của hệ thống dưới dạng mơ hình. Để xây dựng
ứng dụng một cách nhanh chóng và chính xác khi áp dụng phương pháp MDD,
một điều quan trọng cần phải có là kiểm tra tính hợp lệ của mơ hình. Những mơ
hình chính xác, chặt chẽ là điều kiện cần cho các bước xây dựng ứng dụng theo
hướng mơ hình hóa. Vì vậy, khi xây dựng mơ hình cần có cơ chế kiểm tra các
ràng buộc mà mơ hình phải tn theo. Những ràng buộc này được biểu diễn
bằng ngôn ngữ ràng buộc đối tượng OCL.
Trong phạm vi của luận văn, chúng tơi nghiên cứu và trình bày một
phương pháp phát triển cụ thể là văn phạm đồ thị ba(TGG), nghiên cứu về ngơn

ngữ chuyển mơ hình RTL [3], [4]. Sau khi đưa nghiên cứu về RTL chúng tơi
xây dựng các luật chuyển trong bài tốn chuyển từ biểu đồ hoạt động UML sang
đại số tiến trình CSP dựa trên công cụ USE. Trên cơ sở các luật chuyển đã được
xây dựng chúng tôi áp dụng luật chuyển đó cho một ví dụ cụ thể để chuyển đổi
mơ hình biểu đồ hoạt động UML sang CSP[5]. USE được sử dụng làm cơng cụ
kiểm chứng mơ hình chuyển đổi trên.
Cấu trúc của luận văn được tổ chức như sau:
- Chương 1: Cơ sở lý thuyết cho chuyển mô hình. Chương này giới thiệu
chung về phát triển hướng mơ hình và tổng quan về chuyển mơ hình.
- Chương 2: Ngơn ngữ chuyển mơ hình RTL. Trong đó tập chung vào
nghiên cứu cơ sở hình thức cho RTL gồm: kiến thức cơ sở về văn phạm đồ thị
ba, luật chuyển TGG ràng buộc OCL. Từ đó nghiên cứu về cú pháp của RTL và
công cụ USE hỗ trợ RTL.
- Chương 3: Thực nghiệm chuyển mơ hình với RTL. Trên cơ sở nghiên
cứu ngôn ngữ RTL, chúng tôi xây dựng bài toán chuyển từ biểu đồ hoạt động
UML sang đại số tiến trình CSP bằng việc xây dựng các luật chuyển và áp dụng
vào một ví dụ cụ thể.

1


Chương I
Cơ sở lý thuyết cho chuyển mơ hình
Chương này giới thiệu về mơ hình, ưu điểm của việc phát triển hướng mơ
hình và lý thuyết cho chuyển mơ hình. Giới thiệu một số ngơn ngữ chuyển mơ
hình phần mềm .
1.1 Phát triển hướng mơ hình
Phát triển hướng mơ hình (MDD) là hướng tiếp cận xem xét việc xây
dựng chương trình là hoạt động chuyển đổi từ mơ hình này sang mơ hình khác.
Ở hướng tiếp cận đối tượng, tất cả đều quy về đối tượng. Còn ở hướng tiếp cận

MDD thì tất cả đều quy về mơ hình. Một số ưu điểm trong phát triển hướng mơ
hình [10]:
- Phát triển phần mềm nhanh hơn: Trong MDD các mơ hình của một ứng
dụng phần mềm được xác định trên một mức độ trừu tượng cao hơn so với các
ngôn ngữ lập trình truyền thống. Mơ hình này tự động chuyển đổi thành một
ứng dụng phần mềm làm việc bằng cách tạo ra mã hoặc biên dịch /thực thi mơ
hình. Khi mơ hình được sử dụng trên một mức độ trừu tượng cao sẽ nhanh hơn
nhiều so với cùng một mô hình thể hiện trong mã. Nói cách khác: mỗi phần tử
trong mơ hình đại diện cho nhiều dịng mã. Do đó, có thể xây dựng nhiều chức
năng hơn trong cùng một thời gian.
- Chi phí-hiệu quả hơn: MDD có chi phí và hiệu quả hơn. Lý do đầu tiên
đó là MDD thực hiện nhanh hơn do đó sẽ đưa ra thị trường nhanh hơn. Lý do
thứ hai là có thể làm với chi phí thấp hơn. Điều này tất nhiên phụ thuộc vào chi
phí học các phương pháp tiếp cận MDD và các chi phí để phát triển hoặc mua
các cơng cụ. Nó cũng phụ thuộc vào mơ hình kinh doanh. Thay đổi và duy trì
các ứng dụng xây dựng bằng cách sử dụng một cách tiếp cận MDD cũng là hiệu
quả chi phí. Nó là dễ dàng hơn để hiểu được hành vi của một ứng dụng bằng
cách đọc các mơ hình cao cấp. Ngồi ra nó là nhanh hơn để thêm chức năng
hoặc thay đổi chức năng hiện có bằng cách sử dụng một ngơn ngữ cấp cao.
- Tăng chất lượng phần mềm: Một phần mềm ứng dụng được quy định
cụ thể trong một mơ hình cấp cao được thực hiện bởi một cơ cấu hoặc chuyển
đổi thành mã, chất lượng (kỹ thuật) của ứng dụng phụ thuộc vào cấu trúc sinh ra.
Do đó, chất lượng có thể tăng lên rất nhiều bởi vì chúng ta có thể phát triển bởi
những người tốt nhất . Hơn nữa, tất cả các thực hành tốt nhất tìm hiểu sẽ được
2


áp dụng cho các dự án xây dựng bằng cách sử dụng công cụ MDD. Trong
trường hợp mua một công cụ MDD, nó có thể chứa các thực thi tốt nhất bởi vì
nó được xây dựng dựa trên kiến thức của tất cả các dự án xây dựng bởi công cụ

MDD trong quá khứ.
- Ít bị lỗi hơn: Việc kiểm thử phần mềm sẽ tốn rất nhiều thời gian và
chuyên mơn. MDD đảm bảo rằng bạn có thể tập trung vào kiểm tra các chức
năng của ứng dụng, tức là chấp nhận thử nghiệm. Vấn đề kỹ thuật đã được đảm
bảo bằng cách thử nghiệm các cơng cụ MDD, ví dụ về các vấn đề cơ sở hạ tầng
có liên quan hoặc các lỗ hổng bảo mật trong công nghệ.
- Kiểm chứng có ý nghĩa: Ngay cả các chức năng chính nó là ít bị lỗi khi
sử dụng một cách tiếp cận MDD, bởi vì kiểm chứng thực có ý nghĩa có thể được
thực hiện trên các mơ hình cao cấp. Khi sử dụng các ngơn ngữ lập trình truyền
thống, bạn sẽ có một số cú pháp kiểm tra trong IDE của bạn và thậm chí có thể
phân tích một số mã tĩnh. Tuy nhiên, do tính phổ quát của các ngơn ngữ lập trình
này khơng thực sự giúp bạn tránh các lỗi chức năng. Khi sử dụng một cách tiếp
cận MDD xác nhận tên miền cụ thể có thể được thực hiện tại thời điểm thiết kế.
- Biểu diễn hệ thống bằng tri thức miền : MDD thi hành một sự tách biệt
các mối quan tâm và kỹ năng. Chun gia miền có thể tập trung vào việc mơ
hình hóa các miền, trong khi chuyên viên kỹ thuật tập trung vào xây dựng các
công cụ cần thiết cho MDD. Xây dựng các ứng dụng phức tạp không chỉ cho lập
trình tốt nữa. MDD có thể giới thiệu các ký hiệu thích hợp (ví dụ như văn bản,
đồ họa, bảng) để trao quyền cho các chuyên gia tên miền.
- Lập trình tiên tiến cho phép tập trung trên các cơng cụ cứng: với
MDD, các nhà phát triển tiên tiến làm cơng việc ít lặp đi lặp lại. Họ có thể tập
trung vào các khía cạnh sáng tạo của cơng việc của họ. Ví dụ, họ có thể tập
trung vào việc xây dựng các cơng cụ MDD. Họ cũng có thể cố vấn các nhà
phát triển cơ sở hoặc chuyên gia tên miền, hoặc họ có thể chọn các phần cứng
xây dựng ứng dụng.
- Cầu nối khoảng cách giữa công nghệ và công nghệ thông tin(CNTT):
Liên kết kinh doanh-IT là một vấn đề khi nói về xây dựng phần mềm. MDD có
thể mang lại cho kinh doanh và CNTT gần nhau hơn trong các cách sau: thứ
nhất, chuyên gia miền (hoặc các nhà phân tích kinh doanh) trực tiếp tham gia
trong quá trình phát triển. Thứ hai, CNTT (một ứng dụng phần mềm) được xác

định trên một mức độ cao hơn nhiều. Các mơ hình này càng nhiều càng có thể
khai báo và định nghĩa trong các khái niệm miền. Thứ ba, MDD phát triển
3


nhanh hơn phần mềm có thể được xây dựng trong các lần lặp lại ngắn hơn và do
đó có phù hợp hơn cho mục đích (do thơng tin phản hồi nhanh chóng của các
doanh nghiệp, người dùng cuối cùng). Thứ tư, việc xác định các biến đổi rõ ràng
giữa một mơ hình của một tổ chức và một mơ hình của một hệ thống CNTT.
- Dễ thích ứng với những thay đổi trong các yêu cầu nghiệp vụ. Một trong
những vấn đề của phát triển phần mềm là yêu cầu kinh doanh thường xuyên thay
đổi nhanh hơn so với các hệ thống phần mềm hỗ trợ. Tuy nhiên, MDD có thể
cung cấp một giải pháp bởi vì nó làm cho phát triển phần mềm nhanh hơn , nó
cũng dẫn đến dễ dàng hơn để thay đổi các ứng dụng.
- Dễ thích ứng với những thay đổi trong cơng nghệ. Thay đổi công nghệ
theo nhau nhanh hơn và nhanh hơn. Hãy suy nghĩ về những điều như Java EE,
SOA / soba, webservices, REST, SCA, OSGi, và gần đây hạn chế trong cơng
nghệ khi ứng dụng điện tốn đám mây (ví dụ như cấu trúc cơ sở dữ liệu ). MDD
đảm bảo bạn khơng phải thay đổi mơ hình ứng dụng của bạn khi bạn muốn di
chuyển ứng dụng của bạn với các công nghệ khác. Điều duy nhất mà cần phải
thay đổi là bộ tạo (hoặc bộ thông dịch). Sau khi thay đổi các mã bộ tạo (hoặc
thêm các tùy chọn mã bổ sung ) tất cả các mơ hình ứng dụng trực tiếp có thể
được chuyển đổi thành mã cho công nghệ mới.
- Thực sự thực thi kiến trúc: Các công ty thường xác định các nguyên tắc
kiến trúc. Ứng dụng phần mềm phải tuân thủ những nguyên tắc này, nhưng làm
thế nào để kiểm tra hoặc thi hành tuân thủ khi tất cả các mã được tạo ra bằng tay?
Khi sử dụng MDD ứng dụng phần mềm được đảm bảo thực hiện đúng với kiến
trúc được lựa chọn. Bạn thực sự có thể chuẩn hóa IT của bạn bởi vì ngun tắc
kiến trúc được thực thi trong các cơng cụ MDD
1.1.1 Khái niệm về mơ hình

Để hiểu rõ hơn về MDD, sau đây sẽ đưa ra một số khái niệm trong MDD
như [3], [10]:
- Model: mơ hình là cách biểu diễn hệ thống được đơn giản giúp hiểu hơn
về hệ thống. Mơ hình thường được diễn đạt trong một ngôn ngữ đặc tả miền cụ
thể hay ngôn ngữ mô hình hóa chung UML. Mơ hình được biểu diễn bằng ký
hiệu đồ họa.
- Metamodel: Một metamodel của một mơ hình X miêu tả cấu trúc của mơ
hình X theo kiểu hợp lệ. Một metamodel có thể được so sánh với cú pháp trong
thiết kế ngôn ngữ. Metamodel được đinh nghĩa chính xác như là điều kiện tiên
quyết cho chuyển mơ hình.
4


Hình 1.1: Ví dụ về hệ thống phân cấp metamodel bốn lớp của UML[3]
- Metametamodel: một metametamodel của mơ hình X là metamodel
được sử dụng để miêu tả metamodel của model X. Nó có thể được so sánh với
ngữ pháp của một ngôn ngữ, cái mà được sử dụng để miêu tả ngữ pháp của ngôn
ngữ X. Nền tảng được thiết lập tốt và tiêu chuẩn cho việc metametamodel tồn tại
như MOF hay Ecore. MOF là một chuẩn của OMG cho việc định nghĩa
metamodel. MOF có hai phiên bản: Complete MOF(CMOF) và Essential MOF
(EMOF). Một cài đặt của EMOF được sử dụng phổ biến là Ecore, định nghĩa
bởi Eclipse Modeling Framework (EMF)
Ví dụ trong hình 1.1 chúng ta có các cấp độ của model. Mức M0 là cấp độ
dữ liệu người dung, M1 là mơ hình dữ liệu ở cấp độ M0. Cấp M2 là mơ hình cấp
trên của M1, do đó thường được gọi là một metamodel. Cấp M3 được tổ chức
một mơ hình thơng tin của M2 và thường được gọi là metametamodel.
1.1.2 Các chuẩn hướng tiếp cận MDD
Hướng tiếp cận MDD vẫn đang được phát triển và được sử dụng rộng rãi
trong ngành công nghiệp phần mềm. Hiện nay có nhiều tổ chức tham gia nghiên
cứu để thành lập một chuẩn riêng như: MDA (Model Driven Architecture) của

tổ chức OMG, MIC (Model Intergrated Computing) của nhóm ISIS đại học
Vanderbilt, SF (Software Factories) của công ty Microsoft, và một số chuẩn
5


khác. Trong các chuẩn đó, MDA của OMG được cơng bố rộng rãi, phát triển rất
mạnh trong giới nghiên cứu. Hơn nữa còn được ứng dụng để tạo ra rất nhiều
cơng cụ hỗ trợ trong q trình xây dựng phần mềm, các công cụ này được phát
triển rất nhanh trên môi trường Eclipse [10].
1.1.3 Kiến trúc MDA
MDA do tổ chức OMG đề xuất năm 2000. MDA là một hướng tiếp cận
xem việc xây dựng phần mềm là việc chuyển đổi từ mơ hình này sang mơ hình
khác. MDA được đề xuất bắt nguồn từ nhu cầu tồn tại rất lâu là: làm rõ và đặc tả
các tác vụ hệ thống, cái nào phụ thuộc vào nền tảng, cái nào không phụ thuộc
nền tảng, đồng thời chia ra các mức độ phụ thuộc vào nền tảng. MDA cung cấp
một tập các nguyên tắc chỉ dẫn việc xây dựng, đặc tả cấu trúc hệ thống được
biểu diễn như là các mơ hình. Các mơ hình sau đó được sinh bán tự động từ mã
nguồn có khả năng thực thi bởi máy chuyển mơ hình. MDA dựa trên cách sử
dụng có hệ thống các mơ hình như là những tác tử kỹ nghệ sơ cấp. Các mơ hình
được xem như là các lớp thực thể, thay thế mã nguồn. Mã nguồn được sinh ra từ
các mơ hình, từ bộ khung phát triển tới những sản phẩm hồn thiện có thể triển
khai được. Khi đó, người phát triển chỉ tập trung tới vấn đề (tức là các mơ hình)
mà khơng cần quan tâm tới nền tảng cài đặt cụ thể. Ở đây nền tảng có thể là
ngơn ngữ cài đặt như Java, PHP… hoặc là các công nghệ như JSF, Spring…
được áp dụng. Sự phức tạp của nền tảng cũng là lý do cho thấy phát triển hướng
mơ hình rất hiệu quả, có tính mềm dẻo, và khả năng khả chuyển cao. Cũng vì lí
do đó, MDA được phát triển mạnh mẽ trong giới nghiên cứu và cũng được nhiều
công cụ hỗ trợ trong quá trình xây dựng phần mềm[10].
Hướng tiếp cận MDA định hướng các công cụ hỗ trợ xây dựng phải đạt
được: Thứ nhất, xác định phần độc lập giữa hệ thống và nền tảng; thứ hai, xác

định phần phụ thuộc nền tảng; thứ ba, chọn nền tảng chuyên biệt mà hệ thống
phù hợp; thứ tư, chuyển hệ thống từ đặc tả trên nền tảng này sang đặc tả trên nền
tảng khác.
Trong kiến trúc hướng mơ hình MDA, các loại mơ hình sau được sử dụng:
Mơ hình độc lập tính tốn(CIM), mơ hình độc lập nền (Platform Independent
Model), và mơ hình phụ thuộc nền (Platform Specific Model). Ba mơ hình này
biểu diễn các cách nhìn hệ thống từ các khía cạnh khác nhau của hệ thống và
mức độ trừu tượng tương ứng với các giai đoạn phân tích, thiết kế và triển khai
trong kỹ nghệ phần mềm.
6


- Mơ hình độc lập tính tốn (CIM): u cầu của hệ thống được mơ hình
hóa trong mơ hình độc lập tính tốn, CIM miêu tả ngữ cảnh mà hệ thống sẽ sử
dụng. Nó có thể ẩn đi nhiều hoặc tất cả thông tin về việc làm thế nào dữ liệu
được xử lý trong hệ thống. Có thể gọi mơ hình độc lập tính tốn là mơ hình phân
tích, mơ hình miền hoặc mơ hình nghiệp vụ, phụ thuộc vào ngữ cảnh mà chúng
ta sử dụng cho phù hợp.
CIM là mơ hình của một hệ thống để thể hiện vị trí, vai trị của hệ thống
trong mơi trường sẽ triển khai nó. Nó giúp chúng ta biểu diễn chính xác những
gì mà chúng ta hi vọng hệ thống sẽ thực hiện được. Điều này thật sự hữu ích,
khơng chỉ nhằm hiểu được vấn đề chung của hệ thống mà còn giúp chúng ta có
thêm một nguồn thơng tin cho việc xây dựng những mơ hình khác của hệ thống
một cách đúng đắn.
CIM đóng vai trị quan trọng trong việc lấp khoảng trống giữa những
chuyên gia phân tích trên miền cụ thể, những chuyên gia thiết kế, triển khai hay
bảo trì. Giúp chúng ta có thể xây dựng ứng dụng đáp ứng các u cầu trên
những miền cụ thể
- Mơ hình độc lập nền (PIM): là mơ hình độc lập với các đặc điểm của
nền tảng. Nó miêu tả hệ thống mà khơng nêu rõ nó được sử dụng cho nền tảng

nào. Một mơ hình độc lập nền sẽ phù hợp cho các kiểu kiến trúc đặc biệt. PIM
có thể được sử dụng cho công nghệ máy ảo, một loại nền tảng chung hay các
nền tảng trừu tượng.
- Mơ hình phụ thuộc nền (PSM): được xây dựng cho một nền tảng cụ thể.
Nó có nguồn gốc từ một mơ hình độc lập nền tảng cộng thêm một số thông tin
liên quan. Do đó kết hợp được các đặc điểm của kỹ thuật nền tảng độc lập với
chi tiết nền tảng cụ thể. Tuy theo mục đích sử dụng. PSM có thể cung cấp ít hay
nhiều thơng tin chi tiết cần thiết cho việc tự động sinh ra các thành phần triển
khai của hệ thống từ mơ hình thì đó là một mơ hình phụ thuộc nền tảng triển
khai.
1.2 Tổng quan về chuyển mơ hình
Trong phát triển hướng mơ hình một chuỗi các mơ hình được tạo ra và
duy trì. Mơ hình biểu diễn các giai đoạn khác nhau của tiến trình phát triển.
Thêm nữa, mơ hình có thể thể hiện các khung nhìn khác nhau của hệ thống và
biểu diễn các cấp trừu tượng khác nhau của hệ thống.
Chuyển mơ hình là một khái niệm trọng tâm trong lĩnh vực phát triển
hướng mơ hình. Chuyển mơ hình cung cấp một cơ chế cho việc tự động tạo ra
7


và cập nhật các mơ hình đích dựa trên thơng tin chứa trên mơ hình nguồn. Khi
sự chuyển mơ hình được định nghĩa chính xác, nó có thể được sử dụng để đảm
bảo sự nhất qn giữa các mơ hình khác nhau. Hiện nay tồn tại nhiều công nghệ
chuyển mô hình, các loại có sự khác nhau giữa miền vấn đề, chẳng hạn đặc thù
của vấn đề được giải quyết bởi cơng nghệ chuyển mơ hình và cơ chế, chẳng hạn
đặc thù của ngơn ngữ chuyển mơ hình. Có 2 kiểu chuyển: Chuyển từ mơ hình
sang text (M2T) và chuyển mơ hình sang mơ hình (M2M)
1.2.1 Các thuật ngữ trong chuyển mơ hình
Sau đây là các thuật ngữ cơ bản về chuyển mơ hình [10]:
- Ngơn ngữ chuyển mơ hình: là một tập từ vựng và một ngữ pháp được

định nghĩa ngữ nghĩa tốt cho khả năng chuyển mơ hình.
- Luật chuyển mơ hình: Một luật chuyển mơ hình trong mô tả là một thực
thể nhỏ nhất trong chuyển mô hình. Nó miêu tả cách một phần mơ hình nguồn
có thể được chuyển tới phần mơ hình đích. Một luật chứa một mẫu nguồn và
một mẫu đích. Đối với mỗi phần xuất hiện của mẫu nguồn trong mơ hình nguồn
tương ứng một mẫu đích được tạo trong mơ hình đích. Trong ngữ cảnh chuyển
mơ hình dựa trên đồ thị thì mẫu nguồn được gọi là phần bên trái (LHS) và mẫu
đích gọi là phần bên phải (RHS)
- Mơ hình nguồn: trong ngữ cảnh của một chuyển mơ hình, một mơ hình
có thể đóng vai trị như là mơ hình nguồn, nếu nó là đầu vào của bước chuyển.
Mơ hình nguồn tuân thủ metamodel nguồn. Có thể có một hoặc nhiều hơn mơ
hình nguồn là đầu vào của bước chuyển.
- Mơ hình đích: trong ngữ cảnh của chuyển mơ hình, một mơ hình có thể
đóng vai trị như là mơ hình đích, nếu nó là đầu ra của bước chuyển mơ hình.
Mơ hình đích phải tn thủ metamodel đích. Một phép chuyển mơ hình có thẻ
có một hoặc nhiều mơ hình đích.

Hình 1.2 Mơ hình mối quan hệ ở mức metamodel
8


1.2.2 Một số giải pháp sử dụng ngôn ngữ chuyển
Sau đây chúng tôi giới thiệu một số ngôn ngữ và công cụ chuyển được
quan tâm rộng rãi trong cộng đồng nghiên cứu cũng như trong công nghiệp.
Giải pháp sử dụng AGG (Algebraic Graph Transformation)[10]
AGG là ngơn ngữ chuyển mơ hình theo kiểu đại số. AGG bao gồm tập
hợp các đối tượng Node và Edge. Các Node liên kết với nhau thông qua Edge.
AGG bao gồm các lớp trung gian giữa hai mơ hình nguồn và đích. Mỗi lớp trung
gian này là một sự tương ứng giữa một đối tượng của mơ hình nguồn và một đối
tượng của mơ hình đích. Mỗi đối tượng có một định danh phục vụ cho chuyển

đổi tương ứng giữa mơ hình nguồn và đích. Ngồi ra, đối tượng trong AGG có
thể có thuộc tính, kiểu thuộc tính, bao gồm ràng buộc về số lượng đối tượng có
thể liên kết với nhau.
AGG dựa trên cơ sở chặt chẽ về tốn học, đồng thời có khả năng kiểm
tra ràng buộc OCL trên mơ hình nguồn và mơ hình đích. Vì vậy, thường cho
ra mơ hình đích chính xác. Tuy nhiên, AGG gặp phải hạn chế lớn về vấn đề
đặc tả, ngơn ngữ biểu diễn mơ hình. Vì vậy, rất khó để có thể áp dụng AGG
trong thực tế.
Giải pháp sử dụng ATL (ATLAS Transformation Language)[7]
ATL là một ngơn ngữ chuyển mơ hình tới mơ hình. ATL chỉ hỗ trợ
phép chuyển mơ hình theo một hướng. Một chương trình chuyển ATL bao
gồm các luật chuyển mơ tả cách tạo ra các phần tử của mơ hình đích. Ngơn
ngữ được đặc tả như là metamodel và cú pháp cụ thể dưới dạng ký tự. ATL
được tích hợp trong mơi trường phát triển Eclipse và có thể làm việc với các
mơ hình dựa trên EMF. Mã nguồn ATL được biên dịch và sau đó được chạy
trên máy chuyển mơ hình.
Query/View/Transformation (QVT)[3]
Query/View/Transformation (QVT) là một ngơn ngữ chuẩn cho chuyển
mơ hình được tạo bởi OMG. QVT sử dụng ngôn ngữ ràng buộc đối tượng
(OCL), MOF và được căn chỉnh theo kiến trúc hướng mơ hình MDA. QVT
đúng như theo tên nó cho phép chuyển mơ hình (transformation), biểu diễn mơ
hình (view) và truy vấn (query). Truy vấn mơ hình và biểu diễn mơ hình có thể
được xem như là loại đặc biệt của chuyển mơ hình. QVT cũng được tích hợp
trong môi trường phát triển Eclipse.
QVT định nghĩa ba ngôn ngữ cho chuyển mơ hình tới mơ hình (M2M).
Tất cả chúng hoạt động tren mơ hình tn thủ MOF 2.0 metamodels.
9


- QVT Relational : là một ngôn ngữ chuyển mô hình sơ khai. Cả cú pháp

dạng ký tự và dạng đồ họa được định nghĩa cho QVT. Ngôn ngữ này hỗ trợ
chuyển mơ hình hai chiều. Một phép chuyển được đặc tả như là một tập các
quan hệ giữa metamodel nguồn và metamodel đích. Phép chuyển này có thể
được sử dụng để kiểm tra tính hợp lệ của hai mơ hình.
- QVT Core : là ngơn ngữ chuyển mơ hình khai báo cấp thấp, là nền tảng
cho ngôn ngữ QVT Relational.
- QVT Operatinal : là ngôn ngữ chuyển đổi mệnh lệnh (imperative) được
thiết kế cho việc phép chuyển theo một hướng duy nhất.
1.3 Tổng kết chương
Như vậy trong chương này chúng tơi đã nêu rõ vai trị của phát triển
hướng mơ hình, các khái niệm về mơ hình như model, metamodel…, các chuẩn
tiếp cận hướng mơ hình. Ngồi ra cịn nghiên cứu tổng quan về chuyển mơ hình
như: các thuật ngữ trong chuyển mơ hình, một số giải pháp sử dụng ngơn ngữ
chuyển mơ hình AGG, ATL, QVT. Trên cơ sở đó để rút ra những ưu điểm và
hạn chế của các phương pháp chuyển mơ hình trên từ đó nghiên cứu ngơn ngữ
chuyển mơ hình RTL trong phần tiếp theo.

10


Chương II
Ngơn ngữ chuyển mơ hình RTL
Trong phần này chúng tơi sẽ nghiên cứu và cơ sở hình thức cho RTL như:
kiến thức cơ sở về văn phạm đồ thị ba, luật chuyển của văn phạm đồ thị ba ràng
buộc OCL từ đó để xác định cú pháp của RTL.
2.1. Cơ sở hình thức cho RTL
Chuyển đổi mơ hình có thể được xem như là trung tâm của phương pháp
tiếp cận hướng mơ hình, chẳng hạn như phương pháp tiếp cận mơ hình trung
tâm phát triển phần mềm (giống như các phương pháp tiếp cận dựa trên UML)
và mơ hình hướng công nghệ (MDE). Trong phương pháp tiếp cận, đồ thị là một

đại diện tất nhiên cho các mơ hình từ khi hầu hết các ngơn ngữ mơ hình được
hình thức hóa bởi một khung nhìn cú pháp trừu tượng xác định. Trong ngữ cảnh
chuyển đổi đồ thị này là một cách tiếp cận đầy triển vọng cho chuyển đổi mơ
hình, đặc biệt là đối với những chuyển đổi phức tạp. Ưu điểm của phương pháp
tiếp cận này là các luật chuyển đổi đồ thị có thể tạo dễ dàngvà được đặc tả bằng
trực giác. Ngoài ra, sự phức tạp của luật chuyển đổi đồ thị cũng như hình thức
áp dụng có thể được ẩn đối người dùng.
Chuyển đồ thị là một cơ chế để xác định và áp dụng các biến đổi
giữa các đồ thị cái gọi là luật viết lại đồ thị ( luật chuyển đổi đồ thị ). Đồ thị viết
lại là một phần mở rộng của kỹ thuật viết lại trong ngữ pháp Chomsky. Một luật
đồ thị chuyển đổi bao gồm hai đồ thị tương ứng bên trái (LHS)và phía bên phải
(RHS) của luật này. Đối với mỗi luật tương ứng, các nút và cạnh trong LHS
được kết hợp với các nút và các cạnh nhất định trong đồ thị ban đầu. Sau đó, các
nút và cạnh phù hợp mà không tồn tại trong RHS được loại bỏ từ đồ thị ban đầu.
Các nút và các cạnh còn lại trong RHS được xem như là mẫu cho việc tạo ra
các nút mới và các cạnh trong đồ thị ban đầu.
Để tăng sự tích hợp của chuyển đổi đồ thị và phương pháp tiếp cận
hướng mơ hình, đồ thị có thể được mở rộng để đồ thị thuộc tính đại diện các mơ
hình . Ở đây, các mơ hình được nhìn thấy như sơ đồ đối tượng (Object diagram
trong UML). Không giống như các phương pháp tiếp cận khác, ở đây nút và các
cạnh của đồ thị thuộc tính là kiểu khác đồ thị thuộc tính (hay gọi là một đồ thị
kiểu – type graph), trong các nút và các cạnh của đồ thị thuộc tính là kiểu của
tổng đại số A Trong cách này kiểu và ngữ nghĩa của đồ thị thuộc tính có thể
11


được xác định dựa trên OCL. Điều này cho phép chúng ta vượt qua khó khăn
với kiểu đồ thị thuộc tính như làm thế nào để giải thích các yếu tố trong tập hợp,
kế thừa trong các metamodel [3], [4], [8].
2.1.1 Kiến thức cơ sở về văn phạm đồ thị ba

Văn phạm đồ thị ba (TGGs) đã được đầu tiên chính thức đề xuất trong [9].
Mục đích của họ là để giảm bớt sự mô tả của biến đổi phức tạp trong
công nghệ phần mềm. TGGs cho phép chúng ta cấu trúc bản đồ văn phạm hai
đồ thị để đồ thị tạo ra văn phạm đồ thị có thể được liên quan với nhau. Việc lập
bản đồ giữa hai văn phạm đồ thị được thực hiện bằng cách chèn thêm một văn
phạm đồ thị để xác định sự tương ứng giữa các yếu tố của chúng. Trong cách
này, luật ba (triple rule) thu được là một thành phần của ba luật đối với văn
phạm đồ thị bên trái, bên phải, và kết nối. Sau đó, nguồn gốc bộ ba (triple) có
thể được xem như là một thành phần tương ứng của luật ba văn phạm đồ thị
trong TGGs. Tích hợp đồ thị thu được bằng bộ ba được gọi là đồ thị ba. Từ một
luật ba, chúng ta có thể lấy được những luật ba mới như tiến(forward),
ngược(backward) mơ hình tích hợp, và mơ hình phát triển. Thơng qua các kịch
bản hoạt động, sự tương ứng giữa các mơ hình nguồn và đích được thành lập.
Để thúc đẩy sự tích hợp của TGGs và phương pháp tiếp cận hướng mơ
hình, chúng ta mở rộng đồ thị ba đến đồ thị thuộc tính ba. Khơng giống như
những kiểu đồ thị thuộc tính ba đang làm việc, phương pháp tiếp cận ở đây các
cạnh và nút của đồ thị thuộc tính ba là kiểu tổng đại số A. Mục tiêu của chúng ta
là đưa ra các diễn giải của OCL. Ngoài ra, cách tiếp cận dựa trên OCL cho phép
chúng ta hạn chế sự tương ứng một phần của luật ba bởi các điều kiện OCL.
Văn phạm đồ thị ba (TGG) là sự mở rộng của chuyển đổi đồ thị để cung
cấp khả năng mô tả các chuyển đổi phức tạp trong công nghệ phần mềm.
Phương pháp đặc tả này cho phép khai báo các chuyển hai chiều giữa các ngôn
ngữ đồ thị khác nhau.
Cụ thể, TGG cho phép chúng ta thiết lập tương ứng giữa hai đồ thị thuộc
văn phạm nguồn và đích bằng cách chèn thêm một văn phạm để liên hệ hai văn
phạm đó. Trong cách này, luật chuyển đồ thị ba thu được gồm 3 thành phần: luật
vế phải, luật vế trái, và luật kết nối. Đồ thị tích hợp thu được bằng dẫn xuất luật
đồ thị ba được gọi là đồ thị ba [3].
- Định nghĩa 1 (Đồ thị, ánh xạ đồ thị): Đồ thị G =(GV ,GE, sG, tG), GV
là các đỉnh, GE là các cạnh, các hàm sG, sT: GE → GV xác định định nguồn và

đích của một cạnh. Cho đồ thị G, H có ánh xạ đồ thị f= (fV, fE): G→H gồm có
12


hai ánh xạ fV: GV→GE và fE: GE→HE là tương ứng định và cạnh trong đó
fVo sG=sH o fE và fV o tG = tH o fE.
- Định nghĩa 2: Bộ (G, typeG) của đồ thị G=(V,E,s,t) cùng với đồ thị ánh
xạ typeG: G→ TG, ở đây TG được gọi là đồ thị kiểu và G là một thể hiện của
TG. Cho đồ thị G= (G, typeG) và H=(H, typeH), f là đồ thị ánh xạ giữa G và H
khi f: G→ H và typeH o f = typeG.
- Định nghĩa 3 (Đồ thị ba, ánh xạ đồ thị ba): Ba đồ thị SG, CG, TG lần
lượt là đồ thị nguồn, đồ thị đích, đồ thị kết nối, cùng với hai đồ thị ánh xạ sG:
CG → SG và tG : CG → TG tạo thành đồ thị ba G =(SG sG← CG →tG TG) . G
gọi là rỗng nếu, SG, CG và TG là đồ thị rỗng. Đồ thị ánh xạ ba m= (s,c,t): G->H
giữa hai đồ thị triple G = (SG sG← CG →tG TG) và H = (SH sH← CH →tH TH)
gồm có ba đồ thị ánh xạ s : SG → SH, c : CG → CH và t : TG → TH trong đó s
◦ sG = sH ◦ c và t ◦ tG = tH ◦ c
- Định nghĩa 4 (Văn phạm đồ thị ba): Luật chuyển ba tr = L →tr R bao
gồm đồ thị ba L và R và ánh xạ ba tr sao cho

Cho luật chuyển ba tr = (s, c, t) : L → R, đồ thị triple G và ánh xạ ba m =
(sm, cm, tm): L → G, gọi là khớp ba m, các bước chuyển đổi đồ thị triple G
⇒tr,m H từ G tới đồ thị triple H được cho bởi ba đổi tượng SH, CH và TH trong
loại đồ thị bao gồm ánh xạ sH : CH → SH và tH : CH → TH. Ánh xạ n = (sn,
cn, tn) được gọi là comatch.

Văn phạm đồ thị ba là cấu trúc TGG= (TG, S, TR), trong đó TG là đồ thị
kiểu, S là đồ thị khởi đầu và TR={tr1,tr2, tr3, ….., trn} là tập các luật chuyển ba.
 Phương pháp chuyển mơ hình dựa vào văn phạm đồ thị ba: Mơ hình
trong tiếp cận của được xem là các đồ thị. Để biểu diễn mô hình nguồn, đích và

sự kết nối giữa chúng, chúng ta sử dụng văn phạm đồ thị ba. Từ một luật chuyển
13


đồ thị ba chúng ta có thể dẫn xuất thành các luật cho chuyển mơ hình tiến
(nguồn sang đích), ngược (đích sang nguồn) và tích hợp.
- Định nghĩa 5 (Các luật dẫn xuất): Mỗi luật chuyển ba tr = L→R dẫn
xuất ra các luật chuyển tiến, ngược và tích hợp được xác định như sau:

Hình 2.1 Luật chuyển đồ thị ba và bước chuyển với luật chuyển tiến
- Định lý 1. (Chuyển với các luật dẫn xuất): Cho TGG = (TG, S, TR) là
văn phạm đồ thị ba và G =(Gs ← SC → ST) là đồ thị ba định kiểu bởi TG. Một
chuyển tiến từ đồ thị nguồn GS sang đồ thị đích GT khi các điều kiện sau thỏa
mãn:
với mi là các khớp ba,
trong đó (sni, cni, tni)
là các comatch của mi.
2.1.2 Luật chuyển TGGs ràng buộc OCL
Ý tưởng cơ bản cho việc tích hợp TGGs và OCL[3]
Phần này giải thích ý tưởng cơ bản phương pháp tiếp cận bằng một ví dụ
cụ thể. Chúng ta xem xét một tình huống điển hình trong phát triển phần mềm, ở
đây muốn nói đến mối quan hệ giữa mơ hình khái niệm và một mơ hình thiết
kế. Hình 2.2 cho thấy sự tương ứng giữa một liên kết đầu ở bên trái
trong một mơ hình khái niệm với một thuộc tính và hoạt động bên phải
14


bên trong một mơ hình thiết kế. Ví dụ, chúng ta nhận ra rằng sự liên kết đầu
customer được ánh xạ tới các thuộc tính customer và hành động GetCustomer()
của lớp Order

Hình 2.2 : Mơ hình khái niệm bên trái tương ứng với mơ hình thiết kế bên phải
Chúng ta muốn thể hiện yêu cầu đó, khi chúng ta thêm một mối liên hệ
giữa customer và Order trong mơ hình khái niệm, các lớp tương ứng trong mơ
hình thiết kế sẽ tự động được mở rộng với các thuộc tính mới và hàng động mới.
Vì vậy, sự tương ứng giữa liên kết đầy trong mơ hình với các thuộc tính và hoạt
động trong mơ hình thiết kế đã được hình thành một cách chính thức.

Hình 2.3: Chuyển đổi dưới dạng biểu đồ như một metamodel
Kịch bản này là chuyển đổi mơ hình giữa các sơ đồ lớp UML và QVT
cũng như TGGs có thể tiếp cận các u cầu. Hình 2.3 cho thấy chuyển đổi dưới
dạng biểu đồ như một metamodel. Phía bên trái cho thấy các metamodel cho
các domain khái niệm, phía bên phải hiển thị các metamodel cho domain thiết
kế và phần giữa là kết nối tương ứng giữa chúng. Sau đó chúng ta sẽ thấy, sơ đồ
trong hình. 2.3 có thể được xem như là một biểu đồ thể hiện cho các metamodels
15


với các mũi tên đứt đoạn được biểu diễn như là các đối tượng thuộc các lớp từ
phần giữa. Một luật TGG cũng như các ánh xạ QVT có thể thực hiện một hành
động như có thêm một liên kết, cập nhật các thuộc tính và các hoạt động như
được giải thích dưới đây[3],[6].
a, TGGs và OCL cho ví dụ chuyển đổi
Hình 2.4 cho thấy luật chuyển ba addAssociation tích hợp OCL trong
QVT like style. LHS tương ứng với phần bảo vệ, và RHS tương ứng phần phía
dưới. LHS được bao gồm trong RHS. Ràng buộc OCL luật chuyển ba trong hình
2.4 được thể hiện tương ứng trên đầu và dưới của LHS và RHS. Các ràng buộc
OCL có thể không chỉ được sử dụng để hạn chế các giá trị thuộc tính trong mơ
hình bảo vệ và dưới cùng, nhưng chúng cũng có thể thể hiện thêm những hạn
chế chung về đồ thị như một biểu đồ đối tượng

Luật TGG cổ điển không thể hiện ràng buộc OCL. Cách tiếp cận của ở
đây cho phép thêm ràng buộc OCL trong tất cả các bộ phận và do đó cho phép
một hình thức chung để hạn chế việc áp dụng luật cũng như mô tả kết quả làm
mịn của các ứng dụng luật, để mơ tả cập nhật thuộc tính đối tượng. Biểu thức
OCL chung, có chuyển qua đầy đủ đồ thị mà luật được áp dụng. Đánh giá của
các biểu thức OCL được thực hiện trước khi đồ thị làm việc được sửa đổi bởi
luật. Các luật chuyển ba thể hiện trong hình. 2.4 làm như sau. Khi được áp dụng,
đối tượng Assoc được tạo ra để đại diện cho một liên kết trong miền khái niệm.
Kết quả viết lại đồ thị trong miền thiết kế, tức là, đối tượng attr và các đối tượng
Op đại diện cho các liên kết được tạo ra. Các tương ứng giữa các liên kết, các
thuộc tính mới và hoạt động được thiết lập bởi viết lại đồ thị trong miền tương
ứng. Các ràng buộc OCL cho phép chúng ta kiểm tra khả năng áp dụng của các
luật và cập nhật các giá trị thuộc tính trong miền thiết kế.
b,Yêu cầu để tích hợp OCL trong TGGs
Yêu cầu tích hợp OCL trong TGGs như sau:
• Hỗ trợ cơng thức OCL cho các biểu thức thuộc tính.
• Hỗ trợ OCL tiền (pre) và hậu(post) điều kiện các luật chuyển ba.
• Hỗ trợ ràng buộc về metamodel cho các phần tương ứng của các quy tắc
TGG. Giả sử rằng tất cả các ràng buộc phải được thực hiện từ luật TGG.
Ngồi ra, sự tích hợp của TGGs và OCL yêu cầu biến thể của TGGs. Một
nút trong miền tương ứng có thể được kết nối với nhiều nút trong miền còn lại.
Đây là một biến thể của TGGs vì trong bản gốc TGG ánh xạ chỉ là 1-1. Trong
16


phần mở rộng , luật TGG có thể được xóa, nhưng ngược lại nếu chúng đã định
nghĩa từ ban đầu thì luật TGG là khơng được xóa.

Hình 2.4: Luật chuyển ba addAssociation tích hợp OCL
c, Điều kiện OCL cho luật chuyển ba

Trong phần này, xác định áp dụng điều kiện OCL của luật chuyển ba.
Vì hạn chế trong các phần nguồn và đích, luật chuyển ba là xác định độc lập,
điều kiện áp dụng luật chuyển ba có thể được định nghĩa là một kết hợp điều
kiện trước và sau trong các phần nguồn, đích và kết nối tương ứng của luật
chuyển ba.
- Điều kiện OCL cho các phần nguồn và đích
Điều kiện OCL cho nguồn hoặc đích của luật chuyển ba là áp dụng điều
kiện OCL của một luật đơn giản tương ứng với phần này. Chúng ta có thể sử
dụng điều kiện OCL để hạn chế một số luật , vì một mặt, LHS và RHS của luật
là các đồ thị thuộc tính. Mặt khác, các nút của đồ thị thuộc tính phù hợp với một
mơ hình đối tượng M trùng với các điều khoản OCL. Điều này cho phép chúng
ta sử dụng điều kiện OCL như một ràng buộc trên đồ thị thuộc tính.
Định nghĩa 6. (Ràng buộc OCL trên đồ thị thuộc tính)
Một ràng buộc OCL e trên đồ thị thuộc tính là một thuật ngữ logic OCL
nó có thể được đánh giá trong bất kỳ minh hoạ I(a,b) của đồ thị. Đồ thị (không)

17


thỏa mãn một ràng buộc OCL trong một minh họa nếu đánh giá của ràng buộc
trong hình minh hoạ (sai) là đúng.
Định nghĩa 7. (Điều kiện áp dụng OCL)
Điều kiện áp dụng OCL (BACS) của một luật ràng buộc OCL trên đồ thị
thuộc tính tương ứng với các LHS và RHS của luật. BACS trong LHS và RHS
là điều kiện trước và sau tương ứng của luật này. Hình. 2.5 cho thấy OCL áp
dụng tiền điều kiện cho luật, ví dụ: comp.employee → size ()> 500. Có nghĩa là
luật được áp dụng nếu công ty c: Company sử dụng hơn 500 nhân viên. Hậu
điều kiện OCL p.salary <10.000 có nghĩa là luật được áp dụng một cách chính
xác nếu tiền lương của người p: Person ít hơn 10000.

Hình 2.5: Ví dụ điều kiện áp dụng OCL
- Định nghĩa 8. (Điều kiện áp dụng đầy đủ)
Một luật chuyển đổi với BACs là một bộ r = (L, R; BAC), trong đó BAC
bao gồm các điều kiện áp dụng OCL. Một H đồ thị xuất phát một đồ thị G bằng
một quy tắc r = (L; R; BAC) và một ánh xạ m khi và chỉ khi:
• H có nguồn gốc từ G bằng (L → R; m),
• LHS đáp ứng tất cả các tiền điều kiện trong BAC với phạm vi I (  G ;  m ),
và
• RHS đáp ứng tất cả các hậu điều kiện trong BAC với phạm vị I (  H ;
 r,m ),

Ở đây  G và  H tương ứng là các mô hình bắt nguồn từ G và H;  m là
phần biến của ánh xạ m, và  r,m là phần biến cho RHS từ H trong việc áp dụng
luật.
18


Hình 2.6: Ví dụ việc áp dụng điều kiện OCL cho luật ba
Hình 2.6 mơ tả phần nguồn (SL, SR) và phần đích (TL, TR) , điều kiện
OCL hạn chế cho luật chuyển ba. điều kiện OCL trong SL và TL là áp dụng
phần tiền điều kiện, đảm bảo hai đầu vào biểu thức X và Y không trùng với nhau.
OCL điều kiện trong SR và TR là áp dụng phần hậu điều kiện, quy định cụ thể
tác động của việc áp dụng luật: Hai biểu thức đầu vào là giá trị khơng thay đổi
và thuộc tính các biểu thức mới được xác định.
- Điều kiện OCL cho phần kết nối.
Điều kiện OCL ở phần kết nối của luật chuyển ba bao gồm điều kiện
OCLcho sự kết nối giữa phần nguồn và phần đích và điều kiện OCL cho các luật
đơn giản tương ứng với phần kết nối. Hình 2.6 ví dụ trong (CL, CR) điều kiện
OCL cho phần kết nối của các luật chuyển ba. Điều kiện OCL trong CL là phần
áp dụng tiền điều kiện của luật chuyển ba, hạn chế kết nối giữa biểu thức trong

các mô hình nguồn và đích: Hai thuộc tính cmt phải trùng khớp với nhau. Điều
kiện OCL trong CR là phần áp dụng hậu điều kiện, nêu rõ kết nối giữa các biểu
thức đầu vào là không thay đổi. Điều kiện OCL trong metamodel của phần kết
nối cần phải được trình bày một cách rõ ràng trong các luật chuyển ba khi
metamodel tự động xây dựng từ luật chuyển ba này. Ví dụ, phần kết nối của luật
19


chuyển ba hình 2.4 bao gồm các ràng buộc đối với lớp meta Cm2Dm:
self.classCM.name = self.classDM.name
- Điều kiện áp dụng OCL cho luật chuyển ba
Điều kiện ứng dụng OCL của một quy tắc ba có thể được định nghĩa là
một sự kết hợp điều kiện OCL trong các bộ phận của quy tắc ba. Các điều kiện
OCL được tích hợp vào các phần của luật chuyển đồ thị ba. Mục đích là để tăng
khả năng diễn đạt của luật. Từ một luật chuyển đồ thị ba khi được tích hợp với
các điều kiện OCL, tiền và hậu điều kiện của luật dẫn xuất là hoàn toàn xác định.
- Định nghĩa 9 (Điều kiện áp dụng): Điều kiện áp dụng OCL (BAC) của
luật ba bao gồm các điều kiện OCL trong phần nguồn, đích, kết nối tương ứng
của luật ba. BACs của luật là các tiền và hậu điều kiện của vế trái và vế phải luật
một cách tương ứng:
 BAC pre = BAC SL  BAC CL  BAC TL ,
 BAC post = BAC SR  BAC CR  BAC TR , and
 BAC = [BAC pre ,BAC post ],
ở đây BAC xx với xx  {‘SL’, ‘SR’, ‘CL’, ‘CR’, ‘TL’, ‘TR’} là BAC trong vế
trái và phải của luật nguồn, kết nối và đích. BAC pre và BAC post s là tiền và hậu
điều kiện của luật.
- Định nghĩa 10: Điều kiện áp dụng hoàn chỉnh của luật chuyển ba
Một chuyển đổi luật ba với BACs là một bộ tr = (L, R; BAC), ở đó BAC
bao gồm các điều kiện áp dụng OCL. Một đồ thị ba H nhận được từ một đồ thị
ba G bởi một luật chuyển ba tr =(L, R; BAC) và một ánh xạ ba m khi và chỉ khi:

• H tạo ra từ (L → R ,m) và
• BAC thỏa mãn luật áp dụng G  r H, ở đây r: L → R là một luật đơn
giản, có thể được lấy từ tr bằng cách xem đồ thị ba như đồ thị đơn giản.
d, Điều kiện OCL được dẫn xuất từ luật chuyển ba
Dẫn xuất luật chuyển ba cho phép chúng ta xác định các kịch bản hoạt
động của luật chuyển ba cho chuyển đổi mơ hình . Đối với một chuyển đổi từ
mơ hình nguồn tới mơ hình đích, chúng ta giả định mơ hình nguồn và đích là
một phần của đồ thị ba được tạo TGG. Nói cách khác, chúng ta cần phải xác
định được một đồ thị ba cho chuyển đổi mơ hình. Đồ thị ba có thể được xác
định bằng cách sử dụng dẫn xuất chuyển ba từ đồ thị ba ban đầu (S). Chúng ta
cũng có thể sử dụng luật chuyển ba bắt đầu từ mô hình nguồn để xác định đồ thị
20


ba. Điều này được minh họa trong hình 2.7. Đối với một chuyển đổi từ Hs đến
Ht như thể hiện trong hình 2.7, chúng ta cần xác định đồ thị ba H = (HS ← HC
→ HT) có thể được tạo bởi TGG. Nói cách khác, chúng ta cần phải xác định một
dẫn xuất từ đồ thị ba ban đầu (  ←  →  ) H. Theo cách khác, kết quả đồ thị H
có thể thu được từ dẫn xuất {trFk} ở phía bên tay phải như mơ tả trong hình 2.7.
Dẫn xuất này được xây dựng dẫn xuất luật chuyển ba cho chuyển đổi tiến.

Hình 2.7 : Luật chuyển ba và dẫn xuất luật chuyển ba
Một dẫn xuất với luật chuyển ba, ví dụ như {trFk} ln luôn được xác
định trong mối quan hệ với một dẫn xuất tương ứng với luật chuyển ba ban đầu.
Vì vậy, ACs của dẫn xuất luật chuyển ba cũng được định nghĩa trong một ngữ
cảnh. Đặc biệt, bất cứ khi nào một luật chuyển ba tr được áp dụng trong ánh xạ
m
chuyển ba m, ví dụ:, Gn tr,
H như hình 2.7, một dẫn xuất luật chuyển ba


của luật này là cũng có thể áp dụng tương ứng ánh xạ 3 mF, ví dụ, GFn
trF, mF H trình bày trong hình 2.7. Dựa trên mối quan hệ giữa m và mF, ví dụ

như, trong hình 2.7 (lưu ý rằng G iS ⊂ H S cho i = 1; n), chúng ta có thể xác định
Acs của luật được dẫn xuất như sau.
• BACS trong phần của dẫn xuất luật chuyển ba (trF, trF, hoặc trI)
LHS và RHS không trùng với nhau ở tất cả BACs trong phần kết nối luật
chuyển ba tr
• BACs (cả tiền và hậu điều kiện) trong phần dẫn xuất của luật chuyển
ba(TRF, TRF, hoặc trI), trong đó LHS và RHS trùng khớp với nhau ở tất cả các
BACs trong RHS của phần kết nối của luật chuyển ba tr, ngoại trừ các ràng buộc
OCL với từ khoá '@ pre'. Lưu ý từ khoá '@ pre' được dùng để chỉ trạng thái của
các mục của đồ thị ban đầu trước khi áp dụng một luật. Do đó, các ràng buộc
21


OCL với '@ pre’ không áp dụng khi LHS và RHS của các phần trùng với nhau.
Do đó, tiền và hậu điều kiện của dẫn xuất luật chuyển ba có thể được định nghĩa
như sau.
- Định nghĩa 11. (Tiền và hậu điều kiện của dẫn xuất luật chuyển ba)
Cho luật chuyển ba tr , Tiền điều kiện của dẫn xuất luật chuyển ba tr được định
nghĩa như sau:
tr
tr
tr
• BAC trF
pre = BAC SR*  BAC CL  BAC TL ,
tr
tr
tr

• BAC trB
pre = BAC SL  BAC CL  BAC TR* ,và
tr
• BAC trIpre = BAC trSR*  BAC trCL  BAC TR*
,

Hậu điều kiện của dẫn xuất luật chuyển ba của tr được định nghĩa như sau:
tr
tr
tr
• BAC trF
post = BAC SR*  BAC CR  BAC TR ,
tr
tr
tr
• BAC trB
post = BAC SR  BAC CR  BAC TR* ,và
tr
• BAC trIpost = BAC trSR*  BAC trCR  BAC TR*
,

ở đây
trB
trI
- BAC trF
pre , BAC pre , và BAC pre là tiền điều kiện tương ứng dẫn xuất luật

chuyển ba của chuyển đổi tiến, chuyển đổi ngược và chuyển đổi mơ hình tương
trB
trI

tác; BAC trF
post , BAC post , và BAC post là hậu điều kiện của dẫn xuất luật,

- BAC trxx với xx  {‘SL0; ‘SR0; ‘CL0; ‘CR0; ‘TL0; ‘TR0} là BACs tương
ứng trong LHS và RHS của các phần luật chuyển ba tr
tr
- BAC trSR* , BAC trCR , và BAC TR*
là BACs trong SR, CR và TR không thể ràng

buộc OCL với ‘@pre’
2.2. Cú pháp của RTL
Cú pháp RTL dựa trên một hình thức lai của mơ hình cho luật chuyển ba
tích hợp OCL được đề xuất trong [6] như sau:
TGG&OCL Pattern={object:Class_i
(object1,object2):Association_j
[OCL_Condition_k]}
rule <ruleName>
[mode NONDELETING|EXPLICT]
checkSource(
<TGGs&OCL Pattern>
){
<TGGs&OCL Pattern>}
22