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="ology/sec#package1.Class1">
<sec0.2:hasMethod
rdf:resource="ology/sec#package1.Class1/method2()"/>
<sec0.2:hasMethod>
<sec0.2:Method
rdf:about="ology/sec#package1.Class1/method1()">
<sec0.2:packageMemberOf>
<sec0.2:Package rdf:about="ology/sec#package1">
<sec0.2:hasDescriptionInElement>
<j.0:DocumentElement rdf:about=
" />1">
<j.0:definedIn rdf:resource=
" /> <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=
"ology/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=
"ology/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="ology/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:
Hình 9: Use Case tổng quát của hệ thống
Dựa trên biểu đồ ta có thể thấy được hệ thống có 12 chức năng chính, chi tiết các
chức năng của hệ thống như sau:
 Tạo chú thích cho code và document: đây là các quá trình sinh tự động ngữ
nghĩa cho source code và cho document.
 Tạo liên kết mã nguồn và tài liệu: cho phép người dùng định nghĩa mối liên kết
giữa mã nguồn và tài liệu.
 Tạo Test: cho phép người dùng định nghĩa một Test và các thông tin ngữ nghĩa
liên quan tới Test đó như Test đó là test của method nào, test đó được cài đặt
trong class hay method nào.
 Tạo chú thích nâng cao: Việc tạo chú thích nâng cao này thường ít được sử
dụng vì hệ thống đã có các công cụ tạo chú thích ngữ nghĩa tự động. Các chú
thích nâng cao được tạo ra là các chú thích mà không thể tạo ra một cách tự
động được như việc định nghĩa ý nghĩa sử dụng của một method.
 Tìm kiếm tài liệu: use case này nhằm mục đích giúp đỡ cho người dùng tìm

kiếm ngữ nghĩa các tài liệu liên quan tới source code. Ví dụ tìm kiếm các tài
liệu mô tả cách sử dụng của một method hay field.
 Tìm kiếm Test: cho phép tìm kiếm ngữ nghĩa các test
 Tìm kiếm tài nguyên: đây là công cụ tìm kiếm nâng cao có thể dùng cho mọi
trường hợp tìm kiếm ngữ nghĩa. Nó được xây dựng để thay thế cho công cụ tìm
kiếm mặc định của Eclipse
 Phân tích kiến trúc hệ thống: xây dựng mô hình gọi lẫn nhau giữa các tầng của
ứng dụng, từ đó giúp người dùng đưa ra nhận xét là kiến trúc hệ thống có được
cài đặt theo như thiết kế ban đầu hay không.
 Phát hiện nguy cơ bảo mật: phát hiện một số nguy cơ bảo mật bằng việc thực
hiện các truy vấn ngữ nghĩa.
 Phân tích quan hệ giữa các thành phần code: cho phép người dũng xem xét mối
quan hệ phụ thuộc giữa các thành phần code với nhau
 Cập nhật liên kết giữa các artifact: cảnh báo cho người dùng thay đổi tài liệu
khi source code bị thay đổi
 Cây phân cấp gọi hàm: trợ giúp người dùng đọc hiểu code nhanh hơn
3. Kiến trúc chung của hệ thống
Kiến trúc 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 đó.
• Source code của một dự án phần mềm
• Document: các tài liệu liên quan tới dự án phần mềm đó
Các thành phần dữ liệu này đều có thể thay đổi trong quá trình sử dụng. Đối với
các ontology thì dữ liệu annotations được tạo ra từ hai nguồn
• Thứ nhất, dữ liệu được trích xuất một cách tự động từ các thành phần dữ liệu

khác là Source code và Document.
• Thứ hai, dữ liệu được tạo ra bởi chính người sử dụng, có nhiều kiểu dữ liệu,
liên kết phải do chính người sử dụng định nghĩa ra bởi vì hệ thống không thể tự
động tạo ra được từ các dữ liệu Source code và Document.
Tầng 2: Tầng điều khiển
Tầng điều khiển là tầng trung gian sẽ làm việc với tầng dữ liệu và tầng ứng dụng.
Tầng trung gian có nhiệm vụ trích xuất thông tin từ các dữ liệu ở tầng 1 và sử dụng
các dữ liệu ở tầng 1 để suy diễn ra các thông tin mới hay đơn thuần chỉ là tìm kiếm
thông tin dựa trên các thông tin đã có.
Đây là tầng tương đối phức tạp, nó cần phải được cài đặt một cách tỉ mỉ để không
gây ra các sai xót trong quá trình tự động sinh annotations. Các thông tin được extract
từ tầng dữ liệu sẽ được matching với các khái niệm, relations được định nghĩa trong
ontology để tạo ra các annotation.
Bộ suy diễn được lựa chọn trong tầng này là bộ suy diễn Pellet – đây là bộ suy
diễn có hỗ trợ thực hiện suy diễn đối với dữ liệu OWL. Để thực hiện suy diễn ra nhiều
tri thức mới thì hệ thống cần phải có thêm các luật được định nghĩa trước đó. Các
thông tin tìm kiếm được ở tầng này sẽ được sử dụng ở trong tầng ứng dụng.
Tầng 3: Tầng ứng dụng
Tầng ứng dụng là tầng cài đặt plugin trên môi trường Eclipse IDE. Các dữ liệu
được lấy từ tầng điều khiển và hiển thị, trình diễn trên tầng ứng dụng.
4. 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:
1.5. 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ột phầ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ệ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 hiện tại như các độ đo, số lượng class trong
Source Code
- 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ố
class trong 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ông tin 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 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ư vậy, tại bước 1 ta đã xác định được rõ lĩnh vực cũng như phạm vi mà
ontology Source Code cần đáp ứng. Tại bước này ta sẽ xem xét khả 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 như Java, C#,…,
chúng được định nghĩa ở mức cao. Ontology này được tổ chức với 15 khái niệm, độ
phân cấp sâu đến cấp 3 với 33 quan hệ.
Hình 11: SEC Ontology
Vì Ontology SEC là một ontology bao gồm các concept chung cho ngôn ngữ lập

trình hướng đối tượng nên em đã sử dụng lại hầu hết các concept của SEC. Tuy nhiên
với ontology SEC trên em mới chỉ thu được các khái niệm trừu tượng và khái quát
nhất cho việc một ontology Source Code mà chưa thể đáp ứng được đầy đủ miền lĩnh
vực mà ontology Source Code cần phải bao trùm, như là thiếu các concept về biến, về
các dự án, về các tài nguyên, về kiểu dữ liệu, về các tầng trong kiến trúc phần mềm…
cũng như thiếu các thuộc tính như thông tin về các độ đo metric, thông tin về các tầng
layer.
Bước 3: Liệt kê các thuật ngữ quan trọng trong Ontology
Các thuật ngữ quan trọng:
- Các thuật ngữ liên quan tới phần mềm: class, method, variable,…
- Các thuật ngữ liên quan tới bảo trì: requirement, test, metric,…
Bước 4 Định nghĩa lớp và phân cấp các lớp
Các hình ảnh về phân cấp class
Cây phân cấp mức cao nhất Chi tiết lớp SoftwareComponent
Chi tiết lớp Type Chi tiết lớp Metric
Bước 5: Định nghĩa các thuộc tính của các lớp và mối quan hệ giữa chúng
Việc định nghĩa các thuộc tính của các lớp mang một ý nghĩa hết sức quan trọng,
nó liên quan tới khả năng suy diễn ngữ nghĩa của ứng dụng. Do đó bước này cần được
phân tích kĩ lưỡng để xác định mối quan hệ giữa các lớp trong ontology. Để thực hiện
bước này em đã tham khảo các tài liệu liên quan tới ngôn ngữ lập trình hướng đối
tượng như BNF (Backus-Naur Form) của các ngôn ngữ lập trình cũng như đề xuất
thêm các thuộc tính khác. BNF cho phép ta hiểu được cấu trúc của một ngôn ngữ lập
trình từ đó giúp ta rút ra được các mối liên hệ giữa các concept trong ontology Source
Code.
Bước 6: Định nghĩa các ràng buộc của các thuộc tính
Định nghĩa các ràng buộc cho các thuộc tính vừa mới tại ra như thuộc tính
numMethods của lớp ClassMetric được gán cho ràng buộc Functional
Tên thuộc tính Ràng buộc Kiểu ràng buộc
contains Inverse of usesInLayer
encodesRequirement Inverse of requirementEncodedBy

entryPointFor Inverse of hasEntryPoint
extendedBy Inverse of extends
numMethods property characteristic Functional
Bước 7: Tạo ra các thể hiện
Bước này ban đầu được thực hiện một cách tự động, người dùng có thể tự tạo ra các
thực thể mới
Kết quả
Danh sách các lớp quan trọng
ST
T
Tên lớp Super Class Ý nghĩa
1 Layer owl:Thing
Mô tả một tầng trong kiến trúc của một
hệ thống
2 Metric owl:Thing Mô tả các thông tin về một độ đo
3 ClassMetric Metric
Mô tả thông tin chi tiết về độ đo của
một class
4 LayerMetric Metric
Mô tả thông tin chi tiết về độ đo của
một layer
5 MethodMetric Metric
Mô tả thông tin chi tiết về độ đo của
một method
6 PackageMetric Metric
Mô tả thông tin chi tiết về độ đo của
một package
7 ProjectMetric Metric
Mô tả thông tin chi tiết về độ đo của
một project

8 Requirement owl:Thing
Mô tả yêu cầu của một hệ thống phần
mềm
9
SoftwareCompo
nent
owl:Thing Mô tả một đối tượng phần mềm
10 Class
SoftwareComponent
Type
Mô tả một lớp trong lập trình hướng đối
tượng
11 Interface
SoftwareComponent
Type
Mô tả một giao diện trong lập trình
hướng đối tượng của ngôn ngữ Java
12 Library SoftwareComponent Mô tả một thư viện (.zip, .jar) trong lập
trình hướng đối tượng của ngôn ngữ
Java
13 Method SoftwareComponent
Mô tả một phương thức trong lập trình
hướng đối tượng
14 Modifier SoftwareComponent
Mô tả các modifier trong lập trình
hướng đối tượng
15 Package SoftwareComponent Mô tả một package trong ngôn ngữ Java
16 Parameter SoftwareComponent
Mô tả một parameter trong lập trình
hướng đối tượng

17 Project SoftwareComponent Mô tả các thông tin về một project
18 SourceFile SoftwareComponent Mô tả một file source code
19 Variable SoftwareComponent Mô tả các thông tin về một biến
20 Workspace SoftwareComponent
Mô tả các thông tin về một không gian
làm việc
21 Test owl:Thing Mô tả chung về một kiểm thử
22 IntegrationTest Test
Mô tả các thông tin về một kiểm thử
tích hợp
23 UnitTest Test
Mô tả các thông tin về một kiểm thử
đơn vị
24 Type owl:Thing Mô tả một kiểu dữ liệu
25 PrimaryType Type
Mô tả các kiểu dữ liệu primary của
ngôn ngữ hướng đối tượng
Danh sách các thuộc tính quan trọng
ST
T
Tên thuộc
tính
Thuộc lớp Kiểu giá trị Ý nghĩa
1 contains Layer
SoftwareCompo
nent
Một layer có thể có nhiều
SoftwareComponent
2
encodesRequi

rement
Class Requirement
Định nghĩa mối quan hệ
giữa Requirement và một
Class mà thực hiện
Requirement đó
3 entryPointFor
Method
Constructor
Methodsignature
Requirement
Định nghĩa method chính để
cài đặt một Requirement
4 extends
SoftwareCompon
ent
SoftwareCompo
nent
Mối quan hệ giữa một lớp
con và một lớp cha mà nó
extend
5 fullPath SourceFile string
Đường dẫn tuyệt đối tới file
code
6
hasDescriptio
nInDocument
Layer
Interface
Class

Method
Requirement
Project
Test
MethodSignature
Package
document:Docu
ment
Xác định rằng một thành
phần của source code có
liên quan tới tài liệu
Document nào
7
hasDescriptio
nInElement
Layer
Interface
Class
Method
Requirement
Project
Test
MethodSignature
Package
document:Docu
mentElement
Xác định một thành phần
source code có liên quan tới
một thành phần trong một
tài liệu nào đó.

8 hasDeveloper
Layer
SoftwareCompon
ent
Requirement
Metric
Test
string
Định nghĩa mối quan hệ
giữa người phát triển và
thành phần được phát triển
9 hasMethod Class Method
Định nghĩa mối quan hệ
giữa một Class và Method
mà được định nghĩa trong
nó
10 hasMetric SoftwareCompon
ent
Metric Định nghĩa một thành phần
phần mềm có một metric
mà tính toán các độ đo của
nó
11 hasProject Workspace Project
Định nghĩa mối quan hệ
giữa Workspace và Project
12 hasTest
SoftwareCompon
ent
Test
Định nghĩa mối quan hệ

giữa Test và component
thực hiện việc test
13
hasTestResult
s
Test string
Mô tả kết quả của một test
dưới dạng một xâu, đoạn
văn bản
14
implementsIn
terface
Class Interface
Định nghĩa rằng một class
có thể cài đặt một hay nhiều
giao diện
15 isMetricOf Metric
SoftwareCompo
nent
Định nghĩa rằng một Metric
là metric của thành phần
phần mềm nào
16 isTestOf Test
SoftwareCompo
nent
Định nghĩa rằng một Test là
test của thành phần phần
mềm nào
17
lastModified

At
Layer
SoftwareCompon
ent
Requirement
Metric
Test
time
Định nghĩa mối quan hệ
giữa một thành phần và thời
gian sửa đổi thành phần đó
18
lastValidated
At
Requirement time
Định nghĩa thời điểm mà
Requirement được xác thực
bởi người nào đó
19 methodOf Method Class
Định nghĩa Method thuộc
về Class nào
20
metricCalcula
tedAt
Metric time
Định nghĩa thời gian mà độ
đo metric được tính toán
21 packageOf Package Library
Project
Xác định mối quan hệ giữa

package và thành phần chứa
nó
22 projectOf Project Workspace
Xác định mối quan hệ giữa
project và workspace chứa
nó
23
requirementE
ncodeBy
Requirement Class
Định nghĩa mối quan hệ
giữa Requirement và Class
thực hiện yêu cầu đó
24 succeeded Test boolean
Thuộc tính xác định xem
một test có thành công hay
không
25 testedAt Test time
Định nghĩa mối quan hệ
giữa Test và thời gian lúc
thực hiện test
26
usedByPacka
ge
Package Package
Định nghĩa mối quan hệ sử
dụng lẫn nhau của các
Package
27 usesClass Class Class
Định nghĩa mối quan hệ sử

dụng lẫn nhau của các Class
28 usesPackage Package Package
Định nghĩa mối quan hệ sử
dụng nhau giữa package và
package
1.6. Thiết kế Document 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ề Document, lĩnh vực mà ontology sẽ phải bao trùm được là các tri thức trong
một tài liệu.
2. Chúng ta sẽ sử dụng các ontology cho cái gì: Ontology Document được sử
dụng để đưa ra các thông tin tham chiếu, tham khảo cho các test, method, class,
requirement…Nghĩa là Document Ontology lưu trữ các thông tin về các tài liệu
liên quan tới source code và khi người dùng muốn tìm kiếm thông tin về thành
phần source code nào thì sẽ có tài liệu thông tin về thành phần đó được đưa ra.
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ề một lớp được định nghĩa trong tài liệu nào, tài liệu đó nằm
ở đâu trong máy hay có thể download từ trên mạng, thông tin đó nằm ở
trang thứ bao nhiêu hay section thứ bao nhiêu.
- Các thông tin về một method như method sử dụng giải thuật nào, nội dung
giải thuật đó ra sao. Các thông tin này cần phải có trong tài liệu.
- Các thông tin về hướng dẫn sử dụng một method nào đó, ý nghĩa của
method đó là gì, dùng trong trường hợp nào
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 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ư vậy, tại bước 1 ta đã xác định được rõ lĩnh vực cũng như phạm vi mà
ontology Document cần đáp ứng. Tại bước này ta sẽ xem xét khả 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 Fragments Ontology. Ontology này mô tả mối
quan hệ giữa các thành phần trong một tài liệu chung chung không phân biệt định
dạng. Ontology này được tổ chức với 79 khái niệm, độ phân cấp sâu đến cấp 4 với
hơn 30 quan hệ.
Lớp cao nhất trong Document Ontology Các khái niệm trong fragment medium
Các khái niệm trong fragment structural
type
Các khái niệm trong fragment
representational type
Hình 12: Fragment Ontology
Fragment Ontology đã đưa ra hầu hết các khái niệm cơ bản trong một tài liệu
document, tuy nhiên với ontology Fragment trên có nhiều khái niệm được xây dựng
quá cụ thể mà không có tính bao quát. Ví dụ như đối với fragment medium người ta
chia nhỏ text format ra thành nhiều loại như có định dạng pdf, doc, rtf, wpd , thay
vào đó ta có thể tạo một thuộc tính extension cho một document, thuộc tính này sẽ
giúp định nghĩa định dạng của tài liệu đó. Hơn thế nữa ontology Fragment còn thiếu
nhiều mối quan hệ quan trọng giữa các thực thể với nhau. Document Ontology đã kế
thừa một số khái niệm và quan hệ của Fragment Ontology đồng thời xây dựng thêm
nhiều khái niệm cũng như quan hệ mới.
Bước 3: Liệt kê các thuật ngữ quan trọng trong Ontology
Các thuật ngữ quan trọng:
- Các thuật ngữ liên quan tới phần mềm: document element, paragraph,
sentence, section,…
- Các thuật ngữ liên quan tới việc truy vết traceability: đó là các thuộc tính
liên kết giữa một class trong Source Code Ontology và Document
Bước 4 Định nghĩa lớp và phân cấp các lớp
Các hình ảnh về phân cấp class

Cây phân cấp mức cao nhất Chi tiết lớp Agent
Chi tiết lớp DocumentElement Chi tiết lớp Document