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

Để mô hình hóa và kiểm chứng các hệ thống dựa trên sự kiện, lập trình hướng khía cạnh dựa sự kiện Event-based Aspect Oriented Programming – EAOP [3] xác định đan khía cạnh bằng cách phá

ĐẠ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

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TIN

HÀ NỘI - 2016

ĐẠ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

LỜI CAM ĐOAN

Tôi xin cam đoan toàn bộ nội dung bản luận văn là do tôi tìm hiểu, nghiên cứu, tham khảo và tổng hợp từ các nguồn tài liệu khác nhau và làm theo hướng dẫn của người hướng dẫn khoa học Các nguồn tài liệu tham khảo, tổng hợp đều có nguồn gốc rõ ràng và trích dẫn theo đúng quy định

Tôi xin chịu hoàn toàn trách nhiệm về lời cam đoan của mình Nếu có điều gì sai trái, tôi xin chịu mọi hình thức kỷ luật theo quy định

Hà Nội, tháng 05 năm 2016 Người cam đoan

Phạm Như Uyển

LỜI CẢM ƠN

Đầu tiên tôi xin gửi lời cảm ơn sâu sắc tới thầy PGS.TS Trương Ninh Thuận,

Bộ môn Công nghệ Phần mềm, Khoa Công nghệ Thông tin, trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội – người đã định hướng đề tài và tận tình hướng dẫn chỉ bảo tôi trong suốt quá trình thực hiện luận văn tốt nghiệp này

Tôi cũng xin trân trọng cảm ơn quý thầy cô trong Khoa Công nghệ Thông tin trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy, truyền đạt những kiến thức quý báu trong suốt quá trình học làm nền tảng cho tôi thực hiện luận văn này

Cám ơn các anh, chị nghiên cứu sinh và các bạn học viên Khoa Công nghệ Thông tin Các anh chị và các bạn đã giúp đỡ, ủng hộ tôi rất nhiều cũng như đóng góp nhiều ý kiến quý báu, qua đó, giúp tôi hoàn thiện luận văn tốt hơn

Mặc dù đã rất nỗ lực, cố gắng nhưng chắc hẳn luận văn của tôi vẫn còn nhiều thiếu sót Tôi rất mong nhận được nhiều những ý kiến đánh giá quý, phê bình của quý thầy cô, của anh chị và các bạn

Một lần nữa tôi xin chân thành cảm ơn!

Hà Nội, tháng 5 năm 2016

Phạm Như Uyển

MUC LỤC



MUC LỤC 3

DANH SÁCH CÁC HÌNH VẼ 5

DANH SÁCH CÁC THUẬT NGỮ VÀ KHÁI NIỆM 7

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

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

1.2 Nội dung đề tài 9

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

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

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

2.1 Các đặc điểm của lập trình hướng khía cạnh 12

 2.1.1 Quản lý các concerns hệ thống 15

 2.1.2 Phương pháp luận của AOP 18

 2.1.3 Ưu điểm của AOP 19

 2.1.4 Nhược điểm của AOP 19

2.2 Lập trình hướng khía cạnh dựa sự kiện 20

 2.2.1 Công cụ EAOP: Kiến trúc và thực hiện 21

2.3 Event-B 27

 2.3.1 Máy và ngữ cảnh 27

 2.3.2 Sự kiện 30

 2.3.3 Phân rã và kết hợp 31

 2.3.4 Công cụ 31

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 33

3.1 Trình bày EAOP trong Event-B 33

3.2 Mô hình hóa hệ thống EAOP sử dụng Event-B 34

3.3 Kiểm chứng các thuộc tính hệ thống 34

CHƯƠNG 4: PHƯƠNG PHÁP THỰC NGHIỆM 36

KẾT LUẬN 45

TÀI LIỆU THAM KHẢO 47

PHỤ LỤC 49

DANH SÁCH CÁC HÌNH VẼ

Hình 1: Mô hình ánh xạ từ các concern hệ thống sang các phương pháp lập trình

truyền thống 16

Hình 2: Các mô đun yêu cầu logging đều phải nhúng các đoạn mã để gọi logging API 17

Hình 3: Giải quyết các concern hệ thống bằng phương pháp AOP 18

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

Hình 5: Kiến trúc của EAOP 20

Hình 6: Ví dụ đơn giản hóa việc thực hiện trong chương trình cơ bản 22

Hình 7: Cây khía cạnh và sự kiện truyền 25

Hình 8: Cấu trúc máy và ngữ cảnh 28

Hình 9: Mối quan hệ giữa các thành phần máy và ngữ cảnh 28

Hình 10: Cấu trúc máy chi tiết 29

Hình 11: Cấu trúc ngữ cảnh chi tiết 30

Hình 12: Rodin GUI 31

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

Hình 14: Phương pháp mô hình hóa và kiểm chứng các chương trình hướng khía cạnh 37

Hình 15: Lớp Transaction 38

Hình 16: Lớp Exchange 38

Hình 17: Khía cạnh updatetr 39

Hình 18: Sự kiện chuyển tiền gửi trên máy ATM 39

Hình 19: Kết quả minh chứng 40

Hình 20: Lớp Exchange đã được sửa đổi 40

Hình 21: Event-B đặc tả của chương trình cơ bản 42

Hình 22: Đặc tả Event-B của khía cạnh 43

Hình 23: Kết quả thực hiện 43

Hình 24: Kết quả bảng Statistics 44

DANH SÁCH CÁC THUẬT NGỮ VÀ KHÁI NIỆM

AOP Aspect Oriented Programming –

tảng Eclipse

OOP Object-orented programming – Lập

trình hướng đối tượng

FSP Finite State Processes – Quá trình

hữu hạn trạng thái

LTSA Labelled Transition System Anlyzer

- Công cụ phân tích chuyển hệ thống

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

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

Ngày nay, sự phát triển mạnh mẽ của phần mềm ngày càng đóng vai trò quan trọng, được ứng dụng vào tất cả các lĩnh vực trong đời sống xã hội hiện đại Làm cho

tỷ trọng giá trị phần mềm trong các hệ thống ngày càng lớn Tuy nhiên, trong nhiều

hệ thống, lỗi của phần mềm gây ra hậu quả đặc biệt nghiêm trọng, không chỉ thiệt hại nặng nề về mặt kinh tế [14]

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 để mô hình hóa và kiểm chứng các hệ thống dựa trên 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 đề thực thi cắt ngang (crosscutting) Tuy nhiên, những nghiên cứu này đã không giải quyết những kiểm chứng của khía cạnh do bản chất không hình thức hoặc bán hình thức của UML Các tác giả Ubayashi

và Tamai [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à khía cạnh 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 Tác giả 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 hướng khía cạnh Các tác giả đã chuyển hóa đan các mô hình và các lớp mô hình không bị ảnh hưởng bởi khía cạnh thành các quy trình FSP, mà sẽ được kiểm chứng bởi mô hình LTSA kiểm tra đối với các thuộc tính hệ thống muốn

có 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à khía cạnh sang mô hình trạng thái trước khi khởi động mô hình FSP Tác giả đã dùng B [7] để kiểm chứng đan khía cạnh Tác giả bài báo trình bày lớp cơ bản và một số khía

cạnh liên quan của AspectJ trong ngôn ngữ B 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

Để mô hình hóa và kiểm chứng các hệ thống dựa trên sự kiện, lập trình hướng khía cạnh dựa sự kiện (Event-based Aspect Oriented Programming – EAOP) [3] xác định đan khía cạnh bằng cách phát hiện một chuỗi các sự kiện Phương pháp có thể

sử dụng khía cạnh thay đổi sự kiện thay vì thay đổi từng lớp riêng biệt 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

Event-B [2] là một phương pháp hình thức phù hợp hơn cho việc phát triển lớn

hệ thống phân tán và hệ thống phản hồi Phát triển phần mềm trong Event-B bắt đầu bằng việc mô tả các yêu cầu của hệ thống ở mức trừu tượng và sau đó lại làm mịn chúng thông qua một số bước để đạt được mô tả của hệ thống chi tiết có thể chuyển đổi sang mã nguồn Tính nhất quán của mô hình và mối quan hệ giữa mô hình trừu tượng và mô hình làm mịn lại thu được bằng phương pháp chứng minh hình thức Công cụ hỗ trợ cụ thể cho phương pháp hình thức Event-B là công cụ Rodin

Xuất phát từ yêu cầu mô hình hóa và kiểm chứng EAOP và các ưu điểm của phương pháp hình thức Event-B có ý nghĩa thực tiễn trong quá trình phát triển phần

mềm Dẫn đến sự lựa chọn đề tài luận văn tốt nghiệp của tôi là: “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.”

1.2 Nội dung đề tài

Trong luận văn này, đề xuất một phương pháp dựa trên phân tích một ứng dụng EAOP bằng phương pháp hình thức Event-B Ý tưởng xuất phát từ sự tương đồng giữa cấu trúc sự kiện Event-B và EAOP Đầu tiên, chúng ta xác định các thành phần ứng dụng trong EAOP chuyển đổi sang mô hình Event-B Tiếp theo, chúng tôi đưa

mô hình hóa tiếp cận thực tế bằng cách sử dụng nền tảng Rodin để kiểm chứng thuộc tính chương trình có còn bảo tồn một số tính chất sau khi thực hiện đan chương trình, các ràng buộc khác dựa trên công cụ chứng minh tự động Ưu điểm của cách tiếp cận

này là chương trình bao gồm các khía cạnh, biến và các ràng buộc khác được mô hình hóa dễ dàng bằng những đặc tả logic trong Event–B như bất biến và sự kiện

Do đó, tính đúng đắn của hệ thống có thể được chứng minh bằng phương pháp hình thức Điều đó rất quan trọng cho các nhà phát triển phần mềm phát hiện được các vấn đề ở thời gian thiết kế Hơn nữa, cách tiếp cận gần với thực tế mà chúng tôi có thể triển khai một công cụ theo ý tưởng chính để chuyển đổi mô hình EAOP từ Event–B sang công cụ Rodin tự động 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 khía cạnh Với mong muốn kiểm tra chương trình có còn bảo toàn 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 có cấu trúc như 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ề AOP Sau đó, giới thiệu khái quát cơ bản về 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 hình thức Event-B, mô tả cấu trúc, các thành phần của Event-B 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

Trình bày các định nghĩa được ánh xạ của phương pháp hình thức Event-B, các luật chuyển đổi giữa mô hình chương trình phần mềm hướng khía cạnh dựa sự kiện sang mô hình 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

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 Các đặc điểm của lập trình hướng khía cạnh

Lập trình hướng khía cạnh (Khía cạnh Oriented Programming – AOP) [13] là phương pháp lập trình phát triển trên tư duy tách biệt các mối quan tâm khác nhau thành các mô đun khác AOP là một mô hình lập trình mới mẻ ngăn cách mối quan tâm ở cấp thực hiện Trong quan điểm phát triển phần mềm, AOP cho phép các nhà phát triển áp dụng khía cạnh mà thay đổi hành vi các lớp hoặc đối tượng độc lập của bất kỳ hệ thống phân cấp thừa kế Các phát triển sau đó có thể áp dụng những khía cạnh hoặc trong thời gian chạy hoặc thời gian biên dịch Ở đây, chúng tôi sẽ mô tả yếu tố chính của AOP:

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

Điểm nối 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 [13] 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 khía cạnh mọi thứ đều xoay quanh điểm nối

Điểm nối được phân loại như sau:

 Điểm nối tại các phương thức

 Điểm nối tại hàm khởi tạo (contructor)

 Điểm nối tại điểm truy cập các thuộc tính

 Điểm nối tại điểm điều khiển ngoại lệ: được biểu diễn trong khối điều khiển ngoại lệ

 Điểm nối tại các hành vi

b Hướng cắt (pointcut)

Hướng cắt là cấu trúc chương trình mà nó chọn các điểm nối và ngữ cảnh tại các điểm nối đó [13] Ta có thể khai báo hướng cắt trong một khía cạnh, một lớp hoặc

một giao diện Giống như phương thức, có thể dùng định danh truy cập (public, private) để giới hạn quyền truy cập đến hướng cắt Các hướng cắt có thể có tên hoặc không tên Các hướng cắt không tên cũng giống như các lớp không tên, được định nghĩa tại nơi sử dụng Các hướng cắt được đặt tên thì có thể được tham chiếu từ nhiều nơi khác Bảng ánh xạ giữa các điểm nối được chọn cho các hướng cắt:

Loại điểm nối Cú pháp hướng cắt

Thực hiện phương thức execution(MethodSignature)

Gọi phương thức call(MethodSignature)

Thực hiện hàm khởi tạo execution(ConstructorSignature)

Gọi hàm khởi tạo call(ConstructorSignature)

Khởi tạo lớp staticinitialization(TypeSignature) Đọc thuộc tính get(FieldSignature)

Ghi thuộc tính set(FieldSignature)

Thực hiện điều khiển ngoại lệ execution handler (TypeSignature)

Khởi tạo đối tượng initialization(ConstructorSignature)

Tiền khởi tạo đối tượng preinitialization(ConstructorSignature)

Thực hiện advice adviceexecution ()

c Mã hành vi (advice)

Mã hành vi [13] là mã được thực hiện tại một điểm nối mà được chọn bởi hướng cắt Hay nói cách khác, nếu có hướng cắt là khai báo tên phương thức, thì mã hành

vi là phần thân của phương thức đó Hướng cắt và mã hành vi sẽ hình thành nên các luật đan kết các quan hệ đan xen

Mã hành vi được chia thành 3 loại:

 Before: được thực hiện trước điểm nối

 After: được thực hiện sau điểm nối

 Around: bao quanh sự thực hiện điểm nối, mã hành vi 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 (khía cạnh)

Khía cạnh là phần tử trung tâm của aspectJ, giống như lớp trong Java Khía cạnh chứa mã thể hiện các luật đan kết cho các concern [13] Điểm nối, hướng cắt, mã hành vi được kết hợp trong khía cạnh

Tuy có gần giống các đặc điểm của lớp 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… nhưng, khía cạnh có một số khác biệt cơ bản sau:

 Khía cạnh không thể khởi tạo trực tiếp

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

 Khía cạnh 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)

Thực thi cắt ngang trong AspectJ, là quá trình biên dịch thực thi các quy tắc đan các mô đun cắt ngang vào mô đun chính [13]

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 mã hành vi 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ã khía cạnh

AspectJ cho phép đan xen mã khía cạnh 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 [18]

Đan ở mức mã nguồn (source code weaving), aspectJ sẽ nạp các mã khía cạnh

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ã khía cạnh 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 khía cạnh và 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ã khía cạnh [18]

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

Concern là các yêu cầu cụ thể hay mối quan tâm đặc trưng được xác định để thỏa mãn mục tiêu chung của hệ thống Hệ thống phần mềm là sự gắn kết của tập các concern Ví dụ, hệ thống ngân hàng bao gồm các concern: quản lý khách hàng, quản

lý tài khoản, giao dịch nội ngân hàng, giao dịch ATM, chăm sóc khách hàng, lưu giữ

các thực thể trong hệ thống, xác nhận truy cập dịch vụ, Ngoài ra một phần mềm còn phải đảm bảo khả năng dễ hiểu, dễ bảo hành, dễ duy trì, và dễ phát triển [13]

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

Các concern được phục vụ cho một vài mô đun Ví dụ, logging tác động tới tất cả các mô đun trong hệ thống, authencication tác động tới mô đun có yêu cầu kiểm soát truy cập 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 1 [13] 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

Hình 1: Mô hình ánh xạ từ các concern hệ thống sang các phương pháp

lập trình truyền thống

Trong thiết kế phần mềm cách tốt nhất để đơn giản hóa 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 2 [13] 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

Hình 2: Các mô đun yêu cầu logging đều phải nhúng các đoạn mã để gọi logging API

Đây chính là vấn đề sẽ được giải quyết bằng AOP, sử dụng AOP các mô đun khác không cần chứa đoạn mã gọi logging API Hình 3 [13] chỉ ra cách thức thực hiện mô đun logging dùng AOP có cùng chức năng với cách sử dụng OOP, như được ghi trên hình vẽ, cách thực hiện logging bây giờ chỉ tồn tại trong logging mô đun và logging khía cạnh Các mô đun khác không chứa bất kỳ đoạn mã nào gọi đến logging API Như vậy các yêu cầu đan xen giữa các logging mô đun và các mô đun khác được thực hiện duy nhất trong một mô đun hay logging khía cạnh Với phương pháp

mô đun hóa này bất cứ sự thay đổi yêu cầu nào về logging chỉ ảnh hưởng duy nhất đến logging khía cạnh

Hình 3: Giải quyết các concern hệ thống bằng phương pháp AOP

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

Hình 4 [13] mô tả việc phát triển các hệ thống sử dụng AOP: xác định concern, thực hiện chúng, kết hợp lại để thành hệ thống cuối cùng Cụ thể:

 Phân tích bài toán theo hướng khía cạnh (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

 Xây dựng các chức năng (Concern implementation): thực thi các concern một cách độc lập

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

Hình 4: Các giai đoạn phát triển sử dụng phương pháp AOP 2.1.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.1.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 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.2 Lập trình hướng khía cạnh dựa sự kiện

Nghiên cứu của luận văn về lập trình hướng khía cạnh dựa sự kiện (Event-based Aspect-Oriented Programming - EAOP) [3] có những mục tiêu chính: Nghiên cứu

về các thức mô tả các định nghĩa về khía cạnh Cụ thể hơn, mô hình của chúng tôi có những đặc điểm sau đây

Khía cạnh được thể hiện bằng các sự kiện sinh ra trong quá trình thực hiện chương trình cơ bản Đan khía cạnh được thực hiện trên bộ giám sát thực thi, cho phép phát hiện các dãy sự kiện Để giữ cho mô hình đơn giản và trực quan, chúng ta hãy xem xét một mô hình tuần tự cho các sự kiện đồng bộ: Đầu tiên, ngay sau khi một sự kiện được sinh ra, nó xử lý bởi tất cả các khía cạnh Thứ hai, xử lý các chương trình cơ bản và các khía cạnh tiến hành lần lượt: Chương trình cơ bản và bộ giám sát thực thi là hai đối trình

Một khía cạnh được xác định bởi hai ngôn ngữ khác nhau:

- Ngôn ngữ thực thi cắt ngang, cho phép xác định về điểm, trong đó khía cạnh có thể điều chỉnh các chương trình cơ bản

- Ngôn ngữ hành vi (gọi là "advice" trong aspectJ), cho phép điều chỉnh việc thực hiện các chương trình cơ bản

Ví dụ, khía cạnh bảo mật có thể xác định một thực thi cắt ngang phát hiện dãy bao gồm "yêu cầu" theo sau là "phân bổ dịch vụ" mà gây ra một hành động (ví dụ, một chứng thực)

Hình 5: Kiến trúc của EAOP

Để xác định khía cạnh, mô hình của chúng tôi cung cấp các toán tử cho các thành phần khía cạnh rõ ràng Các toán tử này có thể loại trừ những xung đột gây ra bởi khía cạnh tương tranh với nhau tại crosscuts Ví dụ, khía cạnh bảo mật đã đề cập trước đó và một khía cạnh quản lý trong phân bổ dịch vụ, trong trường hợp này, các khía cạnh bảo mật cần phải được ưu tiên

Hơn nữa, mô hình của chúng tôi cho phép việc ứng dụng các khía cạnh trên các khía cạnh khác Ví dụ, một khía cạnh logging áp dụng khía cạnh bảo mật có thể tạo

ra một bản ghi log cho các quản trị viên hệ thống

EAOP chú ý đến các sự kiện phát sinh ra trong quá trình thực hiện chương trình một cách độc lập với bất kỳ ngôn ngữ lập trình cụ thể nào Tính năng chính của mô hình là khía cạnh có thể xác định một hành động cho một dãy các sự kiện thay vì những điểm đơn lẻ như được mô tả trong mô hình AOP Nó có những đặc điểm chính sau:

 Khía cạnh: được xác định theo các sự kiện sinh ra trong quá trình thực hiện chương trình

 Thực thi cắt ngang: xâu chuỗi các sự kiện, có thể bao gồm các trạng thái điều chỉnh, chúng đượ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 khi thực thi cắt ngang được liên kết hoàn chỉnh thì một hành động liên quan được thực hiện

2.2.1 Công cụ EAOP: Kiến trúc và thực hiện

Công cụ lập trình hướng khía cạnh dựa sự kiện bao gồm 5 thành phần (như hình 5 [3] mô tả): bộ tiền xử lý trước, bộ giám sát thực thi và ba thư viện (sự kiện, khía cạnh, và thành phần của khía cạnh)

a Bộ tiền xử lý trước

Bộ tiền xử lý trước mã nguồn Java của chương trình cơ bản (cũng như các khía cạnh nếu muốn định nghĩa các khía cạnh của khía cạnh) để tạo ra các sự kiện và gọi phương thức nhập vào của bộ giám sát thực thi (ví dụ về công cụ thực thi ở hình 6

[3]) Công cụ này dựa trên các kỹ thuật cổ điển Đầu tiên, một phương thức foo được đóng gói đổi tên thành foo_original Việc chuyển đổi phương thức foo mà thân của

nó tạo ra một phương thức gọi sự kiện, gọi bộ giám sát thực thi, sau đó gọi phương

thức foo_original, tạo ra một phương thức trả về sự kiện, gọi bộ giám sát thực thi trở

lại lời gọi

Hình 6: Ví dụ đơn giản hóa việc thực hiện trong chương trình cơ bản

Các hàm tạo được đóng gói tương tự Tuy nhiên, nó không thể tạo ra một sự kiện ở giai đoạn đầu của một cấu trúc bởi vì lệnh đầu tiên của nó phải là một lời gọi

đến super Vì lý do này hàm tạo được chuyển đổi thành hàm tạo mặc định (tạo cấu

trúc đối tượng) và các phương thức khởi tạo cung cấp các lệnh phát sinh sự kiện

Công cụ này được thực hiện bởi phương tiện chuyển đổi của chương trình Java: Recoder [REC] Recoder đơn giản hoá các công thức chuyển đổi và đảm bảo rằng các biến đổi tạo ra mã Java hợp lệ (tức là, kết quả có thể được biên dịch) Để

điều khiển bộ kiểm tra, công cụ của chúng tôi bao gồm một nền tảng cho việc áp dụng có chọn lọc các chuyển đổi các phương thức, các lớp, và khía cạnh Điều này đạt được việc thực thi được một cách hiệu quả, hợp lý nếu số lượng các điểm thực thi không phải là quá lớn Bên cạnh cơ chế này chúng ta quan tâm đến phép định nghĩa ngôn ngữ khía cạnh và xem xét tính hiệu quả dự trữ cho công việc trong tương lai

b Bộ giám sát thực thi

Bộ giám sát thực thi các sự kiện phát sinh ra trong quá trình thực thi các chương trình cơ bản Nơi truyền các sự kiện tương ứng với thời điểm thực thi hiện thời với tất cả các khía cạnh Với kiến trúc của chúng tôi là một chuỗi: Đầu tiên, khi chương trình cơ bản tạo ra một sự kiện và gọi bộ giám sát thực thi, chương trình cơ bản tạm thời ngừng thực thi Với mỗi một khía cạnh có khả năng phản ứng lại với các sự kiện hiện tại, bộ giám sát thực thi số các lưu lượng giám sát chương trình cơ bản mà tiếp tục thực hiện chương trình cơ bản Thứ hai, màn hình thực thi truyền các

sự kiện hiện tại đến khía cạnh và đợi cho các khía cạnh hoàn thành xử lý trước khi truyền sự kiện này sang một khía cạnh khác Do đó, chúng tôi loại bỏ bất kỳ khả năng tương tranh giữa các bộ giám sát thực thi các khía cạnh giữa các khía cạnh với nhau (Nếu không, ngữ nghĩa của các hệ thống dựa trên sự kiện trở nên rất phức tạp.)

c Sự kiện

Sự kiện là đối tượng biểu diễn cho điểm thực hiện chương trình Java Phiên bản hiện tại của công cụ chúng tôi hỗ trợ bốn loại sự kiện: gọi phương thức và kết thúc sự kiện cũng như gọi hàm tạo và trả về các sự kiện Bốn loại là đủ cho các thử nghiệm hiện tại, nhưng loại mới sẽ được bổ sung khi cần thiết (ví dụ, các sự kiện biểu diễn cho cơ sở dữ liệu hoặc vào trong lệnh rẽ nhánh else) Nền tảng hiện tại đã được chuẩn bị cho các sự kiện như: pha kiểm tra, ví dụ, có thể làm rõ ràng những

dòng điều khiển chương trình và thư viện sự kiện mở rộng một cách dễ dàng Sự kiện

mô tả bản chất của các điểm thực hiện mà còn ngữ cảnh động của chúng Ví dụ, một

sự kiện gọi phương thức có chứa bộ nhận, tên phương thức, giá trị đối số, độ sâu của việc thực hiện trong ngăn xếp và xác định mã hiện đang được thực hiện (trong đó

phân biệt các chương trình cơ bản với khía cạnh) Nó cũng chứa giá trị logic skip

được sử dụng để chỉ ra một gói không phải gọi phương thức gốc (như hình 6 [3] mô tả) Điều này cho phép khía cạnh "thay thế" một phương thức bằng một cách khác, một trường của đối tượng sự kiện (được thiết lập bởi các khía cạnh) định nghĩa các giá trị trả về

Một khía cạnh được định nghĩa bởi sự phân lớp con của lớp Khía cạnh trừu tượng và định nghĩa phương thức definition Phương thức này không áp đặt các ràng buộc về cấu trúc của mã và sử dụng các phương thức nextEvent để có được các sự

kiện Sau đó, phương thức cuối cùng này là ngăn chặn và chờ đợi bộ giám sát thực thi "khởi động dậy" cùng các khía cạnh với các sự kiện Hiện thời, điều này được thực hiện bởi luồng Java và thư viện các đối trình đảm bảo điều độ, tại mỗi thời điểm, chỉ có chương trình cơ bản hoặc bộ giám sát thực thi hoặc một khía cạnh đang hoạt động

e Các thành phần khía cạnh

Nếu sự kiện được truyền tuần tự cho tất cả các khía cạnh, bộ giám sát thực thi

sẽ tương đương là biến lặp qua dãy của khía cạnh Các thành phần Khía cạnh quan trọng mở rộng được đưa ra Có thể hạn chế sự truyền của các sự kiện đến các khía cạnh nhất định, quyết định này là động: bộ giám sát thực thi một cây nhị phân trong

đó khía cạnh là lá và các nút bộ lặp là các toán tử thành phần khía cạnh Bộ giám sát các sự kiện liên tục đến mọi khía cạnh bằng cách thực hiện duyệt cây theo chiều sâu của cây khía cạnh

Hình 7: Cây khía cạnh và sự kiện truyền

Công cụ của chúng tôi hiện thời đề xuất bốn toán tử nhị phân của khía cạnh:

 Seq truyền các sự kiện hiện tại (nút gốc cha) cho con trái trước và sau đó sang

con phải

 Any truyền sự kiện tới 2 con của mình trong một trật tự tùy ý

 Fst truyền sự kiện tới con trái, và nếu như con trái không phát hiện crosscut,

sự kiện này được chuyển đến con phải Mọi khía cạnh và mỗi toán tử thành

phần duy trì một trường logic là isCrosscutting để truyền thông tin này Toán

tử logic được quản lý một cách rõ ràng bởi các lập trình viên trong tất cả các khía cạnh

 Cond truyền sự kiện đến con trái, và nếu như con trái phát hiện crosscut, sự

kiện này được chuyển đến con phải của nó