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

CHƯƠNG 3.

Mô hình thành phần CORBA

1. 
   
   
2. 
   
   
3. 
   
   
   1. 
      Khái niệm cơ bản về công nghệ phần mềm hướng thành phần
      
      1. 
         Giới thiệu
         

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.

2. 
   Thành phần
   

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

3. 
   Đối tượng và thành phầ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.
  

4. 
   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.

5. 
   Hợp đồng
   

• 
  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.
  

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.

6. 
   Khuôn mẫu
   

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.

7. 
   Frameworks
   

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.

8. 
   Frameworks và thành phần
   

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.

2. 
   Khái niệm CORBA
   
   1. 
      Giới thiệu
      

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)

2. 
   Ngôn ngữ đặc tả giao tiếp IDL
   

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
  

};

• 
  Để 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:
  

• 
  Kết quả là chúng ta có được tập tin CalculatorOperations.java như sau:
  

} //interface CalculatorOperations

Ánh xạ từ IDL sang java:

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:
  

• 
  Java :
  

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. 
   Mô hình thành phần CORBA
   

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”

1. 
   Giao diện và sự nối ghép
   

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 ngoà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 ngoà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 ngoà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.
  

2. 
   Đặc tả CCM bằng ngôn ngữ IDL
   
   1. 
      Thành phần
      

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.

};

component Car supports Clock {};

2. 
   Facets
   

;

};

Ví dụ:

module motors {

interface Engine{};

interface Panel {};

component Car supports Clock{

provides Engine _engine;

provides Panel_panel;

};

};

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;

};

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

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;

};

};

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. 
   Đ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)
  

CHƯƠNG 4.

Каталог: jspui -> bitstream -> 123456789
123456789 -> Nguyễn Ngọc Lý Giám đốc Trung tâm Nghiên cứu về Môi trường và Cộng đồng
123456789 -> Vò Quúnh Thu Cao häc K18
123456789 -> Khoa Báo chí Đhkhxh&NV
123456789 -> Acknowledgements
123456789 -> Danh mục chữ viết tắT
123456789 -> Chương TỔng quan vật liệu mao quản trung bình (mqtb) trật tự 1 Giới thiệu chung
123456789 -> Khoa hóa họC (141 142 báo cáo)

tải về 0.71 Mb.

Chia sẻ với bạn bè của bạn: