5. Đối tượng cấu phần (Component object): Một đối tượng cấu phần là một thể hiện của cấu phần được cài đặt Khái niệm này khá giống với khái niệm
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 toà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 ngoà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 ngoà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 hoá 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ì luôn 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 hoàn toà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 soát hay không kiểm soá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ứ