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

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 C

ĐẠ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

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

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

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

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

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:

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:

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

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

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á

t rì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

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

X C

P|| \ 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 C

P ||

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

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

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

{res res n}

RES = 1, , Biến res i đạ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 I = Fd,Md 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 m∈Md 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 {x′x∈α \(in∪out) } 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à o ′ k 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

S q S

q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 α ˆ={ }x, y ,

2 0

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 D1 = α,FP1 ,FR1 được làm mịn từ thiết kế

2 2

2 ,FP,FR

D = α (ký hiệu D1D2) 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, r=(res1 , ,res n) Phần đầu của biểu thức trên là để nói rằng các hàm của D2 là một sự làm mịn của các hàm của D1 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 D2 thỏa mãn thì yêu cầu không phải hàm của D1 cũng thỏa mãn Do đó, D2có thể cài đặt từ D1

2.2.2 Thành phần tuần tự

Cho D1= α,FP FR1, 1 và D2 = α,FP FR2, 2 là các thiết kế có yếu tố thời gian Thì

1; 2 ˆ , ,

D D = α FP FR , Trong đó:

D có thể được tái sử dụng cho D2khi D1 đã kết thúc

2.2.3 Kết nối các thành phần song song

Cho D1= α1,FP FR1, 1 và D2 = α2,FP FR2, 2 là thiết kế có yếu tố thời gian Giả sử

, trong đó r1 và r2là các vector của các biến tài nguyên

Điều kiện r = +r1 r2 thể hiện rằng số lượng các nguồn lực đủ để thực hiện D1 và D2

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 (S, → ,C), trong đó mỗi trạng thái s∈S 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 c∈C được thiết kế α,FP FR, , trong

Đị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, 1, 1

Ctr = Fd Md Rd MSpec Init Inv được làm mịn từ

2 2, 2 , 2, 2, 2, 2

Ctr = Fd Md Rd MSpec Init Inv (ký hi ệu Ctr1Ctr2) n ếu:

• F d 1⊆ F d2, Rd1⊆Rd2, và Init Fd2 1=Init Fd1 1, Init Rd2 1≤Init Rd1 1 (trong

đó mỗi hàm f , f1, f2và m ột tập A, f A| ký hi ệu sự giới hạn của f trên A,

và f1≤ f2 ký hi ệu rằng f1và f2có cùng mi ền và f1( )x ≤ f2( )x v ới mọi x trong mi ền đó),

• Md1⊆Md2,

24

Mspec op Mspec op , và Inv2 ⇒Inv1

Xin được giải thích định nghĩa này như sau Ctr2 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 Ctr2 có tất cả các tài nguyên mà Ctr1 có Quy định Inv2⇒Inv1nó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 Ctr1cũng được đảm bảo bởi Ctr2 Do đó có thể dùng Ctr2thay thế cho Ctr1mà không mất đi dịch vụ nào

Cho Ctr i= Fd Md Rd Mspec Init i, i, i, i, i , 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à f ∈Fd1∩Fd2kéo theo Init1( )f =Init2( )f và op∈Md1∩Md2 kéo theo MSpec op1( )⇔MSpec op2( ) Sự kết hợp Ctr1∪Ctr2 được định nghĩa như sau:

Ctr ∪Ctr = Fd ∪Fd Md ∪Md Rd ∪Rd Mspec ∪Mspec Init Init Inv ∧Inv

trong đó (Init1 Init2)( )x được định nghĩa

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

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

Trong đó r và r1 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 Ctr1, Ctr2là 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ì Ctr iCtr1∪Ctr2 với i = 1, 2