Ứng dụng của spin để kiểm chứng sự tuân thủ thể thức tương tác của chương trình

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






HOÀNG VĂN THỦY





ỨNG DỤNG CỦA SPIN ĐỂ KIỂM CHỨNG SỰ TUÂN THỦ
THỂ THỨC TƯƠNG TÁC CỦA CHƯƠNG TRÌNH







LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

Hà Nội – 2014

2

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






HOÀNG VĂN THỦY





ỨNG DỤNG CỦA SPIN ĐỂ KIỂM CHỨNG SỰ TUÂN THỦ
THỂ THỨC TƯƠNG TÁC CỦA CHƯƠNG TRÌNH

Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số:
60480103

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN




NGƯỜI HƯỚNG DẪN KHOA HỌC: TIẾN SĨ ĐẶNG VĂN HƯNG







Hà Nội – 2014

1

LỜI CẢM ƠN
Trước hết tôi xin bày tỏ lòng biết ơn sâu sắc và gửi lời cảm ơn đặc biệt
nhất tới Thầy TS. Đặng Văn Hưng, người đã định hướng đề tài, cung cấp cho tôi
những kiến thức, những tài liệu và tận tình hướng dẫn chỉ bảo tôi trong suốt quá
trình thực hiện đề tài luận văn cao học này, từ những ý tưởng trong đề cương
nghiên cứu, phương pháp nghiên cứu, phương pháp giải quyết vấn đề cho đến
những lần kiểm tra cuối cùng để hoàn thành luận văn này.
Tôi xin bày tỏ lòng biết ơn chân thành tới Thầy, Cô giáo trong bộ môn Kỹ
thuật phần mềm, Khoa Công nghệ thông tin, những người đã mang trí tuệ, công
sức truyền đạt giúp tôi mở rộng kiến thức về Công nghệ thông tin nói chung và Kỹ
thuật phần mềm nói riêng, đó là những kiến thức quý báu và sẽ rất có ích với tôi

trong giai đoạn hiện tại và tương lai.
Tôi xin gửi lời cảm ơn chân thành tới Ban Giám hiệu Nhà trường, Phòng
Đào tạo sau đại học, Đại học Công nghệ - Đại học Quốc gia Hà Nội đã tạo điều
kiện tốt nhất giúp tôi trong suốt quá trình học tập.
Cuối cùng tôi xin gửi lời cảm ơn đến gia đình, bạn bè những người đã luôn
động viên khuyến khích tôi trong suốt quá trình học tập cũng như thực hiện đề tài
luận văn của mình.
Hà Nội, ngày 08 tháng 11 năm 2014
Học viên


Hoàng Văn Thủy
















2

LỜI CAM ĐOAN


Tôi xin cam đoan nội dung trình bày trong luận văn này là do tôi tự nghiên
cứu tìm hiểu dựa trên các tài liệu và tôi trình bày theo ý hiểu của bản thân dưới sự
hướng dẫn trực tiếp của Thầy TS. Đặng Văn Hưng. Các nội dung nghiên cứu, tìm
hiểu và kết quả thực nghiệm là hoàn toàn trung thực.
Luận văn này của tôi chưa từng được ai công bố trong bất cứ công trình nào.
Trong quá trình thực hiện luận văn này tôi đã tham khảo đến các tài liệu
của một số tác giả, tôi đã ghi rõ tên tài liệu, nguồn gốc tài liệu, tên tác giả và tôi
đã liệt kê trong mục “DANH MỤC TÀI LIỆU THAM KHẢO” ở cuối luận văn.
Học viên


Hoàng Văn Thủy

3

MỤC LỤC
LỜI CẢM ƠN 1
LỜI CAM ĐOAN 2
MỤC LỤC 3
DANH MỤC HÌNH VẼ 5
DANH MỤC BẢNG 5
CHƯƠNG 1. MỞ ĐẦU 6
1.1. ĐẶT VẤN ĐỀ 6
1.2. NỘI DUNG VÀ MỤC ĐÍCH NGHIÊN CỨU 7
1.3. GIẢ THUYẾT KHOA HỌC 7
1.4. CẤU TRÚC CỦA LUẬN VĂN 8
CHƯƠNG 2. CƠ SỞ LÝ THUYẾT 9
2.1. Công nghệ phần mềm dựa trên thành phần 9
2.2. Lịch sử phát triển của công nghệ phần mềm dựa trên thành phần 10
2.3. Xây dựng hệ thống dựa trên thành phần 10
2.3.1. Thành phần phần mềm 10
2.3.2. Xác định thành phần 12
2.3.2.1. Dùng lại 12

2.3.2.2. Phát triển mới 12
2.3.2.3. Thích nghi 12
2.3.2.4. Cập nhật thành phần 13
2.4. Lợi ích của công nghệ phần mềm dựa trên thành phần 13
2.6. Mô hình hóa giao diện thành phần 15
2.6.1. Giao diện 15
2.6.2. Vai trò giao diện 15
2.6.3. Đặc tả giao diện với một số ngôn ngữ cơ sở 15
2.6.4. Đặc tả giao diện với các ràng buộc cơ sở 17
2.7. Kết luận 26
CHƯƠNG 3. BỘ CÔNG CỤ KIỂM CHỨNG MÔ HÌNH SPIN VÀ BÀI TOÁN
DEADLOCK 28
3.1. Kiểm duyệt mô hình 28
3.1.1. Tổng quan hoạt động của kiểm duyệt mô hình 29
3.1.2. Quá trình hoạt động của kiểm duyệt mô hình 30
3.1.3. Ưu, nhược điểm của kiểm duyệt mô hình 30
3.2. Bộ công cụ SPIN 31
3.2.1. Tổng quan về SPIN 31
3.2.2. Cấu trúc của SPIN 31
3.2.3. Công cụ ISPIN 33
3.3. Ngôn ngữ Promela 35
3.3.1. Tổng quan về Promela 35
3.3.2. Chương trình Promela 35
3.3.3. Tiến trình 36
3.3.4. Tiến trình Init và Run 37
3.3.5. Biến trong Promela 37
3.3.6. Kiểu dữ liệu trong Promela 38
3.3.6.1. Kiểu dữ liệu cơ bản 38
3.3.6.2. Kiểu dữ liệu có cấu trúc 38
3.3.7. Toán tử, dịnh danh, hằng và biểu thức 39

3.3.8. Câu lệnh trong Promela 40
3.3.9. Các cấu trúc điều khiển 41
3.3.9.1. Câu lệnh điều kiện IF 41
4

3.3.9.2. Câu lệnh lặp DO 42
3.3.10. Đan xen (interleaving) 43
3.3.11. Cấu trúc atomic 44
3.3.12. Kênh trong Promela 45
3.3.12.1. Biến kênh 46
3.3.12.2. Kênh gặp (rendezvous) 46
3.3.12.3. Kênh đệm (Buffer) 47
3.4. Bài toán deadlock trong SPIN 48
3.5. Kết luận 50
CHƯƠNG 4. KIỂM CHỨNG SỰ TUÂN THỦ THỂ THỨC TƯƠNG TÁC CỦA CHƯƠNG
TRÌNH BẰNG SPIN 52
4.1. Phương pháp 52
4.2. Áp dụng 53
4.3. Kết luận 61
CHƯƠNG 5. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 62
5.1. Kết luận 62
5.2. Hướng phát triển. 62
DANH MỤC TÀI LIỆU THAM KHẢO 63
PHỤ LỤC 65

5

DANH MỤC HÌNH VẼ

Hình 2.1. Tổng quan thiết kế phần mềm dựa trên thành phần 9
Hình 2.2. Kiến trúc hệ thống của phần mềm hướng thành phần 11
Hình 2.3. Mô hình phát triển phần mềm dựa trên thành phần 14
Hình 2.4. Mô hình truyền thông 22
Hình 3.1. Sơ đồ tổng quan của kiểm duyệt mô hình 29
Hình 3.2. Cấu trúc mô hình kiểm chứng SPIN 32
Hình 3.3. Giao diện ISPIN soạn thảo mã nguồn mô hình kiểm chứng 33
Hình 3.4. Thiết lập thông số khi thực hiện Simulate/Replay. 34
Hình 3.5. Thiết lập thông số Verification để kiểm chứng. 34
Hình 3.6. Mô hình gửi và nhận thông điệp trên kênh gặp (rendezvous) 47
Hình 3.7. Mô hình gửi và nhận thông tin trên kênh đệm (Buffer) 47
Hình 3.8. Báo cáo deadlock và vi phạm của chương trình guinhan 50
Hình 4.1 Automat mô tả giao thức của thành phần quản lý cơ sở dữ liệu. 52
Hình 4.2 Automat mô tả giao thức tương tác của thành phần môi trường có biểu
thức chính quy là or*w*ct 55

Hình 4.3 Automat mô tả thể thức của thành phần môi trường có biểu thức chính
quy là or*w*rct. 55
Hình 4.4 Automat thể hiện các trạng thái của tiến trình pro. 57
Hình 4.5 Automat thể hiện các trạng thái của tiến trình user1. 58
Hình 4.6. Kết quả khi chạy mô phỏng tương tác giữa pro và user1 58
Hình 4.7. Kết quả sau khi Run verification (thể hiện sự tuân thủ thể thức tương tác
của chương trình sau khi chạy mô phỏng trên ISPIN) 59
Hình 4.8 Automat thể hiện các trạng thái của tiến trình user2. 60
Hình 4.9. Kết quả khi chạy mô phỏng tương tác giữa pro và user2 60
Hình 4.10. Kết quả sau khi Run verification (thể thức của thành phần không tuân
thủ thể thức của chương trình sau khi chạy mô phỏng trên ISPIN). 61





DANH MỤC BẢNG


Bảng 3.1 Kiểu dữ liệu cơ bản 38
Bảng 3.2. Toán tử trong Promela 39
Bảng 3.3. Bảng thể hiện xen kẽ trạng thái của chương trình Promela PQ 44
Bảng 3.4. Kết quả đầu ra có thể của chương trình Promela PQ 44

6

CHƯƠNG 1. MỞ ĐẦU
1.1. ĐẶT VẤN ĐỀ
Phần mềm ngày càng đóng vai trò quan trọng trong xã hội hiện đại. Tỷ
trọng giá trị phần mềm trong các hệ thống ngày càng lớn. Nhưng trong nhiều hệ

thống, lỗi của phần mềm gây ra các hậu quả đặc biệt nghiêm trọng, không chỉ về
mặt kinh tế mà còn về con người, đặc biệt là các phần mềm điều khiển hệ thống
và thiết bị giao thông. Nguyên nhân của các lỗi này là do phần mềm ngày càng
phức tạp do các bài toán được giải quyết và hỗ trợ bởi phần mềm ngày càng lớn.
Để khắc phục các khó khăn này, cách tiếp cận hướng đối tượng đã được sử dụng
để phát triển phần mềm và tỏ ra hiệu quả từ những năm 90 của thế kỷ trước[17].
Tuy nhiên, do độ phức tạp của phần mềm ngày càng cao và để giảm giá thành,
kiến trúc phần mềm cần được cải tiến để tăng tính dùng lại (reuse) của các yếu tố
phần mềm đã phát triển trước đó. Cách tiếp cận hướng thành phần được áp dụng
rộng rãi và có hiệu quả cao. Theo cách tiếp cận này, phần mềm được xây dựng
bằng cách lắp ráp các thành phần riêng biệt lại với nhau như được định nghĩa là:
“Các thiết kế phần mềm mới được tạo ra bằng cách kết hợp các đơn thể
phần mềm có sẵn với một phần mềm mới cung cấp các chức năng mới và mã kết
nối các thành phần với nhau”. Trong đó, thành phần phần mềm được định nghĩa bởi
Szyperski năm 1997 là: “Thành phần phần mềm là một đơn vị của việc kết hợp với
các giao diện được đặc tả bởi hợp đồng và có các mối phụ thuộc tường minh, có
thể được triển khai độc lập và hướng tới việc kết hợp bởi bên thứ ba” [ 11].
Trong định nghĩa này, giao diện của thành phần được đặc tả bởi hợp đồng
đóng vai trò mấu chốt. Hợp đồng bao gồm các dịch vụ và chất lượng dịch vụ mà
thành phần phần mềm cung cấp cho môi trường và những điều kiện mà môi
trường phải thỏa mãn để được nhận dịch vụ của thành phần. Câu hỏi đặt ra là làm
thế nào để kiểm chứng xem môi trường (chương trình gọi đến các dịch vụ của
phần mềm) có tuân thủ các điều kiện được mô tả trong hợp đồng của giao diện
thành phần hay không.
Các phương pháp kiểm chứng hình thức như chứng minh định lý và kiểm
chứng mô hình đã đạt được những thành công nhất định trong kiểm chứng và đặc
tả phần mềm. Việc sử dụng các phương pháp này vào bài toán nêu trên hy vọng
có nhiều hứa hẹn.
Các điều kiện mô tả trong giao diện của thành phần gồm có các tiền điều
kiện đối với các tham số của dịch vụ và thứ tự của các lời gọi dịch vụ mà môi

trường phải tuân thủ (tức là giao thức). Tôi tập trung vào việc kiểm chứng điều
7

kiện thứ hai, tức là kiểm chứng xem môi trường có tuân thủ các thứ tự lời gọi
được qui định hay không và tin rằng lời giải có thể được mở rộng để kiểm tra cả
điều kiện thứ nhất. Để giải quyết bài toán này, ta cần tìm hiểu về giao diện của
thành phần phần mềm và đặc tả của giao thức và tìm hiểu về phương pháp hình
thức để kiểm chứng. Phương pháp mà tôi định sử dụng là kiểm chứng mô hình
bằng công cụ kiểm chứng SPIN và đề tài nghiên cứu của chúng tôi là: “Ứng dụng
của SPIN để kiểm chứng sự tuân thủ thể thức tương tác của chương trình”.
Được biết đề tài này đã được nhiều người nghiên cứu trong và ngoài nước
quan tâm, trong tài liệu [13], các tác giả đã xét bài toán này khi giao thức là các
ràng buộc về thứ tự các phép toán (không phải là dãy), trong tài liệu [9], tác giả đã
đề xuất một mô hình tổng quát và đề xuất các thuật toán để kiểm chứng nhưng các
thuật toán này khó cài đặt và không tự động hoàn toàn vì việc kiểm chứng không
chỉ đối với giao thức mà cả sự tương thích của dịch vụ thời gian thực nên cần đến
các công cụ giải bài toán SAT (Satisfiability – Thỏa mãn của một công thức), tức
là các solvers.
1.2. NỘI DUNG VÀ MỤC ĐÍCH NGHIÊN CỨU
Từ việc đặt bài toán và ý tưởng để giải bài toán được đề xuất trên đây, nội
dung nghiên cứu của đề tài được xác định như sau.
 Tìm hiểu công nghệ phát triển phần mềm hướng thành phần. Tìm hiểu về
các thành phần phần mềm trong phần mềm được phát triển theo hướng
thành phần với: giao diện của thành phần phần mềm, đặc tả giao thức tương
tác của chúng. Trong nội dung này quan trọng là đặc tả giao thức tương tác
của các thành phần.
 Tìm hiểu bộ công kiểm chứng SPIN, ngôn ngữ mô hình hóa Promela trong
bộ công cụ SPIN với cách thức mô hình hóa các thể thức tương tác của các
thành phần phần mềm trong bộ công cụ SPIN bằng ngôn ngữ Promela.
 Trên các cơ sở đó áp dụng bộ công cụ SPIN để kiểm chứng sự tuân thủ thể

thức tương tác hoặc không tuân thủ thể thức tương tác của chương trình
dựa vào các giao thức tương tác.
1.3. GIẢ THUYẾT KHOA HỌC
Phương pháp kiểm chứng sự tuân thủ hoặc không tuân thể thức tương tác
của chương trình bằng công cụ SPIN là cần thiết, nó góp phần tích cực vào việc
phát triển phần mềm hướng thành phần bởi nó rất đơn giản, nếu được thực hiện sẽ
đảm bảo một thành phần phần mềm sẽ tương thích với chương trình, từ đó giảm
8

thời gian phát triển hệ thống, nâng cao chất lượng sản phẩm phần mềm và đáp
ứng yêu cầu khách hàng.
1.4. CẤU TRÚC CỦA LUẬN VĂN
Với nội dung nghiên cứu đã nêu ở trên, thì luận văn gồm có các nội dung
trình bày như sau: Trình bày về công nghệ phần mềm hướng thành phần. Thành
phần phần mềm trong phần mềm được phát triển theo hướng thành phần. Giao
diện tương tác của các thành phần phần mềm. Trong nội dung chủ yếu về công
nghệ phần mềm dựa trên thành phần và đặc tả giao thức tương tác của các thành
phần. Trình bày về bộ công cụ kiểm chứng mô hình SPIN với ngôn ngữ Promela
là ngôn ngữ mô hình hóa trong bộ công cụ SPIN, bài toán deadlock trong SPIN và
cách kiểm tra deadlock trong bộ công cụ SPIN. Phần thực nghiệm, áp dụng bộ
công cụ SPIN để kiểm chứng sự tuân thủ hoặc không tuân thủ thể thức tương tác
của chương trình. Từ kết quả thực nghiệm này có thể kết luận được phương pháp
kiểm chứng đã đưa ra.

9

CHƯƠNG 2. CƠ SỞ LÝ THUYẾT

Nội dung của chương trình bày về công nghệ phần mềm dựa trên thành
phần, lợi ích của nó trong phát triển phần mềm. Nghiên cứu, tìm hiểu giao diện
tương tác và đặc tả giao thức tương tác của các thành phần trong phần mềm phát
triển theo hướng thành phần.
2.1. 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 nhấn mạnh việc thiết kế và xây
dựng hệ thống phần mềm dựa trên tái sử dụng các thành phần. Trong công nghệ
phần mềm dựa trên thành phần, lập trình viên được giải phóng khỏi các vấn đề chi
tiết và nó chuyển trọng tâm từ lập trình tạo phần mềm sang sáng tạo hệ thống.
Ngoài ra thì thực hiện tích hợp là trọng tâm. Cơ sở của nó giả định rằng đã có
nhiều hệ thống phần mềm lớn, phổ biến để biện minh cho việc khai thác phát triển
các thành phần tái sử dụng đáp ứng yêu cầu [3].





















Hình 2.1. Tổng quan thiết kế phần mềm dựa trên thành phần
Phương pháp phát triển phần mềm dựa trên thành phần dựa trên ý tưởng

chọn các thành phần thích hợp có sẵn (off-the-shelf) và sau đó lắp ráp chúng vào
một kiến trúc phần mềm đã được xác định.
Yêu cầu
Thiết kế hệ thống
Lựa chọn Lắp ghép Kiểm thử
Tích hợp hệ thống
Kiểm thử hệ thống
Bảo trì hệ thống
Thiết kế đơn vị
Cài đặt
Kiểm thử đơn vị
Tìm kiếm
Đánh giá
10

Công nghệ phần mềm dựa trên thành phần là một nhánh của công nghệ
phần mềm, trong đó nhấn mạnh sự tách biệt các mối quan tâm liên quan đến các
chức năng mở rộng có sẵn trên toàn hệ thống phần mềm nhất định. Nhằm mục
đích mang lại lợi ích trên phạm vi rộng cả ngắn hạn và dài hạn cho bản thân phần
mềm và cho các tổ chức bảo trợ phần mềm.
2.2. Lịch sử phát triển của công nghệ phần mềm dựa trên thành phần
Phát triển phần mềm dựa trên thành phần liên quan đến ý tưởng tái sử dụng
(reuse). Ý tưởng về việc tái sử dụng các thành phần trong phần mềm có nguồn
gốc từ những năm 1960, ý tưởng trở nên nổi bật tại hội nghị khoa học phần mềm
tại Garmisch Đức vào năm 1968 [3] (hội nghị tìm giải pháp khắc phục khủng
hoảng phần mềm). Ý tưởng cơ bản đó là: Khi phát triển một hệ thống mới, có thể
sử dụng các thành phần đã được phát triển. Khi phát triển các chức năng đặc thù
cần thiết trong hệ thống thì cần phát triển theo cách mà chức năng này có thể
được sử dụng lại trong các hệ thống khác trong tương lai.
Một số những trường hợp tái sử dụng đầu tiên thành công đó là sự phát triển

các thư viện khác nhau, ví dụ như thư viện toán học (sin, cos, ma trận, v.v) [6].
Sự thành công của việc sử dụng lại nằm trong một số cơ sở lập luận:
 Có cơ sở xác định rõ ràng về các loại chức năng.
 Giao tiếp giữa các ứng dụng và các chức năng là đơn giản. Các ứng dụng
gọi các chức năng gửi cho nó các thông số đầu vào và thư viện đáp ứng
bằng cách thực hiện các chức năng và trả lại các kết quả.
 Đầu vào và đầu ra được xác định chính xác
 Xử lý lỗi tốt: nếu đầu vào sai, đầu ra sẽ trả về một giá trị cụ thể thể hiện lỗi.
2.3. Xây dựng hệ thống dựa trên thành phần
2.3.1. Thành phần phần mềm
Thành phần phần mềm là gì? Chúng có được quy định, xác định và xử lý
không? Để đưa ra một định nghĩa chính xác và hiểu rõ về thành phần thì không
phải là dễ dàng. Tuy nhiên có một số định nghĩa, các định nghĩa này cũng phụ
thuộc vào nền tảng và sử dụng cho các mục đích khác nhau [6].
Định nghĩa 1. Một thành phần phần mềm là một phần không tầm thường, nó gần
như độc lập và có thể thay thế trong một hệ thống và đáp ứng một chức năng rõ
ràng trong bối cảnh của một kiến trúc được xác định rõ. Một thành phần phù hợp
cung cấp một tập giao diện vật lý thực hiện công việc.
Định nghĩa 2. Một thành phần phần mềm là một gói phần mềm có thể ràng buộc
tự động một hoặc nhiều chương trình quản lý như một đơn vị truy cập thông qua
giao diện. Thành phần có thể được phát hiện tại lúc chạy.
11

Định nghĩa 3. (Szyperski năm 1997): Thành phần phần mềm là một đơn vị của việc
kết hợp với các giao diện được đặc tả bởi hợp đồng và có các mối phụ thuộc tường
minh, có thể được triển khai độc lập và hướng tới việc kết hợp bởi bên thứ ba.
Để thiết kế phần mềm tốt nhất, nhanh nhất, chi phí thấp chúng ta cần thiết
kế phần mềm dựa trên cơ sở có hệ thống tái sử dụng. .
Thông thường, thành phần là khá nhỏ, độc lập. Một hệ thống gồm các thành
phần cũng có thể được xem là một thành phần với một hệ thống lớn hơn. Các

thành phần có kích thước từ các chức năng đơn giản đến toàn bộ hệ thống ứng
dụng. Cần xác định được thời điểm mà thành phần chạy trong hệ thống, sự tồn tại
của các thành phần trong một hệ thống đang chạy [18].
Các thành phần cung cấp dịch vụ mà không quan tâm, không cần biết hoạt
động bên trong như thuật toán, mã nguồn bằng ngôn ngữ gì, nó chỉ cần nội dung
của giao diện, ví dụ như cú pháp, ngữ nghĩa và hướng dẫn cách sử dụng giao diện.
Một thành phần là một thực thể thực thi độc lập có thể được tạo thành từ một hoặc
nhiều đối tượng thực thi. Giao diện thành phần được công bố và tất cả các tương
tác được thực hiện thông qua giao diện.
Trong một hệ thống phần mềm phức tạp, hệ thống này sẽ được xây dựng
lên bằng cách ghép nối các thành phần phần mềm theo một kiến trúc phần mềm.
Phần mềm mới được tạo ra bằng cách kết hợp các mô-đun có sẵn từ trước với
phần mềm mới, nó có sự gắn kết giữa các thành phần và chức năng mới của các
thành phần phần mềm [18].













Hình 2.2. Kiến trúc hệ thống của phần mềm hướng thành phần
ứng
dụng 2

Thành phần thương mại đặc biệt
Thành phần chung
Thành phần cơ sở
ứng
dụng 1
ứng
dụng 3
Tầng ứng dụng
Tầng thành phần
12

Điều kiện đầy đủ của các thành phần phần mềm được đánh giá bởi các kỹ sư
phần mềm đảm bảo rằng chức năng, hiệu suất, độ tin cậy, khả năng sử dụng, chất
lượng và các yếu tố khác phù hợp với các yêu cầu của hệ thống, hoặc sản phẩm được
xây dựng. Lắp ráp các thành phần tích hợp theo phong cách kiến trúc và kết nối phù
hợp cho phép các thành phần được phối hợp với nhau có hiệu quả. Có thể cập nhật
các phiên bản mới của các thành phần để thay thế cho thành phần đã cũ [6].
Thành phần phần mềm cần phải được tìm hiểu để sử dụng đúng cách trong
các hệ thống phần mềm dựa trên thành phần. Đặc tả giao diện đã được chứng
minh là một phương tiện hiệu quả để tạo điều kiện hiểu biết thành phần. Đặc tả
giao diện thành phần có một số khía cạnh, bao gồm chữ ký, cấu hình, ngữ nghĩa,
giao thức tương tác và chất lượng [7].
2.3.2. Xác định thành phần
Mục tiêu chính của xác định thành phần là tạo ra một tập của đặc tả giao
diện thành phần. Nó xác định các giao diện thành phần từ sự tương tác giữa thành
phần và môi trường của nó. Một kiến trúc và các đặc tả thành phần ban đầu được
xác định trong giai đoạn này. Vào cuối giai đoạn này, các loại mô hình giao diện hệ
thống, giao diện kinh doanh và kiến trúc hợp phần thành phần sẽ được đưa ra [15].
2.3.2.1. Dùng lại
Thành phần tái sử dụng xác định một chiến lược cụ thể cho việc cung cấp

các thành phần có thể được xây dựng hoặc mua sẵn. Thông số kỹ thuật thành phần
có thể được cấp bởi đội ngũ phát triển, tổ chức, hoặc các đối tác đáng tin cậy, hoặc
tìm kiếm từ các nguồn thương mại. Khi một thành phần là ứng cử viên, nó phải có
hình thức xác nhận và nó được chấp nhận hoặc từ chối. Nếu thành phần được chấp
nhận, nó sẽ được lưu trữ trong kho lưu trữ thành phần, sau đó được xuất bản bởi
các nhà phát triển để truy cập vào các dự án khác nhau. Phát triển phần mềm dựa
trên thành phần, đầu tiên tìm các thành phần yêu cầu trong kho thành phần. Khi các
thành phần được tìm ra, chúng sẽ được lấy ra và kiểm tra, thậm chí có thể kiểm thử
trước khi chúng được tái sử dụng [15].
2.3.2.2. Phát triển mới
Trong yêu cầu chức năng phần mềm, nếu không thể thay đổi hoặc không
thể chỉnh sửa các thành phần có sẵn để đáp ứng được yêu cầu, ta phải phân tích,
thiết kế và phát triển những thành phần mới để đáp ứng yêu cầu. Quá trình này
phải bắt đầu từ đầu để tránh sai, thiếu so với yêu cầu [4].
2.3.2.3. Thích nghi
13

Kiến trúc phần mềm mô tả mẫu thiết kế bao gồm các thành phần (đơn vị
chức năng), kết nối và phối hợp. Về bản chất kiến trúc xác định quy tắc thiết kế
cho tất cả các thành phần, xác định các phương thức kết nối và phối hợp. Trong
một số trường hợp, các thành phần tái sử dụng hiện tại có thể không khớp với quy
tắc thiết kế của kiến trúc. Các thành phần này phải được điều chỉnh để đáp ứng
nhu cầu của các kiến trúc hoặc bị loại bỏ và thay thế bằng thành phần khác phù
hợp hơn [4].
2.3.2.4. Cập nhật thành phần
Khi hệ thống được phát triển với thành phần COTS (Commercial Off-The-
Shelf – thương mại, phổ biến sẵn có), cập nhật sẽ phức tạp bởi sự áp đặt của bên
thứ ba (ví dụ tổ chức phát triển các thành phần tái sử dụng có thể nằm ngoài tầm
kiểm soát của các tổ chức phát triển phần mềm). Có thể thay thế các phiên bản
phần mềm hiện có bằng các phiên bản với các thành phần mới có sẵn [4].

2.4. Lợi ích của công nghệ phần mềm dựa trên thành phần
Phát triển phần mềm hướng thành phần là một trong những công nghệ quan
trọng trong kỹ nghệ phần mềm. Hệ thống phần mềm hướng thành phần được xây
dựng dựa trên quá trình lựa chọn và ghép nối các thành phần riêng biệt thành một
hệ thống hoàn chỉnh. Với cách tiếp cận này, phát triển phần mềm hướng thành
phần góp phần rút ngắn thời gian thực hiện dự án, nâng cao chất lượng và độ tin
cậy của sản phẩm [18]. Công nghệ phần mềm hướng thành phần đóng vai trò
quan trọng trong việc chinh phục độ phức tạp của phần mềm, vì khi xây dựng hệ
thống phần mềm phức tạp, nó sẽ được ghép nối từ các thành phần đơn giản hơn,
mà các thành phần này có thể tận dụng lại, mua sẵn hoặc phát triển bởi một nhà
phát triển khác. Việc sử dụng lại hoặc mua ngoài các thành phần phần mềm là xu
hướng tất yếu để đảm bảo yếu tố thời gian và chất lượng của phần mềm. Vì những
ưu điểm này mà công nghệ này đã được áp dụng rộng rãi trong quá trình phát
triển các dự án phần mềm hiện nay.
Nâng cao chất lượng của phần mềm: Khi ghép nối một thành phần vào
phần mềm, thành phần này được lựa chọn trong thư viện hoặc mua sẵn nhưng
chỉ khi đảm bảo được yêu cầu thì mới được tích hợp vào phần mềm. Do đó, sản
phẩm phần mềm đảm bảo được chất lượng. Ngoài ra, chất lượng của phần mềm
được cải thiện bằng cách cải thiện chất lượng của các thành phần. Việc cải
thiện một thành phần là dễ dàng hơn và làm thay đổi rất ít các hoạt động của
toàn hệ thống. Điều này sẽ rất lợi ích cho bảo trì hệ thống. Phương pháp tiếp
cận thành phần giúp hệ thống tìm khiếm khuyết của nó dễ dàng bằng cách kiểm
tra các thành phần đơn lẻ.
14

2.5. Phương pháp phát triển phần mềm hướng thành phần
Phương pháp phát triển phần mềm dựa trên thành phần khác phương pháp
phát triển truyền thống. Theo phương pháp này thì hệ thống có thể phát triển theo
cách chọn thành phần phù hợp và sau đó lắp ráp chúng lại với nhau [4]. Cách tiếp
cận truyền thống thì toàn bộ hệ thống được xây dựng phát triển từ đầu.

Phần mềm dựa trên thành phần được phát triển bằng cách chọn thành phần
khác nhau và lắp ráp chúng lại chứ không phải là lập trình một hệ thống tổng thể từ
đầu, do đó chu kỳ sống của hệ thống phần mềm dựa trên thành phần là khác với các
hệ thống phần mềm truyền thống. Vòng đời của hệ thống phần mềm dựa trên thành
phần có thể được tóm tắt như sau: Phân tích yêu cầu; Lựa chọn kiến trúc phần mềm,
xây dựng, phân tích và đánh giá; Xác định thành phần và tùy biến; Tích hợp hệ
thống; Kiểm thử hệ thống; Bảo trì hệ thống.











Hình 2.3. Mô hình phát triển phần mềm dựa trên thành phần
Các kiến trúc của phần mềm định nghĩa một cách hệ thống về thành phần
tính toán và sự tương tác giữa các thành phần. Việc tập trung vào sáng tạo và lắp
ráp các thành phần có sẵn có thể được phát triển riêng biệt, và thậm chí độc lập.
Xác định thành phần, tuỳ biến và tích hợp là một hoạt động rất quan trọng trong
vòng đời của các hệ thống dựa trên thành phần. Nó bao gồm hai phần chính: Đánh
giá của mỗi thành phần COTS là ứng cử viên dựa trên các yêu cầu chức năng và
chất lượng sẽ được sử dụng để đánh giá thành phần; Tuỳ biến của những thành
phần COTS cần được sửa đổi trước khi được tích hợp vào hệ thống phần mềm
dựa trên thành phần. Tích hợp đưa ra các quyết định quan trọng về cách truyền
thông và phối hợp giữa các thành phần khác nhau của một hệ thống phần mềm.
Đảm bảo chất lượng cho các hệ thống phần mềm dựa trên thành phần cần

phải giải quyết chu kỳ sống và hoạt động chính của nó để phân tích các thành
phần và đạt được hệ thống phần mềm dựa trên thành phần chất lượng cao.
Thành phần 1
Thành phần 2
Thành phần n
⁞

Kho thành
phần
Phần mềm
Tích hợp các
thành phần
Lựa chọn các
thành phần
Các thành phần mua sẵn
(COTS)
15

2.6. Mô hình hóa giao diện thành phần
Như đã biết, phát triển phần mềm dựa trên thành phần thì giao diện tương
tác của các thành phần là quan trọng nhất. Trong nội dung này đề cập đến giao
diện tương tác của các thành phần phần mềm, vai trò giao diện và đặc tả giao thức
tương tác của các thành phần phần mềm.
2.6.1. Giao diện
Giao diện là một khái niệm trừu tượng về hành vi của một thành phần, nó
bao gồm một tập các tương tác của thành phần đó cùng với một tập các ràng buộc
mô tả các hành động có thể xảy ra. Giao diện mô tả hành vi của một thành phần
có thể thu được bằng cách xem xét sự tương tác của giao diện đó với các giao
diện tương tác của các thành phần khác [5].
2.6.2. Vai trò giao diện

Trong giao diện thành phần thì thể thức tương tác (Interaction protocol) mà
nó đặt ra là quan trọng, đó là cách thức gọi các dịch vụ theo thứ tự cụ thể. Một
thành phần có thể thức tương tác cụ thể, một thành phần khác (môi trường) muốn
sử dụng dịch vụ của thành phần thì nó phải gọi các dịch vụ đó theo thứ tự tuân thủ
thể thức thành phần. Giao diện thành phần quy định sự tương tác giữa các thành
phần và cơ chế ghép nối chúng để thành một hệ thống phục vụ nhu cầu thực tế.
Chất lượng, tính đúng đắn và tính thống nhất trong giao diện thành phần
đóng góp phần lớn trong chất lượng và sự thành công của dự án phát triển phần
mềm hướng thành phần.
2.6.3. Đặc tả giao diện với một số ngôn ngữ cơ sở
Ý tưởng cốt lõi của ngôn ngữ đặc tả là để cung cấp một cơ chế khai báo để
xác định tương tác thành phần một cách đúng đắn rằng chúng có thể được xác
nhận [16]. Việc xác minh được thực hiện bằng cách quan sát các đặc tả được xác
định (thứ tự các cuộc gọi) và các mối quan hệ giữa các đối số và các giá trị trả về,
ví dụ trong các cuộc gọi hàm. Ngôn ngữ đặc tả bao gồm: Một cơ chế để sắp đặt
yêu cầu về thực hiện chương trình hoặc trạng thái. Những yêu cầu này được gọi là
mệnh đề nguyên tử.
Một cơ chế phối kết hợp các mệnh đề để mô tả thuộc tính dự kiến của một
thành phần phần mềm. Đây được coi là đặc tả và chia thành các dạng như sau:
 Biểu diễn đặc tả với biểu thức chính quy.
 Biểu diễn đặc tả với biểu thức PLTL (Propositional linear temporal logic).
 Biểu diễn đặc tả với NFA (automata hữu hạn không đơn định).
Một cơ chế để buộc các đặc tả cho các luồng chương trình.
16

Một số cơ sở cho ngôn ngữ đặc tả:
a) Công thức mệnh đề
Một công thức mệnh đề là cơ sở cho cả biểu thức chính quy và biểu thức
PLTL (Propositional linear temporal logic). Cho AP là một tập mệnh đề nguyên
tử hữu hạn khác rỗng. Với mệnh đề nguyên tử là các lệnh của chương trình bao

gồm cả đúng và sai. Các kết nối mệnh đề được định nghĩa với ngữ nghĩa chính
quy và tiện lợi. Ở đây định nghĩa công thức mệnh đề qua tập mệnh đề nguyên tử
AP (Atomic Proposition).
Công thức mệnh đề trên tập mệnh đề nguyên tử AP được định nghĩa quy
nạp như sau:
 Mỗi mệnh đề nguyên tử (P AP) là một công thức mệnh đề.
 Cho P, P
1
, và P
2
là công thức mệnh đề thì: ¬ P; P
1
P
2
; P
1
 P
2
cũng là các
công thức mệnh đề. Không có công thức mệnh đề khác.
b) Biểu thức chính quy
Biểu thức chính quy là một quy ước trực quan và quen thuộc để nhận ra mô
hình được sử dụng rộng rãi trong lĩnh vực lập trình. Chúng cũng được sử dụng
như là một ngôn ngữ đặc tả.
Biểu thức chính quy trên công thức mệnh đề được định nghĩa quy nạp như sau:
 Mỗi công thức mệnh đề là một biểu thức chính quy.
 Cho r, r
1
và r
2

là các biểu thức chính quy thì: r* (bao đóng); r
1
 r
2
(ghép
nối); r
1
 r
2
(hợp) cũng là các biểu thức chính quy. Và không có biểu thức
chính quy khác.
c) Automata hữu hạn không đơn định
Automata hữu hạn không đơn định NFA (Nondeterministic Finite
Automata) tương đương với biểu thức chính quy và khả năng của nó có thể biểu
diễn các ngôn ngữ chính quy. Automata được đưa vào để làm ngôn ngữ đặc tả, có
thể không cần thiết các biểu thức chính quy để đặc tả giao diện mà dùng automata
để tránh phải gánh chịu các biến cố lớn.
Automata hữu hạn không đơn định NFA là một bộ gồm (Σ, S, S
0
, ∆, F) trong đó:
• Σ là một bảng chữ cái hữu hạn,
• S là tập hữu hạn các trạng thái,
• S
0
 S là tập các trạng thái ban đầu,
• ∆  S × Σ × S là quan hệ chuyển trạng thái,
• F  S là tập trạng thái kết thúc.
Một automata hữu hạn A chấp nhận ngôn ngữ L(A)  Σ* gọi là ngôn ngữ chấp
nhận bởi A, được định nghĩa như sau:
17

 Một thực thi của A trên một từ hữu hạn a
0
,…,a
n-1
 Σ* là một thứ tự s
0
,…,s
n

của (n+1) trạng thái trong S, mà s
0
 S
0
và (s
i
, a
i
, s
i+1
)  ∆ với tất cả 0 ≤ i < n.
 Thực thi được chấp nhận nếu và chỉ nếu s
n
F. Một từ w Σ* được chấp
nhận bởi A nếu và chỉ nếu A có một thực thi chấp nhận w.
d) Ví dụ
Một thành phần có giao diện được đặc tả như sau:
@CallSpecifications(
regexp = { "FileUsage ::= (open() ; read()*; write()* ;
close())*"}

)
public interface LogFile {
public void open();
public void close();
public String read();
public void write(String s);
public int length();
}
Trong đó FileUsage được thực hiện với thứ tự theo biểu thức chính quy
regexp. Đầu tiên là open sau đó đến read (có thể hơn một lần) rồi write(có thể hơn
một lần) và cuối cùng là close. Quá trình này có thể lặp lại nhiều lần.
Ở đây ta chỉ quan tâm đến thứ tự thực hiện trong biểu thức regrexp, còn bản
thân các thủ tục open(); read(); write(); close(); ta không đề cập tới.
2.6.4. Đặc tả giao diện với các ràng buộc cơ sở
2.6.4.1. Ràng buộc cơ sở
Đặc tả giao diện cung cấp một cơ sở cho việc phát triển, quản lý và sử dụng
thành phần phần mềm. Trong khuôn khổ này, đặc tả giao diện thành phần giải
quyết các khía cạnh sau: chữ ký (cú pháp), cấu hình (cấu trúc), hành vi (ngữ
nghĩa), tương tác (giao thức hoặc ràng buộc) và chất lượng [7].
Ở mức dưới cùng của đặc tả giao diện có chữ ký của các thành phần, nó tạo
cơ sở cho sự tương tác của các thành phần với thế giới bên ngoài và bao gồm tất
cả các cơ chế hoặc các yếu tố kỹ thuật tương tác cần thiết như thuộc tính, hoạt
động và sự kiện. Mức tiếp theo là cơ cấu tổ chức của giao diện về vai trò của các
thành phần trong ngữ cảnh sử dụng. Như vậy, giao diện thành phần có thể có cấu
hình khác nhau tùy thuộc vào ngữ cảnh, mỗi cấu hình có thể bao gồm một số cổng
phản ánh vai trò các thành phần liên quan đến các thành phần lân cận. Một cổng
sử dụng một số yếu tố giao diện thuộc về chữ ký.
18

Mức độ thứ ba của đặc tả giao diện liên quan đến ngữ nghĩa và yếu tố chữ ký

cá nhân, nó liên quan đến các hành vi chính xác của chúng. Ví dụ ngữ nghĩa đặc tả
của một hoạt động là một cặp precondition, postcondition. Ở mức độ thứ tư là những
ràng buộc tương tác hoặc giao thức tương tác của các thành phần. Quan sát các ràng
buộc này là cần thiết để tránh trường hợp ngoại lệ, lỗi và hành vi không thể đoán
trước và để đảm bảo sử dụng hợp lý các thành phần trong một ngữ cảnh cụ thể.
Khía cạnh thứ năm của đặc tả giao diện là về các đặc tính phi chức năng
của thành phần hoặc các thuộc tính chất lượng chẳng hạn như hiệu suất, độ tin cậy
và tính an toàn. Các đặc tính phi chức năng chiếm một ví trí đặc biệt trong cấu
trúc giao diện thành phần.
Chữ ký giao diện và ngữ nghĩa hành vi xác định chức năng tổng thể của các
thành phần, nó phải phù hợp để sử dụng bởi thành phần khác. Các cấu hình giao
diện và những ràng buộc tương tác liên quan đến việc sử dụng các thành phần
thích hợp trong ngữ cảnh ứng dụng. Các thuộc tính chất lượng cung cấp cơ sở để
đánh giá sự phù hợp hoặc khả năng sử dụng của các thành phần.
Đặc tả giao diện thành phần phần mềm theo các ràng buộc có thể theo định
dạng như sau:
COMPONENT comp1 {
SIGNATURE {
PROVIDES {
attributes (signature & semantics)
operations (signature & semantics)
events (signature & semantics)
constraints
};
REQUIRES {
attributes (signature & semantics)
operations (signature & semantics)
events (signature & semantics)
constraints
};

CONSTRAINTS {
constraints
};
};
CONFIGURATION config1 {
19

PORT port1 {
selected attributes, operations & events
constraints
};
PORT port2 {
selected attributes, operations & events
constraints
};
CONSTRAINTS {
constraints
};
};
CONFIGURATION config2 { };
QUALITIES { };
};
2.6.4.2. Giao thức tương tác với các ràng buộc cơ sở
Khi tương tác với một thành phần sử dụng các yếu tố chữ ký (thuộc tính,
hoạt động và sự kiện của nó), trường hợp ngoại lệ, lỗi hoặc hành vi không đoán
trước có thể xảy ra. Các hành vi ngữ nghĩa của các yếu tố chữ ký cá nhân
không cung cấp trực tiếp, hay hướng dẫn rõ ràng về cách sử dụng hài hòa các
yếu tố để tránh sự tương tác dẫn đến trường hợp ngoại lệ, lỗi hoặc hành vi
không thể đoán trước. Điều này là do sự phụ thuộc giữa các ràng buộc được
quy định cục bộ và các yếu tố cá nhân mà không có cái nhìn tổng thể của mô

hình tương tác cho phép [7].
Trong các ứng dụng phân tán và đồng thời, các dịch vụ được cung cấp bởi
một thành phần là nguyên tử và thực hiện các giao dịch không phải lúc nào cũng
thực hiện được hoặc không phải lúc nào cũng đúng. Hơn nữa, bối cảnh ứng dụng
nhất định có sự hạn chế, trong đó một phần được sử dụng. Sự phụ thuộc hoặc
đồng bộ hóa các giao diện thành phần liên quan đến việc sử dụng các thành phần
và xác định các giao thức tương tác của các thành phần. Các giao thức này giúp
người sử dụng hiểu các thành phần và tạo điều kiện kiểm tra và thực hiện chúng.
Ví dụ một hoạt động có thể được gọi ngay lập tức sau khi hoạt động khác trước
nó được hoàn thành.
Quy định cụ thể các giao thức tương tác của một thành phần tiếp cận thông
qua ràng buộc cơ sở. Giả định cơ bản của tiếp cận này là khi không có những đặc
tả ràng buộc tương tác của thành phần, bất kỳ một trình tự tương tác và trạng thái
cho phép đối tượng áp dụng chữ ký và cấu hình, như vậy, chắc chắn tương tác là
20

thành công. Trong khi có những thành phần khác nhau tạo ra trường hợp ngoại lệ,
lỗi, lý do là do vi phạm các đặc tả ngữ nghĩa của các giao diện tương tác và các
giao thức tương tác của chúng. Vì vậy, tập hợp các kịch bản tương tác cho phép là
lớn hơn nhiều so với giá trị thực tế thiết lập các kịch bản tương tác. Khi một ràng
buộc tương tác được quy định và được kiểm tra (trước khi tương tác), nó sẽ loại
bỏ một số tương tác không hợp lệ. Về bản chất, nó giảm bớt sự cho phép thiết lập
đối với tập giá trị của các tương tác. Khi ràng buộc tương tác được thêm vào
nhiều hơn, sự xấp xỉ trở lên chính xác hơn. Về mặt lý thuyết, khi tất cả các ràng
buộc tương tác được quy định, các tập cho phép sẽ là tập hợp lệ [7].
Cách tiếp cận dựa trên ràng buộc cơ sở xác định giao thức tương tác cho
phép gia tăng và đặc tả linh hoạt, kiểm tra và thực thi các giao thức tương tác.
Mộ số cấu trúc đặc tả ràng buộc:
Cấu trúc 1.
attribute@time

Trong cấu trúc này cho giá trị attribute tại thời điểm (time) đã định sẵn.
Time có thể vào lúc kết nối thành phần hoặc vai trò (role). Một sự kiện cho khởi
động của nó, PRE(op) cho trước yêu cầu thao tác op, hoặc POST(op) cho sau khi
thao tác op hoàn thành. Ví dụ: enabled@^ = false phát biểu rằng thuộc tính
enabled có giá trị false trong lúc kết nối. Với enabled@PRE(report_alarm_data)
nghĩa là enabled là true khi có precondition của hoạt động report_alarm_data.
Cấu trúc 2.
action tr action
action có thể là cho kết nối thành phần hoặc vai trò, một hoạt động hoặc một sự
kiện attribute.SET(value) hoặc attribute.GET để sắp đặt và lấy giá trị của
attribute; tr là một toán tử quan hệ thời gian: (ngay khi) proceeds, before,
leadsTo, pairwiseBefore hoặc pairwiseLeadsTo. Cấu trúc phát biểu rằng hai hành
động thỏa mãn mối quan hệ thời gian nhất định. Ví dụ (ˆproceeds
request_signature) thao tác đầu tiên sau khi kết nối là request_signature. Ràng
buộc (set_alarm_attributes before enabled.SET(true)) nghĩa là thao tác
set_alarm_attributes được truyền ra trước khi thuộc tính enabled được thiết lập
là true, có thể có hoặc có thể không có hành động khác giữa chúng và nó không
đảm bảo hành động thứ hai sẽ xảy ra lúc nào. Một phiên bản chặt chẽ hơn là
leadsTo trong đó (a leadsTo b) yêu cầu hành động b cuối cùng phải xảy ra, trong
khi (a before b) thì không.
Trong ràng buộc về số lần mà một hành động có thể thực hiện, chúng ta có
thể sử dụng cấu trúc trong đặc tả ràng buộc tương tác sau:
21

frequency action
trong đó frequency có thể là once hoặc not và action có thể có giá trị đặc biệt để
có quyền kiểm soát phân chia. Ví dụ chúng ta có thể giới hạn một thuộc tính như
switch được thiết lập là true chỉ đúng một lần trong port/role p1, nhưng chỉ được
đọc trong port/role p2 của cấu hình:
CONFIGURATION C1 {

PORT p1 {
CONSTRAINT once switch.SET(true);
};
PORT p2 {
CONSTRAINT not switch.SET;
};
};
Lựa chọn ràng buộc
Một ràng buộc tương tác có thể riêng về cung cấp, riêng về yêu cầu hoặc cả
cung cấp và yêu cầu. Một vài ràng buộc có thể là chung cho tất cả các cấu hình
giao diện trong khi một số khác là riêng biệt cho cấu hình đặc biệt hoặc vai trò. Ví
dụ một hệ thống viễn thông với thành phần quản lý trung tâm CM (manager
component) được kết nối đến ba thành phần khác: MS (management service), SA
(service arbitrator), SM (service module). Mỗi thành phần khác nhau cung cấp một
thuộc tính enable và thao tác set_alarm_attributes cho chính bản thân nó. Ràng
buộc phát biểu rõ thao tác set_alarm_attributes của thành phần phải được truyền ra
trước khi thuộc tính enable của nó được thiết lập là true. Thao tác
report_alarm_data của CM chỉ được yêu cầu bởi các thành phần khác (SM, SA,
MS) sau khi thuộc tính enabled của thành phần được thiết lập là true.

22

Hình 2.4. Mô hình truyền thông
Cấu hình của thành phần CM:
COMPONENT cm {
SIGNATURE {
PROVIDES {
report_signature(IN Module m_id, IN Sig sig);
report_alarm_data(IN Module m_id, IN AlarmData
alarmData);

report_perf_data(IN Module m_id, IN PerfData perfData);
EVENT e_system_testing;
}
REQUIRES {
ATTRIBUTE BOOLEAN enabled;
request_signature();
set_alarm_attributes(IN Alarm alarm);
set_perf_attributes(IN Perf perf);
set_proxy_perf_attributes(IN SM sm_id, IN Perf perf);
set_ring_attributes(IN Ring_protec protect);
set_ptp_attributes(IN PTP_protec protect);
system_testing();
}
}
}
Cấu hình SM:
COMPONENT sm {
SIGNATURE {
PROVIDES {
ATTRIBUTE BOOLEAN enabled;
ATTRIBUTE Perf performance;
readonly ATTRIBUTE PerfData perfData;
request_signature();
set_alarm_attributes(IN Alarm alarm);
23

system_testing();
}
REQUIRES {
report_signature(IN Module m_id, IN Sig sig);

report_alarm_data(IN Module m_id, IN AlarmData
alarmData);
EVENT e_system_testing;
}
}
}
Cấu hình MS:
COMPONENT ms {
SIGNATURE {
PROVIDES {
ATTRIBUTE BOOLEAN enabled;
request_signature();
set_alarm_attributes(IN Alarm alarm);
set_perf_attributes(IN Perf perf);
system_testing();
/* Constraints */
(set_alarm_attributes, set_perf_attributes)
before enabled.SET(true);
enabled@PRE(system_testing);
}
}
}
Cấu hình SA:
COMPONENT sa {
SIGNATURE {
PROVIDES {
ATTRIBUTE BOOLEAN enabled;
request_signature();