MÔ HÌNH ĐIỀU KHIỂN KIẾN TRÚC MODEL DRIVEN ARCHITECTURE - MDA

Định nghĩa này nhấn mạnh hai điểm chính: đó là các khái niệm được hình thức hóa và bởi vậy cho phép suy diễn reasoning bởi máy tính; thứ hai nó nhấn mạnh mỗi Ontology được xây dựng cho

Mục Lục

Mục Lục 1

LỜI CẢM ƠN 1

CHƯƠNG 1: TỔNG QUAN VỀ ONTOLOGY 2

1.1 Các khái niệm: 2

1.2 Xây dựng Ontology 3

CHƯƠNG 3: ỨNG DỤNG MDA TRONG QUẢN LÝ ONTOLOGY 20

3.4.2 Các Property của Ontology 42

TÀI LIỆU THAM KHẢO 47

LỜI CẢM ƠN

Trước tiên, em xin gửi lời cảm ơn chân thành nhất tới PGS - TS Đỗ Văn Nhơn

đã tận tình hướng dẫn, giảng dạy truyền đạt những kiến thức nền tảng cơ bản cho chúng em về môn học:"Biểu diễn tri thức và ứng dụng", và có những gợi ý

giúp em hoàn thành đề tài: "Mô hình điều khiển kiến trúc và ứng dụng quản

lý Otology"

Em xin được gửi lời cảm ơn chân thành tới các thầy cô giáo trong khoa Công nghệ thông tin - Trường đại học Công nghệ thông tin- Đai học QG.TPHCM đã tần tình giúp đỡ và giảng dạy cho chúng em trong những môn học vừa qua

Trong thời gian vừa qua mặc dù em đã cố gắng rất nhiều để hoàn thành tốt môn học Song chắc chắn kết quả nghiên cứu sẽ không tránh khỏi những thiếu sót, vì vậy em kính mong nhận được sự chỉ bảo và góp ý của quý thầy cô

và các bạn

Em xin chân thành cám ơn!

Hà Nội, tháng 01 năm 2013

Học viên thực hiện

Bùi Hữu Tiến - CH1102010

CHƯƠNG 1: TỔNG QUAN VỀ ONTOLOGY

1.1 Các khái niệm:

Tại trái tim của tất cả ứng dụng Web ngữ nghĩa là sự sử dụng Ontology Thuật ngữ “ontology” có gốc từ triết học (nghĩa là “bản thể học”) nhưng đã được chuyển thành thuật ngữ khoa học máy tính từ nhiều năm nay Một định nghĩa được chấp nhận rộng rãi về Ontology là : “Một Ontology là một đặc tả chính xác và hình thức (an explicit and formal specification) về một khái niệm (a conceptualisation) của một miền thông tin được quan tâm (a domain of

interest)” [Gruber1993] Định nghĩa này nhấn mạnh hai điểm chính: đó là các

khái niệm được hình thức hóa và bởi vậy cho phép suy diễn (reasoning) bởi máy tính; thứ hai nó nhấn mạnh mỗi Ontology được xây dựng cho một vài miền thông tin cần quan tâm, có như thế nó mới thể hiện được vai trò và tác dụng của

nó Ontology thể hiện sự hiểu biết chung về một miền, các ứng dụng có thể dùng sự hiểu biết chung này để giao tiếp với nhau

Ontology bao gồm các khái niệm (concepts), các quan hệ (relations), các thể hiện (instances) và axioms Bởi vậy một Ontology thường được biểu

diễn dưới dạng bộ 4 {C, R, I, A} trong đó C là tập các khái niệm, R là tập các

quan hệ, I là tập các thể hiện và A là tập các axiom [StaabStuder2004] Trong

Ontology, các khái niệm được biểu diễn dưới dạng các lớp (Class), ví dụ : lớp

Personbiểu diễn cho khái niệm Người, lớp Student biểu diễn cho khái niệm Sinh viên Các khái niệm chính là các đối tượng của miền thông tin (domain)

được quan tâm mà chúng ta cần thể hiện

Quan hệ (Relations) bao gồm trước hết là quan hệ phân cấp (quan hệ cha-con)

giữa các lớp, gọi là hierachical relation hay taxonomy Ontology cung cấp hai

loại thuộc tính (hayy quan hệ) là thuộc tính đối tượng (object properties) và thuộc tính dữ liệu (datatype properties) Thuộc tính đối tượng cung cấp mối liên

hệ giữa các lớp (như trong X dạy Y), còn thuộc tính dữ liệu kết nối thuộc tính của lớp với kiểu dữ liệu của nó (như trong X có tên kiểu xâu).

Cuối cùng Axiom được sử dụng để cung cấp thông tin suy diễn về các lớp và thuộc tính, ví dụ để nói rằng hai lớp là tương đương hoặc về phạm vi giá trị của một thuộc tính (cardinality)

Ví dụ về một Ontology đơn giản được sử dụng để biểu diễn quan hệ giữa Giáo viên (Lecturer) và Sinh viên (Student) trong một trường đại học Cả Giáo viên và Sinh viên đều là các khái niệm con của khái niệm Người (Person) Giáo viên thì dạy Sinh viên Người nào cũng có tên (name), tuổi (age), địa chỉ (address) Giáo viên có thêm thuộc tính năm giảng dạy (experimentYear), Sinh viên có thêm thuộc tính điểm số (mark) Một thể hiện của lớp Giáo viên là John, một thể hiện của lớp Sinh viên là Peter

Ngôn ngữ Ontology là ngôn ngữ hình thức được sử dụng để xây dựng Ontology Nó cho phép việc mã hóa tri thức trong một lĩnh vực cụ thể và thường bao gồm các quy tắc suy luận cung cấp cho việc xử lý các yêu cầu dựa trên tri thức đó Ngôn ngữ Ontology thường là ngôn ngữ khai báo, và hầu hết là những sự tổng hợp của ngôn ngữ cấu trúc, và thường được xây dựng dựa trên logic thủ tục hoặc dựa trên logic mô tả Có rất nhiều ngôn ngữ Ontology đã được thiết kế và đưa ra tuân theo sự tiêu chuẩn hóa, ngôn ngữ Ontology đơn giản (định nghĩa các khái niệm) dựa trên frame (định nghĩa khái niệm và thuộc tính) dựa trên (DAML + OIL), … Các ngôn ngữ trên đều hạn chế khi biểu diễn các tri thức phức tạp trong hệ giải toán tự động dựa trên tri thức và thường

là biểu diễn không đủ để có thể thực hiện trên máy tính Qua vấn đề nếu trên, với đề tài xây dựng một ngôn ngữ Ontology để có thể biểu diễn các tri thức trong Ontology COKB-ONT

1.2 Xây dựng Ontology

Một vấn đề quan trọng trong sử dụng Ontology là xây dựng Ontology từ nguồn thông tin Việc xây dựng có thể do con người hoàn toàn thực hiện, bán tự động hoặc tự động Có nhiều phương pháp đã được đề nghị trong xây dựng Ontology

MethOntology [Fernandez1999] là một phương pháp xây dựng

Ontology mà được tiếp thu nhiều ý kiến từ công nghệ phần mềm Chu trình phát triển Ontology được dựa trên các hoạt động được định nghĩa trong chuẩn IEEE

về phát triển phần mềm Các hoạt động này tạo thành vòng đời của Ontology qua các giai đoạn (stages) mà Ontology sẽ di chuyển trong suốt vòng đời của nó cũng như các hoạt động sẽ được thực hiện trong mỗi giai đoạn

Chu trình phát triển Ontology :

Chu trình này đề cập đến các hoạt động nào sẽ được thực hiện khi xây dựng Ontology Nó định nghĩa ba (3) nhóm hoạt động, được thể hiện trong hình và

mô tả chi tiết dưới đây:

· Các hoạt động quản lý Ontology (Management): Chúng bao gồm

lập kế hoạch (Planify), điều khiển (Control) và đảm bảo chất lượng (Quality assurance) Hoạt động lập kế hoạch xác định các nhiệm vụ sẽ

được thực hiện, sự sắp xếp của chúng, thời gian và tài nguyên cần thiết

Hoạt động điều khiển đảm bảo nhiệm vụ được hoàn thành theo yêu cầu Hoạt động đảm bảo chất lượng kiểm tra chất lượng của các đầu ra của

phương pháp MethOntology (ontology, phần mềm, tài liệu)

· Các hoạt động hướng phát triển Ontology (Techicals): Được nhóm

thành các hoạt động tiền phát triển (pre-development), phát triển (development) và sau phát triển (post-development) Trong suốt hoạt động

tiền phát triển, môi trường nơi Ontology được sử dụng sẽ được nghiên

cứu và đây là nghiên cứu về khả năng có thể thực hiện được Trong giai

đoạn phát triển, hoạt động đặc tả (specification) sẽ xác định tại sao cần xây dựng Ontology, mục đích sử dụng và người dùng Hoạt động khái

niệm hóa (conceptualization) cấu trúc hóa tri thức về miền thông tin

thành một mô hình có nghĩa ở mức tri thức Hoạt động hình thức hóa (formalization) sẽ chuyển mô hình mức khái niệm thành một mô hình

hình thức hoặc mô hình tính toán được Cuối cùng mô hình tính toán

được sẽ được cài đặt sử dụng công cụ soạn thảo Ontology Trong giai đoạn hậu phát triển, hoạt động bảo trì (maintainance) sẽ cập nhật và

chữa lỗi cho Ontology nếu cần thiết và nó có thể dùng lại bởi Ontology hoặc ứng dụng khác

· Các hoạt động trợ giúp Ontology (Support): chúng được thực hiện

vào cùng thời điểm với các hoạt động hướng phát triển Ontology Trong

suốt quá trình trợ giúp thì những hoạt động sau xảy ra Hoạt động thu

thập tri thức (knowledge acquistion) mà mục đích của nó là thâu nhận tri

thức từ các chuyên gia hoặc bằng cách học ontology (bán) tự động Hoạt

động đánh giá (evaluation) sẽ phán xét ontology, phần mềm và tài liệu đã phát triển với một khung tham chiếu Hoạt động tích hợp (integration) nếu dùng lại Ontology khác, đi kèm với nó có thể là các hoạt động trộn (merging) và gán (alignment) Ontology nếu có nhiều ontology được dùng lại và cần kết hợp Hoạt động lập tài liệu (documentation) chi tiết lại mỗi giai đoạn và sản phẩm hoàn thành và hoạt động quản lý cấu hình

(configuration management) lưu lại theo phiên bản Ontology, phần mềm,

tài liệu để điều khiển sự thay đổi

Hình 1.1: Chu trình phát triển Ontology [MethOntology]

Chu trình phát triển Ontology ở trên xác định các hoạt động được thực hiện Nó không nói gì về việc chúng được lập lịch như thế nào Điều này được quyết định bởi phần khác trong phương pháp MethOntology, vòng đời Ontology, đưa ra các giai đoạn mà Ontology sẽ di chuyển qua trong suốt cuộc đời của nó và các hoạt động sẽ được thực hiện

Chu trình sống của Ontology:

Chu trình sống của Ontology lập lịch cho các hoạt động phát triển Ontology được nêu chi tiết ở trên Chu trình sống của ontology phát triển theo chu trình và được dựa trên mô hình nguyên mẫu (prototype) tiến hóa Nó cho phép phát triển tăng trưởng Ontology để đảm bảo việc thẩm định sớm Mỗi chu trình phát triển bắt đầu bằng việc lập lịch các nhiệm vụ cần thực hiện, xác định yêu cầu và tài nguyên cần thiết Sau đó hoạt động phát triển được diễn ra, bắt đầu với việc đặc tả Một cách đồng thời, các hoạt động quản lý, bao gồm điều khiển và đảm bảo chất lượng, và các hoạt động trợ giúp, thu thập tri thức, tích hợp, đánh giá, lập tài liệu và quản lý cấu hình được diễn ra Chúng xảy ra song song với các hoạt động phát triển

Trong mỗi chu trình, nguyên mẫu (prototype) Ontology di chuyển qua các hoạt động phát triển, từ đặc tả, qua khái niệm hóa, hình thức hóa và cài đặt tới tận bảo trì mặc dù không cần thiết phải đi qua tất cả Cuối cùng, nguyên mẫu

có thể đủ thành thục để đánh giá và một chu trình mới sẽ được đưa ra dựa trên kết quả của việc đánh giá này Nếu một chu trình được hoàn thành thì những bước sau sẽ được thực hiện :

1 Đặc tả nguyên mẫu

2 Xây dựng một mô hình khái niệm từ các mẩu thông tin từ quá trình thu thập tri thức.

3 Hình thức hóa mô hình khái niệm

4 Cài đặt Ontology trên một ngôn ngữ biểu diễn Ontology

5 Bảo trì ontology kết quả mà có thể dẫn tới một chu trình mới nếu ontology là không thích hợp hoặc yêu cầu mới được phát hiện

Hình dưới đây sẽ thể hiện chu trình sống của Ontology, các hoạt động quản

lý và trợ giúp sẽ diễn ra đồng thời với quá trình phát triển Công sức bỏ ra cho các hoạt động trợ giúp là không giống nhau trong toàn bộ chu trình, thu thập tri thức, tích hợp và đánh giá là lớn hơn trong suốt quá trình khái niệm hóa Ontology Lý do có sự khác biệt này là hầu hết tri thức được yêu cầu trong lúc bắt đầu phát triển, các Ontology được tích hợp ở mức khái niệm trước khi cài đặt và cần đánh giá kết quả sớm ở mức khái niệm để tránh lỗi di truyền

Hình 1.2 : Vòng đời Ontology [MethOntology]

Quá trình phát triển Ontology (Development Process)

Quá trình phát triển bao gồm tất cả các hoạt động tạo ra một nguyên mẫu Ontology thích hợp

Quá trình đặc tả (Specification): quá trình này xác định mục đích và

phạm vi của Ontology Tại sao Ontology được xây dựng, mục đích là gì và người dùng là ai Đặc tả có thể là phi hình thức, trong ngôn ngữ tự nhiên hoặc hình thức

Quá trình khái niệm hóa (Conceptualisation):

Mục đích của hoạt động này là tổ chức và xây dựng cấu trúc tri thức được yêu cầu trong quá trình thu thập tri thức sử dụng một hình thức biểu diễn ngoài độc lập với biểu diễn tri thức và hệ sẽ cài đặt Ontology Một điểm nhìn phi hình thức của miền thông tin sẽ được chuyển thành mô hình bán hình thức sử dụng biểu diễn trung gian dựa trên hệ thống bảng và đồ thị Những biểu diễn trung gian này (khái niêm, thuộc tính, quan hệ, axiom và luật) là có giá trị bởi chúng

có thể hiểu được bởi các chuyên gia về miền thông tin và nhà phát triển Ontology Bởi vậy chúng là cầu nối giữa tri giác về miền của con người với ngôn ngữ cài đặt ontology

Để xây dựng một mô hình khái niệm đầy đủ và thống nhất, hoạt động khái niệm hóa đã định nghĩa một tập các công việc cần thực hiện kế tiếp nhau Các công việc này làm tăng lên sự phức tạp trong việc biểu diễn mô hình khái niệm Theo cách này, nó dễ dàng hơn để đảm bảo một mô hình khái niệm đầy

đủ và thống nhất:

1 Trước hết cần xây dựng một tập các thuật ngữ (terms) sẽ được bao

gồm trong ontology, giải thích bằng ngôn ngữ tự nhiên của chúng và tập các từ đồng nghĩa, từ rút gọn Các thuật ngữ được xác định theo chiến thuật từ giữa ra (middle-out) Gốc của các thuật ngữ cơ bản sẽ được xác định trước, sau đó chúng sẽ được đặc biệt hóa hay tổng quát hóa theo yêu cầu Chiến lược này đưa ra một tập cân bằng các thuât ngữ bởi sự chi tiết chỉ đưa ra khi cần thiết và phân loại mức cao hơn được xây dựng tự nhiên

2 Tiếp đó, các thuật ngữ được phân loại vào một hay nhiều tập phân

cấp các khái niệm (taxonomies of concept), nơi một khái niệm là trừu

tượng của một hay nhiều thuật ngữ Khái niệm lớp con của quan hệ phân cấp được sử dụng, trong đó: C là lớp con của D khi và chỉ khi mọi thể hiện của C là của D

3 Quan hệ nhị phân (Binary relation) được sử dụng để định nghĩa quan

hệ giữa các khái niệm trong một Ontology và với khái niệm của Ontology khác Quan hệ được quyết định bởi tên và khái niệm nguồn, đích

4 Từ điển khái niệm (concept dictionary)được xây dựng Nó mô tả

mỗi khái niệm bằng cách xác định quan hệ lấy khái niệm này lam miền (domain) và các thể hiện khái niệm cũng như thuộc tính lớp Các thuộc tính lớp là các thuộc tính của khái niệm

5 Từ điển khái niệm được chi tiết hóa Với mỗi quan hệ, nó xác định giới hạn (cardinality), quan hệ ngược (inverse ralation) và các thuộc tính toán học (đối xứng, bắc cầu, duy nhất, ) Các thuộc tính lớp cũng được

mô tả về miền khái niệm của chúng, kiểu giá trị, đơn vị đo, phạm vi, giới hạn, giá trị, axiom liên quan và luật suy diễn giá trị của thuộc tính này

hoặc dùng nó để suy diễn thuộc tính khác Ngoài ra có một bảng hằng số

để định nghĩa những phần không thể thay đổi của miền tri thức

6 Một khi các khái niệm, quan hệ phân cấp, quan hệ và thuộc tính đã được xác định thì các axiom hình thức và luật được sử dụng để kiểm tra

ràng buộc hoặc suy diễn giá trị cho thuộc tính Axioms là các biểu thức

logic luôn đúng thông thường được sử dụng để xác định ràng buộc Chúng được định nghĩa phi hình thức trong dạng văn bản và một cách

hình thức dạng logic bậc 1 (ví dụ: >,=,<, , , ) Luật (Rules) nói

chung được sử dụng để suy diễn tri thức trong Ontology như xác định giá trị thuộc tính, thể hiện quan hệ,

Quá trình hình thức hóa (Formalisation):

Mục đích của hoạt động này là hình thức hóa mô hình khái niệm Có những công cụ phát triển Ontology mà tự động chuyển mô hình khái niệm thành các ngôn ngữ Ontology sử dụng bộ dịch Bởi vậy đây không phải là hoạt động cần nhiều công sức

Quá trình cài đặt (Implementation):

Hoạt động này xây dựng mô hình máy tính xử lý được sử dụng ngôn ngữ cài đặt Ontology Có nhiều ngôn ngữ Ontology và chúng không có cùng một khả năng biểu diễn cũng như khả năng suy diễn

Quá trình đánh giá (Evaluation):

Quá trình này sẽ cập nhật và chữa lỗi cho Ontology nếu Ontology xây dựng không hoạt động như mong muốn hoặc thay đổi yêu cầu trong chu trình phát triển hiện tại hoặc chu trình khác dùng lại Ontology này

Như vậy phương pháp xây dựng ontology MethOntology là rất đầy đủ,

mang tính lý thuyết cao Phương pháp này đã lấy nhiều ý tưởng từ phương pháp phát triển phần mềm và tạo ra một chu trình sống của Ontology với mô hình phát triển tiến hóa, tăng dần

Tuy nhiên trong thực tế các bài toán xây dựng Ontology thì không cần thiết phải áp dụng tất cả các giai đoạn trên mà có thể tập trung vào những giai đoạn chủ yếu nhất trong việc tạo ra Ontology Trong đồ án này, một vài phương pháp mang tính thực hành cao hơn sẽ được giới thiệu:

[NoyMcGuiness2003] Noy và McGuiness (2003) đã đề nghị một tập các

bước để xây dựng Ontology như sau:

· Bước 1 – Quyết định miền và phạm vi của Ontology: Để trả lời câu

hỏi này, nhà phát triển ontology phải xác định mục đích của ontology, người sử dụng, và thông tin sẽ được lưu trong ontology

· Bước 2 – Xem xét sự dùng lại của các Ontology đã có: Nhà phát triển

phải xem xét các ontology đã có trong cùng miền quan tâm Sự dùng lại

sẽ tối thiếu thời gian và công sức của quá trình xây dựng ontology, ngoài

ra nó còn đem đến chất lượng cao hơn vì các ontology đã được kiểm thử

kĩ càng

· Bước 3 – Xác định các thuật ngữ quan trọng của Ontology: Và xác

định các khái niệm mà những thuật ngữ này biểu diễn

· Bước 4 – Định nghĩa các lớp và phân cấp các lớp: Bước này có thể

được thực hiện theo một trong các cách tiếp cận (Uschold và

Gruninger1996):

o Từ trên xuống (Top-down): Bắt đầu với việc định nghĩa nhiều khái niệm chung và tiếp theo chia các khái niệm thành các loại chi tiết hơn

o Từ dưới lên (Bottom-up): Bắt đầu với việc định nghĩa các lớp chi tiết hơn và sau đó nhóm các lớp thành các khái niệm tổng quát hơn

o Lai (hybrid): giống như trong cách tiếp cận của phương pháp

MethOntology

· Bước 5 – Định nghĩa các thuộc tính của các lớp: Các lớp một mình là

ít ý nghĩa, cần thiết phải định nghĩa các thuộc tính cho chúng Đó là thuộc tính của riêng lớp hoặc thuộc tính quan hệ giữa các lớp

· Bước 6 – Định nghĩa đặc điểm của thuộc tính: đó là các giới hạn,

miền, phạm vi cho thuộc tính

· Bước 7 – Tạo ra các thể hiện: Bước cuối cùng này là phải đưa vào

Ontology các thể hiện cho mỗi lớp, bao gồm cả thuộc tính

[UscholdKING1995] Một phương pháp xây dựng Ontology được đề nghị bởi

(Uschold và KING, 1995) liên quan đến những giai đoạn dưới đây: xác định

mục đích của Ontology (tại sao lại xây dựng nó, nó được sử dụng như thế nào,

phạm vi người dùng), xây dựng Ontology, đánh giá và lập tài liệu Trong đó xây dựng Ontology được chia tiếp thành ba (3) bước Bước đầu tiên là định

hình Ontology, các khái niệm chính và quan hệ được xác định, định nghĩa của

chúng được viết ra, các thuật ngữ được sử dụng liên quan đến khái niệm và quan hệ cũng được xác định, có sự chấp nhận của chuyên gia về các khái niệm

và định nghĩa đó Bước thứ hai liên quan đến mã hóa Ontology trong một vài ngôn ngữ Ontology Bước thứ ba liên quan đến việc tích hợp có thể với

Ontology đã có

Khó khăn trong việc xây dựng Ontology:

Việc xây dựng Ontology cần tiêu tốn nhiều thời gian và công sức Một thách thức chính cho các nhà nghiên cứu là phát triển công cụ để giúp đỡ quá trình này, đặc biệt giảm thiểu công sức của con người Đó có thể là các công cụ giúp xây dựng Ontology bán tự động (semi-automatic) hoặc tự động Chức năng chính của chúng là phân tích văn bản để khám phá các khái niệm và quan hệ cho Ontology Quá trình này sẽ là tự động nếu không cần sự tham gia của con người và là bán tự động nếu con người chỉ tham gia trong việc xác định các khái niệm và quan hệ chính xác nhất cho miền thông tin mà công cụ đã khám phá ra Các công cụ phân tích văn bản bao gồm công cụ xử lý ngôn ngữ tự nhiên (NLP: Natural Language Processing) Việc xử lý ngôn ngữ tự nhiên mặc dù đã được nghiên cứu nhiều nhưng chủ yếu là về tiếng Anh và vẫn là điểm gây khó khăn trong quá trình xây dựng Ontology nhất là với các văn bản thuộc ngôn ngữ khác như tiếng Việt

CHƯƠNG 2: MÔ HÌNH ĐIỀU KHIỂN KIẾN TRÚC (MODEL DRIVEN

ARCHITECTURE - MDA) 2.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

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

2.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.2: Sự tương ứng giữa một mô hình và một hệ thống

2.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

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

2.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 2.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 2.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 2.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 2.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

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

CHƯƠNG 3: Ứ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

3.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.

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

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

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

3.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ử dụng phần mềm hơn Tuy nhiên, các ontology có nhiều nền tảng chặt chẽ có liên 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.

Hình 3.1: Mô hình hóa Ontology trong ngữ cảnh MDA

3.2.2 Kết nối giữa RDF và MOF

Trước khi bắt đầu mô tả chi tiết hơn về ODM, chúng ta phải làm rõ sự khác nhau giữa việc metamodeling trong Semantic Web (dựa trên các cấu trúc RDFS) và trong MDA (dựa trên MOF) RDFS có một kiến trúc metamodeling không chuẩn và không cố định lớp, làm cho một số yếu tố trong mô hình có vai trò kép trong các đặc tả RDFS Vì vậy, nó trở nên khó hiểu đối với những người thực hiện mô hình hóa, thiếu ngữ nghĩa rõ ràng (bằng cách chỉ định vai trò kép cho một số yếu tố) và sinh ra vấn đề “nhầm lớp” đối với các ngôn ngữ mà nó định nghĩa, trong trường hợp này là OWL Ngược lại, MDA đã cố định và đã xác định rõ kiến trúc bốn tầng

Rõ ràng, nếu chúng ta muốn thực hiện một sự chuyển đổi từ RDF MS (modeling space) thành MOF MS thì chúng ta cần xây dựng các quy tắc chuyển đổi, các quy tắc này phải xác định khái niệm đích nào (đã định nghĩa trong MOF) chúng ta sẽ thu được từ một khái niệm nguồn (đã định nghĩa trong RDFS) Nhiệm vụ chính là xác định những điểm khác nhau và giống nhau quan trọng nhất giữa các cấu trúc chính trong cả hai không gian và quyết định xem làm thế nào để khắc phục sự khác nhau đó Một mô tả ngắn gọn về sự so sánh giữa việc xây dựng metamodeling trong MOF và RDF(S) được thể hiện trong bảng sau

ModelElement ModelElement phân lớp

các thành phần cơ bản (elementary), các cấu trúc nguyên tố của mô hình

Đây là thành phần gốc trong mô hình MOF

rdfs:Resource Biểu diễn tất cả

những gì được

mô tả bởi RDF Cấu trúc cơ bản của đa số RDF

DataType Các kiểu dữ liệu cơ bản

của mô hình, các kiểu mở rộng, v.v

rdfs:Datatype Cơ chế để

nhóm các dữ liệu nguyên thủy

Class Định nghĩa một sự phân

loại qua một tập các thể hiện của đối tượng bằng cách định nghĩa trạng thái

và hành vi của chúng

rdfs:Class Cung cấp một

cơ chế trừu tượng để nhóm các nguồn tài nguyên giống nhau

Classifier Khái niệm trừu tượng,

dùng để định nghĩa sự phân lớp

rdfs:Class cũng

có chức năng giống như khái niệm Classifier của MOF

Association Biểu diễn các mối quan hệ

trong metamodel giữa các cặp thể hiện của các Class

rdf:Property Định nghĩa mối

quan hệ giữa subject

resources và object

resources

Attribute Định nghĩa một nơi lưu trữ

giá trị (value holder), thường là trong mỗi thể hiện của Class

TypedElement TypedElement là một phần

tử mà trong định nghĩa của

nó yêu cầu một kiểu Bản thân TypedElement tự nó không định nghĩa kiểu, nhưng nó liên kết với một Classifier Ví dụ như các thể hiện của đối tượng, các giá trị dữ liệu, v.v

Trong RDF(S), bất kỳ một rdfs:Resource nào cũng có thể được định kiểu (thông qua

rdf:type) bởi