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.2Mô hình chuẩn cho mẫu XMLComponent
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.2Mô 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.