TÌM HIỂU CÔNG NGHỆ DESIGN BY CONTRACT VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ CHO C# - 3 potx

12 328 0
TÌM HIỂU CÔNG NGHỆ DESIGN BY CONTRACT VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ CHO C# - 3 potx

Đ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

Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# n>0; x/=Void Lưu ý cách dùng dấu chấm phẩy (“;”) Ý nghĩa dấu chấm phẩy tương đương với phép and Dấu chấm phẩy đặt phần khai báo thị Khi mệnh đề xác nhận nằm dịng khác nhau, ta khơng cần dùng dấu chấm phẩy (xem có phép and mặc định dòng liên tiếp) Những quy ước giúp ta nhận biết thành phần riêng biệt xác nhận Trong thực tế, ta thường dán nhãn (label) cho thành phần này, ví dụ như: Positive: n>0 Not_void: x/=Void Các nhãn có vai trò định lúc thực thi xác nhận Tuy nhiên, việc sử dụng chúng nhằm làm cho văn ta rõ ràng tường minh Chương 6: Tiền điều kiện hậu điều kiện Ứng dụng xác nhận đặc tả ngữ nghĩa thủ tục Một thủ tục không đoạn mã chương trình mà cài đặt hàm từ đặc tả kiểu liệu trừu tượng, thực cơng việc hữu ích Việc biểu diễn cơng việc cách xác vơ cần thiết Ta đặc tả cơng việc cần thực thi thủ tục xác nhận liên quan với tiền điều kiện (preconditions) hậu điều kiện (postconditions) Tiền điều kiện thuộc tính cần thoả mãn thủ tục gọi; hậu điều kiện thuộc tính chắn có sau thủ tục thực thi xong 6.1 Lớp ngăn xếp Một ví dụ giúp ta làm quen với cách sử dụng xác nhận: 25 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# class STACK [G] feature …Declaration of the features: count, empty, full, put, remove, item end Trước xem phần cài đặt, cần ý thủ tục đặc trưng thuộc tính ngữ nghĩa mạnh mẽ độc lập với cách biểu diễn Ví dụ như: − remove item thực thi có số phần tử lớn − put tăng số phần tử lên 1, remove giảm số phần tử Những thuộc tính phần đặc tả kiểu liệu trừu tượng, người chưa sử dụng đến kiểu liệu trừu tượng phải hiểu Nhưng cách tiếp cận thông thường việc xây dựng phần mềm, văn phần mềm thường không đề cập đến chúng Thông qua tiền điều kiện hậu điều kiện thủ tục, ta đưa chúng vào thành phần tường minh phần mềm Ta biểu diễn tiền điều kiện hậu điều kiện mệnh đề giới thiệu qua hai từ khóa require ensure Lưu ý phần cài đặt thủ tục chừa trống, ta tìm hiểu phần sau indexing description: "Stacks: Cấu trúc liệu với quy tắc truy xuất LIFO” class STACK1 [G] feature – Access count: INTEGER Số phần tử Stack item: G is Phần tử require not empty 26 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# … end feature – Status report empty: BOOLEAN is Kiểm tra Stack rỗng? end full: BOOLEAN is Kiểm tra Stack đầy? … end feature Element change put (x: G) is Thêm phần tử x vào Stack require not full … ensure not empty item = x count = old count + end remove is Xóa phần tử Stack require not empty … ensure not full 27 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# count = old count – end end Cả mệnh đề require ensure tùy chọn Nếu có require phải nằm trước mệnh đề local Những phần giải thích chi tiết ý nghĩa tiền điều kiện hậu điều kiện 6.2 Tiền điều kiện Tiền điều kiện biểu diễn ràng buộc mà thủ tục thực cách xác Ví dụ như: − put không gọi ngăn xếp đầy − remove item không thực ngăn xếp rỗng Tiền điều kiện vào có hiệu lực đến tất lời gọi thủ tục, lớp từ lớp liên quan Một hệ thống xác không thực thi lời gọi không thỏa mãn tiền điều kiện 6.3 Hậu điều kiện Hậu điều kiện biểu diễn thuộc tính trạng thái kết có sau thực thi thủ tục Ví dụ như: − Sau thủ tục put, ngăn xếp rỗng, phần tử phần tử thêm vào, số lượng phần tử tăng lên − Sau thủ tục remove, ngăn xếp đầy, số phần tử giảm Sự có mặt mệnh đề hậu điều kiện thủ tục bảo đảm kết thủ tục thoả mãn thuộc tính (giả sử thủ tục thỏa mãn tiền điều kiện để gọi) Một từ khóa đặc biệt, old, xuất hậu điều kiện put remove dùng từ khóa để biểu diễn thay đổi biến count Cú pháp: old e, e 28 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# biểu thức, thường thuộc tính, biểu thị giá trị e đầu vào thủ tục Hậu điều kiện put có mệnh đề count = old count + để thể put, gọi đối tượng nào, tăng giá trị biến count đối tượng lên Chương 7: Giao ước cho tính đáng tin cậy phần mềm Định nghĩa tiền điều kiện hậu điều kiện cho thủ tục cách định nghĩa hợp đồng (contract) thủ tục lớp gọi 7.1 Quyền lợi nghĩa vụ Bằng cách kết hợp mệnh đề require pre ensure post thủ tục r, lớp đối tượng “tuyên bố” với khách hàng nó: Nếu bạn hứa gọi r thỏa mãn pre, hứa trả kết thỏa mãn post Trong mối liên hệ người người công ty với nhau, hợp đồng văn làm cho điều khoản mối quan hệ trở nên sáng, rõ ràng Thật đáng ngạc nhiên lĩnh vực phần mềm, nơi mà đắn, rõ ràng có vai trị sống cịn, ý tưởng hợp đồng lại phải nhiều thời gian để thể Tiền điều kiện hậu điều kiện mơ tả hợp đồng thủ tục (đóng vai trị nhà cung cấp) đối tượng gọi đến (vai trị khách hàng) Đặc tính quan trọng hợp đồng cơng việc người địi hỏi “nghĩa vụ” (obligation) “quyền lợi” (right) cho bên – thường nghĩa vụ bên trở thành quyền lợi bên Điều hợp đồng lớp đối tượng: 29 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# − Tiền điều kiện ràng buộc khách hàng: định nghĩa điều kiện để lời gọi đến thủ tục trở nên hợp pháp Đây nghĩa vụ khách hàng quyền lợi nhà cung cấp − Hậu điều kiện ràng buộc lớp đối tượng: định nghĩa điều kiện cần phải đảm bảo thủ tục trả Đây quyền lợi khách hàng nghĩa vụ nhà cung cấp 7.1.1 Những quyền lợi − Đối với khách hàng, đảm bảo thuộc tính phải có sau gọi thủ tục − Đối với nhà cung cấp, đảm bảo tính chất phải thỏa mãn nơi thủ tục gọi 7.1.2 Những nghĩa vụ − Đối với khách hàng, đáp ứng yêu cầu phát biểu tiền điều kiện − Đối với nhà cung cấp, phải làm mà hậu điều kiện định Đây hợp đồng cho thủ tục put ví dụ trên: Nghĩa vụ put Quyền lợi Kết hậu điều kiện: Khách hàng Đáp ứng tiền điều kiện: Chỉ gọi Thông tin ngăn xếp cập put(x) ngăn xếp chưa đầy nhật: không rỗng, x nằm cùng, count tăng Đáp ứng hậu điều kiện: Cập Nhà cung cấp nhật thông tin ngăn xếp: không rỗng, x nằm cùng, count tăng 30 Kết tiền điều kiện: Được bảo đảm ngăn xếp chưa đầy put gọi Tìm hiểu công nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# 7.2 Nghệ thuật tin cậy phần mềm: kiểm tra hơn, bảo đảm nhiều Mặc dù bạn chưa để ý, nguyên tắc hợp đồng có xu hướng ngược lại kiến thức tổng quát công nhận ngành công nghiệp phần mềm; gặp nhiều phản ứng từ đầu, Design by Contract số đóng góp vào tin cậy phần mềm đạt tầm quan trọng xứng đáng Một quy tắc tương phản với quan sát nêu trên: tiền điều kiện quyền lợi nhà cung cấp biểu diễn góc bên phải bảng trên: phần khách hàng hợp đồng không thõa mãn, nói cách khác lời gọi khơng đáp ứng tiền điều kiện, sau lớp đối tượng khơng bao bọc hậu điều kiện Trong trường hợp thủ tục làm chuyện gì: trả giá trị bất kỳ, lặp vô hạn, không trả giá trị, chí làm hỏng thực thi cách Đây trường hợp “khách hàng sai” Lợi ích thỏa thuận đơn giản hóa đáng kể phong cách lập trình Tiền điều kiện xem ràng buộc mà lời gọi đến thủ tục phải tuân theo, bạn người phát triển lớp đối tượng, bạn giả sử ràng buộc thỏa mãn viết thủ tục; bạn không cần phải kiểm tra ràng buộc thủ tục Xét hàm bậc sau: sqrt (x: REAL): REAL is Căn bậc x require x >= … end Bạn viết thuật tốn tính bậc mà khơng cần quan tâm đến trường hợp x < 0, điều kiểm tra tiền điều kiện trở thành trách nhiệm khách hàng – lớp gọi tới hàm Thực tế phương pháp Design by Contract xa Viết đoạn chương trình vào sau 31 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# if x < then “Handle the error, somehow” else “Proceed with normal square root computation” end không không cần thiết mà chấp nhận Điều biểu diễn nguyên tắc: Nguyên tắc không dư thừa Không kiểm tra tiền điều kiện thân thủ tục trường hợp Nguyên tắc ngược với chủ trương nhiều sách giáo khoa công nghệ phần mềm hay phương pháp lập trình, thường biết đến phương pháp lập trình phịng thủ - với ý tưởng: để thu phần mềm đáng tin cậy, bạn nên thiết kế thành phần hệ thống cho có khả tự bảo vệ cao Thà dư thiếu, người không cẩn thận tiếp xúc với người lạ Sự kiểm tra dư thừa vơ ích, khơng gây tác hại Design By Contract theo hướng ngược lại: kiểm tra dư thừa thật gây tác hại Điều nghe lạ, người nghĩ kiểm tra dư thừa vơ ích, gây tác hại Tuy nhiên người có hiểu biết chưa sâu tính tin cậy phần mềm tập trung vào phần riêng biệt phần mềm có suy nghĩ Nếu hạn chế tầm nhìn phạm vi hẹp thành phần cụ thể, ví dụ thủ tục sqrt trên, ta thấy thủ tục chặt chẽ có phần kiểm tra thêm thân thủ tục Nhưng hệ thống không giới hạn thủ tục cụ thể mà bao gồm nhiều thủ tục nhiều lớp đối tượng khác Để đạt hệ thống 32 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# đáng tin cậy, ta phải từ bỏ nhìn hạn chế để có tầm nhìn vĩ mơ, bao hàm kiến trúc tổng thể Nếu ta có nhìn tính đơn giản trở thành tiêu chuẩn định Như ta nói từ đầu, phức tạp kẻ thù chất lượng Khi quan tâm đến điều này, ta thấy kiểm tra dư thừa khơng cịn vơ hại Thử hình dung hệ thống thơng thường, với hàng ngàn thủ tục, kiểm tra dư thừa trở thành phức tạp không cần thiết khổng lồ Nếu bắt đầu đường này, chắn điều là: khơng đạt hệ thống đáng tin cậy Với Design By Contract, bạn nhận điều kiện chắn cần thiết để thực chức liên hiệp khách hàng – nhà cung cấp (hay gọi hợp đồng); rõ ràng, điền kiện, cần xác định rõ trách nhiệm ai: khách hàng hay nhà cung cấp Có thể có nhiều câu trả lời, theo chừng mực đó, điều phong cách thiết kế khác Nhưng bạn định bạn cần phải bám vào Nếu bạn có u cầu xác tiền điều kiện, xác định rõ yêu cầu phần trách nhiệm khách hàng (những lời gọi đến thủ tục) khơng kiểm tra thân thủ tục; cịn u cầu khơng nằm tiền điều kiện thủ tục cần phải kiểm tra Đối với hệ thống phần mềm, dù lớn hay nhỏ, chất lượng riêng thành phần chưa đủ Cái giá trị bảo đảm tương tác hai thành phần phải có phân cơng rõ ràng quyền lợi nghĩa vụ, tức cần phải có hợp đồng 7.3 Những xác nhận chế kiểm tra đầu vào Để tránh hiểu lầm, lưu ý hợp đồng ta bàn thủ tục (nhà cung cấp) thủ tục khác (khách hàng – thủ tục gọi đến thủ tục đó) Chúng ta quan tâm đến mối quan hệ phần mềm – phần mềm, khơng 33 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# phải phần mềm – người hay phần mềm – ngoại cảnh Vì vậy, tiền điều kiện khơng quan tâm đến sai liệu người dùng nhập vào, ví dụ xét thủ tục read_positive_integer địi hỏi người dùng nhập vào số dương, tiền điều kiện: require input > kỹ thuật đáng tin cậy Trong trường hợp có thay cho điều kiện if … then thông thường Sự xác nhận giải pháp kiểm tra đắn liệu nhập Tiêu chuẩn Modular Protection (bảo vệ tính mơđun cho phần mềm) khuyến khích cần xác nhận tính hợp lệ liệu nhập từ đối tượng hệ thống cho gần với mã nguồn tốt, sử dụng “bộ lọc” cần thiết: Hình 7-1: Sử dụng lọc module Để nhận liệu từ hệ thống (đường màu xanh nhạt), bạn dựa vào tiền điều kiện Nhưng với môđun màu vàng, liệu phải thỏa mãn 34 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# tiền điều kiện vào mơđun xử lý (màu xanh đậm) Vậy trường hợp này, ta sử dụng xác nhận cho đường màu xanh đậm, thể tương tác phần mềm – phần mềm Và hậu điều kiện mà môđun nhập nhận phải phù hợp với tiền điều kiện thủ tục xử lý Chương 8: Làm việc với xác nhận Trong phần chúng tìm hiểu chi tiết cách dùng tiền điều kiện hậu điều kiện thơng qua ví dụ Những vấn đề đơn giản phức tạp xác nhận minh họa rõ ràng qua ví dụ 8.1 Lớp stack Lớp STACK trang bị xác nhận có dạng chung STACK1 Bây giờ, ta nghĩ phiên đầy đủ với cài đặt giải thích rõ ràng Để lớp sử dụng trực tiếp được, ta phải chọn cài đặt Hãy xem cài đặt ngăn xếp cách dùng mảng Hình 8-1: Stack cài đặt mảng Mảng gọi representation, có phạm vi từ đến capacity Thuộc tính count có kiểu số nguyên (integer) cho biết số phần tử ngăn xếp 35 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# Gọi a đối tượng lớp này, phương thức a.put(x,i) gán giá trị x cho phần tử thứ i stack; để lấy giá trị phần tử thứ i, ta dùng phương thức a.item(i) a @ i Lưu ý phạm vi mảng từ đến capacity, i phải nằm capacity indexing description: “Stacks: Cấu trúc liệu với quy tắc truy xuất LIFO, có độ lớn cố định.” class STACK2 [G] creation make feature Initialization make (n: INTEGER) is Cấp phát cho Stack độ lớn n phần tử require positive_capacity: n >= capacity := n !! representation make (1, capacity) ensure capacity_set: capacity = n array_allocated: representation /= Void stack_empty: empty end feature Access capacity: INTEGER Số phần tử tối đa Stack count: INTEGER Số phần tử Stack item: G is Phần tử 36 ... lớp gọi tới hàm Thực tế phương pháp Design by Contract xa Viết đoạn chương trình vào sau 31 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# if x < then “Handle the error, somehow”... xanh nhạt), bạn dựa vào tiền điều kiện Nhưng với môđun màu vàng, liệu phải thỏa mãn 34 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# tiền điều kiện vào mơđun xử lý (màu... khơng 33 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# phải phần mềm – người hay phần mềm – ngoại cảnh Vì vậy, tiền điều kiện khơng quan tâm đến sai liệu người dùng nhập vào,

Ngày đăng: 30/07/2014, 20:20

Từ khóa liên quan

Mục lục

  • LỜI NÓI ĐẦU

  • TỔNG QUAN

  • Giới thiệu về Eiffel

    • Giới thiệu

    • Design By Contract trong Eiffel

    • EiffelStudio

      • Giao diện

      • Các thao tác căn bản trên EiffelStudio

      • Một số cơ chế mang lại tính đáng tin cậy cho phần mềm

      • Tính đúng đắn của phần mềm

      • Biểu diễn một đặc tả

        • Những công thức của tính đúng đắn

        • Những điều kiện yếu và mạnh

        • Giới thiệu về sự xác nhận trong văn bản của phần mềm

        • Tiền điều kiện và hậu điều kiện

          • Lớp ngăn xếp

          • Tiền điều kiện

          • Hậu điều kiện

          • Giao ước cho tính đáng tin cậy của phần mềm

            • Quyền lợi và nghĩa vụ

              • Những quyền lợi

              • Những nghĩa vụ

              • Nghệ thuật của sự tin cậy phần mềm: kiểm tra ít hơn, bảo đảm

              • Những xác nhận không phải là một cơ chế kiểm tra đầu vào

              • Làm việc với những xác nhận

                • Lớp stack

                • Mệnh lệnh và yêu cầu

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan