Tim hieu-cong-nghe-design-by-contract-va-xay-dung-cong-cu-ho-tro-cho-c#

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN CÔNG NGHỆ PHẦN MỀM
LÊ TRẦN HOÀNG NGUYÊN – 0112103
NGUYỄN BÁCH KHOA - 0112140
TÌM HIỂU CÔNG NGHỆ
DESIGN BY CONTRACT VÀ XÂY DỰNG
CÔNG CỤ HỖ TRỢ CHO C#
KHÓA LUẬN CỬ NHÂN TIN HỌC
GIÁO VIÊN HƯỚNG DẪN
Th.s: NGUYỄN ĐÔNG HÀ
NIÊN KHÓA 2001 – 2005

Tìm hiểu công nghệ Design By Contract và Xây dựng công cụ hỗ trợ cho C#
2
LỜI CẢM ƠN
Đầu tiên, xin chân thành cảm ơn cô Nguyễn Đông Hà đã trực tiếp hướng
dẫn cũng như cung cấp tài liệu để chúng em có thể tiếp cận và tìm hiểu về công
nghệ Design By Contract hữu ích này.
Bên cạnh đó, xin đồng gửi lời cảm ơn đến các thầy cô của bộ môn Công
nghệ Phần mềm Nâng cao đã tạo điều kiện cho chúng em dành nhiều thời gian
nghiên cứu đề tài này.
Cuối cùng, quả là một điều thiếu sót nếu không kể đến sự ủng hộ to lớn về
mặt tinh thần cũng như sự giúp đỡ tận tình của gia đình, bạn bè, đặc biệt là bạn
Nguyễn Lương Ngọc Minh và Nguyễn Ngọc Khánh.
Xin chân thành cảm ơn tất cả, những người đã góp phần giúp cho luận văn
này được hoàn thành.
Thành phố Hồ Chí Minh,
Tháng 7, 2005.

3
MỤC LỤC
LỜI NÓI ĐẦU 7
TỔNG QUAN 8
Chương 1: Giới thiệu về Eiffel 9
1.1. Giới thiệu 9
1.2. Design By Contract trong Eiffel 10
1.3. EiffelStudio 10
1.3.1. Giao diện 11
1.3.2. Các thao tác căn bản trên EiffelStudio 11
Chương 2: Một số cơ chế mang lại tính đáng tin cậy cho phần mềm 17
Chương 3: Tính đúng đắn của phần mềm 18
Chương 4: Biểu diễn một đặc tả 20
4.1. Những công thức của tính đúng đắn 20
4.2. Những điều kiện yếu và mạnh 22
Chương 5: Giới thiệu về sự xác nhận trong văn bản của phần mềm 24
Chương 6: Tiền điều kiện và hậu điều kiện 25
6.1. Lớp ngăn xếp 25
6.2. Tiền điều kiện 28
6.3. Hậu điều kiện 28
Chương 7: Giao ước cho tính đáng tin cậy của phần mềm 29
7.1. Quyền lợi và nghĩa vụ 29
7.1.1. Những quyền lợi 30
7.1.2. Những nghĩa vụ 30
7.2. Nghệ thuật của sự tin cậy phần mềm: kiểm tra ít hơn, bảo đảm nhiều
hơn 31
7.3. Những xác nhận không phải là một cơ chế kiểm tra đầu vào 33

4
Chương 8: Làm việc với những xác nhận 35
8.1. Lớp stack 35
8.2. Mệnh lệnh và yêu cầu 38
8.3. Lưu ý về những cấu trúc rỗng 41
8.4. Thiết kế tiền điều kiện: tolerant hay demanding? 42
8.5. Một môđun tolerant 43
Chương 9: Những điều kiện bất biến của lớp 47
9.1. Định nghĩa và ví dụ 48
9.2. Định dạng và các thuộc tính của điều kiện bất biến của lớp 49
9.3. Điều kiện bất biến thay đổi 51
9.4. Ai phải bảo quản điều kiện bất biến? 52
9.5. Vai trò của những điều kiện bất biến của lớp trong kỹ thuật xây dựng
phần mềm 53
9.6. Những điều kiện bất biến và hợp đồng 54
Chương 10: Khi nào một lớp là đúng? 56
10.1. Tính đúng đắn của một lớp 57
10.2. Vai trò của những thủ tục khởi tạo 60
10.3. Xem lại về mảng 60
Chương 11: Kết nối với kiểu dữ liệu trừu tượng 62
11.1. So sánh đặc tính của lớp với những hàm ADT 63
11.2. Biểu diễn những tiên đề 64
11.3. Hàm trừu tượng 65
11.4. Cài đặt những điều kiện bất biến 66
Chương 12: Một chỉ thị xác nhận 68
Chương 13: Vòng lặp có điều kiện bất biến và điều kiện biến đổi 71
13.1. Vấn đề vòng lặp 71
13.2. Những vòng lặp đúng 71
13.3. Những thành phần của một vòng lặp đúng 72
13.4. Cú pháp của vòng lặp 74

5
Chương 14: Sử dụng những xác nhận 77
14.1. Những xác nhận như một công cụ để viết phần mềm chính xác 77
14.2. Sử dụng những xác nhận cho việc viết tài liệu: thể rút gọn của một lớp
đối tượng 78
Chương 15: Giới thiệu công cụ XC# 81
15.1. Giới thiệu 81
15.2. XC# hoạt động như thế nào 82
15.3. Khai báo các xác nhận 82
15.3.1. Tiền điều kiện 82
15.3.2. Hậu điều kiện 83
15.3.3. Một số thuộc tính mà XC# qui ước sẵn 83
15.4. Ví dụ lớp Stack 86
Chương 16: Kết quả thực nghiệm: công cụ DCS 88
16.1. Nguyên lý làm việc 88
16.2. Thiết kế 94
16.2.1. Tổng thể 94
16.2.2. Chi tiết các lớp đối tượng 95
16.2.2.1 Màn hình Configuration 95
16.2.2.2 Lớp Connect 98
16.2.2.3 Lớp ProjectInfo 99
16.2.2.4 Lớp ClassInfo 101
16.2.2.5 Lớp FunctionInfo 104
16.2.2.6 Lớp Assertion 106
16.2.2.7 Lớp Extra 109
KẾT LUẬN 111
HƯỚNG PHÁT TRIỂN 112
TÀI LIỆU THAM KHẢO 113
Ý KIẾN CỦA GIÁO VIÊN PHẢN BIỆN 114

6
BẢNG CÁC HÌNH VẼ
Hình 1-1: Giao diện EiffelStudio---------------------------------------------------------- 11
Hình 1-2: Thông báo khi lỗi xảy ra ở tiền điều kiện ------------------------------------ 14
Hình 1-3: Code gây ra lỗi ở tiền điều kiện ----------------------------------------------- 14
Hình 1-4: Thông báo khi lỗi xảy ra ở hậu điều kiện ------------------------------------ 15
Hình 1-5: Code gây ra lỗi ở hậu điều kiện ----------------------------------------------- 15
Hình 1-6: Thông báo khi lỗi xảy ra ở điều kiện bất biến------------------------------- 16
Hình 1-7: Code gây ra lỗi ở điều kiện bất biến ------------------------------------------ 16
Hình 7-1: Sử dụng bộ lọc các module ---------------------------------------------------- 34
Hình 8-1: Stack được cài đặt bằng mảng------------------------------------------------- 35
Hình 9-1: Thời gian tồn tại của một đối tượng ------------------------------------------ 50
Hình 10-1: Thời gian tồn tại của một đối tượng----------------------------------------- 58
Hình 11-1: Sự biến đổi giữa những đối tượng trừu tượng và cụ thể------------------ 65
Hình 11-2: Hai cài đặt của cùng một đối tượng trừu tượng---------------------------- 67
Hình 13-1: Một vòng lặp tính toán -------------------------------------------------------- 73
Hình 16-1: Sơ đồ thiết kế tổng thể -------------------------------------------------------- 94
Hình 16-2: Màn hình Configuration ------------------------------------------------------ 95
Hình 16-3: Chi tiết màn hình Configuration --------------------------------------------- 96
Hình 16-4: Lớp Connect-------------------------------------------------------------------- 98
Hình 16-5: Lớp ProjectInfo ---------------------------------------------------------------- 99
Hình 16-6: Lớp ClassInfo -----------------------------------------------------------------101
Hình 16-7: Lớp FunctionInfo -------------------------------------------------------------104
Hình 16-8: Lớp Assertion -----------------------------------------------------------------106
Hình 16-9: Lớp Extra ----------------------------------------------------------------------109

7
LỜI NÓI ĐẦU
Trong ngành công nghệ thông tin, thay đổi là một tất yếu diễn ra hết sức
thường xuyên mà ta phải chấp nhận và cố gắng điều chỉnh nó. Phần mềm này ra đời
thay thế phần mềm khác là một điều vô cùng bình thường, dễ hiểu. Tại sao lại như
thế? Bởi vì người sử dụng luôn mong muốn có được một phần mềm hữu ích. Tuy
nhiên, dù phần mềm có thể đáp ứng những nhu cầu của người sử dụng trong thời
gian hiện tại thì cũng không thể đảm bảo nó sẽ luôn được ưa chuộng. Để có thể tồn
tại lâu dài, phần mềm phải thật sự chất lượng. Điều này đồng nghĩa với việc nó phải
không ngừng được cập nhật. Mà ta cũng biết, phần mềm càng đúng đắn, đáng tin
cậy và rõ ràng bao nhiêu thì công việc nâng cấp và phát triển nó càng dễ dàng bấy
nhiêu. Do đó, có thể nói, một trong những tiêu chí của ngành công nghệ phần mềm
mà bất kỳ thời đại nào, bất kỳ sản phẩm phần mềm nào cũng đều hướng đến là tính
đáng tin cậy và đúng đắn. Xuất phát từ nhu cầu ấy, công nghệ Design By Contract
đã ra đời nhằm giúp đảm bảo cho tính đáng tin cậy của phần mềm. Đó cũng chính là
lý do mà chúng em đã chọn đề tài này.
Với mục đích tìm hiểu công nghệ Design By Contract một cách khá kỹ
lưỡng, chúng em đã tiếp cận nó bằng các tài liệu lý thuyết cũng như qua các công cụ
có khả năng hỗ trợ Design By Contract cho các ngôn ngữ lập trình hiện đại. Không
dừng ở đó, chúng em còn xây dựng một công cụ hỗ trợ công nghệ này cho C# với
tên gọi là DCS (Design By Contract for C Sharp).
Đối tượng và phạm vi nghiên cứu: ý tưởng chính của Design By Contract là
lập một “hợp đồng” giữa một lớp đối tượng (supplier) và những khách hàng (client)
của nó, tức là những lớp đối tượng khác gọi đến các phương thức của lớp này.
Những client này phải bảo đảm một số điều kiện nhất định khi gọi một phương thức
của một supplier gọi là tiền điều kiện (precondition); đáp lại, sau khi thực thi thủ
tục, supplier phải đáp ứng một số điều kiện tương ứng gọi là hậu điều kiện
(postcondition). Những điều kiện của hợp đồng sẽ được kiểm tra bởi trình biên dịch,
và bất cứ sự vi phạm nào của phần mềm cũng sẽ được phát hiện.

8
TỔNG QUAN
Các hướng nghiên cứu đã có của một số tác giả:
- Bertrand Meyer, tác giả của công nghệ Design By Contract và ngôn
ngữ Eiffel, ngôn ngữ hỗ trợ hoàn toàn Design By Contract.
Vấn đề tồn tại: Bởi vì đây là ngôn ngữ lập trình do chính tác giả của Design
By Contract tạo ra nên hỗ trợ rất đầy đủ và rõ ràng cho công nghệ này, nhưng vấn
đề ở đây là ngôn ngữ Eiffel còn xa lạ với người lập trình dù đã ra đời gần 10 năm,
được ít người sử dụng ngôn ngữ này để phát triển phần mềm.
- ResolveCorp và eXtensible C# (XC#), một Add-In hỗ trợ Design By
Contract cho C#. Đây là một công cụ rất tốt, hỗ trợ đầy đủ Design By Contract cho
C#. Tuy nhiên, công cụ này chỉ được sử dụng miễn phí một vài DLL và source code
không mở.
- Man Machine Systems và JMSAssert, công cụ hỗ trợ Design By
Contract cho Java. Đây cũng là một công cụ tốt. Tuy nhiên, JMSAssert chỉ hỗ trợ
biên dịch command line và sử dụng cho JDK từ 1.2 trở xuống, không thể tích hợp
vào các môi trường hỗ trợ lập trình Java như JBuilder, Sun One Studio hay Eclipse.

9
Chương 1: Giới thiệu về Eiffel
1.1. Giới thiệu
Đầu tiên, chúng ta sẽ làm quen với phần mềm Eiffel trước khi tìm hiểu về
công nghệ Design By Contract. Vì sao lại như vậy? Vì tất cả ví dụ dùng trong luận
văn đều sử dụng cấu trúc của ngôn ngữ Eiffel. Còn những khái niệm nào mới được
đề cập trong chương này sẽ được giải thích kỹ hơn trong các phần sau khi giới thiệu
về Design By Contract
Qua hơn 10 năm tồn tại, Eiffel hiện nay được coi là một trong những môi
trường phát triển phần mềm tốt nhất. Trước sức mạnh to lớn của Eiffel trong lĩnh
vực phần mềm thì dù muốn dù không, bạn cũng nên biết qua về nó. Vậy thực chất
Eiffel là gì?
Eiffel là khung làm việc trợ giúp cho việc suy nghĩ, thiết kế và thực thi phần
mềm hướng đối tượng.
Eiffel là một phương pháp, một ngôn ngữ hỗ trợ mô tả một cách hiệu quả và
phát triển những hệ thống có chất lượng.
Eiffel là ngôn ngữ thiết kế
Vai trò của Eiffel còn hơn một ngôn ngữ lập trình. Những gì nó đem lại
không chỉ giới hạn trong ngữ cảnh lập trình mà trải rộng khắp công việc phát triển
phần mềm: phân tích, lên mô hình, viết đặc tả, thiết kế kiến trúc, thực hiện, bảo trì,
làm tài liệu.
Eiffel là một phương pháp.
Eiffel dẫn đường các nhà phân tích và những nhà phát triển xuyên suốt tiến
trình xây dựng một phần mềm.
Phương pháp Eiffel tập trung cả về yếu tố sản phẩm và chất lượng, với
những điểm nhấn: tính đáng tin cậy, tính tái sử dụng, tính mở rộng, tính khả dụng,
tính bền vững.

10
1.2. Design By Contract trong Eiffel
Eiffel hỗ trợ rất nhiều tính năng: tiếp cận hướng đối tượng hoàn thiện, khả
năng giao tiếp bên ngoài (có thể giao tiếp với các ngôn ngữ C, C++, Java,…), hỗ trợ
vòng đời phần mềm bao gồm việc phân tích, thiết kế, thực thi và bảo trì, hỗ trợ
Design By Contract, viết xác nhận, quản lý ngoại lệ…
Design By Contract hầu như là vấn đề luôn được nhắc đến khi đề cập về
Eiffel. Trong Eiffel, mỗi thành phần của hệ thống đều có thể được thực hiện theo
một đặc tả tiên quyết về các thuộc tính trừu tượng của nó, liên quan đến những thao
tác nội tại và những giao tác của nó với các thành phần khác.
Eiffel thực thi một cách trực tiếp ý tưởng Design By Contract, một phương
pháp làm nâng cao tính đáng tin cậy của phần mềm, cung cấp một nền tảng cho việc
đặc tả, làm tài liệu và kiểm nghiệm phần mềm, cũng như việc quản lý các ngoại lệ
và cách sử dụng kế thừa thích hợp.
1.3. EiffelStudio
EiffelStudio là trình biên dịch của Eiffel. Ngoài ra, nó còn là một IDE rất
mạnh với những tính năng độc nhất như: công cụ công nghệ đảo tích hợp, bộ máy
phân tích mã nguồn định lượng.
Tùy vào nhu cầu của mình, bạn có thể sử dụng EiffelStudio như một môi
trường lập trình hoặc chỉ như một công cụ giúp mô hình hóa, xây dựng các mô tả hệ
thống bao gồm các lớp trừu tượng mà không thực thi bằng công cụ Diagram hoặc
kết hợp cả 2 khả năng để đạt đến hiệu quả cao nhất.

11
1.3.1. Giao diện
Hình 1-1: Giao diện EiffelStudio
Giao diện làm việc của EiffelStudio có 4 khung chính: Features, Class,
Clusters, Context. Để thuận tiện cho việc lập trình, các bạn có thể đóng bớt các
khung cửa sổ đi. Tất cả các khung cửa sổ này đều có thể đóng lại ngọai trừ Class.
1.3.2. Các thao tác căn bản trên EiffelStudio
Khởi động chương trình: Programs --> EiffelStudio Version --> EiffelStudio
Chọn "Create a new project" > OK.
Class view là khung làm việc chính của bạn. Sau khi lập trình xong, bạn có
thể biên dịch và cho chạy chương trình bằng công cụ Compile (F7).
Debug chương trình: F10, F11.
Lưu project: File > Save.

12
Biểu diễn Design By Contract trong Eiffel:
Precondition:
require
boolean expressions
Postcondition:
ensure
boolean expressions
Class invariant:
invariant
boolean expressions
Chỉ thị Check:
check
assertion_clause1
assertion_clause2
…
assertion_clausen
end
Loop invariant, loop variant:
from
initialization
until
exit
invariant
inv
variant

13
var
loop
body
end
Demo: Project stack
STACK_CLASS: lớp stack chính, chứa các định nghĩa các thao tác trên
stack.
make: Hàm khởi tạo của stack.
item: hàm lấy phần tử trên cùng stack.
get(t): hàm lấy phần tử thứ t
empty: kiểm tra stack có rỗng.
full: kiểm tra stack có đầy
put(x): thêm phần tử x vào stack
remove: bỏ phần tử trên cùng stack
TEST_CLASS: lớp chính(main), lớp gọi các hàm của lớp STACK_CLASS.
Ta sẽ thử vài trường hợp cho thấy khả năng bắt lỗi của Eiffel.
Lưu ý: Sau mỗi trường hợp hãy sửa lại code như ban đầu rồi mới thử tiếp
trường hợp khác.
Mở tập tin test_class.e.
Chạy thử chương trình (F5).
Chương trình khởi tạo stack gồm 8 phần tử từ 0 đến 7 và xuất stack. Stack
được xuất ra màn hình.
TH1: Lỗi xảy ra ở tiền điều kiện
Sửa n:=8 thành n:=-8.
Tại dòng if (n >= 0) then nhấn tổ hợp phím Ctrl-K.
Tại dòng end --end if , nhấn tổ hợp phím Ctrl-K.
Recompile (Shift-F7) và cho chạy lại chương trình (F5).

14
Xuất hiện thông báo ngoại lệ sau:
Hình 1-2: Thông báo khi lỗi xảy ra ở tiền điều kiện
và con trỏ dừng lại ở câu lệnh
Hình 1-3: Code gây ra lỗi ở tiền điều kiện
Nguyên nhân:
Khi bạn gọi thủ tục a.make(n), do trước đó khởi tạo n là một số âm (=-8),
client không đảm bảo contract, nên trong thủ tục make của lớp STACK_CLASS,
thủ tục make kiểm tra không thỏa tiền điều kiện positive_capacity: n>=0, nó
dừng lại và thông báo cho người lập trình biết.
TH2: Lỗi xảy ra ở hậu điều kiện
Trong lớp TEST_CLASS, tại thủ tục make, sửa như sau:

15
Capacity := n capacity := n-1
Hình 1-4: Thông báo khi lỗi xảy ra ở hậu điều kiện
Hình 1-5: Code gây ra lỗi ở hậu điều kiện
Nguyên nhân:
Trước đó, ta gán capacity := n-1, hậu điều kiện lại yêu cầu capacity = n.
TH3: Lỗi xảy ra ở điều kiện bất biến.
Trong lớp TEST_CLASS, tại thủ tục make, thêm vào dòng sau:
count:=-1

16
Chọn menu Project > Project Setting… Bỏ dấu check ở ensure. Đánh dấu
check ở invariant. Hành động này nhằm bỏ qua chế độ kiểm lỗi ở hậu điều kiện. Ở
đây chỉ muốn minh họa cho việc phát hiện lỗi ở điều kiện bất biến.
Hình 1-6: Thông báo khi lỗi xảy ra ở điều kiện bất biến
Hình 1-7: Code gây ra lỗi ở điều kiện bất biến
Nguyên nhân:
Trước đó, ta gán count := -1, điều kiện bất biến yêu cầu count>=0.

17
Chương 2: Một số cơ chế mang lại tính đáng tin cậy
cho phần mềm
Trước hết, phải nói rằng kỹ thuật định nghĩa thuộc tính của một đối tượng
gần như là có liên quan với cấu trúc của những hệ thống phần mềm. Những kiến
trúc đơn giản, riêng biệt và có khả năng mở rộng sẽ giúp chúng ta đảm bảo tính
đáng tin cậy của phần mềm dễ dàng hơn so với những cấu trúc vặn vẹo. Đặc biệt, cố
gắng giới hạn sự liên quan giữa các môđun với nhau đến mức tối thiểu nhất sẽ là
tiêu điểm cho việc thảo luận về tính riêng biệt. Điều này giúp ngăn chặn những rủi
ro thông thường của tính đáng tin cậy, ví dụ như những biến toàn cục và việc định
nghĩa những cơ chế liên lạc bị giới hạn, client và những mối quan hệ kế thừa. Nói
đến chất lượng phần mềm thì không thể bỏ qua tính đáng tin cậy. Chúng ta cố gắng
giữ cho những cấu trúc càng đơn giản càng tốt. Tuy rằng điều này vẫn chưa đủ đảm
bảo cho tính đáng tin cậy của phần mềm, nhưng dù sao, nó cũng là một điều kiện
cần thiết.
Một điều kiện khác cũng cần thiết nữa là làm cho phần mềm của chúng ta tối
ưu và dễ đọc. Văn bản phần mềm không những được viết một lần mà nó còn phải
được đọc đi đọc lại và viết đi viết lại nhiều lần. Sự trong sáng và tính đơn giản của
các câu chú thích là những yêu cầu cơ bản để nâng cao tính đáng tin cậy của phần
mềm.
Một vũ khí khác cũng rất cần thiết là việc quản lý bộ nhớ một cách tự động,
đặc biệt là bộ thu gom rác (garbage collection). Bất kỳ hệ thống nào có khởi tạo và
thao tác với cấu trúc dữ liệu động mà lại thực hiện thu hồi bộ nhớ bằng tay (tức là
do người lập trình điều khiển) hoặc bộ nhớ không hề được thu hồi thì thật là nguy
hiểm. Bộ thu gom rác không hề là một sự xa xỉ mà nó là thành phần thiết yếu để mở
rộng tính đáng tin cậy cho bất kỳ một môi trường hướng đối tượng nào.
Một kỹ thuật khác nữa mà cũng có thể là thiết yếu mà có liên quan đến
genericity là static typing. Nếu không có những luật như thế thì chúng ta sẽ không
kiểm soát được những lỗi xảy ra lúc run-time do quá trình gõ code gây nên.

18
Tóm lại, tất cả những kỹ thuật này cung cấp một nền tảng cần thiết để ta có
cái nhìn gần hơn về một hệ thống phần mềm đúng đắn và bền vững.
Chương 3: Tính đúng đắn của phần mềm
Giả sử có một người đưa cho bạn một chương trình C với 300 000 dòng lệnh
và hỏi rằng nó có đúng không. Tôi nghĩ rằng rất có khả năng bạn thấy khó và thậm
chí là không thể trả lời được. Tuy nhiên, nếu là một cố vấn viên, bạn hãy trả lời
“Không” và sau đó tính một giá thật cao vì rất có thể bạn đúng.
Thật sự, để có thể trả lời câu hỏi trên một cách đúng nghĩa, bạn không những
cần phải lấy chương trình đó mà còn phải lấy cả lời diễn giải về những gì mà
chương trình đó làm được hay ta gọi chúng là những đặc tả của chương trình.
Có những chú thích giống nhau cũng chẳng sao, dĩ nhiên, khi đó ta không để
ý đến kích thước của chương trình. Ví dụ, câu lệnh x := y+1 không đúng cũng
không sai. Vì đúng hay sai chỉ có ý nghĩa khi xét trong quan hệ của nó với một lời
chú dẫn, tức là cái mà người ta mong đợi có được sau khi thực hiện câu lệnh hay ít
ra thì cũng là sự ảnh hưởng đến trạng thái của các biến trong chương trình. Do đó,
câu lệnh trên sẽ đúng với đặc tả:
“Điều này đảm bảo cho x và y có giá trị khác nhau”
nhưng nó sẽ sai với đặc tả:
“Điều này đảm bảo rằng x có giá trị âm”
(giả sử các thực thể có kiểu số nguyên. Như vậy, x có thể có kết quả không âm sau
khi gán. Điều đó tùy thuộc vào giá trị của y).
Ví dụ này nhằm minh họa cho khái niệm “tính đúng đắn” được trình bày bên
dưới:

19
Tính đúng đắn của phần mềm
Tính đúng đắn là một khái niệm quan hệ
Một hệ thống phần mềm hay một thành phần phần mềm thì không đúng cũng
không sai. Nó chỉ đúng hay sai khi có liên quan với một đặc tả nào đó. Nói một
cách chính xác, ta không thảo luận những thành phần phần mềm có đúng hay
không, mà là thảo luận chúng có phù hợp với những đặc tả của chúng hay không.
Do đó, thuật ngữ “tính đúng đắn” không được dùng cho những thành phần phần
mềm, mà nó được dùng cho từng cặp, mỗi cặp bao gồm một thành phần phần mềm
và một đặc tả.
Trong phần này, ta sẽ biết cách biểu diễn những đặc tả thông qua một xác
nhận (assertion) để giúp ta xác nhận tính đúng đắn của phần mềm. Điều này cho
thấy kết quả của việc viết những đặc tả là một bước đầu tiên quan trọng để đảm bảo
rằng phần mềm thật sự đúng. Việc viết những xác nhận cùng lúc hoặc đúng ra là
trước khi viết phần mềm sẽ mang lại những lợi ích tuyệt vời như sau:
− Sản xuất được phần mềm đúng với khi bắt đầu vì nó được thiết kế
đúng. Ích lợi này đã được Harlan D.Mills (một trong những người khởi đầu đề
xướng việc lập trình có cấu trúc “Structured Programming”) trình bày vào năm
1970 trong quyển sách “How to write correct programs and know it” (có nghĩa là
“Làm thế nào để viết được những chương trình đúng và biết được nó đúng”). “Biết”
ở đây có nghĩa là trang bị cho phần mềm những đối số khi ta viết nó nhằm hiển thị
tính đúng đắn của nó.
− Có được sự hiểu biết tốt hơn về vấn đề và những cách giải quyết cuối
cùng của nó.
− Việc thực hiện các tài liệu cho phần mềm dễ dàng. Chúng ta sẽ thấy
được ở phần sau rằng những xác nhận sẽ đóng một vai trò trung tâm trong việc
hướng đối tượng đến gần tài liệu.

20
− Cung cấp một căn bản cho việc kiểm tra và debug hệ thống.
Trong những phần còn lại chúng ta sẽ tìm hiểu những ứng dụng này.
Trong C, C++ và một số ngôn ngữ khác (dưới sự chỉ đạo của Algol W), ta có
thể viết một câu lệnh đóng vai trò một xác nhận để kiểm tra một tình trạng nào đó
có được giữ ở một trạng thái nào đó như mong muốn hay không khi thực thi phần
mềm, và chương trình sẽ không được thực thi nếu nó không thoả. Mặc dù như thế
cũng có thể làm được những gì mà ta muốn, nhưng việc làm vậy chỉ tượng trưng
cho một phần nhỏ của việc sử dụng những lời xác nhận trong phương pháp hướng
đối tượng. Do đó, nếu giống như nhiều người phát triển phần mềm khác thì bạn sẽ
quen với những câu lệnh như thế nhưng lại không thấy được bức tranh toàn cảnh.
Hầu hết tất cả những khái niệm được bàn ở đây đều sẽ mới lạ với bạn.
Chương 4: Biểu diễn một đặc tả
Chúng ta có thể trở lại nhận xét trước với hình ảnh một ký hiệu toán học đơn
giản được mượn từ lý thuyết của việc kiểm tra một chương trình hình thức và những
lý do quý giá để lập luận về tính đúng đắn của các thành phần phần mềm.
4.1. Những công thức của tính đúng đắn
Giả sử A thực hiện một vài thao tác (ví dụ A là một câu lệnh hay thân của
một thủ tục). Một công thức của tính đúng đắn là một cách biểu diễn theo dạng sau:
{P} A {Q}
Ý nghĩa của công thức tính đúng đắn {P} A {Q}
Bất kỳ thi hành nào của A, bắt đầu ở trạng thái P thì sẽ kết thúc với trạng thái Q
Những công thức của tính đúng đắn (còn được gọi là bộ ba Hoare) là một ký
hiệu toán học, không phải là một khái niệm lập trình; chúng không phải là một trong

21
số những ngôn ngữ phần mềm mà chỉ được thiết kế nhằm giúp cho việc thể hiện
những thuộc tính của các thành phần phần mềm. Trong {P} A {Q}, A biểu thị cho
một thao tác, P và Q là những thuộc tính của những thực thể khác nhau có liên quan
hay còn được gọi là những xác nhận (chúng ta sẽ định nghĩa từ “xác nhận”
(“assertion”) một cách chính xác hơn ở phần sau). Trong hai xác nhận này, P được
gọi là tiền điều kiện (precondition) và Q được gọi là hậu điều kiện (postcondition).
Ví dụ, ta có một công thức bình thường của tính đúng đắn như sau với giả sử
rằng x là một số nguyên:
{x>=9} x := x+5 {x>=13}
Công thức tính đúng đắn được sử dụng để đánh giá tính đúng đắn của phần
mềm. Điều đó cũng có nghĩa là tính đúng đắn chỉ được xét đến khi nó gắn với một
đặc tả nào đó. Như vậy, khi thảo luận về tính đúng đắn của phần mềm, ta không nói
đến những thành phần phần mềm riêng lẻ A, mà nó là bộ ba bao gồm một thành
phần phần mềm A, một tiền điều kiện P và một hậu điều kiện Q. Mục đích duy nhất
của việc này là thiết lập kết quả cho những công thức tính đúng đắn {P} A {Q}.
Trong ví dụ trên, con số 13 ở hậu điều kiện không phải là lỗi do in ấn hay gõ
phím! Giả sử thực hiện đúng phép tính trên số nguyên ở công thức trên: với điều
kiện x>=9 là đúng trước câu lệnh, x>=13 sẽ đúng sau khi thực hiện câu lệnh.
Tuy nhiên, ta thấy được nhiều điều thú vị hơn:
− Với một tiền điều kiện như vậy, hậu điều kiện hay nhất phải là điều
kiện mạnh nhất, và trong trường hợp này là x>=14.
− Còn với hậu điều kiện đã đưa ra thì tiền điều kiện hay nhất phải là tiền
điều kiện yếu nhất, ở đây là x>=8.
Từ một công thức đã cho, ta luôn có thể có được một công thức khác bằng
cách mở rộng tiền điều kiện hay nới lỏng đi hậu điều kiện. Bây giờ, ta sẽ cùng nhau
xem xét nhiều hơn về những khái niệm “mạnh hơn” và “yếu hơn” là thế nào.

22
4.2. Những điều kiện yếu và mạnh
Một cách để xem xét đặc tả theo dạng {P} A {Q} là xem nó như một mô tả
các công việc cho A. Điều này cũng giống như có một mục quảng cáo tuyển người
trên báo đăng rằng “Cần tuyển một người có khả năng thực hiện công việc A khi A
có trạng thái bắt đầu là P, và sau khi A được hoàn tất thì nó phải thỏa mãn Q”.
Giả sử, một người bạn của bạn đang kiếm việc và tình cờ đọc được những
quảng cáo tương tự như thế này, tất cả lương và lợi ích của chúng đều như nhau, chỉ
có điều là chúng khác nhau ở những cái P và Q. Cũng giống như nhiều người, bạn
của bạn thì lười nhác, có thể nói rằng, anh ta muốn có một công việc dễ nhất. Và
anh ta hỏi ý kiến bạn là nên chọn công việc nào. Trong trường hợp này, bạn sẽ
khuyên anh ấy thế nào?
Trước hết, với P: bạn khuyên anh ta nên chọn một công việc với tiền điều
kiện yếu hay mạnh? Câu hỏi tương tự cho hậu điều kiện Q. Bạn hãy suy nghĩ và
chọn cho mình một quyết định trước khi xem câu trả lời ở phần dưới.
Trước hết, ta nói về tiền điều kiện. Từ quan điểm của người làm công tương
lai, tức là người sẽ thực hiện công việc A, tiền điều kiện P định nghĩa những trường
hợp mà ta sẽ phải thực hiện công việc. Do đó, một P mạnh là tốt, vì P càng mạnh thì
các trường hợp bạn phải thực hiện A càng được giới hạn. Như vậy, P càng mạnh thì
càng dễ cho người làm công. Và tuyệt vời nhất là khi kẻ làm công chẳng phải làm gì
cả tức là hắn ta là kẻ ăn không ngồi rồi. Điều này xảy ra khi công việc A được định
nghĩa bởi:
Công thức 1
{False} A {…}
Trong trường hợp này, hậu điều kiện không cần thiết phải đề cập bởi dù nó
có là gì thì cũng không có ảnh hưởng. Nếu có bao giờ bạn thấy một mục tuyển
người như vậy thì đừng mất công đọc hậu điều kiện mà hãy chớp lấy công việc đó

23
ngay lập tức. Tiền điều kiện False là sự xác nhận mạnh nhất có thể vì nó không bao
giờ thỏa mãn một trạng thái nào cả. Bất cứ yêu cầu nào để thực thi A cũng sẽ không
đúng, và lỗi không nằm ở trách nhiệm của A mà là ở người yêu cầu hay khách hàng
(client) bởi nó đã không xem xét bất cứ tiền điều kiện nào cần đến. Dù cho A có
làm hay không làm gì đi nữa thì nó cũng luôn đúng với đặc tả.
Còn với hậu điều kiện Q, tình trạng bị đảo ngược. Một hậu điều kiện mạnh là
một tin xấu: nó chỉ ra rằng bạn phải mang lại nhiều kết quả hơn. Q càng yếu, càng
tốt cho người làm thuê. Thực tế, công việc ăn không ngồi rồi tốt nhì trên thế giới là
công việc được định nghĩa mà không chú ý đến tiền điều kiện:
Công thức 2
{…} A {True}
Hậu điều kiện True là một xác nhận yếu nhất vì nó thỏa mãn mọi trường hợp.
Khái niệm “mạnh hơn” hay “yếu hơn” được định nghĩa một cách hình thức từ logic:
P1 được gọi là mạnh hơn P2, và P2 yếu hơn P1 nếu P1 bao hàm P2 và chúng không
bằng nhau. Khi mọi lời xác nhận bao hàm True, và False bao hàm mọi xác nhận thì
thật là hợp lý để nói rằng True như là yếu nhất và False như là mạnh nhất với tất cả
xác nhận có thể.
Đến đây, có một câu hỏi được đặt ra: “Tại sao công thức 2 là công việc tốt
nhì trên thế giới?” Câu trả lời chính là một điểm tinh tế trong phần định nghĩa ý
nghĩa của công thức {P}A{Q}: sự kết thúc. Định nghĩa nói rằng sự thực thi phải kết
thúc trong tình trạng thoả Q miễn là khi bắt đầu nó thoả P.
Với công thức 1, không có trường hợp nào thoả P. Do đó, A là gì cũng
không thành vấn đề, ngay cả nó là một đoạn code mà khi thi hành, chương trình sẽ
bị rơi vào một vòng lặp không điểm dừng hay là sẽ gây hỏng máy cũng chẳng sao.
Vì dù A là gì thì cũng đúng với đặc tả của nó. Tuy nhiên, với công thức 2, vấn đề là
ở trạng thái kết thúc, nó không cần thoả mãn bất kỳ thuộc tính đặc biệt nào nhưng
trạng thái kết thúc phải được đảm bảo là có tồn tại.

24
Những đọc giả mà đã quen với lý thuyết khoa học máy tính hay những kỹ
thuật chứng minh lập trình sẽ thấy rằng công thức {P} A {Q} dùng ở đây ám chỉ
toàn bộ tính đúng đắn, bao gồm cả sự kết thúc cũng như việc phù hợp với đặc tả.
(Tính chất mà một chương trình sẽ thoả mãn với đặc tả của nó lúc kết thúc là một
phần của tính đúng đắn).
Nãy giờ, ta thảo luận một xác nhận mạnh hơn hay yếu hơn là những “tin tốt”
hay “tin xấu” là dựa trên quan điểm của một người làm công trong tương lai. Nếu
bây giờ thay đổi cách nhìn, đứng trên cương vị của một người chủ, ta thấy mọi thứ
sẽ thay đổi: một tiền điều kiện yếu sẽ là những tin tốt nếu ta muốn các trường hợp
thực thi công việc được tăng lên, và một hậu điều kiện mạnh sẽ là tốt nếu ta muốn
những kết quả của công việc thật sự có ý nghĩa.
Sự đảo ngược của những tiêu chuẩn này là đặc trưng của việc thảo luận về
tính đúng đắn của phần mềm, và sẽ xuất hiện lại như khái niệm chính trong luận
văn này: hợp đồng giữa những khách hàng và những môđun cung cấp là một sự
ràng buộc giữa hai bên. Để sản xuất ra một phần mềm hiệu quả và đáng tin cậy thì
cần phải có một hợp đồng đại diện cho sự thoả hiệp tốt nhất của tất cả mối liên hệ
giữa những nhà cung cấp và khách hàng.
Chương 5: Giới thiệu về sự xác nhận trong văn bản
của phần mềm
Để biểu diễn một đặc tả, chúng ta sẽ tin cậy vào những xác nhận. Một xác
nhận là một biểu thức bao gồm những thực thể của phần mềm và phát biểu một
thuộc tính rằng các thực thể này có thể thoả mãn ở những giai đoạn xác định khi
thực thi phần mềm. Một xác nhận tiêu biểu có thể biểu diễn một số nguyên có giá trị
dương hoặc một tham chiếu không phải rỗng.
Về mặt cú pháp, khái niệm xác nhận đơn giản là một biểu thức logic. Ví dụ
như:

25
n>0; x/=Void
Lưu ý cách dùng dấu chấm phẩy (“;”). Ý nghĩa của dấu chấm phẩy ở đây
tương đương với phép and. Dấu chấm phẩy có thể đặt giữa phần khai báo và chỉ thị.
Khi những mệnh đề của xác nhận nằm trên những dòng khác nhau, ta không cần
dùng dấu chấm phẩy (xem như có một phép and mặc định giữa các dòng liên tiếp).
Những quy ước này giúp ta có thể nhận biết các thành phần riêng biệt của một xác
nhận. Trong thực tế, ta thường dán nhãn (label) cho những thành phần này, ví dụ
như:
Positive: n>0
Not_void: x/=Void
Các nhãn như trên có vai trò nhất định trong lúc thực thi xác nhận. Tuy
nhiên, việc sử dụng chúng ở đây là nhằm làm cho văn bản của ta rõ ràng và tường
minh hơn.
Chương 6: Tiền điều kiện và hậu điều kiện
Ứng dụng đầu tiên của xác nhận là đặc tả ngữ nghĩa của thủ tục. Một thủ tục
không chỉ là một đoạn mã chương trình mà nó là cài đặt của một hàm nào đó từ đặc
tả của một kiểu dữ liệu trừu tượng, nó sẽ thực hiện một công việc hữu ích. Việc biểu
diễn công việc này một cách chính xác là vô cùng cần thiết.
Ta có thể đặc tả công việc cần thực thi của một thủ tục bằng 2 xác nhận liên
quan với nó là tiền điều kiện (preconditions) và hậu điều kiện (postconditions). Tiền
điều kiện chỉ ra những thuộc tính cần được thoả mãn bất cứ khi nào thủ tục được
gọi; còn hậu điều kiện chỉ ra những thuộc tính chắc chắn có sau khi thủ tục thực thi
xong.
6.1. Lớp ngăn xếp
Một ví dụ sẽ giúp ta làm quen với cách sử dụng các xác nhận:

26
class STACK [G] feature
…Declaration of the features:
count, empty, full, put, remove, item
end
Trước khi xem phần cài đặt, cần chú ý rằng những thủ tục được đặc trưng
bởi những thuộc tính ngữ nghĩa mạnh mẽ và độc lập với cách biểu diễn nó. Ví dụ
như:
− remove và item chỉ thực thi được khi có số phần tử lớn hơn 0.
− put tăng số phần tử lên 1, remove giảm số phần tử đi 1.
Những thuộc tính như thế là một phần trong đặc tả của kiểu dữ liệu trừu
tượng, ngay cả những người chưa bao giờ sử dụng đến kiểu dữ liệu trừu tượng cũng
phải hiểu như vậy. Nhưng trong các cách tiếp cận thông thường của việc xây dựng
phần mềm, những văn bản phần mềm thường không đề cập đến chúng. Thông qua
những tiền điều kiện và hậu điều kiện của thủ tục, ta có thể đưa chúng vào những
thành phần tường minh của phần mềm.
Ta sẽ biểu diễn những tiền điều kiện và hậu điều kiện như là mệnh đề được
giới thiệu qua hai từ khóa require và ensure. Lưu ý rằng những phần cài đặt của
những thủ tục được chừa trống, ta sẽ tìm hiểu trong phần sau.
indexing
description: "Stacks: Cấu trúc dữ liệu với quy tắc
truy xuất LIFO”
class STACK1 [G] feature – Access
count: INTEGER
-- Số phần tử của Stack
item: G is
-- Phần tử trên cùng
require
not empty

27
do
…
end
feature – Status report
empty: BOOLEAN is
-- Kiểm tra Stack rỗng?
do ... end
full: BOOLEAN is
-- Kiểm tra Stack đầy?
do
…
end
feature -- Element change
put (x: G) is
-- Thêm phần tử x vào Stack.
require
not full
do
…
ensure
not empty
item = x
count = old count + 1
end
remove is
-- Xóa phần tử trên cùng của Stack.
require
not empty
do
…
ensure
not full

28
count = old count – 1
end
end
Cả 2 mệnh đề require và ensure đều là tùy chọn. Nếu có thì require phải
nằm trước mệnh đề local. Những phần tiếp theo giải thích chi tiết hơn ý nghĩa của
tiền điều kiện và hậu điều kiện.
6.2. Tiền điều kiện
Tiền điều kiện biểu diễn những ràng buộc mà một thủ tục sẽ thực hiện một
cách chính xác. Ví dụ như:
− put sẽ không được gọi nếu ngăn xếp đã đầy.
− remove và item sẽ không thực hiện trên một ngăn xếp rỗng.
Tiền điều kiện vào có hiệu lực đến tất cả những lời gọi của thủ tục, cả trong
lớp và từ những lớp liên quan. Một hệ thống chính xác sẽ không bao giờ thực thi
một 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 những thuộc tính của trạng thái kết quả có được sau
khi thực thi thủ tục. Ví dụ như:
− Sau thủ tục put, ngăn xếp sẽ không thể rỗng, phần tử trên cùng là phần
tử mới được thêm vào, và số lượng phần tử sẽ tăng lên 1.
− Sau thủ tục remove, ngăn xếp không thể đầy, số phần tử giảm đi 1.
Sự có mặt của mệnh đề hậu điều kiện trong thủ tục bảo đảm kết quả của thủ
tục sẽ thoả mãn các thuộc tính (giả sử rằng thủ tục đã thỏa mãn tiền điều kiện để
được gọi).
Một từ khóa đặc biệt, old, xuất hiện trong hậu điều kiện. put và remove dùng
từ khóa này để biểu diễn sự thay đổi của biến count. Cú pháp: old e, trong đó e là

29
một biểu thức, thường là một thuộc tính, biểu thị giá trị của e trong đầu vào của thủ
tục. Hậu điều kiện của put có mệnh đề
để thể hiện rằng put, khi được gọi bởi bất kỳ đối tượng nào, sẽ tăng giá trị biến
count của đối tượng đó lên 1.
Chương 7: Giao ước cho tính đáng tin cậy của phần
mềm
Định nghĩa tiền điều kiện và hậu điều kiện cho một thủ tục là một cách định
nghĩa một hợp đồng (contract) giữa thủ tục và những lớp gọi nó.
7.1. Quyền lợi và nghĩa vụ
Bằng cách kết hợp những mệnh đề require pre và ensure post trong thủ tục
r, lớp đối tượng “tuyên bố” với những khách hàng của nó:
Nếu các bạn hứa gọi r thỏa mãn pre, tôi hứa sẽ trả về kết quả thỏa mãn post
Trong mối liên hệ giữa người và người hoặc giữa các công ty với nhau, hợp
đồng là một văn bản làm cho những điều khoản của mối quan hệ trở nên trong sáng,
rõ ràng. Thật đáng ngạc nhiên khi trong lĩnh vực phần mềm, nơi mà sự đúng đắn, rõ
ràng có vai trò sống còn, ý tưởng hợp đồng này lại phải mất quá nhiều thời gian để
thể hiện mình. Tiền điều kiện và hậu điều kiện mô tả một hợp đồng giữa thủ tục
(đóng vai trò nhà cung cấp) và những đối tượng gọi đến nó (vai trò khách hàng).
Đặc tính quan trọng nhất của hợp đồng trong công việc của con người là sự
đòi hỏi về “nghĩa vụ” (obligation) và “quyền lợi” (right) cho cả 2 bên – thường là
nghĩa vụ của bên này sẽ trở thành quyền lợi của bên kia. Điều này cũng đúng đối
với hợp đồng giữa các lớp đối tượng:

30
− Tiền điều kiện ràng buộc khách hàng: nó định nghĩa những điều kiện
để một lời gọi đến thủ tục trở nên hợp pháp. Đây là nghĩa vụ của khách hàng và là
quyền lợi của nhà cung cấp.
− Hậu điều kiện ràng buộc lớp đối tượng: nó định nghĩa những điều
kiện cần phải được đảm bảo bởi thủ tục khi trả về. Đây là quyền lợi của khách hàng
và là nghĩa vụ của nhà cung cấp.
7.1.1. Những quyền lợi
− Đối với khách hàng, đó là sự đảm bảo những thuộc tính phải có được
sau khi gọi thủ tục.
− Đối với nhà cung cấp, đó là sự đảm bảo những tính chất phải được
thỏa mãn ở bất cứ nơi nào thủ tục được gọi.
7.1.2. Những nghĩa vụ
− Đối với khách hàng, đó là sự đáp ứng những yêu cầu được phát biểu
trong tiền điều kiện.
− Đối với nhà cung cấp, đó là những gì phải làm mà hậu điều kiện đã
định ra.
Đây là hợp đồng cho thủ tục put của ví dụ trên:
put Nghĩa vụ Quyền lợi
Khách hàng
Đáp ứng tiền điều kiện: Chỉ gọi
put(x) khi ngăn xếp chưa đầy.
Kết quả hậu điều kiện:
Thông tin ngăn xếp được cập
nhật: không rỗng, x nằm trên
cùng, count tăng 1.
Nhà cung cấp
Đáp ứng hậu điều kiện: Cập
nhật thông tin ngăn xếp: không
rỗng, x nằm trên cùng, count
tăng 1.
Kết quả tiền điều kiện:
Được bảo đảm là ngăn xếp
chưa đầy khi put được gọi.

31
7.2. Nghệ thuật của sự tin cậy phần mềm: kiểm tra ít hơn,
bảo đảm nhiều hơn
Mặc dù bạn có thể chưa để ý, một trong những nguyên tắc của hợp đồng có
xu hướng đi ngược lại những kiến thức tổng quát đã được công nhận trong ngành
công nghiệp phần mềm; gặp nhiều sự phản ứng ngay từ đầu, nhưng Design by
Contract đã là một trong số những đóng góp chính vào sự tin cậy của phần mềm và
đạt được tầm quan trọng xứng đáng.
Một quy tắc tương phản với sự quan sát đã nêu trên: tiền điều kiện là quyền
lợi của nhà cung cấp và được biểu diễn ở góc dưới bên phải trong bảng trên: nếu
phần khách hàng của hợp đồng không được thõa mãn, nói cách khác nếu lời gọi
không đáp ứng tiền điều kiện, sau đó lớp đối tượng không được bao bọc bởi hậu
điều kiện. Trong trường hợp này thủ tục có thể làm bất cứ chuyện gì: trả ra giá trị
bất kỳ, lặp vô hạn, không trả về giá trị, thậm chí làm hỏng sự thực thi bằng một cách
nào đó. Đây là trường hợp “khách hàng sai”.
Lợi ích đầu tiên của thỏa thuận này là sự đơn giản hóa đáng kể phong cách
lập trình. Tiền điều kiện được xem như những ràng buộc mà một lời gọi đến một
thủ tục phải tuân theo, còn nếu bạn là người phát triển lớp đối tượng, bạn sẽ giả sử
rằng những ràng buộc này được thỏa mãn khi viết những thủ tục; bạn sẽ không cần
phải kiểm tra những ràng buộc đó trong thủ tục. Xét hàm căn bậc 2 như sau:
sqrt (x: REAL): REAL is
-- Căn bậc 2 của x
require
x >= 0
do … end
Bạn sẽ chỉ viết thuật toán tính căn bậc 2 mà không cần quan tâm đến trường
hợp x < 0, điều này đã được kiểm tra bởi tiền điều kiện và trở thành trách nhiệm của
những khách hàng – những lớp sẽ gọi tới hàm này.
Thực tế phương pháp của Design by Contract còn đi xa hơn nữa.
Viết đoạn chương trình này vào sau do

32
if x < 0 then
“Handle the error, somehow”
else
“Proceed with normal square root computation”
end
không chỉ là không cần thiết mà là không thể chấp nhận được. Điều này có thể biểu
diễn như một nguyên tắc:
Nguyên tắc không dư thừa
Không được kiểm tra tiền điều kiện trong thân của thủ tục trong bất kỳ trường
hợp nào
Nguyên tắc này đã đi ngược với chủ trương của rất nhiều sách giáo khoa về
công nghệ phần mềm hay phương pháp lập trình, thường được biết đến như là
phương pháp lập trình phòng thủ - với ý tưởng: để thu được một phần mềm đáng tin
cậy, bạn nên thiết kế mỗi thành phần của hệ thống sao cho nó có khả năng tự bảo vệ
cao nhất. Thà dư còn hơn thiếu, một người không bao giờ là quá cẩn thận khi tiếp
xúc với người lạ. Sự kiểm tra dư thừa có thể vô ích, nhưng ít nhất là nó không gây
tác hại.
Design By Contract đi theo một hướng ngược lại: những kiểm tra dư thừa có
thể và thật sự gây ra tác hại. Điều này mới nghe có vẻ lạ, mọi người sẽ nghĩ rằng sự
kiểm tra dư thừa có thể là vô ích, nhưng không thể nào gây ra tác hại. Tuy nhiên chỉ
những người có sự hiểu biết chưa sâu về tính tin cậy của phần mềm và chỉ tập trung
vào những phần riêng biệt của phần mềm mới có suy nghĩ như vậy. Nếu hạn chế
tầm nhìn trong một phạm vi hẹp của một thành phần cụ thể, ví dụ như thủ tục sqrt ở
trên, ta sẽ thấy rằng thủ tục có vẻ chặt chẽ hơn nếu có phần kiểm tra thêm trong thân
thủ tục. Nhưng một hệ thống không chỉ giới hạn trong một thủ tục cụ thể mà nó bao
gồm nhiều thủ tục trong nhiều lớp đối tượng khác nhau. Để đạt được một hệ thống

33
đáng tin cậy, ta phải từ bỏ cái nhìn hạn chế để có một tầm nhìn vĩ mô, bao hàm trên
kiến trúc tổng thể.
Nếu ta có được cái nhìn như thế thì tính đơn giản sẽ trở thành một tiêu chuẩn
quyết định. Như ta đã nói từ đầu, sự phức tạp là kẻ thù chính của chất lượng. Khi
quan tâm đến điều này, ta sẽ thấy rằng những kiểm tra dư thừa không còn là vô hại
nữa. Thử hình dung một hệ thống thông thường, với hàng ngàn thủ tục, những kiểm
tra dư thừa này sẽ trở thành một sự phức tạp không cần thiết khổng lồ. Nếu chúng ta
bắt đầu bằng con đường này, có thể chắc chắn một điều là: không bao giờ đạt được
một hệ thống đáng tin cậy.
Với Design By Contract, bạn sẽ nhận ra những điều kiện chắc chắn và cần
thiết để thực hiện các chức năng của một liên hiệp khách hàng – nhà cung cấp (hay
gọi là một hợp đồng); và để cho rõ ràng, đối với mỗi điền kiện, cần xác định rõ
trách nhiệm là của ai: khách hàng hay nhà cung cấp. Có thể có nhiều câu trả lời,
theo một chừng mực nào đó, điều này là những phong cách thiết kế khác nhau.
Nhưng một khi bạn đã quyết định thì bạn cần phải bám vào nó. Nếu bạn có yêu cầu
về sự chính xác của tiền điều kiện, xác định rõ rằng yêu cầu là một phần trách
nhiệm của khách hàng (những lời gọi đến thủ tục) thì không được kiểm tra trong
thân của thủ tục; còn nếu yêu cầu này không nằm trong tiền điều kiện thì thủ tục cần
phải kiểm tra nó.
Đối với một hệ thống phần mềm, dù lớn hay nhỏ, chất lượng riêng của từng
thành phần là chưa đủ. Cái giá trị nhất chính là sự bảo đảm rằng mỗi tương tác giữa
hai thành phần bất kỳ đều phải có một sự phân công rõ ràng về quyền lợi và nghĩa
vụ, tức là cần phải có một bản hợp đồng.
7.3. Những xác nhận không phải là một cơ chế kiểm tra
đầu vào
Để tránh hiểu lầm, lưu ý rằng những hợp đồng ta đang bàn là giữa một thủ
tục (nhà cung cấp) và những thủ tục khác (khách hàng – những thủ tục gọi đến thủ
tục đó). Chúng ta đang quan tâm đến mối quan hệ phần mềm – phần mềm, không

34
phải là phần mềm – con người hay phần mềm – ngoại cảnh. Vì vậy, tiền điều kiện
sẽ không quan tâm đến sự đúng sai của dữ 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 một số dương, một tiền
điều kiện:
require
input > 0
không phải là một kỹ thuật đáng tin cậy. Trong trường hợp này không thể có sự
thay thế cho một điều kiện if … then thông thường.
Sự xác nhận không phải là một giải pháp kiểm tra sự đúng đắn của dữ liệu
nhập. Tiêu chuẩn của Modular Protection (bảo vệ tính môđun cho phần mềm)
khuyến khích rằng cần xác nhận tính hợp lệ của dữ liệu nhập từ các đối tượng ngoài
hệ thống sao cho càng gần với mã nguồn càng tốt, có thể sử dụng “bộ lọc” nếu cần
thiết:
Hình 7-1: Sử dụng bộ lọc các module
Để nhận dữ liệu từ ngoài hệ thống (đường màu xanh nhạt), bạn không thể
dựa vào tiền điều kiện. Nhưng với những môđun màu vàng, dữ liệu phải thỏa mãn

35
tiền điều kiện mới có thể đi vào những môđun xử lý (màu xanh đậm). Vậy trong
trường hợp này, ta chỉ có thể sử dụng xác nhận cho đường màu xanh đậm, thể hiện
sự tương tác phần mềm – phần mềm. Và hậu điều kiện mà những môđun nhập nhận
được sẽ phải phù hợp với tiền điều kiện của những thủ tục xử lý.
Chương 8: Làm việc với những xác nhận
Trong phần này chúng sẽ tìm hiểu chi tiết hơn về cách dùng tiền điều kiện và
hậu điều kiện thông qua những ví dụ cơ bản. Những vấn đề đơn giản và phức tạp
của xác nhận sẽ được minh họa rõ ràng qua những ví dụ dưới đây.
8.1. Lớp stack
Lớp STACK được trang bị xác nhận có dạng chung như STACK1. Bây giờ, ta
có thể nghĩ ra một phiên bản đầy đủ cùng với một cài đặt được giải thích rõ ràng.
Để một lớp có thể sử dụng trực tiếp được, ta phải chọn một cài đặt. Hãy xem
một cài đặt của ngăn xếp bằng cách dùng mảng.
Hình 8-1: Stack được cài đặt bằng mảng
Mảng được gọi là representation, có phạm vi từ 1 đến capacity. Thuộc tính
count có kiểu số nguyên (integer) cho biết số phần tử trong ngăn xếp.

36
Gọi a là một đối tượng của lớp này, phương thức a.put(x,i) gán giá trị x cho
phần tử thứ i của stack; để lấy giá trị tại phần tử thứ i, ta dùng phương thức a.item(i)
hoặc a @ i. Lưu ý rằng phạm vi của mảng là từ 1 đến capacity, vì vậy i phải nằm
giữa 1 và capacity.
indexing
description: “Stacks: Cấu trúc dữ liệu với quy tắc truy
xuất LIFO, và 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 >= 0
do
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 của Stack
count: INTEGER
item: G is
-- Phần tử trên cùng

37
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 < capacity in
this representation
do
count := count + 1
representation . put (count, x)
ensure
not_empty: not empty
added_to_top: item = x

38
one_more_item: count = old count + 1
in_top_array_entry: representation @ count = x
end
remove is
-- Xóa phần tử trên cùng của Stack.
require
not_empty: not empty -- i.e. count > 0
do
count := count – 1
ensure
not_full: not full
one_fewer: count = old count – 1
end
feature {NONE} -- Implementation
representation: ARRAY [G]
-- Mảng dùng để chứa các phần tử của Stack
invariant
… Sẽ tìm hiểu trong phần sau
end -- class STACK2
Phần biểu diễn về lớp ở trên cho ta thấy sự đơn giản khi làm việc với những
xác nhận. Ngoại trừ mệnh đề invariant còn thiếu sẽ được bổ sung trong phần sau,
chúng ta hãy cùng nhau xem xét tỉ mỉ những thuộc tính khác nhau của nó.
8.2. Mệnh lệnh và yêu cầu
Những xác nhận trong lớp STACK2 minh họa một khái niệm cơ bản mà ta đã
có cái nhìn lướt qua về sự chuyển tiếp từ những kiểu dữ liệu trừu tượng sang những
lớp: sự khác nhau giữa những khung nhìn “imperative” và “applicative”.
Những xác nhận trong empty và full có thể làm bạn băn khoăn. Xét thủ tục
full trong lớp trên:

39
full: BOOLEAN is
-- Stack có đầy không?
do
Result := (count = capacity)
ensure
full_definition: Result = (count = capacity)
end
Hậu điều kiện yêu cầu rằng thực thể Result có giá trị luận lý bằng với giá
trị của biểu thức count = capacity. Điều đó có nghĩa là Result có giá trị true
nếu count bằng với capacity và nó có giá trị false nếu ngược lại.
Result = (count = capacity) (1)
Bởi vì trong thân thủ tục đã gán
Result := (count = capacity) (2)
Vậy thì liệu hậu điều kiện ở đây có dư thừa không?
Có sự khác biệt rất lớn giữa (1) và (2), vì vậy không hề có sự dư thừa.
(2) là một câu lệnh, thể hiện một hành động, gán giá trị true hay false của
biểu thức count = capacity cho biến Result. Trong khi đó, (1) chỉ là một xác
nhận, không làm gì hết. Nó chỉ đặc tả thuộc tính của trạng thái cuối cùng được
mong đợi
Một câu lệnh, tức (2), thì mang tính chất ra lệnh, còn một xác nhận, tức (1),
thì chỉ mang tính chất mô tả. Câu lệnh mô tả cho câu hỏi “như thế nào”, còn xác
nhận mô tả cho câu hỏi “cái gì”. Một câu lệnh là một phần của cài đặt, còn một xác
nhận chỉ là một thành phần của đặc tả.
Câu lệnh thì mang tính mệnh lệnh, bắt buộc, còn xác nhận thì chỉ mang tính
yêu cầu. Hai thuật ngữ này nhấn mạnh sự khác nhau cơ bản giữa tin học và toán
học.
− Những thao tác của tin học có thể làm thay đổi trạng thái của máy
tính. Những chỉ thị của các ngôn ngữ lập trình thông thường là những câu lệnh tác
động trực tiếp đến máy tính.

40
− Những lý luận toán học không thể thay đổi bất cứ gì. Ví dụ như khi ta
lấy căn bậc hai của 2 thì số 2 trước khi lấy căn và sau khi lấy căn vẫn như nhau.
Tóm lại, xác nhận là mô tả một kết quả được mong đợi, còn chỉ thị (thân
vòng lặp) là ra lệnh bằng cách nào đó đạt được kết quả. Ta không được nhằm lẫn
giữa hai khái niệm này cũng như giữa hai khái niệm “:=” và “=”. Những người sử
dụng một lớp nào đó để tạo ra một môđun của riêng mình sẽ quan tâm đến các xác
nhận hơn là các chỉ thị.
Nguyên nhân của sự gần giống nhau giữa dấu gán (:=) và dấu bằng (=) là
việc gán trong nhiều trường hợp là một cách đơn giản để đạt đến sự ngang bằng.
Cài đặt Result := (count = capacity) thật sự là một ví dụ rõ ràng dễ nhầm
lẫn. Nhưng trong những ví dụ cao hơn thì sự khác nhau giữa đặc tả và cài đặt sẽ lớn
hơn, ngay cả trong một ví dụ đơn giản là hàm tính căn của số thực x có hậu điều
kiện là abs(Result^2-x)<=tolerance (với abs là trị tuyệt đối, còn
tolerance là dung sai). Các chỉ thị trong thân hàm sẽ có tầm quan trọng thấp hơn
vì chúng là những cài đặt cho thuật toán chung của việc tính căn bậc hai.
Thậm chí đối với thủ tục put trong STACK2, có cùng đặc tả nhưng có thể có
sự thực thi khác nhau, mặc dù sự khác biệt có thể là rất nhỏ. Chẳng hạn nếu thân thủ
tục như sau:
if count=capacity then Result:=True else Result:=False end
có thể được đơn giản (nhờ những quy tắc khởi tạo mặc định) thành:
if count = capacity then Result:=True end
Do đó, sự hiện diện của những thành tố giống nhau trong thủ tục và hậu điều
kiện không phải là bằng chứng của sự dư thừa. Nó là bằng chứng của tính bền vững
giữa cài đặt và đặc tả - có thể nói là của tính đúng đắn.
Qua đây, ta thấy một đặc tính của những xác nhận mà sẽ được phát triển cao
hơn: sự thích hợp của chúng đối với tác giả của các lớp client, người mà chúng ta
không nên thắc mắc khi đọc những cài đặt thủ tục, nhưng là người cần một mô tả
trừu tượng hơn về vai trò của thủ tục. Ý tưởng này đưa đến ý niệm về một dạng
thức ngắn gọn (short form) sẽ được thảo luận sau.

41
Vì nguyên nhân thực tiễn, ta sẽ cho phép các xác nhận bao hàm một vài
thành tố mệnh lệnh (các hàm).
Để tóm tắt cho chương này, ta có bảng sau được chia thành 2 cột để thấy sự
tương phản giữa 2 hạng mục của các thành tố phần mềm:
Cài đặt Đặc tả
Câu lệnh Biểu thức
Như thế nào Cái gì
Mệnh lệnh, bắt buộc Yêu cầu
Ra lệnh Mô tả
8.3. Lưu ý về những cấu trúc rỗng
Tiền điều kiện của thủ tục khởi tạo make trong lớp STACK1 yêu cầu một lời
chú giải. Nó đưa ra n>=0, theo sau là một stack rỗng. Nếu n bằng 0, make sẽ gọi
thủ tục khởi tạo mảng, cũng có tên là make, với đối số 1 và 0 cho khoảng tiệm cận
dưới và trên. Đây không phải là một lỗi, mà là xuất phát từ quy ước trong thủ tục
khởi tạo ARRAY: dùng đối số đầu tiên lớn hơn đối số thứ hai đưa ra một mảng
rỗng.
n có giá trị là 0, hoặc là đối số đầu tiên lớn hơn đối số thứ hai của mảng
không hề sai mà đơn giản là stack hay mảng này rỗng. Lỗi chỉ xảy ra khi có lời gọi
muốn truy xuất đến một phần tử trong cấu trúc, chẳng hạn một lời gọi put cho stack
hay item cho mảng, cả hai tiền điều kiện của 2 thủ tục này sẽ luôn luôn sai vì cấu
trúc rỗng (“Khách hàng luôn luôn sai.”).
Khi định nghĩa một cấu trúc dữ liệu nói chung như stack hay mảng, bạn nên
xác định trường hợp một cấu trúc rỗng là có nghĩa hay không. Trong một số trường
hợp thì không: Ví dụ: hầu hết định nghĩa của khái niệm tree bắt đầu từ sự giả định
rằng có ít nhất một node (là node gốc). Nhưng trường hợp rỗng đưa ra không phải là
không có khả năng hợp lý, cũng như mảng và stack, bạn nên lên kế hoạch thiết kế

42
cấu trúc dữ liệu của bạn, thừa nhận rằng mỗi lần khách hàng tạo ra những thể hiện
rỗng thì không chấp nhận nó. Một hệ thống ứng dụng, ví dụ cần một stack có n
phần tử, với n là tiệm cận trên của số phần tử được chứa trong stack, sẽ được tính
toán bởi ứng dụng ngay trước khi nó tạo ra stack. Trong một số lần chạy, con số có
thể có giá trị 0. Đây không phải là lỗi mà nó là một trường hợp vô cùng.
8.4. Thiết kế tiền điều kiện: tolerant hay demanding?
Ta chỉ có thể gắn những điều kiện cho một trong hai đối tác của hợp đồng:
khách hàng (client) hay nhà cung cấp (supplier).
Có 2 khả năng:
− Nếu gán trách nhiệm cho khách hàng, điều kiện sẽ là một phần của
tiền điều kiện.
− Nếu đặt ở nhà cung cấp, những điều kiện này sẽ xuất hiện trong cấu
trúc if...then của mã lệnh.
Ta gọi trường hợp thứ nhất là demanding và thứ hai là tolerant. Lớp stack ở
trên là một minh hoạ cho kiểu demanding, phiên bản tolerant không có sự hiện diện
của tiền điều kiện:
remove is
-- Xóa phần tử trên cùng của Stack
do
if empty then
print ("Error: attempt to pop an empty
stack")
else
count := count – 1
end
end
Dùng kiểu nào thì tốt hơn?
Thoáng nhìn thì tolerant có vẻ tốt hơn (cả tính đáng tin cậy và tính tái sử
dụng), nếu có nhiều khách hàng mà chỉ có một nhà cung cấp, tính tái sử dụng được

43
thể hiện rõ. Nhà cung cấp sẽ thực hiện việc kiểm tra chung chứ không cần mỗi
khách hàng phải có sự kiểm tra riêng.
Nhưng nếu chúng ta xem xét vấn đề gần hơn, lập luận trên sẽ không còn
đúng. Điều kiện ở đây mô tả những gì cần thiết để thủ tục có thể làm công việc của
nó. Trong ví dụ trên, nếu stack là rỗng, một thông báo lỗi sẽ được đưa ra, điều này
không thích hợp. Bởi vì chỉ có khách hàng – mođun dùng stack trong ứng dụng cụ
thể mới quyết định được việc xoá phần tử của một chuỗi rỗng như trên có ý nghĩa
gì.
8.5. Một môđun tolerant
Mặc dù ta đã thấy được rằng tolerant không phải là một sự tiếp cận đúng,
nhưng cũng nên nghiên cứu xem lớp đối tượng sẽ trông như thế nào nếu ta quyết
định tiếp cận theo cách này
indexing
description: " Stacks: Cấu trúc dữ liệu với quy tắc truy
xuất LIFO, và có độ lớn cố định; phiên bản tolerant, đưa
những dòng lệnh kiểm tra vào thẳng mã nguồn."
make
feature -- Initialization
make (n: INTEGER) is
-- Cấp phát cho stack độ lớn n phần tử nếu
n>0;
-- Nếu không thì gán error = Negative_size.
-- Không có tiền điều kiện!
do
if capacity >= 0 then
capacity := n
!! representation.make (capacity)

44
else
error := Negative_size
end
ensure
error_code_if_impossible:
(n<0)=(error =Negative_size)
no_error_if_possible: (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
-- là phần tử trên cùng của stack (nếu stack
không rỗng).
-- Nếu Stack rỗng thì gán error = Underflow.
do
if not empty then
check representation /= Void end
Result := representation.item
error := 0
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)

45
no_error_if_ possible: (not (old empty)) =
(error = 0)
end
feature -- Status report
empty: BOOLEAN is
do
Result := (capacity = 0) or else
representation.empty
end
error: INTEGER
-- Xác định lỗi
full: BOOLEAN is
do
Result := (capacity = 0) or else
representation.full
end
Overflow, Underflow, Negative_size: INTEGER is
unique
-- Những lỗi có thể xảy ra
feature -- Element change
put (x: G) is
-- Thêm vào phần tử x; nếu không được thì gán
giá trị cho error.

46
do
if full then
error := Overflow
else
representation.put (x); error := 0
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
end
remove is
-- Xóa phần tử trên cùng của Stack; nếu không
được thì gán giá trị cho error.
do
if empty then
error := Underflow
else
representation.remove
error := 0
end

47
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 – 1
end
feature {NONE} – Cài đặt
representation: STACK2 [G]
-- Cài đặt của stack (không được bảo vệ)
capacity: INTEGER
-- Số phần tử tối đa của stack
end -- class STACK3
Ví dụ trên đã cho ta thấy sự nặng nề của một lớp dùng cách tiếp cận tolerant.
Đây là một minh chứng cho thấy tolerant sẽ dẫn đến một phần mềm phức tạp và
không cần thiết. Ngược lại, với demanding, theo tinh thần của Design By Contract,
sẽ giúp những client trong phát hiện lỗi trong tất cả các trường hợp theo cách tốt
nhất.
Chương 9: Những điều kiện bất biến của lớp
Tiền điều kiện và hậu điều kiện mô tả những thuộc tính của những thủ tục
riêng biệt. Điều này cũng cần thiết cho việc biểu diễn những thuộc tính toàn cục của
những thể hiện (instance) của một lớp vì chúng phải được lưu giữ trong tất cả thủ
tục. Những thuộc tính như thế sẽ tạo nên điều kiện bất biến của lớp (class invariant).

48
Chúng giữ những thuộc tính ngữ nghĩa sâu hơn và mô tả những ràng buộc toàn vẹn
của một lớp.
9.1. Định nghĩa và ví dụ
Xem lại phần cài đặt ngăn xếp (stack) bằng cách sử dụng mảng mà không có
sự bảo đảm (STACK2)
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 của lớp bao gồm: representation kiểu mảng, capacity và
count kiểu số nguyên tạo nên một stack tượng trưng. Mặc dù những tiền điều kiện
và hậu điều kiện của thủ tục được đưa ra trước đây có thể biểu diễn một vài thuộc
tính ngữ nghĩa của stack nhưng chúng thất bại trong việc biểu diễn tính nhất quán
khi các thuộc tính liên kết với nhau. Ví dụ, count luôn luôn có giá trị từ 0 đến
capacity:
0 <= count; count <= capacity
(điều này cũng hàm ý rằng capacity >= 0), và capacity là kích thước của mảng:
capacity = representation.capacity
Một điều kiện bất biến của lớp (class invariant) cũng như là một xác nhận,
biểu diễn những ràng buộc nhất quán chung được dùng cho mọi thể hiện của lớp.
Nó khác với tiền điều kiện và hậu điều kiện là những cái chỉ mô tả cho những thủ
tục riêng biệt.
Sự xác nhận ở trên chỉ liên quan đến những thuộc tính. Những điều kiện bất
biến cũng có thể biểu diễn mối quan hệ ngữ nghĩa giữa những hàm với nhau hay

49
giữa những hàm với những thuộc tính. Ví dụ, điều kiện bất biến của STACK2 có
thể mô tả sự liên quan giữa thuộc tính empty và count như sau:
empty = (count = 0)
Trong ví dụ này, xác nhận về điều kiện bất biến liên quan đến một thuộc tính
và một hàm. Nó không riêng là việc lặp lại xác nhận ở hậu điều kiện của hàm
(empty). Một xác nhận sẽ trở nên hữu ích hơn nếu nó có liên quan đến nhiều thuộc
tính như ví dụ trên hoặc nhiều hơn một hàm.
Tiếp theo, ta có một ví dụ tiêu biểu khác. Liên quan đến khái niệm tài khoản
ngân hàng, ta giả sử có một lớp là BANK_ACCOUNT có các đặc tính như
deposits_list, withdrawals_list và balance. Lúc đó, điều kiện bất biến
của lớp này có thể là một mệnh đề như sau:
consistent_balance: deposits_list.total –
withdrawals_list.total = balance
Hàm total cho biết giá trị tích lũy của danh sách những hoạt động (số tiền
gửi hay số tiền rút). Ví dụ trên cho thấy tình trạng nhất quán giữa những giá trị có
thể truy cập thông qua các thuộc tính deposits_list, withdrawals_list và
balance.
9.2. Định dạng và các thuộc tính của điều kiện bất biến của
lớp
Về mặt cú pháp, một điều kiện bất biến của lớp là một xác nhận, nằm trong
phần invariant, sau phần feature và trước end.
class STACK4[G] creation
…As in STACK2 ...
feature
... As in STACK2 ...
invariant
count_non_negative: 0 <= count
count_bounded: count <= capacity

50
consistent_with_array_size:
capacity = representation.capacity
empty_if_no_elements: empty = (count = 0)
item_at_top: (count > 0)
implies (representation item (count) = item)
end
Một điều kiện bất biến của lớp C là một bộ những xác nhận mà mỗi thể hiện
của C sẽ thoả mãn tất cả những thời điểm bền vững (stable times). Những thời điểm
bền vững là những thời điểm mà tại đây, thể hiện của lớp trong tình trạng có thể
quan sát được:
+ Khi khởi tạo thể hiện, tức là sau khi thực thi !!a hoặc là !!a.make(…), a
có kiểu là lớp C.
+ Trước và sau mỗi khi yêu cầu một thủ tục r của lớp thông qua lời gọi
a.r(…).
Hình vẽ sau sẽ chỉ ra thời gian tồn tại của một đối tượng
Hình 9-1: Thời gian tồn tại của một đối tượng

51
Vào lúc bắt đầu, tức là bên trái hình Hình 8-1, đối tượng không tồn tại. Đối
tượng được sinh ra bởi câu lệnh !!a hay !!a.make(…) hoặc là do một clone.
Sau đó, client sử dụng đối tượng thông qua các tham chiếu đến a có dạng a.f(…)
với f là một tính năng của lớp sinh ra đối tượng. Và từ đó, đối tượng tồn tại ít nhất
là cho đến khi việc thi hành kết thúc.
Điều kiện bất biến là một thuộc tính đặc thù của những trạng thái được biểu
diễn bởi những ô vuông màu xám trong hình Hình 8-1 (Ví dụ: S1). Những thời
điểm bền vững (stable times) trong hình trên là những chỗ mà đối tượng có thể thấy
được từ bên ngoài, nghĩa là client có thể áp dụng một tính năng nào đó cho nó, bao
gồm:
+ Trạng thái kết quả của việc tạo một đối tượng (trong hình là S1).
+ Những trạng thái ngay trước và sau khi client thực hiện một lời gọi có dạng
a.some_routine(…).
9.3. Điều kiện bất biến thay đổi
Tuy có tên là điều kiện bất biến nhưng nó cũng không cần phải thoả mãn hết
tại mọi thời điểm mặc dù trong ví dụ STACK4, nó vẫn đúng sau khi được khởi tạo.
Trong những trường hợp tổng quát hơn, việc một thủ tục g vào lúc ban đầu vì cố
thực hiện những mục đích của mình - tức là cố đạt được hậu điều kiện – mà có thể
làm hủy đi điều kiện bất biến trong quá trình này (cũng như con người, việc cố gắng
làm một cái gì đó hữu ích có thể phá vỡ trật tự đã được thiết lập của mọi thứ);
nhưng sau đó, ở giai đoạn thực thi tiếp theo, thủ tục này không vi phạm quá nhiều
điều kiện bất biến vốn có là hoàn toàn được chấp nhận. Trong vài tình trạng tức
thời, ví dụ như trong những tình trạng được đánh dấu trên hình Hình 8-1, điều
kiện bất biến sẽ không thể giữ được. Tuy nhiên, điều này vẫn có thể chấp nhận được
miễn là thủ tục sẽ thiết lập lại điều kiện bất biến trước khi kết thúc việc thực thi của
nó.

52
9.4. Ai phải bảo quản điều kiện bất biến?
Những lời gọi đủ điều kiện, có dạng là a.f(…), thực hiện nhân danh cho
một client, là những cái duy nhất luôn phải được bắt đầu và rời khỏi trong trạng thái
thoả mãn điều kiện bất biến; không có quy định nào cho những lời gọi không đủ
điều kiện có dạng f(…) thực thi trực tiếp bởi những client nhưng chỉ phục vụ như
những công cụ hỗ trợ cho việc tiến hành những cái cần thiết của một lời gọi đủ điều
kiện. Do đó, việc bắt buộc duy trì điều kiện bất biến chỉ được áp dụng cho những
tính năng được xuất khẩu (export) ra ngoài hoặc là theo cách chung chung hoặc là
có sự lựa chọn; một tính năng bí mật mà không client nào được sử dụng là tính năng
mà không bị điều kiện bất biến nào ảnh hưởng.
Sau đây là quy định định nghĩa chính xác khi nào một xác nhận được coi là
một điều kiện bất biến đúng của một lớp:
Quy định của điều kiện bất biến
Một xác nhận I sẽ là một điều kiện bất biến đúng của một lớp C nếu và chỉ nếu
nó thoả 2 điều kiện:
+ E1: Mọi thủ tục khởi tạo của C , khi được áp dụng cho những đối số thoả
mãn tiền điều kiện của nó trong trạng thái những thuộc tính có giá trị mặc định, đều
sẽ dẫn đến trạng thái thoả mãn I.
+ E2: Mọi thủ tục được export ra khỏi lớp, khi được áp dụng cho những đối số
và một trạng thái thoả mãn cả I lẫn tiền điều kiện của thủ tục, đều sẽ dẫn đến trạng
thái thoả mãn I.
Chú ý, trong luật này:
+ Mọi lớp được coi như có một thủ tục khởi tạo, và được định nghĩa là null
nếu nó không được chỉ định tường minh.

53
+ Trạng thái của một đối tượng được định nghĩa bởi tất cả những trường của
nó (tức là những giá trị của các thuộc tính của lớp ứng với một thể hiện cụ thể).
+ Tiền điều kiện của thủ tục có thể liên quan đến trạng thái đầu tiên và những
đối số.
+ Hậu điều kiện có thể liên quan đến trạng thái cuối, trạng thái đầu (thông
qua khái niệm old) và trong trường hợp là hàm thì giá trị trả về (nếu có) được định
nghĩa trước bởi thực thể Result.
+ Điều kiện bất biến có thể chỉ liên quan đến trạng thái.
Những xác nhận có thể là những hàm nhưng những hàm như vậy là một
tham chiếu gián tiếp đến các thuộc tính tức các trạng thái.
Ta có thể dùng quy định về điều kiện bất biến như một cơ sở để trả lời câu
hỏi: “Sẽ có ý nghĩa gì nếu điều kiện bất biến gây xâm phạm trong tiến trình thực thi
của hệ thống?” Trước đây, chúng ta đã thấy rằng những dấu hiệu xâm phạm của
một tiền điều kiện là một lỗi (một “bug”) ở khách hàng, còn xâm phạm ở hậu điều
kiện là do lỗi ở người cung cấp. Thật ra, những điều kiện bất biến cũng là những
hậu điều kiện. Chính thuộc tính này giúp ta biết được những gì sẽ nhận được.
9.5. Vai trò của những điều kiện bất biến của lớp trong kỹ
thuật xây dựng phần mềm
Thuộc tính E2 chỉ ra rằng chúng ta có thể xem điều kiện bất biến là phần
được thêm vào một cách không tường minh cho cả tiền và hậu điều kiện của mỗi
thủ tục được export ra ngoài. Do đó, về nguyên tắc, khái niệm điều kiện bất biến là
không cần thiết vì không có nó ta vẫn làm việc tốt hoặc là chỉ việc mở rộng tiền và
hậu điều kiện của tất cả thủ tục trong lớp là được.
Tuy nhiên, không phải vậy. Dù việc có thêm điều kiện bất biến làm phức tạp
những văn bản thủ tục, nhưng quan trọng hơn, ý nghĩa sâu xa của điều kiện bất biến
là nó vượt khỏi những thủ tục riêng và được áp dụng cho cả một lớp. Thật sự, điều
kiện bất biến không chỉ dùng để phục vụ cho những thủ tục viết trong lớp mà còn có
thể sử dụng được khi ta có nhu cầu thêm mới sau đó. Vì vậy, điều kiện bất biến có

54
thể kiểm soát được cả những phần mở rộng của lớp. Điều này sẽ được thể hiện rõ
trong những quy định về việc kế thừa.
Trong phát triển phần mềm, sự thay đổi là một điều tất yếu mà chúng ta phải
chấp nhận, chỉ là ta phải cố gắng điều chỉnh nó. Một vài lĩnh vực của hệ thống phần
mềm như những thành phần riêng biệt, những lớp có thể thay đổi nhanh hơn những
cái khác. Đặc biệt, việc thêm vào, bớt đi hay thay đổi những đặc tính là một hiện
tượng thường xuyên và bình thường. Trong quá trình dễ thay đổi này, việc cứ bám
mãi vào những thuộc tính mặc dù nó có thể thay đổi sẽ gây khó khăn cho việc đảm
bảo toàn bộ hệ thống được duy trì vĩnh viễn. Nhưng với điều kiện bất biến, nó
không gây khó khăn cho ta khi muốn thay đổi vì chúng giữ những ràng buộc ngữ
nghĩa cơ bản được áp dụng cho một lớp.
Ví dụ STACK2 đã minh họa được những ý kiến cơ bản, nhưng để đánh giá
được toàn bộ những ích lợi của điều kiện bất biến thì ta phải theo dõi thêm những ví
dụ tiếp theo. Khái niệm về điều kiện bất biến là một trong số những khái niệm nổi
trội nhất mà ta học được từ phương pháp hướng đối tượng. Chỉ khi nào ta kế thừa
những điều kiện bất biến (của một lớp do chính mình viết) hay đọc và hiểu nó (từ
một lớp của người khác) thì ta mới có thể thực sự cảm nhận được lớp đó là gì.
9.6. Những điều kiện bất biến và hợp đồng
Những điều kiện bất biến sẽ được hiểu rõ hơn khi đưa nó vào ngữ cảnh hợp
đồng. Những hợp đồng giữa người với nhau thường liên quan đến những quy tắc
chung được áp dụng cho mọi khế ước của một mục nào đó; ví dụ như những quy
định về việc phân chia vùng của thành phố được áp dụng cho tất cả hợp đồng xây
dựng nhà. Những điều kiện bất biến cũng đóng vai trò như thế trong hợp đồng phần
mềm: điều kiện bất biến của một lớp ảnh hưởng đến tất cả hợp đồng giữa một thủ
tục của một lớp và một đối tượng sử dụng lớp đó.
Trong phần trên, ta xem những điều kiện bất biến như một cái gì đó được
thêm vào cho tiền và hậu điều kiện của mọi thủ tục được export ra ngoài. Coi body
là phần thân của thủ tục (là tập hợp những câu lệnh trong phần do), pre là tiền điều

55
kiện, post là hậu điều kiện và INV là điều kiện bất biến của lớp. Khi ấy, yêu cầu về
tính đúng đắn trong thủ tục có thể được biểu diễn thông qua những khái niệm đã
được giới thiệu trước đây là:
{INV and pre} body {INV and post}
(Câu lệnh trên có nghĩa là: bất cứ sự thi hành nào trong phần body, bắt đầu
với bất kỳ trạng thái nào của INV và pre thì sẽ kết thúc trong trạng thái thoả mãn
INV và post)
Như vậy, có một câu hỏi dành cho người cung cấp tức người đã viết phần
body: điều kiện bất biến là những tin tốt hay xấu, nó làm cho công việc dễ hơn hay
khó hơn?
Để trả lời được điều này thì bạn phải hiểu được ý nghĩa của cuộc thảo luận
đầu tiên về ý nghĩa của tiền và hậu điều kiện đối với người làm công và người làm
chủ. Thực chất, điều kiện bất biến cũng vậy. Nó có thể là tin tốt mà cũng có thể là
tin xấu. Đối với người xin việc lười biếng, họ muốn có một tiền điều kiện mạnh và
một hậu điều kiện yếu.
Ở đây, thêm INV vào làm cho tiền và hậu điều kiện mạnh hơn hoặc ít nhất
cũng là bằng với ban đầu. Cái này xuất phát từ quy tắc logic: a và b luôn luôn hàm ý
a, điều này có thể nói là nó mạnh hơn hay bằng a. Vì vậy, nếu bạn chịu trách nhiệm
thực hiện phần body, thì điều kiện bất biến sẽ:
+ Làm cho công việc của bạn dễ hơn nếu thêm vào tiền điều kiện pre vì
trạng thái đầu tiên còn phải thỏa mãn thêm INV. Như vậy, sẽ giới hạn hơn những
trường hợp có thể gặp phải.
+ Làm cho công việc của bạn khó hơn nếu thêm vào hậu điều kiện chính
thức post vì bạn phải bảo đảm trạng thái cuối còn phải thoả mãn thêm INV.
Những ý kiến này là đáng tin với cách nhìn điều kiện bất biến là một tình
trạng nhất quán chung được dùng cho lớp như một tổng thể. Do đó, nó cũng được
dùng cho tất cả các thủ tục của lớp. Khi là tác giả của một thủ tục như thế, bạn sẽ
thấy có lợi khi điều kiện này đúng vào lúc bắt đầu thủ tục, nhưng bạn phải bảo đảm

56
rằng thủ tục sẽ thoả mãn điều kiện này một lần nữa lúc kết thúc để thủ tục tiếp theo
thực thi trên cùng một đối tượng lại thấy việc này là có lợi lần nữa.
Trong lớp BANK_ACCOUNT ở trên, mệnh đề điều kiện bất biến:
deposits_list.total – withdrawals_list.total = balance
là một ví dụ tốt. Nếu bạn phải thêm một thủ tục vào lớp, mệnh đề này đảm bảo
những đặc tính deposits_list, withdrawals_list và balance có những giá
trị nhất quán. Vì vậy, bạn không cần kiểm tra thuộc tính này (và như thế, sau khi
xem, chúng ta cũng không phải kiểm tra nó). Nhưng nó cũng có nghĩa là bạn phải
viết thủ tục, để mà, với bất cứ cái gì khác nó làm, nó cũng sẽ rời khỏi đối tượng
trong trạng thái thỏa mãn thuộc tính này lần nữa . Do thế, thủ tục withdraw dùng
để ghi một thao tác rút tiền sẽ không chỉ cập nhật withdrawals_list mà nó cũng
phải cập nhật giá trị của balance nếu balance là một thuộc tính để lấy số tiền gửi
vào tài khoản và khôi phục lại điều kiện bất biến, bảo đảm bất kỳ thủ tục nào khác
được gọi sau đó của cùng một đối tượng cũng sẽ có thể thi hành dễ dàng.
Không chỉ là một thuộc tính mà balance còn có thể là một hàm mà trong
đó nó sẽ tính toán và trả về giá trị của:
deposits_list.total – withdrawals_list.total
Trong trường hợp này, thủ tục withdraw không cần làm bất cứ gì đặc biệt
để có thể duy trì điều kiện bất biến. Khả năng chuyển đổi giữa hai khả năng này mà
không làm ảnh hưởng đến khách hàng là một minh họa của nguyên tắc truy cập
đồng bộ (uniform access).
Ví dụ này chỉ ra rằng những điều kiện bất biến của lớp như một phương tiện
vận chuyển đối với phần mềm một cách lịch thiệp cũng như nếu bạn sử dụng một
loại tài nguyên chia sẻ thì bạn phải đưa nó lại cho người khác sau mỗi lần sử dụng.
Chương 10:Khi nào một lớp là đúng?
Phần này giúp chúng ta tiếp cận với những lý thuyết cơ bản. Ngay cả là đọc
lần đầu tiên thì bạn cũng có thể tiếp cận được với những ý tưởng sẽ được trình bày

57
sắp tới vì nó tập trung vào những điểm chính yếu và rất quý báu khi sử dụng
phương pháp kế thừa.
10.1. Tính đúng đắn của một lớp
Với những tiền điều kiện, hậu điều kiện và điều kiện bất biến, ta có thể định
nghĩa một cách chính xác một lớp đúng đắn là thế nào.
Thật ra, cơ sở để định nghĩa tính đúng đắn của một lớp đã được trình bày
ngay từ đầu luận văn: một lớp, giống như bất kỳ một thành phần phần mềm nào
khác, chỉ có thể được đánh giá là đúng hay không đúng khi nó gắn liền với một đặc
tả nào đó. Như vậy, những tiền điều kiện, hậu điều kiện và điều kiện bất biến chính
là những thông tin mà ta có thể thêm vào phần đặc tả của lớp. Điều này cung cấp
một cơ sở mà dựa vào đó, ta có thể đánh giá tính đúng đắn: một lớp là đúng nếu và
chỉ nếu những cài đặt của nó trong thân của thường trình phù hợp với những tiền
điều kiện, hậu điều kiện và điều kiện bất biến.
Khái niệm {P}A{Q} được giới thiệu từ đầu giúp cho việc biểu diễn điều này
được chính xác. Hãy nhớ ý nghĩa của một công thức đúng đắn là: bất cứ khi nào A
được thực thi trong trạng thái thỏa P thì sự thực thi này sẽ kết thúc trong trạng thái
thỏa Q.
Coi C là một lớp, INV là những điều kiện bất biến của lớp. Với mọi thường
trình r của lớp, gọi prer(xr) và postr(xr) là tiền điều kiện và hậu điều kiện của
nó, xr là những tham số có thể của r, mà cả tiền điều kiện và hậu điều kiện đều có
thể trỏ đến. (Nếu trong phần thường trình, cả tiền điều kiện hoặc hậu điều kiện đều
thiếu thì prer hoặc postr là True). Gọi Bodyr là thân của thường trình r.
Cuối cùng, DefaultC biểu diễn cho việc xác nhận những thuộc tính của C có
giá trị mặc định cùng với kiểu của chúng. Ví dụ, DefaultSTACK2 được nói đến
trong lớp ngăn xếp trước là một xác nhận:
representation = Void
capacity = 0
count = 0

58
Những khái niệm này cho phép ta có một định nghĩa chung về tính đúng đắn
của lớp:
Định nghĩa: tính đúng đắn của lớp
Một lớp là đúng với những xác nhận của nó nếu và chỉ nếu:
+ C1: Với bất kỳ bộ tham số hợp lệ xp nào của thủ tục khởi tạo p thì:
{DefaultC and prepp(xp)} Bodyp {postp(xp) and INV}
+ C2: Với mọi thường trình r được export ra ngoài và bất kỳ bộ tham số hợp lệ xr
nào thì:
{prepr(xr) and INV} Bodyr {postr(xr) and INV}
Quy định này thật sự là một khai báo toán học của lược đồ thông tin trước
đây biểu diễn chu kỳ sống của một đối tượng điển hình. Ta hãy cùng xem lại ví dụ
về BANK_ACCOUNT:
Hình 10-1: Thời gian tồn tại của một đối tượng

Tim hieu-cong-nghe-design-by-contract-va-xay-dung-cong-cu-ho-tro-cho-c#

Tim hieu-cong-nghe-design-by-contract-va-xay-dung-cong-cu-ho-tro-cho-c#

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Tim hieu-cong-nghe-design-by-contract-va-xay-dung-cong-cu-ho-tro-cho-c#

Similar to Tim hieu-cong-nghe-design-by-contract-va-xay-dung-cong-cu-ho-tro-cho-c# (20)

Tim hieu-cong-nghe-design-by-contract-va-xay-dung-cong-cu-ho-tro-cho-c#