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

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

ĐẠ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áttriể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ìnhbả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 chomộ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ênontology để 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ạncủ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ểnEclipse 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íchhiệ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 ontologytrong 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ệcthườ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ảmthiể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ấtnhiề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áttriể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 5

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

1.1 Tự động tạo annotation từ source code 5

1.2 Tự động tạo annotation từ document và tạo link với source code 8

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

2.1 Mục đích hệ thống 9

2.2 Phạm vi hệ thống 10

3 NHỮNG NGƯỜI SỬ DỤNG HỆ THỐNG 10

4 CÁC CHỨC NĂNG CHÍNH CỦA HỆ THỐNG 11

5 KIẾN TRÚC CHUNG CỦA HỆ THỐNG 13

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

6.1 Khởi động hệ thống 15

6.2 Tự động tạo chú thích cho tài liệu và mã nguồn 16

6.2.1 Phân tích mã nguồn 17

6.2.2 Phân tích tài liệu 18

6.3 Tìm kiếm tri thức 20

6.3.1 Tìm kiếm Test 20

6.3.2 Tìm kiếm tài liệu 22

6.3.3 Tìm kiếm mã nguồn 24

6.3.4 Tìm kiếm ngữ nghĩa nâng cao 24

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

6.5 Tra cứu các độ đo metric 27

6.6 Tra cứu thứ tự gọi hàm 28

6.7 Quản lý tri thức 30

6.7.1 Tạo các Test 30

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

6.7.3 Tạo chú thích ngữ nghĩa nâng cao 32

7 CÁC BIỂU ĐỒ TRÌNH TỰ 32

8 THIẾT KẾ ONTOLOGY 33

8.1 Thiết kế Source Code Ontology 33

8.2 Thiết kế Document Ontology 41

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

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

10.1 Thiết kế Perspective 51

10.2 Thiết kế các giao diện 51

CHƯƠNG II: XÂY DỰNG HỆ THỐNG BẢO TRÌ PHẦN MỀM DỰA TRÊN ONTOLOGY 52

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

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

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

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

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

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

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

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

1.1 Về mặt lý thuyết 55

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

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

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

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

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

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

TÀI LIỆU THAM KHẢO 57

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ầnmề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ântí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âncấp này ta áp dụng các mapping với các khái niệm tương ứng trong ontology sourcecode Sau khi mapping xong ta sẽ thu được các instance và relation để tạo ra file OWLphù 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ácinstance với nhau:

 Mapping instances: Định nghĩa các mối quan hệ giữa node trong cây AST vớimột khái niệm trong ontology

Ví dụ như ta định nghĩa như sau:

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:

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 ontologysource 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 ảnhhưởng đến số lượng relation nữa đó là số lượng lỗi cú pháp của source code Việcsource 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ượngrelation, 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

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ữacá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:

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, paragraphtrong tài liệu Các thông tin này sẽ được chuyển thành các annotation theo cáchmapping 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ênkế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

2.1 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ảotrì 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ệcnhậ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ợ đọchiể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

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áctà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ệnviệ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 pdfbằ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 địnhdạ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 đichă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ệcchỉ sử dụng một công cụ làm việc với định dạng pdf

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ả testnhư thế nào Hệ thống này còn trợ giúp cho chúng ta đưa ra các metric về sourcecode 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ốtngườ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áctà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étchỉ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

4 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ếtgiữ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ĩaliên quan tới Test đó như Test đó là test của method nào, test đó được cài đặttrong 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ìmkiế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àiliệ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ọitrường hợp tìm kiếm ngữ nghĩa Nó được xây dựng để thay thế cho công cụ tìmkiế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ó đượccà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ựchiệ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ốiquan 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ệukhi 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

5 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ớitoà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ácontology đó

 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ớicá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ệukhá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ụngcá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ếmthô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ônggâ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 trongontology để 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ộ suydiễ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ềutri 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ácthông tin tìm kiếm được ở tầng này sẽ được sử dụng ở trong tầng ứng dụng

6.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ột phần mềm bao gồm câc yêu cầu phần mềm, các lớp trong SourceCode, 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 trongSource 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ườilậ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ácthô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ụngcá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ậptrì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ênvớ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átnhất cho việc một ontology Source Code mà chưa thể đáp ứng được đầy đủ miền lĩnhvự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ầnglayer

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 đượcphân tích kĩ lưỡng để xác định mối quan hệ giữa các lớp trong ontology Để thực hiệnbướ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 đốitượng như BNF (Backus-Naur Form) của các ngôn ngữ lập trình cũng như đề xuấtthê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ậptrình từ đó giúp ta rút ra được các mối liên hệ giữa các concept trong ontology SourceCode

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

encodesRequirement Inverse of requirementEncodedByentryPointFor Inverse of hasEntryPoint

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ácthực thể mới

Kết quả

Danh sách các lớp quan trọng

ST

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

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ữ