đồ án công nghệ thông tin Những giải pháp cải thiện quy trình tự động hoá tìm kiếm, lựa chọn thành phần phần mềm từ kho dữ liệu trong công nghệ phát triển phần mềm hướng thành phần

Với mục đích nêu rõ được quy trình tự động hoá cho quá trình phát triển phần mềm hướng thành phần, qua báo cáo này, em sẽ tập trung nghiên cứu mô hình đó, đồng thời nhắc đến một số vấn đ

KHOA CễNG NGHỆ THÔNG TIN

Báo cáo thực tập tốt nghiệp

CHUYÊN NGÀNH CễNG NGHỆ THÔNG TIN

ĐỀ TÀI :

NHỮNG GIẢI PHÁP CẢI THIỆN QUY TRÌNH TỰ ĐỘNG HOÁ TèM KIẾM, LỰA CHỌN THÀNH PHẦN PHẦN MỀM TỪ KHO DỮ LIỆU TRONG CễNG

NGHỆ PHÁT TRIỂN PHẦN MỀM

HƯỚNG THÀNH PHẦN

TS Huỳnh Quyết Thắng Phan Thế Đại

Lớp:

K44 – CNPM

Hà Nội, 2-2004

Danh mục từ viết tắt sử dụng trong báo cáo thực tập

Số

TT

1. ADL Architectural Description languages

3 CBSD Component- Based Software Development

4 CBSE Component-based software engineering

5 CORBA Common Object Services Specification

6 COTS Commercial Off-The-Shelf

7 COM Componenent Object Model

8 CORBA (Common Object Request Broker Architecture)

9 DCOM Distributed Componenent Object Model

10 OSD Open Software Description

11 IDLs Interface Defination Language Signature

12 ESI European Software Institute

13 GTS Geographic Translator System

14 OSD Open Software Description

15 NFRs Non-Functional Requirement

16 QoS,

17 UML Unified Modeling Language

19 UUID uniservally unique identifer

Danh mục các hình vẽ trong báo cáo thực tập

Hình 1.1 Các giao diện cơ bản của CORBA 10

Hình 2.1 Mô hình phát triển phần mềm dựa thành phần 16

Hình 2.2 Một kiến trúc phần mềm dựa nền thành phần 17

Hình 2.3 Một mẫu COTS-XML 23

Hình 2.4 Một ví dụ về kiến trúc phần mềm trong UML-RT .26

Hình 2.5 Một ví dụ về UML-RT sử dụng các vai trò “roles” của ứng dụng FTS 27

H ình 2.6 Những giao diện được cung cấp/ được yêu cầu với các UML - RT c apsule's p orts 28

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 29

Hình 2.7' Danh sách các components trong GTS và danh sách ứng cử viên 32

Hình 2.8 Kiến trúc cho CSDL phân tán 36

Hình 2.9 Ví dụ về sự lưu trữ các mảnh của một CSDL phân tán 38

Hình 2.10 Kiến trúc dữ liệu 3 tầng 41

Hình 2.12 Các phần tử của kiến trúc dữ liệu 3 tầng trong các hệ thống Web – CSDL hiện nay 42

Hình 2.13 Kiến trúc tổng quát của hệ thống xử lý truy vấn phân tán 45

Hình 2.14 Hoạt động của hệ thống GTS 49

Hình 2.15 Giao diện của các components trừu tượng trong hệ thống con GTS 50

Hình 2.16 Biểu đồ tuần tự các phương thức trong hệ thống con GTS 51

Hình 2.17 Kiến trúc phần mềm GTS trong UML-RT 53

Hình 2.18 Kiến trúc phần mềm GTS trong UML chuẩn .54

Hình 2.19 Mô tả UML-RT của tất cả các components trong kiến trúc phần mềm GTS .56

Danh mục các bảng trong báo cáo thực tập

Bảng 1 So sánh khả năng về giao diện của các kỹ thuật .14

Bảng 2.1 Danh sách các components trong GTS và danh sách ứng cử viên 32

Bảng 2.2 Sơ đồ thuật toán tạo cấu hình 33

Bảng 2.3 Một số kết quả của thuật toán config() với ví dụ GTS 58

MỤC LỤC

CHƯƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHÁT TRIỂN PHẦN MỀM DỰA TRÊN THÀNH PHẦN VÀ VẤN ĐỀ NGÔN NGỮ ĐỊNH NGHĨA GIAO DIỆN IDLs 4

I Tổng quan công nghệ phát triển phần mềm dựa nền thành phần(CBSD) 4

II Tổng quan về thành phần và giao diện thành phần phần mềm 6

1 Giới thiệu giao diện thành phần phần mềm 6

2 Ngôn ngữ định nghĩa giao diện IDLs trong các kỹ thuật phát triển phần mềm tiêu biểu (COM, DCOM, CORBA, ASSEMBLY …) 7

2.1 Tổng quan giao diện trong COM, DCOM 7

2.2 Tổng quan giao diện trong CORBA 9

2.3 So sánh khả năng về giao diện của các kỹ thuật 12

CHƯƠNG 2: THAM KHẢO MỘT MÔ HÌNH HỆ THỐNG TỰ ĐỘNG HÓA TÌM KIẾM, LỰA CHỌN THÀNH PHẦN PHẦN MỀM TỪ KHO DỮ LIỆU 15 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 nền thành phần phần mềm 15 1 Mô hình 16

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 chọn Components 19

2.1 Tại sao nên sử dụng XML cho đặc tả Components ? 19

2.2 Mô hình chuẩn cho mẫu XMLComponent 21

3 Tìm kiếm các thành phần ứng cử viên 28

4 Thuật toán tìm kiếm và lựa chọn thành phần 29

4.1 Giới thiệu thuật toán 29

4.2 Đánh giá độ phức tạp của thuật toán 32

CHƯƠNG 3 DỮ LIỆU PHÂN TÁN, DỮ LIỆU TẬP TRUNG VÀ VẤN ĐỀ LƯU TRỮ, XỬ LÝ HỆ THỐNG XML PHÂN TÁN 34 1 So sánh tổng quan CSDL phân tán và CSDL tập trung 34 1.1 Điều khiển tập trung 34

1.2 Sự độc lập dữ liệu 34

1.3 Sự giảm dư thừa dữ liệu 35

2 Tham khảo một kiến trúc cho các CSDL phân tán 36

2.1 Lược đồ toàn cục 36

2.2 Lược đồ phân mảnh 37

2.3 Lược đồ định vị 37

2.4 Lược đồ ánh xạ cục bộ 38

3 XML đối với sự phân tán hay tích hợp 39

4 Một sự phân loại của các hệ thống CSDL phân tán 39

5 Xử lý truy vấn trong CSDL XML phân tán 43

CHƯƠNG 4 MỘT ỨNG DỤNG GTS TIÊU BIỂU ĐƯỢC XÂY DỰNG THEO MÔ HÌNH QUY TRÌNH TỰ ĐỘNG HOÁ PHÁT TRIỂN PHẦN MỀM DỰA NỀN THÀNH PHẦN 49 1 Giới thiệu 49

2 Thiết kế kiến trúc phần mềm GTS trong UML – RT 52

2.1 Kiến trúc GTS trong UML-RT 52

2.2 Mapping UML-RT GTS tới chuẩn UML. 54

2.3 Chuyển các thông tin vào các capsules 55

3 Thực hiện thuật toán lựa chọn và kết quả 57

1 Các nghiên cứu tiến hành trong thực tập tốt nghiệp 59

2 Kết luận 61

Các từ trong từ điển 62

Các từ trong từ điển 62

Tài liệu tham khảo 65

Lời nói đầu

Công nghệ phát triển phần mềm dựa thành phần (CBSD) đang là vấn đề rất được quan tâm trên thế giới trong những năm gần đây Trong CBSD, việc xây dựng một ứng dụng được giải quyết bằng cách sử dụng những thành phần đã được làm sẵn, các thành phần này có thể được phát triển ở các thời gian khác nhau, bởi nhiều người khác nhau, và thậm chí dưới nhiều quan điểm khác nhau Mục đích cuối cùng là có thể giảm được thời gian phát triển, giá thành, công sức, trong khi đó lại cải thiện được tính linh hoạt, tính tin cậy, và tính sử dụng lại của các ứng dụng cuối hướng tới việc sử dụng các thành phần phần mềm đã được kiểm thử và chứng nhận là có giá trị í tưởng về một quy trình thống nhất mang tính tự động hoá cao thực hiện hầu như các pha trong quá trình phát triển ứng dụng dựa thành phần là rất hay Nó sẽ giúp cho các mục đích giảm thời gian phát triển, giảm giá thành, công sức, cho chất lượng phần mềm tốt hơn …càng có cơ hội đạt được.

Kế thừa các đề tài tốt nghiệp trước đõy đó nghiờn cứu một số khái niệm như COTS, các kỹ thuật phát triển thành phần phần mềm( như COM, CORBA, DCOM,

…), giao diện thành phần và các phép toán trên giao diện, trong báo cáo này em muốn đề xuất một hướng nghiên cứu bao quát quy trình mang tính chất tự động hoá cao vận dụng những lý thuyết được nghiên cứu cho phát triển CBSD.

Với mục đích nêu rõ được quy trình tự động hoá cho quá trình phát triển phần mềm hướng thành phần, qua báo cáo này, em sẽ tập trung nghiên cứu mô hình đó, đồng thời nhắc đến một số vấn đề liến quan khi sử dụng các components, liên quan đến vấn đề tối ưu hoá quá trình tìm kiếm như là vấn đề đặc tả thành phần phần mềm bao gồm vấn đề giao diện phần mềm và mẫu tài liệu đặc tả XML Đặc biệt chúng ta sẽ đi sâu vào các giai đoạn của quy trình, cải thiện các phương pháp, thuật toán lựa chọn thành phần phần mềm trong kho phần mềm và đánh giá được độ phức tạp của thuật toỏn đú phục vụ cho mục đích tối ưu hoá dần sự lựa chọn các thành phần phần mềm từ kho dữ liệu rộng lớn.

CHƯƠNG 1: TỔNG QUAN Vấ̀ CÔNG NGHỆ PHÁT TRIỂN PHẦN MỀM DỰA TRÊN THÀNH PHẦN VÀ VẤN ĐỀ NGÔN NGỮ ĐỊNH NGHĨA

GIAO DIỆN IDLs

I Tổng quan công nghệ phát triển phần mềm dựa nền thành phần(CBSD)

Phần mềm được lắp ráp từ các thành phần là một trong những ý tưởng và biệnpháp mà cộng đồng những nhà phát triển phần mềm đã đưa ra nhằm giúp cho quátrình xây dựng phần mềm được nhanh chóng và dễ dàng bảo trì hơn Thành phần

là những đối tượng nhỏ được cô lập hoàn toàn với ứng dụng Các thành phần cókhả năng phục vụ ứng dụng thông qua những thuộc tớnh(property) và tìnhhuống(events) mà ứng dụng yêu cầu nó thực hiện.Tức là trong CBSD, việc xâydựng một ứng dụng được giải quyết bằng cách sử dụng những thành phần đã đượclàm sẵn, các thành phần này có thể được phát triển ở các thời gian khác nhau, bởinhiều người khác nhau, và thậm chí dưới nhiều quan điểm khác nhau

Trong CBSD, các nhà thiết kế hệ thống cần phải tính đến các đặc tả của các

thành phần COTS có sẵn được phát triển từ trước trong các kho (repositories)

phần mềm, việc này thậm trí cần phải xem xét ngay cả khi đang xây dựng cỏc yờucầu cho hệ thống, kết hợp chúng trong tất cả các pha của quá trình phát triển Vìthế vấn đề đặc tả các thành phần phần mềm là một trong những vấn đề quan trọngcho quá trình tìm kiếm các thành phần phần mềm CBSD giúp cho các nhà pháttriển không cần quan tâm tới nội dung của mã thực thi trong các chương trình con

đó, lúc này các nhà phát triển chuyển từ việc lập trình tạo ra các sản phẩm sangviệc biên soạn các hệ thống phần mềm, tức là nó chỉ việc tập trung vào việc tíchhợp các thành phần COTS1 có sẵn để xây dựng nờn cỏc hệ thống có tên là các hệthống dựa trờn nờn thành phần mà không cần quan tâm tới chi tiết thực thi củathành phần như thế nào Ngoài ra, CBSD cũng chính là kỹ nghệ phần mềm trên

nền thành phần (component-based software engineering) (CBSE).

Ngày nay, CBSD đang dần trở thành một quy chuẩn chung cho hầu hết cỏccụng ty hay các tổ chức thương mại Muốn đứng vững trong cạnh tranh, tồn tạiđược dưới sự khắc nghiệt của nền kinh tế thị trường, giải pháp duy nhất là phải cómột một quy trình cho phép xây dựng các ứng dụng nhanh và có thể thay đổi đượcmột cách dễ dàng Và chỡa khoá để thực hiện giải pháp đó là chính là phươngpháp xây dựng các hệ thống dựa trên nền thành phần (CBSD) Việc sử dụng

phương pháp này sẽ mang lại cho cỏc hóng phỏt triển rất nhiều lợi ích cả về chấtlượng cũng như thời gian phát triển Nó rõ ràng là ít tốn kém hơn một cỏch đỏng

kể so với các phương pháp phát triển truyền thống

Nghiên cứu về CBSD, chúng ta cần nghiên cứu khá nhiều lĩnh vực Nhưng với

ý tưởng xây dựng quy trình tự động hoá chúng ta cần quan tâm các vấn đề chínhnhư vấn đề thành phần phần mềm, giao diện thành phần phần mềm, thiết kế và mô

tả kiến trúc phần mềm, tài liệu đặc tả cho các thành phần, tìm kiếm, lựa chọn cácthành phần … Chúng ta sẽ xem xét kỹ các vấn đề này trong các phần trong báocáo này

II Tổng quan về thành phần và giao diện thành phần phần mềm

1 Giới thiệu giao diện thành phần phần mềm

Các khả năng của thành phần phần mềm và cách sử dụng nó được đặc tảbởi giao diện Chúng ta có thể sử dụng một định nghĩa về giao diện như sau:

Giao diện là “một sự trừu tượng hóa dịch vụ, nó định nghĩa các thao tác

mà dịch vụ hỗ trợ, nó độc lập với bất kỳ sự thực thi đặc biệt nào”.

Một thành phần phần mềm giao tiếp với thế giới bên ngoài thông qua giaodiện của nó, với tài liệu đặc tả giao diện kèm theo sẽ cho chúng ta biết được nólàm gì (what), nội dung của mã thực thi trong thành phần, quy trình xử lý (how)được ẩn hoàn toàn và người sử dụng thành phần không phải quan tâm tới việc nólàm như thế nào

Các giao diện có thể được mô tả bằng cách sử dụng nhiều ký pháp khácnhau, nó phụ thuộc vào thông tin mà chúng ta muốn chứa đựng, và mức chi tiếtcủa đặt tả Phần giao diện chỉ mô tả tên của các phương thức, kiểu của các tham

số, và giá trị trả về tức là chỉ cung cấp các đặc tả của tập cỏc thỏo tỏc chứ khôngphải từng thao tác đơn lẻ gọi là phần đăng ký Tuy nhiên, thông tin này vẫn chưa

tả bao gồm sự định nghĩa chặt chẽ về cú pháp của các phương thức, cũng như mô

tả về ngữ nghĩa của giao diện

Ba mức vận hành này sẽ là những thứ được xem xét trong tài liệu này đểlựa chọn và tìm kiếm ra các thành phần thích hợp Tất nhiên, ký pháp được sửdụng để mô tả các giao diện của thành phần sẽ phụ thuộc vào mức độ chúng tamuốn che phủ Nó cũng sẽ ảnh hưởng đến các loại kết quả thu được khi suy ra cácđặc tính của ứng dụng từ các đặc tả của giao diện thành phần

2 Ngôn ngữ định nghĩa giao diện IDLs trong các kỹ thuật phát triển phần mềm tiêu biểu (COM, DCOM, CORBA, ASSEMBLY …)

Mỗi khi một ứng dụng trờn mỏy Client cần một dịch vụ của một đối tượng phântán từ xa nào đó, nó sẽ gửi một lời gọi phương thức được đối tượng đó cung cấp.Các dịch vụ do đối tượng phân tán từ xa trên Server cung cấp được gom lại thànhmột đối tượng với giao diện được mô tả trong một ngôn ngữ định nghĩa giao diệnIDL (Interface Definition Language) Các giao diện xác định trong một file IDLđược dùng như một “giao ước” giữa máy Client và đối tượng phân tán trên Server.Theo đó, cỏc máy Client có thể tương tác với các đối tượng từ xa này thông quaviệc gọi các phương thức đã được định nghĩa trong IDL

2.1 Tổng quan giao diện trong COM, DCOM

Một giao diện COM là 1 tập các thao tác có quan hệ một cách logic mà nóđịnh nghĩa một số hành vi Khi chúng ta định nghĩa một giao diện, chúng ta đangcung cấp sự định rõ của tập thao tác này, không có bất kỳ thực hiện ngoại lệ nào

Định nghĩa giao diện mô tả sự thoả thuận giữa người gọi và người thựchiện: nếu một thành phần thực hiện một giao diện riêng biệt, người gọi chờ đợithành phần có thể phải tuân theo đặc tả giao diện Đặc tả giao diện bao gồm nhữngđịnh nghĩa chặt chẽ về cú pháp của các phương thức giao diện, cũng như địnhnghĩa về ngữ nghĩa của giao diện

Để được coi là một giao diện COM, phải thoả mãn những yêu cầu sau [2] :

 Giao diện phải được xác định bởi 1 định danh duy nhất

 Giao diện phải được thừa kế từ một giao diện đặc biệt có tên IUnknown

 Khi đã được công bố, giao diện không được thay đổi (nghĩa là giao diệnkhông thể thay đổi)

Giao diện phải được định nghĩa sao cho các nhà phát triển thành phần biếtcách để hiện thực chúng và các nhà phát triển ứng dụng biết cách sử dụng chúng

Sự thật là COM chỉ quan tâm tới việc người gọi và người thực hiện có sự đồng ývới nhau về định nghĩa giao diện đó hay không Tuy nhiên, trong thực tế, các giaodiện COM thường được định nghĩa bằng ngôn ngữ định nghĩa giao diện (IDL).IDL là một ngôn ngữ giống C++ cho phép mô tả chính xác cú pháp giao diện củachúng ta

IDL là một định dạng text tiện lợi cho cú pháp giao diện văn bản Một khi

mã IDL được viết, nú có thể dịch bằng cách sử dụng trỡnh biờn dịch MicrosoftIDL (MIDL) để sinh ra các biểu diễn tương đương với định nghĩa giao diện, nó rấthữu ích cho cỏc cụng cụ phát triển của chúng ta

 Header file: Định nghĩa các kiểu mà nhà phát triển có thể sử dụng để khai báo

biến con trỏ giao diện hoặc dẫn xuất một lớp thi hành cho một giao diện Headerfile có thể bao gồm một chương trình C hoặc C++

 Type library: Thư viện kiểu là một biểu diễn nhị phân của mã IDL Cỏc cụng

cụng phát triển như Visual Basic đọc type library để xác định cú pháp của giaodiện được mô tả trong type library

 Source code for proxy/stub DLL: Việc thực hiện thư viện liên kết động proxy/

stub được sử dụng trong liên tiến trình và truyền thông từ xa Chúng ta sẽ thảoluận DLL trong phần tiếp theo "Kích hoạt và sắp xếp từ xa" của chương này.IDL không quá khó sử dụng, nhưng nó mới mẻ đối với nhiều nhà phát triển,hầu hết cỏc cụng cụ đều yêu cầu một vài sự hỗ trợ Một số công cụ, như VisualBasic, hoàn toàn che dấu IDL Các nhà phát triển định nghĩa trực tiếp giao diệntheo cú pháp VB và VB sinh ra type library cho giao diện Những công cụ khácsinh ra file IDL cho chúng ta Những công cụ này thường xuyên cung cấp một sốloại wizard để giúp chúng ta đinh nghĩa một giao diện và phương thức của nó, khi

đó họ để lộ ra cú pháp IDL chính xác Chúng ta sẽ gặp IDL nhiều hơn ở phần sau,khi bắt đầu thảo luận về thiết kế và thực thi các thành phần

Định nghĩa giao diện sử dụng IDL là bước đầu tiên hướng tới sự độc lập vềngôn ngữ nhưng nó chưa cho chúng ta tất cả mọi thứ để đạt được điều đó Với mộtfile IDL hoặc một header file hay một type library tương ứng, một nhà phát triển

có thể mó hoá việc hiện thực của giao diện hoặc một ứng dụng khách sử dụng giaodiện trong bất kỡ ngụn ngữ nào miễn là ngôn ngữ đó hiểu được những kiểu đãđược sử dụng trong giao diện đó Để bảo đảm rằng ứng dụng khách và sự thựchiện có thể nói chuyện được với nhau, cả hai phía phải đồng ý rằng con trỏ giaodiện biểu diễn cái gì và làm thế nào để gọi phương thức thông qua con trỏ đó.COM được gọi là tiêu chuẩn nhị phân COM định nghĩa biểu diễn nhị phân chínhxác của một giao diện Bất kì một ngôn ngữ lập trình hoặc công cụ hỗ trợ COMđều phải tạo ra các giao diện đối tượng tương ứng với biểu diễn chuẩn này

File IDL của DCOM cho thấy DCOM Server cung cấp một giao diện kép

khác với giao diện gọi động DII của CORBA và phương phỏp ỏnh xạ (Reflection)của Java Khi làm việc với một lời gọi tĩnh, trỡnh biờn dịch MIDL sẽ tạo ra mã cảproxy và stub khi chạy trên file IDL Chúng sẽ được đăng ký trong Registry của hệthống để có thể sử dụng linh hoạt hơn Đáp lại một lời gọi động, đối tượng COM

sẽ cung cấp một giao diện có tên là IDispatch Cũng như CORBA hay Java RMI,DCOM có nhiều cách mô tả các phương thức và tham số của một đối tượng khithực hiện một lời gọi động Các thư viện động được sử dụng để mô tả các đốitượng, và COM sẽ cung cấp các giao diện bằng cách truy vấn tới thư viện đốitượng thông qua giao diện IDispatch Mỗi đối tượng COM phải hỗ trợ giao diệnIDispatch mới có khả năng nhận các lời gọi động tới các phương thức của nó.Điều này không giống như CORBA – mô hình cho phép gọi bất kỳ đối tượng nào

có thông tin được lưu trong kho IR (Implementation Respository) thông qua DII.Trong DCOM, mỗi giao diện được phân biệt bởi một định danh UUID(Universally Unique Identifier) gọi là IID (Interface ID) Tương tự mỗi lớp đốitượng cũng được gán cho một định danh UUID duy nhất gọi là CLSID (Class ID).Thay vì hỗ trợ tính đa thừa kế cho các đối tượng, COM cung cấp nhiều giao diệncho mỗi đối tượng để đạt được tính năng tương tự Điều này cũng cho phép côngviệc lập trỡnh cú thể thực hiện một cách linh hoạt

2.2 Tổng quan giao diện trong CORBA

Mô hình CORBA phát triển dựa trên giao thức IIOP (Internet Inter ORBProtocol) để điều khiển các đối tượng phân tán trên mạng theo một phương pháptrong suốt đối với người lập trỡnh Cỏc đối tượng CORBA được truy cập bằngcách sử dụng một giao diện với một tập các phương thức Ngôn ngữ định nghĩagiao diện IDL (Interface Definition Language) của OMG được sử dụng để xácđịnh các giao diện, các thuộc tớnh, cỏc phương thức và các tham số cho cácphương thức bên trong giao diện

Thành phần trung tâm của CORBA là Object Request Broker (ORB).Thành phần này cung cấp tất cả cơ sở hạ tầng truyền thông cần thiết để xác định

và định vị các đối tượng, thực hiện điều khiển kết nối và phân tán dữ liệu và yêucầu truyền thông Một đối tượng CORBA không giao tiếp trực tiếp với một đốitượng CORBA khác Thay vào đó, đối tượng yêu cầu một giao diện tới ORB chạytrờn mỏy cục bộ Tiếp đó ORB từ xa định vị đối tượng thích hợp và chuyển lạimột tham chiếu đối tượng cho bờn yờu cầu Ngoài ra, các đối tượng CORBA cũng

có thể tương tác với nhau qua một bộ Object Adapter như BOA (Basic ObjectAdapter) hay POA (Portable Object Adapter) Từ khi được phát triển, CORBA có

thể chạy trên nhiều hệ thống khác nhau, từ cỏc máy chủ trên nền Unix tới các máytính cá nhân với hệ điều hành Windows, chỉ với điều kiện các hệ thống này có hỗtrợ CORBA CORBA tách biệt rõ ràng giữa giao diện và sự thực hiện.Chỳ ýCORBA không phải là một ngôn ngữ lập trình mà chỉ là ngôn ngữ đặc tả

Kiến trúc CORBA cung cấp một cái nhìn thấu đáo bên trong cách làm việccủa CORBA Nó cho biết thành phần mà đặc tả CORBA yêu cầu cũng như cácphần thực hiện mà CORBA không ràng buộc và phụ thuộc cách thi hành

Hình 1.1 Các giao diện cơ bản của CORBA.

Hình 1.1 chỉ ra cách phần mềm ứng dụng giao tiếp kết nối qua ORB.CORBA chuẩn hoỏ cỏc giao diện ORB Trên đỉnh của hình 1.1 là client và sự thihành đối tượng Hai bộ phận này của phần mềm ứng dụng nằm ngoài ORB.Những phần còn lại trong lược đồ là các thành phần có trong ORB Đáy của lược

đồ là nhân ORB mà chi tiết của nú khụng bị bắt buộc bởi đặc tả CORBA NhânORB có thể được thực hiện theo bất cứ cách nào mà các nhà cung cấp sản phẩm

Object Implementation

ORB CoreGiao diện phụ thuộc vào ORBMỗi kiểu đối tượng có riêng stub và skeleton của mình

Giao diện không thay đổi với mọi ORB

Có thể có nhiều loại Object Adapter

chọn lựa Thậm chí người sử dụng có thể thay thể một phần của hạ tầng cơ sởCORBA bằng cơ cấu độc nhất.

Để client có thể sử dụng dịch vụ của một đối tượng thỡ nú phải phát ra yêucầu thông qua giao diện tầng trên của ORB Giao diện này được chia ra thành 3loại:

 Loại giao diện thứ nhất được định nghĩa sẵn trong đặc tả CORBA Mọimôi trường ORB đều hỗ trợ chúng Giao diện này bao gồm dynamicinvocation, giao diện ORB và dynamic skeleton Chúng đều được địnhnghĩa bằng IDL hoặc PIDL (giả IDL) Trong một số trường hợp, đặc tảCORBA có chứa định nghĩa giao diện bằng PIDL cho các đối tượng ORBchuẩn thường được thực hiện ở không gian địa chỉ phía client Ví dụ nhưgiao diện dynamic invocation tạo ra một đối tượng yêu cầu giả PIDL củatrường hợp này sử dụng con trỏ void trong bản mẫu yêu cầu, trực tiếp xácđịnh cách truyền kiểu tham số này được định kiểu khi chạy Đõy là đặc tả ítđược sử dụng và nói chung, bị tránh trong tất cả các đặc tả khác nhưCORBAService và CORBAFacilities Nó chỉ là một quy ước về ký pháptrong một số trường hợp đặc biệt của CORBA

 Loại giao diện thứ hai tương ứng với bộ thích ứng đối tượng - objectadapter Hiện tại, CORBA đã định nghĩa sẵn basic object adapter Objectadapter này cung cấp một số khả năng chung để hợp nhất sự thi hành đốitượng với môi trường ORB

Loại giao diện cuối cùng trong kiến trúc CORBA được người dùng định nghĩabằng IDL Chúng là những stub, static skeleton và các tập tin header cần thiếtđược sinh trong phộp ỏnh xạ từ IDL sang ngôn ngữ cụ thể Loại giao diện này chophép sử dụng CORBA theo cách tự nhiên và dễ dàng nhất Cả CORBA và JavaRMI cùng hỗ trợ khả năng đa thừa kế trên IDL hay mức giao diện Một điểm khácbiệt lớn giữa CORBA với DCOM là CORBA có thể xác định các ngoại lệ trongfile IDL trong khi DCOM hoàn toàn không cung cấp khả năng này TrongCORBA, trỡnh biờn dịch IDL sẽ tạo ra các thông tin về mỗi phương thức trongmột giao diện và chứa chúng trong kho IR (Implementation Repository) Theo đó,một máy Client có thể truy vấn tới IR để lấy thông tin chi tiết về một giao diện và

sử dụng những thông tin đó để tạo và gọi một phương thức động của một đốitượng trên Server thông qua DII (Dynamic Invocation Interface) Tương tự, vềphía Server, giao diện DSI (Dynamic Skeleton Interface) sẽ cho phép một máyClient gọi một thao tác của đối tượng CORBA trên Server ngay cả khi đối tượng

đó chưa từng được biên dịch Khi trỡnh biờn dich IDL gặp một file IDL như thế,

nó sẽ tạo ra các file cho cả Stub và Skeleton

2.3 So sánh khả năng về giao diện của các kỹ thuật

các đối tượng và sử dụng phương

thức truy vấn giao diện

-QueryInterface() để gọi đối tượng

thông qua một trong các giao diện

Hỗ trợ khả năng đa thừa kế trong mỗigiao diện

lớp IUnknown

Mọi giao diện được thừa kế từCorba.Object

3 Các đối tượng trên Server được xác

định bởi một con trỏ, trỏ đến giao

diện hiện đang được sử dụng của

đối tượng đó

Các đối tượng trên Server được xácđịnh thông qua các tham chiếu(ObjRef) tới chúng

4 Các giao diện được xác định bởi

IID (Interface IDs - định danh giao

diện) và các đối tượng trên Server

được phân biệt bởi tên đầy đủ của

chúng thông qua một ánh xạ tới

CLSID (Class IDs) trong Registry

Các giao diện được xác định thôngqua tên của chúng và các đối tượngtrên Server được phân biệt bởi tênđầy đủ của chúng thông qua một ánh

xạ tới một “kho” lưu trữ

5 Các ứng dụng Client điều khiển đối

tượng từ xa thông qua một con trỏ

giao diện

Các ứng dụng Client điều khiển đốitượng từ xa thông qua một thamchiếu tới đối tượng đó

6 Các ánh xạ từ mỗi đối tượng tới tên

đầy đủ của chúng được lưu trữ

trong Registry

Các ánh xạ từ mỗi đối tượng tới tênđầy đủ của chúng được lưu trữ trongmột “kho” lưu trữ

thức được lưu trữ trong một thư

viện kiểu (Type Library)

Các thông tin về mỗi loại phươngthức được lưu trữ trong một “kho”giao diện (Interface Repository)

8 Mọi tham số truyền giữa các đối

tượng Client và Server được xác

Khi các tham số được truyền giữacác đối tượng Client và Server, mọi

diện Do đó, tùy vào IDL mà các

tham số được truyền theo giá trị

hay địa chỉ

địa chỉ Mọi đối tượng khác đượctruyền theo giá trị, kèm theo kiểu dữliệu

9 Cho phép tùy biến các kiểu cấu trúc

dữ liệu và truyền đi như một tham

số Tuy nhiên các cấu trúc dữ liệu

nằm ngoài giao diện phải được khai

báo trong IDL

Các cấu trúc dữ liệu nằm ngoài giaodiện phải được khai báo trong IDL

hỗ trợ mô hình COM

Có thể chạy trên mọi hệ thống có hỗtrợ mô hình CORBA ORB

Ghi chú:

COM (Component Object Model) - Mô hình đối tượng thành phần: là công nghệ

của Mirosoft định nghĩa sự tượng tác giữa các đối tượng trong môi trường

Windows

DCOM (Distributed Componenent Object Model): là một phiên bản của COM

dùng trong mạng cho phộp các đối tượng ở những máy khác nhau trên mạng cóthể tương tác với nhau COM và DCOM là công nghệ cốt lõi của ActiveX, là môhình thành phần của Microsoft dùng trong Intranet và Internet

CORBA( Common Object Request Broker Architecture): là một công nghệ đối

tượng phân bố xác định bởi OMG (Object Management Group) trong kiến trúc OMA (Object Management Architecture) Kiến trúc này cũng đã được chấp nhận bởi The Open Group

Tham khảo giao diện trong C#:

Cú pháp giao diện trong C#:

Để khai báo một giao diện, chúng ta dùng từ khoá interface thay vì từ khoáclass hay struct

Thực hiện một giao diện:

Để thực hiện một giao diện, chúng ta khai báo một lớp (hay một cấu trúc )

kế thừa từ một giao diện và cài đặt tất cả các phương thức của giao diện đó

Ví dụ:

Class Token : Itoken

{

…

// Các phương thức được khai báo luôn là toàn cục

public string Name()

{

…}

Kết luận chung: Qua chương này chúng ta đã làm quen với khái niệm

giao diện trong công nghệ phần mềm hướng thành phần Một giao diện cho phép chúng ta tách rời hoàn tên của một phương thức từ việc cài đặt một

phương thức Giao diện cho phép chúng ta tách rời thực sự “cỏi gỡ” từ “như thế nào” Giao diện nói cho chúng ta biết tên của phương thức là gì Giao diện trình bày cách một đối tượng được dùng như thế nào hơn là cách mà nó ngẫu nhiên được cài đặt như thế nào Điều này phù hợp một cách gần gũi với cách con người làm việc Ví dụ: cách điện thoại làm việc không liên quan đến chúng

ta bởi chúng ta chỉ là người dựng chỳng, chúng ta không tạo ra chúng Đủ để biết chức năng của nó là gì và làm cách nào dựng chỳng thực hiện chức năng

đó Tại sao chúng ta muốn vậy ? Bởi vì chúng ta chỉ là người dùng

CHƯƠNG 2: THAM KHẢO Mệ•T MÔ HÌNH HỆ THỐNG TỰ ĐỘNG HÓA TÌM KIẾM, LỰA CHỌN THÀNH PHẦN PHẦN MỀM TỪ KHO DỮ LIỆU

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 nền thành phần phần mềm

(COTS) ngày càng được sử dụng nhiều vào CBSE cho việc xây dựng cácứng dụng phần mềm, đồng thời các nhà phát triển ứng dụng này yêu cầu có một số

cơ chế để mô tả, tìm kiếm, lựa chọn và viết các components COTS

Trong CBSE, người thiết kế hệ thống phải có sẵn các đặc tả các thành phầnCOTS trước khi đưa ra phát triển trong kho chứa phần mềm, thậm chớ chỳng phảiđược xem xét, đánh giá ngay lúc khi xây dựng cỏc yờu cầu ban đầu của hệ thống,kết hợp chúng vào tất cả các pha trong tiến trỡnh phỏt triển[Mili et al.,1995,Robertson and Robertson, 1999]

Ở đây, những người xây dựng, người thiết kế, người kiến trúc hệ thống phảiđảm nhận các điểm cân bằng giữa 3 khái niệm chớnh: yờu cầu người dùng, kiếntrúc hệ thống, kiến trúc hệ thống, sản phẩm COTS (user requirements, system

architecture and COTS products [23][24] Những giải pháp về công nghệ phần

mềm hiện thời thường dựa trờn cỏc phương pháp xoắn ốc [6], vì mô hình xoắn ốc

có nhiều ưu điểm, nên chúng ta sẽ tiếp cận với mô hình này

Trong hướng tiếp cận này, một kiến trúc phần mềm trừu tượng của hệthống sẽ được định nghĩa trước, kiến trúc này mô tả các đặc điểm của các thành

phần phần mềm trừu tượng (abstract component) và mối quan hệ giữa chúng.

Những thành phần trừu tượng này sau đó sẽ được xem xét và so sánh với danhsỏch các components COTS cụ thể có sẵn trong một kho dữ liệu để tìm ra cácthành phần COTS thích hợp Quá trình này tạo ra một danh sách các thành phầnứng cử viên từ kho chứa, cái mà có thể hình thành nờn cỏc phần của ứng dụng: cácthành phần ứng cử viờn này phải cung cấp một số dịch vụ được yêu cầu bởi ứngdụng, và đáp ứng một số cỏc yêu cầu người dùng như giá, bảo mật Sau đó các tiếntrỡnh tỡm kiếm lựa chọn sẽ được thực hiện để cuối cùng đưa ra được những cấuhình thoả mãn tối ưu cho kiến trúc phần mềm, tạo thành ứng dụng hoàn chỉnh

Sau đây chúng ta sẽ tiếp cận một mô hình tự động hoá cho quy trình pháttriển phần mềm dựa từ các COTS đó cú sẵn

1 Mô hình

UML-RT ( Rational Rose RealTime )

COTSCompone

nt and COTSQuery templates

COTSconfig p rocess

COTStrader process

4

Closure process

Hình 2.1 Mô hình phát triển phần mềm dựa thành phần

Hình 2.2 Một kiến trúc phần mềm dựa nền thành phần

Mô hình 2.1 được chia làm 3 giai đoạn chính Trong đó giai đoạn đầu tiên

là vấn đề xây dựng kiến trúc phần mềm Hình 2.2 biễu diễn một kiến trúc phầnmềm trừu tượng được định nghĩa ngay từ bước đầu thông qua cỏc yờu cầu của

người dựng, mụ tả được đặc tả các components trừu tượng(abstract components)

có trong kiến trúc phần mềm và các mối quan hệ giữa chúng

Nhờ các tiến trình sau đó, các components trừu tượng này đó sẽ được đối

sánh với danh sách các COTS components cụ thể(concrete COTS components) có

sẵn trong kho phần mềm Tiến trình đối sánh này sẽ đưa ra một danh sách cáccomponents ứng cử viên, dần dần hình thành nên một phần của ứng dụng cần xâydựng Các components có thể được lựa chọn theo nhiều phương diện, cả nhữngcomponent mà chúng cung cấp các dịch vụ được yêu cầu, hoặc chúng thoả móncỏc yờu cầu của người dựng(gọi là extra-functional) như về giá cả, các giới hạn vềmức bảo mật… Với danh sách này, kiến trúc hệ thống sẽ được xét duyệt lại đểcung cấp càng nhiều ứng cử viên từ danh sách với khả năng có thể Sau đú cỏcyờu cầu hệ thống được đối sánh với những cái được cung cấp bởi kiến trúc vàđược xét duyệt lại nếu cần thiết

Cuối cựng, cỏc “wrappers” có thể được sử dụng để lắp ghép, sửa đổi cácCOTS components đã được lựa chọn(cho ẩn đi các dịch vụ phụ không được yêucầu, hoặc thay đổi các giao diện của chúng cho phù hợp và tương thích, phù hợpcỏc yờu cầu về liên kết, tương tác giữa các components), và một số ngôn ngữ liênkết - “glue language” có thể được sử dụng để thiết kế, định vị, sắp xếp, lắp rỏpcỏc components(Xem Hình 2.2).

Tiến trình cuối cùng trong quy trình trên là lựa chọn ra các cấu hình từ danhsách các components ứng cử viên thoả món cỏc yờu cầu trong kiến trúc phầnmềm Chúng ta sẽ tập trung đi sâu những giải phỏp tỡm kiếm lựa chọn, và sẽnghiên cứu đến một thuật toán lựa chọn đang tối ưu hơn Phần này chúng ta sẽ tiếptục bàn luận ở phần tiếp theo

(Bước 1): Theo mô hình trên, để mô tả kiến trúc phần mềm, chúng ta sử

dụng UML-RT [25] [Selic and Rumbaugh, 1998]

(Bước 2): Một mẫu chuẩn XML đã được định nghĩa trước dành riêng đặc tảcho các component COTS, cho phép mô tả cả những thuộc tính chức năng -

“functional” và các thuộc tớnh khụng phải là dịch vụ - “extra-functionalproperties” Cần có một cơ chế tự động để xuất các thông tin từ UML-RT thànhcác mẫu XML đặc tả

(Bước 3.1): Tiến trình lựa chọn ra danh sách các thành phần ứng cử viên từkho chứa mẫu XML đặc tả component (gọi là tiến trình trading) sẽ được đượcthực hiện bởi “COTStrader” Trên thế giới đã một Tool đã được xây dựng cho việclựa chọn -”trading” các thành phần trong các hệ thống mở Tham khảo ở tài liệukèm theo

Sau đó cần một thuật toán để lựa chọn ra các tổ hợp thành phần từ danhsách thành phần ứng cử viên để tạo ra các cấu hình thoả mãn kiến trúc phần mềmyêu cầu - (Bước 3.2)

Và trong thời gian tới em sẽ tiếp tục nghiên cứu về Thuật toỏn tỡm kiếm vàlựa chọn thành phần Chúng ta cũng sẽ tập trunng mô tả các giai đoạn trong môhình trên ở Chương 4 với ứng dụng cụ thể GTS

(Bước 3.3): Bước cuối cùng là bước đóng kín các cấu hình để tạo ra mộtứng dụng hoàn chỉnh, và công việc của người phát triển là lựa chọn cấu hình tối

ưu nhất Như vậy, có thể nói toàn bộ tiến trình là tự động

Để mô tả chi tiết cho các bước trên, ở Chương 4 chúng ta sẽ mô tả chi tiếtcác bước trong mô hình qua một ứng dụng GTS (Geographic Translator System)

đã được xây dựng

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 chọn Components

2.1 Tạ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ếntrúc phần mềm

b) Đánh giá các components nàyc) Sửa và mở rộng các components được lựa chọn để phù hợpvớ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ựaCOTS 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(thirdparties), 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ờncỏc khỏi niệm về giao diện component (giao diện sẽ cung cấp một form để điềukhiể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 quangô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ápcomponent, 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ăngnon-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 đangtrở 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ấptiệ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 COTScomponents đã 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 chotraders; Nhưng vấn đề đó là, các traders hiện thời không cung cấp tất cả các chứcnă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ácthà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ữngngườ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ếm

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ánphần mềm) để xuất và nhập các components trao đổi cới các kho dữ liệu phầnmề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

CORBA IDL

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ẽ baogồ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ụ đượccung 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 trongthẻ 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 chitiế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 chitiế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ủamộ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ậnthấ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ễnkiế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 caocủ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ếtADLs đó 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áchướng nghiên cứu này, kí hiệu mô hình cho mục đích chung “general-purposemodeling ký phỏp” UML rõ ràng là ứng cử viên sáng giá, vỡ nú thõn thiện vớinhữ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ôngnghệ “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ấpcá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áttriển ứng dụng phần mềm dựa thành phần và các kiến trúc “run-timearchitectures”) 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 thunhận các mẫu truyền thông kiến trúc (structural communication patterns) giữa cácthà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ựcquan với ngữ nghĩa thông thường (formal semantics ) cho cụ thể hoá, trực quanhoá, 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-timesystems)

Hình 2.4 Một ví dụ về kiến trúc phần mềm trong UML-RT

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áccổ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 ragiao 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, giaodiệ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ủaCOST Ví dụ, hình 2.6 chỉ ra giao diện của thành phần Translator như là các cổngcủa UML-RT Thành phần này được nêu ra ở phần mô tả tài liệu đặc tả TranslatorCOTS

Ở 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)

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ỏpUML-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áccomponents 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 tintrong “capsure, capsure là một khái niệm trong UML-RT để lưu các thông tin về

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 trongphầ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 commercialcomponents”)

Đố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 theokeywords) 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ìmkiếm được sử dụng(mạnh dần) là: tìm kiếm theo : keywords, marketing và thôngtin gói phần mềm(Hệ điều hành, cỏc mụhỡnh component ), các thuộc tính chấtlượ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ácnhà 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ấtlượ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 giaodiệ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ựngmộ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ợpcomponents để 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ầnmề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 radanh 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ìmkiế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 = R 1 ,…,R n, 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 = R 1 ,…, R m.”

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ệncủa CORBA hay COM) được kết hợp từ một tập các thuộc tính và phương thứccô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ì C B (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ếntrú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 đượctì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) Để đơngiản chúng ta sử dụng 2 đặc điểm chính cho ký hiệu là tên và giao diệncomopnent Ví dụ component “FileCompressor” sẽ được viết là FC và giao diệncủ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ụnggian(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ônggian (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 quantớ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

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 đượcxem 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ựchiệ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âydự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ừngbướ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ỏ đinhữ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, protocollevel or semantic level operator) Tuy nhiên để giảm độ phức tạp số mũ, chúng ta

có thể thay đổi thuật toán vào một “branch and bound' one upper bounds to prunemany of the options in the exploration tree, do đó sẽ cải thiện được thời gian chạycủa thuật toán

Bảng 2.2 Sơ đồ thuật toán tạo cấu hình