Tài liệu Nghiên cứu các thuật toán giám sát và xử lý cạnh tranh giữa các thành phần phần mềm trên môi trường phân tán

ĐẠI HỌC QUỐC GIA HÀ NỘI 1 TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ BÍCH NGỌC NGHIÊN CỨU CÁC THUẬT TOÁN GIÁM SÁT VÀ XỬ LÝ CẠNH TRANH GIỮA CÁC THÀNH PHẦN PHẦN MỀM TRÊN MÔI TRƯỜNG PHÂN TÁN LUẬN VĂN THẠC SĨ HÀ NỘI - 2007 2 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN THỊ BÍCH NGỌC NGHIÊN CỨU CÁC THUẬT TOÁN GIÁM SÁT VÀ XỬ LÝ CẠNH TRANH GIỮA CÁC THÀNH PHẦN PHẦM MỀM TRÊN MÔI TRƯỜNG PHÂN TÁN Chuyên ngành: Công nghệ thông tin Mã số: 1.01.10 LUẬN VĂN THẠC SĨ Người hưóng dẫn khoa học: PGS.TS. Hồ Sĩ Đàm 5 MỤC LỤC Mở đầu ..................................................................................................................... 9 Chương 1. Thành phần phần mềm (software component) ........................................ 11 1.1 Kỹ nghệ phần mềm hướng thành phần............................................................ 11 1.1.1 Tổng quan kỹ nghệ phần mềm hướng thành phần ................................... 11 1.1.2 Thành phần phần mềm ............................................................................. 14 1.2 Mô hình thành phần ......................................................................................... 15 1.3 Giám sát và dò vết thành phần ........................................................................ 17 1.3.1 Giới thiệu .................................................................................................. 17 1.3.2 Dò vết thành phần ..................................................................................... 18 1.3.3 Cơ chế tăng khả năng dò vết cho thành phần ........................................... 20 1.3.4 Mô hình hướng sự kiện của Java giúp hỗ trợ dò vết ................................ 22 1.3.5 Gói dò vết của Java ................................................................................... 25 3.2.5. Môi trường dò vết cho phần mềm thành phần ......................................... 26 Chương 2. Hệ thống đối tượng phân tán ................................................................... 28 2.1 Giới thiệu ......................................................................................................... 28 2.2 Sự phân tán trong môi trường Java: RMI ........................................................ 30 2.2.1 Hệ thống đối tượng phân tán trong môi trường Java ................................ 30 2.2.2 Giới thiệu ứng dụng phân tán với RMI .................................................... 31 2.2.3 Kiến trúc của cơ chế RMI ......................................................................... 33 Chương 3. Thuật toán phân tán ................................................................................. 38 3.1 Tổng quan về các thuật toán phân tán ............................................................. 38 3.2 Thuật toán trong mạng đồng bộ ...................................................................... 38 3.2.1 Leader election trong mạng vòng đồng bộ ............................................... 39 3.2.2 Leader Election trong mạng đồng bộ tổng quát ....................................... 42 3.2.3 Leader election trong mạng vòng không đồng bộ .................................... 43 3.3 Thuật toán trong mạng không đồng bộ ........................................................... 46 3.3.1 Mutual Exclusion ...................................................................................... 49 3.3.2 Thuật toán mutual exclution của Dijkstra................................................. 52 3.3.3 Thuật toán Two-process của Peterson ...................................................... 56 3.3.4 Thuật toán mutual exclusion của Burn ..................................................... 57 3.3.5 Thuật toán Bakery của Lamport ............................................................... 59 Chương 4. Áp dụng thuật toán phân tán cho hệ thống ATM tại ngân hàng ............. 64 4.1 Giới thiệu hệ thống ATM tại ngân hàng ......................................................... 64 4.2 Chuẩn ISO 8583 .............................................................................................. 65 4.3 Xử lý phân tán hiện tại .................................................................................... 72 4.4 Áp dụng thuật toán Mutual Exclution của Burn ............................................. 73 Kết luận ................................................................................................................. 76 6 Tài liệu tham khảo ................................................................................................. 78 7 Danh mục các chữ viết tắt và thuật ngữ Chữ viết tắt/Thuật Giải thích ngữ CBSE Component-based software engineering - Kỹ nghệ phần mềm hướng thành phần UID Unique Identifier - Định danh duy nhất Leader Election Bầu đại biểu – Trong mô hình mạng vòng đồng bộ, cần tìm ra một tiến trình duy nhất có định danh lớn nhất làm Leader được phép thực hiện tiến trình, các tiến trình khác phải chờ cho đến lượt mình. LCR Lelann, Chang-Roberts – tên thuật toán Mutual Exclution Vấn đề tương tranh– trong mô hình mạng không đồng bộ, vấn đề này xảy ra khi có nhiều hơn một tiến trình cùng truy cập tài nguyên chia xẻ, cần phải có sự phân phối tài nguyên giữa các tiến trình. HSC Hội sở chính của ngân hàng Danh mục các hình vẽ Hình 1.1: Mô hình hệ thống ứng dụng của ngân hàng ...................................... 5 Hình 1.2: Các kiểu dò vết thành phần ............................................................. 16 Hình 1.3: Cấu trúc mô hình dò vết hướng sự kiện .......................................... 19 Hình 1.4: Chuỗi tương tác ............................................................................... 20 Hình 1.5: Gói dò vết ........................................................................................ 21 Hình 1.6: Bộ phỏng theo Tracker.................................................................... 21 Hình 1.7: Sự thi hành của bindBeanTraker..................................................... 22 Hình 1.8 Môi trường dò vết phân tán .............................................................. 23 Hình 2.1 : Mô hình đối tượng phân tán ........................................................... 25 Hình 2.2 : Đăng ký tham chiếu đối tượng từ xa.............................................. 29 Hình 2.3: Kiến trúc của RMI .......................................................................... 30 Hình 2.4: Sự hỗ trợ thi hành của RMI ............................................................ 30 Hình 2.5 : Quan hệ giữa giao diện và lớp ....................................................... 31 Hình 2.6: Các tầng kiến trúc của RMI ............................................................ 32 Hình 2.7 : Kết nối giữa các máy ảo ................................................................. 34 Hình 3.1: Thông điệp liên tiếp được gửi đi trong thuật toán Hirshberg-Sinclair38 Hình 3.2: Hệ thống bộ nhớ chia sẻ. ................................................................ 43 Hình 3.3 : Chu kỳ hoạt động của một tiến trình .............................................. 47 Hình 3.4: Đặc tả giao diện đối với NSD ......................................................... 47 Hình 3.5: Kiến trúc tổng thể của vấn đề mutual exclution ............................. 48 8 Hình 3.6: Tại thời điểm t1, pi thiết đặt flag[i]=2; tại thời điểm t2, pj lại thấy flag[i] ≠ 2; tại thời điểm t3 thì pi rời khỏi vùng C .............................................................. 51 Hình 4.1 : Qui trình xử lý giao dịch trên ATM ............................................... 67 9 Mở đầu Trước khi đi vào giới thiệu nội dung của luận văn, chúng ta hãy nghiên cứu mô hình ứng dụng của ngân hàng[1]. Hình 1.1 : Mô hình hệ thống ứng dụng của ngân hàng Trong mô hình hệ thống, hệ thống nghiệp vụ cốt lõi bao gồm các phân hệ nghiệp vụ cơ bản của ngân hàng, đó là: Thông tin khách hàng(Customer Information File-CIF), Tiền gửi(Deposit), Khoản vay(Loan), Tài trợ thương mại(Trade Finance), Chuyển tiền(Remittance), Ngân quỹ(Tresury) và Sổ cái tổng hợp(General Ledger-GL). Các phân hệ này xử lý tất cả các nghiệp vụ cốt lõi của ngân hàng và giao tiếp với các phân hệ khác, các hệ thống khác thông qua phần xử lý các dịch vụ phân phối. Trên cơ sở các nghiệp vụ này, ngân hàng phát triển các sản phẩm dịch vụ của mình qua các kênh phân phối sản phẩm gồm có: hệ thống giao dịch của chi nhánh(Branch Delivery System BDS), SWIFT/TELEX, IPBS, T5, ATM, POS, HomeBanking, Internet Banking…Đồng thời hệ thống còn có khả năng tích hợp với các hệ thống chương trình khác như: Quản lý mẫu dấu chữ ký, Trái phiếu, CIC, Quản lý TSCĐ, Quản lý phải thu/phải trả… 10 Dữ liệu của toàn bộ hệ thống được lưu trữ tập trung về kho dữ liệu (Data warehouse) tại HSC. Giao dịch tại các chi nhánh trên toàn quốc sẽ được xử lý trực tuyến tại máy chủ. Với mô hình hoạt động như trên ta có thể thấy ngay rằng ứng dụng của ngân hàng là một ứng dụng phân tán và được phát triển từ nhiều thành phần phần mềm ghép nối lại. Mục tiêu của các ngân hàng đặt ra là ngày càng phát triển nhiều sản phẩm dịch vụ khách hàng chất lượng cao, an toàn, tiện lợi. Để đạt được điều này, bênh cạch việc tìm hiểu thị trường về nhu cầu của khách hàng, các nghiệp vụ đáp ứng như cầu đó, một khía cạnh không kém phần quan trọng mà các ngân hàng đang hướng tới chính là lĩnh vực công nghệ thông tin. Vấn đề nghiên cứu, nắm bắt và làm chủ hệ thống để từ đó có thể phát triển hệ thống là một yêu cầu cấp thiết đặt ra tại các ngân hàng. Với mục tiêu đó, bài luận văn đề cập đến các nội dung sau: Chương 1: Thành phần phần mềm Giới thiệu các khái niệm cơ bản về kỹ nghệ phần mềm hướng thành phần, giám sát và dò vết các thành phần phần mềm Chương 2: Hệ thống đối tượng phân tán Giới thiệu tổng quan về hệ thống phân tán, một mô hình đang được áp dụng rất nhiều trong các phần mềm tại ngân hàng. Chương 3: Thuận toán ứng dụng trong môi trường phân tán, giới thiệu các vấn đề nảy sinh trong môi trường phân tán, thuật toán giải quyết các vấn đề đó. Chương 4: Áp dụng thuật toán phân tán cho hệ thống ATM tại ngân hàng Kết luận. Tài liệu tham khảo. 11 Chương 1. Thành phần phần mềm (software component) 1.1 Kỹ nghệ phần mềm hướng thành phần 1.1.1 Tổng quan kỹ nghệ phần mềm hướng thành phần Kỹ nghệ phần mềm hướng thành phần(CBSE) có nghĩa là lắp rắp các thành phần phần mềm có sẵn trước thành một phần mềm lớn hơn[9]. Khái niệm cơ bản của tiến trình này là các thành phần phần mềm được viết để cung cấp các chức năng chung nhất cho nhiều hệ thống khác nhau. Dựa trên ý tưởng các thành phần phần cứng, mục đích của CBSE là cho phép các phần của một hệ thống phần mềm có thể được thay thế bởi các thành phần mới hơn có chức năng tương tự. Ý tưởng này không phải là mới. Phần mềm được thành phần hoá (Componentizing software) đã được đưa ra bởi Mcllorys khi nói về cuộc khủng hoảng phần mềm. Ngày nay, khi ngày càng có nhiều thành phần phần mềm thương mại trên thị trường thì thay vì xây dựng, việc phát triển phần mềm hướng tới mua các thành phần và lắp ráp chúng lại với nhau. Mục đích của CBSE là giảm chi phí phát triển phần mềm: các hệ thống thành phần có tính linh hoạt và dễ duy trì theo xu hướng plug-and-play của các thành phần. Tiến trình phát triển[9] Phát triển phần mềm có hai tiến trình chính: - Lắp ráp hệ thống phần mềm từ các thành phần phần mềm và - Phát triển các phần mềm để có thể sử dụng lại được Các hoạt động lắp ráp các thành phần phần mềm thành một hệ thống phần mềm có thể chia thành 4 hoạt động sau: - Đánh giá chất lượng thành phần (Component qualification) - Chỉnh sửa lại thành phần cho phù hợp (Component adaptation) - Lắp ráp thành phần(Component assemblly) - Phát triển và duy trì hệ thống Mặc dù tiến trình này là khác biệt so với việc phát triển phần mềm truyền thống thì giữa chúng vẫn có những điểm chung, ví dụ như vấn đề quản lý sự thay đổi và duy trì khi phát triển phần mềm. Sau đây chúng ta sẽ đi vào mô tả chi tiết cho từng hoạt động Đánh giá chất lượng Đánh giá chất lượng là xác định khả năng thích ứng của phần mềm khi sử dụng trong hệ thống được tạo cuối cùng. Khi có nhiều sản phẩm cạnh tranh trên thị trường thì vấn đề đặt ra là phải lựa chọn sản phẩm nào phù hợp nhất. Sự lựa chọn sẽ phụ thuộc vào sự so sánh giữa thành phần này với thành phần khác cũng như sự thích ứng 12 trong sử dụng của các thành phần. Vấn đề nảy sinh trong suốt hoạt động này là tính tin cậy(trust) và chứng thực(certification). Tiến trình chứng thực gồm có hai phần: Thiết lập các sự kiện (fact) về một thành phần và xác định các thuộc tính của thành phần có phù hợp với bản đặc tả đã công bố, và Thiết lập sự tin cậy đối với các sự kiện hợp lệ này, có thể nhờ một tổ chức tin cậy thứ ba chứng thực cho độ tin cậy của sự phù hợp này và cấp cho một bảng chứng thực để xác nhận điều đó. Động cơ thúc đẩy việc chứng thực thành phần là do sự liên hệ giữa các thuộc tính được chứng thực của thành phần với các thuộc tính trong hệ thống cuối cùng . Nếu ta hiểu biết về các thành phần được lựa chọn để lắp ráp thì ta có thể đoán được các thuộc tính của chúng trong hệ thống cuối cùng. Độ chính xác của việc tiên đoán phụ thuộc vào độ tin cậy của thành phần cũng như độ hiểu biết về sự gắn kết các thành phần. Đối với rất nhiều thành phần trên thị thường, sự tiên đoán thường là rất khó khăn do thiếu thông tin về các khả năng của thành phần và các thông tin về độ tin cậy của chúng. Theo học thuyết phần mềm cổ điển, việc đặc tả thành phần phải đầy đủ, hoàn thành và ổn định. Tuy nhiên việc đặc tả đầy đủ là không thực tế: một số thành phần có các thuộc tính biểu lộ ra nhưng lại không thể làm thành tài liệu được, chưa kể là tài liệu đó dùng bộ ký hiệu chuyên biệt. Chỉnh sửa cho phù hợp(adaption) Các thành phần khác nhau được viết để đáp ứng các yêu cầu khác nhau, mỗi thành phần đảm đương bối cảnh mà nó triển khai trong đó. Mục đích của việc chỉnh sửa là đảm bảo sự xung đột giữa các thành phần là nhỏ nhất. Việc sử dụng các cách chỉnh sửa khác nhau phụ thuộc vào khả năng truy nhập vào cấu trúc bên trong của thành phần - Các thành phần hộp trắng (white-box) có thể viết lại đáng kể để vận hành cùng với các thành phần khác - Các thành phần hộp xám (grey-box) cung cấp ngôn ngữ mở rộng hoặc giao diện lập trình ứng dụng (API) - Các thành phần hộp đen (balck-box) không cung cấp ngôn ngữ mở rộng cũng như API Nói chung, một thành phần thường là một hộp đen, các dịch vụ của nó chỉ truy cập thông qua giao diện cho trước. Tuy nhiên, theo logic chúng ta vẫn có thể quan tâm đến các thành phần hộp trắng và hộp xám. Lắp ráp thành phần Lắp ráp là tích hợp các thành phần bằng một số công cụ có sẵn để ghép các thành phần lại tạo ra một hệ thống. Ví dụ, các thành phần thương mại thường được viết theo các mô hình thành phần như Enterprise JavaBeans, COM, CORBA và gần đây là .NET. Phát triển và duy trì hệ thống 13 Các thành phần là các đơn vị thay đổi, sự phát triển của hệ thống là sự thay thế các thành phần đã lỗi thời bằng các thành phần mới hơn. Cách nhìn nhận các thành phần là các đơn vị có thể thay thế được là một cách nhìn hơi quá đơn giản về phát triển hệ thống. Trong thực tế, việc thay thế một thành phần không hề đơn giản, đặc biệt là khi thành phần mới và thành phần cũ không tương xứng với nhau sẽ phát sinh việc chỉnh sửa lại cho thành phần mới. Các lĩnh vực nghiên cứu của kỹ nghệ phần mềm hướng thành phần Như đã để cập ở trên, phát triển phần mềm hướng thành phần có rất nhiều lĩnh vực nghiên cứu. Sau đây là một số lĩnh vực - Mô hình và đặc tả hoá thành phần Ngôn ngữ mô hình hợp nhất UML đã trở thành chuẩn phổ biến cho hầu hết mô hình ứng dụng và được dùng trong các phương thức CBSD như là phương thức xúc tác (Catalysis). Đối với các phiên bản trước phiên bản 2.0 cần phải mở rộng UML để cho phép đặc tả riêng các thành phần phụ thuộc và các giao diện của chúng. Vấn đề này được trình bày chi tiết trong cuốn sách UML Components (Cheesman and Daniels 2001). Tuy nhiên, bên cạnh UML còn có một lượng lớn công việc quan trọng để sao cho tiến trình phát triển hướng thành phần được tiếp cận một cách chính thức. Việc đặc tả chi tiết công việc này bao gồm đặc tả giao diện của thành phần, đặc tả các chức năng hoạt động hay các giao thức tương tác, các ràng buộc để một hoạt động được gọi như thế nào và khi nào. - Các kỹ thuật truy lục và khớp đặc tả Vấn đề làm thế nào để truy lục các đối tượng (artefact) có thể sử dụng lại là một lãnh vực nghiên cứu từ lâu trong việc sử dụng lại phần mềm. Việc truy lục đã tập trung vào các dạng mô tả thành phần (component descriptions) nào nên đặt trong thứ tự mà các thành phần đó có thể được truy lục từ các kho chứa, trong khi các kỹ thuật khớp đặc tả được dùng để tìm kiếm các thành phần dựa trên các tiêu chuẩn chức năng hay hành vi. - Các phương pháp sinh phần mềm Các phương pháp này liên quan đến việc sinh phần mềm từ các đặc tả. Các kỹ thuật này được dùng trong kỹ nghệ pháp triển phần mềm được mô tả ở trên. Các nghiên cứu về lĩnh vực này được trình bày tại trang Web: http://www-ia.tuilmenau.de/~czarn/generate/engl.html. - Các kỹ thuật lắp ráp Như đã đề cập ở trên, các kỹ thuật lắp ráp gồm có các thành phần hộp đen, hộp xám và hộp trắng. Nghiên cức về việc lắp ráp trải khắp từ các kỹ thuật đóng gói cho đến các phương thức phức tạp như nhận biết các bộ điều chỉnh phù hợp để khớp đặc tả. Vấn đề liên quan đến các kỹ thuật lắp ráp bao gồm cả việc làm thế nào để khả năng 14 dùng lại của một thành phần có thể cải tiến bằng cách tính đến làm thế nào để chúng có thể lắp ráp thoái mái trong khi chúng vẫn đang được phát triển. - Các ngôn ngữ kết hợp và cấu tạo Khi ta không có định nghĩa về các bộ phận tạo nên thành phần thì COM và CORBA, những ngôn ngữ kết hợp và cấu tạo sẽ được sử dụng để mô tả sự lắp ráp hay kết gắn của tập hợp thành phần. Các ngôn ngữ này cũng có thể được sử dụng để định nghĩa cách thức phần mềm được kết hợp vào khung làm việc (framework) cho trước hoặc cách thức để các thành phần giữa các hệ thống tương tác với nhau. - Xác minh, kiểm tra và cấp chứng thực Phát triển phần mềm hướng thành phần cũng chỉ ra rằng một thành phần phải trải qua hai giai đoạn test. Giai đoạn test thứ nhất xảy ra trong quá trình phát triển phần mềm, xác minh liệu một thành phần có đáp ứng được bản đặc tả của nó và có đáp ứng được các yêu cầu chức năng. Một thành phần có thể được chứng thực bởi bên thứ ba tùy theo cách thức mà thành phần thi hành trong quá trình test. Giai đoạn test thứ hai liên qua đến việc kiểm tra cách thức thành phần được tích hợp với các thành phần khác khi phát triển hệ thống hướng thành phần. Các chiến lược test khác nhau có thể được sử dụng phụ thuộc vào mức độ rõ ràng của cấu trúc bên trong thành phần. Thông thường, người ta dùng các kỹ thuật hộp đen đối với các thành phần thương mại và dùng kỹ thuật hộp trắng đối với các thành phần có mã nguồn. - Quản lý cấu hình Quản lý cấu hình phần mềm là tiến trình điều khiển sự phát triển hệ thống, thiết lập khía cạnh của hệ thống tương lai và định nghĩa các kỹ thuật cho việc quản lý các phiên bản khác nhau của các khía cạnh đó. 1.1.2 Thành phần phần mềm Thành phần phần mềm là gì? Không có câu trả lời chính xác cho câu hỏi này. Có rất nhiều định nghĩa về thành phần phần mềm. Szyperski: Một thành phần phần mềm là một đơn vị cấu tạo nên phần mềm có các giao diện theo thoả thuận và các sự phụ thuộc vào bối cảnh. Một giao diện(interface) là tập các hoạt động được đặt tên có thể được gọi bởi các máy khách. Sự phụ thuộc bối cảnh (Context dependencies) là các đặc tả về môi trường triển khai cần phải cung cấp, để các thành phần có thể hoạt động[2]. D‟Souza và Wills: một gói phần mềm bao gồm sự thi hành với đặt tả các giao diện được đề nghị và yêu cầu[3]. Hầu hết các định nghĩa đều quy tụ về một số độ đo nào đấy nhưng phát sinh khác nhau trong thực tế vì có nhiều quan niệm khác nhau về thành phần phần mềm. Theo truyền thống, một thành phần được coi là một đơn vị về mặt thi hành trong triển khai. Tuy nhiên, quan điểm này lại không đề cập đến các đặc tả trừu tượng hay thậm chí là các tài liệu thiết kế đi kèm với thành phần. Các thành phần sử dụng lại có thể xuất hiện tại mức bất kỳ trong chu trình phát triển, cụ thể người ta ngày càng quan tâm nhiều 15 đến các thành phần thương mại, độc lập với bất kỳ sự thi hành đặc biệt cũng như công nghệ middleware. 1.2 Mô hình thành phần Mô hình thành phần là một kiến trúc và tập các giao diện API cho phép người phát triển xác định các thành phần phần mềm và có thể kết hợp chúng lại với nhau để tạo ra một ứng dụng. Một mô hình thành phần có hai thành phần chính: các thành phần phần mềm và các phần chứa đựng(container)[9]. Các thành phần phần mềm là một miền rộng về cả kích thước cũng như khả năng của nó, từ các giao diện đồ hoạ nhỏ như các nút bấm cho đến các applet có tính chức năng như các trình xem bảng biểu hoặc các ứng dụng đầy đủ hơn như trình duyệt HTML của các ứng dụng bố trí các trang tin. Các thành phần có thể xuất hiện trực quan như các nút bấm, hoặc có thể không trực quan như các thành phần giám sát việc cung cấp dữ liệu. Các container được dùng để nắm được quá trình lắp ráp của các thành phần liên quan. Các container sẽ cung cấp ngữ cảnh để các thành phần được sắp xếp và tương tác với các thành phần khác. Các container đôi khi cũng có thể là các form, các trang, các frame hay các trình tiện ích giao diện người máy (shell). Các container lại cũng có thể chính là các thành phần, ví dụ một container có thể được sử dụng như là một thành phần bên ngoài của một container khác. Bên cạnh việc định nghĩa ra cấu trúc của các thành phần và các container, mô hình thành phần cũng hỗ trợ nhiều dịch vụ khác nhau. Cụ thể hơn là, một mô hình thành phần đầy đủ chức năng thì nó phải hỗ trợ 6 dịch vụ chính dưới đây[12]: Trưng bày nội quan: Introspection Quản lý sự kiện: Event handling Lưu trữ: Persistence Bố trí vật lý: Layout Hỗ trợ trình tạo ứng dụng: Application builder support Hỗ trợ tính toán phân tán: Distribute computing support Trưng bày nội quan (Introspection) Introspection là một kỹ thuật để trưng bày các chức năng của thành phần với thế giới bên ngoài. Thông qua introspection, một ứng dụng có thể truy vấn một thành phần để tìm ra các khả năng có thể và sau đó tương tác một cách tương ứng với thành phần. Introspection là một trong những khía cạnh quan trọng nhất của mô hình thành phần vì nó đảm nhận việc chỉ định cách thức xuất hiện của thành phần trong các ứng dụng và các thành phần khác. Quản lý sự kiện (Event handling) 16 Event handling là kỹ thuật cho phép một thành phần sinh ra các khai báo sự kiện đáp ứng các thay đổi trạng thái bên trong của thành phần. Khi trạng thái của thành phần bị thay đổi, thành phần sẽ sinh ra một khai báo sự kiện và truyền tới tất cả các thành phần liên quan. Các thành phần liên quan có thể là một ứng dụng cha hay các thành phần khác. Kỹ thuận event handling được thiết kế theo cách thức sao cho các sự kiện có thể dễ dàng nắm bắt và trả lời một cách nhất quán. Ví dụ: việc gọi lại một thành phần nút bấm, lời gọi ấy sẽ sinh ra một sự kiện khi ta bấm chuột vào nút bấm. Trong trường hợp này, sự thay đổi trạng thái button được mang lại khi ta kích vào nút đó . Sự thay đổi trạng thái này gây ra một sự kiện và sự kiện đó được quảng bá tới bất cứ event listener liên quan nào(Một event listener là một ứng dụng hay một thành phần được thiết kế để đáp ứng cho sự kiện). Lưu trữ(Persistence) Persistence là cách thức mà một thành phần được lưu trữ và khôi phục lại được từ một vị trí cố định, chẳng hạn như ổ cứng. Thông tin về một thành phần, thực chất là các thông tin được lưu trữ và khôi phục, là trạng thái bên trong của thành phần, cùng với một số thông tin về mối quan hệ của thành phần đó với một container hoặc các thành phần khác. Nhờ sử dụng những thông tin này, một thành phần có thể được lưu trữ một cách an toàn và được tạo lại tại một thời điểm sau đó. Persistence là một dịch vụ quan trọng đặc biệt trong việc thiết kế các công cụ, dịch vụ này cho phép các nhà phát triển sửa đổi các thuộc tính của thành phần để phù hợp với một ứng dụng cụ thể. Bố trí vật lý(Layout) Layout là một dịch vụ quan trọng của bất cứ một mô hình thành phần nào để hỗ trợ sắp xếp vật lý cho các thành phần. Mặc dù layout vật lý chỉ thực sự được đưa tới các thành phần trực quan, nhưng nó lại là một khía cạnh quan trọng của một mô hình thành phần. Hỗ trợ của dịch vụ Layout có thể được chia ra là hai phần: sự sắp xếp một thành phần bên trong không gian của chính nó và sự sắp xếp của một thành phần đối với các thành phần khác có chia sẻ không gian trong cùng một container. Hỗ trợ trình tạo ứng dụng(Application Builder Support) Hỗ trợ dành cho các công cụ xây dựng ứng dụng đã được đưa ra như là một yêu cầu chính cho các mô hình thành phần. Hỗ trợ này cấp cho các người dùng khả năng để xây dựng một cách sinh động nên các ứng dụng phức tạp. Hỗ trợ này chính là khả năng để các thành phần đưa ra các thuộc tính và hành vi của chúng cho các công cụ xây dựng ứng dụng, như là Visual J++. Các công cụ phát triển sử dụng các thuộc tính và hành vi này để cho phép người dùng tích hợp và tuỳ chỉnh các thành phần trong ngữ cảnh của một ứng dụng có ý nghĩa. 17 Phần lớn các công cụ xây dựng ứng dụng cho phép người dùng không chỉ sắp xếp và soạn thảo ra các thành phần riêng biệt, mà còn chỉ ra mối quan hệ giữa các thành phần, cả bên ngoài và bên trong. Hỗ trợ layout, được cung cấp bởi một mô hình thành phần, hỗ trợ việc sắp xếp các thành phần ở bên ngoài, dịch vụ introspection giúp cho các công cụ xây dựng ứng dụng xác định rõ các khả năng của một thành phần và persistence cho phép người dùng lưu lại các thành phần mà đã được tuỳ chỉnh. Hỗ trợ tính toán phân tán(Distributed computing Support) Dịch vụ cuối cùng của mô hình thành phần đó là sự hỗ trợ cho tính toán phân tán. Gần đây vấn đề này ngày càng trở nên quan trọng do sự phát triển của Internet. Ngày nay nó đang tiến tới xây dựng nên các ứng dụng mà có khả năng thực thi trong một môi trường phân tán, được kết nối các qua mạng rộng lớn. 1.3 Giám sát và dò vết thành phần 1.3.1 Giới thiệu Với tốc độ phát triển các chương trình phần mềm về cả kích thước cũng như độ phức tạp như hiện nay, điều quan trọng bây giờ là phải giảm giá thành và độ phức tạp đồng thời phải tăng độ tin cậy và tính sửa đổi được[11]. Với sự phát triển của công nghệ Internet, rất nhiều hệ thống phân tán được xây dựng đáp ứng các ứng dụng khác nhau. Ngày nay, công nghệ thành phần đã giành được sự quan tâm đáng kể trong cộng đồng công nghệ phần mềm. Khi ngày càng có nhiều thành phần mềm thứ 3 trên thị trường thì ngày càng có nhiều xưởng phần mềm bắt đầu sử dụng công nghệ thành phần để phát triển các chương trình hướng thành phần cho các ứng dụng phân tán. Mặc dù có rất nhiều tài liệu đề cập đến việc xây dựng chương trình hướng thành phần, tuy nhiên có rất ít đề cập tới các vấn đề và các thách thức trong việc kiểm tra và duy trì các thành phần phần mềm và các chương trình hướng thành phần phân tán. Trên thế giới hiện nay đã đưa ra một số vấn đề về việc kiểm tra và duy trì các phần mềm hướng thành phần. Trong đó có một số vấn đề liên quan đến việc dò vết thành phần và dò vết chương trình, gồm có các vấn đề sau:  Việc hiểu được các hành vi của thành phần trong một hệ thống là rất khó khăn. Trong việc kiểm tra và duy trì hệ thống, những người thực hiện thường thấy rất khó để có thể hiểu và giám sát các hành vi của thành phần hệ thống, do các nguyên nhân sau - Các kỹ sư thường sử dụng những kỹ thuật đặc biệt để theo dõi các hành vi của các thành phần trong cùng nhóm phát triển (in-house component). Điều này đã tạo ra sự không nhất quán về các thông điệp, các định dạng và các phương thức dò vết khiến người kiểm tra rất khó kiểm soát. - Không có một kỹ thuật hay hàm theo dõi nào được xây dựng sẵn trong các thành phần thứ ba để giám sát các hành vi bên ngoài của chúng. 18 - Không có hàm cấu hình nào cho các client thành phần để điều khiển và cấu hình các kỹ thuật theo dõi có sẵn. - Không có một phương thức hay công nghệ hệ thống nào để điều khiển và giám sát các hành vi bên ngoài của các thành phần.  Việc cô lập, theo dõi và debug các lỗi trong các thành phần là rất khó. Trong một hệ thống, các thành phần được phát triển bởi các đội khác nhau và sử dụng các kỹ thuật theo dõi, các định dạng theo dõi rất khác nhau. Và các kỹ thuật theo dõi cũng như các thông điệp theo dõi đó làm cho việc xác định và cô lập lỗi rất khó khăn.  Chi phí kiểm tra và điều chỉnh các thành phần là rất cao. Việc kiểm tra các chương trình hướng thành phần là một thách thức lớn trong việc kiểm tra hệ thống vì các nhà cung cấp các thành phần không cung cấp một thông tin thi hành nào. Do đó, những người kiểm tra hệ thống cũng như các kỹ sư tích hợp phải cố gắng rất nhiều mới có thể nhận ra các vấn đề về thi hành và các thành phần gây ra lỗi.  Không có sự xác nhận tính hợp lệ tài nguyên hệ thống cho các thành phần. Hầu hết các thành phần đều không cung cấp được thông tin về tài nguyên hệ thống, do đó người kiểm tra và duy trì hệ thống rất khó định vị tài nguyên hệ thống gây ra lỗi. Như vậy là có hai thách thức chính trong việc phát triển phần mềm phân tán hướng thành phần. Thứ nhất là việc thiết kế các thành phần phần mềm với các kỹ thuật và giao diện nhất quán để hỗ trợ cho việc theo dõi và giám sát các hành vi, các hàm, sự thi hành và các tài nguyên của thành phần. Thách thức thứ hai là việc phát triển một phương thức và môi trường có tính hệ thống để giám sát và phân tích các hành vi của các thành phần và sự thi hành hệ thống trong môi trường phân tán. 1.3.2 Dò vết thành phần Theo chuẩn của IEEE (viện công nghệ và kỹ thuật hoa kỳ), “tracking” (dò vết) là tiến trình theo dõi một đối tượng di chuyển hoặc một số lượng lớn biến đầu vào biến đổi, sử dụng một cơ cấu phụ. Một thường trình dò vết là một thường trình chương trình cung cấp bản ghi lịch sử của các sự kiện đặc biệt trong quá trình thi hành chương trình [11]. Dò vết phầm mềm bao gồm: dò vết dự án, dò vết sản phẩm và dò vết chương trình. Dò vết dự án là dò vết các kế hoạch, các hoạt động, các sự kiện của dự án trong suốt quá trình phát triển phần mềm. Dò vết sản phẩm là chỉ việc điều khiển và giám sát sản phẩm một cách có hệ thống và quản lý được. Đây là một tác vụ quan trong trong việc quản lý cấu hình. Dò vết chương trình là các hoạt động và hiệu quả trong việc theo dõi các nhân tố của chương trình, bao gồm dữ liệu đầu vào, các kết quả đầu ra và các hành 19 vi. Việc này hỗ trợ các kỹ sư trong việc hiểu và debug chương trình cũng như trong việc kiểm tra và duy trì phần mềm. Khả năng dò vết thành phần Theo Schmauch Chareles H, khả năng dò vết (traceability) là khả năng có thể xem một item, trạng thái của nó, vị trí nó đã từng ở tại bất kỳ thời điểm nào. Khả năng dò vết của một thành phần mềm là phần mở rộng được xây dựng sẵn trong thành phần có khả năng theo dõi trạng thái của thuộc tính và hành vi thành phần. Khả năng dò vết thành phần gồm có hai khía cạnh sau: - Khả năng dò vết hành vi: đây là mức độ để một thành phần dễ dàng dò vết các hành vi bên trong và bên ngoài của nó. Có hai cách để dò vết hành vi. Thứ nhất là dò vết các hành vi bên trong. Cách này thích hợp với việc kiểm tra và debug bằng hộp trắng. Mục đích là để dò vết các hàm bên trong, các trạng thái đối tượng bên trong, các điều kiện dữ liệu, các sự kiện và thi hành bên trong thành phần. Cách dò vết thứ hai là dò vết hành vi bên ngoài. Cách này thì dùng hộp đen để kiểm tra, tích hợp và duy trì hệ thống. Mục đích chính là để dò vết các dữ liệu, trạng thái đối tượng có thể nhìn thấy, các sự kiện có thể nhìn thấy, các hàm bên ngoài có thể truy cập được và các tương tác với các thành phần khác. - Khả năng điều khiển dò vết: đây là phần mở rộng của khả năng điều khiển trong thành phần để các hàm dò vết có khả năng tuỳ biến dễ dàng. Với khả năng điều khiển dò vết, các kỹ sư có thể điều khiển và thiết lập các hàm tuỳ biến khác nhau, ví dụ như bật và tắt các hàm tuỳ biến và lựa chọn các khuôn dạng dò vết. Ta có thể phân loại dò vết thành phần thành 5 loại như sau:  Dò vết hoạt động(Operation Trace): ghi lại những tương tác của các hoạt động của thành phần, ví dụ như các lời gọi hàm. Dò vết hoạt động được chia thành hai nhóm o Dò vết hoạt động bên trong: dò vết các lời gọi hàm bên trong thành phần o Dò vết hoạt động bên ngoài: ghi lại các tương tác giữa các thành phần. Dò vết hoạt động bên ngoài ghi lại hoạt động của thành phần qua giao diện của nó, gồm các lời gọi hàm đến và các lời gọi hàm đi ra.  Dò vết thi hành(Performance Trace): ghi lại dữ liệu thi hành và chuẩn hoá các hàm của thành phần trên một nền và môi trường định sẵn. Dò vết thi hành rất hữu ích đối với người phát triển và người kiểm tra để nhận ra những điểm tắc nghẽn trong thi hành cũng như chỉnh sửa và kiểm tra thi hành. Để dò vết thi hành, các kỹ sư có thể tạo ra các đo đạc thi hành cho mỗi hàm trong thành phần, bao gồm tốc độ trung bình, tốc độ lớn nhất, nhỏ nhất.  Dò vết trạng thái(State Trace): là dò vết trạng thái đối tượng hay trạng thái dữ liệu trong một thành phần. Trong một kiểm tra thành phần bằng hộp đen, dò vết 20 trạng thái rất hữu dụng cho người kiểm tra theo dõi được các đối tượng(hay dữ liệu) công cộng nhìn thấy được trong thành phần.  Dò vết sự kiện(Event trace): ghi lại sự kiện và dãy các sự kiện xuất hiện trong thành phần. Dò vết sự kiện cung cấp một cách có hệ thống cho các thành phần GUI để theo dõi các sự kiện và dãy sự kiện GUI.  Dò vết lỗi(Error Trace): ghi lại các thông điệp lỗi sinh ra từ thành phần. Dò vết lỗi cung cấp tất cả các thông điệp lỗi, các ngoại lệ, và các thông tin xử lý liên quan được sinh ra từ thành phần. Hình 1.2: Các kiểu dò vết thành phần 1.3.3 Cơ chế tăng khả năng dò vết cho thành phần Khi một chương trình hướng thành phần được tích hợp vào một thành phần phần mềm thì khả năng dò vết của chương trình sẽ phụ thuộc vào khả năng dò vết của thành phần. Khả năng quan sát thành phần cũng phụ thuộc vào khả năng dò vết thành phần. Trong thực tế, chúng ta phải sử dụng các kỹ thuật đặc biệt để thêm các đoạn mã theo dõi vào chương trình. Tuy nhiên ta cũng thấy việc hỗ trợ các thành phần phát triển bởi các tổ chức khác nhau hay các thành phần thương mại là rất khó khăn. Chúng ta sẽ thảo luận ba kỹ thuật dò vết có hệ thống sau. Bảng liệt kê ba các tiếp cận cơ bản Cách dò vết Thêm đoạn mã Tự động thêm Tự động đóng dựa trên khung làm đoạn mã gói thành phần việc phần mềm Mã nguồn Cần Cần Không cần Cắt mã Không Không Có Chi phí Cao Thấp Thấp 21 Độ phức tạp Thấp Rất cao Cao Tính linh hoạt Cao Thấp Thấp Khả năng ứng Cho tất cả các Dò vết hoạt Dò vết hoạt dụng kiểu dò vết động, dò vết thi động, dò vết thi hành hành Các thành phần Các thành phần Các thành phần Các thành phần áp dụng được in-house in-house in-house và thương mại Phương thức 1: Dò vết dựa trên khung (framework-base tracking). Trong cách tiếp cận này, người ta định nghĩa một khung dò vết (ví dụ như một thư viện lớp) cung cấp cho các kỹ sư phát triển để thêm vào các đoạn mã dò vết chương trình để có thể điều khiển các tham chiếu bằng tay được. Phương thức này thường thực hiện dựa trên thư viện dò vết chương trình. Các kỹ sư phát triển các thành phần thường sử dụng thư viện này để thêm các đoạn mã dò vết vào trong các thành phần. Cách tiếp cận này rất linh hoạt và dễ sử dụng. Nó có thể hỗ trợ tất cả các kiểu dò vết, đặc biệt là dò vết lỗi và dò vết GUI. Tuy nhiên cách thức này lại có một số hạn chế. Thứ nhất là chi phí cao. Thứ hai là phụ thuộc vào người thực hiện thêm mã dò vết. Và cuối cùng là phải có mã nguồn của chương trình. Điều này là rất khó đối với các thành phần thương mại vì chúng không bao giờ cung cấp mã nguồn. Phương thức 2: Tự động thêm đoạn mã. Cách tiếp cận này là phần mở rộng của trên. Bên cạnh một khung dò vết còn có một công cụ tự động để thêm các đoạn mã dò vết vào trong mã nguồn của thành phần. Một ví dụ điển hình cho phương thức này là công cụ thêm đoạn dò vết dựa vào phân tích cú pháp. Để dò vết hoạt động, ta thêm các đoạn dò vết hoạt động vào mỗi hàm của lớp tại vị trí bắt đầu và kết thúc hàm để theo dõi được giá trị đầu vào và các biến đầu ra. Tương tự, ta có thể thêm đoạn mã dò vết hoạt động vào trước và/hoặc sau mỗi lời gọi hàm. Đoạn mã dò vết thi hành cũng có thể thêm vào tương tự như vậy để dò vết thi hành của các hàm. Mặc dù cách tiếp cận này có thể giảm được chi phí, nhưng nó cũng có những hạn chế của nó. Thứ nhất là nó đòi hỏi phải có mã nguồn. Như vậy là không thể áp dụng cho các thành phần thương mại được. Thứ hai là nó không linh hoạt, do phụ thuộc vào tính chất tự động, không thể thêm đoạn mã dò vết vào bất kỳ nơi nào ta muốn. Thứ ba là công cụ phân tích rất phức tạp. Khi chương trình hướng phần mềm có các thành phần được phát triển từ nhiều ngôn ngữ khác nhau thì việc xây dựng các công cụ phân tích rất phức tạp, đòi hỏi chi phí cao. Phương thức 3: Tự động đóng gói thành phần. Cách tiếp cận này là một cách mở rộng khác của các thứ nhất. Cách tiếp cận này sẽ thêm các đoạn mã dò vết để giám sát giao diện bên ngoài và các hành vi của thành phần bằng cách đóng gói chúng vào các hộp đen. Tư tưởng là đóng gói tất cả các thành phần có thể sử dụng lại được (hoặc các 22 thành phần thứ ba) với các đoạn mã dò vết để tạo thành thành phần có thể theo dõi được trong một hộp đen. Với đoạn mã dò vết, các kỹ sư có thể giám sát được các tương tác giữa thành phần thứ ba với các thành phần ứng dụng. Cách tiếp cận này rất hữu dụng trong việc xây dựng phần mềm hướng thành phần dựa vào các thành phần phần mềm thứ ba, ví dụ như EJB. So với hai phương thức trên, phương thức này có một số điểm tiến bộ. Thứ nhất là chi phí thấp. Thứ hai là ta có thể tách biệt được đoạn mã dò vết thêm vào với mã nguồn thành phần. Do không cần mã nguồn, phương thức này có thể dùng cho cả thành phần in-house lẫn thành phần thương mại. Tuy nhiên nó không hỗ trợ dò vết lỗi và dò vết trạng thái do tính độc lập của nó đối với các thành phần. Như vậy mỗi cách tiếp cận có điểm mạnh và điểm yếu riêng. Trong thực tế, chúng đều được sử dụng cho các kiểu dò vết khác nhau. Để thiết kế và xây dựng các thành phần dò vết, các kỹ sư cần phải có hiểu biết về kiến trúc của thành phần, giao diện dò vết và các phương tiện hỗ trợ. Họ phải đối mặt với các thách thức sau: (1) Làm thế nào để thiết kế và thực thi các thành phần có thể dò vết và quan sát được trong một môi trường phân tán? (2) Làm thế nào để cung cấp một khung dò vết xác định và kỹ thuật dò vết hiệu quả với chi phí và sức lực thấp nhất? (3) Làm thế nào để hỗ trợ và giám sát hành vi của các thành phần thương mại trong phần mềm hướng thành phần? Sau đây chúng ta sẽ xem xét một giải pháp dò vết hệ thống. 1.3.4 Mô hình hướng sự kiện của Java giúp hỗ trợ dò vết Mô hình dò vết hướng sự kiện là một kỹ thuật hệ thống hỗ trợ các kỹ sư giám sát, kiểm tra các hành vi của thành phần và các tương tác của chúng trong một chương trình hướng thành phần. Tư tưởng cơ bản của mô hình này dựa trên mô hình sự kiện Java cho các thành phần GUI. Tất cả các thành phần phần mềm và các phần tử của chúng đều được coi là nguồn sự kiện dò vết. Trong một thành phần phần mềm, các kỹ sư phát triển thành phần hoặc công cụ dò vết tự động có thể đưa vào đoạn mã dò vết để đưa ra 5 loại dò vết sự kiện. Đó là dò vết thi hành, dò vết hoạt động, dò vết lỗi, dò vết trạng thái và dò vết các sự kiện GUI. Những sự kiện này được đóng gói thành thông điệp dò vết sự kiện và được đưa vào các hành đợi thông điệp dò vết theo từng loại. Để bắt được các sự kiện dò vết khác nhau, chúng ta sử dụng bộ nghe (listener) dò vết để tiếp nhận các sự kiện, gửi chúng đến bộ xử lý dò vết để tạo ra dò vết thích hợp và đưa chúng vào nơi lưu trữ dò vết đặc biệt.