Luận văn Thạc sĩ Công nghệ thông tin: 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

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

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

1.1

1.2 Nội dung đề tài ........................................................................................ 9

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

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

1.4

CHƯƠNG 2. EAOP VÀ EVENT-B ................................................................................ 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.1 Các đặc điểm của lập trình hướng khía cạnh ........................................ 12

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

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



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 Event-B .................................................................................................. 27



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 KHÍ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

THUẬT NGỮ KHÁI NIỆM

Aspect Oriented Programming – AOP Lập trình hướng khía cạnh

Event-based Khía cạnh Oriented

EAOP Programming – Lập trình hướng khía

cạnh dựa sự kiện

Automatic Teller Machine – Máy ATM rút tiền tự động

Unified Modeling Language – Ngôn UML ngữ mô hình hóa thống nhất

Rigorous Open Development

Enviroment for Complex System - RODIN Công cụ mã nguồn mở dựa trên nền

tảng Eclipse

Object-orented programming – Lập OOP trình hướng đối tượng

Finite State Processes – Quá trình FSP hữu hạn trạng thái

Labelled Transition System Anlyzer LTSA - 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 trò 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 bỏ 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ó cò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ó cò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 trúc luận văn

Các phần cò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

vò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. Quản lý 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 để

thỏ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

cò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

cò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 phải nhúng các đoạn mã để gọ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: Giả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 lõi và concern đan xen. Các

concern lõi được tách ra khỏ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

cò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 cò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

 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 trú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ử lý 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 giản hóa việc thực hiện trong chương trình cơ bả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 bỏ 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

dò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ề.

d. Khía cạnh

Một khía cạnh có thể được xem như là chuyển đổi sự kiện. Trong thực tế, một

khía cạnh là một chương trình Java, nó tạo ra sự kiện bằng tham số và thực hiện một

số tính toán (có thể thay đổi sự kiện), và chờ cho sự kiện tiếp theo. Ví dụ, khía cạnh

bảo mật có thể mã hóa các đối số chứa trong những sự kiện gọi phương thức mà nó

nhận được. Các gói của chương trình cơ bản có trách nhiệm trích xuất các giá trị thay

đổi của các đối số sự kiện trước khi gọi một phương thức gốc. Giá trị trả về của một

lời gọi có thể được lọc bởi một khía cạnh tương tự.

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ó.

Xem xét ví dụ cây khía cạnh trong hình 7 [3], gồm có hai khía cạnh. Trong thời

gian thực hiện chương trình cơ bản, một evt1 sự kiện được phát sinh (bước 1), Sau

đó, bộ giám sát thực thi sự kiện này đến khía cạnh 1 (bước 2) và cuối cùng là đến

khía cạnh 2 (bước 5). Khi khía cạnh 2 chặn lời gọi đến nextEvent, bộ điều khiển

chuyển trở lại chương trình cơ bản.

Tổ hợp mới có thể được phát triển là cần thiết bởi sự phân lớp con của lớp biểu

diễn cho các nút cây nhị phân BinaryKhía cạnhS. Cây khía cạnh có thể được tái cấu

trúc động (đặc biệt là khi một khía cạnh tạo ra một trường hợp mới của một khía

cạnh và chèn nó vào cây hiện tại của các khía cạnh). Sự tồn tại của các nút khác nhau

cũng rất hữu ích để thực hiện các quy tắc cho việc tái cơ cấu động của cây khía cạnh

(ví dụ, Any là toán tử thay thế, Seq là kết hợp).

f. Khía cạnh của khía cạnh

Công cụ EAOP cho phép áp dụng các ứng dụng của khía cạnh cho các khía

cạnh khác. Ở cấp độ thực hiện, vấn đề chính trong trường hợp này bao gồm trong

việc quản lý các lời gọi đệ quy để bộ giám sát thực thi. Khi một khía cạnh được gọi

bởi bộ giám sát thực thi với các sự kiện hiện tại, nó thực thi mã của nó cho đến (chặn)

gọi tới nextEvent. Việc thực hiện các mã này có thể phát ra các sự kiện được truyền

đến bộ giám sát thực thi. Xem xét lại ví dụ thể hiện trong hình 7 [3]: khía cạnh 1

được cung cấp. Do đó, trong quá trình thực hiện, một evt2 sự kiện được phát sinh và

chuyển qua bộ giám sát thực thi (Bước 3), trong đó truyền đến các khía cạnh đã sẵn

sàng sử dụng nó, ở đây chỉ có khía cạnh 2 (bước 4). Khi khía cạnh 2 chặn nextEvent

điều khiển lại khía cạnh 1, nó khôi phục lại thực hiện được mô tả trong phần trước.

Trong thời gian thực thi một khía cạnh, nó không phải là sẵn sàng đón nhận

một sự kiện (tức là, nó không bị chặn nextEvent nhưng đợi sự trả về của các phương

thức trace của bộ giám sát thực thi). Trạng thái này được thực hiện bằng cách sử

dụng giá trị logic isRunning, trong đó với mỗi khía cạnh được quản lý bởi nền tảng

của chúng tôi. Bằng cách này, bộ giám sát thực thi không truyền sự kiện đến các khía

cạnh mà có cờ isRunning là đúng. Điều này đảm bảo rằng sẽ không có vòng lặp

không xác định (ví dụ, một khía cạnh gọi chính nó, hoặc hai khía cạnh gọi nhau).

Điều này không có nghĩa rằng một khía cạnh không thể áp dụng cho chính nó nhưng

nó đòi hỏi tạo ra các trường hợp khác nhau.

Cuối cùng, bộ giám sát tuần tự hóa ứng dụng các khía cạnh và đảm bảo rằng

chính xác một luồng (chương trình cơ bản, bộ giám sát thực thi hay khía cạnh) được

kích hoạt tại từng thời điểm, chương trình cơ bản có thể gồm nhiều luồng. Trong

trường hợp này, phương pháp trace của màn hình phải được đồng bộ hóa

sychronized. Cuối cùng, bộ giám sát thực thi được gọi lại để đối phó với các khía

cạnh của khía cạnh. Để kết luận mô tả này, lưu ý rằng công cụ của chúng tôi không

thực sự cung cấp một ngôn ngữ chuyên dụng cho các định nghĩa của crosscuts [16]

(crosscuts và hành động đều được định nghĩa là mã Java). Tuy nhiên, phương pháp

nextEvent và các toán tử thành phần khía cạnh có thể được xem như là nền tảng cơ

bản cho ngôn ngữ này.

2.3. Event-B

Event-B [2] là một phương pháp hình thức để mô hình hóa và phân tích hệ

thống phân cấp. Event-B sử dụng chủ yếu các ký hiệu toán học, logic mệnh đề, 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ữ cảnh

Các mô hình Event-B [2] được mô tả bởi 2 cấu trúc cơ bản là máy (machines)

và ngữ cảnh (context) được mô tả ở hình 8 [2]. 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].

Hình 8: Cấu trúc máy và ngữ cảnh

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. Mối quan hệ giữa các thành phần của máy và ngữ cảnh được minh

họa hình 9 [2].

Hình 9: Mối quan hệ giữa các thành phần máy và ngữ cảnh

Sau đây, cấu trúc về máy được mô tả chi tiết ở hình 10 [2] là:

Hình 10: Cấu trúc máy chi tiết

Trong đó, hình 10 [2] minh họa những mệnh đề được mô tả trên về máy như sau:

 Refines: gồm các máy mà máy hiện tại tinh chỉnh từ các máy đó.

 Sees: là một danh sách các ngữ cảnh mà máy tham chiếu tới.

 Variables: là một danh sách các biến khác nhau được sử dụng trong máy, các

biến không được trùng tên. Tuy nhiên, không giống như trong ngữ cảnh một

số biến có thể trùng tên với các biến trong máy trừu tượng.

 Invariants: là một danh sách các biểu thức logic toán học khác nhau, được gọi

là các vị từ mà các biến phải thỏa mãn. Mỗi invariants sẽ được gán một nhãn.

 Theorems: có thể được khai báo trong phần Invariants của máy. Tương tự như

trong ngữ cảnh nó là các biểu thức logic toán học nhưng ở trong máy nó không

cần phải chứng minh mà được thể hiện bằng sự kiện.

 Events: gồm danh sách các sự kiện của máy. Một sự kiện tạo ra một hành động

làm thay đổi giá trị của các biến.

Mô tả về cấu trúc ngữ cảnh chi tiết ở hình 11[2] là:

Hình 11: Cấu trúc ngữ cảnh chi tiết

Trong đó, hình 11[2] minh họa những mệnh đề về ngữ cảnh được mô tả như sau:

 Extends: chỉ ra một danh sách các ngữ cảnh mà ngữ cảnh hiện tại mở rộng.

 Sets: chỉ một tập hợp các mô tả trừu tượng và liệt kê các loại, kiểu.

 Constants: là một danh sách các hằng số được đưa vào ngữ cảnh. Hằng số, ngữ

cảnh mà extends từ nó phải có định danh khác nhau.

 Axioms: là một danh sách các vị từ (gọi là tiên đề) của các hằng số trong các

biểu thức logic. Các axioms sẽ được sử dụng làm giả thuyết trong các mệnh

đề chứng minh Pos (Proof obligations).

 Theorems: là một danh sách các biểu thức logic gọi là định lý và cần chứng

minh trong ngữ cảnh.

2.3.2. Sự kiện

Mô hình hệ thống Event-B được bắt đầu từ các sự kiện trừu tượng quan sát

được có thể xảy ra trong hệ thống, từ đó đặc tả các trạng thái và hành vi của hệ thống

ở mức trừu tượng cao hơn. Một sự kiện evt tác động lên (một danh sách) biến trạng

thái v, với điều kiện G (x, v) và hành động A (x, v, v') được mô tả như sau [19]:

evt = any x where G (x, v) then A (x, v, v’)

2.3.3. Phân rã và kết hợp

Một trong những đặc trưng quan trọng nhất của Event-B [2] đó là khả năng bổ

sung các sự kiện mới trong quá trình làm mịn, tuy nhiên khi bổ sung các sự kiện sẽ

làm tăng độ phức tạp của tiến trình làm mịn do phải xử lý nhiều sự kiện và nhiều

biến trạng thái. Ý 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 M1…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ụ

Event-B là phương pháp hình thức phù hợp hơn để phát triển các hệ thống

phân phối và phản ứng. Việc phát triển phần mềm trong Event-B bắt đầu bằng cách

cụ thể hóa những yêu cầu của cả hệ thống và sau đó lọc chúng qua các bước để mô

tả hệ thống một cách chi tiết mà có thể dịch ra thành code. Sự thống nhất của mô

hình và mối quan hệ giữa một mô hình trừu tượng và các bộ lọc của chúng được chỉ

ra bằng các bằng chứng. Công cụ hỗ trợ cũng được cung cấp cụ thể hóa Event-B và

kiểm chứng. Giao diện Rodin GUI [1] minh họa hình 12.

Hình 12: Rodin GUI

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. Trong luận văn này chúng tôi sử dụng bộ công

cụ Rodin để mô hình, làm mịn, sinh và chứng minh tự động các mệnh đề cần chứng

minh để đảm bảo tính đúng đắn của mô hình. Kiến trúc và công cụ được minh họa

hình 13. 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 13: Mô hình kiến trú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 KHÍA CẠNH

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

Trong phần này, giới thiệu phương pháp để mô hình hóa và kiểm chứng ứng

dụng lập trình hướng khía cạnh dựa sự kiện. Đầu tiên, giới thiệu các định nghĩa mới

của các thành phần ứng dụng. Dựa trên các định nghĩa mới, chúng tôi chi tiết hóa các

ứng dụng và tính chất trong ngôn ngữ hướng sự kiện Event-B. Cuối cùng, chúng tôi

kiểm chứng các thuộc tính dựa trên các mệnh đề cần chứng minh.

EAOP là lập trình hướng khía cạnh hệ thống dựa trên các sự kiện thực hiện.

Nếu chương trình ban đầu phát ra một sự kiện hoặc dãy các sự kiện, các thành phần

kiểm tra thực hiện các khía cạnh liên quan. Sau đây, một số định nghĩa:

Định nghĩa 3.1 (chương trình cơ bản). Một chương trình cơ bản gồm 4-tuple

BP=, trong đó E là tập các sự kiện, A là dãy các hành động, V là tập

các thuộc tính của chương trình, C là tập các thuộc tính ràng buộc.

Chúng ta xem chương trình cơ bản như một chương trình 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à thuộc tính mong muốn của các ứng dụng bởi vì nó phải

thỏa mãn một số các điều kiện.

Định nghĩa 3.2 (thực thi cắt ngang). Một thực thi cắt ngang, được xác định

bởi CC E, định nghĩa một dãy của sự kiện biểu diễn những điểm xác định trong

việc thực thi chương trình cơ bản.

Một khía cạnh trong mô hình EAOP bao gồm biến mới và một thực thi cắt

ngang nơi đan mã vào chương trình cơ bản.

Định nghĩa 3.3 (khía cạnh). Một khía cạnh trong mô hình EAOP gồm có

A= trong đó S là tập các mã hành vi liên kết với thực thi cắt ngang CC

và Vr trạng thái biến mới.

Ví dụ: Một ứng dụng EAOP có chứa một khía cạnh thì chuyển một file mã

nguồn đến máy chủ bất cứ khi nào nó được điều chỉnh trong phiên làm việc. Chương

trình được thực hiện với A=<{}, {login → do_login, modify → commit_svn, logout

→ do_logout}>, trong đó login, modify và logout là 3 sự kiện, do_login, commit_svn

và do_logout là 3 mã hành vi tương ứng.

3.2. Mô hình hóa hệ thống EAOP sử dụng Event-B

Dựa trên các định nghĩa ở phần 3.1, phần này trình bày các quy luật chuyển

đổi một ứng dụng lập trình hướng khía cạnh hệ thống hướng sự kiện sang Event-B.

Luật 1: Chương trình cơ bản P = thì được chuyển đổi sang một

máy M trừu tượng Event-B sao cho e E là ánh xạ sự kiện của máy M, hành động

của chương trình cơ bản được mô hình hóa thân của sự kiện Event-B, các biến của

chương trình được chuyển đổi thành biến của máy M, và những ràng buộc của

chương trình thì được mô tả bởi mệnh đề bất biến Event-B.

Luật 2: Khía cạnh được thực hiện khi một dãy sự kiện phát ra bởi chương

trình cơ bản. Chúng tôi mô hình hóa khía cạnh sử dụng cơ chế làm mịn trong Event-

B. Nói cụ thể hơn, mỗi khía cạnh được chuyển đổi thành một máy cụ thể, mà có thể

làm mịn máy trừu tượng (đại diện cho một chương trình cơ bản).

Luật 3: Những mã hành vi được kết hợp với sự kiện trong một khía cạnh thì

được chuyển đổi sang các hành động tương ứng của những sự kiện Event-B.

3.3. Kiểm chứng các thuộc tính hệ thống

Sau khi đặc tả các ứng dụng trong Event-B, chúng tôi khai thác mệnh đề cần

kiểm chứng để kiểm chứng các ràng buộc bên trong.

Bởi vì một khía cạnh có thể thay đổi các biến trong một chương trình cơ bản,

nên nó có thể vi phạm ràng buộc trong chương trình cơ bản. Vì thế chúng tôi cần

phải đảm bảo rằng đan của khía cạnh không làm thay đổi ràng buộc này.

Giả thuyết 1: Với những luật chuyển đổi được đề xuất ở phần 3.2 một khía

cạnh bảo toàn những ràng buộc trong chương trình cơ bản.

Chứng minh: Cho P = là chương trình cơ bản và a =

E, và s là một mã hành vi. →s> là một khía cạnh, trong đó v là một biến mới, e

Cho v là một biến, bắt buộc thỏa mãn các ràng buộc c(v), được điều chỉnh bởi khía

cạnh (cho v’ là v sau khi mở rộng khía cạnh). Chúng ta cần chứng minh rằng, c(v’)

vẫn bảo toàn.

Theo luật 1, e được chuyển đổi thành ev của máy M, cho g(ev) là điều kiện

kích hoạt của sự kiện Event-B, biến v được chuyển đổi trong Event-B thành biến vb.

Chúng ta có bất biến I trong Event-B biểu hiện những ràng buộc của chương trình

cơ bản (i).

Theo luật 2, chúng ta làm mịn máy M’ chứa một sự kiện mịn ev_r với điều

kiện kích hoạt g(ev_r) (ii).

Theo luật 3, được kết hợp giữa mã hành vi của sự kiện ev_r, được chuyển đổi

sang hành động của sự kiện, gán giá trị biến vb thành vb’ (có nghĩa là A(vb,vb’)) (iii).

INV mệnh đề cần chứng minh làm mịn máy M’ được khái quát như sau.

g(ev_r) I(vb) ⊢ I(vb’) (1)

Nếu công thức (1) là đúng cùng với các biến đổi (i), (ii), (iii), chúng ta có thể

kết luận rằng c(v') vẫn bảo toàn.

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

Áp dụng các các lý thuyết đã trình bày về mô hình hóa và kiểm chứng các phần

mềm hướng khía cạnh đã ở trên. Kết quả của quá trình kiểm tra chương trình có còn

bảo toàn một số tính chất sau khi đan chương trình, bảo tồn hệ thống ban đầu không?

Trong phần này, phương pháp thực hiện kiểm chứng chúng tôi được thực hiện

như sau:

Đầu tiên, việc chuyển đổi các yêu cầu của người dùng vào trong một hệ thống

phần mềm bao giờ cũng rất khó khăn, có nhiều phương pháp tiếp cận như lập trình

hướng đối tượng. Ta có một chương trình lập trình hướng đối tượng đã giải quyết

được một số vấn đề nhưng chưa có một phương pháp nào thỏa mãn việc giải quyết

các yêu cầu đan xen ở mức hệ thống một chương trình. Sau khi đan xen các yêu cầu

này được mô tả bằng crosscutting concern vào chương trình ta được mô hình AOP.

Mở rộng các phương pháp AOP bằng cách đan các sự kiện vào chương trình ta

được mô hình EAOP. Trong mô hình EAOP đặt ra có một số ràng buộc phải thỏa

mãn. Các ràng buộc cần phải kiểm tra xem có thỏa mãn hay không?

Từ đây đưa ra các định nghĩa, tập luận nhằm kiểm chứng những ràng buộc này

có thỏa mãn hay không?

Đến thời điểm toàn bộ mô hình bài toán các ràng buộc đều được mô tả bằng

phương pháp thủ công nhưng mong muốn của tôi là làm sao đặc tả các ràng buộc và

kiểm tra nó một cách tự động, nên tôi sử dụng Event-B và ngôn ngữ Event-B để đặc

tả cho các ràng buộc đó. Sau khi tiến hành đặc tả Event–B xong đưa những đặc tả

này vào công cụ Rodin để kiểm tra và chứng minh.

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

Áp dụng 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 dựa sự kiện với máy ATM. Chương trình được thiết kế để xử lý giao dịch

thẻ tín dụng của người dùng với máy ATM có 3 sự kiện: withdraw, deposit và

transfer khi người dùng thực hiện các chức năng rút tiền gửi, gửi tiền gửi hoặc chuyển

tiền gửi từ tài khoản ngân hàng của người dùng. Các tài khoản ngân hàng của người

sử dụng cần phải đáp ứng yêu cầu số dư (balance) trong tài khoản luôn lớn hơn hoặc

bằng không, số tiền muốn rút luôn lớn hơn hoặc bằng không.

Đầu tiên, ta có một chương trình java ứng dụng mô tả máy ATM gồm 3 file:

Transaction.java, Exchange.java, updatetr.ja. Trong đó:

Class transaction mô tả chức năng gửi tiền, rút tiền trên máy ATM được mô

tả như hình 15:

Hình 15: Lớp Transaction

Lớp exchange mô tả chức năng chuyển tiền trên máy ATM được minh họa như

hình 16:

Hình 16: Lớp Exchange

Khía cạnh updatetr mô tả crosscut của chương trình máy ATM được mô tả như

hình 17:

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

Trong chương trình java mô tả máy ATM trên tại lớp Exchange vì một lý do nào

đó người lập trình quên không kiểm tra điều kiện rút tiền là amount < balance mã

vẫn thực hiện rút tiền làm cho số dư tài khoản nhỏ hơn không nếu trường hợp rút tiền

nhiều hơn số dư trong tài khoản amount>balance dẫn đến đặc tả còn thiếu mà vẫn

áp dụng EAOP vào bài toán. Tuân theo các luật, tiến hành mô hình hệ thống hướng

sự kiện Event-B. Rồi kiểm chứng trên công cụ Rodin thì kết quả không chứng minh

được vì điều kiện kích hoạt sự kiện transfer thiếu mệnh đề grd3: amt

kiện transfer được minh họa trong hình 18 như sau:

Hình 18: Sự kiện chuyển tiền gửi trên máy ATM

Kết quả thực hiện soạn thảo trên công cụ Rodin, sinh và kiểm chứng tự động các

mệnh đề cần chứng minh thể hiện sự kiện transfer không kiểm chứng được minh họa

hình 19.

Hình 19: Kết quả minh chứng

Tiến hành sửa đổi lớp Exchange của chương trình java mô tả máy ATM như sau:

Hình 20: Lớp Exchange đã được sửa đổi

Áp dụng EAOP vào bài toán, chúng ta có chương trình cơ bản P = < E, A, V,

C> như sau: E = {withdraw, deposit, transfer}, V = { bal, amount}, trong đó balance

(balance: là số tiền cân bằng trong tài khoản) và amount (số lượng) mà người dùng

muốn rút tiền hoặc gửi tiền, C ={ balance > 0, amount > 0} là trạng thái yêu cầu bắt

buộc, A = { withdraw_act, deposit_act}. Tuân theo luật 1, chúng ta đạt được mô hình

hệ thống hướng sự kiện Event-B như minh họa hình 21 (inv2 và inv3 không những

xác định 2 biến mà còn chắc chắn các ràng buộc của chương trình luôn luôn thỏa

mãn). Có 3 sự kiện trong máy tương ứng với 3 sự kiện của chương trình cơ bản là

withdraw, deposit và transfer.

MACHINE M

VARIABLES

balance amount targetAccount sourceAccount

INVARIANTS

inv1 : balance ∈ ℕ inv2 : amount ∈ ℕ inv3 : balance ≥ 0 inv4 : amount ≥ 0 inv5 : sourceAccount ∈ ℕ inv6 : targetAccount ∈ ℕ

EVENTS

INITIALISATION ≙

STATUS ordinary

BEGIN

act1 : balance ≔ 0 act2 : amount≔0 act3 : targetAccount≔0 act4 : sourceAccount≔0

END

withdraw ≙ STATUS ordinary

WHEN

grd1 : amount < balance

THEN

act1 : balance≔ balance−amount

END

deposit ≙

STATUS ordinary

ANY

amt

WHERE

grd1 : amt ∈ ℕ

THEN

act1 : balance≔balance+ amt

END

transfer ≙ STATUS ordinary

ANY

amt accountNo

WHERE

grd1 : amt∈ℕ grd2 : accountNo ∈ℕ grd3 : amt≤balance

THEN

act1 : balance ≔ balance−amt act2 : targetAccount≔accountNo

END END

Hình 21: Event-B đặc tả của chương trình cơ bản

Chúng ta tạo một khía cạnh để rút tiền gửi nhưng phải mất phí và trả phí cho

người dụng rút tiền lần đầu tiên. Chúng tôi cần thêm 3 biến mới là fee, bonus, và

bFirst để định lại các giá trị tương ứng. Trong trường hợp làm mịn sự kiện

withdraw_c, mã hành vi bổ sung balance được chuyển đổi thành act1. Sử dụng ProB

[6], một công cụ kiểm tra mô hình Event-B, chúng tôi tìm ra một ví dụ khi chứng

minh biến balance ∈ ℕ. Điều này có nghĩa là vi phạm ràng buộc của chương trình

cơ bản. Để làm cho mô hình chính xác, chúng tôi bổ sung điều kiện kích hoạt của sự

kiện withdraw_c bằng cách thêm vào một mệnh đề nữa grd3: bonus > fee chỉ ra rằng

bonus lớn hơn fee khía cạnh cần kiểm tra điều kiện này trong mã hành vi. Sự kiện

mở rộng withdraw_c rút tiền trên máy ATM được đặc tả Event-B của khía cạnh mô

tả hình 22 như sau:

withdraw_c ≙

extended

STATUS

ordinary

REFINES

withdraw

WHEN

grd1 : amount < balance grd2 : bFirst=TRUE grd3 : bonus>fee

THEN

act1 : balance≔balance−amount−fee+bonus

END

Hình 22: Đặc tả Event-B của khía cạnh

Hình 23 minh họa kết quả thực hiện soạn thảo trên công cụ Rodin, sinh và

kiểm chứng tự động các mệnh đề cần chứng minh.

Hình 23: Kết quả thực hiện

Hình 24 minh họa kết quả của quá trình mô hình hóa và kiểm chứng tự động

được thể hiện qua bảng Statistics, cho thấy toàn bộ các ràng buộc được chứng minh

đảm bảo đã đặt ra.

Hình 24: Kết quả bảng Statistics

KẾT LUẬN

Những đóng góp chính của kết quả luận văn trong việc “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”, kết quả cụ thể như sau:

 Luận văn đã trình bày những kiến thức cơ sở liên quan đến việc bài toán kiểm

chứng phần mềm cụ thể là: Lập trình hướng khía cạnh (Aspect Oriented

Programming – AOP), lập trình hướng khía cạnh dựa sự kiện (Event-based

Aspect Oriented Programming – EAOP) và Event-B.

 Luận văn đã trình bày về công cụ hỗ trợ Rodin, công cụ hỗ trợ cho phương

pháp hình thức Event-B.

 Luận văn đã trình bày các quy luật mô hình hóa một ứng dụng lập trình hướng

cạnh hệ thống hướng sự kiện dùng Event-B.

 Luận văn đã trình bày mô hình hóa cách tiếp cận thực tế bằng sử dụng công

cụ Rodin để kiểm chứng thuộc tính chương trình có còn bảo tồn một số thuộc

tính 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 được mô hình hóa dễ dàng bằng đặc tả

logic trong Event–B như invariants và events. 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. Hơn nữa, cách

tiếp cận của luận văn là gần với thực tế, có thể triển khai công cụ theo ý tưởng

chính để chuyển đổi mô hình EAOP từ Event–B sang công cụ Rodin là tự

động.

 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.

Lập trình hướng khía cạnh dựa sự kiện là một phương pháp tiếp cận mở rộng cho

lập trình hướng khía cạnh. Lập trình hướng khía cạnh dựa sự kiện kết hợp ưu điểm

của cả hai lập trình hướng khía cạnh và kiến trúc dựa trên sự kiện. Đề xuất phương

pháp, chuyển đổi một chương trình lập trình hướng khía cạnh dựa sự kiện sang ngôn

ngữ đặc tả Event-B. Sử dụng Event-B để sinh các mệnh đề cần chứng minh để kiểm

tra lại những ứng dụng ràng buộc ảnh hưởng bởi khía cạnh.

Do thời gian nghiên cứu cũng như lượng kiến thức có được, nên còn một số vấn

đề mà luận văn phải tiếp tục hoàn thiện và phát triển trong thời gian tới như:

 Tiếp tục phát triển cần phải mở rộng cùng với crosscuts phức tạp hơn vào mô

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

 Phát triển các thử nghiệm cần được tiến hành để đánh giá chính xác những lợi

ích và hạn chế của phương pháp tiếp cận.

TÀI LIỆU THAM KHẢO

[1]. Event-B and the Rodin platform. http://www.event-b.org, 2012. [2]. J.R. Abrial. Modeling in Event-B: System and software engineering. Cambridge

University Press, New York, NY, USA 1st edition, 2010.

[3]. R. Douence and M. Sudholt. A model and a tool for event-based aspect-oriented programming (eaop). Technical Report TR 02/11/INFO. Ecole des Mines de Nantes, 2002.

[4]. L. Guan, X. Li, and H. Hu. A petri net-based approach for supporting khía cạnh oriented modeling. In Theoretical Apects of Software Engineering, 2008, pages 83-90, June 2008.

[5]. Holzer, L. Ziarek, K. Jayaram, and P. Eugster. Putting events in context: Khía cạnhs for event-based distributed programming. In Proceedings of the Tenth International Conference on Aspects-oriented Software Development, AOSD '11, pages 241-252, New York, NY, USA, 2011. ACM.

[6]. O. Ligot, J. Bendisposto, and M. Leuschel. Debugging event-b models using the

prob disprover plug-in. Proceedings AFADL'07, Juni 2007.

[7]. T. N. Thuan and N. V. Ha. Using b to verify the weaving of aspects. In Software Engineering Conference, 2007. APSEC 2007. 14th Asia-Pacifc, pages 199-205, Dec 2007.

[8]. N. Ubayashi and T. Tamai. Khía cạnh-oriented programming with model checking. In Proceedings of the 1st international conference on Aspect-oriented software development, AOSD '02, pages 148-154, New York, NY, USA, 2002. ACM.

[9]. D.-X. Xu, O. El-Ariss, W.-F. Xu, and L.-Z. Wang. Aspect-oriented modeling and verification with fnite state machines. J. Comput. Sci. Technol., 24(5):949- 961, Sept. 2009.

[10]. J. Zhang, Y. Chen, and G. Liu. Modeling Aspect-oriented programming with uml profile. In Education Technology and Computer Science, 2009. ETCS '09. First International Workshop on, volume 2, pages 242-245, March 2009. [11]. Anh-Hoang Truong, Phuc Dinh Nguyen, Tuyen Luu, Checking

implementations of UML 2.0 sequence diagrams.

[12]. Joseph D. Gradecki, Nicholas Lesiecki, Mastering AspectJ Aspects-Oriented

Programming in Java - Wiley, 1 edition (March 7, 2003).

[13]. Ramnivas Landdad. AspectJ in Action practical aspect-oriented

programming. Manning publishing -2004.

[14]. Visser W, et.al, Model Checking Programs, 15th IEEE International

Conference on Automated Software Engineering, 2000

[15]. R. Douence, P.Fradet, and M. Sudholt. A framework for the detection and resolution of aspect interactions. In Proc. of the ACM SIGPLAN/SIGSOFT Conf. on Generative Programming and Component Engineering (GPCE), October 2002.

[16]. R. Douence, O. Motelet, and M. Sudholt. A formal definition of crosscuts. In Proc. of the 3rd Int. Conf. on Metalevel Architectures and Separation of Crosscutting Concerns, volume 2192 of LNCS. Springer Verlag, September 2001

[17]. Trịnh Thanh Bình, Trương Anh Hoàng, Nguyễn Việt Hà, Kiểm chứng giao thức tương tác giữa các thành phần trong chương trình đa luồng sử dụng lập trình hướng khía cạnh, Chuyên san Các công trình nghiên cứu, phát triển và ứng dụng CNTT-TT, Tạp chí Công nghệ thông tin & Truyền thông, T. V-1, S. 4 (24), 36-45, 2010.

[18]. Trịnh Thanh Bình, Trương Ninh Thuận, Nguyễn Việt Hà, Kiểm chứng sự tuân thủ về ràng buộc thời gian trong các ứng dụng phần mềm, Tạp chí Tin học và Điều khiển học, T. 26, S. 2, 173-184, 2010.

[19]. Trịnh Thanh Bình (2011). Kiểm chứng các thành phần Java tương tranh. Luận

án tiến sỹ, Trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội, tr. 6,7.

PHỤ LỤC

Chương trình đặc tả Event-B của chương trình cơ bản máy ATM.

MACHINE M

VARIABLES

balance amount targetAccount sourceAccount

INVARIANTS

inv1 : balance ∈ ℕ inv2 : amount ∈ ℕ inv3 : balance ≥ 0 inv4 : amount ≥ 0 inv5 : sourceAccount ∈ ℕ inv6 : targetAccount ∈ ℕ

EVENTS

INITIALISATION ≙

STATUS ordinary

BEGIN

act1 : balance ≔ 0 act2 : amount≔0 act3 : targetAccount≔0 act4 : sourceAccount≔0

END

withdraw ≙ STATUS ordinary

WHEN

grd1 : amount < balance

THEN

act1 : balance≔ balance−amount

END

deposit ≙

STATUS ordinary

ANY

amt

WHERE

grd1 : amt ∈ ℕ

THEN

act1 : balance≔balance+ amt

END

transfer ≙ STATUS ordinary

ANY

amt accountNo

WHERE

grd1 : amt∈ℕ grd2 : accountNo ∈ℕ grd3 : amt≤balance

THEN

act1 : balance ≔ balance−amt act2 : targetAccount≔accountNo

END END

Chương trình đặc tả Event-B của khía cạnh trên máy ATM.

MACHINE M1 REFINES M

VARIABLES

balance amount targetAccount sourceAccount fee bonus bFirst

INVARIANTS

inv1 : fee ∈ ℕ inv2 : bonus ∈ ℕ inv3 : bFirst∈ BOOL

EVENTS

INITIALISATION ≙

extended STATUS ordinary

BEGIN

act1 : balance ≔ 0 act2 : amount≔0 act3 : targetAccount≔0 act4 : sourceAccount≔0 act5 : fee ≔ 0 act6 : bonus ≔ 0