tiểu luận công nghệ phần mềm hướng thành phần

M

ĐẠI HỌC CÔNG NGHỆ
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TIỂU LUẬN:

CÔNG NGHỆ PHẦN MỀM HƯỚNG
THÀNH PHẦN

Giáo viên hướng dẫn:
TS. Võ Đình Hiếu

Nhóm học viên thực hiện:
Đỗ Thị Loan
Vũ Thị Ngọc Anh
Phạm Công Thiên Lý

Hà Nội, tháng 3/2013


Công nghệ phần mềm hướng thành phần

Mục lục
1. Giới thiệu....................................................................................3
2. Các thành phần và các mô hình thành phần..........................4
2.1 Các mô hình thành phần......................................................7

3. Quy trình CBSE........................................................................10
3.1 CBSE cho tái sử dụng.........................................................11
3.2 CBSE trong việc tái sử dụng.............................................14

4. Thành phần phức hợp...............................................................17
5. Kết luận......................................................................................21
6. Tài liệu tham khảo....................................................................21

2/21


Công nghệ phần mềm hướng thành phần

3/21

1. Giới thiệu
Công nghệ phần mềm dựa trên thành phần (CBSE) xuất hiện vào
cuối những năm 1990 là một cách tiếp cận để phát triển hệ thống phần
mềm dựa trên việc tái sử dụng các thành phần phần mềm. Sự ra đời của nó
được thúc đấy bới sự thất bại của các nhà thiết kế phát triển hướng đối
tượng đã không dẫn đến tái sử dụng mở rộng như được đề xuất ban đầu.
Các lớp đối tượng đơn lẻ quá chi tiết và cụ thể và thường phải bị ràng buộc
với một ứng dụng lúc biên dịch. Bạn phải có hiểu biết chi tiết các lớp để sử
dụng chúng, điều này thường có nghĩa là bạn phải có mã nguồn thành phần.
Điều này có nghĩa là việc bán và phân phối các đối tượng là các thành phần
tái sử dụng là không thực tế.
Các thành phần được trừu tượng hóa ở mức cao hơn các đối tượng và
được xác định bởi các giao diện. Chúng thường lớn hơn các đối tượng
riêng lẻ và tất cả các chi tiết thực thi được ẩn từ các thành phần khác. Công
nghệ dựa trên thành phần (CBSE) là môt quy trình xác định, thực thi, và
tích hợp các thành phần độc lập vào trong hệ thống. Nó trở thành một cách
tiếp cận phát triển phần mềm quan trọng bởi vì các hệ thống phần mềm
đang trở lên lớn hơn và phức tạp hơn. Các khách hàng đang đòi hỏi phần
mềm đáng tin cậy được cung cấp và triển khai nhanh hơn. Cách duy nhất là

chúng ta có thể đối phó với sự phức tạp và cung cấp phần mềm tốt hơn
một cách nhanh chóng là phải sử dụng lại hơn là thực hiện lại các thành
phần phần mềm.
Các yếu tố cần thiết của công nghệ phần mềm dựa trên thành phần là:
1.Các thành phần độc lập được hoàn toàn được xác định bởi giao
diện của chúng. Cần có một sự tách biệt rõ ràng giao diện thành phần và sự
thực thi của nó. Điều này có nghĩa là một sự thực thi của một thành phần có
thể được thay thế bằng một cái khác, mà không thay đổi các phần khác của
hệ thống.
2.Các tiêu chuẩn của các thành phần là tạo điều kiện kết hợp các
thành phần. Các tiêu chuẩn này được chứa trong một mô hính thành phần.
Chúng xác định, ở mức rất tối thiểu, các giao giện thành phận nên được xác
định như thế nào và chúng giao tiếp với nhau như thế nào. Một số mô hình
tiến xa hơn và xác định các giao diện mà nên được thực thi bởi tất cả các
thành phần thích ứng. Nếu các thành phần thích ứng với các tiêu chuẩn, thì
các hoạt động của chúng độc lập với ngôn ngữ lập trình của chúng. Các
thành phần được viết bằng ngôn ngữ khác nhau có thể được tích hợp vào
cúng một hệ thống.
3.Lớp Middleware(lớp trung gian) cung cấp hỗ trợ phần mềm cho
việc tích hợp các thành phần. Để tạo ra sự độc lập, phân phối các thành
phần làm việc cùng nhau, bạn cần sự hỗ trợ của lớp Middleware để xử lý
các giao tiếp của các thành phần. Lớp Middleware cho việc hỗ trợ thành
phần xử lý các vấn đề ở mức thấp một cách hiêu quả và cho phép bạn tập
trung vào các vấn đề có liên quan đến ứng dụng. Ngoài ra, lớp Middleware


Công nghệ phần mềm hướng thành phần

4/21

cho sự hỗ trợ thành phần có thể cung cấp sự hỗ trợ cho việc phân bổ tài
nguyên, quản lý giao dịch bảo mật và đồng bộ.
4.Một quy trình phát triển đó là hướng đến công nghệ phần mềm
dựa trên thành phần. Bạn cần một quy trình phát triển mà cho phép các yêu
cầu được triển khai, tùy theo chức năng của các thành phần có sẵn.
Phát triển dựa trên thành phần là hiện thân của việc thực hành kỹ thuật
phần mềm tốt. Nó tạo ra hướng để thiết kế một hệ thống sử dụng các thành
phần, ngay cả khi nếu bạn phải phát triển hơn là tái sử dụng các thành phần
này. Về cơ bản, CBSE là các nguyên lý thiết kế đúng đắn mà hỗ trợ việc
xây dựng phần mềm dễ hiểu và dễ bảo trì:
5.Các thành phần là độc lập để chúng không can thiệp vào các hoạt
động khác. Các chi tiết của sự thực thi được ẩn. Các thực thi của các thành
phần có thể được thay đổi mà không ảnh hướng đến phần còn lại của hệ
thồng.
6.Các thành phần giao tiếp thông qua giao diện được xác định rõ
ràng. Nếu các giao diện được duy trì, một thành phần có thể được thay thế
bằng một thành phần khác mà cung cấp thêm hoặc nâng cao chuwca năng.
7.Cơ sở hạ tầng của thành phần cung cấp một loạt các dịch vụ chuẩn
mà có thể được sử dụng trong các hệ thống ứn dụng. Điều này làm giảm số
lượng mã mới mà phải phát triển.
2. Các thành phần và các mô hình thành phần.
Có sự thống nhất chung trong cộng đồng CBSE là một thành phần là
một đơn vị phần mềm độc lập mà có thể được hợp thành với các thành
phần khác tạo ra một hệ thống phần mềm. Ngoài ra, người ta còn đề xuất
một vài định nghĩa khác của một thành phần phần mềm. Councill và
Heineman (2001) định nghĩa một thành phần là:
“ Một yếu tố phần mềm mà phù hợp với một mô hình thành phần
tiêu chuẩn và có thể là được triển khai và tạo ra độc lập mà không chỉnh
sửa theo một tiêu chuẩn của thành phần nào”
Định nghĩa này chủ yếu dựa trên tiêu chuẩn để một đơn vị phần mềm

phù hợp với các tiêu chuẩn này là một thành phần. Szyperski (2002), không
đề cập đến tiêu chuẩn trong định nghĩa của ông về một thành phần mà tập
trung vào các đặc điểm chính của các thành phần:
“ Một thành phần phần mềm là một đơn vị thành phần giao kèo- các
giao diện được thiết lập và phụ thuộc ngữ cảnh rõ ràng duy nhất. Một thành
phần phần mềm có thể được triển khai độc lập và phụ thuộc vào thành
phần bởi bên thứ ba”.
Cả hai định nghĩa trên được dựa trên khái niệm của một thành phần
là một yếu tố mà được bao gồm bởi một hệ thống, chứ không phải là một
dịch vụ mà được tham chiếu bởi hệ thống. Tuy nhiên chúng cũng phù hợp
với ý tưởng một dịch vụ là một thành phần.
Szyperski cũng cho rằng một thành phần không có trạng thái quan
sát bên ngoài. ĐIều này nghĩa là các bản sao của các thành phần hoàn toàn


Công nghệ phần mềm hướng thành phần

5/21

giống nhau. Tuy nhiên, một vài mô hình thành phần, như là mô hình
Enterprise Java Beans, cho phép các thành phần là có trạng thái (stateful) vì
vậy chúng không phù hợp với định nghĩa của Szyperski. Mặc dù các
thanhg phần phi trạng thái (stateless) chắc chắn đơn giản hơn để sử dụng,
có một vài hệ thống mà ở đó các thành phần có trạng thái tiện lợi hơn và
giảm độ phức tạp của hệ thống. Các định nghĩa ở trên có điểm chung là
cùng đồng ý rằng các thành phần là độc lập, và chúng là những đơn vị
thành phần trong một hệ thống. Theo quan điểm của Ian Sommerville, một
định nghĩa tốt hơn của một thành phần có thể được bắt nguồn bằng cách kết
hợp các đề xuất trên.
Bảng bên dưới cho thấy những gì Ian Sommerville cho là các điểm

thiết yếu của một thành phần được sử dụng trong CBSE.
Các đặc điểm Mô tả
của thành phần
Tiêu chuẩn hóa
Tiêu chuẩn hóa thành phần có nghĩa là một thành phần được
sử dụng trong một quy trình CBSE phải phù hợp với một
mô hình thành phần chuẩn. Mô hình này có thể được xác
định các giao diện thành phần, siêu dữ liệu thành phần, tài
liệu, sự hợp thành và triển khai
Độc lập
Một thành phần nền được độc lập – nó nên có thể được biện
soạn và triển khai nó mà không cần phải sử dụng các thành
phần cụ thể khác. Trong các trường hợp mà thành phần cần
các dịch vụ được cung cấp bên ngoài, chúng cần được thiết
lập một cách rõ ràng trong một đặc tả yêu cầu giao diện.
Có khả năng hợp Để một thành phần có khả năng hợp thành, tất cả các tương
thành
tác bên ngoài phải được thực hiện thông qua việc công khai
xác định giao diện. Ngoài ra nó phải cung cấp truy cập ben
ngoài thông tin về chính nó, như các phương thức và thuộc
tính của nó.
Có thể triển khai Để có thể triển khai, một thành phần phải được độc lập. Nó
phải có khả năng hoạt động như một thực thể độc lập trên
một nên tảng thành phần mà cung cấp một thực thi của mô
hình thành phần. Điều này thường có nghĩa là cá thành phần
là nhị phân và không phải được biên dịch trước khi nó được
triển khai. Nếu một thành phần được thực thi như một dịch
vụ, nó không phải được triển khai bới một người dùng của
một thành phần. Thay vào đó nó được triển khai bởi nhà
cung cấp dịch vụ.

Ghi chép
Các thành phần phải được ghi chép đầy đủ để người dùng
tiềm năng có thể quyết đinh có hay không các thành phần
đáp ứng nhu cầu của họ. Cú pháp và, lý tưởng, các ngữ
nghĩa của tất cả các giao diện của thành phần nên được quy
định.


Công nghệ phần mềm hướng thành phần

6/21

Cách hữu hiệu để suy nghĩ về một thành phần như là một nhà cung
cấp chủa một hoặc nhiều dịch vụ. Khi một hệ thống cần một dịch vụ, nó
gọi trên một thành phần để cung cấp dịch vụ mà không quan tâm về nơi mà
thành phần được thực thi hoặc ngôn ngữ lập trình được sử dụng để phát
triển thành phần. Ví dụ, một thành phần trong một hệ thống thư viện có thể
cung cấp một dịch vụ tìm kiếm chi phép người dùng tìm kiếm các loại thư
viện khác nhau.
Một thành phần có thể chuyển đổi từ một định dạng đồ họa này sang
môt định dạng đồ họa khác (vì dụ: .tiff sang .jpeg) cung cấp một dịch vụ
chuyển dổi dữ liệu. v.v
Xem một thành phần là một nhà cung cấp dịch vụ được nhấn mạnh
hai đặc tính quan trọng của thành phần tái sử dụng:
1.Thành phần là một thực thể thực thi độc lập mà được xác định bởi
các giao diện của nó. Bạn không cần hiểu bất kỳ cái gì về mà nguồn của nó
khi sử dụng nó. Nó có thể hoặc được tham chiếu như một dịch vụ bên
ngoài hoặc đưa trực tiếp vào trong một chương trình.
2.Các dịch vụ được cung cấp bởi một thành phần được thực hiện
thông qua một giao diện và tất cả các tương tác được thông qua giao diện

đó. Các giao diện thành phần được biểu hiện trong điều kiện của các hoạt
động tham số và trạng thái bên trong nó không bao giờ lộ ra.
Các thành phần có hai giao diện liên quan, trình bày trong hình 1.
Các giao diện này phản ảnh các dịch vụ mà thành phần cung cấp và các
dịch vụ mà thành phần yêu cầu để vận hành chính xác.
- Giao diện “cung cấp” xác định các dịch vụ dược cung cấp bởi
thành phần. Giao diện nầy, về cơ bản, là các thành phần API. Nó định
nghĩa các phương thức mà có thể được gọi bởi người dùng các thành phần.
- Các giao diện “yêu cầu” xác định dịch vụ gì phải được cung cấp
bởi các thành phâng trong hệ thống nếu một thành phần là để hoạt động
chính xác. Nếu những cái này không có sẵn, thì thành phần sẽ không làm
việc. Điều nàu không làm ảnh hưởng đến sự độc lập hay tính thực thi của
một thành phần bởi vì giao diện “yêu cầu” không xác định các dịch vụ này
nên được cung cấp như thế nào. Trong UML, ký hiệu cho một giao diện
“yêu cầu” là một hình bán nguyệt ở cuối một dòng từ từ biểu tượng thành
phần.
Để minh họa cho các giao diện này, hình 2 cho thấy một mô hình của
một thành phần được thiết kế để thu thập và tổng hợp thông tin từ một
mảng các cảm biến. Nó chạy tự động để thu thấp dữ liệu qua một khoảng
thời gian và theo yêu cầu, cung cấp dữ liệu thu được cho một cuộc goi
thành phần. Giao diện “cung cấp” bao gồm các phương thức thêm, loại bỏ,
bắt đầu, dừng lại, kiểm tra các cảm biến. Phương thức báo cáo trả lại dữ
liệu cảm biến mà đã được thu về, và phương thức listAll cung cấp thông tin
về các cảm biến kèm theo. Các phương thức này kết hợp các tham số cụ
thể các định danh, địa điểm của cảm biến. Giao diện “yêu cầu” được sử


Công nghệ phần mềm hướng thành phần

7/21

dụng để kết nối thành phần tới các cảm biến. Giả thiết rằng các cảm biến có
một giao diện dữ liệu, được truy cập thông qua ensorData, và một giao diện
quản lý được truy câp thông qua phương thức sensorManagement. Giao
diện này được thiết kế để kết nối với các loại cảm biến để nó không bao
gồm các thao tác cảm biến cụ thể như Test, provideReading, vv. Thay vào
đó, các lệnh được dùng bởi một loại cụ thể của cảm biến được nhúng trong
một chuỗi, cái mà là một tham số cho các thao tác trong giao diện “yêu
cầu”. Các thành phần Adaptor phân tích chuỗi này và dịch các lệnh được
nhúng bên trong giao diện điều khiển đặc trưng của mỗi loại cảm biến.

Hình 1: các giao diện thành phần

Hình 2 Mô hình của một thành phần thu thập dữ liệu
Một sự khác biệt quan trọng giữa một thành phần là một dịch vụ bên ngoài
và một thành phần là một yếu tố của một chương trình đó là các dịch vụ là
các thực thể hoàn toàn độc lập. Chúng không có một giao diện “yêu cầu”.
Các chương trình khác nhau có thể sử dụng các dịch vụ này mà không cần
phải thực thi bất kỳ một hỗ trợ bổ xung nào được yêu cầu bởi dịch vụ.
2.1 Các mô hình thành phần
Một mô hình thành phần là một định nghĩa các tiêu chuẩn về sự thực thi,
ghi chép tài liệu, và phát triển thành phần. Các chuẩn này là để những nhà
phát triển thành phần đảm bảo rằng các thành phần có thể hoạt động. Họ
cũng là các nhà cung cấp cơ sở hạ thầng thực hiện thành phần.


Công nghệ phần mềm hướng thành phần

8/21

Nhiều mô hình thành phần đã được đề xuất, nhưng các mô hình quan trọng
nhất hiện nay là mô hình WebServices, mô hình Sun’s Enterprise Java
Beans (EJB) và mô hình Microsoft’s .NET (Lau and Wang, 2007).
Các yếu tố cơ bản của một mô hình thành phần lý tưởng được trình bày bởi
Weinreich và Sametinger (2001). Ian Sommerville đã tổng hợp các yếu tố
của các mô hình trong hình 3. Đây là một biểu đồ biểu diễn các yếu tố của
một mô hình xác định các giao diện thành phần, thông tin mà bạn cần sử
dụng thành phần trong một chương trình, và một mô hình nên được triển
khai như thế nào:
1. Các giao diện(Interfaces): Các thành phần được xác định bằng
cách xác định giao diện của chúng. Mô hình thành phần quy định cụ thể
các giao diện nên được xác định như thế nào và các yếu tố như tên hoạt
động, tham số, và các trường hợp ngoại lệ nên được bao gồm trong việc
xác định giao diện. Mô hình cung nên xác định ngôn ngữ được sử dụng để
xác đinh các giao diện thành phần. Một số các mô hình thánh phần đòi hỏi
các giao diện cụ thể mà phải được xác đinh bằng một thành phần. Chúng
được sử dụng để tạo ra thành phần với cơ sở hạ tầng của mô hình thành
phần, cái mà cung cấp các dịch vụ tiêu chuẩn như an ninh và quản lý giao
dịch.
2. Sử dụng(Usage): Để cho các thành phần được phân phối và truy
cập từ xa, chúng cẩn có một cái tên duy nhất hoặc kết hợp vử lý với chúng.
Điều này phải được toàn cục duy nhất – ví dụ trong mô hình Enterprise
Java Beans một cái tên phân cấp được sinh ra với một gốc dựa trên một tên
miền internet. Các dịch vụ có một URL duy nhất (Uniform Resource
Identifier).
Thành phần meta-data là một dữ liệu về chính thành phần của nó,
chẳng hạn như thông tin về giao diện và các thuộc tính của nó. Meta-data là
quan trọng bởi vì nó cho phép người dùng của các thành phần tìm ra các
dịch vụ gì được cung cấp và yêu cầu. Việc thực thi mô hình thành phần
thông thường bao gồm những cách cụ thể ( như sử dụng một một giao diện

ảnh trong Java) để truy cập thành phần meta-data này.

Hình 3: các yếu tố cơ bản của mô hình thành
phần


Công nghệ phần mềm hướng thành phần

9/21

`
Các thành phần là các thực thể chung và khi triển khai, chúng phải được
cấu hình để phù hợp với hệ thống ứng dụng. Ví dụ, bạn có thể cấu hình
thành phần thu thập dữ liệu (hình 2) bằng cách xác định số lượng tối đa các
cảm biến trong một mảng cảm biến. Mô hình thành phần có thể xác định
các thành phần nhị phân có thể được tùy chỉnh như thế nào cho một môi
trường triển khai riêng.
3.Triển khai(Deployment): Mô hình thành phần bao gồm một đặc tả
của các thành phần nên được đóng gòi như thế nào cho việc triển khai như
là các thực thể độc lập và có thể thi hành được. Bởi vì các thành phần là
các thực thể độc lập, chúng phải được đóng gói với tất cả phần mềm hỗ trợ
mà nó không được cung cấp bởi cơ sở hạ tầng của thành phần, howacj
không được xác định trong một giao diện các yêu cầu. Thông tin triển khai
bao gồm thông tin về nội dung của một gòi và tổ chức nhị phân của nó.
Chắc chắn là các yêu cầu mới ló ra, các thành phần sẽ phải được thay đổi
hoặc bị thay thế. Mô hình thành phần có thể bao gồm các luật quản lý khi
sự thay thế thành phần được cho phép như thế nào. Cuối cùng, một mô
hình thành phần có thể xác định tài liệu thành phần mà nên được tạo ra.
Điều này được sử dụng để tìm kiếm thành phần và quyết định xem nó có
phù hợp không.

Hình 4: Các dịch vụ Middleware xác định mô hình thành phần
Đối với các thành phần mà được thực thị như các đơn vị chương trình chứ
không phải là các dịch vụ bên ngoài, mô hình thành phần đặt ra các dịch vụ
được cung cấp bởi middleware để hỗ trợ các thành phần thực thi.
Weinreich and Sametinger (2001) sử dụng sự tương tụ của một hệ điều
hành hệ thống để giải thích các mô hình thành phần. Một hệ điều hành
cung cấp một tập các các dịch vụ chung mà có thể được sử dụng bởi các
ứng dụng. Sự thực thi của mô hinh thành phần cung cấp các dịch vụ chia sẻ


Công nghệ phần mềm hướng thành phần

10/21

có thể so sánh được cho các thành phần. Hình 4 cho thấy một vài dịch vụ
mà có thể được cung cấp bởi một sự thực thi của một mô hình thành phần.
Các dịch vụ được cung cấp bằng sự thực thi của mô hình thành phần rơi
vào hai hoại sau:
1.Các dịch vụ nên tảng (Platform services), cho phép các thành phần
giao tiếp và tương thích trong môi trường phân phối. Đây là những dịch vụ
cơ bản mà phải có sẵn trong các hệ thống dựa trên thành phần.
2.Các dịch vụ hỗ trợ (Support services), là các dịch vụ phổ biến mà
có thể được đòi hỏi bởi nhiều thành phần khác nhau. Ví dụ, nhiều thành
phần yêu cầu xác thực để đảm bảo rằng người dùng các dịch vụ thành phần
được cho phép. Nó tạo nên ý nghĩa để cung cấp cho một tập tiêu chuẩn của
các dịch vụ của tầng middleware để sử dụng bởi tất cả các thành phần.
Điều này làm giảm giá thành của việc phát triển thành phần và tính không
tương thích của thành phần có thể tránh được.
Middleware thực thi các dịch vụ của thành phần và cung cấp các

giao diện cho các dịch vụ này.
3. Quy trình CBSE (Component-based software engineering- công nghệ
phần mềm hướng thành phần)
Quy trình CBSE là quy trình phần mềm có hỗ trợ công nghệ phần
mềm hướng thành phần. Các khả năng tái sử dụng và phạm vi hoạt động
của các quy trình khác liên quan đến sự phát triển và sử dụng các thành
phần có khả năng tái sử dụng. Hình 5 biểu diễn một cách tổng quan quy
trình trong CBSE.

Hình 5 Quy trình CBSE

Tại mức cao nhất, có 2 kiểu quy trình CBSE:
1. Phát triển để tái sử dụng (Development for reuse). Quy trình này
liên quan đến việc phát triển các thành phần và các dịch vụ sẽ được tái sử
dụng trong các ứng dụng khác, thường liên quan đến các thành phần hiện
có.


Công nghệ phần mềm hướng thành phần

11/21

2. Phát triển bằng việc tái sử dụng ( Development with reuse): Đây là
quy trình phát triển các ứng dụng mới sử dụng các thành phần và các dịch
vụ hiện có.
Các quy trình này có các mục tiêu khác nhau và do đó, bao hàm các hoạt
động khác nhau. Quá trình phát triển cho quá trình tái sử dụng, mục đích là
để sản xuất ra một hoặc nhiều thành phần tái sử dụng.Bạn biết các thành
phần mà bạn sẽ được làm việc cùng và bạn có thể truy cập vào mã nguồn
để tổng quát hóa chúng. Quá trình phát triển bằng việc tái sử dụng, bạn

không biết thành phần nào đã sẵn sàng, vì vậy bạn cần tìm ra các thành
phần này và thiết kế hệ thống của bạn để làm cho hiệu quả sử dụng chúng
là tốt nhất.
Các quy trình cơ bản của CBSE với tái sử dụng và cho tái sử dụng có các
quy trình hỗ trợ liên quan tới tiếp nhận thành phần (component
acquisition), quản lý thành phần (component management), xác nhận thành
phần (component certification):
1. Xác nhận thành phần là quá trình thu các thành phần để tái sử
dụng hoặc phát triển vào một thành phần có khả năng tái sử dụng. Nó có
thể liên quan đến việc truy cập vào các thành phần hoặc dịch vụ được phát
triển cục bộ hoặc tìm ra các thành phần này từ nguồn mở bên ngoài.
2. Quản lý thành phần liên quan đến quản lý các thành phần có khả
năng tái sử dụng của một công ty, đảm bảo rằng chúng được lập danh mục,
lưu trữ, tạo sẵn cho tái sử dụng đúng cách.
3. Xác nhận thành phần là quy trình kiểm tra một thành phần và xác
nhận là đáp ứng được các đặc tả kỹ thuật của nó.
Các thành phần được bảo vệ bởi một kiểu tổ chức có thể được lưu trữ trong
một kho chứa thành phần bao gồm cả các thành phần và thông tin về cách
sử dụng của chúng.
3.1 CBSE cho tái sử dụng( CBSE for reuse)
CBSE cho việc tái sử dụng là quá trình phát triển các thành phần có
khả năng tái sử dụng và làm chúng sẵn sàng cho việc tái sử dụng thông qua
một hệ thống quản lý thành phần.
Tầm nhìn của những người ủng hộ CBSE gần đây (Szyperski, 2002)
là một thị trường thành phần lớn mạnh sẽ phát triển. Sẽ có các nhà cung
cấp thành phần chuyên môn và các nhà cung cấp thành phần sẽ tổ chức
việc bán các thành phần từ các nhà phát triển khác. Những người phát triển
phần mềm sẽ mua các thành phần để gom vào trong một hệ thống và trả phí
cho các dịch vụ khi chúng được sử dụng. Tuy nhiên tầm nhìn này không
được thực hiện. Có rất ít nhà cung cấp thành phần và việc mua các thành

phần là không phổ biến. Tại thời điểm này, thị trường dịch vụ cũng không
phát triển mặc dù có những dự đoán cho rằng nó sẽ mở rộng đáng kể trong
vài năm tới đây.


Công nghệ phần mềm hướng thành phần

12/21

Do đó, CBSE cho tái sử dụng rất có thể sẽ diễn ra bên trong một tổ
chức nơi đã tạo một cam kết với công nghệ phần mềm hướng tái sử dụng.
Họ muốn khai thác tài sản phần mềm đã được phát triển trong các bộ phận
khác nhau của công ty. Tuy nhiên, các thành phần phát triển nội bộ thường
không có khả năng tái sử dụng mà không có sự thay đổi. Chúng thường bao
gổm các tính năng ứng dụng cụ thể và giao diện không có khả năng được
yêu cầu trong các chương trình khác mà thành phần được tái sử dụng.
Để tạo ra các thành phần có khả năng tái sử dụng, bạn phải thích ứng
và mở rộng ứng dụng thành phần cụ thể để tạo ra nhiều thành phần phổ
biến hơn và nhiều phiên bản có khả năng tái sử dụng hơn. Rõ ràng sự thích
ứng này có một giá trị ghép. Do đó bạn phải quyết định:
- Đầu tiên, có một thành phần có khả năng được tái sử dụng.
- Hai là, chi phí tiết kiệm từ tái sử dụng trong tương lai có biện minh
cho giá trị của việc tạo ra thành phần có khả năng tái sử dụng.
Để trả lời cho ý đầu tiên, bạn phải quyết định dù có hay không thành
phần thực thi một hoặc nhiều khái niệm trừu tượng về miền ổn định. Các
khái niệm trừu tượng về miền ổn định là các yếu tố cơ bản của các miền
ứng dụng thay đổi chậm. Ví dụ, trong một hệ thống ngân hàng, khái niệm
trừu tượng có thể bao gồm các tài khoản, các chủ tài khoản, và các báo cáo
tài chính. Trong hệ thống quản lý bệnh viện, khái niệm trừu tượng về miền
có thể bao gồm bệnh nhân, phương pháp điều trị và y tá. Các miền trừu

tượng này thỉnh thoảng được gọi là “đối tượng thương mại”. Nếu thành
phần là một hệ thống xử lý của một miền trừu tượng thường được sử dụng
hoặc một nhóm các đối tượng thương mại liên quan, thì nó có thể có khả
năng được tái sử dụng.
Để trả lời cho câu hỏi về hiệu quả chi phí, bạn phải đánh giá giá trị
của các thay đổi được yêu cầu để tạo ra khả năng tái sử dụng thành phần.
Giá trị này là giá trị của tài liệu thành phần, xác nhận thành phần, và tạo ra
thành phần phổ biến hơn. Những thay đổi mà bạn có thể tạo ra một thành
phần để làm cho nó có khả năng tái sử dụng nhiều hơn bao gồm:
- Loại bỏ các phương thức ứng dụng cụ thể;
- Thay đổi tên để làm cho chúng phổ biến hơn;
- Thêm các phương thức để cung cấp phạm vi chức năng hoàn chỉnh
hơn;
- Tạo bộ xử lý ngoại lệ phù hợp với tất cả các phương thức;
- Thêm một giao diện ‘cấu hình’ cho phép thành phần thích nghi
được với các tình huống sử dụng khác nhau;
- Kết hợp các thành phần được yêu cầu để tăng tính độc lập.
Vấn đề của bộ xử lý ngoại lệ là một vấn đề rất khó. Các thành phần
không nên xử lý loại trừ chính chúng, vì mỗi ứng dụng sẽ có yêu cầu cho
bộ xử lý ngoại lệ của chính chúng. Đúng hơn là, thành phần nên định nghĩa
những ngoại lệ nào có thể xảy ra và nên công bố những ngoại lệ này như
một bộ phận của giao diện. Tuy nhiên, trong thực tiễn có 2 vấn đề:


Công nghệ phần mềm hướng thành phần

13/21

1, Công khai tất cả các ngoại lệ dẫn đến việc các giao diện bị phồng
lên càng khó hiểu hơn. Điều này có thể bỏ đi những người dùng tiềm năng

của thành phần.
2, Việc vận hành thành phần có thể phụ thuộc vào bộ xử lý ngoại lệ
cục bộ, và thay đổi điều này có thể có những ảnh hưởng nghiêm trọng đối
với chức năng của thành phần.
Mili et al. (2002) thảo luận về cách thức ước tính chi phí tạo ra một
thành phần tái sử dụng và lợi nhuận từ đầu tư. Lợi ích của việc tái sử dụng
lớn hơn việc phát triển lại một thành phần không đơn giản là tăng năng
suất. Cũng có tăng chất lượng, vì một thành phần được tái sử dụng sẽ được
tin cậy hơn, và tăng thời gian đưa ra thị trường. Lợi nhuận được tăng lên do
sự triển khai phần mềm nhanh hơn. Mili et al. trình bày nhiều phương pháp
khác nhau để đánh giá sự tăng thêm này, như mô hình COCOMO trong
Chapter 23 (Boehm, et al., 2000). Tuy nhiên, thông số của các công thức
này rất khó đánh giá đúng, và các công thức phải được điều chỉnh phù hợp
với những trường hợp cục bộ, làm cho chúng khó sử dụng. tôi ngờ rằng
một phần nhỏ nhà quản lý dự án phần mềm dùng những mô hình này để
đánh giá những lợi nhuận do đầu tư mang lại từ khả năng tái sử dụng thành
phần.
Rõ ràng, có hay không một thành phần có khả năng tái sử dụng dựa
vào miền ứng dụng và chức năng của nó. Khi bạn thêm vào tính khái quát
cho thành phần, bạn đang tăng thêm khả năng tái sử dụng của nó. Tuy
nhiên, điều này thường có nghĩa là thành phần có nhiều phép tính hơn và
phức tạp hơn, làm cho thành phần khó hiểu và khó sử dụng hơn.
Do đó, có một sự cân đối không thể tránh khỏi giữa khả năng tái sử
dụng và khả năng sử dụng của một thành phần. Để tạo ra một thành phần
có khả năng tái sử dụng bạn phải cung cấp một tập các giao diện chung với
các hoạt động phục vụ cho tất cả các cách trong đó thành phần có thể được
sử dụng. Việc tạo ra các thành phần có khả năng sử dụng có nghĩa là cung
cấp giao diện đơn giản, tối thiểu mà dễ hiểu. Khả năng tái sử dụng thêm
tính phức tạp và vì thế giảm tính dễ hiểu của thành phần. Vì vậy khó khăn
hơn để quyết định tái sử dụng thành phần khi vào và như thế nào. Khi thiết

kế một thành phần có khả năng tái sử dụng, bạn phải tìm ra một cách dàn
xếp giữa tính phổ biến và dễ hiểu.
Nguồn tiềm năng của các thành phần đang tồn tại các hệ thống kế thừa.
Như tôi thảo luận trong Chapter 9, có các hệ thống thực hiện một chức
năng thương mại quan trọng nhưng được viết sử dụng công nghệ phần
mềm đã lỗi thời. Vì đây có thể là khó khăn để sử dụng chúng với các hệ
thống mới. Tuy nhiên nếu bạn chuyển các hệ thống cũ này thành các thành
phần, chức năng của chúng có thể được tái sử dụng trong các ứng dụng
mới.
Dĩ nhiên các hệ thống lỗi thời này thường không có định nghĩa rõ
ràng về yêu cầu và cung cấp giao diện. Để tạo ra khả năng tái sử dụng
thành phần này, bạn phải tạo ra một gói định nghĩa các giao diện thành


Công nghệ phần mềm hướng thành phần

14/21

phần. Các gói ẩn đi độ phức tạp của mã cơ bản và cung cấp một giao diện
cho các thành phần bên trong truy cập vào phần mềm được cung cấp. Mặc
dù gói này là một phần khá phức tạp của phần mềm, chi phí phát triển gói
thường ít hơn chi phí tái thực thi hệ thống cũ.
Một khi bạn đã phát triển và kiểm thử các thành phần tái sử dụng
hoặc dịch vụ, thành phần này sau đó phải được quản lý để tái sử dụng trong
tương lai. Cách quản lý liên quan đến việc quyết định phân loại thành phần
như thế nào để nó có thể được khai thác, tạo ra thành phần có sẵn hoặc là
trong một kho chứa hoặc là như một dịch vụ, duy trì thông tin về cách sử
dụng thành phần và theo dõi các phiên bản thành phần khác. Nếu thành
phần là mã nguồn mở, bạn có thể tạo sẵn nó trong một kho chung như là
nguồn giả (Sourceforge) . Nếu nó được dự định để sử dụng trong một công

ty, thì bạn có thể sử dụng hệ thống kho nội bộ.
Một công ty với một chương trình tái sử dụng có thể thực hiện vài
hình thức chứng nhận thành phần trước khi thành phần sẵn sàng cho tái sử
dụng. Chứng nhận có nghĩa là một vài người trừ nhà phát triển kiểm tra
chất lượng của thành phần. Họ kiểm tra thành phần và chứng thực rằng nó
đạt tới một chuẩn chất lượng có thể chấp nhận được, trước khi thành phần
sẵn sàng cho việc tái sử dụng. Tuy nhiên, nó có thể là một quy trình tốn
kém và nhiều công ty chỉ đơn giản là để thử nghiệm và kiểm tra chất lượng
các nhà phát triển thành phần.
3.2 CBSE với tái sử dụng

Hình 6 CBSE với tái sử dụng

Tái sử dụng thành công các thành phần yêu cầu một tiến trình phát
triển phù hợp với CBSE. Quy trình CBSE với tái sử dụng phải bao gồm các
hoạt động tìm kiếm và hợp nhất các thành phần có khả năng tái sử dụng.
Hình 6 chỉ ra các hoạt động chính bên trong tiến trình đó. Một vài hoạt
động bên trong tiến trình này, chẳng hạn như một khám phá ban đầu của
yêu cầu người dùng, được thực hiện giống như cách trong các quy trình
phần mềm. Tuy nhiên, sự khác nhau bản chất giữa CBSE với tái sử dụng và
các quy trình phần mềm cho phát triển phần mềm nguyên bản là:
1.Các yêu cầu của người dùng ban đầu được phát triển trong các nét
chính hơn là chi tiết, và các bên liên quan được khuyến khích khả năng linh


Công nghệ phần mềm hướng thành phần

15/21

hoạt trong xác định yêu cầu của họ. Yêu cầu quá giới hạn cụ thể số thành

phần có thể đáp ứng các yêu cầu này. Tuy nhiên, không giống như phát
triển gia tăng, bạn cần một tập các yêu cẩu hoàn chỉnh để có thể xác định
các thành phần như có thể tái sử dụng .
2. Các yêu cầu này được sàng lọc và sửa đổi trong tiến trình gần đây
phụ thuộc vào tính sẵn sàng của thành phần. Nếu các yêu cầu người dùng
không thể hoàn thành từ các thành phần có sẵn, bạn phải tìm ra các yêu cầu
liên quan có thể được hỗ trợ. Người dùng có thể sẵn sàng thay đổi suy nghĩ
của họ nếu suy nghĩ đó có nghĩa là hệ thống phân phối rẻ hơn hoặc nhanh
hơn.
3. Có một hoạt động tìm kiếm thêm thành phần và các hoạt động
thiết kế tinh tế sau khi các hệ thống kiến trúc được thiết kế. Một số thành
phần có khả năng sử dụng có thể trở thành không phù hợp hoặc không làm
việc hết sức với các thành phần được chọn khác. Mặc dù không chỉ ra trong
hình 6, điều này có nghĩa là các yêu cầu thêm thay đổi có thể là cần thiết.
4. Phát triển là một quy trình hợp nhất mà các thành phần đã tìm ra
được tích hợp. Điều này liên quan đến việc hợp nhất các thành phần với mô
hình cơ sở hạ tầng thành phần và, thường phát triển bộ điều phối điều hòa
giao diện của các thành phần xung khắc với nhau. Tất nhiên việc bổ sung
các chức năng có thể được yêu cầu một lần nữa và bên trên đó được cung
cấp bởi các thành phần được tái sử dụng.
Giai đoạn thiết kế kiến trúc là đặc biệt quan trọng. Jacobson et al.
(1997) đã thấy rằng định nghĩa một kiến trúc thiết thực là quyết định cho
tái sử dụng thành công. Trong suốt hoạt động thiết kế kiến trúc, bạn có thể
chọn một mẫu thành phần và nền tảng thực hiện. Tuy nhiên nhiều công ty
có một chuẩn phát triển hệ thống nền (e.g., .NET)vì thế mẫu thành phần
được quyết định trước. Như tôi đã thảo luận trong chương 6, bạn cũng thiết
lập tổ chức cấp cao của hệ thống tại giai đoạn này và đưa ra quyết định về
hệ thống phân phối và kiểm soát.
Một hoạt động là duy nhất cho quy trình CBSE là xác định thành phần ứng
viên hoặc dịch vụ cho việc tái sử dụng. Điều này liên quan đến một số các

hoạt động con, như đã chỉ ra trong Hình 17.8. Ban đầu, trọng tâm của bạn
nên được chú tâm vào tìm kiếm và lựa chọn. Bạn cần thuyết phục chính
mình rắdng có các thành phần sẵn sàng đáp ứng các yêu cầu của bạn. Hiển
nhiên, bạn nên làm một vài kiểm tra ban đầu thành phần phù hợp nhưng
việc kiểm tra chi tiết có thể không được yêu cầu. Trong giai đoạn sau, sau
khi kiến trúc hệ thống đã được thiết kế, bạn nên sử dụng thêm thời gian vào
việc xác nhận thành phần. Bạn cần chắc chắn rằng các thành phần được xác
định thực sự phù hợp với ứng dụng của bạn. Nếu không, bạn phải lặp lại
quy trình tìm kiếm và lựa chọn.


Công nghệ phần mềm hướng thành phần

16/21

Hình 7 Quá trình xác định thành phần

Bước đầu trong việc xác định các thành phần là tìm các thành phần
có sẵn cục bộ hoặc từ nhà cung cấp đáng tin cậy. Như tôi đã nói trong phần
trước, có tương đối ít nhà cung cấp thành phần vì vậy bạn nên tìm kiếm
thành phần có khả năng nhất được phát triển trong công ty của chính bạn.
Các công ty phát triển phần mềm có thể xây dựng cơ sở dữ liệu riêng của
họ về các thành phần có khả năng tái sử dụng mà không những rủi ro vốn
có trong việc sử dụng các thành phần từ nhà cung cấp bên ngoài. Ngoài ra,
bạn có thể quyết định tìm kiếm thư viện mã có sẵn trên Web, như
Sourceforge hoặc Google Code, để xem nếu mã nguồn của thành phần mà
bạn cần là sẵn có. Nếu bạn đang tìm kiếm các dịch vụ, thì có một số công
cụ tìm kiếm web chuyên dụng có sẵn có thể tìm ra các dịch vụ web công
cộng.
Khi quá trình tìm kiếm thành phần được xác định các thành phần có

thể thực hiện được, bạn phải lựa chọn các thành phần ứng viên cho hoạt
động đánh giá. Trong một vài trường hợp, điều này sẽ là một công việc đơn
giản. Các thành phần trong danh sách sẽ trực tiếp thực thi những yêu cầu
của người dùng và sẽ có các các thành phần không hoàn chỉnh phù hợp với
những yêu cầu này. Tuy nhiên, trong các trường hợp khác, quá trình lựa
chọn phức tạp hơn nhiều. sẽ không có một bản đồ rõ ràng về yêu cầu đối
với các thành phần và bạn có thể thấy rằng vài thành phần phải hợp nhất
với nhau để phù hợp với yêu cầu đặc biệt hoặc một nhóm các yêu cầu.
Vì thế, bạn phải quyết định kết cấu thành phần nào cung cấp vùng
phủ sóng tốt nhất của các yêu cầu.
Khi bạn đã lựa chọn thành phần cho sự bao hàm có thể trong một hệ
thống,sau đó bạn nên thông qua chúng để kiểm tra chúng vận hành như
được thông báo. Phạm vi thông qua yêu cầu phụ thuộc vào nguồn của các
thành phần. Nếu bạn đang sử dụng một thành phần được phát triển bởi một
nguồn đáng tin cậy và nổi tiếng, bạn có thể quyết định việc kiểm tra thành
phần là không cần thiết. Bạn thường kiểm tra thành phần khi nó kết hợp với
các thành phần khác. Mặt khác, nếu bạn đang sử dụng một thành phần từ
nguồn không rõ, bạn luôn luôn nên kiểm tra và kiểm thử thành phần trước
khi đưa nó vào trong hệ thống của bạn.
Việc xác nhận thành phần liên quan đến việc phát triển một bộ các
trường hợp thử nghiệm cho một thành phần (hoặc có khả năng thực hiện
mở rộng các trường hợp thử nghiệm được cung cấp với thành phần đó) và
việc phát triển khai thác thử nghiệm để chạy các thử nghiệm thành phần.
Vấn đề lớn với việc xác nhận thành phần là đặc điểm kỹ thuật thành phần
có thể không đủ chi tiết để cho phép bạn phát triển một bộ hoàn chỉnh các
kiểm thử phần mềm. Các thành phần thường được quy định một cách chính
thức, với các tài liệu chính thức chỉ là đặc tả kỹ thuật giao diện của chúng.
Điều này không bao gồm đầy đủ thông tin cho bạn để phát triển một bộ
hoàn chỉnh các kiểm thử mà sẽ thuyết phục bạn rằng giao diện thông báo
của thành phần là cái mà bạn yêu cầu.

Công nghệ phần mềm hướng thành phần

17/21

Cũng như thử nghiệm mà một thành phần để tái sử dụng làm những
gì mà bạn yêu cầu, bạn cũng có thể phải kiểm tra thành phần không bao
gồm bất cứ mã độc nào hoặc chức năng mà bạn không cần. Các nhà phát
triển chuyên nghiệp hiếm khi sử dụng các thành phần từ nguồn không đáng
tin, đặc biệt nếu các nguồn đó không cung cấp mã nguổn. Vì vậy vấn đề mã
độc thường không tăng. Tuy nhiên các thành phần có thể thường chứa các
hàm mà bạn không cần và bạn phải kiểm tra các chức năng này không ảnh
hưởng tới việc sử dụng thành phần của bạn.
Vấn đề với chức năng không cần thiết là nó có thể được kích hoạt
bởi chính thành phần đó. Điều này có thể làm chậm lại các thành phần,
khiến nó tạo ra các kết quả đáng ngạc nhiên hoặc, trong một số trường hợp,
tạo ra lỗi hệ thống nghiêm trọng.
4. Thành phần phức hợp
Thành phần phức hợp là quá trình tích hợp các thành phần lại với
nhau, và đặc biệt với cách viết “glue code” tạo ra một hệ thống hoặc các
thành phần khác, có nhiều cách khác nhau để soạn một thành phần, như
trong hình 17.10.

Hình 9: Các loại thành phần phức hợp
Từ trái qua phải là sơ đồ minh họa cho thành phần liên tục, thành
phần thứ bậc và thành phần phức hợp. Trong thảo luận dưới đây đưa ra
cách soạn hai thành phần(A và B) để tạo ra một thành phần mới:
1.Thành phần tuần tự (a) trong hình 9. Bạn tạo ra một thành phần
mới từ hai thành phần hiện có bằng cách gọi các thành phần hiện có trong

chuỗi. Bạn có thể coi thành phần tích hợp như là một thành phần tích hợp
của ‘provides interfaces’. Đó là, các dịch vụ được cung cấp bởi thành phần
A được gọi và kết quả trả về bởi A sau đó được sử dụng để gọi đến các
dịch vụ được cung cấp bởi thành phần B. Các thành phần không gọi nhau
trong thành phần phức hợp liên tiếp. Một số mã glue yêu cầu gọi gọi các
thành phần dịch vụ theo đúng thứ tự và để đảm bảo rằng các kết quả cung


Công nghệ phần mềm hướng thành phần

18/21

cấp bởi thành phần phức hợp A là tương thích với đầu vào dự kiến của
thành phần B. Giao diện ‘provides’ phụ thuộc vào các chức năng kết hợp
của thành phần phức hợp A và B nhưng sẽ không bình thường là thành
phần phức hợp của chúng ‘provides interfaces’. Đây là loại thành phần
phức hợp có thể sử dụng với thành phần là những yếu tố chương trình hoặc
các thành phần đó là dịch vụ.
2.Thành phần thứ bậc (b) trong hình 9. Đây là loại thành phần phức
hợp xảy ra khi một phần cuộc gọi trực tiếp vào các dịch vụ được cung cấp
bởi các thành phần khác. Các thành phần được gọi là cung cấp các dịch vụ
được yêu cầu của các thành phần gọi. Do đó, giao diện của các thành phần
được gọi là các ‘provides’ phải phù hợp với các 'yêu cầu' giao diện của
thành phần gọi. Thành phần A gọi trực tiếp vào thành phần B, và nếu giao
diện của chúng phù hợp, có thể không cần cho mã bổ sung. Tuy nhiên, nếu
có sự không phù hợp giữa giao diện ' requires ' của A và giao diện
‘provides’ của B, thì sau đó một số mã chuyển đổi có thể được yêu cầu.
Khi các dịch vụ không có giao diện ‘requires’, chế độ này của các thành
phần phức hợp không được sử dụng khi các thành phần được thực hiện như
dịch vụ web.

3.Thành phần phức hợp tương ứng với hình (c) trong Hình 9. Điều
này xảy ra khi hai hoặc nhiều thành phần được đặt lại với nhau (tăng) để
tạo ra một thành phần mới để kết hợp chức năng của chúng. Giao diện
‘provides’ và giao diện ‘requires’ của các thành phần mới là sự kết hợp của
các giao diện tương ứng trong thành phần A và B. Các thành phần được gọi
là riêng thông qua giao diện bên ngoài của các thành phần con. Các thành
phần A và B độc lập và không gọi nhau. Đây là loại thành phần phức hợp
có thể được sử dụng với các thành phần là các chương trình hoặc các thành
phần đó là dịch vụ.
Bạn có thể sử dụng tất cả các hình thức của thành phần tổng hợp khi
xây dựng hệ thống. Trong mọi trường hợp có thể sẽ phải viết mã kết nối
("glue code") để liên kết các thành phần đó lại với nhau. Ví dụ, ta có các
thành phần liên tục thì đầu ra của thành phần A thường trở thành đầu vào
của thành phần B. Bạn cần phải có các câu lệnh trung gian gọi thành phần
A, thu thập kết quả từ A, kết quả này sẽ là một tham số truyền vào khi gọi
thành phần B. Khi một thành phần này gọi một thành phần khác thì phải có
một thành phần trung gian để đảm bảo giao diện thành phần cung cấp
(Provider) tương thích với giao diện thành phần yêu cầu(Requires).
Khi bạn viết các thành phần mới đặc biệt cho các thành phần tổng
hợp, bạn cần thiết kế các giao diện của các thành phần để chúng tương
thích với các thành phần khác trong hệ thống. Từ đó bạn có thể dễ dàng tạo
ra các thành phần này trong một đơn vị. Tuy nhiên, khi các thành phần
được phát triển độc lập để tái sử dụng, bạn sẽ thường xuyên phải đối mặt
với sự không tương thích giao diện. Điều này có nghĩa rằng các giao diện
của các thành phần con mà bạn muốn tạo ra là không giống nhau. Ba loại
không tương thích có thể xảy ra :


Công nghệ phần mềm hướng thành phần

19/21

1.Tham số không tương thích Các hoạt động trên mỗi bên của giao
diện có cùng tên nhưng khác kiểu tham số hoặc số lượng các tham số
không giống nhau
2.Không tương thích hoạt động Tên của các hoạt động trong giao
diện thành phần cung cấp và giao diện thành phần yêu cầu là khác nhau.
3.Hoạt động không đầy đủ Giao diện của một thành phần cung cấp
là một tập hợp con của giao diện thành phần yêu cầu hoặc ngược lại.
Trong mọi trường hợp, để giải quyết vấn đề không tương thích này
bạn phải viết một bộ chuyển đổi để hòa hợp các giao diện của hai thành
phần được sử dụng lại. Một bộ chuyển đổi thành phần sẽ chuyển đổi một
giao diện này sang một giao diện khác. Hình thức chính xác của các bộ
chuyển đổi phụ thuộc vào loại của thành phần tổng hợp. Đôi khi, như trong
ví dụ tiếp theo, Bộ chuyển đổi sẽ chuyển đổi kết quả từ một thành phần
thành một hình thức mới mà nó có thể được sử dụng như một đầu vào của
thành phần khác. Trong trường hợp khác bộ chuyển đổi có thể được gọi
bởi thành phần A giống như một proxy cho thành phần B. Tình trạng này
xảy ra nếu A có nhu cầu gọi B nhưng giao diện thành phần 'yêu cầu' của
A không phù hợp với giao diện thành phần "cung cấp" của B. Bộ chuyển
đổi sẽ hòa hợp những khác biệt này bằng cách chuyển đổi các thông số đầu
vào của nó từ A vào các thông số đầu vào cần thiết cho B. sau đó nó gọi B
để cung cấp các dịch vụ theo yêu cầu của A.

Hình 10 Các thành phần không tương thích giao diện
Để minh họa cho bộ chuyển đổi, chúng ta xem xét hai thành phần
thể hiện trong hình 10 có giao diện không tương thích nhau. Đây có thể là
một phần của một hệ thống được sử dụng bởi các dịch vụ cấp cứu . Khi nhà
điều hành cấp cứu nhận một cuộc gọi, số điện thoại là đầu vào cho thành
phần addressFinder để xác định vị trí địa chỉ. Sau đó, sử dụng thành phần

Mapper để in bản đồ và gửi đến chiếc xe cứu thương . Trong thực tế, các
thành phần này sẽ có giao diện phức tạp hơn nhiều, nhưng để minh họa
khái niệm của một bộ chuyển đổi chúng tôi chỉ đưa ra ở mức đơn giản.


Công nghệ phần mềm hướng thành phần

20/21

Thành phần đầu tiên, addressFinder, tìm địa chỉ phù hợp với một số
điện thoại. Nó cũng có thể trở lại chủ sở hữu của người có quyền sở hữu
gắn liền với số điện thoại và các loại quyền sở hữu. Các thành phần
mapper có một mã bưu điện(ở Hoa Kỳ, một mã bưu điện với tiêu chuẩn bổ
sung bốn chữ số xác định quyền sở hữu) và hiển thị hoặc in bản đồ đường
phố của khu vực xung quanh mã ở một quy mô nhất định.
Các thành phần có thể biên soạn trong nguyên tắc bởi vì quyền sở
hữu bao gồm việc gửi dữ liệu hoặc mã bưu điện. Tuy nhiên, bạn phải viết
một thành phần được gọi là bộ chuyển đổi từ postCodeStripper sang
addressFinder và dải ra các post code. Việc gửi mã này sau đó được sử
dụng như một đầu vào để ánh xạ vào bản đồ đường phố với tỉ lệ 1/10.000.
Đoạn mã sau đây là một ví dụ về thành phần tuần tự, minh họa chuỗi các

cuộc gọi:
Hình 11: Bộ điều hợp liên kết thu thập dữ liệu và cảm biến.
Một trường hợp khác, trong đó một phần bộ chuyển đổi có thể được
sử dụng trong thành phần phức hợp phân cấp, nơi mà người ta mong muốn
thành phần đươc sử dụng khác nhưng có sự không tương thích giữa giao
diện ‘provides’ và giao diện ‘requires’ của các thành phần trong thành phần
phức hợp.
Các thảo luận trên các thành phần phức hợp giả sử bạn có thể nói từ các tài

liệu thành phần có hay không giao diện tương thích. Tất nhiên, định nghĩa
giao diện bao gồm các tên hoạt động và các loại tham số, vì vậy bạn có thể
làm cho một số đánh giá sự phù hợp của từ này. Tuy nhiên, bạn phụ thuộc
vào các tài liệu thành phần để quyết định liệu các giao diện ngữ nghĩa có
tương thích hay không.

5. Kết luận
Công nghệ phần mềm hướng thành phần là một phương pháp dựa
trên việc tái sử dụng để xác định, thực thi, và tạo các thành phần độc lập
vào trong hệ thống.


Công nghệ phần mềm hướng thành phần

21/21

Một thành phần là một đơn vị phần mềm có chức năng và phụ thuộc
được xác định hoàn toàn bởi một tập các giao diện công cộng. Các thành
phần có thể được phối hợp với các thành phần khác mà không cần biết sự
thực thi của chúng và có thể được triển khai như một đơn vị thực thi.
Các thành phần có thể được thực thi như các đơn vị chương trình mà
được bao gồm trong một hệ thống hoặc là các dịch vụ mở rộng được tham
khảo bên trong hệ thống.
Một mô hình thành phần xác định một tập các chuẩn của các thành
phần, bao gồm các chuẩn giao diện, các chuẩn sử dụng và các chuẩn triển
khai. Việc thực thi mô hình thành phần cung cấp một tập các dịch vụ chung
mà có thể được sử dụng bởi tất cả các thành phần.
Trong suốt quy trình công nghệ phần mềm hướng thành phần, bạn
phải xen kẽ các quy trình của các yêu cầu công nghệ và thiết kế hệ thống.
bạn phải đánh đổi các yêu cầu mong đợi với các dịch vụ mà có sẵn từ các

thành phần tái sử dụng đang tồn tại.
Sản phẩm thành phần là quy trình của việc “lắp ráp” các thành phần cùng
nhau để tạo ra hệ thống.
6. Tài liệu tham khảo
[1] Ian. Sommerville - Software Engineering 9th editor (Pearson 2011)