MODEL-DRIVEN ARCHITECTURE AND ONTOLOGY MANAGEMENT

Tiểu luận môn Semantic Web về MODEL-DRIVEN ARCHITECTURE AND ONTOLOGY MANAGEMENT

TIỂU LUẬN MÔN: SEMANTIC WEB

Lớp: Khoa học máy tính, Khóa năm: 2008-2010

Huế, 12/2009

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

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

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 (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

MDA cung cấp một phương pháp tiếp cận để:

- 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

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

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

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

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

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

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

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)

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

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

JOLAP, JDM UML4EJB…

JOLAP, JDM UML4EJB…

Platform Independent

Models (PIM)

Platform Specific Models (PSM)

- 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ữ

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

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

đồ 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

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

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

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

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

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

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

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

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)

Hình 17: Định nghĩa của một stereotype mới

Các ràng buộc cung cấp khả năng làm mịn ngữ nghĩa của thành phần mô hình hóa mà nó được gắn vào Chúng có thể được gắn vào một stereotype bằng cách

sử dụng OCL (Object Constraint Language) hoặc ngôn ngữ nói thông thường để xác định chính xác ngữ nghĩa của stereotype

Một tập hợp nhất quán của các phần mở rộng của các thành phần mô hình UML cơ bản, được định nghĩa cho các mục đích cụ thể hoặc cho một domain mô hình hóa cụ thể, tạo thành một UML Profile Một định nghĩa UML Profile trong ngữ cảnh của kiến trúc mô hình hóa MDA bốn lớp có nghĩa là mở rộng UML ở tầng metamodel (M2) Ta có thể xem một phần mở rộng như thế là một ngôn ngữ mới, nhưng cũng có thể xem UML là một họ các ngôn ngữ Mỗi ngôn ngữ sử dụng các

ký hiệu UML, với bốn cơ chế mở rộng UML Các đặc tả UML gần đây cho phép sử dụng các kí hiệu đồ họa trong việc đặc tả các stereotype và các định nghĩa thẻ Vì vậy, tất cả các stereotype và tagged value được sử dụng trong này đều được định nghĩa theo cách đó

Các ví dụ về UML Profiles

Nhiều UML Profile quan trọng hiện nay đã được phát triển Một số UML Profile đã được chấp nhận bởi OMG, chẳng hạn như UML profile cho CORBA (2002), và UML profile cho Enterprise Applications Intergration (2004) Bên cạnh những đặc tả chính thức này, một số UML profile nổi bật đã được chấp nhận rộng rãi bởi các kỹ sư phần mềm Một trong những profile phổ biến nhất là UML profile

để xây dựng các ứng dụng web được phát triển bởi Jim Conallen (2002) Nhận ra sự thiếu sót của UML nguyên bản trong việc mô hình hóa các ứng dụng web (chẳng hạn như các liên kết, các Web form và các Web page), Conallen mở rộng một số thành phần mô hình UML (chẳng hạn như Class và Attribute) với các thành phần gốc liên quan đến các ứng dụng web (chẳng hạn như server page, client page, form, v.v) Hình sau biểu diễn biểu đồ UML của một ứng dụng web bằng cách sử dụng UML profile của Conallen Biểu đồ chứa các biễu diễn UML của các server pages (spUnbounded), một form, và các nút trên form (Simulate) Trong hình này, chúng tôi đã sử dụng các tính năng đồ họa của công cụ Rational Rose UML cho việc mô hình hóa các ứng dụng Web bằng cách sử dụng UML Profile này Trên thực tế, ta cũng có thể thu được ý nghĩa ngữ nghĩa giống như vậy của một thành phần mô hình UML mở rộng (chẳng hạn như Class) nếu ta sử dụng biểu diễn đồ họa của các thành phần mô hình chuẩn cùng với các phương pháp chuẩn trong việc biểu diễn các stereotype (chẳng hạn nút Simulate trong lớp “form”)

Hình 18: Biểu đồ UML của một ứng dụng Web được mô hình hóa bằng cách sử dụng một UML profile dành cho việc mô hình hóa các ứng dụng Web.

Một UML profile quan trọng khác là dùng cho mô hình hóa XML Schema được phát triển bởi David Carlson (2001) Nắm được nhu cầu của các nhà phát triển các ứng dụng nghiệp vụ trong việc sử dụng một tập hợp các đặc trưng của XML Schema, Carlson thấy rằng các giản đồ kết quả khó chia sẻ rộng rãi giữa nhóm người dùng và các đối tác kinh doanh Trong thực tế, các hình thức khác của sự biểu diễn của các mô hình là có hiệu quả hơn so với giản đồ XML khi xác định các từ vựng mới hoặc chia sẻ các định nghĩa với người dùng Carlson đề xuất việc sử dụng UML như là một tiêu chuẩn để đặc tả và thiết kế hệ thống Hình sau cho thấy ontology Musician được biểu diễn trong UML Profile của Carlson Điều quan trọng cần lưu ý là mỗi lớp và thuộc tính có một stereotype tương ứng (nghĩa là XSDcomplexType và XSDattribute) Bằng cách này, ta có thể ánh xạ mô hình này thành một định nghĩa giản đồ XML sử dụng các công cụ (chẳng hạn như một XSLT

sẽ chuyển đổi biểu diễn XMI của mô hình UML thành định nghĩa giản đồ XML) Bên cạnh các stereotype trong hình bên dưới, UML Profile có chứa tất cả các thành phần nguyên thủy khác cần thiết để cho việc định nghĩa các giản đồ XML

Hình 19: Biểu đồ UML của ontology Musician, biểu diễn với UML profile dành cho

việc mô hình hóa giản đồ XML.

Cuối cùng, lưu ý rằng có rất nhiều UML profile quan trọng khác ngoài những cái đã nói ở trên Một số ví dụ là các UML profile cho thiết kế cơ sở dữ liệu (của Naiburg & Maksimchuk, 2001) và UML profile cho các kiến trúc framework Bởi vì mục tiêu chính của chúng ta là minh họa cho việc sử dụng các tiêu chuẩn MDA để phát triển các ontology, nên ta chỉ bàn chi tiết về Ontology UML Profile

1.11 XML cho việc chia sẻ các MDA Artifacts

XML Metadata Interchange (XMI) là một chuẩn dựa trên XML để chia sẻ MDA metadata Mặc dù tiêu chuẩn này nghe có vẻ như là đã được biết rõ ràng, nhưng nhiều người vẫn lẫn lộn bởi thuật ngữ này Chúng tôi sẽ cố gắng giải thích về XMI Sự nhầm lẫn này xuất phát từ sự hiện diện của các XML schema khác nhau và tất cả chúng đều được gọi là XMI Chúng ta thường gặp hai loại XMI document, hoặc chính xác hơn là hai XML schema định nghĩa XMI:

- XML schema cho các metamodel MOF

- XML schema cho các mô hình UML

XML schema đầu tiên định nghĩa cú pháp để chia sẻ cả các metamodel dựa trên MOF và cả chính định nghĩa của MOF Vì vậy, chúng ta sử dụng một schema trong hai lớp MDA khác nhau là M3 và M2, để chia sẻ các metametamodel và các metamodel Chẳng hạn như MOF được xác định bởi chính nó, vì vậy chúng ta sử dụng MOF XML schema để mô tả XMI document bao gồm các đặc tả MOF, và document này cũng đồng thời là một phần của chuẩn MOF

Tương tự như vậy, có một document mô tả chuẩn XMI chứa metamodel UML Tuy nhiên, UML là một ngôn ngữ mô hình hóa mà các nhà phát triển sử dụng cho các mô hình khác nhau Rõ ràng đây là một nhu cầu đối với một XML schema để trao đổi các mô hình UML Trong thực tế, có một schema đã được chuẩn hóa gọi là UML XMI Schema Các công cụ UML như Rational Rose của IBM,

Poseidon cho UML, và Together hỗ trợ schema này, nhưng một số nhà nghiên cứu cho rằng luôn bị mất một số thông tin khi chia sẻ các mô hình UML giữa các công

cụ UML

Hơn nữa, các nhà phát triển không bao giờ sử dụng các UML XML Schema như là một ngôn ngữ XML trong các ứng dụng domain Ta luôn xác định một domain XML language, nghĩa là một domain XML schema Theo đó, có một tập các quy tắc cho việc ánh xạ các mô hình UML thành các XML schema Vì vậy, người ta có thể tạo ra một XML schema cho bất kỳ một mô hình UML nào, trong khi các thể hiện của các mô hình (các đối tượng) được chia sẻ phù hợp với các schema đó Do giả định rằng cả các đối tượng UML và các lớp UML đều nằm trong cùng một tầng MDA (tầng M1), ta xem như các XML schema được tạo ra và các thể hiện của chúng là các XML document đều được đặt trong lớp M1

Hình 20: Việc ánh xạ các MDA metametamodel, metamodel, và model sang XMI

Bởi vì ta có một tập các quy tắc để tạo ra các giản đồ XML từ các mô hình UML, chúng ta có thể áp dụng cùng một nguyên tắc như vậy với các tầng MDA ở trên (M2 và M3), và do đó ta có thể tạo ra một giản đồ XML cho mỗi metamodel dựa trên MOF Sử dụng nguyên tắc đó, ta đã tạo ra các giản đồ XML cho nhiều metamodel khác nhau (chẳng hạn như ODM) Ví dụ, các nhà phát triển của Protégé

đã tạo ra một giản đồ XML cho một metamodel tương thích MOF của bộ soạn thảo ontology Protégé Tóm lại, ta có thể xem XMI là:

- một tập các quy tắc cho sự serialization của đối tượng

- một tập các quy tắc cho việc tạo ra schema

Theo đó, OMG đã đặc tả một số tài liệu liên quan đến XMI:

- XML schema cho các metamodel MOF

- XMI document cho metamodel MOF

- XMI document cho metamodel UML

- XML schema cho các mô hình UML

Để minh họa cho các tài liệu và lược đồ XMI nói trên, hình sau đây trình bày một đoạn trích từ một tài liệu XMI biểu diễn cho lớp UML Musician được định nghĩa trong phần trước Tài liệu đã được thể hiện phù hợp với giản đồ XMI đã được chuẩn hóa cho các mô hình UML Tài liệu này là ở mức dưới cùng (M1), và là một thể hiện của giản đồ XML được định nghĩa ở mức M2.

<UML:Class xmi.id="Im19247250m106c9d71d66m24d0" name="Musician"

visibility="public" isSpecification="false" isRoot="true" isLeaf="true" isAbstract="false" isActive="false">

2 Ứng dụng MDA trong quản lý Ontology

Một hệ thống quản lý ontology là gì?

Trong những năm gần đây, mối quan tâm đến việc sử dụng các thông tin ontology trong giao tiếp tri thức giữa các hệ thống phần mềm đã có sự tăng đột biến Kết quả là, ngày càng có nhiều hệ thống phần mềm tham gia vào các nhiệm vụ quản lý ontology, bao gồm việc tạo, lưu trữ, tìm kiếm, truy vấn, tái sử dụng, bảo trì,

và tích hợp Gần đây, đã có những nỗ lực để tách các công việc đó ra khỏi các hệ thống phần mềm riêng lẻ và đặt chúng cùng nhau vào trong một middleware, là một

hệ thống quản lý ontology Một hệ thống quản lý ontology cung cấp một cơ chế để

xử lý các thông tin ontology ở một mức độ trừu tượng thích hợp Bằng cách sử dụng giao diện lập trình và các ngôn ngữ truy vấn mà hệ thống quản lý ontology cung cấp, các chương trình ứng dụng có thể thao tác và truy vấn ontology mà không cần phải biết chi tiết của chúng hoặc tái cài đặt ngữ nghĩa của các ngôn ngữ ontology tiêu chuẩn

Một hệ thống quản lý đối với ontology cũng tương đương với một hệ thống quản lý cơ sở dữ liệu (DBMS) đối với dữ liệu Một DBMS cho phép một ứng dụng đứng ngoài (externalize) quá trình lưu trữ và xử lý dữ liệu, thông qua một giao diện chuẩn, và làm cho các chương trình không cần phải quan tâm đến vấn đề quyết định làm thế nào để lưu trữ dữ liệu trong các file, làm thế nào để chỉ mục dữ liệu, làm thế nào để tối ưu hóa truy vấn, làm thế nào để lấy kết quả truy vấn, v.v Một cách tương

tự, một hệ thống quản lý ontology cho phép một ứng dụng thao tác và truy vấn ontology mà không cần phải quan tâm về việc ontology này được lưu giữ và truy cập như thế nào, truy vấn được xử lý như thế nào, cách kết quả truy vấn sẽ được lấy

ra, v.v., bằng cách cung cấp một giao diện lập trình Khả năng chỉnh sửa ontology không được xem như là thành phần quan trọng của một hệ thống quản lý ontology Một hệ thống quản lý ontology có thể có hoặc không có các khả năng chỉnh sửa và thiết kế ontology Trong trường hợp không có, hệ thống quản lý ontology có thể được sử dụng cùng với một trình soạn thảo ontology như Protégé, nếu cần thiết

2.1 Các hệ thống quản lý ontology truyền thống

Hiện nay, có hơn 90 công cụ để thiết kế và quản lý ontology Đa số là các công cụ thiết kế và chỉnh sửa các tập tin ontology Ngoài khả năng chỉnh sửa, một

số trong đó có thể cung các khả năng về việc phân tích, sửa đổi, và bảo trì ontology Một trong những công cụ chỉnh sửa phổ biến là Protégé, được phát triển bởi trường Đại học Stanford School of Medicine Một số công cụ khác là SemTalk, oiled, Unicorn, Jena, và Snobase, …

Bảng 1 tóm tắt một số hệ thống quản lý ontology Điều quan trọng cần lưu ý rằng các hệ thống này chủ yếu tập trung vào các thao tác ontology Các khả năng tương tác với các ngôn ngữ mô hình hóa khác và các công cụ phát triển đến chỉ là một tính năng phụ cho các hệ thống này Nghĩa là, chúng tách biệt các workspace cho quản lý ontology và phát triển phần mềm, và không cung cấp một môi trường tích hợp chặt chẽ cho kỹ thuật phần mềm và ontology

Hệ thống Chức năng Các chuẩn Khả năng

tương tác

Jena Một framework phát triển

phần mềm cho xử lý và truy vấn ontology

RDF, RDFS, OWL, SPARQL Không

Sesame Một RDF database cho phép

xử lý và truy vấn ontology

RDF, RDFS, OWL

Không

Protégé Công cụ soạn thảo ontology

đồ họa, và là framework của

cơ sở tri thức cho xử lý và truy vấn ontology

RDF, RDFS, OWL Thông qua các plugin (khả năng

bị hạn chế);

UML → OWL ontology

KOAN Tổng hợp các công cụ quản

lý ontology bao gồm tạo, xử

lý, suy luận và truy vấn ontology

RDF, RDFS,

RDFS ontology

Jastor Bộ tạo mã Java cho việc tạo

các Java bean từ các OWL ontology

RDF, RDFS, OWL OWL ontology → Java Beans

D2RQ Một ngôn ngữ và công cụ

cho việc đặc tả các ánh xạ giữa schema CSDL quan hệ

và OWL ontology

RDF, RDFS,

OWL ontology

Bảng 1: Các hệ thống quản lý ontology truyền thống

2.2 Kiến trúc hạ tầng ontology dựa trên MDA

2.2.1 Tổng quan

Ontology và MDA là hai phương pháp tiếp cận theo mô hình đang được phát triển song song nhưng bởi các cộng đồng khác nhau Chúng có một số mục đích và kết quả chung và có thể được nhóm lại gần hơn Nhiều tác giả đã cố gắng đưa ra một vài giải pháp nhằm tạo ra sự kết nối giữa chúng Kết quả của sự nỗ lực đó là sáng kiến gần đây của OMG (Object Management Group) cho việc định nghĩa một platform phát triển ontology

Để được người sử dụng chấp nhận rộng rãi và thành công trong các ứng dụng thế giới thực thì công nghệ tri thức và việc mô hình hóa ontology phải theo kịp các xu hướng trong trào lưu phát triển phần mềm Nó phải cung cấp một sự hỗ trợ tốt dưới hình thức các công cụ phần mềm, đồng thời phải dễ dàng tích hợp với các công cụ phần mềm và các ứng dụng đang hiện có hoặc đang được phát triển

Cùng với sự phát triển của Semantic Web, tầm quan trọng của ontology cũng được tăng lên một cách nhanh chóng Các nhà nghiên cứu Semantic Web đang cố gắng làm cho sự phát triển ontology và các ontology nói chung gần với người sử

quan mật thiết đến các mô hình đã biết đến trong AI (ví dụ: description logic, semantic networks, frames) Vì vậy, hầu hết các ontology Web ngữ nghĩa hiện nay được phát triển trong các thực nghiệm AI Theo đó, chúng ta cần trả lời một vài câu hỏi như: Làm thế nào để chúng ta có thể tăng số lượng người phát triển ontology? Làm thế nào để chúng ta có thể thúc đẩy các kỹ sư công nghệ phần mềm để phát triển và sử dụng các ontology? Chúng ta có thể sử dụng công cụ phát triển phần mềm để phát triển các ontology không? Vì vậy, chúng ta cần một số phương pháp

để tích hợp sự phát triển phần miềm và ontology

Việc tích hợp công nghệ phần mềm với khái niệm Semantic Web không phải

là ý tưởng mới Nhiều nhà nghiên cứu đã gợi ý sử dụng UML để giải quyết vấn đề này Tuy nhiên, UML dựa trên mô hình hướng đối tượng và có vài hạn chế so với việc phát triển ontology Do đó, chúng ta chỉ có thể sử dụng UML trong giai đoạn khởi đầu của phát triển ontology Những hạn chế có thể được khắc phục bằng cách

sử dụng các mở rộng của UML (ví dụ các UML profile) và các chuẩn OMG khác như MDA Hơn nữa, nếu chúng ta muốn đưa ra một giải pháp thích hợp với các đề xuất của MDA, chúng ta cũng phải hỗ trợ sự sinh tự động các định nghĩa ontology hoạt động một cách đầy đủ (ví dụ: trong ngôn ngữ OWL) Hiện nay, hướng quan trọng nhất để đạt được mục đích này chính là hướng mà một nhóm nghiên cứu trong OMG đang theo đuổi, họ đang cố gắng đạt được sự hội tụ của nhiều đề xuất khác nhau cho các giải pháp đối với vấn đề này Kết quả của sự nỗ lực này sẽ là một ngôn ngữ chuẩn (nghĩa là một siêu mô hình) dựa trên các chuẩn MDA và khuyến nghị của W3C Web Ontology Language (OWL)

Trong phương pháp tiếp cận mô hình hóa ontology trong phạm vi của MDA (xem hình sau), một số đặc tả cần được định nghĩa:

- Ontology Definition Metamodel (ODM)

- Ontology UML Profile (OUP)

- Các ánh xạ hai chiều giữa OWL và ODM, ODM và các metamodel khác, ODM và OUP, giữa OUP và các UML profile khác