Các kỹ thuật chuyển đổi mô hình và sinh mã trong phát triển ứng dụng web hướng mô hình

MỤC LỤC

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

Chữ viết tắt

Chú giải

ATL

ATLAS Transformation Language

CM

Code Model

CWM

Common Warehouse Metamodel

DSL

Domain-Specific Language

DTD

Document Type Definition

EJB

Enterprise Java Bean

EMF

Eclipse Modeling Framework

JET

Java Emitter Templates

JMI

Java Metadata Interface

JSF

Java Server Faces

JSP

Java Server Pages

MDA

Model-Driven Architecture

MDD

Model-Driven Development

MDE

Model-Driven Engineering

MDR

Metadata Repository

MDSD

Model-Driven Software Development

MDSE

Model-Driven Software Engineering

MDWD

Model-Driven Web Development

MDWE

Model-Driven Web Engineering

MOF

Meta-Object Facility

NAD

Navigation Access Program

OCL

Object Constraint Language

OGNL

Object Graph Navigation Language

1


Chữ viết tắt

Chú giải

OMG

Object Management Group

OO-H
OOWS

Object-Oriented Hypermedia
Object-Oriented Web Solution

PIM

Platform-Independent Model

PSM

Platform-Specific Model

QVT

Query/View/Tranfomation

RMI

Remote Method Invocation

TTCN-3

Testing and Test Control Notation Version 3

UI

User Interface

UTP

UML Testing Profile

UWE

UML-based Web Engineering

ƯML

Unified Modeling Language

WebML

Web Markup Language

WebSA

Web Software Arichitecture

XMI

XML Metadata Interchange

XML

extensible Markup Language

2


DANH MỤC CÁC BẢNG

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

3


MỞ ĐẦU
Ngày nay, cơng nghiệp phần mềm đóng vai trị quan trọng, tác động đến sự

phát triển kinh tế xã hội và được xem là một trong những trụ cột chính của
tăng trưởng kinh tế ở nhiều nước. Tuy nhiên, việc phát triển phần mềm theo
cách truyền thống ngày càng phải đối mặt với nhiều khó khăn như vấn đề phát
triển, vấn đề tính khả chuyển, khả năng tương tác hay với sự phát triển nhanh
chóng của các nền tảng cơng nghệ mới. Do đó, những nhà phát triển phần
mềm phải dành nhiều công sức và thời gian để điều chỉnh ứng dụng (thường
theo cách thủ công là sửa mã nguồn) sao cho có thể hoạt động được trên các
nền tảng cơng nghệ mới. Chính vì vậy, một xu hướng phát triển phần mềm
mới nhằm khắc phục những khó khăn trên đã được nghiên cứu và phát triển,
đó là phát triển phần mềm hướng mơ hình (MDSD: Model driven software
development).
Kỹ thuật hướng mơ hình (MDE) là kỹ thuật mới cho sự phát triển sản phẩm
phần mềm. Kỹ thuật này giải quyết được sự phức tạp của nền tảng công nghệ
khác nhau bằng việc sử dụng các mơ hình (models) như là tác nhân chính
trong tồn bộ vịng đời phát triển ứng dụng, giảm sự phụ thuộc vào nền tảng
công nghệ [1-3]. MDE phát triển dựa trên ý tưởng xây dựng các mơ hình độc
lập với nền tảng và hỗ trợ việc chuyển đổi mơ hình thành mã nguồn của
chương trình. Do đó, q trình phát triển phần mềm hướng mơ hình được xem
như là một chuỗi các chuyển đổi mơ hình và chuyển đổi mơ hình đóng một
vai trị quan trọng trong kỹ thuật hướng mơ hình [4].
Phát triển phần mềm hướng mơ hình đang trở thành một phương pháp tiếp
cận, được chấp nhận rộng rãi để phát triển các ứng dụng phức tạp và ngày
càng giành được nhiều sự quan tâm của cộng đồng nghiên cứu, cũng như giới
công nghiệp phần mềm [1]. Sinh mã tự động là nền tảng thiết yếu của các
phương pháp tiếp cận theo hướng mơ hình để phát triển phần mềm. Việc sinh
mã tự động giúp cho việc phát triển ứng dụng trở nên hiệu quả hơn, hứa hẹn
sẽ là một bước tiến mới trong phát triển phần mềm, giúp lập trình viên nâng
cao được hiệu xuất làm việc và ngày càng được sử dụng nhiều trong tiến trình
phát triển phần mềm [5].
Các nghiên cứu đã minh chứng, phương pháp sinh mã hướng mô hình cho

tiến trình phần mềm đã tăng tốc độ tổng thể từ 3 đến 10 lần [5-7], làm giảm yếu
tố con người [8, 9], giảm thời gian phát triển ứng dụng web [9-12]. Việc sử
dụng các mơ hình để tạo mã chương trình, có thể tạo ra các sản phẩm phần

4


mềm có khả năng tương thích và sử dụng trên các nền tảng khác nhau [13],
trong [14] đã chứng minh việc sử dụng phương pháp này cho phép tiết kiệm rất
nhiều chi phí (nhất là chi phí bảo trì cho ứng dụng), vì chúng làm giảm sự cần
thiết phải thay đổi sau khi đưa ứng dụng vào sử dụng.
Các ứng dụng Web bao gồm nhiều thành phần khác nhau, có thể được cung
cấp bởi những nhà phát triển khác nhau, nên việc sử dụng các kỹ thuật phát
triển phần mềm hướng mơ hình cho các ứng dụng web đặc biệt hữu ích [1, 15,
16].
Trong những phương pháp phát triển ứng dụng web hướng mơ hình hiện
nay. UWE (UML-based Web Engineering) là một hướng tiếp cận cho phép
phát triển ứng dụng web hướng mơ hình dựa trên kiến trúc MDA. UWE cung
cấp một quy trình và cơng cụ, giúp mơ hình hố và xây dựng các ứng dụng
web, do nhóm nghiên cứu trường đại học LMU, Đức thực hiện với mục đích
tự động hố quy trình phát triển ứng dụng web và giảm thiểu tối đa việc lập
trình cài đặt mã nguồn cho ứng dụng.
UWE cung cấp một tập các mô hình tương ứng với từng khía cạnh của ứng
dụng web bao gồm: Mơ hình u cầu (requirements models), mơ hình nội
dung (content models), mơ hình điều hướng (navigation models), mơ hình xử
lý (process models), mơ hình trình bày (presentation models) và sử dụng biểu
đồ UML 2.0 cho việc mơ hình hoá. Một trong những ưu điểm quan trọng của
UWE là tất cả các mơ hình của nó đều là phần mở rộng của UML. UWE sử
dụng ký pháp đồ họa hồn tồn dựa trên UML. Nó cho phép sử dụng các công
cụ dựa trên UML và giảm thiểu thời gian nghiên cứu của các nhà phát triển

Web, những người đã quen thuộc với UML[17].
Tuy nhiên, các nghiên cứu phát triển ứng dụng web hướng mơ hình theo
phương pháp UWE, cịn tồn tại một số vấn đề cần tiếp tục đi sâu nghiên cứu:
Thứ nhất: Việc chuyển đổi từ mơ hình u cầu sang các mơ hình: Nội dung,
điều hướng, xử lý và trình bày vẫn phải được điều chỉnh thủ công, làm cho
việc phát triển ứng dụng Web tốn thời gian và chi phí; việc đảm bảo tính
thống nhất giữa các mơ hình cũng như cần cập nhật đồng bộ giữa các mơ hình
khi có thay đổi là rất khó khăn.
Thứ hai: Các nghiên cứu chủ yếu mới chỉ tập trung cho việc mơ hình hóa,
việc sinh code tự động còn nhiều hạn chế, chủ yếu mới chỉ dừng ở việc tạo ra
khung để kỹ thuật viên lập trình viết mã.
Khắc phục những hạn chế, tồn tại nêu trên, việc nghiên cứu xây dựng
phương pháp chuyển đổi mơ hình tự động, cải tiến kỹ thuật sinh mã để nâng
5


cao chất lượng mã nguồn, tăng năng suất, tiết kiệm thời gian và chi phí cho
ứng dụng web, giúp phát triển ứng dụng web đơn giản, linh hoạt, nhanh
chóng và hiệu quả hơn là vấn đề cần thiết, góp phần thúc đẩy sự phát triển của
lĩnh vực ứng dụng web, một lĩnh vực giàu tiềm năng nhưng mới chỉ là bước
đầu phát triển tại Việt Nam. Chính vì vậy, NCS chọn đề tài: “Các kỹ thuật
chuyển đổi mơ hình và sinh mã trong phát triển ứng dụng web hướng mơ
hình”.
Hướng tiếp cận của đề tài là phát triển bộ quy tắc chuyển đổi model to
model và mode to code theo phương pháp UWE, xây dựng công cụ
CODEGER-UWE để hỗ trợ phát triển các ứng dựng Web theo kiến trúc
MVC. Phương pháp dựa trên việc tạo mơ hình u cầu ở mức mơ hình độc
lập tính tốn (Computation Independent Model – CIM), sau đó xây dựng các
quy tắc chuyển đổi, để chuyển đổi sang mức mơ hình độc lập nền tảng
(platform-independent model – PIM) và mơ hình nền cụ thể (Platform

Specific Model - PSM), từ đó sinh code tự động cho ứng dụng web theo kiến
trúc MVC. Các quy tắc chuyển đổi của nghiên cứu được xây dựng với ngôn
ngữ chuyển đổi mơ hình (ATLAS Transformation Language – ATL). Áp dụng
phát triển ứng dụng web Chẩn đoán bệnh thủy sản “benhthuysan.vn”. Phương
pháp tiếp cận giúp đảm bảo tính thống nhất giữa các mơ hình sau khi chuyển
đổi, góp phần đảm bảo hiệu quả chuyển đổi mơ hình và sinh code tự động cho
phát triển ứng dụng Web hướng mơ hình theo kiến trúc MVC.
Mục đích nghiên cứu
Mục tiêu chung của đề tài là nghiên cứu kỹ thuật phát triển phần mềm
hướng mơ hình cho các ứng dụng web, nhằm phát triển bộ quy tắc chuyển đổi
model to model và model to code, theo phương pháp UWE và cụ thể hóa các
quy tắc chuyển đổi, bằng việc xây dựng công cụ hỗ trợ phát triển ứng dụng
Web theo kiến trúc MVC. Đề tài có các mục tiêu cụ thể sau:
- Tiếp cận kỹ thuật MDE, luận án phát triển bộ quy tắc chuyển đổi từ mơ
hình mức CIM sang PIM, sang PSM, sang mã nguồn cho phát triển ứng
dụng web hướng mô hình theo phương pháp UWE.
- Trên cơ sở các quy tắc đã phát triển, xây dựng công cụ sinh mã tự động
cho ứng dụng web. Thực nghiệm vào phát triển ứng dụng web Chẩn
đoán bệnh thủy sản (benhthuysan.vn).
Nhiệm vụ nghiên cứu
Với mục tiêu đặt ra ở trên, nhiệm vụ nghiên cứu của đề tài bao gồm:
6


- Tổng hợp, phân tích các kỹ thuật phát triển phần mềm hướng mơ hình,

-

kỹ thuật phát triển ứng dụng web hướng mơ hình như UWE, WebML,
WebSA...

Phát triển các quy tắc chuyển đổi mơ hình.
Phát triển các quy tắc sinh code với ngôn ngữ ATL cho phát triển ứng
dụng web hướng mơ hình theo phương pháp UWE.
Xây dựng cơng cụ sinh code tự động cho ứng dụng web theo kiến trúc
MVC.
Thực nghiệm và đánh giá: Tiến hành kiểm chứng tính khả thi của nghiên
cứu đề xuất trong luận án, bằng việc áp dụng vào phát triển ứng dụng
web Chẩn đoán bệnh thủy sản (benhthuysan.vn).

Đối tượng và phạm vi nghiên cứu
Đối tượng nghiên cứu của đề tài là vấn đề chuyển đổi mơ hình và sinh mã
tự động cho phát triển ứng dụng web theo phương pháp UWE. Trên cơ sở đó,
đề tài nghiên cứu các kiến thức thuộc về lý thuyết liên quan đến chuyển đổi
mơ hình và sinh code từ các mơ hình u cầu, nội dung, điều hướng, xử lý và
mơ hình trình bày nhằm áp dụng trong việc phát triển các bài toán thực tế.
Đề tài nghiên cứu các đặc điểm chung của phát triển ứng dụng web hướng
mơ hình, để xây dựng các quy tắc chuyển đổi mơ hình và sinh code tự động
với ngơn ngữ ATL cho phát triển ứng dụng Web theo kiến trúc MVC. Tiếp
theo, đề tài sẽ phân tích kết quả áp dụng phát triển ứng dụng web Chẩn đoán
bệnh thủy sản “benhthuysan.vn”.
Phương pháp nghiên cứu
Phương pháp lý thuyết
Phương pháp luận án sử dụng để nghiên cứu gồm:
- Tiến hành thu thập và nghiên cứu các tài liệu có liên quan đến luận án.
- Nghiên cứu lý luận, hệ thống hóa lý thuyết có liên quan đến xây dựng cơ
sở lý luận của đề tài: Thực trạng của kỹ thuật phát triển phần mềm
hướng mơ hình; Kỹ thuật phát triển ứng dụng web hướng mơ hình:
UWE, OOWS, WebML, WebSA.
- Tổng hợp, phân tích kỹ thuật chuyển đổi mơ hình theo phương pháp
UWE, từng bước hình thành những vấn đề lý luận của việc phát triển các

quy tắc chuyển đổi mơ hình, sinh code.
Phương pháp thực nghiệm

7


Tiến hành kiểm chứng tính khả thi của nghiên cứu đề xuất trong luận án,
bằng việc áp dụng vào các bài tốn điển hình đã được rất nhiều nghiên cứu
trong lĩnh vực này sử dụng để thực nghiệm, đặc biệt luận án đã thực nghiệm
trên bài toán trong thực tế về lĩnh vực chẩn đoán bệnh thủy sản. Sử dụng
nhiều công cụ khác nhau để kiểm chứng, đánh giá và so sánh tính hiệu quả
giữa chúng.
Ý nghĩa khoa học và thực tiễn của đề tài
Ý nghĩa khoa học
Đề tài tổng hợp và phân tích kỹ thuật phát triển ứng dụng web hướng mơ
hình. Kết quả nghiên cứu có thể làm tài liệu tham khảo cho các đơn vị phát
triển phần mềm, cần tiến hành phát triển các ứng dụng Web hướng mơ hình,
cung cấp các tài liệu tham khảo về các vấn đề liên quan.
Hướng nghiên cứu của đề tài có ý nghĩa trong việc cung cấp giải pháp phát
triển các ứng dụng web hướng mơ hình, giúp cho việc xây dựng ứng dụng
web đạt hiệu quả cao hơn.
Ý nghĩa thực tiễn
Kết quả nghiên cứu là tài liệu có giá trị tham khảo trong hoạt động nghiên
cứu và phát triển ứng dụng web hướng mơ hình. Kết quả nghiên cứu đã đề
xuất bộ quy tắc chuyển đổi mơ hình và sinh code cho ứng dụng web, đồng
thời cung cấp công cụ hỗ trợ cho phát triển ứng dụng web, giúp cho việc phát
triển ứng dụng web hướng mơ hình được thuận lợi, các doanh nghiệp phát
triển ứng dụng web giảm yếu tố con người, nâng cao hiệu quả làm việc.
Các kết quả mới đạt được
Tất cả các kết quả của luận án đã được đánh giá thông qua các công trình,

được đăng tải trong kỷ yếu của các hội thảo và các tạp chí. Những đóng góp
của nghiên cứu bao gồm:
(1) Tổng hợp lý thuyết, từ đó bổ sung phát triển các quy tắc chuyển đổi mơ
hình từ CIM to PIM cho phát triển ứng dụng web hướng mơ hình, theo
phương pháp UWE. Tổng hợp, phân tích các kỹ thuật phát triển ứng dụng
web hướng mơ hình như UWE, WebML, WebSA. Nội dung này được
trình bày trong chương 1 và chương 2 của luận án, có 4 cơng trình cơng
bố liên quan: CT1, CT2, CT3, CT7.
(2) Xây dựng phương pháp sinh mã và tích hợp phát triển cơng cụ
CODEGER-UWE sinh code cho ứng dụng web, theo phương pháp UWE,

8


với ngơn ngữ chuyển đổi mơ hình ATL. Nội dung này được trình bày
trong chương 3 và có 2 cơng trình cơng bố liên quan: CT4, CT5.
(3) Áp dụng xây dựng chuẩn đoán bệnh thủy sản trên nền tảng
benhthuysan.vn. Nội dung này được trình bày trong chương 3 (mục 3.4)
và có 2 cơng trình cơng bố liên quan: CT6, CT8.

CHƯƠNG 1: PHÁT TRIỂN PHẦN MỀM HƯỚNG MƠ HÌNH
Chương 1, tác giả giới thiệu về kiến trúc MDA, tổng hợp, phân tích các
thành phần trong MDA như các mơ hình CIM, PIM, PSM. Phân tích, so sách
một số kỹ thuật Web hướng mơ hình điển hình như OOWS, UWE, WebML,
WebSA làm cơ sở để lựa chọn, xây dựng mơ hình và các quy tắc chuyển đổi
trong chương 2. Trong chương 1, tác giả cũng trình bày tình hình các nghiên
cứu liên quan, phân tích cụ thể điểm mạnh và điểm cần cải tiến của các
nghiên cứu và dẫn tới lý do của đề tài luận án.

9

1.1. Kiến trúc MDA
MDA (Model Driven Architecture) được định nghĩa bởi OMG [18, 19]:
“MDA là một cách tiếp cận đặc tả hệ thống cơng nghệ thơng tin, nó phân tách
các đặc tả chức năng và các đặc tả thực thi”. Một mơ hình trong MDA, là một
đặc tả hình thức của chức năng và cấu trúc, cũng như hành vi ứng xử của một
ứng dụng hay một hệ thống phần mềm.

Hình 1.1. Tổng quan về MDA [18]

Kiến trúc hướng mơ hình (MDA) là kỹ thuật mới cho sự phát triển sản
phẩm phần mềm. Kỹ thuật này giải quyết được sự phức tạp của nền tảng công
nghệ khác nhau, bằng việc sử dụng các mơ hình (models) như là tác nhân
chính trong tồn bộ vịng đời phát triển ứng dụng, giảm sự phụ thuộc vào nền
tảng cơng nghệ [20]. Khi có nền tảng mới ra đời, thì ứng dụng mới sẽ được
chuyển đổi tự động từ các mơ hình để tương thích với nền tảng mới. Do đó,
MDA đang trở thành một phương pháp tiếp cận được chấp nhận rộng rãi, để
phát triển các ứng dụng phức tạp và ngày càng dành được nhiều sự quan tâm
của cộng đồng nghiên cứu, cũng như giới công nghiệp phần mềm.
Các ứng dụng Web, bao gồm nhiều thành phần khác nhau, có thể được
cung cấp bởi những nhà phát triển khác nhau với nền tảng công nghệ khác
nhau, nên việc sử dụng các kỹ thuật phát triển hướng mơ hình cho các ứng
dụng Web đặc biệt hữu ích [1, 15, 16]. Các kỹ thuật này đã khắc phục được
nhiều hạn chế mà các quá trình phát triển phần mềm trước đó chưa giải quyết
được, giảm chi phí thực hiện dự án phần mềm, tăng năng suất thực hiện dự án
một cách trực tiếp hoặc thông qua giảm khối lượng công việc làm lại [21].
MDA là một cách tiếp cận mơ hình hố trực quan, trong suốt quy trình tìm
hiểu, phân tích, thiết kế, thực thi một hệ thống phần mềm. MDA phân chia các
mô hình đặc tả hệ thống từ mức độ trừu tượng hóa cao, cho đến mức chi tiết

10


và cung cấp các quy tắc chuyển đổi, cho phép chuyển đổi giữa các mơ hình.
Hình 1.2 thể hiện tiến trình phát triển phần mềm theo MDA [19, 22-25].
Mơ hình độc
lập tính tốn

(CIM)

Mơ hình độc
lập nền
(PIM)

Mơ hình
nền cụ thể
(PSM)

Mơ hình
thực thi
(CODE)

Hình 1.2. Tiến trình MDA [22]

− Computation Independent Model (CIM) – Mơ hình độc lập tính tốn

CIM khơng hiển thị chi tiết về kiến trúc của hệ thống [26], CIM đại
diện cho tiến trình nghiệp vụ của tổ chức sẽ được xây dựng. Mơ hình CIM tập
trung vào sự đặc tả hệ thống bằng các thuật ngữ gần gũi với người làm nghiệp

vụ, được xác định bởi sự kết hợp làm việc giữa người phân tích nghiệp vụ và
những người làm nghiệp vụ sẽ sử dụng hệ thống. Chính vì vậy, mơ hình CIM
cịn được gọi là mơ hình phạm vi hay mơ hình nghiệp vụ. CIM chỉ miêu tả
mơi trường mà hệ thống thực thi và nó hỗ trợ chúng ta hình dung ra được hệ
thống đích, mà chúng ta muốn từ các yêu cầu ban đầu [22]. CIM cũng đóng
vai trị quan trọng trong việc thu hẹp khoảng cách giữa người sử dụng và các
chuyên gia trong lĩnh vực thiết kế, phát triển hệ thống [1]. Trong phát triển
phần mềm sử dụng hướng tiếp cận MDA, thì các yêu cầu cụ thể trong CIM có
mối liên hệ chặt chẽ với cấu trúc PIM và PSM [22].
− Platform Independent Model (PIM) – Mơ hình độc lập nền

PIM là một khung nhìn của hệ thống từ một điểm nhìn độc lập với nền
cơng nghệ [1, 20]. Mơ hình độc lập nền chỉ chú trọng vào các thao tác của hệ
thống, ẩn đi chi tiết cụ thể về nền công nghệ. Tức là ta không quan tâm đến
công nghệ nào sẽ được sử dụng để phát triển hệ thống. Một PIM cần thể hiện
được sự không phụ thuộc nền công nghệ và nó thích hợp cho việc sử dụng,
với nhiều nền công nghệ khác nhau hoặc tương tự nhau.
− Platform Specific Model (PSM) – Mơ hình nền cụ thể

PSM là một khung nhìn của hệ thống từ góc độ của một nền cơng nghệ
cụ thể nào đó. PSM chứa những gì được thể hiện trong PIM [27], với các chi
tiết cụ thể của một nền công nghệ sẽ được sử dụng để phát triển phần mềm
như Java, .Net.... Hình 1.3 trình bày một cách tổng quan về sự phân loại các
mô hình chính của MDA theo trật tự từ mức độ trừu tượng hóa đến cụ thể
hố.
11


MDA

Trừu tượng hóa

Cụ thể hóa

PIM: Mơ hình độc lập

PSM: Mơ hình theo nền cơng nghệ cụ thể

Hình 1.3. Sự phân loại các mơ hình chính trong MDA

1.1.1. Chuyển đổi mơ hình trong MDA
Chuyển đổi mơ hình là trung tâm của kỹ thuật phần mềm hướng mơ hình
[28, 29]. Sự chuyển đổi mơ hình trong MDA là việc sử dụng một cơ chế nào
đó, để biến đổi các mơ hình ở mức trừu tượng hố cao, thành các mơ hình ở
mức cụ thể và chi tiết hơn dựa trên sự định nghĩa các quy tắc chuyển đổi. Đó
là sự chuyển từ CIM sang PIM, từ PIM sang PSM, và từ PSM có thể chuyển
thành mã chương trình cụ thể thực thi hệ thống [30]. Hình 1.4 mơ phỏng sự
chuyển đổi giữa các mơ hình trong MDA.

12


Hình 1.4. Chuyển đổi mơ hình trong MDA[31]

Theo [32] chuyển đổi mơ hình là trung tâm của MDA, có 2 loại chuyển
đổi mơ hình thường gặp trong MDA: Chuyển đổi mơ hình tới mơ hình, và
chuyển đổi mơ hình tới mã nguồn.
Chuyển đổi mơ hình tới mơ hình: Chuyển đổi thơng tin từ một mơ hình hay
nhiều mơ hình tới một mơ hình khác, hay một tập các mơ hình. Một ví dụ về
chuyển đổi mơ hình tới mơ hình là chuyển đổi một tập các lớp thực thể, thành

một lược đồ cơ sở dữ liệu tương ứng.
Chuyển đổi mô hình tới mã nguồn là một chuyển đổi thơng dụng đối với
những người đã dùng các cơng cụ mơ hình hóa UML có khả năng sinh mã.
Các chuyển đổi này, chuyển đổi một thành phần của mơ hình sang một đoạn
mã nguồn. Chuyển đổi mơ hình tới mã nguồn có thể được phát triển cho gần
như bất kỳ dạng ngôn ngữ lập trình nào.
1.1.1.1. Chuyển đổi từ CIM sang PIM
Mơ hình Độc lập tính tốn (CIM), có nghĩa là mơ hình này khơng chứa bất
kỳ thơng tin nào về hệ thống phần mềm. Mơ hình CIM được trình bày bởi các
mơ hình quy trình nghiệp vụ, được cho là đại diện cho thế giới thực. Chuyển
đổi từ CIM sang PIM, là chuyển đổi đầu tiên trong MDA và nó rất quan trọng
trong việc thiết kế phần mềm chất lượng cao. Đầu tiên, sử dụng sơ đồ hoạt
động UML để xử lý các tác vụ của người sử dụng. Sơ đồ hoạt động này được
chỉ rõ trong các yêu cầu hệ thống. Các thành phần hệ thống được suy luận từ
mô hình yêu cầu và một bộ các nguyên mẫu, giúp các thành phần hệ thống tạo
ra PIM.

Hình 1.5. Mơ hình chuyển từ CIM sang PIM [20]

13


1.1.1.2. Chuyển đổi từ PIM sang PSM
Theo vết mơ hình

Hình 1.6. Đánh dấu mơ hình [31]

Hình 1.6 miêu tả chi tiết một trong những cách mà một chuyển đổi có thể
được thực hiện. Một nền công nghệ cụ thể được lựa chọn. Ánh xạ cho nền
cơng nghệ này sẵn có và được chuẩn bị. Ánh xạ này bao gồm một bộ thiết bị

đánh dấu. Các dấu được sử dụng nhằm đánh dấu các yếu tố mơ hình để hướng
dẫn cho q trình biến đổi mơ hình. Việc sử dụng ánh xạ sẽ làm cho PIM
đánh dấu được biến đổi xa hơn nhằm tạo ra PSM.
Q trình biến đổi siêu mơ hình – Metamodel

Hình 1.7. Q trình biến đổi Metalmodel [31]

Mơ hình được chuẩn bị bằng cách sử dụng một ngơn ngữ độc lập với nền
công nghệ được xác định bởi một metamodel. Một nền công nghệ cụ thể được
lựa chọn. Đặc tả mơ hình chuyển đổi nền tảng này hiện có sẵn hoặc được
chuẩn bị. Sự chuyển đổi đặc tả này dưới dạng ánh xạ giữa các metamodel.
Ánh xạ chỉ dẫn sự chuyển đổi của PIM tạo ra PSM.

14


Q trình biến đổi mơ hình

Hình 1.8. Q trình biến đổi mơ hình [31]

Mơ hình được chuẩn bị bằng cách sử dụng các kiểu độc lập nền công nghệ
trong mô hình. Các kiểu có thể là phần của một khung phần mềm. Các yếu tố
trong PIM là các kiểu phụ của dạng độc lập nền công nghệ. Một nền công
nghệ cụ thể được lựa chọn. Dạng biến đổi đặc tả nền cơng nghệ này sẵn có
hoặc được chuẩn bị sẵn. Sự biến đổi này là ánh xạ giữa các kiểu độc lập nền
tảng và các kiểu phụ thuộc nền tảng. Các yếu tố trong PSM là kiểu phụ của
các kiểu đặc tả nền tảng.
Cách tiếp cận này khác hẳn với ánh xạ metamodel, chủ yếu bằng các kiểu
đặc tả trong một mơ hình mà được sử dụng cho ánh xạ, thay thế cho các khái
niệm đặc tả bởi mơ hình metamodel.

Ứng dụng mẫu
Mở rộng các phương pháp tiếp cận ánh xạ siêu mơ hình và mơ hình bao
gồm các mẫu cùng với các kiểu hay các khái niệm ngôn ngữ mơ hình.

15


Hình 1.9. Ứng dụng mẫu [31]

Hình 1.10.

Một cách khác để sử dụng các mẫu [31]

Hình 1.10 chỉ ra một cách khác để sử dụng các mẫu: Khi các tên của nền
tảng cụ thể đánh dấu, có nghĩa là, tên của các mẫu thiết kế quy định cho một
nền tảng.
Mơ hình kết hợp
Có một số cách tiếp cận MDA dựa vào các mơ hình kết hợp.

Hình 1.11. Mơ hình kết hợp [31]

Ngồi các kiểu độc lập nền tảng, mơ hình chung có thể cung cấp các mẫu.
Cả hai kiểu và mẫu này có thể được ánh xạ tới các mẫu và các kiểu đặc tả nền
tảng.
Phương pháp tiếp cận ánh xạ mơ hình metamodel có thể sử dụng các mẫu
cùng một cách.
Hình 1.11 mở rộng mơ hình MDA theo một cách khác, nhằm miêu tả chi
tiết một trong những cách chuyển đổi khác có thể được thực hiện.
Thơng tin bổ sung

16


Ngoài những PIM và các nền tảng cụ thể đánh dấu, thơng tin bổ sung có
thể được cung cấp để hướng dẫn việc chuyển đổi.
Thông tin bổ sung sẽ thường xuyên dựa trên các kiến thức thực tế của nhà
thiết kế.

Hình 1.12.

Bổ sung thơng tin để chuyển sang PSM [31]

Hình vẽ mở rộng mẫu MDA đơn giản nhằm chỉ ra cách sử dụng của thơng tin
bổ sung

Hình 1.13.

Sử dụng thơng tin bổ sung trong kỹ thuật biến
đổi cụ thể [31]

Hình 1.13 mở rộng thêm mẫu MDA nhằm chỉ ra cách sử dụng thông tin bổ
sung trong kỹ thuật biến đổi cụ thể.
Trong q trình chuẩn bị mơ hình PIM, ngồi việc sử dụng các tên mẫu có
sẵn thì các thơng tin khác có thể được thêm vào để tạo ra PIM đánh dấu.
Ngồi các mẫu ra, các thơng tin thêm cũng có thể được sử dụng khi PIM đánh
dấu được biến đổi thêm nhằm tạo ra PSM.
1.1.1.3. Chuyển đổi từ PSM sang code
Chuyển đổi từ mơ hình PSM sang code, được sử dụng khi tất cả các chi
tiết cụ thể của nền tảng được xác định và mơ hình đã sẵn sàng để triển khai
thực tế. Từ mơ hình PSM chuyển đổi thành các tệp lệnh, được định nghĩa

bằng MOF M2T.
17


MOF M2T là ngơn ngữ được chuẩn hố bởi OMG tuân thủ
theo kiến trúc MDA. Ngôn ngữ này mô tả cách chuyển đổi từ
một mơ hình sang mã nguồn. Phương pháp tiếp cận dựa trên
khn mẫu, trong đó mã nguồn được sinh ra từ mơ hình, được
chỉ ra như một tập hợp các khuôn mẫu mà được tham chiếu
với các thành phần của mơ hình. Cụ thể hơn, một khn mẫu
đặc tả một khuôn mẫu dạng mã nguồn, với các vị trí
(placeholder) cho dữ liệu được lấy từ các mơ hình. Các vị trí
này cơ bản là các biểu thức biểu diễn cụ thể qua các thực thể
siêu mơ hình, với các truy vấn là các cơ chế chủ yếu cho việc
lựa chọn và khai thác giá trị từ các mơ hình. Các giá trị này
sau đó chuyển đổi sang các đoạn mã nguồn sử dụng ngôn
ngữ diễn tả (expression language).
1.1.2. Ngơn ngữ chuyển đổi mơ hình
1.1.2.1. Ngơn ngữ ATL
ATL (ATLAS Transformation Language) là ngơn ngữ chuyển đổi mơ hình
[33-40]. ATL cung cấp cho các nhà phát triển cách thức để tạo ra một tập các
mơ hình đích từ một tập các mơ hình nguồn. Thơng thường, khi xây dựng các
quy tắc chuyển đổi thì ATL sử dụng kiểu khai báo (Declarative) [41], nó cho
phép đơn giản hóa việc thể hiện ánh xạ giữa mơ hình nguồn và mơ hình đích.
Tuy nhiên, ATL cũng cung cấp cấu trúc bắt buộc (imperative constructs) để dễ
dàng đặc tả ánh xạ khó thể hiện khi dùng kiểu khai báo [36, 42-44]. Bên cạnh
các chuyển đổi mơ hình cơ bản, ATL định nghĩa thêm một phương tiện truy
vấn mơ hình (ATL query) cho phép chuyển đổi các phần tử của mơ hình sang
các kiểu dữ liệu nguyên thủy, từ đó các nhà phát triển có thể dễ dàng phát
triển các biến đổi ATL hơn trong việc xây dựng các ứng dụng web.

Ngôn ngữ chuyển đổi ATL cho phép các nhà phát triển xác định các yếu tố
của mơ hình nguồn phù hợp và điều hướng để khởi tạo các thành phần mơ
hình đích [30, 33]
Một phép biến đổi mơ hình ATL đơn giản xác định cách tạo ra mơ hình
đích Mb, tn thủ siêu mơ hình MMb, từ mơ hình nguồn Ma tn thủ siêu mơ
hình MMa [45] (hình 1.14). Do đó, khi có các siêu mơ hình (Metamodel) sẽ
thực hiện được phép chuyển đổi mơ hình sử dụng ATL [37, 46, 47]. UWE là
một phương pháp dựa trên UML để mơ hình hóa các ứng dụng Web theo kiến
trúc định hướng mơ hình - Model-Driven Architecture MDA.
18


Hình 1.14.

Tổng quan chuyển đổi mơ hình trong ATL
[12]

Một chương trình chuyển đổi ATL bao gồm các quy tắc xác định cách
thức các phần tử mơ hình nguồn được kết hợp và chuyển hướng đến các phần
tử của mơ hình đích. Bên cạnh chuyển đổi mơ hình cơ bản, ATL định nghĩa
một cơ sở truy vấn mơ hình cho phép xác định các u cầu đầu của mơ hình.
Ngơn ngữ ATL cho phép các nhà phát triển ATL thiết kế nhiều loại đơn vị
ATL khác nhau. Một đơn vị ATL (ATL unit) được định nghĩa trong tệp ATL
của nó. Các tệp ATL được phân biệt bởi phần mở rộng .atl. ATL chủ yếu tập
trung vào chuyển đổi mơ hình. Những hoạt động chuyển đổi đó được đóng
gói thành một mơ đun ATL. Ngồi mơ đun ra, ngơn ngữ ATL cịn cho phép
các nhà phát triển tạo ra các mơ hình cho các chương trình có kiểu dữ liệu cơ
bản. Những đơn vị (unit) đó gọi là truy vấn ATL (ATL queries). Mục đích của
truy vấn là tính tốn các giá trị nguyên thủy, ví dụ như là kiểu string hay kiểu
interger từ mơ hình nguồn. ATL cũng cho phép phát triển các thư viện độc lập

mà có thể import từ các đơn vị ATL khác, bao gồm cả bản thân các thư viện
đó. Điều này cung cấp một con đường thuận tiện, để tái sử dụng mã nguồn
ATL được sử dụng trong nhiều đơn vị ATL.
1.1.2.1.1. Cú pháp và ngữ nghĩa ATL
Ngôn ngữ ATL cho phép các nhà phát triển ATL thiết kế nhiều loại đơn vị
ATL khác nhau. Một đơn vị ATL (ATL unit) được định nghĩa trong tệp ATL
của nó. Các tệp ATL được phân biệt bởi phần mở rộng .atl.
Phần dưới đây sẽ trình bày về 3 đơn vị ATL, sẽ giải thích mục đích sử
dụng từng loại đơn vị và cung cấp tổng quan nội dung của 3 đơn vị.
 ATL mô đun

19


Một mô đun ATL tương ứng với một chuyển đổi một hình sang mơ hình.
Loại đơn vị ATL này, cho phép các nhà phát triển ATL xác định cách thức để
tạo ra một tập các mơ hình mục tiêu từ một tập các mơ hình nguồn. Cả mơ
hình nguồn và mục tiêu của một mô đun ATL phải được “định kiểu” bởi
metamodels tương ứng. Hơn nữa, một mô đun ATL chấp nhận một số cố định
của các mơ hình như đầu vào, và trả về một số cố định của các mơ hình mục
tiêu. Như vậy, một mơ đun ATL không thể tạo ra một số lượng không rõ các
mô hình mục tiêu tương ứng (ví dụ mơ hình phù hợp với một cùng một
metamodel).
Một mô đun ATL định nghĩa một chuyển đổi từ mơ hình đến mơ hình. Nó
bao gồm các thành phần: Header định nghĩa một số thuộc tính có liên quan
đến các mơ đun chuyển đổi, Import cho phần nhập khẩu một số thư viện ATL
hiện có, Helper tập hợp các lớp trợ giúp có thể được xem như tương đương
với các phương thức Java, Rules tập hợp các quy tắc định nghĩa cách mơ hình
mục tiêu được tạo ra từ những mơ hình nguồn.
Phần Helpers và Rules không thuộc về phần cụ thể nào trong một chuyển

đổi ATL. Chúng có thể được khai báo theo thứ tự bất kỳ, tùy thuộc vào từng
hoàn cảnh cụ thể. Bốn phần cơ bản sẽ được trình bày chi tiết trong phần dưới
đây:
− Header: Phần tiêu đề xác định tên của mô đun chuyển đổi và tên của các biến
tương ứng với mơ hình nguồn và mục tiêu. Nó cũng mã hóa các chế độ sử
dụng mơ đun. Cú pháp cho phần Header được định nghĩa như sau:
module module_name;
create output_models [from|refines] input_models;

Từ khóa module định nghĩa tên của mơ đun. Cần lưu ý tên của tệp ATL
chứa mã nguồn của mơ đun phải có tên giống với tên của mơ đun. Ví dụ, một
mơ đun chuyển đổi ModelA2ModelB phải được định nghĩa trong tệp
ModelA2ModelB.atl.
Mơ hình đích được khai báo bởi từ khóa create, cùng với việc khai báo mơ
hình nguồn bởi từ khóa from (trong chế độ thơng thường), hay refines (trong
trường hợp chuyển đổi làm mịn mơ hình). Khai báo mơ hình, dù là một đầu
vào hay đầu ra, phải phù hợp với cấu trúc model_name : metamodel_name.
Có thể khai báo nhiều hơn một mơ hình nguồn hoặc mơ hình đích bằng cách
tách các khai báo mơ hình bằng dấu phẩy. Lưu ý: Tên của các mơ hình khai
20


báo sẽ được sử dụng để nhận dạng. Cho nên, mỗi tên mơ hình được khai báo
phải là duy nhất trong tập các mơ hình được khai báo (cả đầu vào và đầu ra).
− Import: Phần tùy chọn Import cho phép khai báo các thư viện của ATL được
sử dụng trong chương trình. Khai báo của một thư viện ATL được thực hiện
như sau:
uses extensionless_library_file_name;

Ví dụ, để sử dụng các thư viện chuỗi, người ta sẽ viết:

uses strings;

Lưu ý rằng có thể khai báo một số thư viện khác nhau bằng cách sử dụng
nhiều lệnh uses.
− Helpers trong ATL có thể được xem như tương đương với các phương thức
trong Java. Helper giúp định nghĩa các đoạn mã ATL, có thể được gọi từ các
điểm khác nhau trong chuyển đổi ATL.
Một ATL Helper được xác định bởi các yếu tố sau:
+ Tên (tương ứng với tên của phương thức)
+ Loại ngữ cảnh: Được xác định giống cách mà một phương thức được
định nghĩa trong ngữ cảnh của lớp tương ứng trong lập trình hướng
đối tượng.
+ Kiểu giá trị trả về: Trong ATL, mỗi helper phải có một giá trị trả về.
+ Các thông số: Mỗi tham số được xác định bởi một cặp (tên tham số:
kiểu tham số).
Ví dụ, định nghĩa một helper trả về giá trị lớn nhất của 2 số nguyên.
helper context Integer def: max(x : Integer): Integer = ...;
− Rule trong ATL có 2 loại tương ứng với hai chế độ lập trình khác nhau được

cung cấp bởi ATL (ví dụ như kiểu khai báo hay bắt buộc): mached rules (dạng
khai báo) và called rules (dạng bắt buộc).
+ Matched rules: Các quy tắc này tạo thành cốt lõi của một chuyển đổi khai báo
ATL khi nó có thể xác định loại của phần tử nguồn, mà các phần tử đích được
sinh ra và cách khởi tạo các phần tử đích. Một matched rule được xác định
bởi tên của nó. Nó kết hợp các kiểu của phần tử mơ hình đích. Quy tắc xác
định cách tạo các phần tử mơ hình đích cần phải phù hợp với phần tử mơ hình

21

nguồn. Khai báo nguồn của matched rules được định nghĩa sau từ khóa from.
Nó cho phép xác định một biến phần tử mơ hình tương ứng với kiểu của các
phần tử đích mà quy tắc phải phù hợp. Kiểu này tương ứng với một thực thể
của metamodel nguồn của quy tắc chuyển đổi. Điều này có nghĩa là, các quy
tắc sẽ tạo ra các phần tử đích cho mỗi phần tử mơ hình nguồn phù hợp với
kiểu đó. Khai báo đầu ra của quy tắc phù hợp được đặt sau từ khóa “to”. Mục
đích là xác định các phần tử sẽ được tạo ra khi phần tử nguồn của quy tắc
được làm phù hợp và cách những phần tử tạo ra đó được khởi tạo. Phần chỉ
lệnh bắt buộc tùy chọn, được đưa ra sau từ khóa “to”, qua đó có thể xác định
mã nguồn bắt buộc sẽ thực hiện sau khi khởi tạo của các phần tử đích được
tạo ra bởi quy tắc.
Ví dụ một matched rules ATL:
rule Author {
from
a : MMAuthor!Author
to
p : MMPerson!Person (
name <- a.name,
surname <- a.surname
)
+ Called rules: Cung cấp cho các nhà phát triển ATL một công cụ ngôn ngữ bắt

buộc thuận tiện. Called rules cũng có thể được coi như là một helpers: Chúng
phải được gọi chính xác khi thực thi và có thể chấp nhận các biến. Tuy nhiên,
ngược lại với helpers, called rules có thể tạo ra các phần tử mơ hình đích như
là matched rules. Một called rule phải được gọi từ vùng mã nguồn bắt buộc
hoặc từ một matched rule khác hay called rule khác. Giống như matched rule,
một called rule được đặt sau từ khóa rule. Called rules có thể bao gồm phần
biến cục bộ tùy chọn. Tuy nhiên, vì nó khơng phải làm phù hợp các phần tử
mơ hình nguồn, nên called rule khơng chứa các mẫu nguồn. Hơn nữa, mẫu

mơ hình mà có khả năng tạo các phần tử mơ hình đích cũng là tùy chọn. Lưu
ý rằng, vì called rule khơng làm phù hợp bất kỳ các phần tử mơ hình nguồn
nào, nên sự khởi tạo của các phần tử mơ hình đích mà được tạo bởi mẫu đích
phải dựa trên sự kết hợp của các biến cục bộ, tham số và thuộc tính của mơ
đun. Mẫu đích của called rules được định nghĩa giống mẫu đích của matched
rule. Nó cũng được định nghĩa sau từ khóa “to”. Một called rule có thể có

22


phần bắt buộc tương tự như phần được định nghĩa trong matched rules. Lưu ý
rằng, phần mã nguồn bắt buộc là khơng bắt buộc, có thể xác định một called
rule mà chỉ chứa phần mẫu đích hay phần mã nguồn bắt buộc. Dưới đây là
một ví dụ về cấu trúc called rule:
rule NewPerson (na: String, s_na: String) {
to
p : MMPerson!Person (
name <- na )
do {
p.surname <- s_na
}
 Chế độ thực thi mô đun

ATL định nghĩa hai chế độ thực thi khác nhau cho các mô đun ATL. Với
chế độ thực thi mặc định, các nhà phát triển ATL phải xác định rõ ràng cách
các phần tử mơ hình đích phải được tạo ra từ các phần tử mơ hình nguồn.
Chế độ thực thi được mô tả trong các phần dưới đây:
− Chế độ thực thi Normal: Là chế độ mặc định của mơ đun ATL. Nó được kết
hợp với từ khóa from trong tiêu đề mơ đun. Trong chế độ thực thi mặc định,
các nhà phát triển ATL phải xác định (dù là quy tắc matched rules hay called

rules) các cách để tạo ra từng phần tử mơ hình đích mong đợi. Chế độ này
phù hợp với hầu hết các chuyển đổi ATL nơi mơ hình đích khác với mơ hình
nguồn.
− Chế đội thực thi Refining: Chế độ này đưa ra để giảm bớt quá trình chuyển
đổi, tinh chỉnh giữa mơ hình nguồn và đích tương tự nhau. Với chế độ tinh
chỉnh, các nhà phát triển ATL có thể tập trung vào các mã ATL dành riêng cho
việc tạo ra các phần tử đích đã thay đổi. Các phần tử mơ hình khác (ví dụ,
những thành phần khơng thay đổi giữa nguồn và mơ hình đích) được mặc
nhiên sao chép từ nguồn đến các mơ hình đích bởi ATL engine.
 Truy vấn ATL

Ngồi mơ đun, ATL cịn cho phép định nghĩa các truy vấn trên mơ hình.
Một truy vấn sử dụng một số lượng mơ hình nguồn và trả về một giá trị đơn
của bất kỳ kiểu dữ liệu nguyên thủy nào. Một đơn vị truy vấn bao gồm một
phần tử truy vấn đơn cùng các helpers và thuộc tính được định nghĩa trong
ngữ cảnh của mô đun ATL hay bất kỳ các phần tử mơ hình nào định nghĩa

23


trong mơ hình nguồn truy vấn. Lưu ý rằng, đơn vị truy vấn ATL phải bắt đầu
vào khai báo các phần tử truy vấn.
Truy vấn ATL được khai báo như sau:
query query_name = exp;
 Thư viện ATL

Kiểu đơn vị cuối cùng của ATL là thư viện ATL. Phát triển một thư viện
ATL cho phép định nghĩa tập hợp các lớp trợ giúp ATL, mà có thể gọi từ các
đơn vị khác nhau của ATL.
Không giống như ATL mô đun, trong thư viện ATL khơng có các phần tử

mặc định. Cho nên, trong thư viện không thể mô tả các lớp trợ giúp trong ngữ
cảnh mặc định như của mô đun. Có nghĩa là tất cả lớp trợ giúp định nghĩa
trong thư viện ATL cần phải liên kết với một ngữ cảnh.
So sánh với truy vấn ATL, một thư viện ATL khơng thể thực thi độc lập.
Điều này có nghĩa là thư viện không liên kết với bất kỳ bước khởi tạo nào tại
thời điểm thực thi. Vì thiếu bước khởi tạo nên lớp trợ giúp thuộc tính khơng
thể định nghĩa trong thư viện ATL.
1.1.2.1.2. Kiến trúc ATL
Kiến trúc ATL bao gồm:
− Phần lõi (Core): Mô tả khái niệm ATL theo một cách trừu tượng
− Bộ phân tích (Parser) và bộ biên dịch (Compiler)
− Máy ảo (Virtual Machines) cho phép thực thi chuyển đổi.
− Mơi trường phát triển: Bao gồm trình soạn thảo, trình gỡ lỗi, dựa trên
các thành phần đề cập ở trên.
 Phần lõi (Core)

24


Hình 1.15.

Phần lõi ATL

IModel là một biểu diễn phù hợp của mơ hình phù hợp cho chuyển đổi
ATL. Nó cung cấp các phương thức để tìm kiếm các phần tử, tạo mới, vv…
Giao diện IReferenceModel mở rộng IModel và là một phiên bản cụ thể
của IModel mà tượng trưng cho siêu mơ hình. Nó định nghĩa các hoạt động
dành riêng cho siêu mơ hình mà hữu ích cho chuyển đổi ATL.
ModelFactory dành riêng cho tạo mơ hình và mơ hình tham chiếu.
Giao diện IInjector, IExtractor cung cấp cách để nạp và lưu mơ hình được

tạo từ trước bởi modelFactory.
Giao diện ILauncher dành riêng cho cài đặt bởi máy ảo ATL: Nó định nghĩa
các phương thức để tham số hóa và khởi động một chuyển đổi.
Dịch vụ (services): Để đơn giản hóa việc sử dụng phần lõi ATL và giảm
trùng lặp mã nguồn, 2 dịch vụ cung cấp: CoreService và LauncherService.
Các lớp tiện ích đều cung cấp một cách thức để nhìn vào các phần mở rộng
hay bộ nhớ cục bộ cho cài đặt Core.
LauncherService cho phép gọi một chuyển đổi từ tập các biến giống như
bản đồ đường dẫn và bản đồ của tên mơ hình: Nó có liên quan chặt chẽ tới
cấu hình và các tác vụ như cho phép gọi chuyển đổi trên các máy ảo.
 Máy ảo ATL

Máy ảo ATL VM là bộ thông dịch byte code mà quản lý kiểu phân cấp của
OCL và ATL. Hình dưới đây mô tả hoạt động của ATL VM.

25