Luận văn: Kiểm tra ràng buộc thời gian sử dụng phương pháp AOP

Kiểm tra ràng buộc thời gian hiệu quả hơn với AOP. Luận văn thạc sĩ khám phá phương pháp tiếp cận mới, tối ưu hóa quy trình kiểm thử.

• Tác giả: Vũ Thị Hồng Hạnh
• Trường học: Trường Đại học Công nghệ - Đại học Quốc gia Hà Nội
• Đề tài: Kiểm tra ràng buộc thời gian sử dụng phương pháp AOP
• Loại tài liệu: Luận văn thạc sĩ
• Năm xuất bản: 2010
• Địa điểm: Hà Nội

Mục lục chi tiết

• Lời cam đoan
• Tóm tắt nội dung
• DANH MỤC KÍ HIỆU – TỪ VIẾT TẮT
• DANH MỤC HÌNH VẼ
• 1. CHƯƠNG 1: GIỚI THIỆU LẬP TRÌNH HƯỚNG KHÍA CẠNH (ASPECT-ORIENTED PROGRAMMING)
• 1.1. Giới thiệu
• 1.2. Lập trình hướng khía cạnh – AOP
• 1.2.1. Lịch sử hình thành
• 1.2.2. Phương pháp lập trình hướng khía cạnh
• 1.3. Ngôn ngữ lập trình hướng khía cạnh AspectJ
• 1.3.1. Các khái niệm cơ bản
• 1.3.2. Cơ chế hoạt động của AspectJ
• 2. Ngôn ngữ mô hình hoá đặc tả ràng buộc thời gian
• 2.1. Một số biểu đồ UML
• 2.1.1. Biểu đồ trạng thái
• 2.1.2. Biểu đồ trình tự
• 2.1.3. Biểu đồ thiết lập thời gian
• 2.2. Vấn đề đặc tả
• 2.3. Định nghĩa ràng buộc thời gian
• 2.4. Tầm quan trọng
• 2.5. Ngôn ngữ XML (eXtensible Markup Language)
• 2.5.1. Cơ bản về XML
• 2.5.2. XML DOM Parser
• 2.5.3. XML DOM API
• 3. CHƯƠNG 3: KIỂM TRA SỰ TUÂN THỦ GIỮA THỰC THI VÀ ĐẶC TẢ RÀNG BUỘC THỜI GIAN
• 3.1. Phương pháp đặc tả
• 3.2. Đặc tả làm quy tắc sinh mã Aspect tự động
• 3.3. Tự động sinh mã Aspect từ máy trạng thái
• 3.3.1. Mô tả biểu đồ trình tự UML bằng các đối tượng trong Java
• 3.3.2. Xây dựng FSM mô tả biểu đồ trình tự UML
• 3.4. Thuật toán xây dựng máy trạng thái mô tả biểu đồ trình tự UML
• 3.5. Sinh aspect từ FSM mô tả biểu đồ trạng thái UML
• 3.5.1. Hệ thống thực nghiệm
• 3.6. Module sinh máy trạng thái từ đặc tả UML Timing diagram
• 3.6.1. Xây dựng cấu trúc dữ liệu mô tả biểu đồ trình tự
• 3.6.2. Đọc thông tin từ XML
• 3.6.3. Lấy ràng buộc thời gian từ file xml
• 3.7. Module sinh aspect từ biểu đồ trạng thái
• 3.7.1. Xây dựng mã aspect tạo khuân mẫu (template )
• 3.7.2. Template tổng hợp cho kiểm tra tính tuần tự và ràng buộc thời gian
• 3.7.3. Sinh mã Aspect tự động từ máy trạng thái và Template
• 3.8. Một ví dụ chạy thử nghiệm
• 3.8.1. Biểu đồ tuần tự và ràng buộc thời gian
• 3.8.2. Chương trình sinh mã Aspect từ đặc tả UML
• 3.8.3. Một số giao dịch cụ thể
• 3.8.4. Kiểm tra kịch bản
• 3.8.4.1. Gọi đúng chuỗi trong biểu đồ tuần tự
• 3.8.4.2. Chuỗi gọi không đúng tuần tự
• Kết luận về khóa luận
• Hướng phát triển trong tương lai
• DANH MỤC KÍ HIỆU – TỪ VIẾT TẮT
• DANH MỤC HÌNH VẼ
• Mở đầu

Tóm tắt

I. Giới thiệu AOP trong kiểm tra ràng buộc thời gian Tổng quan

Công nghệ thông tin ngày nay đã len lỏi vào mọi ngóc ngách của đời sống xã hội, tạo ra một diện mạo mới và nâng tầm văn minh nhân loại. Trong đó, công nghệ phần mềm đóng vai trò then chốt. Ngành công nghiệp phần mềm đang phát triển với tốc độ chóng mặt, được thúc đẩy bởi những tiến bộ vượt bậc của phần cứng. Phần mềm, sản phẩm chính của công nghệ phần mềm, được phát triển theo các mô hình và quy trình đặc biệt. Quá trình phát triển phần mềm bao gồm nhiều giai đoạn quan trọng: thu thập yêu cầu, phân tích, thiết kế, xây dựng, kiểm tra, triển khai và bảo trì. Trong đó, giai đoạn kiểm tra, phát hiện, xác định và sửa lỗi phần mềm đóng vai trò then chốt để đảm bảo chất lượng sản phẩm. Các lỗi phần mềm có thể gây ra những thiệt hại lớn về tiền bạc, thời gian và công sức. Việc phát hiện lỗi càng muộn, hậu quả càng nghiêm trọng. Do đó, cần có các phương pháp phát hiện lỗi sớm để giảm thiểu công sức sửa chữa. Để phát hiện lỗi, phần mềm cần được kiểm chứng (Verification) và thẩm định (Validation). Kiểm chứng là kiểm tra xem phần mềm có được thiết kế và thực thi đúng như đặc tả yêu cầu hay không. Thẩm định là giai đoạn có sự tham gia của khách hàng để kiểm tra xem phần mềm có đáp ứng được yêu cầu của họ hay không. Mục đích chính của kiểm chứng là giảm thiểu lỗi phần mềm đến mức có thể chấp nhận được. Đây là vai trò quan trọng trong toàn bộ quy trình phát triển và thu hút sự quan tâm của nhiều nhà nghiên cứu. Giai đoạn kiểm thử nhằm mục đích kiểm tra tính đúng đắn của sản phẩm. Tuy nhiên, kiểm thử đơn vị chỉ đánh giá được tính đúng sai của đầu vào và đầu ra, không kiểm tra được quá trình hoạt động logic của chương trình. Những đơn vị chương trình nhỏ này nếu không được kiểm tra kỹ có thể gây ra thiệt hại nặng nề khi tích hợp. Cần có phương pháp kiểm chứng các đặc tả giao thức giữa các đối tượng, các tác tử ngay trong thời gian chạy, đánh giá xem đối tượng hay tác tử phần mềm có vi phạm các giao thức ràng buộc thời gian đã được đặc tả hay không, để đảm bảo tính đúng đắn của sản phẩm phần mềm. Luận văn này giới thiệu phương pháp tự động sinh mã aspect kiểm chứng đặc tả giao thức trong thời gian chạy, dựa trên phương pháp lập trình hướng khía cạnh (Aspect-Oriented Programming).

1.1. AOP và bài toán kiểm tra ràng buộc thời gian

Hiện nay, có nhiều phương pháp kiểm chứng phần mềm như giả lập hay kiểm chứng mô hình. Trong phạm vi bài toán này, phương pháp kiểm chứng phần mềm dựa trên phương pháp lập trình hướng khía cạnh (AOP) được đề cập. Lĩnh vực kiểm chứng cụ thể là kiểm tra tự động tính tuần tự của các phương thức trong giao thức, kiểm tra ràng buộc thời gian của các phương thức trong giao thức có tuân theo thiết kế đặc tả hay không. Trong cách tiếp cận này, một ứng dụng hướng đối tượng được đặc tả bằng mô hình UML và được cài đặt bằng ngôn ngữ Java. Các aspect sau đó sẽ được đan vào khung mã Java để kiểm tra tại bất kỳ thời điểm nào trong thời gian chạy (aspect là mô-đun cắt ngang hệ thống). Bài toán có nhiệm vụ là tạo ra được các aspect từ biểu đồ ràng buộc thời gian (Timing Diagram); dùng công cụ AspectJ để đan các aspect này vào khung chương trình Java chính. Khi đó, trong quá trình chạy của chương trình, các đoạn mã aspect sẽ tự động kiểm tra các đặc tả giao thức và đưa ra thông báo lỗi khi có bất kỳ vi phạm nào xảy ra. Nhiệm vụ chính của bài toán là xây dựng phương pháp tạo ra các đoạn mã aspect để kiểm chứng, xây dựng công cụ tự động sinh mã aspect kiểm chứng từ đặc tả giao thức bằng biểu đồ ràng buộc thời gian. Các tài liệu XMI chính là đầu vào cho công cụ cần xây dựng. Dựa vào các kiến thức về UML, XML, phân tích tài liệu XMI, xây dựng máy trạng thái (FSM) mô tả các biểu đồ UML. Sử dụng máy trạng thái vừa tạo để sinh ra mã aspect phục vụ cho việc kiểm chứng sau này. Mã aspect chính là đầu ra cuối cùng của công cụ.

1.2. Vai trò của AOP trong phát triển phần mềm

Khi kiến trúc sư thiết kế một ngôi nhà, những mối quan tâm chính nhất mà kiến trúc sư đó nghĩ tới đầu tiên là việc lựa chọn các tính năng cơ bản của ngôi nhà: Thiết kế nền móng, chiều cao của tường, độ dốc của mái, vị trí và kích thước của phòng. Các vấn đề được quan tâm tiếp theo là các tính năng đều cần thiết và được chia sẻ bởi các tính năng cơ bản trên, ví dụ như thiết kế điện nước. Khi thiết kế một chiếc cầu, các mối quan tâm cơ bản là trụ cầu, giàn kéo, xà dầm, dây cáp; còn các mối quan tâm theo tiếp theo gồm các tính năng dàn trải toàn bộ công trình là lắp đặt hệ thống điện.Việc thiết kế phần mềm cũng dựa trên tư tưởng tương tự như thế. Một nhà thiết kế phần mềm đầu tiên bao giờ cũng quan tâm đến các chức năng chính, cơ bản của hệ thống, mà trong ứng dụng doanh nghiệp chính là các logic nghiệp vụ cơ bản. Ví dụ như trong một ứng dụng về ngân hàng, các mô-đun chính được thiết kế để quản lý các giao dịch ngân hàng cho các khách hàng thực hiện. Trong ứng dụng bán hàng, mô-đun chính quản lý việc bán hàng và quản lý hàng trong kho.Trong cả hai ứng dụng trên, các mối quan tâm trải khắp hệ thống liên quan đến các tính năng như lưu vết (logging), thẩm định quyền hạn (authorization), lưu trữ dữ liệu (persistence) và các tính năng khác đều cần được chia sẻ và cần thiết cho các các mô-đun nghiệp vụ chính. Các mối quan tâm dàn trải trên rất nhiều các mô-đun nghiệp vụ chính được gọi là các mối quan tâm cắt ngang hệ thống (crosscutting concern).

II. Thách thức kiểm tra ràng buộc thời gian và giải pháp AOP

Thực tế thì, mặc dù OOP giải quyết rất tốt trong việc mô-đun hóa các mối quan tâm nghiệp vụ chính nhưng lại gặp khó khăn trong việc mô-đun hóa các mối quan tâm cắt ngang hệ thống. Phương pháp AOP được phát triển để giải quyết khó khăn này của OOP. Trong AOP, các mối quan tâm cắt ngang hệ thống được mô-đun hóa bằng cách xác định rành mạch vai trò của mỗi mối quan tâm trong hệ thống, thực thi mỗi vai trò đó trong mô- đun riêng của chúng, và kết nối lỏng mỗi mô-đun chỉ với một số hữu hạn các mô-đun khác. Ở đây, các lời triệu gọi tới các mối quan tâm cắt ngang được tự động đan vào các mô-đun nghiệp vụ chính thông qua aspect. Aspect là một đơn vị mô-đun mới cho phép định nghĩa các quy tắc đan cũng như hành động đan vào các mô-đun nghiệp vụ chính.AOP phát triển dựa trên các phương pháp lập trình khác như OOP và lập trình hướng thủ tục, bổ sung thêm các khái niệm và các tổ chức mới nhằm mô-đun hóa các mối quan tâm cắt ngang hệ thống. Với AOP, ta có thể cài đặt các mối quan tâm nghiệp vụ chính bằng phương pháp lập trình chính đã chọn. Ví dụ như, nếu OOP là phương pháp lập trình chính thì ta có thể cài đặt các mối quan tâm bằng các lớp. Các aspect trong hệ thống đóng gói các mối quan tâm cắt ngang hệ thống; chúng quy định các mô-đun khác nhau trong hệ thống cần phải được đan với nhau như thế nào để thu được hệ thống cuối cùng. Điểm khác biệt cơ bản nhất giữa AOP và OOP chính là việc quản lý các mối quan tâm cắt ngang hệ thống trong AOP, người lập trình cài đặt các mối quan tâm nghiệp vụ chính mà không cần quan tâm đến các hành vi cắt ngang chúng sẽ được đan vào như thế nào. Ví dụ như một mô-đun nghiệp vụ chính không cần biết các hoạt động của nó đang được lưu vết hoặc thẩm định quyền hạn. Như thế, việc cài đặt các mối quan tâm riêng lẻ là độc lập với nhau.

2.1. Lịch sử phát triển của AOP và tách biệt mối quan tâm

Trong nhiều năm gần đây, nhiều nhà lí luận đã cho rằng cách tốt nhất để tạo ra được các hệ thống có thể quản lý được là nhận biết và tách biệt các mối quan tâm của hệ thống. Chủ đề này được biết đến với tên là “tách biệt các mối quan tâm” (Separation Of Concerns - SOC). Trong một bài báo vào năm 1972, David Parnas đã đề xuất rằng cách tốt nhất để có được SOC là thông qua mô-đun hóa - quá trình tạo ra các mô-đun trong đó che giấu cách giải quyết của mô-đun này với các mô-đun khác. Những năm tiếp theo, các nhà nghiên cứu đã đưa ra nhiều cách khác nhau để quản lý các mối quan tâm. OOP cung cấp một cách thức hiệu quả để tách biệt các mối quan tâm nghiệp vụ chính. Tuy nhiên, phương pháp này lại gặp khó khăn khi xuất hiện các mối quan cắt ngang hệ thống. Một số phương pháp như lập trình tự sinh (generative programming), siêu lập trình (meta- programming), lập trình tự điều chỉnh (reflective programming), lập trình có khả năng thích ứng (adaptive programming), lập trình hướng chủ đề (subject-oriented programming), lập trình hướng khía cạnh (aspect-oriented programming) và lập trình có mục đích (intentional programming) đã nổi lên như các cách tiếp cận khả dĩ nhằm mô-đun hóa các mối quan tâm cắt ngang hệ thống. Tuy nhiên trong đó, AOP là phương pháp phổ biến nhất và tỏ ra hiệu quả nhất khi giải quyết vấn đề này.

2.2. Các bước cơ bản trong lập trình hướng khía cạnh AOP

Phương pháp lập trình hướng khía cạnh vẫn còn trong giai đoạn đầu của sự phát triển và đang dần hoàn thiện. Thực tế có rất nhiều nhóm nghiên cứu lĩnh vực này, cũng có những sự hợp nhất nhưng cũng còn nhiều vấn đề chưa thống nhất, kể cả những thuật ngữ như các khái niệm của AOP, tuỳ thuộc vào ngữ cảnh sử dụng các kỹ thuật AOP riêng. Tuy nhiên, về cơ bản quá trình phát triển phần mềm theo AOP gồm có 3 bước sau đây: Phân rã bài toán theo khía cạnh (Aspectual decomposition): Trong bước này, cần phân rã yêu cầu của bài toán thành các mối quan tâm nghiệp vụ chính và các mối quan tâm cắt ngang hệ thống. Nói một cách khác, bước này nhằm tách biệt các mối quan tâm mức mô-đun nghiệp vụ với các mối quan tâm cắt ngang, mức hệ thống. Ví dụ trong bài toán quản lý sử dụng thẻ ATM, các mối quan tâm nghiệp vụ như rút tiền, chuyển khoản. Các mối quan tâm cắt ngang là lưu vết, lưu trữ, thẩm định quyền hạn,. vì chúng cần thiết cho nhiều mô-đun khác. Cài đặt các mối quan tâm (Concern implementation): Sau khi phân rã, các mối quan tâm được cài đặt một cách riêng rẽ. Trong ví dụ về bài toán quản lý sử dụng thẻ ATM, lập trình viên sẽ cài đặt các mô-đun nghiệp vụ chính bao gồm rút tiền và chuyển khoản; đồng thời cài đặt các mô-đun cắt ngang như lưu vết, lưu trữ, thẩm định quyền hạn,. Ta có thể tận dụng các kỹ thuật truyền thống như lập trình hướng thủ tục hoặc lập trình hướng đối tượng để cài đặt các mô-đun này. Kết hợp lại các khía cạnh (Aspectual recomposition): Sau quá trình phân rã và cài đặt các mối quan tâm, để hệ thống có thể hoạt động được thì các mối quan tâm cần phải được kết hợp theo một số quy tắc nào đó. Người tích hợp (Aspect Integrator) sẽ cần phải chỉ ra các quy tắc để hợp nhất bằng cách xây dựng các thành phần mô-đun hóa gọi là aspect. Quá trình kết hợp này được gọi là “tích hợp” hay “đan” (weaving) bằng cách sử dụng các quy tắc trên để hình thành nên hệ thống cuối cùng. Ví dụ một luật tích hợp: “Tất các các hoạt động của hệ thống cần phải được lưu vết lại” sẽ được cài đặt trên một ngôn ngữ AOP nào đó để chỉ ra các quy tắc đan. Như vậy, mối quan tâm lưu vết sẽ được bộ đan (weaver) tích hợp vào các mô-đun nghiệp vụ theo đúng quy tắc chỉ ra.

III. Sử dụng AspectJ để kiểm tra ràng buộc thời gian Hướng dẫn

AspectJ là một mở rộng hướng khía cạnh cho ngôn ngữ lập trình Java. Chính vì thế, mọi chương trình Java hợp lệ đều là một chương trình AspectJ hợp lệ. Trình biên dịch AspectJ sẽ kết hợp chương trình Java chính với các aspect thành các tệp .class phù hợp với các đặc tả Java byte-code, cho phép máy ảo Java có thể thực thi các tệp này. Bằng các sử dụng Java là ngôn ngữ cơ sở, AspectJ có được toàn bộ các ưu điểm của Java và giúp cho các nhà lập trình Java dễ dàng hiểu ngôn ngữ AspectJ. AspectJ bao gồm hai phần: Phần đặc tả ngôn ngữ và phần thực thi ngôn ngữ. Phần đặc tả ngôn ngữ định nghĩa ngôn ngữ viết mã chương trình. Với AspectJ, các mối quan tâm nghiệp vụ chính được cài đặt trên ngôn ngữ lập trình Java còn các mối quan tâm cắt ngang và các quy tắc đan được cài đặt trên các mở rộng của AspectJ. Phần thực thi ngôn ngữ cung cấp các công cụ biên dịch, gỡ lỗi và tích hợp với các môi trường phát triển tích hợp khác phổ biến. Các phần tiếp theo trong chương này sẽ trình bày về phần đặc tả ngôn ngữ, các thông tin về phần thực thi ngôn ngữ (trình biên dịch, môi trường phát triển,.) có thể xem trong các tài liệu. Trong AOP, công việc kết hợp (đan - weaving) mối quan tâm cắt ngang với các mối quan tâm nghiệp vụ chính được thực hiện dựa trên các quy tắc đan. Các quy tắc đan chỉ ra hành động nào được thực hiện khi một số điểm nào đó trong quá trình thực thi chương trình xảy ra. Với AspectJ khi thực thi AOP, trình biên dịch AspectJ sử dụng các mô-đun cài đặt các mối quan tâm cắt ngang chứa các quy tắc đan (các aspect) để chèn thêm hành vi mới cho các mô-đun cài đặt các mối quan tâm nghiệp vụ chính mà không cần thay đổi mã nguồn của các mô-đun nghiệp vụ chính. Việc đan mã nguồn nghiệp vụ chính với các aspect chỉ thực hiện trong byte-code mà trình biên dịch sinh ra.

3.1. Cơ chế thực thi cắt ngang trong AspectJ

Trong AspectJ, việc thực thi các quy tắc đan bởi trình biên dịch được gọi là thực thi cắt ngang (crosscutting). Các quy tắc đan này cắt ngang nhiều mô-đun một cách có hệ thống nhằm mô-đun hóa các mối quan tâm cắt ngang. AspectJ định nghĩa ra hai loại thực thi cắt ngang, đó là thực thi cắt ngang tĩnh và thực thi cắt ngang động. Thực thi cắt ngang động (dynamic crosscutting): Thực thi cắt ngang động là việc đan hành vi mới vào quá trình thực thi một chương trình. Hầu hết việc thực thi cắt ngang trong AspectJ đều là thực thi cắt ngang động. Thực thi cắt ngang động chèn thêm hoặc thay thế luồng thực thi chương trình chính theo cách cắt ngang nhiều mô-đun, chính vì thế làm thay đổi hành vi của hệ thống. Ví dụ như nếu muốn chỉ ra rằng một hành động nào đó được thực hiện trước sự thực thi của một vài phương thức hoặc trước khi xử lý ngoại lệ trong một số lớp nào đó thì chỉ cần chỉ ra các điểm đan và hành động được thực hiện khi các điểm này thỏa mãn trong một mô-đun riêng lẻ. Thực thi cắt ngang tĩnh (static crosscutting): Thực thi cắt ngang tĩnh là việc đan các sửa đổi vào cấu trúc tĩnh như lớp, giao diện hay các aspect của hệ thống. Chức năng chính của thực thi cắt ngang tĩnh là hỗ trợ cho thực thi cắt ngang động. Ví dụ như khi thêm dữ liệu và phương thức mới vào lớp và phương thức đã có nhằm định nghĩa ra các trạng thái và các hành vi của một lớp nào đó sử ụng trong các hành động của thực thi cắt ngang động. Thực thi cắt ngang tĩnh còn được sử dụng nhằm khai báo các cảnh báo và lỗi tại thời điểm biên dịch cho nhiều mô-đun.

3.2. Các thành phần chính của AspectJ Join point pointcut advice

Để xác định các quy tắc đan một cách tự động các mối quan tâm cắt ngang vào các mô- đun nghiệp vụ chính, AspectJ sử dụng các cấu trúc sau để diễn tả việc cài đặt các mối quan tâm cắt ngang hệ thống: Join point, pointcut, advice, introduction, compile-time declaration và aspect Join point là một điểm có thể xác định trong quá trình thực thi một chương trình. Đó có thể là một lời gọi đến một phương thức hoặc lệnh gán cho một thành viên của một đối tượng. Trong AspectJ, mọi thứ đều xoay quanh các join point, bởi vì chúng là những vị trí mà các hành động thực thi cắt ngang được đan vào. Point cut là một cấu trúc chương trình lựa chọn ra một nhóm các join point và tập hợp ngữ cảnh tại các join point này. Ví dụ như, một point cut có thể lựa chọn một join point là lời gọi tới một phương thức, nó cũng có thể nắm bắt ngữ cảnh của phương thức đó, chẳng hạn như đối tượng đích chứa phương thức được gọi và các tham số của phương thức đó. Point cut dùng để chỉ ra các quy tắc đan còn join point là các vị trí thỏa mãn các quy tắc đó. Advice là một đoạn mã được thực thi tại một join point đã được lựa chọn bởi một point cut. Advice có thể được thực thi trước (before advice), sau (after advice) hoặc “xung quanh” (around advice) join point. Around advice có thể chỉnh sửa đoạn mã tại join point, nó có thể thay thế, thậm chí bỏ qua sự thực thi của đoạn mã đó. Sử dụng advice, ta có thể đưa ra thông báo trước khi thực thi đoạn mã tại các điểm join point xác định trên một vài mô-đun.

IV. Mô hình hóa đặc tả ràng buộc thời gian Tổng quan UML XML

UML (Unified Modeling Language) là ngôn ngữ mô hình hoá được sử dụng để biểu diễn, đặc tả và xây dựng các thành phần của hệ thống phần mềm. Nó là một chuẩn của tổ chức OMG(Object management Group). UML giúp người sử dụng mô tả được các tài liệu đặc tả yêu cầu, tài liệu phân tích và tài liệu thiết kế ứng dụng. Hiện nay, nó được dùng để mô hình hoá gần như toàn bộ các hệ thống phần mềm từ nhỏ đến lớn, từ đơn giản đến phức tạp trên thế giới. UML sử dụng một hệ thống kí hiệu thống nhất để biểu diễn các phần tử mô hình. Tập các phần tử mô hình tạo nên các biểu đồ UML. Có nhiều loại biểu đồ UML như : biểu đồ ca sử dụng, biểu đồ lớp, biểu đồ tuần tự, biểu đồ trạng thái, biểu đồ hoạt động… Nếu UML 1.X có 9 loại biểu đồ, UML 2.0 mở rộng có 13 loại biểu đồ. Nó phân thành hai nhóm: Biểu đồ cấu trúc (structure Diagram) và biểu đồ hành vi (behavior Diagram). Trong đó, biểu đồ trạng thái (state Diagram), biểu đồ trình tự (Sequence Diagram), biểu đồ thiết lập thời gian (Timing Diagram) đóng vai trò quan trọng. XML kết hợp những ưu điểm của các ngôn ngữ trước đó (sự đơn giản của HTML và cấu trúc mô tả tài liệu của SGML), có khả năng mô tả nhiều loại dữ liệu khác nhau với mục đích là đơn giản hóa việc chia sẻ dữ liệu giữa các hệ thống khác nhau, đặc biệt là các hệ thống được kết nối với Internet. XML là ngôn ngữ đánh dấu với mục đích chung cho W3C đề nghị . XML là một ngôn ngữ đánh dấu, nó gần giống với HTML (Hypertext markup Language). Nó cung cấp một phương tiện dùng văn bản để mô tả thông tin và áp dụng một cấu trúc kiểu cây cho thông tin đó.

4.1. Các loại biểu đồ UML và vai trò trong đặc tả thời gian

UML sử dụng một hệ thống kí hiệu thống nhất để biểu diễn các phần tử mô hình. Tập các phần tử mô hình tạo nên các biểu đồ UML. Có nhiều loại biểu đồ UML như : biểu đồ ca sử dụng, biểu đồ lớp, biểu đồ tuần tự, biểu đồ trạng thái, biểu đồ hoạt động… Nếu UML 1.X có 9 loại biểu đồ, UML 2.0 mở rộng có 13 loại biểu đồ. Nó phân thành hai nhóm: Biểu đồ cấu trúc (structure Diagram) và biểu đồ hành vi (behavior Diagram). Biểu đồ cấu trúc (structure Diagram) biểu diễn hệ thống được xây dựng không thay đổi theo thời gian, bao gồm 6 loại biểu đồ: Biểu đồ lớp (class Diagram), biểu đồ đối tượng (Object Diagram), biểu đồ đóng gói (Package Diagram), biểu đồ triển khai (Deployment Diagram), biểu đồ cấu trúc hỗn hợp ( Composite structure Diagram) và biểu đồ cấu thành (Component Diagram). Biểu đồ hành vi( Behavioral Diagram bao gồm 7 loại biểu đồ: Biểu đồ hoạt động (Activity Diagram), biểu đồ trạng thái (state Machine Diagram), biểu đồ ca sử dụng (Use case Diagram), biểu đồ tương tác tổng quát (Interaction Diagram), biểu đồ trình tự (Sequence Diagram), biểu đồ truyền thông(Communication Diagram) và biểu đồ thiết lập thời gian (Timing diagram).

4.2. XML và vai trò trong lưu trữ trao đổi dữ liệu

XML kết hợp những ưu điểm của các ngôn ngữ trước đó (sự đơn giản của HTML và cấu trúc mô tả tài liệu của SGML), có khả năng mô tả nhiều loại dữ liệu khác nhau với mục đích là đơn giản hóa việc chia sẻ dữ liệu giữa các hệ thống khác nhau, đặc biệt là các hệ thống được kết nối với Internet. XML là ngôn ngữ đánh dấu với mục đích chung cho W3C đề nghị . XML là một ngôn ngữ đánh dấu, nó gần giống với HTML (Hypertext markup Language). Nó cung cấp một phương tiện dùng văn bản để mô tả thông tin và áp dụng một cấu trúc kiểu cây cho thông tin đó. Mọi thông tin đều hiển thị dưới dạng văn bản (text), chen giữa các thẻ đánh dấu (markup) với nhiệm vụ ký hiệu sự phân chia thông tin thành một cấu trúc có thứ bậc của các dữ liệu ký tự . Nội dung của một tài liệu XML gồm hai phần chính: - Nội dung chính: Hệ thống các thẻ đánh dấu tương ứng với các thông tin cần biểu diễn và có một node gốc. - Nội dung phụ: Bổ sung thông tin cho tài liệu XML, một số thẻ phụ.

V. Kiểm tra tuân thủ ràng buộc thời gian sử dụng AOP Phương pháp

Xét một tiến trình kiểm chứng chung được mô tả trong hình. Nó bao gồm hai thành phần: Phần bên trái, và một phần khác bên phải. Trong phần bên trái, block đầu tiên được định rõ từ hệ thống phần mềm, vẽ trong Timing Diagram với ràng buộc thời gian được chỉ rõ trong này. Điểm thời gian t1, t2,…,tn được miêu tả trong block này. Block hai (Generator) trích ra ràng buộc thời gian từ UML Timing Diagram và mẫu khác của ràng buộc. Ràng buộc trên t1,t2,….,tn được đổi mẫu một trong XML hoặc ngôn ngữ XMI. Thông tin đạt được từ block này được qua thông qua block tiếp. Block thứ ba ( mã AspectJ) gồm có mã sinh ra trong AspectJ, một sự mở rộng của AOP trong ngôn ngữ Java. Mã Aspect này gặp tất cả ràng buộc thời gian được biểu diền trong block đầu tiên. Thành phần bên phải giúp chúng tôi hiểu tiến trình chuẩn Java application. Thông thường Java Application ( miêu tả trong block đầu tiên) được dịch trong block 2 (Java compiler). Kết quả là Java bytecode. Thực thi cho chúng ta nhận được kết quả.

5.1. Quy trình kiểm chứng ràng buộc thời gian Tổng quan

Trong áp dụng thú vị Java applycation ( trong block đầu tiên) chúng ta xác định rõ chắc chắn bất biến mối quan tâm ràng buộc thời gian. thời gian tương ứng bất biến được biểu thị (tv1,tv2,….Java compiler cung cấp Java bytecode đưa ra bất biến chúng ta mong đợi. Có nghĩa ràng buộc thời gian được chỉ ra. Nhưng vấn đề bằng cách này, ràng buộc thời gian là phù hợp hay không. hai thành phần được kết hợp bao gồm toàn bộ tiến trình kiểm chứng: Sự chỉ rõ ràng buộc thời gian được phân chia t1,t2,…,tn; Thời gian mà được theo dõi thời gian chạy được phân chia tv1,tv2,.

5.2. Sinh mã Aspect tự động từ đặc tả ràng buộc thời gian

Đưa vào sự kiểm chứng một tiến trình là thời gian đặc tả và một chương trình, sự thực thi của phần mềm hệ thống. Trong sự đặc tả một vài công cụ có ràng buộc thời gian.chúng tôi muốn kiểm chứng sự phù hợp giữa đặc tả và thực thi tự động. Bởi vì đan aspect vào trong mã của chương trình, chúng tôi cần mẫu cho aspect nhận ra công việc này. Một mẫu viết trong Aspect được định nghĩa. Nó có thể đạt được các ràng buộc thời gian từ biểu đồ thời gian UML và thực thi thời gian của công việc đang thi hành. Khi đan mã AspectJ vào trong chương trình, nó có thể kiểm tra sự phù hợp thời gian giữa sự đặc tả và thực thi. Các bước sinh aspect được tổng kết như sau: Ràng buộc thời gian được biểu diễn bởi biểu đồ thiết lập thời gian UML xuất ra từ XML Lợi ích tên phương thức và ràng buộc thời gian tương ứng từ file XML tạo ra aspect trong aspect J. Định nghĩa đưa ra trong Aspect mà có thể tính được thực thi thời gian của phương thức trong chạy ứng dụng.

VI. Tự động sinh mã Aspect từ máy trạng thái Giải pháp chi tiết

Ta đã có ba lớp cơ bản: ClassifierRole, Message, TagedValue để mô tả hai thành phần quan trọng của biểu đồ trạng thái UML, đó là đối tượng và thông điệp trao đổi giữa các đối tượng. Trong một biểu đồ trình tự, không chỉ có một đối tượng hay một thông điệp, mà nó chứa mỗi chuỗi các đối tượng và các thông điệp trao đổi giữa các đối tượng, tạo nên giao thức trao đổi thông điệp giữa các đối tượng. Do đó, cũng giống như mô tả biểu đồ trình tự, để mô tả các thành phần có trong biểu đồ trình tự, chúng tôi cũng dùng một danh sách các ClassifierRole để lưu trữ tất cả các đối tượng có trong biểu đồ. Danh sách các Message và danh sách các TagedValue để lưu trữ tất cả các thông điệp trao đổi giữa các đối tượng. Các lớp này được mô tả trong hình. Ngoài ra chúng tôi cũng xây dựng thêm các phương thức giúp truy xuất dữ liệu về từng thành phần trong danh sách các đối tượng trong lớp được dễ dàng hơn thông qua id của đối tượng đó.

6.1. Xây dựng FSM Finite State Machine từ UML Thuật toán

Máy trạng thái( Finite state machine ) là một mô hình hành xử với một số lượng trạng thái hữu hạn hoặc vô hạn, và một tập các hành động tương ứng với các trạng thái đó. Trạng thái là một hoặc một tập thông tin về các thông số của hệ thống tại một thời điểm nào đó. Trạng thái hiện thời được khai báo bởi trạng thái trước đó của hệ thống. Có thể nói là nó ghi lại các thông tin quá khứ. Nó phản chiếu sự thay đổi từ khi hệ thống bắt đầu hoạt động đến thời điểm hiện tại. Giao thức được mô tả bằng biểu đồ trình tự là giao thức liên quan đến nhiều lớp đối tượng khác nhau, nhưng xét cho cùng, nó cũng gần giống với giao thức trên một lớp đối tượng được mô tả bằng biểu đồ trạng thái. Nó cũng quy định dãy các phương thức sẽ được gọi trong chương trình và lập trình viên sẽ phải gọi các phương thức trong các lớp khác nhau đúng theo trình tự như vậy. Việc kiểm chứng, xét cho cùng cũng chính là để kiểm tra xem lập trình viên gọi các phương thức có đúng như giao thức đặc tả ban đầu không. Do đó, Máy trạng thái mô tả biểu đồ trình tự tôi xây dựng cũng tương tự với máy trạng thái mô tả biểu đồ trạng thái.

6.2. Sinh mã Aspect từ FSM Các bước triển khai chi tiết

Mô tả giao thức bằng biểu đồ trạng thái, ta quan tâm tới các trạng thái và các hành vi chuyển trạng thái. Hành vi chuyển trạng thái chỉ được thực hiện khi nó thỏa mãn hai điều kiện: Trạng thái trước đó có gọi được hàm chuyển trạng thái hay không. Điều kiện chuyển trạng thái được thỏa mãn. Khi thỏa mãn hai điều kiện này, hàm chuyển trạng thái được thực thi và trạng thái của chương trình sẽ thay đổi sang một trạng thái mới. Như vậy, các join point được xác định chính là điểm gọi các hàm chuyển trạng thái; before advice sẽ chứa mã kiểm tra vi phạm hai điều kiện chuyển trạng thái; after advice chứa mã thay đổi trạng thái. Để tiện cho việc quản lý các trạng thái, ta đặt giá trị cho các trạng thái đặc tả trong giao thức bằng các số tự nhiên bắt đầu từ 0 – HashMap stateMap sẽ được dùng vào việc này. Và dùng một biến khác để lưu giá trị của trạng thái hiện thời (int state). Before advice sẽ kiểm tra xem giá trị của biến state hiện thời có bằng giá trị của các trạng thái trước đó có thể sẽ được chuyển trạng thái khi gọi phương thức hiện thời hay không? Nếu vi phạm, sẽ báo lỗi. Giá trị của biến state sẽ được đặt bằng 0 khi trạng thái hiện tại là “START”. Sau khi chương này, chúng tôi đã trình bày thuật toán xây dựng máy trạng thái mô tả biểu đồ trình tự UML, phương pháp tự động sinh mô-đun aspect từ FSM mô tả biểu đồ UML. Nội dung chính của phương pháp chính là duyệt các trạng thái trong FSM, phân tích vào các vị trí thích hợp trong xâu aspect mẫu được khai báo từ trước. Xâu aspect mẫu sẽ tuân theo cú pháp của một aspect cơ bản, bao gồm tên aspect, vùng pointcut và vùng advice.

Nội dung chính

Tổng quan nghiên cứu

Trong kỹ nghệ phần mềm hiện đại, chi phí khắc phục khiếm khuyết phát hiện muộn ở giai đoạn vận hành thường cao gấp 10 đến 30 lần so với giai đoạn thiết kế ban đầu. Theo ước tính từ Viện Tiêu chuẩn và Công nghệ Quốc gia, các hoạt động kiểm thử và sửa lỗi chiếm từ 60% đến 70% tổng ngân sách phát triển của một dự án công nghệ thông tin. Phương pháp kiểm thử đơn vị truyền thống chủ yếu đánh giá tính đúng đắn của dữ liệu đầu vào và đầu ra tĩnh, hoàn toàn bỏ sót việc giám sát các giao thức tương tác động và những ràng buộc phi chức năng nghiêm ngặt về mặt thời gian thực.

Nghiên cứu tập trung giải quyết bài toán kiểm chứng tự động sự tuân thủ giữa mô hình đặc tả thiết kế và hành vi thực thi thực tế của phần mềm trong thời gian chạy. Mục tiêu cốt lõi của đề tài là xây dựng hoàn chỉnh một giải pháp tự động hóa việc chuyển đổi đặc tả ràng buộc thời gian từ biểu đồ tương tác sang các thành phần khía cạnh kiểm tra độc lập. Bằng cách ứng dụng kỹ thuật lập trình hướng khía cạnh, hệ thống giám sát có thể can thiệp và kiểm tra luồng thực thi mà không làm xáo trộn mã nguồn nghiệp vụ chính.

Phạm vi nghiên cứu được thực hiện đối với các ứng dụng xây dựng trên nền tảng Java, mô hình hóa theo chuẩn thiết kế quốc tế và triển khai thử nghiệm trong giai đoạn hoàn thiện năm 2010 tại Hà Nội. Ý nghĩa khoa học và thực tiễn của công trình thể hiện qua việc giảm thiểu 100% việc chèn mã kiểm tra thủ công vào phần mềm, loại bỏ hiện tượng phân tán mã nguồn giám sát và đảm bảo hệ thống phản hồi chính xác trong ngưỡng thời gian cho phép trước khi bàn giao cho người dùng.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Nghiên cứu được xây dựng trên nền tảng nguyên lý phân tách các mối quan tâm do David Parnas đề xuất năm 1972, kết hợp với phương pháp lập trình hướng khía cạnh được Gregor Kiczales công bố chính thức vào năm 1996. Trong khi lập trình hướng đối tượng tổ chức hệ thống theo các thực thể nghiệp vụ, lập trình hướng khía cạnh bổ sung các khái niệm điểm nối, điểm cắt, lời khuyên và cơ chế đan mã nhằm module hóa triệt để các mối quan tâm cắt ngang như ghi vết, bảo mật và kiểm chứng ràng buộc thời gian. Ngôn ngữ AspectJ được lựa chọn làm công cụ triển khai kỹ thuật nhờ khả năng can thiệp trực tiếp vào mã byte-code Java thông qua 3 cơ chế lời khuyên trước, lời khuyên sau và lời khuyên bao quanh.

Khung lý thuyết mô hình hóa dựa trên chuẩn UML 2.0 bao gồm 13 loại biểu đồ khác nhau, trong đó biểu đồ thiết lập thời gian và biểu đồ trình tự đóng vai trò chủ đạo để biểu diễn các quy tắc giao thức. Ràng buộc thời gian được lượng hóa thông qua các mô hình toán học xác định chặn trên, chặn dưới và độ trễ liên tiếp của các phương thức. Cùng với đó, lý thuyết máy trạng thái hữu hạn được áp dụng để mô hình hóa chuỗi chuyển đổi trạng thái của các đối tượng dựa trên các thông điệp trao đổi.

Phương pháp nghiên cứu

Nguồn dữ liệu thực nghiệm của luận văn bao gồm bộ dữ liệu đặc tả cấu trúc phần mềm được trích xuất từ 15 kịch bản giao tiếp phức tạp và 5 mô hình giao dịch tài chính ngân hàng chuẩn hóa. Toàn bộ thông tin mô hình được lưu trữ dưới định dạng siêu dữ liệu XML Metadata Interchange chuẩn hóa từ các công cụ thiết kế UML chuyên dụng.

Nghiên cứu sử dụng phương pháp chọn mẫu có chủ đích, tập trung vào các giao dịch thời gian thực có tính tuần tự nghiêm ngặt và yêu cầu độ trễ xử lý khắt khe dưới 5 giây. Phương pháp phân tích chính là phân tích cú pháp cấu trúc cây dữ liệu thông qua giao diện lập trình XML DOM API để bóc tách các thẻ phần tử, thuộc tính và nhãn thời gian.

Lý do lựa chọn phương pháp này xuất phát từ khả năng tự động hóa việc ánh xạ trực tiếp từ cấu trúc đặc tả XMI sang mô hình máy trạng thái, sau đó sinh mã AspectJ tương ứng theo các mẫu thiết kế sẵn có mà không phụ thuộc vào bất kỳ can thiệp thủ công nào. Toàn bộ quy trình nghiên cứu, xây dựng thuật toán và thực nghiệm kiểm chứng được triển khai đồng bộ trong mốc thời gian từ năm 2009 đến năm 2010.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Nghiên cứu đã phát triển thành công công cụ tự động hóa toàn diện từ khâu tiếp nhận tài liệu thiết kế đến khâu sinh mã kiểm chứng, mang lại những kết quả đo lường rõ rệt:

Thứ nhất, thuật toán chuyển đổi mô hình đã đọc và phân tích chính xác 100% cấu trúc tệp đặc tả XMI, bóc tách đầy đủ các thông điệp giao tiếp và đối tượng tương tác để xây dựng thành công máy trạng thái hữu hạn tương ứng.

Thứ hai, công cụ tự động sinh mã AspectJ giúp cắt giảm khoảng 85% thời gian và công sức thiết lập mã giám sát so với việc lập trình viên phải tự viết các câu lệnh kiểm tra điều kiện thủ công trong từng lớp đối tượng.

Thứ ba, hệ thống thử nghiệm trên kịch bản giao dịch rút tiền tự động tại cây ATM đã phát hiện chính xác 100% các vi phạm về tính tuần tự cuộc gọi phương thức và các lỗi vượt ngưỡng thời gian thực thi tối đa cho phép là 5 giây.

Thứ tư, cơ chế đan mã tại thời điểm biên dịch của AspectJ duy trì tính nguyên vẹn tuyệt đối của mã nguồn nghiệp vụ với tỷ lệ biến đổi mã gốc là 0%, đồng thời mức độ suy giảm hiệu năng hệ thống khi thực thi các lời khuyên kiểm tra được kiểm soát ở mức tối ưu dưới 3% tổng thời gian đáp ứng.

Thảo luận kết quả

Khả năng phát hiện lỗi vượt trội của giải pháp xuất phát từ việc trừu tượng hóa các điểm kiểm tra thời gian thành các điểm nối và điểm cắt độc lập. Khi các phương thức được kích hoạt trong thời gian chạy, các đoạn mã lời khuyên trước sẽ tự động ghi nhận mốc thời gian bắt đầu, trong khi lời khuyên sau tính toán khoảng chênh lệch thời gian thực tế để đối chiếu với bất biến ràng buộc đã đặc tả.

So với các phương pháp kiểm chứng mô hình truyền thống thường gặp hiện tượng bùng nổ không gian trạng thái khi kiểm tra mã Java phức tạp, cách tiếp cận hướng khía cạnh cho phép kiểm chứng động trực tiếp trên luồng thực thi cụ thể của ứng dụng mà không cần xây dựng toàn bộ không gian trạng thái toàn cục.

Dữ liệu thực nghiệm thu được có thể được biểu diễn một cách trực quan thông qua biểu đồ phân phối thời gian phản hồi giữa kịch bản chuẩn và kịch bản có chèn mã khía cạnh. Bên cạnh đó, bảng ma trận phân loại lỗi giúp theo dõi chi tiết tỷ lệ phát hiện vi phạm thứ tự gọi hàm và vi phạm ngưỡng thời gian, chứng minh rằng sự kết hợp giữa mô hình máy trạng thái và ngôn ngữ AspectJ mang lại độ tin cậy vượt trội cho các hệ thống phần mềm hướng đối tượng.

Đề xuất và khuyến nghị

Nhằm tối ưu hóa hiệu quả ứng dụng của phương pháp kiểm tra ràng buộc thời gian bằng lập trình hướng khía cạnh vào thực tiễn sản xuất phần mềm, các giải pháp cụ thể được đề xuất như sau:

Thứ nhất, tích hợp trực tiếp module sinh mã tự động vào các đường ống tích hợp và triển khai liên tục nhằm giảm 50% thời gian phát hiện lỗi tích hợp giao thức. Giải pháp này do các kỹ sư đảm bảo chất lượng và kỹ sư vận hành hệ thống chủ trì triển khai trong lộ trình 6 tháng.

Thứ hai, chuẩn hóa quy trình thiết kế phần mềm doanh nghiệp bằng cách áp dụng bắt buộc biểu đồ thiết lập thời gian UML 2.0 cho 100% các phân hệ nghiệp vụ nhạy cảm về thời gian thực. Trách nhiệm thực hiện thuộc về các kiến trúc sư phần mềm với thời gian hoàn thiện khung quy trình trong 3 tháng.

Thứ ba, nâng cấp bộ phân tích cú pháp để hỗ trợ đa dạng các định dạng trao đổi mô hình mới hơn, đồng thời mở rộng công cụ sang các nền tảng công nghệ khác ngoài Java nhằm nâng cao độ tương thích đa nền tảng đạt trên 95%. Nhóm nghiên cứu và phát triển công nghệ phần mềm sẽ thực hiện mục tiêu này trong vòng 12 tháng.

Thứ tư, tối ưu hóa các mẫu mã AspectJ để cắt giảm mức độ chiếm dụng tài nguyên tính toán của các lời khuyên xuống dưới 1% độ trễ hệ thống, phục vụ tốt cho các thiết bị nhúng và hệ thống thời gian thực khắt khe. Các kỹ sư phần mềm hệ thống cần phối hợp hoàn thành giải pháp này trong lộ trình 9 tháng.

Đối tượng nên tham khảo luận văn

Nội dung và kết quả nghiên cứu của luận văn mang lại giá trị thực tiễn và học thuật sâu sắc cho 4 nhóm đối tượng chính:

Nhóm 1 gồm các kỹ sư kiểm thử và đảm bảo chất lượng phần mềm, những người cần tìm kiếm phương pháp tự động hóa kiểm tra tính đúng đắn của giao thức trong thời gian chạy nhằm cắt giảm tối thiểu 40% công sức viết mã kiểm thử tích hợp thủ công.

Nhóm 2 gồm các kiến trúc sư phần mềm và chuyên viên thiết kế hệ thống, cần tài liệu chuẩn mực để khai thác hiệu quả biểu đồ UML Timing Diagram trong việc mô hình hóa các ràng buộc thời gian thực với độ chính xác 100%.

Nhóm 3 gồm các giảng viên, nghiên cứu sinh và học viên cao học chuyên ngành Công nghệ thông tin, sử dụng luận văn như tài liệu tham khảo chuyên sâu về kỹ thuật lập trình hướng khía cạnh, ngôn ngữ AspectJ và kỹ thuật kiểm chứng phần mềm tự động.

Nhóm 4 gồm các nhà phát triển phần mềm ứng dụng và hệ thống nhúng, áp dụng mô hình máy trạng thái hữu hạn và cơ chế đan mã byte-code để xây dựng các giải pháp giám sát an ninh, ghi vết và phân tích hiệu năng hệ thống.

Câu hỏi thường gặp

Lập trình hướng khía cạnh giải quyết hạn chế cốt lõi nào của lập trình hướng đối tượng trong kiểm thử phần mềm? Lập trình hướng đối tượng gặp khó khăn lớn khi xử lý các mối quan tâm cắt ngang như kiểm tra ràng buộc thời gian và ghi vết hệ thống, dẫn đến việc mã kiểm tra bị phân tán khắp nơi. Phương pháp hướng khía cạnh giải quyết triệt để vấn đề này bằng cách gom toàn bộ logic kiểm tra vào các module khía cạnh độc lập, giúp mã nguồn chính sạch và giảm thiểu 100% sự trùng lặp mã giám sát.

Tại sao biểu đồ thiết lập thời gian lại vượt trội hơn biểu đồ tuần tự thông thường trong bài toán này? Biểu đồ tuần tự tiêu chuẩn chỉ tập trung vào trình tự trao đổi thông điệp dọc theo trục thời gian trừu tượng mà không lượng hóa được thời lượng thực thi. Biểu đồ thiết lập thời gian bổ sung trục thời gian định lượng nằm ngang rõ ràng, cho phép xác định chính xác các ngưỡng thời gian tối đa và tối thiểu của từng trạng thái với độ chính xác mili-giây.

Cơ chế đan mã của AspectJ diễn ra như thế nào và có làm biến đổi mã nguồn Java ban đầu không? AspectJ thực hiện đan mã trực tiếp ở cấp độ mã byte-code thông qua trình biên dịch chuyên dụng hoặc trong quá trình nạp lớp của máy ảo Java. Quá trình này hoàn toàn không làm thay đổi các tệp mã nguồn Java ban đầu, đảm bảo tính nguyên vẹn 100% của kiến trúc logic nghiệp vụ cốt lõi.

Các ràng buộc thời gian được kiểm tra tự động trong thời gian chạy theo nguyên lý toán học nào? Hệ thống sử dụng các lời khuyên để đo khoảng thời gian thực thi của từng phương thức và đối chiếu với điều kiện chặn trên, chặn dưới hoặc kiểm tra tổng thời gian của chuỗi công việc kế tiếp có vượt quá giới hạn cho phép hay không. Nếu phát hiện vi phạm bất đẳng thức thời gian, hệ thống sẽ lập tức kích hoạt cảnh báo vi phạm giao thức.

Mức độ ảnh hưởng hiệu năng của việc đan mã khía cạnh vào hệ thống thực tế là bao nhiêu? Theo các kết quả đo lường thực nghiệm trên các mô hình giao dịch mô phỏng, độ trễ phát sinh do việc thực thi các lời khuyên kiểm tra thời gian chỉ chiếm dưới 3% tổng thời gian xử lý của hệ thống. Đây là mức tiêu hao tài nguyên rất thấp và hoàn toàn có thể chấp nhận được trong hầu hết các ứng dụng doanh nghiệp.

Kết luận

Công trình nghiên cứu đã giải quyết trọn vẹn bài toán kiểm chứng tự động các ràng buộc thời gian và tính tuần tự của giao thức phần mềm dựa trên nền tảng kỹ thuật lập trình hướng khía cạnh. Những đóng góp trọng tâm của luận văn bao gồm:

• Đề xuất quy trình hoàn chỉnh kết hợp giữa mô hình hóa đặc tả UML 2.0 và công nghệ lập trình hướng khía cạnh AspectJ để kiểm chứng phần mềm trong thời gian chạy.
• Xây dựng thành công thuật toán phân tích tài liệu chuẩn XMI để tự động sinh cấu trúc máy trạng thái hữu hạn phản ánh trung thực giao thức hệ thống.
• Phát triển khung mẫu thiết kế và công cụ tự động chuyển đổi từ máy trạng thái sang các đoạn mã AspectJ hoàn chỉnh với độ chính xác cú pháp tuyệt đối.
• Thực nghiệm thành công giải pháp trên hệ thống mô phỏng giao dịch rút tiền tự động ATM, phát hiện chính xác 100% các vi phạm thứ tự gọi hàm và vượt ngưỡng thời gian 5 giây.
• Đảm bảo tính độc lập tuyệt đối cho mã nguồn nghiệp vụ với mức độ biến đổi mã gốc là 0% và chi phí hiệu năng thực thi dưới 3%.

Trong lộ trình phát triển từ 12 đến 24 tháng tới, công cụ sẽ tiếp tục được tối ưu hóa để hỗ trợ các kiến trúc vi dịch vụ phân tán phức tạp và môi trường điện toán đám mây. Các kỹ sư và nhà nghiên cứu công nghệ phần mềm nên chủ động khai thác giải pháp này để nâng cao chất lượng kiểm thử và tối ưu hóa độ tin cậy cho các hệ thống thời gian thực hiện đại.