đồ á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


Báo cáo thực tập tốt nghiệp
CHUYÊN NGÀNH CễNG NGHỆ THÔNG TIN


 !"#
#$%!
&#
'(#
Giáo viên hướng dẫn: Sinh viên thực hiện:
)*+, +/01.2-3 .4-.056
Lớp:
K44 – CNPM
786 9:9;;<
Danh mục từ viết tắt sử dụng trong báo cáo thực tập
)=

>?601121 6@6-3.A4
1. ADL Architectural Description languages
2. CBS COTS-Based Systems
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

2
14. OSD Open Software Description
15. NFRs Non-Functional Requirement
16. Q
o
S,
17. UML Unified Modeling Language
18. UML-RT UML Real Time
19. UUID uniservally unique identifer
3
Danh mục các hình vẽ trong báo cáo thực tập
4
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4BC+DEFCBGH1C
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
5
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
I 9*JK*L1@!:MN41O1M@MPMMGQBG-E-1C1HG-3R60-1HSMB.T-QUQ)
56
6
Danh mục các bảng trong báo cáo thực tập
V@-3J* )GCP R.@-W-3?U364GX6Y-MN4MPMRZ1.+[1 *********************************J<
V@-39*J* %4 CPM.MPMMGQBG-E-1C1HG-3)?7X4 CPM.\-3M]?6^-*****_9
V@-39*9* )`ab1.+[11GP-15GMO+.I *****************************************************************__
V@-39*_* 81C=R01c+@MN41.+[11GP-MG-d63ef?g6?hXi)*************************jk
7

l!l
'mJnoOp&#
%q#oorst
%%!C**************************************************************************************************<
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
J*6g61.6Y+364GX6Y-1.7 B.T-B.T-QUQ********************************************************u
9*3L--3vaw -3.A4364GX6Y-%!C1HG-3MPMRZ1.+[1B.P11H6x-B.T-QUQ
16^+y6x+e % V ))zV!{f*********************************************|
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
'm9Y}~•
 !"##$%!
******************************************************************************************************************************Jj
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
J*L.I *****************************************************************************************************************Ju
9*PMaU€+O1?U-3L--3va•Ma•M1@axM@61.6Y-c+P1HI 1IQR60Q ?7D‚4
M.ƒ-GQBG-E-1C*****************************************************************************************************JK
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
_*IQR60QMPM1.7 B.T-\-3M]?6^-****************************************************************9k
<*.+[11G„-1…QR60Q?7D‚4M.ƒ-1.7 B.T-**************************************************9K
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
'm_*%!† %!‡oor
!' ˆ‰!h~ˆ!†******************************************_<
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
1
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
_*ˆ!a=6?g6C‚B.Š-1P-.4/1hM..‹B**************************************************************_K
<*81C‚B.Š-DG56MN4MPM.Y1.=-3)%!B.Š-1P-*****************************************_K
j*ˆ]DŒ1H+/?O-1HG-3)%!ˆ!B.Š-1P-******************************************************<_
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
J*6g61.6Y+**************************************************************************************************************<K
9*.601R0R60-1HSMB.T-QUQ)1HG-3!•***************************************j_
2.1 Kiến trúc GTS trong UML-RT 53
2.2 Mapping UML-RT GTS tới chuẩn UML 55
2.3 Chuyển các thông tin vào các capsules 56
_*.‚M.6Y-1.+[11GP-D‚4M.ƒ-?7R01c+@*********************************************************jk
:!‡***********************************************************************************u;
1. Cỏc nghiờn cứu tiến hành trong thực tập tốt nghiệp 60
2. Kết luận 62
******************************************************************************************************************************u9
PM1>1HG-31>a6x-********************************************************************************************u_
76D6Y+1.4QR.@G***********************************************************************************************uu
2
!Ž6-•6aT+
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.
3
'mJnoOp&#
%q#oorst
%%!C
*•-3c+4-ML-3-3.YB.P11H6x-B.T-QUQX‚4-U-1.7 B.T-eV)%f

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ện
phá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ình
huống(events) mà ứng dụng yêu cầu nó thực hiện.Tức là 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.
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ờu
cầ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ọng
cho 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át
triể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 sang
việ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ích
hợp các thành phần COTS
1
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ủa
thà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ỏc
cụ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 được
một cách dễ dàng. Và chỡa khoá để thực hiện giải pháp đó là chính là phương
phá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

1
COTS là các thành phần phần mềm thương mại được phát triển độc lập với hệ thống cần xây
dựng (Xem kỹ phần giới thiệu về COTS và NDI)
4
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ất
lượ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ính
như 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ác
thành phần … Chúng ta sẽ xem xét kỹ các vấn đề này trong các phần trong báo
cáo này.
5
*•-3c+4-?U1.7 B.T-?7364GX6Y-1.7 B.T-B.T-QUQ
J*6g61.6Y+364GX6Y-1.7 B.T-B.T-QUQ
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 giao
diệ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ác
nhau, nó phụ thuộc vào thông tin mà chúng ta muốn chứa đựng, và mức chi tiết
củ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ông
phả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

đủ để phát triển các ứng dụng cho hệ thống mở [22].
Ở trên phần đăng ký (signature) là mức ngữ nghĩa (semantic level) liên
quan tới “ý nghĩa” của các thao tác - hành vi – và mức giao thức (protocol level)
liên quan tới các giao thức truy cập dịch vụ của thành phần. Nú chớnh là các thủ
tục riêng mà thành phần phải tuân thủ nếu chúng muốn các phương thức của
chúng được gọi, hoặc khi chúng muốn gọi các phương thức khác. Hay nói rõ hơn,
nếu một thành phần thực hiện một công việc cụ thể và cung cấp một giao diện thỡ
bờn gọi có thể sử dụng thành phần đó nếu tuân theo các đặc tả giao diện. Các đặc
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 ta
muố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.
6
9* 3L--3vaw -3.A4364GX6Y-%!C1HG-3MPMRZ1.+[1B.P11H6x-
B.T-QUQ16^+y6x+e % V ))zV!{f
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ân
tá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ành
một đối tượng với giao diện được mô tả trong một ngôn ngữ định nghĩa giao diện
IDL (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 qua
việ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 đang
cung 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ực
hiệ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ờ đợi
thà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ư định
nghĩ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ện
khô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ết
cá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 giao
diệ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ủa
chúng ta.
7
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 Microsoft
IDL (MIDL) để sinh ra các biểu diễn tương đương với định nghĩa giao diện, nó rất
hữ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. Header
file 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 giao
diệ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ảo luậ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ư Visual
Basic, hoàn toàn che dấu IDL. Các nhà phát triển định nghĩa trực tiếp giao diện
theo cú pháp VB và VB sinh ra type library cho giao diện. Những công cụ khác
sinh 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ột
file 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 giao
diệ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ực
hiện có thể nói chuyện được với nhau, cả hai phía phải đồng ý rằng con trỏ giao
diệ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ính
xá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.
COM hỗ trợ cả hai hình thức gọi tĩnh và động tới các đối tượng. Nó hoạt động hơi
8
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 khi
thực hiện một lời gọi động. Các thư viện động được sử dụng để mô tả các đối

tượng, và COM sẽ cung cấp các giao diện bằng cách truy vấn tới thư viện đối
tượng thông qua giao diện IDispatch. Mỗi đối tượng COM phải hỗ trợ giao diện
IDispatch 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 đối
tượ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ện
cho mỗi đối tượng để đạt được tính năng tương tự. Điều này cũng cho phép công
việ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 ORB
Protocol) để điều khiển các đối tượng phân tán trên mạng theo một phương pháp
trong suốt đối với người lập trỡnh. Cỏc đối tượng CORBA được truy cập bằng
cá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ĩa
giao 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ác
phươ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êu
cầu truyền thông. Một đối tượng CORBA không giao tiếp trực tiếp với một đối
tượng CORBA khác. Thay vào đó, đối tượng yêu cầu một giao diện tới ORB chạy
trờn mỏy cục bộ. Tiếp đó ORB từ xa định vị đối tượng thích hợp và chuyển lại
mộ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 Object
Adapter) hay POA (Portable Object Adapter). Từ khi được phát triển, CORBA có
9
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áy

tí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ệc
của CORBA. Nó cho biết thành phần mà đặc tả CORBA yêu cầu cũng như các
phần thực hiện mà CORBA không ràng buộc và phụ thuộc cách thi hành.


I J*JPM364GX6Y-M`y@-MN4V*
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ự thi
hà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ân
ORB 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
ORB Core
Client
Stub Dynamic
Invocation
ORB
Interface

Object Adapter
Dynamic
Skeleton
Static
Skeleton
Object Implementation
ORB Core
Giao diện phụ thuộc vào ORB

Mỗ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
10
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êu
cầu thông qua giao diện tầng trên của ORB. Giao diện này được chia ra thành 3
loại:
• Loại giao diện thứ nhất được định nghĩa sẵn trong đặc tả CORBA. Mọi
môi trường ORB đều hỗ trợ chúng. Giao diện này bao gồm dynamic
invocation, giao diện ORB và dynamic skeleton. Chúng đều được định
nghĩ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 ORB
chuẩ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ủa
trườ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áp
trong 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 - object
adapter. Hiện tại, CORBA đã định nghĩa sẵn basic object adapter. Object
adapter này cung cấp một số khả năng chung để hợp nhất sự thi hành đối
tượ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ĩa
bằ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 cho
phép sử dụng CORBA theo cách tự nhiên và dễ dàng nhất. Cả CORBA và Java
RMI 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ác

biệt lớn giữa CORBA với DCOM là CORBA có thể xác định các ngoại lệ trong
file IDL trong khi DCOM hoàn toàn không cung cấp khả năng này. Trong
CORBA, trỡnh biờn dịch IDL sẽ tạo ra các thông tin về mỗi phương thức trong
mộ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 đối
tượ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áy
Client 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.
11
2.3. So sánh khả năng về giao diện của các kỹ thuật
STT DCOM CORBA
1 Hỗ trợ khả năng đa giao diện cho
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ỗi
giao diện.
2 Mọi đối tượng được cung cấp bởi
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ông
qua tên của chúng 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 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 đối
tượng từ xa thông qua một tham
chiế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ữ trong
một “kho” lưu trữ.
7 Các thông tin về mỗi loại phương
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ương
thứ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
đinh bởi một file định nghĩa giao
Khi các tham số được truyền giữa
các đối tượng Client và Server, mọi
kiểu giao diện cũng được truyền theo
12
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 được
truyề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 giao
diện phải được khai báo trong IDL.
10 Có thể chạy trên mọi hệ thống có
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.
.6M.S
(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.
% (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.
V( 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.
.4QR.@G364GX6Y-1HG-3‘
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.
Ví dụ:
Interface Itoken
{
// Khai bỏo các phương thức chính xác như trong lớp hay cấu trúc
string Name();
}
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ụ:
13
Class Token : Itoken
{
…
// Các phương thức được khai báo luôn là toàn cục
public string Name()
{
…
}

}
Một lớp có thể mở rộng lớp khác và cài đặt một giao diện. Lớp cơ sở được
đặt tên trước, theo sau là dấu phẩy, sau nữa là giao diện cơ sở.
Ví dụ:
Interface IToken
{
……
}
class DefaultTokenImpl
{
…
}
class IdentifierToken : DefaultTokenImpl, IToken
{
…
}
01D+[-M.+-3 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.
14
'm9Y}~•
 !"##$%!

*6g61.6Y+QL.I .G7-M.’ M.Gc+/1HI €Š/X‚-3B.T-QUQX‚4
1H^--U-1.7 B.T-B.T-QUQ
(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ần
COTS 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ến
trú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 danh
sỏch các components COTS cụ thể có sẵn trong một kho dữ liệu để tìm ra các
thà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ác
thà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 ứng
dụ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ến trỡ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ấu hì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át
triển phần mềm dựa từ các COTS đó cú sẵn.
15

J*L.I
UML-RT (
Rational Rose
RealTime
)
COTSComponen
t
and
COTSQuery
templates

)MG-d63BH
GMECC

COTStrader p
rocess

<
Closure
process
Hình 2.1. Mô hình phát triển phần mềm dựa thành phần
16
I 9*981R60-1HSMB.T-QUQX‚4-U-1.7 B.T-
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ần
mề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ác
components ứ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ây
dựng. Các components có thể được lựa chọn theo nhiều phương diện, cả những
component mà chúng cung cấp các dịch vụ được yêu cầu, hoặc chúng thoả món
cỏ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ỏc
yờ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.
17
Cuối cựng, cỏc “wrappers” có thể được sử dụng để lắp ghép, sửa đổi các
COTS components đã được lựa chọn(cho ẩn đi các dịch vụ phụ không được yêu
cầ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ợp
cỏ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ên
kết - “glue language” có thể được sử dụng để thiết kế, định vị, sắp xếp, lắp rỏp
cỏ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ừ danh
sách các components ứng cử viên thoả món cỏc yờu cầu trong kiến trúc phần
mề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ếp
tụ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-functional
properties”. Cần có một cơ chế tự động để xuất các thông tin từ UML-RT thành
cá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 được

thực hiện bởi “COTStrader”. Trên thế giới đã một Tool đã được xây dựng cho việc
lựa chọn -”trading” các thành phần trong các hệ thống mở. Tham khảo ở tài liệu
kè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ừ danh
sá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ềm
yê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ết
các bước trong mô hình qua một ứng dụng GTS (Geographic Translator System)
đã được xây dựng.
18