6. Kết quả nghiên cứu, đóng góp khoa học của luận án
2.1.1. Kịch bản sử dụng tiến trình Markov đánh giá độ tin cậy
2.1.1.1. Nguyên lý áp dụng tiến trình Markov
Tác giả L. Singh [55] đề xuất phương pháp đánh giá độ tin cậy từ mô hình kiến trúc của phần mềm bao gồm hai kỹ thuật:
Kỹ thuật xác định xác suất của trạng thái (State Based) dựa trên mô phỏng các trạng thái và phân tích xác suất ban đầu các trạng thái.
Kỹ thuật xác định xác suất chuyển trạng thái hay xác suất đường dẫn (Path Based) dựa trên mô phỏng các chuyển trạng thái, thực thi các chuyển trạng thái và tính toán các xác suất chuyển trạng thái, dựa trên số liệu về hoạt động của hệ thống.
37
Tác giả L. Cheung đề xuất mô hình tính toán độ tin cậy trong giai đoạn thiết kế phần mềm gồm 3 giai đoạn [51]:
Giai đoạn 1: Trong giai đoạn này, tập hợp các trạng thái được xác định bằng cách tận dụng mô hình kiến trúc và thực hiện phân tích tiêu chuẩn, dựa vào chi tiết kiến trúc mô hình. Từ đó xác định được các trạng thái có thể có của hệ thống với các thông số tồn tại của nó.
Giai đoạn 2: Từ thông số các trạng thái nói trên, kết hợp với thông tin về hành vi xác suất của hệ thống (các thông tin này thu được từ số liệu thống kê về hồ sơ hoạt động của hệ thống), người thiết kế xác định được các xác suất chuyển trạng thái để từ đó xây dựng nên mô hình về độ tin cậy của hệ thống.
Giai đoạn 3: Từ các thông số đã biết về mô hình độ tin cậy của hệ thống, áp dụng các mô hình tính toán để xác định, ước đoán về độ tin cậy của hệ thống.
2.1.1.2. Quy trình đánh giá độ tin cậy
Như đã trình bày ở trên, mô hình của L. Cheung [51] gồm 3 giai đoạn để tính toán độ tin cậy của hệ thống phần mềm. Tuy nhiên, cách tiếp cận của Cheung phân tách một hệ thống phần mềm thành các thành phần nhỏ, từ đó sử dụng cấu trúc của hệ thống để xây dựng mô hình hành vi động của hệ thống. Vấn đề đặt ra là nếu hệ thống không phải thể phân tách, phân tách không tường minh hoặc chúng ta không có được thiết kế cấu trúc chi tiết các thành phần của hệ thống thì cách tiếp cận này khó khả thi. Do đó chúng tôi đề xuất quy trình nhằm kết hợp các kỹ thuật của L. Singh [55] và mô hình của L.Cheung cho phép mô hình quá trình hoạt động bình thường của phần mềm bằng tiến trình Markov với là tập hợp trạng thái, là ma trận xác suất chuyển của module . Quy trình đánh giá được thực hiện theo kịch bản 3 bước như sau:
Bƣớc 1.Mô hình hóa hệ thống. Bao gồm các thao tác xác định tập các trạng thái của hệ thống và xác định các phép chuyển đổi trạng thái dựa trên phân tích dữ liệu hoạt động thực tế.
Bƣớc 2.Xây dựng tiến trình Markov. Để xây dựng tiến trình Markov, chúng ta cần xác định được ma trận trạng thái ban đầu và ma trận xác suất chuyển. Tiến trình được đề xuất cần phải đảm bảo:
- Xác định được các xác suất ban đầu của các trạng thái:
- Tổng xác suất ban đầu của các trạng thái là 1.
- Các xác suất chuyển đổi trạng thái, lưu trong ma trận . - Tổng các xác suất từ một trạng thái luôn là 1.
Bƣớc 3. Tính toán mô hình. Ở Bước 2 đã có ma trận xác suất ban đầu
và ma trận xác suất chuyển . Bước tiếp theo chúng ta sẽ xác định ma trận trận xác suất các trạng thái ở thời điểm : .
- Sau 1 đơn vị thời gian, ta có ma trận trạng thái:
38
- Sau 2 đơn vị thời gian, ta có ma trận trạng thái:
(2.2) …
- Sau đơn vị thời gian, ta có ma trận trạng thái:
(2.3) Trong trường hợp tổng quát, theo (2.3) ta có:
(2.4) Xác suất module ở trạng thái tại thời điểm là:
(2.5)
là giá trị của trạng thái trong ma trận trạng thái ở thời điểm (ma trận ). Khi đó, độ tin cậy của module là:
∑ (2.6) Như vậy chúng ta không chỉ tính được độ tin cậy của module mà còn tính được xác suất tồn tại của các trạng thái còn lại trong mô hình tại thời điểm cuối, tức các
.
2.1.2. Cài đặt thực nghiệm
Để thử nghiệm quy trình đề xuất, chúng tôi sử dụng các bộ dữ liệu chuẩn trong [55][51][97] là các dữ liệu được sử dụng nhiều trong các nghiên cứu về áp dụng tiến trình Markov cho mô hình hóa độ tin cậy phần mềm.
2.1.2.1. Cài đặt thử nghiệm 1
Chúng tôi sử dụng bộ dữ liệu thử nghiệm của Young Min Kwon [97] mô hình hóa phần mềm gồm các trạng thái A, B, C để thực hiện một công việc. Các bước của quy trình đề xuất được triển khai như sau.
Bƣớc 1. Mô hình hóa hệ thống
Hệ thống được mô hình hóa bao gồm: Tập trạng thái
Các chuyển đổi trạng thái, biểu diễn bởi mũi tên như Hình 2.1.
Bƣớc 2. Xây dựng tiến trình Markov
Gọi và lần lượt là xác suất tồn tại ban đầu của các trạng thái và . Giả định và đã được xác định, từ đó có các giá trị cụ thể đối với xác suất tồn tại ban đầu của các trạng thái và . Ta có vector xác suất ban đầu là :
Giả thiết có ma trận xác suất chuyển trạng thái , với giá trị ở dòng , cột là xác suất chuyển từ trạng thái sang trạng thái .
39 [ ]
Từ đó ta có mô hình xác suất như Hình 2.1, trong đó xác suất chuyển trạng thái đã được xác định. Ví dụ, xét trạng thái :
Xác suất chuyển trạng thái từ trạng sang trạng thái là . Xác suất chuyển trạng thái từ trạng sang trạng thái là . Xác suất chuyển trạng thái từ trạng sang trạng thái là .
Xác suất chuyển trạng thái từ trạng sang các trạng thái , , là 0. Lưu ý rằng tổng các xác suất từ một trạng thái phải luôn bằng 1, ví dụ trạng thái A:
Hình 2.1. Tiến trình Markov của thử nghiệm 1
Bƣớc 3. Tính toán mô hình
Ta sử dụng bộ tham số giả định:
Từ đó có ma trận xác suất ban đầu là:
Và ma trận xác suất chuyển là 𝐒𝐮 𝐅𝐚
40 [ ]
Theo công thức (2.3), ma trận xác suất ở thời điểm cuối cùng:
Từ đó ta có độ tin cậy hệ thống: . Như vậy, việc áp dụng quy trình 3 bước ở trên đã cung cấp giá trị độ tin cậy của hệ thống sau một thời gian hoạt động rất dài (giả thiết ). Chú ý rằng giá trị độ tin cậy là một giá trị rất thấp so với các giá trị độ tin cậy của các thực nghiệm trong các công trình khác (thông thường ). Lý do vì chỉ có duy nhất một khả năng chuyển từ trạng thái sang trạng thái với xác suất rất thấp: . Từ đó chúng ta có thể rút ra kết luận số lượng phép chuyển trạng thái đến trạng thái
cũng như xác suất xảy ra của các phép chuyển trạng thái đó quyết định rất lớn đến độ tin cậy của hệ thống.
2.1.2.2. Cài đặt thử nghiệm 2
Ở phép thực nghiệm thứ hai, chúng tôi sử dụng bộ dữ liệu thử nghiệm của Leslie Cheung [51]. Chúng ta có các module mô hình hóa chuyển động của một robot với các trạng thái: Idle (Trạng thái dừng), Estimating Sensor Data (ESD - Ước tính dữ liệu cảm biến), Turning Left (TL - Rẽ trái), Turning Right (TR - Rẽ phải), Going Straight (GS - Đi thẳng) và Updating Database (UD - Cập nhật cơ sở dữ liệu). Từ đó ta có các bước của quy trình đánh giá độ tin cậy như sau.
Bƣớc 1: Mô hình hóa hệ thống
Chúng ta có mô hình của hệ thống như trong Hình 2.2.
Hình 2.2. Mô hình hóa hệ thống của thử nghiệm 2
Dừng rẽ/ đi thẳng Đi thẳng Tạm dừng Rẽ phải Dừng rẽ/ đi thẳng Khởi động Rẽ trái Dừng đi, cập nhật CSDL Hết cập nhật Idle TL TR UD GS ESD
41
Hình 2.3. Tiến trình Markov của thử nghiệm 2
[ ]
Bƣớc 2: Xây dựng tiến trình Markov
Dựa vào hồ sơ hoạt động của hệ thống, chúng ta có ma trận xác suất các trạng thái ban đầu:
Với xác suất của ban đầu của trạng thái Idle bằng 1, ta có ma trận xác suất chuyển là (kí hiệu – tương ứng với xác suất 0.0). Từ mô hình của hệ thống và ma trận xác suất chuyển, ta thu được tiến trình Markov như trong Hình 2.3. Hai trạng thái và biểu diễn những trạng thái gặp lỗi của thao tác rẽ phải và rẽ trái, trạng thái Fail được đưa vào mô hình để cụ thể hóa hai trường hợp trên.
Bƣớc 3: Tính toán mô hình
Giả sử thời gian kiểm thử là 1 tiếng (≃ 3600s), từ đó ta có ma trận xác suất ở thời điểm cuối là:
Từ đó ta có xác suất của trạng thái gặp lỗi , từ đó tính được giá trị độ tin cậy của hệ thống:
0.1 0.2 0.2 1.0 0.1 1 1 0.8 0.9 1.0 0.3 0.2 0.8 0.2 1 Idle ESD TL TR UD GS Fail F1 F2 0.2
42
Rõ ràng, so với thực nghiệm thứ nhất, giá trị độ tin cậy của hệ thống cao hơn rất nhiều. Lý do ở đây vì khả năng hệ thống gặp lỗi chỉ xảy ra khi hệ thống gặp hai phép chuyển trạng thái và hai phép chuyển trạng thái này đều có xác suất khá nhỏ:
. Điều này hoàn toàn tương đồng với kết luận rút ra từ thực nghiệm thứ nhất: xác suất chuyển sang trạng thái thất bại thấp (tức xác suất hệ thống hoạt động bình thường cao) tương ứng với độ tin cậy cao.
2.1.2.3. Cài đặt thử nghiệm 3
Trong thử nghiệm thứ ba, chúng tôi sử dụng bộ dữ liệu thử nghiệm của Singh [55] để mô hình hóa một robot bao gồm các thành phần: Controller, Sensor, Follower và GUI. Quy trình ba bước được triển khai ở đây như sau.
Bƣớc 1: Mô hình hóa hệ thống
Hệ thống được mô hình hóa các trạng thái như trong Hình 2.4.
Hình 2.4. Tiến trình Markov của thử nghiệm 3
Bƣớc 2: Xây dựng tiến trình Markov
Ta có ma trận xác suất các trạng thái ban đầu là:
Từ đó ta có ma trận xác suất chuyển như sau.
[ ] Bƣớc 3: Tính toán mô hình
Sử dụng công cụ toán học tính toán được giá trị độ tin cậy của hệ thống là:
Từ kết quả thực nghiệm này ta thấy, tuy xác suất của các phép chuyển từ các trạng thái hoạt động bình thường sang trạng thái lỗi là thấp (lần lượt là và
) nhưng độ tin cậy của hệ thống vẫn thấp. Như vậy, ngoài sự phụ thuộc vào xác
0.9 0.39 0.79 0.2 0.01 0.1 0.02 0.39 0.9 0.1 End GUI Sensor Fail Control 0.2 Follow
43
suất chuyển trạng thái, độ tin cậy còn phụ thuộc vào tập hợp các trạng thái của hệ thống, tức cách thức mô hình tập trạng thái .
Từ những lý thuyết và kết quả thực nghiệm được trình bày trong tiểu mục, chúng tôi rút ra các nhận xét sau:
Thứ nhất: giá trị độ tin cậy của hệ thống được mô hình hóa phụ thuộc vào cả hai yếu tố: cách thức mô hình tập trạng thái và ma trận xác suất chuyển trạng thái.
Thứ hai: mô hình và quy trình áp dụng để đánh giá độ tin cậy của phần mềm trong giai đoạn thiết kế sẽ cho kết quả có độ chính xác cao nếu như các tham số giả định trong thành phần tính toán thu được là có giá trị gần với giá trị thực tế.
Thứ ba: ưu điểm của mô hình là có thể đưa ra những đánh giá về độ tin cậy của phần mềm trong giai đoạn thiết kế, giúp cho giảm được chi phí kiểm thử do không phải tạo ra tất cả các trường hợp để thử nghiệm và nếu có thể tạo ra một số lượng lớn trường hợp để đánh giá gần đúng.
Tuy nhiên, một số tồn tại của mô hình có thể chỉ ra như sau:
Việc mô hình hóa các module đòi hỏi phải có kinh nghiệm của người đánh giá. Việc ước lượng xác suất tồn tại các trạng thái tương đối khó khăn, đòi hỏi phải
dựa trên số liệu thống kê về hồ sơ hoạt động của module.
Khó mô hình hóa, khó có phương pháp tiếp cận với hệ thống ứng dụng công nghệ như RMI (Remote Method Invocation), RPC (Remote Procedure Call) là những công nghệ liên quan tới việc sử dụng các hàm của các chương trình Java trong một mạng phân tán.
Chúng tôi đề xuất hướng để mở rộng công việc hiện tại về tìm hiểu các ràng buộc của hệ thống, từ đó đưa vào mô hình nhằm nâng cao độ chính xác tính toán.
Kết quả nghiên cứu trong phần này đã được công bố trong công trình số 1 (danh mục các công trình đã công bố của luận án) tại Tạp chí Khoa học và Công nghệ các trường đại học kỹ thuật, số 102 năm 2014.
2.2. Tiến trình Markov mô hình hóa tiến trình trẻ hóa của phần mềm
2.2.1. Sự trẻ hóa của hệ thống phần mềm
Trong thực tế, chúng ta hoàn toàn có thể gặp một ứng dụng phần mềm chạy liên tục trong một khoảng thời gian dài, ví dụ như ứng dụng phân tích khoa học có thể chạy trong vài ngày hoặc vài tuần hay ứng dụng máy chủ trong kiến trúc máy chủ-máy khách được xây dựng để hoạt động liên tục. Khi đó tiến trình tương ứng với phần mềm sẽ bị lão hóa (aging), nói cách khác là bị suy giảm từ từ về khả năng sử dụng tài nguyên của hệ thống [18]. Nguyên nhân của sự lão hóa bao gồm: sự rò rỉ bộ nhớ (xảy ra do tiến trình quản lý bộ nhớ thiếu hiệu quả), quản lý khóa file không an toàn, sự không thống nhất trong truy nhập và thao tác file, v.v.. Sự lão hóa phần mềm sẽ ảnh hưởng đến hiệu năng của ứng dụng và thậm chí khiến ứng dụng không tiếp tục hoạt động được nữa [94].
44
Nếu một ứng dụng được xây dựng trong môi trường phát triển hoàn hảo và hoạt động theo đúng kịch bản làm việc, tiến trình tương ứng sẽ không bị lão hóa. Tuy nhiên, các hệ thống thực tế hiếm khi đạt được điều đó. Các tiến trình của chúng sẽ bị lão hóa trong môi trường thực chạy. Chú ý rằng sự lão hóa phần mềm và sự lão hóa tiến trình có những khác biệt nhỏ. Sự lão hóa phần mềm liên quan đến việc mã nguồn trở nên không tương thích khi yêu cầu bị thay đổi sau nhiều năm. Ngược lại, sự lão hóa tiến trình liên quan đến sự suy giảm hoạt động của các chức năng của phần mềm sau quá trình hoạt động trong vài ngày hoặc vài tuần.
Hình 2.5. Mô hình trạng thái của hệ thống trẻ hóa
Ngược lại với sự lão hóa của tiến trình phần mềm, "sự trẻ hóa phần mềm (software rejuvenation)", là một khái niệm liên quan đến khởi động lại phần mềm một cách định kì và đưa hệ thống về trạng thái sạch sẽ ban đầu sau mỗi lần bảo trì [96][83]. Kỹ thuật này còn có một tên gọi khác là "sự bảo trì phòng ngừa (software preventive maintenance)". Ta có Hình 2.5 mô tả tổng quan bốn trạng thái của hệ thống khi áp dụng kĩ thuật trẻ hóa. Trong kỹ thuật này, thay vì để hệ thống xảy ra sự cố khi tiến trình bị lão hóa, chúng ta có thể thực hiện việc trẻ hóa tiến trình nhằm đảm bảo sự hoạt động bình thường. Hiện kỹ thuật trẻ hóa phần mềm đã được ứng dụng trên rất nhiều kiến trúc phần mềm khác nhau như kiến trúc client-server [96], kiến trúc cluster [48], kiến trúc cho máy chủ dựa trên giao thức SOAP [54], v.v..
Ở mục tiếp theo, chúng ta sẽ thực hiện các tính toán đánh giá giá trị các độ đo chất lượng phần mềm như là biến của thời gian thực hiện trẻ hóa.
2.2.2. Phƣơng thức đánh giá độ tin cậy, độ sẵn sàng và độ an toàn của hệ thống phần mềm trẻ hóa
2.2.2.1. Mô hình hóa hệ thống
Chúng ta xét đến một hệ thống theo mô hình khách - chủ (client – server), trong đó hệ thống nhận được các yêu cầu (transaction) từ máy khách và phục vụ các yêu cầu đó. Hệ thống cài đặt một bộ đệm theo dạng hàng đợi, tức cơ chế đến trước phục vụ trước (First Come First Serve), để tiếp nhận các yêu cầu [78]. Tiến trình Markov để mô hình hệ thống phần mềm khi thực hiện kỹ thuật trẻ hóa sẽ bao gồm ba trạng thái như tại Hình 2.6.
- : trạng thái hệ thống hoạt động bình thường: sẵn sàng phục vụ các yêu cầu. - : trạng thái không an toàn, tức trạng thái phần mềm gặp phải những lỗi. Khi