Xây dựng ngôn ngữ mẫu cho lập trình dựa trên thành phần

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ






NGUYỄN HẢI BÌNH





XÂY DỰNG NGÔN NGỮ MẪU CHO LẬP
TRÌNH DỰA TRÊN THÀNH PHẦN









LUẬN VĂN THẠC SĨ

Hà Nội – 2010



MỤC LỤC


Trang

MỞ ĐẦU 1
Chương 1. Khái quát về phát triển hệ thống dựa trên thành phần 2
1.1 Tiến trình công nghệ phần mềm dựa trên thành phần 2
1.2 Phát triển hệ thống dựa trên thành phần 4
1.2.1 Định phẩm, thích ứng và hợp thành thành phần 5
1.2.2 Chế tạo thành phần 8
1.2.3 Phân tích và thiết kế cho dùng lại 8

1.2.4 Phân loại và tìm kiếm thành phần 9
1.3 Mô hình vòng đời tiến trình dựa trên thành phần 11
Chương 2. Mô hình thành phần 16
2.1 Cơ sở cho mô hình thành phần 16
2.2 Thiết kế 22
2.3 Giao diện và hợp đồng 24
2.4 Thành phần 28
Chương 3. Ngôn ngữ mẫu đặc tả thành phần 31
3.1 Ví dụ hệ thống ParcelCall 31
3.2 Đặc tả giao diện 32
3.2.1 Giao diện sơ cấp 32
3.2.2 Kết hợp và thừa kế giao diện 33
3.3 Đặc tả hợp đồng 34
3.3.1 Sự đặc tả của một phương thức 34
3.3.2 Kết hợp, làm mịn và thừa kế hợp đồng 36
3.4 Đặc tả thành phần 38
3.4.1 Ngữ nghĩa của thành phần 38
3.4.2 Sự làm mịn, che dấu giao diện và kết hợp các thành phần. 42
Chương 4. Ví dụ về đặc tả thành phần 45
4.1 Khái quát về hệ thống 45
4.2 Phân tích ca sử dụng và đặc tả thành phần 47
KẾT LUẬN 54
TÀI LIỆU THAM KHẢO 55
1

MỞ ĐẦU

Một ý tưởng là lợi dụng và sử dụng lại các thành phần để xây dựng và để bảo
trì các hệ thống phần mềm hình thành từ “lập trình cấu trúc” trong nhưng năm
70. Đó là một luận cứ mạnh để phát triển các phương pháp và các ngôn ngữ

hướng đối tượng trong những năm 80, và ngày nay với sự phát triển các hệ
thống lớn đã khiến chúng ta quay lại ý tưởng này và biến nó thành hiện thực.
Kỹ thuật hướng đối tượng và kỹ thuật dựa trên thành phần đã trở thành phổ
biến và được sử dụng rộng rãi trong mô hình hóa và thiết kế cho hệ thống phần
mềm phức tạp. Chúng cung cấp khả năng hỗ trợ cho việc phân rã một ứng dụng
thành các đối tượng và các thành phần, những thứ có thể sử dụng lại và mở rộng
những thiết kế dựa trên những thành phần đã tồn tại. Sự phân tích và kiểm
chứng những hệ thống như vậy sẽ là dễ dàng bởi tính kết hợp trong kiến trúc
thành phần.
Một số minh chứng tiêu biểu cho kỹ thuật hướng đối tượng và kỹ thuật dựa
trên thành phần là CORBA, EJB, J2EE, COM và .NET. Bên cạnh đó những
ngôn ngữ mô hình hóa hình thức và bán hình thức như UML, JML và BIP đã trở
thành phổ biến với việc hỗ trợ phát triển hệ thống dựa trên mô hình. Tuy nhiên
những mô hình này hoặc là không hỗ trợ mức trừu tượng hóa hoặc thiếu ký hiệu
ngữ nghĩa, là thứ có thể được sử dụng để tích hợp với ngôn ngữ lập trình khác,
và đến bây giờ chúng vẫn chưa cung cấp đủ sự hỗ trợ cho việc mô hình hóa và
phân tích chất lượng tổng thể những dịch vụ của hệ thống được phát triển từ
những thành phần.
Chúng ta cần tìm kiếm một kỹ thuật mô hình hóa, có thể hỗ trợ việc đặc tả hệ
thống thành phần ở mức trừu tượng hóa cao, và có thể cung cấp một nền tảng cơ
sở để phát triển một ngôn ngữ mẫu có khả năng tích hợp vào các ngôn ngữ lập
trình khác nhau để hỗ trợ cho việc lập trình dựa trên thành phần.
Với mục đích đó, luận văn tập trung đi vào tìm hiểu việc thiết lập mô hình
toán học cho thành phần, đưa ra những định nghĩa hình thức cho giao diện, hợp
đồng, thành phần, và cả những vấn đề liên quan đến chúng như làm mịn, thừa kế,
kết hợp. Luận văn cũng đề xuất cách biểu diễn giao diện, hợp đồng và thành
phần dưới dạng ngôn ngữ đặc tả, và làm rõ những vấn đề được trình bày thông
qua việc xem xét một ví dụ về hệ thống hỗ trợ bán hàng trong siêu thị.

2

CHƯƠNG 1. KHÁI QUÁT VỀ PHÁT TRIỂN HỆ THỐNG DỰA
TRÊN THÀNH PHẦN

1.1 Tiến trình công nghệ phần mềm dựa trên thành phần
Công nghệ phần mềm dựa trên thành phần (CBSE – Component Based
Software Engineering) là một tiến trình nhấn mạnh tới thiết kế và xây dựng hệ
thống dựa trên máy tính bằng việc dùng các “thành phần” phần mềm dùng lại
được.
Về bề ngoài, CBSE dường như hoàn toàn tương tự với công nghệ phần mềm
hướng đối tượng. Tiến trình này bắt đầu khi tổ phần mềm thiết lập yêu cầu cho
hệ thống được xây dựng bằng việc dùng các kĩ thuật thu thập yêu cầu, sau đó
thiết kế kiến trúc được thiết lập nhưng thay vì đi ngay vào các nhiệm vụ thiết kế
chi tiết, thì lại xem xét các yêu cầu để xác định những gì trực tiếp chịu trách
nhiệm cho việc hợp thành, thay vì xây dựng mới. Tức là, tổ phần mềm đưa ra
những câu hỏi sau cho từng yêu cầu hệ thống:
 Các thành phần đã được cung cấp (COTS - commercial off the shelf) có
sẵn cho việc thực hiện yêu cầu hay không?
 Các thành phần dùng lại được phát triển trước đây có sẵn để thực hiện yêu
cầu hay không?
 Giao diện cho các thành phần có sẵn có tương hợp với kiến trúc của hệ
thống cần được xây dựng hay không?
Tiến trình CBSE phải được đặc trưng theo cách không chỉ nhận diện ra các
thành phần ứng cử viên mà còn định lượng từng giao diện của các thành phần,
thích ứng các thành phần để loại bỏ sự không tương thích với kiến trúc, lắp ráp
các thành phần vào trong một kiểu cách kiến trúc đã được lựa chọn, và cập nhật
các thành phần theo yêu cầu thay đổi của hệ thống.
Mô hình tiến trình cho công nghệ phần mềm dựa trên thành phần nhấn mạnh
vào các việc song song mà theo đó công nghệ miền được sử dụng đồng thời với
việc phát triển dựa trên thành phần [1, 3]. Nội dung của công nghệ miền là xác

định, xây dựng, phân loại và phát hiện một tập các thành phần phần mềm có khả
năng ứng dụng vào việc phát triển phần mềm hiện tại và tương lai trong miền
ứng dụng đặc biệt. Mục tiêu tổng thể là thiết lập những cơ chế làm cho người kĩ
sư phần mềm chia sẻ những thành phần này, dùng lại chúng trong khi làm việc
với hệ thống mới và hệ thống hiện có.
3

Hình 1.1 minh họa cho mô hình tiến trình CBSE điển hình. Công nghệ miền
tạo ra mô hình của miền ứng dụng được dùng làm cơ sở cho việc phân tích yêu
cầu người dùng trong luồng công nghệ phần mềm, và sau khi các thành phần
dùng lại đã được mua, được chọn từ thư viện hiện có, hay được xây dựng (như
một phần việc của công nghệ miền), chúng được trở thành công cụ đã sẵn sàng
cho người kĩ sư phần mềm trong việc phát triển hệ thống dựa trên thành phần.

Hình 1.1 Mô hình tiến trình hỗ trợ CBSE
Các bước trong tiến trình tiếp cận tổng thể tới việc phân tích miền được xác
định là:
 Định nghĩa miền được khảo sát.
 Phân loại các yếu tố được trích ra từ miền.
 Thu thập mẫu đại diện của các ứng dụng trong miền.
 Phân tích từng ứng dụng trong mẫu.
 Phát triển mô hình phân tích cho các mẫu.
4

Điều quan trọng cần lưu ý là việc phân tích miền được áp dụng cho bất kỳ
mô thức công nghệ phần mềm nào và có thể được áp dụng tốt cho cả việc phát
triển hướng đối tượng.
Prieto-Diaz mở rộng bước phân tích miền thứ hai trong công nghệ miền nêu
trên [1], và gợi ý cách tiếp cận tám bước tới việc xác định và phân loại các thành
phần dùng lại như sau:

(1) Lựa các chức năng hay sự vật đặc thù.
(2) Trừu tượng hoá chức năng hay sự vật.
(3) Xác định phân loại.
(4) Định danh các tính năng chung.
(5) Định danh các quan hệ đặc biệt.
(6) Trừu tượng hoá các quan hệ.
(7) Suy dẫn ra mô hình chức năng.
(8) Định nghĩa ngôn ngữ miền.
Đôi khi khó xác định được rằng liệu với một thành phần dùng lại tiềm năng
nào đó trong thực tế có áp dụng được cho một tình huống đặc biệt hay không.
Để tiến hành việc xác định này, cần phải định nghĩa ra một tập các đặc trưng
miền được dùng chung cho mọi phần mềm bên trong một miền. Đặc trưng miền
định nghĩa ra thuộc tính chung nào đó cho mọi sản phẩm tồn tại trong miền đó,
chẳng hạn, các đặc trưng chung có thể là tầm quan trọng của tính an toàn, tính
tin cậy, ngôn ngữ lập trình, tương tranh trong xử lí, và nhiều điều khác nữa.
1.2 Phát triển hệ thống dựa trên thành phần
Phát triển dựa trên thành phần là hoạt động CBSE xuất hiện song song với
công nghệ miền. Bằng việc dùng các phương pháp phân tích và thiết kế kiến trúc,
tổ phần mềm làm mịn kiến trúc thích hợp cho mô hình phân tích đã được tạo ra
cho ứng dụng được xây dựng.
Một khi kiến trúc đã được thiết lập, nó phải đưa các thành phần vào. Các
thành phần này là có sẵn từ thư viện dùng lại hoặc được chế tạo mới để đáp ứng
nhu cầu riêng biệt này. Do đó, luồng nhiệm vụ cho việc phát triển hệ thống dựa
trên thành phần có hai việc song song như ở hình 1.1. Khi các thành phần dùng
lại được là có sẵn cho việc tích hợp tiềm năng vào trong kiến trúc, thì chúng
phải được định tính và thích nghi. Khi thành phần mới cần tới, thì chúng phải
5

được chế tạo. Sau đó chúng được tích hợp vào trong kiến trúc và được kiểm thử
kĩ càng.

1.2.1 Định phẩm, thích ứng và hợp thành thành phần
Như ta đã thấy, công nghệ miền cung cấp thư viện các thành phần dùng lại
được cần cho công nghệ phần mềm dựa trên thành phần. Một số trong những
thành phần dùng lại được này được phát triển bởi đội ngũ sở tại, số khác có thể
được trích từ những ứng dụng đã có, và số khác nữa thì có thể kiếm được từ bên
thứ ba.
Tuy nhiên sự tồn tại của các thành phần dùng lại được không đảm bảo rằng
các thành phần này có thể được tích hợp một cách dễ dàng hay hiệu quả vào
kiến trúc được chọn cho ứng dụng mới. Chính bởi lí do này mà trình tự các hoạt
động phát triển dựa trên thành phần được áp dụng khi một thành phần được đề
nghị sử dụng.
Định phẩm thành phần: Định phẩm thành phần đảm bảo rằng một thành
phần ứng cử viên sẽ thực hiện chức năng được yêu cầu, sẽ “khớp” đúng vào
phong cách kiến trúc đã xác định cho hệ thống, và sẽ phải có các đặc trưng
phẩm chất (như hiệu năng, độ tin cậy, tính sẵn sàng) cần cho ứng dụng.
Mô tả giao diện cung cấp thông tin có ích về thao tác và sử dụng thành phần
phần mềm, nhưng nó không cung cấp tất cả các thông tin cần để xác định xem
một thành phần được đề nghị trong thực tế có dùng lại được một cách có hiệu
quả trong ứng dụng mới hay không. Dưới đây là một số nhân tố được xem xét
khi định phẩm thành phần:
 Giao diện lập trình ứng dụng (API).
 Các công cụ phát triển và tích hợp được thành phần cần tới.
 Các yêu cầu khi chạy, kể cả việc dùng tài nguyên (như bộ nhớ hay lưu
trữ), thời gian hay tốc độ, và giao thức mạng.
 Tính năng an toàn, kể cả kiểm soát truy nhập và giao thức xác minh.
 Các giả thiết thiết kế nhúng.
 Giải quyết các trường hợp ngoại lệ.
Thích ứng thành phần: Trong trường hợp lí tưởng, công nghệ miền tạo ra
một thư viện các thành phần mà có thể dễ dàng được tích hợp vào kiến trúc ứng
dụng. Điều ngụ ý “dễ tích hợp” là ở chỗ:

6

 Các phưong pháp nhất quán về quản lý tài nguyên đã được thực hiện
cho mọi thành phần trong thư viện.
 Các hoạt động chung như quản lí dữ liệu đã có cho mọi thành phần.
 Giao diện bên trong kiến trúc và với môi trường bên ngoài đã được
thực hiện theo cách nhất quán.
Trong thực tế, ngay sau khi thành phần đã được định phẩm để dùng bên trong
một kiến trúc ứng dụng, thì nó có thể bộc lộ ra những xung đột không tương
thích với một hay nhiều vùng phải được chú ý. Để làm giảm bớt những xung
khắc này, một kĩ thuật thích ứng được gọi là bọc gói thành phần [1, 3] thường
được sử dụng. Khi tổ phần mềm đã có quyền truy nhập hoàn toàn vào thiết kế
bên trong và mã cho thành phần (thường không phải là trường hợp khi thành
phần COTS được dùng) thì việc bọc gói hộp trắng sẽ được áp dụng. Giống như
phần tương ứng của nó trong kiểm thử phần mềm, bọc gói hộp trắng xem xét
các chi tiết xử lí bên trong của thành phần này và làm những thay đổi mức mã
để loại bỏ các xung khắc. Bọc gói hộp xám được áp dụng khi thư viện thành
phần được cung cấp một một ngôn ngữ mở rộng thành phần hay API có khả
năng loại bỏ hay che mặt nạ cho các xung khắc. Bọc gói hộp đen đòi hỏi đưa vào
tiền và hậu xử lí tại giao diện thành phần để loại bỏ hay làm mặt nạ cho các
xung khắc. Tổ phần mềm phải xác định xem liệu nỗ lực được yêu cầu bao gói
thích hợp thành phần có thể được thực hiện không hay là thành phần chuyên biệt
hoá (được thiết kế để khử bỏ xung khắc gặp phải) nên được chế tạo ra.
Hợp thành thành phần: Nhiệm vụ hợp thành thành phần là lắp ráp các
thành phần đủ phẩm chất, đã thích ứng hay đã chế tạo vào kiến trúc đã thiết lập
cho ứng dụng. Để thực hiện điều này, phải thiết lập một kết cấu nền để gắn các
thành phần thành một hệ thống vận hành. Kết cấu nền này (thường là thư viện
các thành phần đã khu biệt hoá) đưa ra một mô hình cho việc điều phối các
thành phần lẫn nhau và thực hiện các nhiệm vụ chung.
Trong số nhiều cơ chế để tạo ra một kết cấu nền hiệu quả thì tập bốn “chất

liệu kiến trúc” cần có để đạt tới việc hợp thành thành phần là:
 Mô hình trao đổi dữ liệu. Cơ chế để người dùng và ứng dụng có khả
năng tương tác và truyền dữ liệu (như kéo và thả, cắt và dán) nên được
định nghĩa cho mọi thành phần dùng lại. Cơ chế trao đổi dữ liệu này
không chỉ cho phép việc truyền dữ liệu người - phần mềm và thành
phần - thành phần mà còn truyền giữa các tài nguyên hệ thống (như
kéo một tệp sang biểu tượng máy in để in ra).
7

 Tự động hoá. Nhiều loại công cụ, macro và script nên được cài đặt để
làm thuận tiện cho tương tác giữa các thành phần dùng lại.
 Lưu trữ có cấu trúc. Dữ liệu không thuần nhất (như dữ liệu đồ hoạ,
tiếng nói, video, văn bản và số) chứa trong “tài liệu hợp thành” nên
được tổ chức và truy nhập như một cấu trúc riêng lẻ, thay vì một tuyển
tập các tệp tách biệt. Dữ liệu có cấu trúc duy trì một mô tả cho các cấu
trúc lồng nhau mà ứng dụng có thể tự do uốn nắn để định vị, tạo ra hay
sửa đổi từng nội dung dữ liệu.
 Mô hình đối tượng nền. Mô hình đối tượng đảm bảo rằng các thành
phần được phát triển trong các ngôn ngữ lập trình khác nhau nằm ở các
nền khác nhau có thể liên tác được. Tức là, các đối tượng phải có khả
năng trao đổi qua mạng. Để làm được điều này, mô hình đối tượng
định nghĩa ra một chuẩn cho tính liên tác thành phần.
Do tác động tiềm năng của việc dùng lại và vai trò của CBSE đối với nền
công nghiệp phần mềm là cực kì lớn, nên một số công ty chính và các liên đoàn
công nghiệp đã đề nghị các chuẩn cho phần mềm thành phần [1], bao gồm:
 OMG/CORBA. Nhóm quản lí đối tượng Object Management Group
(OMG) đã công bố kiến trúc trung gian yêu cầu đối tượng chung
(CORBA - common object request broker architectures). Một đối
tượng trung gian yêu cầu sự vật (ORB) cung cấp nhiều thứ về các dịch
vụ làm cho các thành phần dùng lại (đối tượng) có khả năng trao đổi

với các thành phần khác, bất kể tới vị trí của chúng trong hệ thống. Khi
các thành phần được xây dựng có dùng chuẩn OMG/CORBA, thì việc
tích hợp các thành phần đó bên trong hệ thống được đảm bảo nếu có
một ngôn ngữ định nghĩa giao diện (IDL) được tạo ra cho mọi thành
phần. Bằng việc dùng mô hình client/server, các đối tượng bên trong
ứng dụng khách có thể yêu cầu một hay nhiều dịch vụ từ nguồn phục
vụ ORB. Các yêu cầu được thực hiện qua một IDL hay theo cách động
vào lúc chạy, và một kho giao diện chứa tất cả các thông tin cần thiết,
dịch vụ yêu cầu và dịch vụ đáp ứng.
 Microsoft COM. Microsoft đã phát triển một mô hình đối tượng thành
phần (COM – component object model) cung cấp đặc tả cho việc dùng
các thành phần do nhiều nhà sản xuất tạo ra trong một ứng dụng chạy
dưới hệ điều hành Windows. COM bao gồm hai phần tử: giao diện
COM và một tập hợp cơ chế để đăng kí và truyền thông báo giữa các
giao diện COM. Theo quan điểm ứng dụng, sự quan tâm không phải là
8

cách các đối tượng COM được cài đặt, mà chỉ tập trung vào sự kiện
đối tượng có một giao diện mà nó đăng kí với hệ thống, và nó dùng hệ
thống thành phần này để trao đổi các sự vật COM khác.
 Sun JavaBean. Hệ thống thành phần JavaBean là kết cấu nền CBSE
độc lập, khả chuyển, đã được phát triển bằng việc dùng ngôn ngữ lập
trình Java. Hệ thống JavaBean mở rộng tiện ích Java cho phù hợp với
các thành phần phần mềm phức tạp hơn được yêu cầu cho việc phát
triển dựa trên thành phần. Hệ thống thành phần JavaBean bao gồm một
tập các công cụ, được gọi là Bean Development Kit (BDK), cho phép
phát triển, phân tích cách các thành phần Bean làm việc, chuyên biệt
hoá hành vi và dáng vẻ của chúng, thiết lập cơ chế điều phối và trao
đổi, phát triển các Bean chuyên biệt để dùng trong ứng dụng đặc biệt
và kiểm thử, đánh giá hành vi Bean.

Có thể thấy, vào thời điểm này chưa có câu trả lời cho thấy chuẩn nào trong
số các chuẩn trên sẽ chi phối nền công nghiệp phần mềm. Mặc dầu nhiều nhà
phát triển đã chuẩn hoá theo một trong các chuẩn này, nhưng rất có thể là các tổ
chức phần mềm lớn có thể chọn dùng tất cả các chuẩn đó, tuỳ theo loại ứng
dụng và nền phát triển được dùng.
1.2.2 Chế tạo thành phần
Tiến trình CBSE khuyến khích việc dùng thành phần phần mềm hiện có. Tuy
nhiên, điều không tránh được là có những lúc cần phải chế tạo thành phần. Tức
là thành phần phần mềm mới phải được phát triển và tích hợp bằng COTS có
sẵn và thành phần tự làm. Bởi vì những thành phần mới này trở thành thành viên
của thư viện thành phần dùng lại của cơ quan sở tại, nên chúng được phải chế
tạo để dùng lại.
Không có gì quá khó về việc tạo ra thành phần phần mềm có thể được dùng
lại. Các khái niệm thiết kế như trừu tượng hoá, che giấu, độc lập chức năng, làm
mịn và lập trình có cấu trúc, cùng với phương pháp hướng đối tượng, kiểm thử,
SQA, kiểm chứng tính đúng đắn, tất cả đều đóng góp cho việc tạo ra thành phần
phần mềm dùng lại được. Chúng ta sẽ không xét lại những điểm đó mà thay vì
thế chúng ta xem xét vấn đề chuyên về dùng lại để bổ sung cho công nghệ phần
mềm thực tế.
1.2.3 Phân tích và thiết kế cho dùng lại
Các mô hình dữ liệu, chức năng và hành vi (được biểu diễn trong nhiều kí
pháp khác nhau) có thể được tạo ra để mô tả cho một ứng dụng đặc biệt phải
9

thực hiện những gì, do đó những đặc tả được dùng để mô tả cho các mô hình
này. Mô tả đầy đủ cho yêu cầu là kết quả của việc phân tích, mô hình được phân
tích để xác định những yếu tố đó của mô hình, nhằm trỏ tới các thành phần phần
mềm dùng lại được. Vấn đề là trích ra thông tin từ các yêu cầu mô hình dưới
dạng có thể đưa tới tầm “sánh đúng đặc tả”.
Nếu việc so sánh đúng cho lại các thành phần khớp với nhu cầu của ứng

dụng hiện tại, thì người thiết kế có thể lấy ra các thành phần này từ thư viện
dùng lại và dùng chúng trong thiết kế hệ thống mới. Nếu thành phần thiết kế
không tìm được, thì kỹ sư phần mềm phải áp dụng phương pháp thiết kế để tạo
ra chúng. Chính tại điểm này, khi người thiết kế bắt đầu tạo ra thành phần mới,
thì thiết kế cho dùng lại cần được xét tới. Thiết kế cho dùng lại đòi hỏi người kỹ
sư phần mềm phải áp dụng các khái niệm và nguyên tắc thiết kế. Nhưng đặc
trưng của miền ứng dụng cũng phải được xem xét tới. Một số vấn đề mấu chốt
tạo nên cơ sở cho thiết kế dùng lại là:
 Dữ liệu chuẩn. Miền ứng dụng nên được nghiên cứu và các cấu trúc
dữ liệu toàn cục chuẩn (như cấu trúc tệp hay cơ sở dữ liệu đầy đủ) nên
được nhận diện. Tất cả các thành phần thiết kế có thể được đặc trưng
để dùng các cấu trúc dữ liệu chuẩn này.
 Giao thức giao diện chuẩn. Ba mức của giao thức giao diện chuẩn
nên được thiết lập: bản chất của giao diện giữa các môđun, thiết kế
giao diện kĩ thuật ngoài, và giao diện người/máy.
 Tiêu bản chương trình. Mô hình kiến trúc hiện tại có thể làm tiêu bản
cho thiết kế kiến trúc của chương trình mới.
Một khi dữ liệu chuẩn, giao diện và tiêu bản chương trình đã được thiết lập,
thì người thiết kế có một khuôn khổ để theo đó tạo ra thiết kế. Các thành phần
mới tuân theo khuôn khổ này có tính khả chuyển cao cho việc dùng lại về sau.
1.2.4 Phân loại và tìm kiếm thành phần
Ta hãy xét một thư viện đại học, với số lượng lớn các sách, tạp chí và những
nguồn thông tin khác đều có sẵn cho việc sử dụng. Nhưng để truy nhập vào thư
viện đó, cần phải xây dựng một lược đồ danh mục. Để tìm kiếm trong khối
lượng lớn thông tin này, thủ thư đã định nghĩa ra một lược đồ phân loại bao gồm
cả mã phân loại, từ khoá, tên tác giả và các chỉ mục khác. Tất cả đều tạo khả
năng cho người dùng tìm ra nguồn tài liệu cần thiết một cách nhanh chóng và dễ
dàng.
10

Bây giờ, ta hãy xét một kho thành phần lớn với nhiều thành phần phần mềm
dùng lại nằm trong nó. Nhưng làm sao người kĩ sư phần mềm tìm được thành
phần mình cần? Để trả lời câu hỏi này, một câu hỏi mới nảy sinh: Làm sao
chúng ta có thể mô tả các thành phần phần mềm theo thuật ngữ không mơ hồ, có
thể phân loại được? Đây là những câu hỏi khó, và còn chưa có câu trả lời xác
định. Ở đây chúng ta xem xét xu hướng hiện nay mà có thể giúp người kĩ sư
phần mềm tìm kiếm được thành phần cần thiết qua các thư viện thành phần dùng
lại.
Mô tả thành phần dùng lại được: Thành phần phần mềm dùng lại có thể
được mô tả theo nhiều cách, nhưng một mô tả lý tưởng bao gồm ba điều được
gọi là mô hình 3C (concept, content, context – khái niệm, nội dung, hoàn cảnh).
 Khái niệm về một thành phần phần mềm là “một mô tả về điều thành
phần thực hiện, tức là mô tả chức năng”. Giao diện cho thành phần
được mô tả đầy đủ về mặt cú pháp còn ngữ nghĩa được biểu diễn bằng
nhiều phương pháp, hình thức nhưng phổ biến là bên trong ngữ cảnh
của tiền và hậu điều kiện. Khái niệm nên truyền đạt ý định của thành
phần.
 Nội dung của thành phần mô tả ngữ nghĩa cho cách mà các khái niệm
được thực hiện. Về bản chất, nội dung là thông tin được giấu kín với
người dùng bình thường và chỉ cần được biết tới đối với những người
có ý định thay đổi hay kiểm thử thành phần.
 Hoàn cảnh đặt thành phần phần mềm dùng lại được vào trong miền
ứng dụng của nó. Tức là, bằng việc xác định các tính năng khái niệm,
vận hành và thực hiện, hoàn cảnh làm cho người kĩ sư phần mềm có
khả năng tìm ra thành phần thích hợp để đáp ứng các yêu cầu ứng
dụng.
Để dùng trong thực tế, thì khái niệm, nội dung và hoàn cảnh phải được
chuyển thành lược đồ đặc tả cụ thể. Các phương pháp được đề nghị có thể được
phân loại thành ba vùng chính: các phương pháp thư viện và khoa học thông tin,
các phương pháp trí tuệ nhân tạo, hệ thống siêu văn bản. Đại đa số công việc

được thực hiện cho tới nay đều gợi ý việc dùng phương pháp khoa học thư viện
cho phân loại thành phần.
Hình 1.2 giới thiệu một phân loại theo phương pháp chỉ số khoa học thư viện.
Các từ vựng chỉ số có kiểm soát giới hạn các thuật ngữ hay cú pháp có thể được
dùng để phân loại thành phần. Từ vựng chỉ số không kiểm soát thì không đặt
11

hạn chế nào vào bản chất của mô tả. Đa số các lược đồ phân loại cho thành phần
phần mềm đều rơi vào trong ba loại: phân loại liệt kê, phân loại nhiều mặt, phân
loại giá trị - thuộc tính.

Hình 1.2 Phân loại về phương pháp tạo chỉ số
Môi trường dùng lại: Việc dùng lại thành phần phần mềm phải được hỗ trợ
bởi một môi trường bao gồm các yếu tố sau:
 Một cơ sở dữ liệu thành phần có khả năng cất giữ các thành phần phần
mềm và thông tin phân loại cần thiết để tìm lại chúng.
 Một hệ quản trị thư viện cung cấp việc truy nhập vào cơ sở dữ liệu này.
 Một hệ thống tìm kiếm thành phần phần mềm làm cho ứng dụng khách
có khả năng tìm lại các thành phần và dịch vụ từ nguồn phục vụ thư
viện.
 Công cụ CBSE hỗ trợ cho việc tích hợp các thành phần được dùng lại
vào thiết kế hay cài đặt mới.
1.3 Mô hình vòng đời tiến trình dựa trên thành phần
CBSE chú tâm vào những thách thức tương tự trong kỹ nghệ phần mềm
thông thường. Nhiều phương pháp, công cụ và nguyên lý của kỹ nghệ phần
mềm sử dụng trong các hệ thống khác nhau cũng được dùng với cách tương tự
hoặc có chút đổi khác trong CBSE. Cho dù có sự khác biệt nhưng CBSE rõ ràng
12

tập trung vào các câu hỏi liên quan đến thành phần và nó phân biệt tiến trình của

“phát triển thành phần” so với “phát triển hệ thống dựa trên thành phần”.
Ý tưởng chính của tiếp cận dựa trên thành phần là xây dựng hệ thống từ
những thành phần đã tồn tại trước đó. Đầu tiên, các tiến trình phát triển hệ thống
dựa trên thành phần là tách biệt khỏi các tiến trình phát triển thành phần; các
thành phần đã phải được phát triển và sẵn sàng có thể sử dụng trong những sản
phẩm khác nhau khi tiến trình phát triển hệ thống khởi động. Thứ hai, một tiến
trình riêng biệt sẽ xuất hiện, đó là tìm kiếm và đánh giá các thành phần. Thứ ba,
các hoạt động trong các tiến trình sẽ khác với các hoạt động trong sự tiếp cận
không dựa trên thành phần; với phát triển hệ thống, sự quan tâm là tìm những
thành phần phù hợp và thẩm định chúng, đồng thời với sự phát triển thành phần,
thiết kế để sử dụng lại sẽ là mối quan tâm chủ yếu.
Phát triển hệ thống với thành phần tập trung vào sự nhận biết các thực thể có
thể dùng lại và mối quan hệ giữa chúng, bắt đầu từ các yêu cầu hệ thống và từ
các thành phần đã tồn tại, đã sẵn sàng sử dụng. Nhiều nỗ lực thực hiện trong
phát triển hệ thống sẽ không còn quá nặng nhọc trừ nỗ lực giải quyết yêu cầu đối
với các thành phần, định vị chúng, lựa chọn những thành phần thích hợp nhất,
kiểm thử chúng và cứ thế phát triển hệ thống tăng dần.
Những khác biệt này có thể được xem xét một cách chi tiết hơn ở hình 1.3
chỉ ra mô hình chữ V được dùng trong sự tiếp cận dựa trên thành phần. Mô hình
chữ V được sử dụng rộng rãi trong nhiều tổ chức, tiêu biểu là xây dựng các sản
phẩm phức tạp, dùng trong thời gian dài, như là xe hơi hoặc robot. Trong những
mô hình này, tiến trình bắt đầu theo cách thông thường bởi các yêu cầu kỹ nghệ
và các yêu cầu đặc tả theo sự đặc tả hệ thống. Trong sự tiếp cận không dựa trên
thành phần, tiến trình sẽ tiếp tục với thiết kế đơn vị, thực thi và kiểm thử. Thay
vì thực hiện những hoạt động này một cách thường xuyên, thì CBSE đơn giản là
lựa chọn những thành phần thích hợp và tích hợp chúng vào hệ thống. Tuy nhiên,
có hai vấn đề nảy sinh: thành phần để lựa chọn là không rõ ràng, và thành phần
đã chọn chỉ thích hợp một phần với thiết kế tổng thể. Thực tế đầu tiên chỉ ra
rằng chúng ta phải có một tiến trình để tìm kiếm các thành phần, tiến trình này
gồm các hoạt động cho tìm kiếm và đánh giá các thành phần. Thực tế thứ hai

cho biết sự cần thiết một thành phần được chấp nhận và kiểm thử trước khi nó
được tích hợp vào hệ thống, và tất nhiên nó là một tiến trình của sự phát triển
thành phần, độc lập với tiến trình phát triển hệ thống.
13


Hình 1.3 Tiến trình phát triển chữ V cho phát triển dựa trên thành phần
Hình 1.3 vẫn chỉ ra một tiến trình đơn giản và lý tưởng hóa. Nó giả sử rằng
các thành phần được chọn và được sử dụng là đầy đủ, thích đáng, gần với các
đơn vị được xác nhận trong tiến trình thiết kế, cũng là thích hợp với những yêu
cầu, và sẽ làm giảm công sức thực hiện của các đơn vị.
Bây giờ, chúng ta sẽ xem xét các hoạt động tại các pha khác nhau trong tiến
trình phát triển một cách chi tiết hơn như sau:
Phân tích và đặc tả yêu cầu: Ở pha này, một hoạt động quan trọng là phân
tích những gì có thể và xác nhận những giải pháp đáp ứng những đòi hỏi này.
Trong sự tiếp cận dựa trên thành phần điều này là cần thiết để phân tích xem
những yêu cầu này là có được hay không, có thể đáp ứng bởi những thành phần
sẵn có hay không. Điều này có nghĩa rằng các yêu cầu phải được nhận biết bởi
các thành phần có thể được sử dụng. Từ đó, không phải rằng các thành phần
thích hợp có thể luôn được tìm thấy, và khi đó các thành phần mới phải được bổ
sung. Để giữ sự tiếp cận dựa trên thành phần và tận dụng những thuận lợi của nó
thì có thể dàn xếp bằng cách sửa đổi các yêu cầu và làm cho chúng có thể sử
dụng những thành phần đang tồn tại.
Thiết kế hệ thống: Giống như pha đặc tả các yêu cầu, thiết kế và đặc tả hệ
thống là quan hệ chặt chẽ với những thành phần đã có. Những thành phần tiềm
năng tuân theo một mô hình thành phần riêng biệt, trên lý thuyết thì có thể sử
dụng những thành phần được thực hiện trong các công nghệ thành phần khác,
nhưng trong thực tế rất khó để đạt được kết quả giữa những mô hình thành phần
14

khác nhau. Mô hình thành phần thực hành đòi hỏi một mẫu kiến trúc thực hành,
và điều này ảnh hưởng đến các quyết định kiến trúc. Thí dụ, nếu mô hình thành
phần đòi hỏi một kiểu kiến trúc client/server, thì thật là rõ ràng rằng ứng dụng sẽ
dùng kiểu đó và không dùng kiểu khác. Điều này sẽ đặt sự giới hạn lên thiết kế
hệ thống, những tính chất khác của các thành phần có thể có một ảnh hưởng trực
tiếp lên các quyết định thiết kế. Vì lý do này, tiến trình thiết kế là được kết nối
chặt chẽ tới tính sẵn sàng của thành phần.
Thực thi và kiểm thử đơn vị: Khi xây dựng hệ thống dựa trên thành phần,
một trường hợp lý tưởng là xây dựng một ứng dụng bằng sự tích hợp, kết nối
trực tiếp các thành phần. “Mã lệnh gắn kết” (glue code) là mã lệnh đặc tả kết nối
này. Trong thực tế triển khai, vai trò của mã lệnh gắn kết cũng sẽ bao gồm sự
kết nối của các thành phần, và cả sự thực thi của các hàm chức năng mới. Trong
một trường hợp lý tưởng là các thành phần đã được xây dựng sẵn sàng và đã
được kiểm thử, tuy nhiên thành phần kiểm thử trong môi trường cô lập là không
đủ. Thông thường thiết kế các đơn vị sẽ được thi hành như sự lắp ghép của vài
thành phần và có thể với một mã lệnh gắn kết. Các sự gắn kết này phải được
kiểm thử tách biệt nhau, vì một sự gắn kết đúng các thành phần có thể không
đúng mặc dù từng thành phần là đúng.
Tích hợp hệ thống: Tiến trình tích hợp bao gồm sự tích hợp các thành phần
kiến trúc cơ bản chuẩn, xây dựng một thành phần khung và các thành phần ứng
dụng. Sự tích hợp của một thành phần đơn lẻ vào một hệ thống được gọi là triển
khai thành phần. Trong một cách khác để tích hợp toàn bộ hệ thống, một sự triển
khai thành phần là một kỹ thuật để tích hợp các thành phần đơn lẻ, nó gồm việc
kết nạp và đăng ký của thành phần.
Xác minh và thẩm định hệ thống: Kiểm thử chuẩn mực và kỹ thuật xác
minh được dùng ở đây. Vấn đề đặc tả cho tiếp cận dựa trên thành phần là vị trí
của lỗi, đặc biệt khi các thành phần là kiểu hộp đen và được phân phối từ các
bên khác nhau. Thông thường, một thành phần có thể lộ ra một lỗi, nhưng
nguyên nhân của sự cố lại nằm ở những thành phần khác. Các giao diện hợp
đồng thực hiện một vai trò quan trọng trong sự kiểm tra sự đúng đắn của đầu

vào và đầu ra từ các thành phần. Các giao diện này cho phép một sự đặc tả của
đầu vào, đầu ra và kiểm tra tính đúng đắn của dữ liệu.
Hỗ trợ hoạt động và bảo trì: Tiến trình bảo trì bao gồm vài bước tương tự
như tiến trình tích hợp: một thành phần mới hoặc đã chỉnh sửa được triển khai
trong hệ thống. Nó cũng có thể cần thay đổi mã lệnh gắn kết. Hầu hết các trường
hợp là một thành phần đang tồn tại sẽ được chỉnh sửa hoặc một phiên bản mới
15

của thành phần tương tự sẽ được tích hợp vào hệ thống. Khi đó lại xuất hiện
những vấn đề mới bởi sự không tương thích giữa các thành phần, hoặc bởi các
sự phụ thuộc giữa chúng bị đứt gãy. Điều này có nghĩa là, hệ thống cần phải
được xác minh lại lần nữa (hoặc là bằng phương pháp hình thức, hoặc là mô
phỏng, hoặc là kiểm thử).

Hình 1.4 Mô hình chữ V chi tiết của tiến trình phát triển dựa trên thành phần
Trong sự so sánh với các tiếp cận không dựa trên thành phần, một tiến trình
phát triển dựa trên thành phần giúp giảm bớt đáng kể công việc trong lập trình,
nhưng trong xác minh và kiểm thử đòi hỏi nhiều công sức hơn. Hoạt động xác
minh lặp lại trong vài pha, với sự khác nhau chút ít về mục tiêu là: xác minh
thành phần trong sự cô lập, xác minh các thành phần trong sự ghép nối, xác
minh hệ thống khi một thành phần được triển khai trong hệ thống.
16

CHƯƠNG 2. MÔ HÌNH THÀNH PHẦN

2. 1 Cơ sở cho mô hình thành phần
Ở những năm 70, một phương pháp lập trình mới được giới thiệu, đó là
phương pháp lập trình làm tăng hiệu suất của các lập trình viên và trở thành một
phương pháp kinh điển. Phương pháp này được biết đến với tên phương pháp
lập trình có cấu trúc và nó vẫn được sử dụng cho đến bây giờ để viết các module

chương trình nhỏ. Cũng ở thời điểm này một nhóm ở Pháp giới thiệu một ngôn
ngữ mẫu để hỗ trợ lập trình có cấu trúc gọi là EXCEL [6]. Một chương trình
trong EXCEL được xem là một hộp đen với một đầu vào duy nhất và một đầu ra
duy nhất. Một nhiệm vụ cơ bản ứng với một hộp đen đơn thể, còn một hộp đen
hợp thành được xây dựng từ những hộp đen khác sử dụng cấu trúc ghép tuần tự
“;”, cấu trúc rẽ nhánh có điều kiện “IF-THEN-ELSE-FI” và cấu trúc lặp “DO-
OD”.
Ngôn ngữ lập trình cấu trúc là không phù hợp cho sự phát triển công nghệ
thông tin hiện tại, khi mà hệ thống phần mềm là trưởng thành nhanh cả về giới
hạn của kích thước và độ phức tạp, điều này cần những kỹ thuật lập trình phải
tốt hơn tính module, nó cần phải hỗ trợ tính dùng lại và tính kết hợp. Tuy nhiên,
vẫn có nhiều điều có thể học được từ phương pháp lập trình cấu trúc để áp dụng
cho sự phát triển một mô hình thành phần:
 Một hộp đen trong EXCEL là một dịch vụ chức năng theo lý thuyết
với điều kiện trước (precondition) và điều kiện sau (post condition) có
thể được dùng lại trong một chương trình khác.
 Một phương pháp cấu trúc cho sự xây dựng một dịch vụ phức tạp hơn
từ những dịch vụ khác nhỏ hơn.
Chúng ta không xem một hộp đen trong EXCEL được coi như một thành
phần bởi vì nó chia sẻ các biến chương trình với toàn bộ các hộp đen khác của
chương trình, điều này có nghĩa là nó gây cản trở và phụ thuộc quá nhiều vào
môi trường, thêm nữa nó không hỗ trợ tính dùng lại. Chúng ta muốn các hộp đen
phải độc lập hơn. Để phục vụ mục đích này, chúng ta thử chia các biến chương
trình thành các nhóm và phân tán chúng giữa các hộp đen bằng cách nhóm các
biến được sử dụng nhiều bởi các câu lệnh trong một hộp đen sẽ được định vị
trong hộp, và các hộp có cùng nhóm biến sẽ được kết hợp cùng nhau tới một
module với vài chức năng hành động trên tập các biến giống nhau, sắp xếp lại
các hộp đen, giữ các kết nối giống nhau. Cách nhóm các hộp này không làm
17

thay đổi ngữ nghĩa của chương trình, nhưng tạo ra một cách mới cho sự module
hóa, mỗi module được tăng cường sự tự trị (xem hình 2.1). Tóm lại, một module
được tạo ra bằng cách có: các biến, vài hàm, các cổng vào, các cổng ra, các cổng
vào trung gian, và các cổng ra trung gian.

Hình 2.1 Từ các hộp EXCEL đến các thành phần
Các cổng vào và ra trung gian là cho trường hợp một dịch vụ hỗn hợp có vài
dịch vụ con được định vị trong những module khác nhau và luồng điều khiển
(được biểu diễn như cách cạnh trực tiếp) đi ra từ module và sau cùng quay trở
lại. Thuận lợi chính của loại module này là chúng có thể được dùng trong một hệ
thống theo kiểu “plug and play”, và kể từ đây chúng được gọi là các thành phần.
Các biến, các hàm, các cổng của chúng hình thành nên giao diện (interface) của
thành phần. Do đó, giao diện thành phần là một phần tử có cú pháp mới được sử
dụng trong một ngôn ngữ hỗ trợ lập trình thành phần.
Để dùng lại một thành phần, một điều cần biết là thành phần làm những gì.
Cho nên, một đại lượng được dùng để trình bày thuộc tính của biến (như kiểu
của chúng và giá trị khởi tạo), và các điều kiện trước (pre-condition), điều kiện
sau (post-condition) cho những hàm của nó (ở tại các cổng vào và ra) phải được
cung cấp với giao diện của nó. Các cổng trung gian được kết nối tới các hàm
tương ứng với các hộp đen con của nó để thành phần hoạt động đúng đắn. Các
cổng trung gian này và các hàm tương ứng của chúng được gọi là “giao diện yêu
cầu” (required interface) và sự đặc tả những hàm này cần phải được cung cấp
với giao diện. Sự đặc tả các hàm của một thành phần hình thành nên khái niệm
“hợp đồng” (contract) của thành phần.
18

Chúng ta phải đi tới việc làm rõ những khái niệm của thành phần, giao diện
và hợp đồng của chúng. Thành phần có cấu trúc đơn giản với các lớp trong lập
trình hướng đối tượng, nhưng có giao diện rõ ràng, chức năng cần mở rộng cho
một thành phần là rành mạch trong giao diện yêu cầu của thành phần, và điều

này làm sự phát triển một thành phần trở nên độc lập hơn so với các thành phần
khác.
Các khái niệm thành phần, giao diện là quan trọng nhất nhưng vẫn chưa có
định nghĩa chung cho hai khái niệm này trong CBSE. Ở phần này, chúng ta sẽ
thảo luận những cách nhìn khác nhau như thế nào đối với những khái niệm này
để có thể làm cho chúng trở nên thống nhất dưới dạng mô hình toán học [6].
Thành phần: xem trong từ điển Oxford Advanced Learners, chúng ta thấy
“một thành phần là bất kỳ phần nào của thứ được tạo ra” [10]. Trong kỹ nghệ
phần mềm, điều này sẽ cho phép một hệ thống phần mềm được hiểu như là “các
thành phần”: các câu lệnh ngôn ngữ assembly, các thủ tục, các module, các gói
phần mềm, các tiến trình, các hệ thống con, định nghĩa này rõ ràng là quá tổng
quát. Để giải quyết những gì được coi là nguyên tắc và những gì ngoài nguyên
tắc, chúng ta đầu tiên lọc ra những mục đích sử dụng “các thành phần” trong sự
phát triển phần mềm, và sau đó tìm hiểu các ràng buộc liên quan của chúng hoặc
những thuộc tính cần thiết.
Như đã nói trước, mục đích được chấp nhận chủ yếu của phát triển dựa trên
thành phần là để xây dựng và bảo trì hệ thống phần mềm bằng cách sử dụng các
thành phần phần mềm đã tồn tại. Nó được hiểu rằng các thành phần là cần có
khả năng sử dụng lại, chúng phải tương tác với các thành phần khác trong một
kiến trúc hệ thống. Mục tiêu này của CBSE hàm ý 4 tính chất đặc trưng sau đây
cho một thành phần thực sự có khả năng dùng lại:
 (P1) Hợp đồng đặc tả các giao diện
 (P2) Các ngữ cảnh phụ thuộc đầy đủ rõ ràng
 (P3) Sự triển khai độc lập
 (P4) Tích hợp hãng thứ ba
Dựa trên những điều kiện ấy, nó diễn đạt rằng một câu lệnh ngôn ngữ
assembly và các gói phần mềm sẽ không được coi như những thành phần, nhưng
các lớp trong thư viện lớp là những thành phần. Tuy nhiên, các lớp có thể khó là
các thành phần nếu chúng ta đòi hỏi P3 khi sự kết hợp các thành phần không
truy cập tới mã nguồn. Một cách khác, chúng ta có thể lấy một lớp để có thể sử

19

dụng như một thành phần, bằng cách cung cấp một miêu tả các phương thức và
các lớp yêu cầu của nó.
Cách sử dụng một thành phần trong một hệ thống phần mềm bao gồm việc sử
dụng nó để thay thế một thành phần đã cũ để nâng cấp hệ thống hay thay thế
một thành phần bị lỗi để sửa chữa hệ thống, hoặc bổ sung thành phần vào hệ
thống để mở rộng các dịch vụ hệ thống, hoặc tích hợp nó vào hệ thống trong khi
hệ thống vẫn đang được xây dựng. Một vài nhà nghiên cứu thì khăng khăng cho
rằng một thành phần cần có khả năng sử dụng lại trong trạng thái động của việc
cấu hình lại hệ thống. Những vấn đề liên quan đến thuộc tính từ P1 đên P4 là
khác nhau khi một thành phần được sử dụng trong những ứng dụng khác nhau,
cho những mục đích khác nhau hay cho những loại hệ thống khác nhau. Đây
chính là lý do tại sao một số nhà cung cấp những định nghĩa chặt chẽ, nghiêm
ngặt hơn những người khác [10]. Một trong những định nghĩa thành phần như
vậy là việc định nghĩa được thông qua 3 tiên đề sau:
 (A1) Một thành phần là có khả năng thực hiện công việc một cách độc
lập.
 (A2) Các thành phần có thể được phát triển độc lập từ các thành phần
khác.
 (A3) Mục đích của kết hợp là có thể hợp tác giữa các thành phần hợp
thành.
Ba tiên đề này còn ngụ ý một số lượng tính chất nhiều hơn được gọi là các hệ
quả của định nghĩa thành phần:
 (C1) Một thành phần có khả năng nhận đầu vào từ môi trường của nó
và (hoặc) cho đầu ra tới môi trường của nó.
 (C2) Một thành phần có thể là độc lập với môi trường của nó.
 (C3) Sự thêm vào hoặc gỡ bỏ một thành phần không đòi hỏi sửa đổi
các thành phần khác trong kết cấu.
 (C4) Tính thời gian thực của đầu ra một thành phần là độc lập với tính

thời gian thực của đầu vào.
 (C5) Chức năng của một thành phần là độc lập với vị trí của nó trong
kết cấu.
 (C6) Sự thay đổi vị trí của một thành phần không đòi hỏi sự thay đổi từ
những thành phần khác trong kết cấu.
20

 (C7) Một thành phần là một đơn vị của một hệ ngăn chặn lỗi.
Tính chất C2 ngụ ý rằng một thành phần không có trạng thái. Điều này chỉ
được đòi hỏi trong một vài hoàn cảnh giới hạn như cho một sự tái cấu hình động.
Tính chất C4 chỉ áp dụng trong hệ thống thời gian thực và tính chất C5, C6 chỉ
liên quan đến hệ thống di động phân tán. Chúng ta không xem xét tại sao C7 lại
cần cho tất cả trừ khi một thành phần là cần được sử dụng để thay thế cho những
thành phần khác trong suốt thời gian thực thi của hệ thống. Trên thực tế rất
nhiều ứng dụng hợp tác hoặc quản lý có thể được sử dụng để kết hợp các thành
phần dễ bị lỗi nhằm đạt được độ dung thứ lỗi.
Giao diện: Mặc dù ở đây không có sự nhất trí về thành phần là gì, mọi định
nghĩa đều đồng ý sự quan trọng của thành phần là giao diện, và các giao diện là
để kết hợp mà không có sự truy cập tới mã nguồn của các thành phần. Điều này
ngụ ý rằng sự khác biệt là được phản ánh chủ yếu trong các quyết định dựa trên
những gì thông tin sẽ được chứa đựng trong giao diện của một thành phần. Các
giao diện cho các mục đích sử dụng khác nhau và các ứng dụng khác nhau trong
các môi trường khác nhau có thể chứa đựng thông tin khác nhau, và có những
tính chất khác nhau:
 Một giao diện cho một thành phần trong một hệ thống tuần tự là khác
nhau rõ ràng với một hệ thống truyền thông đồng thời. Các đòi hỏi sau
này là giao diện bao gồm một sự miêu tả của giao thức truyền thông
trong khi trước kia không đòi hỏi như thế.
 Một giao diện cho một thành phần trong ứng dụng thời gian thực sẽ
cần cung cấp các ràng buộc thời gian thực của các dịch vụ, nhưng một

ứng dụng không phụ thuộc thời gian thì không như vậy.
 Các thành phần trong hệ thống phân tán, hệ thống di động hoặc dựa
trên internet đòi hỏi các giao diện của chúng chứa đựng thông tin về
các địa điểm hoặc địa chỉ của chúng.
 Một thành phần dịch vụ có đặc điểm khác với một thành phần trung
gian.
Vì thế, giao diện quyết định hành xử bên ngoài và các đặc điểm của thành
phần, chúng cho phép thành phần được sử dụng như một hộp đen.
Dựa trên miêu tả ở trên, chúng ta định nghĩa một giao diện cho một thành
phần như một miêu tả những gì cần thiết cho thành phần sử dụng trong xây
dựng và bảo trì hệ thống phần mềm [10]. Sự miêu tả một giao diện phải chứa
21

đựng thông tin về mọi khung nhìn bao quanh, như là tính chức năng, hành xử,
các giao thức, độ an toàn, độ tin cậy, thời gian thực, năng lực, băng thông, sự
tiêu thụ bộ nhớ và kỹ thuật truyền thông, đó là những gì cần thiết cho việc kết
hợp các thành phần trong kiến trúc định sẵn cho ứng dụng của hệ thống. Tuy
nhiên, sự miêu tả này có thể được gia tăng theo hướng các tính chất đòi hỏi mới
hoặc các quan điểm có thể được bổ sung khi cần tùy theo ứng dụng.
Kiến trúc: Sự quan tâm chính của lập trình trong hệ thống nhỏ là lưu lượng
của điều khiển và cấu trúc dữ liệu. Các đặc tả, thiết kế và sự thẩm định tập trung
chủ yếu dựa trên giải thuật và cấu trúc dữ liệu của chương trình. Với lập trình
trong hệ thống lớn, các quan tâm chủ yếu là các thành phần và sự tích hợp thống
nhất của chúng trong một ngữ cảnh kiến trúc. Thiết kế kiến trúc trở thành một
vấn đề nghiêm trọng bởi vì vai trò quan trọng của nó trong sự truyền thông giữa
các bên liên quan khác nhau, phân tích hệ thống và sử dụng lại với phạm vi lớn.
Có nhiều định nghĩa về kiến trúc phần mềm. Cơ sở chung của chúng là: một
kiến trúc miêu tả một hệ thống như là một cấu trúc phân rã của hệ thống thành
nhiều hệ thống con và các kết nối của chúng. Ngôn ngữ miêu tả kiến trúc
(ADLs– Architecture Description Languages) có mục đích miêu tả kiến trúc.

Các phần tử cơ sở của ADLs là các thành phần và các vật kết nối (connectors).
Một ADL cũng cung cấp các quy tắc cho việc kết hợp các thành phần với nhau
bằng các vật kết nối nối. Các ADL đã trải qua những bất lợi khi chúng chỉ có thể
được hiểu bởi những chuyên gia ngôn ngữ, chúng không thể tiếp cận tới lĩnh
vực và ứng dụng đặc biệt. Sự không hình thức và dùng các ký hiệu đồ họa, như
UML, bây giờ là được sử dụng rộng rãi bởi những người phát triển phần mềm
dùng để miêu tả kiến trúc, tuy nhiên, tập ngữ nghĩa cho các mô hình dựa trên
UML vẫn chưa được thiết lập một cách vững chắc.
Một sự miêu tả cấu trúc hệ thống một cách ít ỏi là không đủ hỗ trợ cho phân
tích hệ thống, thiết kế, thực hiện, xác minh và cấu hình. Tăng cường năng lực
diễn tả là cần thiết cho một ADL, trong thực hành, một ADL sẽ cũng hỗ trợ
những loại khung nhìn sau:
 Sự tương tác (Interaction): giao thức tương tác và các kỹ thuật tương
tác.
 Chức năng và hành vi (Functionality and Behavior): các dịch vụ
chức năng, các tính chất chính của các thành phần (như tính an toàn và
tính tin cậy).
22

 Tài nguyên và chất lượng dịch vụ (Resources and Quality of
Service): các đòi hỏi đơn vị phần cứng, thời gian thực, năng lực, băng
thông,…Những chi tiết này cho phép phân tích và đánh giá trục trặc,
như là chất lượng dịch vụ.
Một trong những thách thức lớn nhất trong CBSE là phát triển một mô hình
có hiệu lực hỗ trợ sự phân chia các khung nhìn cho sự phân tích các vấn đề quan
tâm khác nhau, trong khi chúng có thể kết nối thống nhất hoặc kết hợp trong
toàn bộ tiến trình phát triển hệ thống. Ở phần này, chúng tôi đề xuất một kiến
trúc dựa trên thành phần cho các hệ thống được mô tả trong hình 2.2. Với các
thành phần tự trị, qua giao diện của chúng, ta có thể đặt chúng cùng nhau bởi
các kết nối để hình thành một thành phần lớn dần lên và ngày càng nhiều dịch

vụ đến khi nó đầy đủ, và những dịch vụ nó cung cấp là đủ cho chúng ta để thỏa
mãn những đòi hỏi được xác định như những tiến trình các ca sử dụng. Vì thế,
hệ thống của chúng ta xây dựng theo cách này có 2 phần: phần bị động bao gồm
các thành phần đóng được lấy từ tập các thành phần, và phần chủ động là một
tập các tiến trình được khởi tạo bằng các sự kiện bên ngoài và sử dụng các dịch
vụ từ phần bị động để thỏa mãn những đòi hỏi từ các tác nhân ngoài của hệ
thống.

Hình 2.2 Kiến trúc hệ thống thành phần
2.2 Thiết kế
Như đã nói ở phần trước, một thành phần cung cấp những dịch vụ tới môi
trường của nó, những dịch vụ này có thể là dữ liệu hoặc những phương thức. Để
mô tả chức năng cho những phương thức, chúng ta sử dụng những ký hiệu cua
UTP (Unifying Theories of Programming). UTP được hoàn thành trong nhiều
năm với nỗ lực trong việc hình thức hóa cơ sở ngôn ngữ lập trình và kỹ thuật
suy luận cho chương trình [2, 11]. UTP được Tony Hoare và He Jifeng phát
triển, nó chứa đựng năng lực lập luận của logic vị từ và đại số quan hệ. Mọi
23

chương trình được xem như quan hệ hai ngôi trên một không gian trạng thái là
một tập X các biến chương trình hoặc các biến đáng chú ý khác (như biến ok’
nhận giá trị đúng khi kết thúc chương trình). Trong trường hợp tổng quát, quan
hệ từng phần của một chương trình tuần tự P được biểu diễn bởi một cặp vị từ
trên các biến trạng thái, kí hiệu là
( ) ( , ')pre x post x x+
và gọi là một thiết kế
(design), ở đây x biểu diễn các giá trị các biến trước khi thực thi chương trình, x’
biểu thị các giá trị mới cho các biến sau khi thực thi,
()pre x
là các điều kiện

trước (pre-condition) định nghĩa miền xác định của quan hệ, post(x,x
’
) là điều
kiện sau (post-condition) định nghĩa quan hệ của nó.
Nghĩa của thiết kế
( ) ( , ')pre x post x x+
được xác định bởi vị từ
( ) ' ( , ')pre x ok ok post x x  
, xác nhận rằng nếu chương trình được kích hoạt từ
một trạng thái thỏa mãn điều kiện trước pre(x) thì sự thực thi chương trình sẽ kết
thúc trong một trạng thái mà các giá trị mới trong trạng thái này là liên quan đến
các giá trị cũ trước khi thực hiện bởi post. Ví dụ, một phép gán x:= x + y được
định nghĩa là
'true x x y+
.
UTP của Hoare và He cung cấp sự tiếp cận để mô hình việc thực thi một
chương trình trong giới hạn của quan hệ giữa các trạng thái của chương trình. Ở
đây, một trạng thái của chương trình P được định nghĩa qua một tập các biến và
được gọi là ký tự của chương trình, ký hiệu là
()P

và đơn giản là

nếu không
gây ra sự hiểu lầm. Cho một chương trình với các lệnh tuần tự, ta quan tâm giá
trị các biến đầu vào
()in

và các biến đầu ra
()out


. Ta sử dụng một biến logic
ok để biểu thị một chương trình là được bắt đầu đúng đắn, và
'ok
để miêu tả sự
thực thi đã kết thúc. Ký tự

được định nghĩa là
{ , '}in out ok ok


, và một
thiết kế là:
( ( ) ( , ')) ( ) ' ( , ')
def
p x R x y ok p x ok R x y   +

Ở đây:
 p là điều kiện trước, định nghĩa các trạng thái khởi tạo
 R là điều kiện sau, mối quan hệ các trạng thái khởi tạo tới các trạng
thái kết thúc trong phạm vi giá trị đầu vào x và giá trị đầu ra y’. Lưu ý
rằng một vài biến x được thay đổi bởi một chương trình và trong
trường hợp này chúng ta nói
x in


và
'x out



 ok và ok’

miêu tả bắt đầu và kết thúc, chúng không xuất hiện trong các
biểu thức hoặc trong văn bản chương trình.