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ợ

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 toá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. 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. Tiền điều kiện, hậu điều kiện và tính bất biến 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ó. 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 đó 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. Design By Contract trong Eiffel Eiffel [4] hỗ trợ rất nhiều tính năng: tiếp cận hướng đối tượng hoàn thiện, khả năng giao tiếp bên ngoài (có thể giao tiếp với các ngôn ngữ C, C++, Java,…), hỗ trợvòng đời phần mềm bao gồm việc phân tích, thiết kế, thực thi và bảo trì, hỗ trợ Design By Contract, viết xác nhận, quản lý ngoại lệ… Design By Contract hầu như là vấn đề luôn được nhắc đến khi đề cập về Eiffel. Trong Eiffel, mỗi thành phần của hệ thống đều có thể được thực hiện theo một đặc tả tiên quyết về các thuộc tính trừu tượng của nó, liên quan đến những thao tác nội tại và những giao tác của nó với các thành phần khác. Eiffel thực thi một cách trực tiếp ý tưởng Design By Contract, một phương phá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. 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 … assertion_clausen end Loop invariant, loop variant from initialization until exit invariant inv variant var loop body end 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 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. CHƯƠNG 3. Mô hình thành phần CORBA Khái niệm cơ bản về công nghệ phần mềm hướng thành phần 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 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. 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ử… Đố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 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. 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 ứ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. 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 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 để hoà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 ngoà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. 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 hoàn cho các vấn đề tuần hoà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 đoá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. 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ỳ 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. 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. Khái niệm CORBA 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 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) 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ó