Áp dụng đặc tả hình thức vào mô hình đặc tả yêu cầu phần mềm i

Nghiên cứu, phân tích và đánh giá các phương pháp tính toán độ tương tự dựa trên đặc trưng và dựa trên logic khi biểu diễn mục tiêu của mô hình i* dưới dạng biểu diễn logic, cũng như đề

TRƯỜNG ĐẠI HỌC BÁCH KHOA

BÙI CÔNG TUẤN

ÁP DỤNG ĐẶC TẢ HÌNH THỨC VÀO MÔ HÌNH ĐẶC TẢ YÊU CẦU PHẦN MỀM I*

Cán bộ hướng dẫn khoa học :

(Ghi rõ họ, tên, học hàm, học vị và chữ ký) Cán bộ chấm nhận xét 1 :

(Ghi rõ họ, tên, học hàm, học vị và chữ ký) Cán bộ chấm nhận xét 2 :

(Ghi rõ họ, tên, học hàm, học vị và chữ ký) Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày tháng năm

Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm: (Ghi rõ họ, tên, học hàm, học vị của Hội đồng chấm bảo vệ luận văn thạc sĩ) 1

2

3

4

5

Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trưởng Khoa quản lý chuyên ngành sau khi luận văn đã được sửa chữa (nếu có)

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: Bùi Công Tuấn MSHV: 13070273 Ngày, tháng, năm sinh: 28/09/1988 Nơi sinh: TP.HCM

Chuyên ngành: Khoa học máy tính Mã số : 60.48.01

I TÊN ĐỀ TÀI: ÁP DỤNG ĐẶC TẢ HÌNH THỨC VÀO MÔ HÌNH ĐẶC TẢ

YÊU CẦU PHẦN MỀM I*

II NHIỆM VỤ VÀ NỘI DUNG:

- Thực hiện các nội dung đã nêu trong đề cương luận văn thạc sỹ

III NGÀY GIAO NHIỆM VỤ : 11/01/2016

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 19/06/2016

V CÁN BỘ HƯỚNG DẪN : TS Bùi Hoài Thắng

Xin chân thành cảm ơn sự giảng dạy của các thầy cô trong khoa đã giúp đỡ tôi những kiến thức quý báu Đặc biệt, xin chân thành cảm ơn thầy Bùi Hoài Thắng đã hướng dẫn và hỗ trợ cho tôi trong thời gian vừa qua

Cuối cùng, tôi xin cảm ơn gia đình, đồng nghiệp và bạn bè đã động viên, hỗ trợ giúp tôi có thể hoàn thành đề tài luận văn này

TP Hồ Chí Minh, Ngày 20 Tháng 6 Năm 2016

Học viên thực hiện

Bùi Công Tuấn

Ngày nay, ứng dụng công nghệ thông tin vào trong công việc ngày càng nhiều, từ

đó nhu cầu phát triển phần mềm cũng tăng lên Trong giai đoạn đầu của phát triển phần

mềm là giai đoạn phân tích yêu cầu, các yêu cầu về phần mềm cần xây dựng phải được

đặc tả một cách đầy đủ để có thể tiến hành thiết kế và xây dựng phần mềm cho phù hợp

Có nhiều loại ngôn ngữ và mô hình được sử dụng trong giai đoạn này, ngôn ngữ mô hình

i* là một ngôn ngữ mới với hướng mục tiêu rất phù hợp cho việc phân tích yêu cầu cho

giai đoạn đầu Tuy nhiên, các mô hình i* được tạo ra nhiều nhưng phần lớn ít được tái

sử dụng vì chưa có một cách thức lưu trữ thích hợp và phương pháp tìm kiếm các mô

hình đã có sẳn để gợi ý cho người phân tích yêu cầu

Do đó, trong luận văn này đề xuất một kỹ thuật đặc tả hình thức cho mô hình i*

Cụ thể là biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic Nghiên cứu,

phân tích và đánh giá các phương pháp tính toán độ tương tự dựa trên đặc trưng và dựa

trên logic khi biểu diễn mục tiêu của mô hình i* dưới dạng biểu diễn logic, cũng như đề

ra một số phương pháp khác hỗ trợ cho phương pháp tính toán độ tương tự dựa trên đặc

trưng và logic như dùng đồ thị con đẳng cấu Đồng thời, đề xuất một cách thức để xây

dựng một cơ sở dữ liệu để có thể lưu trữ các đặc tả mục tiêu của mô hình i*

Nowadays, the application of information and technology for working is more and more developed, so the software development also needs increase The stage in the early stages of the software development is the requirements analysis stage, the software requirements should be specified fully to be able to carry out the design and construction

of appropriate software There are many kinds of languages and models used in this stage, i* modeling language is a new suitable language with goal-oriented for the requirements analysis in this stage However, i* models are generated a lot but most are not reused because they does not have a suitable storage and strong search method for suggestions in requirements analysis

Therefore, in this paper proposes a formal specification for the i* model Specifically, the goal in i* model is represented via logic expression Research, analyze and evaluate the feature-based and logic-based similarity methods on representation of goals in the model i*, and subgraph isomorphism method for supporting these above methods At the same time, paper proposed a way to build a database to store the goal

specification of the model i*

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như

đã ghi rõ trong luận văn, các công việc trình bày trong luận văn này là do chính tôi thực hiện và chưa có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở trường này hoặc trường khác

Người thực hiện (ký tên)

Bùi Công Tuấn

CHƯƠNG 1: GIỚI THIỆU 1

1.1 Lý do và mục đích nghiên cứu 1

1.2 Mục tiêu và giới hạn luận văn 3

1.3 Cấu trúc của luận văn 4

CHƯƠNG 2: CÁC NGHIÊN CỨU LIÊN QUAN 6

2.1 Ngôn ngữ mô hình i* 6

2.2 Biểu diễn logic của Web Service 7

2.3 Bước chuyển đổi OWL-S sang biểu diễn logic 9

2.4 Độ tương tự của Web Service có ngữ nghĩa dựa trên logic 11

2.4.1 Độ tương tự dựa trên đặc trưng 11

2.4.2 Độ tương tự dựa trên Logic 12

CHƯƠNG 3: CƠ SỞ LÝ THUYẾT 15

3.1 Đặc tả hình thức 15

3.2 Ngôn ngữ mô hình i* (iStar) 17

3.3 Đồ thị con đẳng cấu (Subgraph Isomorphism) 21

CHƯƠNG 4: MÔ HÌNH HÓA BÀI TOÁN 31

4.1 Biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic 31

4.2 Tính độ tương tự dựa trên đặc trưng và logic 35

4.2.1 Ví dụ 1 35

4.2.2 Ví dụ 2 41

4.2.3 Ví dụ 3 43

4.3 Biểu diễn mô hình i* dưới dạng đồ thị 46

4.4 Tìm đồ thị con đẳng cấu 48

4.5 Tính độ tương tự dựa trên logic và dựa trên đồ thị con đẳng cấu 48

CHƯƠNG 5: CASE STUDY 51

5.1 Trạng thái 1 53

5.4 Trạng thái 4 61

5.5 Trạng thái 5 62

CHƯƠNG 6: HIỆN THỰC VÀ THỰC NGHIỆM 66

6.1 Kiến trúc hệ thống 66

6.2 Bộ dữ liệu kiểm thử (Dataset) 68

6.3 Kết quả thực nghiệm 71

6.3.1 Phương pháp tính độ tương tự dựa trên đặc trưng (M1) 72

6.3.2 Phương pháp tính độ tương tự dựa trên logic (M2) 73

6.3.3 Phương pháp dựa trên đồ thị con đẳng cấu (M3) 74

6.3.4 Phương pháp tính độ tương tự dựa trên logic và đồ thị con đẳng cấu (M4) 75 6.3.5 Thống kê thời gian thực thi chung 75

6.3.6 So sánh kết quả gợi ý của 4 phương pháp trên tập DataSet_3 79

CHƯƠNG 7: KẾT LUẬN 83

7.1 Kết quả đạt được 83

7.2 Hướng nghiên cứu tiếp theo 83

DANH MỤC TÀI LIỆU THAM KHẢO 84

PHỤ LỤC 86

Danh sách các loại mô hình, các loại phần tử và liên kết trong mô hình i* 86

LÝ LỊCH TRÍCH NGANG 91

STT Thuật ngữ Tiếng Anh Thuật ngữ Tiếng Việt

2 Strategic Depedency model Mô hình chiến lược phụ thuộc

3 Strategic Reationale model Mô hình chiến lược quan hệ

8 Feature-based similarity Độ tương tự dựa trên đặc trưng

Hình 1.1: Mô phỏng quy trình tiếp cận của của đề tài 4

Hình 2.1: Tổng quan kiến trúc của công cụ Tagoon+ 7

Hình 2.2: Mapping giữa web service và biểu diễn logic 9

Hình 2.3: Mô tả chuyển đổi web service sang mệnh đề logic 10

Hình 3.1: Ảnh chụp giao diện của công cụ SOFL Specification Creator 16

Hình 3.2: Mô hình SD (Travel Reimbursement) 19

Hình 3.3: Mô hình SR (Travel Reimbursement) với tác nhân Student được “opened up” 19

Hình 3.4: Thể hiện mô hình i* dưới chuẩn iStarML với tác nhân Customer as Buyer [Service] cùng các goal, softgoal bên trong 20

Hình 3.5: Đồ thị vô hướng G1 và G2 22

Hình 3.6: G1 và G2 là 2 đồ thị vô hướng đẳng cấu với nhau 23

Hình 3.7: G3 và G4 là 2 đồ thị có hướng không đẳng cấu với nhau 23

Hình 3.8: Ví dụ về đồ thị con đẳng cấu của hai đồ thị G5 và G6 24

Hình 4.1: Mô hình i* của tác nhân “Design Product” được vẽ bằng công cụ OpenOME 33

Hình 4.2: Mapping giữa mô hình i* và biểu diễn logic 35

Hình 4.3: Mô hình i* của tác nhân “Manage product” 36

Hình 4.4: Mô hình i* của tác nhân “Unkown” 36

Hình 4.5: Mô hình G3 sau khi thêm nút “Design process be effective” 42

Hình 4.6: Ba mô hình phân biệt loại nút trong mệnh đề logic 44

Hình 4.7: Chuyển đổi mô hình i* sang dạng đồ thị 47

Hình 4.8: Mô hình i* chuyển đổi dưới dạng đồ thị 47

Hình 5.1: Mô hình i* “Public Transport Service” 51

Hình 5.2: Danh sách 5 mô hình i* đã có trong cơ sở dữ liệu 52

Hình 5.5: Mô hình i* người phân tích vẽ với ba nút 60

Hình 5.6: Mô hình i* người dùng vẽ với bốn nút 61

Hình 5.7: Mô hình i* người dùng vẽ với bốn nút 63

Hình 5.8: Kết quả thực thi ở trạng thái 1 của mô hình G0 với sáu mô hình truy vấn 64

Hình 6.1: Kiến trúc tổng quát của hệ thống 66

Hình 6.2: CSDL lưu trữ các biểu diễn logic, data thô dạng XML và cấu trúc đồ thị 67

Hình 6.3: Cấu trúc chương trình 68

Hình 6.4: Danh sách các file iStarML trong dataset 2 69

Hình 6.5: Công cụ OpenOME với mô hình i* Claims Handling 71

Hình 6.6: Hệ thống báo lỗi các file iStarML không hợp lệ 71

Hình 6.7: Sơ đồ thống kê thời gian thực thi (theo đơn vị giây) trên 4 tập DataSet 76

Hình 6.8: Thời gian thực thi của 4 phương pháp trên DataSet_5 77

Hình 6.9: Mô hình i* “1_4” 81

Hình 6.10: Mô hình i* “3_4” 81

Bảng 4.1: Danh sách các loại phần tử/nút trong mô hình i* 31

Bảng 4.2: Danh sác các loại liên kết trong mô hình i* 32

Bảng 4.3: So sánh độ tương tự trên đặc trưng và logic của 3 đồ thị trên 43

Bảng 5.1: Danh sách các biểu diễn logic của 5 mô hình i* 53

Bảng 5.2: Danh sách các biểu diễn logic của 5 độ xấp xỉ hơn ở trạng thái 1 56

Bảng 5.3: Tính độ tương tự dựa trên đặc trưng và logic ở trạng thái 1 57

Bảng 5.4: Danh sách các biểu diễn logic của 5 độ xấp xỉ hơn ở trạng thái 2 59

Bảng 5.5: Tính độ tương tự dựa trên đặc trưng và logic ở trạng thái 2 59

Bảng 5.6: Tính độ tương tự dựa trên đặc trưng và logic ở trạng thái 3 60

Bảng 5.7: Tính độ tương tự dựa trên đặc trưng và logic ở trạng thái 4 62

Bảng 5.8: Tính độ tương tự dựa trên đặc trưng và logic ở trạng thái 5 63

Bảng 6.1: Danh sách dataset dùng để thực nghiệm 70

Bảng 6.2: Kết quả thực nghiệm phương pháp tính độ tương tự trên đặc trưng 72

Bảng 6.3: Kết quả thực nghiệm phương pháp tính độ tương tự trên logic 73

Bảng 6.4: Kết quả thực nghiệm phương pháp dựa trên đồ thị con đẳng cấu 74

Bảng 6.5: Kết quả thực nghiệm phương pháp tính độ tương tự trên logic và đồ thị con đẳng cấu 75

Bảng 6.6: Thống kê thời gian thực thi của 4 phương pháp 75

Bảng 6.8: So sánh kết quả gợi ý của 4 phương pháp trên tập DataSet_3 80

CHƯƠNG 1: GIỚI THIỆU

Chương này sẽ giới thiệu tổng quan về luận văn, các lý do và mục đích nghiên cứu, sơ lược kết quả đạt được và trình bày cấu trúc của luận văn

1.1 Lý do và mục đích nghiên cứu

Ngày nay, ứng dụng công nghệ thông tin vào trong công việc ngày càng nhiều, từ

đó nhu cầu phát triển phần mềm cũng tăng lên Trong giai đoạn đầu của phát triển phần mềm là giai đoạn phân tích yêu cầu, các yêu cầu về phần mềm cần xây dựng phải được đặc tả một cách đầy đủ để có thể tiến hành thiết kế và xây dựng phần mềm cho phù hợp

Các đặc tả này có thể ở dưới các dạng phi hình thức (informal) như các biểu đồ, văn bản hoặc hình thức (formal) như các biểu thức toán mô tả yêu cầu Tính chính xác

và hữu dụng của các đặc tả ở bước này rất quan trọng vì nó phải mô tả được phần mềm cần xây dựng, giúp các nhà phát triển phần mềm có các quyết định đúng đắn trong thiết

kế và hiện thực phần mềm, cũng như giúp kiểm chứng về chất lượng sản phẩm làm ra

Các nghiên cứu về đặc tả hình thức đã bắt đầu từ rất sớm và đã đạt được một số thành công nhất định Tuy nhiên, các nghiên cứu gần đây đã chỉ ra những điểm còn yếu của phương pháp này như là chi phí (thời gian và nhân lực) rất cao, mức trừu tượng đặc

tả thấp và chưa phù hợp với các yêu cầu phát triển phần mềm nhanh chóng như hiện nay Một số nghiên cứu khác đã chỉ ra rằng, phương pháp này cần phải được cải tiến theo hướng tăng tính tích hợp, tăng mức độ trừu tượng đặc tả và chú tâm tạo ra các kỹ thuật hạng nhẹ, chi phí (thời gian và nhân lực) thấp Mặc dù có nhiều nhóm nghiên cứu về lĩnh vực Công nghệ phần mềm ở Việt nam, nhưng các nghiên cứu chuyên về đặc tả hình thức

và ứng dụng vào trong thực tiễn hiện nay còn chưa phát triển nhiều

Các phương pháp đặc tả hình thức có ưu điểm rõ rệt về nền tảng lý thuyết để đảm bảo tuyệt đối tính đúng đắn của một hệ thống, để có áp dụng trong công nghiệp phần mềm Tuy nhiên, việc đặc tả thường phức tạp, nặng về toán học cần các chuyên gia về phương pháp hình thức, một số thành phần trong hệ thống khó có thể mô tả bằng ngôn

ngữ hình thức Hơn nữa khách hàng thường không thích các đặc tả toán học nên không hiểu hiểu được các đặc tả này, do đó chúng ta cần để che dấu bớt các rối rắm toán học

và tăng cường các công cụ hổ trợ trong phân tích yêu cầu Ngoài ra, đặc tả hình thức cần được nâng từ mức thiết kế chức năng đến mức trừu tượng trong bước phân tích yêu cầu (requirement engineering), cũng như tính tích hợp (integration) của các đặc tả hình thức trong vòng đời phát triển phần mềm

Trong những năm gần đây, UML trở thành một ngôn ngữ chuẩn để mô hình hóa các yêu cầu phần mềm và thiết kế Tuy nhiên, ở giai đoạn đầu của việc đặc tả yêu cầu thì ngôn ngữ UML thường chú trọng đến việc biểu diễn thông tin của các tác nhân và sự tương tác của tác nhân với các usecase, còn mối quan hệ giữa tác nhân với tác nhân và usecase với usecase thì lại sơ xài, chủ yếu với 3 mối quan hệ: Generalization, «Include» and «Extend» Ngoài ra, cũng còn một vấn đề khác là việc phân rã một usecase thành một hệ thống sub các usecase cũng là khó khăn trong UML

Ngôn ngữ mô hình i* là ngôn ngữ mô hình thích hợp cho việc mô hình hóa yêu cầu ở giai đoạn đầu và giúp hiểu được các vấn đề của đặc trưng miền [4] Ngược lại với hướng tiếp cận UML khi mà sơ đồ Usecase chỉ bao gồm hàm mục tiêu (tác nhân nào thực hiện những hành động nào – cụ thể trong phần mềm), ngôn ngữ mô hình i* có cả hướng tác nhân và hướng mục tiêu Ngôn ngữ mô hình i* trả lời câu hỏi: who và why, không trả lời câu hỏi what Ngôn ngữ mô hình i* còn cho phép mô hình cả hai tình huống là: as-is và to-be Ngoài ra, ngôn ngữ mô hình i* cung cấp nhiều mức độ phân tích: ability (khả năng), workability (khả năng làm việc), viability (tính khả thi) và believability (số lượng khả tin)

Việc mô hình hóa ở giai đoạn đầu, ngoài việc chọn được một ngôn ngữ mô hình thích hợp thì việc tái sử dụng lại các mô hình đã có cũng là một vấn đề cần quan tâm Như thế nào mà người phân tích yêu cầu khi thực hiện các bước phân tích thì có được những bước gợi ý là đã có một mô hình tương tự để cho việc phân tích được diễn ra

nhanh hơn và kết quả phân tích qua thời gian ngày càng được cải thiện do tận dụng lại được các mô hình phân tích trước đó.

1.2 Mục tiêu và giới hạn luận văn

Ngôn ngữ mô hình i* là một ngôn ngữ mô hình hướng mục tiêu Trong một tác nhân, ta có thể thấy nó hướng tới mục tiêu nào và để đạt được mục tiêu đó thì nó cần có những công việc, tài nguyên hay những mục tiêu con nào Trong luận văn, sẽ tập trung vào việc biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic

Khi đã có được biểu diễn logic các mục tiêu trong mô hình i*, vấn đề thứ hai là làm sao có thể tính toán độ tương tự giữa các mô hình i* dựa trên các biểu diễn này Luận văn sẽ nghiên cứu và đánh giá phương pháp tính độ tương tự dựa vào logic trên để

có thể thấy được các ưu và khuyết điểm của phương pháp, từ đó đề nghị bổ sung một phương pháp/giải thuật hỗ trợ khác

Vấn đề thứ ba là việc lưu trữ các biểu diễn này cũng như các biểu diễn đã có trước

đó Có nhiều cách để lưu trữ như dùng các hệ cơ sở dữ liệu hay định nghĩa một cấu trúc lưu trữ dạng tập tin, nhưng các cách trên phải đảm bảo được việc có thể hiển thị lại mô hình đã vẽ dưới dạng đồ họa và các đặc tả đã được chuyển đổi từ mô hình

Tóm lại, đề tài sẽ tập trung biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic Nghiên cứu phương pháp/giải thuật tính độ tương tự giữa các biểu diễn logic trên, các giải thuật đề nghị bổ sung để tăng độ chính xác cho phương pháp tính độ tương

tự dựa trên logic và xây dựng thư viện lưu trữ các đặc tả

Hình 1.1 cho thấy quy trình tiếp cận của luận văn, luận văn sẽ tập trung giải quyết phần 2.1 và 2.2 là tính toán độ tương tự để có thể gợi ý cho người phân tích yêu cầu và xây dựng thư viện lưu trữ

Kết quả đạt được của đề tài là một đóng góp cho kỹ thuật sử dụng đặc tả hình thức trong việc biểu diễn và tính độ tương tự giữa các mục tiêu của mô hình i* Thấy được

ưu và khuyết điểm của kỹ thuật này trong việc biểu diễn mục tiêu của mô hình i* và cách thức xây dựng một thư viện lưu trữ để có thể sử dụng lại các mô hình về sau

Hình 1.1: Mô phỏng quy trình tiếp cận của của đề tài

1.3 Cấu trúc của luận văn

Các phần còn lại của luận văn được tổ chức như sau:

Chương 2 – Các nghiên cứu liên quan: luận văn sẽ trình bày các công trình và nghiên cứu liên quan về ngôn ngữ mô hình i*, các phương pháp tính độ tương tự dựa trên logic giữa các Web Service, nhận xét về phương pháp tính độ tương tự trên để có thể áp dụng vào bài toán của luận văn

Chương 3 – Cơ sở lý thuyết: luận văn sẽ trình bày các vấn đề về cơ sở lý thuyết

về ngôn ngữ mô hình i*, các khái niệm và định nghĩa của phương pháp đặc tả hình thức, khái niệm về đồ thị con đẳng cấu để giải quyết khuyết điểm của việc sử dụng đặc tả hình thức khi biểu diễn mục tiêu của mô hình i*

Chương 4 – Mô hình hóa bài toán: luận văn sẽ trình bày cách thức biểu diễn mục tiêu trong mô hình i* dưới dạng biểu diễn logic Nghiên cứu, đánh giá phương pháp tính

độ tương tự dựa trên logic cho mục tiêu trong mô hình i* Đồng thời đề xuất một giải thuật bổ sung để hỗ trợ giải quyết khuyết điểm của phương pháp tính độ tương tự dựa trên logic

Chương 5 – Case studies: để có thể hiểu rõ hơn về cách thức biểu diễn mục tiêu trong mô hình i* và các bước tính toán độ tương tự giữa các mô hình để hệ thống có thể gợi ý cho người phân tích yêu cầu, luận văn sẽ trình bày một case study nhỏ với các trạng thái thay đổi độ tương tự và kết quả gợi ý khi người phân tích yêu cầu vẽ mô hình i* ở từng bước

Chương 6 – Hiện thực và thực nghiệm: phần hiện thực luận văn sẽ trình bày phần hiện thực hệ thống Kiến trúc của hệ thống gồm những thành phần nào, cách xây dựng

cơ sở dữ liệu lưu trữ Phần thực nghiệm, luận văn sẽ trình bày các bộ dữ liệu kiểm thử

và kết quả thực nghiệm So sánh các kết quả thực nghiệm giữa các phương pháp đề xuất

Chương 7 – Kết luận: trình bày các kết quả đạt được và chưa đạt được của luận văn, các vấn đề khó khăn khi thực hiện luận văn, và đề xuất hướng nghiên cứu tiếp theo trong tương lai

CHƯƠNG 2: CÁC NGHIÊN CỨU LIÊN QUAN

Ở chương này luận văn sẽ trình bày các công trình và nghiên cứu liên quan về ngôn ngữ mô hình i*, các phương pháp tính độ tương tự dựa trên logic giữa các Web Service, nhận xét về phương pháp tính độ tương tự trên để có thể áp dụng vào bài toán của luận văn

2.1 Ngôn ngữ mô hình i*

Ngày nay cũng có rất nhiều nghiên cứu và ứng dụng sử dụng ngôn ngữ mô hình i* Theo MIT Press [7], quyển sách “Social Modeling for Requirements Engineering” của tác giả Eric Yu [23] mô tả một cách tiếp cận dựa trên việc mô hình hóa dùng ngôn ngữ mô hình i* hay còn gọi là khung thức i* (i* framework) Cách tiếp cận này là một cách tiếp cận mới trong thách thức của việc lấy yêu cầu phần mềm, dựa trên mô hình hóa và phân tích các mối quan hệ giữa các bên liên quan, cũng như các mục tiêu cần đạt được, các nhiệm vụ cần được thực hiện và các tài nguyên cần được trang bị

Các công cụ để thiết kế và trừu tượng hóa mô hình i* đã được phát triển khá nhiều như: openOME [2], J-PRIM [3], Tagoon+ [1], … hay Visio của Mircosoft Các công cụ như openOME, J-PRIM cho phép người phân tích yêu cầu vẽ các mô hình hướng mục tiêu qua ngôn ngữ mô hình i*, cho xuất ra định dạng *.istarml là một chuẩn lưu trữ chung

để trao đổi mô hình i* giữa các công cụ khác nhau Tagoon+ là một công cụ phát triển trên nền Java cho phép tích hợp mô hình i* vào Ontology, với đầu vào là tập tin *.istarml, đầu ra là tập tin *.owl Để tích hợp vào Ontology ngoài chuẩn đầu vào là tập tin iStarML thì các tập tin này cần được mở rộng với thuộc tính “sannotation” để lưu trữ các chú thích ngữ nghĩa cho mỗi phần tử mô hình

Trước một số lượng lớn các nghiên cứu cũng như các công cụ đã được xây dựng

ở trên, ta thấy được i* là một ngôn ngữ mô hình thích hợp cho việc phân tích yêu cầu ở giai đoạn đầu

Tuy nhiên, công cụ nêu trên chỉ cho phép tích hợp nhưng chưa cho phép kiểm tra, đánh giá mô hình i* cũng như chưa có một cở sở dữ liệu các mô hình đã được đặc tả trước đó, hay cung cấp một cách thức để tính toán độ tương tự giữa các mô hình i* đã

có để từ đó có thể tìm kiếm/gợi ý cho người phân tích yêu cầu các mô hình tương tự Các công cụ chỉ tập trung nhiều vào việc cho phép người thiết kế vẽ ra mô hình i* hay nổi bật nhất là công cụ Tagoon+ cho phép tích hợp mô hình i* vào Ontology như đã nêu

ở trên, nên việc hướng tới một phương pháp tính toán độ tương tự giữa các mô hình i* cũng là một hướng tiếp cận mới và sẽ có đóng góp tốt cho ngôn ngữ mô hình hướng mục tiêu nói chung và ngôn ngữ mô hình i* nói riêng và đóng góp một cách áp dụng đặc tả hình thức vào một bài toán cụ thể

Hình 2.1: Tổng quan kiến trúc của công cụ Tagoon+

2.2 Biểu diễn logic của Web Service

Có nhiều các để biểu diễn các bài toán, biểu diễn logic là một trong số các phương pháp Theo [17], một web service có thể được bằng logic qua định nghĩa bằng các đặc tính input và output như sau:

W = (N, P, E, Q)

trong đó:

- N là tên duy nhất của web service

- P là tiền điều kiện phải được thỏa mãn khi thực thi web service

- E là biểu diễn kết quả (hay hậu điều kiện) sau khi web service thực thi

- Q là tập các thuộc tính về chất lượng, mỗi thuộc tính gồm cặp giá trị nam/value,

ví dụ {respTime =3} (thời gian phản hồi = 3)

Các input và output của web service được biểu diễn như sau:

WS  fin  fout  fin-1  …  fin-m  fout-1  …  fout-m

trong đó:

- fin là biểu diễn logic thể hiện thuộc tính đầu vào của hàm và các tiền điều kiện

- fout là biểu diễn logic thể hiện thuộc tính đầu ra của hàm và hiệu quả

Ví dụ: WS1 là web service HotelReservationService WS1 nhận vào Hotel và Dates, sau đó trả về thông tin HotelReservation

- fin : Hotel  Dates

- fout: HotelReservation

hay: WS  Hotel  Dates  HotelReservation

Hình 2.2 biểu diễn cách một web service được chuyển sang biểu diễn logic Với

ID, Inputs, Preconditions, Outputs, Effects của web service lần lượt được chuyển sang Name, Left, Right của biểu diễn logic

Trong công thức 𝐿𝑒𝑓𝑡 → 𝑅𝑖𝑔ℎ𝑡 nếu một vế nào đó không có thành phần thì chúng

ta xem vế đó là true Ví dụ: WS  Hotel  Dates  true, với web service không có thành phần ở vé phải

Hình 2.2: Mapping giữa web service và biểu diễn logic

2.3 Bước chuyển đổi OWL-S sang biểu diễn logic

Theo [17], việc chuyển đổi từ OWL-S sang biểu diễn logic là quá trình rút trích thông tin về input, output, pre-condition và effect của web services, sau đó chuyển đổi

chúng sang thành phần của biểu diễn logic Gọi WSP i là thông tin của web service ith và

f i là biểu diễn logic được chuyển đổi Mỗi thành phần được chuyển đổi như sau:

- Tên của biểu diễn logic là ID của web service: 𝑛𝑎𝑚𝑒(𝑓𝑖) = 𝑊𝑆𝑃𝑖 𝐼𝐷

- Vế trái của biểu diễn logic là input và pre-condition của web service:

Sau khi đã hoàn tất việc chuyển đổi một web service sang biểu diễn logic Bước tiếp theo là cần tính toán độ tương tự của hai web service, việc tính toán độ tương tự của tác giả được dựa trên ba tiêu chí: tính toán độ tương tự dựa trên đặc trưng, tính toán độ tương tự dựa trên Ontology , điểm hạn chế của hai cách tính độ tương tự trên từ đó đưa

ra phương pháp tính toán độ tương tự dựa trên logic

Hình 2.3: Mô tả chuyển đổi web service sang mệnh đề logic

2.4 Độ tương tự của Web Service có ngữ nghĩa dựa trên logic

Theo [17], tác giả đề xuất cách so sánh dựa trên độ đo mới giữa hai web service

mà được biểu diễn như hai công thức logic Độ đo của tác giả được phát triển từ các độ

đo cổ điển như:

- Feature-based similarity: Tác giả rút trích các đặc trưng từ các công thức logic,

dựa trên tính toán độ tương tự giữa chúng

- Logic-based similarity: cuối cùng là thể hiện logic được dùng cho tính toán độ tương tự Tác giả sử dụng “xấp xỉ-hơn” (over-approximation) để tính toán độ

xấp xỉ của công thức gốc Ý tưởng là hai công thức có logic giống sẽ có độ tương tự cao hơn so với công thức gốc

2.4.1 Độ tương tự dựa trên đặc trưng

Để tính toán độ tương tự giữa hai biểu diễn logic (mệnh đề logic), chúng ta xác định phần giống nhau (the common part) và phần khác nhau (the different part) của hai biểu diễn Phần giống nhau và phần khác nhau được định nghĩa như sau:

Phần giống nhau - Ta có hai mệnh đề logic f và g Phần chung C sẽ được định

nghĩa như sau:

f1 = Dates  Hotel → HotelReservation

f13 = ¬Hotel  ¬Dates  City  HotelReservation

C = {Dates, Hotel, HotelReservation}

a = |C| = |{Dates, Hotel, HotelReservation}| = 3

Phần khác nhau - Ta có 2 mệnh đề logic f và g Phần khác nhau D sẽ được định

nghĩa như sau:

D = (f ∪ g)\C = ({∀fi ∈ f} ∪ {∀gj ∈ g})\C Với fi, gj là số hạng nguyên tử (atomic terms) trong f và g Đặt b là hệ số phần khác nhau giữa f và g

b = |D|

2

Ví dụ: Hai mệnh đề logic f1 và f13

f1 = Dates  Hotel → HotelReservation

f13 = ¬Hotel  ¬Dates  City  HotelReservation

Độ tương tự dựa trên đặc trưng (Feature-based similarity) - Ta có hai mệnh đề

logic f và g Phần độ tương tự dựa trên đặc trưng (SimFe) sẽ được tính toán theo công thức như sau:

SimFe(f, g) = a

a + bTheo ví dụ trên ta sẽ có

SimFe(f1, f13) = 3

3+12= 6

7 ≈ 0.86

2.4.2 Độ tương tự dựa trên Logic

Theo [17], dù tính toán độ tương tự dựa trên đặc trưng, kết hợp với Ontology nhưng vẫn chưa đạt hiệu quả cao khi dữ liệu có tính logic Do đó, có thể tối ưu hóa độ tương tự thêm bằng cách dựa trên logic

Độ xấp xỉ hơn (over approximation) của 2 mệnh đề - Ta có 2 mệnh đề logic f1 và

f2 Xấp xỉ hơn sẽ được định nghĩa như sau:

f12 = f1  f2 = f1in  f2in → f1out  f2out

Trong đó,  là toán tử xấp xỉ hơn (over approximation operator), f12 được chứng minh theo Z3 [19]

Độ tương tự web service dựa trên logic – Ta có hai web service WSA, WSB, fA, fB

là hai biểu diển logic của WSA, WSB , fAB là độ xấp xỉ hơn của của hai WSA, WSB theo định nghĩa trên Độ tương tự của hai web service WSA, WSB sẽ được tính toán dựa trên công thức sau:

SimLo(WSA, WSB) = SemFe(fA, fAB)

SemFe(fB, fAB)

2Trong đó, SimFe(f1, f2) là độ tương tự dựa trên đặc trưng của f1, f2

Dựa trên công thức trên độ tương tự của 2 web service sẽ được tính toán theo giải thuật 1 sau:

Giải thuật 1: Tính toán độ tương tự dựa trên logic của 2 web service

Input: cặp web service WS1, WS2

Output: Giá trị của độ tương tự dựa trên logic – S

Process:

1 Xây dựng biểu diễn logic của 2 web services f1, f2

2 Tính toán độ xấp xỉ hơn f12 của f1, f2

3 Sử dụng Z3 để đơn giản hóa f12

4 Tính toán phần giống nhau và phần khác nhau a, b theo định nghĩa trên của mỗi cặp f1− f12, f2− f12

5 Tính toán độ tương tự dựa trên tính chất SimFe(f1, f12) và SimFe(f2, f12)

6 Tính toán độ tương tự dựa trên logic từ độ tương tự dựa trên tính chất SimFe(f1, f12) và SimFe(f2, f12)

7 Trả giá trị S

Ví dụ: Ta có 3 mệnh đề logic sau

- f1 = Dates  Hotel → HotelReservation

- f2 = City → Hotel

- f3 = Hotel → City

Độ xấp xỉ hơn được tính như sau:

- f23 = f2  f3 = (City → Hotel )  (Hotel → City) = (City  Hotel →

Hotel  City) = true

- f13 = f1  f3 = (Dates  Hotel → HotelReservation) (Hotel → City) =(Dates  Hotel) Hotel → City  HotelReservation =

¬Hotel  ¬Dates City  HotelReservation

CHƯƠNG 3: CƠ SỞ LÝ THUYẾT

Chương này của luận văn sẽ trình bày các vấn đề về cơ sở lý thuyết về ngôn ngữ

mô hình i*, các khái niệm và định nghĩa của phương pháp đặc tả hình thức, khái niệm

về đồ thị con đẳng cấu để giải quyết khuyết điểm của việc sử dụng đặc tả hình thức khi biểu diễn mục tiêu của mô hình i*

3.1 Đặc tả hình thức

Trong ngành khoa học máy tính, các phương pháp hình thức là các kỹ thuật toán học cho việc đặc tả, phát triển và kiểm định các hệ thống phần mềm và phần cứng Cách tiếp cận này đặc biệt quan trọng đối với các hệ thống cần có tính toàn vẹn cao, chẳng hạn hệ thống điều khiển lò phản ứng hạt nhân hay điều khiển tên lửa, khi an toàn hay an ninh có vai trò quan trọng, để góp phần đảm bảo rằng quá trình phát triển hệ thống sẽ không có lỗi [8]

Đặc tả hình thức được viết bằng tập các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa (sematic) rất chặt chẽ Đặc tả hình thức cũng có thể là dùng mô hình,

sơ đồ để mô tả Mô hình hệ thống được câú trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự

 Thiết kế ở mức cao: Ngôn ngữ Alloy, UML

 Thiết kế ở mức nguồn: JML (Java Modeling Language) (Java), Dafny (C#), Krakatoa (Java/C), …

Ngôn ngữ mô hình Java JML là một ngôn ngữ mô hình theo phương pháp “thỏa thuận” hay còn gọi là phương pháp Design by contract (DBC) Ý tưởng chính của phương pháp này là một lớp hay một phương thức và khách hàng của nó có một thỏa thuận với nhau Khách hàng phải bảo đảm các điều kiện đầu vào và các phương thức này phải thỏa mãn được các yêu cầu của khách hàng JML là ngôn ngữ đặc tả hành vi, được

sử dụng để đặc tả hành vi của các mô đun trong ngôn ngữ Java Các đặc tả của JML được thêm vào mã nguồn của Java dưới dạng các chú giải (annotation) bên trong các chú thích

(comment) Ngôn ngữ Java sẽ hiểu các chú thích là JML khi các chú thích có ký tự bắt

đầu là ký tự “@” Ví dụ: //@ <đặc tả JML> cho định dạng chú thích từng dòng và /*@

<đặc tả JML> @*/ cho định dạng chú thích nhiều dòng

Ngoài JML, thì còn những ngôn ngữ mô hình khác như ngôn ngữ mô hình hướng đối tượng Cụ thể là SOFL (Structured Object-Oriented Formal Language), SOFL là ngôn ngữ đặc tả dựa trên mô hình hướng đối tượng Nó cung cấp một ngôn ngữ đặc tả tổng quát cho tất cả các bước từ giai đoạn thu thập yêu cầu, đến giai đoạn thiết kế và hiện thực phần mềm Các công cụ hỗ trợ cho ngôn ngữ SOFL cũng có khá nhiều như

SOFL Specification Creator là công cụ cho phép soạn thảo các đặc tả một cách trực quan

(kéo thả) và tự động sinh ra các cấu trúc khung của đặc tả và mô đun xử lý tương ứng

Hình 3.1: Ảnh chụp giao diện của công cụ SOFL Specification Creator

Hình 3.1 thể hiện lược đồ dòng dữ liệu điều kiện (CDFD – Condition Data Flow Diagram) biểu diễn các thành phần process tương tác với nhau qua dòng dữ liệu và sử dụng các kho dữ liệu (data store)

Hai ngôn ngữ JML và SOFL được nêu ở trên là hai ngôn ngữ ở mức nguồn, còn trong giai đoạn đầu của việc phân tích yêu cầu Các khái niệm, yêu cầu và mục tiêu cần đạt được vẫn còn ở đang ở mức trừu tượng, ở giai đoạn này UML là một ngôn ngữ mô hình phổ biến và đã được áp dụng rộng rãi Tuy nhiên UML thì lại chú trọng với việc tác nhân nào thực hiện những hành động cụ thể nào ở trong phần mềm, và khi muốn phân

rã các mô hình UML như sơ đồ UseCase cũng là một vấn đề khó khăn Ngôn ngữ mô hình i* là ngôn ngữ mô hình hướng mục tiêu và cả hướng tác nhân có thể đáp ứng được yêu cầu trên

3.2 Ngôn ngữ mô hình i* (iStar)

Khung thức i* là một khung thức hoạt động theo mô hình hướng tác nhân modeling) hay hướng mục tiêu (goal-modeling), bao gồm các khái niệm như actor, role, agent, position, và các nguyên nhân về chúng

(agent-Tích hợp trong khung thức i* là ngôn ngữ mô hình i*, là ngôn ngữ mô hình thích hợp cho việc mô hình hóa yêu cầu ở giai đoạn đầu và giúp hiểu được các vấn đề của đặc trưng miền Ngược lại với hướng tiếp cận UML khi mà sơ đồ UseCase chỉ bao gồm hàm mục tiêu (tác nhân nào thực hiện những hành động nào – cụ thể trong phần mềm), ngôn ngữ mô hình i* có cả hướng tác nhân và hướng mục tiêu Ngôn ngữ mô hình i* trả lời câu hỏi: who và why, không trả lời câu hỏi what Ngôn ngữ mô hình i* còn cho phép mô hình hóa cả hai tình huống là: as-is và to-be Ngoài ra, ngôn ngữ mô hình i* cung cấp nhiều mức độ phân tích: ability (khả năng), workability (khả năng làm việc), viability (tính khả thi) và believability (số lượng khả tin)

Ngày nay có rất nhiều nghiên cứu, và ứng dụng đã sử dụng ngôn ngữ mô hình i* trong kỹ thuật lấy yêu cầu ở giai đoạn đầu, thiết kế quy trình hay yêu cầu hệ thống Ngôn

ngữ mô hình i* có hai dạng mô hình chính là Strategic Dependency model (SD) và

Strategic Rationale model (SR)

 Strategic Dependency model (mô hình chiến lược phụ thuộc) là tập hợp các

nút và liên kết, mỗi nút biểu diễn 1 tác nhân và mỗi liên kết giữa 2 tác nhân cho biết tác nhân nào phụ thuộc vào tác nhân khác Mô hình SD được sử dụng

để thể hiện các mạng có mục đích, mối quan hệ chiến lược giữa các tác nhân

 Strategic Reationale model (mô hình chiến lược quan hệ) là đồ thị, với nhiều

nút và liên kết cùng nhau thể hiện cấu trúc với quan hệ bên dưới Các tác nhân trong mô hình SD sẽ được mở ra (opened up) để cho thấy những ý định cụ thể của nó Mô hình SR cũng có 4 loại nút như mô hình SD là: goal, task, resource, and softgoal và có 3 loại liên kết trong nội bộ của actor là: means-ends links, task decomposition links and contribution links

Có nhiều công cụ để thiết kế và trừu tượng hóa mô hình i* như: openOME, PRIM , Tagoon+ Tool, … hay Visio của Mircosoft Mỗi công cụ có 1 cách lưu trữ mô hình khác nhau, như bằng XML của openOME, J-PRIM thì dùng Java lưu trữ bằng MySQL Trước sự đa dạng về các công cụ, mỗi công cụ lại có 1 chuẩn lưu trữ mô hình i* như thế thì i* có 1 chuẩn chung để trao đổi (model interchange format), gọi là iStarML [5] là định dạng mô hình i* bằng XML

J-Hình 3.2 và J-Hình 3.3 bên dưới thể hiện hai dạng chính của mô hình i* Mô hình

SD thể hiện mối quan hệ phụ thuộc của các tác nhân với nhau, ví dụ như tác nhân “PhD Student” cũng là (is-a) tác nhân “Student” Với mô hình dạng SR, tác nhân “Student” được mở ra để cho thấy các goal “Travel organized” và mối liên hệ giữa các subgoal, task, resource để có thể đạt được goal này

Hình 3.2: Mô hình SD (Travel Reimbursement)

Hình 3.3: Mô hình SR (Travel Reimbursement) với tác nhân Student được

“opened up”

Biểu diễn mô hình i* dưới dạng XML ( chuẩn của iStarML)

Hình 3.4: Thể hiện mô hình i* dưới chuẩn iStarML với tác nhân Customer

as Buyer [Service] cùng các goal, softgoal bên trong

fontfamily="Segoe UI"fontcolor="000000" fontsize="12"/>

<ielement type="softgoal" id="_RKKzwKCLEeWZP_hdsKrw6w"

name="Low Price">

<graphic content="basic" xpos="0" ypos="0" width="120" height="55" unit="pt" bgcolor="FFFFFF" fontfamily="Segoe UI" fontcolor="000000" fontsize="12"/>

</ielement>

<ielement type="goal" id="_bjJZwKCLEeWZP_hdsKrw6w"

name="Low Price Service Provider Be Found">

<graphic content="basic" xpos="0" ypos="0" width="120" height="55" unit="pt" bgcolor="FFFFFF" fontfamily="Segoe UI" fontcolor="000000" fontsize="12"/>

<ielementLink type="contribution" value="hurt"

Khi biểu diễn các mục tiêu trong mô hình i* dạng SR dưới dạng biểu diễn logic Các mục tiêu goal, softgoal sẽ được biểu diễn ở vế phải, các task, resource cần phải thực hiện để đạt được các goal, softgoal sẽ được biểu diễn ở vế phải Tuy nhiên, cách biểu diễn này có một hạn chế là chưa thể hiện các mối liên kết trung gian giữa các thành phần task, resource và goal, softgoal Để giải quyết vấn đề này đề tài trình bày một giải thuật

bổ sung để tăng độ chính xác của phương pháp tính độ tương tự dựa trên logic là đồ thị con đẳng cấu

3.3 Đồ thị con đẳng cấu (Subgraph Isomorphism)

Về bản chất, mô hình i* cũng có thể được xem là một đồ thị có hướng Với các phần tử trong mô hình là đỉnh của đồ thị, các liên kết là cạnh của đồ thị Các đỉnh và cạnh của đồ thị sẽ được gán nhãn được ứng với loại phần tử hay loại liên kết trong mô hình i*

Khi tính độ tương tự dựa trên logic, chúng ta chỉ tập trung với nội dung và loại của phần tử mà chưa quan tâm đến các liên kết giữa chúng, thì bài toán đồ thị con đẳng cấu sẽ giúp chúng ta giải quyết được vấn đề này

Đồ thị và đồ thị con đẳng cấu là những khái niệm được sử dụng rất rộng rãi, đặc biệt là trong thời đại bùng nổ mạng xã hội ngày nay Việc so sánh hai đồ thị có đẳng cấu với nhau, hay tìm một đồ thị con đẳng cấu trong đồ thị lớn trở thành một bài toán phổ biến

Trong lý thuyết độ phức tạp tính toán (Computational complexity theory), Đồ thị con đẳng cấu là một bài toán quyết định (decision problem) thuộc loại NP-đầy đủ (NP-

complete) Bài toán đồ thị con đẳng cấu là bài toán được suy ra từ bài toán đồ thị đẳng

cấu

Định nghĩa đồ thị đẳng cấu:

Đầu vào: hai đồ thị G1 và G2

Câu hỏi: G1 có đẳng cấu với đồ thị G2 hay không?

Hình 3.5: Đồ thị vô hướng G1 và G2

Trả lời: Hai đồ thị G1 và G2 ở hình trên đẳng cấu với nhau Với,

 γ(1)=a, γ(2)=b, γ(3)=c, γ(4)=d

 μ(u1)=e1, μ(u2)=e2, μ(u3)=e6, μ(u4)=e5, μ(u5)=e4, μ(u6)=e3

Hình 3.6 và Hình 3.7 là trường hợp hai đồ thị đẳng cấu khi vô hướng và không đẳng cấu khi có hướng

Hình 3.6: G1 và G2 là 2 đồ thị vô hướng đẳng cấu với nhau

Hình 3.7: G3 và G4 là 2 đồ thị có hướng không đẳng cấu với nhau

Bài toán đồ thị con đẳng cấu là bài toán phức tạp hơn bài toán đồ thị đẳng cấu

Định nghĩa đồ thị con đẳng cấu:

Reimbursement) ở hình 3.3 Đồ thị G5 được gán lại bằng các đỉnh A, B, C, D, E, F, G và

đồ thị G6 được gán lại bằng các đỉnh 1, 2, 3, 4 như Hình 3.8 để dễ cho việc trình bày Cạnh từ đỉnh B tới đỉnh C gọi là BC, tương tự cho từ đỉnh 2 tới đỉnh 1 gọi là 21

Hình 3.8: Ví dụ về đồ thị con đẳng cấu của hai đồ thị G5 và G6

Đầu vào: hai đồ thị G5 và G6

Câu hỏi: G6 có đẳng cấu với một đồ thị con G5 hay không?

Trả lời: Đồ thị G6 có đẳng cấu với một đồ thị con của đồ thị G5 ở hình trên Với,

 γ(1)=B, γ(2)=X, γ(3)=D, γ(4)=E

 μ(21)=CB, μ(31)=DB, μ(24)=CE, μ(34)=DE

Thuật toán đầu tiên giải quyết vấn đề đồ thị con đẳng cấu là của J.R Ullmann với

bài báo “An algorithm for subgraph isomorphism” được xuất bản trên tạp chí Journal of

the ACM năm 1976 [22] Giải thuật Ullmann là một thủ tục đệ quy quay lui để tìm một

đồ thị con đẳng cấu G trong đồ thị lớn với đồ thị H nhập vào Sau này thì xuất hiện thêm một số giải thuật khác như của Messmer và Bunker dùng cây quyết định để tăng tốc độ

giải thuật, hay bản nâng cấp của giải thuật Ullmann năm 2010 dùng Bit vector để tăng tốc độ xử lý

Giải thuật Ullmann

Theo [21], ta có hai đồ thị G1, G2 Với G1 là Model graph (đồ thị mẫu), G2 là Query graph (đồ thị đã có), G1 có phải là đồ thị con đẳng cấu của G2 hay không Thuật toán diễn tả một thủ tục vét cạn (thực ra là thuật toán duyệt theo chiều sâu) Đồ thị G1, G2 lần lượt được biểu diễn thành hai ma trận kề A = [αij], B = [βij]

Thuật toán được thiết kế để tìm tất cả các đồ thị con đẳng cấu với G1 có trong G2 Khái niệm quan trọng của thuật toán là ma trận hoán vị M’ (có kích thước là nxm, với n tổng dòng của ma trận A, m là tổng dòng của ma trận B) Ma trận này có tính chất: mỗi dòng có duy nhất một số 1 và không có cột nào nhiều hơn một số 1

Ma trận M’ này được dùng để hoán vị các dòng và cột của ma trận B tìm ma trận

C Với ma trận 𝐶 = [𝑐𝑖𝑗] = 𝑀′(𝑀′𝐵)𝑇, ký hiệu T thể hiện sự chuyển vị Đồ thị con đẳng cấu tồn tại khi tất cả i và j của α và β, (αij =1) = (βij = 1)

Ví dụ về giải thuật Ullmann với đồ thị vô hướng, không gán nhãn

Biểu diễn 2 đồ thị H và G dưới dạng ma trận Trong đó H là ma trận truy vấn (query graph), G là ma trận mẫu (model graph)

𝐴𝐻 0 1 0 0

1 0 1 1

0 1 0 0

0 1 0 0

Ma trận hoán vị 𝑀0 với giá trị được tính theo công thức dưới

Dựa vào công thức trên ta lần lượt tính được 𝑀10, 𝑀20, 𝑀30, 𝑀40 như sau

Ma trận M’ là ma trận có tính chất: mỗi dòng có duy nhất một số một và không

có cột nào nhiều hơn một số một Sau khi ra được ma trận M’ ta tiếp tục tính ma trận C theo công thức sau

𝐶 = 𝑀′(𝑀′𝐴𝐻)𝑇

Ta lấy từng ma trận M’ nhân với ma trận 𝐴𝐻, sau đó lấy chuyển vị T của kết quả nhân này Rồi tiếp tục nhân ma trận M’ với ma trận chuyển vị trên Nếu ma trận kết quả bằng với ma trận 𝐴𝐺, thì so tất cả cạnh của ma trận 𝐴𝐻 và 𝐴𝐺 nếu trùng nhau thì in ra kết quả

Trường hợp với đồ thị vô hướng, đỉnh có gán nhãn

Các bước tính toán tương tự như đồ thị vô hướng không gán nhãn, nhưng tại bước

so sánh ta kiểm tra thêm các đỉnh có cùng nhãn hay không