4.4.3.2 Biểu diễn các hành vi bằng JML
Trong phần 4.4.3.1 chúng ta đã biểu diễn các ràng buộc hành vi của hệ thống bằng OCL để kiểm chứng tính nhất quán của hệ thống tại giai đoạn thiết kế. Để tiếp tục thực hiện kiểm chứng tính nhất quán của hệ thống tại giai đoạn cài đặt, chúng ta sẽ biểu diễn các ràng buộc này bằng ngôn ngữ đặc tả JML.
Như trên đã trình bày, JML là ngơn ngữ đặc tả các mơ-đun trong chương trình Java, tương ứng với kịch bản calculating optimal control trong giai đoạn thiết kế. Đặc tả 4.4 biểu diễn các ràng buộc về hành vi của hệ thống ARTC. 1 //@ ensures((state==STATE.heavyTraffic)&&(signal==SIGNAL.red)) ==>(this.signal==SIGNAL.green); 2 //@ ensures((state==STATE.lowTraffic)&&(signal==SIGNAL.green)) ==>(this.signal==SIGNAL.red); 3 //@ ensures((state==STATE.heavyTraffic)&&(signal==SIGNAL.red)) ==>(this.signalTime==\old(this.signalTime)-10); 4 //@ also 5 //@ ensures((state==STATE.heavyTraffic)&&(signal==SIGNAL.green) )==>(this.signalTime==\old(this.signalTime)+10); 6 //@ ensures((state==STATE.lowTraffic)&&(signal==SIGNAL.red)) ==>(this.signalTime==\old(this.signalTime)+10); 7 //@ also
8 //@ ensures((state==STATE.lowTraffic)&&(signal==SIGNAL.green)) ==>(this.signalTime==\old(this.signalTime)-10); 9 //@ ensures((state==STATE.highTraffic)&&(signal==SIGNAL.green)) ==>(this.direction==DIRECTION.choose); 10 //@ ensures((state==STATE.highTraffic)&&(signal==SIGNAL.red)) ==>(this.direction==DIRECTION.noChoose); 11 //@ ensures((state==STATE.noTraffic)&&(signal=SIGNAL.red))==>( this.direction==DIRECTION.noChoose); 12 //@ ensures((state==STATE.noTraffic)&&(signal==SIGNAL.green)) ==>(this.direction==DIRECTION.choose);
Đặc tả 4.4: Đặc tả hành vi của mã nguồn chương trình ARTC trước tái cấu trúc.
4.4.4 Kiểm chứng tính nhất qn trong tái cấu trúc mơhình hệ thống ARTC. hình hệ thống ARTC.
Hệ thống điều khiển giao thơng đường bồ ARTC được mô tả một cách chi tiết trong Tiểu mục 4.4. Thêm vào đó, luận án cũng đã đánh giá ưu nhược điểm của hệ thống hiện tại và đưa ra giải pháp khắc phục các nhược điểm đó bằng cách áp dụng mẫu Strategy để tái cấu trúc mơ hình hệ thống. Để phục vụ cho mục tiêu kiểm chứng, các ràng buộc mơ tả hành vi cần bảo tồn của hệ thống đã được biểu diễn bằng OCL và JML. Luận án sẽ tiến hành kiểm chứng sự bảo toàn hành vi của hệ thống này bằng quy trình kiểm chứng đã đề xuất trong Tiểu mục 4.3.1.
Theo Mệnh đề 4.11, dễ thấy, các thuộc tính tĩnh (bất biến) của mơ hình trước và sau khi áp dụng mẫu thiết kế Strategy không hề thay đổi. Thật vậy, mẫu Strategy chỉ thực hiện phân bố lại các thuộc tính và khơng làm ảnh hưởng gì đến ngữ nghĩa của nó. Bởi vậy, tiến trình tái cấu trúc trên mơ hình ARTC là bảo tồn các thuộc tính tĩnh.
Chúng ta sẽ xem xét đến khả năng bảo tồn các thuộc tính động của mơ hình hệ thống ARTC sau tái cấu trúc thơng qua các Đặc tả 4.1, 4.2 và 4.3 mô tả các hành vi. Đặc tả tiền/hậu của kịch bản analyzeTraffic() trong mơ hình khởi đầu (Hình4.4 và 4.5) được xác định theo Định nghĩa 4.8 và Định nghĩa 4.9 như sau:
1 PRE_SiM = trafficFlow -> isEmpty()
2 POST_SiM = if (state = heavyTraffic) then ((signal = green) AND (greenTime > 60))
3 else if (state = lowTraffic) then ((signal = red) AND (redTime <= 60))
4 else if (state = highTraffic) then (direction =
CHOOSE)
5 else (direction = NO_CHOOSE) 6 endif
7 endif 8 endif
Đặc tả 4.5: Các ràng buộc trên kịch bản optimizeTraffic() của mơ hình khởi đầu.
Một cách tương tự, chúng ta cũng chỉ ra được tiền/hậu điều kiện của kịch bản optimizeTraffic() trong mơ hình tiến hóa (được mơ tả trong Hình 4.6 và Hình 4.7):
1 PRE_S’iM = trafficFlow -> isEmpty()
2 POST_S’iM = if (state = heavyTraffic) then ((signal = green) AND (greenTime > 60))
3 else if (state = lowTraffic) then ((signal = red)
AND (redTime <= 60))
4 else if (state = highTraffic) then (direction =
CHOOSE)
5 else (direction = NO_CHOOSE)
6 endif
7 endif 8 endif
Đặc tả 4.6:Đặc tả trên kịch bảnoptimizeTraffic() của mơ hình tiến hóa.
Từ các giá trị về tiền/hậu điều kiện được tính tốn của các kịch bản trong mơ hình khởi đầu và mơ hình tiến hóa. Theo Định nghĩa 4.12, tiến trình tái cấu trúc sử dụng mẫu thiết kế Strategy trên mơ hình hệ thống ARTC là nhất quán về mặt hành vi, nói cách khác mơ hình ARTC bảo tồn hành vi tồn phần trên mơ hình tiến hóa. Chú ý rằng, OCL mô tả các điều kiện ràng buộc dựa trên các công thức của logic vị từ cấp 1. Bởi vậy, q trình kiểm chứng có thể thực hiện một cách tự động bởi các công cụ hỗ trợ kiểm chứng như Z3 [22].
Hình 4.8: Kết quả kiểm chứng sự bảo tồn hành vi trong tái trúc chương trình phần mềm
4.4.5 Kiểm chứng tính nhất qn trong tái cấu trúc chương trình phần mềm ARTC.
Hệ thống ARTC đã được mô tả trong phần 4.4, tại đó, chúng ta cũng đã xem xét đến một số hành vi cần bảo toàn của hệ thống trước khi tiến hành tái cấu trúc bằng cách sử dụng phần mềm OpenJML [17] tích hợp vào mơi trường Eclipse3. Sau đây, chúng ta sẽ áp dụng các định nghĩa đã xây dựng để kiểm chứng sự bảo toàn của các hành vi trên trong tái cấu trúc chương trình phần mềm.
Thơng qua q trình thực nghiệm, luận án đã cài đặt mã nguồn cho hệ thống ARTC trước và sau khi thực hiện tái cấu trúc. Kết quả của quá trình kiểm chứng được thể hiện trong Hình 4.8.
Như vậy, với kết quả này, chúng ta có thể thấy rằng, chương trình sau tái cấu trúc khơng bảo toàn được toàn bộ các hành vi của chương trình nguồn, bởi vậy cần phải xem xét lại tiến trình tái cấu trúc đã thực hiện để xem lỗi được phát sinh từ đâu.
4.5 Kết chương
Trong chương này, luận án đã đề xuất 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 bằng cách áp dụng mẫu thiết kế Strategy. Phương pháp kiểm chứng được thực hiện một cách
tuần tự tại các giai đoạn thiết kế và cài đặt trong vòng đời phát triển phần mềm. Đối tượng mà luận án quan tâm đến sự bảo toàn hành vi là các kịch bản tham gia vào tiến trình tái cấu trúc, cụ thể là xem xét sự biến đổi các
điều kiện ràng buộc về bất biến, tiền/hậu điều kiện của các kịch bản này. Tại giai đoạn thiết kế, mơ hình phần mềm được biểu diễn bằng các biểu đồ lớp và biểu đồ tuần tự của UML, hành vi cần bảo toàn được biểu diễn bằng các biểu thức OCL. Còn tại giai đoạn cài đặt, chúng tơi mã hóa hệ thống bằng ngơn ngữ lập trình Java, biểu diễn hành vi bằng JML. Q trình kiểm chứng sự bảo tồn hành vi của hệ thống ở cả hai giai đoạn đều dựa trên tập luật nhất quán đã được xây dựng.
Đã có một số nghiên cứu giải quyết bài tồn kiểm chứng sự nhất quán về mặt hành vi trong tái cấu trúc, tuy nhiên, những cơng trình này chủ yếu tập trung vào sự nhất quán giữa các giai đoạn khác nhau trong chu kỳ phát triển phần mềm (giữa giai đoạn cài đặt và giai đoạn thiết kế) hoặc giữa nhiều loại biểu đồ khác nhau trong một mơ hình (giữa biểu đồ trạng thái và biểu đồ trình tự). Luận án tập trung giải quyết bài tốn kiểm chứng tính nhất quán trong cùng một giai đoạn và đề cập cụ thể đến sự bảo toàn hành vi của các kịch bản bị tái cấu trúc trong một hệ thống phần mềm.
Để minh họa cho phương pháp đề xuất, luận án cũng đã tiến hành mô tả hệ thống điều khiển lưu lượng giao thông đường bộ ARTC và tái cấu trúc hệ thống này bằng mẫu thiết kế Strategy. Chú ý rằng mẫu Strategy là một trong những mẫu thiết kế được sử dụng khá phổ biến, bao hàm trong nó khái niệm đa hình. Bởi vậy, tuy rằng luận án sử dụng mẫu Strategy để tái cấu trúc hệ thống phần mềm nhưng phương pháp kiểm chứng có thể được sử dụng mở rộng và kiểm chứng một cách tương tự với một số mẫu thiết kế khác. Nói cách khác, người phát triển hệ thống có thể coi đây là nền tảng để tiếp tục nghiên cứu và kiểm chứng tính nhất quán trong tái cấu trúc hệ thống phần mềm bằng các mẫu thiết kế khác.
Trong chương này, chúng tôi mới chỉ thực hiện quy trình kiểm chứng trên một bộ kịch bản (biểu diễn cho cùng một chức năng tương ứng giữa hai mơ hình). Đối với các hệ thống phức tạp và có nhiều kịch bản, các bước thực hiện kiểm chứng đều được tiến hành một cách tương tự đối với từng cặp kịch bản. Kết quả cuối cùng của việc kiểm chứng sự bảo toàn hành vi tại một giai đoạn của hệ thống được tái cấu trúc là sự kết hợp của các kết quả kiểm chứng của mỗi cặp kịch bản trong các hệ thống phần mềm. Ngồi ra,
q trình kiểm chứng sau cùng là sự tổng hợp kết quả kiểm chứng trên cả hai giai đoạn thiết kế và cài đặt phần mềm.
Phương pháp đề xuất một mặt thể hiện tính thống nhất về mặt lý luận bởi sự thực hiện xuyên suốt trong các giai đoạn thiết kế và cài đặt của quy trình phát triển của phần mềm. Mặt khác, tại giai đoạn cài đặt chúng tôi đã tiến hành kiểm tra một cách tự động, điều này thể hiện tính khả thi của nghiên cứu. Như vậy, trong khuôn khổ nội dung của luận án phương pháp đề xuất có thể sử dụng trong các hoạt động cải tiến chất lượng phần mềm. Như đã đề cập trước đó, q trình kiểm tra sự bảo tồn hành vi đã được tiến hành một cách tự động tại giai đoạn cài đặt. Tuy nhiên, tại giai đoạn thiết kế, quá trình kiểm chứng vẫn được thực thi một cách thủ công. Điều này, dẫn đến việc tiêu tốn khơng chỉ về mặt thời gian mà cịn dễ phát sinh lỗi. Trong chương tiếp theo của luận án, chúng tôi sẽ xây dựng công cụ CVT hỗ trợ kiểm chứng tính nhất qn của mơ hình phần mềm.
Kết quả nghiên cứu nêu trên được cơng bố tại kỷ yếu có phản biện trong Hội nghị quốc tế lần thứ 5 về EAI International Conference on Context- Aware Systems and Applications 2016 (ICCASA) (cơng trình khoa học số 1*) và Tạp chí Mobile Networks and Applications journal (MONET) (SCIE- indexed) Vol.22.2 (cơng trình khoa học số 2*).
CÔNG CỤ KIỂM CHỨNG
Các Chương3 và 4, luận án đã lần lượt trình bày các phương pháp kiểm chứng sự bảo toàn về bất biến và hành vi trong tái cấu trúc hệ thống phần mềm. Trong chương này, chúng tôi tiếp tục phát triển công cụ CVT hỗ trợ kiểm chứng tính nhất qn trong tái cấu trúc mơ hình phần mềm.
5.1 Giới thiệu
Mục tiêu cuối cùng của việc tái cấu trúc trên các hệ thống phần mềm là cải thiện chất lượng của các hệ thống đó, tuy nhiên cơng việc này cần được tiến hành một cách cẩn thận bởi nó có thể dẫn đến tiêu tốn nhiều thời gian và dễ phát sinh lỗi, đặc biệt khi thực hiện tái cấu trúc một cách thủ công. Bởi vậy, bài tốn phát triển cơng cụ hỗ trợ cũng đóng một vai trị then chốt trong tái cấu trúc hệ thống phần mềm, theo cách hỗ trợ tiến trình này thực hiện một cách nhanh chóng và chính xác [58].
Một nghiên cứu gần đây được thực hiên bởi Mohammed Misbhauddin và các cộng sự vào năm 2015 chỉ ra rằng các công cụ tái cấu trúc vẫn đang trong giai đoạn đầu của quá trình phát triển và phân thành hai nhóm chính như sau [48]:
– Các cơng cụ tự động tìm kiếm các vị trí và kỹ thuật tái cấu trúc; – Các cơng cụ thực thi tiến trình tái cấu trúc sau khi đã xác định được
Như vậy, xét về mặt chức năng, cả hai loại công cụ dường như phù hợp với nhau một cách rất tự nhiên (một loại dùng để tìm kiếm vị trí tái cấu trúc, loại khác dùng để thực hiện tiến trình tái cấu trúc). Những năm gần đây, xuất hiện thêm một số công cụ như Refactoring Browser for Smalltalk [57], JRefactory1, Design Pattern Transformer (DPT) [35], Refactorit2, Eclipse3, v.v. Tuy nhiên, hầu hết các công cụ này thuộc về nhóm thứ hai (thực hiện tái cấu trúc) và chưa xem xét bài tốn bảo tồn hành vi của hệ thống sau tiến trình này. Nói cách khác các cơng cụ này chưa thực hiện công việc đánh giá sự nhất quán về mặt hành vi giữa hệ thống trước và sau khi tái cấu trúc. Trong Chương4, luận án đã đề xuất phương pháp bảo toàn hành vi trong tái cấu trúc mơ hình phần mềm. Phương pháp mà chúng tôi sử dụng dựa trên sự đánh giá các tham số về bất biến, tiền/hậu điều kiện của các kịch bản tham gia vào quá trình tái cấu trúc. Quy trình kiểm chứng được áp dụng trong các giai đoạn thiết kế và cài đặt của vịng đời phát triển phần mềm. Chúng tơi cũng đã chỉ ra phương pháp kiểm chứng tự động trong giai đoạn cài đặt nhờ vào sự trợ giúp của cơng cụ OpenJML tích hợp vào mơi trường Eclipse [17]. Tuy nhiên, tại giai đoạn thiết kế, chúng tôi vẫn đang tiến hành kiểm chứng một cách thủ cơng. Vì vậy, phát triển một công cụ hỗ trợ kiểm chứng trong giai đoạn này là nhu cầu tất yếu.
Công cụ CVT (Consistency Validator Tool) được xây dựng để đáp ứng yêu cầu hỗ trợ kiểm chứng sự bảo tồn hành vi trong tái cấu trúc mơ hình phần mềm. Cụ thể, CVT sẽ nhận các tệp dữ liệu đầu là: (1) mơ hình hệ thống trước và sau khi tái cấu trúc, (2) biểu thức OCL mơ tả hành vi của chúng. Sau q trình kiểm chứng, CVT sẽ đưa ra kết quả về khả năng nhất qn giữa các mơ hình trước và sau khi tái cấu trúc.
Như đã đề cập từ trước, OCL được biết đến là ngôn ngữ phổ biến hỗ trợ biểu diễn các điều kiện ràng buộc trên các phần tử của mơ hình UML. Luận án cũng đã sử dụng OCL để biểu diễn hành vi của mơ hình hệ thống trong chương 4. Tuy nhiên, khó khăn mà chúng tơi gặp phải trong q trình kiểm chứng khi sử dụng OCL để mơ tả hành vi là các cơng cụ phát triển cho OCL cịn hạn chế. Trong khi đó, logic vị từ cấp 1 (FOL [63]) đã có một thời gian dài phát triển và đã đạt đến giai đoạn trưởng thành cả về số lượng
1. http://jrefactory.sourceforge.net/ 2. http://jrefactory.sourceforge.net/ 3. https://eclipse.org/downloads/
và chất lượng. Phân tích một cách chuyên sâu, các biểu thức OCL được xây dựng trên cơ sở tốn học là các cơng thức logic vị từ cấp 1. Do đó, khi xây dựng kiến trúc của cơng cụ kiểm chứng CVT, chúng tôi đã tiến hành công việc chuyển đổi các biểu thức OCL sang các công thức FOL.
Đã có một vài nghiên cứu thực hiên cơng việc chuyển đổi từ OCL sang FOL, tuy nhiên, họ mới chỉ dừng lại ở việc chuyển đổi một số biểu thức OCL đơn giản và chưa xem xét q trình chuyển đổi với các biểu thức có cú pháp phức tạp [7, 19, 20]. Do đó, luận án cũng đi vào giải quyết vấn đề cịn tồn tại này.
Cơng cụ CVT bao gồm một số chức năng chính bao gồm: (1) kiểm tra sự tương thích giữa biểu thức OCL mơ tả hành vi với đặc tả các thành phần của mơ hình UML(well-formedness checking), (2)thực hiện chuyển đổi biểu thức OCL sang công thức FOL(OCL2FOL Translator) và(3) thực hiện kiểm tra sự nhất quán (Checking Consistency). Đây cũng được coi là các đóng góp chính của chúng tơi trong nghiên cứu về bài tốn xây dựng cơng cụ.
Các mục tiếp theo của chương này được cấu trúc như sau, Mục 5.2 mô tả kiến trúc tổng quát của CVT và chi tiết tiến trình chuyển đổi từ OCL sang FOL. Để minh họa cho tính khả thi và tin cậy của CVT, chúng tôi tiến hành cài đặt và thực nghiệm công cụ với hệ thống điều khiển lưu lượng giao thông đường bộ (ARTC) trong Mục 5.3. Cuối cùng, Mục 5.4 là một số đánh giá, kết luận và hướng phát triển của chương.
5.2 Xây dựng công cụ kiểm chứng CVT
Trong Mục này, đầu tiên luận án sẽ trình bày kiến trúc tổng quát của bộ công cụ CVT. Kế tiếp, chúng tôi mô tả một cách chi tiết quá trình chuyển đổi từ biểu thức OCL sang công thức FOL.
5.2.1 Kiến trúc của công cụ kiểm chứng CVT
Từ góc nhìn hướng kiến trúc, CVT bao gồm hai thành phần cơ bản: (i)
môi trường định nghĩa (definition environment) và (ii) môi trường thực thi (execution environment) như được mơ tả trong Hình 5.1.
Hình 5.1: Kiến trúc của công cụ CVT
Môi trường định nghĩa là khối bên trên của Hình5.1, nơi tạo ra các biểu đồ của UML (bao gồm biểu đồ lớp và biểu đồ tuần tự) biểu diễn các mơ hình khởi đầu và mơ hình tiến hóa của hệ thống. Mơi trường định nghĩa
cũng chịu trách nhiệm nhận vào các tệp OCL đặc tả các hành vi cần kiểm chứng, đồng thời thực hiện công việc kiểm tra sự tương thích về kiểu giữa