Khóa luận Kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
Vũ Văn Thế
KIỂM TRA SỰ TINH CHẾ HAI MÔ HÌNH CÓ
ÁP DỤNG MẪU THIẾT KẾ
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
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
Vũ Văn Thế
KIỂM TRA SỰ TINH CHẾ HAI MÔ HÌNH
CÓ ÁP DỤNG MẪU THIẾT KẾ
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: TS. Trƣơng Ninh Thuận
HÀ NỘI - 2010
LỜI CẢM ƠN
Sau hơn 5 tháng tìm hiểu và thực hiện, khóa luận “Kiểm tra sự tinh chế hai mô
hình có áp dụng mẫu thiết kế” đã hoàn thành. Để đạt được kết quả này, chúng tôi đã nỗ
lực hết sức đồng thời cũng nhận được rất nhiều sự quan tâm, giúp đỡ, ủng hộ của các
thầy cô, bạn bè và gia đình.
Trước hết, chúng em xin gửi lời cảm ơn chân thành đến bộ môn Công nghệ
phần mềm khoa Công nghệ Thông tin trường Đại học Công nghệ - Đại học Quốc gia
Hà Nội và các thầy cô đặc biệt là cô Vũ Diệu Hương, thầy Trương Ninh Thuận và thầy
Đặng Việt Dũng đã tận tình giúp đỡ, hướng dẫn chúng em hoàn thành khóa luận này.
Chúng tôi rất cảm ơn các bạn bè, các anh chị trong khoa đã bên cạnh ủng hộ,
đóng góp ý kiến cho chúng tôi trong quá trình thực hiện khóa luận.
Và chúng con cũng xin chân thành cảm ơn gia đình đã luôn động viên, tạo điều
kiện tốt nhất cho chúng con học tập và hoàn thành khóa luận.
Khóa luận đã hoàn thành với một số kết quả nhất định, tuy nhiên vẫn không
tránh khỏi sai sót. Kính mong sự cảm thông và đóng góp ý kiến từ các thầy cô và các
bạn.
Hà Nội, tháng 5 năm 2010
Vũ Văn Thế
Tóm tắt
Nội dung chính của bài khóa luận “Kiểm tra sự tinh chế hai mô hình có áp dụng
mẫu thiết kế” có thể được trình bày ngắn gọn qua các vấn đề sau:
- Tìm hiểu về khái niệm và vai trò của Mẫu thiết kế (design pattern) nói chung và
mẫu thiết kế hợp nhất nói chúng cũng như việc áp dụng mẫu thiết kế hợp nhất
(union design pattern)
- Thực hiện chuyển biểu đồ lớp UML sang dạng đặc tả OWL Ontology trên cơ sở
lý thuyết bài khóa luận của sinh viên Giáp Thị Ngọc Thúy đã thực hiện.
- Tìm hiểu một số công cụ đã có hỗ trợ việc so sánh hai OWL Ontology, phân
tích những ưu nhược điểm của chúng.
- Tìm kiếm giải pháp cho việc truy vấn OWL Ontology từ ngôn ngữ lập trình
Java đồng thời viết những luật Prolog kiểm tra sự tương đương của 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.
- Thiết kế và cài đặt công cụ hỗ trợ so sánh hai OWL Ontology hay hai phiên bản
của một biểu đồ lớp trước và sau khi áp dụng mẫu hợp nhất thông qua những
luật Prolog.
Mục lục
MỞ ĐẦU..............................................................................................................................1
1.1. Vai trò của mẫu thiết kế..........................................................................................2
1.2. Mẫu thiết kế hợp nhất (Union Design Pattern).......................................................3
2.1. OWL Ontology .......................................................................................................5
2.1. Prolog......................................................................................................................6
2.1.1. Giới thiệu ngôn ngữ Prolog..............................................................................6
2.1.1.1. Prolog là ngôn ngữ lập trình logic............................................................6
2.1.1.2. Cú pháp Prolog .........................................................................................6
2.1.2. Sự kiện và Luật trong Prolog ...........................................................................7
2.2.2.1. Xây dựng sự kiện .......................................................................................7
2.2.2.2. Xây dựng luật ............................................................................................8
THIẾT KẾ...........................................................................................................................9
3.2. Thực hiện so sánh hai OWL Ontology .................................................................10
3.2.2. OwlDiff ..........................................................................................................11
CHƢƠNG 4: XÂY DỰNG CÔNG CỤ...........................................................................15
4.1. Phân tích yêu cầu ..................................................................................................15
4.1.3.1. Yêu cầu chức năng ..................................................................................22
4.1.3.2. Yêu cầu về mặt giao diện.........................................................................24
4.2. Pha phân tích.........................................................................................................25
4.2.1. Biểu đồ UseCase tổng quát ............................................................................25
4.2.2. Kịch bản cho các ca sử dụng..........................................................................25
4.2.3. Xây dựng biểu đồ lớp phân tích.....................................................................27
4.3. Pha thiết kế............................................................................................................28
4.3.1. Biểu đồ tuần tự...............................................................................................28
4.3.2. Biểu đồ lớp chi tiết.........................................................................................29
4.3.3. Thiết kế riêng từng chức năng........................................................................30
4.3.4. Thiết kế giao diện người dùng .......................................................................31
4.4. Cài đặt và kiểm thử...............................................................................................32
4.4.1. Cài đặt ............................................................................................................32
4.4.1.2. Truy vấn Owl Ontology...........................................................................33
4.4.2. Một số trường hợp kiểm thử ..........................................................................41
CHƢƠNG 5: TỔNG KẾT ...............................................................................................47
5.1. Tổng kết quá trình thực hiện và kết quả đặt được ................................................47
DANH SÁCH CÁC BẢNG BIỂU
Bang 2: Kịch bản ca sử dụng “Import OWL Ontology”....................................................25
DANH SÁCH CÁC HÌNH VẼ
Hinh 1 Biểu đồ lớp cho mẫu thiết kế hợp nhất.....................................................................3
Hinh 2: Các kiểu dữ liệu trong Prolog.................................................................................7
Hinh 5: Biểu đồ lớp trước khi áp dụng mẫu hợp nhất........................................................15
Hinh 6: Biểu đồ lớp sau khi áp dụng mẫu hợp nhất...........................................................15
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
DANH SÁCH CÁC TỪ VIẾT TẮT
STT
Từ viết tắt
UML
Diễn giải
1
2
3
Unified Modeling Language
Web Ontology Language
Programing in Logic
OWL
Prolog
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.
1
CHƯƠNG 1: GIỚI THIỆU VỀ MẪU THIẾT KẾ
(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
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
2
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
3
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.
4
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
5
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).
6
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).
7
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).
8
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.
9
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:
10
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.
11
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):
12
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
13
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
14
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
15
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
16
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:
17
- 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:
18
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:
19
- 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
20
- 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.
21
Tải về để xem bản đầy đủ
58 trang
13/04/2025
160
Bạn đang xem 30 trang mẫu của tài liệu "Khóa luận Kiểm tra sự tinh chế hai mô hình có áp dụng mẫu thiết kế", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- khoa_luan_kiem_tra_su_tinh_che_hai_mo_hinh_co_ap_dung_mau_th.pdf
