Tài liệu 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ữ ADLs CBD CBSE CNS CSP Mô tả Architecture Description Languages - Kiến trúc mô tả Ngôn ngữ Component-based development - Phát triển hướng thành phần Component-Based Software Engineering - Công nghệ phần mềm hướng thành phần 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 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 PVS rCOS UML UNU-IIST UTP Object Constraint Language – Ngôn ngữ ràng buộc đối tượng Prototype Verification System - Hệ thống xác minh nguyên mẫu bằng cách chứng minh định lý 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 Unified Modeling Language - Ngôn ngữ mô hình hóa thống nhất 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 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 P || C song của C và P được định nghĩa tương tự như ký pháp song song trong CSP. x 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 P || C \ X x 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. 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 RES = {res1 ,..., res n }. Biến resi đạ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