PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

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

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: ddat145@yahoo.com.vn

Đồ á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ôngtrình nào khác

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

Tác giả ĐATN

Nguyễn Đức Đạt

5 Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảovệ:

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

Giáo viên hướng dẫn

TS Cao Tuấn Dũng

LỜI MỞ ĐẦU

Bảo trì phần mềm là một công việc được thực hiện lặp đi lặp lại nhiều lần trong quátrình phát triển phần mềm Cùng với quá trình phát triển phần mềm việc bảo trì phầnmềm cũng ngày càng trở lên khó khăn hơn dẫn tới tốn kém về mặt thời gian, chi phí vàcông sức bảo trì Đã có nhiều nhà nghiên cứu hướng tới việc xây dựng những công cụ hỗtrợ cho công việc bảo trì này nhưng mới chỉ đạt được những kết quả đơn giản ở một vàitác vụ đơn lẻ trong quá trình bảo trì Cho đến nay người ta vẫn nỗ lực tìm kiếm nhữnggiải pháp mới để hỗ trợ nhiều tác vụ bảo trì một cách có hiệu quả hơn Đã và đang cónhững hệ thống như vậy được phát triển ở nhiều nơi và bởi nhiều nhà khoa học trên khắpthế giới

Nhận thức được khả năng ứng dụng thực tế cũng như những lợi ích mà một công cụ

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ụngphầ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ĩaChươ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

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 trongtrườ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ệntại trường

Em xin được gửi lời cảm ơn đến thầy Cao Tuấn Dũng - Giảng viên bộ môn Côngnghệ phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách Khoa Hà Nội đã hếtlòng giúp đỡ, hướng dẫn và chỉ dạy tận tình trong quá trình em làm đồ án tốt nghiệp

Cuối cùng, em xin được gửi lời cảm ơn chân thành tới gia đình, bạn bè đã động viên,chăm sóc, đóng góp ý kiến và giúp đỡ trong quá trình học tập, nghiên cứu và hoàn thành

đồ án tốt nghiệp

Hà Nội, ngày 28 tháng 05 năm 2009

Nguyễn Đức ĐạtSinh viên lớp KSTN-CNTT–K49Khoa Công nghệ Thông tin - Đại học Bách Khoa Hà Nội

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP

Bảo trì phần mềm là một giai đoạn quan trọng và tốn kém trong quá trình phát triển phầnmềm Cùng với sự phát triển của phần mềm những khó khăn của quá trình bảo trì ngày càng tăngdẫn tới chi phí cho quá trình bảo trì cũng tăng theo Các công cụ hiện tại mới chỉ cung cấp các hỗtrợ cho việc bảo trì phần mềm ở mức đơn giản cho một vài tác vụ đơn lẻ trong quá trình bảo trì

Đồ án này tập chung vào việc nghiên cứu và xây dựng một hệ thống dựa trên web ngữ nghĩa

để trợ giúp cho quá trình bảo trì phần mềm Những nghiên cứu của hệ thống có thể được áp dụngcho các ngôn ngữ lập trình khác nhau Tuy nhiên trong giới hạn của đồ án này chỉ thực hiện càiđặt cụ thể một Plugin cho môi trường phát triển Eclipse của ngôn ngữ Java

MỤC LỤC

LỜI MỞ ĐẦU 2

LỜI CẢM ƠN 3

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP 4

ABSTRACT OF THESIS 5

DANH MỤC HÌNH VẼ 9

CHƯƠNG I: BÀI TOÁN BẢO TRÌ PHẦN MỀM 11

1 TỔNG QUAN VỀ BẢO TRÌ PHẦN MỀM 11

1.1 Khái niệm bảo trì phần mềm 11

1.2 Sự cần thiết của bảo trì phần mềm 12

1.3 Quy trình bảo trì phần mềm 12

2 PHÂN TÍCH HIỆN TRẠNG CỦA HỆ THỐNG BẢO TRÌ PHẦN MỀM 14

2.1 Chi phí bảo trì phần mềm 14

2.2 Những khó khăn gặp phải trong quá trình bảo trì phần mềm 15

2.3 Tool hỗ trợ bảo trì 16

CHƯƠNG II: WEB NGỮ NGHĨA VÀ VAI TRÒ CỦA ONTOLOGY TRONG BẢO TRÌ PHẦN MỀM 18

1 WEB NGỮ NGHĨA 18

1.1 Khái niệm 18

1.2 Kiến trúc của Semantic Web 18

2 ONTOLOGY 19

2.1 Khái niệm 19

2.2 Vòng đời của Ontology 20

2.3 Phương pháp xây dựng Ontology 21

3 ONTOLOGY TRONG BẢO TRÌ PHẦN MỀM 23

3.1 Vai trò của Ontology trong bảo trì phần mềm 23

3.2 Các ontology con của hệ thống 23

CHƯƠNG III: TỔNG QUAN VỀ CÔNG NGHỆ 26

1 OWL – WEB ONTOLOGY LANGUAGE 26

1.1 Khái niệm OWL 26

1.2 Cấu trúc của OWL 27

1.2.1 Namespace 27

1.2.2 Ontology headers 27

1.3 Các phần tử cơ bản 27

1.3.1 Class và Individual 27

1.3.2 Định nghĩa thuộc tính đơn giản 28

1.3.3 Các đặc tính của một thuộc tính 28

1.3.4 Ràng buộc thuộc tính 30

2 PELLET OWL REASONER 30

2.1 Giới thiệu về Pellet 30

2.2 Các tính năng của Pellet 30

2.3 Kiến trúc Pellet 31

3 ECLIPSE PLUGIN FRAMEWORK 32

3.1 Eclipse Plugin 33

3.2 AST Parser 34

CHƯƠNG IV: PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN WEB NGỮ NGHĨA 36

1 HƯỚNG TIẾP CẬN CỦA HỆ THỐNG 37

2 THIẾT KẾ ONTOLOGY 38

2.1 Thiết kế Source Code Ontology 38

2.2 Thiết kế Document Ontology 45

3 TẠO ANNOTATION 53

3.1 Tự động tạo annotation từ source code 53

3.2 Tạo annotation từ document và link với source code 59

3.2.1 Thực hiện tự động 59

3.2.2 Thực hiện thủ công 63

4 MỤC ĐÍCH VÀ PHẠM VI CỦA HỆ THỐNG 64

4.1 Mục đích hệ thống 64

4.2 Phạm vi hệ thống 64

5 NHỮNG NGƯỜI SỬ DỤNG HỆ THỐNG 64

6 CÁC CHỨC NĂNG CHÍNH CỦA HỆ THỐNG 65

7 KIẾN TRÚC CHUNG CỦA HỆ THỐNG 67

8 ĐẶC TẢ CÁC CHỨC NĂNG CỦA HỆ THỐNG 69

8.1 Tìm kiếm tri thức 69

8.1.1 Tìm kiếm Test 69

8.1.2 Tìm kiếm tài liệu 70

8.2 Tra cứu quan hệ giữa các thành phần mã nguồn 72

8.3 Tra cứu các độ đo metric 73

8.4 Tra cứu thứ tự gọi hàm 74

8.5 Tạo tri thức 75

8.5.1 Tạo các Test 75

8.5.2 Tạo quan hệ giữa mã nguồn và tài liệu 76

9 THIẾT KẾ LỚP CỦA HỆ THỐNG 76

10 THIẾT KẾ MÀN HÌNH 78

10.1 Giao diện cửa sổ tìm kiếm Test 78

10.2 Giao diện cửa sổ tìm kiếm Document 79

10.3 Giao diện cửa sổ tra cứu quan hệ mã nguồn 79

10.4 Giao diện cửa sổ tra cứu các độ đo 81

10.5 Giao diện cửa sổ cảnh báo thay đổi tài liệu 81

10.6 Giao diện cửa sổ phân cấp gọi hàm 81

10.7 Giao diện cửa sổ tạo Test 82

10.8 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 84

10.9 Giao diện phân tích tự động các artifact và xem ontology 85

CHƯƠNG VI: CÀI ĐẶT VÀ PHÁT TRIỂN SEMANTICSMPLUGIN 86

1 CHỨC NĂNG TÌM KIẾM 86

2 CHỨC NĂNG XÁC ĐỊNH MỐI QUAN HỆ GIỮA CÁC THÀNH PHẦN MÃ NGUỒN 88

3 CHỨC NĂNG XEM CÁC ĐỘ ĐO METRIC 89

4 CHỨC NĂNG TẠO TEST 92

5 CHỨC NĂNG CẢNH BÁO THAY ĐỔI TÀI LIỆU 93

CHƯƠNG VII: XÂY DỰNG HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN WEB NGỮ NGHĨA 95

1 XÂY DỰNG ỨNG DỤNG 95

1.1 Công cụ và môi trường phát triển 95

1.2 Một số vấn đề về lập trình 95

1.2.1 Tăng tốc độ của quá trình phân tích source code 95

1.2.2 Đặt tên cho các instance trong quá trình tự động sinh metadata 96

1.2.3 Sửa đổi ontology khi source code của hệ thống bị thay đổi 97

2 GIỚI THIỆU KẾT QUẢ 97

CHƯƠNG VIII: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 98

1 KẾT QUẢ ĐẠT ĐƯỢC 98

1.2 Về mặt chương trình 98

2 ĐÁNH GIÁ KẾT QUẢ 98

2.1 Về mặt lí thuyết 98

2.2 Về mặt chương trình 98

2.3 Một số hạn chế 99

3 HƯỚNG PHÁT TRIỂN 99

TÀI LIỆU THAM KHẢO 100

DANH MỤC HÌNH VẼ

Hình 1: Các loại bảo trì phần mềm 11

Hình 2: Các hoạt động trong quy trình bảo trì phần mềm 13

Hình 3: Trình tự bảo trì 13

Hình 4: Chi phí phát triển phần mềm 15

Hình 5: Kiến trúc Semantic Web 18

Hình 6: Vòng đời của Ontology 21

Hình 7: Ontology con 24

Hình 8: Kiến trúc Pellet 32

Hình 9: Các thành phần trong Eclipse SDK 33

Hình 10: Kiến trúc Eclipse plugin 33

Hình 11: Cấu trúc dạng cây một project Java 34

Hình 12: Hướng tiếp cận tổng quan của hệ thống 37

Hình 13: Kiến trúc tổng quan của hệ thống 37

Hình 14: SEC Ontology 40

Hình 15: Fragment Ontology 48

Hình 16: Cây phân cấp class của Document Ontology 49

Hình 17: Mapping instances 54

Hình 18: Mapping relations 54

Hình 19: Sinh annotation từ source code 55

Hình 20: Ví dụ về tạo annotation từ source code 55

Hình 21: Ví dụ về annotation được sinh ra từ source code 57

Hình 22: Sinh annotation từ document và link với annotation của source code 59

Hình 23: Ví dụ về tài liệu được phân tích 61

Hình 24: Ví dụ việc tạo annotation từ document 62

Hình 25: Tên thành phần source code trong tài liệu 62

Hình 26: Tạo thủ công liên kết giữa source code và tài liệu 63

Hình 27: Những người sử dụng hệ thống 65

Hình 28: Use Case tổng quát của hệ thống 66

Hình 29: Kiến trúc hệ thống 68

Hình 30: Giao diện tìm kiếm Test 78

Hình 31: Giao diện tìm kiếm tài liệu 79

Hình 32: Giao diện tra cứu quan hệ mã nguồn 80

Hình 33: Giao diện tra cứu các độ đo 81

Hình 34: Giao diện cảnh báo thay đổi tài liệu 81

Hình 35: Giao diện cây phân cấp gọi hàm 82

Hình 36: Lựa chọn thành phần code từ đoạn text được select 82

Hình 37: Lựa chọn một thành phần source code 83

Hình 38: Popup menu Description in 84

Hình 39: Popup menu Link source code với Test 84

Hình 40: Giao diện lựa chọn thành phần tài liệu 84

Hình 41: Giao diện phân tích code 85

Hình 42: Giao diện phân tích tài liệu 85

Hình 43: Mô hình chức năng tìm kiếm 86

Hình 44: Giao diện tạo Layer cho hệ thống 88

Hình 45: Cập nhật liên kết giữa các artifact 93

Hình 46: Mô hình làm tăng tốc độ phân tích source code 96

CHƯƠNG I: BÀI TOÁN BẢO TRÌ PHẦN MỀM

1 Tổng quan về bảo trì phần mềm

Để hiểu được ứng dụng bảo trì phần mềm ta cần phải trả lời được các câu hỏi sau:

 Bảo trì phần mềm là gì?

 Tại sao cần phải bảo trì phần mềm?

 Bảo trì phần mềm như thế nào?

1.1 Khái niệm bảo trì phần mềm

Bảo trì phần mềm (software maintenance) bao gồm điều chỉnh các lỗi mà chưa đượcphát hiện trong các giai đoạn trước của chu kỳ sống của một phần mềm, nâng cấp tínhnăng sử dụng và an toàn vận hành của phần mềm Bảo trì phần mềm có thể chiếm đến65%-75% công sức trong chu kỳ sống của một phần mềm

Quá trình phát triển phầm mềm bao gồm rất nhiều giai đoạn: thu thập yêu cầu, phântích, thiết kế, xây dựng, kiểm tra, triển khai và bảo trì phần mềm Nhiệm vụ của giai đoạnbảo trì phần mềm là giữ cho phần mềm được cập nhật khi môi trường thay đổi và yêu cầungười sử dụng thay đổi

Theo IEEE (1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phầnmềm sau khi đã bàn giao để chỉnh lại các lỗi phát sinh, cải thiện hiệu năng của phần mềmhoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trường đã bịthay đổi Bảo trì phần mềm được chia thành 4 loại:

Hình 1: Các loại bảo trì phần mềm

 Sửa lại cho đúng (corrective): là việc sửa các lỗi hoặc hỏng hóc phát sinh Các lỗinày có thể do lỗi thiết kế, lỗi logic hoặc lỗi coding sản phẩm Ngoài ra, các lỗicũng có thể do quá trình xử lý dữ liệu, hoặc hoạt động của hệ thống

 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ênngoà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ámphá 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ếncá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 trongnhữ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ủangườ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ảithự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ềnthô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:

 Bảo trì điều khiển các chức năng thường ngày của phần mềm

 Bảo trì điều khiển các thay đổi phần mềm

 Hoàn thiện các chức năng đã có của hệ thống

 Ngăn ngừa việc giảm hiệu năng phần mềm

Hình 2: Các hoạt động trong quy trình bảo trì phần mềm

Trình tự bảo trì có thể được thể hiện như sau [8]:

Hình 3: Trình tự bảo trì

Công đoạn hiểu phần mềm đã có:

• Theo tài liệu để nắm chắc các chức năng

• Theo tài liệu chi tiết để nắm vững đặc tả chi tiết, điều kiện kiểm thử,

• Dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống

Công đoạn tu sửa phần mềm đã có:

• Bảo trì chương trình nguồn, tạo các môđun mới và dịch lại

• Thực hiện kiểm thử unit và tu chỉnh những mục liên quan có trong tư liệu đặctả.

• 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áttriể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ầnmề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

 Khoảng 65% chi phí bảo trì dành cho việc hoàn chỉnh, chỉnh sửa các chức năng

 Lượng code bảo trì

 Trong năm 1990 ước tính khoảng 120 tỉ dòng source code được bảo trì (Ulrich)

 Trong năm 2000 ước tính khoảng 250 tỉ dòng source code được bảo trì(Sommerville) và con số này ngày càng tăng nhanh

 Trung bình 100 công ty bảo trì khoảng 35 triệu dòng code (Muller) và sau mỗinăm số dòng code bảo trì lại tăng lên khoảng 10% Và kết quả là lượng codephải bảo trì tăng lên gấp đôi trong vòng 7 năm

Hình 4: Chi phí phát triển phần mềm

2.2 Những khó khăn gặp phải trong quá trình bảo trì phần mềm

Hệ thống phần mềm và thông tin đi kèm luôn có biến động lớn theo thời gian, gâykhó khăn trong việc đọc hiểu và bảo trì, do không có sự kết nối chặt chẽ giữa các thànhphần phần mềm và metadata của hệ thống Chìa khóa của việc bảo trì một hệ thống phứctạp là phải hiểu chúng, phải hiểu sâu về các thành phần chức năng, phi chức năng, và cáctương tác giữa chúng Đặc biệt, khó khăn nhất nằm trong phần source code; nhiều nghiêncứu đã chỉ ra rằng chi phí dành cho việc đọc hiểu code chiếm một phần rất lớn trong toàn

bộ chi phí bảo trì phần mềm Theo quy mô của hệ thống, lượng source code và các mốiquan hệ giữa các thành phần source code cũng ngày một tăng nhanh, cả về số lượng và

độ phức tạp, gây ra rất nhiều khó khăn cho người bảo trì trong việc đọc hiểu và xác địnhđoạn code cần được tập trung bảo trì

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 Tuynhiê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ácthà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ữacá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)

 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ácnhau (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ênkế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ếutậ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ạnchế 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ấpbộ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.Tương tự như vậy, nếu không được hỗ trợ, người kỹ sư sẽ gặp khó khăn không nhỏ khimuốn tái sử dụng các artefact của chính mình, chưa nói đến tái sử dụng artefact sẵn cócủa người khác

Việc tìm kiếm, phân tích và tìm hiểu source code đóng vai trò rất quan trọng Tuynhiên, ngay trong những IDE phát triển phần mềm mạnh nhất như Eclipse, việc hỗ trợtìm kiếm cũng không mạnh mẽ khi chỉ đơn thuần tìm kiếm text riêng lẻ, thông thườngtheo tên các method, class, …mà không hỗ trợ tìm kiếm kết hợp giữa các thành phần này.Người lập trình rất hay gặp phải những tình huống tìm kiếm như: tìm kiếm các phươngthức nhận một kiểu nào đó làm đối số đầu vào hay tìm kiếm các phương thức trả về mộtkiểu dữ liệu nào đó Hiện nay chưa có một IDE nào thỏa mãn các yêu cầu tìm kiếm nàyđơn giản là bởi vì chúng không khai thác tính ngữ nghĩa giữa các thành phần của sourcecode để thực hiện tìm kiếm

2.3 Tool hỗ trợ bảo trì

Có rất nhiều sản phẩm trên thị trường được dùng cho việc bảo trì phần mềm Mộttrong những loại của sản phẩm đó là các công cụ theo dõi lỗi, có một vai trò quan trọngtrong bảo trì Bugzilla của Mozilla Foundation là một ví dụ về một công cụ như vậy Cácsản phẩm dò tìm lỗi khác như Test Director của Mercury Interactive, Silk Radar củaSegue Software, SQA Manager của phần mềm Rational và QA director củaCompuware[6]

ProTeus III Expert CMMS của tổ chức Eagle Technology là một gói phần mềm bảotrì phần mềm cho phép người sử dụng kế hoạch ngăn chặn và bảo trì, tạo các yêu cầu việclàm tự động, lịch sử bảo trì các thiết bị tài liệu, truy vết tài sản và công việc tồn đọng, tạocác đơn đặt hàng, và tạo ra các bản báo cáo Microsoft Visual Source Safe là một tool hệthống kiểm soát mã nguồn được sử dụng bởi nhà quản lý cấu hình

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ốichươ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 đốitượ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ầnmề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ớimụ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ốngnà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ứcKANDOR Đâ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 Donhữ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ầnthiết cho một số tác vụ bảo trì

CHƯƠNG II: WEB NGỮ NGHĨA VÀ VAI TRÒ CỦA

ONTOLOGY TRONG BẢO TRÌ PHẦN MỀM

1 Web ngữ nghĩa

1.1 Khái niệm

Hiện nay có tồn tại một số các định nghĩa khác nhau về web ngữ nghĩa, tuy nhiên haiđịnh nghĩa sau có thể coi như là các định nghĩa chuẩn về web ngữ nghĩa

Theo Tim Berners-Lee (ông tổ của web): “Web ngữ nghĩa là mô hình mở rộng của

web hiện tại (World Wide Web), trong đó thông tin mang ngữ nghĩa rõ ràng, cho phép máy tính và con người tìm kiếm, chia sẻ và tích hợp thông tin dễ dàng hơn”.

Theo W3C “Web ngữ nghĩa là một quan điểm, với ý tưởng các dữ liệu trên web được

định nghĩa, liên kết theo cách nào đó có thể sử dụng bởi máy tính, không chỉ cho mục đích hiển thị mà còn cho phép tự động, tích hợp và tái sử dụng dữ liệu thông qua các ứng dụng”

Nhắc đến Web ngữ nghĩa, ta không thể nào không kể đến Ontology Các Ontology tạo

ra xương sống cho các ứng dụng web ngữ nghĩa Ontology cho phép máy móc có thể hiểuđược các thông tin thông qua sự liên kết giữa các nguồn thông tin và các thuật ngữ trongOntology Hơn thế nữa, các Ontology làm sự tác động qua lại giữa các nguồn thông tin

dễ dàng hơn thông qua liên kết đến cùng một Ontology hay liên kết giữa các Ontologyvới nhau

1.2.Kiến trúc của Semantic Web

Hình 5: Kiến trúc Semantic Web

Quan điểm về Web ngữ nghĩa thường được mô tả thông qua kiến trúc lớp như trên.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

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ộtphươ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ênweb 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ĩahơ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ôngthí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 ứngdụ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

Ontology là một khái niệm được bắt nguồn từ triết học và được miêu tả trong Kivela

and Hyvonen,2002 và Smith and Welty, 2001; nó được nghiên cứu và phát triển bởi các

nhà nghiên cứu về trí tuệ nhân tạo để mô tả một cách hình thức một miền lĩnh vực nào

đó

2.1 Khái niệm

Có nhiều khái niệm về ontology đã được đưa ra và một trong những định nghĩa cơ

bản được đưa ra bởi Gruber vào năm 1993, theo đó ontology “là quá trình chi tiết hóa

các mức khái niệm; hay nói cách khác ontology bao gồm các khái niệm trong một mô hình miền lĩnh vực nào đó mà các khái niệm đó được mô tả một cách chi tiết”

[Gruber,1993] Sau đó vào năm 1997, Borst đã đưa ra định nghĩa ontology “là sự chi tiết

hóa một cách hình thức các khái niệm có thể chia sẻ với nhau, quan hệ với nhau”[Borst,1997]

Dựa trên hai định nghĩa này, ta có định nghĩa tổng quát về ontology như sau:

“Ontology là một tập các khái niệm và quan hệ giữa các khái niệm được định nghĩa cho

một lĩnh vực nào đó nhằm vào việc biểu diễn và trao đổi thông tin để con người và máy tính có thể hiểu được”

Tổ chức W3C đã đề ra một ngôn ngữ ontology trên Web (OWL: Web Ontoloty Language) để xây dựng Sematic Web dựa trên nền tảng của ontology.

Mỗi Ontology định nghĩa một bộ từ vựng mang tính phổ biến & thông thường chomột lĩnh vực nào đó Bộ từ vựng này sẽ giúp các nhà nghiên cứu chia sẻ thông tin vớinhau nó cho phép các nhà nghiên cứu chia sẻ thông tin trong một hoặc nhiều lĩnh vực

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áttriể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ườidù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áiniệ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ụngtrong 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ácontology 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ốngthô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ợpontology 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ươngtiệ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ớicá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ácsoftware 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

2.2 Vòng đời của Ontology

Vòng đời của Ontology được mô tả trong hình vẽ 5 [Paul, 2004]

Hình 6: Vòng đời của Ontology

Từ các tài liệu chuyên môn (chủ yếu tồn tại dưới dạng văn bản), các lớp, các quan hệgiữa các lớp và thuộc tính của các lớp được định nghĩa, cấu trúc hóa và biểu diễn trongOntology Các lớp mới được thêm vào phải được định vị vị trí của lớp trong Ontology đãxây dựng trước, và xác thực tính hợp lệ của các thông tin mới trích rút được Trong quátrình tìm kiếm, khai thác ontology, các tri thức mới được suy diễn từ cơ sở tri thức sinh rathông tin có ích mới, phục vụ nhu cầu của hệ thống khai thác Nhờ đó, ontology đượcnâng cấp dần dần

2.3 Phương pháp xây dựng Ontology

Quy trình phát triển Ontology là một quy trình gồm nhiều bước, tuy nhiên vẫn chưa

có một phương pháp chuẩn hóa nào để phát triển các ontologies Trong đồ án này em ápdụng một quy trình được áp dụng tương đối phổ biến hiện nay là quy trình phát triển gồm

7 bước do Stanford Center for Biomedical Informatics Research đưa ra (đây là nhóm pháttriển phần mềm Protégé để trình diễn và xoạn thảo Ontology) [10]

Bước 1: Xác định lĩnh vực và phạm vi của Ontology

Trong giai đoạn này cần xác định mục đích của việc xây dựng ontology là gì? Phục vụđối tượng nào? Ontology sắp xây dựng cần có đặc điểm gì, liên quan đến lĩnh vực, phạm

vi nào Quá trình khai thác, quản lý và bảo trì ontology được thực hiện ra sao?

Bước 2: Xem xét việc sử dụng lại các ontology có sẵn

Cấu trúc của một Ontology bao gồm 3 tầng: tầng trừu tượng (Abstract), tầng miền xácđịnh (Domain) và tầng mở rộng (Extension) Trong đó tầng trừu tượng có tính tái sử dụngrấ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 đồngOntology cũng đang lớn mạnh và có rất nhiều Ontology đã được tạo ra, với tâm huyếtcủ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

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ậykhi 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áclớp trong ontology tương ứng Tất nhiên không phải thuật ngữ nào cũng đưa vàoontology, vì chưa chắc đã định vị được cho thuật ngữ đó Do đó cần phải liệt kê các thuậtngữ, để xác định ngữ nghĩa cho các thuật ngữ đó, cũng như cân nhắc về phạm vi củaontology 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áiniệ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ủacác thuật ngữ đã có để có được các mô tả cho thuật ngữ đó, mà còn phải định vị cho cáclớ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ớicác lớp đã có nếu có nhiều thuật ngữ có ngữ nghĩa như nhau (đồng nghĩa, hay đa ngônngữ) 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

quát nhất trong lĩnh vực và sau đó chuyên biệt hóa các khái niệm đó Ví dụ: Trong Ontology về quản lý nhân sự, ta bắt đầu với lớp Người, sau đó chuyên biệt hóa lớpNgười đó bằng cách tạo ra các lớp con của lớp Người như : Kỹ sư, Công nhân, Bác sỹ,… Lớp Kỹ sư cũng có thể chuyên biệt hóa bằng cách tạo ra các lớp con như Kỹ sư CNTT, Kỹ sư điện, Kỹ sư cơ khí, …

 Phương pháp từ dưới lên (bottom-up): bắt đầu với định nghĩa của các lớp cụ thể

nhất, như các lá trong cây phân cấp Sau đó gộp các lớp đó lại thành các khái tổng quát hơn Ví dụ: ta bắt đầu với việc định nghĩa các lớp như: nhân viên lễ tân, nhân viên vệ sinh, nhân viên kỹ thuật Sau đó tạo ra một lớp chung hơn cho các lớp đó

là lớp nhân viên

 Phương pháp kết hợp: kết hợp giữa phương pháp từ trên xuống và từ dưới lên: bắt đầu từ định nghĩa các lớp dễ thấy trước và sau đó tổng quát hóa và chuyên biệt hóacác lớp đó một cách thích hợp Ví dụ ta bắt đầu với lớp nhân viên trước, là thuật ngữ hay gặp nhất trong quản lý nhân sự Sau đó chúng ta có thể chuyên biệt hóa thành các lớp con: nhân viên lễ tân, nhân viên vệ sinh,… hoặc tổng quát hóa lên thành lớp Người

Bước 5: Xác định các thuộc tính

Để xác định thuộc tính cho các lớp, ta quay trở lại danh sách các thuật ngữ đã liệt kêđược Hầu hết các thuật ngữ còn lại (sau khi đã xác định lớp) là thuộc tính của các lớp đó.Với mỗi thuộc tính tìm được, ta phải xác định xem nó mô tả cho lớp nào Các thuộc tính

đó sẽ trở thành thuộc tính của các lớp xác định Ví dụ lớp Người có các thuộc tính sau:

Họ, Tên, Ngày sinh, Giới tính, Nghề nghiệp, Địa chỉ, Điện thoại,…

Bước 6: Xác định giới hạn của các thuộc tính (lực lượng, kiểu giá trị).

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ị chophé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àngchặ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ệncho 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ụngcá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 trungtâ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ếttrong 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ếpcậ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 quantâm tới

3.1 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àotrong 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 địnhnghĩ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àiliệ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 chophé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ácmố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ở, chophé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àyphù hợp với mô hình chia sẻ dữ liệu giữa các thành viên của bộ phận bảo trì

3.2 Các ontology con của hệ thống

Một cách trực quan, tri thức về hệ thống là thành phần cơ bản và quan trọng để bảo trìphần mềm Các ontology con được miêu tả như trong Hình 7 Các câu hỏi cho các hệthống ontology con là: Những artifacts của một phần mềm hệ thống là gì? Làm thế nào đểcác artifact này có thể liên quan đến nhau? Các công nghệ được sử dụng bởi hệ thốngphần mềm? Hệ thống được cài đặt ở đâu? Ai là những người sử dụng phần mềm hệthống? Các chức năng nào của hệ thống từ miền ứng dụng được coi là những ứng dụngcủa hệ thống phần mềm? [3]

Việc trả lời những câu hỏi này đã dẫn đến việc phân rã hệ thống phần mềm thành cácartifacts, phân loại các artifact này và xác định người sử dụng cũng như các công nghệđược sử dụng trong quá trình phát triển.

Hình 7: Ontology con

Các artifacts của một hệ thống có thể được chia thành các tài liệu và các thành phầnphần mềm Các loại tài liệu là: tài liệu liên quan tới sản phẩm liên quan, tài liệu mô tả cáclại chính hệ thống đó (ví dụ, các đặc tả yêu cầu phần mềm, các đặc tả thiết kế phần mềm,

và các đặc tả sản phẩm phần mềm); các quá trình liên quan, các tài liệu được sử dụng đểtiến hành phát triển và bảo trì phần mềm (ví dụ, kế hoạch phát triển phần mềm, kế hoạchđảm bảo chất lượng, kế hoạch test và các kế hoạch quản lí cấu hình); và các tài liệu liênquan tới hỗ trợ khác như trợ giúp thực thi hệ thống (ví dụ, tài liệu hướng dẫn người sửdụng, hướng dẫn thao tác, hướng dẫn bảo trì)

Các thành phần phần mềm mô tả tất cả các thành phần code Booch [2] phân loạichúng ra thành các loại sau: các thành phần thực thi được, sinh ra các phần thực thi; cácthành phần deploy được, bao gồm các chương trình chạy được; các thành phần sản phẩmcông việc, đó là source code và dữ liệu; và tất cả các thứ mà thành phần deploy được cóthể sinh ra

Tất cả những artifacts này theo một cách nào đó đều có liên quan với nhau Ví dụ, mộtđặc tả yêu cầu có liên quan đến một đặc tả thiết kế, đặc tả thiết kế đó lại liên quan tới cácthành phần deploy Đây là loại quan hệ có liên quan tới hai artifacts ở các mức trừu tượngkhác nhau Một mối quan hệ giữa các artifact là kiểu đồng quan hệ giữa các thành phầnartifact cùng ở mức trừu tượng Và cuối cùng, một artifacts có thể là sự kết hợp của cácartifact khác (ví dụ như, một trong những tài liệu có thể là sự kết hợp của một số phần)

Các mối quan hệ khác trong ontology con này đó là: hệ thống phần mềm SYSTEMđược cài đặt trên một HARDWARE, nó có thể tương tác với các SYSTEMS khác và vớingười sử dụng USER, nó cài đặt một vài miền tác vụ TASK để có thể tự động thực hiện

và các đặc tả yêu cầu SOFTWARE REQUIREMENT SPECIFICATIONS phần mềm sẽ

mô tả các tác vụ này Diễn tả các ràng buộc thông qua các mối quan hệ như sau: nếu a1 làmột REQUIREMENT SPECIFICATION và a1 đồng liên quan tới a2, thì a2 cũng phải làmột REQUIREMENT SPECIFICATION (ví dụ: mối quan hệ đồng liên quan giữa cácartifact của cùng một kiểu)

CHƯƠNG III: TỔNG QUAN VỀ CÔNG NGHỆ

Ứng dụng này liên quan đến nhiều công nghệ, bao gồm các công nghệ liên quan tớiOntology, Eclipse và các bộ xoạn thảo tài liệu Trong chương này em sẽ trình bày ngắngọn về các công nhệ chính được sử dụng trong đồ án này

1 OWL – Web Ontology Language

"Hãy nói cho tôi biết tôi nên mua loại rượu nào để thích hợp với một bữa tiệc nhỏ Tôikhông thích Sauternes."

Đây là một câu hỏi mà khó có một ứng dụng web thông thường nào có thể thực hiệnviệc tìm kiếm thông tin thỏa mãn câu truy vấn này Để hỗ trợ cho việc này ta cần đưa ramột vài từ khóa và ngữ nghĩa của tài nguyên được mô tả trên web và tạo thành cácmetadata [9]

1.1 Khái niệm OWL

OWL - Web Ontologoy Language là một ngôn ngữ được dùng cho việc định nghĩa và

xây dựng các Web ontologies Ontology là một thuật ngữ mượn từ triết học đề cập đến khoa học mô tả các loại thực thể trong thế giới và quan hệ giữa chúng Một OWL

ontology bao gồm các mô tả về các classes, properties và các instances của chúng.

Một câu hỏi thường đặt ra là tại sao chúng ta lại không sử dụng các chuẩn Web khácnhư XML và XML Schema mà lại sử dụng ontology Có hai lý do giải thích cho câu hỏinày:

 Ontology khác với XML schema, Ontology là một biểu diễn tri thức, chứ khôngphải là một message format (định dạng thông điệp) Hầu hết các công nghệ với cácchuẩn Web là một sự kết hợp giữa các message formats và các protocolspecifications (giao thức truyền thông) Các định dạng này được gắn ngữ nghĩa vớicác thao tác, như “Khi nhận được message PurchaseOrder, chuyển Amount dollars

từ AccountFrom đếb AccountTo và vận chuyển Product” Tuy nhiên, đặc tả khôngđược thiết kế để hỗ trợ reasoning (suy diễn) ngoài ngữ cảnh trong giao tác

 Một lợi ích khác của các OWL ontologies là sự sẵn có của các công cụ thực hiệnviệc suy diễn với ontology Các công cụ này sẽ cung cấp cho ta các hỗ trợ tổngquát có thể sử dụng với tất cả các domain ứng dụng khác nhau trong khi đối vớiXML thì người ta có thể phải xây dựng một hệ thống suy diễn cho một lĩnh vực cụthể Hơn thế nữa việc xây dựng một ontology là khá đơn giản và dễ kiểm xoátbằng các công cụ soạn thảo ontology chuyên nghiệp

OWL cung cấp 3 ngôn ngữ con với cấp độ diễn đạt và hỗ trợ tăng dần đó là: OWL Lite,OWL DL và OWL Full

1.2.Cấu trúc của OWL

 rdf:about cung cấp một tên hay một tham chiếu cho ontology

 rdfs:comment cho phép chú thích ngữ nghĩa cho một ontology

 owl:imports cung cấp một cơ chế include-style owl:imports nhận một tham số duy nhất, nhận biết bởi thuộc tính rdf:resource

1.3 Các phần tử cơ bản

1.3.1 Class và Individual

1) Class đơn giản

Mỗi individual trong OWL đều thuộc về lớp owl:Thing Do đó, mỗi class được ngườidùng định nghĩa đều là subclass của owl:Thing Trong domain về rượu, 3 root classesđược định nghĩa là: Winery, Region, và ConsumableThing

<owl:Class rdf:ID="Winery"/>

<owl:Class rdf:ID="Region"/>

<owl:Class rdf:ID="ConsumableThing"/>

Cần chú ý là các định nghĩa có thể được chi tiết dần, cũng như có thể được phân tán

Ví dụ như lớp Winery sẽ được chi tiết các đặc tính hơn về sau

Để tạo cấu trúc phân cấp cho các class, sử dụng quan hệ rdfs:subClassOf Nếu X làmột subclass của Y, thì tất cả các instance của X cũng là một instance của Y Quan hệrdfs:subClassOf có tính bắc cầu Nếu X là một subclass của Y và Y là một subclass của

Z thì X cũng là một subclass của Z

Định nghĩa cho một class bao gồm 2 phần: tên và danh sách các restrictions Mỗiexpression trực tiếp trong class definition đưa thêm các giới hạn cho các instances củaclass được định nghĩa Instances của class này phải thỏa mãn tất cả các restrictions đó

Dưới đây là một định nghĩa đơn giản (một phần của định nghĩa hoàn chỉnh) cho classWine Wine là một PotableLiquid

1.3.2 Định nghĩa thuộc tính đơn giản

Một property là một quan hệ 2 ngôi Có 2 loại properties:

 datatype properties: property có dữ liệu là các kiểu đơn giản như string, int…

 object properties: mối quan hệ giữa hai instance của hai class.

<owl:ObjectProperty rdf:ID="madeFromGrape">

<rdfs:domain rdf:resource="#Wine"/>  định nghĩa thuộc class nào

<rdfs:range rdf:resource="#WineGrape"/>  định nghĩa loại dữ liệu

Nếu một property P là có tính symmetric (đối xứng) thì với mọi x và y

P(x,y) iff P(y,x) ( A iff B ≡ (A B) & (B A)  B) & (B  A)  B) & (B  A) )

Thuộc tính adjacentRegion là symmetric trong khi locatedIn thì không

Nếu thuộc tính P1 là inverseOf của thuộc tính P2 thì với mọi x,y ta có

P1(x,y) iff P2(y,x)

Chú ý rằng cú pháp của owl:inverseOf lấy đầu vào là tên của một property

5) Inverse Functional Property

Nếu một thuộc tính P là InverseFunctional thì với mọi x, y và z:

P(y,x) & P(z,x)  y = z

Chú ý rằng producesWine trong phần trước là inverse functional Lý do là inverse củamột thuộc tính functional phải là một inverse functional Chúng ta có thể định nghĩahasMaker và producesWine như sau:

2 Pellet OWL Reasoner

2.1 Giới thiệu về Pellet

Pellet là một bộ suy diễn cho OWL DL, đó là một phần mềm mã nguồn mở viết bằngJava và là sự kết hợp của Jena và các thư viện OWL API Bộ Pellet API cung cấp cácchức năng để xác thực, kiểm tra sự đồng bộ của ontologies, phân loại các khái niệm trongontology, hay kiểm tra sự kế thừa theo thứ tự và trả lời các truy vấn RDQL (hay còn đượcgọi là các truy vấn ABox)

Pellet hỗ trợ đầy đủ các tính năng của OWL DL, bao gồm cả việc suy diễn về các lớpliệt kê (enumerated classes) Nghĩa là ta có thể sử dụng các tính năng owl:oneOf vàowl:hasValue có trong OWL Hiện nay Pellet là bộ suy diễn đầu tiên và duy nhất cài đặtđầy đủ các tính năng của OWL

2.2 Các tính năng của Pellet

Pellet có các tính năng mà giải quyết được các yêu cầu của một Semantic Web cũng như các vấn đề gặp phải trong Semantic Web

 Phân tích và sửa chữa Ontology: Tất cả các tri thức cơ sở OWL được mã hóa như

dưới dạng các đồ thị RDF/XML OWL DL phải tuân theo một số hạn chế trên các đồ thịRDF, ví dụ như các ràng buộc về disjoint trên một tập tên các lớp Việc đảm bảo rằngmột tài liệu RDF/XML có đáp ứng tất cả các ràng buộc hay không là một công việctương đối khó khăn Pellet có chức năng giúp đỡ repair các tài liệu vi phạm các ràng buộcnày

 Xác minh lớp: đây là một quá trình rất phức tạp bao gồm nhiều bước, Pellet sẽ phân

loại các tri thức có trong ontology ra thành các lớp khác nhau

 Sự kế thừa theo thứ tự: Trong Semantic Web đây chính là chìa khóa cho việc suy

diễn ngữ nghĩa Tuy nhiên hầu hết các bộ suy diễn đều chưa hỗ trợ tính năng này

 Truy vấn liên hợp ABox: việc trả lời các câu truy vấn cũng là một tính năng quan

trọng khác đối với Semantic Web Pellet đã cài đặt module trả lời các câu truy vấn ABox

sử dụng kĩ thuật “rolling-up” Họ đã đưa ra một thuật toán để tối ưu hóa các truy vấnbằng cách thay đổi phù hợp các ứng cử viên cho các biến có thể được tìm thấy và thử.Khai thác sự phụ thuộc giữa các biến khác nhau giúp giảm được tổng số test được thựchiện và do đó làm tăng tốc độ trả lời một cách rõ rệt

 Suy diễn kiểu dữ liệu: XML Schema là một tập các kiểu dữ liệu cơ bản bao gồm

nhiều loại dữ liệu số (số nguyên, số thực), chuỗi, kiểu ngày giờ Nó cũng cung cấp mộtvài cơ chế cho phép tạo mới các kiểu dữ liệu Ví dụ ta có thể định nghĩa một kiểu dữ liệumới bằng cách thêm vào một vài ràng buộc, ví dụ như một xâu phải thỏa mãn một biểuthức chính quy nào đó hay một kiểu số nguyên phải là một số có 10 kí tự số Hiện nay hệthống XML Schema có xu hướng xác nhận độ chính xác tài liệu và sinh ra các PSVI thay

vì kiểm tra kiểu dữ liệu Pellet có thể kiểm tra được tính thỏa mãn của các liên hợp nhưvậy

 Các kiểu dữ liệu đơn giản do người dùng tự định nghĩa: Vấn đề chính trong việc

tạo các kiểu dữ liệu người dùng đó là làm sao để định nghĩa URI cho các định nghĩaXML Schema Trong Pellet đã áp dụng giải pháp sử dụng DAML + OIL để xác định URIcủa một kiểu dữ liệu được xây dựng từ URI của tài liệu XML Schema và tên của kiểu dữliệu đơn giản đó

 Truy vấn đã Ontology sử dụng E-Connections: một E-Connection là một ngôn ngữ

mô tả tri thức được định nghĩa là sự kết hợp của các hình thức logic khác Pellet sử dụngE-Connections như một ngôn ngữ cho việc định nghĩa và tạo các kết nối giữa cácontology OWL-DL, đó là một kiểu kêt nối tri thức chứ không phải kết nối logic Phươngpháp tiếp cận này cung cấp một lựa chọn khác thay cho owl:imports để mang tất cả cácaxioms từ ontology được import

 Debug Ontology: Phát hiện được các khái niệm không thỏa mãn trong một ontology

là một tác vụ có thể thực hiện trực tiếp Tuy nhiên việc chuẩn đoán và giải quyết các lỗithường không được hỗ trợ Ví dụ không có một giải thích nào được đưa ra là tại sao lạixảy ra lỗi hay sự phụ thuộc giữa các class như thế nào gây ra lỗi Pellet cung cấp hỗ trợcho cả hai tác vụ này bằng cách định vị các axiom gâp ra sự không nhất quán và mốiquan hệ giữa các khái niệm không thỏa mãn Hiện tại tính năng này đã được cung cấptrong Swoop, một nhánh phát triển của Pellet, nó cho phép người dùng debug ontology

2.3 Kiến trúc Pellet

Cốt lõi của bộ suy diễn Pellet là bộ suy diễn hoạt cảnh (tableaux reasoner) để kiểm tracác nhất quán của tri thức cơ sở, tức là một cặp ABox và TBox Bộ suy diễn này có thểlàm việc với các kiểu dữ liệu Oracle và có thể kiểm tra sự nhất quán các liên hợp của cáckiểu dữ liệu (được định nghĩa sẵn hoặc do người dùng định nghĩa) Các ontology OWLđược load vào bộ suy diễn sau một bước xác minh lớp và repair ontology Bước này đểchắc rằng tất cả các tài nguyên để có một bộ ba triple phù hợp còn các khai báo thiếu kiểu

sẽ được thêm vào một danh sách bằng cách sử dụng một vài luật heuristic Trong quátrình load các axiom về các class (subclass, các class tương đương hay các disjoint axiom– các khái niệm phân biệt nhau) được đưa vào thành phần TBox và các thông tin vềindividual (kiểu và các thông tin thuộc tính) được lưu trữ trong thành phần Abox Cácaxiom TBox được đưa qua một bộ tiền xử lý chuẩn trước khi được đưa vào bộ suy diễnhoạt cảnh (tableaux reasoner).

Hình 8: Kiến trúc Pellet

Về bản chất bộ suy diễn hoạt cảnh chỉ có duy nhất một chức năng đó là kiểm tra sựthỏa mãn của một ABox đối với một TBox Tất cả các tác vụ suy diễn khác đều có thểđưa về kiểm tra tính nhất quán tri thức cơ sở bằng một chuyển đổi thích hợp Giao diệnlập trình hệ thống SPI (System Programming Interface) của Pellet cung cấp một chứcnăng tổng quát để quản lý các chuyển đổi như vậy Giao diện tri thức này cũng như cácthành phần còn lại đều được xây dựng dựa trên thư viện ATerm ATerm (viết tắt củaAnnotated Term) là một kiểu dữ liệu trừu tượng được thiết kế cho trao đổi của cây dữliệu cấu trúc giữa các ứng dụng phân tán Thư viện ATerm cung cấp các khái niệm choviệc chia sẻ và tự động thu gom rác giúp cho việc giảm bớt không gian bộ nhớ sử dụng

3 Eclipse Plugin Framework

Eclipse là phần mềm miễn phí, được các nhà phát triển sử dụng để xây dựng nhữngứng dụng J2EE, sử dụng Eclipse nhà phát triển có thể tích hợp với nhiều công cụ hỗ trợkhác để có được một bộ công cụ hòan chỉnh mà không cần dùng đến phần mềm riêng nàokhác Eclipse SDK bao gồm 3 phần chính: Platform, Java Development Toolkit (JDT),Plug-in Development environment (PDE) Eclipse được xem như là một môi trường hỗtrợ phát triển Java mạnh mẽ PDE hỗ trợ việc mở rộng Eclipse, tích hợp các Plug-in vàoEclipse Platform Eclipse Platform là nền tảng của toàn bộ phần mềm Eclipse, mục đíchcủa nó là cung cấp những dịch vụ cần thiết cho việc tích hợp những bộ công cụ phát triểnphần mềm khách dưới dạng Plug-in, bản thân JDT cũng có thể được coi như là một Plug-in

Hình 9: Các thành phần trong Eclipse SDK

3.1 Eclipse Plugin

Eclipse framework có thể được add thêm số plugin tùy thích, các plugin này có thể làmột môi trường đầy đủ, một ứng dụng riêng biệt hay chỉ là một cửa sổ thêm vào mộtplugin có sẵn Có những nguyên tắc nghiêm ngặt trong việc viết plugin thông qua mộtAPI đảm bảo sự đồng bộ giữa các ứng dụng nhưng nó cũng cung cấp rất nhiều trợ giúptrong việc tạo ra các form wizard, template, menu và các ví dụ mẫu

Dưới đây là kiến trúc của Eclipse plugin, Eclipse platform có một hạt nhân nhỏ Ngoại trừ hạt nhân này, mọi thứ đều là plugin Mỗi một plugin đều được load bởi một hạt nhân nhỏ như vậy

Hình 10: Kiến trúc Eclipse plugin

Nhờ có kiến trúc plugin này mà các nhà phát triển có thể mở rộng Eclipse bằng cáchviết các viết các phần mở rộng (extension) cho các điểm mở rộng (extension points) đượcđịnh nghĩa từ trước

Nền tảng Eclipse có trách nhiệm:

 Khởi động và chạy platform

 Khai báo và quản lý các plugin

 Quản lý nguồn tài nguyên

Nền tảng Eclipse là chung và đối xử với tất cả các plugin giống nhau Nó không biếtbất cứ thông tin gì về một miền thông tin cụ thể nào và có thể chạy hoặc không trên GUI.Giao diện người dùng của Eclipse định nghĩa các khối giao diện người dùng Nó đượcchia ra làm 3 nhóm là workbench, JFace, và SWT Từ quan điểm của người dùng, mộtworkbench là cửa sổ chính của Eclipse Nó bao gồm các views, toolbars, menu bars, vàcác bộ editors Mục đích của workbench là tạo điều kiện cho việc tích hợp các công cụ.

Những công cụ này sử dụng các điểm mở rộng (extension points) để đóng góp vào trong

workbench JFace là một bộ khung giao diện nhỏ cho phép tạo các giao diện người dùngphổ biến JFace được thiết kế để làm việc với SWT, SWT định nghĩa một tập các widgetcho phép tạo dựng nên các công cụ tích hợp đơn giản cho Eclipse

Chú ý rằng không phải toàn bộ plugin đều phải viết bằng Java, chỉ có thành phần giaodiện GUI là phải viết bằng Java mà thôi Do đó, các ứng dụng C hoặc C++ đều có thể sửdụng làm plugin của Eclipse mà không cần phải viết lại toàn bộ code Tất cả các ứngdụng này đều có thể chạy trên cùng một môi trường là Eclipse

3.2 AST Parser

AST (Abstract Syntax Tree) có thể được so sánh với mô hình cây DOM của một fileXML Giống như DOM, AST cho phép ta chỉnh sửa mô hình cây và ánh xạ những thayđổi vào source code

Java Model biểu diễn một project Java thành dưới dạng một cấu trúc cây như sau:

Hình 11: Cấu trúc dạng cây một project Java

Các node trong Java Model cài đặt một trong các interface sau:

 IJavaProject: là node mô tả một Java Project Nó bao gồm các IPackageFragmentRoots là các node con.

 IPackageFragmentRoot: có thể là source hoặc là thư mục class của một project,

file zip, jar IPackageFragmentRoot có thể chứa source hoặc file binary.

 IPackageFragment: một package đơn giản, nó bao gồm các ICompilationUnits

hoặc IClassFiles, phụ thuộc vào liệu IPackageFragmentRoot là kiểu source hay

kiểu binary Chú ý rằng IPackageFragment không được tổ chức theo kiểu con Ví dụ net.sf.a không phải là cha của net.sf.a.b Chúng là hai con hoàn toàn độc lập nhau của cùng một IPackageFragmentRoot.

cha- ICompilationUnit: một file source Java

 IImportDeclaration, IType, IField, IInitializer, IMethod: là con của ICompilationUnit

 Tìm kiếm node AST

Một chương trình “Hello world” đơn giản cũng sinh ra một cây khá phức tạp Vậy đểtìm được lời gọi hàm println("Hello World")trong chương trình thì phải làm thế nào?

Ta có thể scan qua tất cả các level trên cây, nhưng điều này thực sự không tiện lợi vì nómất nhiều thời gian

Có một giải pháp tốt hơn đó là cho phép truy vấn một node bằng cách sử dụng một bộviếng thăm visitor Mọi lớp con của lớp ASTNode đều có hai method đó là visit() vàendVisit() Thêm vào đó, lớp ASTVisistor khai báo hai method là preVisist(ASTNodenode) và postVisist(ASTNode node)

Mọi node AST sẽ được truyền vào lớp con của lớp ASTVisitor AST sẽ từng bước đệquy viếng thăm qua cây gọi các method của bộ viếng thăm cho từng AST node theo thứ

CHƯƠNG IV: PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN WEB NGỮ NGHĨA

Thông qua các khái niệm và quy trình bảo trì phần mềm cũng như qua phân tích hiệntrạng của bảo trì phần mềm ở các chương trước ta đã thấy được vai trò của việc áp dụngontology trong việc hỗ trợ bảo trì phần mềm Việc áp dụng ontology trong bảo trì phầnmềm sẽ giúp giảm chi phí về mặt thời gian bảo trì cũng như nâng cao hiệu quả của cáctác vụ trong bảo trì phần mềm

Đối với các công ty về công nghệ thông tin thì các công việc bảo trì phần mềm là việckhông thể tránh khỏi, không những thế đó còn là một trong những công việc thườngxuyên phải thực hiện Do đó, nếu như có một công cụ cho phép thực hiện giảm thiểu thờigian bảo trì cũng như tăng hiệu quả bảo trì thì sẽ giúp giảm đi được rất nhiều chi phí nhất

là khi các công cụ được tích hợp vào ngay trong môi trường IDE phát triển phần mềm

1 Hướng tiếp cận của hệ thống

Hình 12 mô tả hướng tiếp cận tổng quan của hệ thống sử dụng ontology trong bảo trì phần mềm [1][2][4]

Hình 12: Hướng tiếp cận tổng quan của hệ thống

Hệ thống cho phép tạo và quản lý các thông tin ngữ nghĩa được sinh ra tự động hoặcthủ công từ các thành phần artifact (source code, document) của hệ thống Các thông tinngữ nghĩa đó gọi là semantic metadata Việc sử dụng và sửa đổi các thông tin ngữ nghĩanày sẽ được thực hiện bởi SemanticSMPlugin, kết quả thu được sẽ được đưa ra cho ngườibảo trì

Quá trình bảo trì có thể được thực hiện bởi nhiều người bảo trì khác nhau Tri thức dotừng người tạo ra có thể được chia sẻ cho những người bảo trì khác Để thực hiện đượcđiều này thì hệ thống được thiết kế với kiến trúc tổng quan như sau:

Hình 13: Kiến trúc tổng quan của hệ thống

Các tri thức ngữ nghĩa sinh ra được sử dụng theo hai hướng Trong hướng thứ nhất,metadata cùng với tài nguyên tương ứng được submit lên server thông qua một webservice, trở thành kho tri thức chung, là nguồn dữ liệu cho các hoạt động bảo trì và tái sửdụng phần mềm Theo hướng thứ hai, các metadata không được submit lên server, màđược lưu lại ở client, để hỗ trợ cho các hoạt động cục bộ Nói theo cách khác, hệ thống cóthể hoạt động hoàn toàn độc lập ở client, hoặc dưới hỗ trợ của các dịch vụ từ service, cácclient có thể phối hợp, cùng hoạt động trên một nguồn dữ liệu chung Vai trò của Servertrong kiến trúc này đó là lưu trữ và quản lý các Sementic Metadata và các artifact của cácthành viên trong bộ phận bảo trì Nó làm nhiệm vụ trung gian cho phép chia sẻ các trithức ngữ nghĩa giữa các thành viên với nhau

Hệ thống trợ giúp bảo trì phần mềm này là một phần của dự án hợp tác giữa bộ mônCông Nghệ Phần Mềm với công ty Mitani năm 2009, hệ thống đó có tên là “Ứng dụngSemantic Web trong tái sử dụng và bảo trì phần mềm” Hiện tại hệ thống còn đang tronggiai đoạn phát triển và nhiệm vụ của em trong dự án này là xây dựng cơ chế tạoannotation và sử dụng các annotation này trong vấn đề bảo trì phần mềm

Do khối lượng công việc trong dự án Mitani2009 khá lớn nên trong đồ án này em mớithực hiện được phần bên phía client bao gồm các chức năng chính của hệ thống còn cácchức năng liên quan tới Web Service sẽ được phát triển sau này

Theo mô hình giải pháp này, có thể thấy hai vấn đề cốt lõi của bài toán cần được giảiquyết đó là:

 Tạo ra một cách tự động và thủ công các annotation từ các thành phần artifact của

hệ thống

 Khai thác, suy diễn và truy vấn các annotation đó để áp dụng vào bảo trì phầnmềm Việc khai thác này sẽ được thể hiện trên các tính năng cài đặt mà các hệthống khác không có được

Trước khi tạo ra được các annotation để sử dụng thì ta cần phải xây dựng Ontologycho hệ thống Hệ thống bao gồm hai artifact đó là source code và document, do đó tacũng xây dựng hai ontology tương ứng với hai artifact trên đó là source code ontology vàdocument ontology Hai ontology này phải được thiết kế để có thể liên kết với nhau nhằmphục vụ cho công việc tạo link giữa hai thành phần artifact Quá trình thiết kế haiontology sẽ được mô tả ngay trong phần tiếp theo

2 Thiết kế Ontology

Như đã trình bày ở trên thì quy trình xây dựng ontology gồm có 7 bước, các bước nàyđược áp dụng cho việc xây dựng Ontology SourceCode và Ontology Document như sau:

2.1 Thiết kế Source Code Ontology

Bước 1: Xác định lĩnh vực và phạm vi của ontology

Để xác định lĩnh vực và phạm vi của Ontology ta cần trả lời một số câu hỏi cơ bản:

1 Lĩnh vực mà Ontology sẽ phải bao trùm là gì: Trong bài toán quản trị tri thức vềSource Code, lĩnh vực mà ontology sẽ phải bao trùm được là các tri thức trong mộtphần mềm bao gồm câc yêu cầu phần mềm, các lớp trong Source Code, các class,các method, các kiểu dữ liệu, các biến, các tài liệu kiểm thử…

2 Chúng ta sẽ sử dụng các ontology cho cái gì: Ontology Source Code được sử dụng

để bảo trì phần mềm do đó nó cần bao hàm các thông tin về phần mềm, các tài liệubảo trì, các yêu cầu bảo trì…

3 Các thông tin trong Ontology phải trả lời được những câu hỏi nào?

- Các thông tin về phần mềm hiện tại như các độ đo, số lượng class trong SourceCode

- Các thông tin về kiến trúc hiện tại của phần mềm như số module/layer, số classtrong mỗi layer, sự gọi lẫn nhau giữa các layer

- Các thông tin về các bản Test trước đó

- Các thông tin về tài liệu liên quan tới một thành phần Source Code như thôngtin về tài liệu liên quan tới thuật toán của một method hay class

- …

4 Ai sẽ là người sử dụng và bảo trì Ontology: Ontology được sử dụng bởi người lập