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ử.
Trường đại học
Trường Đại học Công nghệ - Đại học Quốc gia Hà NộiNgười đăng
Ẩn danhThể loại
Luận văn thạc sĩPhí lưu trữ
30 PointMục lục chi tiết
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.
24/09/2025
