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

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

12 8 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

Cấu trú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

    • Lưu ý về những cấu trúc rỗng

    • Thiết kế tiền điều kiện: tolerant hay demanding?

    • Một môđun tolerant

  • Những điều kiện bất biến của lớp

    • Định nghĩa và ví dụ

    • Định dạng và các thuộc tính của điều kiện bất biến của lớp

    • Điều kiện bất biến thay đổi

    • Ai phải bảo quản điều kiện bất biến?

    • Vai trò của những điều kiện bất biến của lớp trong kỹ thuật

    • Những điều kiện bất biến và hợp đồng

  • Khi nào một lớp là đúng?

    • Tính đúng đắn của một lớp

    • Vai trò của những thủ tục khởi tạo

    • Xem lại về mảng

  • Kết nối với kiểu dữ liệu trừu tượng

    • So sánh đặc tính của lớp với những hàm ADT

    • Biểu diễn những tiên đề

    • Hàm trừu tượng

    • Cài đặt những điều kiện bất biến

  • Một chỉ thị xác nhận

  • Vòng lặp có điều kiện bất biến và điều kiện biến đổi

    • Vấn đề vòng lặp

    • Những vòng lặp đúng

    • Những thành phần của một vòng lặp đúng

    • Cú pháp của vòng lặp

  • Sử dụng những xác nhận

    • Những xác nhận như một công cụ để viết phần mềm chính xác

    • Sử dụng những xác nhận cho việc viết tài liệu: thể rút gọn c

  • Giới thiệu công cụ XC#

    • Giới thiệu

    • XC# hoạt động như thế nào

    • Khai báo các xác nhận

      • Tiền điều kiện

      • Hậu điều kiện

      • Một số thuộc tính mà XC# qui ước sẵn

    • Ví dụ lớp Stack

  • Kết quả thực nghiệm: công cụ DCS

    • Nguyên lý làm việc

    • Thiết kế

      • Tổng thể

      • Chi tiết các lớp đối tượng

        • Màn hình Configuration

        • Lớp Connect

        • Lớp ProjectInfo

        • Lớp ClassInfo

        • Lớp FunctionInfo

        • Lớp Assertion

        • Lớp Extra

          • KẾT LUẬN

            • HƯỚNG PHÁT TRIỂN

            • TÀI LIỆU THAM KHẢO

            • Ý KIẾN CỦA GIÁO VIÊN PHẢN BIỆN

Nội dung

Tìm hiểu công nghệ Design By Contract và Xây dựng công cụ hỗ trợ cho C# require not_empty: not empty -- i.e. count 0 do Result := representation @ count end feature – Status report empty: BOOLEAN is -- Kiểm tra Stack rỗng? do Result := (count = 0) ensure empty_definition: Result = (count = 0) end full: BOOLEAN is -- Kiểm tra Stack đầy? do Result := (count = capacity) ensure full_definition: Result = (count = capacity) end feature – Element change put (x: G) is -- Thêm phần tử x vào Stack. require not_full: not full --i.e. count...

Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# require not_empty: not empty i.e count > Result := representation @ count end feature – Status report empty: BOOLEAN is Kiểm tra Stack rỗng? Result := (count = 0) ensure empty_definition: Result = (count = 0) end full: BOOLEAN is Kiểm tra Stack đầy? Result := (count = capacity) ensure full_definition: Result = (count = capacity) end feature – Element change put (x: G) is Thêm phần tử x vào Stack require not_full: not full i.e count < capacity in this representation count := count + representation put (count, x) ensure not_empty: not empty added_to_top: item = x 37 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# one_more_item: count = old count + in_top_array_entry: representation @ count = x end remove is Xóa phần tử Stack require not_empty: not empty i.e count > count := count – ensure not_full: not full one_fewer: count = old count – end feature {NONE} Implementation representation: ARRAY [G] Mảng dùng để chứa phần tử Stack invariant … Sẽ tìm hiểu phần sau end class STACK2 Phần biểu diễn lớp cho ta thấy đơn giản làm việc với xác nhận Ngoại trừ mệnh đề invariant thiếu bổ sung phần sau, xem xét tỉ mỉ thuộc tính khác 8.2 Mệnh lệnh yêu cầu Những xác nhận lớp STACK2 minh họa khái niệm mà ta có nhìn lướt qua chuyển tiếp từ kiểu liệu trừu tượng sang lớp: khác khung nhìn “imperative” “applicative” Những xác nhận empty full làm bạn băn khoăn Xét thủ tục full lớp trên: 38 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# full: BOOLEAN is Stack có đầy khơng? Result := (count = capacity) ensure full_definition: Result = (count = capacity) end Hậu điều kiện yêu cầu thực thể Result có giá trị luận lý với giá trị biểu thức count = capacity Điều có nghĩa Result có giá trị true count với capacity có giá trị false ngược lại Result = (count = capacity) (1) Bởi thân thủ tục gán Result := (count = capacity) (2) Vậy liệu hậu điều kiện có dư thừa khơng? Có khác biệt lớn (1) (2), khơng có dư thừa (2) câu lệnh, thể hành động, gán giá trị true hay false biểu thức count = capacity cho biến Result Trong đó, (1) xác nhận, khơng làm hết Nó đặc tả thuộc tính trạng thái cuối mong đợi Một câu lệnh, tức (2), mang tính chất lệnh, cịn xác nhận, tức (1), mang tính chất mơ tả Câu lệnh mơ tả cho câu hỏi “như nào”, xác nhận mơ tả cho câu hỏi “cái gì” Một câu lệnh phần cài đặt, xác nhận thành phần đặc tả Câu lệnh mang tính mệnh lệnh, bắt buộc, cịn xác nhận mang tính u cầu Hai thuật ngữ nhấn mạnh khác tin học toán học − Những thao tác tin học làm thay đổi trạng thái máy tính Những thị ngơn ngữ lập trình thơng thường câu lệnh tác động trực tiếp đến máy tính 39 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# − Những lý luận tốn học khơng thể thay đổi Ví dụ ta lấy bậc hai số trước lấy sau lấy Tóm lại, xác nhận mô tả kết mong đợi, thị (thân vòng lặp) lệnh cách đạt kết Ta khơng nhằm lẫn hai khái niệm hai khái niệm “:=” “=” Những người sử dụng lớp để tạo mơđun riêng quan tâm đến xác nhận thị Nguyên nhân gần giống dấu gán (:=) dấu (=) việc gán nhiều trường hợp cách đơn giản để đạt đến ngang Cài đặt Result := (count = capacity) thật ví dụ rõ ràng dễ nhầm lẫn Nhưng ví dụ cao khác đặc tả cài đặt lớn hơn, ví dụ đơn giản hàm tính số thực x có hậu điều kiện abs(Result^2-x)=0, theo sau stack rỗng Nếu n 0, make gọi thủ tục khởi tạo mảng, có tên make, với đối số cho khoảng tiệm cận Đây lỗi, mà xuất phát từ quy ước thủ tục khởi tạo ARRAY: dùng đối số lớn đối số thứ hai đưa mảng rỗng n có giá trị 0, đối số lớn đối số thứ hai mảng không sai mà đơn giản stack hay mảng rỗng Lỗi xảy có lời gọi muốn truy xuất đến phần tử cấu trúc, chẳng hạn lời gọi put cho stack hay item cho mảng, hai tiền điều kiện thủ tục ln ln sai cấu trúc rỗng (“Khách hàng luôn sai.”) Khi định nghĩa cấu trúc liệu nói chung stack hay mảng, bạn nên xác định trường hợp cấu trúc rỗng có nghĩa hay khơng Trong số trường hợp khơng: Ví dụ: hầu hết định nghĩa khái niệm tree giả định có node (là node gốc) Nhưng trường hợp rỗng đưa khơng phải khơng có khả hợp lý, mảng stack, bạn nên lên kế hoạch thiết kế 41 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# cấu trúc liệu bạn, thừa nhận lần khách hàng tạo thể rỗng khơng chấp nhận Một hệ thống ứng dụng, ví dụ cần stack có n phần tử, với n tiệm cận số phần tử chứa stack, tính tốn ứng dụng trước tạo stack Trong số lần chạy, số có giá trị Đây khơng phải lỗi mà trường hợp vô 8.4 Thiết kế tiền điều kiện: tolerant hay demanding? Ta gắn điều kiện cho hai đối tác hợp đồng: khách hàng (client) hay nhà cung cấp (supplier) Có khả năng: − Nếu gán trách nhiệm cho khách hàng, điều kiện phần tiền điều kiện − Nếu đặt nhà cung cấp, điều kiện xuất cấu trúc if then mã lệnh Ta gọi trường hợp thứ demanding thứ hai tolerant Lớp stack minh hoạ cho kiểu demanding, phiên tolerant khơng có diện tiền điều kiện: remove is Xóa phần tử Stack if empty then print ("Error: attempt to pop an empty stack") else count := count – end end Dùng kiểu tốt hơn? Thống nhìn tolerant tốt (cả tính đáng tin cậy tính tái sử dụng), có nhiều khách hàng mà có nhà cung cấp, tính tái sử dụng 42 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# thể rõ Nhà cung cấp thực việc kiểm tra chung khơng cần khách hàng phải có kiểm tra riêng Nhưng xem xét vấn đề gần hơn, lập luận khơng cịn Điều kiện mơ tả cần thiết để thủ tục làm cơng việc Trong ví dụ trên, stack rỗng, thông báo lỗi đưa ra, điều khơng thích hợp Bởi có khách hàng – mođun dùng stack ứng dụng cụ thể định việc xoá phần tử chuỗi rỗng có ý nghĩa 8.5 Một mơđun tolerant Mặc dù ta thấy tolerant tiếp cận đúng, nên nghiên cứu xem lớp đối tượng trông ta định tiếp cận theo cách indexing description: " Stacks: Cấu trúc liệu với quy tắc truy xuất LIFO, có độ lớn cố định; phiên tolerant, đưa dòng lệnh kiểm tra vào thẳng mã nguồn." class STACK3 [G] creation make feature Initialization make (n: INTEGER) is Cấp phát cho stack độ lớn n phần tử n>0; Nếu khơng gán error = Negative_size Khơng có tiền điều kiện! if capacity >= then capacity := n !! representation.make (capacity) 43 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# else error := Negative_size end ensure error_code_if_impossible: (n= 0) = (error = 0) capacity_set_if_no_error:(error = 0) implies (capacity = n) allocated_if_no_error: (error=0) implies (representation/= Void) end feature Access item: G is phần tử stack (nếu stack không rỗng) Nếu Stack rỗng gán error = Underflow Khơng có tiền điều kiện! if not empty then check representation /= Void end Result := representation.item error := else error := Underflow Trong trường hợp này, Result có giá trị mặc định end ensure error_code_if_impossible: (old empty) = (error = Underflow) 44 Tìm hiểu công nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# no_error_if_ possible: (not (old empty)) = (error = 0) end feature Status report empty: BOOLEAN is Số phần tử Stack Result := (capacity = 0) or else representation.empty end error: INTEGER Xác định lỗi full: BOOLEAN is Số phần tử Stack Result := (capacity = 0) or else representation.full end Overflow, Underflow, Negative_size: INTEGER is unique Những lỗi xảy feature Element change put (x: G) is Thêm vào phần tử x; khơng gán giá trị cho error Khơng có tiền điều kiện! 45 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# if full then error := Overflow else check representation /= Void end representation.put (x); error := end ensure error_code_if_impossible: (old full) = (error = Overflow) no_error_if_possible: (not old full) = (error = 0) not_empty_if_no_error: (error = 0) implies not empty added_to_top_if_no_error: (error = 0) implies item = x one_more_item_if_no_error: (error = 0) implies count = old count + end remove is Xóa phần tử Stack; khơng gán giá trị cho error Khơng có tiền điều kiện! if empty then error := Underflow else check representation /= Void end representation.remove error := end 46 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# ensure error_code_if_impossible: (old empty) = (error = Underflow) no_error_if_possible: (not old empty) = (error = 0) not_full_if_no_error: (error = 0) implies not full one_fewer_item_if_no_error: (error = 0) implies count = old count – end feature {NONE} – Cài đặt representation: STACK2 [G] Cài đặt stack (không bảo vệ) capacity: INTEGER Số phần tử tối đa stack end class STACK3 Ví dụ cho ta thấy nặng nề lớp dùng cách tiếp cận tolerant Đây minh chứng cho thấy tolerant dẫn đến phần mềm phức tạp không cần thiết Ngược lại, với demanding, theo tinh thần Design By Contract, giúp client phát lỗi tất trường hợp theo cách tốt Chương 9: Những điều kiện bất biến lớp Tiền điều kiện hậu điều kiện mơ tả thuộc tính thủ tục riêng biệt Điều cần thiết cho việc biểu diễn thuộc tính tồn cục thể (instance) lớp chúng phải lưu giữ tất thủ tục Những thuộc tính tạo nên điều kiện bất biến lớp (class invariant) 47 Tìm hiểu cơng nghệ Design By Contract Xây dựng công cụ hỗ trợ cho C# Chúng giữ thuộc tính ngữ nghĩa sâu mơ tả ràng buộc tồn vẹn lớp 9.1 Định nghĩa ví dụ Xem lại phần cài đặt ngăn xếp (stack) cách sử dụng mảng mà khơng có bảo đảm (STACK2) class STACK2 [G] creation make feature … make, empty, full, item, put, remove … capacity: INTEGER count: INTEGER feature {NONE} –- Cài đặt representation: ARRAY [G] end Những thuộc tính lớp bao gồm: representation kiểu mảng, capacity count kiểu số nguyên tạo nên stack tượng trưng Mặc dù tiền điều kiện hậu điều kiện thủ tục đưa trước biểu diễn vài thuộc tính ngữ nghĩa stack chúng thất bại việc biểu diễn tính quán thuộc tính liên kết với Ví dụ, count ln ln có giá trị từ đến capacity:

Ngày đăng: 08/05/2021, 15:56

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w