I. Giới thiệu mô hình hoàn chỉnh cho quy trình xây dựng phần mềm dựa trên
2.1Tại sao nên sử dụng XML cho đặc tả Components ?
2. Các đề xuất về ngôn ngữ đặc đặc tả để cải thiện quá trình tìm kiếm, và lựa
2.1Tại sao nên sử dụng XML cho đặc tả Components ?
Trong CBSD, quá trình xây dựng những hệ thống dựa COTS bao gồm một số nhiệm vụ, [3] ví dụ như bao gồm các nhiệm vụ:
a) Tìm kiếm các components thoả món cỏc yờu cầu của kiến trúc phần mềm.
b) Đánh giá các components này
c) Sửa và mở rộng các components được lựa chọn để phù hợp với kiến trúc ứng dụng.
d) Và tích hợp các thành phần phần mềm này với nhau ([6]) Rất quan trọng cho những tiến trình này để sử dụng các đặc tả rõ ràng, chính xác, đầy đủ của các components để đảm bảo sự phát triển phần mềm dựa COTS một cách thành công. Ngoài ra, sau đó các components còn được đăng ký vào trong các kho (nổi tiếng) bởi các nhà phát triển hoặc tổ chức thứ 3(third parties), thuận tiện cho tiến trỡnh phỏt triển COTS.
Hầu như các đề xuất cho việc tạo tài liệu cho các components đều dựa trờn cỏc khỏi niệm về giao diện component (giao diện sẽ cung cấp một form để điều khiển những sự độc lập đang nảy sinh giữa các trong chương trình hoặc hệ thống [26]). Theo cách này thì hầu như cỏc ngụn ngữ lập trình hiện nay(vớ dụ như Java, C#, Smalltalk, …) hỗ trợ một số cơ chế cho phép định nghĩa các giao diện qua ngôn ngữ định nghĩa giao diện IDLs(Interface Definition Languages). Tuy nhiên, hầu hết các đề xuất về IDLs bị hạn chế khi diễn tả các chức năng cú pháp component, lờ đi các đề cập quan trọng liên quan, như các giao thức, protocols, behavioral, hoặc thông tin ngữ nghĩa “ semantic information “ hoặc các chức năng non-functional [3].
Mặt khỏc, cỏc tiến trình lựa chọn và tìm kiếm các components COTS đang trở nên vấn đề quan trọng nền tảng của hiệu quả phát triển dựa COTS. Tuy nhiên, các tiến trình này hiện thời đang đối mặt với nhiều hạn chế nghiêm trọng,
Thứ nhất: chủ yếu là bởi vì thông tin đi kèm theo các components là không đầy đủ cho sự lựa chọn hiệu quả,..
Thứ hai: Các chuẩn đánh giá và tìm kiếm thường quá đơn giản để cung cấp tiện ích mang tính thực tế.
Trong trường hợp thứ nhất, bản chất hộp đen “black-box nature” của COTS components đã giấu đi các thông tin về các hành vi bên trong. Bên cạnh đó chỉ có những thuộc tớnh mụ tả chức năng - ”functional properties” của các thành phần
thường được miêu tả, cũn các thông tin quan trọng để lựa chọn components thì thiếu đi, ví dụ protocol hoặc “semantic information” [Vallecillo et al., 1999], hoặc cỏc yờu cầu không mang tính chức năng – “non-functional requirements”[28]
[Rosa et al., 2001, Chung et al., 1999].
Mặt khỏc cỏc tiến trỡnh tỡm kiếm và lựa chọn component được uỷ thác cho traders; Nhưng vấn đề đó là, các traders hiện thời không cung cấp tất cả các chức năng được yêu cầu cho việc COTS component trading một cách hiệu quả trong các hệ thống mở và độc lập “open and independently extensible systems”(vớ dụ như, Internet), được bàn luận trong [27] [Vasudevan and Bannon, 1999].
Cú ít nhất 3 vấn đề trong tiến trình này.
Thứ nhất: Cách tạo tài liệu và đặc tả cho các thành phần trừu tượng “abstract components” được miêu tả trong sự mô tả kiến trúc phần mềm và các thành phần cụ thể “concrete components” trong kho phần mềm. Nhờ vậy chỳng cú thể được tạo thành cặp và so sánh.
Thứ hai: Đó là các tiến trình lựa chọn các thành phần phần mềm, cho phép có thể bổ sung một phần các chức năng được yêu cầu bởi kiến trúc phần mềm.
Cuối cùng, khi các COTS components ứng cử viên được liệt kê ra, thỡ cỏc kiến trúc phần mềm khác nhau được xây dựng từ chúng cần được mô tả, và những người thiết kế hệ thống cần thấy được những sự lựa chọn khác nhau để anh ta có thể có thể quyết định cái nào là tối ưu nhất theo yêu cầu của người dùng
Tài liệu [3] [21] giới thiệu một hướng cho việc tạo đặc tả và tìm kiếmcomponents COTS dựa trên 2 mẫu XML. Mẫu thứ nhất (gọi là COTScomponent) components COTS dựa trên 2 mẫu XML. Mẫu thứ nhất (gọi là COTScomponent) phục vụ cho đặc tả components, và mẫu thứ hai(được gọi là COTSquery) phục vụ việc truy vấn traders. Các mẫu này có thể được sử dụng bởi nhiều loại người (ví dụ các thiết kế kiến trúc hệ thống, người thiết kế, người phát triển, và cả người bán phần mềm) để xuất và nhập các components trao đổi cới các kho dữ liệu phần mềm.