MODEL-DRIVEN ARCHITECTUREAND ONTOLOGY MANAGEMENT

ĐẠI HỌC HUẾ
TRƯỜNG ĐẠI HỌC KHOA HỌC

TIỂU LUẬN
MÔN: SEMANTIC WEB
ĐỀ TÀI:
MODEL-DRIVEN ARCHITECTURE
AND ONTOLOGY MANAGEMENT
Thực hiện: Nhóm 2
Lê Thị Ngọc Ánh
Nguyễn Lý Hữu Huấn
Nguyễn Quốc Huy
Trịnh Thị Tường Vy
Lớp: Khoa học máy tính, Khóa năm: 2008-2010
Huế, 12/2009
MỤC LỤC
MỞ ĐẦU 1
1. Model Driven Architecture (MDA) 2
2. Ứng dụng MDA trong quản lý Ontology 28
TÀI LIỆU THAM KHẢO 64
DANH MỤC CÁC TỪ VIẾT TẮT
AI : Artificial Intelligence
CIM : Computation Independent Model
CWM : Common Warehouse Metamodel
DTD : Document Type Definitions
EBNF : Extended Backus–Naur form
EDOC : Enterprise Distributed Object Computing
MDA : Model Driven Architecture
MOF : Meta-Object Facility
MS : Modeling space
ODM : Ontology Definition Metamodel

OIL : Ontology Inference Layer
OMG : Object Management Group
OUP : Ontology UML Profile
OWL : Web Ontology Language
PIM : Platform Independent Model
PSM : Platform Specified Model
QVT : Query/Views/Transformations
RFP : Request for Proposal
SPEM : Software Process Engineering Metamodel
UML : Unified Modeling Language
XMI : XML Metadata Interchange
XSD : XML Schema Definitions
XSLT : eXtensible Stylesheet Language
Transformation
Model-Driven Architecture and Ontology Management
MỞ ĐẦU
Bước phát triển tiếp theo của World Wide Web là Semantic Web, nó sẽ cho
phép các dữ liệu mà máy có thể hiểu được chia sẻ trên mạng Internet. Semantic
Web sẽ được trang bị bởi siêu dữ liệu, mô tả bởi các ontology. Ontology là một
trong những khái niệm quan trọng nhất trong biểu diễn tri thức. Nó có thể được
định nghĩa là một sự khái niệm hóa hình thức được chia sẻ của một domain cụ thể.
Semantic Web và các ngôn ngữ dựa trên nền tảng XML của nó là các hướng
chính của sự phát triển web trong tương lai. Các domain ontology là phần quan
trọng nhất của ứng dụng Web ngữ nghĩa.
Để khắc phục sự cách biệt giữa người phát triển phần mềm và các kỹ thuật
trí tuệ nhân tạo (AI), một số đề xuất đã được đưa ra cho việc sử dụng UML trong
phát triển ontology. Nhưng, bản thân UML không đáp ứng được nhu cầu của việc
biểu diễn các khái niệm ontology được lấy từ Descriptive Logic, và các khái niệm
đã được bao gồm trong các ngôn ngữ ontology Semantic Web (ví dụ như RDF,
RDF Schema, OWL, v.v.).

Trong lịch sử công nghệ phần mềm, việc sử dụng các mô hình và mức độ
trừu tượng trong các mô hình đã có một sự gia tăng đáng kể. Việc mô hình hóa đã
bị tách biệt khỏi các platform phát triển và triển khai bên dưới, làm tăng tính tái sử
dụng và dễ dàng hơn để tạo và sửa đổi bởi các domain expert, và đòi hỏi ít kiến
thức hơn về các hệ thống triển khai cụ thể. Xu hướng này làm cho việc mô hình hóa
phần mềm gần với công nghệ tri thức hơn. Giai đoạn hiện tại của quá trình tiến triển
này là Model Driven Architecture (MDA). Trong thời gian gần đây, nhiều tổ chức
đã bắt đầu tập trung chú ý vào MDA như là một cách tiếp cận để thiết kế và triển
khai các ứng dụng. Đây là một sự phát triển rất tích cực vì nhiều lý do. MDA
khuyến khích sử dụng hiệu quả các mô hình hệ thống trong quá trình phát triển
phần mềm, và nó hỗ trợ tái sử dụng các thực tiễn tốt nhất khi tạo ra các họ của các
hệ thống. Như được định nghĩa bởi Object Management Group (OMG), MDA là
một cách để tổ chức và quản lý các kiến trúc enterprise được hỗ trợ bởi các công cụ
tự động và các dịch vụ cho cả hai quá trình xác định các mô hình và tạo điều kiện
thuận lợi cho việc chuyển đổi giữa các loại mô hình khác nhau.
-1-
Model-Driven Architecture and Ontology Management
1. Model Driven Architecture (MDA)
1.1. Khái niệm về MDA
Vào năm 1995, Object Management Group (OMG) đã bắt đầu nghiên cứu
các đặc tả công nghệ chuyên ngành (Domain Technology Specifications). Nhận
thức được nhu cầu cần chuẩn hóa hoạt động này, OMG thành lập một hội đồng
công nghệ chuyên ngành (Domain Technology Committee) trong giai đoạn tái cấu
trúc quy trình làm việc vào những năm 1996 và 1997. Cũng trong năm 1995, Mary
Loomis đã lãnh đạo các thành viên của OMG trong việc mở rộng công việc nghiên
cứu của họ về mô hình hóa đối tượng, và điều này đã dẫn tới việc sử dụng ngôn ngữ
UML (Unified Modeling Language). Sau đó, các thành viên của OMG đã bắt đầu
dùng UML trong việc đặc tả các công nghệ.
Vào năm 2001, OMG đã bắt đầu sử dụng nền tảng thứ hai, Model Driven
Architecture (MDA). MDA không phải là một nền tảng, như OMA (Object

Management Architecture) hay CORBA, để thực thi các hệ thống phân tán. Nó là
một kiến trúc định hướng mô hình (model driven), cung cấp cách thức sử dụng các
mô hình để điều khiển các công đoạn tìm hiểu, thiết kế, xây dựng, triển khai, vận
hành, bảo trì và chỉnh sửa hệ thống ứng dụng.
MDA là một hướng tiếp cận mới trong việc phát triển các hệ thống phần
mềm. Nó tách biệt sự đặc tả các chức năng hệ thống khỏi sự đặc tả việc hiện thực
các chức năng này trên một platform cụ thể thông qua khái niệm mô hình.
MDA cung cấp một cách tiếp cận mở và trung lập đối với nhà cung cấp dịch
vụ cho sự thay đổi về nghiệp vụ và công nghệ. Dựa trên các chuẩn đã được thiết
lập, MDA tách biệt luận lý nghiệp vụ và ứng dụng khỏi công nghệ platform bên
dưới. Các mô hình độc lập platform của một ứng dụng hay của các chức năng và
hành vi nghiệp vụ của hệ thống tích hợp, được xây dựng bằng cách sử dụng UML
và các chuẩn mô hình hóa có liên quan khác, có thể được thực hiện thông qua MDA
trên hầu như bất kỳ platform nào, platform mở hoặc có bản quyền, bao gồm Web
Services, .NET, CORBA®, J2EE,… Những mô hình độc lập platform này tách biệt
việc lập tài liệu các chức năng và hành vi nghiệp vụ của một ứng dụng khỏi code
hiện thực chúng, cô lập lõi (core) của ứng dụng khỏi công nghệ, trong khi vẫn cho
phép tính cộng tác giữa các phần cả trong trường hợp cùng platform và khác
platform. Không còn ràng buộc lẫn nhau, các mặt công nghệ và nghiệp vụ của một
ứng dụng hoặc một hệ thống tích hợp có thể phát triển theo nhịp độ riêng của nó –
luận lý nghiệp vụ tương ứng với nhu cầu nghiệp vụ, và công nghệ tận dụng những
phát triển mới khi nghiệp vụ yêu cầu.
MDA tập trung chủ yếu vào các chức năng và hành vi của một hệ thống hoặc
một ứng dụng phân tán, không phải là công nghệ mà nó sẽ được thực hiện. Nó tách
biệt các chi tiết thực hiện khỏi các chức năng công việc. Vì vậy, chúng ta không cần
phải lặp lại quá trình của mô hình hóa chức năng và hành vi của một ứng dụng hoặc
hệ thống mỗi khi xuất hiện một công nghệ mới. Các kiến trúc khác thường gắn với
một công nghệ cụ thể. Với MDA, chức năng và hành vi được mô hình hóa một và
chỉ một lần. Việc ánh xạ đến các platform MDA sẽ được thực hiện bởi các công cụ,
do đó sẽ thuận lợi cho việc hỗ trợ công nghệ mới hoặc khác nhau.

-2-
Model-Driven Architecture and Ontology Management
MDA cung cấp một phương pháp tiếp cận để:
- Đặc tả một hệ thống một cách độc lập với platform hỗ trợ nó
- Đặc tả các platform
- Chọn ra một platform cụ thể cho hệ thống
- Biến đổi đặc tả hệ thống thành bản đặc tả dùng cho một platform cụ
thể.
MDA có 3 mục đích chính là:
- Tính khả chuyển (portability);
- Khả năng hoạt động trên nhiều nền tảng (interoperability);
- Khả năng sử dụng lại (reusability).
Một trong những mục đích chính của MDA là nhằm tách biệt thiết kế với cấu
trúc. Bởi vì các khái niệm và các công nghệ sử dụng trong thiết kế và trong cấu trúc
đều thay đổi theo những bước phát triển riêng, việc tách biệt chúng cho phép các
nhà phát triển hệ thống lựa chọn được cái tốt nhất và phù hợp nhất trong cả hai
domain. Việc thiết kế chú trọng đến các yêu cầu chức năng (use case) trong khi cấu
trúc cung cấp cơ sở hạ tầng mà qua đó thực hiện các yêu cầu phi chức năng như khả
năng mở rộng, độ tin cậy và hiệu năng.
Hình 1: Tổng quan về MDA
Hình 1 mô tả về kiến trúc Model Driven Architecture (MDA), đây là một
kiến trúc trung lập với ngôn ngữ, nhà cung cấp và middleware.
Phần cốt lõi của kiến trúc này (nằm ở trung tâm của hình trên) được dựa trên
các chuẩn mô hình hóa của OMG: UML, MOF và CWM. Đây là kiến trúc đa mô
hình lõi. Mỗi mô hình lõi phải là độc lập với bất kỳ một middleware platform nào.
Số lượng mô hình lõi là nhỏ bởi vì mỗi mô hình lõi biểu diễn các đặc tính thông
-3-
Model-Driven Architecture and Ontology Management
dụng của tất cả các platform trong các category của nó (theo thuật ngữ kỹ thuật thì
đây là một metamodel).

Các nguyên lý của MDA
Có 4 nguyên lý về MDA theo quan điểm của OMG:
- Các mô hình được biểu diễn trong một ký hiệu hoàn toàn xác định là
một nền tảng cho việc nắm rõ các hệ thống đối với các giải pháp quy mô
enterprise.
- Việc xây dựng các hệ thống có thể được tổ chức xung quanh một tập
các mô hình bằng cách áp đặt một loạt các biến đổi giữa các mô hình, tổ
chức thành một khuôn khổ kiến trúc của các lớp và các phép biến đổi.
- Một nền móng chính thức để mô tả các mô hình trong một bộ các
metamodels tạo điều kiện thuận lợi cho việc tích hợp và chuyển đổi giữa
các mô hình, và là cơ sở cho việc tự động hóa thông qua các công cụ.
- Sự thừa nhận rộng rãi của phương pháp tiếp cận dựa trên mô hình này
đòi hỏi các tiêu chuẩn công nghệ để cung cấp tính mở cho người sử dụng,
và thúc đẩy sự cạnh tranh giữa các nhà cung cấp.
Để hỗ trợ những nguyên lý này, OMG đã xác định một tập hợp cụ thể của
các lớp và phép biến đổi, cung cấp một khung khái niệm và từ vựng cho MDA.
1.2. Các mô hình (model) và siêu mô hình (metamodel)
Mô hình đóng một vai trò quan trọng trong MDA. Định nghĩa chung nhất nói
rằng một mô hình là một hình chiếu đơn giản hóa của thế giới thực, hay hình thức
hơn, một mô hình là một tập các phát biểu của một hệ thống đang nghiên cứu.
Trong thực tế, người ta có thể nói rằng một mô hình là một tập các phần tử
(element) hình thức mô tả một cái gì đó đang được phát triển cho một mục đích cụ
thể và có thể được phân tích bằng cách sử dụng các phương pháp khác nhau. Ngoài
những gì được chỉ ra theo định nghĩa của mô hình, một mô hình kỹ thuật phải có
năm đặc tính cơ bản sau:
- Tính trừu tượng hóa (Abstraction). Một mô hình luôn luôn là một sự
biểu diễn rút gọn của hệ thống mà nó trình bày.
- Tính có thể hiểu được (Understandability). Nếu trình bày tóm tắt cách
chi tiết mà chưa đầy đủ thì chúng ta cũng phải trình bày những gì còn lại
dưới các dạng trực quan nhất (ví dụ như ký hiệu).

- Tính chính xác (Accuracy). Một mô hình phải trình bày các tính năng
của hệ thống rất gần gũi với cuộc sống thực tế.
- Tính dự đoán (Predictiveness). Chúng ta sẽ có thể sử dụng một mô
hình để dự đoán chính xác các đặc tính của hệ thống được mô hình hóa
hoặc thông qua các thử nghiệm (chẳng hạn như bằng cách thực hiện một
mô hình trên một máy tính) hoặc thông qua một số loại phân tích hình
thức.
- Chi phí hiệu quả (Inexpensiveness). Xây dựng và phân tích một mô
hình phải rẻ hơn một cách đáng kể so với các hệ thống được mô hình hóa.
-4-
Model-Driven Architecture and Ontology Management
Siêu mô hình (metamodel) là một khái niệm chính được sử dụng trong
MDA. Một Metamodel là một mô hình đặc tả cho một lớp của các hệ thống đang
nghiên cứu, trong đó mỗi hệ thống đang nghiên cứu trong lớp đó là một mô hình
hợp lệ biểu diễn theo một ngôn ngữ mô hình hóa nhất định. Một Metamodel tạo ra
các phát biểu về những gì có thể được biểu diễn (tức là được khẳng định) trong các
mô hình hợp lệ của một ngôn ngữ mô hình hóa nhất định. Trong thực tế, một
metamodel là một mô hình của một ngôn ngữ mô hình hóa. Biểu đồ UML trong
hình 2 trình bày mối quan hệ giữa một hệ thống đang nghiên cứu và một mô hình
được trình bày bằng một ngôn ngữ mô hình cụ thể. Vì một metamodel là một mô
hình nên nó có thể được trình bày trong một ngôn ngữ mô hình hóa. Trong một số
kiến trúc mô hình hóa, chẳng hạn như MDA, có một ngôn ngữ mô hình cụ thể để
định nghĩa các metamodel, và ngôn ngữ đó được định nghĩa trong tầng
metametamodeling của một kiến trúc mô hình cụ thể. Trong trường hợp MDA,
ngôn ngữ mô hình này được gọi là Meta-Object Facility (MOF).

Hình 2: Sự tương ứng giữa một mô hình và một hệ thống
1.3. Các thành phần cơ bản trong MDA
PIM (Platform Independent Model)
PIM là một cái nhìn về hệ thống trên quan điểm độc lập platform, mô tả hệ

thống mà không chứa bất cứ thông tin gì về platform sẽ hiện thực cuối cùng. Một
PIM thể hiện một mức độc lập platform cụ thể để có thể sử dụng với một tập các
platform khác nhau thuộc các loại tương tự. Một PIM mô tả một hệ thống phần
mềm hỗ trợ một số nghiệp vụ. Trong một PIM, hệ thống được mô hình từ quan
điểm làm thế nào để hệ thống hỗ trợ tốt nhất cho doanh nghiệp và nghiệp vụ.
Những yếu tố như là một hệ thống sẽ được hiện thực trên một mainframe với một
cơ sở dữ liệu quan hệ hay trên một server ứng dụng EJB thì không đóng vai trò gì
trong một PIM.
Cho dù mục tiêu cuối cùng của bạn là CCM, EJB, MTS, hoặc là một số
thành phần hay platform giao tác nào, bước đầu tiên khi xây dựng một ứng dụng
dựa trên MDA là phải tạo ra một mô hình ứng dụng độc lập platform được biểu
diễn thông qua UML theo quan điểm của mô hình lõi thích hợp. Các nhà chuyên gia
platform sẽ convert mô hình ứng dụng tổng quát này sang một mô hình của một
platform cụ thể như CCM, EJB, hay MTS. Các ánh xạ chuẩn sẽ cho phép các công
cụ thực hiện tự động một số quá trình chuyển đổi. Trong hình 1, các platform đích
nằm ở vòng tròn bao quanh mô hình lõi.
-5-
Model-Driven Architecture and Ontology Management
Việc làm tăng tối đa sự tự động hóa của việc ánh xạ là một mục tiêu đang
được nghiên cứu, tuy nhiên, trong hầu hết các trường hợp thì vẫn cần đến các thao
tác coding thủ công, nhất là khi không có các MDA tool.
PSM (Platform Specified Model)
Mô hình platform-specific biểu diễn một cách trung thực cả ngữ nghĩa
business run-time và technical run-time của ứng dụng. Nó vẫn là một mô hình
UML, nhưng, do các bước biến đổi, được biểu diễn theo một biến thể (nghĩa là một
profile) của UML mà phản ánh một cách chính xác các thành phần technical run-
time của platform đích. Ngữ nghĩa của mô hình độc lập platform ban đầu được
chuyển sang mô hình platform-specific.
PSM là một mô hình đã xác định platform, nó mô tả hệ thống với đầy đủ
thông tin về platform sẽ hiện thực cuối cùng. Một PSM kết hợp những đặc tả ở

trong PIM với những chi tiết xác định làm cách nào để hệ thống sử dụng một
platform cụ thể. Một PSM xác định hệ thống dưới dạng các cấu trúc hiện thực mà
đã có sẵn trong một công nghệ hiện thực cụ thể. Ví dụ: Một EJB PSM là một mô
hình của hệ thống dưới dạng các cấu trúc EJB. Nó thường chứa các thuật ngữ của
EJB như là: “home interface”, “entity bean”, “session bean” …Một PSM cơ sở dữ
liệu quan hệ bao gồm các thuật ngữ như: “table”, “column”, “foreign key”… Rõ
ràng là một PSM sẽ chỉ có ý nghĩa với các nhà phát triển có kiến thức về các
platform cụ thể. Một PIM được chuyển thành một hoặc nhiều PSM. Với mỗi
platform công nghệ cụ thể, một PSM riêng biệt sẽ được tạo ra. Hầu hết các hệ thống
ngày nay sử dụng nhiều công nghệ, do đó thường sẽ có nhiều PSM cho một PIM.
Cả hai mô hình PIM và PSM đều mô tả hệ thống, nhưng PIM lại không đề
cập chi tiết phần nền tảng mà hệ thống sẽ sử dụng trong khi PSM lại có đề cập.
PSM là mô hình thực thi hệ thống: nó cung cấp đầy đủ các thông tin để xây
dựng và vận hành một hệ thống phần mềm. Các thông tin này bao gồm mã chương
trình, các bản đặc tả công việc chạy và liên kết chương trình, bản mô tả công việc
triển khai, đặc tả cấu hình hệ thống.
Code
Bước cuối của sự phát triển phần mềm là chuyển các PSM sang code. Bởi vì
ở mức PSM công nghệ đã được chọn cụ thể, do đó việc chuyển đổi tương đối dễ
dàng. Đối với các môi trường cấu thành, hệ thống cần phải sinh ra nhiều loại code
và file cấu hình bao gồm các file giao diện, các file định nghĩa thành phần, các file
code chương trình, các file cấu hình thành phần, và các file cấu hình hợp.
Tóm lại, MDA định nghĩa PIM, PSM, code và mối quan hệ giữa chúng. Một
PIM phải được tạo ra, sau đó chuyển thành một hoặc nhiều PSM, và sau đó chuyển
thành code. Bước phức tạp nhất trong chu trình phát triển MDA là bước chuyển một
PIM thành một hoặc nhiều PSM.
Sự gia tăng mức độ trừu tượng: PIM, PSM, code là các artifact của các bước
khác nhau trong chu trình phát triển phần mềm. Quan trọng hơn, chúng thể hiện các
mức trừu tượng khác nhau của sự đặc tả hệ thống. Khả năng chuyển đổi một PIM
-6-

Model-Driven Architecture and Ontology Management
mức cao vào một PSM làm tăng mức độ trừu tượng mà tại đó nhà phát triển có thể
làm việc. Điều này cho phép một nhà phát triển có thể giải quyết các hệ thống phức
tạp mà chỉ cần rất ít nỗ lực.
1.4. Sự chuyển đổi mô hình
Thành phần chính của kiến trúc MDA là quá trình biến đổi mô hình (Model
Transformation). Đây là quá trình chuyển một mô hình sang mô hình khác của cùng
hệ thống. Đầu vào của việc biến đổi này là mô hình PIM đã được đánh dấu và công
việc ánh xạ. Kết quả nhận được là mô hình PSM và hồ sơ ghi chép việc biến đổi
này.
Hình 3: Sự chuyển đổi từ PIM sang PSM
Các yêu cầu đối với hệ thống được biểu diễn trong một mô hình độc lập tính
toán (Computation Independent Model - CIM). CIM sẽ mô tả hoàn cảnh mà hệ
thống sẽ được sử dụng trong đó. Mô hình này thỉnh thoảng được gọi là mô hình
miền (domain model) hay mô hình nghiệp vụ (business model). Nó có thể che đi
toàn bộ thông tin về việc sử dụng các hệ thống xử lí dữ liệu tự động. Mô hình này
độc lập với cách thức hệ thống được triển khai. Trong đặc tả MDA của một hệ
thống, các yêu cầu CIM nên có khả năng truy nguyên mô hình PIM, PSM và ngược
lại.
-7-
Model-Driven Architecture and Ontology Management
Hình 4: Các bước chính trong chu trình phát triển của MDA
Chu trình MDA có vẻ như rất giống sự phát triển truyền thống. Tuy nhiên,
vẫn có các sự khác nhau. Theo truyền thống, sự chuyển đổi từ mô hình sang mô
hình và từ mô hình sang code chủ yếu được làm bằng tay. Cũng có những công cụ
tạo một số mẫu code từ một mô hình, nhưng thường nó không làm gì hơn là tạo một
số đoạn code mẫu, còn hầu hết công việc đều phải thực hiện bằng tay. Ngược lại, sự
chuyển đổi trong MDA luôn được thực hiện nhờ các công cụ tự động. Có những
công cụ còn có thể chuyển từ PSM qua code, vì thực tế là PSM khá gần với code.
Cái mới ở trong MDA là sự chuyển đổi từ PIM qua PSM cũng được làm tự động.

Đây rõ ràng là lợi ích mà MDA mang đến. Sẽ tốn bao nhiêu nỗ lực trong dự án của
bạn để thực hiện công việc khó nhọc là xây dựng một mô hình cơ sở dữ liệu từ một
thiết kế mức cao? Sẽ tốn bao nhiêu thời gian quý báu để xây dựng một mô hình
thành phần COM, hoặc một mô hình thành phần EJB từ cùng thiết kế đó. Đó chính
là lợi ích thiết thực mà MDA đem lại: gánh nặng công việc của các nhà làm IT được
giải phóng nhờ vào sự tự động trong công việc của họ.
Hiện nay, khái niệm MDA còn khá mới và các công cụ chưa đủ hoàn chỉnh
để chuyển từ PIM sang PSM và từ PSM sang code 100%. Các nhà phát triển cần
phải chỉnh sửa thủ công trên các mô hình PSM và code đã được chuyển đổi. Tuy
nhiên, các công cụ hiện tại có thể tạo ra một ứng dụng chạy được từ một PIM với
các chức năng cơ bản, như là tạo và thay đổi các đối tượng trong hệ thống.
Quy trình MDA chỉ ra vai trò của các mô hình khác nhau (PIM, PSM và
code) trong MDA framework. Một công cụ chuyển đổi lấy một PIM chuyển qua
PSM, và một công cụ khác (hoặc cùng công cụ đó) chuyển PSM đó sang code.
Những sự chuyển đổi này là bản chất của quy trình phát triển MDA. Các công cụ
chuyển đổi được thấy như là một hộp đen, nó lấy một mô hình làm input và sinh ra
output là mô hình thứ hai.
Đi sâu vào bên trong các công cụ chuyển đổi, ta có thể thấy các thành phần
của công cụ thực hiện việc chuyển đổi. Một trong những thành phần đó là các định
nghĩa mô tả làm thế nào thực hiện việc chuyển đổi một mô hình. Ta gọi định nghĩa
đó là định nghĩa chuyển đổi (definition transformation). Hình 5 chỉ ra cấu trúc bên
trong của các công cụ chuyển đổi.
Hình 5: Các định nghĩa chuyển đổi trong các công cụ chuyển đổi
Chú ý rằng các công cụ chuyển đổi có thể sử dụng cùng một định nghĩa
chuyển đổi cho bất kỳ mô hình input nào. Để cho các đặc tả chuyển đổi có thể được
sử dụng lặp lại và độc lập với mô hình nguồn áp dụng, các đặc tả đó phải có liên
quan đến kiến trúc ngôn ngữ nguồn cũng như kiến trúc ngôn ngữ đích. Ví dụ: khi
định nghĩa một định nghĩa chuyển đổi từ UML qua C# thì cần phải mô tả những
-8-
Model-Driven Architecture and Ontology Management

kiến trúc liên quan để C# có thể được tạo ra từ một (hay bất kỳ) mô hình UML nào.
Như mô tả ở hình sau:
Hình 6: Định nghĩa chuyển đổi được định nghĩa giữa các ngôn ngữ
Chúng ta có thể phát biểu rằng các định nghĩa chuyển đổi cấu tạo bởi một tập
các luật chuyển đổi, đó là các đặc tả rõ ràng về cách một mô hình có thể được sử
dụng để tạo ra một hoặc một phần mô hình khác. Dựa trên quan sát đó, ta có thể
định nghĩa sự chuyển đổi, các luật chuyển đổi, và sự định nghĩa chuyển đổi như
sau:
- Một sự chuyển đổi là một sự sinh tự động mô hình đích từ mô hình
nguồn theo một sự định nghĩa chuyển đổi.
- Một sự định nghĩa chuyển đổi là một tập các luật chuyển đổi, mô tả
cách chuyển một mô hình trong ngôn ngữ nguồn sang mô hình trong
ngôn ngữ đích.
- Một luật chuyển đổi là một sự mô tả cách mà một hay nhiều kiến trúc
trong ngôn ngữ nguồn chuyển thành một hay nhiều kiến trúc trong ngôn
ngữ đích.
Đặc điểm quan trọng nhất của sự chuyển đổi là nó phải giữ được ý nghĩa
giữa mô hình nguồn và đích. Dĩ nhiên, ý nghĩa của một mô hình chỉ có thể giữ được
tới mức độ mà nó đã thể hiện trong cả mô hình nguồn và đích. Ví dụ, sự đặc tả hành
vi có thể là một phần của mô hình UML, nhưng không phải là một phần của mô
hình thực thể quan hệ (Entity-Relationship, ER). Tuy nhiên, mô hình UML có thể
chuyển thành một mô hình ER, và chỉ giữ được các đặc điểm cấu trúc của hệ thống.
Hình 7 cho thấy một ví dụ đơn giản của một mô hình độc lập platform (PIM)
và sự chuyển đổi nó thành mô hình đặc trưng platform (PSM).
-9-
Model-Driven Architecture and Ontology Management
Hình 7: Một ví dụ đơn giản của việc chuyển đổi PIM thành PSM
Mô hình PIM trong hình trên biểu diễn một khách hàng và tài khoản. Ở mức
độ trừu tượng này, mô hình mô tả các đặc điểm quan trọng của domain theo quan
điểm các lớp và các thuộc tính của nó, nhưng không mô tả bất kỳ sự lựa chọn

platform-specific nào về công nghệ sẽ được sử dụng để biểu diễn chúng. Hình trên
minh hoạ ba ánh xạ (hoặc chuyển đổi) cụ thể, được định nghĩa để tạo các PSM,
cùng với những tiêu chuẩn được sử dụng để diễn tả các ánh xạ đó. Ví dụ, một trong
những cách tiếp cận là xuất PSM được mô tả trong UML thành định dạng XMI, sử
dụng các định nghĩa tiêu chuẩn như XML Schema Definitions (XSD) hoặc
Document Type Definitions (DTD). Sau đó, nó có thể được sử dụng như là input
cho một công cụ sinh mã để tạo ra các định nghĩa giao diện trong Java đối với mỗi
lớp được định nghĩa trong UML.
Thông thường, một tập các quy tắc được xây dựng sẵn trong các công cụ
sinh mã để thực hiện việc chuyển đổi. Tuy nhiên, công cụ sinh mã thường cho phép
những quy tắc này có thể được định nghĩa cụ thể như là các template trong một
ngôn ngữ kịch bản.
1.5. MDA Framework
Các thành phần chính của MDA framework:
- Mô hình: mô hình là một sự đặc tả hệ thống theo một góc nhìn nào đó
(không gian, thời gian, tĩnh, động…).
- Ngôn ngữ: Một mô hình được viết ở trong một ngôn ngữ được định nghĩa
tốt.
- Định nghĩa chuyển đổi: Một định nghĩa chuyển đổi mô tả cách để chuyển
đổi một mô hình trong ngôn ngữ nguồn sang một mô hình trong ngôn ngữ đích.
-10-
Customer
Name: String
SSN: Integer
Children: Integer
Account
Id: Integer
Name: String
Balance: Float
Java, C# (PSM)

Class Customer {
public string Name;
public int SSN;
public int Children;
}
Computation
Independent
Business Model
Computation
Independent
Model View
Platform Specific
Design and
Implementation Model
Mappings
PIM - PSM
XMI
XSD, DTD
XMI
XSD, DTD
MOF, JMI
MOF, JMI
JOLAP, JDM
UML4EJB…
JOLAP, JDM
UML4EJB…
Platform Independent
Models (PIM)
Platform Specific
Models (PSM)

Model-Driven Architecture and Ontology Management
- Công cụ (tool) thực hiện sự chuyển đổi đó: Một công cụ chuyển đổi thực
hiện một sự chuyển đổi cho một mô hình nguồn xác định theo một định nghĩa
chuyển đổi.
Hình 8: MDA framework cơ bản
Từ góc nhìn của nhà phát triển, PIM và PSM là các thành phần quan trọng
nhất. Một nhà phát triển tập trung vào sự phát triển một PIM, mô tả hệ thống phần
mềm ở một mức trừu tượng cao. Tiếp đến, người đó sẽ chọn một hoặc một vài công
cụ có thể thực hiện việc chuyển đổi trên PIM theo một định nghĩa chuyển đổi cụ thể
đã xác định nào đó. Kết quả sẽ sinh ra một PSM, và sau đó được chuyển sang code.
Trong hình 8 chỉ có một PSM, nhưng thường từ một PIM sẽ sinh ra nhiều
PSM và các cầu nối tiềm năng giữa các PSM đó. Hình trên cũng chỉ mô tả sự
chuyển đổi từ PIM sang PSM, ngoài ra còn phải có thêm quá trình chuyển từ PSM
sang code.
Có hai nguyên nhân khiến các siêu mô hình là quan trọng trong MDA. Thứ
nhất, chúng ta cần một cơ chế để định nghĩa các ngôn ngữ lập mô hình, và các định
nghĩa này không được mơ hồ. Các công cụ chuyển đổi có thể đọc, viết, hiểu các mô
hình được định nghĩa đó. Trong MDA, chúng ta định nghĩa các ngôn ngữ này thông
qua các siêu mô hình. Thứ hai, một định nghĩa chuyển đổi bao gồm các luật chuyển
đổi mô tả cách chuyển đổi một mô hình trong ngôn ngữ nguồn sang mô hình trong
ngôn ngữ đích. Ở đây chỉ muốn nhấn mạnh rằng để có thể hiểu và tạo ra các định
nghĩa chuyển đổi, chúng ta cần hiểu các siêu mô hình trong ngôn ngữ nguồn và
đích.
Hình 9 chỉ ra một MDA framework đầy đủ ở mức siêu mô hình. Một nửa
phía dưới của hình này giống với hình MDA framework cơ bản. Nửa này chính là
cái mà các nhà phát triển sẽ thấy cuối cùng. Nửa phía trên của hình giới thiệu siêu
ngôn ngữ để định nghĩa các ngôn ngữ.
-11-
Model-Driven Architecture and Ontology Management
Hình 9: Framework MDA mở rộng, bao gồm cả siêu ngôn ngữ

Các nhà phát triển sẽ chỉ cần thấy MDA framework cơ bản, không thêm siêu
mức (metalevel). Một nhóm nhỏ các nhà phát triển, thường là những người có kinh
nghiệm, sẽ định nghĩa các ngôn ngữ cũng như các sự chuyển đổi giữa các ngôn ngữ
đó. Và họ bắt buộc phải hiểu thấu đáo siêu mức ở trong MDA framework mở rộng
trên.
Một điều dĩ nhiên là các định nghĩa chuyển đổi phải được viết trong một
ngôn ngữ hoàn toàn xác định (well-defined language) để cho phép các công cụ
chuyển đổi có thể đọc và thực thi sự chuyển đổi. Một ngôn ngữ được dùng để viết
các định nghĩa chuyển đổi gọi là ngôn ngữ định nghĩa chuyển đổi (transformation
definition language). Với các ngôn ngữ đó, ta có thể định nghĩa sự chuyển đổi dựa
trên các siêu mô hình của nó. Bởi vì ta đang làm việc ở siêu mức, do đó, một ngôn
ngữ định nghĩa sự chuyển đổi được gọi là một siêu ngôn ngữ.
Một MDA framework sẽ không đầy đủ nếu thiếu một ngôn ngữ định nghĩa
sự chuyển đổi. Hình sau là một MDA framework đầy đủ. Nó giống với MDA
framework mở rộng giới thiệu ở trên, chỉ khác là có thêm ngôn ngữ định nghĩa sự
chuyển đổi.
-12-
Model-Driven Architecture and Ontology Management
Hình 10: MDA framework đầy đủ
1.6. Kiến trúc của MDA
MDA bao gồm kiến trúc metamodeling bốn tầng: tầng meta-metamodel
(M3), tầng metamodel (M2), tầng model (M1), và tầng instance (M0). Ngoài ra, mô
hình MDA có liên quan đến nhiều tiêu chuẩn, bao gồm Unified Modeling Language
(UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI),
Enterprise Distributed Object Computing (EDOC), Software Process Engineering
Metamodel (SPEM), và Common Warehouse Metamodel (CWM). Lưu ý rằng thuật
ngữ “kiến trúc” trong MDA không phải là kiến trúc của hệ thống đang được mô
hình hóa, mà là kiến trúc của các tiêu chuẩn và các hình thức mô hình khác nhau, nó
như là nền tảng công nghệ cho MDA.
Kiến trúc MDA được dựa trên nguyên lý sử dụng các ngôn ngữ mô hình hóa

để mô tả một hệ thống ở các cấp độ khác nhau: mô hình độc lập tính toán (CIM)
biểu diễn môi trường và các yêu cầu của hệ thống, mô hình độc lập platform (PIM)
mô tả kiến trúc hệ thống theo một cách thức trung lập với công nghệ, và mô hình
platform cụ thể (PSM) mở rộng PIM với các đặc tả chi tiết về việc mô hình được
triển khai như thế nào trên một platform (một tập hệ thống con và các công nghệ) cụ
thể. Góc nhìn bên dưới MDA là việc các ánh xạ tự động có thể được sử dụng để
chuyển từ một PSM thành một PIM (khi một platform cụ thể đã được xác định) và
giữa một PSM và code. Trên thực tế, việc này được thực hiện dựa vào một số các
công nghệ của OMG, đặc biệt là Meta-Object Facility (MOF), XML Metadata
Interchange (XMI) framework, Unified Modeling Language (UML), UML profile
và ngôn ngữ Query/Views/Transformations (QVT). Chúng được thiết kế để cung
cấp một framework chung để định nghĩa các ngôn ngữ mô hình hóa và các ký hiệu
-13-
Model-Driven Architecture and Ontology Management
đồ họa dựa trên UML tương ứng, và phương tiện để xây dựng các bộ soạn thảo và
kho mô hình có các định dạng chuẩn và các giao diện để trao đổi và tương tác với
các mô hình.
Hình 11: Kiến trúc siêu dữ liệu bốn tầng của MDA
Trên đỉnh của kiến trúc MDA là meta-metamodel (MOF). Nó là một
framework và ngôn ngữ tự định nghĩa, trừu tượng để đặc tả, xây dựng và quản lý
các metamodel trung lập với kỹ thuật. Nó là nền tảng để xác định bất kỳ một ngôn
ngữ mô hình hóa nào như UML hoặc thậm chí là bản thân MOF. MOF cũng định
nghĩa một framework để triển khai các kho chứa metadata (ví dụ, các mô hình)
được mô tả bởi các metamodel. Mục tiêu chính của cấu trúc bốn tầng với một meta-
metamodel chung là nhằm hỗ trợ nhiều metamodel và model, nhằm cho phép khả
năng mở rộng, tích hợp và quản lý model và metamodel chung.
Mọi metamodel, tiêu chuẩn hoặc tùy chỉnh (do người sử dụng định nghĩa),
được xác định bởi MOF đều được đặt trên tầng M2. Một trong số đó là UML, một
ngôn ngữ mô hình đồ họa cho việc đặc tả các hệ thống phần mềm. Với các UML
profile, các khái niệm UML cơ bản (Class, Association, v.v.) có thể được mở rộng

với những khái niệm mới (stereotype) và thích nghi với nhu cầu của một sự mô hình
hóa cụ thể. Các mô hình của thế giới thực, được biểu diễn bởi các khái niệm được
định nghĩa trong metamodel tương ứng tại tầng M2 (ví dụ như metamodel UML)
nằm ở tầng M1. Cuối cùng, tại tầng M0, là những thứ từ thế giới thực đã được mô
hình hóa trong tầng M1. Ví dụ như: MOF Class (tại tầng M3) được dùng để định
nghĩa khái niệm UML Class (M2), UML Class được dùng để xác định khái niệm
Person (M1), và Tom, Dick và Harry (UML Objects) biểu diễn cho thực tế (M0).
Nằm ở dưới cùng của kiến trúc này là tầng Instance (M0). Có hai phương
pháp tiếp cận để mô tả tầng này:
1. Tầng Instance bao gồm các thể hiện của các khái niệm được định
nghĩa trong tầng model (M1), ví dụ như các đối tượng trong ngôn ngữ lập
trình.
-14-
Model-Driven Architecture and Ontology Management
2. Tầng Instance bao gồm những thứ trong thế giới thực, cả cụ thể (ví
dụ Mark là một thể hiện của lớp Person, Lassie là một thể hiện của lớp Dog)
lẫn trừu tượng (ví dụ các lớp OML như Person, Dog, v.v.).
Trong nghiên cứu này, chúng tôi nghiêng về phương pháp thứ hai, nhưng ta
cần phải trình bày một số chi tiết về tác động của nó trong UML. Trong UML, cả
các class và các object đều thuộc cùng một layer (là model layer) trong kiến trúc 4
tầng của MDA. Các tầng MDA được gọi là các tầng ngôn ngữ. Mặt khác, các khái
niệm của cùng một tầng ngôn ngữ có thể nằm ở các tầng ontology khác nhau. Do
đó, các lớp và đối tượng UML nằm ở các tầng ontology khác nhau, nhưng lại thuộc
cùng một tầng ngôn ngữ.
Ngoài các chuẩn đã nói ở trên, MDA được dựa trên XMI, là một chuẩn dùng
để định nghĩa các ánh xạ của các metametamodel, metamodel và model dựa trên
MDA thành các XML document và các XML schema. Bởi vì XML đã được hỗ trợ
rộng rãi bởi nhiều công cụ phần mềm, điều đó làm cho XMI có thể thực hiện việc
chuyển đổi các metametamodel, metamodel và model tốt hơn.
1.7. Các lợi ích từ MDA

Tính khả chuyển đổi (Portability)
Trong MDA, tính khả chuyển đạt được nhờ tập trung vào sự phát triển các
PIM. Cùng một PIM có thể được chuyển tự động sang nhiều PSM của các platform
khác. Do đó, mọi thứ xác định ở mức PIM là hoàn toàn khả chuyển. Sự mở rộng
của tính khả chuyển có thể đạt được và phụ thuộc vào các công cụ chuyển đổi tự
động sẵn có. Có một loạt các công cụ chuyển đổi tự động có sẵn để hỗ trợ cho
những platform phổ biến. Còn với những platform ít phổ biến hơn, bạn có thể phải
sử dụng một công cụ hỗ trợ việc định nghĩa chuyển đổi dưới dạng plug-in và tự ta
phải viết các định nghĩa chuyển đổi đó. Với những công nghệ và platform sẽ có
trong tương lai, công nghệ phần mềm phải thực hiện sự chuyển đổi tương ứng kịp
thời. Điều này cho phép chúng ta triển khai nhanh các hệ thống mới với công nghệ
mới, dựa trên các PIM đã tồn tại.
Hiệu suất (Productivity)
Trong MDA, tiêu điểm của các nhà phát triển là hướng vào sự phát triển một
PIM. Các PSM cũng cần được tạo ra thông qua sự chuyển từ PIM qua PSM. Dĩ
nhiên là có một vài người cần định nghĩa sự chuyển đổi chính xác, đây là một việc
rất là khó khăn và mang tính chuyên môn. Tuy thế sự chuyển đổi này chỉ cần được
định nghĩa một lần và sau đó có thể được áp dụng trong sự phát triển của nhiều hệ
thống. Chi phí cho các nỗ lực để định nghĩa sự chuyển đổi là rất lớn và nó chỉ có thể
được làm bởi những người có kỹ năng rất cao. Phần lớn các nhà phát triển sẽ nhắm
vào sự phát triển PIM. Bởi vì họ có thể làm việc độc lập với các chi tiết cụ thể và
riêng biệt của platform đích nên có nhiều chi tiết cụ thể về kĩ thuật mà họ không cần
quan tâm đến. Các chi tiết kĩ thuật cụ thể đó sẽ được tự động thêm vào khi thực hiện
chuyển từ PIM qua PSM. Điều này sẽ cải tiến năng suất qua hai cách:
• Đầu tiên các nhà phát triển có ít công việc cần phải làm bởi vì platform cụ
thể không cần được thiết kế và viết ra; chúng sẽ được đưa vào trong sự định nghĩa
-15-
Model-Driven Architecture and Ontology Management
chuyển đổi mô hình. Tại mức PSM và code, không cần phải viết nhiều code, bởi vì
một lượng lớn code đã được tự động sinh ra từ PIM.

• Điều cải tiến thứ hai xuất phát từ sự thật là các nhà phát triển có thể thay
đổi đích nhắm của họ từ code sang PIM, nhờ đó họ có thể tập trung nhiều hơn vào
sự giải quyết các vấn đề nghiệp vụ. Do vậy hệ thống đáp ứng tốt hơn các nhu cầu
của người dùng cuối. Người dùng cuối sẽ có được nhiều chức năng tốt hơn trong
thời gian ngắn hơn.
Các lợi ích về hiệu suất chỉ có thể đạt được bằng cách sử dụng các công cụ
tạo các PSM từ một PIM tự động hoàn toàn. Điều này đồng nghĩa với việc nhiều
thông tin về ứng dụng phải được kết hợp chặt chẽ ở trong PIM và (hoặc) trong các
công cụ. Bởi vì mô hình ở mức cao không chỉ “nằm trên giấy”, mà nó có liên hệ
trực tiếp đến việc tạo code, yêu cầu về sự đầy đủ và nhất quán của mô hình ở mức
cao (PIM) cao hơn so với sự phát triển truyền thống.
Tính cộng tác với các hệ thống khác (Interoperability)
Ở các phần trước chúng ta đã thấy chưa hoàn chỉnh bức tranh tổng thể của
MDA. Như ở hình dưới, nhiều PSM được sinh ra từ một PIM có thể có các mối
quan hệ. Khi các PSM được nhắm đến các platform khác nhau, chúng không thể
tương tác trực tiếp với nhau. Bằng cách này hay cách khác, chúng ta cần chuyển đổi
các khái niệm của một platform này vào các khái niệm của một platform khác. Và
đây chính là cái mà tính cộng tác với các hệ thống khác đề cập đến. MDA giải quyết
vấn đề này bằng cách tạo ra không chỉ các PSM mà còn các cầu nối (bridge) giữa
các PSM đó.
Hình 12: Tính cộng tác với các hệ thống khác trong MDA sử dụng các cầu nối
Nếu ta có thể chuyển một PIM thành hai PSM đích ở hai platform khác nhau,
tất các những thông tin mà chúng ta cần để kết nối khoảng trống giữa hai PSM là
sẵn có. Với mỗi thành phần ở trong PSM thứ nhất ta biết được nó được chuyển qua
từ thành phần nào trong PIM. Và từ thành phần PIM đó, ta biết được thành phần
nào tương ứng trong PSM thứ hai. Từ đó ta suy ra được các thành phần của PSM
thứ nhất liên quan với các thành phần của PSM thứ hai như thế nào. Hơn nữa ta
-16-
Model-Driven Architecture and Ontology Management
cũng đã biết tất cả các chi tiết kĩ thuật các platform xác định của hai PSM (vì nếu

ngược lại ta không thể thực hiện sự chuyển từ PIM sang PSM) do đó ta có tất cả
thông tin cần thiết để sinh ra cầu nối giữa hai PSM.
Ví dụ, một PSM là mô hình Java (code) và một PSM khác là mô hình cơ sở
dữ liệu (CSDL) quan hệ. Với mỗi thành phần Customer ở trong PIM, ta biết được
nó chuyển thành lớp Java (Java class) nào. Chúng ta cũng biết thành phần Customer
này được chuyển thành bảng (table) nào. Xây dựng một cầu nối giữa một đối tượng
Java trong PSM Java và một bảng trong PSM CSDL quan hệ là một việc dễ dàng.
Để truy xuất một đối tượng từ CSDL, ta thực hiện truy vấn từ các bảng được
chuyển đổi từ thành phần Customer, và thao tác trên các lớp ở trong PSM với dữ
liệu đã có. Để lưu trữ một đối tượng, ta tìm dữ liệu trong đối tượng Java và lưu trữ
chúng ở trong bảng Customer.Tính cộng tác giữa các platform được thực hiện bởi
các công cụ sinh ra không chỉ các PSM mà còn các cầu nối giữa chúng.
Việc bảo trì và lập tài liệu (Maintenance and Documentation)
Khi làm việc trong chu kỳ phát triển MDA, các nhà phát triển tập trung vào
PIM, một mức trừu tượng cao hơn code. PIM được sử dụng để tạo ra PSM, và từ đó
tạo ra code. Mô hình là một sự thể hiện chính xác của code. Do vậy, PIM thực hiện
chức năng lập tài liệu ở mức cao, đây là điều cần thiết cho bất kỳ hệ thống phần
mềm nào.
Một sự khác biệt lớn là PIM không bị bỏ đi sau khi sử dụng. Các thay đổi
trên hệ thống sẽ được làm trên PIM rồi sinh lại PSM và code. Thực tế hiện nay,
nhiều thay đổi được làm trên PSM và sau đó tạo lại code. Tuy nhiên, một công cụ
tốt phải duy trì được mối quan hệ giữa PIM và PSM, ngay cả khi có những thay đổi
trên PSM. Các thay đổi trên PSM do đó sẽ ánh xạ trở lại PIM, và tài liệu ở mức cao
sẽ giữ được sự nhất quán với code thật sự.
1.8. Meta-Object Facility (MOF)
Meta-Object Facility (MOF) bắt nguồn từ một sự điều chỉnh của lõi UML để
đáp ứng nhu cầu của MDA. MOF về cơ bản là một tập tối thiểu của các khái niệm
có thể được sử dụng để định nghĩa các ngôn ngữ mô hình hóa khác. Nó tương tự
(nhưng không phải giống hệt) với một phần của UML được sử dụng trong mô hình
hóa cấu trúc. Trong phiên bản mới nhất (2.0), các khái niệm của MOF và kiến trúc

thượng tầng của UML, có nguồn gốc từ các khái niệm của cơ sở hạ tầng UML.
Về cơ bản, có một chuẩn OMG được gọi là cơ sở hạ tầng UML, chứa các
khái niệm cơ bản được dự định sử dụng trong các metamodel khác. Hình 13 cho
thấy sự phụ thuộc của một số metamodel được sử dụng rộng rãi dựa trên các gói lõi
UML.
-17-
Model-Driven Architecture and Ontology Management

Hình 13: Gói lõi UML được xem như là một nhân chung
Gói lõi UML định nghĩa một cách chính xác những khái niệm cơ bản thường
xuyên được sử dụng trong mô hình hóa. Một sự khác biệt đáng chú ý đối với phiên
bản cũ hơn là mỗi khái niệm trong phiên bản mới tập trung vào một số khía cạnh
nhỏ. Điều này cho phép các khái niệm dễ dàng được kết hợp trong các metamodel
khác nhau, tránh sử dụng những khía cạnh không cần thiết. Trong phiên bản 2.0 của
chuẩn MOF, có hai metametamodel để lựa chọn:
- MOF cơ bản (EMOF);
- MOF đầy đủ (CMOF).
EMOF nghiêng về tính đơn giản của quá trình triển khai trong khi CMOF thì
diễn đạt nhiều hơn, nhưng phức tạp hơn và khó thực thi hơn. Hình sau cho thấy
EMOF và CMOF và sự phụ thuộc của chúng.

Hình 14: EMOF và CMOF và sự phụ thuộc của chúng
-18-
Model-Driven Architecture and Ontology Management
Từ hình trên, chúng ta có thể thấy rằng EMOF có nguồn gốc chủ yếu là từ
các gói cơ bản của cơ sở hạ tầng UML, trong khi CMOF mở rộng EMOF sử dụng
các khái niệm từ gói Constructs (là một phần của cơ sở hạ tầng UML).
Về cơ bản, bốn khái niệm mô hình hóa chính trong MOF là:
- Lớp (Class) – mô hình các siêu đối tượng (metaobject) và khái niệm
MOF, đó là các thực thể trong các metamodel (tức là UML Class,

Attribute và Association, ODM Class, Property, v.v., và thậm chí là các
khái niệm MOF như Class hay Property);
- Mối quan hệ liên kết (Association) – mô hình các mối quan hệ nhị
phân (ví dụ: các lớp cha (superclasses) của UML hoặc MOF hoặc các
thuộc tính cha (superproperties) của ODM);
- Kiểu dữ liệu (DataType) – mô hình các kiểu nguyên thủy (String,
Integer, v.v.);
- Gói (Package) – mô đun hóa các khái niệm khác; ví dụ, nó nhóm các
khái niệm tương tự nhau.
Tất nhiên, có rất nhiều khái niệm như vậy, nhưng đây là những khái niệm
quan trọng nhất và được sử dụng thường xuyên nhất. Hình sau cho ta một cái nhìn
về metamodel. Nó cho thấy một phần định nghĩa MOF của một metamodel.

Hình 15: Định nghĩa của một phần của một metamodel (trong trường hợp này,
EMOF được định nghĩa trong phạm vi chính nó)
Không được nhầm lẫn bởi thực tế là Class của MOF được định nghĩa bằng
cách sử dụng MOF Class. Điều này cũng giống như định nghĩa các từ trong từ điển:
một từ được định nghĩa bằng một số từ khác, nhưng tất cả các từ được định nghĩa
bằng các từ ở cùng một từ điển. Ví dụ, định nghĩa của “or” trong từ điển có thể bao
gồm câu sau: “restating or clarifying the first item mentioned”. Như thế, định nghĩa
của “or” bao gồm từ mà nó định nghĩa! Về các metamodel khác được định nghĩa tại
-19-
Model-Driven Architecture and Ontology Management
EMOF, có một phần của cơ sở hạ tầng UML định nghĩa khái niệm UML Class, và
biểu đồ đó rất giống với sơ đồ thể hiện trong hình trên.
1.9. Các metamodel MDA đặc trưng
Để minh họa ứng dụng của ngôn ngữ MOF, trong phần này mô tả 3
metamodel MOF nổi bật được định nghĩa trong các đặc tả của OMG.
1.9.1. Unified Modeling Language (UML)
UML là một ngôn ngữ dùng để đặc tả, trực quan hóa và lập tài liệu cho các

hệ thống phần mềm cũng như mô hình hóa các hoạt động nghiệp vụ và các hệ thống
không phải là phần mềm khác. UML chính là kết quả tốt nhất của quá trình thực
nghiệm trong mô hình hóa và đã được chứng minh thành công trong việc mô hình
hóa nhiều hệ thống lớn và phức tạp.
Như đã đề cập trước, phần lõi UML cũng tương tự như MOF. Do đó, chúng
ta không thảo luận về các thành phần của nó. UML thường được nhận dạng như
một phép ký hiệu đồ họa. Gần đây, UML đã được công nhận thêm như một ngôn
ngữ độc lập của bất kỳ ký hiệu đồ họa chứ không chỉ là các ký hiệu đồ họa như
trước.
Tuy nhiên, UML cũng có vai trò rất quan trọng với tư cách là một ngôn ngữ
dành cho việc biễu diễn bằng đồ họa của các mô hình trong các hệ thống phần mềm.
UML có các đặc trưng để nhấn mạnh các khung nhìn đặc thù của một mô hình bằng
cách sử dụng việc biểu diễn đồ hoạ, gọi là các lược đồ UML. Từ đó ta có thể tóm tắt
các mô hình; nếu không thì ta sẽ không thể phân tích và giải quyết các hệ thống
phức tạp. UML định nghĩa các loại biểu đồ sau để có những cách nhìn khác nhau
của các mô hình:
- Biểu đồ Use Case
- Biểu đồ lớp
- Biểu đồ trạng thái: Biểu đồ Statechart và Biểu đồ hoạt động
- Biểu đồ tương tác: Biểu đồ tuần tự và Biểu đồ cộng tác
- Biểu đồ cài đặt: Biểu đồ thành phần và Biểu đồ triển khai
Những biểu đồ này cung cấp cho các nhà phát triển những góc nhìn khác
nhau về hệ thống đang được nghiên cứu hoặc phát triển. Một mô hình nắm giữ toàn
bộ hệ thống và được biễu diễn đồ họa bởi các biểu đồ chỉ tích hợp tất cả những góc
nhìn này vào một thực thể chung, bao gồm sự kết hợp tất cả các chi tiết mô hình hóa
của hệ thống đó.
1.9.2. Common Warehouse Metamodel (CWM)
Sự phức tạp và đa dạng của các lĩnh vực được mô tả bằng các metamodel có
nghĩa là nhiều metamodel khác nhau không ngừng được phát triển. Ngay cả khi
những metamodel đó được dựa trên cùng một metametamodel, sự tương tác của

chúng đòi hỏi một số cầu nối (chẳng hạn như các phép biến đổi). Vấn đề này được
nhấn mạnh trong lĩnh vực kho dữ liệu, trong đó nhằm đến việc điều khiển và tích
hợp dữ liệu dựa trên một số lượng lớn các metamodel khác nhau.
-20-
Model-Driven Architecture and Ontology Management
Hình 16: Cấu trúc của CWM
Common Warehouse Metamodel (CWM) là một chuẩn công nghiệp mở của
OMG dành cho các công cụ tích hợp đối với kho dữ liệu và phân tích nghiệp vụ. Nó
dựa trên cơ sở sử dụng siêu dữ liệu phổ biến. CWM là một ví dụ về một cách tiếp
cận tích hợp siêu dữ liệu dựa trên mô hình. Nó không phải là một metamodel
nguyên khối, mà trên thực tế nó bao gồm nhiều mô hình khác nhau nhưng lại có
liên quan với nhau. Mỗi mô hình là một subdomain thông tin trong một chuỗi
nghiệp vụ. Hình trên cho ta thấy sơ đồ khối của tổ chức CWM, cụ thể là các
metamodel chứa trong CWM.
CWM bao gồm một số metamodel được tổ chức thành các lớp sau: Object
Model, Foundation, Resource, Analysis, và Management. Các Metamodel nằm ở
những lớp cao hơn dựa vào các Metamodel từ các lớp thấp hơn. Lớp cơ sở (Object
Model) dựa trên UML, UML thực sự là một tập cha của nó. Trong hình trên, chúng
ta đã nhấn mạnh đến các metamodel có liên quan nhiều hơn đến việc thiết kế các
metamodel của các hệ thống thông tin thông minh. Ví dụ: metamodel Data Mining
thuộc về nhóm các metamodel của các hệ thống thông tin thông minh.
CWM có ảnh hưởng lớn đến sự tích hợp các metamodel trong các hệ thống
thông tin thông minh. Nó có thể được sử dụng như một nền tảng mở rộng hoặc một
khuôn mẫu trong việc xây dựng các metamodel mới.
1.9.3. Ontology Definition Metamodel (ODM)
MDA và kiến trúc bốn tầng của nó cung cấp một cơ sở vững chắc để xác
định các metamodel của bất kỳ ngôn ngữ mô hình hóa nào, vì vậy việc xác định một
ngôn ngữ mô hình hóa ontology trong MOF là sự lựa chọn đúng đắn. Các ngôn ngữ
đó có thể tận dụng sự hỗ trợ của MDA trong các công cụ mô hình hóa, quản lý mô
hình và khả năng tương tác với các metamodel khác. Hiện nay các công cụ phần

mềm không cài đặt nhiều khái niệm cơ bản của MDA. Tuy nhiên, hầu hết các ứng
dụng này, mà chủ yếu là hướng đến UML và tầng Modeling Layer (M1), dự kiến sẽ
được nâng cấp để hỗ trợ MDA.
Hiện nay, có một yêu cầu đề xuất (Request for Proposal) nằm trong OMG
nhằm xác định một ngôn ngữ phù hợp cho việc mô hình hóa các ngôn ngữ Semantic
-21-
Model-Driven Architecture and Ontology Management
Web ontology trong ngữ cảnh của MDA. Đề xuất này là kết quả của một nghiên
cứu ở phạm vi rộng trước đây trong các lĩnh vực của MDA và ontology. Đề xuất
này quy định các thành phần quan trọng nhất phải có trong bản đặc tả OMG cuối
cùng, cụ thể là:
- Ontology Definition Metamodel (ODM). ODM nên được thiết kế để bao
hàm được các khái niệm ontology thông dụng. Một khởi điểm tốt cho xây dựng
ODM là OWL vì nó là kết quả của sự phát triển của các ngôn ngữ hiện tại biểu diễn
ontology.
- Ontology UML Profile: Để sử dụng khả năng mô hình hóa trên giao diện
đồ họa của UML, ODM cũng đồng thời định nghĩa một ontology UML profile để
hỗ trợ các ký pháp UML cho định nghĩa ontology. Profile này cho phép việc chỉnh
sửa đồ họa các ontologies sử dụng các biểu đồ UML cũng như các lợi ích khác của
việc sử dụng các công cụ UML CASE. Cả hai mô hình UML và ODM đều được sắp
xếp ở định dạng XMI nên việc chuyển đổi hai chiều giữa chúng có thể được thực
hiện bằng cách sử dụng XSL Transformation. OWL còn được biểu diễn theo định
dạng XML, do đó, cần cung cấp một cặp XSL Transformation khác cho việc ánh xạ
hai chiều giữa ODM và OWL.
- Các ánh xạ hai chiều giữa OWL và ODM; giữa ODM và các metamodel
khác; giữa ODM và Ontology UML Profile; giữa Ontology UML Profile và các
UML profile khác.
1.10. UML Profiles
UML profile là một khái niệm được sử dụng để điều chỉnh các cấu trúc UML
cơ bản cho một mục đích cụ thể. Về cơ bản, điều này có nghĩa là giới thiệu các loại

phần tử mô hình hóa mới bằng cách mở rộng các phần tử cơ bản, và đưa chúng vào
các công cụ. Ngoài ra, thông tin dạng tự do có thể được gắn vào các thành phần mô
hình hóa mới.
Các cấu trúc UML cơ bản (các phần tử mô hình) có thể được tùy chỉnh và
mở rộng với ngữ nghĩa mới bằng cách sử dụng bốn cơ chế mở rộng UML được định
nghĩa trong đặc tả UML: stereotype (khuôn mẫu), các định nghĩa thẻ, các giá trị thẻ
(tagged values), và các ràng buộc.
Stereotype cho phép định nghĩa các lớp con ảo của các metaclass UML, bằng
cách gán cho nó những ngữ nghĩa bổ sung. Ví dụ, nếu muốn định nghĩa một
stereotype «OntClass» (xem hình sau) bằng cách mở rộng lớp UML «metaclass» để
chỉ rõ thành phần mô hình hóa được sử dụng để biễu diễn cho các lớp ontology.
Các định nghĩa thẻ có thể được gán cho các thành phần mô hình. Chúng cho
phép giới thiệu các loại thuộc tính mới mà các thành phần mô hình có thể có, và
tương tự với các định nghĩa meta-attribute. Mỗi định nghĩa thẻ xác định các giá trị
thực tế của các thuộc tính của các thành phần mô hình riêng biệt; các giá trị này
được gọi là tagged values. Các định nghĩa thẻ có thể được gắn vào một stereotype
để định nghĩa các meta-attribute ảo của nó. Ví dụ, stereotype «OntClass» trong hình
sau có một định nghĩa thẻ xác định bốn tagged values (đối với numeration,
intersection, v v).
-22-