1. Trang chủ
  2. » Công Nghệ Thông Tin

Công nghệ phần mềm chuong 8

15 34 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 15
Dung lượng 135,31 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

 Các quá trình đáng tin cậy  Cách sử dụng các quy trình đáng tin cậy dẫn đến các hệ thống đáng tin cậy  Kiến trúc hệ thống đáng tin cậy  Các mẫu kiến trúc về tính chịu lỗi phần mềm 

Trang 1

Bài giảng 8 - Kỹ thuật tin cậy

Phần 1 Chủ đề được bảo vệ

 Sự thừa và đa dạng

 Các phương pháp cơ bản để đạt được sự khoan dung lỗi

 Các quá trình đáng tin cậy

 Cách sử dụng các quy trình đáng tin cậy dẫn đến các hệ thống đáng tin cậy

 Kiến trúc hệ thống đáng tin cậy

 Các mẫu kiến trúc về tính chịu lỗi phần mềm

 Lập trình bền vững

 Hướng dẫn lập trình để tránh lỗi

Độ tin cậy phần mềm

 Nói chung, khách hàng phần mềm mong đợi tất cả các phần mềm đều đáng tin cậy Tuy nhiên, đối với các ứng dụng không quan trọng, họ có thể sẵn sàng chấp nhận một số lỗi hệ thống

 Một số ứng dụng (hệ thống quan trọng) có những yêu cầu độ tin cậy rất cao và kỹ thuật công nghệ phần mềm đặc biệt có thể được sử dụng để đạt được điều này

 Viễn thông và hệ thống điện

 Hệ thống không gian vũ trụ

Thành tựu đáng tin cậy

 Tránh lỗi

 Hệ thống được phát triển theo cách mà tránh được lỗi của con người và do đó các lỗi hệ thống được giảm thiểu

 Quá trình phát triển được tổ chức để các lỗi trong hệ thống được phát hiện và sửa chữa trước khi giao hàng cho khách hàng

 Phát hiện lỗi

 Các kỹ thuật xác minh và xác nhận được sử dụng để phát hiện và loại bỏ các lỗi trong hệ thống trước khi nó được triển khai

 Khả năng chịu lỗi

 Hệ thống được thiết kế sao cho các lỗi trong phần mềm được phân phối không dẫn đến lỗi hệ thống

Trang 2

Chi phí gia tăng của việc loại bỏ lỗi dư

Hệ thống quy định

 Nhiều hệ thống quan trọng là các hệ thống quy định, có nghĩa là việc sử dụng chúng phải được chấp thuận bởi một nhà điều tiết bên ngoài trước khi hệ thống đi vào hoạt động

 Hệ thống hạt nhân

 Hệ thống kiểm soát không lưu

 Các thiết bị y tế

 Một trường hợp an toàn và đáng tin cậy phải được sự chấp thuận của cơ quan quản lý Do đó, việc phát triển các hệ thống quan trọng phải tạo ra bằng chứng thuyết phục nhà quản lý rằng hệ thống này là đáng tin cậy, an toàn

và an toàn

Đa dạng và sự dư thừa

 Giữ nhiều hơn một phiên bản của một thành phần quan trọng có sẵn để nếu một trong những thất bại sau đó một bản sao lưu có sẵn

 Đa dạng

 Cung cấp các chức năng tương tự theo những cách khác nhau để họ sẽ không thất bại trong cùng một cách

 Tuy nhiên, việc bổ sung tính đa dạng và sự dư thừa cho thấy sự phức tạp và điều này có thể làm tăng cơ hội sai sót

 Một số kỹ sư ủng hộ tính đơn giản và V & V rộng lớn là một tuyến đường hiệu quả hơn để đảm bảo tính tin cậy của phần mềm

Đa dạng Và các ví dụ dự phòng

Trang 3

 Dư Nơi sẵn có là rất quan trọng (ví dụ như trong hệ thống thương

mại điện tử), các công ty thường giữ các máy chủ sao lưu và chuyển sang những

tự động nếu thất bại xảy ra

 Đa dạng Để cung cấp khả năng chống lại các cuộc tấn công bên

ngoài, các máy chủ khác nhau có thể được triển khai bằng cách sử dụng các hệ

điều hành khác nhau (ví dụ Windows và Linux)

Đa dạng quá trình và sự thừa

 Các hoạt động của quá trình, chẳng hạn như xác nhận hợp lệ,

không nên phụ thuộc vào một cách tiếp cận đơn lẻ, chẳng hạn như kiểm tra, để

xác nhận tính hợp lệ của hệ thống

 Thay vào đó, nhiều hoạt động khác nhau của quá trình bổ sung lẫn

nhau và cho phép kiểm tra chéo giúp tránh lỗi quá trình, có thể dẫn đến lỗi trong

phần mềm

Các quá trình đáng tin cậy

 Để đảm bảo một số lỗi phần mềm tối thiểu, điều quan trọng là phải

có quy trình phần mềm được xác định rõ ràng, lặp lại

 Một quá trình lặp lại được xác định rõ ràng là một quá trình không

phụ thuộc hoàn toàn vào các kỹ năng cá nhân; thay vì có thể được ban hành bởi

những người khác nhau

 Các nhà quản lý sử dụng thông tin về quy trình để kiểm tra xem có

thực hành kỹ thuật phần mềm tốt hay không

 Để phát hiện lỗi, rõ ràng là các hoạt động của quá trình nên bao

gồm các nỗ lực đáng kể dành cho việc xác minh và xác nhận

Các thuộc tính của các quá trình đáng tin cậy

Đặc tính quá trình Sự miêu tả

Tài liệu Quá trình cần có một mô hình quy trình xác định đưa ra các hoạt

động trong quy trình và tài liệu được sản xuất trong các hoạt động này

Tiêu chuẩn hoá Một bộ tiêu chuẩn phát triển phần mềm toàn diện bao gồm sản

xuất phần mềm và tài liệu nên có sẵn

Auditable Quá trình này cần được hiểu rõ bởi những người ngoài những

người tham gia quá trình, những người có thể kiểm tra xem các tiêu chuẩn quy trình đang được tuân thủ và đưa ra các gợi ý để cải tiến quy trình

Phong phú Quá trình nên bao gồm các hoạt động xác minh và xác nhận dự

phòng thừa và đa dạng

Mạnh mẽ Quá trình này sẽ có thể phục hồi từ thất bại của các hoạt động

của từng quá trình

Các hoạt động xác nhận

Trang 4

 Đánh giá yêu cầu

 Quản lý yêu cầu

 Đặc điểm chính thức

 xây dựng mô hình hệ thống

 Thiết kế và kiểm tra mã

 Phân tích tĩnh

 Lập kế hoạch kiểm tra và quản lý

 Quản lý thay đổi, thảo luận trong Chương 25, cũng rất cần thiết

Khả năng chịu lỗi

 Trong các tình huống nguy kịch, các hệ thống phần mềm phải Chịu lỗi

 Khả năng chịu lỗi là cần thiết khi có yêu cầu về tính khả dụng cao hoặc khi mà chi phí hỏng hóc của hệ thống rất cao

 Khả năng chịu lỗi có nghĩa là hệ thống có thể tiếp tục hoạt động bất chấp sự thất bại của phần mềm

 Ngay cả khi hệ thống đã được chứng minh là phù hợp với đặc điểm kỹ thuật của nó, nó cũng phải chịu lỗi vì có thể có lỗi kỹ thuật hoặc xác nhận có thể không chính xác

Kiến trúc hệ thống đáng tin cậy

 Kiến trúc hệ thống đáng tin cậy được sử dụng trong những trường hợp cần phải có khả năng chịu lỗi Các kiến trúc nói chung đều dựa trên sự thừa

và đa dạng

 Ví dụ về các tình huống khi các kiến trúc đáng tin cậy được sử dụng:

 Hệ thống kiểm soát chuyến bay, nơi mà sự thất bại của hệ thống có thể đe doạ đến sự an toàn của hành khách

 Các hệ thống lò phản ứng mà sự thất bại của một hệ thống điều khiển có thể dẫn đến tình trạng khẩn cấp hóa học hoặc hạt nhân

 Hệ thống viễn thông, nơi có nhu cầu sử dụng 24/7

Hệ thống bảo vệ

 Một hệ thống chuyên biệt liên quan đến một số hệ thống kiểm soát khác có thể thực hiện hành động khẩn cấp nếu xảy ra sự cố

 Hệ thống để dừng một chuyến tàu nếu nó đi qua một ánh sáng màu đỏ

 Hệ thống để đóng lò phản ứng nếu nhiệt độ / áp suất quá cao

Trang 5

 Hệ thống bảo vệ độc lập giám sát hệ thống kiểm soát và môi trường

 Nếu một vấn đề được phát hiện, nó ra lệnh để thực hiện hành động khẩn cấp để tắt hệ thống và tránh một thảm hoạ

Kiến trúc hệ thống bảo vệ

Chức năng hệ thống bảo vệ

 Các hệ thống bảo vệ là dư thừa bởi vì chúng bao gồm các khả năng giám sát và điều khiển nhân bản những phần trong phần mềm điều khiển

 Các hệ thống bảo vệ nên được đa dạng và sử dụng các công nghệ khác nhau từ phần mềm điều khiển

 Chúng đơn giản hơn hệ thống điều khiển vì vậy có thể tốn nhiều công sức hơn để kiểm chứng và đảm bảo độ tin cậy

Trang 6

 Mục tiêu là để đảm bảo rằng có một xác suất thấp của sự thất bại

về nhu cầu cho hệ thống bảo vệ

Kiến trúc tự giám sát

 Kiến trúc đa kênh, nơi hệ thống theo dõi các hoạt động của riêng mình và thực hiện hành động nếu phát hiện sự không nhất quán

 Cùng một tính toán được thực hiện trên mỗi kênh và kết quả được

so sánh Nếu kết quả giống hệt nhau và được sản xuất cùng một lúc thì giả định rằng hệ thống đang hoạt động chính xác

 Nếu kết quả là khác nhau, sau đó một thất bại được giả định và một lỗi ngoại lệ được nêu ra

Kiến trúc tự giám sát

Hệ thống tự giám sát

 Phần cứng trong mỗi kênh phải đa dạng vì vậy sự cố phần cứng chung sẽ không dẫn đến mỗi kênh có cùng kết quả

 Phần mềm trong từng kênh cũng phải đa dạng, nếu không lỗi phần mềm tương tự sẽ ảnh hưởng đến từng kênh

 Nếu cần có tính sẵn sàng cao, bạn có thể sử dụng nhiều hệ thống

tự kiểm tra song song

 Đây là cách tiếp cận được sử dụng trong dòng máy bay Airbus cho hệ thống kiểm soát bay của họ

Kiến trúc hệ thống điều khiển chuyến bay của Airbus

Trang 7

Thảo luận về kiến trúc Airbus

 Airbus FCS có 5 máy tính riêng biệt, trong đó một máy có thể chạy phần mềm điều khiển

 Sử dụng rộng rãi đã được thực hiện của sự đa dạng

 Các hệ thống chính sử dụng một bộ xử lý khác nhau từ các

hệ thống thứ cấp

 Các hệ thống chính và trung học sử dụng chipset từ các nhà sản xuất khác nhau

 Phần mềm trong hệ thống thứ cấp là ít phức tạp hơn so với các hệ thống chính - chỉ cung cấp chức năng rất quan trọng

 Phần mềm trong mỗi kênh được phát triển bằng các ngôn ngữ lập trình khác nhau của các nhóm khác nhau

 Các ngôn ngữ lập trình khác nhau được sử dụng trong các

hệ thống sơ cấp và trung học

Những điểm chính

 Khả năng tin cậy trong một chương trình có thể đạt được bằng cách tránh những sai sót, bằng cách phát hiện và loại bỏ các lỗi trước khi triển khai hệ thống, và bao gồm các cơ sở chịu lỗi

 Việc sử dụng sự thừa và đa dạng trong phần cứng, quá trình phần mềm và các hệ thống phần mềm là điều cần thiết cho sự phát triển của các hệ thống đáng tin cậy

Trang 8

 Việc sử dụng một quy trình được xác định rõ ràng, lặp lại là cần thiết nếu những lỗi trong hệ thống phải được giảm thiểu

 Kiến trúc hệ thống đáng tin cậy là các kiến trúc hệ thống được thiết kế cho khả năng chịu lỗi Các kiểu kiến trúc hỗ trợ khả năng chịu lỗi bao gồm các hệ thống bảo vệ, kiến trúc tự giám sát và lập trình phiên bản N

Bài giảng 8 - Kỹ thuật tin cậy

Phần 2 N-phiên bản chương trình

 Nhiều phiên bản của một hệ thống phần mềm thực hiện tính toán cùng một lúc Cần có một số lượng máy tính lẻ, ví dụ 3

 Kết quả được so sánh bằng cách sử dụng một hệ thống bỏ phiếu và kết quả phần lớn được coi là kết quả chính xác

 Phương pháp tiếp cận có nguồn gốc từ khái niệm thừa thừa ba mô đun, như được sử dụng trong các hệ thống phần cứng

Dung sai lỗi phần cứng

 Phụ thuộc vào dự phòng thừa ba (modular redundancy sự thừa mô đun - TMR)

 Có ba thành phần trùng lặp giống nhau nhận được cùng một đầu vào và có kết quả đầu ra được so sánh

 Nếu một đầu ra là khác nhau, nó là bỏ qua và hư hỏng thành phần được giả định

 Dựa vào hầu hết các lỗi do lỗi thành phần chứ không phải lỗi thiết

kế và xác suất thấp của sự cố đồng thời thành phần

Thừa ba mô đun

N-phiên bản chương trình

Trang 9

N-phiên bản chương trình

 Các phiên bản hệ thống khác nhau được thiết kế và thực hiện bởi các nhóm khác nhau Người ta giả định rằng có một xác suất thấp rằng họ sẽ mắc phải những sai lầm tương tự Các thuật toán được sử dụng nên nhưng có thể không khác nhau

 Có một số bằng chứng thực nghiệm cho thấy các nhóm thường giải thích sai thông số kỹ thuật theo cùng một cách và chọn các thuật toán tương

tự trong hệ thống của họ

Đa dạng phần mềm

 Cách tiếp cận để khoan dung lỗi phần mềm phụ thuộc vào sự đa dạng của phần mềm khi giả định rằng các cài đặt khác nhau của cùng một đặc tả phần mềm sẽ thất bại theo những cách khác nhau

 Người ta cho rằng việc triển khai là (a) độc lập và (b) không bao gồm lỗi phổ biến

 Các chiến lược để đạt được sự đa dạng

 Ngôn ngữ lập trình khác nhau

 Các phương pháp và công cụ thiết kế khác nhau

 Mô tả rõ ràng các thuật toán khác nhau

Vấn đề với sự đa dạng thiết kế

 Các đội không có văn hoá đa dạng nên họ có xu hướng giải quyết các vấn đề theo cách tương tự

 Lỗi đặc trưng

 Các đội khác nhau cũng có những sai lầm tương tự Một số phần của quá trình thực hiện khó khăn hơn nhiều so với những người khác vì vậy tất cả các nhóm đều có xu hướng mắc sai lầm ở cùng một nơi;

Trang 10

 Nếu có một lỗi trong đặc tả thì điều này được phản ánh trong tất cả các hiện thực;

 Điều này có thể được giải quyết đến một mức độ nào đó bằng cách sử dụng nhiều đại diện đặc điểm kỹ thuật

Phụ thuộc hàm

 Cả hai phương pháp tiếp cận phần mềm dự phòng đều dễ bị lỗi kỹ thuật Nếu các đặc điểm kỹ thuật là không chính xác, hệ thống có thể thất bại

 Đây cũng là vấn đề về phần cứng nhưng các đặc tả phần mềm thường phức tạp hơn các chi tiết kỹ thuật phần cứng và khó kiểm chứng hơn

 Điều này đã được giải quyết trong một số trường hợp bằng cách phát triển các đặc tả phần mềm riêng biệt từ cùng một đặc tả người dùng

Cải tiến trong thực tế

 Về nguyên tắc, nếu đa dạng và độc lập có thể đạt được, lập trình

đa lập trình dẫn đến những cải tiến rất đáng kể về độ tin cậy và tính sẵn có

 Trong thực tế, những cải tiến quan sát được ít quan trọng hơn nhưng cách tiếp cận này dường như dẫn đến sự cải thiện độ tin cậy giữa 5 đến 9 lần

 Câu hỏi then chốt là liệu các cải tiến này có xứng đáng với chi phí phát triển đáng kể cho các chương trình đa ngôn ngữ hay không

Lập trình bền vững

 Thực tiễn lập kế hoạch tốt có thể được áp dụng để giúp giảm tỷ lệ mắc các lỗi của chương trình

 Những hoạt động lập trình hỗ trợ

 Phát hiện lỗi

 Khả năng chịu lỗi

Hướng dẫn thực hành tốt cho lập trình tin cậy

Hướng dẫn lập trình vững vàng

1 Giới hạn khả năng hiển thị thông tin trong một chương trình

2 Kiểm tra tất cả các yếu tố đầu vào cho hiệu lực

3 Cung cấp một trình xử lý cho tất cả các ngoại lệ

4 Giảm thiểu việc sử dụng cấu trúc dễ bị lỗi

5 Cung cấp khả năng khởi động lại

6 Kiểm tra mảng giới hạn

7 Bao gồm hết thời gian chờ khi gọi các thành phần bên ngoài

8 Đặt tên cho tất cả các hằng số thể hiện giá trị thực

Kiểm soát khả năng hiển thị thông tin trong một chương trình

 Các thành phần của chương trình chỉ nên được phép truy cập dữ liệu mà họ cần để thực hiện

Trang 11

 Điều này có nghĩa là tình cờ tham nhũng của các phần của chương trình nhà nước của các thành phần này là không thể

 Bạn có thể kiểm soát khả năng hiển thị bằng cách sử dụng các kiểu

dữ liệu trừu tượng mà phần dữ liệu là riêng tư và bạn chỉ cho phép truy cập vào

dữ liệu thông qua các hoạt động được xác định trước như get () và put ()

Kiểm tra tất cả các yếu tố đầu vào cho hiệu lực

 Tất cả các chương trình lấy đầu vào từ môi trường của họ và đưa

ra các giả định về những đầu vào này

 Tuy nhiên, các đặc điểm của chương trình hiếm khi xác định phải làm gì nếu đầu vào không phù hợp với những giả định này

 Do đó, nhiều chương trình hoạt động không thể đoán trước khi xuất hiện với các đầu vào bất thường và đôi khi đó là những mối đe dọa đối với

an ninh của hệ thống

 Do đó, bạn luôn phải kiểm tra đầu vào trước khi xử lý dựa trên các giả định về các đầu vào này

Kiểm tra tính hợp lệ

 Kiểm tra phạm vi

 Kiểm tra xem đầu vào có nằm trong phạm vi đã biết hay chưa

 Kiểm tra kích thước

 Kiểm tra xem đầu vào không vượt quá kích thước tối đa, ví dụ: 40 ký tự cho tên

 Kiểm tra đại diện

 Kiểm tra xem đầu vào không bao gồm các ký tự không phải

là một phần của biểu diễn của nó ví dụ như tên không bao gồm các chữ số

 Kiểm tra hợp lý

 Sử dụng thông tin về đầu vào để kiểm tra xem nó có hợp lý chứ không phải là giá trị cực đoan

Cung cấp một trình xử lý cho tất cả các ngoại lệ

 Một ngoại lệ của chương trình là một lỗi hoặc một số Sự kiện bất ngờ như mất điện

 Các cấu trúc xử lý ngoại lệ cho phép Các sự kiện được xử lý mà không cần Kiểm tra trạng thái liên tục để phát hiện các ngoại lệ

 Sử dụng cấu trúc điều khiển bình thường để phát hiện Ngoại lệ cần nhiều báo cáo bổ sung được Thêm vào chương trình Điều này làm tăng thêm đáng kể

Chi phí và có khả năng bị lỗi

Ngày đăng: 21/02/2020, 22:34

🧩 Sản phẩm bạn có thể quan tâm

w