Mô hình hóa giao diện của các thành phần trong các hệ thống 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Ệ









PHẠM ĐÌNH CHINH












MÔ HÌNH HÓA
GIAO DIỆN CỦA CÁC THÀNH PHẦN
TRONG CÁC HỆ THỐNG DỰA TRÊN THÀNH PHẦN

LUẬN VĂN THẠC
SĨ

Hà Nội -
2011


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







PHẠM ĐÌNH CHINH

MÔ HÌNH HÓA
GIAO DIỆN CỦA CÁC THÀNH PHẦN
TRONG CÁC HỆ THỐNG DỰA TRÊN THÀNH PHẦN







Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60.48.10




LUẬN VĂN THẠC
SĨ




NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐẶNG VĂN HƯNG

Hà Nội –
2011

4
MỤC LỤC
PHẦN MỞ ĐẦU 7
CHƯƠNG 1: KIẾN TRÚC VÀ PHƯƠNG PHÁP LUẬN PHÁT TRIỂN PHẦN
MỀM HƯỚNG THÀNH PHẦN 9

1.1 Giới thiệu 9
1.2 Thành phần, giao diện và mô hình kiến trúc 10
1.2.1 Thành phần 10
1.2.2 Giao diện 12
1.2.3 Mô hình kiến trúc 13
1.2.4 Thống nhất khái niệm về phát triển phần mềm hướng thành phần 14
1.3 Các lý thuyết hình thức mới nhất 15
1.3.1 Mô hình kiến trúc 15

1.3.2 Sự cần thiết phải liên kết các phương pháp và lý thuyết 16
1.4 Giới thiệu mô hình rCOS 17
1.5 Kết luận 18
CHƯƠNG 2: ĐỀ XUẤT MÔ HÌNH GIAO DIỆN THÀNH PHẦN VÀ PHƯƠNG
PHÁP LUẬN PHÁT TRIỂN CHO CÁC HỆ THỐNG THỜI GIAN THỰC 19

2.1 Giới thiệu 19
2.2 Mô hình hóa đặc tả giao diện của thành phần 20
2.2.1 Làm mịn của các thiết kế xét đến yếu tố thời gian 21
2.2.2 Thành phần tuần tự 22
2.2.3 Kết nối các thành phần song song 22
2.2.4 Thành phần thụ động 25
2.2.5 Sự kết hợp của các thành phần 27
2.2.6 Thành phần chủ động 29
2.2.7 Ví dụ minh họa 30
2.3 Kiến trúc và phương pháp phát triển cho hệ thành phần thời gian thực 32
2.4 Kết luận và hướng nghiên cứu tiếp theo 33
CHƯƠNG 3: ÁP DỤNG MÔ HÌNH ĐỀ XUẤT ĐỂ XÂY DỰNG HỆ THỐNG
XUẤT HÓA ĐƠN BÁN HÀNG 35

3.1 Phát biểu bài toán 35
3.2 Xây dựng chương trình 35
3.2.1 Các chức năng hệ thống 35
3.2.2 Thành phần Client (Khách hàng) 37
3.2.3 Thành phần Product (Sản phẩm) 39
3.2.4 Thành phần Invoice (Hóa đơn) 40
3.2.5 Thành phần hệ thống xuất hoá đơn (Invoice_System) 43
3.3 Nhận xét về ví dụ 43
5
KẾT LUẬN 44

TÀI LIỆU THAM KHẢO 45

6
DANH MỤC HÌNH
STT Tên danh mục hình Trang
Hình 1 Sơ đồ thành phần cho hệ thống CNS 30
Hình 2 Mô hình kiến trúc cho hệ thống dựa trên thành phần 32
Hình 3 Mô hình thành phần cho hệ thống xuất hóa đơn bán hàng 36

7
DANH MỤC CÁC TỪ VIẾT TẮT
Thuật ngữ
Mô tả
ADLs
Architecture Description Languages - Kiến trúc mô tả Ngôn
ngữ
CBD
Component-based development - Phát triển hướng thành
phần
CBSE
Component-Based Software Engineering - Công nghệ phần
mềm hướng thành phần
CNS
Car Navigation System - Hệ thống chỉ dẫn hỗ trợ lái xe ôtô
điều khiển xe đi qua một khu vực
CSP
Communicating Sequential Processes - Quá trình trao đổi
tuần tự
EDC Extended Duration Calculus – Mở rộng tính toán thời lượng
FIFO
First In, First Out – Vào trước, ra trước hay Đến trước phục
vụ trước
GPS Global Positioning System – Hệ thống định vị toàn cầu
IDL Interface description language - Ngôn ngữ mô tả giao diện
OCL
Object Constraint Language – Ngôn ngữ ràng buộc đối
tượng
PVS
Prototype Verification System - Hệ thống xác minh nguyên

mẫu bằng cách chứng minh định lý
rCOS
Relational Calculus of Object and Component Systems –
Phép tính quan hệ của các đối tượng và thành phần
UML
Unified Modeling Language - Ngôn ngữ mô hình hóa thống
nhất
UNU-IIST
International Institute for Software Technology - The
United Nations University - Viện nghiên cứu Quốc tế về
Công nghệ phần mềm - Đại học Liên Hiệp Quốc tại Macao
UTP
Unifying Theories of Programming – Lý thuyết thống nhất
về lập trình


7
PHẦN MỞ ĐẦU
Trong những năm bảy mươi, một phương pháp lập trình mới đã được giới thiệu
làm tăng năng suất của lập trình đáng kể và đã trở thành kinh điển. Phương pháp này
được gọi là phương pháp lập trình cấu trúc và phương pháp này vẫn còn sử dụng ngày
nay để viết các môđun chương trình nhỏ. Trong những năm tám mươi, lý luận về các
phương pháp và ngôn ngữ hướng đối tượng ra đời, phát triển mạnh mẽ và được sử
dụng rộng rãi ngày nay. Tuy nhiên, các hệ thống hiện nay ngày càng trở nên phức tạp,
vì vậy ý tưởng phát triển một hệ thống phần mềm mới bằng cách lắp ghép từ các thành
phần đã có do rất nhiều người, nhiều nguồn khác nhau xây dựng tương tự như việc sản
xuất một chiếc xe ôtô lắp ráp từ hàng vạn linh kiện từ các nhà máy khác nhau tạo ra đã
được đặt ra. Công nghệ phát triển phần mềm này được gọi là công nghệ phát triển
phần mềm hướng thành phần.
Có thể đánh giá công nghệ phát triển phần mềm hướng thành phần hiện nay

đang ở trong giai đoạn đầu tiên của sự phát triển, nhiều tác giả đã đề xuất các mô hình
khác nhau cho công nghệ này và vẫn chưa đạt được sự thống nhất về tiêu chuẩn công
nghệ cho thiết kế, khởi tạo và kết hợp các thành phần. Việc tìm kiếm các mô hình cho
việc mô tả thành phần, kiến trúc kết hợp giữa các thành phần và các phương thức để
xây dựng phần mềm hướng thành phần vẫn đang là một thách thức.
Nhằm góp một phần rất nhỏ vào việc xây dựng và hoàn chỉnh các phương pháp
luận cho việc phát triển phần mềm hướng thành phần. Trong phạm vi của luận văn này
chúng tôi đặt ra hai mục tiêu chính:
(1) Từ việc nghiên cứu các phương pháp luận về mô hình phát triển phần mềm
hướng thành phần do nhiều các tác giả khác nhau đề xuất nhằm làm sáng tỏ
các khái niệm và góp một phần nhỏ vào việc thống nhất, tiêu chuẩn hóa mô
hình phát triển phần mềm hướng thành phần.
(2) Từ các kết quả của các nghiên cứu trước đó, đề xuất ra một mô hình giao
diện của các thành phần nhằm giải quyết một lĩnh vực mà các nghiên cứu
trước đây chưa đề cập đến hoặc có đề cập nhưng giải quyết chưa triệt đó là
đề xuất mô hình giao diện cho các thành phần của hệ thống thành phần
hướng thời gian thực nhằm đóng góp một phần vào việc chuẩn hóa phương
pháp luận phát triển cho các hệ thống thời gian thực.

Để giải quyết hai mục tiêu đặt ra ở trên, luận văn này được chia thành 3
chương, cụ thể:
Chương 1, tập trung vào xem xét nghiên cứu về phương pháp luận và kiến trúc
của mô hình phát triển phần mềm hướng thành phần do rất nhiều tác giả đề xuất. Từ
nghiên cứu đó tìm ra các điểm thống nhất và các điểm khác biệt giữa các lý thuyết
đồng thời cũng nêu ra các vấn đề mà các mô hình lý luận hiện nay đã giải quyết được,
những phần còn hạn chế hoặc chưa giải quyết được.
8
Chương 2, đề xuất ra một mô hình của các giao diện các thành phần cho các hệ
thống hướng thành phần thời gian thực. Trong đó mở rộng đặc tả của phương thức với
ràng buộc thời gian, đó là mối quan hệ giữa sự tài nguyên sẵn có và lượng thời gian

dành để thực hiện phương thức. Hợp đồng được định nghĩa bao gồm các đặc tả,
phương thức và định nghĩa một thành phần như là một sự thực thi của hợp đồng. Sự
thực thi có thể yêu cầu dịch vụ từ các thành phần khác với một số ràng buộc về lịch
cho việc sử dụng các chia sẻ về phương thức và tài nguyên với sự có mặt đồng thời.
Mô hình của chúng tôi hỗ trợ sự phân chia giữa yêu cầu là hàm và không phải là hàm,
và cho phép xác minh tính đúng đắn của hệ thống dựa trên thành phần thời gian thực.
Chương 3,
đưa ra một minh họa là xây dựng hệ thống xuất hóa đơn cho khách
hàng nhằm minh họa cho mô hình giao diện của các thành phần đã được đề xuất ở
Chương 2. Đồng thời từ minh họa này cũng giúp cho các khái niệm đưa ra ở Chương 2
sáng tỏ hơn.
Tiếp theo là phần tổng kết về luận văn và đề ra hướng phát triển của luận văn.
Cuối luận văn là phần thuật ngữ liên quan và các tài liệu tham khảo.
9
CHƯƠNG 1: KIẾN TRÚC VÀ PHƯƠNG PHÁP LUẬN PHÁT TRIỂN
PHẦN MỀM HƯỚNG THÀNH PHẦN
Công nghệ phần mềm hướng thành phần (Component-based Software Engineering
- CBSE) là hướng tới làm thế nào để tạo ra một chương trình mới bằng cách ghép nối
một thành phần làm sẵn với một chương trình mới mà có thể kết dính giữa thành phần
và chức năng mới[10]. Trước khi tìm hiểu các lý thuyết về công nghệ phần mềm
hướng thành phần, tôi xin đưa ra các thuộc tính sau đây được đa số các học thuyết thừa
nhận:
- Nguyên tắc hộp đen về tính lắp ghép, thay thế và sử dụng lại: khi lắp
ghép một thành phần với những phần khác của hệ thống, thay thế một thành
phần bởi thành phần khác hoặc sử dụng lại một ứng dụng khác thì không
phải quan tâm đến thiết kế hoặc mã lệnh.
- Phát triển độc lập: các thành phần có thể thiết kế, thực hiện, thẩm tra, kiểm
tra và triển khai một cách độc lập.
- Khả năng cùng hoạt động: các thành phần có thể thực hiện ở các ngôn ngữ
lập trình và mô hình khác nhau nhưng chúng có thể lắp ghép, kết dính và

phối hợp hoạt động với nhau.
Trong chương này chúng ta sẽ bàn về một số khó khăn và các vấn đề quan trọng
mà chúng ta cần phải xem xét khi phát triển một phương pháp hình thức cho công
nghệ phần mềm dựa trên thành phần. Trong đó trình bày kết quả nghiên cứu nhằm liên
kết các lý thuyết và phương pháp lập trình hiện có nhằm hỗ trợ hiệu quả cho công
nghệ phần mềm dựa trên thành phần.
1.1 Giới thiệu
Trong những năm bảy mươi, một phương pháp lập trình mới đã được giới thiệu
làm tăng năng suất của lập trình đáng kể và đã trở thành kinh điển. Phương pháp này
được gọi là phương pháp lập trình cấu trúc và phương pháp này vẫn còn sử dụng ngày
nay để viết các môđun chương trình nhỏ. Trong những năm 80 lý luận về các phương
pháp và ngôn ngữ hướng đối tượng ra đời, phát triển mạnh mẽ và được sử dụng rộng
rãi ngày nay. Tuy nhiên, các hệ thống hiện nay ngày càng trở nên phức tạp vì vậy đặt
ra ý tưởng khai thác và sử dụng lại các thành phần đã có để phát triển hệ thống phần
mềm [20].
Trong khi phát triển phần mềm dựa trên thành phần được hiểu là yêu cầu các thành
phần tái sử dụng có thể tương tác với nhau và phù hợp với kiến trúc của hệ thống, cho
đến nay chưa đạt được sự thống nhất về tiêu chuẩn công nghệ cho thiết kế, khởi tạo và
kết hợp các thành phần. Tìm cách tiếp cận theo mô hình cho việc mô tả thành phần,
kiến trúc kết hợp giữa các thành phần và các phương thức để xây dựng phần mềm
10
hướng thành phần vẫn đang là một thách thức. Có vẻ như phát triển phần mềm dựa
trên thành phần hiện nay đang trong tình trạng tương tự như lập trình hướng đối tượng
trong những năm 80:
“Tôi dự đoán là lập trình hướng đối tượng trong những năm 1980 giống như
lập trình cấu trúc những năm 1970. Mọi người sẽ ủng hộ nó. Mỗi nhà sản xuất
sẽ quảng bá sản phẩm của mình là đã hỗ trợ nó. Mỗi nhà quản lý sẽ trả phí
dịch vụ với nó. Mọi lập trình sẽ thực hành nó. Và không ai biết nó sẽ đi đến
đâu[40]”. – Phát biểu của T. Rentsch vào tháng 12 năm 1982
Trong chương này, chúng ta sẽ thảo luận về một số khái niệm và một số vấn đề

cần thiết cho một phương pháp hình thức để hỗ trợ công nghệ phần mềm dựa trên
thành phần (CBSE). Chúng tôi cho rằng cần có sự tích hợp các lý thuyết và các
phương pháp lập trình hướng thành phần hiện nay. Mối quan tâm khác nhau được mô
tả trong các quan điểm khác nhau của hệ thống ở các cấp độ trừu tượng khác nhau, bao
gồm cả sự phụ thuộc giữa cú pháp, hành vi tĩnh, hành vi động và sự tương tác giữa các
thành phần. Liên kết các lý thuyết cũng sẽ làm sáng tỏ về sự tích hợp của các công cụ,
chẳng hạn như mô hình kiểm chứng, chứng minh định lý và các công cụ kiểm thử để
xác minh hệ thống.
Do chưa có một tiêu chuẩn thống nhất cho phương pháp phát triển phần mềm dựa
trên thành phần vì vậy chúng ta sẽ lựa chọn cách tiếp cận tổng hợp các lý thuyết hướng
thành phần hiện có. Từ đây có thể giúp chia sẻ kiến thức cho nhiều người khác nhau
trong các hệ thống phát triển dựa trên thành phần như: người xây dựng yêu cầu, người
phân tích, người chịu trách nhiệm tích hợp hệ thống, người thiết kế thành phần, người
kiểm định thành phần và người kiểm định toàn hệ thống. Những người khác nhau
đóng vai trò khác nhau và quan tâm đến các mô hình liên quan đến công việc của họ.
Trong mục tiếp theo (mục 1.2) xin được giới thiệu các khái niệm về thành phần,
giao diện và kiến trúc. Đây là ba khái niệm cơ bản nhất mà hiện nay chưa đạt được sự
đồng thuận. Trong mục 1.3, chúng tôi sẽ cung cấp một cái nhìn tổng quan về các
phương pháp mô hình hóa các hệ thống dựa trên thành phần hiện nay. Trong mục 1.4
sẽ nêu tóm tắt về một phương pháp được đã đề xuất là rCOS.
1.2 Thành phần, giao diện và mô hình kiến trúc
Các khái niệm về thành phần, giao diện và mô kiến trúc là quan trọng nhất trong
một mô hình phát triển dựa trên thành phần (CBSE). Trong phần này sẽ trình bày về
ba khái niệm đó.
1.2.1 Thành phần
Theo từ điển Oxford, chúng ta có thể tìm thấy định nghĩa:
“Thành phần là bất kỳ bộ phận nào trong một cái gì đó được làm ra”.
11
Trong công nghệ phần mềm, một hệ thống phần mềm có thể có các thành phần
như: chỉ dẫn ngôn ngữ, các thủ tục, nhiệm vụ, mô-đun, các đối tượng, các lớp, các gói

phần mềm, các quy trình, các hệ thống con vv… Định nghĩa này rõ ràng là rất chung
chung cho CBSE (công nghệ phần mềm hướng thành phần) và không cung cấp bất cứ
điều gì mới. Để đánh giá xem những gì là quy tắc và những gì không phải quy tắc, đầu
tiên chúng ta sẽ làm rõ mục đích sử dụng của “thành phần” trong phát triển phần mềm
và sau đó sẽ nghiên cứu tác động hoặc những thuộc tính cần thiết.
Như chúng ta đã đề cập trước đó, mục tiêu của phát triển phần mềm dựa trên thành
phần đã được thừa nhận rộng rãi là xây dựng và duy 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 hiện có, ví dụ: [49, 43, 38, 30, 41, 17, 9]. Điều này
được hiểu rằng các thành phần được yêu cầu phải đảm bảo việc tái sử dụng. Nó phải
tương tác với nhau trong một kiến trúc hệ thống [45, 4, 38, 52, 41]. Mục tiêu của
CBSE có bốn đặc tính giúp cho một thành phần thực sự có thể dùng lại [49]:
P1 - sự hợp đồng phải chỉ rõ trong giao diện,
P2 - sự phụ thuộc vào ngữ cảnh phải rõ ràng,
P3 - có thể triển khai độc lập,
P4 - kết hợp được với bên thứ ba.
Dựa trên những điều kiện này, trong lập luận [26] chỉ ra rằng một chỉ dẫn ngôn
ngữ và gói phần mềm không nên được coi là thành phần, nhưng các lớp trong một thư
viện lớp có thể coi là các thành phần. Tuy nhiên, nhiều lớp sẽ không được coi là các
thành phần khi không thỏa mãn thuộc tính P3, nghĩa là khi tích hợp thành phần mà
không cần quan tâm tới mã nguồn chi tiết. Mặt khác, chúng ta có thể nâng cấp một lớp
để làm cho nó có thể sử dụng như là một thành phần, bằng cách cung cấp một mô tả
của lớp các yêu cầu và các phương thức.
Việc sử dụng của một thành phần trong hệ thống phần mềm để thay thế một thành
phần đã lỗi thời nhằm nâng cấp hệ thống hoặc một thành phần đã bị hỏng để sửa chữa
hệ thống, thêm nó vào hệ thống nhằm mở rộng các dịch vụ của hệ thống hoặc kết hợp
nó vào hệ thống khi hệ thống đó đang trong quá trình xây dựng. Một số nhà nghiên
cứu nhấn mạnh vào thành phần được sử dụng lại trong quá trình cấu hình động. Các
tác động của các thuộc tính P1 - P4 là khác nhau khi một thành phần được sử dụng
trong các ứng dụng khác nhau, cho các mục đích khác nhau hoặc các loại hệ thống
khác nhau. Đây là lý do chính tại sao một số người đưa ra định nghĩa chặt chẽ hơn

những người khác (ví dụ: [9, 43]). Trong [9], một thành phần được xác định bởi ba
tiên đề sau:
A1 - Thành phần có khả năng thực hiện một nhiệm vụ độc lập khi không kết
hợp với các thành phần khác.
A2 - Thành phần có thể được phát triển độc lập từ những người khác nhau.
12
A3 - Mục đích của sự kết hợp là cho phép hợp tác giữa các thành phần cấu
thành.
Các tính chất này thật ra cần thiết cho một hệ thống con(“sub-system”) trong [48].
Trong [9] cho rằng ba tiên đề trên có thể suy ra các thuộc tính là hệ quả:
C1 - Một thành phần có khả năng nhận đầu vào từ môi trường và có thể xuất
kết quả đầu ra cho môi trường.
C2 - Một thành phần cần phải độc lập với môi trường.
C3 - Bổ sung hoặc loại bỏ thành phần không cần yêu cầu sửa đổi các thành
phần khác trong thành phần hợp thành.
C4 - Tính kịp thời của đầu ra của một thành phần cần được độc lập tính kịp
thời của đầu vào.
C5 - Các chức năng của thành phần cần được độc lập với vị trí của nó trong
thành phần hợp thành.
C6 - Việc thay đổi vị trí của một thành phần không yêu cầu sửa đổi với các
thành phần khác trong thành phần hợp thành.
C7 - Một thành phần phải có một bộ phận ngăn chặn lỗi.
Ý nghĩa của các hệ quả từ các tiên đề chỉ là lập luận chưa chính thức. Thuộc tính
C2 suy ra một thành phần không có trạng thái và điều này cũng được khẳng định trên
trong [49]. Điều này có thể hiểu là chỉ yêu cầu trong một số trường hợp hạn chế, chẳng
hạn như đối với cấu hình động lại. Thuộc tính C4 chỉ áp dụng cho các hệ thống thời
gian thực và thuộc tính C5&C6 chỉ liên quan đến hệ thống phân phát di động. Chúng
tôi không thấy lý do tại sao C7 là cần thiết ở tất cả, trừ khi một thành phần được sử
dụng để thay thế một thành phần khác trong lúc hệ thống đang chạy. Thực ra, trong
nhiều ứng dụng điều phối viên hoặc người quản lý có thể được sử dụng để phối hợp

các thành phần dễ bị lỗi để đạt được khả năng kháng lỗi [34].
Mặt khác, trong [43] một thành phần phần mềm là một trừu tượng tĩnh với nút cắm
không chỉ được sử dụng để cung cấp dịch vụ mà còn để yêu cầu dịch vụ. Điều này cho
thấy thành phần thường không được sử dụng trong sự cô lập, nhưng kiến trúc phần
mềm sẽ xác định thành phần được cắm như thế nào với nhau. Thực tế đây là kiểu của
thành phần được gọi là module bên trong [48].
1.2.2 Giao diện
Mặc dù không có sự đồng thuận về mô tả thành phần như thế nào nhưng tất cả các
định nghĩa đều thống nhất về tầm quan trọng của giao diện của thành phần, và giao
diện đưa ra để cho các thành phần kết hợp không có quyền truy cập vào mã nguồn của
thành phần khác. Trong đó cũng cho thấy rằng sự khác biệt chủ yếu là quyết định xem
những thông tin nào nằm trong giao diện của thành phần.
13
Chúng tôi cũng cho rằng giao diện cho các cách thức 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 thông tin khác nhau
và có các thuộc tính khác nhau:
- Một giao diện cho một thành phần trong một hệ thống tuần tự rõ ràng là khác
với trong hệ thống trao đổi đồng thời. Từ đây yêu cầu giao diện bao gồm một
mô tả của giao thức trao đổi.
- Một giao diện cho một thành phần trong ứng dụng thời gian thực sẽ đòi hỏi
cung cấp ràng buộc thời gian của dịch vụ, trong các hệ thống không xét đến
thời gian thì không.
- Một thành phần triển khai trên di động hoặc trên Internet đòi hỏi giao diện
phải bao gồm thông tin về vị trí và địa chỉ.
- Một giao diện thành phần là không trạng thái khi thành phần đó được yêu
cầu sử dụng động và độc lập với các thành phần khác.
- Một thành phần dịch vụ có nhiều thuộc tính khác nhau từ thành phần trung
gian.
Vì vậy, giao diện là để xác định các hành vi bên ngoài và tính năng của các thành
phần và cho phép các thành phần được sử dụng như một hộp đen.

Dựa trên mô tả ở trên, chúng ta đã xem xét định nghĩa khái niệm của một giao diện
cho thành phần như là một mô tả về những gì cần thiết cho thành phần được sử dụng
trong xây dựng và duy trì hệ thống phần mềm. Các mô tả của một giao diện phải có
các thông tin về các khía cạnh như: chức năng, hành vi, các giao thức, độ an toàn, độ
tin cậy, thời gian thực, sức mạnh, băng thông, tiêu thụ bộ nhớ và các cơ chế truyền
thông. Tất cả những điều đó là cần thiết cho kết hợp các thành phần trong một kiến
trúc ứng dụng của hệ thống. Tuy nhiên, mô tả này có thể được gia tăng trong trường
hợp đòi hỏi thuộc tính mới hơn hoặc khung nhìn có thể được bổ sung khi cần thiết để
đáp ứng yêu cầu của ứng dụng.
1.2.3 Mô hình kiến trúc
Các mối quan tâm chính về lập trình trong các ứng dụng nhỏ là quan tâm đến
luồng điều khiển và cấu trúc dữ liệu. Đặc tả, thiết kế và xác minh tập trung vào thuật
toán và cấu trúc dữ liệu của chương trình.
Đối với lập trình các chương trình lớn, các mối quan tâm chính là các thành phần
và sự tích hợp đúng đắn của nó trong một bối cảnh kiến trúc. Các thiết kế kiến trúc trở
thành một vấn đề quan trọng vì nó đóng vai trò quan trọng trong giao tiếp giữa các đối
tượng hưởng lợi khác nhau, phân tích hệ thống và sử dụng lại quy mô lớn [4].
Có nhiều định nghĩa về kiến trúc phần mềm, chẳng hạn như [2,4,38,48]. Cơ sở
chung của tất cả chúng là một kiến trúc mô tả một hệ thống như phân rã cấu trúc của
14
hệ thống thành các hệ thống con và kết nối nó lại. Kiến trúc mô tả Ngôn ngữ (ADLs)
như [2, 4, 38] đã đưa ra đề xuất mô tả kiến trúc. Các yếu tố cơ bản của ADLs là những
thành phần và kết nối. ADLs cũng cung cấp các quy tắc kết nối khi đặt các thành phần
cùng nhau. Nó có chút bất lợi là chỉ có thể hiểu được bởi các chuyên gia ngôn ngữ - họ
không thể tiếp cận các chuyên gia tên miền và ứng dụng. Các ký hiệu đồ họa như
UML cũng được dùng rộng rãi bởi các nhà phát triển phần mềm để đặc tả kiến trúc
[41]. Tuy nhiên, nền tảng ngữ nghĩa cho các mô hình này dựa trên UML chưa được
thiết lập vững chắc.
Một mô tả cấu trúc của hệ thống là không đủ trong việc hỗ trợ phân tích hệ thống,
thiết kế, triển khai, xác minh và cấu hình. Nhiều ngữ nghĩa hơn là cần thiết cho một [5]

ADL. Đặc biệt, một ADL cũng nên hỗ trợ các loại sau đây:
Interaction: các giao thức tương tác và thiết bị,
Functionality và Behavior: chức năng dịch vụ, tính chất quan trọng của các
thành phần (ví dụ như an toàn và độ tin cậy),
Resources và Quality of Service: đơn vị phần cứng cần thiết, thời gian
thực, năng lượng, băng thông vv. Những chi tiết này cho phép phân tích và
đánh giá tầm quan trọng chẳng hạn như chất lượng dịch vụ.
Đó là một lợi thế lớn nếu một mô tả kiến trúc hỗ trợ việc tách các mối quan tâm và
cho phép chúng được luôn được tích hợp để phân tích hệ thống.
Một trong những thách thức lớn nhất trong CBSE chính thức là phát triển một mô
hình có hiệu quả hỗ trợ việc phân chia các quan điểm phân tích của các mối quan tâm
khác nhau, trong khi họ có thể được thống nhất liên kết hoặc kết hợp trong một quá
trình phát triển toàn bộ hệ thống.
1.2.4 Thống nhất khái niệm về phát triển phần mềm hướng thành phần
Từ xem xét các lý thuyết và các khái niệm ở trên, chúng tôi xin đưa ra khái niệm
thống nhất sau mà đa số các mô hình thừa nhận:
Phát triển phần mềm hướng thành phần (CBSE):
là hướng tới tạo ra một
chương trình mới bằng cách ghép nối các thành phần có sẵn với một chương trình
khác để tạo ra một chương trình mới với chức năng mới hoạt động tốt.
Thành phần:
có thể coi là một hộp đen chứa các dịch vụ và các dịch vụ này được
mô tả rõ ràng bởi giao diện.
Giao diện:
nhằm mô tả sự tương tác của thành phần với môi trường bên ngoài bao
gồm hành vi bên ngoài và tính năng bên trong của các thành phần.
Mô hình kiến trúc của phần mềm:
là cấu trúc trong đó bao gồm các thành phần,
các thuộc tính bên ngoài và các mối quan hệ giữa các thành phần.
15

1.3 Các lý thuyết hình thức mới nhất
Phần này đưa cái nhìn tổng quan về các mô hình dựa trên thành phần hiện nay và
tóm tắt các yêu cầu chung về các mô hình dựa trên thành phần.
1.3.1 Mô hình kiến trúc
Hầu hết các lý thuyết trước đây, chẳng hạn như [36,35,50,1,38], tập trung vào kiến
trúc hệ thống mô hình. Tất cả các mô hình của kiến trúc đối phó với sự phối hợp giữa
các thành phần, trong một phương pháp tiếp cận dựa trên sự kiện. Nó cũng có thể được
sử dụng cho đặc tả của khớp nối và phối hợp. Tuy nhiên, không đi đến thiết kế, thực
hiện và triển khai thành phần. Điều này có thể là lý do tại sao ADLs vẫn không đóng
vai trò quan trọng trong kỹ thuật phần mềm thực tế.
Gần đây, các mô hình tinh tế hơn được đề xuất để mô tả hành vi của các thành
phần và các phối hợp, chẳng hạn như [3, 17]. Reo [3] là một mô hình dựa trên kênh
giao tiếp đồng bộ. Hợp của các thành phần (và các kết nối) được định nghĩa trong điều
khoản của một vài toán tử. Mô hình này được định nghĩa bằng các toán tử và đại số
mệnh đề và mô hình mô phỏng được để hỗ trợ phân tích. Những bất lợi của cách tiếp
cận này là nó không chỉ rõ là làm thế nào để có thể được mở rộng để đối với những
vấn đề khác, chẳng hạn như thời gian hay nguồn lực. Cũng hướng sự kiện, trong mô
hình [17] xem xét một kiến trúc lớp cho các thành phần, cung cấp bởi các kết nối. Nó
xem xét các ràng buộc thời gian và phân tích qua trình lập kế hoạch. Các hành vi của
một thành phần được xác định trong một thể hiện của ôtômat thời gian. Điều này cung
cấp một mô hình cấp thấp thực hiện tốt của một thành phần. Tuy nhiên, việc sử dụng
các đồng hồ địa phương cho sự chậm trễ mô hình khó có thể được coi là dựa trên
thành phần. Chúng ta cần nói về một thành phần ở mức độ chi tiết cao hơn.
Phép tính dòng [6, 7, 54] là một khung biểu thị, nhưng không tương tự như của [3,
17] cho một mô hình dựa trên kênh dữ liệu. Nói chung một mô hình biểu thị hỗ trợ
khái niệm về phát triển từng bước của kỹ thuật làm mịn và đặc tả liên kết tốt hơn ở cấp
độ trừu tượng khác nhau. Broy cũng đề xuất một mô hình nhiều khung nhìn trong mô
hình giao diện, mô hình máy trạng thái, mô hình quy trình, mô hình phân phối và mô
hình dữ liệu [6, 7].
Những bất lợi chính của các tiếp cận dựa trên thông điệp/sự kiện là sự thay đổi của

dòng dữ liệu của một thành phần không được thể hiện trực tiếp. Trong khi đó là thế
mạnh của mô hình hành vi của các thiết bị điện tử và các giao thức trao đổi, đó không
phải là xu hướng của công nghệ phần mềm. Mối quan hệ của các mô hình này để triển
khai chương trình không rõ ràng và thực tế trong kỹ thuật thiết kế phần mềm, chẳng
hạn như các mẫu thiết kế không được hỗ trợ. Điều này dẫn đến khó khăn trong việc
tìm hiểu sự thống nhất giữa các giao thức tương tác và chức năng.
16
1.3.2 Sự cần thiết phải liên kết các phương pháp và lý thuyết
Mục tiêu lớn của CBSE là hỗ trợ phát triển độc lập của các thành phần và thiết kế
các kết cấu, phân tích và xác minh các hệ thống tổng thể.
Để đạt được mục tiêu này, điều quan trọng là phương pháp cung cấp ký hiệu cho
mô hình nhiều khung nhìn, cho phép tách các mối quan tâm và hỗ trợ mô hình hóa và
lý luận về thuộc tính ở mức độ trừu tượng khác nhau. Bản chất của đa khung nhìn và
tách các mối quan tâm cho phép chúng ta xác định một cách độc lập, mô tả và hợp các
điều kiện/khía cạnh khác nhau của sự đúng đắn [25] với những quan điểm khác nhau
của thành phần, bao gồm giao diện cú pháp, hành vi tĩnh và chức năng, hành vi động
và đồng bộ, các giao thức tương tác, thời gian và nguồn lực hạn chế vv. Chia tách là
nguyên tắc quan trọng để đảm bảo sự đơn giản của mô hình [30].
Điều quan trọng là các mô hình hỗ trợ trừu tượng với che giấu thông tin để chúng
ta có thể phát triển làm mịn và chuyển đổi kỹ thuật thiết kế dựa trên [30,6,14]. Điều
này sẽ cung cấp một nền tảng lý thuyết cho sự tích hợp của các kỹ thuật thiết kế hình
thức với các phương pháp phát triển kỹ thuật thực tế. Thiết kế theo cách này có thể bảo
toàn chính xác đến một mức độ trừu tượng nhất định và hỗ trợ sinh mã để đảm bảo
tính chính xác (tức là được chính xác trong xây dựng [39]).
Làm mịn có nét đặc trưng là thay thế một thành phần bằng một thành phần khác.
Nó liên quan đến việc thay thế của các khía cạnh, nhưng chúng tôi có thể xác định và
thực hiện làm mịn cho các tính chất khác nhau một cách riêng biệt, mà không vi phạm
tính chính xác của các mặt. Sự tích hợp của mô hình dựa trên sự kiện và trạng thái làm
mịn dựa trên đảm bảo điều kiện làm mịn toàn cục bằng làm mịn cục bộ. Làm mịn toàn
cục được quy định bằng cách ngăn chặn hành vi của hệ thống (chẳng hạn như ngữ

nghĩa thất bại phân kỳ của CSP). Làm mịn toàn cục đã được xác minh trong một cách
tiếp cận có thể hỗ trợ suy luận với sự hỗ trợ của chứng minh định lý. Làm mịn cục bộ
được quy định về tiền điều kiện và hậu điều kiện của hoạt động và xác nhận của mô
phỏng thường được hỗ trợ bởi một mô hình kiểm tra. Ngoài ra, làm mịn thể hiện trong
CBSE phải được kết hợp lại để suy luận toàn cục về hệ thống có thể được thực hiện
bằng cách suy luận cục bộ về thành phần [7].
Chúng tôi cũng sẽ làm mịn các tính toán để hỗ trợ thiết kế mở rộng và lặp, phân
tích và xác minh. Điều này rõ ràng là quan trọng để mở rộng các ứng dụng của phương
pháp này để phát triển phần mềm quy mô lớn và cho sự phát triển của công cụ hỗ trợ
hiệu quả. Chúng tôi tin là mở rộng và lặp liên quan chặt chẽ và bổ sung vào kết cấu và
quan trọng cho việc giảm khối lượng đặc tả, xác minh và làm giảm mức độ tự động
hóa [39].
Lợi điểm và điểm mạnh của các phương pháp khác nhau là để đối phó với những
khía cạnh khác nhau của hệ thống thành phần, một bản tích hợp của các phương pháp
này là cần thiết để các lý thuyết và các công cụ được liên kết để đảm bảo sự thống nhất
17
về các quan điểm khác nhau của một hệ thống. Ví dụ, các chức năng tĩnh mô tả tiền
điều kiện và hậu điều kiện, hành vi động và các giao thức tương tác phải được thống
nhất.
1.4 Giới thiệu mô hình rCOS
Những thuộc tính trên đòi hỏi thành phần phải được mô tả theo nguyên tắc hộp
đen, những dịch vụ nó cung cấp ra bên ngoài và những dịch vụ gì nó đòi hỏi từ bên
ngoài. Trong rCOS, sự cung cấp dịch vụ và yêu cầu dịch vụ dựa vào hợp đồng giao
diện bên cung cấp và hợp đồng giao diện bên yêu cầu của thành phần được tách biệt
ra. Theo đó, hợp đồng với nhau giữa giao diện của thành phần cung cấp đặc tả hộp
đen. Mô hình hợp đồng trong rCOS cũng định nghĩa mô hình ngữ nghĩa hợp nhất của
việc triển khai giao diện trong các ngôn ngữ lập trình khác nhau, như vậy sẽ hỗ trợ tối
đa khả năng cùng hoạt động của thành phần và phân tích tính chính xác với sự chú ý
đến hợp đồng giao diện. Lý thuyết về hợp đồng và thành phần trong rCOS mô tả khả
năng thay thế của thành phần, tối đa hóa hỗ trợ việc phát triển độc lập của các thành

phần. Các bố trí được định nghĩa trong rCOS cho tập giao diện cung cấp của một
thành phần giao diện để đáp ứng yêu cầu của thành phần khác, tên được ẩn và thay đổi
đối với giao diện về hoạt động của thành phần [11, 20].
Mặc dù, không có sự mô tả chính xác đối với chương trình mới mà có khả năng
cung cấp cả sự kết dính giữa các thành phần và các chức năng mới. Trong phần này,
chúng tôi sẽ giới thiệu những khái niệm của quá trình bên trong rCOS. Giống như
thành phần, quá trình có giao diện là các biến cục bộ và các phương thức, các hành vi
của nó được chỉ rõ bởi quá trình hợp đồng. Không giống như thành phần thụ động chờ
các client gọi các dịch vụ nó cung cấp, quá trình chủ động có các điều khiển khi gọi ra
bên ngoài hoặc chờ đáp ứng dịch vụ. Với những quá trình chủ động, không có sự tách
biệt giữa hợp đồng do giao diện của nó cung cấp hay do giao diện của nó yêu cầu, bởi
vì không có sự tách biệt đặc tả gọi ra ngoài hay gọi vào. Để dễ dàng, nhưng không mất
tính thuyết phục, chúng tôi cho rằng những quá trình như Java thread không cung cấp
dịch vụ và chỉ gọi các thao tác cung cấp bởi thành phần. Bởi vậy, quá trình chỉ giao
tiếp qua các thành phần được chia sẻ. Giữa 2 quá trình sẽ được chèn vào thành phần
kết nối và từ đó tạo ra một quá trình mới.
Đặt C là tập hợp song song của các thành phần Ci, i =1, ,k. Sự liên kết của
chương với C đó là quá trình P tạo lời gọi đến các phép toán trong tập X được cung
cấp bởi C. Kết cấu song song của C và P được định nghĩa tương tự như
ký pháp song song trong CSP.
Thành phần cấu tạo kết dính được định nghĩa nhờ sự bỏ qua cách thức song song
giữa thành phần C và quá trình P. Chúng ta coi
x
XCP \||
là một thành phần. Chúng ta
sẽ nghiên cứu đại số mệnh đề của cấu tạo quy trình cũng như thành phần.
x
CP ||
18
Các chương trình ứng dụng sẽ được biểu diễn thành tập các quá trình song song

nhằm sử dụng các dịch vụ được cung cấp bởi thành phần. Như vậy các quá trình chỉ có
thể tương tác với các thành phần qua giao diện đưa ra, khả năng cùng hoạt động được
cung cấp như các hợp động được định nghĩa bởi ngôn ngữ chung mô tả giao diện (IDL
- interface description language), mặc dù các thành phần, sự kết dính giữa chương
trình và thành phần không được thực thi trên cùng một ngôn ngữ. Phân tích và xác
thực các ứng dụng có thể được thực thi trên cơ sở hình thức trên từng mức hợp đồng
của thành phần thay vì khi thực hiện thành phần. Phân tích và xác thức có thể sử dụng
lại và chứng minh các thuộc tính của thành phần, ví dụ như sự phân chia quyền tự thực
hiện hoặc không tự thực hiện của việc thực thi thành phần, không cần thiết phải chứng
minh lại chúng.
1.5 Kết luận
Một số các ký hiệu chính thức và lý thuyết đã được thiết lập và chứng tỏ như là
công cụ hiệu quả để xử lý các khía cạnh khác nhau của hệ thống máy tính. Kỹ thuật
mô phỏng hoạt động và các công cụ kiểm chứng mô hình được cho là hiệu quả cho
việc kiểm tra tính đúng đắn, nhất quán và làm mịn các giao thức tương tác, trong khi
xác minh dựa theo suy luận và chứng minh định lý được tìm ra tốt hơn thích hợp cho
các lý luận về đặc tả biểu thị các chức năng. Trong CBSE, phân tích và xác minh của
các khía cạnh khác nhau của tính đúng đắn và do đó có thể được thực hiện bởi các kỹ
thuật và công cụ khác nhau. Tuy nhiên, tích hợp của các thành phần đòi hỏi sự tích
hợp của các phương pháp để đảm bảo các khía cạnh khác nhau về tính đúng đắn và
khả năng thay thế. Sự tích hợp đòi hỏi một mô hình thực hiện cơ bản của các hệ thống
phần mềm thành phần.
Một thành phần không thể có được thiết kế và thực hiện trong một nền tảng hướng
đối tượng. Tuy nhiên, những công nghệ thành phần hiện nay như COM, CORBA, và
Enterprise JavaBeans được xây dựng dựa trên lập trình hướng đối tượng. Các ngôn
ngữ hướng đối tượng đang sử dụng rộng rãi trong các ứng dụng và nhiều người sử
dụng thì sự an toàn là quan trọng. Điều này dẫn đến sự cần thiết phải nghiên cứu kỹ
thuật của mô hình, thiết kế và xác minh của hệ thống đối tượng và xây dựng hệ thống
thành phần trên các hệ thống hướng đối tượng.
Cũng như sự thống nhất các lý thuyết lập trình thủ tục và lập trình hướng đối

tượng, sự thống nhất của lý thuyết hướng thành phần sẽ đạt được trong một thời điểm
không xa [23, 33, 21].
19
CHƯƠNG 2: ĐỀ XUẤT MÔ HÌNH GIAO DIỆN THÀNH PHẦN VÀ
PHƯƠNG PHÁP LUẬN PHÁT TRIỂN CHO CÁC HỆ THỐNG THỜI
GIAN THỰC
Nhằm đóng góp vào lý luận cho mô hình phát triển hướng thành phần, chúng tôi
đưa ra một mô hình của các giao diện các thành phần cho các hệ thống hướng thành
phần thời gian thực. Chúng tôi mở rộng đặc tả của phương thức với ràng buộc thời
gian, đó là mối quan hệ giữa sự tài nguyên sẵn có và lượng thời gian dành để thực hiện
phương thức. Chúng tôi định nghĩa hợp đồng bao gồm các đặc tả phương thức và định
nghĩa một thành phần như là một sự thực thi của hợp đồng. Sự thực thi có thể yêu cầu
dịch vụ từ các thành phần khác với một số ràng buộc về lịch cho việc sử dụng các chia
sẻ về phương thức và tài nguyên với sự có mặt đồng thời. Mô hình của chúng tôi hỗ
trợ sự phân chia giữa yêu cầu là hàm và không phải là hàm, và cho phép xác minh tính
đúng đắn của hệ thống dựa trên thành phần thời gian thực.
2.1 Giới thiệu
Sử dụng lại là một trong những ưu điểm của phương pháp phát triển dựa trên
thành phần. Tuy nhiên, khi thêm thuộc tính thời gian vào các đặc tả của một thành
phần, số lượng các thành phần có thể dùng lại sẽ giảm đi nếu nó không được xây dựng
linh hoạt. Điều này thường đúng với các hệ thống nhúng thời gian thực, nơi các thành
phần dựa trên một phần cứng cụ thể. Nếu các đặc tả thời gian của một thành phần là ấn
định cho một phần cứng thì thành phần đó sẽ không thể sử dụng cho các phần cứng
khác. Hơn nữa, yêu cầu về thời gian thực của một hệ thống dựa trên thành phần không
những đòi hỏi trong các thành phần riêng lẻ mà còn trong các hệ thống tích hợp các
thành phần. Để tăng tính linh hoạt cho các đặc tả thời gian của thành phần, chúng tôi
xác định thời gian của mỗi phương thức như một mối quan hệ giữa thời gian để thực
hiện phương thức và các nguồn lực cung cấp cho thành phần. Việc thực hiện một
phương thức có thể phụ thuộc vào các dịch vụ từ các thành phần khác, chính điều này
có thể loại trừ lẫn nhau khi có sự xuất hiện đồng thời. Vì vậy, để đảm bảo dịch vụ thời

gian thực, thành phần cần một ràng buộc về hành vi thời gian thực của sự tương tác
của các thành phần trong hệ thống cũng như lịch trình cho các dịch vụ của hệ thống.
Để nắm bắt những loại ràng buộc chúng tôi giới thiệu một bất biến lịch trình về các
đặc tả của giao diện thành phần. Sau đó, các thành phần có thể cung cấp dịch vụ đúng
chỉ khi bất biến này thỏa mãn. Trong các nghiên cứu trước đây nói rất nhiều về giao
diện thành phần, nhưng không nhiều trong số đó có tính đến các đặc tả thời gian.
Trong phần này, chúng tôi đề xuất một mô hình cho các hệ thống thành phần dựa
trên ý tưởng này bằng cách sử dụng các ký hiệu từ UTP. Với các đặc tả thời gian thực
linh hoạt đối với các phương thức, với ràng buộc cho các thành phần tương tác như
giao diện bất biến lịch trình, mô hình của chúng tôi hỗ trợ việc kiểm chứng hình thức
20
về thành phần và tạo điều kiện cho việc phân tích lịch biểu các hệ thống thời gian thực
dựa trên thành phần. Việc kiểm chứng hình thức cho các ứng dụng cần sự an toàn
đóng vai trò rất quan trọng, nhưng điều đó rất khó thực hiện ngay cả có sự hỗ trợ của
các công cụ. Do đó, khả năng tích hợp sẽ giúp giảm sự phức tạp và khuyến khích việc
thực hiện kiểm chứng hình thức.
Trong chương này được tổ chức như sau: trong mục 2.2, chúng tôi trình bày mô
hình hình thức của chúng tôi cho các giao diện thành phần thời gian thực và thành
phần. Sau đó, trong mục 2.3 chúng tôi đề xuất một ngữ nghĩa hình thức của nhiệm vụ
đồng thời trong các thành phần chủ động. Mục 2.4 trình bày mô hình kiến trúc và cách
thức để xây dựng thành phần. Mục cuối cùng là kết luận và những hướng nghiên cứu
dựa trên mô hình này.
2.2 Mô hình hóa đặc tả giao diện của thành phần
Một thành phần cung cấp dịch vụ cho khách hàng, các dịch vụ có thể là dữ liệu
hoặc các phương thức. Để xác định các thuộc tính thời gian của một phương thức một
cách linh hoạt, chúng ta giả định một tập hợp các biến là số nguyên
{ }
n
resresRES , ,
1

=
. Biến
i
res
đại diện cho một kiểu tài nguyên và giá trị của nó đại
diện cho số lượng các tài nguyên kiểu đó sử dụng cho thành phần. Một phương thức sẽ
có một đặc tả về tài nguyên để chỉ ra các yêu cầu về tài nguyên khi nó thực thi, đó sẽ
là một vị từ trên các biến số nguyên của RES. Một phương thức sẽ cần một thời gian
để thực hiện và lượng thời gian này phụ thuộc vào kiểu và số lượng các nguồn lực sẵn
có. Chúng tôi đề xuất một biến thời gian

đại diện cho lượng thời gian thực hiện của
một phương thức. Giá trị của

cho một phương thức phải thoả mãn một số điều kiện
khi sự thực thi của phương thức chấm dứt. Điều kiện này thể hiện như một vị từ trên
biến

, những biến tài nguyên và những biến đầu vào cho phương thức.
Định nghĩa 1 (Giao diện): Một giao diện
MdFdI ,=
bao gồm
• Fd - một khai báo biến là một tập hợp các biến
• Md - một khai báo phương thức là một tập hợp các phương thức; mỗi
phương thức
Mdm∈
có dạng op(in, out), trong đó in và out là tập các biến.
Một phương thức trong một giao diện được quy định bởi một "thiết kế thời gian"
là
,,FP FR

α
, với α biểu thị cho tập các biến sử dụng cho phương thức, FP biểu thị
đặc tả hàm, và FR biểu thị đặc tả không phải hàm của phương thức. Chúng ta thực
hiện theo như trong [31] để đại diện cho FP và FR (như trong lý thuyết UTP được đề
xuất bởi He và Hoare [24]):
• FP là một vị từ có dạng

21
Trong đó p là tiền điều kiện của phương thức với giá trị khởi tạo về các biến
nằm trong tập
out\
α
với giả định p được các phương thức sử dụng khi hoạt
động. R là hậu điều kiện liên quan tới các giá trị ban đầu đến các kết quả
cuối cùng (thể hiện bởi các biến trong
( )
{ }
outinxx ∪∈
′
\
α
và các biến vào
ra). Biến logic ok là một biến đặc biệt thể hiện trạng thái của phương thức,
ok là đúng khi và chỉ khi phương thức đã bắt đầu và
ko
′
là đúng khi và chỉ
khi phương thức này kết thúc. Chúng tôi sử dụng các chỉ số f trong
f


để
phân biệt nó với
n

, trong đó f là viết tắt của hàm và n là không phải hàm.
Chúng tôi mượn những ký hiệu
=
ˆ
từ phương pháp B cho các định nghĩa sau
tên.
• FR là một vị từ có dạng
SqSq
n
⇒=
ˆ


Trong đó q là tiền điều kiện nguồn lực trong các giao diện của phương thức
với giả định các nguồn lực này sẽ sử dụng trong thức và được thể hiện như
là một vị từ về các biến trong RES. S là hậu điều kiện về thời gian của
phương thức có liên quan đến

lượng thời gian thực hiện và các nguồn lực
được sử dụng cho phương thức này. S được thể hiện như một vị từ về các
biến trong RES,
α
và

.
Định nghĩa của FP trong một thiết kế

,,FP FR
α
có tính tới yếu tố thời gian là
dựa theo thuyết UTP (Unifying Theory of Programming). Ví dụ để minh họa ý nghĩa
đối với FR.
Cho
{ }
yx,
ˆ
=
α
,
2
0
ˆ
f
FP x y x=≥→ =

( ) ( )( )
005.00133001.011331226133
ˆ
≤⇒=∧≤⇒==+=  PPPPFR
r
.
Trong đó
FRFP,,
α
là thể hiện cho một thiết kế tính tới yếu tố thời gian để
tính toán
xp =

với x không âm, trong đó mất không quá 0.001 đơn vị thời gian khi
thực hiện bởi một bộ xử lý 133Mhz và mất không quá 0.0005 đơn vị thời gian khi thực
hiện bởi một bộ xử lý 266Mhz.
2.2.1 Làm mịn của các thiết kế xét đến yếu tố thời gian
Định nghĩa về mối quan hệ làm mịn các thiết kế có tính tới yếu tố thời gian chỉ là
một phần mở rộng của thiết kế đã được trình bày trong UTP và cũng như trong [31].
Một thiết kế có xét đến thời gian
111
,, FRFPD
α
=
được làm mịn từ thiết kế
222
,, FRFPD
α
=
(ký hiệu
12
DD
) nếu:

22
Trong đó
υ
,
υ
′
là các vector của các biến chương trình và r là vector ký hiệu cho
các biến tài nguyên,
( )

1
, ,
n
r res res=
. Phần đầu của biểu thức trên là để nói rằng các
hàm của
2
D
là một sự làm mịn của các hàm của
1
D
như trong [31]. Phần thứ hai của
biểu thức chỉ đơn giản nói rằng nếu các yêu cầu không phải hàm của
2
D
thỏa mãn thì
yêu cầu không phải hàm của
1
D
cũng thỏa mãn. Do đó,
2
D
có thể cài đặt từ
1
D
.
2.2.2 Thành phần tuần tự
Cho
1 11
,,D FP FR

α
=
và
2 22
,,D FP FR
α
=
là các thiết kế có yếu tố thời gian. Thì
1; 2 , ,
ˆ
D D FP FR
α
=
,
Trong đó:
• Cho
11
()FP FP
υ
′
=
và
22
()FP FP
υ
′
=
. Thì
12
() ()

ˆ
FP m FP m FP m=∃• ∧

•
[ ] [ ]
12 11 2 2 1 2
,( / / )
ˆ
FR FR FR=∃ • ∧ ∧= +       
.
Từ đây về sau, chúng ta sử dụng ký hiệu
[ ]
1
/Fx x
để thể hiện kết quả của từ sự
thay thế của
1
x
cho x trong biểu thức F. Lưu ý rằng chúng ta giả định là tất cả các
nguồn lực không được tiêu thụ. Do đó các nguồn tài nguyên cùng được sử dụng cho
1
D
có thể được tái sử dụng cho
2
D
khi
1
D
đã kết thúc.
2.2.3 Kết nối các thành phần song song

Cho
1 11 1
,,D FP FR
α
=
và
2 22 2
,,D FP FR
α
=
là thiết kế có yếu tố thời gian. Giả sử
12
αα
∩=∅
, thì
12
,,
ˆ
D D FP FR
α
=
,
Trong đó:
•
12
ˆ
αα α
= ∪
,
12

ˆ
FP FP FP= ∧

•
[ ] [ ]
{ }
1212 11 1 2 2 2 12 1 2
, ,, ( /, / /, / ax , )
ˆ
FR r r FR r r FR r r m r r r=∃ • ∧ ∧= ∧= +      
, trong đó
1
r
và
2
r
là các vector của các biến tài nguyên.
Điều kiện
12
rrr= +
thể hiện rằng số lượng các nguồn lực đủ để thực hiện
1
D
và
2
D

song song độc lập. Lệnh kết thúc khi cả hai thành phần kết thúc. Để kiểm chứng cho
hai định nghĩa, chúng ta có thể sử dụng ngữ nghĩa hoạt động cho các chương trình
được định nghĩa như là một hệ thống chuyển tiếp có nhãn

( )
,,SC→
, trong đó mỗi
trạng thái
sS∈
là một bộ dữ liệu (v, r, t), v là một vector giá trị của các biến chương
trình, r là một vector giá trị của các biến tài nguyên và t là một số thực để chỉ ra thời
gian thực. C là một tập các lệnh. Ngữ nghĩa của
cC∈
được thiết kế
,,FP FR
α
, trong
23
đó
f
FP p R= 
và
rn
FR p S= 
. Có quá trình chuyển tiếp
( ) ( )
,, , ,
c
vrt v r t
′′′
→
nếu
() (, ) () (,,, )
r

pv Rvv r r p r t t S rvv
′′ ′ ′
∧ ∧ = ∧ ∧ = −∧
tuân theo sự diễn dịch của thiết kế.
Xác định thành phần song song và thành phần tuần tự một cách rõ ràng trong hệ thống
chuyển tiếp trùng với định nghĩa ở trên. Rõ ràng là giống như cho các thiết kế chưa
tính thời gian:
Định lý 1. Mối quan hệ làm mịn

của các thiết kế kết hợp song song và thiết kế
kết hợp tuần tự có xét yếu tố thời gian là tuân theo các quy tắc như thiết kế không xét
đến yếu tố thời gian.
Định nghĩa 2 (Hợp đồng có yếu tố thời gian). Hợp đồng có tính tới yếu tố thời
gian là một bộ
,, , ,I Rd MSpec Init Inv
, trong đó
•
,I Fd Md=
là giao diện
• Rd – một khai báo tài nguyên, đó là một tập con của RES
• Init là một giá trị khởi tạo, đó là sự kết hợp mỗi biến trong Fd và biến địa
phương có giá trị cùng loại, một biến trong Rd với một số nguyên
• Mspec là đặc tả của một phương thức được kết hợp giữa phương thức op(in,
out) trong Md với một thiết kế có tính tới yếu tố thời gian
,,FP FR
α
, trong
đó
( )
( )

\ in out Fd
α
∪⊆

• Inv là một vị từ về các thuộc tính trong hợp đồng (được gọi là tính bất biến
của hợp đồng). Inv đại diện cho các thuộc tính bất biến về giá trị của các
biến trong bảng khai báo thuộc tính của Fd, từ đó có thể dựa vào đó để truy
cập từ bên ngoài. Do đó, Inv là sự thỏa được đặc biệt của Init.
Chúng tôi muốn nhấn mạnh ở đây là các biến tài nguyên khai báo trong Rd chỉ
được sử dụng trong nội bộ hợp đồng và thành phần. Còn Inv trong hợp đồng thể hiện
tính chất của các biến của hợp đồng mà nó cung cấp cho môi trường. Trong trường
hợp hợp đồng không có bất cứ thuộc tính bất biến nào, Inv sẽ có giá trị là True.
Định nghĩa 3 (Làm mịn hợp đồng). Hợp đồng xét đến thời gian
1 1 1 1 1 11
, ,, , ,Ctr Fd Md Rd MSpec Init Inv=
được làm mịn từ
2 2 2 2 2 22
, ,, , ,Ctr Fd Md Rd MSpec Init Inv=
(ký hiệu
12
Ctr Ctr

) nếu:
•
12
Fd Fd⊆
,
12
Rd Rd⊆
, và

21 11
Init Fd Init Fd=
,
21 11
Init Rd Init Rd≤
(trong
đó mỗi hàm
f
,
1
f
,
2
f
và một tập A,
|fA
ký hiệu sự giới hạn của
f
trên A,
và
12
ff≤
ký hiệu rằng
1
f
và
2
f
có cùng miền và
( ) ( )

12
fx fx≤
với mọi x
trong miền đó),
•
12
Md Md⊆
,
• Với mọi phương thức op khai báo trong
1
Md

24
( ) ( )
12
Mspec op Mspec op
, và
21
Inv Inv⇒
.
Xin được giải thích định nghĩa này như sau.
2
Ctr
cung cấp tất cả các dịch vụ mà
1
Ctr
cung cấp và ngoài ra còn có thể có thêm các dịch vụ khác.
2
Ctr
có tất cả các tài

nguyên mà
1
Ctr
có. Quy định
21
Inv Inv⇒
nói lên rằng tất cả các thuộc tính của các biến
được đảm bảo bởi
1
Ctr
cũng được đảm bảo bởi
2
Ctr
. Do đó có thể dùng
2
Ctr
thay thế
cho
1
Ctr
mà không mất đi dịch vụ nào.
Cho
, ,, ,
i i ii i i
Ctr Fd Md Rd Mspec Init=
, i = 1, 2 là hợp đồng có yếu tố thời gian trong
đó có các bộ tương thích với các thuộc tính và phương thức, tức là
12
f Fd Fd
∈∩

kéo
theo
( ) ( )
12
Init f Init f=
và
12
op Md Md∈∩
kéo theo
( ) ( )
12
MSpec op MSpec op⇔
. Sự
kết hợp
12
Ctr Ctr∪
được định nghĩa như sau:
( )
( )
12 121 212 1 21 212
, ,, , , ,Ctr Ctr Fd Fd Md Md Rd Rd Mspec Mspec Init Init Inv Inv∪= ∪ ∪ ∪ ∪ ∧
trong đó
( )( )
12
Init Init x
được định nghĩa
( ) ( )
{ }
( ) ( )
( ) ( ) ( )

( ) ( ) ( )
12 1 2
1 12
2 21
max ,
\
\
Init x Init x if x dom Init dom Init
Init x if x dom Init dom Init
Init x if x dom Init dom Init

∈∩


∈


∈



Khi
12
Ctr Ctr∪
được định nghĩa, chúng ta nói rằng
1
Ctr
và
2
Ctr

có thể kết hợp với
nhau được. Lưu ý rằng khi kết hợp hai hợp đồng, số tài nguyên có sẵn cho thành phần
kết hợp được định nghĩa là tối đa của hợp đồng thành phần. Định nghĩa này phản ánh
quan điểm của chúng tôi là một phương thức trong hợp đồng kết hợp có ít nhất việc
thực hiện như nó có trong các hợp đồng thành phần và tính đúng đắn được thỏa mãn.
Tính đúng đắn có nghĩa là việc thực thi sẽ tốt hơn nếu nhiều tài nguyên được cung cấp
hơn và được mô hình hóa như sau:
Một thiết kế thời gian
,,FP FR
α
thỏa mãn tính đúng đắn nếu FR thỏa mãn
[ ] [ ]
( )
( )
11 1
, • / /r r r r FR r RES FR r RES∀ ≥⇒ ⇒
,
Trong đó r và
1
r
là vector của các giá trị của các biến tài nguyên (nhớ lại rằng RES
là vector của các biến tài nguyên và FR là một mối quan hệ trên RES,

và α). Để định
nghĩa về sự làm mịn của hợp đồng có xét đến thời gian có ý nghĩa, chúng tôi giả định
rằng tất cả các thiết kế thời gian cho các đặc tả của hợp đồng cũng được hình thành.
Định lý 2. Cho
1
Ctr
,

2
Ctr
là hợp đồng thời gian có thể kết hợp được trong đó đặc
tả của tất cả các phương thức là đúng đắn thì
12

i
Ctr Ctr Ctr∪
với i = 1, 2.
25
Chứng minh. Bằng cách kiểm tra trực tiếp từ sự đúng đắn của các đặc tả kỹ thuật
cho các phương thức và định nghĩa về sự làm mịn của thiết kế có xét đến thời gian.
Bây giờ chúng tôi muốn hình thức hóa các khái niệm về thành phần. Theo trực
giác, một thành phần thụ động là thực thi một hợp đồng sử dụng dịch vụ từ các thành
phần thụ động khác thông qua hợp đồng của nó. Để đơn giản, chúng tôi không giới
thiệu các khái niệm về phương thức riêng và các đặc tính riêng mà sử dụng với kiến
trúc đơn giản với mô hình client/server và thông tin liên lạc đồng bộ. Mô hình của
chúng tôi có thể được mở rộng cho trường hợp tổng quát dễ dàng. Trong phần này sẽ
tập trung vào các phương pháp thời gian thực. Việc thực hiện một phương thức có thể
gọi các phương thức khác trong các thành phần khác. Các lời gọi các phương thức
trong thành phần khác có thể cần một khoảng thời gian để xử lý việc sử dụng đồng
thời của các phương thức. Điều này là bởi khi có cuộc gọi đồng thời với một phương
thức, hệ thống cần một lịch trình tiến độ sử dụng của các phương thức, mà có thể buộc
một lời gọi phải chờ. Chúng tôi giả định rằng có một lịch trình trong hệ thống. Điều
này có thể được lên lịch tập trung hay phân tán. Chúng tôi cố gắng để kết hợp chỉ có
các thông tin cần thiết về lịch trình các thành phần bằng cách sử dụng lịch trình bất
biến Sinv. Như với các thiết lập của tên tài nguyên, chúng tôi cố định một tập hợp các
biến toàn cục Π được sử dụng bởi lịch trình này. Mỗi
v∈Π
có thể tương ứng với một

lời gọi từ một thành phần C cho một dịch vụ từ một thành phần Q. Các lịch trình sử
dụng các biến trong Π để lập lịch cho các lời gọi từ các thành phần dựa trên các lịch
trình bất biến Sinv. Chúng tôi cũng giới thiệu một tập hợp Dep của các tên thành phần
trong khai báo của một thành phần Comp. Dep là một tập hợp hữu hạn các thành phần
phụ thuộc vào Comp. Ý tưởng là khi thực hiện một phương thức op trong Comp có
một lời gọi đến một phương thức trong một thành phần C sau đó gọi này phải được gửi
đến các lịch trình để lên lịch. Căn cứ lịch trình về các yêu cầu hiện tại để giải quyết bất
kỳ cuộc xung đột và có thể buộc một số lời gọi phải chờ một thời gian nhất định.
2.2.4 Thành phần thụ động
Định nghĩa 4 (Thành phần thụ động). Một thành phần thụ động thời gian thực là
một bộ
, , , , Comp Ctr Dep SDep Mcode SInv=
,
Trong đó Comp là tên để nhận diện thành phần, bao gồm
• Hợp đồng
, ,, , ,Ctr Fd Md Rd Mspec Init Inv=
.
• Tập Dep chứa các tên của thành phần, mỗi phần tử trong Dep là tên của
thành phần mà Comp phụ thuộc vào.
• SDep là tập các biến trong Π (biểu thị sự tương tác với lịch trình).
• SInv là một vị từ trên các biến
v SDep∈
( để thể hiện các giả định về thông
tin mà bộ lịch trình có thể dựa vào khi phương thức Comp được gọi tới).