PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN CÔNG NGHỆ ONTOLOGY

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH CHƯƠNG TRÌNH ĐÀO TẠO THẠC SĨ CNTT QUA MẠNG CHUYÊN ĐỀ BIỂU DIỄN TRI THỨC VÀ ỨNG DỤNG BÁO CÁO PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN CÔNG NGHỆ ONTOLOGY Giảng viên hướng dẫn: PGS.TS. ĐỖ VĂN NHƠN Học viên thực hiện: VŨ VĂN VIỆT (CH1101058) tháng 12 năm 2012 GIỚI THIỆU 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ần mề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ăng dẫ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 ontology để 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ụng cho 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. 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ện trạng của bảo trì phần mềm ta đã thấy được vai trò của việc áp dụng ontology trong việc hỗ trợ bảo trì phần mềm. Việc áp dụng ontology trong bảo trì phần mề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ác tá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ệc không thể tránh khỏi, không những thế đó còn là một trong những công việc thường xuyê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ời gian 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à 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. MỤC LỤC MỤC LỤC 3 CHƯƠNG I: PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN CÔNG NGHỆ ONTOLOGY 4    1.1. Tự động tạo annotaon từ source code 4 1.2. Tự động tạo annotaon từ document và tạo link với source code 7    1.3. Mục đích hệ thống 8 1.4. Phạm vi hệ thống 9  !  " #$%  & '()*+   ' (,,-,.   1.5. Thiết kế Source Code Ontology 14 1.6. Thiết kế Document Ontology 22 /(-  '& 0(1  ' 1.7. Thiết kế Perspecve 32 1.8. Thiết kế các giao diện 32 CHƯƠNG II: XÂY DỰNG HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN ONTOLOGY 33 23.!4$!  '' 1.9. Công cụ và môi trường phát triển 33 1.10. Một số vấn đề về lập trình 33 &56789:;<:=>?@A8BC6DEDF6G:DHI@B:J:IKJ'' &L88M6:DI:A:N6H8>6:J8BI67?@A8BC6D8O;<67HN6DPJ8>K>8>' &'Q>;RNI68ISI7TUDNHI@B:J:IKJ:=>DV8D967WX8D>T;RN'/ CHƯƠNG III: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 36 (Y+Z[  '0 1.11. Về mặt lý thuyết 36 1.12. Về mặt chương trình 36 ##(Y+Z  '0 1.13. Về mặt lí thuyết 36 1.14. Về mặt chương trình 36 1.15. Một số hạn chế 37 #)\  '] TÀI LIỆU THAM KHẢO 38 CHƯƠNG I: PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN CÔNG NGHỆ ONTOLOGY 1. Hướng tiếp cận của hệ thống Hình 1: Tổng quan về bảo trì phần mềm dựa trên ontology Hai bước chính trong việc áp dụng ontology vào trong bảo trì phần mềm đó là:  Tạo ra một cách tự động các annotation từ các thành phần artifact của hệ thống (source code và document)  Khai thác, suy diễn và truy vấn các annotation đó để áp dụng vào bảo trì phần mềm Bước thứ hai sẽ được đề cập chi tiết hơn ở các phần sau của đồ án còn bây giờ em sẽ đề cập chi tiết tới quá trình tự động sinh các annotation từ các artifact của hệ thống 1.1. Tự động tạo annotation từ source code Quá trình sinh tự động annotation từ source code dựa trên JDT, đó là một bộ phân tích Java do Eclipse cung cấp. JDT đọc source code và thực hiện việc phân tích cú pháp và thực hiện tách từ để thu được cây cú pháp trừu tượng AST. Dựa trên cây phân cấp này ta áp dụng các mapping với các khái niệm tương ứng trong ontology source code. Sau khi mapping xong ta sẽ thu được các instance và relation để tạo ra file OWL phù hợp. Hình 4 là mô hình sinh tự động annotation từ source code. Có hai kiểu mapping đó là mapping các instance và mapping các relation giữa các instance với nhau:  Mapping instances: Định nghĩa các mối quan hệ giữa node trong cây AST với một khái niệm trong ontology Ví dụ như ta định nghĩa như sau: MethodDeclaration MethodInnovation Hình 2: Mapping instances  Điều đó có nghĩa rằng khi ta gặp các lời định nghĩa method (MethodDeclaration) hay khi gặp các lời gọi hàm (MethodInnovation) thì ta sẽ mapping các method đó với khái niệm Method trong Ontology. Nghĩa là sẽ tạo ra một instance của lớp Method để mô tả cho method gặp trong source code.  Mapping relations: dựa trên mối quan hệ giữa các khái niệm trong ontology và mối quan hệ giữa các node trong cây AST để tạo ra các relations. Ví dụ ta định nghĩa như sau: TypeDeclaration Class MethodDeclaration Method Hình 3: Mapping relations  Điều đó có nghĩa là khi ta gặp được một lời định nghĩa một hàm MethodDeclaration là con của con của một lời định nghĩa lớp TypeDeclaration trên cây AST trong source code thì ta sẽ mapping mối quan hệ cha-con đó thành mối quan hệ Class – hasMethod – Method trong ontology. Số instances và relations được tạo ra phụ thuộc vào độ phức tạp của ontology source code và kích thước của source code. Ngoài ra còn có một yếu tố khác cũng ảnh hưởng đến số lượng relation nữa đó là số lượng lỗi cú pháp của source code. Việc source code bị lỗi không gây ra lỗi phân tích tuy nhiên nó sẽ làm giảm đi số lượng relation, lỗi càng nhiều thì relation giữa các instance càng ít. Lý do đơn giản là vì khi Method hasChild hasMethod code bị lỗi hệ thống sẽ không thể tạo ra được mối quan hệ tham chiếu lẫn nhau giữa các thành phần source code, do đó sẽ không thể mapping với ontology để tạo relation được. Hình 4: Sinh annotation từ source code Lấy một ví dụ minh họa đơn giản: ta có một class tên là class1, class này có hai phương thức getData và setData, sau khi phân tích ta sẽ thu được các instance và quan hệ như hình vẽ Hình 5: Ví dụ về tạo annotation từ source code Sau quá trình phân tích trên, các instance và relation sẽ được ghi ra file .owl để sử tránh phân tích lại khi mở lại ứng dụng. Một phần file owl sau sẽ mô tả lại quan hệ của một class với các thành phần khác trong source code: <sec0.2:Class rdf:about="http://hut.ontology/sec#package1.Class1"> <sec0.2:hasMethod rdf:resource="http://hut.ontology/sec#package1.Class1/method2()"/> <sec0.2:hasMethod> <sec0.2:Method rdf:about="http://hut.ontology/sec#package1.Class1/method1()"> <sec0.2:packageMemberOf> <sec0.2:Package rdf:about="http://hut.ontology/sec#package1"> <sec0.2:hasDescriptionInElement> <j.0:DocumentElement rdf:about= "http://www.hut.edu.vn/ontology/document#Document_for_package 1"> <j.0:definedIn rdf:resource= "http://www.hut.edu.vn/ontology/document#Milestone-1.pdf"/> <j.0:startPage rdf:datatype= "xsd:nonNegativeInteger">4 </j.0:startPage> </j.0:DocumentElement> </sec0.2:hasDescriptionInElement> </sec0.2:Package> </sec0.2:packageMemberOf> <sec0.2:hasSource> <sec0.2:SourceFile rdf:about= "http://hut.ontology/sec#/project1/src/package1/Class1.java"> <sec0.2:fileName>Class1.java</sec0.2:fileName> <sec0.2:fullPath>/project1/src/package1/Class1.java</sec0.2:fullPath> </sec0.2:SourceFile> </sec0.2:hasSource> <sec0.2:hasVariable> <sec0.2:Variable rdf:about= "http://hut.ontology/sec#package1.Class1/method1()/b"> <rdfs:label xml:lang="en">b</rdfs:label> <sec0.2:hasDirectType>Variable</sec0.2:hasDirectType> </sec0.2:Variable> </sec0.2:hasVariable> </sec0.2:Method> </sec0.2:hasMethod> <sec0.2:packageMemberOf rdf:resource="http://hut.ontology/sec#package1"/> </sec0.2:Class> 1.2. Tự động tạo annotation từ document và tạo link với source code Tài liệu ở đây là các tài liệu liên quan tới phần mềm. Trong Hình 6, các tài liệu này sẽ được đưa qua một bộ trích xuất văn bản để thu được các title, section, paragraph trong tài liệu. Các thông tin này sẽ được chuyển thành các annotation theo cách mapping tương tự như đối với quá trình mapping trong phân tích source code. Sau đó các annotation này sẽ được kết hợp với annotation source code nhờ một bộ sinh liên kết ngữ nghĩa giữa source code và document. Hình 6: Sinh annotation từ document và link với annotation của source code Lấy một ví dụ minh họa đơn giản được thể hiện trên hình vẽ sau: Hình 7: Ví dụ việc tạo annotation từ document 2. Mục đích và phạm vi của hệ thống 1.3. Mục đích hệ thống Mục đích chung nhất của hệ thống trước hết đó là sử dụng các tài nguyên sẵn có từ trước của hệ thống cũ như các tài liệu phân tích yêu cầu, các tài liệu hướng dẫn sử dụng, các tài liệu về API hệ thống, mã nguồn hệ thống, để trợ giúp cho người bảo trì trong quá trình thực hiện bảo trì phần mềm. Tiếp theo hệ thống cần phải tối hiểu hóa các công việc nhập liệu của người dùng, tránh nhập quá nhiều thông tin để có thể sử dụng được hệ thống vì nếu không việc nhập thông tin cũng gây ra tốn kém rất nhiều về mặt thời gian đối với người sử dụng. Các thông tin tri thức của hệ thống phải được lưu trữ dưới dạng ngôn ngữ ontology để có thể suy diễn ra các thông tin mới sau này. Hệ thống cần phải hỗ trợ các tác vụ chính của công việc bảo trì bao gồm hỗ trợ đọc hiểu code, hỗ trợ tìm kiếm tài liệu liên quan tới code, liên quan tới một yêu cầu nào đó. Đồng thời hệ thống cũng cần phải trợ giúp người dùng trong công việc sáng tạo, chia sẻ, và tìm kiếm tri thức. 1.4. Phạm vi hệ thống Hệ thống là một ứng dụng được chạy trên nền môi trường phát triển Eclipse IDE dưới dạng một Plugin. Hiện tại hệ thống chỉ tập chung hỗ trợ cho việc bảo trì các dự án được viết bằng ngôn ngữ Java. Môi trường phát triển Eclipse chính là một môi trường phát triển được các nhà phát triển dự án viết bằng Java sử dụng nhiều nhất. Hiện tại hệ thống hỗ trợ tất cả các phiên bản Eclipse từ 3.2 trở lên cũng như hỗ trợ các môi trường được phát triển nên từ Eclipse như MyEclipse. Với hệ thống này yêu cầu phải làm việc với các tài liệu của hệ thống, ví dụ như các tài liệu liên quan tới yêu cầu phần mềm, tài liệu sử dụng Các tài liệu này có thể ở các định dạng khác nhau như .pdf, .doc hay .html. Trong đồ án này em chỉ thực hiện việc hỗ trợ với các tài liệu có định dạng .pdf vì một số lý do sau. Thứ nhất, ta có thể dễ dàng thực hiện việc chuyển đổi các tài liệu định dạng khác sang định dạng .pdf bằng các công cụ chuyển đổi định dạng miễn phí. Thứ hai, có rất nhiều kiểu kiểu định dạng tài liệu khác nhau nên không thể tạo ra từng công cụ để làm việc với từng kiểu định dạng một được. Cho dù ta có tạo ra các công cụ sử dụng cho từng định dạng đi chăng nữa thì kết quả là các công cụ đó cũng không giúp ích được gì hơn so với việc chỉ sử dụng một công cụ làm việc với định dạng .pdf 1. Những người sử dụng hệ thống Những người sử dụng hệ thống có thể là người trong bộ phận bảo trì phần mềm hoặc những người thiết kế hệ thống. Nói chung những người có liên quan tới tài liệu dự án hay liên quan tới source code hệ thống đều có thể sử dụng để trợ giúp cho công việc của mình. Hình 8: Những người sử dụng hệ thống Người test hệ thống: là người thực hiện việc kiểm tra các test của hệ thống, kiểm tra xem có những test nào đã được thực hiện, các class nào đã được test, kết quả test như thế nào Hệ thống này còn trợ giúp cho chúng ta đưa ra các metric về source code của hệ thống để người test có thể phân tích ra nên tập trung test vào phần nào. Người lập trình: là người thường xuyên phải đọc hiểu code, đây là người thường xuyên sử dụng chức năng trợ giúp đọc hiểu code của hệ thống. Để đọc hiểu code tốt người lập trình cũng có thể sử dụng chức năng truy vết link giữa source code và các tài liệu liên quan tới source code. Người phân tích và thiết kế hệ thống: người này có thể sử dụng chức năng kiểm tra kiến trúc hệ thống xem hệ thống có được cài đặt đúng như đã thiết kế hay không. Các cài đặt không đúng như theo thiết kế sẽ được liệt kê ra để hệ thống có thể xem xét chỉnh sửa lại. Người phân tích yêu cầu hệ thống: là người thực hiện việc kiểm tra các yêu cầu về hệ thống đã được test hay chưa, các yêu cầu nào của hệ thống đã được thực hiện, những yêu cầu nào chưa được cài đặt hay kết quả cài đặt như thế nào. 2. Các chức năng chính của hệ thống Biểu đồ Use Case tổng quát của hệ thống như sau: [...]... niệm bảo trì phần mềm và các hoạt động trong quy trình bảo trì phần mềm  Hiểu được các vấn đề khó khăn trong quá trình bảo trì phần mềm từ đó đưa ra các giải pháp khắc phục  Nắm bắt được công nghệ Ontology và các bước xây dựng một ứng dụng dựa trên Ontology  Nghiên cứu và sử dụng hiệu quả thư viện Pellet cho việc truy vấn ontology  Hiểu được việc áp dụng Ontology vào trong quy trình bảo trì phần mềm, ... liên quan tới việc hiển thị cây phân 18 CompositePropertyBrowser cấp class trong ontology Class được thiết kế cho việc tái sử dụng, tất cả các view có liên quan tới việc hiển thị cây phân cấp property trong ontology 6 Thiết kế màn hình 1.7 Thiết kế Perspective 1.8 Thiết kế các giao diện CHƯƠNG II: XÂY DỰNG HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN ONTOLOGY 1 Xây dựng ứng dụng 1.9 Công cụ và môi trường phát triển... B File source A được phân tích ngay từ đầu quá trình phân tích source code Do khi mới bắt đầu phân tích, số lượng các relation, instance có trong ontology là không lớn lên việc tìm kiếm và tạo instance trong quá trình phân tích file A là nhỏ Sau đó giả sử hệ thống phân tích tiếp 200 file source code khác rồi mới phân tích đến file B Kết quả là khi phân tích file B, dữ liệu trong ontology đã lớn, do... cùng Việc phân nhỏ project ra để phân tích sẽ giúp cho ontology trong quá trình phân tích không quá lớn, từ đó giảm thời gian phân tích một file java và do đó giảm thời gian phân tích toàn bộ source code của hệ thống Hình 14: Mô hình làm tăng tốc độ phân tích source code 1.10.2.Đặt tên cho các instance trong quá trình tự động sinh metadata Trong ontology mỗi một instance phân biệt phải có một id khác... 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ệu bả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. .. của hệ thống được chia thành 3 tầng như sau: Hình 10: Kiến trúc hệ thống Tầng 1: Tầng dữ liệu Đây là tầng rất quan trọng trong hệ thống, nó bao gồm các dữ liệu liên quan tới toàn bộ ứng dụng Các dữ liệu cần thiết của hệ thống bao gồm các dữ liệu sau: • Hai ontology là Source Code ontology và Document ontology Hai ontology được liên kết với nhau thông qua các relation được định nghĩa trong các ontology. .. instance trong quá trình phân tích file B sẽ lớn hơn nhiều so với thời gian phân tích file B Để giải quyết vấn đề này em đã thực hiện như sau:  Khi phân tích một package, ta sẽ tạo ra một bộ load ontology Với mỗi một class trong package này ta sẽ thực hiện việc phân tích, tạo instance, relation trên bộ load ontology này Sau khi phân tích xong package sẽ lưu lại các instance, relation trong ontology hiện... người sử dụng và bảo trì Ontology: Ontology được sử dụng bởi người lập trình – người bảo trì phần mềm, đây là người có kiến thức chuyên môn về phần mềm nên có thể hiểu và sử dụng được các concept trong Ontology Các thông tin về Ontology đều được public đối với người sử dụng, không có concept hay thuộc tính nào là cần phải hạn chế quyền sử dụng Bước 2: Xem xét việc sử dụng lại các ontology đã có Như... năng tái sử dụng các ontology đã có và phục vụ tốt cho việc mô hình hóa các tri thức trong lĩnh vực và phạm vi đó, ở đây ta sẽ sử dụng lại Ontology SEC (Software Engineering concept) Ontology này mô tả mối quan hệ giữa các thành phần phần mềm hướng đối tượng như các test, các độ đo, các yêu cầu phần mềm và nhiều thành phần phần mềm khác Đây là các khái niệm chung cho các ngôn ngữ lập trình hướng đối tượng... trên các công cụ và môi trường phát triển sau: • Môi trường phát triển: Window XP Professional • IDE tích hợp plugin: Eclipse 3.3 trở lên • Java Framework: 1.5 • Công cụ suy diễn ontology: Pellet • Ontology: OWL DL • JGraph 1.5 • JPedal 1.0 1.10 Một số vấn đề về lập trình Trong quá trình lập trình em đã gặp phải một số vấn đề sau: 1.10.1.Tăng tốc độ của quá trình phân tích source code Đối với một phần . THAM KHẢO 38 CHƯƠNG I: PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN CÔNG NGHỆ ONTOLOGY 1. Hướng tiếp cận của hệ thống Hình 1: Tổng quan về bảo trì phần mềm dựa trên ontology Hai bước chính. và quy trình bảo trì phần mềm cũng như qua phân tích hiện trạng của bảo trì phần mềm ta đã thấy được vai trò của việc áp dụng ontology trong việc hỗ trợ bảo trì phần mềm. Việc áp dụng ontology. PHỐ HỒ CHÍ MINH CHƯƠNG TRÌNH ĐÀO TẠO THẠC SĨ CNTT QUA MẠNG CHUYÊN ĐỀ BIỂU DIỄN TRI THỨC VÀ ỨNG DỤNG BÁO CÁO PHÂN TÍCH THIẾT KẾ HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN CÔNG NGHỆ ONTOLOGY Giảng viên hướng