5. Đối tượng cấu phần (Component object): Một đối tượng cấu phần là
1.6 Vòng đời phát triển phần mềm trên cơ sở cấu phần
Mặc dù trong lĩnh vực công nghiệp phần mềm, công nghệ phần mềm trên cơ sở cấu phần (CBSE – component base softwar engineering) được coi là nền tảng vững chắc, nhưng đứng về phương diện là một khoa học cơng nghệ thì nó vẫn cịn khá non nớt. Thực tế cho thấy, các quy trình thành cơng cần phải được chia sẻ như các bài thực hành tốt nhất để có nhiều tổ chức hơn thành cơng với
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 27
CBSE. Vấn đề trước hết là các tổ chức phát triển phần mềm và các phòng dịch vụ thơng tin thường có ghanh đua về vấn đề quy trình đã được đăng ký. Ví dụ, nếu một nhà quản lý dịch vụ thông tin thất bại khi chuyển giao một hệ thống phần mềm, họ sẽ có một lựa chọn là sử dụng tồn bộ nguồn lực bên ngoài. Nếu bạn cho rằng nguồn lực sẵn có, nguồn lực bên ngồi và các cơng cụ phát triển là khơng có gì mới mẻ so với việc phát triển phần mềm thong thường, thì sự khác nhau chính là ở quy trình được sử dụng để phát triển hệ thống phần mềm.
Trọng tâm của quy trình xây dựng giải pháp (Allen và Frost 1998) được đưa ra bởi khách hàng hoặc doanh nghiệp (Eles và Sims, 1998). Trong lĩnh vực công nghệ phần mềm. Điều này luôn đạt được bằng việc mơ hình hóa các quy trình nghiệp vụ (Jacobson 1994). Thỏa thuận giữa khách hàng và nhà thiết kế đạt được thơng qua việc tài liệu hóa các yêu cầu hoặc xem xét các thiết kế. Mỗi lần việc thiết kế giải pháp được bắt đầu, các cấu phần bắt đầu có một ảnh hưởng nào đó. Nhóm chịu trách nhiệm xây dựng các giải pháp thực sự là thành phần chi phối đến dự án. Một lựa chọn cho thiết kế các cấu phần tương tác là dựa trên mơ hình UML. Thách thức cho người xây dựng giải pháp là tập hợp thành hệ thống lớn trên cơ sở các cấu phần. Để làm được điều này ta sẽ cần thơng tin về các cấu phần có sẵn, các giao diện yêu cầu, các dịch vụ, sự vận hành, và các phương thức.
Quy trình tìm đúng các cấu phần là quan trọng với nhà thiết kế, và thuật ngữ thường được sử dụng trong quá trình thiết kế là lấp đầy khoảng trống. Quá trình lấp khoảng trống có thể đưa đến một trong hai kết luận sau:
i) Cấu phần giống như yêu cầu đã được tìm thấy và đưa vào sử dụng.
ii) Khơng có cấu phần nào như thế tồn tại.
Điều này dẫn đến địi hỏi đó là cần có một quy trình lưu trữ các cấu phần có sẵn, đơi khi bạn cũng cần tạo một dự án con để xây dựng một cấu phần theo đặc tả. Điều này có nghĩa là quy trình lưu trữ khơng chỉ nắm giữ các các cấu phần đã xây dựng sẵn, mà cịn kích hoạt quy trình xây dựng cấu phần mới. Lợi ích thực sự của CBSE chỉ được nhận ra bằng cách kích hoạt song song giải pháp và sự phát triển cấu phần, điều này đạt được thông qua việc lập kế hoạch và thiết kế. Với các cấu phần khơng tìm thấy, quy trình lưu trữ phải cho phép khách hàng đưa ra mong muốn để nhận được sự cung ứng khác.
Mỗi lần ta sử dụng một cấu phần cho dù cấu phần đó đã được đóng gói hay đã được gắn vào sản phẩm, ta cũng cần một quy trình quản lý cấu hình cấu phần
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 28
đó. Bởi vì các phiên bản mới của một cấu phần có thể được cung ứng bất cứ lúc nào, và người xây dựng giải pháp có thể muốn cải tiến nâng cấp, hay khách hàng cần một quy trình thơng báo cho họ khi các cấu phần cập nhật, lưu trữ. Người xây dựng giải pháp có thể dễ dàng thay thế một cấu phần tồn tại bằng phiên bản mới hơn. Điều này đạt được nếu người xây dựng giải pháp có xác nhận đăng ký nhận thơng báo khi có cấu phần phiên bản mới được lưu trữ.
Thêm một định nghĩa nữa ở đây để ta có thể phân biệt sự khác nhau giữa vòng đơi phát triển phần mềm và vịng đời cấu phần đó là: Trong một vòng đời phát triển phần mềm truyền thống, những người phát triển thường là người phân tích, thiết kế và lập trình. Một dự án có một sự khởi đầu tốt, khi các yêu cầu trở nên rõ ràng, và kết thúc tốt đẹp khi hệ thống phần mềm cuối cùng sẽ được chuyển giao. Sản xuất cấu phần thì khác, người ta mất nhiều thời gian hơn để nghiên cứu về các quy tắc nghiệp vụ, mơ hình quy trình nghiệp vụ, phân tích và thiết kế. Nhưng thời gian sử dụng để phát triển là ít hơn trong khi kiểm thử phải thực hiện xuyên suốt. Để tìm hiểu một cách chi tiết về vịng đời cấu phần ta đi đến định nghĩa sau:
Vòng đời phần mềm cấu phần (CSLC-Component Software Life Cycle)[3]
biểu diễn quy trình trọn vẹn để phát triển một phần mềm có sử dụng đến tích hợp cấu phần bên ngồi. CSLC nhấn mạnh vào: các quy tắc nghiệp vụ, mơ hình quy trình nghiệp vụ, thiết kế, xây dựng, duy trì kiểm thử, triển khai, mở rộng, duy trì sử dụng lại và bảo trì.
Các giai đoạn phân tích và thiết kế cho 1 CSLC là đặc biệt dài hơn so với vòng đời phát triển phần mềm truyền thống. Hoạt động kiểm chứng được thực hiện ít nhất ở cuối mỗi pha trong CSLC. Trong quá trình kiểm thử đơn vị ta sử dụng cách cài đặt và kiểm thử “tối ưu nhất”. Kiểm thử viên phần mềm phối hợp với tất cả các thành viên trong đội tham gia kiểm thử tích hợp và kiểm thử hệ thống. Việc bảo trì được thiết kế cho cấu phần xác định nhằm phát triển trong thời gian dài. Cài đặt mơ hình cấu phần hỗ trợ sự tương tác và kết hợp, từ đó các kỹ sư có thể tạo các hạ tầng cấu phần phần mềm, đặc tả miền cho các cấu phần của họ tương tác với các chức năng và hành vi của hệ thống gọi cấu phần trong CSLC.
Bảng dưới đây thể hiện so sánh giữa vòng đời phát triển phần mềm truyền thống với vòng đời phát triển CBSE.
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 29
Bảng 1. So sánh vòng đời phát triển trên cơ sở cấu phần với vòng đời phát triển phần mềm truyền thống [3]
Bước Vòng đời phát triển phần mềm truyền thống
Vòng đời phát triển CBSE
1 Mơ hình quy trình nghiệp vụ Mơ hình quy trình nghiệp vụ
2 Quản lý yêu cầu Quản lý yêu cầu
3 Mơ hình thiết kế hệ thống Mơ hình thiết kế hệ thống (cấu phần)
CBSE Lấp đầy khoảng trống (gap fullfilled)
CBSE Đặc tả cấu phần mới
CBSE Đưa cấu phần vào sử dụng
CBSE Lập danh sách thư tín (liên hệ)
4 Lựa chọn mơi trường phát triển tương tác (IDE - Interactive development environment)
Lựa chọn môi tường phát triển tương tác (IDE - Interactive development environment)
5 Xây dựng cơ sở dữ liệu Xây dựng cơ sở dữ liệu 6 Xây dựng tầng giữa Xây dựng tầng giữa
7 Xây dựng phần mềm khác Xây dựng phần mềm khác
8 Kiểm thử Kiểm thử
9 Đóng gói Đóng gói
CBSE Tiếp nhận cảnh báo, cấu phần mới
CBSE Xem xét cấu phần mới
CBSE Cập nhật thiết kế
10 Bảo trì Bảo trì
11 Mở rộng Mở rộng
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 30
Chương 2 CORBA
Chúng ta bắt đầu buổi học về các hệ phân tán hướng đối tượng bằng việcs nói chuyện về Common Object Request Broker Architecture (kiến trúc đối tượng chung yêu cầu trung gian), gọi tắt là CORBA. Như cái tên của nó, CORBA khơng phải là
một hệ thống phân tán chính thống, nhưng phần nào cũng có các đặc điểm của một hệ phân tán. Các đặc điểm này được vẽ lên bởi nhóm quản lý đối tượng OMG (object management group), một tổ chức phi lợi nhuận với trên 800 thành viên, chủ yếu là từ ngành cơng nghiệp. Mục đích quan trọng của OMG đối với CORBA là định nghĩa một hệ phân tán có thể khắc phục nhiều vấn đề về liên thao tác hố khi tích hợp với các ứng dụng mạng. Các chức năng đầu tiên của CORBA xuất hiện đầu tiên vào
những năm 1990. Hiện nay, sự thi hành của CORBA ở phiên bản 2.4 đã được phát
triển rộng rãi, trong khi CORBA phiên bản 3 đầu tiên đang sẵn sàng.
Giống như các hệ thống khác, các kết quả thu được đều phải qua quá trình làm việc trong các uỷ ban, CORBA có nhiều các đặc trưng và các tính năng. Các đặc điểm cốt lõi được nói đến phải trên 700 trang và những cái khác là 1,200 dành để nói về các dịch vụ khác nhau được xây dựng trên nền các đặc điểm cốt lõi đó. Và như một điều tự nhiên, mỗi sự thi hành của CORBA là có sự mở rộng của chính nó vì ln có vài thứ mà mỗi một nhà cung cấp cảm thấy có thể khơng được bỏ lỡ nhưng lại không được bao gồm trong các đặc điểm. CORBA minh hoạ trở lại việc tạo ra một hệ phân tán đơn giản , có thể đó là một bài tập hơi khó.
Theo những dịng trang, chúng ta sẽ khơng thảo luận tất cả các vấn đề mà corba có, chỉ tập trung một số phần thật cần thiết như một hệ phân tán và những cái tiêu biểu đối với các hệ phân tán hướng đối tượng khác. Các đặc điểm của CORBA có thể được tìm thấy tại trang web http:// www.omg.org OMG, 2001.
9.1.1 Tổng quan về corba:
Kiến trúc bao trùm của CORBA trung thành với mơ hình tham chiếu của nhóm OMG. Mơ hình tham chiếu này, như hình 9.1, bao gồm 4 nhóm phần tử kiến trúc nối kết với cái gọi là ORB (Object Request Broker). ORB tạo nên cốt lõi của bất cứ hệ phân tán nào của Corba; nó chịu trách nhiệm cấp quyền liên lạc giữa các đối tượng và các máy khách của các đối tượng trong khi che giấu các vấn đề có liên quan tới sự phân tán và không đồng nhất. Trong nhiều hệ thống, ORB được thi hành như các thư viện được liên kết với một máy khách và một ứng dụng chủ, và cung cấp các dịch vụ truyền thông cơ bản. Chúng ta sẽ trở lại ORB khi thảo luận mơ hình đối tượng
Corba. Các đối tượng ứng dụng Các tiện nghi dọc (vùng đặc trưng) Các tiện nghi ngang (mục đích chung) Các dịch vụ đối tượng phổ biến
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 31
Hình 9-1: Kiến trúc bao trùm của Corba
Ngoài ra, các đối tượng được xây dựng nên như một phần của các ứng dụng cụ thể, mơ hình tham chiếu cũng khác biệt với những gì mà ta biết về các tiện nghi của Corba. Các tiện nghi được khởi dựng như là các thành phần của các dịch vụ của Corba và được tách thành 2 nhóm khác nhau. Các tiện nghi ngang gồm có các
dịch vụ cấp độ cao cho các mục đích chung mà các dịch vụ này là các vùng ứng dụng độc lập. Hiện tại, các dịch vụ như vậy bao gồm giao diện người dùng, quản lý thông tin, quản lý hệ thống, và quản lý các tác vụ (thường để định nghĩa các hệ thống dịng cơng việc). Các tiện nghi dọc gồm có các dịch vụ cấp cao được chèn vào cùng ứng dụng cụ thể như thương mại điện tử, ngân hàng, sản xuất, …
Chúng ta sẽ không thảo luận các đối tượng ứng dụng và các tiện nghi của Corba một cách chi tiết, nhưng thường quan tâm hơn vào các dịch vụ cơ bản và ORB.
Mơ hình đối tượng:
orba sử dụng mơ hình đối tượng từ xa mà chúng ta đã mơ tả trong chương 2. Trong mơ hình này, sự thi hành của một đối tượng cư trú trong khoảng không gian địa chỉ của một máy chủ. Thật là thú vị khi nhận thấy rằng các chi tiết kỹ thuật của Corba không bao giờ ở trạng thái dứt khoát mà các đối tượng sẽ chỉ được thi hành như các đối tượng từ xa. Tuy nhiên, hầu như tất cả hệ thống của Corba chỉ hỗ trợ mơ hình này. Thêm vào đó, các đặc điểm kỹ thuật thường đề nghị các đối tượng phân tán trong
Corba phải thật sự là các đối tượng từ xa. Sau đó, khi thảo luận về mơ hình đối tượng Globe, chúng ta chỉ ra cách thức một mơ hình khác hồn tồn của một đối tượng có
thể, về nguyên lý, cũng được hỗ trợ tốt như Corba.
Các đối tượng và các dịch vụ được định rõ trong Ngôn ngữ định nghĩa giao diện Corba (Interface Definition Language IDL). Corba IDL tương tự như các ngôn ngữ định nghĩa giao diện khác trong đó nó cung cấp một cú pháp nghiêm ngặt cho các phương thức biểu diễn và các tham số. Không thể mô tả ngữ nghĩa trong Corba IDL. Một giao diện là một bộ các phương thức và các đối tượng định rõ các giao diện nào mà chúng thi hành.
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 32
Các chi tiết kỹ thuật giao diện chỉ có thể đựơc cung cấp bởi IDL. Như những gì mà ta sẽ thấy sau đây, trong các hệ thống như Distributed COM và Globe, các giao diện được định rõ tại mức thấp ở dạng các bảng. Chúng được gọi là giao diện nhị phân là bởi sự độc lập bản chất của bất kỳ ngơn ngữ lập trình nào. Tuy nhiên trong Corba, thật là cần thiết khi cung cấp các luật rút trích liên quan tới bản đồ các chi tiết kỹ thuật của IDL tới các ngôn ngữ lập trình có sẵn. Hiện tại, các luật như thế đã được cung cấp cho một số ngôn ngữ, bao gồm cả C, C++, Java, Smalltalk, Ada, và COBOL.
Căn cứ vào việc Corba được tổ chức như một bộ các máy khách và các đối tượng chủ, sự tổ chức tổng quát của một hệ thống Corba được trình bày trong hình 9-2.
Hình 9 – 2: tổ chức tổng quát của một hệ thống Corba
Dưới bất kỳ quy trình nào trong Corba, có là khách hay chủ đều là ORB. ORB có thể được xem tốt nhất trong hệ thống thời gian thực mà ở đó việc điều khiển truyền thơng cơ bản giữa một khách và một đối tượng là đáng tin cậy. Việc truyền thông cơ bản này đảm bảo rằng một lời gọi được gửi đến chủ của các đối tượng và sự trả lời được thông qua quay trở lại khách.
Từ hình phối cảnh của một quá trình, ORB chỉ cung cấp một vài các dịch vụ. Một trong các dịch vụ này đang điều khiển các đối tượng tham chiếu. Các tham chiếu như thế thường phụ thuộc một phần vào ORB. Một ORB vì thế sẽ cung cấp các thao tác để kiểm sốt hay khơng kiểm sốt các đối tượng tham chiếu, cũng như các thao tác cho việc so sánh các tham chiếu. Các đối tượng tham chiếu được thảo luận chi tiết hơn phần sau.
ORB còn cung cấp các thao tác khác để xử lý việc tìm kiếm các dịch vụ có ảnh hưởng đến quá trình lúc khởi đầu. Tổng thể, nó cung cấp một cách thức để thu được một tham chiếu ban đầu tới một đối tượng đang thi hành một dịch vụ cụ thể của
Máy khách Ứng dụng máy khách sự uỷ quyền IDL tĩnh Giao diện lời gọi động OS cục bộ ORB khách Giao diệnO RB
Sự thi hành đối tượng
Bộ khung Giao diện khung động Bộ điều hợp đối tượng Máy chủ Máy khách Ứng dụng máy khách sự uỷ quyền IDL tĩnh Giao diện lời gọi động OS cục bộ ORB chủ Giao diện ORB Giao diện ORB OS cục bộ
Bài giảng COP – Chuyên ngành: CNPM - Version 1
Biên soạn: Ngô Thị Lan & Nguyễn Lan Oanh - 33
Corba. Ví dụ, để sử dụng dịch vụ đặt tên, một quá trình cần biết cách thức để tham
chiếu tới dịch vụ đó. Các mặt khởi tạo đó áp dụng tốt tương tự cho các dịch vụ khác. Ngoài giao diện ORB ra, các máy khách và máy chủ nhận ra rằng mọi thứ