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
1.Giới thiệu
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.
2.2 Mô hình chuẩn cho mẫu XMLComponent
Với hướng tiếp cận trên của chúng ta, một thành phần phần mềm có thể được địng nghĩa bên trong một mẫu “COTScomponent”, mẫu này bao gồm 4 phần cơ bản sau: functional, properties, packaging, và marketing. Nội dung thông tin trong đó chúng ta sẽ nói qua một ví dụ trong phần này.
Non Functional
Các thuộc tính trong đặc tả Component
COTStrader: spec template
Functional Marketing Packaging module OnePlaceBuffer { // Provided interfaces interface OnePlaceBuffer { void write(in long x); long read();
};
// Required interfaces
interface out {
oneway void print(in long x); };
};
Ví dụ về giao diện
Chúng ta có thể tham khảo mẫu đặc tả COTS với các sơ đồ sau:
Hình 2.3 Một mẫu COTS-XML
Tên của component là OnePlaceBuffer. Chúng ta có thể thấy 4 phần như đã đề cập. Phần functional miêu tả các phần của dịch vụ xử lý , bao gồm cả cỳ phỏp(vớ dụ chữ ký) và thông tin ngữ nghĩa. Phần funtional của một dịch vụ sẽ bao gồm một tập các giao diện được cung cấp bởi dịch vụ đó(providedInterfaces), và một tập các giao diện được yêu cầu (là cái mà bất kỳ trường hợp nào của dịch vụ này có thể yêu từ những components khác khi thực hiện cài đặt các dịch vụ được cung cấp của nó (requiredInterfaces).
Thông tin ngữ nghĩa có thể được miêu tả với điều kiện pre/post.(bờn trong thẻ behavior), với vấn đề giao thức (serviceAccessProtocol).
Phần properties mô tả các phần non-functional của dịch vụ (ví dụ QoS, NFRs, ...), which are based on “properties”, là cặp (name, value) theo chuẩn RM -ODP.
Phần packaging bao gồm thông tin gói phần mềm, như cách download, deploy và cài đặt COTS component(cung cấp dịch vụ được yêu cầu, bao gồm chi tiết cài đặt các ràng buộc về kiến trỳc, mụi trường, …)
Cuối cựng, thụng tin marketing sẽ quan tâm đến phần còn lại các vấn đề không mang tính công nghệ của dịch vụ, như thông tin về giá, bản quyền, các chi tiết về người cung cấp, các vấn đề đặc biệt, ...
Khi các mẫu XML này được lưu trữ ở các kho CSDL phân tán, việc nghiên cứu cỏc cụng nghệ lưu trữ và xử lý hệ thống XML phân tán là rất cần thiết. Bởi công nghệ phần mềm hướng thành phần đang dần dần phát triển trờn cỏc hệ thống lớn, phạm vi lớn, và vấn đề tìm kiếm các thành phần phần mềm là trên phạm vi Internet.
3. Vấn đề thiết kế kiến trúc phần mềm trong UML – RT
Theo định nghĩa của [Bass et al., 1999] [29]: Kiến trúc phần mềm của một chương trình hoặc một hệ thống xử lý là một kiến trúc hoặc nhiều kiến trúc của một hệ thống, trong đó bao gồm các thành phần phần mềm, các thuộc tính nhận thấy được bên ngoài của các thành phần phần mềm đó và các mối quan hệ giữa chúng “The software architectureof a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them".
Với nghĩa “cỏc thuộc tính nhận thấy được bên ngoài”, muốn ngụ ý rằng: các thành phần phần mềm khỏc cú thể làm bằng một componnent, như các dịch vụ được cung cấp, các đặc trưng về sự thực thi, sự sử dụng nguồn chung, … ”... those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on".
Các hệ thống phần mềm phức tạp yêu cầu các ký hiệu mô tả để biễu diễn kiến trúc của chúng. Nói chung, kiến trúc phần mềm định nghĩa kiến trúc mức cao của nó, thể hiện ra tổ chức của nó như một tập cỏc liờn kết các components.
Theo truyền thống, người ta sử dụng cỏc ngụn ngữ mô tả kiến trỳc chuyờn biệt “Architecture Description Languages” (ADLs), cho phép mô tả ở dạng chuẩn “formal description” của kết cấu và các hành vi của kiến trúc ứng dụng
[Medvidovic and Taylor, 2000] [30].
Tuy nhiên, Sự tuân thủ quy tắc và thiếu sự hỗ trợ trực quan của hầu hết ADLs đó thỳc đẩy quá trình tìm tòi cỏc kớ hiệu mô tả thân thiện hơn. Trong các hướng nghiên cứu này, kí hiệu mô hình cho mục đích chung “general-purpose modeling ký phỏp” UML rõ ràng là ứng cử viên sáng giá, vỡ nú thõn thiện với những nhà phát triển, dễ học và sử dụng bởi những người không chuyên về công nghệ “non-technical people”, nó đưa ra một sơ đồ mức cao thân thiện và có hỗ trợ tool.
Có một vấn đề đó là sự định nghĩa của UML đã tồn tại không cung cấp cách rõ ràng cho việc mó hoỏ và mô hình hoỏ cỏc phần tử kiến trúc, điển hỡnh đó tỡm thấy trong cỏc ngụn ngữ miêu tả kiến trúc. Điều này được bàn luận trong
[Garlan et al., 2002] [31] và [Medvidovic et al., 2002] [32]. Và điều này vẫn cũn đỳng cho đến khi phiên bản UML 2.0 ra đời (với mong đợi để hỗ trợ cho sự phát triển ứng dụng phần mềm dựa thành phần và các kiến trúc “run-time architectures”) và sự lựa chọn ngày nay cho việc tạo tài liệu các kiến trúc phần mềm là UML-RT [Selic and Rumbaugh, 1998] [33], cái này định nghĩa UML dành cho mô hình hoỏ cỏc hệ thống thời gian thực.
Mô hình kiến trúc phần mềm trong UML Real-Time
Ngôn ngữ mô hình hoá (UML: Unified Modeling Language) là ngôn ngữ chuẩn cho việc định rõ, trực quan hoá, vẽ sơ đồ specifying, visualizing, constructing, and documenting the artefacts of software systems”.
UML-RT là ngôn ngữ cho mô hình hoỏ cỏc hệ thống thời gian thực phức tạp (ví dụ., viễn thụng, cỏc ứng dụng điều khiển tự động, các ứng dụng không gian vũ trụ, …) Nó bao gồm 3 khái niệm UML, role modeling và ROOM. Role modeling thu nhận các mẫu truyền thông kiến trúc (structural communication patterns) giữa các thành phần. ROOM có nghĩa là mô hình hoá hướng đối tượng thời gian thực (Real-Time Object-Oriented Modeling) [34]. Nó là ngôn ngữ mô hình hoá trực quan với ngữ nghĩa thông thường (formal semantics ) cho cụ thể hoá, trực quan hoá, tạo tài liệu, và tự động việc xây dựng các hệ thống thời gian thực phân tán, hướng sự kiện và phức tạp (complex, event-driven, and distributed real-time systems).
Chúng ta sử dụng 3 khái niệm – “constructs” của UML-RT để mô hình hoá kiến trúc phần mềm: capsules, ports và connectors. Hình 2.5 mô tả một ví dụ của những graphical constructs này trong đó thể hiện vai trò của ứng dụng GTS(sẽ được nói rừ hơn ở phần sau). Một capsule chỉ ra một ký pháp đồ hoạ để thể hiện thành phần của cả hệ thống. Đặc tả thành phần [ví dụ các thông tin interfaces, behavior, non-functional ] được mô tả bên trong capsule. Thông tin này, tuy nhiên, lại không được chỉ ra tại mức trên cùng của kiến trúc phần. Tại mức này, chỉ tên của thành phần được chỉ ra bên trong một capsule. Ví dụ, /sder:Sender nghĩa là sder đó là một đối tượng (instance) của thành phần cơ sở (base component) của Sender.
Hình 2.5. Một ví dụ về UML-RT sử dụng các vai trò “roles” của ứng dụng GTS
Một cổng là trung gian giữa tương tác của capsule với thế giới bên ngoài. Các cổng nhận ra các giao thức chỉ ra thứ tự mà cỏc thụng điệp được gởi giữa các cổng được kết nối. Hình 2.5, kớ phỏp +transReqSend:ProtTrans là một cổng được là transReqSend và một giao thức gọi là ProtTrans. Ký pháp ProtTrans~ chính là giao thức kép (dual protocol). Cổng cung cấp các kĩ thuật để một capsule đị nh ra giao diện vào ra. Chúng ta sử dụng giao diện ra ký phỏp (cỏc hộp đen nhỏ) để mô tả thành phần được cung cấp giao diện và sử dụng giao diện vào ký phỏp (cỏc hộp đen nhỏ) để mô tả những giao diện được yêu cầu. Như đã đề cập ở phần trên, giao diện được yêu cầu là các vấn đề về chức năng của một đặc tả thành phần của COST. Ví dụ, hình 2.6 chỉ ra giao diện của thành phần Translator như là các cổng của UML-RT. Thành phần này được nêu ra ở phần mô tả tài liệu đặc tả Translator COTS .
Ở Hình 2.6 dưới đây, chỉ có tên của các cổng là được chỉ rõ.
Hình 2.6. Những giao diện được cung cấp/được yêu cầu với các UML-RT capsule's ports
Cuối cùng, connectors thu nhận những truyền thụng chớnh giữa các capsules, và chúng được thể hiện bởi các đường nối giữa 2 cổng. Nếu một connector kết hợp nhiều hơn một cổng thỡ nú phải được nhân đôi trong capsule yêu cầu nú (vớ dụ cổng transProv trong thành phần của GTS).
3. Tìm kiếm các thành phần ứng cử viên
Hình 2.7 Mô hình một tiến trình tự động cho phát triển phần mềm dựa nền thành phần
Hình 2.7 cho ta nhìn lại tiến trình tự động phát triển phần mềm hướng thành phần, sơ đồ bao gồm tất cả các nhiệm vụ tiếp nối nhau[Cú tại website:
http://www.traders.com hoặc [35]]. Sau các phần nghiên cứu trên nói trên, chúng ta đã hiểu phương pháp xây dựng được kiến trúc phần mềm sử dụng kớ phỏp UML-RT (task 1), chúng ta sẽ nghiên cứu các tiến trình tiiếp theo để tìm kiếm các components COTS phù hợp với cỏc yờu cầu bắt buộc trong kiến trúc phần mềm.
Task 2 tiếp theo sẽ trích chọn các thông tin về component(vớ dụ thông tin trong “capsure, capsure là một khái niệm trong UML-RT để lưu các thông tin về một component ) và sinh ra một đặc tả của component “COTS document" ứng với
mỗi “capsule” trong kiến trúc phần mềm Loại tài liệu này đã được trình bày trong phần đặc tả component bằng XML.
Sau bước 2 chúng ta đã có danh sỏch cỏc đặc tả cho các components gọi là các “COTS documents”, bây giờ chúng ta cùng bàn luận đến tiến trình tim kiếm (gọi là COTStrader) (task 3.1) sẽ sử dụng các đặc tả này để tìm ra cỏc cỏc component COTS(commercial components) tương tự từ kho phần mềm, kho này lưu trữ các “concrete XML COTS documents”(tức là “real commercial components”).
Đối với mỗi tài liệu này(mụ tả các components trừu tượng), thủ tục trader sẽ sinh ra một danh sách các components ứng cử viên. Tiến tình này đã được nêu rõ trong [36].
Các hoạt động để lựa chọn và sinh ra danh sách các componenntss ứng cử viên thường bắt đầu tìm kiếm đơn giản( ví dụ chỉ dựa trờn cỏc tỡm kiếm theo keywords) và sẽ dần dần chính xác hơn sau mỗi vòng lặp. Điển hình các mức tìm kiếm được sử dụng(mạnh dần) là: tìm kiếm theo : keywords, marketing và thông tin gói phần mềm(Hệ điều hành, cỏc mụhỡnh component ...), các thuộc tính chất lượng, tên giao diện, cỏc phộp xử lý, và các thông tin về ngữ nghĩa, hành vi (behavioral and semantic information) …. Tuy nhiên theo kinh nghiệm của các nhà phát triển thì rất khó để vượt qua mức tìm kiếm theo các thuộc tính chất lượng. Bới các nhà cung cấp phần mềm thậm chớ khụng cung cấp tên của các giao diện cung cấp dịch vụ, và không đề cập đến ngữ nghĩa của chúng.
4. Thuật toỏn tỡm kiếm và lựa chọn thành phần
4.1 Giới thiệu thuật toán
Sau bước 3.1 chúng ta đó cú trong tay danh sách các thành phần ứng cử viên.
Nhiệm vụ cần giải quyết của chúng ta bây giờ(Bước 3.2) đó là xây dựng một thuật toán cho phép tìm kiếm, lựa chọn từ danh sách này xuất ra các tổ hợp components để tạo ra các cấu hình thoả mãn hoàn toàn yêu cầu kiến trúc phần mềm [37]. Việc tìm kiếm, lựa chọn có thể dựa trên.
Trong phần này, chúng ta tập trung nghiên cứu một thuật toán tính toán ra danh sách các tổ hợp này, những tổ hợp này chúng ta gọi là các cấu hình. Việc tìm kiếm có thể dựa vào Thuật toán sẽ xử lý cỏc kớ phỏp đặc tả component liên quan đến các giao diện dược hỗ trợ và các giao diện được yêu cầu.
“Một COTS component C sẽ được định nghĩa bởi hai tập hợp giao diện (interfaces) C = ( R; R), tập thứ nhất bao gồm các giao diện được hỗ trợ bởi thành phần R = {R1,…,Rn}, và tập thứ hai bao gồm các giao diện được yêu cầu bởi thành phần R = {R1,…,Rm}.”
Chúng ta sẽ ký hiệu hai tập giao diện trên là C.R và C.R cho đơn giản. Để vận hành ở mức đăng ký, các giao diện chuẩn Ri và Rj (giống như các giao diện của CORBA hay COM) được kết hợp từ một tập các thuộc tính và phương thức công cộng (public). Ở mức giao thức, mỗi Ri hoặc Rj sẽ mô tả một 'vai trò' (‘role’), còn ở tại mức ngữ nghĩa, mỗi chúng lại tương ứng với một mô tả của giao diện, tức là mỗi giao diện sẽ được gắn thêm thông tin ngữ nghĩa (Ví dụ, các trạng thái trước/sau (pre/post conditions)).
Nếu B là tập con các đặc tả components trong kho thì CB(A) là danh sách ứng cử viên, A là kiến trúc phần mềm. B sẽ cung cấp bất kì giao diện nào mà kiến trúc A cũng cung cấp.
Ví dụ: Cột bên phải Bảng 2.1 là danh sách gồm 8 components ứng cử viên được tìm thấy từ kho B nhờ tiến trình “COTStrader” ứng với kiến trúc phần mềm GTS. Cột bên trái biểu diễn 6 components của hệ thống con GTS(Xem hình). Để đơn giản chúng ta sử dụng 2 đặc điểm chính cho ký hiệu là tên và giao diện comopnent. Ví dụ component “FileCompressor” sẽ được viết là FC và giao diện của nó là RFC .
Trong đó hãy chú ý, thành phần ứng cử viên C2 hoặc C6 yêu cầu các dịch vụ ngoài được định nghĩa bởi giao diện RTL và RFL. Cái đầu tiên biễu diễn giao diện “Tool”, cái bao gồm cỏcphương thức chọn lọc cho việc truyền các ảnh khụng gian(vớ dụ: sắp xếp kích cỡ, quay, rolling, ..,). Cái thứ hai biểu diễn giao diện “Filter”, cái bao gồm các phương thức tuyển chọn thực hiện xử lý các ảnh không gian (ví dụ: xử lý nhiễu, thresholding, tỡm biờn edge detect, shading, segmentation, …)
Trong trường hợp, thành phần C6 nằm trong một cấu hình, chúng ta cần đóng kín (close) nó trước nếu muốn ứng dụng làm việc được. Bước cuối cùng của quy trình, chúng ta sẽ quan tâm đến điều này, đóng kín các cấu hình có liên quan tới kho chứa B. Chúng ta sẽ bàn luận vấn đề này sau.
Bảng 2.1. Hình 2.7. Danh sách các components trong GTS và danh sách ứng cử viên
Thuật toán COTSconfig cố gắng xây dựng một tập tất cả các cấu hình S có thể từ các thành phần ứng cử viên CB(A) đã được sinh ra từ các tiến trình trước.
Ý tưởng cơ bản là xây dựng tất cả cỏc các tổ hợp từ các thành phần ứng cử viên (trong đó phải ẩn tất cả các dịch vụ có thể bị trùng để khi kết hợp chỳng khụng bị xảy ra lỗi), lựa chọn trong những tổ hợp đú cỏc tổ hợp Sol = {S1,…, Sl} sao cho A.R ⊆ Sol.R (Cái này đảm bảo không còn các lỗ hổng dịch vụ).
Bảng 3.2 trình bày một giải thuật quay lui để thực hiện quá trình này. Nó cung cấp, từ tập hợp các ứng cử viên CB(A) = {C1,…, Ck}, và từ ứng dụng A được xem như một thành phần, một tập S các cấu hình hợp lệ.
Các khởi tạo của giải thuật là S = ỉ; Sol = ỉ; configs(1; Sol; S). Việc thực hiện giải thuật này sẽ được làm ở phần sau.
Chúng ta có thể thấy, giải thuật khảo sát qua tất cả các khả năng để xây dựng ra một tập đích bao gồm tất cả các cấu hình hợp lý, có giá trị một cách từng bước một (dòng 11). Mỗi cấu hỡnh (dũng 9) đều được sinh ra bằng cách thử tất cả các ứng cử viên, kết hợp dần các dịch vụ Cj.Rj còn chưa chứa trong A, và bỏ đi những cái mà A đó cú rồi (dòng 8 và dòng 10). Khi giải thuật kết thúc, biến S sẽ chứa đựng tất cả các cấu hình cần thiết. Theo cách mà giải thuật làm việc, thì sẽ không có chuyện các cấu hình trong S còn tồn tại các lỗ hổng dịch vụ hay các dịch vụ chồng chéo. Do đó, giải thuật sẽ chỉ sản sinh ra những cấu hình hợp lệ.
4.2 Đánh giá độ phức tạp của thuật toán
Độ phức tạp của thuật toán là O(L2n) , với n là số lượng các giao diện được đưa ra bởi tất cả các components trong CB(A) và L là sự phức tạp của toán tử “substitutability operator” được sử dụng (ví dụ, at the signature level, protocol