ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ VĂN THỊ HỒNG PHÚC NGHIÊN CỨU KỸ THUẬT KIỂM THỬ PHẦN MỀM
TRÊN CƠ SỞ MÔ HÌNH UML LUẬN VĂN THẠC SĨ


2.2 Vòng đời phát triển phần mềm trên cơ sở cấu phần 9
2.3 Các mô hình cấu phần và dịch vụ cấu phần 12
2.3.1 Mô hình cấu phần 12
2.3.2 Sự cài đặt mô hình cấu phần và các dịch vụ 16
2.4 UML trong phát triển phần mềm 19
2.4.1 Mục tiêu của UML 19
2.4.2 Vai trò, vị trí của các lược đồ UML trong vòng đời phần mềm 21
2.4.3 Các công cụ xây dựng UML 22
2.5 Lý thuyết kiểm thử 24
2.5.1 Tại sao kiểm thử là cần thiết? [2] 24
2.5.2 Nguyên nhân gây lỗi phần mềm 25
2.5.3 Vai trò của kiểm thử trong phát triển phần mềm 28
Chương 3: Kiểm thử trên cơ sở các mô hình UML 34
3.1. Các thành phần của cấu phần 34
3.2. UML và kiểm thử 35
3.3. Kiểm thử phần mềm trên cơ sở cấu phần 42
3.4. Các khía cạnh kiểm thử 46
3.3.1. Khía cạnh cấu trúc của kiểm thử 47
3.3.2. Khía cạnh hành vi của kiểm thử 48
3.5. Mô hình kiểm thử trong phần mềm cấu phần [5] 50
3.4.1 Mô hình tương tác 50
3.4.2 Mô hình hành vi 51
3.4.3 Cấu trúc điều khiển 52
3.4.4 Các quan hệ về tương tác dữ liệu 52
3.6. UML trong pha kiểm thử tích hợp 53
3.5.1 Mô hình áp dụng cho kiểm thử tích hợp phần mềm cấu phần 55
3.5.2. Các tiếp cận kiểm thử tích hợp trên cơ sở UML 58
Chương 4: Thực nghiệm kiểm thử phần mềm 64
4.1 Sử dụng cấu phần Text trong Java 64
4.2 Bài toán ( Phát biểu) 66

Hình 5: Cấu trúc một cầu phần
34
6
Hình 6: Quy trình kiểm thử cấu phần trong hệ thống
38
7
Hình 7: Lược đồ biểu diễn cấu trúc một ca kiểm thử
39

Hình 8: Lược đồ biểu diễn các use case quản lý giao dịch ATM
40
8
Hình 9: Mô hình biểu diễn cấu trúc của hồ sơ kiểm thử
47
9
Hình 10: Các khái niệm liên quan đến tình huống kiểm thử
48
10
Hình 11: Các khái niệm liên quan đến hành vi kiểm thử
49
11
Hình 12: Các khái niệm dữ liệu trong hồ sơ kiểm thử
49
12
Hình 13: Tập điều kiện kiểm tra phụ thuộc
57
13
Hình 14: Mô hình cộng tác mô tả hoạt động giao dịch của máy
ATM
59


DANH MỤC BẢNG

#
Tên danh mục bảng
Trang
Bảng 1
So sánh vòng đời phát triển phần mềm trên cơ sở cấu
phần với vòng đời phát triển phần mềm truyền thống.
11
Bảng 2
Các yếu tố cơ bản trong kiểm thử
32
Bảng 3
UML hỗ trợ các loại kiểm thử
35
THUẬT NGỮ SỬ DỤNG TRONG TÀI LIỆU

Thuật
ngữ
Từ gốc
Giải thích

COM
Component Object Model
Mô hình đối tượng cấu phần
CSLC
Component Software Life Cycle
Vòng đời phần mềm cấu phần
RTE
Real-time and embedded system
Hệ thống nhúng và thời gian
thực
IDL
Interface Definition Language
Ngôn ngữ định nghĩa giao diện
HTTP
HyperText Transfer Protocol
Giao thức truyền siêu văn bản
XML
eXtensible Markup Language
Ngôn ngữ đánh dấu mở rộng
IDE
Interactive development
environment
Môi trường phát triển tương tác
QoS
Quality of Service
Chất lượng dịch vụ
HĐH
Operating system
Hệ điều hành
CIG

Trước hết tôi xin gửi lời cảm ơn đặc biệt nhất tới PGS.TS Đặng Văn Đức viện
Công nghệ thông tin người đã định hướng đề tài và tận tình hướng dẫn chỉ bảo tôi
trong suốt quá trình thực hiện luận văn cao học này.
Tôi xin được gửi lời cảm ơn sâu sắc tới Trung tâm Đào tạo Sau đại học và các thầy
cô giáo trong Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hà Nội đã tận tình
giảng dạy và truyền đạt những kiến thức, những kinh nghiệm quý báu trong suốt 2
năm học Cao học.
Tôi xin bày tỏ lòng cảm ơn chân thành tới tất cả các bạn bè, các thầy cô giáo, các
đồng nghiệp Khoa Công nghệ thông tin, Trường Đại học Quốc Gia Hà Nội đã động
viên, tạo điều kiện cho tôi trong suốt thời gian thực hiện luận văn này.
Cuối cùng tôi xin dành một tình cảm biết ơn tới Bố, Mẹ, những người đã luôn luôn
ở bên cạnh tôi, động viên, chia sẻ cùng tôi trong suốt thời gian học cao học cũng như
quá trình thực hiện luận văn cao học.

Hà Nội, ngày 30 tháng 6 năm 2009
Văn Thị Hồng Phúc Hà Nội, ngày 30 tháng 6 năm 2009
Học viên Văn Thị Hồng Phúc
1
Chương 1: Giới thiệu
1.1. Giới thiệu nhiệm vụ chính của đề tài
Kiểm thử là một khâu không thể thiếu trong quá trình phát triển phần mềm.
Nhiều hệ thống phần mềm thất bại là do không tìm ra lỗi. Nguồn lực sử dụng
cho khâu kiểm thử là một yêu cầu khá lớn trong quá trình phát triển phần mềm.
Quá trình kiểm thử yêu cầu một số pha kết hợp gồm: kiểm thử đơn vị, kiểm
thử tích hợp, kiểm thử hệ thống, và kiểm thử chấp nhận.
Quy trình kiểm thử được xây dựng nhằm đạt các mục tiêu chính như sau:
 Xem xét các yêu cầu đưa ra bởi khách hàng, đối chiếu với sản phẩm
phần mềm được lập trình bởi lập trình viên.
 Phát hiện các sai sót hoặc lỗi trong phần mềm mà ở đó hành vi phần
mềm là không đúng, hoặc không tuân theo các đặc tả của nó.
Phương pháp hướng đối tượng (Object-Oriented) đã thể hiện rõ tính ưu việt

Nội dung luận văn này nhằm mục tiêu khảo sát các vấn đề cơ bản và kỹ thuật
phát triển phần mềm theo cấu phần. Đặc biệt luận văn tập trung vào kỹ thuật
kiểm thử phần mềm phát triển dựa theo cấu phần với mục đích hướng tới ứng
dụng thực tế tại Việt Nam.
1.2. Tình hình nghiên cứu trong và ngoài nước
Năm 1975 Freed Brooks, một nhà quản lý dự án IBM, viết cuốn The
Mythical Man-month. Bài luận ngắn trong trong cuốn sách này mô tả những khó
khăn khi phát triển phần mềm phức tạp, Brooks viết một chương với tiêu đề là
“No Silver Bullet” giải thích rằng các hệ thống phần mềm là phức tạp. Ông dự
đoán sẽ không có kỹ thuật nào là duy nhất – no silver bullet – mà nó có thể cải
thiện năng suất theo danh sách yêu cầu cho mọi hệ thống. Trong chương này,
Brooker trích dẫn ra các lý do gây nên “khủng hoảng phần mềm”, và khủng
hoảng này sẽ còn tiếp tục cho đến khi một kỹ thuật mới như công nghệ phần
mềm trên cơ sở cấu phần (CBSE – Component based software engineering) trở
nên có tính khoa học và nó thực sự dựa trên tính khoa học.
Và như thế, CBSE đã đưa ra được “Những bài học hay nhất” về sản phẩm
công nghệ phần mềm trong suốt 30 năm tiếp theo. Brooks trình bày 2 phương
pháp khả thi giúp giảm mức độ phức tạp của phần mềm đó là “Buy before
Build” và “Reuse before Buy”. Các khái niệm mấu chốt được đưa ra nhằm giúp
giảm được chi phí trong công nghệ phát triển phần mềm.
Trong hội nghị thảo luận năm 1968, NATO đã tham gia tranh luận về thuật
ngữ khủng hoảng phần mềm. Thêm nhiều thuật ngữ khó hiểu như kẽ hở phần
mềm, … các thuật ngữ này dần dần được làm rõ khi trong quá trình phát triển
công nghệ phần mềm. Theo David và Fraser phát biểu năm 1968, “ Kẽ hở được
phát hiện tại thời điểm khi mà hậu quả việc hỏng hóc phần mềm tăng theo mọi
mức độ nghiêm trọng”. Để phát triển phần mềm trên cơ sở cấu phần chúng ta
phải học cách xây dựng các cấu phần đó dựa vào các yêu cầu, hoặc dựa trên việc
thiết kế các module thành phần hay các thiết kế trực tiếp các cấu phần. Các
khách hàng đặt hàng (các cấu phần) và việc tích hợp các cấu phần cung cấp bởi
nhà sản xuất sẽ đảm bảo rằng nó đáp ứng được yêu cầu khách hàng với các

phân tích, thiết kế và kiểm thử.

4
Chương 2: Một số khái niệm cơ bản
Lập trình hướng cấu phần (COP – Component oriented programming) và
công nghệ phần mềm trên cơ sở cấu phần (CBSE – Component based software
engineering) đôi khi có thể hiểu là một. Tuy nhiên, CBSE là thuật ngữ rộng hơn,
và COP chỉ là một phần trong đó.

CBSE = COA + COD + COP + COM

Trong đó COA (component oriented analysis), COD (Component oriented
design) và COM (Component oriented management) thể hiện các thuật ngữ về
phân tích hướng cấu phần, thiết kế hướng cấu phần và quản lý hướng cấu phần.
Mục tiêu của CBSE là phát triển phần mềm một cách nhanh chóng, và giảm chi
phí bằng cách xây dựng các hệ thống thông qua việc thu thập các cấu phần có
sẵn. Thiết kế, phát triển, và duy trì các cấu phần nhằm mục đích sử dụng lại là
một quy trình rất phức tạp, với các yêu cầu ở mức cao không chỉ đáp ứng được
tính chức năng và mềm dẻo cấu phần mà còn đáp ứng việc phát triển phần mềm
một cách có tổ chức. CBSE bao gồm rất nhiều các nguyên tắc công nghệ phần
mềm và các kỹ thuật khác nhau.

Trong công nghệ phần mềm truyền thống, quy trình phát triển phần mềm bao
gồm các hoạt động hoặc các trạng thái tuần tự, cách đặt tên, phân tích, thiết kế,
ngôn ngữ lập trình, kiểm thử, và tích hợp. Trong CBSE, các giai đoạn phát triển
chính vẫn tuân thủ theo các bước thực hiện như quy trình phát triển truyền
thống, và bổ sung thêm bước tập hợp và lắp ghép các cấu phần. Ta có thể nhận

nghĩa là nó độc lập với các cấu phần khác – nó có rất nhiều sự phụ thuộc.

4. Cấu phần được cài đặt (Installed component): Là sự sao chép của
một thực thi cấu phần dưới hình thức cài đặt (hoặc triển khai). Một sự
thực thi cấu phần được triển khai bằng cách đăng ký nó với môi trường
khi chạy thật. Môi trường chạy thật định nghĩa khả năng của cấu phần
được cài đặt nhằm tạo một thể hiện khi thực hiện bước vận hành nó.

5. Đối tượng cấu phần (Component object): Một đối tượng cấu phần là một
thể hiện của cấu phần được cài đặt. Khái niệm này khá giống với khái niệm
trong lập trình hướng đối tượng, một đối tượng cấu phần trong lập trình hướng
cấu phần là một đối tượng có dữ liệu riêng và định nghĩa duy nhất, nó thực hiện
hành vi thực thi xác định. Một cấu phần cài đặt có thể có các đối tượng cấu
phần đa nhiệm hoặc đơn nhiệm.
2.1 Phần mềm sử dụng cấu phần
Để tìm hiểu, nghiên cứu về mục tiêu mà luận văn đã đề ra, trước tiên, ta đi
vào việc tìm hiểu các thuật ngữ cơ bản được sử dụng trong CBSE, ta đi từ các
khái niệm nhỏ nhất, đơn giản nhất về cấu phần.
Một phần tử phần mềm chứa chuỗi các lệnh cấp cao, các tính toán được thực
hiện bởi máy tính. Phần tử phần mềm là thực thi nếu: (1) máy tính trực tiếp thực
thi các lệnh hoặc (2) có một bộ thông dịch chạy trên máy tính dịch các câu lệnh
sang dạng máy thực thi được.
6
Mã nguồn phần mềm là tập các file máy có thể đọc được, chứa các câu lệnh
chương trình được viết ứng với một ngôn ngữ lập trình. Các câu lệnh này được
dịch thành các câu lệnh thực thi được hoặc nhờ vào bộ biên dịch hoặc bộ thông
dịch.

cấu phần phần mềm để các phần tử phần mềm tương tác trực tiếp với các phần
tử khác. Chuẩn giao diện khai báo một giao diện có thể chứa cái gì.
7
Cấu phần cung cấp một giao diện cung ứng nếu cấu phần đó chứa sự cài đặt
tất cả các thao tác được định nghĩa bởi giao diện. Một cấu phần cần một giao
diện yêu cầu, nếu cấu phần đó đòi hỏi một tương tác được định nghĩa trong giao
diện này và nó giả thiết rằng có phần tử phần mềm nào đó sẽ cung cấp giao diện
này. Một cấu phần không thể cung cấp một giao diện cung ứng, nếu thiếu một
trong số giao diện yêu cầu của nó. Vì vậy, lý tưởng nhất, một cấu phần cần được
triển khai với thông tin mô tả đặc tả tất cả các giao diện yêu cầu và giao diện
cung ứng của nó.
Các phần tử phần mềm tương tác với một cấu phần thông qua việc sử dụng
các giao diện được định nghĩa rõ ràng và được tài liệu hóa. Một chuẩn tương tác
định nghĩa các phần tử của một giao diện. Nếu cấu phần chỉ có thể thực hiện
chức năng của nó bằng cách tương tác với phần tử phần mềm khác, tất cả các
phụ thuộc bối cảnh phải được đặc tả tường minh trong tài liệu cấu phần. Chuẩn
tương tác bao gồm các tương tác trực tiếp và gián tiếp giữa các cấu phần.
Một cấu phần có thể có một phụ thuộc bối cảnh tường minh trên HĐH, một
cấu phần phần mềm, hoặc một phần tử phần mềm khác. Một chuẩn tương tác
đặc tả dạng các phụ thuộc bối cảnh tường minh mà cấu phần có thể có. Một
dạng khác của phụ thuộc bối cảnh tường minh xảy ra khi một cấu phần phải
chạy trên một máy tính với một xung nhịp xác định để đạt được hiệu năng mong
muốn. Nếu cấu phần phải tương tác với một thiết bị phần cứng, cấu phần đó sử
dụng các giao diện lập trình ứng dụng (APIs - Application Programming
Interfaces) của HĐH hoặc giao diện của cài đặt mô hình cấu phần. Trong cả hai
trường hợp, thông tin mô tả cấu phần phải định nghĩa rõ ràng phụ thuộc bối cảnh
tường minh này.

được đóng gói dạng nhị phân).
Trong quá trình triển khai, có thể khách hàng hoặc bên chứng nhận thứ ba sẽ
có yêu cầu đòi quyền truy cập mã nguồn. Khi đó, nhà sản xuất cấu phần sẽ quyết
định về việc triển khai mã nguồn của cấu phần đó.
Một chuẩn kết hợp định nghĩa cách thức soạn cấu phần để tạo ra một cấu trúc
lớn hơn, cách thức mà một nhà sản xuất thay thế cấu phần bằng cấu phần khác
theo cấu trúc đã có sẵn.
Thêm vào đó, với một mô tả giao diện, nhà sản xuất cấu phần cần cung cấp
tài liệu mô tả đầy đủ tới người dùng cấu phần tương lai, để người dùng có khả
năng gắn cấu phần đó vào trong một ứng dụng cụ thể. Bên chứng nhận thứ ba
cũng sẽ sử dụng tài liệu được cung cấp để kiểm chứng quy trình được sử dụng
phát triển cấu phần đó và đảm bảo rằng sản phẩm cuối cùng đáp ứng được đầy
đủ đặc tả. Nhà sản xuất cấu phần hoặc tổ chức chứng nhận thứ ba sẽ quyết định
dạng thích hợp nhất cho tài liệu, đó là lưu trữ nó cùng với cấu phần theo cả hai
dạng mã nguồn hoặc nhị phân, hay cung cấp độc lập. Điểm mạnh của phần mềm
phát triển trên cơ sở cấu phần được thể hiện ở:
 Quy tắc nghiệp vụ
 Quy trình nghiệp vụ
 Các yêu cầu chức năng
 Các yêu cầu phi chức năng
 Các chuỗi tình huống sử dụng
 Tài liệu thiết kế sử dụng các lược đồ UML và ngôn ngữ ràng buộc đối
tượng
9
 Các điều kiện trước
 Các điều kiện sau
 Các hợp đồng thiết kế

Điều này dẫn đến đòi hỏi đó là cần có một quy trình lưu trữ các cấu phần có
sẵn, đôi khi bạn cũng cần tạo một dự án con để xây dựng một cấu phần theo đặc
tả. Điều này có nghĩa là quy trình lưu trữ không chỉ nắm giữ các các cấu phần đã
10
xây dựng sẵn, mà còn kích hoạt quy trình xây dựng cấu phần mới. Lợi ích thực
sự của CBSE chỉ được nhận ra bằng cách kích hoạt song song giải pháp và sự
phát triển cấu phần, điều này đạt được thông qua việc lập kế hoạch và thiết kế.
Với các cấu phần không tìm thấy, quy trình lưu trữ phải cho phép khách hàng
đưa ra mong muốn để nhận được sự cung ứng khác.
Mỗi lần ta sử dụng một cấu phần cho dù cấu phần đó đã được đóng gói hay
đã được gắn vào sản phẩm, ta cũng cần một quy trình quản lý cấu hình cấu phần
đó. Bởi vì các phiên bản mới của một cấu phần có thể được cung ứng bất cứ lúc
nào, và người xây dựng giải pháp có thể muốn cải tiến nâng cấp, hay khách hàng
cần một quy trình thông báo cho họ khi các cấu phần cập nhật, lưu trữ. Người
xây dựng giải pháp có thể dễ dàng thay thế một cấu phần tồn tại bằng phiên bản
mới hơn. Điều này đạt được nếu người xây dựng giải pháp có xác nhận đăng ký
nhận thông báo khi có cấu phần phiên bản mới được lưu trữ.
Thêm một định nghĩa nữa ở đây để ta có thể phân biệt sự khác nhau giữa
vòng đơi phát triển phần mềm và vòng đời cấu phần đó là: Trong một vòng đời
phát triển phần mềm truyền thống, những người phát triển thường là người phân
tích, thiết kế và lập trình. Một dự án có một sự khởi đầu tốt, khi các yêu cầu trở
nên rõ ràng, và kết thúc tốt đẹp khi hệ thống phần mềm cuối cùng sẽ được
chuyển giao. Sản xuất cấu phần thì khác, người ta mất nhiều thời gian hơn để
nghiên cứu về các quy tắc nghiệp vụ, mô hình quy trình nghiệp vụ, phân tích và
thiết kế. Nhưng thời gian sử dụng để phát triển là ít hơn trong khi kiểm thử phải
thực hiện xuyên suốt. Để tìm hiểu một cách chi tiết về vòng đời cấu phần ta đi
đến định nghĩa sau:

Mô hình quy trình nghiệp vụ
Mô hình quy trình nghiệp vụ
2
Quản lý yêu cầu
Quản lý yêu cầu
3
Mô hình thiết kế hệ thống
Mô hình thiết kế hệ thống (cấu phần)
CBSE

Lấp đầy khoảng trống (gap fullfilled)
CBSE

Đặc tả cấu phần mới
CBSE

Đưa cấu phần vào sử dụng
CBSE

Lập danh sách thư tín (liên hệ)
4
Lựa chọn môi trường phát triển
tương tác (IDE - Interactive
development environment)
Lựa chọn môi tường phát triển tương
tác (IDE - Interactive development
environment)
5
Xây dựng cơ sở dữ liệu
Xây dựng cơ sở dữ liệu

12
2.3 Các mô hình cấu phần và dịch vụ cấu phần
Cấu phần ở mức ứng dụng có thể được sử dụng, nhưng khả năng sử dụng
lại cấu phần phần mềm mức ứng dụng là chưa đủ thích hợp. Thiếu sót của việc
sử dụng lại xảy ra bởi vì các ứng dụng là quá thô, chúng thiếu hỗ trợ kết hợp, và
hệ điều hành thiếu các chuẩn đặc tả miền. Các thiếu sót đó được thể hiện qua
một số đặc điểm:
Thiếu tính chất hạt nhân – Lack of granularity – Các ứng dụng là quá thô để
có thể cải thiện việc sử dụng lại. Các nhà phát triển ứng dụng thường được yêu
cầu thiết kế và cài đặt các chức năng chung chung mà bất kỳ ứng dụng nào cũng
có thể có. CBSE tìm ra các nhân tố chung đưa vào các các dịch vụ được cung
cấp bởi sự cài đặt mô hình cấu phần hoặc các cấu phần đã được đặt hàng và tích
hợp vào hạ tầng cấu phần. Tư tưởng trọng tâm của CBSE là phát triển các công
nghệ chi tiết hơn, các cấu phần được làm mịn dần và cho phép sử dụng lại ở
mức các ứng dụng thành phần tương tự như tại mức ứng dụng.
Thiếu sự hỗ kết hợp – lack of composition support –Trên thực tế, các hệ điều
hành đảm bảo rằng các ứng dụng thực thi hoàn toàn độc lập với nhau. Cơ chế
như giao tiếp quy trình nội bộ được nói đến là khả năng trao đổi dữ liệu giữa các
ứng dụng, nhưng các giao diện ứng dụng thường đặc tả kém và thiếu các chuẩn
kết hợp. Trong khi các ứng dụng triển khai trong hệ điều hành xác định và sử
dụng các dịch vụ của hệ điều hành đó. Chúng hiếm khi là đơn vị kết hợp.
Thiếu các chuẩn đặc tả miền – (Lack of domain - specific standards) – Các
dịch vụ của một hệ điều hành là quá chung chung không hỗ trợ được các miền
ứng dụng đặc tả. Ví dụ, một hệ thống đồng bộ cần các dịch vụ khác nhau và giao
diện lập trình ứng dụng (APIs-Application programming Interfaces) hơn là một
hệ thống điều khiển quy trình hoặc một ứng dụng viễn thông.
Mục tiêu của CBSE là phát triển các hệ thống phần mềm bằng cách tạo ra các

định nghĩa các thuộc tính cấu phần bắt buộc như định dạng mã, các chuẩn tài
liệu hoặc các giao diện độc lập của nhà sản xuất.
[3]Mô hình cấu phần định nghĩa một tập các chuẩn bao gồm: cài đặt cấu
phần, đặt tên, khả năng vận hành nội bộ, tuỳ biến, kết hợp, phát triển và triển
khai. Một mô hình cấu phần cũng định nghĩa chuẩn cho việc triển khai mô hình
liên kết các cấu, tập các đối tượng phần mềm thực thi được yêu cầu hỗ trợ thực
thi của các cấu phần tuân theo mô hình.
Một số các mô hình cấu phần đang được sử dụng hiện nay là mô hình thành
phần CORBA của OMG, COM+/DOM, và SUN -javabean, Enterprise
JavaBeans của Microsoft. Không nhất thiết khi phát triển cấu phần phải tuân
theo một chuẩn, nhưng tại một thời điểm không nên có quá nhiều chuẩn.
Các phần tử cơ bản của một mô hình cấu phần được Weinreich và
Sametinger liệt kê chi tiết - 2001. Hình dưới đây tổng hợp lại các phần tử trong
mô hình cấu phần, nó chỉ ra rằng các phần tử đã được phân loại theo các giao
diện cấu phần, các phần tử liên quan đến thông tin mà bạn cần sử dụng đến cấu
phần đó trong một chương trình và các phần tử tập trung vào việc triển khai cấu
phần.
14
Hình
1.
Các phần tử cơ bản của một mô hình cấu phần[1]
Giao diện Thông tin cung cấp Triển khai và sử dụng
Định nghĩa
giao diện

Một mô hình cấu phần có thể cũng có các chuẩn đặc trưng để mô tả các tính
năng đặc tả miền cần thiết trong các ứng dụng. Ví dụ, sự kết hợp các cấu phần
trong các miền với các hoạt động đang diễn ra đòi hỏi tiếp cận các mô hình
chuỗi được chuẩn hoá và các cơ chế đồng bộ. Một hệ xử lý phân tán mở đòi hỏi
các chuần lời gọi phương thức từ xa, và chuẩn bảo mật. Các ứng dụng nghiệp vụ
3 lớp cần các dịch vụ giao dịch được chuẩn hoá và cơ sở dữ liệu APIs. Cuối
cùng, một mô hình cấu phần với các tài liệu kết hợp (như OLE) cần đặc tả từng
15
phần, các quan hệ bao hàm và giao diện. Các mô hình cấu phần đặc tả miền gọi
tới các chức năng đặc biệt trong cài đặt mô hình cấu phần.
2.3.1.2 Giao diện, thỏa thuận và ngôn ngữ định nghĩa giao diện
Mục đích của các cấu phần là được sử dụng lại trong phần mềm. Hai hình
thức sử dụng lại là sử dụng lại hộp trắng và sử dụng lại hộp đen.
Sử dụng lại hộp trắng nghĩa là mã nguồn của cấu phần phần là có sẵn đầy đủ
và có thể nghiên cứu, sử dụng lại, lắp ghép hoặc chỉnh sửa. Sử dụng lại hộp
trắng thể hiện vai trò chính trong các nền tảng hướng đối tượng, đáp ứng sức
mạnh kế thừa cho các cài đặt phần mềm sử dụng lại. Nhược điểm của sử dụng
lại hộp trắng là các khách hàng sử dụng cấu phần có thể thay đổi mã nguồn cấu
phần đó nếu có sự thay đổi bên trong chương trình.
Sử dụng lại hộp đen dựa trên nguyên tắc che giấu thông tin. Người dùng cấu
phần chỉ có thể dựa trên vào các giao diện. Các giao diện này là sự mô tả hoặc
đặc tả hành vi cấu phần. Thông qua các giao diện, các lời gọi cấu phần có thể
được thay đổi tiếp tục thỏa mãn yêu cầu định nghĩa. Giao diện thể hiện một cách
tường minh và qua các công cụ chẳng hạn như bộ biên dịch, có thể kiểm chứng
tĩnh khả năng tương thích với các cấu phần client.
Một giao diện không phải là phần hợp thành của cấu phần, mà các phần hợp
thành cấu phần là các dịch vụ chẳng hạn như một thoả thuận giữa một cấu phần

vào đó, để các cài đặt mô hình cấu phần được tường minh, các cấu phần nhỏ
được lắp ghép vào xây dựng ứng dụng. Các kết nối internet nhanh hỗ trợ người
dùng tải các cấu phần đã đóng gói và tài liệu đi kèm để phát triển các hệ thống
phần mềm.
Một mô hình cấu phần mô tả cách mà các cấu phần được đóng gói, bởi vậy
chúng có thể được triển khai độc lập. Một cấu phần được triển khai nghĩa là nó
được cài đặt và cấu hình trong một hạ tầng cấu phần. Cấu phần được đóng gói
thường gồm mã chương trình, dữ liệu cấu hình, các cấu phần khác và các tài
nguyên đi kèm. Một mô tả triển khai cung cấp thông tin bên trong của gói (hoặc
các gói liên quan) và các thông tin khác cần thiết cho quy trình triển khai. Chuẩn
triển khai đặc tả cấu trúc và ngữ nghĩa cho các mô tả triển khai và nó quy định
định dạng các gói. Thêm vào nữa, mô hình cấu phần có thể định nghĩa các quy
trình triển khai bao gồm cả việc đăng ký cấu phần.
2.3.2 Sự cài đặt mô hình cấu phần và các dịch vụ
Nếu một cấu phần thực hiện một công việc cụ thể và cung cấp một giao diện
thì bên gọi có thể sử dụng cấu phần đó nếu tuân theo các đặc tả của giao diện
cấu phần. Các đặc tả cấu phần bao gồm sự định nghĩa chặt chẽ về cú pháp các
phương thức, cũng như mô tả về ngữ nghĩa của giao diện. Các tiếp cận hiện tại ở
mức đăng ký là sử dụng các ngôn ngữ đặc tả giao diện - IDLs cho việc mô tả các
giao diện. IDLs được định nghĩa bởi CORBA, COM và COM+ là các ví dụ điển
hình. Việc cài đặt mô hình cấu phần được thiết kế cho tập các phần tử phần mềm
hỗ trợ thực hiện các cấu phần trong một mô hình cấu phần. Một mô hình cấu
phần có thể được nhúng trong một HĐH nhưng nó sẽ chỉ khiến HĐH trở nên
phức tạp thêm, và hạn chế tính ứng dụng của mô hình cấu phần. Việc cài đặt mô
hình cấu phần tiêu biểu cho một lớp mỏng thực thi ngay trên HĐH. Các HĐH đa
17
nhiệm có thể di chuyển lớp này để đảm bảo khả năng ứng dụng tối đa của mô

(OMG – Object management group), một tổ chức phi lợi nhuận với khoảng 800
công nhân có kỹ năng và tay nghề. Trọng tâm của mô hình này là kiến trúc
CORBA, một chuẩn vận hành cho các ứng dụng trên cơ sở đối tượng phân tán
hỗ trợ các ngôn ngữ cài đặt khác nhau.
Các mô hình cấu phần nổi tiếng khác như COM của Microsoft và JavaBean của
Sun định nghĩa các dịch vụ giống nhau có ích trong các hệ thống đa miền. Tất cả
18
các nhà cung ứng cài đặt mô hình cấu phần cũng đang phát triển các tương tác
đặc tả miền và các chuẩn kết hợp.

Hình
2.
Chuẩn đặc tả miền [3]
Đặc tả miền
Mô hình cấu phần chung + Các dịch vụ
Các hạ tầng ngang +
Các dịch vụ
Các hạ tầng dọc +
Các dịch vụ
Tương tác
siêu dữ liệu
Quản lý hệ thống các
tài liệu thống nhất
Đồng bộ
Thông tin liên lạc
Tự động hóa quy trình
Tài chính