PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Thông tin về sinh viên
Họ và tên sinh viên: Nguyễn Đức Đạt
Điện thoại liên lạc : 0944 783 023
Email: [email protected]
Lớp: KSTN-CNTT-K49
Hệ đào tạo: Chính qui
Đồ án tốt nghiệp được thực hiện tại:
Bộ môn công nghệ phần mềm
Thời gian làm ĐATN: Từ ngày / /2009 đến / /2009
2. Mục đích nội dung của ĐATN
Nghiên cứu và ứng dụng semantic web trong quá trình bảo trì phần mềm
3. Các nhiệm vụ cụ thể của ĐATN
•
•
•
•
•
Tìm hiểu về công nghệ ontology
Tìm hiểu về các vấn đề khó khăn trong quá trình bảo trì phần mềm
Tìm hiểu về hướng tiếp cận ontology vào trong quá trình bảo trì phần mềm
Phân tích và thiêt kế hệ thống Plugin cho bảo trì phần mềm.
Xây dựng hệ thống
4. Lời cam đoan của sinh viên:
Tôi – sinh viên Nguyễn Đức Đạt - cam kết ĐATN là công trình nghiên cứu của bản thân tôi
dưới sự hướng dẫn của TS. Cao Tuấn Dũng.
Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công
hỗ trợ bảo trì phần mềm đem lại nên em đã lựa chọn đề tài “Xây dựng hệ thống hỗ trợ
bảo trì phần mềm tích hợp với Eclipse sử dụng công nghệ web ngữ nghĩa”. Đây cũng là
một phần trong dự án Mitani2009 “Ứng dụng Semantic Web trong bảo trì và tái sử dụng
phần mềm” của bộ môn Công Nghệ Phần Mềm.
Mục đích chính khi phát triển đề tài là xây dựng được một công cụ, tạm đặt tên là
“Semantic Software Maintenance Plugin - SemanticSMPlugin”, để hỗ trợ các nhà bảo trì
trong một số tác vụ cụ thể của quá trình bảo trì. Hệ thống dựa trên những tài nguyên sẵn
có của hệ thống đó là source code và tài liệu đặc tả hệ thống để tạo ra các thông tin ngữ
nghĩa và sử dụng các thông tin này để xây dựng nên các chức năng hỗ trợ bảo trì.
Nội dung trình bày của đồ án
Chương I: Bài toán bảo trì phần mềm
Chương II: Web ngữ nghĩa và vai trò của Ontology trong bảo trì phần mềm.
Chương III: Tổng quan về công nghệ.
Chương IV: Phân tích và thiết kế hệ thống bảo trì phần mềm dựa trên web ngữ
nghĩa
Chương V: Xây dựng hệ thống bảo trì phần mềm dựa trên web ngữ nghĩa
Chương VI: Kết luận và hướng phát triển.
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
2
LỜI CẢM ƠN
Trước hết, em xin được chân thành gửi lời cảm ơn sâu sắc tới các thầy cô giáo trong
trường Đại học Bách Khoa Hà Nội nói chung và các thầy cô trong khoa Công nghệ
Thông tin, bộ môn Công nghệ phần mềm nói riêng đã tận tình giảng dạy, truyền đạt cho
em những kiến thức, những kinh nghiệm quý báu trong suốt 5 năm học tập và rèn luyện
Lớp KSTN-CNTT-K49
4
ABSTRACT OF THESIS
Software maintenance is a period of important and expensive in the process of software
development. Along with the software evolution, difficulties of maintaining were increased lead
to the cost of software maintenance is increased. The currently tools which provide support for
software maintenance are simple for a single task during maintenance process.
This thesis focus on researching and building a system based on the ontology to assist the
maintenance software. The research can be applied to many different programming languages.
However, in the limitation of the thesis, the system implemented a specific Plugin for the
development environment of Java language - Eclipse.
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
5
MỤC LỤC
LỜI MỞ ĐẦU.................................................................................................................................................................. 2
LỜI CẢM ƠN.................................................................................................................................................................. 3
ABSTRACT OF THESIS................................................................................................................................................. 5
DANH MỤC HÌNH VẼ.................................................................................................................................................... 11
HÌNH 1: CÁC LOẠI BẢO TRÌ PHẦN MỀM 11
HÌNH 9: CÁC THÀNH PHẦN TRONG ECLIPSE SDK 33
11
HÌNH 10: KIẾN TRÚC ECLIPSE PLUGIN 33
11
HÌNH 11: CẤU TRÚC DẠNG CÂY MỘT PROJECT JAVA 34
11
HÌNH 12: HƯỚNG TIẾP CẬN TỔNG QUAN CỦA HỆ THỐNG 37
11
HÌNH 13: KIẾN TRÚC TỔNG QUAN CỦA HỆ THỐNG 38
11
HÌNH 14: SEC ONTOLOGY 40
11
HÌNH 15: FRAGMENT ONTOLOGY 48
11
HÌNH 16: CÂY PHÂN CẤP CLASS CỦA DOCUMENT ONTOLOGY 49
HÌNH 24: VÍ DỤ VIỆC TẠO ANNOTATION TỪ DOCUMENT 62
11
HÌNH 25: TÊN THÀNH PHẦN SOURCE CODE TRONG TÀI LIỆU 62
11
HÌNH 26: TẠO THỦ CÔNG LIÊN KẾT GIỮA SOURCE CODE VÀ TÀI LIỆU 63
11
HÌNH 27: NHỮNG NGƯỜI SỬ DỤNG HỆ THỐNG 65
11
HÌNH 28: USE CASE TỔNG QUÁT CỦA HỆ THỐNG 66
11
HÌNH 29: KIẾN TRÚC HỆ THỐNG 68
11
HÌNH 30: GIAO DIỆN TÌM KIẾM TEST 79
11
Sinh viên thực hiện: Nguyễn Đức Đạt
HÌNH 37: LỰA CHỌN MỘT THÀNH PHẦN SOURCE CODE 84
11
HÌNH 38: POPUP MENU DESCRIPTION IN 85
11
HÌNH 39: POPUP MENU LINK SOURCE CODE VỚI TEST 85
12
HÌNH 40: GIAO DIỆN LỰA CHỌN THÀNH PHẦN TÀI LIỆU 85
12
HÌNH 41: GIAO DIỆN PHÂN TÍCH CODE 86
12
HÌNH 42: GIAO DIỆN PHÂN TÍCH TÀI LIỆU 86
12
HÌNH 43: MÔ HÌNH CHỨC NĂNG TÌM KIẾM 87
12
HÌNH 44: GIAO DIỆN TẠO LAYER CHO HỆ THỐNG 89
20
1.1. Khái niệm.....................................................................................................................................................20
1.2. Kiến trúc của Semantic Web........................................................................................................................20
2. ONTOLOGY
21
1.3. Khái niệm.....................................................................................................................................................21
1.4. Vòng đời của Ontology................................................................................................................................22
1.5. Phương pháp xây dựng Ontology...............................................................................................................23
3. ONTOLOGY TRONG BẢO TRÌ PHẦN MỀM
25
1.6. Vai trò của Ontology trong bảo trì phần mềm............................................................................................25
1.7. Các ontology con của hệ thống...................................................................................................................25
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
7
CHƯƠNG III: TỔNG QUAN VỀ CÔNG NGHỆ.............................................................................................................28
1. OWL – WEB ONTOLOGY LANGUAGE
28
2. THIẾT KẾ ONTOLOGY
41
1.16. Thiết kế Source Code Ontology..................................................................................................................41
1.17. Thiết kế Document Ontology.....................................................................................................................48
3. TẠO ANNOTATION
55
1.18. Tự động tạo annotation từ source code....................................................................................................55
1.19. Tạo annotation từ document và link với source code...............................................................................61
1.19.1.Thực hiện tự động..............................................................................................................................................61
1.19.2.Thực hiện thủ công.............................................................................................................................................65
4. MỤC ĐÍCH VÀ PHẠM VI CỦA HỆ THỐNG
66
1.20. Mục đích hệ thống.....................................................................................................................................66
1.21. Phạm vi hệ thống.......................................................................................................................................66
1. NHỮNG NGƯỜI SỬ DỤNG HỆ THỐNG
66
2. CÁC CHỨC NĂNG CHÍNH CỦA HỆ THỐNG
67
6. THIẾT KẾ MÀN HÌNH
81
1.27. Giao diện cửa sổ tìm kiếm Test..................................................................................................................81
1.28. Giao diện cửa sổ tìm kiếm Document.......................................................................................................81
1.29. Giao diện cửa sổ tra cứu quan hệ mã nguồn............................................................................................82
1.30. Giao diện cửa sổ tra cứu các độ đo...........................................................................................................84
1.31. Giao diện cửa sổ cảnh báo thay đổi tài liệu..............................................................................................84
1.32. Giao diện cửa sổ phân cấp gọi hàm..........................................................................................................84
1.33. Giao diện cửa sổ tạo Test..........................................................................................................................85
............................................................................................................................................................................86
1.34. Giao diện tạo thủ công link giữa thành phần source code với tài liệu và source code với Test................87
1.35. Giao diện phân tích tự động các artifact và xem ontology.......................................................................88
CHƯƠNG VI: CÀI ĐẶT VÀ PHÁT TRIỂN SEMANTICSMPLUGIN.............................................................................89
1. CHỨC NĂNG TÌM KIẾM
89
2. CHỨC NĂNG XÁC ĐỊNH MỐI QUAN HỆ GIỮA CÁC THÀNH PHẦN MÃ NGUỒN
91
3. CHỨC NĂNG XEM CÁC ĐỘ ĐO METRIC
92
4. CHỨC NĂNG TẠO TEST
1. KẾT QUẢ ĐẠT ĐƯỢC
101
1.1. Về mặt lý thuyết........................................................................................................................................101
1.2. Về mặt chương trình.................................................................................................................................101
9. ĐÁNH GIÁ KẾT QUẢ
101
1.36. Về mặt lí thuyết.......................................................................................................................................101
1.37. Về mặt chương trình...............................................................................................................................101
1.38. Một số hạn chế........................................................................................................................................102
10. HƯỚNG PHÁT TRIỂN
102
TÀI LIỆU THAM KHẢO............................................................................................................................................... 103
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
10
DANH MỤC HÌNH VẼ
HÌNH 1: CÁC LOẠI BẢO TRÌ PHẦN MỀM...................................................................................................................13
HÌNH 32: GIAO DIỆN TRA CỨU QUAN HỆ MÃ NGUỒN............................................................................................83
HÌNH 33: GIAO DIỆN TRA CỨU CÁC ĐỘ ĐO.............................................................................................................84
HÌNH 34: GIAO DIỆN CẢNH BÁO THAY ĐỔI TÀI LIỆU.............................................................................................84
HÌNH 35: GIAO DIỆN CÂY PHÂN CẤP GỌI HÀM.......................................................................................................85
HÌNH 36: LỰA CHỌN THÀNH PHẦN CODE TỪ ĐOẠN TEXT ĐƯỢC SELECT........................................................85
HÌNH 37: LỰA CHỌN MỘT THÀNH PHẦN SOURCE CODE......................................................................................86
HÌNH 38: POPUP MENU DESCRIPTION IN................................................................................................................87
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
11
HÌNH 39: POPUP MENU LINK SOURCE CODE VỚI TEST.......................................................................................87
HÌNH 40: GIAO DIỆN LỰA CHỌN THÀNH PHẦN TÀI LIỆU.......................................................................................87
HÌNH 41: GIAO DIỆN PHÂN TÍCH CODE.................................................................................................................... 88
HÌNH 42: GIAO DIỆN PHÂN TÍCH TÀI LIỆU...............................................................................................................88
HÌNH 43: MÔ HÌNH CHỨC NĂNG TÌM KIẾM..............................................................................................................89
HÌNH 44: GIAO DIỆN TẠO LAYER CHO HỆ THỐNG.................................................................................................91
HÌNH 45: CẬP NHẬT LIÊN KẾT GIỮA CÁC ARTIFACT.............................................................................................96
HÌNH 46: MÔ HÌNH LÀM TĂNG TỐC ĐỘ PHÂN TÍCH SOURCE CODE....................................................................99
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
12
13
• Thích ứng (adaptative): là việc chỉnh sửa phần mềm cho phù hợp với môi trường
đã thay đổi của sản phẩm. Môi trường ở đây có nghĩa là tất các các yếu tố bên
ngoài sản phẩm như quy tắc kinh doanh, luật pháp, phương thức làm việc,...
• Hoàn thiện: chỉnh sửa để đáp ứng các yêu cầu mới hoặc thay đổi của người sử
dụng. Loại này tập trung vào nâng cao chức năng của hệ thống, hoặc các hoạt
động tăng cường hiệu năng của hệ thống, hoặc đơn giản là cải thiện giao diện.
Nguyên nhân là với một phần mềm thành công, người sử dụng sẽ bắt đầu khám
phá những yêu cầu mới, ngoài yêu cầu mà họ đã đề ra ban đầu, do đó, cần cải tiến
các chức năng.
• Phòng ngừa (preventive): mục đích là làm hệ thống dễ dàng bảo trì hơn trong
những lần tiếp theo.
1.2. Sự cần thiết của bảo trì phần mềm
Bảo trì phần mềm để chắc chắn rằng phần mềm có thể thỏa mãn được các yêu cầu của
người dùng. Bảo trì có thể được áp dụng cho phần mềm được phát triển theo bất kì một
mô hình vòng đời phần mềm nào (như mô hình thác nước, mô hình xoắn ốc…). Các thay
đổi về hệ thống gây ra các hành động thiếu chính xác của phần mềm. Bảo trì cần phải
thực hiện để:
• Chỉnh sửa các lỗi
• Nâng cao thiết kế
• Các cài đặt nâng cao
• Giao tiếp với các hệ thống khác
• Thích ứng chương trình với các phần cứng, phần mềm, các phương tiện truyền
thông khác nhau
• Giúp hệ thống dễ sử dụng lại hơn trong những lần bảo trì tiếp theo
Người bảo trì cần phải thực hiện một số công việc sau:
Lớp KSTN-CNTT-K49
15
•
Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặc
tả.
• Chú ý theo sát tác động của môđun được sửa đến các thành phần khác trong hệ
thống.
Công đoạn phát triển phần mềm mới:
• Khi thêm chức năng mới phải phát triển chương trình cho phù hợp với yêu cầu
• Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm thử unit
• Phản ảnh vào giao diện của phần mềm (thông báo, phiên bản, . . .)
2. Phân tích hiện trạng của hệ thống bảo trì phần mềm
2.1. Chi phí bảo trì phần mềm
Chi phí cho bảo trì phần mềm là rất lớn so với các chi phí khác trong quy trình phát
triển phần mềm. Hình 4 mô tả chi phí của từng giai đoạn trong quy trình phát triển phần
mềm. Jussi Koskinen đã thống kê như sau:
Chi phí toàn bộ cho bảo trì phần mềm:
• Chi phí bảo trì phần mềm hàng năm của Mĩ ước tính khoảng hơn 70 tỉ đô,
trong đó riêng chính phủ liên bang đã tiêu tốn khỏang 8.38 tỉ đô trong giai
đoạn 5 năm để khắc phục sự cố Y2K
• Ở mức độ công ty, ví dụ Nokia sử dụng khỏang 90 triệu đô cho việc ngăn ngừa
sự cố Y2K
Chi phí cho các công việc bảo trì
• Khoảng 50% thời gian bảo trì được dành cho quá trình đọc hiểu code
Các liên kết truy vết giúp cho các kĩ sư phần mềm hiểu được mối quan hệ và sự phụ
thuộc giữa các thành phần phần mềm từ đó giúp đỡ cho quá trình đọc hiểu code. Tuy
nhiên, ngay trong các tổ chức và dự án với quy trình phát triển phần mềm thuần thục, các
thành phần phần mềm được tạo ra trong các bước của quy trình này cuối cùng cũng bị
mất liên kết với các thành phần khác. Các nhân tố chủ yếu dẫn đến việc mất liên kết giữa
các thành phần phần mềm bao gồm:
Các thành phần phần mềm khác nhau được viết bằng các ngôn ngữ khác nhau
(ngôn ngữ tự nhiên và ngôn ngữ lập trình)
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
17
Các thành phần phần mềm mô tả hệ thống phần mềm ở các cấp độ trừu tượng khác
nhau (cấp độ thiết kế và cài đặt)
Các quy trình làm thay đổi một thành phần artefact không dẫn đến các sửa đổi liên
kết đang tồn tại giữa nó với các thành phần artefact khác (Ví dụ: khi sửa code thì
không có đưa ra cảnh báo cho việc sửa tài liệu sử dụng của code đó)
Thiếu các công cụ hỗ trợ việc tạo và duy trì các liên kết truy vết này.
Các nghiên cứu tạo liên kết truy vết giữa source code và tài liệu cho đến nay chủ yếu
tập chung vào việc kết nối tài liệu và source code dựa trên những liên kết một-một. Hạn
chế lớn nhất của phương pháp này là đã bỏ qua các thông tin ngữ nghĩa, có cấu trúc có
thể tìm thấy trong các document và source code, dẫn đến sự thiếu chính xác và khả năng
ứng dụng trong thực tế không được cao.
Một thách thức khác gặp phải trong quá trình bảo trì hệ thống là một kỹ sư phần mềm,
theo thời gian cũng không còn nắm rõ được các thông tin về kiến trúc, về source code,
hay rộng hơn là các artefact do chính họ tạo ra nữa. Khó khăn thậm chí còn tăng nên gấp
bội nếu kỹ sư bảo trì không trực tiếp tham gia trong quá trình phát triển phần mềm.
18
Có các sản phẩm được sử dụng chuyên nghiệp cho một ngôn ngữ lập trình cụ thể như
CCFinder, JAAT là các sản phẩm được thiết kế dành riêng cho ngôn ngữ JAVA.
CCFinder giúp tìm ra các đoạn mã giống nhau trong một chương trình JAVA. JAAT thì
cho phép thực hiện trích rút các biểu thức mà có thể cùng tham chiếu tới cùng một vị trí
bộ nhớ trong quá trình thực thi chương trình. Đối với ngôn ngữ C++, có một công cụ gọi
là OCL – bộ gỡ lỗi dựa trên truy vấn (query-based debugger), đó là một công cụ để gỡ rối
chương trình C++ sử dụng các truy vấn được tạo thành từ các ngôn ngữ ràng buộc đối
tượng.
Các nghiên cứu trước đó về áp dụng công nghệ web ngữ nghĩa trong bảo trì phần
mềm chủ yếu tập chung vào việc hỗ trợ cho một thành phần phần mêm cụ thể hoặc hỗ trợ
cho một tác vụ bảo trì cụ thể. Ví dụ như ứng dụng Dhruv, đó là một web ngữ nghĩa với
mục đích hỗ trợ quá trình giải quyết lỗi trong cộng đồng web. Ngữ cảnh của ứng dụng là
làm sao để cộng đồng mã nguồn mở tìm được cách fix các lỗi bug trong phần mềm của
họ. Ontology được sử dụng để trợ giúp kết nối giữa người phát triển với các bug-report
và các vùng code bị ảnh hưởng thông qua liên lạc điện tử (các forum, các mailing list)[5].
So sánh với hệ thống LaSSIE, một hệ thống có cùng phương pháp tiếp cận, hệ thống
này có những đặc điểm sau:
Việc tạo metadata của source code và tài liệu được thực hiện một cách manual.
Điều này dẫn tới lượng dữ liệu phải nhập là lớn, không những thế dữ liệu nhập vào
sẽ rất dễ không chính xác, và không đầy đủ thông tin ngữ nghĩa
Hệ thống LaSSIE này có nhiều hạn chế do sử dụng ngôn ngữ mô tả tri thức
KANDOR. Đây là một ngôn ngữ không hỗ trợ suy diễn phân cấp, đồng thời nó
cũng không cho phép tạo ra một mối quan hệ giữa các thuộc tính khác nhau. Do
những hạn chế này nên hệ thống LaSSIE không suy diễn ra được các kết quả cần
thiết cho một số tác vụ bảo trì.
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp bên dưới cùng – nền tảng của kiến trúc là URI, Unicode và XML, bao gồm các
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
20
chuẩn web đang tồn tại, cung cấp các cú pháp cơ sở cho các ngôn ngữ web ngữ nghĩa.
Unicode cung cấp các lược đồ mã hóa ký tự cơ bản, cho phép sử dụng tập kí tự quốc tế,
được sử dụng trong XML. Chuẩn URI (Uniform resource identifier) cung cấp một
phương tiện để nhận biết duy nhất và đánh địa chỉ cho các tài liệu, các nguồn tin trên
web. Tất cả các khái niệm trong ngôn ngữ cao hơn trong mô hình trên đều được mô tả
bằng Unicode và được nhận dạng duy nhất qua các URI.
Các ngôn ngữ RDF(S), OWL và các luật nẳm ở bên trên, được sử dụng để mô tả các
từ vựng dùng trong web ngữ nghĩa cũng như các đối tượng dựa trên các từ vựng đó. Các
đối tượng này được tham chiếu đến bởi những URI.
Việc đặt lớp logic lên trên OWL và các luật hơi gây tranh cãi, do ngôn ngữ OWL và
các luật đã có logic bên trong. Có một số người đồng ý rằng ngôn ngữ logic có ý nghĩa
hơn nên đặt trên ngôn ngữ Ontology. Một số khác thì cho rằng đây là một lớp không
thích hợp, OWL và các luật nên là các ngôn ngữ ở mức trên cùng của ngôn ngữ Ontology
và các ứng dụng có thể truy cập tới lớp này trực tiếp.
Các lớp Proof và Trust chưa được xác định rõ, nhưng thường được cho là các ứng
dụng và không là một ngôn ngữ cụ thể nào. Ví dụ: ứng dụng có thể chứng minh một số
tuyên bố bằng cách sử dụng lập luận suy diễn, và một tuyên bố có thể được tin tưởng nếu
nó đã được chứng minh và được xác thực bởi một số các bên thứ 3 đã được tin tưởng.
Người dùng đóng một vai trò quan trọng trong lớp Trust, bởi vì người dùng nên quyết
định mặc dù nguồn thông tin đó có thể được tin cậy.
2. Ontology
Nó bao gồm các định nghĩa về các khái niệm căn bản trong một lĩnh vực và các mối liên
hệ giữa chúng mà máy tính có thể hiểu được.
Trong lĩnh vực Công nghệ thông tin, Ontology có một số đặc điểm sau:
Ontology được chuẩn hóa: các thuật ngữ trong Ontology được định nghĩa rõ ràng
về ngữ nghĩa
Ontology cung cấp khả năng đọc hiểu cho con người. chúng có thể được phát
triển, chia sẻ, hiểu bởi không chỉ các chương trình máy tính mà còn bởi các người
dùng, các chuyên gia và người thiết kế ontology về lĩnh vực đó.
Ontology là sự toàn diện: Chúng được thiết kế với mục đích bao trùm tất cả khái
niệm, có thể tái sử dụng trong các lĩnh vực khác nhau, không phải chỉ sử dụng
trong một ứng dụng chuyên biệt.
Ontology có thể chia sẻ: thông thường một ontology bao gồm rất nhiều khái niệm
do đó việc xây dựng ontology sẽ mất rất nhiều thời gian nếu không sử dụng lại các
ontology sẵn có. Việc chia sẻ các ontology giúp dễ dàng kết hợp các ontology
được phát triển riêng rẽ, sử dụng chúng để cho phép giao tiếp giữa các hệ thống
thông tin cần chia sẽ thông tin dựa trên các khái niệm chung. Ví dụ kết hợp
ontology của các đại lý du lịch với ontology về các dịch vụ khách sạn, các phương
tiện giao thông, có thể giúp khách du lịch tìm được hành trình du lịch phù hợp với
các yêu cầu về thời gian, giá cả của họ.
Một số lý do cần phát triển một Ontology:
Để chia sẻ những hiểu biết chung về cấu trúc thông tin giữa con người và các
software agent.
Để cho phép tái sử dụng lĩnh vực tri thức (domain knowledge).
Để làm cho các giả thuyết về lĩnh vực được tường minh.
Để tách biệt tri thức lĩnh vực ra khỏi tri thức thao tác (operational knowledge ).
Để phân tích lĩnh vực tri thức.
1.4. Vòng đời của Ontology
Vòng đời của Ontology được mô tả trong hình vẽ 5 [Paul, 2004].
rất cao, tầng miền xác định có thể tái sử dụng trong một lĩnh vực nhất định. Cộng đồng
Ontology cũng đang lớn mạnh và có rất nhiều Ontology đã được tạo ra, với tâm huyết
của nhiều chuyên gia. Do đó trước khi bắt đầu xây dựng ontology, cần xét đến khả năng
sử dụng lại các ontology đã có. Nếu có thể sử dụng lại một phần các ontology đã có, chi
phí bỏ ra cho quá trình xây dựng ontology sẽ giảm đi rất nhiều.
Sinh viên thực hiện: Nguyễn Đức Đạt
Lớp KSTN-CNTT-K49
23
Bước 3: Liệt kê các thuật ngữ quan trọng
Ontology được xây dựng trên cơ sở các khái niệm trong một lĩnh vực cụ thể, vì vậy
khi xây dựng ontology cần bắt đầu từ các thuật ngữ chuyên ngành để xây dựng thành các
lớp trong ontology tương ứng. Tất nhiên không phải thuật ngữ nào cũng đưa vào
ontology, vì chưa chắc đã định vị được cho thuật ngữ đó. Do đó cần phải liệt kê các thuật
ngữ, để xác định ngữ nghĩa cho các thuật ngữ đó, cũng như cân nhắc về phạm vi của
ontology. Việc liệt kê các thuật ngữ còn cho thấy được phần nào tổng quan về các khái
niệm trong lĩnh vực đó, giúp cho các bước tiếp theo được thuận lợi.
Bước 4: Xác định các lớp và phân cấp của các lớp
Công việc xác định các lớp không chỉ đơn giản là tiến hành tìm hiểu về ngữ nghĩa của
các thuật ngữ đã có để có được các mô tả cho thuật ngữ đó, mà còn phải định vị cho các
lớp mới, loại bỏ ra khỏi ontology nếu nằm ngoài phạm vi của ontology hay hợp nhất với
các lớp đã có nếu có nhiều thuật ngữ có ngữ nghĩa như nhau (đồng nghĩa, hay đa ngôn
ngữ). Ngoài ra không phải thuật ngữ nào cũng mang tính chất như một lớp.
Một công việc cần phải tiến hành song song với việc xác định các lớp là xác định
phân cấp của các lớp đó. Việc này giúp định vị các lớp dễ dàng hơn.
Có một số phương pháp tiếp cận trong việc xác định phân cấp của các lớp:
Phương pháp từ trên xuống (top-down): bắt đầu với định nghĩa của các lớp tổng
Các thuộc tính có thể có nhiều khía cạnh khác nhau: như kiểu giá trị, các giá trị cho
phép, số các thuộc tính (lực lượng), và các đặc trưng khác mà giá trị của thuộc tính có thể
nhận. Ví dụ: “Năm sinh” của một “nhân viên” chỉ có duy nhất và là số nguyên, có thể
nhận giá trị từ 1948 đến 1990. Cần phải xác định các ràng buộc cho một thuộc tính càng
chặt chẽ càng tốt, để tránh trường hợp nhập dữ liệu sai, dẫn đến đổ vỡ của các ứng dụng
sử dụng Ontology này.
Bước 7: Tạo các thể hiện/thực thể
Bước cuối cùng là tạo ra các thể hiện của các lớp trong sự phân cấp. Việc tạo thể hiện
cho một lớp là quá trình điền các thông tin vào các thuộc tính của lớp đó.
3. Ontology trong bảo trì phần mềm
Để trợ giúp cho người bảo trì trong các tác vụ của mình các nhà phát triển đã sử dụng
các kĩ thuật quản lý tri thức và các công cụ trợ giúp cho các tác vụ đó. Thành phần trung
tâm của cách tiếp cận này đó là việc định nghĩa ra một ontology của các tri thức cần thiết
trong bảo trì phần mềm. Ontology này được coi như là kiến trúc nền tảng trong cách tiếp
cận của họ. Nó cung cấp một danh sách các khái niệm và quan hệ mà người dùng quan
tâm tới.
1.6. Vai trò của Ontology trong bảo trì phần mềm
Thứ nhất, ontology cung cấp một tầng tích hợp dữ liệu từ nhiều nguồn khác nhau vào
trong một mô hình ngữ nghĩa thống nhất. Các dữ liệu được kết hợp với nhau có thể được
sử dụng để suy diễn ra các thông tin mong muốn, các thông tin này không được định
nghĩa trực tiếp trong từng nguồn dữ liệu riêng lẻ trước đó.
Thứ hai, mối quan hệ giữa các thành phần source code với nhau và source code với tài
liệu là thành phần không thể thiếu trong việc bảo trì phần mềm. Sử dụng ontology cho
phép hệ thống có thể tổ chức và lưu trữ các thông tin này từ đó so khớp các dữ liệu và các
mối quan hệ để phục vụ cho công tác bảo trì.
Thứ ba, ontology cho phép suy diễn ra những tri thức mới từ các tri thức cơ sở, cho
phép liên kết các đối tượng theo các mối quan hệ gián tiếp nhau.
Thứ tư, dữ liệu mà ontology sử dụng có thể được đặt ở nhiều nơi khác nhau, điều này