Luận văn Kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế

quả của việc không xác định đầy đủ các phương thức cụ thể ....................... 16 Hinh 9: Kết quả của việc không xác định đầy đủ các phương thức ................................... 17 Hinh 10: Quan hệ kết hợp ................................................................................................... 20 Hinh 11: Quan hệ khai quát hóa ........................................................................................ 20 Hinh 12: Quan hệ cộng hợp ............................................................................................... 20 Hinh 13: Quan hệ hợp thành .............................................................................................. 21 Hinh 14: Quan hệ thực thi .................................................................................................. 21 Hinh 15: Quan hệ phụ thuộc .............................................................................................. 21 Hinh 16: Biểu đồ UseCase tổng thể ................................................................................... 25 Hinh 17: Biểu đồ lớp phân tích .......................................................................................... 27 Hinh 18: BIểu đồ tuần tự ca sử dụng “Import OWL Ontology” ........................................ 28 Hinh 19: Biểu đồ tuần tự ca sử dụng “Compare two OWL Ontology” ............................. 28 Hinh 20: Biểu đồ lớp chi tiết .............................................................................................. 29 Hinh 21: Thiết kế chức năng “Import OWL Ontology” ..................................................... 30 Hinh 22: Thiết kế chức năng “Compare two OWL Ontology” .......................................... 30 Hinh 23: Giao diện chính của chương trình khi bắt đầu chạy ........................................... 31 Hinh 24: Giao diện của chương trình với kết quả của quá trình kiểm tra ......................... 32 DANH SÁCH CÁC TỪ VIẾT TẮT STT Từ viết tắt Diễn giải 1 UML Unified Modeling Language 2 OWL Web Ontology Language 3 Prolog Programing in Logic 1 MỞ ĐẦU OWL (Web Ontology Language) là ngôn ngữ để phát triển Ontology. Các Ontology được thể hiện bằng ngôn ngữ OWL có ưu điểm là dễ mở rộng, có thể chia sẻ qua Internet, hỗ trợ khả năng suy luận bằng cách thực hiện truy vấn các thông tin trong Ontology. Một số công cụ hỗ trợ so sánh các Ontology đã được phát triển như là Protégé, OWLDiff. Các công cụ này thực hiện các chức năng như so sánh sự giống và khác nhau của hai OWL ontology, hòa trộn hai OWL Ontology. Trong công nghệ phần mềm, mẫu thiết kế được sử dụng để cải tiến thiết kế do giải pháp mẫu cung cấp mang đến một kiến trúc hệ thống tốt hơn nếu chúng ta thực hiện đúng đắn việc tích hợp giải pháp mẫu vào mô hình thiết kế ban đầu. Trong thực tế thì có nhiều trường hợp thực hiện sai việc tích hợp này. Do đó một vấn đề đặt ra là cần kiểm tra mô hình thu được sau khi áp dụng mẫu có thoả mãn các tính chất cấu trúc của giải pháp mẫu hay không. Cụ thể, khi chúng ta có một mô hình thiết kế ban đầu, một mẫu thiết kế được sử dụng để cái tiến mô hình thiết kế này và một mô hình thiết kế mới, làm thế nào để kiểm tra xem mô hình thiết kế mới có thoả mãn các tính chất cấu trúc của mẫu thiết kế hay không, hay việc áp dụng mẫu ở đây có đúng đắn hay không. Trong khoá luận của sinh viên Giáp Thị Ngọc Thuý đã đề xuất quy trình chuyển đặc tả UML sang đặc tả OWL. Khoá luận này tập trung để tìm hiểu khả năng của các công cụ sẵn có hỗ trợ so sánh các đặc tả OWL và tiến hành xây dựng thử nghiệm công cụ hỗ trợ kiểm tra sự tinh chế thiết kế hai mô hình có áp dụng mẫu thiết kế trong tiến trình phát triển hướng đối tượng. Khoá luận sẽ giới thiệu về mẫu thiết kế, minh hoạ một số trường hợp áp dụng sai cấu trúc giải pháp của mẫu thiết kế và trình bày các kết quả phân tích, thiết kế, cài đặt thử nghiệm công cụ thực hiện kiểm tra tự động kết quả tích hợp mẫu. Kết cấu của Khoá luận này bao gồm x chương. Chương 1 giới thiệu về Mẫu thiết kế, Chương 2 trình bày OWL Ontology và Prolog, Chương 3 trình bày về Kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế, Chương 4 trình bày về việc xây dựng công cụ kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế, và cuối cùng là Chương 5 sẽ tổng hợp kết quả làm được và hướng phát triển của bài Khóa luận. 2 CHƯƠNG 1: GIỚI THIỆU VỀ MẪU THIẾT KẾ Trong công nghệ phần mềm, một mẫu thiết kế là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm. Một mẫu thiết kế không phải là một thiết kế hoàn thiện để có thể chuyển đổi trực tiếp thành mã, nó chỉ là một mô tả hay là sườn (template) mô tả cách giải quyết một vấn đề có thể được dùng trong nhiều tình huống khác nhau. Các mẫu thiết kế hướng đối tượng thường cho thấy mối quan hệ và sự tương tác giữa các lớp hay các đối tượng, mà không cần chỉ rõ các lớp hay đối tượng của từng ứng dụng cụ thể. (Wikipedia) Có hàng nghìn những mẫu thiết kế cung cấp những giải pháp cho rất nhiều những vấn đề khác nhau trong việc thiết kế những hành vi như giao diện người máy, cấu trúc của hệ thống, hành vi của hệ thống. Những mẫu thiết kế được biểu diễn bởi những ngôn ngữ và ký hiệu khác nhau chẳng hạn như văn bản, UML và những ngôn ngữ mô hình hóa Một bản mô tả của mẫu thiết kế cần có những vấn đề chính sau: 1. Vấn đề mô điều kiện áp dụng mẫu thiết kế. Nó giải thích rõ hơn về bài toán và ngữ cảnh của nó. Nó bao gồm một danh sách những điều kiện phải được thỏa mãn trước khi nó được áp dụng mẫu thiết kế. Bài toán được biểu diễn qua phần mục đích và tính khả dụng trong tài liệu mẫu thiết kế. 2. Vấn đề mô tả những thành phần tạo lên bản thiết kế, những quan hệ, vai trò và sự hợp tác của chúng. Nó được biểu diễn qua phần cấu trúc, sự hợp tác và những thành phần tham gia trong tài liệu của mẫu 1.1. Vai trò của mẫu thiết kế Bên cạnh những lợi ích trực tiếp của một giải pháp tốt cho việc tinh chế thiết kế của những hệ thống phần mềm, chất lượng tốt hơn, những mẫu thiết kế thậm trí còn có thể cải thiện tài liệu và bảo trì những hệ thống đã có và cho phép những người thiết kế trừu tượng hóa những chi tiết thiết kế đã quen thuộc (Ví dụ: những quan hệ, những 3 phương thức) và tập chung vào những nhiệm vụ quan trọng hơn. Những mẫu cũng làm cho việc sử dụng lại những thiết kế và cấu trúc trở nên đơn giản hơn. 1.2. Mẫu thiết kế hợp nhất (Union Design Pattern) Mẫu thiết kế hợp nhất là một mẫu mang tính cấu trúc mô tả quan hệ kế thừa giữa một lớp cha và những lớp con của nó. Lớp cha là một sự biểu diễn mang tính trừu tượng của sự kết hợp của tất cả các lớp con. Mẫu thiết kế hợp nhất hướng đến hai mục tiêu của thiết kế hướng đối tượng là: - Tập hợp mã nguồn chung từ những lớp con và đưa nó vào một lớp cha. - Định nghĩa một lớp cha mang tính trừu tượng biểu diễn một mức trừu tượng cao hơn so với những lớp con cụ thể. Lớp cha mang tính trừu tượng đó là một sự biểu diễn của những tính chất chung của tất cả những lớp con. Những lớp con cụ thể là khác nhau, chúng chứa những thể hiện khác nhau. Mẫu hợp nhất (Union Pattern) sử dụng trên nền tảng những nguyên lý của thiết kế hướng đối tượng như tính kế thừa, tính đa hình, tính kế thừa, tính đóng gói nhằm hướng tới mục tiêu thiết kế những hệ thống mạnh mẽ hơn, linh động hơn và năng suất hơn. Một cách tổng quát, Một biểu đồ lớp UML cho mẫu thiết kế hợp nhất có dạng như sau: Hinh 1: Biểu đồ lớp cho mẫu thiết kế hợp nhất 4 Các đặc điểm của mẫu hợp nhất:  Hai hay nhiều lớp con: Một lớp con có thể là trừu tượng, trong trường hợp này lớp con đó có thể biểu diễn một tầng mang tính trừu tượng khác  Một lớp cha biểu diễn một sự trừu tượng hóa của tất cả cấc lớp con. Lớp cha đó không bao giờ được khởi tạo bởi vì nó không biểu diễn một thực thể cụ thể nào. Những phương thức cùa lớp cha có thể là trừu tượng (những hành vi thay đổi được định nghĩa trong những lớp con) hoặc cụ thể (những hành vi bất biến đối với mỗi lớp con) Tóm lại, kết quả của việc áp dụng mẫu hợp nhất là một mô hình thiết kế bao gồm một lớp cha mang tính trừu tượng và những lớp con. Lớp cha mang tính trừu tượng có cả phương thức cụ thể cái mà thực thi những hành vi bất biến của hệ thống và phương thức trừu tượng cái mà biểu diễn những hành vi không cố định của hệ thống. Những lớp con có những phương thức cụ thể thực thi những hành vi khác nhau của hệ thống và biểu diễn tính đa hình của hệ thống. 5 CHƯƠNG 2: OWL ONTOLOGY VÀ PROLOG Trong Chương này chúng tôi xin giới thiệu những khái niệm của một OWL Ontology và ngôn ngữ Prolog, những công cụ chính được sử dụng trong bài Khóa luận này. Tuy nhiên do tính chất của bài Khóa luận chúng tôi chỉ có thể giới thiệu một số nét chính về OWL Ontology cũng như ngôn ngữ Prolog. 2.1. OWL Ontology OWL (Web Ontology Language) là một trong những ngôn ngữ biểu diễn tri thức cho những ontology được đưa ra bởi W3C (World Wide Web Consortium – Tổ chức những chuẩn quốc tế cho World Wide Web). Chúng được thể hiện bởi những chuỗi ký tự dựa trên nền tảng RDF (Resource Description Framework)/XML (Extensible Markup Language) cho web ngữ nghĩa (Semantic Web). Owl được chia làm 3 loại: OWL - Lite, OWL - DL, OWL - FULL Các thành phần của OWL Ontology - Các cá thể (Individuals) - Thể hiện Các cá thể là các thành phần cơ bản, nền tảng của một Owl Ontology. Các cá thể trong một Owl Ontology có thể bao gồm các đối tượng cụ thể như con người, động vật, cái bàn…. Một Owl Ontology có thể không cần bất kỳ một cá thể nào, nhưng một trong những lý do chính của một Owl Ontology là để cung cấp một ngữ nghĩa của việc phân lớp các cá thể, mặc dù các cá thể này không thực sự là một phần của ontology. - Các lớp (Classes) - Khái niệm Các lớp là một thể hiện của một nhóm, tập hợp các đối tượng. 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. Một lớp có thể chứa các lớp con, có thể là một lớp tổng quan (chứa tất cả mọi thứ), có thể là lớp chỉ chứa những cá thể riêng lẻ, Một lớp có thể xếp gộp vào hoặc bị xếp gộp vào bởi các lớp khác. Mối quan hệ xếp gộp này được sử dụng để tạo ra 6 một cấu trúc có thứ bậc các lớp, thường là với một lớp thông dụng nhất kiểu Thing ở trên đỉnh và các lớp rất rõ ràng kiểu 2002, Ford ở phía dưới cùng. - Các thuộc tính (Properties) Các đối tượng trong Owl 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. - Các mối quan hệ (Relation) Một trong những ứng dụng quan trọng của việc sử dụng các thuộc tính là để mô tả mối liên hệ giữa các đối tượng trong ontology. Một mối quan hệ là một thuộc tính có giá trị là một đối tượng nào đó trong ontology. 2.1. Prolog 2.1.1. Giới thiệu ngôn ngữ Prolog 2.1.1.1. Prolog là ngôn ngữ lập trình logic. Prolog là tên viết tắt của PROgramming in LOGic, là ngôn ngữ được sử dụng phổ biến nhất trong dòng các ngôn ngữ lập trình logic. Ngôn ngữ Prolog do giáo sư người Pháp Alain Colmerauer và nhóm nghiên cứu của ông đề xuất lần đầu tiên tại trường Đại học Marseille vào đầu những năm 1970. Prolog được sử dụng chủ yếu trong lĩnh vực trí tuệ nhân tạo. 2.1.1.2. Cú pháp Prolog a. Các thuật ngữ Một chương trình Prolog là một cơ sở dữ liệu gồm các mệnh đề (Clause). Mỗi mệnh đề được xây dựng từ các vị từ (predicate). Một vị từ là một phát biểu nào đó về các đối tượng có giá trị chân đúng (true) hoặc sai (fail). Một vị từ có thể có các đối là các nguyên tử logic (logic atom). 7 Mỗi nguyên tử biểu diễn một quan hệ giữa các hạng (term). Như vậy, hạng và quan hệ giữa các hạng tạo thành mệnh đề. Hạng được xem là những đối tượng “dữ liệu” trong một chương trình Prolog. Hạng có thể là hạng sơ cấp (elementary term) gòm hằng (constant), biến (variable) và các hạng phức hợp (compound term). Các hạng phức hợp biểu diễn các đối tượng phức tạp của bài toán cần giải quyết thuộc lĩnh vực đang xét. Hạng phức hợp là một hàm tử (functor) có chứa các đối (argument), có dạng: Tên_hàm_tử (Đối_1, Đối_2,…, Đối_n) b. Các kiểu dữ liệu trong Prolog Các kiểu dữ liệu trong Prolog được biểu diễn trong hình sau đây: Hinh 2: Các kiểu dữ liệu trong Prolog 2.1.2. Sự kiện và Luật trong Prolog 2.2.2.1. Xây dựng sự kiện Ví dụ về sự kiện: parent(pam, bob). sister(mary, tom). 8 brother(peter, tomy). Sau khi hệ thống nhận được những sự kiện này, nếu người dùng đặt câu hỏi ?-parent(pam, bob). Sau khi hệ thống tìm thấy sự kiện này trong chương trình, Prolog trả lời: Yes Nếu đặt câu hỏi ?-parent(X, bob). Hệ thống sẽ trả lời: X = pam 2.2.2.2. Xây dựng luật Mỗi luật bao gồm hai phần khác nhau:  Phần bên phải: chỉ điều kiện, còn được gọi là thân (body) của luật  Phần bên trái: chỉ kết luận, còn được gọi là đầu (head) của luật VD: father(X, Y):-man(X), parent(X, Y). (father(X, Y) đúng nếu man(X) và parent(X, Y) đều đúng và sai nếu man(X) hoặc parent(X, Y) sai) person(X):-man(X); woman(X). (person(X) đúng nếu man(X) đúng hoặc woman(X) đúng; person(X) sai nếu man(X) và woman(X) đều sai). 9 CHƯƠNG 3. KIỂM TRA KẾT QUẢ ÁP DỤNG MẪU THIẾT KẾ Sau một thời gian tìm hiểu, cùng với sự giúp đỡ nhiệt tình của các thầy, cô hướng dẫn chúng tôi đã tìm ra và xin đề xuất một giải pháp hỗ trợ việc kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế. Giải pháp mà chúng tôi lựa chọn được thực hiện thông qua những bước sau đây:  Chuyển biểu đồ lớp trong UML sang OWL Ontology  Thực hiện so sánh hai OWL Ontology Sau đây chúng tôi sẽ trình bày chi tiết từng bước thực hiện trên để làm rõ hơn về giải pháp trên. 3.1. Chuyển biểu đồ lớp trong UML sang OWL Ontology Có lẽ câu hỏi đầu tiên chúng tôi nhận được khi trình bầy về vấn đề này là “tại sao lại phải chuyển biểu đồ lớp trong UML sang OWL Ontology”. Như chúng ta đã biết, UML là một ngôn ngữ mô hình hóa phi chuẩn, một biểu đồ UML được biểu diễn bởi những ký hiệu hình họa chính vì thế nếu để biểu đồ lớp dưới dạng UML chúng ta sẽ rất khó để có thể thực hiện việc so sánh này. Chính vì thế chúng ta có thể nghĩ đến việc chuyển biểu đồ lớp UML sang một ngôn ngữ mô hình hóa chuẩn nào đó như OWL Ontology, XMI, … Với nững ưu điểm: Cấu trúc đơn giản, linh động cho người dùng trong việc định nghĩa cấu trúc, dễ dàng chia sẻ qua Internet. OWL Ontology xứng đáng được lựa chọn để biểu diễn biểu đồ lớp UML trong hoàn cảnh này. Chúng ta có thể dễ dàng chuyển một biểu đồ lớp trong UML sang OWL Ontology bằng việc áp dụng những ánh xạ chuyển những chi tiết đặc tả một biểu đồ lớp trong UML sang OWL Ontology đã được trình bầy cụ thể trong bài khóa luận của sinh viên Giáp Thị Ngọc Thúy và ở đây chúng tôi xin phép không trình bày lại nữa. 10 3.2. Thực hiện so sánh hai OWL Ontology Ngày nay cũng đã xuất hiện khá nhiều những công cụ cho phép người dùng so sánh hai phiên bản khác nhau của một owl ontology. Trước khi đưa ra giải pháp để thực hiện việc so sánh hai OWL Ontology chúng tôi cũng xin trình bày về thực trạng của một vài công cụ điển hình hỗ trợ cho việc so sánh hai OWL Ontology hiện nay. 3.2.1. Protégé Protégé được phát triển bởi Trung tâm nghiên cứu thông tin Y sinh Stanford (Stanford Center for Biomedical Infomationn Research) của trường đại học Y khoa Stanford (Stanford University School of Medicine) Protégé là một công cụ dựa trên nền tảng mã nguồn mở và được sử dụng miễn phí. Đây là một công cụ hỗ trợ việc mô hình hóa tri thưc dưới dạng Ontology với nhiều định dạng như: owl, rdf, rdfs,… Bên cạnh đó, Protégé còn cho phép chúng ta quản lý nhiều ontology như việc trộn hai ontology, so sánh hai phiên bản khác nhau của một ontology,… Tuy nhiên trong bài viết này chúng ta chỉ quan tâm đến chức năng so sánh hai phiên bản khác nhau của một ontology. Hình ảnh sau biểu diễn kết quả quả của quá trình kiểm tra hai phiên bản khác nhau của một Owl Ontology bằng Protégé: Hinh 3: Kết quả so sánh hai phiên bản của một OWL Ontology với Protégé Trong bảng kết quả nhận được ở trên có chứa các cột: 11  f1, f2: Là hai cột biểu diễn những lớp, thuộc tính của phiên bản trước đó và phiên bản hiện tại( đang được mở trên Protégé )  renamed: Một ô trong cột này nhận giá trị “Yes” nếu hai lớp, thuộc tính ở hai ô tương ứng trong cột f1, f2 là tương đương nhau nhưng chỉ khác nhau về tên. Ngược lại, nó nhận giá trị “No” khi hai thuộc tính tương ứng trong hai ô ở f1, và f2 không tương đương nhau.  operation: Cột này biểu diễn mối quan hệ giữa hai thuộc tính ở hai ô tương ứng trong f1 và f2. Operation nhận giá trị “Map” nếu hai thuộc tính ở f1 và f2 đều tồn tại, nhận giá trị “Add” nếu thuộc tính chỉ tồn tại ở f1 hoặc f2.  map level: Chỉ ra mức độ phù hợp giữa hai thuộc tính tương ứng trong f1 và f2  rename explanation: Đưa ra một gợi ý của Protégé cho việc đặt lại tên giữa hai thuộc tính tương ứng ở f1 và f2 nếu giá trị trương ứng trong cột renamed là “Yes”. Nhận xét: Việc so sánh hai phiên bản khác nhau của một Owl Ontology với Protégé đã phân tích tương đối đầy đủ sự giống và khác nhau của hai OWL Ontology và hiển thị một cách rõ ràng giúp người dùng dễ dàng có thể nhận biết được những sự giống hay khác nhau đó. Tuy nhiên trong điều kiện hai OWL Ontology được so sánh biểu diễn hai biểu đồ lớp trong UML thì bên cạnh việc so sánh những chi tiết đơn thuần của hai OWL Ontology chúng ta cần có sự so sánh và biểu diễn một cách tường minh những mối quan hệ mang tính cấu trúc một biểu đồ lớp của hai OWL Ontology 3.2.2. OwlDiff OwlDiff là một công cụ cho phép so sánh hoặc hòa trộn hai Ontology. Hiện nay OwlDiff có thể chạy như một ứng dụng độc và cũng có thể chạy như một plug-in của công cụ Protégé. OwlDiff thực hiện so sánh hai Ontology vào thông báo những điểm không tương đương cũng như tương đương giữa hai Ontology. 12 Hinh sau đây biểu diễn kết quả của việc so sánh hai OWL Ontology metamodel1.owl và metamodel2.owl (được đính kèm bài khóa luận như một dữ liệu kiểm tra): 13 Hinh 4: Kết quả quá trinh so sánh hai OWL Ontology với OWLDiff Nhận xét: Chúng ta có thể thấy rằng với OWLDiff việc so sánh hai OWL Ontology được chi tiết và rõ ràng hơn rất nhiều so với việc sử dụng công cụ Protégé, việc thể hiện kết quả cũng được cải thiện rất nhiều. Song một vấn đề cực kỳ quan trọng là kiểm tra cấu trúc của hai OWL Ontology biểu diễn biểu đồ lớp UML hầu như không được thể hiện và việc thể hiện kết quả so sánh cũng không tạo nên mối quan hệ phân cấp rõ ràng giữa các thành phần của một biểu đồ lớp. 3.2.3. Giải pháp thực hiện so sánh hai OWL Ontology Để có thể thực hiện việc so sánh hai OWL Ontology nhiệm vụ đâu tiên là chúng ta phải thực hiện việc truy vấn trên hai OWL Ontology đó và lấy ra những chi tiết được sử dụng để biểu diễn hai biểu đồ lớp trong UML tương ứng. Có rất nhiều ngôn ngữ, công cụ hỗ trợ việc truy vấn OWL Ontology như: OQUEL (Ontology Query Language), COQL (CML Ontology Query Language), Protégé-OWL API,… Tuy nhiên để cho dễ dàng hơn trong việc truy vấn OWL Ontology trong ngôn ngữ java (ngôn ngữ chính thực hiện chương trình) chúng tôi sẽ sử dụng bộ thư viện của Protégé-OWL API. Đây là một thư viện cung cấp các lớp và các phương thức cho 14 phép chúng ta có thể tạo, truy vấn các OWL Ontology (việc truy vấn OWL Ontology sẽ được trình bày chi tiết hơn trong phần cài đặt ở Chương 4). Các chi tiết sử dụng để đặc tả hai OWL Ontology vừa truy vấn sẽ được lưu lại như là một cơ sở dữ liệu Prolog để rồi sau đó chúng ta có thể sử dụng những ràng buộc được viết dưới dạng các mệnh đề Prolog để thực hiện kiểm tra. Như đã trình bầy ở trên Prolog là một ngôn ngữ lập trình logic, nó hỗ trợ rất tốt cho việc suy luận vì vậy việc sử dụng những Prolog để thực hiện kiểm tra sẽ giúp chúng ta có thể kiểm tra được đầy đủ và chính xác hơn. Sau đây là những ràng buộc của hai OWL Ontology hay hai biểu đồ lớp (một biểu đồ là kết quả sau khi áp dụng mẫu hợp nhất của biểu đồ còn lại) tương đương: - Mọi lớp trong biểu đồ 1 (biểu đồ lớp trước khi áp dụng mẫu hợp nhất) đều là lớp cụ thể. - Tồn tại một lớp duy nhất trong biểu đồ 2 (biểu đồ lớp là kết quả của việc áp dụng mẫu hợp nhất cho biểu đồ 1) là lớp trừu tượng và tất cả các lớp còn lại trong biểu đồ 2 đề là lớp cụ thể và là lớp con của lớp trừu tượng đó. - Những phương thức có ở tất cả các lớp và được triển khai giống nhau trong biểu đồ 1 được chuyển thành một phương thức duy nhất và giống với những lớp dó trong lớp trừu tượng của biểu đồ 2. - Những phương thức có ở tất cả các lớp, song được triển khai khác nhau trong biểu đồ 1 được chuyển thành một phương thức trừu tượng trong lớp trừu tượng của biểu đồ 2. Đồng thời trong mỗi lớp con trong biểu đồ 2 phải có phương thức triển khai phương thức trừu tượng đó. - Các lớp trong biểu đồ 1 cùng với những hành vi của nó phải được bảo toàn trong biểu đồ 2 15 CHƯƠNG 4: XÂY DỰNG CÔNG CỤ Ở chương này chúng tôi xin trình bày về trình tự những bước thực hiện nhằm xây dựng công cụ hỗ trợ cho việc kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế thông qua việc so sánh hai OWL Ontology. Mục tiêu của chương trình là phát huy những ưu điểm cũng như khắc phục những yếu điểm mà những chương trình trước đã có. 4.1. Phân tích yêu cầu Vai trò của UML trong thiết kế phần mềm là không thể hoài nghi, những mẫu thiết kế nói chung và mẫu thiết kế hợp nhất nói riêng cũng là những giải pháp vô cùng hữu ích và cần thiết trong việc thiết kế, tối ưu hóa những mô hình UML. Sau đây là một ví dụ về một biểu đồ lớp trước khi áp dụng và sau khi áp dụng mẫu thiết kế hợp nhất. Hinh 5: Biểu đồ lớp trước khi áp dụng mẫu hợp nhất Hinh 6: Biểu đồ lớp sau khi áp dụng mẫu hợp nhất 16 Tuy nhiên việc thực hiện tối ưu hóa biểu đồ lớp sử dụng mẫu thiết kế hợp nhất được thực hiện tự động hay do con người thực hiện cũng không thể tránh được những sai sót không móng muốn. Đó là điều tối kỵ trong việc phát triển phần mềm, trong phát triển phần mềm, một sai sót dù là nhỏ cũng có thể khiến cho chúng ta tốn không ít kinh phí để có thể loại bỏ chúng. Chúng ta có thể bắt gặp những lỗi sau trong việc áp dụng mẫu hợp nhất (không thỏa mãn những tính chất của mẫu hợp nhất được đưa ra trong Chương 1):  Không xác định được lớp cha trừu tượng của một các lớp con Hinh 7: Kết quả của việc không tìm ra lớp cha trừu tượng của các lớp con khi áp dụng mẫu hợp nhất Sai sót kiểu này sẽ làm cho việc mã hóa vướng phải sự trùng lặp không cần thiết và rất khó kiểm soát và chỉnh sửa những sai sót khi xảy ra.  Không xác định đầy đủ những phương thức cụ thể của lớp cha trừu tượng Hinh 8: Kết quả của việc không xác định đầy đủ các phương thức cụ thể của lớp cha trừu tượng  Không xác định đầy đủ những phương thức trừu tượng của lớp cha trừu tượng 17 Hinh 9: Kết quả của việc không xác định đầy đủ các phương thức trừu tượng của lớp cha trừu tượng  Bên cạnh những lỗi như trên còn có rất nhiều lỗi mà người thiết kế có thể gặp phải khi áp dụng mẫu hợp nhất như: Có một lớp trừu tượng ở lớp cha không được triển khai trong một số lớp con, hay các lớp con không đảm bảo đầy đủ các hành vi… Những lỗi này sẽ được thể hiện đầy đủ qua các ràng buộc được giới thiệu ở phần sau. Từ việc phân tích những lỗi mà người thiết kế có thể mắc phải khi áp dụng mẫu hợp nhất chúng ta có thể thấy rằng việc kiểm tra việc áp dụng mẫu thiết kế hợp nhất là một việc làm cần thiết và cực kỳ quan trọng. 4.1.1. Biểu đồ lớp trong UML Trong phương pháp hướng đối tượng, một nhóm đối tượng có chung một số thuộc tính và phương thức tạo thành một lớp. Mối tương tác giữa các đối tượng trong hệ thống sẽ được biểu diễn thông qua mối quan hệ giữa các lớp. Các lớp( bao gồm cả các thuộc tính và phương thức ) cùng với các mối quan hệ sẽ tạo thành biểu đồ lớp. Biểu đồ lớp là một biểu đồ dạng mô hình tĩnh nhằm mô tả hướng nhìn tĩnh về một hệ thống bằng các khái niệm lớp, các thuộc tính, phương thức của lớp và mỗi quan hệ giữa chúng với nhau. Một biểu đồ lớp trong UML được biểu diễn bởi một tập các khái niệm sau: 18 - Lớp: Một lớp trong UML được biểu diễn bởi các thuộc tính: tên lớp, phạm vi truy nhập( visibility ), IsAbstract ( lớp trừu tượng hay không ), các thuộc tính và các phương thức. Lớp có thể thừa kế từ một lớp cha. - Thuộc tính( Attribute ): Các thuộc tính trong biểu đồ lớp được biểu diễn theo cấu trúc chung như sau: phạm_vi tên : kiểu số_đối_tượng = mặc_định (giá_trị_giới_hạn) Trong đó: phạm_vi: cho biết phạm vi truy nhập của thuộc tính. Có 3 kiểu xác định thuộc tính phổ biến là: + : Thuộc tính kiểu public # : Thuộc tính kiểu protected - : Thuộc tính kiểu private ~ : Thuộc tính được phép truy nhập tới từ các lớp trong cùng package tên: là xâu ký tự biểu diễn tên thuộc tính kiểu: là kiểu dữ liệu của thuộc tính số_đối_tượng: chỉ ra số đối tượng khai báo cho thuộc tính mặc_định: là giá trị khởi đầu mặc định ( nếu có ) của thuộc tính giá_trị_giới_hạn: là giới hạn các giá trị cho thuộc tính ( thông tin này không bắt buộc). Ví dụ về một khai báo thuộc tính đầy đủ: purchaseDate: Date[1] = “01-01-2010” (Saturday) - Phƣơng thức ( method ): các phương thức trong UML được biểu diễn theo cấu trúc chung như sau: 19 phạm_vi tên ( danh_sách_tham_số ) : kiểu_trả_lại { kiểu_phương_thức } Trong đó: phạm_vi biểu diễn phạm vi cho phương thức. Giống như đối với thuộc tính, có ba dạng kiểu xác định cơ bản cho phương thức là: + : phương thức kiểu public # : phương thức kiểu protected - : phương thức kiểu private ~ : phương thức được phép truy nhập tới từ các lớp trong cùng package tên : là xâu ký tự xác định tên của phương thức kiểu_trả_lại: chỉ ra kiểu giá trị trả về của phương thức danh_sách_tham_số: biểu diễn danh sách các tham số trong khai báo của phương thức. Mỗi tham số được biểu diễn dưới dạng chung: tên_tham_sô : kiểu_giá_trị = giá_trị_mặc_định kiểu_phương_thức: không bắt buộc, cho biết kiểu phương thức. Phương thức có thể nhận một trong các kiểu đặc biệt sau: abstract: phương thức kiểu trừu tượng query: phương thức kiểu truy vấn Ví dụ một khai báo phương thức cho một lớp: generatePurchaseList(prodID: int): String Các mối quan hệ trong biểu đồ lớp Giữa các lớp có các dạng quan hệ cơ bản như sau: 20 - Quan hệ kết hợp ( Association ): Một kết hợp ( assocition ) là một sự nối kết giữa các lớp, cũng có nghĩa là sự nối kết giữa các đối tượng của các lớp này. Trong UML, một quan hệ được ấn định nhằm mô tả một tập hợp các liên kết ( links ), tức là một sự liên quan về ngữ nghĩa ( semantic connection ) giữa một nhóm các đối tượng được biểu diễn bởi các lớp tương ứng. Hinh 10: Quan hệ kết hợp - Khái quát hóa ( Generalization ): Khái quát hóa là mối quan hệ giữa một lớp có các đặc trưng mang tính khái quát cao hơn và một lớp có tính chất đặc biệt hơn. Trong sơ đồ lớp, mối quan hệ khái quá hóa chính là sự kế thừa của một lớp từ lớp khác. Hinh 11: Quan hệ khai quát hóa - Quan hệ kết tập ( Aggregation ): Là dạng quan hệ mô tả một lớp A là một phần của lớp B và lớp A có hể tồn tại độc lập. Quan hệ cộng hợp được biểu diễn bằng một mũi tên gắn hình thoi rỗng ở đầu hướng về lớp bao hàm. Trong ví dụ sau, lớp Hóa đơn là một phần của lớp Khách hàng nhưng đối tượng Hóa đơn vẫn có thể tồn tại độc lập với đối tượng khách hàng. Hinh 12: Quan hệ cộng hợp 21 - Quan hệ hợp thành ( Composition ): Một quan hệ hợp thành biểu diễn một quan hệ kiểu tổng thể - bộ phận. Lớp A có quan hệ gộp với lớp B nếu lớp A là một phần của lớp B và sự tồn tại của đối tượng lớp B điểu khiển sự tồn tại của đối tượng lớ A. Hinh 13: Quan hệ hợp thành - Quan hệ thực thi ( Realization ): Một quan hệ thực hiện chỉ ra một lớp thực thi hành vi đặc tả bởi một lớp khác ( thường là một giao diện ) Một giao diện có thể được thực thi bởi nhiều lớp Một lớp có thể thực thi nhiều giao diện Hinh 14: Quan hệ thực thi - Quan hệ phụ thuộc ( Dependency ): Sự phụ thuộc chỉ ra một quan hệ ngữ nghĩa giữa hai hoặc nhiều lớp trong đó sự thay đổi của lớp này bắt buộc sự thay đổi của lớp khác mặc dù giữa chúng không có một sự liên kết rõ ràng Hinh 15: Quan hệ phụ thuộc 4.1.2. Biểu đồ lớp đặc tả dƣới dạng OWL Ontology Trong OWL Ontolog đặc tả một mô hình lớp trong UML định nghĩa các lớp OWL (OWL:Class): Class, Attribute, Operator, Parameter, Parameter_Direction_Kind… nhằm biểu diễn các lớp, toán tử, tham số và kiểu tham số tương ứng trong UML. Bảng sau đây sẽ mô tả chi tiết những lớp được khai báo trong OWL Ontology để mô tả một biểu đồ lớp. 22 Bang 1: Mô tả các lớp trong OWL Ontology đặc tả biểu đồ lớp trong UML OwlClass (Lớp) Property (Thuộc tính) PropertyType (Kiểu thuộc tính) Range (Phạm vi của thuộc tính) Class class_name owl:FunctionalPro perty String isAbstract owl:FunctionalPro perty boolean subClass owl:ObjectProperty Class Visibility_Kind visibility_kind owl:FunctionalPro perty String Parameter_Direct_ Kind parameter_direction_ kind owl:FunctionalPro perty String Parameter direction owl:ObjectProperty Parameter_Direct_ Kind para_name owl:DataTypeProp erty String owner_of_pa owl:ObjectProperty Operator Operator visibility owl:FunctionalPro perty Visibility_Kind op_isAbstract owl:FunctionalPro perty boolean operator_name owl:FunctionalPro perty String seq_parameters owl:ObjectProperty Prameter owner_of_op owl:ObjectProperty Class Một lớp, thuộc tính, phương thức trong biểu đồ lớp được biểu diễn bằng những cá thể (individual) của những lớp Class, Operator tương ứng trong OWL Ontology. 4.1.3. Yêu cầu hệ thống 4.1.3.1. Yêu cầu chức năng Hệ thống cho phép người sử dụng nhập vào hai phiên bản khác nhau của một biểu đồ lớp sau khi đã được đặc tả dưới dạng owl ontology. Hệ thống sẽ thực hiện truy 23 vấn trên hai owl ontology đó để lấy các thông tin về lớp, phương thức của lớp, thuộc tính của lớp, … của hai phiên bản của biểu đồ lớp. Hệ thống sẽ thực hiện so sánh hai phiên bản của biểu đồ lớp dựa trên những thuộc tính truy vấn được từ hai owl ontology. 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. Những ràng buộc để CD1 và CD2 là tương đương được đưa ra ở phần trên có thể được viết lại một cách chi tiết như sau:  Mọi lớp trong CD1 đều là lớp cụ thể  Tồn tại một lớp mới c0 thuộc CD2 sao cho c0 là lớp trừu tượng, và mọi lớp ci còn lại trong CD2 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 các lớp ci 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)  Tồn tại các phương thức o1,o2 trong CD1 với các đặc điểm sau o Trùng tên o Cùng kiểu o Cùng danh sách tham số o Cùng kiểu trả về o Được triển khai như nhau o Thuộc các lớp khác nhau  Tồn tại các phương thức o3,o4 trong CD1 với các đặc điểm sau (ví dụ phương thức makesound của Cat và Monkey) o Trùng tên o Cùng kiểu (cụ thể) o Cùng danh sách tham số o Cùng kiểu trả về o Được triển khai khác nhau o Thuộc các lớp khác nhau  Tồn tại phương thức o5 thuộc CD2 sao cho: o o5 thuộc lớp c0 24 o o5 có mọi đặc điểm giống với o1,o2  Tồn tại phương thức o6 thuộc CD2 sao cho: o o6 thuộc lớp c0 o 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.  Tồn tại phương thức o7 thuộc CD2 sao cho: o o7 thuộc ci o 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ể o o7 triển khai giống o3 4.1.3.2. Yêu cầu về mặt giao diện Giao diện của chương trình bên cạnh việc phải phát huy những ưu điểm của những chương trình đã có ở trên còn phải khắc phục những yếu điểm của nó. Nói một cách cụ thể hơn, giao diện của chương trình cần hỗ trợ tốt nhất cho người sử dụng kể cả những người không biết nhiều về biểu đồ lớp cũng như những chuyên gia về biểu đồ lớp UML hay thiết kế phần mềm. Giao diện cho phép người dùng lựa chọn những OWL Ontology để so sánh một cách dễ dàng, kết quả của quá trình kiểm tra phải hiển thị sự khác nhau giữa những điểm tương đương hay không tương đương giữa hai mô hình, biểu diễn rõ ràng cấu trúc của một biểu đồ lớp. 25 4.2. Pha phân tích 4.2.1. Biểu đồ UseCase tổng quát Hinh 16: Biểu đồ UseCase tổng thể 4.2.2. Kịch bản cho các ca sử dụng Bang 2: Kịch bản ca sử dụng “Import OWL Ontology” Tên Usecase Import owl ontology Tác nhân chính Người dùng Mức 1 Người chịu trách nhiệm Người dùng Tiền điều kiện Hệ thống được đã được kích hoạt Đảm bảo tối thiểu Thông báo lỗi nếu xảy ra Đảm bảo thành công Hai owl ontology cần kiểm tra được đưa vào hệ thống Kích hoạt Người dùng chọn chức năng nhập owl ontology 26 Chuỗi sự kiện chính Tác nhân Hệ thống 1. Hệ thống hiển thị form cho phép người sử dụng lựa chọn owl ontology 2. Người dùng chọn owl ontology cần kiểm tra 3. Các owl ontology được chọn sẽ được đưa vào hệ thống để kiểm tra Ngoại lệ: Bang 3: Kịch bản ca sử dụng “Compare two OWL Ontology” Tên Usecase Compare two OWL Ontology Tác nhân chính Người dùng Mức 1 Người chịu trách nhiệm Người dùng Tiền điều kiện Hai owl ontology mô tả hai phiên bản của biểu đồ lớp( Class Diagram ) đã được nạp vào hệ thống Đảm bảo tối thiểu Thông báo lỗi nếu có Đảm bảo thành công Kết quả kiểm tra phải được thông báo cho người sử dụng Kích hoạt Người dùng kích hoạt chức năng kiểm tra Chuỗi sự kiện chính Tác nhân Hệ thống 1. Hệ thống hiển form kích hoạt quá trình kiểm tra 2. Người dùng kích hoạt 3. Hệ thống kiểm tra hai owl ontology, thực 27 quá trình kiểm tra hiện truy vấn những đặc tả của hai biểu đồ lớp đồng thời so sánh những đặc tả đó 4. Hệ thống thông báo kết quả của quá trình kiểm tra Ngoại lệ: 3.a. Hai owl ontology nhập vào có cấu trúc không đúng 4.2.3. Xây dựng biểu đồ lớp phân tích Hinh 17: Biểu đồ lớp phân tích 28 4.3. Pha thiết kế 4.3.1. Biểu đồ tuần tự 4.2.2.1. Biểu đồ tuần tự của ca sử dụng “Import OWL Ontology” Hinh 18: BIểu đồ tuần tự ca sử dụng “Import OWL Ontology” 4.2.2.2. Biểu đồ tuần tự của ca sử dụng “Compare two OWL Ontology” Hinh 19: Biểu đồ tuần tự ca sử dụng “Compare two OWL Ontology” 29 4.3.2. Biểu đồ lớp chi tiết Hinh 20: Biểu đồ lớp chi tiết 30 4.3.3. Thiết kế riêng từng chức năng 4.2.2.3. Chức năng “Import OWL Ontology” Hinh 21: Thiết kế chức năng “Import OWL Ontology” 4.2.2.4. Chức năng “Compare two OWL Ontology” Hinh 22: Thiết kế chức năng “Compare two OWL Ontology” 31 4.3.4. Thiết kế giao diện ngƣời dùng Hình sau đây thể hiện giao diện chính của chương trình khi mới bắt đầu chạy, giao diện chính của chương trình đảm bảo cho phép người sử dụng dễ dàng nhập vào hai OWL Ontology cần kiểm tra. Bên cạnh đó giao diện còn thể hiện một số nút chức năng tiện ích cho người sử dụng như: Checking (Bắt đầu việc kiểm tra), Reset (hủy bỏ dữ liệu và kết quả kiểm tra cũ), Exit (kết thúc chương trình). Hinh 23: Giao diện chính của chương trình khi bắt đầu chạy Kết quả của quá trình kiểm tra được trình bầy trong một bảng trong đó thể hiện những đặc tình tương ứng giữa hai mô hình và kết quả so sánh giữa hai đặc tính đó. Trong bảng kết quả có thể hiện rõ mỗi quan hệ giữa các lớp, thuộc tính của lớp, phương thức của lớp, tham biến của phương thức… 32 Hinh 24: Giao diện của chương trình với kết quả của quá trình kiểm tra 4.4. Cài đặt và kiểm thử 4.4.1. Cài đặt Trong phần này, chúng tôi xin trình về một số vấn đề chính liên quan đến việc cài đặt chương trình demo: Môi trường thực hiện, những phần mềm và thư viện liên quan. Đồng thời, trong phần này chúng tôi cũng xin trình bầy về cách truy vấn Owl Ontology bằng ngôn ngữ Java và một số luật điển hình được sử dụng để thực hiện việc kiểm tra hai mô hình biểu đồ lớp. 4.4.1.1. Môi trường thực hiện và những phần mềm, thư viện liên quan Chương trình được phát triển trên môi trường JDK 1.5 với môi trường soạn thảy Eclipse 3.0. Ngoài ra để có thể chạy thành công chương trình còn cầm có sự hỗ trợ của phần mềm SWI-Prolog (ở đây tôi sử dụng phiên bản 5.6.55) và Protégé để thực hiện việc kiểm tra hai mô hình bằng những luật Prolog và tạo, truy các Owl Ontology. 33 Bên cạnh những thư viện cơ bản của JDK 1.5 chương trình còn cần có bộ thư viện có trong plugin edu.stanford.smi.protegex.owl mà chúng ta có thể dễ dàng tìm thấy trong thư mục plugin của thư mục cài đặt chương trình Protégé khi nó được cài đặt trên máy tính và những thư viện của chương trình Prolog để thực hiện việc truy vấn Owl Ontology và SWI-Prolog bằng ngôn ngữ Java. 4.4.1.2. Truy vấn Owl Ontology Như đã trình bày ở trên, việc truy vấn OWL Ontology trong ngôn ngữ java mà chúng tôi sử dụng là Protégé-OWL API. Để trình bày cách thức mà Protégé-OWL API thực hiện truy vấn OWL Ontology, chúng ta hãy xét ví dụ sau đây: Ví dụ 1: lấy toàn bộ những thể hiện của lớp Visibility_Kind với những thuộc tính của nó bằng cách sử dụng ngôn ngữ java với thư viện Protégé-Owl API: import edu.stanford.smi.protegex.owl.ProtegeOWL; import edu.stanford.smi.protegex.owl.model.*; import edu.stanford.smi.protegex.owl.jena.*; import java.util.*; public class ProtegeOwlAPIExp{ public static void main(String[] args){ JenaOWLModel owlModel; try{ owlModel = ProtegeOWL.createJenaOWLModelFromURI( "file:///C:/metamodel1.owl"); OWLNamedClass namedClass = owlModel.getOWLNamedClass("Visibility_Kind"); Collection individualOfVisibilityKind = namedClass.getInstances(true); Visibility_Kind myVisibilityKind; 34 for(Iterator indiIterator = individualOfVisibilityKind.iterator(); indiIterator.hasNext();){ OWLIndividual individual = (OWLIndividual)indiIterator.next(); Collection propertiesColl = individual.getPossibleRDFProperties(); System.out.println(individual.getBrowserText()); For(Iterator proIterator = propertiesColl.iterator();proIterator.hasNext();) { RDFProperty pro = (RDFProperty)proIterator.next(); //String proType = //pro.getProtegeType().getBrowserText(); //if(proType.equals("owl:DatatypeProperty")){ String proName = pro.getName(); if(proName.equals("visibility_kind")){ String visibility_kind = "" + individual.getPropertyValue(pro); System.out.print(“\tVisibility_Kind:” + visibility_kind); } //} } }catch(Exception e){ 35 e.printStackTrace(); } } } Kết quả trả lại sau khi chay chương trình trên là: public visibility_kind: public protected visibility_kind: protected private visibility_kind: private Kết quả trên thể hiện toàn bộ những thể hiện của lớp Visibility_Kind trong Owl Ontology metamodel1.owl với thuộc tính visibility_kind có kiểu dữ liệu là String Xét cấu trúc của chương trình ProtegeOwlAPIExp.java trên: Lệnh: owlModel=ProtegeOWL.createJenaOWLModelFromURI("file:///C:/metamodel1 .owl”); Thực hiện việc tải một OwlModel từ một địa chỉ URI (Uniform Resource Identifier. Trong trường hợp này URL dẫn đến một file owl trên máy cục bộ). Sau khi OwlModel đã được tải vào trong chương trình của chúng ta, chúng ta có thể thực hiện những truy vấn mà mình muốn. Lệnh: OWLNamedClass namedClass = owlModel.getOWLNamedClass("Visibility_Kind"); Collection individualOfVisibilityKind = 36 namedClass.getInstances(true); Thực hiện việc truy vấn và lấy ra toàn bộ những thể hiện của lớp “Visibility_Kind” và đưa vào một biến có kiểu Collection (tập hợp) là individualOfVisibilityKind. Lệnh: OWLIndividual individual = (OWLIndividual)indiIterator.next(); Collection propertiesColl=individual.getPossibleRDFProperties(); Thực hiện việc lấy ra một thể hiện của lớp Visibility_Kind và toàn bộ những thuộc tính của thể hiện đó và được lưu vào trong một biến có kiểu Collection là propertiesColl. Lệnh tiếp theo là: RDFProperty pro = (RDFProperty)proIterator.next(); String proName = pro.getName(); Thực hiện việc lấy từng thuộc tính pro trong tập hợp những thuộc tính được chỉ ra ở trên và tên của thuộc tính được lấy ra và lưu vào biến proName qua phương thức getName. Giá trị của thuộc tính pro trong một thể hiện individual được trả lại bằng phương thức individual.getPropertyValue(pro); .Chúng ta có thể thấy rõ hơn trong ví dụ trên với câu lệnh: String visibility_kind = "" + individual.getPropertyValue(pro); Trên đây là một số những lớp và phương thức được sử dụng chính trong chương trình của bài khóa luận để thực hiện việc truy vấn hai Owl Ontology. Chúng ta 37 có thể tham khảo chi tiết về thư viện Protégé-Owl API trên Website: 4.4.1.3. Kiểm tra hai mô hình bằng các luật Prolog Những khái niệm cơ bản về Prolog đã được chúng tôi trình bày trong chương trước, ở đây chúng tôi chỉ xin gới thiệu về một số luật điển hình được sử dụng để so sánh hai Owl Ontology. Những luật sử dụng để kiểm tra sự tương đương của hai toán tử (operator): o Luật sử đụng để kiểm tra một tham biến P có thuộc mô hình 1 hay không: Một tham biến thuộc mô hình 1 nếu nó thuộc một toán tử nào đó trong mô hình 1 parameter_in_model1(P):- operator(O), %Voi Toan tu O bat ky operator_in_model1(O), %Toan tu O thuoc mo hinh 1 operator_has_seq_parameter(O, P),!. %Toan tu O chua %tham so P o Tương tự ta có luật kiểm tra một tham biến P có thuộc mô hình 2 hay không parameter_in_model2(P):- %parameter(P), operator(O), operator_in_model2(O), operator_has_seq_parameter(O, P),!. o Luật kiểm tra một tập hợp tham số của một toán tử O1 trong mô hình 1 không có trong tập hợp tham số của toán tử O2 trong mô hình 2 Tập hợp các tham số T1 của toán tử O1 trong mô hình 1 không có trong tập hợp tham số T2 trong toán tử O2 nếu tồn tại một tham số P1 thuộc T1 và P2 thuộc mô hình 2 mà P2 tương đương với P1 nhưng P2 không thuộc T2 38 parameters_set_of_operator1_model1_not_in_opeartor2_model2(O1, O2):- operator(O1), operator(O2), %O1, O2 la cac toan tu operator_in_model1(O1), operator_has_isabstract(O1, false), %O1 thuoc mo hinh 1, O1 la toan tu cu the operator_in_model2(O2), operator_has_isabstract(O2, false), %O2 thuoc mo hinh 2 va O2 la toan tu cu the operator_has_seq_parameter(O1, P1), %O1 co tham so P1 %parameter(P2), %parameter_in_model2(P2),%Tham so P2 thuoc mo hinh 2 equivalent_parameters(P1, P2),%P1 tuong duong P2 not(operator_has_seq_parameter(O2, P2)),!. %P2 khong thuoc O2 o Tương tự ta có luật kiểm tra tập hợp tham số của một toán tử O2 trong mô hình 2 không có trong tập hợp tham số của toán tử O1 trong mô hình 1 parameters_set_of_operator2_model2_not_in_opeartor1_model1(O1, O2):- operator(O1), operator(O2), operator_in_model1(O1), operator_has_isabstract(O1, false), operator_in_model2(O2), operator_has_isabstract(O2, false), operator_has_seq_parameter(O2, P2), %parameter(P1), %parameter_in_model1(P1), equivalent_parameters(P1, P2), not(operator_has_seq_parameter(O1, P1)),!. 39 o Luật kiểm tra xem hai toán tử thuộc hai mô hình có cùng tập hơp tham số hay không: Hai toán tử O1 thuộc mô hình 1 và O2 thuộc mô hình 2 có cùng tập hợp tham số nếu tập tham số của O1 chứa trong tập tham số của O2 và ngược lại. Điều này tương đương với không xảy ra việc tập hợp các tham số của O1 không trong tập tham số của O2 và và tập tham số của O2 không có trong tập tham số của O1 operators_has_not_same_parameters(O1, O2):- operator(O1), operator(O2), parameters_set_of_operator1_model1_not_in_opeartor2_mod el2(O1, O2); operator(O1), operator(O2), parameters_set_of_operator2_model2_not_in_opeartor1_mod el1(O1, O2). o Luật kiểm tra hai toán tử thuộc hai mô hình có cùng chung tập hợp những tham số hay không: Luật này là phủ định của luật trên operator_has_same_parameters(O1, O2):- operator(O1), operator(O2), operator_in_model1(O1), operator_in_model2(O2), not(operators_has_not_same_parameters(O1, O2)). o Luật kiểm tra sự tương đương của toán tử O1 thuộc mô hình 1 và O2 thuộc mô hình 2: Hai toán tử O1 và O2 tương đương nhau khi và chỉ khi chúng có cùng tên, kiểu (trừu tượng hay cụ thể), cùng được triển khai giống nhau trong các lớp chứa nó hay không, và có cùng tập hợp những tham số equivalent_operators(O1, O2):- 40 operator(O1), %O1 la mot toan tu operator_in_model1(O1), %O1 thuoc mo hinh 1 operator(O2), %O2 la mot toan tu operator_in_model2(O2), %O2 thuoc mo hinh 2 operator_has_name(O1, X), %O1 co ten la X operator_has_name(O2, Y), %O2 co ten Y X == Y, %X bang Y (hai toan tu cung ten) operator_has_isabstract(O1, E), operator_has_isabstract(O2, F), E == F, %hai toan tu co cung la truu tuong hoac cu the operator_has_commonality(O1, G), operator_has_commonality(O2, H), G == H, %O1, O2 deu duoc trien khai giong nhau hoac %khong giong nhau trong cac lop chua no operator_has_same_parameters(O1, O2),!. % O1, O2 co cung tap hop cac tham so 41 4.4.2. Một số trƣờng hợp kiểm thử  Trƣờng hợp 1  Input là hai đặt tả của hai mô hình lớp sau dưới dạng OWL Ontology Mô hình 1: Mô hình 2: 42  Kết quả Hình 4.9: Kết quả kiểm thử 1 Kết quả trả về của chương trình với hai mô hình trên là Đúng (True) – Hai mô hình là tương đương Nhận xét: Kết quả trả về là hợp lý với thực tiễn, biểu diễn cấu trúc lớp một cách rõ ràng. 43  Trƣờng hợp 2  Input là hai đặt tả của hai mô hình lớp sau dưới dạng OWL Ontology Mô hình 1: Mô hình 2: 44  Kết quả Hình 4.10: Kết quả kiểm thử 2 Kết quả trả về của chương trình với hai mô hình trên là Sai (false) – Hai mô hình là không tương đương về cả mặt cấu trúc và tính đảm bảo các hành vi của các lớp Nhận xét: Kết quả trả về là hợp lý với thực tiễn, biểu diễn cấu trúc lớp một cách rõ ràng. Những điểm giống và khác nhau được hiển thị giúp người sử dụng dễ dàng phát hiện ra. 45  Trƣờng hợp 3  Input là hai đặt tả của hai mô hình lớp sau dưới dạng OWL Ontology Mô hình 1: Mô hình 2: 46  Kết quả Hình 4.11: Kết quả kiểm thử 3 Kết quả trả về của chương trình với hai mô hình trên là Sai (false) – Hai mô hình là không tương đương về mặt cấu trúc nhưng vẫn đảm bảo về mặt hành vi của các lớp Nhận xét: Kết quả trả về là hợp lý với thực tiễn. 47 CHƯƠNG 5: TỔNG KẾT 5.1. Tổng kết quá trình thực hiện và kết quả đặt được Với yêu cầu đặt ra ban đầu của đề tài “Kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế”, chúng tôi đã tiến hành khảo sát hiện trạng, lựa chọn phương án, phân tích thiết kế và cài đặt chương trình thử nghiệm. Kết quả đạt được như sau: 5.1.1. Về mặt khảo sát, lựa chọn phƣơng án và phân tích thiết kế Chúng tôi đã khảo sát và phân tích thực trạng việc so sánh giữa hai OWL Ontology: Những chương trình hỗ trợ việc so sánh hai OWL Ontology đã tồn tại, những ưu điểm và những vấn đề cần khắc phục Sau một thời gian nghiên cứu và tìm ra phương án để thực hiện đề tài, chúng tôi đã tìm ra một phương án khả quan để thực hiện việc so sánh hai OWL Ontology (biểu diễn hai biểu đồ lớp UML): Đó là việc tìm ra phương án để thực hiện truy vấn OWL Ontology và thực hiện so sánh hai mô hình bằng cách sử dụng các luật Prolog. Chúng tôi đã cố gắng phân tích yêu cầu người dụng một cách đầy đủ nhất có thể, để thực hiện việc thiết kế một công cụ so sánh hai OWL Ontology đơn giản nhưng hiệu quả trên cơ sở phát huy những ưu điểm của những công cụ đã có và khắc phục những thiếu sót mà chúng gặp phải. 5.1.2. Về mặt cài đặt và kiểm thử Sau một thời gian thực hiện cài đặt, công cụ đã được cài đặt một cách thành công. Công cụ đã đặt được những gì mày trong giai đoạn thiết kế đặt ra, đó là việc so sánh cụ thể những chi tiết sử dụng để đặc tả biểu đồ lớp trong hai OWL Ontology, việc hiển thị những chi tiết được so sánh theo đúng cấu trúc của một biểu đồ lớp từ đó giúp người dùng dễ phát hiện những sai sót, bên cạnh đó công cụ cũng đặt được mục đích quan trọng mà những công cụ trước chưa đặt được, đó là việc so sánh về mặt cấu trúc giữa hai OWL Ontology. Đó là điểm mấu chốt trong việc so sánh hai phiên bản của một biểu đồ lớp (trước và sau khi áp dụng mẫu thiết kế hợp nhất). 48 5.2. Hướng phát triển Hiện tại Công cụ kiểm tra kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế giữa hai mô hình UML mới chỉ dừng lại ở việc kiểm tra, và chỉ ra sự tương đương hay không giữa những thành phần của hai biểu đồ lớp trong UML cũng như việc thỏa mãn cấu trúc mẫu. Song với những gì cong cụ đã đạt được hiện tại, trong tương lai công cụ hoàn toàn có thể tiến xa hơn với việc so sánh hai mô hình bất kỳ trong UML, với một giao diện tốt hơn, hay thậm trí là một chương trình tinh chế tự động một biểu đồ trong UML. 49 TÀI LIỆU THAM KHẢO [1] Bogumila Hnatkowska, Zbigniew Huzar, Lech Tuzinkiewicz. Refinement of UML Collaborations. Institute of Applied Informatics, Wrocław University of Technology [2] Cedric Bouhours, Herve Leblanc, Christian Percebois. Alternative Models for Structural Design Patterns. Universite PaulSabatier. [3] Klaus Bergner, Andreas Rausch, Marc Sihling, Alexander Vilbig. Structuring and Refinement of Class Diagrams. D-80290 Munchen, Germany, 1 st June 1998 [4] Patrick Blackburn, Johan Bos and Kristina Striegnitz. Learn Prolog Now [5] Bruce Eckel. Thinking in Java [6] Website: [7] Trần Tiến Dũng. Giáo trình lý thuyết và bài tập Java. Nxb Lao động Xã Hội [8] TS. Phan Huy Khánh. Lập trình logic trong Prolog [9] Trần Đình Quế, Nguyễn Mạnh Sơn. Phân tích thiết kế hệ thống thông tin. Học viện bưu chính viễn thông.