Một số phương pháp kiểm chứng các hệ thống hướng đối tượng (tt)

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Đào Thị Hường MỘT SỐ PHƯƠNG PHÁP KIỂM CHỨNG CÁC HỆ THỐNG HƯỚNG ĐỐI TƯỢNG TÓM TẮT LUẬN ÁN TIẾN SỸ CÔNG NGHỆ THÔNG TIN Hà Nội - 2017 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Đào Thị Hường MỘT SỐ PHƯƠNG PHÁP KIỂM CHỨNG CÁC HỆ THỐNG HƯỚNG ĐỐI TƯỢNG Chuyên ngành: Kỹ thuật Phần mềm Mã số: 62.48.01.03 TÓM TẮT LUẬN ÁN TIẾN SỸ CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS Trương Ninh Thuận Hà Nội - 2017 Mục lục Giới thiệu 1.1 Đặt vấn đề 1.2 Các kết luận án 1.3 Bố cục luận án 1 2 KIẾN THỨC CƠ SỞ 2.1 Tái cấu trúc 2.2 Mẫu thiết kế 3 3 Kiểm chứng tính bất biến tái cấu trúc mơ hình 3.1 Giới thiệu 3.2 Phương pháp bảo tồn tính bất biến tái cấu trúc biểu đồ lớp UML 3.2.1 Mơ hình hóa biểu đồ lớp UML 3.2.2 Xây dựng tập luật áp dụng tái cấu trúc biểu đồ lớp mơ hình UML 3.3 Kết chương 5 5 Kiểm chứng bảo toàn hành vi tái cấu trúc 4.1 Giới thiệu 4.2 Kiểm chứng tính quán mặt hành vi tái cấu trúc hệ thống phần mềm 4.2.1 Tổng quan quy trình kiểm chứng bảo tồn hành vi tái cấu trúc hệ thống phần mềm 4.2.2 Phương pháp kiểm chứng tính qn tái cấu trúc mơ hình phần mềm 4.2.3 Kiểm chứng tính quán tái cấu trúc chương trình phần mềm 4.2.4 Kiểm chứng bảo toàn hành vi tái cấu trúc mơ hình hệ thống ARTC 4.3 Kết chương Công cụ kiểm chứng 5.1 Giới thiệu 5.2 Xây dựng công cụ kiểm chứng CVT 5.2.1 Kiến trúc công cụ CVT 5.2.2 Chuyển đổi biểu thức OCL sang công thức FOL 5.3 Cài đặt thực nghiệm 5.4 Kết chương 12 13 13 13 13 14 17 17 18 19 19 19 19 20 20 21 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 22 6.1 Các đóng góp luận án 22 i 6.2 Hướng phát triển 23 Danh mục cơng trình khoa học 24 ii Chương Giới thiệu 1.1 Đặt vấn đề Tái cấu trúc (Refactoring) “là tiến trình thay đổi cấu trúc bên (internal structure) hệ thống phần mềm mà khơng làm ảnh hưởng đến hành vi bên ngồi (external behavior) Thực tái cấu trúc hệ thống phần mềm cho phép người phát triển có kiến trúc chắn, từ dễ dàng bảo trì hệ thống Tuy nhiên, tiến trình tiêu tốn nhiều thời gian dễ phát sinh lỗi người phát triển không tuân thủ cách nghiêm ngặt quy trình tiêu chuẩn phát triển phần mềm Bài tốn kiểm chứng tính qn hệ thống phần mềm ban đầu phiên tái cấu trúc điều kiện cần, giúp đánh giá độ tin cậy tiến trình tái cấu trúc sở cho hoạt động cải thiện chất lượng phần mềm sau Các cơng trình nghiên cứu kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc đa dạng với nhiều cách tiếp cận khác Trong phạm vi nghiên cứu, luận án tập trung đến hai vấn đề thu hút nhiều quan tâm là: (1) đặc tả hệ thống phần mềm với ràng phương pháp hình thức; (2) kiểm chứng bảo toàn bất biến, hành vi công cụ hỗ trợ kiểm chứng cấu trúc hệ thống phần mềm Một số nghiên cứu chuyên sâu khảo sát lĩnh vực tái cấu trúc hệ thống phần mềm, đặc biệt nghiên cứu thực kiểm chứng tính quán hệ thống phần mềm tiến trình Có hai hướng tiếp cận nhận quan tâm nhiều nhà nghiên cứu: (1) hướng tiếp cận sử dụng khẳng định (assertion) để biểu diễn hành vi hệ thống (bao gồm bất biến, tiền/hậu điều kiện); (2) hướng thứ hai sử dụng biến đổi mơ hình (model transformation) Cụ thể, nghiên cứu tốn kiểm chứng tính quán tái cấu trúc chia thành ba vấn đề sau: – Kiểm tra bảo tồn bất biến hệ thống tiến trình tái cấu trúc (Invariants Preservation) Phương pháp đề xuất họ dựa kỹ thuật biến đổi đồ thị với việc biểu diễn mơ hình phần mềm UML ngơn ngữ OCL để biểu diễn bất biến Chưa có nghiên cứu thực sâu vào kiểm tra bảo toàn bất biến biểu đồ lớp – Kiểm tra bảo toàn hành vi hệ thống tiến trình tái cấu trúc hệ thống phần mềm (Behaviors Preservation) Các nghiên cứu chuyên sâu kiểm tra bảo toàn hành vi hệ thống phần mềm (trong giai đoạn thiết kế cài đặt) thường biểu diễn hành vi hệ thống khẳng định (assertions) Các nghiên cứu kiểm chứng tính quán chủ yếu giai đoạn mã nguồn, kiểm tra quán giai khác 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) – Công cụ hỗ trợ kiểm tra tính quán hệ thống tiến trình tái cấu trúc (Tool supports for Checking Consistency) Các cơng cụ hỗ trợ cho tiến trình tái cấu trúc hệ thống phần mềm chia thành hai loại chính: (i) tìm kiếm vị trí tái cấu trúc (ii) thực tái cấu trúc Tuy nhiên, hầu hết công cụ rơi vào loại thứ chưa có xem xét đến vấn đề bảo toàn hành vi hệ thống sau tiến trình tái cấu trúc Các cơng trình nghiên cứu kiểm chứng tính quán hệ thống phần mềm tiến trình tái cấu trúc có tính chất đa đạng phương pháp kỹ thuật sử dụng Giải tốn tìm lời giải đáp cho câu hỏi “Hệ thống trước sau tái cấu trúc có quán với hay khơng ? ” Bài tốn có liệu đầu vào bao gồm: (i) hệ thống ban đầu (initial system) với phiên tái cấu trúc (evolution system) (ii) ràng buộc bất biến lớp hành vi hệ thống Dữ liệu đầu kết thông báo mức độ quán hệ thống trước sau tái cấu trúc 1.2 Các kết luận án Các kết nghiên cứu luận án góp phần bổ sung hoàn thiện phương pháp kiểm chứng tính quán tái cấu trúc hệ thống phần mềm Cụ thể, luận án có bốn đóng góp sau: – Đề xuất phương pháp kiểm chứng tính bất biến tái cấu trúc mơ hình phần mềm – Đề xuất phương pháp kiểm chứng bảo toàn hành vi tái cấu trúc hệ thống phần mềm – Xây dựng công cụ CVT hỗ trợ kiểm chứng bảo tồn hành vi tái cấu trúc mơ hình phần mềm – Minh họa phương pháp đề xuất ví dụ Hệ thống điều khiển giao thơng đường ARTC Về góc nhìn lý thuyết, luận án đề xuất phương pháp kiểm chứng tính quán bao phủ ràng buộc bất biến lớp hành vi hệ thống, xuyên suốt từ giai đoạn thiết giai đoạn cài đặt chu trình phát triển phần mềm Về góc nhìn thực hành, luận án xây dựng công cụ CVT hỗ trợ kiểm chứng tính quán tái cấu trúc mơ hình phần mềm Như vậy, kết nghiên cứu luận án thể tính thống mặt lý thuyết, đồng thời khả thi mặt thực hành Mục tiêu cuối luận án xây dựng giải pháp tương đối hoàn chỉnh cho tốn kiểm chứng tính qn tái cấu trúc hệ thống phần mềm 1.3 Bố cục luận án Luận án “Một số phương pháp kiếm chứng hệ thống hướng đối tượng” bao gồm sáu chương Trong đó, Chương trình bày tốn mà luận án nghiên cứu, Chương trình bày cách tóm tắt hướng nghiên cứu tốn kiểm chứng tính quán tái cấu trúc Chương đề xuất phương pháp kiểm chứng ràng buộc bất biến tái cấu trúc biểu đồ lớp Chương đề xuất phương pháp kiểm chứng bảo toàn hành vi tái cấu trúc hệ thống phần mềm Cơng cụ hỗ trợ kiểm chứng trình bày Chương Cuối cùng, Chương kết luận hướng nghiên cứu luận án Chương KIẾN THỨC CƠ SỞ 2.1 Tái cấu trúc Tái cấu trúc (refactoring) “là tiến trình thay đổi hệ thống phần mềm theo cách không làm thay đổi hành vi bên (external behavior) hệ thống lại cải thiện cấu trúc bên (internal structure) ” Ý tưởng tái cấu trúc phân bố lại lớp (classes), thuộc tính (attributes) phương thức (methods) thông qua mối quan hệ phân cấp thành phần hệ thống 2.2 Mẫu thiết kế “Mỗi mẫu thiết kế mô tả vấn đề xảy nhiều nhiều mơi trường sau mơ tả giải pháp để xử lý vấn đề đó, theo cách mà bạn sử dụng lại giải pháp triệu lần” Các mẫu thiết kế cung cấp khuôn mẫu chung để giải vấn đề có tính chất thường xun (lặp lặp lại) trình sử dụng phần mềm Nói cách khác, mẫu thiết kế cung cấp giải pháp cho vấn đề thiết kế phổ biến thường gặp lập trình, cụ thể vấn đề kế thừa tương tác nói chung Mẫu thiết kế không sử dụng để xử lý vấn đề kiến trúc tổng thể quy mô lớn tồn mơ hình phần mềm Mẫu Strategy “Định nghĩa tập hợp thuật tốn, đóng gói chúng thành loại hốn đổi cho nhau” Mẫu Strategy thực thi thuật toán cách linh hoạt, tùy thuộc vào ngữ cảnh cụ thể Ý nghĩa thực Strategy tách rời phần xử lý chức khỏi đối tượng Sau tạo tập hợp thuật toán để xử lý chức cho phép lựa chọn thuật tốn đắn thực thi chương trình Mẫu Strategy thường sử dụng để thay cho kế thừa, muốn chấm dứt việc theo dõi chỉnh sửa chức qua nhiều lớp Hình 2.1: Mẫu thiết kế Strategy Mẫu Strategy bao gồm thành phần sau: – IStrategy: Giao diện (Interface) chia sẻ lớp cụ thể họ thuật toán Lớp Context sử dụng giao diện để gọi đến thuật toán định nghĩa lớp con; – ConcreteStrategy: Nơi thuật toán cài đặt cụ thể; – Context: Lớp dùng để tham chiếu đến kiểu ISstrategy Trong số trường hợp, Context cài đặt phương thức, lớp ConcreteStrategy truy cập đến liệu Sự hợp tác thành phần mẫu Strategy: – IStrategy Context tương tác để thực việc lựa chọn thuật tốn Một Context truyền tất liệu cần thiết thuật toán đến IStrategy Ngồi ra, Context truyền đối số cho hoạt động IStrategy Điều cho phép IStrategy gọi lại Context cần thiết; – Một Context chuyển tiếp yêu cầu từ máy khách (client) đến IStrategy Máy khách thường tạo truyền đối tượng ConcreteStrategy đến Context; sau đó, tương tác riêng với Context Thường có gia đình lớp ConcreteStrategy để máy khách lựa chọn Ưu điểm việc sử dụng mẫu Strategy đóng gói thuật tốn lớp riêng biệt, điều làm cho việc sử dụng lại mã thuận tiện nhiều đó, hành vi lớp Context thay đổi cách linh hoạt thời điểm chạy chương trình Chương Kiểm chứng tính bất biến tái cấu trúc mơ hình 3.1 Giới thiệu Tái cấu trúc thực biểu đồ lớp UML đương nhiên có ảnh hưởng trực tiếp lên cấu trúc ràng buộc bất biến Các nhà phát triển phần mềm cần phải kiểm sốt tác động để có thay đổi mong muốn Chương này, luận án đề xuất phương pháp kiểm chứng tính quán tái cấu trúc biểu đồ lớp theo cách bảo toàn bất biến Bất biến lớp (class invariants) định nghĩa khẳng định (assertions), biểu diễn cho điều kiện ràng buộc thuộc tính lớp Các điều kiện phải thỏa mãn thể lớp Ý tưởng phương pháp kiểm chứng tính bất biến tái cấu trúc biểu đồ lớp (1) đặc tả cách hình thức biểu đồ lớp với bất biến nó, (2) định nghĩa mẫu (template) để mơ tả phép tốn tái cấu trúc (3) xây dựng luật áp dụng phép toán tái cho phiên tái cấu trúc thỏa ràng buộc bất biến mơ hình ban đầu Đóng góp chương đề xuất mẫu mơ tả phép tốn tích hợp ràng buộc bất biến mơ hình phần mềm 3.2 3.2.1 Phương pháp bảo tồn tính bất biến tái cấu trúc biểu đồ lớp UML Mơ hình hóa biểu đồ lớp UML Định nghĩa 3.1 (Biểu đồ lớp UML) Một biểu đồ lớp biểu diễn - CD = ΣC , ΣA , ΣC tập hợp lớp ΣA tập hợp liên kết lớp Định nghĩa 3.2 (Lớp) Một lớp C ∈ ΣC biểu diễn - C = NC , MC , AC , NC tên lớp, MC tập hợp phương thức AC tập hợp thuộc tính Định nghĩa 3.3 (Phương thức) Một phương thức mCi ∈ MC biểu diễn i , P i , Ri i i mCi = NM MC MC , NMC tên phương thức, PMC danh sách C i tham số RM kiểu phương thức C Định nghĩa 3.4 (Thuộc tính) Một thuộc tính aCi ∈ AC biểu diễn - aCi = NAi C , TAi C , PAi C , NAi C tên phương thức, TAi i kiểu thuộc tính PAi C biểu thức logic vị từ biểu diễn cho ràng buộc thuộc tính Định nghĩa 3.5 (Bất biến lớp) Bất biến lớp C , ký hiệu INVC , xác định kết hợp biểu thức logic vị từ biểu diễn cho ràng buộc thuộc tính lớp Giả sử, PAi C biểu thức logic vị từ biểu diễn ràng buộc thuộc tính aCi ∈ AC (trong trường hợp thuộc tính aCi khơng có ràng buộc, giá trị biểu thức PAi C gán (true)) ký hiệu | AC |= n (lực lượng tập hợp AC ) Khi đó, bất biến lớp C mô tả công thức sau đây: INVC = n i i=1 PAC Định nghĩa 3.6 (Liên kết) Liên kết as ∈ ΣA biểu diễn - as = Nas , Eas1 , Eas2 , Nas tên liên kết, Eas1 , Eas2 mấu liên kết mấu liên kết Định nghĩa 3.7 (Sự tương đương ngữ nghĩa hai phương thức) Cho cặp phương j j j thức mCi mD , mCi ∈ MC mD ∈ MD Khi đó, mCi mD gọi tương j i ∼ đương mặt ngữ nghĩa biểu thị biểu thức MC = MD nếu:  j i  // trùng tên NMC ≡ NMD j i PMC ≡ PM //trùng danh sách tham số  R i ≡ R j D //trùng kiểu trả MC MD Khi MC ∪MD phân chia thành lớp tương đương biểu diễn MC ,D = {mCij ,D }, đây:  i  mC ∈ MC j ij j i mC , mD ∈ mC ,D ⇔ mD ∈ MD  j M i ∼ C = MD Chúng ký hiệu phương thức mCi tập MC không thuộc tập mCij ,D biểu thức MC \ MC ,D j Định nghĩa 3.8 (Cặp thuộc tính kết hợp) Cho cặp thuộc tính aCi aD , j j i i aC ∈ AC aD ∈ AD aC aD gọi kết hợp biểu thị biểu thức j AiC ∼ = AD nếu: NAi D ≡ NAj D TAi D ≡ TAj D //trùng tên //trùng kiểu thuộc tính Ở PAi C PAj D tương đương khơng tương đương Khi AC ∪AD phân chia thành lớp kết hợp biểu thị AC ,D = {aCij ,D }, đó:  i  aC ∈ AC j ij j aCi , aD ∈ aC ,D ⇔ aD ∈ AD  j Ai ∼ C = AD Chúng ký hiệu aCi tập hợp AC không thuộc tập hợp AijC ,D biểu thức AC \ AC ,D Hình 3.4: Phép toán tái cấu trúc Factoring , a , , a q ∗ AD = aD D D i ∗ INVD = qi=1 PAi D , PAi D biểu diễn ràng buộc thuộc tính aD – MC ,D = {mCij ,D } | MC ,D |= k (0 ≤ k ≤ (n, p)) – AC ,D = {aCij ,D } | AC ,D |= h (0 ≤ h ≤ (m, q)) – MC ,D = ∅ – AC ,D = ∅ • Mơ hình tiến hóa M : – lớp E = NE , ME , AE xác định sau: ∗ ME = {mEi : mEi ∈ MC ,D }∪(MC \ MC ,D )∪(MD \ MC ,D ) ∗ AE = {aEi : aEi ∈ AC ,D }∪(AC \ AC ,D )∪(AD \ AC ,D ) ∗ INVE = m+q−h PAi E , PAi E biểu diễn ràng buộc thuộc tính aEi , i=1 và:  j i i  ∈ AC ,D aA PAC ∨ PAD E i i PAE = PAi C aAE ∈ (AC \ AC ,D )  P i i ∈ (AD \ AC ,D ) aA AD E • Biểu diễn UML: Phép tốn Composition minh họa Hình 3.3 3.2.2.4 Phép tốn: Factoring • Tên gọi: Factoring • Tình áp dụng: – Thành phần: lớp C D khơng có mối quan hệ kế thừa với có chung số thuộc tính kết hợp phương thức tương đương ngữ nghĩa; – Mục đích: loại bỏ thuộc tính phương thức giống nhau; – Thực thi: xây dựng lớp E cách trích lọc thuộc tính kết hợp phương thức tương đương mặt ngữ nghĩa từ lớp C D, lớp C D tương ứng phần lại lớp C D sau trích chọn thuộc tính phương thức Các lớp C D có mối quan hệ kế thừa trực tiếp từ lớp E • Mơ hình khởi đầu M: – lớp C = NC , MC , AC ; ∗ MC = mC1 , mC2 , , mCn ∗ AC = aC1 , aC2 , , aCm i i i ∗ INVC = m i=1 PAC , PAC biểu diễn ràng buộc thuộc tính aC 10 – lớp D = ND , MD , AD ; , m , , m p ∗ MD = mD D D , a , , a q ∗ AD = aD D D i ∗ INVD = qi=1 PAi D , PAi D biểu diễn ràng buộc thuộc tính aD ij – MC ,D = {mC ,D } | MC ,D |= k (k ≤ n ∧ k ≤ p) – AC ,D = {aCij ,D } | AC ,D |= h (h ≤ m ∧ h ≤ q) – MC ,D = ∅ AC ,D = ∅ • Mơ hình tiến hóa M : – lớp C = NC , MC , AC xác định sau: ∗ MC = {mCi : mCi ∈ (MC \ MC ,D )} ∗ AC = {aCi : aCi ∈ (AC \ AC ,D )} (m−h) ∗ INVC = i=1 PAi , PAi biểu diễn ràng buộc thuộc tính aCi C C – lớp D = ND , MD , AD xác định sau: i : m i ∈ (M \ M ∗ MD = {mD D C ,D )} D i i ∈ (A \ A ∗ AD = {aD : aD D C ,D )} (q−h) i i i ∗ INVD = i=1 PA , PA biểu diễn ràng buộc thuộc tính aD D D – lớp E = NE , ME , AE xác định sau: ∗ ME = {mEi : mEi ∈ MC ,D } ∗ AE = {aEi : aEi ∈ AC ,D } ∗ INVE = hi=1 PAi E , PAi E biểu diễn ràng buộc thuộc tính aEi , và: i PAi E = PAi C ∨ PAj D với aA ∈ AC ,D E • Biểu diễn UML: Phép tốn Factoring minh họa Hình 3.4 3.2.2.5 Phép tốn: Unfolding • Tên gọi: Unfolding • Tình áp dụng: – Thành phần: lớp C với danh sách dài phương thức, phương thức không tham chiếu cách đồng đến thuộc tính nó; – Mục đích: tối ưu hóa khả thực thi mã nguồn; – Thực thi: nhóm phương thức thuộc tính mà tham chiếu thành lớp bắt nguồn từ lớp C , thuộc tính phân chia thành tập hợp rời rạc Tạo mối quan hệ kế thừa từ phần lại lớp C tới lớp vừa tạo • Mơ hình khởi đầu M: – lớp C = NC , MC , AC ; ∗ MC = {mC1 , mC2 , , mCn } ∗ AC = {aC1 , aC2 , , aCp , aCp+1 , , aCp+q , aCp+q+1 , , a ( p+q+m)C } Giả sử A1C = {aC1 , aC2 , , aCp }, A2C = {aCp+1 , aCp+2 , , aCp+q } and A3C = {aCp+q+1 , aCp+q+2 , , aCp+q+m } ∗ INVC = p+q+m PAi C , PAi C biểu diễn ràng buộc thuộc tính aCi i=1 – Khơng tính tổng qt giả sử rằng: ∗ đoạn mã nguồn S1 , S2 thuộc phương thức mC1 tham chiếu đến thuộc tính aC1 , , aCp aCp+1 , , aCp+q , cách tương ứng; ∗ phương thức mC1 tạo thành từ đoạn mã S1 S2 ; ∗ thực với phương thức mC1 , phương thức khác (nếu có xảy ra) thực cách tương tự • Mơ hình tiến hóa M : 11 Hình 3.5: Phép toán tái cấu trúc Unfolding – lớp C = NC , MC , AC định nghĩa sau: ∗ MC = {mCi : mCi tạo thành từ đoạn mã S1 } i ∗ AC = AC = {aC : ≤ i ≤ p} ∗ INVC = pi=1 PAi , PAi = PAi C , ràng buộc thuộc tính aCi C C – lớp D = ND , MD , AD xác định sau: i : mi tạo thành từ đoạn mã S2 } ∗ MD = {mD D i ∗ AD = AC = {aC : (p+1) ≤ i ≤ q} i i i ∗ INVD = p+q i=p+1 PAD , PAD = PAC , ràng buộc thuộc tính i aD – lớp E = NE , ME , AE xác định sau: ∗ ME = {mCi : mCi ∈ (MC \ mC1 )} ∗ AE = A3C = {aCi : aCi ∈ (AC \ (AC ∪AD ))} i i i ∗ INVE = p+q+m i=p+q+1 PAE , PAE = PAC , ràng buộc thuộc tính aEi , và: – lớp C D có mối quan hệ kế thừa trực tiếp từ lớp E AC ∩AD = ∅ • Biểu diễn UML: Phép tốn Unfolding minh họa Hình 3.5 3.3 Kết chương Chương luận án đề xuất phương pháp kiểm chứng tính bất biến tái cấu trúc biểu đồ lớp UML Để đạt mục tiêu này, luận án tiến hành hình thức hóa biểu đồ lớp với bất biến Kế tiếp, nhờ vào việc xác định ràng buộc phép tốn, q trình tái cấu trúc biểu đồ lớp tiến hành theo cách bảo toàn bất biến Đóng góp luận án chương định nghĩa tập mẫu để mô tả phép tốn tích hợp bất biến lớp vào tiến trình tái cấu trúc Các ràng buộc mơ hình phần mềm phân thành hai loại bản: (1) Bất biến (2) Tiền/hậu điều kiện Trong chương này, đề xuất phương pháp tái cấu trúc biểu đồ lớp theo cách bảo toàn bất biến Trong chương tiếp theo, luận án tiếp tục giải toán tái cấu trúc hệ thống phần mềm mà đảm bảo trì hành vi (tiền/hậu điều kiện) hệ thống 12 Chương Kiểm chứng bảo toàn hành vi tái cấu trúc Chương luận án trình bày phương pháp kiểm chứng bảo tồn hành vi tái cấu trúc Đối tượng mà luận án quan tâm đến bảo toàn hành vi kịch (scenarios) bị tác động tiến trình tái cấu trúc Ý tưởng để giải tốn (1) đặc tả phương pháp hình thức hệ thống phần mềm; (2) định nghĩa tập luật để quản lý biến đổi hành vi (3) xây dựng luật áp dụng kiểm chứng bảo tồn hành vi Đóng góp luận án chương đề xuất khái niệm kịch kiểm chứng quán mặt hành vi tái cấu trúc 4.1 Giới thiệu Tái cấu trúc kỹ thuật mạnh mẽ sử dụng để cải thiện cấu trúc bên hệ thống phần mềm Mẫu thiết kế cung cấp giải pháp chung, tin cậy cho vấn đề thường xảy lập trình Sự kết hợp tái cấu trúc mẫu thiết tự nhiên để tiến tới mục tiêu có kiến trúc phần mềm chắn Trong chương này, luận án đề xuất phương pháp kiểm chứng bảo toàn hành vi tái cấu trúc hệ thống phần mềm, có sử dụng mẫu thiết kế Phương pháp đề xuất áp dụng giai đoạn thiết kế cài đặt quy trình phát triển phần mềm 4.2 4.2.1 Kiểm chứng tính quán mặt hành vi tái cấu trúc hệ thống phần mềm Tổng quan quy trình kiểm chứng bảo tồn hành vi tái cấu trúc hệ thống phần mềm Hình 4.1 mơ tả quy trình với ba tiến trình chính: (1) tái cấu trúc, (2) tính tốn tiền hậu điều kiện kịch (3) thực kiểm chứng Tại giai đoạn thiết kế, luận án sử dụng biểu đồ lớp biểu đồ (còn gọi kịch bản) UML để mơ hình hóa hệ thống phần mềm, ngơn ngữ ràng buộc đối tượng OCL để biểu diễn hành vi (bao gồm bất biến, tiền hậu điều kiện) Mơ hình sau tái cấu trúc tính tốn lại ràng buộc hành vi Cuối cùng, dựa tập luật xây dựng, tiến trình kiểm chứng thực Quá trình kiểm chứng giai đoạn cài đặt thực cách tương tự, khác biệt chế tác phần mềm tái cấu trúc chương trình phần mềm Trong luận án này, cài đặt hệ thống ngơn ngữ lập trình Java đặc tả hành vi JML Nhờ vào hỗ trợ cơng cụ OpenJML tích hợp vào mơi trường Eclipse, trình kiểm chứng thực thi cách tự động Kết cuối bảo toàn hành vi tái cấu trúc hệ thống kết hợp kết hai trình kiểm chứng giai đoạn thiết kế cài đặt nói 13 Hình 4.1: Tổng quan quy trình kiểm chứng 4.2.2 4.2.2.1 Phương pháp kiểm chứng tính quán tái cấu trúc mơ hình phần mềm Mơ hình hóa hệ thống phần mềm UML Các thành phần hệ thống mơ hình hóa cách dựa định nghĩa sau đây: Định nghĩa 4.1 (Mơ hình) Một mơ hình M bộ-2 CM , SM , CM tập hợp lớp SM tập hợp hành vi kich có mơ hình Định nghĩa 4.2 (Lớp) Một lớp CiM ∈ CM biểu diễn bộ-3 CiM = OPCiM , ACiM , ICiM , OPCiM tập hợp phương thức công khai, ACiM tập hợp thuộc tính cơng khai, ICiM tập trạng thái bất biến lớp Định nghĩa 4.3 (Tiền điều kiện phương thức trừu tượng) Tiền điều kiện PREopiM phương thức opei , thực hóa N phương thức opei lớp CksiM , lớp trừu tượng CiM tính hợp tiền điều kiện tất phương thức opei lớp CksiM Giả sử Pi (opei ) biểu diễn tiền điều kiện phương thức opei lớp con, tính tiền điều kiện theo cơng thức PREopiM = Pi (opei ) cho phương thức opei lớp trừu tượng CiM , opei ∈ CksiM phương thức thực hóa, P mệnh đề Định nghĩa 4.4 (Hậu điều kiện phương thức trừu tượng) Hậu điều kiện POSTopiM phương thức opei , thực hóa N phương thức opei lớp CksiM , lớp trừu tượng CiM tính hợp hậu điều kiện tất phương thức opei lớp CksiM Tương tự cách tính tiền điều kiện phương thức lớp trừu tượng, dễ thấy POSTopiM = Pi (opei ), opei ∈ CksiM phương thức thực hóa, P mệnh đề biểu diễn hậu điều kiện phương thức opei lớp Trong chương này, kịch hệ thống tương ứng với biểu đồ UML 14 Định nghĩa 4.5 (Kịch bản) Một kịch SiM biểu diễn bộ-4 SiM = CISiM , PRESiM , ESiM , POSTSiM , CISiM ⊆ CiM biểu diễn cho tập hợp lớp tham gia vào kịch bản, PRESiM tiền điều kiện kịch bản, ESiM tập có thứ tự phương thức lớp thực thi kịch bản, POSTSiM hậu điều kiện kịch Định nghĩa 4.6 (Phương thức kịch bản) Một phương thức kịch bộ-4 EkSiM = PREEkSiM , OPEkSiM , POSTEkSiM , k , PREEkSiM tiền điều kiện phương thức, OPEkSiM phương thức công khai thực thi kịch bản, POSTEkSiM hậu điều kiện phương thức, k thứ tự thực phương thức kịch Trong luận án này, xem xét trường hợp mà tiền hậu điều kiện phương thức kết hợp vị từ thuộc tính lớp tham gia vào kịch bản, ví dụ, PREEkSiM = P (ACijM ), ACijM ∈ ACiM thuộc tính, CiM ⊆ CISiM P vị từ Một kịch bao gồm chuỗi hoạt động, tiền hậu điều kiện phương thức hình thành biểu thức tiền hậu điều kiện phương thức thực trước Lưu ý rằng, phương thức công khai lớp kịch khác có tiền hậu điều kiện khác Tiền hậu điều kiện kịch xác định dựa tiền hậu điều kiện tất phương thức có tham gia kịch Và định nghĩa sau: Định nghĩa 4.7 (Tiền điều kiện kịch bản) Tiền điều kiện kịch PRESiM xác định tiền điều kiện phương thức thực thi kịch Tiền điều kiện phương thức kịch đặc ràng buộc tất thuộc tính công khai kịch Định nghĩa 4.8 (Hậu điều kiện kịch bản) Hậu điều kiện kịch POSTSiM xác định hợp ràng buộc thuộc tính cơng khai ACijM hậu điều kiện phương thức POSTEkSiM diễn sau ESiM Cho kịch S = (e1 , e2 , en ), ei , i = n, phương thức thứ i thực thi kịch Theo định nghĩa 4.6, có ei = (preei , opei , postei , i ) post( ei ) = Pk (Ak C ), Pk logic vị từ Ak C , biểu diễn cho thuộc tính lớp C có liên quan đến kịch Giả sử kịch S có thuộc tính cơng khai AC xuất biểu thức hậu điều kiện ei ej cho ≤ i < j ≤ n Như vậy, có postei = Pi (AC ) postej = Pj (AC ) Nếu ei thực thi trước ej , Pj (AC ) cần phải trì phương thức thứ j thực thi Định nghĩa 4.9 (Tái cấu trúc) Một tiến trình tái cấu trúc R sử dụng mẫu thiết kế D D(SUBMS ) biểu diễn sau: R : M −−−−−−−→ M , M M theo thứ tự biểu thị cho mơ hình trước sau thực tái cấu trúc, D tên mẫu thiết kế ứng dụng, SUBMS ⊆ SM tập kịch tham gia vào tiến trình tái cấu trúc Với mục tiêu giảm độ phức tạp cho trình kiểm chứng, thuộc tính cần kiểm chứng phân thành hai loại (i) Các thuộc tính tĩnh (static), (ii) thuộc tính động (dynamic) Đối với loại thuộc tính thứ nhất, phương pháp kiểm chứng dựa bất biến lớp, với loại thuộc tính thứ hai, trình kiểm chứng thao tác tiền/hậu điều kiện kịch Chú ý rằng, Chương luận án giải toán kiểm chứng bảo toàn bất biến tái cấu trúc biểu đồ lớp UML Chương này, khái niệm bất biến hiểu cách tương tự (các ràng buộc 15 thuộc tính lớp), nhiên tiến trình tái cấu trúc lại thực thơng qua việc sử dụng mẫu thiết kế Strategy Nói cách khác, trình tái cấu trúc thực Chương Chương hồn tồn khác Do đó, luận án tiếp tục thực kiểm chứng bảo tồn bất biến tiến trình tái cấu trúc chương Quá trình kiểm chứng thực cách lần lượt, dựa tuân thủ Mệnh đề chi tiết sau 4.2.2.2 Kiểm chứng thuộc tính tĩnh Mệnh đề 4.1 (Bảo tồn tính chất tĩnh) Q trình tái cấu trúc mơ hình phần mềm coi bảo tồn thuộc tính tĩnh bất biến lớp mơ hình tương đương logic với bất biến lớp mơ hình ban đầu D(SUBMS ) Chúng ta hình thức hóa mệnh đề cụ thể sau Cho R : M −−−−−−−→ M mơ hình tái cấu trúc, R coi bảo tồn tính chất tĩnh ∀ CiM | CiM ∈ CM ∧CiM ∈ CM ⇒ ICiM ≡ ICiM 4.2.2.3 Kiểm chứng thuộc tính động Các thuộc tính động hiểu ràng buộc hành vi mơ hình phần mềm, luận án này, chúng tơi quan tâm đến bảo tồn hành vi kịch tham gia vào trình tái cấu trúc Mệnh đề 4.2 (Nhất qn tồn phần thuộc tính động) Một tiến trình tái cấu trúc mơ hình phần mềm gọi qn tồn phần thuộc tính động (với mơ hình ban đầu), với kịch mơ hình tại, tiền hậu điều kiện tương đương logic với tiền hậu điều kiện kịch tương ứng mơ hình ban đầu D(SUBMS ) Một cách hình thức hóa, cho R : M −−−−−−−→ M tiến trình tái cấu trúc, SiM ∈ SUBMS gọi quán toàn phần thuộc tính động, PRESiM ≡ PRESiM ∧POSTSiM ≡ POSTSiM Trong phần 4.2.2.1, tiền hậu điều kiện kịch suy dẫn phương thức tham gia vào kịch bản, PRESiM ≡ PRESiM ∧POSTSiM ≡ POSTSiM , tất ràng buộc thuộc tính cơng khai kịch sau tái cấu trúc bảo toàn Mệnh đề 4.3 (Nhất quán phận thuộc tính động) Một tiến trình tái cấu trúc mơ hình phần mềm gọi quán phận thuộc tính động (so với mơ hình ban đầu) tiền điều kiện kịch mơ hình (mơ hình sau tái cấu trúc) không thay đổi, hậu điều kiện kịch thỏa mãn phần so với tiền/hậu điều kiện kịch tương ứng mơ hình gốc Tương tự trên, hình thức hóa tiến trình quán phận D(SUBMS ) thuộc tính động sau Cho R : M −−−−−−−→ M tiến trình tái cấu trúc, SiM ∈ SUBMS gọi quán phần PRESiM ≡ PRESiM ∧POSTSiM ⇒ POSTSiM Trong trường hợp này, POSTSiM ⇒ POSTSiM , giá trị ràng buộc kịch thuộc tính cộng khai nằm phạm vi mong muốn Mệnh đề 4.4 (Khơng qn) Một tiến trình tái cấu trúc mơ hình phần mềm gọi khơng qn đồng thời khơng thỏa mãn quán toàn phần quán phận thuộc tính động D(SUBMS ) Cho R : M −−−−−−−→ M tiến trình tái cấu trúc, SiM ∈ SUBMS không quán SiM không thỏa mãn qn phần (đương nhiên khơng 16 thể thỏa mãn quán toàn phần) Trong trường hợp này, giá trị ràng buộc thuộc tính cơng khai kịch bị vi phạm sau tiến trình tái cấu trúc 4.2.3 Kiểm chứng tính quán tái cấu trúc chương trình phần mềm Mệnh đề 4.5 (Bảo tồn thực thi chương trình nguồn) Một chương trình P gọi bảo tồn thực thi với kịch bản, trước sau thực thi chương trình tiền hậu điều kiện bảo tồn Chúng ta biểu diễn cách hình thức hóa mệnh đề sau, PRESP [SP ]POSTSP Mệnh đề 4.6 (Sự bảo tồn thực thi chương trình tái cấu trúc) Một chương trình tái cấu trúc P gọi bảo tồn thực thi với chương trình nguồn P với kịch bản, tiền hậu điều kiện bảo tồn sau thực tái cấu trúc Chúng ta biểu diễn mệnh đề cơng thức hình thức sau, PRESP [SP ]POSTSP 4.2.4 Kiểm chứng bảo toàn hành vi tái cấu trúc mơ hình hệ thống ARTC Hệ thống điều khiển giao thông đường (Adaptive Road Traffic Control - ARTC) cho phép phối hợp hoạt động tín hiệu đèn khu vực phản ứng cách thông minh với dao động lưu lượng giao thông thời điểm Hệ thống ARTC thời có số hạn chế khả thực thi hỗ trợ cho tiến trình sử dụng lại Bởi vậy, tiến hành tái cấu trúc hệ thống cách sử dụng mẫu Strategy Khơng tính tổng quát, giả sử hướng giao lội, luận án xác định số hành vi cần bảo toàn hệ thống sau: – Khi giao thơng trạng thái bị ách tắc (heavyTraffic), tín hiệu đèn xanh cần bật lên (nếu trạng thái đỏ) – Khi giao thông trạng thái bị ách tắc (heavyTraffic), tín hiệu đèn xanh bật lên, thời gian (time) dành cho tín hiệu cần gia tăng – Tại hướng giao lộ đó, giao thơng trạng thái với lưu lượng cao (highTraffic), tín hiệu đèn xanh bật, phương tiện giao thơng nên lựa chọn theo hướng Theo Mệnh đề 4.1, dễ thấy, thuộc tính tĩnh (bất biến) mơ hình trước sau áp dụng mẫu thiết kế Strategy khơng thay đổi Như vậy, q trình tái cấu trúc hồn tồn bảo tồn thuộc tính tĩnh Q trình kiểm chứng bảo tồn hành vi thực ràng buộc tiền/hậu kịch analyzeTraffic() Các ràng buộc mơ hình khởi đầu mô tả Đặc tả 4.1: PRE_SiM = trafficFlow -> isEmpty () POST_SiM = if ( state = heavyTraffic ) then (( signal = green ) AND ( greenTime > 60) ) else if ( state = lowTraffic ) then (( signal = red ) AND ( greenTime isEmpty () POST_S ’ iM = if ( state = heavyTraffic ) then (( signal = green ) AND ( greenTime > 60) ) else if ( state = lowTraffic ) then (( signal = red ) AND ( greenTime