Khóa luận Chuyển đổi từ mô hình uml sang owl ontology và ứng dụng

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ ====================***================== Giáp Thị Ngọc Thúy CHUYỂN ĐỔI TỪ MÔ HÌNH UML SANG OWL ONTOLOGY VÀ ỨNG DỤNG KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin HÀ NỘI - 2010 1 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ ====================***================== Giáp Thị Ngọc Thúy CHUYỂN ĐỔI TỪ MÔ HÌNH UML SANG OWL ONTOLOGY VÀ ỨNG DỤNG KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin Cán bộ hướng dẫn: ThS.Vũ Diệu Hương Cán bộ đồng hướng dẫn: ThS. Đặng Việt Dũng HÀ NỘI - 2010 2 LỜI CẢM ƠN Bài khóa luận “Chuyển đổi từ mô hình UML sang OWL Ontology và ứng dụng” của em được hoàn thành bên cạnh nhờ sự nỗ lực của bản thân, em còn được sự chỉ bảo tận tình từ phía các thầy cô để giúp em hoàn thành khóa luận này. Em xin chân thành cảm ơn các thầy cô trong bộ môn Công nghệ phần mềm – khoa CNTT – trường ĐH Công Nghệ vì đã tạo cơ hội cho em thực hiện khóa luận này. Đặc biệt là tới cô Vũ Diệu Hương và thầy Đặng Việt Dũng, là những người đã tận tình giúp đỡ và trực tiếp hướng dẫn để em hoàn thành được khóa luận này. Cuối cùng, em kính mong nhận được những ý kiến đóng góp của thầy cô để khóa luận này của em được hoàn chỉnh hơn. Em xin chân thành cảm ơn. Giáp Thị Ngọc Thúy Khoa Công nghệ thông tin Trường Đại học Công nghệ - ĐHQGHN 3 MỤC LỤC TÓM TẮT NỘI DUNG ................................................................................................7 MỞ ĐẦU ......................................................................................................................8 CHƯƠNG 1: GIỚI THIỆU VỀ UML VÀ OWL ONTOLOGY ....................................9 1.1. Ngôn ngữ UML (Unified Modeling Language) ..............................................9 1.1.1. Ngôn ngữ mô hình hóa UML ..................................................................9 1.1.2. Một số thành phần chủ yếu của ngôn ngữ UML ......................................9 1.2. Ontology ......................................................................................................14 1.3. OWL (Web Ontology Language)..................................................................14 1.3.1. Các mức của OWL ................................................................................15 1.3.2. Bản mô tả từ vựng ngôn ngữ OWL Lite ................................................15 1.4. OWL Ontolgogy...........................................................................................24 1.4.1. Các phần tử trong OWL Ontology .........................................................25 1.4.2. Một số công cụ hỗ trợ việc xây dựng OWL Ontology............................25 CHƯƠNG 2: CÁC QUY TẮC CHUYỂN ĐỔI TỪ MÔ HÌNH UML SANG OWL ONTOLOGY..............................................................................................................32 2.1. Giới thiệu .....................................................................................................32 2.2. Quy tắc chuyển đổi từ mô hình UML sang OWL Ontology ..........................32 2.2.1 Gói (Package)........................................................................................33 2.2.2. Lớp (Class)............................................................................................34 2.2.3. Chú thích...............................................................................................35 2.2.4. Giao diện (Interface) .............................................................................36 2.2.5. Tổng quát hóa........................................................................................36 2.2.6. Liên kết (Association) ...........................................................................37 2.2.7. Các vai trò (Roles).................................................................................41 2.2.8. Các thuộc tính (Attributes) ....................................................................41 2.2.9. Ràng buộc số lượng...............................................................................42 2.2.10. Mối quan hệ phụ thuộc ..........................................................................44 2.2.11. Liệt kê ...................................................................................................45 2.2.12. Kết tập...................................................................................................46 2.2.13. Phương thức ..........................................................................................47 CHƯƠNG 3: QUY TRÌNH THỰC HIỆN KIỂM TRA KẾT QUẢ ÁP DỤNG MẪU VÀO MÔ HÌNH THIẾT KẾ UML .............................................................................50 3.1. Giới thiệu .....................................................................................................50 3.2. Mẫu Union Pattern (UP) ...............................................................................50 3.2.1. Giới thiệu ..............................................................................................50 3.2.2. Các tính chất cấu trúc cần đảm bảo........................................................51 3.2.3. Một số trường hợp áp dụng sai mẫu Union Pattern ................................52 3.3. Mẫu thiết kế Composite ................................................................................53 3.4. Bài toán ........................................................................................................55 3.4.1. Các bước thực hiện................................................................................56 4 CHƯƠNG 4: KIỂM TRA KẾT QUẢ TÍCH HỢP MẪU UNION PATTERN VÀO MÔ HÌNH THIẾT KẾ HÀNH VI CÁC CON VẬT ...........................................................58 4.1. Mô tả bài toán cụ thể ....................................................................................58 4.2. Các bước thực hiện .......................................................................................60 4.2.1. Bước 1: Biển đổi hai biểu đồ lớp UML sang siêu mô hình.....................60 4.2.2. Bước 2: Chuyển đổi từ siêu mô hình UML sang OWL Ontology...........60 4.2.3. Các luật ràng buộc :...............................................................................73 4.2.4. Bước 3: Kiểm tra bằng công cụ .............................................................75 4.3. Kết quả kiểm tra và đánh giá. .......................................................................75 CHƯƠNG 5: TỔNG KẾT ..........................................................................................76 5.1. Kết quả đạt được: .........................................................................................76 5.2. Kết luận ........................................................................................................76 PHỤ LỤC 1 ................................................................................................................77 PHỤ LỤC 2 ................................................................................................................91 Tài liệu tham khảo ....................................................................................................104 5 DANH MỤC BẢNG BIỂU BẢNG 1: BẢNG MÔ TẢ TỪ VỰNG CỦA OWL LITE. ...........................................16 BẢNG 2. CẤU TRÚC TỪ VỰNG OWL LITE MÔ TẢ RÀNG BUỘC .....................16 BẢNG 3. BẢNG TỪ VỰNG XÂY DỰNG THÔNG TIN VỀ PHIÊN BẢN VÀ CHÚ THÍCH........................................................................................................................16 BẢNG 4. CÁC KIỂU DỮ LIỆU. ................................................................................17 BẢNG 5: BẢNG LIỆT KÊ CÁC QUY TẮC CHUYỂN ĐỔI .....................................32 DANH MỤC HÌNH VẼ Hình 1.1. Biểu đồ Ca sử dụng của một công ty bảo hiểm. [1]......................................10 Hình 1.2. Biểu đồ trình tự cho Print Server. [1]...........................................................10 Hình 1.3. Biểu đồ cộng tác của hệ thống Đặt Sách ......................................................11 Hình 1.4. Biểu đồ lớp Thư Viện. [7] ...........................................................................11 Hình 1.5. Biểu đồ lớp và biểu đồ đối tượng của lớp. [1] ..............................................12 Hình 1.6. Biểu đồ trạng thái. [1]..................................................................................12 Hình 1.7. Các thành phần mô hình thường dùng. [1] ...................................................13 Hình 1.8. Giao diện Protégé 3.4.4. ..............................................................................27 Hình 1.9. Giao diện Altova SematicWorks. ................................................................28 Hình 1.10. Giao diện Altova SematicWorks...............................................................29 Hình 1.11. Các lớp và thuộc tính với các ràng buộc. ...................................................30 Hình 1.12. Các thuộc tính. ..........................................................................................30 Hình 1.13. Các thể hiện của lớp. .................................................................................31 Hình 2.1. Kí hiệu gói. .................................................................................................33 Hình 2.2. Ví dụ về gói.................................................................................................33 Hình 2.3. Kí hiệu Lớp UML........................................................................................34 Hình 2.4. Ví dụ minh họa lớp ảo. ................................................................................35 Hình 2.5. Ví dụ minh họa Interface. ............................................................................36 Hình 2.6. Minh họa quan hệ thừa kế. ..........................................................................37 Hình 2.7. Lớp Author liên kết với lớp Computer.........................................................38 Hình 2.8. Minh họa liên kết một hướng......................................................................38 Hình 2.9. Minh họa mối liên kết hai chiều. .................................................................39 Hình 2.10. Lớp liên kết. ..............................................................................................40 Hình 2.11. Ví dụ minh họa các vai trò.........................................................................41 Hình 2.12. Minh họa thuộc tính lớp. ..........................................................................41 Hình 2.13. Minh họa ObjectPropeprty. .......................................................................42 Hình 2.14. Sơ đồ lớp biểu diễn hệ thống quản lý dịch vụ tiết kiệm..............................42 Hình 2.15. Minh họa mối sự phụ thuộc. ......................................................................44 Hình 2.16. Quan hệ phụ thuộc.....................................................................................45 Hình 2.17. Minh họa kiểu liệt kê. ................................................................................46 Hình 2.18. Minh họa mối quan hệ kết tập....................................................................47 6 Hình 2.19. Siêu mô hình của biểu đồ lớp UML. ..........................................................48 Hình 3.1. Mô hình của mẫu Union Pattern. .................................................................51 Hình 3.2. Ví dụ về mô hình áp dụng mẫu Union Pattern. ............................................52 Hình 3.3. Trường hợp áp dụng sai mẫu UP. ................................................................52 Hình 3.4. Trường hợp áp dụng sai mẫu UP. ................................................................52 Hình 3.5. Trường hợp áp dụng sai mẫu UP. ...............................................................53 Hình 3.6. Cấu trúc mẫu Composite .............................................................................53 Hình 3.7. Trường hợp áp dụng mẫu Composite đúng. .................................................54 Hình 3.8. Mô hình ban đầu.........................................................................................54 Hình 3.9. Trường hợp áp dụng sai mẫu Composite .....................................................55 Hình 3.10. Các bước trong quy trình kiểm tra. ............................................................57 Hình 4.1. Các lớp UML ban đầu. ................................................................................58 Hình 4.2. Biểu đồ lớp sau khi tinh chế áp dụng mẫu Union Pattern. ............................59 Hình 4.3. Siêu mô hình của các biểu đồ lớp...................................................................60 Hình 4.4. Các lớp sau khi chuyển đổi từ siêu mô hình bằng công cụ Protégé. .............61 Hình 4.5. Các thuộc tính của lớp Class. ......................................................................61 Hình 4.6. Thuộc tính của lớp Operation......................................................................62 Hình 4.7. Thuộc tính của lớp Parameter. ....................................................................63 Hình 4.8. Thuộc tính lớp Parameter_Direction_Kind. ................................................64 Hình 4.9. Thuộc tính của lớp Visibility........................................................................64 Hình 4.10. Toàn bộ thuộc tính của các lớp. .................................................................65 Hình 4.11. Các thể hiện của lớp Class.........................................................................66 Hình 4.12. Các thể hiện của lớp Operation. ................................................................67 Hình 4.13. Các Thể hiện của lớp Parameter. ..............................................................68 Hình 4.14. Các thể hiện của lớp Parameter.................................................................69 Hình 4.15. Các thể hiện của lớp Parameter_Direction_Kind .......................................69 Hình 4.16. Các thể hiện của lớp Visibility_Kind. .........................................................70 Hình 4.17. Các thể hiện của lớp Class.........................................................................70 Hình 4.18. Các thể hiện của lớp Class: lớp Mammal. ..................................................71 Hình 4.19. Các thể hiện của lớp Operation. ................................................................71 Hình 4.20. Thể hiện của lớp Operation: phương thức makeSound của lớp Mammal. ..72 Hình 4.21. Thể hiện của lớp Operation: phương thức makeSound trong lớp Cat. ........72 Hình 4.22. Thể hiện của lớp Parameter. ......................................................................73 BẢNG CHỮ VIẾT TẮT OWL Web Ontology Language UML Unified Modeling Language UP Union Pattern OCL Object Constraint Language 7 TÓM TẮT NỘI DUNG Ngôn ngữ mô hình hóa UML được sử dụng phổ biến nhất trong công nghệ phần mềm nhưng lại không đủ chặt chẽ và chưa có công cụ hỗ trợ kiểm tra tính đúng đắn của đặc tả. Do vậy, chúng ta thường phải kết hợp với các ngôn ngữ đặc tả khác để thu được bản đặc tả hệ thống vừa trực quan, dễ hiểu vừa có ngữ nghĩa chặt chẽ, được kiểm tra tự động bởi các công cụ. Và trong quá trình áp dụng các mẫu thiết kế để thu được một mô hình thiết kế tối ưu hơn, ta có thể gặp phải những sai sót. Do vậy, ta cần phải kiểm tra xem mô hình thu được có thỏa mãn các tính chất của mẫu hay không. Điều đó rất quan trọng để có thể giảm thiểu rủi ro và tăng hiệu quả trong quá trình phát triển phần mềm. Trong khóa luận này, tôi sẽ vận dụng các quy tắc chuyển đổi đặc tả UML sang OWL, từ hai mô hình thiết kế ban đầu và sau khi áp dụng mẫu, ta sẽ thu được hai đặc tả OWL, từ đó ta kết hợp với các ràng buộc được viết bằng ngôn ngữ đặc tả OCL hoặc Prolog, và với các công cụ kiểm tra tự động, ta sẽ kiểm tra hai đặc tả OWL có tương đương nhau hay không, cũng tức là hai mô hình đó có tương đương nhau hay không. Do đó, khóa luận của tôi sẽ tập trung vào quy trình chuyển từ đặc tả UML sang đặc tả OWL, kết hợp với các ngôn ngữ đặc tả OCL, Prolog để cho ngữ nghĩa của các đặc tả chặt chẽ hơn. Nó cũng tiến hành thử nghiệm ứng dụng quy trình này để kiểm tra kết quả áp dụng mẫu thiết kế trong phát triển phần mềm hướng đối tượng. 8 MỞ ĐẦU UML là ngôn ngữ mô hình hóa thống nhất, với các kí hiệu trực quan nên được sử dụng phổ biến trong ngành công nghiệp phần mềm. Một mô hình UML thường chứa nhiều biểu đồ thể hiện các khía cạnh khác nhau của hệ thống và thêm vào đó là các ràng buộc được mô tả bằng lời hoặc bằng ngôn ngữ ràng buộc đối tượng để cho ngữ nghĩa của các yếu tố mô hình được chặt chẽ hơn. Để kiểm tra các yếu tố mô hình UML có thỏa mãn một số thuộc tính đã được định nghĩa, chúng ta không thể thực hiện được bằng các công cụ đặc tả UML hiện tại. Cho đến nay, chúng ta thường phải chuyển mô hình UML sang đặc tả bằng các ngôn ngữ có tính hình thức cao hơn và sử dụng các công cụ hỗ trợ ngôn ngữ đó để phân tích tính đúng đắn của đặc tả. Dựa trên hướng nghiên cứu này, chúng tôi đề xuất sử dụng ngôn ngữ OWL và Prolog để kiểm tra các yếu tố của mô hình UML. Theo cách tiếp cận này, các yếu tố của mô hình sẽ được chuyển đổi sang các yếu tố tương ứng của đặc tả OWL, còn các ràng buộc sẽ được mô tả bằng Prolog. Khóa luận này tập trung vào tìm hiểu cách thức chuyển đổi từ đặc tả UML sang đặc tả OWL, sử dụng Prolog để thể hiện các ràng buộc cho các yếu tố mô hình và thực hiện một ứng dụng thử nghiệm. Bài toán được chọn để thực hiện ứng dụng thử nghiệm là kiểm tra kết quả áp dụng mẫu thiết kế cho một mô hình UML cho trước. Mẫu thiết kế cung cấp giải pháp tốt để giải quyết các vấn đề gặp phải trong giai đoạn thiết kế. Các giải pháp này được thẩm định nhiều lần trong các dự án thực tế trước đây, và nếu áp dụng đúng các giải pháp mẫu đưa ra thì chúng ta sẽ thu được thiết kế có kiến trúc tốt hơn so với mô hình ban đầu. Tuy nhiên, trong thực tế đã có rất nhiều trường hợp áp dụng sai giải pháp mẫu đưa ra, dẫn đến mô hình thiết kế mới không thỏa mãn các tính chất cấu trúc của giải pháp mẫu. Khóa luận sẽ trình bày quy trình chuyển đổi các mô hình UML sang đặc tả bằng ngôn ngữ OWL, các tính chất cấu trúc của giải pháp mẫu được mô tả bằng Prolog để có thể kiểm tra được tính đúng đắn của việc áp dụng mẫu bằng công cụ tự động. Việc xây dựng công cụ sử dụng ở đây được thực hiện bởi khóa luận tốt nghiệp của sinh viên Vũ Văn Thế. Cấu trúc của Khóa luận này bao gồm năm chương. Chương 1 trình bày khái quát về UML, OWL Ontology và bản mô tả từ vựng của OWL cùng các mức của nó. Chương 2 trình bày về các quy tắc chuyển đổi từ mô hình UML sang OWL Ontology. Chương 3 trình bày về quy trình thực hiện kiểm tra kết quả áp dụng mẫu vào mô hình thiết kế UML. Chương 4 sẽ thực hiện kiểm tra kết quả tích hợp mẫu Union Pattern vào mô hình thiết kế cụ thể, và chương 5 sẽ tổng kết những kết quả đạt được. Trước tiên, để hiểu được các quy tắc chuyển đổi từ UML sang OWL Ontology, ta cần hiểu được các khái niệm thế nào là UML, Ontology và OWL Ontology. Và chương 1 sẽ trình bày chi tiết và rõ ràng hơn về vấn đề này. 9 CHƯƠNG 1: GIỚI THIỆU VỀ UML VÀ OWL ONTOLOGY 1.1. Ngôn ngữ UML (Unified Modeling Language) 1.1.1. Ngôn ngữ mô hình hóa UML Ngôn ngữ mô hình hóa UML là một ngôn ngữ biểu diễn mô hình theo phương pháp hướng đối tượng được xây dựng bởi ba tác giả là: James Rumbaugh, Grady Booch và Ivar Jacobson với mục đích là:  Thứ nhất là tạo ra một công cụ để có thể mô hình hóa các hệ thống sử dụng các khái niệm hướng đối tượng.  Thứ hai là, nó sẽ thiết lập một mối liên hệ từ nhận thức của con người đến các sự kiện cần mô hình hóa.  Thứ ba, nó sẽ giải quyết vấn đề về thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau.  Và cuối cùng, nó tạo nên một ngôn ngữ mô hình hóa mà cả con người và máy tính đều có thể hiểu được. Như vậy, ngôn ngữ UML là ngôn ngữ biểu diễn mô hình, nó dựa trên một tập hợp các kí tự để xây dựng các mô hình của hệ thống. Mỗi một thành phần của nó mang một ý nghĩa khác nhau để có thể biểu diễn các khía cạnh khác nhau của hệ thống. Để tìm hiểu thêm về UML, phần tiếp theo chúng ta sẽ nói kĩ hơn về một số thành phần cơ bản của nó. 1.1.2. Một số thành phần chủ yếu của ngôn ngữ UML 1.1.2.1. Các loại biểu đồ Trong UML có rất nhiều loại biểu đồ khác nhau được sử dụng để cung cấp một cái nhìn chi tiết nhất về tất các các khía cạnh của hệ thống. Đầu tiên là biểu đồ Ca sử dụng, sau đó là các Biểu đồ tuần tự, Biểu đồ cộng tác, Biểu đồ lớp, Biểu đồ đối tượng, Biểu đồ chuyển trạng thái, v.v.. o Biểu đồ Ca sử dụng Biểu đồ này mô tả chức năng mà hệ thống cung cấp, đó là các hành vi, nhiệm vụ của hệ thống mà người sử dụng mong muốn nó thực hiện, nó không miêu tả các chức năng hoạt động bên trong hệ thống ra sao. 10 Hình 1.1. Biểu đồ Ca sử dụng của một công ty bảo hiểm. [1] Biểu đồ này được xây dựng ở giai đoạn đầu của công việc thiết kế, nó xác định chức năng theo các nhìn của người sử dụng và với mục đích là xác định ngữ cảnh của hệ thống, giúp nhà phát triển phần mềm nắm bắt được yêu cầu và kiểm chứng kiến trúc hệ thống [7]. Dựa vào các chức năng mà nó cung cấp, ta có thể xây dựng hệ thống ở mức chi tiết hơn ở các loại biểu đó sau đó. o Biểu đồ tuần tự Chỉ ra trình tự hoạt động giữa các đối tượng, thứ tự giữa các thông điệp gửi đi giữa các đối tượng và trình tự tương tác giữa các đối tượng theo sự sắp xếp về thời gian.. Hình 1.2. Biểu đồ trình tự cho Print Server. [1] o Biểu đồ cộng tác Chỉ ra sự cộng tác giữa các đối tượng. Bên cạnh việc thể hiện các trao đổi thông điệp (còn gọi là sự tương tác), nó còn thể hiện các đối tượng và quan hệ giữa chúng. 11 Hình 1.3. Biểu đồ cộng tác của hệ thống Đặt Sách o Biểu đồ lớp Biểu đồ chỉ ra cấu trúc các lớp trong hệ thống. Các lớp quan hệ với nhau thông qua liên kết, phụ thuộc, tổng quát hóa hay đóng gói. Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, với cấu trúc bên trong của lớp gồm các khái niệm thuộc tính và phương thức [1]. Ví dụ: Hình 1.4. Biểu đồ lớp Thư Viện. [7] o Biểu đồ đối tượng Biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp thay vì các lớp. Một biểu đồ đối tượng là một ví dụ của biểu đồ lớp. Ví dụ: 12 Hình 1.5. Biểu đồ lớp và biểu đồ đối tượng của lớp. [1] o Biểu đồ chuyển trạng thái Biểu đồ chuyển trạng thái chỉ ra các trạng thái mà các đối tượng của lớp đó có thể có và các sự kiện gây nên sự biến đổi trạng thái đó. Hình 1.6. Biểu đồ trạng thái. [1] Bên cạnh các loại biểu đồ, trong UML còn có các kí hiệu được sử dụng bên trong các loại biểu đồ, thể hiện các vai trò và ý nghĩa khác nhau hỗ trợ cho việc lập mô hình, và có thể đặc tả đầy đủ các khía cạnh của hệ thống. 1.1.2.2. Các thành phần trong mô hình UML Đó là các kí hiệu được sử dụng trong biểu đồ. Nó là các phần tử của mô hình, thể hiện các khái niệm hướng đối tượng quen thuộc. Chẳng hạn như các phần tử: Lớp, Đối tượng, Trạng thái, Nút, Gói, Thành phần, .v.v. [1]. 13 Hình 1.7. Các thành phần mô hình thường dùng. [1] Trong đó, một vài quan hệ đáng chú ý như sau: o Liên kết (Association): Liên kết các phần tử và các thực thể với nhau. Kí hiệu: o Tổng quát hóa (Generalization): Còn được gọi là tính kế thừa, với nghĩa rằng, phần tử này có thể là một sự chuyên biệt hóa của phần tử khác. Kí hiệu: o Sự phụ thuộc (Dependency): Chỉ ra rằng một phần tử này phụ thuộc trong một phương thức nào đó với phần tử khác. Kí hiệu: o Kết tập (Aggregation): Một dạng đặc biệt của liên kết, trong đó, một phần tử này chứa các phần tử khác. Kí hiệu: o Mối quan hệ thực hiện (Realization): Một quan hệ thực hiện chỉ ra một lớp thực hiện hành vi đặc tả bởi một lớp khác (thường là một giao diện)[7] và được kí hiệu: 14 1.2. Ontology Để thực hiện việc chuyển đổi từ UML sang OWL Ontology, trước hết ta hãy tìm hiểu các khái niệm thế nào là Ontology? và nó có những đặc điểm như thế nào. Trước tiên, thuật ngữ “Ontology”, nó có nghĩa là “bản thể học”. Đối tượng nghiên cứu chủ yếu của Ontology là các sự vật và phân loại chúng dựa vào các điểm đặc trưng mang tính bản chất của nó ở trong thực tế. Trong lĩnh vực công nghệ thông tin và khoa học máy tính, ontology còn là sự biểu diễn tri thức mang tính hình thức bằng việc thiết lập các khái niệm trong một miền lĩnh vực nào đó và các mối quan hệ giữa các khái niệm đó. Nó được sử dụng để suy luận về các đặc tính hoặc để mô tả miền lĩnh vực nào đó [9]. Ontology có thể biểu diễn dựa trên các logic mô tả và khai thác được khả năng biểu diễn tri thức cũng như khả năng lập luận hiệu quả của logic mô tả. Vì thế, chúng ta sử dụng Ontology với các mục đích: o Thứ nhất là để chia sẻ những tri thức về các khái niệm, cấu trúc thông tin giữa con người hoặc giữa các hệ thống phần mềm. Ontology giống như một cuốn từ điển chuyên ngành, nó sẽ cung cấp và giải thích các thuật ngữ cho người dùng khi được yêu cầu. o Thứ hai, nó sẽ cho phép tái sử dụng tri thức. Chúng ta có thể trộn hai hay nhiều Ontology với nhau, và sử dụng lại các khái niệm được định nghĩa trong các Ontology này. Bài toán đặt ra làm cách nào để bổ xung các quan hệ, thuộc tính sẵn có vào một hệ thống mới hay đó chính là vấn đề tái sử dụng tri thức. o Và thứ ba là nó đưa ra các giả thiết rõ ràng về miền lĩnh vực. Ontology có thể dễ dàng thay đổi sự thực thi khi tri thức về lĩnh vực đó thay đổi. Thêm vào đó, việc đặc tả rõ ràng về một miền tri thức sẽ giúp cho người mới tiếp cận hiểu được ngữ nghĩa của các miền tri thức ấy. Để xây dựng được một Ontology, người ta có thể sử dụng khá nhiều ngôn ngữ khác nhau, nhưng một trong những ngôn ngữ biểu diễn Ontology một cách dễ dàng và hiệu quả nhất là OWL (Web Ontology Language). 1.3. OWL (Web Ontology Language) OWL (Web Ontology Language) là ngôn ngữ Ontology được phát triển bởi tổ chức W3C (The World Wide Web Consortium). Nó có thể xử lý thông tin chứa trong các văn bản, và đưa ra nội dung cần thiết cho người dùng, nó đối lập với trường hợp là chỉ đưa ra nội dung thông tin ấy có mặt ở đâu cho người sử dụng. Ngoài ra, OWL còn có thể được sử dụng để biểu diễn các ý nghĩa của một nhóm từ vựng và các mối quan hệ giữa các nhóm đó một cách rõ ràng rành mạch hơn. OWL có khả năng biểu diễn ý nghĩa và ngữ nghĩa một cách dễ dàng hơn là XML (Extensible Markup Language-Ngôn ngữ đánh dấu mở rộng), RDF (Resource Description Framework- Khung mô tả tài nguyên), hay RDF-S (RDF 15 Schema). OWL là một bộ từ vựng, mở rộng của khung mô tả tài nguyên (RDF) và được thừa kế từ ngôn ngữ DAML+OIL Web Ontology- một dự án được hỗ trợ bởi W3C. Nó kế thừa các ưu thế của ngôn ngữ này đồng thời khắc phục những hạn chế của RDFS. OWL có thêm khả năng mô tả các thuộc tính và các lớp, mối quan hệ giữa các lớp, các ràng buộc về số lượng, so sánh, nhiều kiểu thuộc tính, những nét đặc trưng của thuộc tính, .v.v. Vì vậy mà OWL có khả năng biểu diễn thông tin tri thức, nó là ngôn ngữ Ontology khá mạnh. Trong OWL có các mức khác nhau, mỗi mức lại có các đặc điểm riêng, và sau đây là chi tiết của từng mức. 1.3.1. Các mức của OWL OWL có 3 mức đó là OWL Lite, OWL DL và OWL Full. Ba mức này có khả năng diễn đạt cao dần, mức cao hơn là sự mở rộng của mức thấp hơn. o OWL Lite: Hỗ trợ những người dùng chủ yếu cần sự phân lớp theo thứ bậc và các ràng buộc đơn giản. Có nghĩa nó cho phép bạn định nghĩa các lớp và các thuộc tính cũng như thể hiện của các lớp và một vài ràng buộc đơn giản. Ví dụ như, khi trợ giúp các ràng buộc về số lượng các phần tử, nó chỉ cho phép số lượng các phần tử là 0 hoặc 1. Nó ít có khả năng để diễn đạt các mối quan hệ phức tạp và nó ít phức tạp hơn là OWL DL. o OWL DL (OWL Discription Logic):Ttrợ giúp những người dùng cần sự diễn đạt nhiều nhất trong khi vẫn duy trì được tất cả các chức năng có thể được tính toán (đảm bảo các kết luận có thể được tính toán) và có khả năng đưa ra quyết định (tất cả các tính toán sẽ kết thúc trong thời gian có hạn định). OWL bao gồm tất cả cấu trúc của ngôn ngữ OWL Lite, nhưng có thể sử dụng các ràng buộc ở dạng phức tạp hơn. o OWL Full: Người sử dụng có thể diễn đạt nhiều nhất và có cấu trúc cũng tự do của RDF mà không cần đảm bảo về mặt tính toán của các biểu thức. Ví dụ, trong một lớp của OWL Full có thể được coi là một tập hợp các thể hiện và cũng đồng thời là chính nó cũng là một thể hiện. OWL Full cho phép các ontology tăng thêm ý nghĩa cho vốn từ vựng đã được định nghĩa trước đó (RDF hoặc OWL). Trong đó, OWL Full là sự mở rộng của OWL DL, OWL DL lại là sự mở rộng của OWL Lite. OWL có thể được xem như là sự mở rộng của ngôn ngữ RDF, còn OWL Lite và OWL DL có thể được xem như là sự mở rộng ràng buộc của RDF. Và sau đây là một số các đặc điểm của OWL Lite, tiếp đó là các đặc điểm mở rộng của OWL DL và OWL Full. 1.3.2. Bản mô tả từ vựng ngôn ngữ OWL Lite Và sau đây là các thành phần chính của OWL Lite: 16 BẢNG 1: BẢNG MÔ TẢ TỪ VỰNG CỦA OWL LITE. RDF Schema So sánh Các kiểu thuộctính Class(Thing, Nothing) equivalentClass ObjectProperty rdfs:subClassOf equivalentProperty DatatypeProperty rdf:Property sameAs inverseOf rdfs:subPropertyOf differentFrom TransitiveProperty rdfs:domain AllDifferent SymmetricProperty rdfs:range distinctMembers FunctionalProperty Individual InverseFunctionalProperty Trong OWL cũng hỗ trợ để xây dựng các mối ràng buộc trong Ontolgy, sau đây là cấu trúc từ vựng của để mô tả các ràng buộc đó. BẢNG 2. CẤU TRÚC TỪ VỰNG OWL LITE MÔ TẢ RÀNG BUỘC Các ràng buộc thuộc tính Ràng buộc về tập hợp Các thông tin tiêu đề Restriction minCardinality (chỉ có 0 hoặc 1) Ontology onProperty maxCardinality (chỉ có 0 hoặc 1) imports allValuesFrom cardinality (chỉ có 0 hoặc 1) someValuesFrom Cũng như một số ngôn ngữ lập trình khác, OWL cho phép xây dựng những đoạn ghi chú, các thông tin về phiên bản của nó, v.v. BẢNG 3. BẢNG TỪ VỰNG XÂY DỰNG THÔNG TIN VỀ PHIÊN BẢN VÀ CHÚ THÍCH. Phần giao của lớp Phiên bản Chú thích intersectionOf versionInfo rdfs:label 17 priorVersion rdfs:comment backwardCompatibleWit h rdfs:seeAlso incompatibleWith rdfs:isDefinedBy DeprecatedClass AnnotationProperty DeprecatedProperty OntologyProperty Một phần không thể thiếu để có thể biểu diễn các thuộc tính dữ liệu trong Ontology đó là các kiểu dữ liệu. OWL hỗ trợ rất nhiều kiểu dữ liệu, và sau đây là bảng mô tả các kiểu dữ liệu của OWL: BẢNG 4. CÁC KIỂU DỮ LIỆU. xsd:string xsd:normalizedString xsd:boolean xsd:decimal xsd:float xsd:double xsd:integer xsd:nonNegativeInteger xsd:positiveInteger xsd:nonPositiveInteger xsd:negativeInteger xsd:short xsd:long xsd:int xsd:byte xsd:unsignedLong xsd:unsignedInt xsd:unsignedShort xsd:hexBinary xsd:unsignedByte xsd:date xsd:dateTime xsd:base64Binary xsd:gDay xsd:gYear xsd:time xsd:language xsd:anyURI xsd:gYearMonth xsd:NCName xsd:NMTOKEN xsd:gMonthDay xsd:gMonth xsd:token xsd:Name 18 Sau đây là mô tả chi tiết về một số thành phần của ngôn ngữ OWL Lite: o Class (lớp): Một lớp được định nghĩa là một tập hợp các thể hiện cùng có một số thuộc tính như nhau. Ví dụ như Nam và Hoa đều thuộc lớp Người. Các lớp được tổ chức thành hệ thống phân cấp với việc sử dụng subClassOf. Ví dụ: Ta tạo ra 3 lớp : Động vật, Thực vật, và Con người: Thực tế, thông thường ta luôn có một lớp được định nghĩa sẵn là owl:Thing, lớp này là lớp cha của tất cả các lớp mà ta dùng định nghĩa. Hoặc OWL cũng định nghĩa một lớp rỗng owl:Nothing. o rdfs:subClassOf : Tạo ra một hệ thống phân cấp các lớp, một lớp là lớp con của một lớp khác. Chẳng hạn, lớp Động vật có thể là lớp con của lớp Sinh vật: o rdf:Property: Các thuộc tính có thể được sử dụng để biểu diễn các mối quan hệ giữa các thể hiện hoặc các thể hiện với các giá trị dữ liệu. Ví dụ các thuộc tính như hasChild, hasSibling, hay hasAge. Trong OWL có owl:DatatypeProperty và owl:ObjectProperty đều là lớp con của rdf:Property trong RDF. Ví dụ: Máy bay có các chuyến bay  lớp Plane có thuộc tính hasFlight, liên quan đến lớp Flight. Còn thuộc tính name của lớp sinh vật có thuộc tính kiểu dữ liệu xsd:string. o subPropertyOf: các thuộc tính cũng phân cấp, một thuộc tính này có thể là thuộc tính con của một hoặc một vài thuộc tính khác. Chẳng hạn như thuộc tính hasSibling có thể là thuộc tính con của thuộc tính hasRelative. Ta có: 19 o rdfs:domain : Một miền của thuộc tính giới hạn các thể hiện có thể được ứng dụng . Hay nói khác đi là nó xác đinh thuộc tính của miền này thuộc vào lớp nào. Như ví dụ lớp Sinh vật ở trên, thuộc tính name được khai báo với rdfs:domain thì thuộc tính name này thuộc lớp Sinh_vat. o rdfs:range : Phạm vi của thuộc tính cũng bị giới hạn các giá trị có được. Ta xét ví dụ sau: Giá trị cụ thể của thuộc tính “hasFlight” sẽ là một hoặc một vài thể hiện của lớp Flight. o Các thể hiện: Các thể hiện đó là các minh họa cụ thể của lớp. Ví dụ, sinh viên Lan, là một thể hiện của lớp Sinh_vien, với thuộc tính name có giá trị là Lan, .v.v. Ta có ví dụ sau: Ta tạo một thể hiện cho lớp Dong_vat: o equivalentClass (Lớp tương đương): Hai lớp cũng có thể tương đương nhau, các lớp tương đương có cùng các trường hợp. Ví dụ, người viết một cuốn sách (Writer) là một tác giả của cuốn sách ấy (Author) thì hai cách gọi Writer và Author là tương đương nhau. Vì vậy, một thể hiện của Writer cũng là một thể hiện của Author và ngược lại. 20 Hoặc: Với điều kiện trước đó, ta đã khai báo lớp FictionBook là lớp con của lớp Book, lớp Book lại có thuộc tính là genreOf, thì lớp FictionBook được gọi là tương đương với lớp Book có thuộc tính genreOf có giá trị là Fiction. o equivalentProperty (Thuộc tính tương đương): Chẳng hạn ta có thể chỉ ra rằng thuộc tính writerOf, và thuộc tính authorOf chỉ cùng một khái niệm. o sameAs: Hai cá thể (hay là thể hiện) có thể tương đương nhau. Cấu trúc này có thể được sử dụng để tạo ra những cái tên khác nhau, nhưng đều cùng chỉ về một cá thể (thể hiện). Ví dụ như: một dịch vụ có thể cung cấp cho bạn một thể hiện của lớp Vat_dung (Vật dụng) là Coc , trong khi dịch vụ khác lại định nghĩa là Ly ta khai báo: Khi đó hệ thống đó sẽ biết rằng, bất kì thông tin nào về Coc (cốc) thì cũng áp dụng được với Ly (ly) và ngược lại. o differentFrom: Một thể hiện này được diễn tả khác với các cá thể khác, nó ngược lại với sameAs. Ví dụ: 21 o AllDifferent: Tất cả các thể hiện được khai báo trong owl:AllDifferent sẽ được phân biệt với nhau. o inverseOf: Các thuộc tính nghịch đảo là với mỗi một hoạt động, nó có tương ứng một hoạt động ngược lại. Ví dụ, thuộc tính subClass, có thể có thuộc tính superClass. Ví dụ như: o TransitiveProperty (thuộc tính bắc cầu): Nếu A là tổ tiên của B biểu diễn bằng thuộc tính isAncestorOf. Tương tự, B là tổ tiên của C thì suy ra A là tổ tiên của C, hay là với thuộc tính isAncesorOf là thuộc tính bắc cầu. Đó là tính chất bắc cầu. Ví dụ: o SysmetricProperty (Thuộc tính đối xứng): chẳng hạn thuộc tính isFriendOf là thuộc tính đối xứng, chẳng hạn nều An là bạn của Nam, thì Nam là bạn của An. Ví dụ biểu diễn: o FunctionalProperty (thuộc tính chức năng): Đây là thuộc tính chỉ có giá trị duy nhất. Ví dụ 22 o InverseFunctionalProperty (thuộc tính chức năng nghịch đảo): Ví dụ: Khi đó, thuộc tính producesWine chỉ có 1 giá trị, và thuộc tính nghịch đảo của nó là hasMaker. Và sau đây là một số các ràng buộc trên thuộc tính của OWL Lite: o allValuesFrom: Thể hiện sự ràng buộc của thuộc tính với lớp. Nó có nghĩa là thuộc tính ấy trên lớp liên quan có một phạm vi ràng buộc đi kèm với nó. Chẳng hạn, một lớp Person có một thuộc tính hasDaughter ràng buộc kiểu allValuesFrom với lớp Woman. Khi đó, nếu có một thể hiện của lớp Person là Nam, có thuộc tính hasDaughter có giá trị là An chẳng hạn, thì có thể suy ra là An thuộc lớp Woman. Tức là tất cả các giá trị của hasDaughter đều là thể hiện của lớp Woman. o someValuesFrom: Ví dụ trang WebPaper có ràng buộc kiểu someValuesFrom trên thuộc tính hasKeyword thì một vài giá trị của hasKeyword có thể là các thể hiện của lớp WebPaper. Hay nói cách khác, một trong số các giá trị của hasKeyword có thể là thể hiện của WebPaper. Trên OWL Lite còn có sự ràng buộc về tập hợp: o minCardinality và maxCardinality: số lượng nhỏ nhất và lớn nhất các phần tử của tập hợp các giá trị của thuộc tính. o cardinality: Số lượng phần tử của giá trị thuộc tính là một số xác định o Khoảng giá trị: Được biểu diễn trong khoảng minCardinality và maxCardinality. Trong OWL Lite, giá trị nguyên có thể gán là 0 và 1. Ví dụ minh họa: 23 Một số các đặc điểm mở rộng của OWL DL và OWL Full: o oneOf: Các lớp có thể được mô tả bằng một bảng liệt kê các thể hiện tạo nên lớp đó. Ví dụ, lớp daysOfWeek có các thể hiện là Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday. Xét ví dụ: o hasValue: Một thuộc tính nào đó yêu cầu cần phải có chắc chắn một giá trị. ví dụ : Thuộc tính hasSugar phải có ít nhất một giá trị, và đó là giá trị Dry. o disjointWith: Các lớp có thể được bắt đầu được phân tách ra thành các phần khác nhau. Ví dụ, Man và Woman có thể được tách ra các lớp. Giả dụ, A là một thực thể của Man, thì A không thể là thực thể của Woman. Ta xét ví dụ: 24 Khi đó, nếu một thực thể của EdibleThing thuộc Pasta thì sẽ không thể là Meat, Fowl, Seafood, Dessert, Fruit. Chỉ có Pasta là phân tách với các lớp trên, chứ không khẳng định có phân tách giữa các lớp còn lại với nhau, chẳng hạn như Meat và Fruit. o unionOf, complementOf, intersectionOf: OWL DL và OWL Full cho phép tính dựa vào sự kết hợp các lớp và các ràng buộc theo kiểu Boolean (Đại số Boolean): unionOf (hợp), complementOf (giao), và intersectionOf (phần bù). Ví dụ: o minCardinality, maxCardinality, cardinality: Trong OWL DL và OWL Full không giới hạn số lượng các phần tử như trong OWL Lite. Nghĩa là một thuộc tính nào đó có thể có số lượng phần tử nhỏ nhất là 2. OWL còn rất nhiều cú pháp lệnh nữa, nhưng trong khóa luận này, chúng tôi chỉ xin trình bày những cấu trúc từ vựng thường dùng nhất và để thuận tiện cho chuyển đổi từ mô hình UML sang OWL Ontology, tôi sẽ sử dụng OWL DL. 1.4. OWL Ontolgogy OWL Ontology cũng có thể hiểu là một ngôn ngữ hay một tập các quy tắc để mô tả một cách tường mình các khái niệm và các quan hệ giữa các khái niệm để hỗ trợ tương tác giữa các hệ thống được sử dụng trong khoa học máy tính hay công nghệ thông tin. Nó sẽ cung cấp một bộ từ vựng để xây dựng các khái niệm, các thuộc tính quan trọng. Ngoài ra, OWL Ontology còn cung cấp các mối ràng buộc được sử dụng trong một miền lĩnh vực nào đó để có thể giao tiếp giữa người với một hệ thống ứng dụng phân tán khác. 25 Hay nói một cách ngắn gọn hơn, OWL Ontology là ontology được xây dựng sử dụng OWL. 1.4.1. Các phần tử trong OWL Ontology o Các cá thể hay là các thể hiện (individuals): Các cá thể là các thành phần cơ bản, nền tảng của một ontology. Các cá thể trong một ontology có thể bao gồm các đối tượng cụ thể như con người, động vật, cái bàn... hoặc là các cá thể trừu tượng như các thành viên hay công ty .v.v. o Các lớp hay là các khái niệm (Class): Lớp là một nhóm, một tập hợp các đối tượng trừu tượng có chung các đặc tính nào đó. Chúng có thể chứa các cá thể, các lớp khác, hay là sự phối hợp của cả hai. Hầu hết các Ontology đều tập trung xây dựng các lớp được tổ chức theo một cấu trúc phân cấp để mô tả các loại vật trong một miền lĩnh vực cần quan tâm. Ví dụ “sinh vật” là một lớp trong ngữ cảnh sinh vật học. Bên dưới lớp này có thể có các lớp con ví dụ như lớp “động vật” và “thực vật”... o Các thuộc tính (Properties) Các đối tượng trong ontology có thể được mô tả thông qua việc khai báo các thuộc tính của chúng. Mỗi một thuộc tính đều có tên và giá trị của thuộc tính đó. Các thuộc tính được sử dụng để lưu trữ các thông tin mà đối tượng có thể có. Ví dụ, đối với một cá nhân có thể có các thuộc tính: Họ_tên, ngày_sinh, quê_quán, số_cmnd... Giá trị của một thuộc tính có thể có các kiểu dữ liệu phức tạp. o Các mối ràng buộc (Relation) Các mối ràng buộc mô tả một số ràng buộc về ý nghĩa của các khái niệm và quan hệ với các khái niệm khác. Chẳng hạn với tính chất “Employee_ID” chẳng hạn, sẽ mỗi nhân viên chỉ có duy nhất một mã số. 1.4.2. Một số công cụ hỗ trợ việc xây dựng OWL Ontology Về mặt lý thuyết thì người ta có thể hoàn toàn xây dựng được một OWL Ontology mà không cần đến các công cụ để hỗ trợ, mà có thể thực hiện trực tiếp và thủ công bằng các ngôn ngữ như OWL. Tuy nhiên, nếu một Ontology có kích thước lớn và có cấu trúc phức tạp, thì việc thực hiện thủ công sẽ mất khá nhiểu thời gian và công sức. Thêm vào đó, việc xây dựng nên một Ontology không chỉ đòi hỏi việc tao ra các cấu trúc phân cấp, định nghĩa các thuộc tính, ràng buộc, v.v. mà nó còn liên quan đến việc kiểm tra tính đúng đắn và đầy đủ của Ontology, suy luận trên Ontology, v.v. Vì vậy, các công cụ hỗ trợ sẽ làm giảm được thời gian xây dựng cũng như có thể kiểm chứng được mô hình Ontology. Công cụ hỗ 26 trợ góp phần đắc lực trong việc xây dựng Ontology và ảnh hưởng rất lớn đến chất lượng của một hệ thống Ontology. Sau đây là một số các công cụ hỗ trợ xây dựng OWL Ontology: 1.4.2.1. Protégé Protégé là một bộ phần mềm mã nguồn mở Java nổi tiếng, được nghiên cứu và phát triển từ năm 1978 do một nhóm nghiên cứu của Mark Musen, ĐH, Stanford, để quản lý thông tin trong lĩnh vực y học. Mã nguồn của Protégé có thể được tìm thấy tại website: Các ưu điểm của Protégé là: o Đầu tiên, công cụ này hỗ trợ đầy đủ ba phiên bản của ngôn ngữ OWL là OWL Lite, OWL DL và OWL Full. o Thứ hai là, nhờ việc sử dụng mô hình hướng đối tượng của ngôn ngữ Java, Protégé tỏ ra rất hiệu quả trong việc mô hình các lớp, thực thể, và các mối quan hệ, v.v. o Thứ ba, giao diện thiết kế của nó có tính trực quan và tính tương tác cao. Người sử dụng có thể định nghĩa các thành phần của Ontology bằng cách điền trực tiếp vào các form cho sẵn. o Thứ tư, nó cho phép biểu diễn trực quan Ontology dưới dạng các sơ đồ. o Thứ năm là nó cung cấp chức năng tìm kiếm lỗi, kiểm tra tính nhất quán và đầy đủ của Ontology. Để sử dụng, người thiết kế chọn chức năng Run Ontology Test và Check Consistency. o Và cuối cùng, nó hỗ trợ sinh mã tự động. Protégé cho phép chuyển Ontology thành mã nguồn RDF/XML, OWL, DIG, Java, EMF Java Interfaces, Java Schema Classes. Các mã này có thể được nhúng trực tiếp vào ứng dụng và là đầu vào cho các thao tác trên Ontology khi cần. Ngoài ra, nó còn cung cấp đầy đủ chuẩn giao tiếp cho các Plug-in. Và sau đây là giao diện của Protégé 3.4: 27 Hình 1.8. Giao diện Protégé 3.4.4. Bên cạnh công cụ hỗ trợ xây dựng Ontology hữu hiệu như là Protégé, còn có một số công cụ khác, cũng hỗ trợ để xây dựng, và chỉnh sửa OWL Ontology rất trực quan và khá hiệu quả. Một trong số đó là Altova Semantic Works. 1.4.2.2. Altova SemanticWorks ® 2010 Altova SemanticWorks cung cấp sự hỗ trợ hiệu quả trong việc tạo ra và chỉnh sửa những OWL Ontology một cách rất trực quan. Altova SemanticWorks ® 2010 hỗ trợ cả ba mức ngôn ngữ của OWL. Sử dụng SemanticWorks, ta có thể tạo ra những ontology phức tạp một cách trực quan, có các biểu tượng trực quan, v.v. Altova SemanticWorks ® 2010 chia ra các thành phần khác nhau tạo nên một ontology thành năm mục: Classes (Các lớp), Properties (Thuộc tính), Instances (các ví dụ cụ thể), allDifferent và Ontologies. Trong mục Classes, nó hiển thị tất cả các lớp của ontology và một phần cửa sổ hiện ra sẽ là danh sách các thuộc tính và những thể hiện của lớp đó. Toàn bộ thuộc tính của ontology cũng được liệt kê trong mục Property, và có một cửa sổ ngăn cách là các mục liệt kê các miền của thuộc tính đó. Tất cả các thể hiện của lớp được liệt kê trong mục Instances, còn mục allDifferent là danh sách các mục (items) phân biệt với nhau trong một ontology. Và cuối cùng là mục Ontologies chứa tất cả các tài nguyên là các ontology, bao gồm các ontology đã được nhập vào file hiện tại. 28 Công cụ này cung cấp cấu trúc kiểm tra xem OWL ontology có thể chuyển thành đặc tả RDF/XML, đồng thời, nó cũng hỗ trợ việc kiểm tra ngữ nghĩa trong OWL DL và OWL Lite, và đưa ra các danh sách lỗi hoặc xung đột. Hình 1.9. Giao diện Altova SematicWorks. 29 Hình 1.10. Giao diện Altova SematicWorks. Hiện nay, còn rất nhiều công cụ có khả năng hỗ trợ tạo ra OWL Ontology, song Protégé là công cụ rất hữu ích để xây dựng một ontology một cách rất trực quan và được sử dụng khá phổ biến. Nó hỗ trợ khá chi tiết về các lớp, thuộc tính và mối quan hệ ràng buộc trong các ontology. Do vậy, chúng tôi sẽ sử dụng công cụ hỗ trợ Protégé 3.4 để tạo ra OWL Ontology trong bài khóa luận này. Và sau đây là một ví dụ về một OWL Ontology biểu diễn một hệ thống các sinh vật bằng Protégé: 30 Hình 1.11. Các lớp và thuộc tính với các ràng buộc. Hình 1.12. Các thuộc tính. 31 Hình 1.13. Các thể hiện của lớp. Chương 1 đã trình bày sơ lược về ngôn ngữ mô hình hóa thống nhất UML bao gồm các loại biểu đồ: biểu đồ ca sử dụng, biểu đồ lớp, biểu đồ đối tượng, biểu đồ trạng thái, biểu đồ tuần tự, biểu đồ cộng tác, và các thành phần trong mô hình UML. Bên cạnh đó, chương này cũng đề cập đến các khái niệm về Ontology, OWL và các thành phần chính của OWL. Và cuối cùng là một số các công cụ hỗ trợ tạo một OWL Ontology. Trong chương 2, tôi sẽ trình bày về các quy tắc để chuyển đổi từ mô hình UML sang OWL Ontology. 32 CHƯƠNG 2: CÁC QUY TẮC CHUYỂN ĐỔI TỪ MÔ HÌNH UML SANG OWL ONTOLOGY 2.1. Giới thiệu Như đã giới thiệu ban đầu, bài toán được đặt ra là kiểm tra mô hình sau khi áp dụng thiết kế mẫu có thỏa mãn các tính chất cấu trúc của giải pháp mẫu hay không, nhờ vào việc chuyển đổi từ mô hình UML sang OWL và sử dụng Prolog để thể hiện các yếu tố ràng buộc trong mô hình. Tuy nhiên, trong OWL không hỗ trợ đầy đủ các ràng buộc, liên kết mà các yếu tố trên mô hình UML thể hiện. Ví dụ như công cụ không hỗ trợ việc biểu diễn phương thức trong các lớp, các liên kết, v.v. Vì vậy, cần có các quy tắc chuyển đổi từ mô hình UML sang OWL để biến đổi một mô hình UML sang OWL sao cho đạt kết quả thật chính xác. Và sau đây tôi xin trình bày một số quy tắc chuyển đổi. 2.2. Quy tắc chuyển đổi từ mô hình UML sang OWL Ontology BẢNG 5: BẢNG LIỆT KÊ CÁC QUY TẮC CHUYỂN ĐỔI UML OWL Mô tả Gói (Package) owl:Ontology Được khai báo trong phần đầu Lớp (Class) o Lớp cụ thể o Lớp ảo owl:Class o owl:Class o owl:Class, “isAbstract” Tên tương ứng với nhau Đối với lớp ảo, thêm thuộc tính kiểu đối tượng “isAbstract” Chú thích (Comment) owl:comment / Giao diện (Inteface) owl:Class, rdfs:subClassOf / Tổng quát hóa (Generalization) owl:subClassOf / Liên kết (Association) o Liên kết một hướng o Liên kết hai hướng o Lớp liên kết owl:ObjectProperty Mỗi trường hợp có một cách chuyển đổi khác nhau. Vai trò (Roles) owl:ObjectProperty / Thuộc tính (Attributes) owl:DatatypeProperty owl:ObjectProperty / 33 Ràng buộc số lượng owl:cardinality owl:minCardinality owl:maxCardinality / Quan hệ phụ thuộc: o Phụ thuộc một lớp o Phụ thuộc nhiều lớp owl:ObjectProperty, “Dependency” / Liệt kê owl:one of / Kết tập owl:ObjectProperty “has_{class_name}” / Phương thức / Phương thức được chuyển đổi theo cách riêng. Và sau đây là mô tả một cách chi tiết các quy tắc chuyển đổi từ UML sang OWL: 2.2.1 Gói (Package) Gói là một nhóm các phần tử của mô hình gồm có các lớp, các quan hệ và các gói nhỏ hơn. Gói được mô tả trong UML gồm có tên gói, có thể có các lớp,gói nhỏ khác và được kí hiệu như sau: Hình 2.1. Kí hiệu gói. Biểu diễn trong OWL: owl: Ontology Các thông tin về gói dữ liệu sẽ được khai báo ở ngay phần đầu của file OWL Ontology. Các lớp trong gói sẽ chung một tên gói được khai báo trong phần đầu đó. Ví dụ ta có gói Pizza như sau: Hình 2.2. Ví dụ về gói. Trong OWL Ontololgy sẽ được biểu diễn như sau: OWL: Ontology 34 2.2.2. Lớp (Class) 2.2.2.1. Lớp cụ thể UML: Class Trong UML có lớp cụ thể và lớp trừu tượng, lớp cụ thể là lớp có các thể hiện cụ thể. Còn lớp trừu tượng là lớp không có các thể hiện cụ thể trong hệ thống thực. Do vậy, ta có thể định nghĩa các hàm trừu tượng cho các lớp trừu tượng, đó là những hàm chưa được cài đặt nội dung thực hiện trong lớp chúng được khai báo, mà những hàm này sẽ được cài đặt trong các lớp con cháu sau đó ở các lớp cụ thể. Ta có quy tắc chuyển đổi từ lớp cụ thể sang OWL Ontology như sau: Hình 2.3. Kí hiệu Lớp UML. OWL: Class Tên trong lớp OWL tương ứng với tên trong lớp UML, được khai báo trong phần 35 2.2.2.2. Lớp ảo UML:Abstract Class OWL: owl:Class, DatatypeProperty:isAbtract. Trong OWL sẽ khai báo Lớp, với tên lớp là tên lớp ảo trong UML, và có thuộc tính ‘isAbstract’ kiểu DatatypeProperty:Boolean, và giá trị cho thuộc tính này sẽ là ‘true’. Đối với lớp ảo, ta có ví dụ dưới đây, lớp Nhan Vien là lớp ảo, việc chuyển đổi sang OWL : Hình 2.4. Ví dụ minh họa lớp ảo. 2.2.3. Chú thích UML: Comment , Note OWL: owl:comment 36 2.2.4. Giao diện (Interface) UML: Giao diện (Interface) Giao diện là tập hợp những thao tác quan sát được từ bên ngoài của một lớp và/ hoặc một thành phần, không có nội dung cài đặt riêng lớp đó. OWL: owl:Class, rdfs:subClassOf OWL sẽ định nghĩa giao diện như một lớp (owl:Class), và định nghĩa thêm lớp thừa kế lớp đó (rdfs:subClassOf) và có các thành phần để cài đặt lớp cha. Ta xét ví dụ sau: Hình 2.5. Ví dụ minh họa Interface. Ta sẽ định nghĩa giao diện “Person”: 2.2.5. Tổng quát hóa UML: Tổng quát hóa (Generalization): OWL: owl:subClassOf. 37 Tổng quát hóa là đi từ các lớp dưới lên trên, sau đó hình thành lớp tổng quát (lớp trên, lớp cha), tức là cây cấu trúc từ lá đến gốc. Khi đó tổng quát hóa chính là quan hệ kế thừa giữa các lớp. Trong đó, lớp con (lớp dưới, lớp kế thừa hay lớp dẫn xuất) kế thừa trực tiếp các thuộc tính và các phương thức thuộc loại công khai (public), hay được bảo vệ (protected) của lớp cha (lớp trên hay lớp cơ sở). Trong OWL sẽ được biểu diễn bằng owl:subClassOf. Ta có ví dụ sau: Hình 2.6. Minh họa quan hệ thừa kế. Lớp B thừa kế lớp A: Ta sẽ định nghĩa lớp A, sau đó định nghĩa lớp B là lớp con của lớp A: Ví dụ trên được chuyển sang OWL Ontology: Khi muốn khai báo hai lớp con (B và C cùng thừa kế một lớp cha A) tách rời nhau thì ta sẽ sử dụng: owl:disjointWith 2.2.6. Liên kết (Association) UML : Mối quan hệ liên kết OWL: owl:ObjectProperty 38 Một liên kết là một sự nối kết giữa các lớp, nó liên quan về ngữ nghĩa giữa các đối tượng của các lớp tham gia. Lớp và liên hệ giữa các lớp là những công cụ rất mạnh mẽ cho việc mô hình hóa các hệ thống phức tạp, ví dụ như cấu trúc sản phẩm, cấu trúc văn bản và tất cả các cấu trúc thông tin khác. Ví dụ: Hình 2.7. Lớp Author liên kết với lớp Computer. Theo nguyên tắc, khi chuyển liên kết sang OWL Ontology, thì liên kết sẽ được chuyển thành một thuộc tính đối tượng (kiểu ObjectProperty). Tùy từng loại liên kết thì có quy tắc chuyển khác nhau. 2.2.6.1. Trường hợp Liên kết theo một hướng Ví dụ: Hình 2.8. Minh họa liên kết một hướng. Khi đó, trong OWL Ontology, tạo ra 2 lớp HTBanHang và PhieuBanHang, các thuộc tính của lớp tương ứng và thêm một thuộc tính đối tượng (ObjectProperty) là “Ghi_nhan” sẽ được tạo ra trong lớp HTBanHang để liên kết hai lớp HTBanHang và PhieuBanHang. Trong trường hợp không có tên vai trò trong liên kết thì công cụ hỗ trợ sẽ tự động tạo đặt tên cho thuộc tính này. Khi đó, rdf:domain và rdf:range của thuộc tính đó tương ứng sẽ là rdf:ID= “HTBanHang” và rdf:ID= “PhieuBanHang”. 39 2.2.6.2. Liên kết theo hai hướng Với liên kết theo hai hướng, với mỗi liên kết ta cũng chuyển đổi tương tự như đối với liên kết theo 1 hướng. Tùy vào chiều mũi tên mà ta có thuộc tính đối tượng của vai trò liên kết đó sẽ ở lớp nào, và thuộc tính đối tượng còn lại của vai trò liên kết có thể theo kiểu ngược lại (inverseOf) với thuộc tính của vai trò kia hoặc không. Ví dụ: Hình 2.9. Minh họa mối liên kết hai chiều. Ta sẽ xây dựng 2 lớp Customer và lớp Account, một thuộc tính đối tượng Holds thuộc lớp Customer, và thuộc tính Owned by thuộc lớp Account. Thuộc tính Owned by theo kiểu đảo ngược với thuộc tính Holds. Vì vậy, trong OWL, sơ đồ trên sẽ được chuyển sang OWL như sau: 40 2.2.6.3. Lớp liên kết Ta xét ví dụ sau: Hình 2.10. Lớp liên kết. Khí đó, lớp Employment sẽ là lớp liên kết của Company và lớp Person. Lớp liên kết sẽ có thêm thuộc tính dữ liệu (DatatypeProperty) là “isAssociationClass”, với kiểu Boolean và giá trị cho thuộc tính này là true. Ngoài ra, lớp liên kết còn có thêm hai thuộc tính đối tượng nữa là “firstOf_{association_class_name }”, và “secondOf_{association_class_name}”. Vì vậy, theo như ví dụ trên, lớp liên kết sẽ được biểu diễn như sau: Để đặt giá trị cho isAssociationClass: Thuộc tính “firstOf_Employment”: Thuộc tính “secondOf_Employment”: 41 2.2.7. Các vai trò (Roles) Các vai trò trong liên kết được chuyển sang là thuộc tính đối tượng (ObjectProperty). Đồng thời nó được khai báo là thuộc tính con (subObjectPropertyOf) của thuộc tính mô tả liên kết mà nó tham gia. Ví dụ như sau: Hình 2.11. Ví dụ minh họa các vai trò. Vai trò “instructor” được chuyển sang thành thuộc tính ObjectProperty trong lớp StaffMember, thuộc tính này được khai báo là thuộc tính con (subObjectPropertyOf) của thuộc tính đối tượng “instructs”. 2.2.8. Các thuộc tính (Attributes) Hình 2.12. Minh họa thuộc tính lớp. Thuộc tính có giá trị là kiểu dữ liệu (DatatypeProperty) và thuộc tính có giá trị là kiểu đối tượng ( tức là các lớp). Khai báo thuộc tính dữ liệu: Khai báo thuộc tính đối tượng: 42 Hình 2.13. Minh họa ObjectPropeprty. Ví dụ trên được chuyển sang OWL: 2.2.9. Ràng buộc số lượng UML : Số lượng trong liên hệ Số lượng được ghi ở phía đầu đường thẳng thể hiện liên hệ, sát vào lớp là miền áp dụng của nó. Phạm vi của số lượng phần tử trong liên hệ có thể từ 0-tới-1 (0..1), 0-tới-nhiều (0..*), hay một-tới-nhiều (1..*), hai (2), năm-tới-mười một (5..11). Cũng có thể miêu tả một dãy số ví dụ (1,4,6, 8..12). Giá trị mặc định là 1. Hình 2.14. Sơ đồ lớp biểu diễn hệ thống quản lý dịch vụ tiết kiệm. 43 Khi đó, dịch vụ tài khoản tiết kiệm (Savings Account Service) sẽ có một tới nhiều tài khoản tiết kiệm (Saving Account). Khách hàng có thể có một hoặc nhiều tài khoản, còn tài khoản thì được sở hữu bởi từ 1 đến 3 khách hàng. v.v. Ta có các giàng buộc về số lượng sẽ được biểu diễn trong OWL như sau: 2.2.9.1. owl:cardinality Ràng buộc với số lượng phần tử chính xác với số lượng cụ thể. Ví dụ: Với lớp sinh vật, số lượng giới tính (với thuộc tính là “gioi_tinh”) chỉ là [3] chẳng hạn. Khi đó ta sẽ có giàng buộc như sau: 2.2.9.2. owl:minCardinality Ràng buộc với số lượng phần tử nhỏ nhất như [1..*] Ví dụ như với sơ đồ quản lý tài khoản tiết kiệm, Dịch vụ quản lý tài khoản tiết kiệm quản lý ít nhất một tài khoản tiết kiệm. Khi đó ta sẽ có: 2.2.9.3. owl:maxCardinality Tương tự với số lượng phần tử nhỏ nhất owl:minCardinality. 44 Khoảng giá trị: Nếu số lượng phần tử giới hạn trong một khoảng ví dụ [1..3] thì ta sẽ khai báo ràng buộc với owl:minCardinality với giá trị là 1, và owl:maxCardinality với giá trị là 3, tương tự cách khai báo như trên. Nếu số lượng phần tử cụ thể là các số (có nhiều giá trị của số lượng phần tử) ta có thể thêm vào với owl:cadinality, tương tự như các ví dụ trên. 2.2.10. Mối quan hệ phụ thuộc UML: Mối quan hệ phụ thuộc (Dependencies) Hình 2.15. Minh họa mối sự phụ thuộc. Do Lớp Sale có tham số của phương thức là kiểu lớp ProductDescription nên đó là một kiểu phụ thuộc. Đối với quan hệ phụ thuộc thì trong OWL sẽ được biểu diễn như sau: Ta sẽ tạo ra một thuộc tính là “Dependency” kiểu ObjectProperty. Các owl:domain và owl:range sẽ là các lớp tham gia vào mối quan hệ phụ thuộc này. Như trong ví dụ, trong lớp Sale sẽ có thêm một thuộc tính là “Dependency” có kiểu ObjectProperty. 2.2.10.1. Phụ thuộc vào một lớp Chẳng hạn ta có ví dụ sau: Lớp A phụ thuộc vào lớp B: 45 Hình 2.16. Quan hệ phụ thuộc. Khi đó, ta sẽ chuyển đổi sang OWL như sau: 2.2.10.2. Phụ thuộc vào nhiều lớp Ví dụ như lớp A phụ thuộc lớp B và lớp C thì ta sử dụng owl:unionOf. Đối với những liên kết hoặc thuộc tính có tên tương đương nhau, thì khi đó ta sẽ chuyển liên kết hay thuộc tính tương đương về một thuộc tính kiểu đối tượng (kiểu ObjectProperty). Với liên kết có tên tương đương nhau thì miền và phạm vi sẽ được xác định thông qua các lớp mà liên kết chỉ đến. Các lóp đó sẽ được kết hợp bằng “owl:unionOf” tương tự như trên và phần liên kết đã giải thích cách chuyển đổi liên kết sang OWL. Với các thuộc tính tương đương nhau, tương đương về tên lẫn giá trị thì chúng cũng được chuyển giống như với liên kết. 2.2.11. Liệt kê UML: Kiểu liệt kê 46 Trong lớp bao gồm các thể hiện của lớp, với lớp kiểu liệt kê này, trong OWL Ontology ta sẽ sử dụng owl:oneOf. Ta xét ví dụ sau: Hình 2.17. Minh họa kiểu liệt kê. Ta có: 2.2.12. Kết tập UML: Kết tập Kết tập là một trường hợp đặc biệt của liên hệ. Kết tập biểu thị rằng quan hệ giữa các lớp dựa trên nền tảng của nguyên tắc "một tổng thể được tạo thành bởi các bộ phận". Nó được sử dụng khi chúng ta muốn tạo nên một thực thể mới bằng cách tập hợp các thực thể tồn tại với nhau. Một ví dụ tiêu biểu của kết tập là chiếc xe ô tô gồm có bốn bánh xe, một động cơ, một khung gầm, một hộp số, v.v.... Xét ví dụ sau: Một lớp tài khoản được tạo bởi các lớp chi tiết về khách hàng, các lệnh giao dịch đối với tài khoản cũng như các quy định của nhà băng. Quan hệ trên có thể được trình bày như sau: 47 Hình 2.18. Minh họa mối quan hệ kết tập. Trong OWL không có một cấu trúc xác định nào cho mối quan hệ Bộ phận- Toàn bộ. Kết tập được xem như một loại liên kết. Ví vậy, với mối quan hệ này thì lớp tổng thể cần phải có thêm thuộc tính “has_{tên lớp bộ phận}” kiểu ObjectProperty. Và ở mỗi lớp bộ phận, nên có thêm thuộc tính là “{lớp bộ phận}_partOf_{tên lớp tổng thể}”. Với ví dụ như trên, ta sẽ có: 2.2.13. Phương thức Đối với phương thức, OWL không có cấu trúc để hỗ trợ. Điều này đòi hỏi, cần phải có luật chuyển đổi riêng. Khi đó, ta sẽ khai báo Phương thức như một lớp riêng và có quan hệ kết tập với lớp, có nghĩa là Lớp chứa các phương thức. Các thuộc tính Operator và các liên kết được thể như hình dưới. 48 Class +name: String +isAbstract: Boolean Operation +name: String +isAbstract: Boolean +visibility: VisibilityKind +Commonality: Boolean Parameter +name: String +direction: ParameterDirectionKind +class +ownedOperation 0..1 * +operation +ownedParameter 0..1 * +superClass +subClass * * Hình 2.19. Siêu mô hình của biểu đồ lớp UML. Khi đó, ta sẽ tạo thêm 2 lớp là lớp Parameter (tham số) và lớp Type với hai lớp con kế thừa nó là VisibilityKind và lớp ParameterDirectionKind. Khi đó ta sẽ có quy tắc chuyển đổi đối với phương thức trong UML như sau: o Lớp Class sẽ có thêm một thuộc tính kiểu đối tượng là “ownedOperation” với owl:domain là Class, và owl:range là Operation. Xây dựng lớp Operation với các thuộc tính: o op_name: DatatypeProperty: String. Tên phương thức o isAbstract: DatatypeProperty: Boolean Kiểm tra xem phương thức có là phương thức ảo không? Nếu là phương thức ảo, thuộc tính này nhận giá trị true, nếu không là false. o visibility: ObjectProperty:VisibilityKind Thuộc tính này kiểu Phương thức thuộc loại nào? public, protected hay private, có liên kết với lớp VisibilityKind. o commonality: DatatypeProperty:Boolean. Phương thức có được triển khai như nhau không? Nếu có thì thuộc tính nhận giá trị true, ngược lại là false. o ownedParameter: ObjectProperty:Parameter. Phương thức có những tham số nào? có liên kết với lớp Parameter. o class: ObjectProperty: Class : liên kết với lớp Class. 49 Tiếp đó ta sẽ xây dựng lớp Parameter (Tham số): o para_name: DatatypeProperty: String. Tên tham số o direction: ObjectProperty: ParameterDirectionKind Dạng trả về của tham số là in, out, inout, return. Nó rdf: range là lớp ParameterDirectionKind. Tiếp theo là xây dựng hai lớp VisibilityKind và ParmeterDirectionKind. Lớp VisibilityKind có thuộc tính: o visibilityKind: DatatypeProperty: String. Có 4 lựa chọn cho phạm vi thuộc tính là : o Public: Mọi lớp đều nhìn thấy thuộc tính, phương thức. o Private: Lớp khác không nhìn thấy thuộc tính, phương thức. o Protected: Các lớp thừa kế có thể nhìn thấy. o Package và Implementation: thuộc tính, phương thức là public đối với với các lớp trong gói. Lớp ParameterDirectionKind có thuộc tính: paraDirectionKind: DatatypeProperty:String. Các kiểu parameterDirectionKind (các kiểu tham số) gồm có: in, out, inout và return. Còn để ví dụ mình họa cho cách chuyển đổi từ phương thức này, chúng tôi sẽ nói rõ hơn trong phần triển khai ứng dụng ở chương 3. Vậy là ta đã vừa xây dựng được những quy tắc chuyển đổi từ các yếu tố trong UML sang OWL. Trên đây là một số các luật cơ bản để có thể chuyển đổi từ mô hình UML sang OWL. Do đó, việc chuyển đổi này hoàn toàn có thể thực hiện được bằng công cụ Protégé. Và sau đây, chương 3 sẽ giới thiệu về các quy trình để thực hiện việc kiểm tra xem kết quả áp dụng các mẫu vào mô hình thiết kế UML. 50 CHƯƠNG 3: QUY TRÌNH THỰC HIỆN KIỂM TRA KẾT QUẢ ÁP DỤNG MẪU VÀO MÔ HÌNH THIẾT KẾ UML 3.1. Giới thiệu Các mẫu thiết kế (Design Pattern) luôn thu hút được sự quan tâm cả trong kinh doanh lẫn nghiên cứu lý thuyết để đạt được mục tiêu tăng khả năng sử dụng lại các thiết kế. Các mẫu thiết kế không phải là một bản thiết kế hoàn chỉnh để có thể chuyển trực tiếp thành mã nguồn, mà nó là một bản mô tả hay một mẫu mô tả việc giải quyết vấn đề có thể sử dụng được trong nhiều trường hợp khác nhau. Các mẫu thiết kế hướng đối tượng điển hình phải chỉ ra các mối quan hệ và tương tác giữa các lớp hoặc đối tượng, mà không cần phải xác định xem các lớp và các đối tượng ứng dụng cụ thể của nó. Cấu trúc của mẫu thiết kế rất rõ ràng và có khả năng sử dụng lại rất cao. Vì vậy, việc sử dụng các mẫu thiết kế là một sự lựa chọn tốt để cải tiến hoặc tinh chế thiết kế phần mềm. Áp dụng mẫu bằng cách tích hợp cấu trúc giải pháp của mẫu vào mô hình ban đầu. Tuy nhiên, chúng ta cần đảm bảo sự tích hợp đúng. Điều đó có nghĩa là mô hình phải thỏa mãn các tính chất cấu trúc của mẫu và bảo toàn hành vi của mô hình bàn đầu. Trong chương này, chúng tôi sẽ trình bày về quy trình thực hiện kiểm tra kết quả áp dụng mẫu vào mô hình thiết kế UML. Hiện nay, có rất nhiều mẫu thiết kế, và tôi xin giới thiệu một số mẫu thiết kế được sử dụng khá thông dụng và mang lại hiệu quả cao, đó là mẫu Union Pattern và mẫu Composite Pattern. 3.2. Mẫu Union Pattern (UP) 3.2.1. Giới thiệu Mẫu Union Pattern là một mẫu có cấu trúc mô tả mối quan hệ thừa kế giữa lớp cha và lớp con của nó. Lớp cha là lớp ảo đại diện cho tập hợp các lớp con. Mục tiêu của Union Pattern hướng tới hai lợi ích của thiết kế hướng đối tượng là tập hợp mã (hoisting) và việc tách riêng các tầng trừu tượng. 1. Hoisting: Tập hợp mã (code) từ các lớp con và xây dựng lại nó trong lớp cha. 2. Tách riêng các tầng trừu tượng: việc định nghĩa một lớp cha trừu tượng miêu tả mức trừu tượng cao hơn so với các lớp con cụ thể. Lớp cha trừu tượng là một bản mô tả bản chất chung cho tất cả các lớp con cụ thể. Chính 51 vì vậy, nó mô tả những khía cạnh bất biến hay những gì là chung nhất của tất cả các phần tử tập hợp lớp con của nó. Các lớp con cụ thể khác với các lớp khác về một số hành vi. Vì vậy mà chúng mô tả các khía cạnh thay đổi của vấn đề. Tại bất kì thời điểm nào, chương trình sử dụng các lớp trong trong mẫu Union Pattern sẽ thực thi ở mức thấp hơn, hay là ở mức cụ thể hơn, hoặc ở mức mức trừu tượng thấp hơn trong mô hình có nhiều mức trừu tượng khác nhau. Các mã nguồn làm việc tại mức trừu tượng của lớp cha là mã không thay đổi. Nó có khả năng làm việc với bất kì một thể hiện của lớp cụ thể nào bởi vì nó chỉ xử lý các hành vi bất biến của lớp cha. Tất cả các hành vi thực tế của hệ thống chính là hành vi bất biến của lớp trừu tượng và thêm vào những hành vi được những thể hiện ở lớp cụ thể, được sử dụng và cung cấp một cách có tính đa hình. Union Pattern sử dụng các khái niệm cơ bản trong thiết kế hướng đối tượng như là Tính thừa kế, Tính đa hình, Tính trừu tượng, Sự đóng gói với mục đích làm mạnh hơn, khả chuyển và tính hiệu quả của hệ thống. Hiện nay, biểu đồ lớp UML của mẫu thiết kế Union Pattern thường có dạng: Hình 3.1. Mô hình của mẫu Union Pattern. 3.2.2. Các tính chất cấu trúc cần đảm bảo o Hai hoặc nhiều lớp con: Lớp con có thể là lớp ảo, trong trường hợp đó, nó sẽ biểu diễn tầng trìu tượng khác nhau. o Một lớp cha trìu tượng: biểu diễn sự trìu tượng hóa tất cả các lớp con. Một lớp cha không có thể hiện cụ thể bởi vì nó không mô tả bất cứ thực thể tồn tại riêng biệt nào. Các phương thức của lớp cha có thể là trìu tượng (các hành vi biến đổi được định nghĩa trong các lớp con) hoặc có thể là cụ thể (giữ nguyên các hành vi đó). Tóm lại, kết quả của việc ứng dụng mẫu Union Pattern là một mô hình thiết kế bao gồm một lớp cha trìu tượng và các lớp con. Lớp cha trìu tượng có cả phương thức cụ thể thực thi những hành vi bất biến của hệ thống và các phương thức trìu tượng mô tả hành vi biến đổi của hệ thống và được khai triển trong các lớp con cháu của nó. Các lớp con có các phương thức cụ thể thực thi các hành vi biến đổi của hệ thống và mô tả tính đa hình của hệ thống. 52 3.2.3. Một số trường hợp áp dụng sai mẫu Union Pattern Ta có ví dụ sau, áp dụng mẫu Union Pattern với biểu đồ lớp sau: Hình 3.2. Ví dụ về mô hình áp dụng mẫu Union Pattern. Ví dụ về áp dụng mẫu sai trong trường hợp này là: o Lớp cha không phải là lớp trừu tượng Hình 3.3. Trường hợp áp dụng sai mẫu UP. o Phương thức makeSound() ở lớp cha không phải là phương thức trừu tượng Hình 3.4. Trường hợp áp dụng sai mẫu UP. 53 o Quan hệ kết tập với lớp Mammal mà không phải quan hệ thừa kế. Hình 3.5. Trường hợp áp dụng sai mẫu UP. 3.3. Mẫu thiết kế Composite Mẫu thiết kế Composite là loại mẫu cấu trúc, cung cấp giải pháp để tổ chức các đối tượng theo cấu trúc cây, thể hiện phân cấp toàn thể- bộ phận. Với cấu trúc này, người dùng thao tác với các đối tượng không cần quan tâm xem mình đang thao tác với đối tượng toàn thể hay đối tượng bộ phận, cách thức thao tác là như nhau với tất cả các đối tượng trong cây phân cấp. Cấu trúc giải pháp của mẫu Composite có dạng như sau: Hình 3.6. Cấu trúc mẫu Composite Cấu trúc giải pháp của mẫu Composite gồm 3 thành phần là Component, Composite và Leaf. Mỗi thành phần này có những đặc tính về mặt cấu trúc như sau: o Component: Lớp có ít nhất hai quan hệ kết tập, và một trong số đó là lớp con. o Composite: Lớp mà vừa là lớp con trong quan hệ tổng quát hoá- chuyên biệt hoá vừa là lớp bộ phận trong quan hệ toàn thể - bộ phận với lớp >. 54 o Leaf: Lớp bộ phận trong mối quan hệ toàn thể - bộ phận với > Dưới đây là một số ví dụ về kết quả áp dụng mẫu Composite. Hình 3.7 là kết quả của việc áp dụng đúng, các lớp trong mô hình thoả mãn tất cả các đặc tính về mặt cấu trúc của các lớp tương ứng trong cấu trúc giải pháp của mẫu. Hình 3.7. Trường hợp áp dụng mẫu Composite đúng. Hình 3.8 là kết qủa của việc áp dụng sai vì chúng ta thấy các lớp Line, Text, Rectangle (đóng vai trò lớp Leaf trong cấu trúc giải pháp của mẫu) không thoả mãn các đặc trưng của lớp Leaf. Hình 3.8. Mô hình ban đầu. 55 Hình 3.9 cũng là một ví dụ về áp dụng mẫu sai vì lớp Line, Text, Rectangle, Image không thoả mãn các đặc trưng của lớp Leaf và Composite tương ứng. Hình 3.9. Trường hợp áp dụng sai mẫu Composite 3.4. Bài toán Bài toán được đặt ra là kiểm tra sự tương đương của hai mô hình ban đầu và mô hính sau khi áp dụng mẫu thiết kế. Do đó:  Đầu vào của bài toán: 1. Mô hình ban đầu gồm có: o Một biểu đồ UML (biểu đồ lớp, biểu đồ trạng thái .v.v.). o Các ràng buộc được đặc tả bằng text hoặc bằng OCL, v.v. 2. Mô hình thiết kế mới o Các biểu đồ chi tiết hơn o Có cấu trúc tốt hơn 3. Các tính chất cấu trúc của mẫu đã áp dụng Trong bài khóa luận này, tôi sẽ sử dụng mẫu Union Pattern. Vì vậy, cấu trúc mô hình cũng phải tuân theo tính chất cấu trúc của mẫu Union Pattern.  Đầu ra của bài toán Kết quả kiểm tra. 56 Quy trình kiểm tra sẽ được thực hiện thông qua các bước sau đây: 3.4.1. Các bước thực hiện Trong thiết kế phần mềm, chúng ta cần thực thi một vài bước từ thiết kế ban đầu và trải qua vài tinh chế. Chúng ta kiểm tra tính tương đương của thiết kế qua mỗi bước và thiết kế ở bước tiếp theo để đạt được một sản phẩm phần mềm đúng như thiết kế ban đầu. Đầu vào sẽ là hai mô hình bao một mô hình thiết kế ban đầu và mô hình đã tinh chế sau khi áp dụng mẫu thiết kế vào mô hình ban đầu. Quy trình kiểm tra: o Bước 1: Chuyển đổi thành siêu mô hình (meta-model) từ các biểu đồ UML. Siêu mô hình UML được định nghĩa hoàn toàn là việc mô tả ngữ nghĩa của các đối tượng trong các mô hình UML. Nó được định nghĩa theo kiểu đường vòng, sử dụng tập hợp các kí hiệu UML và ngữ nghĩa để đặc tả chính nó. Một mô hình là một thể hiện của siêu mô hình UML, mỗi một thành phần của mô hình UML là một thể hiện của một lớp trong siêu mô hình. Ví dụ như tất cả các phương thức trong mô hình UML là các thể hiện của lớp Operation trong siêu mô hình UML. Kết quả của bước này là hai siêu mô hình tương ứng với thiết kế ban đầu và thiết kế sau khi tinh chế. o Bước 2: Chuyển đổi từ siêu mô hình sang OWL Ontology. Áp dụng các quy tắc chuyển đổi đã đề cập trong chương 2, ta sẽ chuyển đổi các yếu tố trong siêu mô hình sang các đặc OWL. Vì vậy, ta sẽ từ hai siêu mô hình ta sẽ thu được hai bản đặc tả OWL. Tại bước 3, ta sẽ sử dụng các công cụ để kiểm tra tính tương đương của hai mô hình đã cho. o Bước 3: Kiểm tra các thành phần của mô hình trong bản đặc tả OWL bằng công cụ kiểm chứng tự động. Để kiểm tra xem hai mô hình OWL tương ứng với hai siêu mô hình, vì vậy mà tương ứng với thiết kế ban đầu và thiết kế sau tinh chế, chúng ta kiểm tra mô hình OWL 2 có phải là bản tinh chế của mô hình OWL 1 hay không bằng công cụ tự động. Đầu ra: cho ra kết quả kiểm tra Như vậy, các bước thực hiện việc kiểm tra hai mô hình được mô tả bằng sơ đồ sau: 57 Hình 3.10. Các bước trong quy trình kiểm tra. Chương 3 đã trình bày một số mẫu thiết kế và quy trình thực hiện việc kiểm tra kết quả áp dụng mẫu vào mô hình thiết kế UML. Chúng ta sẽ xét một ví dụ cụ thể áp dụng quy trình kiểm tra này ở chương 4. 58 CHƯƠNG 4: KIỂM TRA KẾT QUẢ TÍCH HỢP MẪU UNION PATTERN VÀO MÔ HÌNH THIẾT KẾ HÀNH VI CÁC CON VẬT 4.1. Mô tả bài toán cụ thể Giả sử chúng ta muốn xác định hành vi của các con vật như Cat (Mèo), Monkey (Khỉ) và Whale (Cá voi), tương ứng với ba lớp Cat, Monkey, và Whale, như trong mô hình đầu tiên. Các con vật có rất nhiều hành vi, tuy nhiên chúng ta sẽ giới hạn chúng chỉ còn ba hành vi, được mô tả trong form (mẫu) các chức năng dưới đây: o boolean givesMilk(): trả lại true nếu con vật có thể cho sữa và false nếu ngược lại. o String makeSound(): trả lại xâu mô tả âm thanh phổ biến mà con vật tạo ra. o boolean givesLiveBirth(): trả lại true nếu con vật còn non ngày tuổi. Ta có biểu đồ lớp ban đầu thể hiện hành vi của các con vật như sau: Hình 4.1. Các lớp UML ban đầu. Chúng ta có thể bắt đầu với việc thiết kế các lớp như mô hình ban đầu. Tuy nhiên, chúng ta sẽ thực thi cùng đoạn mã giống nhau với phương thức givesMilk và givesLiveBirth trong ba lớp. Sau đó, nếu ta muốn thêm một lớp mới, đoạn mã sẽ được sao đi sao lại nhiều lần nữa. Để tránh gặp phải vấn đề này, chúng ta có thể sử dụng giải pháp là Union Pattern. Chúng ta có thể chuyển tất cả đoạn mã chung lên một lớp cha và các lớp khác sẽ tự động thừa kế những hành vi đó. Dựa trên cấu trúc của Union Pattern, bản tinh chế thiết kế, là kết quả của việc kết hợp biểu đồ lớp đầu tiên với mẫu thiết kế Union Pattern. Trong bản tinh chế, có thêm một lớp cha mới, với tên là Mammal. Hai phương thức givesMilk() và givesLiveBirth() trả lại một cách chính xác giá trị giống nhau đối với tất cả các động vật ở đây. Vì vậy, chúng được đưa vào lớp cha 59 Mammal. Phương thức makeSound() trả lại giá trị khác nhau đối với từng loài động vật, nhưng chúng ta trông đợi bất kì con vật nào bao gồm các loài động vật, có thể phát ra được âm thanh. Vì vậy, lớp Mammal có phương thức makeSound(), nhưng chúng ta không biết chính xác là âm thanh như thế nào, nên phương thức này trong lớp Mammal là phương thức trừu tượng. Các phương thức makeSound() trong các lớp cụ thể Cat, Monkey và Whale sẽ là phương thức cụ thể, bởi vì mỗi loài động vật lại tạo ra một âm thanh riêng. Biểu đồ lớp sau khi áp dụng mẫu Union Pattern được biểu diễn như sau: Hình 4.2. Biểu đồ lớp sau khi tinh chế áp dụng mẫu Union Pattern. Bây giờ chúng ta phải kiểm tra xem bản tinh chế có đảm bảo nó đã thỏa mãn cấu trúc của Union Pattern và tương đương về các hành vi so với hanh vi của biểu đồ lớp ban đầu hay chưa: o Lớp Cat, Monkey và lớp Whale là tất cả các lớp cụ thể. Chúng có các phương thức giống nhau là givesMilk, makeSoun, và givesLiveBirth. Nhưng chúng thực thi chỉ hai phương thức givesMilk và givesLiveBirth là giống nhau. o Mỗi lớp trong biểu đồ thực thi phương thức makeSound theo một cách khác nhau. Thứ hai là chúng ta mô tả các luật tinh chế để đảm bảo rằng nó thỏa mãn cấu trúc của Union Pattern: o Tồn tại một lớp cha trừu tượng trong bản tinh chế. o Tất cả các lớp cụ thể trong biểu đồ lớp ban đầu là các lớp con của lớp cha trừu tượng. o Lớp cha trừu tượng có các phương thức givesMilk, makeSound, givesLiveBirth trong đó lớp givesMilk và givesLiveBirth là phương thức cụ thể, còn makeSound là phương thức trừu tượng. o Tất cả các lớp cụ thể có một phương thức trừu tượng tên là makeSound thực thi phương thức trừu tượng trong lớp cha. 60 Bây giờ, chúng ta phải kiểm tra xem bản tinh chế xem nó có thỏa mãn tất cả các luật ở trên không. Chúng tôi sẽ thực hiện ba bước trong quy trình kiểm tra trong phần 4.2 sau đây. 4.2. Các bước thực hiện 4.2.1. Bước 1: Biển đổi hai biểu đồ lớp UML sang siêu mô hình Hai biểu đồ lớp có các yếu tố: Lớp, Phương thức, Tham số, Thuộc tính, các quan hệ, ràng buộc, v.v... Vì vậy, khi biến đổi thành siêu mô hình thì mỗi yếu tố đó sẽ tạo ra các lớp, có quan hệ với nhau. Đối với hai biểu đồ lớp đã cho, do chỉ có Lớp, Phương thức và Tham số nên ta sẽ tạo ra được một siêu mô hình như hình vẽ sau đây: Class +name: String +isAbstract: Boolean Operation +name: String +isAbstract: Boolean +visibility: VisibilityKind +Commonality: Boolean Parameter +name: String +direction: ParameterDirectionKind +class +ownedOperation 0..1 * +operation +ownedParameter 0..1 * +superClass +subClass * * Hình 4.3. Siêu mô hình của các biểu đồ lớp. 4.2.2. Bước 2: Chuyển đổi từ siêu mô hình UML sang OWL Ontology Khi chuyển đổi từ mô hình UML sang OWL Ontology, ta sẽ áp dụng các quy tắc chuyển đổi đã trình bày ở chương 2 và sử dụng công cụ hỗ trợ Protégé. Trước hết, ta sẽ chuyển siêu mô hình sang OWL Ontology bằng công cụ Protégé như sau: o Tất cả các lớp khi chuyển sang lớp OWL giữ nguyên tên lớp: Class, Operator, Parameter. 61 Hình 4.4. Các lớp sau khi chuyển đổi từ siêu mô hình bằng công cụ Protégé. Ngoài ra, nhận thấy hai thuộc tính visibility của Operation có kiểu đối tượng là VisibilityKind, và thuộc tính direction có kiểu đối tượng là ParameterDirectionKind nên trong OWL Ontology chúng ta sẽ thêm 1 lớp Types với hai lớp con là Parameter_Direction_Kind, và lớp Visibility_Kind. Tiếp theo là các thuộc tính của từng lớp: o Với lớp Class: Hình 4.5. Các thuộc tính của lớp Class. 62 Ngoài các thuộc tính class_name và isAbstract ra, lớp Class còn có hai mối liên kết là subClass và ownedOperation nên hai liên kết này được chuyển thành hai thuộc tính đối tượng. Do ràng buộc số lượng ở hai liên kết này là [*] nên hai thuộc tính đó có thể có nhiều giá trị. o Thuộc tính với lớp Operation: Ngoài các thuộc tính: op_name, op_isAbstract, visibility và commonality ra, lớp Operation có quan hệ kết tập với lớp Class và lớp Parameter nên theo luật chuyển đổi ta có thêm hai thuộc tính đối tượng là class và ownedParameter. Đồng thời, ràng buộc về số lượng ở vai trò liên kết class là [0..1] nên minCardinality:0 và maxCardinality:1. Thuộc tính class là thuộc tính đảo ngược với thuộc tính ownedOperation của lớp Class. Hình 4.6. Thuộc tính của lớp Operation. o Thuộc tính của lớp Parameter: Lớp Parameter: Ngoài các thuộc tính direction, para_name, lớp Parameter còn có quan hệ kết tập với lớp Operation nên theo luật chuyển đổi, ta có thêm 63 thuộc tính đối tượng là operation. Vì ràng buộc trong vai trò liên kết của operation là [0..1] nên ta có minCardinality: 0 và minCardinality: 1. Đồng thời, thuộc tính operation còn là thuộc tính kiểu đảo ngược với thuộc tính ownedParameter. Hình 4.7. Thuộc tính của lớp Parameter. 64 o Đối với lớp Parameter_Direction_Kind: Lớp này có thuộc tính là parameter_direction_kind. Hình 4.8. Thuộc tính lớp Parameter_Direction_Kind. o Đối với lớp Visibility_Kind: Thuộc tính của lớp là visibility_kind. Hình 4.9. Thuộc tính của lớp Visibility. 65 Toàn bộ các thuộc tính của mô hình: Hình 4.10. Toàn bộ thuộc tính của các lớp. Khi đó, để chuyển đổi hai mô hình đầu vào thành OWL Ontology, ta chỉ cần thêm các thể hiện cho siêu mô hình. 66 Với mô hình ban đầu, ta có thể hiện của nó như sau: o Với lớp Class: đó là Cat, Monkey, và Whale Hình 4.11. Các thể hiện của lớp Class. Đối với lớp Monkey và Whale ta cũng thực hiện tương tự như trên hình. 67 o Các thể hiện của lớp Operation: Hình 4.12. Các thể hiện của lớp Operation. Các phương thức khác cũng thực hiện tương tự. 68 o Các thể hiện của lớp Parameter: Do trong lớp Parameter các tham số không có tên mà chỉ có kiểu trả về nên ta có: Hình 4.13. Các Thể hiện của lớp Parameter. 69 Hình 4.14. Các thể hiện của lớp Parameter. Các tham số còn lại cũng thực hiện tương tự. o Các thể hiện của lớp Parameter_Direction_Kind : Hình 4.15. Các thể hiện của lớp Parameter_Direction_Kind 70 o Các thể hiện của lớp Visibility_Kind: Hình 4.16. Các thể hiện của lớp Visibility_Kind. Đối với mô hình sau khi áp dụng mẫu: Tiếp theo là biểu diễn mô hình sau khi áp dụng mẫu thiết kế thông qua siêu mô hình. Mô hình thứ hai cũng là một thể hiện của siêu mô hình vừa xây dựng, do đó ta có: o Các thể hiện của lớp Class như sau: Hình 4.17. Các thể hiện của lớp Class. 71 Hình 4.18. Các thể hiện của lớp Class: lớp Mammal. Các thể hiện Cat, monkey, whale là tương tự nhau. o Thể hiện của lớp Operation: Hình 4.19. Các thể hiện của lớp Operation. 72 Hình 4.20. Thể hiện của lớp Operation: phương thức makeSound của lớp Mammal. Hình 4.21. Thể hiện của lớp Operation: phương thức makeSound trong lớp Cat. Các thể hiện phương thức givesMilk và givesLiveBirth là tương tự nhau. Và các thể hiện makeSound_Cat, makeSound_Monkey, và makeSound_whale cũng tương tự nhau. 73 o Thể hiện của lớp: Parameter Hình 4.22. Thể hiện của lớp Parameter. Các thể hiện của lớp Parameter_Direction_Kind và lớp Visibility cũng tương tự như mô hình thứ nhất. Trên đây là cách xây dựng và thể hiện một Ontology chuyển đổi từ mô hình UML. File mã nguồn đầy đủ của chương trình chuyển đổi sẽ được trình bày trong phần phụ lục của bài khóa luận này. 4.2.3. Các luật ràng buộc : Giả sử mô hình của biểu đồ lớp ban đầu là CD1, và mô hình sau sau khi tinh chế là CD2. Hai mô hình được coi là tương đương nhau nếu chúng thỏa mãn các luật ràng buộc sau: o Mọi lớp trong CD1 đều là lớp cụ thể. Ví dụ như các lớp cụ thể Cat, Monkey, Whale trong biểu đồ lớp ban đầu. o Tồn tại một lớp mới c0 thuộc CD2 sao cho c0 là lớp trừu tượng. Mọi lớp ci còn lại trong CD2 đều là lớp cụ thể và c0 là lớp tổng quát (lớp cha) của các lớp ci, đồng thời tất cả các lớp ci đó đều trùng với các lớp c trong CD1 (trong CD1 có lớp c nào thì trong CD2 có lớp ci tương ứng). 74 o Tồn tại các phương thức o1, o2 trong CD1 với các đặc điểm sau:  Trùng tên  Cùng kiểu  Cùng danh sách tham số  Cùng kiểu trả về  Được triển khai như nhau  Thuộc các lớp khác nhau Điều đó có nghĩa là trong CD1 cần phải có các phương thức giống nhau trong các lớp khác nhau của mô hình. o Tồn tại các phương thức o3, o4 trong CD1 với các đặc điểm sau:  Trùng tên  Cùng kiểu (cụ thể)  Cùng danh sách tham số  Cùng kiểu trả về  Được triển khai khác nhau  Thuộc các lớp khác nhau Điều này có nghĩa rằng trong mô hình ban đầu phải tồn tại các phương thức giống nhau nhưng triển khai của nó lại khác nhau. Ví dụ như phương thức makeSound() trong các lớp Cat, Monkey và Whale. o Tồn tại phương thức o5 thuộc CD2 sao cho:  o5 thuộc lớp c0  o5 có mọi đặc điểm giống với o1,o2 Điều này có nghĩa là trong mô hình sau tinh chế, lớp cha trìu tượng có tồn tại phương thức cụ thể, giống với những phương thức giống nhau cả trong cách triển khai ở trong mô hình ban đầu, ví dụ như phương thức givesMilk(), givesLiveBirth(). o Tồn tại phương thức o6 thuộc CD2 sao cho:  o6 thuộc lớp c0  o6 là phương thức trừu tượng, có tên và các đặc điểm khác giống với o3 nhưng triển khai thì khác. Điều này có nghĩa rằng trong CD2 tồn tại một phương thức thuộc lớp cha trìu tượng, là phương thức trìu tượng và giống với các phương thức cụ thể giống nhau trong CD1 song có cách khai triển khác nhau. Ví dụ như phương thức makeSound(). o Tồn tại phương thức o7 thuộc CD2 sao cho: 75  o7 thuộc ci  o7 có cùng tên và các thuộc tính khác giống o6 ngoại trừ nội dung triển khai và o7 là phương thức cụ thể  o7 triển khai giống o3 Mô hình sau tinh chế CD2 có phương thức thuộc các lớp con cụ thể, có cùng tên và các thuộc tính giống với phương thức ảo ở lớp cha của nó, nó được triển khai giống với các phương thức cụ thể giống nhau trong CD1 song có các khai triển khác nhau. Ví dụ như phương thức makeSound() trong ba lớp Cat, Monkey, Whale trong CD2. 4.2.4. Bước 3: Kiểm tra bằng công cụ Công cụ kiểm tra sẽ được phát triển bởi khóa luận của sinh viên Vũ Văn Thế. 4.3. Kết quả kiểm tra và đánh giá. Các luật trên có thể được viết bằng công cụ Prolog, và công cụ hỗ trợ sẽ sử dụng các luật đó để kiểm tra tính tương đương của các mô hình đầu vào. Các luật chuyển đổi này được viết bằng ngôn ngữ lập trình Prolog và kết quả kiểm tra bằng công cụ tự động ra sao sẽ được thực hiện trong khóa luận của sinh viên Vũ Văn Thế. 76 CHƯƠNG 5: TỔNG KẾT 5.1. Kết quả đạt được: Sau khi tìm hiểu và nghiên cứu về Ontology, OWL và các luật chuyển đổi mô hình UML sang OWL. Luận văn đã đạt được hai mục tiêu chính như sau: o Về mặt lý thuyết: Đạt được mục tiêu là tìm hiểu và xây dựng phương pháp để thực hiện kiểm tra sự tương đương của các mô hình UML bằng việc chuyển sang ngôn ngữ OWL Ontology và từ đó thực hiện việc kiểm tra với file OWL thu được cùng các luật ràng buộc. Qua quá trình nghiên cứu, chúng tôi đã được nghiên cứu rất nhiều tài liệu hay và bổ ích đối xung quanh vấn đề này. Đồng thời, việc tìm hiểu các quy tắc chuyển đổi giúp cho việc xây dựng một Ontology đầy đủ và chính xác hơn. o Về mặt ứng dụng minh họa: Với mục tiêu là làm rõ quy trình kiểm tra sự tương đương của hai mô hình UML và đưa ra được kết quả kiểm tra. Bài khóa luận của tôi đã thực hiện được hai bước đầu tiên trong ba bước của quy trình này. Với bước kiểm tra bằng công cụ tự động, bài khóa luận của sinh viên Vũ Văn Thế sẽ xây dựng một công cụ tự động để thực hiện việc kiểm tra đó. 5.2. Kết luận Trong quá trình thực hiện Khóa luận này, chúng tôi đã tìm hiểu các ngôn ngữ UML, OCL, OWL và Prolog. Chúng tôi cũng đã tìm hiểu cách thức để chuyển đổi từ một đặc tả UML sang đặc tả OWL và các công cụ hỗ trợ phát triển đặc tả OWL. Chúng tôi đã thực hiện một ứng dụng thử nghiệm để đánh giá được hiệu quả của việc chuyển đổi này. Qua quá trình thực hiện Khóa luận, chúng tôi đã có kiến thức về một số ngôn ngữ đặc tả, biết cách xây dựng các ontology bằng ngôn ngữ OWL và biết cách viết đặc tả bằng Prolog Đặc biệt, chúng tôi đã nắm được cách thức để chuyển đổi từ mô hình UML sang đặc tả OWL và một hướng để kiểm tra kết quả áp dụng mẫu thiết kế trong phát triển hướng đối tượng. Trong thời gian tới, chúng tôi sẽ tiến hành thử nghiệm trên một số loại bài toán khác để đánh giá được hiệu quả của việc chuyển đổi từ đặc tả UML sang OWL. 77 PHỤ LỤC 1 Sau đây là mã nguồn OWL đầy đủ của mô hình ban đầu thể hiện hành vi của các con vật (Hình 4.1): <rdf:RDF xmlns:rdf="" xmlns:protege="" xmlns="" xmlns:xsp="" xmlns:owl="" xmlns:xsd="" xmlns:swrl="" xmlns:swrlb="" xmlns:rdfs="" xml:base=""> <owl:minCardinality rdf:datatype="" >0 78 <owl:maxCardinality rdf:datatype="" >1 <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" > <owl:minCardinality rdf:datatype="" >0 <owl:maxCardinality rdf:datatype="" >1 79 <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" >ParameterDirectionKind is an enumeration of the following literal values: • in — Indicates that parameter values are passed into the behavioral element by the caller. • inout — Indicates that parameter values are passed into a behavioral element by the caller and then back out to the caller from the behavioral element. • out — Indicates that parameter values are passed from a behavioral element out to the caller. • return — Indicates that parameter values are passed as return values from a behavioral element back to the caller. 80 <rdfs:comment rdf:datatype="" >các lớp con của lớp đang xét <rdfs:comment rdf:datatype="" >Chuỗi tham sô, phương thức có những tham số nào? <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" 81 >hướng của tham số (có các dạng in, out, inout, return) <rdfs:comment rdf:datatype="" >tên của phương thức <rdfs:comment rdf:datatype="" >Lớp có phải lớp ảo không? <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" >phương thức là public, protected, private? <rdfs:comment rdf:datatype="" 82 >Ví dụ như: private, public, protected .v.v. <rdfs:comment rdf:datatype="" >khai triển của phương thức (có giống nhau không?) <rdfs:comment rdf:datatype="" >gồm in, out, inout hoặc return <rdfs:comment rdf:datatype="" >tên tham số <rdfs:comment rdf:datatype="" >có phải là phương thức ảo hay không? 83 protected private <rdfs:comment rdf:datatype="" > in <rdfs:comment rdf:datatype="" >trong các phương thức trong biểu đồ không có tham số những vẫn có giá trị trả về, vì vậy mà para_name để trống <parameter_direction_kind xml:lang="en">inout <rdfs:comment rdf:datatype="" > out 84 <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" > Whale <op_name rdf:datatype="" >giveLiveBirth public <parameter_direction_kind xml:lang="en">return <op_isAbstract rdf:datatype="" >false 85 <commonality rdf:datatype="" >true <op_isAbstract rdf:datatype="" >false <commonality rdf:datatype="" >true <op_name rdf:datatype="" >givesMilk <op_isAbstract rdf:datatype="" >false <op_name rdf:datatype="" 86 >makeSound <commonality rdf:datatype="" >false <isAbstract rdf:datatype="" >false Monkey <rdfs:comment rdf:datatype="" > <isAbstract rdf:datatype="" >false <commonality rdf:datatype="" 87 >true <op_name rdf:datatype="" >givesLiveBirth <op_isAbstract rdf:datatype="" >false <op_isAbstract rdf:datatype="" >false <op_name rdf:datatype="" >givesMilk <commonality rdf:datatype="" >true 88 <op_name rdf:datatype="" >makeSound <op_isAbstract rdf:datatype="" >false <commonality rdf:datatype="" >false Cat <isAbstract rdf:datatype="" >false <rdfs:comment rdf:datatype="" >có 3 lớp Cat, Monkey, Whale, không phải là lớp ảo <commonality rdf:datatype="" >true <op_isAbstract rdf:datatype="" >false <rdfs:comment rdf:datatype="" >có giá trị trả về là true hoặc false givesLiveBirth 89 <commonality rdf:datatype="" >true <rdfs:comment rdf:datatype="" >có giá trị trả về là true hoặc false givesMilk <op_isAbstract rdf:datatype="" >false 90 makeSound <rdfs:comment rdf:datatype="" > <op_isAbstract rdf:datatype="" >false <commonality rdf:datatype="" >false <!-- Created with Protege (with OWL Plugin 3.4.4, Build 579) --> 91 PHỤ LỤC 2 Dưới đây là mã nguồn OWL của mô hình sau khi áp dụng mẫu thiết kế Union Pattern vào mô hình band đầu (hình 4.2): <rdf:RDF xmlns:rdf="" xmlns:protege="" xmlns="" xmlns:xsp="" xmlns:owl="" xmlns:xsd="" xmlns:swrl="" xmlns:swrlb="" xmlns:rdfs="" xml:base=""> <owl:maxCardinality rdf:datatype="" >1 92 <owl:minCardinality rdf:datatype="" >0 <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" > <owl:maxCardinality rdf:datatype="" >1 <owl:minCardinality rdf:datatype="" >0 93 <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" >ParameterDirectionKind is an enumeration of the following literal values: • in — Indicates that parameter values are passed into the behavioral element by the caller. • inout — Indicates that parameter values are passed into a behavioral element by the caller and then back out to the caller from the behavioral element. • out — Indicates that parameter values are passed from a behavioral element out to the caller. • return — Indicates that parameter values are passed as return values from a behavioral element back to the caller. <rdfs:comment rdf:datatype="" >Phương thức là public, protected, private .v.v. <rdf:type rdf:resource=""/> 94 <rdfs:comment rdf:datatype="" >các lớp con của lớp đang xét <rdfs:comment rdf:datatype="" >Chuỗi tham sô, phương thức có những tham số nào? <rdfs:comment rdf:datatype="" > 95 <rdfs:comment rdf:datatype="" >hướng của tham số (có các dạng in, out, inout, return) <rdfs:comment rdf:datatype="" >tên của phương thức <rdf:type rdf:resource=""/> <rdfs:comment rdf:datatype="" >Lớp có phải là lớp ảo hay không? <rdf:type rdf:resource=""/> <rdfs:comment rdf:datatype="" > <rdf:type rdf:resource=""/> 96 <rdfs:comment rdf:datatype="" >Ví dụ như: private, public, protected. v.v <rdf:type rdf:resource=""/> <rdfs:comment rdf:datatype="" >tính triển khai của phương thức (có giống nhau không?) <rdf:type rdf:resource=""/> <rdf:type rdf:resource=""/> <rdfs:comment rdf:datatype="" >gồm in, out, inout hoặc return <rdfs:comment rdf:datatype="" >tên tham số <rdf:type rdf:resource=""/> <rdfs:comment rdf:datatype="" >có phải là phương thức ảo hay không? 97 <rdf:type rdf:resource=""/> protected private <rdfs:comment rdf:datatype="" > in <rdfs:comment rdf:datatype="" >trong các phương thức trong biểu đồ không có tham số những vẫn có giá trị trả về, vì vậy mà para_name để trống <parameter_direction_kind xml:lang="en">inout <rdfs:comment rdf:datatype="" > 98 out <rdfs:comment rdf:datatype="" > <rdfs:comment rdf:datatype="" > Whale public <op_isAbstract rdf:datatype="" >false <op_name rdf:datatype="" >makeSound <parameter_direction_kind xml:lang="en">return 99 <commonality rdf:datatype="" >false <isAbstract rdf:datatype="" >false Monkey <rdfs:comment rdf:datatype="" > <isAbstract rdf:datatype="" >false <op_name rdf:datatype="" >makeSound <op_isAbstract rdf:datatype="" >false 100 <commonality rdf:datatype="" >false Cat <isAbstract rdf:datatype="" >false <rdfs:comment rdf:datatype="" >có 3 lớp Cat, Monkey, Whale, không phải là lớp ảo makeSound <rdfs:comment rdf:datatype="" > <op_isAbstract rdf:datatype="" >false <commonality rdf:datatype="" >false 101 <op_name rdf:datatype="" >givesLiveBirth <commonality rdf:datatype="" >true <op_isAbstract rdf:datatype="" >false <rdfs:comment rdf:datatype="" > <op_isAbstract rdf:datatype="" >false givesMilk 102 <commonality rdf:datatype="" >true <isAbstract rdf:datatype="" >true <rdfs:comment rdf:datatype="" >lớp cha trừu tượng <op_name rdf:datatype="" >makeSound <commonality rdf:datatype="" >false <op_isAbstract rdf:datatype="" >true 103 <class_name rdf:datatype="" >Mammal <!-- Created with Protege (with OWL Plugin 3.4.4, Build 579) --> 104 Tài liệu tham khảo Tiếng Việt: [1] Tôn Thất Hòa An, TS.Dương Kiều Hoa, Phân tích và thiết kế hệ thống thông tin với UML [2] Các dịch vụ Web và Web ngữ nghĩa (semantic Web), phần 4: Tạo một bản thể luận, [3] Trần Thị Ngân, Phương thức xây dựng Ontology, lieu/phuong-thuc-xay-dung-ontology.158466.html [4] Võ Hoàng Nguyên, Hoàng Lê Quân (2009), đồ án Giới thiệu Sermantic Web và Ontology [5] Ontology, [6] Ontology và OWL, [7] TS.Trương Ninh Thuận, Bài giảng Phân tích thiết kế hướng đối tượng. Tiếng Anh: [8] Dipl.-Wirt.-Inf. Sebastian Leinhos, Transformation for “OWL from UML”, [9] Ontology, [10] OWL Web Ontology Language Overview, lieu/phuong-thuc-xay-dung-ontology.158466.html [11] Vu Dieu Huong, Truong Ninh Thuan, Ensuring consistent levels of abstraction using B renement.