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Ợ KHỐ 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Ợ KHỐ 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 khố 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 hồ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 hồ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 hồ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ợ. Ngồ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. 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 1.3.1. Quyền lợi..............................................................................................8 1.3.2. 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. 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.1.1. Giới thiệu............................................................................................16 3.1.2. Thành phần .........................................................................................17 3.1.3. Đối tượng và thành phần.....................................................................17 3.1.4. Giao diện ............................................................................................18 3.1.5. Hợp đồng ............................................................................................19 3.1.6. Khuơn mẫu .........................................................................................21 3.1.7. Frameworks ........................................................................................21 3.1.8. Frameworks và thành phần .................................................................22 3.2. Khái niệm CORBA.......................................................................................22 3.2.1. Giới thiệu............................................................................................22 3.2.2. Ngơn ngữ đặc tả giao tiếp IDL ............................................................23 3.3. Mơ hình thành phần CORBA........................................................................25 3.3.1. Giao diện và sự nối ghép.....................................................................25 3.3.2. Đặ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. 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.4. Triển khai .....................................................................................................37 4.5. Thử nghiệm ..................................................................................................37 4.5.1. Bài tốn ..............................................................................................37 4.5.2. Giao diện khởi động chương trình.......................................................40 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 Viết tắt Viết đầy đủ Giải nghĩa DbC Design by Contract Thiết kế theo hợp đồng CBSE Component-Based Software Engineering Kĩ nghệ phần mềm hướng thành phần CBD Component-Based Development Phát triển hướng thành phần CORBA Common Object Request Broker Architecture Kiến trúc mơi giới gọi các đối tượng phân tán CCM CORBA component Model Mơ hình thành phần CORBA API Application Programming Interface Giao diện lập trình ứng dụng 1 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 để 2 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. 3 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 tồ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. Ngồ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 hồn tồ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. 4 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 tố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. 5 - 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 hồ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 6 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ỉ tồ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). 7 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. 8 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. 9 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. 10  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 hồn tồ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 số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 tồ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 (khách hàng) - Phải cĩ mặt ở sân bay ít nhất 5 phút trước khi khởi hành. - Chỉ mang theo hành lý đã được kiểm định. - Thanh tốn tiền vé máy bay. - Đến được địa điểm mong muốn. Bên cung cấp (Hãng hàng khơng) - Đưa khách hàng điến địa điểm cần đến - Khơng cần quan tâm khách hàng đến trễ hay khơng. - Cĩ mang hành lý cấm hay khơng. - Đã trả tiền vé chưa. 11 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 - 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 - Cập nhật bảng chứa các yếu tố xuất hiện, liên kết với cá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ĩa là 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á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ĩ. 12 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 tồ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 hồn thiện, khả năng giao tiếp bên ngồ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. 13 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 14 … 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 tố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 tồn chèn… ensure has (x) item (key) = x count = old count + 1 end 15 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. 16 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 hồn tồ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ả hồn tồ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 17 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 hồ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 18 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 ngồ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 19 ứ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 ngồ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 20 hành vi trong thành phần, hợp đồng đưa ra danh sách các điều kiện mà cần phải gắn với bên thực hiện (tiền điều kiện) và các kết quả thành phần cần phải trả lại (hậu điều kiện). Tiền điều kiện, hậu điều kiện và tính bất biến hợp thành đặc tả những hành vi của thành phần. Mở rộng hơn việc đặc tả cách hành vi của thành phần đơn lẻ, hợp đồng cĩ thể được dùng để quy định các tương tác giữa một nhĩm các thành phần. Tuy nhiên, chúng được sử dụng một cách khác nhau. Một hợp đồng quy định tương tác giữa các thành phần cĩ những điều kiện sau:  Cĩ một tập những thành phần tham gia.  Vai trị của mỗi thành phần thơng qua các nghĩa vụ của hợp đồng, ví dụ như loại nghĩa vụ địi hỏi các thành phần hỗ trợ các biến nhất định và giao diện, và nghĩa vụ hệ quả địi hỏi các thành phần thực hiện một chuỗi lệnh của hành động, bao gồm việc gửi tin đến các thành phần khác.  Tính biết biến được duy trì bởi các thành phần.  Đặc tả các phương thức thuyết minh cho một hợp đồng. Chú ý rằng các thành phần khơng chỉ cung cấp các dịch vụ cho các thành phần khác mà cịn địi hỏi chúng từ các thành phần khác. Nĩ đúng cho cả yêu cầu chức năng và yêu cầu phi chức năng. Đo đĩ, các nghĩa vụ hợp đồng cĩ sự khác biệt đáng kể so với tiền điều kiện, hậu điều kiện của các phương thức được cung cấp bởi một thành phần. Tất cả hành vi của thành phần cĩ thể khá phức tạp bởi vì nĩ tham gia trong nhiều hợp đồng. Hơn nữa, hợp đồng chỉ rõ điều kiện mà trong đĩ tương tác giữa các thành phần trong điều khoản của tiền điều kiện và hậu điều kiện về hoạt động. Tiền điều kiện chỉ rõ các đặc điểm mơi trường phải đáp ứng để hoạt động của hợp đồng cĩ thể đáp ứng hậu điềukiện. Đơn giản tiền điều kiện/hậu điều kiện về hoạt động thiết lập sự đúng đắn cục bộ, trong khi để hồn thiện sự đúng đắn tổng thể, sự chấm dứt là cần thiết. Bởi vì hợp đồng được thiết kế để đại diện cho các tin nhắn, qua giao thức giữa các thành phần, chúng là bắt buộc trong tự nhiên và do đĩ khĩ diễn tả trong một hình thức khai báo Cũng lưu ý rằng hợp đồng và giao diện là những khái niệm khác nhau. Giao diện là tập hợp các hoạt động chỉ rõ các dịch vụ được cung cấp bởi thành phần, hợp đồng chỉ rõ các hành vi bên ngồi của thành phần hoặc là tương tác giữa các thành phần khác nhau. 21 3.1.6. Khuơn mẫu Kiến trúc sư Christopher Alexander [8] đã lần đầu tiên giới thiệu khái niệm về khuơn mẫu vào cuối năm 1970. Trong khái niệm này, khuơn mẫu định nghĩa giải pháp tuần hồn cho các vấn đề tuần hồn. Khuơn mẫu bắt những giải pháp khơng rõ ràng, khơng chỉ là những nguyên tắc và chiến lược trừu tượng, một cách gián tiếp, với tính chất khác biệt với nhiều kỹ thuật giải quyết vấn đề khác (như là mẫu hoặc phương thức thiết kế phần mềm) mà giải pháp bắt nguồn từ nguyên tắc. Các giải pháp cần được chứng minh để giải quyết vấn đề chứ khơng phải là lý thuyết hoặc suy đốn. Khuơn mẫu mơ tả mối quan hệ giữa cấu trúc hệ thống và cơ chế và khơng những là các mơ đun độc lập. Cuối cùng, yếu tố con người là một phần của khuơn mẫu. Một khuơn mẫu thiết kế cĩ thể được dùng để miêu tả trong thiết kế và tài liệu của một thành phần. Một thành phần, như một thực thể tái sử dụng, cĩ thể được xem như một sự thi hành một số khuơn mẫu thiết kế. Các khuơn mẫu thiết kế cĩ thể được sử dụng để mơ tả mức độ thấp chi tiết sự thi hành của hành vi và cấu trúc của những thành phần, hoặc là mối quan hệ giữa các thành phần trong bối cảnh của một ngơn ngữ lập trình cụ thể. Khuơn mẫu đã được áp dụng cho các thiết kế của nhiều hệ thống hướng đối tượng, và được coi là tái sử dụng những kiến trúc nhỏ gĩp phần vào một kiến trúc tổng thể. Mối quan hệ giữa các thành phần và khuơn mẫu thiết kế cĩ thể được xem như sau. Khuơn mẫu thiết kế được sử dụng rộng rãi trong quá trình thiết kế hệ thống dựa thành phần, trong đĩ các đơn vị tái sử dụng phải được xác định. Việc sử dụng các khuơn mẫu thiết kế làm cho nĩ dễ dàng hơn cho chúng ta cơng nhận những phần tái sử dụng hoặc tìm chúng trong các thành phần từ trước hoặc phát triển chúng như là các đơn vị tái sử dụng. Khuơn mẫu thiết kế cĩ thể được sử dụng để mơ tả hành vi của các bộ phận bên trong thành phần và do đĩ được sử dụng để phát triển thành phần. Hơn nữa, khuơn mẫu thiết kế khơng những được sử dụng để mơ tả cấu tạo thành phần khi thiết kế một hợp đồng hoặc framework mà các liên kết các thành phần riêng biệt. 3.1.7. Frameworks Nghĩa của CBSE khi xây dựng một phần mềm là: “đặt các phần lại với nhau”. Trong đĩ một mơi trường là điều cần thiết để các phần đĩ cĩ thể ghép lại với nhau. Framework là một phương tiện cung cấp một mơi trường như vậy. Framework cĩ liên quan chặt chẽ đến khuơn mẫu. Chúng xác định một nhĩm những bên tham gia và các mối quan hệ giữa chúng mà cĩ thể tái sử dụng trong bất kỳ 22 trạng thái nào. Szyperski [8] thấy rằng: so với khuơn mẫu, việc mơ tả đơn vị của thiết kế và chuyên biệt hơn khuơn mẫu. Một điển hình và thường được sử dụng là mơ hình Model-View-Controller (MVC) trong đĩ xác định một thiết lập mà Model được trình bày bởi View, và Controller quản lý các thao tác của người dùng. Framework cũng là các đơn vị kiến trúc phù hợp để chia sẻ và tái sử dụng. Framework cung cấp một giải pháp mạnh mẽ trong bối cảnh các thành phần tham gia cĩ thể nối ghép một cách hiệu quả. Framework sử dụng ở đây là framework hướng đối tượng và cĩ hơi khác so với framework thành phần. Framework hướng đối tượng trừu tượng hơn. Chúng là một phần của thiết kế và triển khai cho các ứng dụng trong một miền cụ thể. Framework cĩ trách nhiệm xử lý các tương tác phức tạp và các thành phần chỉ cần thực hiện đầy đủ vai trị của chúng trong framework. 3.1.8. Frameworks và thành phần Theo như các định nghĩa framework trước đĩ, một framework được xem như là một bảng mạch (framework thành phần) mà trong đĩ các vị trí trống đang chờ chèn các thành phần. Framework được thuyết minh bằng cách lấp đầy những chỗ trống. Yêu cầu được chỉ ra để cho biết những gì mà thành phần cần làm cho phù hợp với các chức năng như những gì đã được quy định ở bảng mạch. Trong khái niệm về framework chuẩn, chúng ta thấy rằng hành vi của framework cĩ thể được đặc tả trong các điểu khoản của tiền điều kiện và hậu điền kiện của framework, tính bất biến và sự thuyết minh cũng như là các thành phần được tham gia và mỗi quan hệ tĩnh giữa chúng. Hai vấn đề nữa là chuẩn hĩa kết nối giữa các thành phần và xác định cụ thể hơn giao diện các hành phần cần phải cĩ để các framework bao quanh. Các chỗ trống cĩ thể được lập đầy bằng các thành phần hoặc các framework khác. Các giao diện và các mối quan hệ giữa các thành phần được miêu tả. Các chi tiết trong đặc tả vẫn cịn được che dấu trong thành phần và cần tiếp thục như thế. Các framework thành phần cần phải được lấp đầy bởi các thành phần và được thuyết minh theo cách này. Như framework được thuyết minh bởi thành phần, chính nĩ sẽ trở thành một thành phần mới để sử dụng trong các framework mới. 3.2. Khái niệm CORBA 3.2.1. Giới thiệu Các ngơn ngữ lập trình đều cĩ các điểm chung là các lời gọi hàm, thủ tục, tham số truyền, trị trả về… Trong khi đĩ các đối tượng trong ngơn ngữ lập trình hướng đối tượng thiết kế bằng ngơn ngữ nào thì chỉ cĩ mã lệnh tương ứng của ngơn ngữ đĩ mới 23 truy xuất được chúng. Vậy làm sao các đối tượng được thiết kế bằng các ngơn ngữ lập trình khác nhau cĩ thể triệu gọi và sử dụng lẫn nhau? Các điểm chung của các ngơn ngữ lập trình được tập hợp lại trong ngơn ngữ đặc tả. Và CORBA là một ngơn ngữ đặc tả. CORBA là từ viết tắt của Common Object Request Broker Architecture và tạm dịch là kiến trúc mơi giới gọi các đối tượng phân tán. CORBA cịn được gọi là ngơn ngữ đặc tả giao tiếp (IDL – Interface Description Language) 3.2.2. Ngơn ngữ đặc tả giao tiếp IDL IDL [10] được sử dụng để mơ tả các giao diện giữa các đối tượng CORBA. Ngơn ngữ IDL là trung lập đối với ngơn ngữ thực hiện, nĩi cách khác, giao diện IDL cĩ thể được thực hiện trong bất kỳ ngơn ngữ nào chẳng hạn như Java, C, C + +, và một số ngơn ngữ khác. Ta lấy một ví dụ về đặc tả đối tượng Calculator bằng ngơn ngữ IDL của CORBA:  Tạo file Calculator.idl interface Calculator { long addNumber ( in long x, in long y ); };  Để chuyển file đặc tả này sang các ngơn ngữ lập trình khác chúng ta cĩ thể dùng như sau: idl2cpp Calculator.idl // chuyển sang C++ idlj Calculator.idl // chuyển sang java  Kết quả là chúng ta cĩ được tập tin CalculatorOperations.java như sau: publicinterface CalculatorOperations{ int addNumber(int x, int y); } //interface CalculatorOperations Ánh xạ từ IDL sang java: 24 Bảng 3: Bảng ánh xạ từ IDL sang java IDL Java module package interface interface string java.lang.String long int long long long float float double double exception class operation Method  CORBA IDL: module { interface MathLibrary { long add( in long x, in long y ); string About( in string version ); } };  Java : package Math; publicinterface MathLibrary { int add (int x, int y); String About(String version); } 25 Ngơn ngữ đặc tả trong mơ hình CORBA gần giống với ngơn ngữ C. CORBA đưa ra từ khĩa in cho các biến truyền vào theo trị và từ khĩa out để lấy trị trả về. 3.3. Mơ hình thành phần CORBA Mơ hình thành phần CORBA (CCM) là đặc tả thành phần gần đây nhất và được hồn thiện từ đặc tả OMG (Object Management Group). Nĩ được thiết kế dựa trên cơ sở tích lũy kinh nghiệm sử dụng dịch vụ CORBA, JavaBeans, và EJB [12] Giống như nhiều mơ hình thành phần khác, CCM tập trung vào các nhà phát triển ứng dụng bằng cách ghép các mơ-đun cĩ sẵn, mà cịn rõ ràng với việc thiết kế thành phần, lắp ráp và triển khai. Mục đích chính đằng sao đặc tả CCM là cung cấp giải pháp cho sự phức tạp của CORBA và những dịch vụ của nĩ. Trọng tâm của CCM là “một mơ hình thành phần phía máy chủ cho việc xây dựng và phát triển ứng dụng CORBA” Một trong những lợi ích của CCM là sự cố gắng “hợp nhất” các mặt được bao gồm trong kĩ nghệ phần mềm. Kết quả là một ứng dụng phần mềm được mơ tả trong các hình thức khác nhau theo 2 chiều: chiều thời gian (vịng đời, từ thiết kế đến triển khai) và chiều trừu tượng (từ khái niệm trừu tượng đến thi hành). Nhìn chung, điều này đã làm cho các đặc tả khá phức tạp. Với CCM, một thành phần là “một đơn vị mã phần mềm độc lập bao gồm dữ liệu và sự logic của nĩ, cùng với định nghĩa về kết nối được xác định rõ ràng hoặc giao diện tiếp xúc về liên lạc. Nĩ được thiết kế để cĩ thể sử dụng lặp lại trong phát triển ứng dụng, cĩ thể cĩ hoặc khơng cĩ các tùy biến” 3.3.1. Giao diện và sự nối ghép Cái nhìn từ bên ngồi của một thành phần là một phần mở rộng của ngơn ngữ CORBA IDL truyền thống. Một giao diện thành phần được tạo bởi các cổng được chia thành từng phần một [12] 26 Hình 1: Giao diện thành phần CORBA và các cổng Thành phần được coi như là một hộp đen. Giao diện chỉ là các điểm truy cập đến thành phần và đặc tả của thành phần trở thành đặc tả của giao diện thành phần. Thành phần hỗ trợ nhiều tính năng bên ngồi mà khách hàng và các thành phần khác của mơi trường ứng dụng cĩ thể tương tác với thành phần. Các đặc tính bên ngồi đĩ được gọi là các cổng. Mơ hình thành phần hỗ trợ 4 loại cổng chính là:  Facets: được đặt tên cho giao diện được cung cấp bởi thành phần cho các tương tác của bên khách hàng.  Receptacles: được đặt tên cho điểm kết nối miêu tả khả năng của thành phần sử dụng sự tham khảo được hỗ trợ bởi một vài tác nhân bên ngồi.  Event sources: được đặt tên cho điểm kết nối mà phát ra các sự kiện của một kiểu lý thuyết tới một hoặc nhiều sự kiện người dùng quan tâm hoặc tới một kênh sự kiện.  Event sinks: được đặt tên cho điểm kết nối vào mà sự kiện của một kiểu lý thuyết cĩ thể được đẩy vào. CCM xem các cổng như là các biến được đặt tên và đặt kiểu, do đĩ các facets khác nhau của cùng một thành phần cĩ thể cĩ các kiểu giống nhau. Các thành phần được đặt kiểu và cĩ thể kế thừa từ các thành phần khác. 27 3.3.2. Đặc tả CCM bằng ngơn ngữ IDL 3.3.2.1. Thành phần Thành phần được dùng với từ khĩa component. Giao diện tương đương được hỗ trợ bởi các thành phần cĩ thể kế thừa từ một số giao diện người dùng tự định nghĩa. Mối quan hệ này được thể hiện bằng cách sử dụng từ khĩa supports. Ví dụ: interface Clock { Time getTime (); void ResetTime (in Time t); }; component Car supports Clock {}; 3.3.2.2. Facets Facets tương ứng với giao diện được cung cấp bởi một thành phần. Facets được dùng với từ khĩa provides. component XXX { provides ; }; Ví dụ: module motors { interface Engine{}; interface Panel {}; component Car supports Clock{ provides Engine _engine; provides Panel_panel; }; }; 28 3.3.2.3. Receptacles Tương ứng với giao diện được yêu cầu bởi thành phần chức năng trong một mơi trường nhất định. Receptacle được dùng với từ khĩa uses  Receptacle đơn Cĩ thể kết nối đến một đối tượng, component XXX { uses ; }; Ví dụ: interface Customer {}; component Account { uses Customer owner; };  Nhiều receptacle Cĩ thể kết nối với nhiều đối tượng. component XXX { usesmultiple ; }; Ví dụ: component Account { usesmultiple Customer owner; }; 3.3.2.4. Event Sources Từ khĩa publishes được sử dụng để định nghĩa event sources. Từ khĩa này chấp nhận kết nối 1 – n 29 component XXX { publishes ; }; Ví dụ: module stockbroker { eventtype AlertSignal{ public string reason; }; component Broker { publishes AlertSignal alert_source; }; }; Từ khĩa emits chấp nhận kết nối 1- 1 component XXX { emits ; }; Ví dụ: module stockbrocker { eventtype StockLimit { public long stock_value; }; component Broker { emits StockLimit limitAlert; }; }; 30 3.3.2.5. Event Sinks Event sink được dùng với từ khĩa consumes. component XXX { consumes ; }; Ví dụ: module stockbrocker { eventtype AlertSignal { public string reason; }; component Trader { consumes AlertSignal alert_sink; }; }; 3.3.3. Điều kiện kết nối Để các thành phần trong CCM cĩ thể kết nối được với nhau nếu các cổng của chúng thỏa mãn một số điều kiện chính sau:  Facet cĩ thể chỉ kết nối với receptacles (cổng provideschỉ kết nối với cổng uses)  Event source chỉ cĩ thể kết nối với event sinks (nĩi cách khác: cổng publishes và cổng emitschỉ cĩ thể kết nối với cổng consumes).  Mỗi cổng provides(facet) cĩ thể kết nối với nhiều cổng uses(receptacles), mỗi cổng publishes cĩ thể kết nối với nhiều cổng consumesnhưng khơng thể ngược lại.  Mỗi cổng emitschỉ cĩ thể kết nối với một cổng consumes.  Với mỗi một cặp cổng đã được kết nối, kiểu của cổng cung cấp (facets, event sources) là kiểu con của một trong những cổng yêu cầu (receptacles, event sinks) 31 CHƯƠNG 4. Xây dựng cơng cụ đặc tả và kiểm chứng thành phần 4.1. Mơ tả cơng cụ Cơng cụ về đặ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. Đặc điểm nổi bật của ứng dụng bao gồm: - Mơi trường giao diện trực quan sinh động giúp cho người dùng cĩ khả năng tạo ra các thành phần, các cổng mà khơng cần thiết phải cĩ hiểu biết sâu về các ngơn ngữ đặc tả như Eiffel hay IDL. - Ứng dụng được phát triển trên nền Java nên cĩ thể chạy độc lập trên các mơi trường khác. 4.2. Ngơn ngữ phát triển cơng cụ Ngơn ngữ được lựa chọn để phát triển ứng dụng là ngơn ngữ Java. So với một số ngơn ngữ khác, nĩ cĩ cách ưu điểm: - Hiệu suất cao. - Cĩ tính hướng đối tượng cao. - Dễ học, dễ sử dụng nên những người sử dụng sau cĩ thể tiếp tục phát triển ứng dụng một cách dễ dàng. - Mơi trường làm việc thân thiện. - Cĩ thể chạy độc lập trên mọi mơi trường. 4.3. Phân tích cơng cụ đặc tả và kiểm chứng thành phần 4.3.1. Mơ tả cơng cụ Cơng cụ phải cĩ các chức năng sau:  Vẽ được các thành phần và các cổng trên thành phần đĩ.  Điền thơng tin chi tiết cho các thành phần và các cơng mỗi khi tạo mới.  Kiểm tra được sự kết nối của các cổng trong các thành phần. Phát hiện lỗi kết nối khi khơng thỏa mãn điều kiện.  Chức năng vào ra dữ liệu: người dùng cĩ thể lưu lại phần mình đã làm và tạm dừng để cĩ thể làm tiếp vào phiên làm việc sau. 32 4.3.2. Mơ hình hoạt động Ứng dụng được thiết kế theo mơ hình Model - View - Controller (MVC) Hình 2: Mơ hình MVC Một đối tượng đồ họa (GUI Component) bao gồm 3 thành phần cơ bản: Model, View, và Controller. Model cĩ trách nhiệm đối với tồn bộ dữ liệu cũng như trạng thái của đối tượng đồ họa. View chính là thể hiện trực quan của Model, hay nĩi cách khác chính là giao diện của đối tượng đồ họa. Và Controller điều khiển việc tương tác giữa đối tượng đồ họa với người sử dụng cũng như những đối tượng khác. Khi người sử dụng hoặc những đối tượng khác cần thay đổi trạng thái của đối tượng đồ họa, nĩ sẽ tương tác thơng qua Controller của đối tượng đồ họa. Controller sẽ thực hiện việc thay đổi trên Model. Khi cĩ bất kỳ sự thay đổi nào ở xảy ra ở Model, nĩ sẽ phát thơng điệp (broadcast message) thơng báo cho View và Controller biết. Nhận được thơng điệp từ Model, View sẽ cập nhật lại thể hiện của mình, đảm bảo rằng nĩ luơn là thể hiện trực quan chính xác của Model. Cịn Controller, khi nhận được thơng điệp từ Model, sẽ cĩ những tương tác cần thiết phản hồi lại người sử dụng hoặc các đối tượng khác. Trong ứng dụng này, các tệp chứa class về các cổng nằm trong Model. Các tệp chứa class giao diện nằm trong View, tệp Contract.java được nằm trong Controller. Model quản lý trạng thái thơng tin của các thành phần và các cổng. Viewer thể hiện các thành phần và cổng đĩ ra ngồi khung hiển thị của ứng dụng. Cịn Controller kiểm tra việc liên kết các cổng của các thành phần đĩ. 4.3.3. Thiết kế các lớp và đối tượng Căn cứ vào các đối tượng tham gia vào quá trình kiểm chứng, chúng tơi đưa ra các lớp đối tượng như sau: 33 Bảng 4: Các lớp đối tượng trong ứng dụng STT Tên lớp Mơ tả 01 canvaspanel Lớp đối tượng dùng để vẽ đối tượng 02 component Lớp chứa các thành phần 03 port Lớp cha chứa các thơng tin chung của các cổng 04 attribute Lớp chứa thơng tin cổng attribute 05 facets Lớp chưa thơng tin cổng facets 06 receptacles Lớp chưa thơng tin cổng receptacles 07 eventsources Lớp chứa thơng tin cổng event source 08 eventsinks Lớp chứa thơng tin cổng event sinks 09 inout Lớp vào ra dữ liệu 10 contract Lớp xử lý kết nối của các cổng 4.3.3.1. Sơ đồ tương tác giữa các đối tượng Tương tác giữa các đối tượng đĩ được thể hiện trong sơ đồ lớp dưới đây: 34 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 Các cổng được thừa kế từ lớp port được thể hiện trong sơ đồ dưới đây: Hình 4: Sơ đồ lớp thể hiện mối quan hệ kế thừa của các cổng 35 4.3.3.2. Mơ tả chi tiết các lớp đối tượng  Lớp component: Hình 5: Lớp Component Bảng 5: Chi tiết lớp component STT Thuộc tính Kiểu dữ liệu Phạm vi Mơ tả 01 id int private Mã thành phần 02 name string private Tên của thành phần 03 x int private Tọa độ x của thành phần khi vẽ 04 y int private Tọa độ y của thành phần khi vẽ  Lớp port: Hình 6: Lớp port 36 Bảng 6: Chi tiết lớp port STT Thuộc tính Kiểu dữ liệu Phạm vi Mơ tả 01 idComponent int private Mã thành phần mà cổng nằm trên đĩ 02 name string private Tên cổng 03 type int private Loại cổng. Cĩ thể là facets, receptacles, event sinks hoặc event sources  Lớp canvaspanel Hình 7: Lớp canvaspanel Bảng 7: Chi tiết lớp canvaspanel STT Thuộc tính Kiểu dữ liệu Phạm vi Mơ tả 01 label JLabel private Dùng để vẽ ảnh các thành phần, và các cổng 02 images images private Load ảnh các thành phần và các cổng 03 contract Contract private Kiểm tra điều kiện kết nối giữa các cổng của các thành phần 37  Lớp Contract Hình 8: Lớp Contract Bảng 8: Chi tiết lớp Contract STT Thuộc tính Kiểu dữ liệu Phạm vi Mơ tả 01 namePort1 String private Tên cổng thứ 1 02 namePort2 String private Tên cổng thứ 2 4.4. Triển khai Ứng dụng được phát triển bằng ngơn ngữ Java nên cần phải cài đặt JDK trước khi chạy chương trình. - Tải jdk tại địa chỉ: - Chọn hệ điều hành tương ứng rồi click vào nút download. - Bắt đầu chạy ứng dụng. 4.5. Thử nghiệm 4.5.1. Bài tốn Giả sử chúng ta cĩ một hệ thống Stock Quoter (Hình 9) [5] Đây là một hệ thống phức tạp với nhiều thành phần kết nối với nhau. 38 Hình 9: Kiến trúc CCM của hệ thống Stock Quoter. Để cĩ thể giới thiệu cơng cụ một cách dễ hiểu với người đọc, chúng ta sẽ tiếp cận với hệ thống đơn giản trước. Hệ thống Stock Quoter đơn giản gồm 2 thành phần với các cổng notifier_out, notifier_in, quoter_info_out, quoter_info_in (Hình 10) [12] Hình 10: Giao diện thành phần CORBA và các cổng. Hình vẽ minh họa hệ thống Stock Quoter bằng cách sử dụng mơ hình thành phần CORBA. Thành phần Stock Distributor biểu diễn hệ cơ sở dữ liệu chứng khốn thời gian thực. Khi các giá trị của cổ phiếu thay đổi, nĩ đẩy một eventype cĩ chứa tên cổ phiếu thơng qua một cổng event source (notifier_out) đến cổng event sink (notifier_in) tương ứng của một hoặc nhiều thành phần Stock Broker khác. Nếu các thành phần StockBroker này cần những thơng tin khác của cổ phiếu, chúng cĩ thể yêu cầu một hành động thơng qua cổng receptacle (quoter_info_in) của thành phần StockBroker đến cổng facets (quoter_info_out) của thành phần StockDistributor. 39 Dưới đây là sự thực thi của thành phần StockBroker và StockDistributor. Các cổng được định nghĩa như sau: component StockBroker { consumesStockName notifier_in; usesStockQuoter quoter_info_in; }; component StockDistributor supports Trigger { publishesStockName notifier_out; providesStockQuoter quoter_info_out; attributelong notification_rate; }; Thành phần StockBroker chứa hai cổng tương ứng với hai chức năng mà nĩ thực hiện. Một eventtype gọi là notifier_in sẽ tiếp nhận thơng tin từ thành phần StockDistributor khi giá trị cổ phiếu thay đổi. Ở hình trên, cổng notifier_in được kết nối với cổng notifier_out của thành phần StockDistributor khi kiến trúc CCM được triển khai và cấu hình cơng cụ khi ứng dụng được thực hiện. Nĩ sử dụng giao diện StockQuoter được cung cấp bởi thành phần StockDistributor mà báo cáo thơng tin về cổ phiếu như giá cổ phiếu tăng hay giảm hay giá trị giao dịch của cổ phiếu trong ngày. Thành phần StockDistributor xuất một eventtype được gọi là notifier_out để đẩy thơng tin về thành phần StockBroker khi mà giá trị cổ phiếu thay đổi. Ngồi ra, nĩ cịng định nghĩa một cổng facet được gọi là quoter_info_out trong đĩ chứa các thơng tin thêm về một cổ phiếu cụ thể. Tiếp theo, thành phần này cịn định nghĩa một thuộc tính attribute cĩ tên là notification_rate mà quản trị hệ thống cĩ thể sử dụng để kiểm sốt tốc độ của thành phần StockDistributor, cơ sở dữ liệu bảng giá cổ phiếu và đẩy những thay đổi cho thành phần StockBroker để người dùng cĩ thể theo dõi trực tiếp. Sau quá trình phân tích, thiết kế, lập trình và kiểm thử chúng tơi đã xây dựng (mặc dù chưa hồn thiện) ứng dụng đặc tả và kiểm chứng. Dưới đây là một số giao diện của ứng dụng 40 4.5.2. Giao diện khởi động chương trình Hình 11: Giao diện khởi động ứng dụng Giao diện khởi động chương trình bao gồm thanh menu File, Edit, View… Thanh cơng cụ dùng để thêm các thành phần và các cổng ở bên trái chương trình. Bên phải là panel thể hiện những hình vẽ mà người dùng vẽ ra. Ở dưới là khung hiển thị các bước làm của người dùng. Thơng báo kết quả các cổng của thành phần cĩ kết nối được hay khơng. 41 4.5.3. Giao diện khi làm việc với các thành phần Hình 12: Giao diện điền thơng tin khi thêm mới 1 thành phần Khi chọn nút vẽ thành phần, giao diện để điền thơng tin cho component được khởi tạo. Người dùng điền tên thành phần vào khung Name, sau đĩ chọn OK để hồn thành. Nếu khơng cần tạo thành phần nữa thì click vào nút Cancel để bỏ qua. Sau khi tạo thành cơng, mơ hình thành phần sẽ được thể hiện như hình vẽ 13. Dưới đây là 3 thành phần được đặt tên là Stock Distributor, Stock Broker. 42 Hình 13: Giao diện kết quả sau khi thêm một thành phần thành cơng 4.5.4. Giao diện làm việc với các cổng Sau khi tạo thành cơng các thành phần, người dùng cĩ thể tạo các cổng cho từng thành phần bằng cách click vào nút khởi tạo cổng ở thanh cơng cụ bên tay trái cửa sổ. Sau khi chọn vị trí cho cổng trên thành phần, giao diện điền thơng tin cho cổng hiện lên, bao gồm tên cổng, tên kiểu, tên kiểu cha nếu cĩ kế thừa. (Hình 14) 43 Hình 14: Giao diện điền thơng tin khi thêm một cổng mới 44 Hình 15: Giao diện kết quả khi thêm mới cổng thành cơng Sau khi tạo cổng thành cơng, màn hình sẽ hiện lên như sau (Hình 15). Ở đây, cổng cĩ tên là: notifier_out, quoter_info_out… được tạo trên Stock Distributor. Các cổng notifier_in và quoter_info_in được tạo trên Stock Broker. 45 4.5.5. Giao diện sau khi kiểm chứng kết nối giữa các thành phần Hình 16: Giao diện khi kết nối thành cơng các cổng Sau khi tạo các thành phần và các cổng thành cơng. Người dùng cĩ thể kết nối các cổng của các thành phần với nhau để kiểm tra bằng cách click vào biểu tượng kết nối trên thanh cơng cụ, click chuột vào cổng thứ nhất và di đến cổng thứ hai là cổng cần kết nối. Sau khi kết nối, chương trình sẽ kiểm tra đặc tả của các cổng mà người dùng đã điền ở trên và kiểm tra với các điều kiện kết nối. Nếu thỏa mãn, kết nối thành cơng và được thể hiện ở hình 16. Trái lại, nếu khơng thành cơng, chương trình sẽ hiện lên bảng thơng báo như hình 17 (Xem lại các điều kiện kết nối phần 3.3.3 trang 30). 46 Hình 17: Giao diện khi kết nối khơng thành cơng các cổng 47 Kết luận Qua quá trình nghiên cứu và thực hiện khố luận, chúng tơi nhận thấy đã đạt được một số kết quả chính sau: - Nắm bắt được khá rõ các nền tảng cần thiết để cĩ thể nhìn gần hơn về một hệ thống phần mềm đúng đắn và bền vững. Nĩi một cách dễ hiểu, phần mềm đúng đắn là phần mềm cĩ ít lỗi và xử lý được những lỗi bất thường xảy ra trong phần mềm trong lúc làm việc. Như thế, phần mềm mới cĩ khả năng tồn tại lâu dài với thời gian và được người dùng ưa chuộng. - Hiểu khá rõ về cơng nghệ Design ByContract và khả năng ứng dụng của nĩ trong lập trình hướng đối tượng. 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. Phải thỏa mãn những giao ước đĩ thì các thành phần mới cĩ thể liên kết với nhau để tạo nên sự chính xác, tính đúng đắn cho phần mềm. Ngồi ra, cơng nghê này cịn cung cấp một cơng cụ rất tốt cho việc viết tài liệu phát triển cho phần mềm, dễ dàng phát hiện và gỡ lỗi. - Xây dựng một cơng cụ đặc tả và kiếm chứng cho sự liên kết của các thành phần bằng ngơn ngữ Java. Khi sử dụng ứng dụng này, một cách trực quan, người dùng nhanh chĩng vẽ ra các thành phần cùng với các cổng. - Ngồi ra chúng tơi đã trình bày một số khía cạnh của đặc tả thành phần, vạch ra phương pháp tiếp cận với cách giao tiếp của thành phần dựa trên các loại cổng được kết nối. Chúng tơi đã xác định các ràng buộc về cổng, nhờ đĩ, chúng ta cĩ thể biết được các thành phần cĩ thể kết nối được với nhau nếu chúng đáp ứng được những yêu cầu mà chúng tơi đã nêu ở trên. Ở mức độ này, chúng tơi mới chỉ nghiên cứu đến các loại cổng (facet, receptacle, event source, event sink) và các ràng buộc về loại cổng. Chúng tơi đã xác minh điều kiện kết nối của các loại cổng và tích hợp chúng với nhau để hỗ trợ cho phương pháp tiếp cận của chúng tơi. Điều này sẽ ủng hộ chúng tơi trong việc xác minh tính tương thích giữa các thành phần bởi các đặc tả hành vi ở mức độ ngữ nghĩa. 48 Hướng phát triển Trong thời gian tới, chúng tơi sẽ tiến hành kiểm tra thành phần cấu tạo giữa các hành vi của các cổng khi kết nối thành cơng giữa các loại cổng. Sau đĩ chúng tơi sẽ nâng cấp ứng dụng hiện tại để cĩ thể hỗ trợ tốt hơn việc đặc tả và kiểm chứng cho cơng đoạn kết nối các thành phần của phần mềm hướng thành phần này. 49 Tài liệu tham khảo Tài liệu tham khảo tiếng Việt [1] Nguyễn Thanh Bình - Đặng Thị Lệ Thu. Giải pháp nâng cao chất lượng phần mềm hướng đối tượng. Tạp chí khoa học và cơng nghệ, Đại học Đà Nẵng. Số 5(28).2008. Tài liệu tham khảo tiếng Anh [2] A. M. Zaremski and J. M. Wing. Specification matching of software components. 333–369, 1997. [3] B. Meyer. Design By Contract, in Advances in Object-Oriented Software Engineering. Prentice Hall. 1991. [4] B. Meyer. Eiffel: The Language. Prentice Hall. 1992. [5] Bala Natarajan, Douglas C. Schmidt, and Steve Vinoski. The CORBA Component Model. September 01, 2004 [6] Boodhoo, Jean-Paul. Design Patterns: Model View Controller. Retrieved 2009-07- 07. [7] C.A.R Hoare. An axiomatic basis for computer programming. Communications of the ACM. 1969. [8] Ivica Crnkovic - Magnus Larsson. Building Reliable Component-Based Software Systems. Artech house, Inc. 2002. tr.3-18 và tr.73-76. [9] Frank Pilhofer. Writing and Using CORBA Components. Technology report, FPX. 04/2002. [10] Jeremy Rosenberger. Teach Yourself CORBA In 14 Days [11] Jonas Bergstrưm. Design By Contract for Java. [12] Tran Thi Mai Thuong - Vo Van Thanh - Truong Ninh Thuan. Checking the conformability in CORBA component model specifications. Journal of Science, Natural Sciences and Technology. 2008. [13] Yi Liu - H. Conrad Cunningham. Software Component Specification Using Design by Contract. National Defense Industry Association. 04/2002. 50 Phụ lục (Hướng dẫn sử dụng chương trình) Sau khi cài đặt mơi trường jre cho java. Người dùng cĩ thể click vào file chạy chương trình để chạy cơng cụ (Hình 11) Đầu tiên để vẽ một thành phần, người dùng cĩ thể click vào nút cĩ biểu tượng sau đĩ di chuột sang màn hình bên phải để vẽ. Chương trình sẽ hiện lên bảng địi người dùng phải điền đầy đủ thơng tin cho thành phần. Sau khi hồn thành thao tác, click vào nút ok để vẽ hoặc click vào nút cancel để bỏ qua khơng vẽ nữa. Để cĩ thể vẽ các cổng cho thành phần, người dùng click vào nút cĩ các biểu tượng , , , , tương ứng với các cổng attribute, facet, receptacle, event source, event sinks. Chú ý, các cổng nằm trên thành phần nên khi vẽ, người dùng phải click vào phạm vi bên trong thành phần, nếu khơng sẽ cĩ thơng báo lỗi hiện ra ngăn cấm việc vẽ các cổng. Chương trình sẽ hiện lên khung bắt buộc người dùng điền thơng tin cho các cổng đĩ. Khung thơng tin bao gồm ơ điển tên cổng, kiểu của cổng, và tủy chọn xem kiểu của cổng đĩ cĩ kế thừa kiểu nào khác của một cổng nào đĩ khác hay khơng. Sau khi hồn thành thao tác, người dùng click vào ok để vẽ cổng hoặc click vào cancel để bỏ qua khơng vẽ cổng nữa. Sau khi vẽ xong các thành phần và các cổng, người dùng cĩ thể click vào nút cĩ biểu tượng để tiến hành kết nối các cổng của các thành phần. Người dùng click chuột vào 1 cổng bất kỳ và giữ lỳ chuột, di đến cổng thứ 2 cần kết nối, sau đĩ thả chuột ra. Chương trình sẽ kiểm tra các điều kiện kết nối (xem lại mục 3.3.3). Nếu khơng thỏa mãi một trong 5 điều kiện đã nên ở trên, sẽ cĩ một bảng thơng báo kết nối khơng thành cơng kèm theo lỗi xảy ra ở điều kiện nào. Sau khi người dùng xác nhận, phần kết nối sẽ tự động được xĩa đi. Ngồi ra người dùng cĩ thể dùng thêm một số chức năng phụ như tạo mới một bản đặc tả mới bằng cách vào menu File → New. Nếu người dùng kết nối sai cổng (nhưng vẫn thỏa mãn điều kiện) thì cĩ thể sử dụng chức năng undo hoặc redo bằng cách vào menu Edit → Undo hoặc Edit → Redo.