Một số phương pháp kiểm chứng tái cấu trúc phần mềm

Bởi vậy, tiến trình tái cấu trúc cần được kiểm soátmột cách chặt chẽ đồng thời phải đánh giá ảnh hưởng của tiến trình nàytrên các đặc trưng về chất lượng và xem xét sự bảo toàn các đặc t

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Tôi xin cam đoan luận án “Một số phương pháp kiểm chứngtái cấu trúc phần mềm” là công trình nghiên cứu của riêng tôi Các sốliệu, kết quả được trình bày trong luận án là hoàn toàn trung thực và chưatừng được công bố trong bất kỳ một công trình nào khác.

 Tôi đã trích dẫn đầy đủ các tài liệu tham khảo, công trình nghiên cứuliên quan ở trong nước và quốc tế Ngoại trừ các tài liệu tham khảonày, luận án hoàn toàn là công việc của riêng tôi

 Trong các công trình khoa học được công bố trong luận án, tôi đã thểhiện rõ ràng và chính xác đóng góp của các đồng tác giả và những gì

do tôi đã đóng góp

 Luận án được hoàn thành trong thời gian tôi làm Nghiên cứu sinh tại

Bộ môn Công nghệ phần mềm, Khoa Công nghệ Thông tin, TrườngĐại học Công nghệ, Đại học Quốc gia Hà Nội

Tác giả:

Hà Nội:

i

LỜI CẢM ƠN

Trước hết, tôi muốn bày tỏ sự biết ơn đến PGS.TS Trương Ninh Thuận,cán bộ hướng dẫn, người đã trực tiếp giảng dạy và định hướng tôi trongsuốt thời gian học cao học, thực hiện luận văn thạc sĩ cũng như luận ánnày Thầy không chỉ hướng dẫn cho tôi những kiến thức về học thuật màcòn chỉ bảo cho tôi những kinh nghiệm quý báu trong cuộc sống Một vinh

dự lớn cho tôi được học tập, nghiên cứu dưới sự hướng dẫn của Thầy

Tôi xin bày tỏ sự biết ơn sâu sắc đến các Thầy Cô trong Bộ mônCông nghệ phần mềm vì sự giúp đỡ của các Thầy Cô về các đóng góp rấthữu ích cho luận án

Tôi xin trân trọng cảm ơn Khoa Công nghệ thông tin, Phòng Đàotạo và Ban giám hiệu trường Đại học Công nghệ đã tạo điều kiện thuận lợicho tôi trong suốt quá trình thực hiện luận án

Tôi cũng bày tỏ sự biết ơn đến Ban giám hiệu Trường Đại họcHải Phòng đã tạo điều kiện về thời gian và tài chính cho tôi thực hiện luận

án này Tôi muốn cảm ơn đến Ban chủ nhiệm, các cán bộ, giảng viên KhoaCông nghệ thông tin - Trường Đại học Hải Phòng đã cổ vũ động viên vàsát cánh bên tôi trong suốt quá trình nghiên cứu

Một phần của nghiên cứu này được thực hiện trong khuôn khổ đềtài nghiên cứu khoa học số 102.03-2014.40 (Nafosted) Xin cảm ơn các traođổi và trợ giúp của các thành viên đề tài

Tôi muốn cảm ơn đến tất cả những người bạn của tôi, đến toànthể Anh/Chị/Em NCS những người luôn chia sẻ, động viên tôi bất cứ khinào tôi cần và tôi luôn ghi nhớ điều đó

Cuối cùng, tôi xin bày tỏ lòng biết ơn vô hạn đối với cha mẹ,chồng, con và gia đình đã luôn ủng hộ và yêu thương tôi một cách vô điềukiện Nếu không có sự ủng hộ của gia đình và chồng con tôi không thể hoànthành được luận án này

Một lần nữa xin được trân trọng cảm ơn vì tất cả

NCS Đào Thị Hường

TÓM TẮT

Trong qúa trình phát triển của hệ thống phần mềm, tái cấu trúc toring) được biết đến “như tiến trình cải thiện cấu trúc bên trong (internalstructure) mà không làm ảnh hưởng đến hành vi bên ngoài (external beha-viour) của hệ thống” Tuy nhiên, hoạt động tái cấu trúc thực hiện trên các

(refac-hệ thống phần mềm rất dễ phát sinh lỗi đặc biệt trong trường hợp ngườiphát triển không tuân thủ một cách nghiêm ngặt các quy trình và tiêu chuẩnphát triển phần mềm Bởi vậy, tiến trình tái cấu trúc cần được kiểm soátmột cách chặt chẽ đồng thời phải đánh giá ảnh hưởng của tiến trình nàytrên các đặc trưng về chất lượng và xem xét sự bảo toàn các đặc tính quantrọng của hệ thống phần mềm

Luận án đề xuất một số phương pháp bảo toàn các ràng buộc của hệthống phần sau tiến trình tái cấu trúc Cụ thể, luận án quan tâm đến cáctiến trình tái cấu trúc áp dụng trên các hệ thống hướng đối tượng với cácđặc trưng về bất biến (invariants) và hành vi (behaviors) Các đóng gópchính của luận án được tóm tắt như sau:

(i) Đề xuất phương pháp bảo toàn bất biến trong tái cấu trúc biểu đồ lớpcủa UML Các phần tử của biểu đồ lớp cùng với các ràng buộc bất biếnđược hình thức hóa bằng các ký pháp toán học Tái cấu trúc trên biểu

đồ lớp được thực hiện thông qua các phép toán Folding, Abstraction,Composition, Factoring và Unfolding Luận án đề xuất luật tái cấutrúc (refactoring rules) cho các phép toán đồng thời cũng chứng minh

sự đúng đắn của các luật này bằng phương pháp toán học Tiến trìnhtái cấu trúc áp dụng các phép toán trên được khẳng định là bảo toànbất biến của các lớp của mô hình ban đầu trên mô hình tái cấu trúc.(ii) Đề xuất phương pháp kiểm chứng sự bảo toàn hành vi trong tái cấutrúc hệ thống phần mềm bằng cách áp dụng mẫu thiết kế Phần mềmban đầu cùng với các ràng buộc về hành vi (pre/post-conditions) củacác kịch bản (scenarios) tham gia vào tiến trình tái cấu trúc được hìnhthức hóa Hoạt động tái cấu trúc được thực thi sẽ gây ảnh hưởng trựctiếp đến các thành phần cấu tạo cũng như các ràng buộc hành vi này

Bởi vậy, các ràng buộc hành vi được tính toán lại và so sánh với vớicác ràng buộc của hệ thống ban đầu Chú ý rằng, đối tượng được quantâm đến khía cạnh bảo toàn hành vi là các kịch bản tham gia vào tiếntrình tái cấu trúc Đóng góp chủ yếu của luận án trong giải quyết bàitoán bảo toàn hành vi là việc xây dựng các định nghĩa biểu diễn hìnhthức các khái niệm trong kịch bản và sử dụng các định nghĩa này trongquy trình kiểm chứng được đề xuất Bài toán bảo toàn hành vi đã đượcgiải quyết tại các giai đoạn thiết kế và cài đặt trong vòng đời pháttriển phần mềm.

(iii) Xây dựng công cụ CVT (Consistency Validator Tool) hỗ trợ cho quátrình kiểm chứng tính nhất quán trong tái cấu trúc mô hình phầnmềm CVT nhận dữ liệu đầu vào là mô hình cùng với các ràng buộchành vi của các hệ thống trước và sau khi tái cấu trúc Sau quá trìnhthực thi, CVT sẽ trả lại kết luận về khả năng nhất quán giữa các môhình này

Từ khóa: tái cấu trúc, bảo toàn bất biến, bảo toàn hành vi, kiểm chứngtính nhất quán

Lời cam đoan i

1.1 Đặt vấn đề 1

1.2 Nội dung nghiên cứu 6

1.3 Cấu trúc luận án 7

Chương 2 KIẾN THỨC CƠ SỞ 9 2.1 Tái cấu trúc (refactoring) 9

2.2 Mô hình hướng đối tượng 12

2.3 Ngôn ngữ mô hình hóa thống nhất UML 14

2.3.1 Biểu đồ lớp 15

2.3.2 Biểu đồ tuần tự 16

2.4 Mẫu thiết kế 17

2.5 Ngôn ngữ ràng buộc đối tượng OCL (Object Constraint Lan-guage) 21

2.6 Ngôn ngữ đặc tả cho Java (Java Modeling Language - JML) 25 2.7 Logic vị từ bậc 1 (First-Order Logic - FOL) 26

2.8 Kết chương 27

v

Chương 3 PHƯƠNG PHÁP BẢO TOÀN BẤT BIẾN TRONG

3.1 Giới thiệu 28

3.2 Các nghiên cứu liên quan 30

3.3 Tái cấu trúc trên biểu đồ lớp của UML 33

3.3.1 Tái cấu trúc các lớp với mối quan hệ phân cấp 33

3.3.2 Tái cấu trúc các liên kết trong biểu đồ lớp 35

3.4 Phương pháp bảo toàn bất biến trong tái cấu trúc biểu đồ lớp của UML 36

3.4.1 Quy trình kiểm tra sự bảo toàn bất biến trong tái cấu trúc biểu đồ lớp của UML 37

3.4.2 Mô hình hóa biểu đồ lớp trong UML 38

3.4.3 Khuôn mẫu biễu diễn các phép toán tái cấu trúc 42

3.4.4 Xây dựng các luật tái cấu trúc 43

3.4.5 Chứng minh tính đúng đắn của các luật tái cấu trúc 54 3.4.6 Kiểm chứng sự bảo toàn các ràng buộc bất biến sau tái cấu trúc 58

3.5 Kết chương 59

Chương 4 PHƯƠNG PHÁP KIỂM CHỨNG SỰ BẢO TOÀN HÀNH VI TRONG TÁI CẤU TRÚC 62 4.1 Giới thiệu 62

4.2 Các nghiên cứu liên quan 64

4.3 Phương pháp kiểm chứng sự bảo toàn hành vi trong tái cấu trúc hệ thống phần mềm 67

4.3.1 Quy trình kiểm chứng sự bảo toàn hành vi trong tái cấu trúc hệ thống phần mềm 67

4.3.2 Phương pháp kiểm chứng tính nhất quán trong tái cấu trúc mô hình phần mềm 69

4.3.3 Phương pháp kiểm chứng tính nhất quán trong tái cấu trúc chương trình phần mềm 76

4.4 Áp dụng phương pháp kiểm chứng sự bảo toàn hành vi trên hệ thống điều khiển lưu lượng giao thông đường bộ (ARTC) 77 4.4.1 Mô tả hệ thống ARTC 78

4.4.2 Một số hạn chế của hệ thống ARTC trước tái cấu trúc 82 4.4.3 Xác định các hành vi cần bảo toàn 84

4.4.4 Kiểm chứng tính nhất quán trong tái cấu trúc mô hình hệ thống ARTC 88

4.4.5 Kiểm chứng tính nhất quán trong tái cấu trúc chương

trình phần mềm ARTC 904.5 Kết chương 90

5.1 Giới thiệu 935.2 Xây dựng công cụ kiểm chứng CVT 955.2.1 Kiến trúc của công cụ kiểm chứng CVT 955.2.2 Chuyển đổi biểu thức OCL sang công thức FOL 975.3 Cài đặt và thực nghiệm 1025.4 Kết chương 105

6.1 Các đóng góp của luận án 1076.2 Hướng phát triển 109

Từ viết tắt Dạng đầy đủ Diễn giải/Tạm dịch

ATM Automated Teller Machine Hệ thống rút tiền tự động

ARTC Adaptive Road Traffic Control Hệ thống điều khiển giao thông

CVT Consistency Validator Tool Công cụ kiểm chứng tính nhất quán

OCL Object Constraint Language Ngôn ngữ ràng buộc đối tượng

SMT Satisfiability Modulo Theories Tính khả thỏa của lý thuyết môđunUML Unified Modeling Language Ngôn ngữ mô hình hóa thống nhấtXML eXtensible Markup Language Ngôn ngữ đánh dấu mở rộng

viii

3.1 Khuôn mẫu biểu diễn phép toán tái cấu trúc 43

5.1 Biểu thức OCL và công thức FOL tương ứng 985.2 Các luật sản xuất R của văn phạm phi ngữ cảnh G 995.3 Tập các luật xây dựng cây AST từ văn phạm phi ngữ cảnh G 100

ix

1.1 Cấu trúc luận án 7

2.1 Tổng quan về các loại biểu đồ trong UML 2.5 16

2.2 Minh họa biểu đồ lớp trong UML 17

2.3 Minh họa biểu đồ tuần tự trong UML 18

2.4 Một số mẫu thiết kế 19

2.5 Mẫu thiết kế Strategy 20

3.1 Tái cấu trúc biểu đồ lớp với quan hệ phân cấp trong kế thừa 34 3.2 Sự biến đổi của các kết hợp trong tái cấu trúc biểu đồ lớp 35

3.3 Quy trình kiểm tra sự bảo toàn bất biến trong tái cấu trúc biểu đồ lớp của UML 37

3.4 Một phần mô hình hệ thống ATM đơn giản 39

3.5 Phép toán tái cấu trúc Folding 45

3.6 Phép toán tái cấu trúc Abstraction 47

3.7 Phép toán tái cấu trúc Composition 48

3.8 Phép toán tái cấu trúc Factoring 50

3.9 Phép toán tái cấu trúc Unfolding 52

4.1 Quy trình kiểm chứng sự bảo toàn hành vi trong tái cấu trúc hệ thống phần mềm 68

4.2 Minh họa Kịch bản S của mô hình 73

4.3 Mô hình hoạt động của hệ thống ARTC 78

4.4 Biểu đồ lớp của hệ thống ARTC trước tái cấu trúc 80

4.5 Biểu đồ tuần tự của hệ thống ARTC trước tái cấu trúc 81

4.6 Biểu đồ lớp của hệ thống ARTC sau khi tái cấu trúc 83

4.7 Biểu đồ tuần tự của hệ thống ARTC sau khi tái cấu trúc 87

4.8 Kết quả kiểm chứng sự bảo toàn hành vi trong tái trúc chương trình phần mềm 90

5.1 Kiến trúc của công cụ CVT 96

5.2 Giao diện người dùng của CVT 102 5.3 Công thức FOL dạng tiền tố tương ứng với biểu thức OCL 103

x

5.4 Minh họa kết quả kiểm chứng trong trường hợp nhất quán 1045.5 Minh họa kết quả kiểm chứng trong trường hợp không nhấtquán 105

2.1 Biểu thức JML đặc tả cho phương thức analyzeTimeLimit() 254.1 Đặc tả trên biểu đồ lớp của hệ thống ARTC khởi đầu 844.2 Đặc tả trên biểu đồ lớp của hệ thống ARTC sau tái cấu trúc 854.3 Đặc tả trên lớp OptimizerStrategy sau tái cấu trúc 864.4 Đặc tả hành vi của mã nguồn chương trình ARTC trước táicấu trúc 874.5 Các ràng buộc trên kịch bản optimizeTraffic() của mô hìnhkhởi đầu 884.6 Đặc tả trên kịch bản optimizeTraffic() của mô hình tiến hóa 89

xii

MỞ ĐẦU

Tái cấu trúc (refactoring) [27, 49, 72], “là tiến trình thay đổi cấu trúcbên trong (internal structure) mà không làm ảnh hưởng đến hành vi bênngoài (external behaviour) của hệ thống phần mềm” Ý tưởng chính của táicấu trúc là phân bố lại các lớp (classes), các thuộc tính (attributes) và cácphương thức (methods) xung quanh mối quan hệ phân cấp giữa các thànhphần của hệ thống nhằm tạo các điều kiện thuận lợi cho việc thích ứng(adaptations) và mở rộng (extensions) trong tương lai

Tái cấu trúc là một kỹ thuật mạnh mẽ được sử dụng để nâng cao chấtlượng phần mềm, tuy nhiên nó có thể dẫn đến tiêu tốn nhiều thời gian, côngsức và dễ phát sinh lỗi Bởi vậy, tiến trình tái cấu trúc phải được thực thimột cách thận trọng, đồng thời xem xét, giải quyết các bài toán liên quansau đây [43]:

(1) Đánh giá ảnh hưởng của tiến trình tái cấu trúc trên các chỉ tiêu vềchất lượng(Assessing the effect of refactoring on quality);

(2) Đảm bảo tiến trình tái cấu trúc bảo toàn hành vi (Guaranteeing thatthe refactoring preserves software behaviour);

(3) Duy trì sự nhất quán giữa các thành phần phần mềm sau tiến trình táicấu trúc (Maintaining consistency between refactored software compo-nents after refactoring process);

(4) Xây dựng công cụ hỗ trợ trong quá trình tái cấu trúc

1

Bài toán thứ nhất về đánh giá ảnh hưởng của tiến trình tái cấu trúctrên các chỉ tiêu chất lượng của phần mềm là tất yếu, xuất phát từ mụcđích của tiến trình tái cấu trúc là cải thiện chất lượng của phần mềm Chấtlượng phần mềm được thể hiện thông qua một số đặc trưng cơ bản như

độ phức tạp (complexity), tính hiểu được (understandability), khả năng mởrộng (extensibility), khả năng sử dụng lại (reusability) và hiệu suất thực hiện(performance) Để đo lường hoặc ước lượng tác động của một tiến trình táicấu trúc lên các đặc trưng này, đã có nhiều kỹ thuật khác nhau được đềxuất như độ đo phần mềm (software metrics), đo thực nghiệm (empiricalmeasurements), kỹ thuật thống kê (statistical techniques) hay điều khiểnthực nghiệm (controlled experiments), v.v Cụ thể, Kataoka đã đề xuất độ

đo tương liên (coupling metrics) như bộ tiêu chuẩn sử dụng để đánh giá ảnhhưởng của tiến trình tái cấu trúc trên đặc trưng về khả năng bảo trì củachương trình phần mềm [33] Tahvildari thực hiện mã hóa (encode) bản thiết

kế thành đồ thị mục tiêu mềm (soft-goals graph) (chứa đựng các thông tin

về mối tương quan giữa các thuộc tính chất lượng của phần mềm) sử dụng

để hướng dẫn các quá trình chuyển đổi trong tái cấu trúc [66] Ngoài ra,Tahvildari còn xây dựng một danh mục (catalogue) độ đo hướng đối tượng(object-oriented metrics) như các chỉ thị, sử dụng trong việc tự động pháthiện vị trí một phép toán tái cấu trúc có thể được áp dụng Như vậy, bàitoán đánh giá ảnh hưởng của tiến trình tái cấu trúc được giải quyết thôngqua việc ước lượng (hoặc đo lường) ảnh hưởng của mỗi phép toán tái cấutrúc trên các chỉ số chất lượng của phần mềm

Bài toán thứ hai liên quan đến sự bảo toàn hành vi của phần mềm táicấu trúc cũng bắt nguồn từ định nghĩa của khái niệm này Các khó khănphải đối mặt đối với bài toán này là vấn đề xác định cũng như đặc tả hìnhthức hành vi của phần mềm Kế tiếp là định nghĩa một cách chính xác kháiniệm về bảo toàn hành vi (behaviour preservation) Chú ý rằng, các loạihành vi cần bảo toàn thường phụ thuộc vào đặc trưng của mỗi loại phầnmềm (hệ thống thời gian thực thường quan tâm đến các yếu tố thời gian,các ràng buộc về bộ nhớ và tiêu thụ năng lượng thường áp dụng trên các

hệ thống nhúng, v.v.) Trong một số trường hợp đòi hỏi sự linh hoạt, ngườiphát triển hệ thống buộc phải chấp nhận một số yếu điểm của việc khôngbảo toàn hành vi, tuy nhiên phải đảm bảo rằng điều này không ảnh hưởngđến toàn bộ ngữ nghĩa chung (mục tiêu cần bảo toàn) của phần mềm

Bài toán về bảo toàn hành vi trong tái cấu trúc nhận được nhiều sự quantâm của các nhà nghiên cứu Một số kỹ thuật phổ biến để giải quyết bài toánnày là biến đổi đồ thị (graph transformation) [8, 10,23, 40, 64,73], sử dụngbất biến, tiền và hậu điều kiện (invariants, pre/post-conditions), [52, 58]hoặc cắt lát chương trình (slice program) [42], mô tả hệ thống bằng khungnhìn logic [51] v.v Các nghiên cứu này tập trung kiểm chứng sự bảo toànhành vi chính giai đoạn mã nguồn với nhau, hoặc kiểm tra sự nhất quángiữa các giai khác nhau của tiến trình phát triển phần mềm (giai đoạn thiết

kế với giai đoạn cài đặt mã nguồn)

Bài toán thứ ba, kiểm chứng tính nhất quán trong tái cấu trúc các hệthống phần mềm hiện đang được quan tâm theo hai hướng chính, nhấtquán theo chiều dọc (vertical consistency) và nhất quán theo chiều ngang(horizontal consitency) Nhất quán theo chiều ngang được hiểu là sự nhấtquán giữa các phiên bản khác nhau (phiên bản trước và phiên bản sau tái cấutrúc của một chế tác phần mềm) Nhất quán theo chiều dọc (horizontal) [46]

là sự nhất quán giữa nhiều loại chế tác khác nhau của phần mềm (ví dụ,giữa mô hình thiết kế và bản cài đặt mã nguồn) Bài toán kiểm chứng sựnhất quán trong một số trường hợp lại bao hàm bên trong nó bài toán vềbảo toàn hành vi (ví dụ, phiên bản tái cấu trúc của một chế tác phần mềmbảo toàn hành vi của phiên bản ban đầu cũng được gọi là nhất quán về mặthành vi)

Vấn đề cuối cùng được quan tâm là công cụ hỗ trợ trong tiến trình tái cấutrúc (Tool supports for Refactoring) Các công cụ hỗ trợ cho tiến trình táicấu trúc hệ thống phần mềm được chia thành hai loại chính: (i) tìm kiếm vịtrí tái cấu trúc và (ii) thực hiện tái cấu trúc Hai nhóm công cụ này phù hợpvới nhau một cách khá tự nhiên (một loại tìm kiếm vị trí và một loại thựcthi tác vụ tái cấu trúc) Trong thời gian gần đây, xuất hiện nhiều công cụ hỗtrợ cho tiến trình tái cấu trúc như Refactoring Browser for Smalltalk [57],JRefactory1, Design Pattern Transformer (DPT) [35], Refactorit2, Eclipse3(phát triển môi trường tích hợp), v.v Tuy nhiên, hầu hết các công cụ nàyđều rơi vào loại thứ nhất và chưa có sự xem xét đến vấn đề bảo toàn hành

vi của hệ thống sau tiến trình tái cấu trúc

1 http://jrefactory.sourceforge.net/

2 http://www.refactorit.com/

3 https://eclipse.org/downloads/

Phương pháp hướng đối tượng (Object Oriented Method ) dựa trên kháiniệm cơ sở là lớp (class) [47] Thông thường, lớp được sử dụng để miêu tảmột kiểu dữ liệu trừu tượng, nó biểu diễn một tập hợp các đối tượng (objects)

có cùng các đặc trưng (features) bao gồm thuộc tính (attributes) và hành

vi (thể hiện bằng khái niệm methods) Các đặc trưng của các đối tượng cầnphải được đặc tả một các hình thức bởi các lớp mà nó được khai báo Cáckhẳng định (assertions), bao gồm bất biến của lớp (class invariants), tiềnđiều kiện (pre-conditions) và hậu điều kiện (post-conditions) của phươngthức là các khái niệm đóng vai trò biểu diễn các đặc tả hình thức này Cáckhẳng định này được ứng dụng vào trong hệ thống nhằm đạt một số mụctiêu như tạo ra các phần mềm đáng tin cậy, tài liệu hóa phần mềm một cách

có hệ thống và là công cụ trung tâm để thử nghiệm và gỡ lỗi các phần mềmhướng đối tượng Do đó, cần phải theo dõi sự biến đổi của các đặc trưngnày trong toàn bộ quá trình xây dựng, phát triển và vận hành hệ thống

Tái cấu trúc khi áp dụng vào bất kỳ hệ thống nào cũng dẫn đến nhữngthay đổi tất yếu về cấu trúc của hệ thống đó Do đó, khi thực thi các hoạtđộng tái cấu trúc trên các hệ thống hướng đối tượng sẽ tác động trực tiếpcác đặc trưng về thuộc tính, hành vi của lớp và đương nhiên sẽ dẫn đến cácthay đổi trên các đặc trưng về bất biến của lớp và hành vi (tiền/hậu điềukiện của phương thức) Bởi vậy, luận án tập trung, xem xét giải quyết cácvấn đề về bảo toàn các đặc trưng trên Nói cách khác, luận án xem xét bàitoán bảo toàn ràng buộc bất biến và hành vi trong tiến trình tái cấu trúcphần mềm hướng đối tượng

Như đã phân tích ở trên, các công trình nghiên cứu về kỹ thuật tái cấutrúc trên các hệ thống phần mềm rất đa dạng, phức tạp với với nhiều cáchtiếp cận khác nhau [43, 48] Trong khuôn khổ nghiên cứu, luận án chỉ tậptrung đến bài toán bảo toàn một số ràng buộc (properties preservation) của

hệ thống hướng đối tượng trong tái cấu trúc, cụ thể như sau:

(i) Bài toán bảo toàn các ràng buộc bất biến của lớp (invariants vation) trong tái cấu trúc biểu đồ lớp của UML Các nghiên cứu [53,

preser-54, 64, 71] đã thực hiện tái cấu trúc trên biểu đồ lớp, biểu đồ trạngthái và biểu đồ hoạt động Họ chỉ ra một số phép toán áp dụng trêncác biểu đồ này Nghiên cứu [53] xem xét sự biến đổi các ràng buộcbất biến trên biểu đồ trạng thái Tuy nhiên, đặc điểm chung của các

nghiên cứu này là biểu diễn các phép toán cũng như các luật tái cấutrúc bằng phương pháp không hình thức (informal) hoặc nửa hìnhthức (semi-formal) và mô tả các phép toán bằng ngôn ngữ tự nhiên.Điều này không chỉ dẫn đến sự thiếu chính xác trong quá trình thựcthi mà còn khó khăn trong việc xây dựng các công cụ hỗ trợ kiểmchứng Ngoài ra, chưa có nghiên cứu nào thực sự đi sâu và xem xét sựbiến đổi của các ràng buộc bất biến khi thực hiện tái cấu trúc biểu đồlớp.

(ii) Bài toán kiểm chứng sự bảo toàn hành vi (behaviors preservation)trong tái cấu trúc các hệ thống phần mềm Các nghiên cứu chuyên sâu

về bài toán bảo toàn hành vi [8, 10, 23, 40, 42, 51, 52, 58, 64, 73] đượcthực hiện trên bản phân tích thiết kế (biểu đồ lớp, biểu đồ trạng thái,v.v.) hoặc bản cài đặt chương trình phần mềm Khái niệm hành vi mà

họ quan tâm bao gồm các hoạt động như bảo toàn quyền truy cập(access) vào cơ sở dữ liệu, lời gọi hàm (method call), cập nhật (update)các biến (các biến có khả năng cập nhật phải được bảo toàn sau táicấu trúc), v.v Hoặc họ tiến hành kiểm chứng tính nhất quán giữa cácgiai đoạn khác nhau (giữa thiết kế và cài đặt, v.v.) trong tái cấu trúc

Vì vây, mục tiêu của luận án “Một số phương pháp kiểm chứng táicấu trúc phần mềm” hướng đến tập trung đề xuất một số phương phápbảo toàn các ràng buộc trên hệ thống hướng đối tượng, cụ thể là các ràngbuộc về bất biến của lớp và ràng buộc về hành vi của kịch bản trong tiếntrình tái cấu trúc Phương pháp tiếp cận của luận án là hình thức hóa cácthành phần của hệ thống và xây dựng cơ sở lý thuyết nhằm bảo đảm sự bảotoàn các ràng buộc này khi thực thi tiến trình tái cấu trúc

Đối tượng nghiên cứu của luận án là kỹ thuật tái cấu trúc áp dụng trên

mô hình thiết kế, bản cài đặt chương trình phần mềm và các đặc trưng của

hệ thống Cụ thể, luận án quan tâm đến biểu đồ lớp, biểu đồ tuần tự, bảncài đặt chương trình phần mềm và các ràng buộc về bất biến (trên thuộctính của lớp), các ràng buộc về hành vi (tiền/hậu điều kiện của các phươngthức) Các thành phần này được hình thức hóa và xem xét sự bảo toàn củacác khẳng định trong tiến trình tái cấu trúc

1.2 Nội dung nghiên cứu

Các kết quả nghiên cứu của luận án góp phần bổ sung và hoàn thiệncác giải pháp nâng cao chất lượng của hệ thống phần mềm khi áp dụng kỹthuật tái cấu trúc Cụ thể, luận án có các đóng góp chính sau đây:

(i) Đề xuất phương pháp bảo toàn bất biến của lớp trong tái cấu trúc môhình UML Các thành phần của biểu đồ lớp cùng với các ràng buộcbất biến được hình thức hóa Tiến trình tái cấu trúc biểu đồ lớp củaUML được thực hiện thông qua năm phép toán Folding, Abstraction,Composition, Factoring và Unfolding Luận án đã đề xuất các luật táicấu trúc cho các phép toán và chứng minh sự bảo toàn bất biến củatiến trình tái cấu trúc bằng cách áp dụng các phép toán này

(ii) Đề xuất phương pháp bảo toàn hành vi trong tái cấu trúc tại các giaiđoạn thiết kế và cài đặt phần mềm Đối tượng xem xét sự bảo toànhành vi trong tái cấu trúc là các biểu đồ tuần tự (còn gọi là kịch bản-scenarios) tham gia vào tiến trình tái cấu trúc Trước và sau khi táicấu trúc, các ràng buộc về hành vi (tiền/hậu điều kiện của kịch bản)được tính toán và so sánh, từ đó đưa ra kết luận về sự bảo toàn hành

vi của các kịch bản này và đưa ra kết luận cuối cùng về sự bảo toànhành vi của hệ thống Chú ý rằng, trong bài toán này luận án đặc biệtquan tâm đến tiến trình tái cấu trúc có sử dụng mẫu thiết kế, cụ thể

là mẫu Strategy (một mẫu thuộc về nhóm các mẫu hành vi của nhómGoF [67])

(iii) Xây dựng công cụ CVT hỗ trợ kiểm chứng tính nhất quán về mặt hành

vi của mô hình phần mềm Công cụ CVT nhận đầu vào các mô hìnhphần mềm trước và sau khi tái cấu trúc cùng với các ràng buộc vềhành vi (biểu diễn bằng biểu thức OCL) và trả lại kết luận về sự nhấtquán giữa hai mô hình này

Đóng góp (i) của luận án tập trung giải quyết bảo toàn các ràng buộcbất biến (các ràng buộc liên quan đến các thuộc tính của lớp) của mô hìnhphần mềm Đóng góp (ii) liên quan đến khía cạnh bảo toàn hành vi (cácràng buộc liên quan đến các phương thức), đây là hai loại ràng buộc cơ bản

về ngữ nghĩa đối với các hệ thống phần mềm Như vậy, các đóng góp (i) và(ii) thể hiện sự thống nhất về mặt lý thuyết và được sử dụng bổ trợ cho

nhau trong thực nghiệm để hướng đến cải thiện chất lượng phần mềm mộtcách tốt nhất có thể Đóng góp (iii) minh chứng cho sự khả thi của phươngpháp đề xuất trong thực tiễn.

Luận án “Một số phương pháp kiểm chứng tái cấu trúc phần mềm” baogồm 6 chương Trong đó Chương 1 Mở đầu trình bày về lý do chọn đề tài,đối tượng và nội dung nghiên cứu của luận án Các chương còn lại được tổchức như trong Hình 1.1, cụ thể như sau:

1 được sử dụng như cơ sở lý thuyết trung gian để biểu diễn các ràng buộctrong tiến trình xây dựng công cụ kiểm chứng ở Chương 5.

Chương 3Phương pháp bảo toàn bất biến trong tái cấu trúc Chương này

đề xuất phương pháp bảo toàn các bất biến của lớp trong tái cấu trúc môhình phần mềm Biểu đồ lớp và ràng buộc về bất biến của lớp được hìnhthức hóa bằng các công thức logic vị từ cấp 1 Tái cấu trúc trên biểu đồ lớpđược thực hiện thông qua năm phép toán liên quan đến quan hệ phân cấptrong kế thừa

Chương 4 Phương pháp kiểm chứng sự bảo toàn hành vi trong tái cấutrúc Chương này trình bày các phương pháp kiểm chứng tính nhất quán

về mặt hành vi của hệ thống phần mềm trong tái cấu trúc tại các pha thiết

kế và cài đặt chương trình Tái cấu trúc được thực hiên bằng cách áp dụngmẫu thiết kế Strategy Tại giai đoạn thiết kế, hệ thống được mô hình hóabằng UML và đặc tả hành vi bằng OCL Tại giai đoạn cài đặt, hệ thốngđược mã hóa bằng ngôn ngữ lập trình Java và đặc tả hành vi bằng JML.Quy trình kiểm chứng được đề xuất áp dụng chung cho cả hai giai đoạnthiết kế và cài đặt Các ràng buộc hành vi của các hệ thống khởi đầu và hệthống sau tái cấu trúc sẽ được kiểm tra tính nhất quán thông qua các tậpluật đã được xây dựng

Chương 5 Công cụ kiểm chứng Luận án đưa ra kiến trúc và quá trìnhcài đặt thực nghiệm công cụ kiểm chứng CVT (Consitency Validator Tool),

hỗ trợ trong kiểm chứng tính nhất quán của mô hình phần mềm trong táicấu trúc Các mô hình trước và sau khi tái cấu trúc cùng với các ràng buộchành vi là các dữ liệu đầu vào của công cụ Sau quá trình thực thi, CVT sẽtrả lại kết quả cuối cùng về khả năng nhất quán về mặt hành vi giữa môhình phần mềm

Cuối cùng, Chương 6Kết luận và hướng phát triển Chương này sẽ phântích về tất cả các phương pháp kiểm chứng đã đề xuất cũng như ưu nhượcđiểm của các phương pháp này Luận án cũng thảo luận về các nghiên cứutrong tương lai từ các kết quả ban đầu đã đạt được

KIẾN THỨC CƠ SỞ

Trong chương này, luận án sẽ trình bày về những kiến thức cơ sở được sửdụng trong các chương tiếp theo Mở đầu, Mục 2.1, 2.2 sẽ làm rõ khái niệmtái cấu trúc cũng như các bước áp dụng kỹ thuật tái cấu trúc trên chế tácphần mềm và các khái niệm khóa của mô hình hướng đối tượng được sử dụngtrong luận án Các mục tiếp theo, luận án sẽ lần lượt mô tả về ngôn ngữ

mô hình hóa thống nhất UML (Unified Modeling Language), mẫu thiết kế(Design Pattern), ngôn ngữ ràng buộc đối tượng OCL (Object ConstraintLanguage), ngôn ngữ đặc tả cho Java JML (Java Modeling Language) vàcuối cùng là logic vị từ cấp 1 FOL (First-Order Logic) Chú ý rằng, trongchương này luận án đề cập đến các khái niệm quan trọng như biểu đồ lớp(Class diagram), lớp (Class), thuộc tính (attribute), phương thức (methods),bất biến của lớp (class invariants), tiền/hậu điều kiện (pre/post-conditions)của phương thức, v.v Tuy nhiên, do nội dung và phương pháp nghiên cứucủa các Chương 3và 4 là khác nhau nên các khái niệm này cũng được biểudiễn hình thức theo các cách khác nhau nhằm mục tiêu tạo sự phù hợp vớiphương pháp nghiên cứu được đề xuất ở từng chương

Tái cấu trúc (refactoring) “là sự thay đổi cấu trúc bên trong nhằm mụctiêu làm cho nó trở nên dễ hiểu và dễ sửa đổi hơn mà không làm thay đổihành vi có thể quan sát được của hệ thống phần mềm” Ý tưởng chính củatái cấu trúc là phân bố lại các lớp (classes), các thuộc tính (attributes) và các

9

phương thức (methods) xung quanh mối quan hệ phân cấp giữa các thànhphần này [27].

Tái cấu trúc thường được thực hiện theo từng bước nhỏ, mỗi bước nhỏnày đều được chứng minh sự bảo toàn về mặt hành vi Sự kết hợp nhiềubước nhỏ sẽ tạo thành một tiến trình tái cấu trúc phức hợp mà vẫn bảotoàn được các hành vi bên ngoài của hệ thống Mục tiêu của tái cấu trúcluôn luôn là sự tương đương (về ngữ nghĩa hoặc hành vi) của hệ thống banđầu với phiên bản tái cấu trúc của nó Tuy nhiên, trong một số trường hợpcần sự linh hoạt, tái cấu trúc chỉ cần bảo toàn một số hành vi mong muốncủa hệ thống

Tái cấu trúc trên hệ thống phần mềm mang lại một số lợi ích như giúpcải thiện thiết kế của hệ thống, làm cho phần mềm trở nên dễ hiểu hơn,giúp tìm ra lỗi của hệ thống và làm tăng hiệu quả thực thi của chương trìnhphần mềm [27]

Về mặt kỹ thuật, tái cấu trúc có nguồn gốc từ toán học khi thực hiệnbiến đổi các biểu thức tương đương (thay đổi các nhân tố biểu diễn làm chobiểu thức trở nên rõ ràng hơn) Bởi vậy, tái cấu trúc ẩn bên trong nó ngụ

ý tương đương; nói cách khác trước và sau khi tái cấu trúc chức năng củaphần mềm phải giống nhau

Kỹ thuật tái cấu trúc khi mới ra đời được giới thiệu để áp dụng trên mãnguồn của phần mềm, tuy nhiên, theo thời gian kỹ thuật này được thực thitrên hầu hết các chế tác (artifact ) khác nhau của hệ thống phần mềm như

mô hình thiết kế, lược đồ cơ sở dữ liệu, bản phân tích yêu cầu phần mềm,

hệ thống cần phải xác định vị trí nào trên chế tác sẽ được tác độnghoạt động tái cấu trúc;

(2) Xác định phép toán tái cấu trúc sẽ được tiến hành đối với vị trí trên.Tiến trình tái cấu trúc bao gồm bên trong nó rất nhiều hoạt động khác

nhau, bởi vậy cần phải xác định rõ loại hoạt động tái cấu trúc được

áp dụng trên vị trí đã xác định trong bước (1);

(3) Đảm bảo rằng tiến trình tái cấu trúc bảo toàn hành vi của hệ thống.Mục tiêu cuối cùng của tiến trình tái cấu trúc là cải thiện cấu trúc bêntrong nhưng không làm ảnh hưởng đến hành vi bên ngoài Bởi vậy, saumỗi khi thực hiện tiến trình bằng cách thức nào đó phải chỉ ra sự bảotoàn các hành vi mong muốn của hệ thống;

(4) Thực thi tiến trình tái cấu với vị trí và kỹ thuật tái cấu trúc đã đượcxác định tại các bước (1) và bước (2) Thực hiện các hoạt động tái cấutrúc trên các thành phần phần mềm;

(5) Đánh giá ảnh hưởng của tiến trình tái cấu trúc trên các đặc trưng vềchất lượng phần mềm Sự cải thiện chất lượng của hệ thống phần mềmđược đánh giá thông qua các chỉ tiêu như tính phức hợp, khả nănghiểu được, khả năng bảo trì, v.v hoặc sự cải thiện các tiến trình nhưgiá thành, công sức, năng suất;

(6) Duy trì sự nhất quán giữa các chế tác khác phần mềm với nhau Hệthống phần mềm có rất nhiều chế tác khác nhau, khi thực hiện tái cấutrúc trên một chế tác phần mềm thì phải đảm bảo sự nhất quán của

nó đối với các chế tác còn lại

Quy trình tái cấu trên áp dụng đối với tất cả các chế tác phần mềm đượctái cấu trúc, tuy nhiên, mỗi hoạt động này có thể được hỗ trợ bởi rất nhiềucông cụ, kỹ thuật hoặc phương pháp hình thức hóa khác nhau nhằm manglại hiệu quả cao nhất cho tiến trình tái cấu trúc

Tiến trình tái cấu trúc bao gồm bên trong nó rất nhiều hoạt động khácnhau, Flower [27] đã trình bày một danh mục khá đầy đủ các phép tái cấutrúc Dựa trên tiêu chí về độ phức tạp (complexity), ông cũng phân loại cácphép toán tái cấu trúc vào hai nhóm chính: (i) nhóm các phép tái cấu trúcnguyên thủy (Primitive Refactoring) và (ii) nhóm các phép tái cấu trúcphức hợp (Composite Refactoring) Nhóm các phép tái cấu trúc nguyênthủy thường đề cập đến các hoạt động khá đơn giản như MoveAttribute,MoveAssociationEnd, PushDownAttribute, RenameAttribute, ExtractClass,ExtractSuperclass, PullUpMethod, v.v Các hoạt động này đã được chứngminh là các biến đổi bảo toàn hành vi (behavior-preserving) trong tiến trìnhtái cấu trúc [45] Nhóm các phép tái cấu trúc còn lại liên quan quan đến

các hoạt động phức tạp hơn và được cấu thành từ sự kết hợp các phép táicấu trúc nguyên thủy theo các cách khác nhau [14] như tuần tự (chaining)hoặc lặp (iteration) Nói cách khác, các phép tái cấu trúc phức hợp thườngđược tạo ra từ một tập có thứ tự các phép tái cấu trúc nguyên thủy.

Như vậy, các hoạt động tái cấu trúc rất đa dạng và phức tạp, việc ápdụng các phép toán nào trên những chế tác phần mềm nào là một trongnhững thử thách và phụ thuộc vào các yếu tố như kinh nghiệm và tầm nhìncủa người phát triển hệ thống

Mô hình hướng đối tượng biểu diễn một hệ thống có tính logic của cácđối tượng có trong thế giới thực cùng với các ràng buộc của các đối tượngnày và các mối quan hệ tương quan giữa chúng [11] Mô hình hướng đốitượng thường được biểu diễn bởi biểu đồ lớp trong UML (mô tả cấu trúctĩnh của hệ thống) và được tạo thành từ các phần tử chính sau đây:

(1) Lớp: là tập hợp các đối tượng có cùng các thuộc tính (attributes) vàphương thức (methods) Mỗi đối tượng phải thuộc về một lớp nào đó

và là một thể hiện của lớp đó Trong lập trình hướng đối tượng, câulệnh khai báo ra một lớp mới tương đương với việc tạo ra môt kiểu

dữ liệu trừu tượng hoặc một kiểu dữ liệu nguyên thủy (kiểu số nguyên(integer), kiểu xâu (string), hay kiểu logic, v.v)

– Thuộc tính (Attributes): dùng để biểu diễn các thông tin hữu íchcủa các thể hiện của một lớp (tập hợp các giá trị của các thuộctính của các đối tượng trong lớp và gọi là trạng thái của đối tượng(state))

– Phương thức (Methods): dùng để biểu diễn hành vi (behavior )của lớp (các phương thức thường thao tác trên trạng thái của đốitượng)

(2) Mối quan hệ giữa các lớp: trong mô hình hướng đối tượng, các lớpthường tương tác với nhau theo những cách riêng và bao gồm rất nhiềuloại liên kết logic Trong luận án này, chúng tôi quan tâm đến một sốloại liên kết sau đây:

– Kết hợp (Association): là một quan hệ cấu trúc mô tả một tậphợp các liên kết (links), mỗi liên kết tạo ra sự kết nối giữa các đốitượng;

– Tụ hợp (Aggregation): là dạng đặc biệt của kết hợp, diễn đạt choquan hệ cấu trúc giữa một tổng thể và các bộ phận của nó;– Hợp thành (Composition): là dạng đặc biệt của tụ hợp, trong đónếu đối tượng tổng thể bị hủy bỏ thì các đối tượng bộ phận của

nó cũng bị hủy bỏ theo;

– Hiện thực hóa (Realization): là quan hệ ngữ nghĩa giữa các phânlớp (classifiers), trong đó một phân lớp sẽ đặc tả cam kết mà phânlớp kia phải đảm bảo đáp ứng và thực thi Quan hệ hiện thực hóa

mà chúng ta thường gặp là quan hệ giữa các giao diện và lớp haythành phần thực thi, hoặc quan hệ giữa các ca sử dụng và cáccộng tác hiện thực hóa chúng;

– Tổng quát hóa (Generalization): là loại quan hệ đặc biệt hóa/kháiquát hóa trong đó các đối tượng của phần tử đặc biệt hóa là cóthể được thay thế bởi các đối tượng của phần tử khái quát hóa.Theo cách này, phần tử con sẽ kế thừa và chia sẻ cấu trúc và hành

đồ lớp được phân thành ba loại như sau:

– Bất biến của lớp (Class invariants): là ràng buộc định nghĩa trêncác thuộc tính của lớp và phải được thỏa mãn bởi bất kì một thểhiện nào của lớp;

– Tiền điều kiện của phương thức (Pre-condition of a method ): làđiều kiện mà phương thức cần phải thỏa mãn trước khi nó đượcthực hiện;

– Hậu điều kiện của phương thức (Post-condition of a method ): làđiều kiện mà phương thức cần phải thỏa mãn sau khi nó đượcthực hiện;

Một cách ngắn gọn, có thể nói rằng một mô hình hướng đối tượng baogồm nhiều lớp đối tượng, các mối quan hệ giữa các lớp đối tượng này vànhững ràng buộc được áp dụng trên chúng

Các hệ thống hướng đối tượng thường được biết đến với ưu điểm lớn làkhả năng tái sử dụng các thành phần phần mềm trong các giai đoạn pháttriển tiếp theo của chính phần mềm đó Điều này làm cho kỹ thuật tái cấutrúc trở nên đặc biệt phù hợp với các hệ thống hướng đối tượng vì sự hỗtrợ một cách tự nhiên của các hệ thống này đối với các hoạt động tái cấutrúc [5]

Ngôn ngữ mô hình hóa thống nhất UML (Unified Modeling Language) [60]

là một chuẩn ngôn ngữ, phiên bản đầu tiên 0.9 ra đời vào năm 1997 bởi

sự hợp nhất của các phương pháp: phương pháp của Grady Booch [69],

kỹ thuật mô hình hóa đối tượng (Object Modeling Technique - OMT) củaJames Rumbaugh [59] và kỹ nghệ phần mềm hướng đối tượng (Object-Oriented Software Engineering - OOSE) của Ivar Jacobsen [31] UML đượccông nhận là chuẩn ISO (International Organization for Standardization)bởi tổ chức OMG (Object Management Group) vào năm 2005 UML baogồm một tập các ký pháp đồ họa thống nhất được sử dụng rộng rãi, hiệuquả trong việc đặc tả và thiết kế các hệ thống phần mềm theo phương pháphướng đối tượng [9, 41] Mô hình hóa hệ thống bằng UML giúp người pháttriển hệ thống có được cái nhìn trực quan, dễ dàng xác định được các thànhphần chính, cấu trúc tĩnh cũng như các hành vi động của hệ thống

Phiên bản mới nhất của UML là 2.5 phát hành vào năm 2015 và bổ sungnhiều loại biểu đồ hơn so với các phiên bản UML trước đây Hình 2.1 mô tảtổng quan các loại biểu đồ trong UML 2.5 [61] Các biểu đồ này được phânloại thành hai nhóm chính: (1) nhóm các biểu đồ mô tả cấu trúc (structurediagram) và (2) nhóm các biểu đồ mô tả hành vi (behavior diagram) Nhómcác biểu đồ cấu trúc được sử dụng để mô tả các khía cạnh tĩnh (static) của

hệ thống, các khía cạnh này biểu diễn các thành phần của biểu đồ và tạothành cấu trúc chính của hệ thống Các biểu đồ lớp (class diagram), biểu đồđối tượng (object diagram), biểu đồ gói (package diagram) và một số biểu

đồ khác như phía bên trái của Hình 2.1 [61] thuộc về nhóm các biểu đồ cấutrúc Nhóm các biểu đồ mô tả khía cạnh động (dynamic) của hệ thống làcác biểu đồ hành vi, bao gồm các biểu đồ tiêu biểu là biểu đồ ca sử dụng(use case diagram), biểu đồ tương tác (interaction diagram), biểu đồ trạngthái (state diagram) và biểu đồ hoạt động (activity diagram) Các biểu đồnày cho phép trực quan hóa, đặc tả, xây dựng và tài liệu hóa các hoạt độngbiểu diễn hành vi của hệ thống phần mềm

Trong tiểu mục này, luận án trình bày chi tiết hai biểu đồ tiêu biểu trongUML là biểu đồ lớp và biểu đồ tuần tự Biểu đồ lớp thuộc về nhóm các biểu

đồ cấu trúc và biểu đồ tuần tự thuộc về nhóm các biểu đồ hành vi, đây làcác biểu đồ được sử dụng trong các Chương 3, 4 của luận án

2.3.1 Biểu đồ lớp

Biểu đồ lớp (Class Diagram-CD ) [60] được sử dụng để biểu diễn khungnhìn tĩnh (static view ) của hệ thống Khung nhìn tĩnh là nền tảng cơ bảncủa UML Các phần tử của khung nhìn tĩnh của mô hình là các khái niệmtrong miền ứng dụng, bao gồm các khái niệm thế giới thực, các khái niệmtrừu tượng, các khái niệm cài đặt, các khái niệm máy tính và nhìn chung làtất cả các khái niệm xuất hiện trong hệ thống phần mềm

Khung nhìn tĩnh phản ánh cấu trúc đối tượng của hệ thống Cấu trúc dữliệu và các hành vi được thống nhất trong cấu trúc đối tượng Khung nhìntĩnh mô tả các khai báo hành vi dưới dạng khai báo các thao tác Phần tửchính trong khung nhìn tĩnh là các phân lớp (lớp, giao diện và kiểu dữ liệu)

và quan hệ giữa chúng (quan hệ kết hợp, quan hệ tổng quát hóa và quan

hệ phụ thuộc) Trong khung nhìn này, mỗi đối tượng là một đơn vị cơ bảnlàm nên hệ thống và gói là đơn vị tổ chức chung để quản lý các nội dungcủa mô hình Hình 2.2minh họa các khái niệm cơ bản của biểu đồ lớp trongUML [61]

Hình 2.1: Tổng quan về các loại biểu đồ trong UML 2.5

2.3.2 Biểu đồ tuần tự

Biểu đồ tuần tự (Sequence Diagram - SD ) tập trung vào trình tự thờigian của các thông điệp [60] Nó biểu diễn tương tác ở dạng biểu đồ haichiều Chiều dọc là trục thời gian, tính từ trên xuống Chiều ngang chỉ racác vai trò của đối tượng tham gia cộng tác Mỗi vai trò được tái hiện bởimột cột dọc gồm hai phần, phần tiêu đề thường là phần khai báo thể hiệnlớp và phần đường thẳng dọc gọi là đường chu kỳ sống (lifeline) Thời giantồn tại của đối tượng được biểu diễn bằng đường nét đứt Trong khoảng thờigian thực hiện của một thủ tục đối tượng, đường chu kỳ sống sẽ là đườngnét đôi

Hình 2.2: Minh họa biểu đồ lớp trong UML

Một thông điệp được biểu diễn ở dạng đường mũi tên từ đường chu kỳsống của một đối tượng gửi đến đối tượng nhận Các mũi tên này được sắpxếp theo trình tự thời gian từ trên xuống Khác với các thông điệp đồng bộ,các thông điệp không đồng bộ sẽ được biểu diễn bằng đường mũi tên ở đầukhông được tô đặc

Hình2.3[61] minh họa biểu đồ tuần tự và luận án còn sử dụng khái niệmkịch bản (scenario) để tham chiếu đến biểu đồ tuần tự trong UML

Christopher Alexander là người đầu tiên đưa ra khái niệm về mẫu thiết

kế (design pattern) [2] Ông định nghĩa về mẫu thiết kế như sau, “Mỗi mẫu

Hình 2.3: Minh họa biểu đồ tuần tự trong UML

thiết kế mô tả giải pháp để xử một vấn đề xảy ra một cách phổ biến trongmôi trường thế giới thực Bởi vậy, mẫu thiết kế cho phép các nhà phát triểnphần mềm có thể sử dụng lại các giải pháp này cả triệu lần” Như vậy, đốivới một tình huống phát sinh có tính chất thường xuyên (lặp đi lặp lại)trong quá trình sử dụng phần mềm, các mẫu thiết kế cung cấp một khuônmẫu chung để giải quyết nó Nói cách khác, mẫu thiết kế cung cấp giải phápcho các vấn đề thiết kế phổ biến thường gặp trong lập trình, cụ thể là cácvấn đề về kế thừa và tương tác nói chung Mẫu thiết kế không sử dụng để

xử lý các vấn đề về kiến trúc tổng thể trong quy mô lớn của toàn bộ môhình phần mềm

Ưu điểm của các mẫu thiết kế là khả năng tái sử dụng, dễ mở rộng vàbảo trì Thực tế đã chứng minh, một phần mềm với một kiến trúc khôngtốt, khi gặp vấn đề phát sinh, người phát triển sẽ phải dành nhiều thời gian,thậm chí là nhiều hơn cả thời gian bỏ ra xây dựng, chỉ là để sửa chữa chúng

Các mẫu thiết kế được trình bày một cách chi tiết và đầy đủ trong cuốnsách của bộ tứ GOF [28] và được phân loại thành ba nhóm chính, cụ thể là:(i) nhóm các mẫu khởi tạo (creational patterns), (ii) nhóm các mẫu cấu trúc(structural patterns) và (iii) nhóm các mẫu hành vi (behavioral patterns)

Nhóm mẫu đầu tiên, cung cấp cách thức để tạo ra một hoặc nhóm đối tượng.Các mẫu trong nhóm thứ hai dùng để thiết lập, định nghĩa quan hệ giữacác đối tượng Nhóm mẫu cuối cùng xác định cách cư xử giao tiếp giữa cáclớp và các đối tượng.

Nhóm các mẫu khởi tạo (creational patterns) bao gồm Factory, AbstractFactory, Singleton, Prototype, Builder Các mẫu này giải quyết vấn đề tạolập các đối tượng sao cho phù hợp với mục đích của từng tình huống cụ thể.Kết quả của việc sử dụng các mẫu thuộc nhóm này là sự tách biệt hệ thốngvới các đối tượng (tạo lập, sáng tác, và biểu diễn đối tượng) Chúng làmtăng tính linh hoạt của hệ thống về những gì, ai, như thế nào, và khi nàocác đối tượng được sáng tạo

Các mẫu Adapter, Fa¸cade, Proxy, Composite, v.v thuộc về nhóm mẫucấu trúc (structural patterns) Các mẫu này được sử dụng để kết hợp cáclớp và các đối tượng đơn lẻ trở thành các lớp và đối tượng có cấu trúc

Nhóm mẫu cuối cùng là nhóm các mẫu hành vi (behavioral patterns),bao gồm các mẫu Chain of responsibility, Command, Mediator, Strategypattern, v.v Các mẫu này này được sử dụng để xác định giao thức truyềnthông chung giữa các đối tượng bằng cách hiện thực hóa chúng Sử dụng cácmẫu trong nhóm hành vi làm tăng tính linh hoạt của hệ thống trong việcthực hiện giao tiếp giữa các lớp và đối tượng Hình 2.4 mô tả mẫu Strategy

và mối quan hệ của nó với một số mẫu thiết kế khác [67]

Hình 2.4: Một số mẫu thiết kế

Luận án sẽ trình bày chi tiết một mẫu trong nhóm hành vi, cụ thể làmẫu Strategy, mẫu này được áp dụng vào trong tiến trình tái cấu trongChương 4 Mẫu Strategy “Định nghĩa một tập hợp các thuật toán, đóng gói

chúng thành từng loại và có thể hoán đổi cho nhau” Mẫu Strategy thựcthi các thuật toán một cách linh hoạt, tùy thuộc vào ngữ cảnh cụ thể Ýnghĩa thực sự của Strategy là tách rời phần xử lý một chức năng ra khỏiđối tượng Sau đó tạo ra một tập hợp các thuật toán để xử lý chức năng đó

và cho phép lựa chọn thuật toán đúng đắn nhất khi thực thi chương trình.Mẫu Strategy thường được sử dụng để thay thế cho sự kế thừa, khi muốnchấm dứt việc theo dõi và chỉnh sửa một chức năng qua nhiều lớp con

Hình 2.5: Mẫu thiết kế Strategy

Mẫu Strategy bao gồm các thành phần sau:

– IStrategy: Giao diện (Interface) được chia sẻ giữa các lớp con cụ thểtrong họ các thuật toán Lớp Context sử dụng giao diện để gọi đến cácthuật toán đã được định nghĩa trong các lớp con;

– ConcreteStrategy: Nơi các thuật toán được cài đặt cụ thể;

– Context : Lớp dùng để tham chiếu đến kiểu ISstrategy Trong một sốtrường hợp, Context có thể cài đặt các phương thức, bởi vậy các lớpConcreteStrategy có thể truy cập đến các dữ liệu này

Sự hợp tác giữa các thành phần trong mẫu Strategy:

– IStrategy và Context tương tác để thực hiện việc lựa chọn các thuậttoán Một Context có thể truyền tất cả các dữ liệu cần thiết bằng cácthuật toán đến IStrategy Ngoài ra, Context có thể truyền chính nónhư là một đối số cho các hoạt động của IStrategy Điều đó cho phépIStrategy gọi lại Context khi cần thiết;

– Một Context chuyển tiếp yêu cầu từ máy khách (client) đến các tegy của nó Máy khách thường tạo và truyền đối tượng ConcreteStra-tegy đến Context ; sau đó, nó tương tác riêng với Context Thường cómột gia đình các lớp ConcreteStrategy để máy khách lựa chọn

IStra-Ưu điểm của việc sử dụng mẫu Strategy là đóng gói các thuật toán trongcác lớp riêng biệt, điều này sẽ làm cho việc sử dụng lại mã được thuận tiệnhơn nhiều và do đó, hành vi của lớp Context có thể thay đổi một cách linhhoạt tại thời điểm chạy chương trình.

Constraint Language)

Ngôn ngữ ràng buộc đối tượng OCL (Object Constraint Language) rađời nhằm mục tiêu khắc phục các hạn chế của UML trong việc biểu diễnmột cách chính xác các khía cạnh chi tiết của bản thiết kế hệ thống [21].OCL được phát triển lần đầu bởi tổ chức IBM vào năm 1995 và được tíchhợp vào UML năm 1997

Thời gian đầu, OCL chỉ được sử dụng như là một ngôn ngữ ràng buộcđối tượng bổ sung cho UML, tuy nhiên nó nhanh chóng được mở rộng phạm

vi và trở thành một thành phần quan trọng trong bất kỳ kỹ nghệ hướng môhình nào OCL được coi như một ngôn ngữ mặc định dùng biểu diễn cáctruy vấn trên mô hình hoặc siêu mô hình, thực hiện và đặc tả các yêu cầu.OCL cũng thường được sử dụng để mô tả các phép biến đổi mô hình (như

là một phần của các mô hình nguồn và mô hình đích trong các quy tắc biếnđổi), biểu diễn sự hợp lệ của các quy tắc (như là một phần của định nghĩađặc tả các miền mới), hoặc các mẫu sản sinh mã nguồn (mô tả các mẫu vàquy tắc sản sinh mã), v.v Để đáp ứng các mục tiêu này, OCL được pháttriển và phát hành một số các phiên bản OCL được phát triển như là mộtchuẩn công nghiệp bởi tổ chức Object Management Group1 (OMG) [12].Phiên bản mới nhất của OCL là 2.4 được ra đời vào năm 2014, phiên bảnnày tương thích với phiên bản 2.4.1 của UML

Mỗi biểu thức trong OCL đều xác định một kiểu nhất định (kiểu này

có thể được định nghĩa trước trong OCL hoặc là một kiểu được định nghĩatrong mô hình với các ràng buộc được mô tả bởi OCL) Kiểu của các biểuthức trong OCL cũng phải phù hợp với các quy tắc và các phép toán được

áp dụng trên kiểu đó Chú ý rằng OCL chỉ là một ngôn ngữ đặc tả thuầntúy, bởi vậy khi các biểu thức OCL được thực thi, nó không gây bất cứ ảnh

1 http://www.omg.org/

hưởng nào đến trạng thái của mô hình phần mềm mà nó đặc tả Ngoài ra,tất cả các vấn đề liên quan đến cài đặt cũng nằm ngoại phạm vi và khôngthể biểu diễn bằng OCL OCL có thể được sử dụng để mô tả nhiều loại ràngbuộc khác nhau trong mô hình UML, sau đây là một số loại ràng buộc tậptrung chủ yếu vào tác dụng của nó trên biểu đồ lớp:

– Biểu diễn các ràng buộc bất biến của lớp (class invariants);

– Khởi tạo giá trị cho thuộc tính của các biến trong biểu thức OCL;– Biểu diễn cách tính giá trị của các phần tử dẫn xuất dựa trên giá trịcủa các phần tử nguồn;

– Thực hiện các câu lệnh truy vấn;

– Biểu diễn tiền/hậu điều kiện (pre/post-conditions) của các phươngthức có trong mô hình

Các khả năng biểu diễn trên của OCL sẽ lần lượt được cụ thể hóa nhưsau:

OCL được dùng để biểu diễn các ràng buộc bất biến riants): Các ràng buộc toàn vẹn trong OCL được biểu diễn dưới dạng cácbất biến được định nghĩa trong một Context cụ thể, với tên của Context

(Inva-là kiểu của ràng buộc Phần thân của context, (Inva-là các điều kiện logic (sau

từ khóa inv) phải được kiểm tra và thỏa mãn bởi tất cả các thể hiện của

Context đó

Các bất biến là các biểu thức được sử dụng phổ biến nhất trong OCL vì

nó cho phép các nhà thiết kế dễ dàng đặc tả tất cả các loại điều kiện mà hệthống phải tuân thủ Ngoài ra, bất biến còn có thể hạn chế giá trị của cácđối tượng đơn lẻ Biểu thức dưới đây phát biểu rằng, tất cả các quotesphải

có giá trị dương Chú ý rằng biến self đại diện cho một thể hiện tùy ý củalớp Quote và dấu chấm được sử dụng để truy cập vào các tính chất (thuộctính hoặc phương thức) của biến self trong lớp Quote Tất cả các thể hiệncủa lớp Quote phải được đánh giá là thỏa mãn bất biến này và biến (self)đương nhiên cũng phải thỏa mãn ràng buộc bất biến đó

1 context Quote inv QuoteOverZero: self.value > 0

OCL sử dụng để khởi tạo giá trị cho thuộc tính của các biến:OCL có thể được sử dụng để khởi tạo giá trị ban đầu cho các thuộc tính của

một đối tượng khi đối tượng đó được tạo ra Để thực hiện công việc này,kiểu của biểu thức OCL khởi tạo và kiểu của thuộc tính được dùng khởi tạophải phù hợp với nhau.

Biểu thức OCL sau đây khởi tạo giá trị là falsecho thuộc tínhpremium

củaCustomer(trạng thái của premiumsẽ được chuyển thành truekhi kháchhàng đã thuê một số xe)

1 context Customer::premium: boolean init: false

Biểu thức OCL xác định các quy tắc tính toán giá trị của cácthuộc tính trong mô hình dẫn xuất: các phần tử dẫn xuất là các phần

tử mà có giá trị được suy dẫn từ các giá trị của các phần tử thuộc vào môhình nguồn OCL là một lựa chọn phổ biến cho việc xác định các quy tắcdẫn xuất này

Hãy xem xét quy tắc sau đây cho việc chiết khấu các phần tử dẫn xuất

từ lớp Customer, phát biểu rằng các khách hàngs có trạng thái của thuộctínhpremiumlàtruethì được hưởng 30%, các khách hàng có trạng thái củathuộc tínhpremiumlà falsevà có ít nhất 5 chiếc xe cho thuê thì được giảmgiá 15%, còn lại tất cả các khách hàng khác đều không được giảm giá

1 context Customer::discount: integer derive:

2 if not self.premium then

Câu lệnh truy vấn: biểu thức OCL dạng này thực hiện truy vấn trên

cơ sở dữ liệu hệ thống và trả về thông tin cho người dùng

Câu lệnh truy vấn sau sẽ trả về giá trị là true nếu chiếc car là chiếcđược dùng nhiều nhất trong hệ thống xe cho thuê

1 context Car::mostPopular(): boolean

2 body: Car::allInstances()->forAll(c1|c1<>self

3 implies c1.rentalAgreement->size()<=self.rentalAgreement->size

())

Biểu diễn tiền/hậu điều kiện của các phép toán: có hai cách tiếpcận để kiểm tra sự thỏa mãn của các ràng buộc về tiền/hậu điều kiện đốivới các phép toán Cách thứ nhất là dùng các câu lệnh chỉ thị và cách thứhai là đặc tả các ràng buộc thông qua hợp đồng (contract) Trong cách tiếpcận đầu tiên, người thiết kế xác định rõ ràng tập các câu lệnh cấu trúc vàcác cấu trúc này sẽ được thực thi khi thực hiện phép toán Theo cách tiếpcận thứ hai, nhà thiết kế sẽ cung cấp cho mỗi hoạt động một hợp đồng của

nó Mỗi hợp đồng bao gồm một tập các điều khoản về tiền/hậu điều kiện.Tiền điều kiện xác định một tập hợp các ràng buộc đầu vào trước khi hoạtđộng được thực thi, còn hậu điều kiện cho biết các ràng buộc mà hệ thốngphải thỏa mãn khi kết thúc giao dịch OCL là ngôn ngữ thường được lựachọn để biểu diễn cho tiền/hậu điều kiện của hoạt động mức độ mô hình

1 context Rental::newRental(id:Integer, price:Real, startingDate:

Date,

2 endingDate:Date, customer:Customer, carRegNum:String,

pickupBranch: Branch, dropOffBranch: Branch)

3 pre: customer.licenseExpDate>endingDate

4 post: Rental.allInstances->one(r | r.oclIsNew() and

5 r.oclIsTypeOf(Rental) and r.endingDate=endingDate and r.

startingDate=startingDate

6 and r.driver=customer and r.pickupBranch=pickupBranch and r.

dropOffBranch=dropOffBranch

7 and r.car=Car.allInstances()->any(c | c.regNum=carRegNum))

Biểu thức tiền điều kiện được đặt sau từ khóapre và hậu điều kiện đượcđặt sau từ khóa post

Như vậy, trong Tiểu mục này luận án đã trình bày một số đặc trưng

cơ bản của ngôn ngữ ràng buộc đối tượng OCL, cụ thể là các biểu thứcOCL đặc tả bất biến (invariants), tiền/hậu điều kiện (pre/post-conditions)

bổ sung vào mô hình thiết kế của hệ thống Đặc biệt, luận án sẽ sử dụngcác biểu thức đặc tả này để biểu diễn các ràng buộc về bất biến và hành vicần kiểm chứng trong tiến trình tái cấu trúc trong các Chương 3 và 4 Nóicách khác, các ràng buộc cần kiểm chứng sự bảo toàn được biểu diễn mộtcách hình thức bằng các biểu thức OCL, điều này làm tăng tính chính xáccũng như tạo điều kiện dễ dàng cho các bước tiếp theo của tiến trình kiểmchứng

2.6 Ngôn ngữ đặc tả cho Java (Java Modeling

Language - JML)

Tại giai đoạn thiết kế hệ thống, tổ chức OMG cung cấp cho chúng ta ngônngữ ràng buộc OCL để biểu diễn các điều kiện ràng buộc trên mô hình Tạigiai đoạn cài đặt mã nguồn, ngôn ngữ JML (Java Modeling Language) [36]

là ngôn ngữ đặc tả hình thức được sử dụng để hỗ trợ cho ngôn ngữ lậptrình Java trên khía cạnh đặc tả và kiểm chứng các ràng buộc về bất biến,tiền/hậu điều kiện của các phương thức trong chương trình Đặc tả JMLđược nhúng vào mã nguồn Java (có thể ở cùng tệp mã nguồn của Java hoặc

ở một tệp riêng biệt) và bắt đầu bởi kí hiệu //@<JML specification >hoặc/∗@ <JML specification > @∗/ theo sau là các thuộc tính cần đặc tả Một

số từ khóa cơ bản như requires, ensures định nghĩa các biểu thức tiềnđiều kiện, hậu điều kiện và invariant định nghĩa các bất biến Đặc tả 2.1biểu diễn các biểu thức tiền và hậu điều kiện để kiểm tra trạng thái chophương thức analyzeTimeLimit() sử dụng ngôn ngữ JML Các thuộc tínhđược đặc tả trong JML sẽ được biên dịch và thực thi cùng với mã nguồn đểkiểm chứng sự thỏa mãn nó

Hiện nay, đã có nhiều công cụ được xây dựng và phát triển để kiểm chứng

mã Java cùng với đặc tả JML của nó như ESC/Java2 [25], RAC [13] hayOpenJML [17, 37], các công cụ này đều có thể tích hợp vào Eclipse

Như vậy, xét về mặt vai trò ngôn ngữ ràng buộc OCL và ngôn ngữ đặc

tả JML đều được sử dụng để đặc tả các ràng buộc về bất biến và hành vicủa hệ thống phần mềm Tuy nhiên, thời điểm sử dụng các ngôn ngữ này

là khác nhau, OCL được sử dụng bổ sung các đặc tả cho mô hình hệ thốngcòn JML lại biểu diễn các ràng buộc tại giai đoạn cài đặt hệ thống phầnmềm.

Lôgic vị từ bậc 1 (FOL) [63] cung cấp cho chúng ta khả năng biểu diễncác biểu thức logic mệnh đề (propositional logic) và cách thức định lượnghóa trên các đối tượng Nhờ vào các lượng từ trong FOL chúng ta có thể mô

tả các đối tượng và mối quan hệ giữa chúng một cách chính xác Đây chính

là ưu điểm của FOL so với logic mệnh đề FOL có thể dùng để biểu diễn lýthuyết số, lý thuyết tập hợp và thậm chí biểu diễn sự tính toán trong máyTuring

Bây giờ chúng ta sẽ mô tả một cách ngắn gọn các ký hiệu cơ bản dùng

để xây dựng lên các công thức FOL Các ký hiệu này được trình bày đầy

đủ trong [63]

Các phép toán kết hợp (Logical connectives) (⇒, ∧, ∨, và ⇔), phủđịnh (¬), và dấu ngoặc Chúng sẽ được sử dụng một cách đệ quy để tạo nêncác công thức phức hợp

Các ký hiệu hằng (Constants symbols) là các chuỗi (a, b, c, v.v.)dùng để biểu diễn thay thế cho các đối tượng

Các ký hiệu biến (Variable symbols) sẽ được sử dụng như những

“place holders” cho việc định lượng hóa trên các đối tượng

Các ký hiệu vị từ (Predicate symbols) mỗi ký hiệu được liên kếtvới arity (ví dụ, số lượng các đối số), có thể là 0 hoặc một số xác định khác

Vị từ được dùng để biểu diễn cho thuộc tính của các đối tượng và mối quan

hệ giữa chúng

Các ký hiệu hàm (Function symbols) mỗi ký hiệu được đặc tả bởiarity (ví dụ, số lượng các đối số nhập vào) đây là một hàm ánh xạ từ một

số lượng các đối tượng đến các đối tượng

Các lượng từ với mọi và tồn tại (Universal and existential tifier symbols) dùng để định lượng hóa trên các đối tượng

quan-Chương5của luận án trình bày về vấn đề phát triển công cụ hỗ trợ kiểmchứng tính nhất quán trong tái cấu trúc mô hình phần mềm Như đã đề cập,tại giai đoạn thiết kế hành vi cần kiểm chứng được biểu diễn bằng ngôn ngữràng buộc đối tượng OCL Tuy nhiên, cho tới thời điểm hiện tại, các công

cụ phát triển cho OCL còn khá hạn chế trong khi công cụ sử dụng logic vị

từ bậc nhất đã ở giai đoạn trưởng thành cả về số lương và chất lượng Bởivậy Tiểu mục này trình bày các kiến thức cơ sở về công thức FOL, các ràngbuộc về hành vi biểu diễn bằng biểu thức OCL sẽ được chuyển đổi sang cáccông thức FOL này Công cụ hỗ trợ kiểm chứng tính nhất quán CVT khôngthao tác trực tiếp trên các biểu thức OCL mà sẽ thực hiện kiểm tra tínhnhất quán trên các công thức FOL tương ứng này

Trong chương này luận án đã trình bày tóm tắt các kiến thức nền được

sử dụng trong các chương tiếp theo Mục 2.1 diễn tả về kỹ thuật tái cấutrúc với một số đặc điểm chính của kỹ thuật này Mục 2.2 dành sự quantâm đặc biệt đối với các khái niệm khóa của mô hình hướng đối tượng đượchình thức hóa trong các Chương 3 và 4 Mục2.3 luận án trình bày về ngônngữ mô hình hóa thống nhất UML cùng với hai loại biểu đồ tiêu biểu làbiểu đồ lớp và biểu đồ tuần tự Mục2.4 diễn tả mẫu thiết kế Strategy thuộc

về nhóm các mẫu hành vi, là mẫu thiết kế được áp dụng trong Chương 4.Ngôn ngữ ràng buộc đối tượng OCL được mô tả trong Mục 2.5 Cuối cùng

là các kiến thức tổng quan về ngôn ngữ đặc tả cho Java (JML) và logic vị

từ bậc 1 (FOL), đây là các phương tiện để biểu diễn các ràng buộc của hệthống cần phải nghiên cứu sự bảo toàn trong tiến trình tái cấu trúc