Mô hình hóa và kiểm chứng các chương trình phần mềm hướng khía cạnh (TT)

Nội dung đề tài Lập trình hướng khía cạnh dựa trên sự kiện EAOP mô hình cho phép xem xét hệ thống mối quan hệ giữa point-cut và để thực hiện các aspect khi nhận được sự kiệ

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

PHẠM NHƯ UYỂN

MÔ HÌNH HÓA VÀ KIỂM CHỨNG

CÁC CHƯƠNG TRÌNH PHẦN MỀM HƯỚNG KHÍA CẠNH

Ngành: Công nghệ Thông tin Chuyên ngành: Kỹ thuật Phần mềm

Mã số: 60480103

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS Trương Ninh Thuận

HÀ NỘI - 2016

CHƯƠNG 1: ĐẶT VẤN ĐỀ

1.1 Sự cần thiết của đề tài

Có rất nhiều công trình nghiên cứu tập trung vào kiểm chứng mô hình hướng khía cạnh sử dụng các kỹ thuật khác nhau như UML [10], kiểm chứng mô hình (model checking) [9], Petri-net [4], và B [7] nhưng không phù hợp với một hệ thống dựa trên các sự kiện

Một số công trình nghiên cứu đã khai thác những kí hiệu của UML hoặc mở rộng những kí hiệu UML để cụ thể hóa những vấn đề crosscutting Tuy nhiên, những nghiên cứu này đã không giải quyết những khía cạnh kiểm chứng do bản chất không chính thức hoặc bán chính thức của UML Ubayashi và Tamain [8] đã đề xuất một phương pháp để kiểm chứng chương trình AOP sử dụng mô hình kiểm tra Phương pháp nhằm vào các giai đoạn lập trình và ứng dụng các mô hình kiểm tra để có kết quả đan code của lớp và aspect Phương pháp này đảm bảo sự chính xác trong kiểm chứng, tuy nhiên lại bỏ qua các vấn đề kiểm chứng mô đun Điều này có nghĩa là rất khó có thể sử dụng phương pháp này để xác minh phần mềm lớn

Dianxiang Xu [9] đã đề xuất sử dụng máy trạng thái và kiểm chứng những chương trình sử dụng aspect Chúng đã chuyển hóa các mô hình đan và các lớp mô hình không bị ảnh hưởng bởi aspect thành các chương trình FSP, mà sẽ được kiểm chứng bởi mô hình LTSA chống lại các thuộc tính hệ thống mong muốn Tuy nhiên, phương pháp này cần phải chuyển hóa chương trình cơ bản và aspect sang mô hình trạng thái trước khi khởi động mô hình FSP [7] Sử dụng B để kiểm chứng đan aspect Tác giả này trình bày lớp cơ bản và một số aspect liên quan của AspectJ trong ngôn ngữ B Nó nhằm mục đích đạt được lợi ích từ các minh chứng tạo ra bởi công cụ B để đảm bảo chính xác của aspectJ thành phần

Để giải quyết vấn đề này, EAOP [3] cho phép xem xét hệ thống mối quan hệ giữa point-cut và để thực hiện các aspect khi nhận được sự kiện được phát sinh bởi chương trình cơ bản Tuy nhiên, mô hình này không đi kèm với phương pháp đặc tả cụ thể chính thức cũng như không cung cấp bất kỳ cơ chế để xác minh tính chất của nó chính thức Trong bài này, chúng tôi đề xuất một phương pháp dựa trên mô hình hóa phương thức trên Event-B [2] để phân tích một ứng dụng EAOP Đầu tiên, chúng ta xác định các thành phần của nó trong Event-B nơi sử dụng các Event- B cơ chế làm

mịn để mô hình cơ bản và chương trình giám sát Sau đó, khai thác Event – B để chứng minh được tạo ra để kiểm tra xem các hạn chế áp dụng bởi aspect cross-cuts

1.2 Nội dung đề tài

Lập trình hướng khía cạnh dựa trên sự kiện (EAOP) mô hình cho phép xem xét hệ thống mối quan hệ giữa point-cut và để thực hiện các aspect khi nhận được sự kiện được phát sinh bởi chương trình cơ bản Tuy nhiên, mô hình này không đi kèm với phương pháp đặc tả cụ thể chính thức cũng như không cung cấp bất kỳ cơ chế để xác minh tính chất của nó chính thức Trong bài này, chúng tôi đề xuất một phương pháp dựa trên mô hình hóa phương thức trên Event-B để phân tích một ứng dụng EAOP Đầu tiên, chúng ta xác định các thành phần của nó trong Event-B nơi sử dụng các Event- B cơ chế làm mịn để mô hình cơ bản và chương trình giám sát Sau đó, chúng ta khai thác Event – B để chứng minh được tạo ra để kiểm tra xem các hạn chế áp dụng bởi aspect cross-cuts Cuối cùng, phương pháp đề xuất được minh họa chi tiết với một chương trình ATM

1.3 Đóng góp của luận văn

Đóng góp của luận văn liên quan việc mô hình hóa và kiểm chứng EAOP sử dụng phương pháp hình thức Event-B Phương pháp mà chúng tôi đề xuất dựa trên việc dịch một chương trình EAOP thành các máy của Event-B, tận dụng các cơ chế làm mịn để kiểm chứng những ràng buộc trong chương trình trong mỗi aspect Với mong muốn kiểm tra chương trình có còn lưu giữ một số định nghĩa thuộc tính sau khi đan chương trình Luận văn cũng minh họa phương pháp mô hình hóa và kiểm chứng trong một chương trình ATM

1.4 Cấu trúc luận văn

Các phần còn lại của luận văn sẽ được trình bày bao gồm các phần sau:

CHƯƠNG 2: EAOP VÀ EVENT-B

Giới thiệu khái quát những kiến thức cơ bản vể EAOP Mô hình kiến trúc EAOP Trình bày những kiến thức tổng quan về phương pháp mô hình hóa Event-B,

mô tả cấu trúc của mô hình, các thành phần Trình bày công cụ kiểm chứng tự động Rodin

CHƯƠNG 3: MÔ HÌNH HÓA VÀ KIỂM CHỨNG CÁC PHẦN MỀM HƯỚNG KHÍA CẠNH

Tập trung vào việc mô hình hóa và kiểm chứng chương trình phần mềm hướng khía cạnh đưa ra cách định nghĩa hướng khía cạnh hệ thống hướng sự kiện trong Event-B Mô hình hóa hệ thống lập trình hướng khía cạnh sử dụng Event-B Kiểm chứng hệ thống

CHƯƠNG 4: ÁP DỤNG BÀI TOÁN

Áp dụng phương pháp đã trình bày ở trên để mô hình hóa và kiểm chứng bài toán máy ATM

CHƯƠNG 5: KẾT LUẬN

Kết luận tổng thể các kết quả đạt được trong luận văn và hướng phát triển của luận văn

CHƯƠNG 2 EAOP VÀ EVENT-B

2.1 Event-based Aspect Oriented Programming

Nền tảng chung của EAOP được trình bày trong [3] EAOP chú ý đến các sự kiện phát sinh ra trong quá trình thực hiện chương trình độc lập với bất kỳ ngôn ngữ lập trình cụ thể Tính năng chính của mô hình là aspect có thể định nghĩa một hành động cho một chuỗi các sự kiện thay vì cá nhân chỉ như mô tả trong mô hình AOP Nó có những đặc điểm chính sau:

 Aspect: được định nghĩa về các sự kiện sinh ra trong quá trình thực hiện chương trình

 Cross-cuts: giảm chuỗi sự kiện, có thể bao gồm các trạng thái thay đổi, được xác định bởi mô hình sự kiện đó được kết hợp trong quá trình thực hiện chương trình

 Một cross-cuts được chọn, một hành động liên quan được thực hiện

2.2 Các đăc điểm của AOP

a Điểm nối (join point)

Join point [13]: có thể là bất kỳ điểm nào có thể xác định được khi thực hiện chương trình Có thể là lời gọi hàm đến một phương thức hoặc một lệnh gán cho một biến của đối tượng Trong Aspect mọi thứ đều xoay quanh join point

b Hướng cắt (pointcut)

Pointcut [13]: là cấu trúc chương trình mà nó chọn các join point và ngữ cảnh tại các join point đó Ví dụ một pointcut có thể chọn một join point là một lời gọi đến mọt phương thức và lấy thông tin ngữ cảnh của phương thức đó như đối tượng chứa phương thức, các đối số của phương thức đó

c Mã hành vi (advice)

Advice [13]: là mã được thực hiện tại một join point mà được chọn bởi poincut Advice tương tự cấu trúc của hàm cung cấp các thức, các hành động đan xen tại các join point mà nó được chọn bởi pointcut Poincut và advice sẽ hình thành nên các luật đan kết các quan hệ đan xen

Advice được chia thành 3 loại:

 Before: được thực hiện trước join point

 After: được thực hiện sau join point

 Around: bao quanh sự thực hiện join point, advice này có thể thực hiện vòng, thực hiện tiếp của mã nguồn ban đầu hoặc thực hiện thay đổi ngữ cảnh (tham

số của hàm, )

d Khía cạnh (aspect)

Aspect [13]: là phần tử trung tâm của AspectJ, giống như class trong Java Aspect chứa mã thể hiện các luật đan kết cho các concern Join point, pointcut, advice được kết hợp trong aspect

Tuy có gần giống các đặc điểm của class trong Java như: chứa thuộc tính, phương thức, có thể khai báo trừu tượng, có thể kế thừa… Tuy nhiên, Aspect có một số khác biệt cơ bản sau:

 Aspect không thể khởi tạo trực tiếp

 Aspect không thể kế thừa từ một aspect cụ thể (không phải trừu tượng)

 Aspect có thể được đánh dấu là có quyền bằng định danh privileged Nhờ đó

nó có thể truy cập đến các thành viên của lớp mà chúng cắt ngang

e Thực thi cắt ngang (crosscutting)

Crosscutting [13]: trong aspectj, là quá trình biên dịch thực thi các quy tắc đan cá

mô đun cắt ngang vào mô đun chính

Thực thi cắt ngang có 2 loại:

 Thực thi cắt ngang động (dynamic crosscutting): là việc đan các advice mới vào quá trình thực thi một chương trình Trình biên dịch sẽ dựa vào tập các quy tắc đan để xác định điểm đan để chèn thêm hoặc thay thế luồng thực thi của chương trình bằng mô đun cắt ngang Từ đó, làm thay đổi hành vi của hệ thông

 Thực thi cắt ngang tĩnh (static crosscutting) là quá trình đan một sửa đổi vào cấu trúc tĩnh của lớp, giao diên, hay các khía cạnh 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

f Đan mã aspect

AspectJ cho phép đan xen mã aspect với các chương trình Java ở ba mức khác nhau mức mã nguồn, mã bytecode và tại thời điểm nạp chương trình khi chương trình gốc chuẩn bị được thực hiện

Đan ở mức mã nguồn (source code weaving), AspectJ sẽ nạp các mã aspect và Java ở mức mã nguồn (.aj và java), sau đó thực hiện biên dịch để sinh ra mã đã được đan xen bytecode, dạng class Đan xen ở mức mã bytecode (byte code weaving), AspectJ sẽ dịch lại và sinh mã dạng class từ các các mã aspect và Java đã được biên dịch ở dạng (.class) Đan xen tại thời điểm nạp chương trình (load time weaving), các mã của aspectvà Java dạng class được cung cấp cho máy ảo Java (JVM) Khi JVM nạp chương trình để chạy, bộ nạp lớp của AspectJ sẽ thực hiện đan xen và chạy chương trình

Với việc đan xen ở mức mã bytecode và tại thời điểm nạp chương trình thì phương pháp này có thể được sử dụng mà không yêu cầu phải có mã nguồn Khi thay đổi đặc tả thì mới phải phải sinh và biên dịch lại mã aspect [18]

2.2.1 Quản lý các concerns hệ thống

Concern được chia làm 2 loại:

 Concern thành phân: thể hiện các chức năng nội tại của mô đun

 Concern đan xen: thể hiện các quan hệ ràng buộc giữa các mô đun trong hệ thống

Việc xác định được các concern trong hệ thống, chúng ta sẽ tập trung vào các concern một cách độc lập và sẽ giảm độ phức tạp của hệ thống

Các concern đan xen nhau giữa các mô đun, các kỹ thuật thi công hiện tại sẽ trộn chúng vào một mô đun Hình vẽ sau sẽ minh họa: Với mô hình biển diễn nhiều chiều của các concern được ánh xạ trên các ngôn ngữ một chiều như sau

Trong thiết kế phần mềm cách tốt nhất để đơn giản các hệ thống phức tạp là xác định các concern rồi mô đun hóa chúng OOP được thiết kế để phục vụ việc mô đun hóa các concern cơ bản, nhưng khi gặp concern mức hệ thống thì OOP không đáp ứng được yêu cầu Hình sau minh họa ví dụ thiết kế dùng phương pháp truyền thống Ngay cả khi bạn có một bản thiết kế tốt của logging mô đun như: cung cấp

các API trừu tượng (Abstract API), giấu các định dạng log mesage Các mô đun còn lại vẫn cần phải nhúng các đoạn mã để gọi các logging API [13]

2.2.2 Phương pháp luận của AOP

Tuy nhiên cộng đồng nghiên cứu AOP đưa ra 3 bước sau:

 Aspectual decomposition: chúng ta phân tách các yêu cầu nhằm xác định các concern lõi và concern đan xen Các concern lõi được tách ra khỏi các concern đan xen

 Concern implementation: thực thi các concern một cách độc lập

 Aspectual Recomposotion: chỉ ra các quy luật kết hợp bằng cách tạo ra các aspect còn được gọi là quá trình đan mã, sử dụng các thông tin trong aspect để cấu thành hệ thống đích [13]

Hình 8: Các giai đoạn phát triển sử dụng phương pháp AOP

2.2.3 Ưu điểm của AOP

Những ưu điểm của phương pháp AOP như sau:

 Tách biệt chức năng hơn của các mô đun độc lập

 Tính năng mô đun hóa cao hơn

 Phát triển hệ thống dễ dàng hơn

 Kết nối được với các thiết kế trong tương lai

 Tăng khả năng sử dụng lại mã

 Giảm thời gian thi công hệ thống

 Giảm giá thành hệ thống

2.2.4 Nhược điểm của AOP

Mặc dù phương pháp AOP có nhiều ưu điểm, song phương pháp AOP vẫn còn có những nhược điểm là:

 AOP thực ra không giải quyết vấn đề mới, không giải quyết vấn đề chưa giải quyết

 AOP không là cứu cánh cho các nhà thiết kế cẩu thả

 AOP phá vỡ tính đóng gói

2.3 Event-B

Event-B [2] là một phương pháp hình thức dựa trên lý thuyết và tập hợp, ngôn ngữ thay thế tổng quát và logic vị từ bậc một (first order logic) Event-B bao gồm các ký pháp, phương pháp và công cụ hỗ trợ quá trình phát triển phần mềm bằng cách làm mịn (refinement) Quá trình làm mịn bằng cách xây dựng máy trừu tượng sau đó làm mịn dần cho đến khi nhận được một máy thực thi, tương tự như mã nguồn của chương trình [19]

2.3.1 Máy và ngữ cảnh

Các mô hình Event-B được mô tả bởi 2 cấu trúc cơ bản là máy (machines) và ngữ cảnh (context) Trong đó, máy dùng để mô tả phân động của mô hình bao gồm biến, bất biến, định lý, và các sự kiện tương tác với môi trường Ngữ cảnh mô tả phần tĩnh của mô hình, chứa các tập hợp, hằng, tiên đề và định lý [19]

Một mô hình có thể chỉ gồm có máy hoặc ngữ cảnh hoặc sự kết hợp giữa máy và ngữ cảnh Một máy có thể không hoặc tham chiếu một vài ngữ cảnh Các máy và ngữ cảnh của mô hình được làm mịn bằng cách bổ sung các hằng, biến, bất biến, định lý, sự kiên

biến trạng thái Ý tưởng chính của sự phân rã là phân chia mô hình M thành các mô hình con M 1…Mn, các mô hình con này dễ dàng được làm mịn hơn so với mô hình ban đầu [19]

2.3.4 Công cụ

Rodin là bộ công cụ mã nguồn mở dựa trên nền tảng Eclipse để mô hình và kiểm chứng tự động trong Event-B Kiến trúc và công cụ được minh họa hình dưới Trong đó, Event-B UI cung cấp cho người dùng giao diện để chỉnh sửa mô hình Event-B Event-B Core gồm có 3 thành phần: kiểm tra tĩnh (kiểm tra cú pháp trong

mô hình Event-B), máy kiểm chứng (nơi thực hiện các kiểm chứng đơn giản làm cho dễ dàng tự động hóa), và máy quản lý kiểm chứng (quản lý kiểm chứng và chứng cứ liên quan) Các Rodin Core bao gồm 2 thành phần: kho Rodin (quản lý kiên trì dữ liệu) và người xây dựng Rodin (công việc lập lịch tùy thuộc vào những thay đổi trong kho Rodin)

Event-B UI Event-B Core Rodin Core Event-B Library

Eclipse platform

Hình 14: Mô hình kiến trúc Rodin

CHƯƠNG 3: MÔ HÌNH HÓA VÀ KIỂM CHỨNG CÁC PHÂN

MỀM LẬP TRÌNH HƯỚNG KHÍA CẠNH

3.1 Trình bày lập trình hướng khía cạnh hệ thống hướng sự kiện trong

Event-B

EAOP là lập trình hướng khía cạnh hệ thống hướng sự kiện Nếu chương trình ban đầu phát ra một sự kiện hoặc chuỗi các sự kiện, các thành phần giám sát thực hiện các khía cạnh liên quan Sau đây, một số định nghĩa:

Định nghĩa 3.1 (chương trình cơ bản) Một chương trình cơ bản gồm 4-tuple

BP=<E, A, V, C>, trong đó E là tập các sự kiện, A là chuỗi các hành động, V là tập các thuộc tính của chương trình, C là tập các thuộc tính ràng buộc

Chúng ta xem chương trình cơ bản như một chương trình hệ thống hướng sự kiên, chỉ đơn giản bao gồm các sự kiện, hành động, các biến, và những ràng buộc Những ràng buộc này được xem như là đặc tính mong muốn của các ứng dụng bởi vì nó phải thỏa mãn một số các điều kiện

Định nghĩa 3.2 (cross-cut) Một crosscut, được xác định bởi CCE, qui định một chuỗi các sự kiện đại diện cho những điểm xác định đánh giá chương trình cơ bản

Một aspect trong mô hình EAOP gồm biến mới và một cross-cut trong đó chứa các chương trình cơ bản

Định nghĩa 3.3 (aspect) Một aspect trong mô hình EAOP gồm có A=<Vr,

CC×S> trong đó S là tập các advice liên quan đến cross-cut CC và Vr trạng thái biến

Ví dụ: Một ứng dụng EAOP có chứa một aspect thì chuyển một file mã nguồn đến máy chủ bất cứ khi nào nó được sửa đổi trong phiên làm việc Chương trình được

thực hiện với A=<{}, {login → do_login, modigy → commit_svn, logout →

do_logout}>, trong đó login, modify và logout là 3 sự kiện, do_login, commit_svn và do_logout là 3 advice tương ứng