Nghiên cứu thiết kế theo hợp đồng và xây dựng công cụ hỗ trợ

Tài liệu tham khảo công nghệ thông tin Nghiên cứu thiết kế theo hợp đồng và xây dựng công cụ hỗ trợ

ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LỜI CẢM ƠN

Sinh viên thực hiện khoá luận tốt nghiệp đề tài “Nghiên cứu thiết kế theo hợpđồng và xây dựng công cụ hỗ trợ” xin được bày tỏ lòng chân thành biết ơn tới các thầycô giáo Trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội nói chung và thầy côBộ môn Công nghệ Phần mềm nói riêng Trong suốt bốn năm qua thầy cô khôngnhững tận tình truyền đạt kiến thức mà còn luôn động viên chúng tôi trong học tậpcũng như trong cuộc sống.

Đặc biệt, chúng tôi xin chân thành cảm ơn thầy giáo hướng dẫn, thầy TrươngNinh Thuận, đã tận tình chỉ bảo, tạo mọi điều kiện cơ sở vật chất cũng như tinh thầncho chúng tôi hoàn thành khóa luận và sửa chữa những sai sót trong suốt quá trìnhthực hiện đề tài.

Chúng tôi cũng xin cảm ơn tới các bạn sinh viên K51 đã cho chúng tôi những ýkiến đóng góp có giá trị khi thực hiện đề tài này.

Đề tài “Nghiên cứu thiết kế theo hợp đồng và xây dựng công cụ hỗ trợ” đượchoàn thành trong thời gian hạn hẹp nên không tránh khỏi những khiếm khuyết Chúngtôi rất mong nhận được ý kiến đóng góp từ thầy cô giáo và các bạn để có thể tiếp tụchoàn thiện hệ thống này hơn.

Hà nội ngày 24 tháng 4 năm 2010

Sinh viên

Nguyễn Thế Nam

TÓM TẮT NỘI DUNG

Khóa luận tìm hiểu về công nghệ thiết kế theo hợp đồng (Design by Contract) [3]và trình bày những khái niệm cơ bản Đây là công nghệ giúp cho chúng ta xây dựngđặc tả giữa các lớp trong một thành phần và xem xét sự kết hợp giữa chúng với nhau.Mở rộng hơn nữa là đặc tả các thành phần trong một phần mềm và các thành phần phảithỏa mãn những điều kiện nào đó mới có thể liên kết với nhau để tạo thành phần mềmcó tính tin cậy, tính đúng đắn cao.

Bên cạnh đó khóa luận còn đưa ra một số khái niệm và cơ chế cho tính đúng đắncủa phần mềm Các cấu trúc đơn giản thường có tính tin cậy hơn những phần mềm cócấu trúc phức tạp Nhưng điểm yếu của nó lại không thể phục vụ được nhu cầu ngàycàng tăng lên của người phát triển và người sử dụng Vì thế, một số cơ chế như cốgắng giữ cho cấu trúc của phần mềm càng đơn giản càng tốt Viết văn bản mô tả phầnmềm để người phát triển sau này có thể đọc lại hoặc viết lại Quản lý bộ nhớ, hay cònđược gọi là “kỹ thuật thu gom rác” cũng làm cho phần mềm tối ưu hơn bình thường.Hoặc là việc sử dụng lại những công cụ có sẵn của những phần mềm đáng tin cậytrước đó cũng là một giải pháp thường được các nhà phát triển ứng dụng Chi tiết hơnnữa là phát triển tất cả các giai đoạn: phân tích, thiết kế, lập trình, kiểm thử, bảo trìtrong một dự án phần mềm.

Tiếp theo, khóa luận còn đưa ra các mô hình dựa trên CORBA Khái niệm về kỹnghệ phần mềm hướng thành phần Một phần mềm được tạo ra là do sự ghép nối cácthành phần độc lập lại với nhau Các thành phần này sẽ không cần phải biên dịch lạihoặc không cần phải chỉnh sửa lại khi thêm mới một thành phần khác hay là chỉnh sửamột thành phần có sẵn Mô hình thành phần CORBA là mô hình chính mà chúng tôinghiên cứu và ứng dụng nó trong việc xây dựng công cụ hỗ trợ.

Ngoài ra khóa luận còn đi vào xây dựng công cụ đặc tả và kiếm chứng hỗ trợngười dùng kiểm tra sự phù hợp của các thành phần khi kết nối với nhau một cách trựcquan Công cụ có áp dụng những công nghệ mới hiện nay như mô hình Model – View– Controller (M-V-C) [6] hoặc sử dụng thư viện layer trong lập trình java game, dễdàng cho việc lập trình công cụ.

MỤC LỤC

Mở đầu 1

CHƯƠNG 1 Tính đúng đắn, tính tin cậy của phần mềm 3

1.1 Một số cơ chế mang lại tính đúng đắn 3

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

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

1.2.2 Những điều kiện yếu, mạnh 5

1.3 Giao ước cho tính tin cậy của phần mềm 7

2.3 Tiền điều kiện, hậu điều kiện và tính bất biến 11

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

2.3.2 Tính bất biến 12

2.4 Design By Contract trong Eiffel 12

2.4.1 Biểu diễn Design by Contract trong Eiffel 13

2.4.2 Ví dụ minh họa 14

CHƯƠNG 3 Mô hình thành phần CORBA 16

3.1 Khái niệm cơ bản về công nghệ phần mềm hướng thành phần 16

3.3.3 Điều kiện kết nối 30

CHƯƠNG 4 Xây dựng công cụ đặc tả và kiểm chứng thành phần 31

4.1 Mô tả công cụ 31

4.2 Ngôn ngữ phát triển công cụ 31

4.3 Phân tích công cụ đặc tả và kiểm chứng thành phần 31

4.3.1 Mô tả công cụ 31

4.3.2 Mô hình hoạt động 32

4.3.3 Thiết kế các lớp và đối tượng 32

4.3.3.1 Sơ đồ tương tác giữa các đối tượng 33

4.3.3.2 Mô tả chi tiết các lớp đối tượng 35

4.5.3 Giao diện khi làm việc với các thành phần 41

4.5.4 Giao diện làm việc với các cổng 42

4.5.5 Giao diện sau khi kiểm chứng kết nối giữa các thành phần 45

Kết luận 47

Hướng phát triển 48

Tài liệu tham khảo 49

Phụ lục 50

DANH MỤC HÌNH VẼ

Hình 1: Giao diện thành phần CORBA và các cổng 26

Hình 2: Mô hình MVC 32

Hình 3: Sơ đồ lớp thể hiện mối liên hệ giữa các đối tượng trong ứng dụng 34

Hình 4: Sơ đồ lớp thể hiện mối quan hệ kế thừa của các cổng 34

Hình 5: Lớp Component 35

Hình 6: Lớp port 35

Hình 7: Lớp canvaspanel 36

Hình 8: Lớp Contract 37

Hình 9: Kiến trúc CCM của hệ thống Stock Quoter 38

Hình 10: Giao diện thành phần CORBA và các cổng 38

Hình 11: Giao diện khởi động ứng dụng 40

Hình 12: Giao diện điền thông tin khi thêm mới 1 thành phần 41

Hình 13: Giao diện kết quả sau khi thêm một thành phần thành công 42

Hình 14: Giao diện điền thông tin khi thêm một cổng mới 43

Hình 15: Giao diện kết quả khi thêm mới cổng thành công 44

Hình 16: Giao diện khi kết nối thành công các cổng 45

Hình 17: Giao diện khi kết nối không thành công các cổng 46

DANH MỤC BẢNG BIỂU

Bảng 1: Hợp đồng giữa một hãng hàng không và khành hàng 10

Bảng 2: Hợp đồng chèn một từ vào từ điển 11

Bảng 3: Bảng ánh xạ từ IDL sang java 24

Bảng 4: Các lớp đối tượng trong ứng dụng 33

Bảng 5: Chi tiết lớp component 35

Bảng 6: Chi tiết lớp port 36

Bảng 7: Chi tiết lớp canvaspanel 36

Bảng 8: Chi tiết lớp Contract 37

DANH MỤC CÔNG THỨC

Công thức 1: Công thức tính đúng đắn 4

Công thức 2: Tiền điều kiện mạnh, hậu điều kiện không cần phải quan tâm 5

Công thức 3: Hậu điều kiện mạnh, tiền điều kiện không cần phải quan tâm 6

Công thức 4: Điều kiện bất biến trong công thức tính đúng đắn 12

BẢNG KÝ HIỆU, CHỮ VIẾT TẮT

DbC Design by Contract Thiết kế theo hợp đồng

Kiến trúc môi giới gọi các đối tượng phân tán

Mở đầu

Trong phát triển phần mềm, thay đổi yêu cầu là một tất yếu diễn ra hết sứcthường xuyên mà những nhà phát triển phải chấp nhận và cố gắng điều chỉnh nó Phầnmề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ạisao 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 hơn, tiện lợi hơn và hoạt động tốt hơn Tuy nhiên, dù phần mềm có thể đáp ứngnhữ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ảonó 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ấtlượ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à nhưchúng ta đã biết, phần mềm càng đúng đắn, đáng tin cậy và rõ ràng bao nhiêu thì côngviệ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 trongnhữ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ảnphẩ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ệ thiết kế theo hợp đồng (Design By Contract) đã ra đời nhằm

giúp cho việc đả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 tôi đã chọn đề tài này

Với mục đích tìm hiểu công nghệ thiết kế theo hợp đồng một cách khá kỹ lưỡng,chúng tôi đã 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 tôi còn xây dựng một công cụ về đặc tả và kiểm chứng cho các thành phầntrong ngôn ngữ Java.

Đối tượng và phạm vi nghiên cứu: ý tưởng chính của thiết kế theo hợp đồng làlập một “hợp đồng” giữa các đối tượng cung cấp (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ứccủ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ự viphạm nào của phần mềm cũng sẽ được phát hiện Mở rộng hơn là nghiên cứu thànhphần phần mềm Nó là một trong những nghiên cứu quan trọng trong kỹ nghệ phầnmềm hướng thành phần, thể hiện bước đầu tiên hướng tới việc tái sử dụng thành phần,đặc tả thành phần mang lại những thông tin cần thiết để người sử dụng có thể hiểuđược vì sao và như thế nào mà thành phần có thể sử dụng được hoặc tái sử dụng Từ

đó nghiên cứu mối quan hệ giữa các thành phần trong một phần mềm và điều kiện đểcác thành phần đó có thể liên kết được với nhau Song song với việc nghiên cứu côngnghệ thiết kế theo hợp đồng, chúng tôi cũng đã nghiên cứu sâu hơn về ngôn ngữ java,mô hình thiết kế Model – View – Controller (M-V-C) và xây dựng công cụ đặc tả,kiếm chứng giúp cho việc làm sáng rõ thêm công nghệ mà chúng tôi đã nghiên cứu.

CHƯƠNG 1.

Tính đúng đắn, tính tin cậy của phần mềm

1.1 Một số cơ chế mang lại tính đúng đắn

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ầnnhư 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 đơngiả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ậycủa phần mềm dễ dàng hơn so với những cấu trúc phức tạp Đặc biệt, cố gắng giới hạnsự 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ệcthả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ủatí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ênlạ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 đơngiả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ầnmềm, nhưng dù sao, nó cũng là một điều kiện cần thiết.

Một cơ chế khác nữa là làm cho phần mềm của chúng ta tối ưu và dễ đọc Vănbản mô tả phần mềm không những được viết một lần mà nó còn phải được đọc đi đọclạ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.

Thêm vào đó, một cơ chế 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à kỹ thuật thu gom rác (garbage collection) Đây là cơ chế được sửdụng phổ biến trong việc viết ứng dụng hiện nay Các ứng dụng một cách tự động cóthể thu hồi hoặc xóa đi các mảnh vụn bộ nhớ không còn được sử dụng nữa 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ồithì thật là nguy hiểm.

Ngoài ra, việc sử dụng lại những công cụ của những phần mềm đáng tin cậytrước đó cũng tăng thêm tính tin cậy cho phần mềm của chúng ta hơn là khi ta xâydựng một hệ thống mới hoàn toàn.

Tóm lại, tất cả những cơ chế này cung cấp một nền tảng cần thiết để ta có cáinhìn gần hơn về một hệ thống phần mềm đúng đắn và bền vững.

Ý 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 [7]) 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 trongsố những ngôn ngữ phần mềm mà chỉ được thiết kế nhằm giúp cho việc thể hiệnnhững thuộc tính của các thành phần phần mềm Trong công thức 1, A biểu thị chomộ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 quanhay còn được gọi là những xác nhận Trong hai xác nhận này, P được gọi là tiền điềukiện (precondition) và Q được gọi là hậu điều kiện (postcondition).

Ví dụ, chúng 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>=10} x := x+6 {x>=15}

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ữngthà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ềmA, 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ố 15 ở 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>=7 là đúng trước câu lệnh, x>=15 sẽ đúng sau khi thực hiện câu lệnh.

Tuy nhiên, chúng 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>=16.

- 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>=9.

Từ một công thức đã cho, chúng ta luôn có thể có được một công thức khác bằngcá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ờ, chúng ta sẽ cùngnhau 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.

1.2.2 Những điều kiện yếu, 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ênbá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ảngcá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ềulà 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ếnbạ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ệnyế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 chomì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ợpmà 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áctrườ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àngdễ 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ắnta 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:

{False} A {…}

Công thức 2: Tiền điều kiện mạnh, hậu điều kiện không cần phải quan tâm

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 đó 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ãnmộ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ỗikhô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àmgì đ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 tinxấ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àmthuê 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ĩamà không chú ý đến tiền điều kiện:

{…} A {True}

Công thức 3: Hậu điều kiện mạnh, tiền điều kiện không cần phải quan tâm.

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úngkhô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ậnthì 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ôngthành vấn đề, ngay cả nó là một đoạn mã mà khi thi hành, chương trình sẽ bị rơi vàomộ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ưngtrạng thái kết thúc phải được đảm bảo là có tồn tại.

Những ai đã 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ộtchươ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).

Chúng 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 thicô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ếtquả 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ữahai 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ộthợ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à cungcấp và khách hàng.

1.3 Giao ước cho tính tin cậy của phần mềm

Bằng cách kết hợp những mệnh đề tiền điều kiện pre và hậu điều kiện 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 [3]

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 đồnglà 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ệnmì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ự đòihỏ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 đồnggiữa các lớp đối tượng:

- 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àngvà 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ầnphải được đảm bảo bởi thủ tục khi trả về Đây là quyền lợi của khách hàngvà là nghĩa vụ của nhà cung cấp.

1.3.1 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ọithủ 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.

Một phần chính trong chất lượng sản phẩm là tính đúng đắn, tính tin cậy củaphần mềm: đó là khả năng của một hệ thống có thể thực hiện các công việc của mìnhtheo các đặc tả có sẵn và có thể xử lý được các tình huống bất thường Nói một cáchđơn giản, tính tin cậy tức là không có lỗi.

Có nhiều cách xây dựng nên tính tin cậy cho phần mềm Chúng ta có thể sử dụnglại các phương thức có sẵn Có nghĩa là dùng lại những thành phần của các phần mềmthông dụng mà đúng đắn, nó làm cho phần mềm mà chúng ta xây dựng đạt được tínhtin cậy hơn là xây dựng mới các phần mềm Một cách khác, việc bẫy những mâu thuẫncủa chương trình trước khi chúng trở thành lỗi cũng góp phần củng cố thêm tính đúngđắn của phần mềm Hoặc là “kỹ thuật thu gom rác” – kỹ thuật thu gọn các mảnh vụnbộ nhỡ không còn được sử dụng nữa – cũng làm cho phần mềm được tin cậy hơn.

Nhưng như thế vẫn chưa đủ, để chắc chắn rằng phần mềm hướng đối tượng sẽ thihành một cách đúng đắn, chúng ta vẫn cần một hệ thống các phương pháp để xác địnhvà triển khai các thành phần của phần mềm hướng đối tượng và các mối quan hệ củachúng trong hệ thống phần mềm Một phương pháp mới mẻ đã xuất hiện, nó được gọilà “Design by Contract”, được tạm dịch là “Thiết kế theo hợp đồng” Theo thuyếtDesign by Contract, một hệ thống phần mềm được xem như là tập hợp các thành phầncó các giao tiếp tương tác với nhau dựa trên định nghĩa chính xác của các giao ướctrong hợp đồng.

Lợi ích của “Design by Contract” bao gồm:

 Giúp cho việc hiểu biết rõ hơn về các phương pháp hướng đối tượng vàtổng quát hơn là của cấu trúc của phần mềm.

 Tiếp cận một cách có hệ thống đến việc xây dựng hệ thống hướng đốitượng có ít hoặc hoàn toàn không có lỗi.

 Xây dựng được các framework hiệu quả hơn cho việc gỡ lỗi, kiểm thử. Dễ dàng viết tài liệu cho phần mềm.

 Hiểu và kiểm soát được kỹ thuật thừa kế.

 Một kỹ thuật cho mối quan hệ với các trường hợp dị thường, dẫn đến sựan toàn và hiệu quả cho việc xây dựng các ngôn ngữ xử lý các trường hợpngoại lệ.

2.2 Khái niệm về hợp đồng

Trong công việc thường ngày, một hợp đồng được viết bởi hai bên khi một bên(bên cung cấp) trình bày các công việc với bên kia (bên khách hàng) Mỗi bên mongchờ các lợi ích từ hợp đồng và chấp nhận các giao ước có trong hợp đồng đó Thôngthường, mỗi giao ước của bên này sẽ là lợi ích cho bên kia và ngược lại Mục tiêu củabản hợp đồng là giải thích rõ ràng các lợi ích và các giao ước.

Một ví dụ đơn giản sau đây minh họa cho một hợp đồng giữa một hãng hàngkhông và khách hàng.

Bảng 1: Hợp đồng giữa một hãng hàng không và khành hàngGiao ướcLợi ích

Bên khách hàng(khách hàng)

- Phải có mặt ở sân bay ítnhất 5 phút trước khikhởi hành.

- Chỉ mang theo hành lýđã được kiểm định.- Thanh toán tiền vé máy

địa điểm mong muốn.

Bên cung cấp(Hãng hàngkhông)

khách hàng điến địađiểm cần đến

- Không cần quan tâmkhách hàng đến trễ haykhông.

- Có mang hành lý cấmhay không.

- Đã trả tiền vé chưa.

Hợp đồng đảm bảo cho cả bên khách bởi sự chỉ rõ nên thực hiện những gì và chobên cung cấp bằng cách chỉ ra bên cung cấp không phải chịu trách nhiệm về những gìbên thực hiện không thực hiện đúng những quy định trong phạm vi hợp đồng.

Cùng chung một ý tưởng áp dụng cho phần mềm Xem xét một yếu tố phần mềmE Để đạt được mục đích (thực hiện hợp đồng riêng của mình) E sử dụng một chiếnlược nhất định, bao gồm những công việc con t1, t2,…, tn Nếu một công việc con ti nàođó bất thường, nó sẽ được thực hiện bằng cách gọi một thủ tục R Nói cách khác, Ehợp đồng ra công việc con cho R Tình trạng như vậy cần phải được quản lý bằng bảngphân công nghĩa vụ và lợi ích một cách rõ ràng.

Ví dụ như ti là công việc chèn một từ vào từ điển (một bảng mà mỗi phần tử đượcxác định bởi một chuỗi ký tự sử dụng như là một khóa) Hợp đồng sẽ là:

Bảng 2: Hợp đồng chèn một từ vào từ điểnGiao ướcLợi íchBên thực hiện - Chắc chắn rằng bảng

không đầy dữ liệu vàkhóa không phải làchuỗi rỗng

bảng chứa các yếu tốxuất hiện, liên kết vớicác khóa.

Bên cung cấp - Bản ghiđưa các yếu tố vào bảng,liên kết với các khóa.

- Không cần phải làm gìnếu bảng đầy hoặc khóalà một chuỗi rỗng

Thiết kế theo hợp đồng được sử dụng ở đây để cung cấp đặc tả chính xác cho cácchức năng của các thành phần và nâng cao tính tin cậy của chúng Theo Meyer [1992],một hợp đồng là một tập hợp các xác nhận mô tả chính xác mỗi đặc điểm của thànhphần phải làm gì và không phải làm gì Xác nhận chính trong công nghệ thiết kế theohợp đồng có 3 kiểu: Tính bất biến, tiền điều kiện và hậu điều kiện.

2.3.Tiền điều kiện, hậu điều kiện và tính bất biến2.3.1 Tiền điều kiện và hậu điều kiện.

Tiền điều kiện và hậu điều kiện được sử dụng để định nghĩa ngữ nghĩa cácphương thức Chúng chỉ rõ nhiệm vụ được thi hành bởi một phương thức Việc địnhnghĩa tiền điều kiện và hậu điều kiện cho một phương thức là cách để định nghĩa mộthợp đồng, hợp đồng này ràng buộc phương thức và các lời gọi đến nó

Tiền điều kiện mô tả sự ràng buộc mà với sự ràng buộc này, phương thức sẽ thựchiện một cách đúng đắn Đó là nghĩa vụ của bên thực hiện và là quyền lợi của bêncung cấp.

Hậu điều kiện diễn tả các thuộc tính từ kết quả thực hiện một phương thức Đó lànghĩa vụ của bên cung cấp và là quyền lợi của bên thực hiện

Ví dụ một hành động xóa bản ghi từ tập hợp cần có tiền điều kiện yêu cầu bảnghi với khóa chính phải tồn tại và hậu điều kiện yêu cầu bản ghi đó không được nhiềuhơn các yếu tố trong tập hợp đó

2.3.2 Tính bất biến

Tính bất biến ràng buộc gán các kiểu cần giúp cho đúng với các trường hợp củakiểu mà hành động bắt đầu được biểu diễn trong trường hợp đó Trong trường hợp củacác phương thức thành phần, chúng ta có thể gắn tính bất biến vào giao diện để xácđịnh thuộc tính của đối tượng thành phần thực thi giao diện Ví dụ, tính bất biến có thểnói rõ được giá trị của một vài thuộc tính luôn phải lớn hơn 0.

Điều kiện bất biến của lớp mô tả các ràng buộc toàn vẹn của lớp Khái niệm nàyquan trọng cho việc quản lý cấu hình và kiếm thử hồi quy vì nó mô tả xâu hơn đặc tínhcủa một lớp Điều kiện bất biến của lớp được thêm vào với tiền điều kiện và hậu điềukiện của mỗi phương thức của lớp:

{INV & P} A {INV & Q}

Công thức 4: Điều kiện bất biến trong công thức tính đúng đắn

INV là điều kiện bất biến được thêm vào Điều này thể hiện rằng bất biến INV là

không thay đổi trước và sau khi thực hiện A.

2.4.Design By Contract trong Eiffel

Eiffel [4] 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áplà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.

2.4.1 Biểu diễn Design by Contract trong Eiffel

 Precondition: Được thể hiện bằng từ khóa require

Ví dụ:

boolean expressions

Cần phải thỏa mãn biểu thức lô-gic boolean expressions trong mệnh đề require

trước mới có thể thực hiện tiếp thủ tục r ở sau đó.

 Postcondition: Được thể hiện bằng từ khóa ensure

Ví dụ:

boolean expressions

Sau khi thực hiện thủ tục r, kết quả trả về phải thỏa mãn biểu thức lô-gic boolean

expressions trong mệnh đề ensure

 Class invariant: Được thể hiện bằng từ khóa invariant

Ví dụ:

boolean expressions

Trong suốt quá trình thực hiện thủ tục r cần phải thỏa mãn biểu thức lô-gic

boolean expressions trong mệnh đề invariant

 Chỉ thị Check: Được thể hiện bằng cặp từ khóa check…end

Ví dụ:

assertion_clause2

Mệnh đề requie giới thiệu về điều kiện input, hoặc là tiền điều kiện; mệnh đềensure giới thiệu về điều kiện output hay còn gọi là hậu điều kiện Cả hai điều kiện là

ví dụ về sự xác nhận, hoặc điều kiện logic (mệnh đề hợp đồng) liên kết với thành phần

của phần mềm Trong tiền điều kiện, biến count là số phần tử hiện thời và capacity làsố lượng lớn nhất có thể đưa vào; trong hậu điều kiện, has là hàm boolean để xem từ

đó có không, và item trả lại từ liên kết với khóa Kí hiệu old count là giá trị count cũ.

Một ví dụ khác về cơ chế gửi tin.

tried_fast := Truesend_fast (m)

if not tried_slow then

Trong ví dụ này các giá trị logic ban đầu sẽ được khởi tạo là False Nếu

send_fast không thành công, phần thân của mệnh đề do sẽ được thực hiện lại Còn nếu

việc thực thi send_slow không thành công, mệnh đề rescue sẽ được thự hiện.

CBSE cơ bản dựa vào khái niệm của thành phần Các từ ngữ khác như giao diện,hợp đồng, framework, và khuôn mẫu có liên quan chặt chẽ đến việc phát triển thànhphần phần mềm.

Một thành phần là một đơn vị có thể sử dụng lại của việc triển khai và cấu tạonên phần mềm Một điểm chung ở đây là thành phần có mối quan hệ chặt chẽ với đốitượng, vì thế, nó là một phần mở rộng của việc phát triển công nghệ hướng đối tượng.Tuy nhiên, có nhiều nhân tố như chi tiết, khái niệm về cấu tạo và triển khai, thậm chícả quá trình phát triển, cũng phải phân biệt rõ thành phần và đối tượng.

Một giao diện quy định cụ thể các điểm truy cập đến thành phần một, và do đógiúp khách hàng hiểu được chức năng và cách sử dụng của thành phần một Giao diệnrõ ràng là tách ra từ việc thực hiện các thành phần một Thực hiện đúng quy định, giaodiện một quy định cụ thể các thuộc tính chức năng của thành phần một Một mô tảhoàn toàn chức năng của thành phần là không đủ.

Một giao diện quy định cụ thể các điểm truy cập đến một thành phần, và do đógiúp khách hàng hiểu dược chức năng và cách sử dụng của thành phần đó Giao diệnđược tách hẳn ra từ việc thực hiện các thành phần Theo như định nghĩa, một giao diệnquy định cụ thể các thuộc tính, chức năng của một thành phần Do đó, một mô tả vềchức năng của một thành phần là không đủ.

Các đặc tả thành phần có thể thực hiện được thông qua một hợp đồng, trong đótập trung vào việc đặc tả các điều kiện mà thành phần tương tác với môi trường củanó Mặc dù các component có thể có các kích cỡ khác nhau và các thành phần lớnđược chú trọng hơn cả Một tập hợp các thành phần đóng một vai trò cụ thể sẽ được

chú trọng hơn là một thành phần đơn lẻ Điều này dẫn đến khái niệm framework Mộtframework mô tả một đơn vị lớn của thiết kế và xác định mối quan hệ trong mộtnhóm nhất định của các yếu tố Các yếu tố này có thể là những thành phần.

Khuôn mẫu xác định các giải pháp cho các vấn đề ở mức độ trừu tượng cao vàcác cách sử dụng lại chúng Khuôn mẫu thường bắt những đơn vị thiết kế nhỏ khiđược so sánh với framework, bởi vì framework bao gồm các khuôn mẫu thiết kế khácnhau.

3.1.2 Thành phần

Thành phần là trung tâm của CBSE và cần phải định nghĩa chính xác về thànhphần để hiểu được cơ sở của CBSE Chúng ta có thể tìm được vài định nghĩa của thànhphần trong nhiều tài liệu, phần lớn trong số chúng không có định nghĩa trực quan vềthành phần Ví dụ trong công nghệ Component Object Model (COM) của Microsoft,một thành phần được định nghĩa là: một bộ phận biên soạn nên phần mềm, cung cấpnên một dịch vụ Mọi người đều đồng ý rằngthành phần là một bộ phận của phần mềmvà nó rõ ràng là cung cấp một dịch vụ nhưng định nghĩa này còn quá rộng Ví dụ nhưbiên dịch các thư viện (các file có đuôi o và dll) cũng có thể được định nghĩa theocách này.

Một đặc điểm quan trong nhất của thành phần là sự tách biệt giao diện của nótrong sự thực thi Sự tách biệt này khác với những gì chúng ta có thể tìm thấy ở nhiềungôn ngữ lập trình khác hoặc trong ngôn ngữ lập trình hướng đối tượng mà việc địnhnghĩa lớp được tách biệtvới những lớp thực thi Trong CBSE, các thành phần được yêucầu kết hợp lại trong phần mềm Các thành phần kết hợp và triển khai phải tồn tại độclập và không cần phải biên dịch lại hoặc phải liên kết lại với phần mềm khi mà thêmmới hoặc chỉnh sửa các thành phần khác Một đặc điểm quan trọng nữa của thành phầnlà khả năng thể hiện chức năng thông qua giao diện của nó Ý nghĩa của nó là cần thiếtcho việc hoàn thiện các đặc tả của thành phần bao gồm các giao diện chức năng, đặctính phi chức năng (hiệu suất, tài nguyên,…), ca sử dụng, kiểm thử…

3.1.3 Đối tượng và thành phần

Đối tượng và thành phần thường được nghĩ đến là đồng nghĩa hoặc tương tựnhau Tác giả Szyperski và Pfister [8] đã xem thành phần như là tập hợp các đối tượng,mà các đối tượng này hợp tác chặt chẽ với nhau Ranh giới giữa một thành phần vớicác thành phần hoặc đối tượng khác được chỉ rõ và sự tương tác của thành phần đượcthực thi qua các giao diện của thành phần trong khi các tính chất bên trong các thành

phần (ví dụ như các đối tượng của nó) được ẩn đi Đối tượng trong một thành phầnđơnlẻ có thể truy cập đến việc thực thi của thành phần khác Tuy nhiên, sự truy cập đếnviệc thực thi của một đối tượng từ bên ngoài thành phần cần phải được ngăn chặn.

Thay vì chứa các lớp hoặc đối tượng, một component có thể chứa các thủ tục cổđiển, các biến global (static), và do đó không những có thể thực hiện bằng cách tiếpcận hướng đối tượng mà còn có thể tiếp cận theo hướng chức hoặc cách tiếp cận ngônngữ assembly Tương tự như quan hệ thừa kế giữa các đối tượng, một component cóthể có một mối quan hệ với các thành phần khác Một lớp cha của một lớp không cầnthiết phải ở trong component chứa lớp đó Nếu một lớp trong component có lớp chatrong một component khác, quan hệ thừa kế giữa các lớp xuất hiện tại ranh giới giữacác component.

D.Souza and Wills [8] thảo luận về sự khác biệt và giống nhau của đối tượng vàthành phần Một câu hỏi quan trọng đặt ra là có khi nào một lớp trở thành một thànhphần hay không Nếu một lớp được đóng gói cùng với các định nghĩa về giao giện rõràng mà nó yêu cầu và thực hiện, thì lớp này sẽ được gọi là một thành phần Giao diệnlập trình ứng dụng (API) là một đặc tả các thuộc tính của mô đun mà client phụ thuộcvào API của thành phần có sẵn ở dạng một hay nhiều cấu trúc giao diện (ví dụ: javainterfaces hoặc abstract virtual classes trong C++) Cũng tương tự như thế với lớp,component có thể liên kết với các lớp khác Nếu các lớp này tự chúng có đầy đủ cácđịnh nghĩa API, tập hợp kết của của các lớp được thiết kế cấu tạo thành mộtcomponent.

Có 3 sự khác biệt quan trọng nhất dưới đây giữa component và đối tượng: Component thường sử dụng việc lưu trữ liên tục trong khi đối tượng lưu trữ

ứng với với các dịch vụ khác nhau được cung cấp bởi component, sau đó componentdự kiến sẽ có nhiều giao diện.

Điều chú ý quan trọng là một giao diện không cung cấp một sự thực thi của bấtkỳ hoạt động nào của nó Thay vào đó, nó chỉ đơn thuần là tên của tập hợp các hànhđộng và cung cấp các mô vả và giao thức các hoạt động của nó Đặc điểm này làm chonó có thể thay thế một phần thực hiện mà không phải thay đổi giao diện, và cách làmnày cải thiện được hiệu năng hệ thống mà không phải xây dựng lại hệ thống; và thêmmột giao diện (và những sự thực thi) mà không phải thay đổi những sự thực thi đã cóvà trong cách này cải thiện được khả năng tương thích của component.

Khách hàng tùy chỉnh các component bởi các phương tiện giao diện vì giao diệnchỉ nhìn thấy được một phần Lý tưởng nhất, trong giao diện, ngữ nghĩa của mỗi hànhđộng phải được xác định vởi bì đây là điều quan trọng cho cả sự thi hành của giao diệnvà máy khách sử dụng giao diện Trong phần lớn các mô hình component hiện tại, giaodiện định chỉ định nghĩa một cú pháp (ví dụ: kiểu đầu vào đầu ra) và đưa ra rất ít thôngtin về các component.

Giao diện được định nghĩa trong công nghệ component có thể diễn đạt cácfunctional properties Function properties bao gồm một phần signature mà hành độngđược cung cấp bởi một component đã được miêu tả, và một phần trạng thái mà trạngthái của component được xác định.

Chúng ta có thể phân biệt hai loại giao diện Các component có thể xuất và nhậpcác giao diện cho và từ môi trường mà có thể bao gồm các component khác Một giaodiện xuất ra ngoài miêu tả dịch vụ cung cấp bởi component ra môi trường, trong khimột giao diện nhập vào xác định một dịch vụ yêu cầu bởi component từ môi trường.Các phương pháp tiếp cận chung của các giao diện là cú pháp truyền thống Tuy nhiên,việc thực hiện các vấn đề ngữ cảnh liên quan đến ngữ cảnh phụ thuộc (tức là đặc tảcủa môi trường triển khai và môi trường chạy) và sự tương tác cho biết sự cần thiếtcủa một hợp đồng rõ ràng xác định các hành vi của một component.

3.1.5 Hợp đồng

Hầu hết các kỹ thuật dùng để mô tả giao diện như IDL chỉ có quan tâm đến phầnchữ ký, trong đó hành động được cung cấp bởi một thành phần được miêu tả và do đókhông giải quyết các hành vi chung của các thành phần Một đặc tả chính xác của cáchành vi của một thành phần có thể thực hiện một hợp đồng Meyer đã đề cập, một hợpđồng danh sách cácràng buộc chung mà thành phần sẽ duy trì gọi là tính bất biến Mỗi