Đo phần mềm hướng thành phần

Từ tập cỏc độ đo khả năng tớch hợp và khả năng tỏi sử dụng của thành phần đó trỡnh bày trong chương 2 và chương 3, chương này sẽ tập trung vào việc xõy dựng một độ đo thành phần tổng qu

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

MỤC LỤC

LỜI GIỚI THIỆU 8

CHƯƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM HƯỚNG THÀNH PHẦN VÀ ĐỘ ĐO PHẦN MỀM 11

1.1 Thành phần (component) 12

1.1.1 Định nghĩa 12

1.1.2 Kiến trúc của thành phần 13

1.1.3 Những thuộc tính chất lượng của thành phần 14

1.1.4 Thành phần NET 16

1.2 Công nghệ phần mềm hướng thành phần 21

1.2.1 Giới thiệu về công nghệ phần mềm hướng thành phần 21

1.2.2 Quy tŕnh phát triển 22

1.2.3 Ưu điểm của công nghệ phần mềm hướng thành phần 25

1.3 Độ đo phần mềm 26

1.3.1 Định nghĩa độ đo phần mềm 26

1.3.2 Các thuộc tính của độ đo phần mềm 27

1.3.3 Phân loại độ đo phần mềm 28

1.4 Nhiệm vụ của luận văn 31

CHƯƠNG 2: ĐỘ ĐO KHẢ NĂNG TÍCH HỢP CỦA THÀNH PHẦN 34

2.1 Một số nguyên tắc tích hợp hệ thống 35

2.2 Kỹ thuật tích hợp thành phần 37

2.2.1 Adapter 37

2.2.2 Bridge 38

2.2.3 Proxy 39

2.2.4 Mediator 40

2.2.5 Facade 41

2.3 Độ đo khả năng tích hợp của thành phần 43

2.3.1 Tập độ đo khả năng tích hợp của thành phần do V L Narasimhan & B Hendradjaya đề xuất 44

2.3.2 Độ đo CPD (Component Packing Density) 46

2.3.3 Độ đo CID (Component Interaction Density) 48

2.4 Kết chương 52

CHƯƠNG 3: ĐỘ ĐO KHẢ NĂNG TÁI SỬ DỤNG 55

3.1 Những khái niệm cơ bản 55

3.1.1 Khả năng tái sử dụng của thành phần 55

3.1.2 Các phương pháp tái sử dụng 57

3.1.3 Vai tṛ của tái sử dụng trong CBSE 58

3.2 Các hoạt động xảy ra trong quá tŕnh tái sử dụng thành phần 59

3.3 Tập độ đo khả năng tái sử dụng do Hironori Washizaki đề xuất 61

3.4 Định nghĩa tập độ đo khả năng tái sử dụng 63

3.4.1 Độ đo RCO (Rate of Component Observability) 64

3.4.2 Độ đo RCC (Rate of Component Customizability) 66

3.4.3 Độ đo SCCr (Self-Completeness of Component’s Return Value)67 3.4.4 Độ đo SCCp (Self-Completeness of Component’s Parameter) 68

3.4.5 Độ đo khả năng tái sử dụng 69

3.5 Kết chương 70

CHƯƠNG 4: XÂY DỰNG ĐỘ ĐO THÀNH PHẦN TỔNG QUÁT 72

4.1 Xây dựng độ đo thành phần tổng quát 73

4.2 Cài đặt độ đo thành phần tổng quát 74

4.3 Một số h́nh ảnh minh hoạ các chức năng chính của chương tŕnh mô phỏng 77

4.4 So sánh GCM với một số độ đo khác 79

So sánh với độ đo CK mở rộng 79

So sánh với tập độ đo khả năng tái sử dụng của Hironori Washizaki 87

So sánh với tập độ đo khả năng tích hợp của V L Narasimhan & B Hendradjaya 87

4.5 Kết chương 92

KẾT LUẬN 93

TÀI LIỆU THAM KHẢO 95

DANH MỤC CÁC H̀NH VẼ

H́nh 1.1: Mô h́nh tham chiếu kiến trúc thành phần ……… 13

H́nh 1.2: Mô h́nh kết hợp ……… 19

H́nh 1.3: Mô h́nh ngăn chặn ……… 19

H́nh 2.1: Hệ thống tích hợp và các thành phần ……… 37

H́nh 2.2: Mô phỏng Adapter ……… 38

H́nh 2.3: Mô phỏng Bridge ……… 40

H́nh 2.4: Mô phỏng Proxy ……… 40

H́nh 2.5: Tương tác giữa các thành phần không có Mediator ……… 42

H́nh 2.6: Tương tác giữa các thành phần tồn tại Mediator ………… 42

H́nh 2.7: Tương tác giữa các thành phần không có Facade ………… 43

H́nh 2.8: Tương tác giữa các thành phầntồn tại Facade ……… 44

H́nh 2.9: Quy tŕnh tính độ đo khả năng tích hợp của thành phần A trong hệ thống X ……… 53

H́nh 4.1: : Quá tŕnh thực hiện các phép đo ……… 77

CHÚ THÍCH THUẬT NGỮ VÀ TỪ VIẾT TẮT

STT Thuật ngữ - Từ viết tắt Chú thích

nghĩa thông qua các giao diện của chúng Có hai loại giao diện: giao diện cung cấp - định nghĩa các dịch vụ được thành phần cung cấp và giao diện yêu cầu – xác định các dịch vụ mà hệ thống phải hỗ trợ cho thành phần

ngôn ngữ trung gian Các ngôn ngữ chuẩn của NET đều được dịch ra ngôn ngữ này

3 NET Framework Là nền tảng cơ bản của NET và chứa

các thành phần sau: các ngôn ngữ chuẩn của NET, Common Language Runtime – CLR và một số thư viện

Assembly

dụng chạy cục bộ của NET

dụng Web của NET

để đóng gói với các phương thức có cùng dấu hiệu với nó

do Chidamber và Kemerer đề xuất

19 CIDL Component Interface Definition

Language

thành phần

21 Receptacle Là giao diện được thành phần yêu cầu

Component

Component

Return Value

Parameter

32 GCM General Component Metric

LỜI GIỚI THIỆU

Xây dựng hệ thống phần mềm hướng thành phần hiện nay là một phương pháp khá phổ biến và mang lại nhiều kết quả to lớn Hệ thống được xây dựng hoàn chỉnh dựa trên những thành phần có sẵn đă giúp giảm rủi ro, thời gian xây dựng hệ thống và tăng cường độ tin cậy của hệ thống Cách tiếp cận tiên tiến này đă làm thay đổi toàn bộ quy tŕnh sản xuất phần mềm trước đây Bây giờ chúng ta không xây dựng hệ thống từ con số không mà chúng ta sử dụng những thành phần có sẵn Do đó, hiện nay ngày càng có nhiều nhà sản xuất phát triển những thành phần đáp ứng một số chức năng nào đó

Vấn đề đặt ra là cùng với một yêu cầu chức năng nhưng chúng ta có vô

số các thành phần thoả măn, vậy làm thế nào để lựa chọn ra một thành phần đáp ứng đầy đủ các yêu cầu của người sử dụng và mang lại hiệu quả cao nhất Hơn nữa, điểm yếu nhất hiện nay của công nghệ phần mềm hướng thành phần chính là việc thiếu những độ đo chính xác, giúp người sử dụng đánh giá các thành phần một cách hoàn chỉnh Do đó, luận văn này tập trung giải quyết vấn đề trên bằng cách xây dựng một số độ đo thành phần phần mềm

Bố cục của luận văn này gồm có 4 chương như sau:

1 Chương 1: Tổng quan về công nghệ phần mềm hướng thành phần và độ đo phần mềm Trong chương này chúng ta đă xem xét

tổng quan về quy tŕnh phát triển phần mềm hướng thành phần Tiếp

theo là xem xét về độ đo phần mềm

2 Chương 2: Độ đo khả năng tích hợp của thành phần Chương

này tập trung xem xét về khả năng tích hợp của thành phần, các kỹ

thuật tích hợp và xây dựng một tập các độ đo khả năng tích hợp của

thành phần

3 Chương 3: Độ đo khả năng tái sử dụng của thành phần Chương

này nghiờn cứu về khả năng tỏi sử dụng của thành phần và phỏt triển tập độ đo khả năng tỏi sử dụng của thành phần

4 Chương 4: Xõy dựng độ đo thành phần tổng quát Từ tập cỏc độ

đo khả năng tớch hợp và khả năng tỏi sử dụng của thành phần đó trỡnh bày trong chương 2 và chương 3, chương này sẽ tập trung vào việc xõy dựng một độ đo thành phần tổng quỏt nhằm giỳp người sử dụng cú được đánh giỏ chớnh xỏc nhất về một thành phần

Để hoàn thành được luận văn này, tôi xin bày tỏ lũng biết ơn sâu sắc tới tập thể các thầy giáo, cô giáo trường Đại học Bách khoa Hà Nội nói chung

và khoa Công nghệ thông tin nói riêng đó tận tỡnh giảng dạy truyền đạt cho tôi những kiến thức, kinh nghiệm quý báu trong suốt những năm vừa qua Tôi xin chân thành cảm ơn thầy giáo Huỳnh Quyết Thắng, bộ môn Công nghệ phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách khoa Hà Nội đó khuyến khớch, động viên, góp ý và hướng dẫn tôi rất tận tỡnh trong suốt quỏ trỡnh thực hiện luận văn

Và tụi cũng bày tỏ lũng biết ơn đối với tất cả các bạn bè, đồng nghiệp và người thân đó động viên, hỗ trợ để tôi có thể hoàn thành luận văn này Tuy nhiờn, trong quỏ trỡnh làm luận văn, dự đó cố gắng thực hiện nhưng

do kinh nghiệm cũn ớt, thời gian nghiờn cứu hạn chế nên chắc chắn không

tránh khỏi thiếu sót, rất mong được sự giúp đỡ và góp ý của Quý thầy cụ,

và đồng nghiệp để luận văn này có thể phát triển một cách toàn diện hơn

Hà nội, ngày 30 tháng 10 năm 2005

Học viên Phạm Thị Quỳnh

CHƯƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM HƯỚNG THÀNH PHẦN VÀ ĐỘ ĐO PHẦN MỀM

Xây dựng một hệ thống phần mềm lớn là một nhiệm vụ hết sức phức tạp

và khó khăn, chúng ta phải thực hiện mọi hành động một cách chính xác nhất và tốt nhất trong từng pha của quá tŕnh phát triển Một trong những hành động đó là sử dụng lại mă nguồn và đi theo những phương pháp luận xây dựng đă được chấp nhận từ trước nhằm giảm chi phí, thời gian và công sức

Phương pháp tiếp cận hiện đại với khả năng tái sử dụng phần mềm được thực hiện thông qua công nghệ phần mềm hướng thành phần Mặc dù chúng

ta không có một định nghĩa chuẩn IEEE/ISO cho thành phần, nhưng Syzperski đă định nghĩa thành phần như sau [3]: “Thành phần là một đơn vị kết cấu từ nhiều giao diện (interface (*)) đă được xác định một cách rơ ràng

và các phụ thuộc ngữ cảnh cụ thể Thành phần có thể được triển khai một cách độc lập và là một đối tượng để từ đó bên thứ ba có thể xây dựng tiếp” Đồng thời, Syzperski đă chỉ ra rằng các thành phần phải được kết hợp để làm việc với nhau nhằm xây dựng một hệ thống

Khi nhiều hệ thống được xây dựng từ các thành phần độc lập th́ càng có nhiều thành phần được phát triển bởi những nhà sản xuất khác nhau Điều này sẽ dẫn tới việc cần phải có các độ đo để tính hiệu quả của từng thành phần Các độ đo giúp ích rất nhiều cho người quản lư dự án, người xây dựng, người kiểm thử và bất kỳ người nào có liên quan đến quá tŕnh xây dựng phần mềm

(*) Trong luận văn, interface xin được hiểu là các dịch vụ do thành phần cung cấp hoặc yêu cầu hệ thống phải hỗ trợ cho thành phần

Một tập hợp các độ đo được sử dụng để dự đoán chi phí, công sức, thời gian xây dựng và kiểm thử phần mềm Độ đo phần mềm được nghiên cứu để đánh giá chất lượng của quá tŕnh xây dựng phần mềm

Trong chương này, chúng ta bắt đầu với những khái niệm cơ bản như thành phần là ǵ, kiến trúc của một thành phần và t́m hiểu ví dụ cụ thể trên nền NET Sau đó, chúng ta nghiên cứu về công nghệ phần mềm hướng thành phần và quy tŕnh sản xuất một phần mềm hướng thành phần Cuối cùng, chúng ta sẽ tập trung vào các độ đo phần mềm

1.1 Thành phần (component)

1.1.1 Định nghĩa

Mô-đun là một đơn vị của kết cấu phần mềm Nó là một ví dụ sơ khai về thành phần phần mềm Trong cách tiếp cận hướng đối tượng, các lớp cung cấp định dạng cơ bản của mô-đun C̣n thành phần là một kiểu, một lớp, hoặc một sản phẩm được thiết kế, được tư liệu hoá và được đóng gói để tái sử dụng

Một định nghĩa khác lại nhấn mạnh vào kết cấu [3]: Thành phần phần mềm là một đơn vị kết cấu, chứa các giao diện được đặc tả một cách rơ ràng

và có sự phụ thuộc về ngữ cảnh Nó có thể được phát triển một cách độc lập Phát triển phầm mềm hướng thành phần là một phương pháp trong đó hệ thống được xây dựng từ những mảng đă được sản xuất một cách độc lập và được định nghĩa rơ ràng bằng cách kết hợp những mảng này với các thành phần tự làm khác

Ngoài ra, một số định nghĩa khác nêu lên rằng: thành phần là các gói có quan hệ với nhau một cách khái niệm về mặt ứng xử của chúng, trong khi

một số thành phần khác là các đơn vị vật lý, có khả năng triển khai trong một môi trường đă được định nghĩa rơ ràng

1.1.2 Kiến trỳc của thành phần

Khả năng tái sử dụng hoặc tích hợp các thành phần sẽ không thể đạt được nếu như không có một kiến trúc chuẩn Hiện nay, có một số kiến trúc đang được sử dụng rộng răi như: ActiveX, CORBA, JavaBeans …

H́nh 1.1: Mô h́nh tham chiếu kiến trúc thành phần

H́nh 1.1 biểu diễn mô h́nh tham chiếu của kiến trúc thành phần [1] Các thành phần chính của mô h́nh này bao gồm: Framework, thành phần, ràng buộc giữa các thành phần, các dịch vụ, mă lệnh kết nối

• Framework: cung cấp một tập các dịch vụ nhằm hỗ trợ và đảm bảo

mô h́nh thành phần Mô h́nh thành phần là một tập hợp các kiểu thành phần, các giao diện của nó và một bản đặc tả các mẫu (pattern) hỗ trợ tương tác giữa các kiểu thành phần

• Thành phần: Một thành phần là một cấu trúc phần mềm có thể được thực hiện trên một thiết bị vật lư hoặc logic Một thành phần

có thể cài đặt một hoặc nhiều giao diện Tất cả các thành phần đều phải thoả măn ràng buộc của nó

• Ràng buộc của thành phần (Component Contract): là một thoả thuận nhằm đảm bảo những thành phần độc lập phải tuân thủ các nguyên tắc nào đó V́ vậy, các thành phần sẽ tương tác với nhau theo những cách đă dự báo trước, và có thể được triển khai trên môi trường xây dựng sẵn hoặc môi trường thực thi tiêu chuẩn

• Các dịch vụ (Coordination Service): Component Framework cung cấp một số dịch vụ như: dịch vụ giao tác và dịch vụ đảm bảo tính thống nhất

• Mă lệnh kết nối (Glue Code): là mă lệnh nhằm liên kết các thành phần được xây dựng độc lập dựa trên những cam kết để các thành phần có thể tương tác được với nhau Có rất ít trường hợp những thành phần đă tồn tại có thể kết nối trực tiếp với nhau một cách tự động V́ vậy, những ứng dụng được xây dựng dựa trên việc tái sử dụng các thành phần phải có mă lệnh kết nối

1.1.3 Những thuộc tính chất lượng của thành phần

Để đánh giá một thành phần, ta phải xác định cách đánh giá chất lượng của thành phần đó Các thuộc tính chất lượng của thành phần là nền tảng cơ

bản để đảm bảo chất lượng của chúng; và do đó, nó sẽ đảm bảo chất lượng của toàn bộ hệ thống được xây dựng dựa trên các thành phần Sau đây là một

số thuộc tính chất lượng của thành phần:

• Chức năng - thuộc tính này liên quan tới những vấn đề sau:

- Mức độ cài đặt các yêu cầu của thành phần

- Chứa tất cả các tham chiếu và các yếu tố cần thiết

- Mức độ chịu lỗi trong các bản đặc tả, bản thiết kế và cài đặt của thành phần

• Giao diện - được đánh giá dựa trên:

- Mức độ hoàn thiện của đầu vào và đầu ra của thành phần

- Độ linh hoạt của giao diện khi thay đổi một số tham số

• Tư liệu hoá

- Chứa tất cả các tài liệu cần thiết

• Độ tin cậy

- Khả năng chịu lỗi (Ví dụ: thành phần có thể giải quyết được trong các trường hợp dữ liệu vào sai)

1.1.4 Thành phần NET

1.1.4.1 Mô h́nh thành phần của NET

Công nghệ hướng thành phần của NET đă mở rộng và đơn giản hoá các công nghệ trước đây như COM, DCOM, COM+ Thành phần MSIL DLL đă thay thế thành phần COM, thành phần MSIL Remoting Chanels EXE thay thế DCOM, và Web Service thay thế những thành phần SOAP mới nhằm hướng tới những thành phần Web độc lập nền, độc lập ngôn ngữ

Công nghệ thành phần của NET là hướng đối tượng thống nhất Bất kỳ thành phần NET nào đều ở dạng MSIL tiền biên dịch, chúng có thể được sử dụng ở những thành phần MSIL khác và những client tương thích

Bản thân NET Framework cũng được xây dựng từ mô h́nh thành phần Các namespace nằm trong các file dll File dll là một thành phần đă được triển khai của NET (c̣n gọi là Assembly) Namespace chỉ là các gói logic dùng để sắp xếp các lớp có quan hệ với nhau Assembly có thể có nhiều namespace và một namespace được mở rộng trên nhiều file assembly

Thành phần NET là một mô-đun MSIL được biên dịch trước và tự mô tả

Nó được xây dựng từ một hoặc nhiều lớp hoặc mô-đun được triển khai trong một file dll Một assembly gồm 4 thành phần sau:

• Manifest: Bảng chứa các thông tin tổng quát: tên của assembly, giá trị khoá của phiên bản, tên đầy đủ, các file tạo nên assembly, các assembly được tham chiếu

• Siêu thông tin (Metadata): thông tin của các module

• Mă nguồn IL của các module

• Tài nguyên đi kèm: file ảnh, …

Một mô-đun có mă nguồn MSIL và siêu thông tin của nó, nhưng không

có manifest Mô-đun không được tải tự động Mô-đun thường được sử dụng như một khối xây dựng sẵn vào thời điểm dịch chương tŕnh để tạo nên một file assembly Mô-đun có đuôi là netmodule Trong một mô-đun có thể có một hoặc nhiều lớp Mỗi mô-đun được viết bằng nhiều ngôn ngữ khác nhau, nhưng cuối cùng đều ở cùng một định dạng là MSIL Assembly có file manifest để tự mô tả về thành phần của nó Assemply có đuôi mở rộng là dll hoặc exe và được tải tự động Đó là lư do tại sao nhiều người gọi thành phần NET là assembly hoặc thành phần được triển khai trong assembly File dll không phải là file chạy, nó tương tự như file class

Trong NET Framework có rất nhiều kiểu thành phần Ta có thể phân chúng thành hai loại: thành phần trực quan và thành phần không trực quan Thành phần trực quan là những thành phần được triển khai trên ToolBox và được coi như một biểu tượng để kéo thả Ta chỉ tập trung vào thành phần không trực quan và gọi tắt đó là thành phần NET

Một thành phần NET có thể được cài đặt ở phía client, server hoặc middleware Thành phần NET luôn cung cấp một số dịch vụ cho các client của nó (client có thể là một thành phần khác hoặc một ứng dụng client)

Thành phần NET có thể là thành phần cục bộ (.dll) - được truy nhập một cách cục bộ trong cùng một miền ứng dụng trên cùng một máy; hoặc có thể

là thành phần từ xa (.exe) - được truy nhập từ xa thông qua miền ứng dụng trên cùng một máy hoặc trên các máy khác nhau Một miền ứng dụng là một tiến tŕnh không quan trọng - tức là nó có thể được bắt đầu hoặc kết thúc một cách độc lập trong tiến tŕnh Một thành phần không thể truy nhập trực tiếp tới một thành phần khác trong một miền ứng dụng hoặc tiến tŕnh khác v́ mỗi miền ứng dụng phải có không gian nhớ riêng của nó

Thành phần NET DLL có thể được triển khai như một thành phần private, tức là thành phần đó phải biết client của nó; hoặc có thể được triển khai như một thành phần public - tức là thành phần đó không cần biết client của nó Thành phần DLL có thể được sử dụng ngay trong Window Form, Web Form của một DLL hoặc một ứng dụng khác

Client của một thành phần tạo ra một tham chiếu tới thành phần đó vào lúc dịch chương tŕnh; sau đó, client tải thành phần một cách tự động vào miền ứng dụng của nó vào lúc thực thi khi có yêu cầu

1.1.4.2 Mô h́nh kết nối các thành phần NET

Cấu trúc của thành phần NET

Có hai mô h́nh cấu trúc thành phần NET, đó là: mô h́nh kết hợp và mô h́nh ngăn chặn Trong mô h́nh kết hợp, thành phần bên trong xử lư trực tiếp với client của thành phần bên ngoài khi có một yêu cầu về dịch vụ của nó Tức là thành phần bên ngoài nêu rơ các giao diện của thành phần bên trong

Inner Outer

innerM()

outerM1()

H́nh 1.2: Mô h́nh kết hợp

Trong mô h́nh ngăn chặn, nếu có một yêu cầu tới thành phần bên ngoài

mà cần sự giúp đỡ của thành phần bên trong th́ yêu cầu đó sẽ được đưa tới thành phần bên trong Thành phần bên ngoài không nêu rơ giao diện của thành phần bên trong Mô h́nh ngăn chặn là trong suốt đối với client của thành phần bên ngoài Client không biết rơ thành phần nào sẽ thực thi yêu cầu của ḿnh

Inner Outer

innerM() outerM2()

H́nh 1.3: Mô h́nh ngăn chặn

Thành phần NET có thể được tạo thành bằng cách kết hợp cả hai mô h́nh trên trong một cấu trúc phẳng hoặc cấu trúc lồng nhau theo nhiều mức

Giao tiếp giữa các thành phần

.NET Delegate là một kiểu phương thức (tham chiếu tới một phương thức) tương tự như con trỏ hàm trong C++, nhưng nó an toàn và bảo mật hơn Delegate sẽ chuyển một điều khiển luồng tới nơi giữ sự kiện đă được đăng kư của nó mỗi khi sự kiện xảy ra

Một thể hiện của Delegate có thể giữ một phương thức tĩnh của lớp, một phương thức của thành phần hoặc một phương thức của chính nó Có hai loại Delegate: SingleCast và MultiCast

SingleCast Delegate chỉ có thể chuyển một phương thức tại một thời điểm MultiCast Delegate có kiểu trả về là void và có thể được gán với nhiều phương thức; nó sẽ viện dẫn tới các phương thức này theo thứ tự đă đăng kư Delegate đóng vai tṛ là một tai nghe, bộ giữ sự kiện (event handler) phải đăng kư với Delegate th́ mới có thể giữ được sự kiện khi nó xảy ra

Sự kiện là một thông điệp được gửi từ một đối tượng để viện dẫn tới một hành động nào đó Đối tượng gây ra sự kiện gọi là event source; đối tượng chặn và lưu sự kiện gọi là event target

Đây là mô h́nh giao tiếp hướng sự kiện giữa các thành phần hoặc trong một thành phần Lớp Delegate là lớp kênh giao tiếp giữa event source và event target Sự kiện có thể được định nghĩa trước hoặc do người lập tŕnh định nghĩa Sau đây là cách tạo và sử dụng delegate event:

- Tạo ra lớp Delegate

- Tạo ra lớp chứa trường Delegate

- Định nghĩa bộ giữ sự kiện

- Gán delegate event với event handler thông qua bộ nghe sự kiện, bộ kích hoạt sự kiện, viện dẫn tới event handler

Bộ kết nối từ xa cho các thành phần phân tán của NET

Thành phần hoặc client không thể truy nhập một cách trực tiếp tới một thành phần từ xa chạy trên một miền ứng dụng khác trên cùng một tiến tŕnh hoặc khác tiến tŕnh, trừ khi nó sử dụng kênh kết nối Remoting

Có hai cách để viện dẫn một đối tượng: trong MBV (Marshal By Value), server gửi bản sao của đối tượng tới client và trong MBR (Marshal By

Reference), client tạo ra một proxy của đối tượng từ xa Khi thành phần từ

xa chạy trên một máy khác th́ chỉ sử dụng được MBR

Kênh là một cách để cài đặt giao tiếp giữa client và các thành phần từ xa Tiến tŕnh phải được gắn với một cổng Kênh client gắn với một cổng trên client và kênh server gắn với một cổng trên server

Trả lời không đồng bộ được xây dựng dựa trên Remoting Delegate Client sẽ không bị khoá khi đang đợi trả lời từ phía các thành phần từ xa Khi client tạo ra một lời gọi không đồng bộ tới một phương thức từ xa th́ nó

sẽ gửi cho server một phương thức callback để được gọi lại sau thông qua Remoting Delegate

1.2 Công nghệ phần mềm hướng thành phần

Phần này tŕnh bày tổng quan về quy tŕnh phát triển phần mềm hướng thành phần, và một số hoạt động diễn ra trong quá tŕnh xây dựng phần mềm hướng thành phần

1.2.1 Giới thiệu về cụng nghệ phần mềm hướng thành phần

Công nghệ phần mềm hướng thành phần (Component-based software engineering - CBSE) hay quy tŕnh phát triển phần mềm hướng thành phần (Component-based software development - CBSD) đề cập tới quá tŕnh xây dựng phần mềm bằng cách kết hợp các thành phần đă tồn tại Đằng sau quy tŕnh này là khái niệm về các thành phần được xây dựng nhằm cung cấp những chức năng chung cho nhiều hệ thống khác nhau Lấy ư tưởng từ các thành phần phần cứng, mục đích của CBSE là cho phép các thành phần của

hệ thống phần mềm có thể được thay thế bằng những thành phần mới hơn,

có chức năng tương tự

Đây không phải là một ư tưởng mới Năm 1969, Mcllorys đă đề xuất ư tưởng về việc xây dựng phần mềm bằng cách lắp ghép các thành phần với nhau Nhưng những năm gần đây, cùng với sự phát triển mạnh mẽ của các thành phần thương mại có sẵn (Commercial Off-The-Shelf - COTS), công nghệ phần mềm hướng thành phần mới được phát triển một cách mạnh mẽ CBSE giúp giảm chi phí xây dựng phần mềm, hệ thống phần mềm được xây dựng dựa trên các thành phần khá linh hoạt và dễ bảo tŕ v́ ta chỉ cần tích hợp các thành phần có sẵn vào trong hệ thống

- Thẩm định thành phần

- Điều chỉnh thành phần

- Kết hợp các thành phần

- Phát triển và bảo tŕ hệ thống Mặc dù quy tŕnh xây dựng hệ thống hướng thành phần khác so với quy tŕnh xây dựng hệ thống truyền thống, những cả hai quy tŕnh này đều có những vấn đề chung; ví dụ, vấn đề trong thay đổi quản lư và bảo tŕ phần mềm Trong phần tiếp theo chúng ta sẽ nghiên cứu chi tiết về từng hoạt động trong quy tŕnh phát triển phần mềm hướng thành phần

1.2.2.1 Thẩm định

Thẩm định là quy tŕnh xác định khả năng phù hợp của một thành phần đối với những yêu cầu đặt ra và các thành phần khác đă tồn tại trong hệ thống cần xây dựng Khi những thành phần phần mềm được xây dựng có sẵn mang tính cạnh tranh cao th́ việc thẩm định c̣n bao gồm cả hoạt động lựa chọn những thành phần nào thích hợp nhất Thẩm định một thành phần bao gồm cả việc đánh giá quy tŕnh phát triển được sử dụng để xây dựng và bảo tŕ thành phần Đây là điều cần thiết, nhất là đối với các ứng dụng yêu cầu độ tin cậy cao, nhưng điều này cũng làm giảm sức hấp dẫn đối với việc sử dụng những thành phần đă tồn tại

Quá tŕnh thẩm định thành phần gồm hai pha: phát hiện và đánh giá Trong pha phát hiện, các đặc điểm của thành phần phải được xác định Những đặc điểm này bao gồm: chức năng (những dịch vụ nào sẽ được cung cấp) và các khía cạnh về giao diện của thành phần (thành phần sử dụng chuẩn nào) Các đặc điểm của thành phần cũng bao gồm cả những vấn đề về mặt chất lượng như: độ tin cậy, khả năng sử dụng, khả năng ước lượng Trong một số trường hợp, c̣n xét đến những đặc điểm phi kỹ thuật như: nhà sản xuất, hiệu năng sử dụng thành phần ở những hệ thống trước đây Phát hiện là một quá tŕnh khó và không rơ ràng, do khó định lượng và lưu trữ rất nhiều thông tin cần thiết

Hiện nay có một số kỹ thuật đánh giá khá chính xác cho phép lựa chọn một thành phần từ rất nhiều các thành phần có sẵn Ví dụ, ISO 91 đề xuất tiêu chuẩn đánh giá phần mềm Các phương pháp đánh giá thành phần thường kết hợp việc nghiên cứu về mặt tư liệu của thành phần, thảo luận với những người đă sử dụng thành phần đó và thực hiện các mẫu thử

Một xu hướng hiện nay là dựa trên phương pháp “dây truyền sản xuất” Phương pháp này sử dụng tập các thành phần có khả năng tái sử dụng mà đă tồn tại trong hàng loạt các sản phẩm phần mềm đă xây dựng Giả sử rằng các

hệ thống giống nhau sẽ có kiến trúc và những chức năng chính tương tự nhau V́ vậy, những chức năng chung có thể được cung cấp bởi cùng một tập các thành phần, do đó làm cho quy tŕnh phát triển và bảo tŕ phần mềm trở nên dễ dàng hơn

1.2.2.2 Điều chỉnh

Những thành phần riêng lẻ được xây dựng để giải quyết các yêu cầu khác nhau, mỗi thành phần được xây dựng dựa trên giả thiết về ngữ cảnh mà sau này nó sẽ được triển khai Mục đích của việc điều chỉnh là để đảm bảo sự xung đột giữa các thành phần là tối thiểu Có nhiều phương pháp điều chỉnh thành phần, nhưng những phương pháp này thường dựa trên việc đánh giá cấu trúc bên trong của thành phần

Thành phần được chia thành 3 loại

• Thành phần hộp trắng: có thể được xây dựng lại để cùng hoạt động với các thành phần khác

• Thành phần hộp xám: cung cấp ngôn ngữ mở rộng của nó hoặc các API (application programming interface)

• Thành phần hộp đen: không có ngôn ngữ mở rộng và API Một thành phần thường là hộp đen, tức là nó chỉ cung cấp các phương pháp truy nhập tới nó thông qua các giao diện đă được định nghĩa rất rơ ràng

Mỗi phương pháp điều chỉnh có ưu điểm và nhược điểm riêng Tuy nhiên, với những thành phần hộp trắng có thể cho kết quả đánh giá và bảo tŕ chính xác hơn, v́ ta có thể thay đổi được mă nguồn của nó C̣n để điều chỉnh các thành phần hộp xám và hộp đen, chúng ta phải sử dụng những kỹ thuật đặc biệt như wrap, bridge và mediate

1.2.2.3 Kết hợp

Kết hợp là quá tŕnh tích hợp các thành phần dựa trên một số những nền chuẩn đă được định nghĩa Thông thường, các thành phần thường được định nghĩa dựa trên một số công nghệ như NET, DCOM, CORBA, Enterprise JavaBeans …Do đó, những nền chuẩn này cung cấp cách kết hợp các thành phần được xây dựng dựa trên các công nghệ khác nhau, thành một hệ thống hoàn thiện

1.2.2.4 Phát triển và bảo tŕ hệ thống

V́ các thành phần là những đơn vị độc lập và có thể bị thay thế, cho nên quá tŕnh xây dựng hệ thống dựa trên việc thay thế các thành phần cũ bằng thành phần khác mới hơn Tuy nhiên, trong thực tế, việc thay thế một thành phần này bằng thành phần khác không phải là một nhiệm vụ dễ dàng, đặc biệt là khi có nhiều điều không tương xứng giữa thành phần mới và thành phần cũ Điều đó dẫn tới việc phải quay lại pha điều chỉnh thành phần mới

1.2.3 Ưu điểm của công nghệ phần mềm hướng thành phần

Mục tiêu của quá tŕnh xây dựng hướng thành phần là tận dụng những giải pháp tốt nhất để tăng hiệu năng sản xuất Phát triển hướng thành phần quản

lư độ phức tạp, cải thiện tính nhất quán, hạn chế các rủi ro, hỗ trợ việc phát triển song song và phân tán Tăng hiệu năng sản xuất sẽ làm giảm thời gian

sản xuất, thời gian đưa ra thị trường và chi phí bảo tŕ Việc sử dụng các thành phần làm tăng khả năng giám sát và tính trực quan của dự án

Ngày nay, các ứng dụng phần mềm ngày càng trở nên phức tạp và lỗi phần mềm thường rất nghiêm trọng, điều đó có thể dẫn tới những vấn đề không thể giải quyết được và gây hậu quả nghiêm trọng Do đó, cần thiết phải có các độ đo sản phẩm phần mềm một cách hiệu quả

Độ đo phần mềm thường được sử dụng cho các mục đích sau: [8]

• Ước lượng chi phí và kế hoạch thực hiện của những dự án tương lai

• Ước lượng ảnh hưởng của các công cụ và công nghệ mới

• Ước lượng xu hướng phát triển của sản phẩm theo thời gian

• Cải thiện chất lượng phần mềm

• Dự báo những nguồn tài nguyên cần thiết

• Trong tương lai, độ đo phần mềm có thể rất có ích trong việc xây dựng các chuẩn thiết kế của một tổ chức

1.3.2 Các thuộc tính của độ đo phần mềm

Để độ đo trở nên hữu ích, độ đo phải hợp lệ, đáng tin cậy, chính xác và

có thể thực hiện được Độ đo hợp lệ nếu nó mô tả chính thuộc tính cần đo

Độ đo đáng tin cậy nếu kết quả gần đúng với kết quả thật Độ đo có thể thực hiện được nếu nó dễ sử dụng và yêu cầu chi phí thấp đối với một dự án thực

tế Độ đo có thể thực hiện được không yêu cầu chi phí đo quá lớn hoặc dữ liệu đo khó có thể đạt được tại thời điểm đo

Sự khác biệt giữa vấn đề chủ quan và khách quan là hết sức quan trọng

Độ đo khách quan không phụ thuộc vào người đo và kết quả đo là như nhau Các độ đo như ḍng lệnh, đo độ phức tạp cổ điển, độ đo hướng đối tượng và đếm số lượng các thành phần có thể được đo một cách khách quan sau khi cài đặt; nhưng có nhiều độ đo quan trọng khác như kỹ năng và động lực của đội dự án lại phụ thuộc vào sự đánh giá của người ước lượng

Thông thường các thuộc tính không được đo một cách trực tiếp Thay v́ thế, một số phép đo khác được thực hiện và độ đo cuối cùng được tính ra từ các phép đo trung gian này Trong trườg hợp này, tính hợp lệ của phép suy diễn phải được đảm bảo hợp lệ

Khi bản chất của phần mềm không thể đo được th́ các kết quả của quy tŕnh phát triển phải được đo Nếu quá tŕnh tính toán không rơ ràng th́ kết quả thu được sẽ không đáng tin cậy

Chúng ta có thể sử dụng nhiều đơn vị đo chính xác nhưng có một số hiện tượng sẽ giới hạn độ chính xác Ví dụ, chiều dài của thanh sắt sẽ bị thay đổi

khi nhiệt độ thay đổi Do đó, không thể tạo ra các độ đo quá chính xác v́ sự biến đổi ngẫu nhiên có thể lớn hơn độ chính xác mong đợi của các độ đo

Để thực hiện được ta nên lựa chọn dữ liệu một cách tự động Nếu dữ liệu không được lưu trữ trong máy tính th́ dữ liệu dùng để đo sẽ được thu thập trong khi thực hiện Dữ liệu cần thiết nên được chuẩn bị sẵn sàng tại trước mỗi pha của quá tŕnh phát triển khi những quyết định quan trọng được đưa

ra Một phương pháp mà yêu cầu số lượng tham số lớn cũng sẽ yêu cầu một lượng lớn những chi phí không cần thiết để thực hiện việc ước lượng

Ước lượng phép đo dựa trên thống kê được thu thập từ các dự án trước và được lưu trữ trong kho dữ liệu Giả thiết rằng các đặc tính của dự án có thể ước lượng được Vấn đề là dự án mới th́ không hoàn toàn giống với dự án

cũ Các công cụ hoặc phương thức mới có thể được sử dụng hoặc ít nhất những thành viên trong đội dự án được học cách để thực hiện công việc tốt hơn Hơn nữa phương pháp thống kế không giống nhau cũng có thể gây ra

sự sai khác giữa các dự án

1.3.3 Phân loại độ đo phần mềm

Cùng với sự phát triển của công nghệ phần mềm, rất nhiều độ đo đă được

đề xuất Sau đây là một số loại độ đo phần mềm: [8]

• Độ đo mă nguồn: Độ đo này dựa trên phần cài đặt chi tiết và được tính toán từ việc phân tích mă nguồn Độ đo này chỉ được thực hiện khi đă hoàn thành xong pha lập tŕnh Độ đo LOC (Line of Code) là một ví dụ điển h́nh cho loại độ đo mă nguồn

• Độ đo cấu trúc: Độ đo cấu trúc dựa trên thiết kế hệ thống và có thể được đo trước khi hoàn thành xong mă lệnh

• Độ đo lai ghép: Đây là độ đo kết hợp giữa độ đo mă nguồn và độ

đo cấu trúc Ví dụ, luồng thông tin được đánh trọng số dựa trên cấu trúc của ḍng mă lệnh SLOC (Structure of Line of Code)

• Độ đo thực thi: Độ đo này được tính toán trong lúc thực thi chương tŕnh

• Độ đo hướng đối tượng: Là những độ đo dành cho ngôn ngữ lập tŕnh hướng đối tượng C&K là một độ đo điển h́nh của loại này [4]

• Độ đo hướng thành phần: Được sử dụng để đo lường các đặc tính của thành phần, như: khả năng tái sử dụng, độ phức tạp, độ tin cậy, khả năng tương … của một thành phần

Tuy nhiên, độ đo phần mềm c̣n có thể được phân loại thành độ đo toàn bộ sản phẩm phần mềm và độ đo quy tŕnh xây dựng phần mềm Nếu phân loại theo cách thức đo th́ ta có phép đo bên trong và bên ngoài

1.3.3.1 Độ đo sản phẩm và độ đo quy tŕnh

Độ đo được chia thành hai loại Độ đo sản phẩm đo các sản phẩm có liên quan đến dự án Độ đo quy tŕnh đo các đặc trưng của quy tŕnh xây dựng Cả hai độ đo này đều cần thiết trong quá tŕnh xây dựng sản phẩm và thực hiện quy tŕnh, và tạo nên các ước lượng chi phí tốt Hướng tiếp cận các độ đo sản phẩm tập trung vào sản phẩm được tạo ra, chứ không phải cách tạo ra sản phẩm Các đặc tính của sản phẩm được phân tích từ mă nguồn, từ tài liệu, khung nh́n bên ngoài của người sử dụng của sản phẩm và từ lợi ích của doanh nghiệp

Số lượng mă nguồn lớn không chỉ ra hiệu quả sản xuất lớn Đặc biệt là trong quy tŕnh phát triển hướng thành phần mà việc tái sử dụng là vấn đề

chính Một sản phẩm có ít mă nguồn có thể tạo ra nhiều chức năng với chi phí thấp hơn là một sản phẩm với số lượng mă nguồn lớn Điều quan trọng

là chúng ta phải quan sát sản phẩm từ khung nh́n của người sử dụng Đối với người sử dụng, giá trị của hệ thống không phải là kích thước và độ phức tạp của hệ thống Việc sử dụng một hệ thống có ít chức năng, nhưng đó là những chức năng quan trọng c̣n tốt hơn việc sử dụng một hệ thống có nhiều chức năng không quan trọng

Độ đo sản phẩm cũng là độ đo chất lượng Chúng có thể được sử dụng để phân tích khả năng bảo tŕ, tính mềm dẻo, khả năng sử dụng và độ chính xác Các thuộc tính này có mối quan hệ mật thiết với nhau

Độ đo quy tŕnh đo các thuộc tính trong quá tŕnh phát triển Một mô h́nh quy tŕnh định nghĩa một tập các hành động xảy ra trong một khoảng thời gian Các thuộc tính của độ đo quy tŕnh là số lượng và khoảng thời gian xảy

ra các hành động này Thời gian cần để phân tích và số lượng các lỗi được t́m thấy trong hệ thống là những ví dụ về các thuộc tính cần đo Các tham số như: tŕnh độ nhân viên, hàm thời gian có thể được sử dụng trực tiếp trong các mô h́nh ước lượng để dự đoán các thuộc tính khác

Việc nâng cấp một quy tŕnh thường liên hệ tới các quy tŕnh khác và rất khó để tạo ra các môi trương thí nghiệm để đo từng tác nhân của quy tŕnh Trong hầu hết các trường hợp độ đo quy tŕnh có quan hệ với độ đo sản phẩm

1.3.3.2 Phép đo bên trong và bên ngoài

Điều quan trọng là phải phân biệt được các phép đo dùng để đo những thuộc tính bên trong của sản phẩm hay thuộc tính bên ngoài của sản phẩm Các thuộc tính trước được gọi là phép đo bên ngoài và các thuộc tính sau

được gọi là phép đo bên trong Ví dụ, các thuộc tính trước là số lượng cửa sổ trong giao diện của người sử dụng và số lượng các ca sử dụng trong hệ thống Các thuộc tính sau như số lượng các lớp, số lượng trung b́nh các phương thức trên một lớp và số lượng trung b́nh các ḍng lệnh trong một phương thức

Henderson – Sellers [3] liệt kê các độ đo kích thước chương tŕnh, cấu trúc dữ liệu, độ phức tạp của luồng điều khiển, sự gán kết giữa các mô-đun

là các ví dụ về các nhân tố bên trong Độ phức tạp, khả năng hiểu, khả năng thay đổi, khả năng kiểm thử và khả năng bảo tŕ là các nhân tố bên ngoài Ngày nay, thao tác giữa các thành phần là vô cũng quan trọng khi phần mềm được xây dựng bằng cách kết hợp nhiều thành phần Ưu điểm của các nhân

tố bên trong là chúng có thể được tính một cách khách quan và được so sánh với các nhân tố bên ngoài Các nhân tố bên trong hữu ích khi ước lượng hoặc dự đoán các giá trị bên ngoài nếu quan hệ giữa các nhân tố bên trong

và bên ngoài đă được định nghĩa

Độ phức tạp biểu thị cho mức độ suy nghĩ để lĩnh hội một điều ǵ đó Độ phức tạp cấu trúc đo cấu trúc của phần mềm, ví dụ, cấu trúc luồng điều khiển, cấu trúc phân cấp … Phạm vi thừa kế và độ phức tạp của một vấn đề được giải quyết là một phần của độ phức tạp có thể được xác định mà không cần giao nhiệm vụ cho đội dự án

1.4 Nhiệm vụ của luận văn

Việc cần thiết phải lựa chọn một thành phần trong một tập hợp các thành phần có chức năng tương tự nhau, đă đặt ra một yêu cầu phải t́m ra những phương thức thích hợp để giúp người xây dựng phần mềm giải quyết nhiệm

vụ khó khăn này Một bước quan trọng là định nghĩa một tập các độ đo cho

kết quả đơn giản và hữu ích đối với quá tŕnh lựa chọn thành phần thích hợp Sau đây chúng ta sẽ tŕnh bày một số độ đo thành phần phần mềm - chủ yếu tập trung vào thuộc tính chất lượng, thuộc tính có thể sử dụng được

Thập nguyên trước đă đánh dấu sự phát triển của quy tŕnh xây dựng phần mềm dựa trên thành phần có sẵn (CBSD) Ư tưởng là xây dựng từng thành phần có chất lượng cao và kết hợp chúng lại thành một khối thoả măn một chức năng nào đó của hệ thống Một trong những quy tŕnh khó khăn nhất trong CBSD là lựa chọn một thành phần có sẵn, thích hợp nhất, đáp ứng mọi yêu cầu của kiến trúc hệ thống và người sử dụng

Chính v́ những lư do trên mà nhiệm vụ của luận văn này là xây dựng một tập hợp các độ đo nhằm đánh giá thành phần một cách chính xác nhất Tuy nhiên, để đánh giá một thành phần th́ có rất nhiều khía cạnh; điều đó có nghĩa là chất lượng của một thành phần phụ thuộc vào rất nhiều yếu tố như:

độ tin cậy, khả năng tái sử dụng, độ phức tạp, khả năng sử dụng được, khả năng tích hợp …

Hiện nay, đă có một số phép đo được sử dụng khá phổ biến như phép đo

CK mở rộng [4], tập độ đo khả năng tái sử dụng [1] [3], bộ đo khả năng tích hợp [2], tập độ đo khả năng có thể sử dụng được [5] của một thành phần … Tuy nhiên, những phép đo này chỉ đánh giá thành phần theo một khía cạnh nhất định mà không thể đánh giá được thành phần một cách tổng quát

Từ những nghiên cứu về thành phần, quy tŕnh xây dựng phần mềm hướng thành phần và dựa trên một số phép đo đă được đề xuất, người làm luận văn đă đề xuất nghiên cứu xây dựng hai tập độ đo liên quan đến khả năng tích hợp và khả năng tái sử dụng của thành phần Bởi v́ đây chính là hai thuộc tính quan trọng nhất của một thành phần và nó có ảnh hưởng hoặc bao hàm cả các thuộc tính khác

Một thành phần có khả năng tích hợp cao có nghĩa là việc đưa nó vào một hệ thống mới phải dễ dàng nhưng vẫn đảm bảo hệ thống chạy ổn định

Từ đó cho thấy một thành phần có khả năng tích hợp cao th́ phải có độ phức tạp nhỏ và độ tin cậy lớn Hơn nữa, trong quá tŕnh xây dựng hệ thống hướng thành phần th́ nhiệm vụ tích hợp các thành phần được xây dựng độc lập thành một hệ thống hoàn chỉnh là một trong những nhiệm vụ cơ bản và quan trọng nhất

Ngoài ra, phương pháp xây dựng phần mềm hướng đối tượng c̣n hướng tới mục tiêu giảm chi phí, giảm rủi ro, giảm thời gian sản xuất phần mềm; đồng thời, tăng độ tin cậy Do đó, khả năng tái sử dụng của một thành phần càng cao th́ các mục tiêu này sẽ đạt được dễ dàng hơn

Trong các chương tiếp theo sẽ tŕnh bày về việc xây dựng hai tập độ đo thành phần: tập độ đo khả năng tích hợp và tập độ đo khả năng tái sử dụng

Từ hai tập độ đo này chúng ta sẽ xây dựng độ đo thành phần tổng quát Và cuối cùng là xây dựng một chương tŕnh thực hiện đo thành phần theo tập các phép đo đă đề xuất

Trên cơ sở các nghiên cứu lư thuyết và thực nghiệm trên phần mềm, người viết luận văn thấy rằng tập các độ đo khả năng tích hợp và độ đo khả năng tái sử dụng của thành phần được đề xuất trong luận văn có thể được áp dụng cho bất kỳ thành phần nào Tuy nhiên, trong phạm vi luận văn th́ chỉ xây dựng chương tŕnh demo cho thành phần NET Ngoài ra, luận văn đă cố gắng đề xuất một độ đo thành phần tổng quát dựa trên hai tập độ đo khả năng tích hợp và khả năng tái sử dụng Giá trị của độ đo thành phần tổng quát có thể mang lại một đánh giá tổng quát nhất và tương đối chính xác về thành phần được đo

CHƯƠNG 2: ĐỘ ĐO KHẢ NĂNG TÍCH HỢP CỦA

THÀNH PHẦN

Vấn đề chính mà chúng ta cần giải quyết trong quá tŕnh xây dựng hệ thống phần mềm hướng thành phần là lựa chọn ra những thành phần thích hợp nhất trong số những thành phần sẵn có, thoả măn yêu cầu đặt ra Tuy nhiên, chúng ta cần phải có những tiêu chí để xác định thế nào là thích hợp nhất

Chúng ta thấy rằng quá tŕnh kết hợp, tích hợp và viết từng thành phần thành một ứng dụng hoàn thiện yêu cầu việc phân tích, thiết kế, kiểm thử và bảo tŕ toàn bộ muộn hơn Và thật không may là nhược điểm chính của phương pháp CBSE là thiếu những độ đo thích hợp để ước lượng khả năng thành công của việc xây dựng phần mềm

Ngoài ra, trong CBSE những vấn đề có liên quan tới việc tích hợp thành phần đóng vai tṛ vô cùng quan trọng, tích hợp các thành phần nhằm hướng tới việc xây dựng một hệ thống thực sự

Do đó, trong phần này chúng ta đưa ra một tập độ đo được sử dụng để ước lượng một cách hiệu quả toàn bộ quá tŕnh tích hợp trong pha đặc tả và thiết kế V́ vậy, người xây dựng phần mềm không phải đợi đến pha cài đặt mới nhận được ước lượng này

Khó khăn chính mà chúng ta gặp phải khi xây dựng các độ đo này là: những thành phần mà chúng ta đo chủ yếu là những thành phần hộp đen, có nghĩa là chúng ta chỉ thấy được các giao diện, mà không thấy được cài đặt bên trong của nó Trong phạm vi của luận văn này sẽ xây dựng tập hợp các

độ đo khả năng tích hợp của các thành phần NET

Chúng ta bắt đầu chương này với việc đưa ra một số nguyên tắc tích hợp

hệ thống Sau đó, tŕnh bày về các kỹ thuật thường được sử dụng để tích hợp thành phần Cuối cùng, sẽ xây dựng và mô phỏng một tập hợp độ đo về khả năng tích hợp của thành phần

2.1 Một số nguyờn tắc tớch hợp hệ thống

Tích hợp hệ thống trong phát triển phần mềm hướng thành phần là quá tŕnh lựa chọn những thành phần riêng lẻ và kết hợp chúng với nhau để tạo thành một hệ thống hoàn chỉnh [2]

Về mặt lư thuyết, ta có thể xây dựng một hệ thống bằng cách kết hợp hàng trăm thành phần với nhau Một số nhà sản xuất đă xây dựng các kiến trúc thành phần phần mềm chuẩn như: JavaBeans, COM+/DCOM và CCM, NET Framework… Khi có nhiều chuẩn được đưa ra th́ các hệ thống được thiết kế bằng cách sử dụng nhiều chuẩn khác nhau sẽ không thể tích hợp với nhau một cách hoàn hảo v́ hai lư do Thứ nhất, cần phải tương thích một cách tuyệt đối giữa các chuẩn đă dùng Thứ hai, sự khác biệt giữa các thuộc tính của các thành phần trong từng chuẩn

Nhược điểm của việc tích hợp thành phần là những khó khăn về mặt công nghệ trong quá tŕnh tích hợp, các ràng buộc về mặt hiệu năng và khả năng không tương thích giữa những nhà phát triển khác nhau Vấn đề này càng trở nên nghiêm trọng hơn khi có một số lượng lớn các thành phần được

sử dụng trong hệ thống Cho nên, việc phát hiện ra độ phức tạp của thành phần sẽ làm cho việc tích hợp và kiểm thử trở nên dễ dàng hơn Hơn nữa, phát hiện ra các thành phần quan trọng sẽ làm giảm rủi ro trong quá tŕnh xây dựng hệ thống Đồng thời, nhiệm vụ bảo tŕ hệ thống sau này cũng sẽ thuận lợi hơn khi ta đă biết đầy đủ bản chất của các thành phần

H́nh 2.1 minh hoạ mối liên kết giữa 2 thành phần của hệ thống P và Q, trong đó mỗi nút đại diện cho một thành phần và mỗi cung đại diện cho mối liên kết giữa các thành phần đó Trong ví dụ này, thành phần B được coi là phức tạp hơn các thành phần A, D, X v́ nó có nhiều đường liên kết hơn Do

đó, B sẽ là thành phần quan trọng hơn Ngoài ra, thành phần X có thể không phức tạp nhưng nó vẫn cần thiết để các hoạt động của toàn bộ hệ thống diễn

ra chính xác Ở đây, các hàm của thành phần X như một cầu nối giữa hai thành phần phức tạp B và E Ngoài ra, độ phức tạp của hệ thống phụ thuộc vào mật độ của các thành phần

2.2 Kỹ thuật tớch hợp thành phần

2.2.1 Adapter

Adapter biến đổi giao diện của một lớp thành một giao diện khác mà client mong muốn, điều đó giúp cho các lớp có các giao diện không tương thích nhau có thể giao tiếp được với nhau Adapter c̣n được gọi là wrapper Client của một lớp cần sử dụng giao diện sẽ tạo ra một yêu cầu tới Adapter thay v́ gửi tới lớp Adapter sẽ dịch yêu cầu này thành dạng mà lớp có thể hiểu được và sau đó gửi cho lớp

Adapter có thể được áp dụng ở mức thành phần, nó sẽ biến đổi giao diện của một thành phần Bằng cách sử dụng Adapter, không cần phải thay đổi thành phần hiện tại và các client của nó khi xảy ra giao tiếp giữa chúng Khái niệm client ở đây có thể được hiểu là các thành phần khác

Adapter có thể thay đổi số lượng công việc mà nó phải làm để tích hợp thành phần với các client của nó Trong một số trường hợp, adapter chỉ cần thay đổi tên của phương thức Số lượng công việc này phụ thuộc vào sự khác biệt giữa giao diện của thành phần và giao diện được client mong đợi

Phía khách (Client)

Adapter

Thành phần

Phía khách (Client)

H́nh 2.2: Mô phỏng Adapter [8]

2.2.2 Bridge

Bridge sử dụng ở mức thành phần cho phép ta tạo ra một liên kết giữa các giao diện của thành phần và phần cài đặt nó Bridge cũng tương tự như Adapter Điều khác biệt chủ yếu là Adapter được sử dụng để giúp cho các thành phần tồn tại một cách độc lập có thể giao tiếp được với nhau, trong khi Bridge được sử dụng vào lúc thực thi một thành phần để tạo ra một giao diện

ổn định và cùng lúc đó cho phép thay đổi phần cài đặt

Khi thay đổi phần cài đặt của thành phần có sử dụng Bridge th́ không cần phải dịch lại mức trừu tượng hoặc thay đổi client của nó Client không quan tâm đến chi tiết của phần cài đặt Bridge giúp mở rộng phần trừu tượng và phần cài đặt của nó một cách độc lập V́ vậy, không cần thiết phải có sự tương ứng 1-1 giữa giao diện và các phương thức cài đặt Phần cài đặt có thể cung cấp nhiều phương thức gốc và giao diện có thể định nghĩa các phương thức ở mức cao hơn dựa trên những phương thức gốc này

Có ba cách cài đặt:

• Cho phép mức trừu tượng biết tất cả những phần cài đặt đă có và client có thể lựa chọn những phần cài đặt này bằng cách gửi các tham số tương ứng

• Cho phép sử dụng một cài đặt mặc định và sau đó có thể thay đổi

• Chuyển lựa chọn cài đặt tới một thành phần Sau đó mức trừu tượng sẽ gọi thành phần này

Phía khách (Client)

Bridge

Thành phần A

Thành phần B

H́nh 2.3: Mô phỏng Bridge [8]

2.2.3 Proxy

Proxy tương tự như thành phần trung gian cho phép quản lư các giao tiếp tới thành phần đích Nó điều khiển truy nhập tới thành phần đích và có các giao diện giống như giao diện của thành phần đích

Proxy được sử dụng rộng răi trong các hệ phân tán nhằm thay thế cho các thành phần từ xa Nó giúp client giao tiếp với một thành phần trung gian chứ không phải là thành phần đích Nó cũng có thể được sử dụng để cung cấp các điều khiển truy nhập tới thành phần Ví dụ: với các client khác nhau sẽ

có quyền truy nhập khác nhau

Không gian địa chỉ

Phía khách (Client)

Phía khách (Client) Không gian địa chỉ

H́nh 2.4: Mô phỏng Proxy [8]