Khóa luận 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ỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Nguyễn Thế Nam
NGHIÊN CỨU THIẾT KẾ THEO HỢP ĐỒNG
VÀ
XÂY DỰNG CÔNG CỤ HỖ TRỢ
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công Nghệ Thông Tin
HÀ NỘI - 2010
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Nguyễn Thế Nam
NGHIÊN CỨU THIẾT KẾ THEO HỢP ĐỒNG
VÀ
XÂY DỰNG CÔNG CỤ HỖ TRỢ
KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Chuyên ngành: Công Nghệ Phần Mềm
Cán bộ hướng dẫn: TS. Trương Ninh Thuận
HÀ NỘI - 2010
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ầy
cô 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ông
nhữ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ập
cũ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ương
Ninh 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ần
cho 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ình
thự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ợ” được
hoà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úng
tô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ục
hoà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ải
thỏ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ềm
có 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 đắn
củ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ày
cà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ần
mề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ậy
trướ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ơn
nữ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ác
thà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ại
hoặ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ửa
mộ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ôi
nghiê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ực
quan. 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.
1.2.2.
Những công thức của tính đúng đắn......................................................4
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
1.3.1.
1.3.2.
Quyền lợi..............................................................................................8
Nghĩa vụ...............................................................................................8
CHƯƠNG 2. Giới thiệu về Design by Contract .......................................................9
2.1. Giới thiệu .......................................................................................................9
2.2. Khái niệm về hợp đồng.................................................................................10
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.
2.3.2.
Tiền điều kiện và hậu điều kiện...........................................................11
Tính bất biến.......................................................................................12
2.4. Design By Contract trong Eiffel....................................................................12
2.4.1.
2.4.2.
Biểu diễn Design by Contract trong Eiffel ..........................................13
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.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
Giới thiệu............................................................................................16
Thành phần.........................................................................................17
Đối tượng và thành phần.....................................................................17
Giao diện ............................................................................................18
Hợp đồng............................................................................................19
Khuôn mẫu .........................................................................................21
3.1.7.
3.1.8.
Frameworks........................................................................................21
Frameworks và thành phần .................................................................22
3.2. Khái niệm CORBA.......................................................................................22
3.2.1.
3.2.2.
Giới thiệu............................................................................................22
Ngôn ngữ đặc tả giao tiếp IDL............................................................23
3.3. Mô hình thành phần CORBA........................................................................25
3.3.1.
3.3.2.
Giao diện và sự nối ghép.....................................................................25
Đặc tả CCM bằng ngôn ngữ IDL ........................................................27
3.3.2.1. Thành phần .....................................................................................27
3.3.2.2. Facets..............................................................................................27
3.3.2.3. Receptacles .....................................................................................28
3.3.2.4. Event Sources..................................................................................28
3.3.2.5. Event Sinks .....................................................................................30
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.
4.3.2.
4.3.3.
Mô tả công cụ .....................................................................................31
Mô hình hoạt động..............................................................................32
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.4. Triển khai .....................................................................................................37
4.5. Thử nghiệm ..................................................................................................37
4.5.1.
4.5.2.
Bài toán ..............................................................................................37
Giao diện khởi động chương trình.......................................................40
4.5.3.
4.5.4.
4.5.5.
Giao diện khi làm việc với các thành phần..........................................41
Giao diện làm việc với các cổng .........................................................42
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
Viết tắt
Viết đầy đủ
Giải nghĩa
Thiết kế theo hợp đồng
DbC
Design by Contract
Component-Based
CBSE
CBD
Kĩ nghệ phần mềm hướng thành phần
Phát triển hướng thành phần
Software Engineering
Component-Based
Development
Common Object Request Kiến trúc môi giới gọi các đối tượng
CORBA
CCM
Broker Architecture
phân tán
CORBA component
Model
Mô hình thành phần CORBA
Application
API
Giao diện lập trình ứng dụng
Programming Interface
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ức
thườ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ầ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 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 ứ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à 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ô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ệ 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ần
trong 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ứ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. Mở rộng hơn là nghiên cứu thành
phần phần mềm. Nó là một trong những nghiên cứu quan trọng trong kỹ nghệ phần
mề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 để
1
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ông
nghệ 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.
2
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ầ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 phức tạp. Đặ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 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ăn
bả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 đọ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.
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ồi
thì 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ậy
trướ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ây
dự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ái
nhìn gần hơn về một hệ thống phần mềm đúng đắn và bền vững.
3
1.2. Biểu diễn một đặc tả
1.2.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}
Công thức 1: Công thức tính đúng đắn
Ý 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 trong
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 công thức 1, 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. 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ụ, 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ữ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ố 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.
4
- 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ằ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ờ, chúng 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.
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ê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:
{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ã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
5
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:
{…} 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ú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 mã 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.
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ộ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).
6
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 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.
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 đồ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:
- 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.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ọ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.
1.3.2. 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.
8
CHƯƠNG 2.
Giới thiệu về Design by Contract
2.1. Giới thiệu
Khi xét đến sự phát triển các phương thức và công cụ của một phần mềm mới,
các nhà phát triển đã có khuynh hướng chú trọng đến năng suất hơn là chất lượng của
phần mềm. Thời đại hiện nay, xu hướng đó đã không còn phù hợp. Trong công nghệ
hướng đối tượng [3] các lợi ích về năng suất đã xếp vị trí thứ yếu, phần lớn các nhà
phát triển đã chuyển sang lợi ích về chất lượng sản phẩm.
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ủa
phầ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ình
theo 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ụng
lạ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ềm
thô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ính
tin 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ẫn
củ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ụn
bộ 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ẽ thi
hà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 định
và 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ủa
chú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ọi
là “Design by Contract”, được tạm dịch là “Thiết kế theo hợp đồng”. Theo thuyết
Design by Contract, một hệ thống phần mềm được xem như là tập hợp các thành phần
có 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 ước
trong 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.
9
Tiếp cận một cách có hệ thống đến việc xây dựng hệ thống hướng đối
tượ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ợp
ngoạ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 mong
chờ các lợi ích từ hợp đồng và chấp nhận các giao ước có trong hợp đồng đó. Thông
thườ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ủa
bả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àng
khô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àng
Giao ước
Lợi ích
Bên khách hàng - Phải có mặt ở sân bay ít - Đến được địa điểm
nhất 5 phút trước khi
khởi hành.
mong muốn.
(khách hàng)
- Chỉ mang theo hành lý
đã được kiểm định.
- Thanh toán tiền vé máy
bay.
Bên cung cấp
-
Đưa khách hàng điến địa - Không cần quan tâm
điểm cần đến
khách hàng đến trễ hay
(Hãng
hàng
không.
không)
-
-
Có mang hành lý cấm
hay không.
Đã trả tiền vé chưa.
10
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à cho
bê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ềm
E. Để đạ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ến
lượ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, E
hợ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ảng
phâ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ử
được xá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ển
Giao ước
Lợi ích
Bên thực hiện
Bên cung cấp
- Chắc chắn rằng bảng - Cập nhật bảng chứa các
không đầy dữ liệu và
khóa không phải là
chuỗi rỗng
yếu tố xuất hiện, liên kết
với các khóa.
-
Bản ghi đưa các yếu tố - Không cần phải làm gì
vào bảng, liên kết với
nếu bảng đầy hoặc khóa
là một chuỗi rỗng..
các khóa.
Thiết kế theo hợp đồng được sử dụng ở đây để cung cấp đặc tả chính xác cho các
chứ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ành
phầ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ế theo
hợ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ến
2.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ác
phương thức. Chúng chỉ rõ nhiệm vụ được thi hành bởi một phương thức. Việc định
nghĩ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ột
hợp đồng, hợp đồng này ràng buộc phương thức và các lời gọi đến nó.
11
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ực
hiệ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ên
cung 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ản
ghi 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ều
hơ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ủa
kiểu mà hành động bắt đầu được biểu diễn trong trường hợp đó. Trong trường hợp của
cá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ày
quan 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ính
củ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ều
kiệ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.
12
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.
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ụ:
require
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ụ:
ensure
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ụ:
invariant
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ụ:
check
assertion_clause1
assertion_clause2
13
…
assertion_clausen
end
Loop invariant, loop variant
from
initialization
until
exit
invariant
inv
variant
var
loop
body
end
2.4.2. Ví dụ minh họa
Lấy ví dụ cho thuật toán put với công việc chèn một phần tử x vào từ điển với x
chứa một chuỗi các kí tự được coi như là khóa.
Put (x: ELEMENT; key: STRING)is
require
count <= capacity
notkey.empty
do
… Thuật toàn chèn…
ensure
has (x)
item (key) = x
count = old count + 1
end
14
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.
send (m: MESSAGE)is
-- Gửi một tin nhắn m theo chế độ gửi nhanh nếu có thể,
nếu không sẽ chuyển sang chế độ gửi chậm.
local
tried_fast, tried_slow:BOOLEAN
do
if tried_fast then
tried_slow := True
send_slow (m)
else
tried_fast := True
send_fast (m)
end
rescue
if not tried_slow then
retry
end
end
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.
15
CHƯƠNG 3.
Mô hình thành phần CORBA
3.1. Khái niệm cơ bản về công nghệ phần mềm hướng thành
phần
3.1.1. Giới thiệu
Có rất nhiều khái niệm cơ bản thường gặp về công nghệ phần mềm hướng thành
phần (CBSE) [8]. Các định nghĩa khác nhau có thể gây ra các nhầm lẫn vì CBSE là
một khái niệm mới mẻ. Nhiều khái niệm vẫn chưa hoàn toàn giải thích hoặc thử
nghiệm trong thực tế, và như một kệ quả, các định nghĩa của chúng vẫn còn rất mơ hồ.
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ành
phầ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ạo
nê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 đối
tượ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ện
rõ 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, giao
diệ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ện
quy đị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ủa
nó. 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
16
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ột
framework mô tả một đơn vị lớn của thiết kế và xác định mối quan hệ trong một
nhó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ác
nhau.
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ành
phầ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ành
phầ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ấp
nê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ềm
và 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 theo
cá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ều
ngô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 định
nghĩ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êu
cầ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 độc
lậ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êm
mớ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ần
là 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ết
cho 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, đặc
tí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ới
cá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 được
thự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
17
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đơn
lẻ 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 đến
việ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ếp
cậ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ôn
ngữ 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ần
thiết phải ở trong component chứa lớp đó. Nếu một lớp trong component có lớp cha
trong 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ữa
cá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ành
phầ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ện
lậ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ộc
và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ụ: java
interfaces 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ột
component.
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ữ
ở từng nơi từng vùng.
Component có một bộ các cơ chế liên thông với nhau rộng hơn so với đối
tượng, trong đó thường sử dụng cơ chế gửi tin.
Component thường là những đơn vị có tính chất lớn hơn các đối tượng và
có hành động phức tạp hơn ở những giao diện của chúng.
3.1.4. Giao diện
Một giao diện của component có thể được định nghĩa dưới dạng đặc tả của các
điểm truy cập của nó. Các máy khách truy cập các dịch vụ cung cấp bởi thành phần sử
dụng các điểm truy cập đó. Nếu thành phần có nhiều điểm truy cập, mỗi điểm sẽ tương
18
ứng với với các dịch vụ khác nhau được cung cấp bởi component, sau đó component
dự 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ất
kỳ 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 cho
nó 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àm
nà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êm
mộ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ện
chỉ 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ện
và 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,
giao diệ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ông tin về các component.
Giao diện được định nghĩa trong công nghệ component có thể diễn đạt các
functional 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ạng
thá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ập
các giao diện cho và từ môi trường mà có thể bao gồm các component khác. Một giao
diện xuất ra ngoài miêu tả dịch vụ cung cấp bởi component ra môi trường, trong khi
mộ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ết
củ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ần
chữ 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ác
hà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
19
Tải về để xem bản đầy đủ
61 trang
06/06/2025
40
Bạn đang xem 30 trang mẫu của tài liệu "Khóa luận Nghiên cứu thiết kế theo hợp đồng và xây dựng công cụ hỗ trợ", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- khoa_luan_nghien_cuu_thiet_ke_theo_hop_dong_va_xay_dung_cong.pdf
