1. Trang chủ
  2. » Luận Văn - Báo Cáo

Kiểm chứng một số ràng buộc trong chương trình java sử dụng AOP

40 509 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 40
Dung lượng 1,54 MB

Nội dung

1.2 Mục tiêu Luận văn đặt ra mục tiêu là nghiên cứu về một số kĩ thuật kiểm chứng phần mềm từ đó đề xuất cách tiếp cận kiểm chứng các biểu thức tiền-hậu điều kiện và các xác nhận của kị

Trang 1

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

Trang 2

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

Trang 3

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi Các kết quả trình bày trong luận văn là hoàn toàn trung thực, chưa được công bố trong bất kỳ công trình nào khác

Tôi xin cam đoan các trích dẫn tài liệu tham khảo trong luận văn đều đã được ghi rõ nguồn gốc

Hà Nội, ngày 10 tháng 9 năm 2015

TÁC GIẢ

Lê Ngọc Minh

Trang 4

LỜI CẢM ƠN

Trong quá trình thực hiện đề tài, tôi đã gặp rất nhiều khó khăn và bỡ ngỡ Nếu không có sự giúp đỡ, động viên chân thành của các thầy cô và bạn bè đồng nghiệp

có lẽ tôi khó có thể hoàn thành tốt luận văn này

Trước hết tôi xin tỏ lòng biết ơn sâu sắc đến TS Trịnh Thanh Bình đã tận tình hướng dẫn trong suốt quá trình viết luận văn

Tôi xin trân trọng cảm ơn quý Thầy, Cô và bạn bè 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 truyền đạt kiến thức, sát cánh và trải nghiệm cùng tôi trong suốt những năm học tập tại đây Với vốn kiến thức được tiếp thu trong quá trình học là nền tảng cho quá trình nghiên cứu luận văn

Tôi xin trân trọng cảm ơn Đảng ủy, Ban Giám hiệu, Ban chủ nhiệm khoa Công nghệ thông tin trường Đại học Hải Phòng đã tạo điều kiện cho tôi trong suốt quá trình học tập và làm luận văn này

Cuối cùng tôi gửi lời cảm ơn đến vợ con, gia đình đã động viên giúp đỡ tôi trong những lúc khó khăn trong công tác và học tập

Xin trân trọng cảm ơn!

Trang 5

DANH MỤC CÁC BẢNG

2.1 Ánh xạ giữa các loại join point và pointcut tương ứng 8 2.2 Ví dụ về một khía cạnh với mã hành vi trước và sau 9

3.1 Đặc tả kịch bản mô tả chức năng rút tiền tự động của máy

ATM

14

4.1 Cài đặt chương trình cho kịch bản kiểm tra các assertion 23 4.2 Cài đặt kịch bản mô tả chức năng rút tiền từ tài khoản 24 4.3 Cài đặt kịch bản mô tả chức năng chuyển khoản 28 4.4 Kết quả kiểm chứng cho kịch bản 4 30

Trang 6

3.1 Phương pháp kiểm chứng ràng buộc của kịch bản trong

chương trình Java sử dụng AOP

15

4.1 Giao diện chính của chương trình 20

4.3 Kết quả kiểm chứng kịch bản 1 vi phạm đặc tả 22 4.4 Kết quả kiểm chứng kịch bản 1 không vi phạm 22 4.5 là kết quả kiểm tra các assertion cho kịch bản được cài đặt sai 24 4.6 Kết quả kiểm tra các assertion cho kịch bản cài đặt đúng 24 4.7 Mô tả tạo Aspect với bài toán rút tiền đơn giản 27

Trang 7

DANH MỤC CÁC TỪ VIẾT TẮT

Trang 8

Mục Lục

LỜI CAM ĐOAN iii

LỜI CẢM ƠN iv

DANH MỤC CÁC BẢNG v

DANH MỤC CÁC HÌNH vi

DANH MỤC CÁC TỪ VIẾT TẮT vii

CHƯƠNG 1 GIỚI THIỆU 1

1.1 Đặt vấn đề 1

1.2 Mục tiêu 2

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

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

CHƯƠNG 2 KIẾN THỨC CƠ SỞ 4

2.1 Kiểm chứng phần mềm 4

2.2 Phương pháp lập trình hướng khía cạnh 5

2.2.1 Thực thi cắt ngang 6

2.2.2.Điểm nối 6

2.2.3 Hướng cắt (pointcut) 7

2.2.4 Mã hành vi 8

2.4.5 Khía cạnh 9

2.3 Ngôn ngữ mô hình hóa JML (Java modeling language) 10

2.4 Kết luận 11

CHƯƠNG 3: KIỂM CHỨNG MỘT SỐ RÀNG BUỘC CHƯỜNG TRÌNH JAVA SỬ DỤNG AOP 12

3.1 Giới thiệu 12

3.2 Bài toán 12

3.3 Phương pháp kiểm chứng sử dụng AOP 13

3.3.1 Sinh mã aspect từ đặc tả JML 14

3.3.2 Đan xen mã 16

CHƯƠNG 4 CHƯƠNG TRÌNH THỰC NGHIỆM 17

4.1 Chức năng đã cài đặt 17

4.2 Công cụ và môi trường xây dựng chương trình thực nghiệm 17

4.2.1 JDK 17

Trang 9

4.2.2 Netbean IDE 17

4.2.3 AJDT 17

4.3 Thực nghiệm 18

4.5 Kết luận 28

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

5.1 Kết quả đạt được 29

5.2 Hướng phát triển 29

TÀI LIỆU THAM KHẢO 29

Trang 10

CHƯƠNG 1 GIỚI THIỆU 1.1 Đặt vấn đề

Phân tích và đặc tả yêu cầu đóng vai trò quan trọng trong quá trình xây dựng và phát triển phần mềm Các yêu cầu phần mềm thường được đặc tả dưới dạng các

ca sử dụng (use case-UC) mô tả toàn bộ sự tương tác giữa người dùng và hệ thống Trong mỗi tài liệu đặc tả, mô hình UC biểu diễn kịch bản mô tả các bước

mà hệ thống cần tuân thủ để thực hiện một nhiệm vụ Một kịch bản thường gồm các thành phần như : sự kiện, sự tương tác giữa các sự kiện, các biểu thức tiền điều kiện (precondition) và hậu điều kiện (postcondition), xác nhận (assertion) Trong đó, tiền điều kiện và hậu điều kiện định nghĩa các ràng buộc mà kịch bản buộc phải thỏa mãn khi bắt đầu và kết thúc thực thi một nhiệm vụ, assertion đặc

tả một thuộc tính mà kịch bản phải thoả mãn tại một thời điểm nào đó Cuối cùng, kịch bản sẽ được được cài đặt bởi các đoạn mã nguồn chương trình Hình 1.1 biểu diễn một kịch bản ở mức mã nguồn thực hiện phép chia hai số nguyên dương, với biểu thức tiền điều kiện là y khác không và hậu điều kiện là kết quả của phép chia x cho y

Hình 1.1 Kịch bản biểu diễn phép chia hai số nguyên

Việc kiểm tra tính đúng đắn của một kịch bản bao gồm kiểm tra các biểu thức tiền-hậu điều kiện và các assertion có thể thực hiện ở các giai đoạn đặc tả hoặc

mã nguồn chương trình Hiện nay, đã có một vài phương pháp khác nhau được

đề xuất nhằm kiểm tra tính đúng đắn của kịch bản tại các giai đoạn thiết kế và

mã nguồn chương trình như các phương pháp kiểm chứng[1], kiểm thử[4] Mỗi phương pháp đều có những ưu và nhược điểm nhất định Các phương pháp kiểm thử yêu cầu phải có mã nguồn và các ca kiểm thử (test case) thường chỉ phát hiện được các lỗi về giá trị đầu ra (output) nhưng không phát hiện được các lỗi

vi phạm ràng buộc thiết kế Trong khi đó, một vi phạm ràng buộc thiết kế có thể gây ra lỗi hệ thống, đặc biệt khi tích hợp nhiều môđun thì việc xác định chính xác vị trí gây lỗi sẽ rất khó khăn làm cho chi phí phát triển tăng cao [1] Các phương pháp kiểm chứng như chứng minh định lý (theorem proving)[5] và kiểm

Trang 11

chứng mô hình (model checking) [3] đã được ứng dụng thành công để kiểm chứng bản thiết kế phần mềm nhằm phát hiện sớm những lỗi tiềm ẩn, giảm thời gian và chi phí phát triển Ngược lại, các phương pháp kiểm chứng tại mức mã nguồn nhằm kiểm tra sự tuân thủ giữa bản thiết kế và cài đặt của phần mềm

1.2 Mục tiêu

Luận văn đặt ra mục tiêu là nghiên cứu về một số kĩ thuật kiểm chứng phần mềm từ đó đề xuất cách tiếp cận kiểm chứng các biểu thức tiền-hậu điều kiện và các xác nhận của kịch bản tại mức mã nguồn sử dụng phương pháp lập trình hướng khía cạnh (Aspect oriented programming-AOP) Các mục tiêu cụ thể cần đạt được là:

 Khảo cứu một số phương pháp kiểm chứng chương trình; mô hình ca sử dụng trong phân tích thiết kế và đặc tả yêu cầu phần mềm; phương pháp lập trình hướng khía cạnh; ngôn ngữ mô hình hoá JML (Java modeling language);

 Đề xuất một cách tiếp cận để kiểm chứng các biểu thức tiền-hậu điều kiện

và xác nhận của kịch bản sử dụng phương pháp lập trình hướng khía cạnh;

 Xây dựng và thử nghiệm thành công công cụ kiểm chứng một số ràng buộc của kịch bản tại mức mã nguồn chương trình

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

Đóng góp chính của luận văn là đề xuất và xây dựng thành công một công cụ kiểm chứng một số ràng buộc của một kịch bản tại thời điểm thực thi (mức mã nguồn) Các kết quả chính như sau:

 Tìm hiểu và trình bày một số phương pháp kiểm chứng, kiểm thử phần mềm; phương pháp lập trình hướng khía cạnh với Java (AspectJ); ngôn ngữ mô hình hóa JML;

 Đề xuất và xây dựng thành công một công cụ để kiểm tra một số ràng buộc kịch bản tại thời điểm thực thi, áp dụng cho các kịch bản được cài đặt trên ngôn ngữ lập trình Java

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

Luận văn gồm 4 chương chính được cấu trúc như sau:

 Chương 1: Giới thiệu bài toán kiểm chứng một số ràng buộc của kịch bản, mục tiêu và các đóng góp của luận văn;

 Chương 2: Trình bày một số kiến thức cơ sở cho mục tiêu nghiên cứu và các đóng góp của luận văn;

Trang 12

 Chương 3: Đề xuất phương pháp kiểm chứng một số ràng buộc của kịch bản trong chương trình Java;

 Chương 4: Giới thiệu chương trình thực nghiệm và các đóng góp,

 Chương 5: Kết luận và hướng phát triển của luận văn

Trang 13

CHƯƠNG 2 KIẾN THỨC CƠ SỞ

Trong chương này luận văn trình bày một số kiến thức nền về kiểm chứng phần mềm tại thời điểm thực thi, phương pháp lập trình hướng khía cạnh, ngôn ngữ

mô hình hóa JML Đây là các kiến thức cơ sở được sử dụng cho các đóng góp của luận văn trong chương 3 và chương 4

2.1 Kiểm chứng phần mềm

Kiểm chứng phần mềm (software verification) là tập các nguyên lý, phương pháp và công cụ nhằm bảo đảm tính đúng đắn của phần mềm, trong mục này luận văn trình bày hai phương pháp kiểm chứng phần mềm là kiểm chứng hình thức và kiểm chứng tại thời điểm thực thi chương trình

là hàm gán nhãn với AP là tập hữu hạn các mệnh đề nguyên tử được xây dựng từ hệ thống

Một bộ kiểm chứng mô hình (model checker ) sẽ kiểm tra tất cả các trạng thái có thể có của mô hình để tìm ra tất cả các đường thực thi có thể gây ra lỗi Do đó không gian trạng thái thường là vô cùng lớn nếu không muốn nói là vô hạn Vì vậy việc phải duyệt qua tất cả các trạng thái là bất khả thi Để đối phó với bài toán bùng nổ không gian trạng thái đã có một vài nghiên cứu liên quan đến các

kỹ thuật làm giảm không gian trạng thái như Abstraction, Slicing

2.1.2 Chứng minh định lý

Phương pháp chứng minh định lý (theorem proving) [5] sử dụng các kĩ thuật suy luận để chứng minh tính đúng đắn của một công thức hay tính khả thỏa của một công thức F với tất cả các mô hình, ký hiệu |= F Một hệ chứng minh bao gồm các luật suy diễn bao gồm các tiên đề, định lý Một hệ thống được gọi là đúng (sound) nếu tất cả các định lý của nó đều được chứng minh

2.1.3 Kiểm chứng tại thời điểm thực thi

Kiểm chứng tại thời điểm thực thi (runtime verification)[1] là kĩ thuật kết hợp giữa kiểm chứng hình thức và thực thi chương trình nhằm phát hiện các lỗi của

hệ thống dựa trên quá trình quan sát đầu vào (input), đầu ra (output) trong khi thực thi chương trình, các giá trị đầu ra được quan sát để kiểm tra tính thỏa được

so với đặc tả yêu cầu phần mềm So với phương pháp kiểm chứng tĩnh thì kiểm

Trang 14

chứng tại thời điểm thực thi được thực hiện trong khi chạy chương trình Phương pháp này thường được sử dụng để kiểm tra sự tuân thủ giữa bản thiết kế

và sự cài đặt của nó áp dụng cho các ngôn ngữ lập trình cụ thể, điển hình là Java với các công cụ kiểm chứng như JPF [8,15], JLO, ESC/Java, Một số ưu điểm của phương pháp kiểm chứng tại thời điểm thực thi[14] như sau:

- Có thể bảo đảm tính đúng đắn giữa sự cài đặt phần mềm sơ với bản thiết

kế của nó;

- Nhiều thông tin chỉ có sẵn hoặc phụ thuộc vào môi trường khi nó được thực thi;

- Với các hệ thống an toàn và bảo mật cao đòi hỏi phải được kiểm chứng tại

tấ cả các giai đoạn trong quá trình phát triển

2.2 Phương pháp lập trình hướng khía cạnh

Phương pháp lập trình hướng khía cạnh (Aspect-Oriented Programming) [8,12]

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 nhau Ở đây, một mối quan tâm thường không phải

là một chức năng nghiệp vụ cụ thể và có thể được đóng gói mà là một khía cạnh (thuộc tính) chung mà nhiều môđun phần mềm trong cùng hệ thống nên có, ví

dụ như lưu vết thao tác và lỗi (error logging) Với AOP, chúng ta có thể cài đặt các mối quan tâm chung cắt ngang hệ thống bằng các môđun đặc biệt gọi là khía cạnh (aspect) thay vì dàn trải chúng trên các môđun nghiệp vụ liên quan Các khía cạnh sau đó được kết hợp tự động với các môđun nghiệp vụ khác bằng quá trình gọi là đan (weaving) bằng bộ biên dịch đặc biệt Các ưu điểm của phương pháp AOP được tóm tắt như sau[8,12]:

- Mô-đun hóa những vấn đề đan xen nhau: AOP xác định vấn đề một cách riêng biệt, cho phép mô-đun hóa những vấn đề liên quan đến nhiều lớp đối tượng

- Tái sử dụng mã nguồn tốt hơn: Các aspect là những mô-đun riêng biệt, được kết hợp linh động – đây chính là yếu tố quan trọng để tái sử dụng

mã nguồn

- Cho phép mở rộng hệ thống dễ dàng hơn: Một thiết kế tốt phải tính đến

cả những yêu cầu hiện tại và tương lai, việc xác định các yêu cầu trong tương lai là một công việc khó khăn Nhưng nếu bỏ qua các yêu cầu trong tương lai, có thể bạn sẽ phải thay đổi hay thực hiện lại nhiều phần của hệ thống Với AOP, người thiết kế hệ thống có thể để lại quyết định thiết kế cho những yêu cầu trong tương lai nhờ thực hiện các aspect riêng biệt AspectJ [12] là một phương pháp lập trình AOP áp dụng cho ngôn ngữ Java Trình biên dịch AspectJ sẽ đan xen chương trình Java chính với các khía cạnh thành các tệp mã bytecode chạy trên chính máy ảo Java Trong các mục tiếp theo của luận văn, tôi trình bày một số khái niệm liên quan trong AspectJ được

Trang 15

sử dụng để sinh mã kiểm chứng kịch bản với các ràng buộc về biểu thức tiền và hậu điều kiện và các assertion

2.2.1 Thực thi cắt ngang

Trong AspectJ, quá trình trình biên dịch thực thi các quy tắc đan để đan kết các môđun cắt ngang vào môđun nghiệp vụ chính được gọi là thực thi cắt ngang (crosscutting) AspectJ định nghĩa hai loại thực thi cắt ngang là thực thi cắt ngang động và thực thi cắt ngang tĩnh:

 Thực thi cắt ngang động (dynamic crosscutting) là việc đan các 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 và chèn thêm hoặc thay thế luồng thực thi chương trình chính bằng môđun cắt ngang, từ đó làm thay đổi hành vi của hệ thống Hầu hết việc thực thi cắt ngang trong AspectJ đều là thực thi cắt ngang động

 Thực thi cắt ngang 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 hệ thống Chức năng chính của thực thi cắt ngang tĩnh là hỗ trợ cho thực thi cắt ngang động Ví dụ như thêm dữ liệu và phương thức mới vào lớp đã có nhằm định nghĩa trạng thái và hành vi của lớp đó để sử dụng trong các hành vi cắt ngang động Thực thi cắt ngang tĩnh còn được sử dụng nhằm khai báo các cảnh báo và lỗi tại thời điểm biên dịch cho nhiều môđun

Trong AOP, mỗi khía cạnh được coi là biểu diễn của một quy tắc đan, nó chỉ ra môđun cần được đan, vị trí đan trong môđun đó, hành vi sẽ được đan vào thông qua các định nghĩa của điểm nối, hướng cắt và mã hành vi

2.2.2.Điểm nối

Điểm nối (joinpoint) là một điểm có thể xác định trong quá trình thực thi một chương trình, điểm này chính là vị trí mà các hành động thực thi cắt ngang được đan vào Trong AspectJ có một số loại điểm nối được chia thành hai loại thực thi và triệu hồi phương thức sau

 Điểm nối thực thi phương thức (method execution joinpoint): điểm này nằm trên chính phần thân của phương thức thực thi, nó gồm toàn bộ các lệnh nằm trong thân phương thức,

 Điểm nối triệu gọi phương thức (method call joinpoint): điểm này nằm trên phần chương trình gọi phương thức đang xét, nó chính là điểm mà phương thức đang xét được gọi

Trang 16

Hình 2.1 Điểm nối thực thi và triệu gọi phương thức

2.2.3 Hướng cắt (pointcut)

Trong AspectJ, điểm nối thường được sử dụng trong một hướng cắt (pointcut), mỗi hướng cắt chứa một nhóm các điểm nối cùng với ngữ cảnh của nó 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ể sử 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, 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

Cú pháp khai báo hướng cắt như trong sau [12] [15]

[access specifier] pointcut pointcut-name([args]):

pointcut-definition

Ví dụ: pointcut callSayHello(): call(* *.sayHello());

Trong đó [access specifier] khai báo định danh truy cập có thể là public hoặc private, [pointcut name] khai báo tên của hướng cắt, [args] khai báo các tham số, cuối cùng [pointcut-definition]là định nghĩa hướng cắt

Bảng 2.1 Ánh xạ giữa các loại join point và pointcut tương ứng

Cú pháp pointcut Loại join point

execution(ConstructorSignature) Thực hiện hàm dựng

Trang 17

call(ConstructorSignature) Gọi hàm dựng

staticinitialization(TypeSignatur

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

initialization(ConstructorSignatu

preinitialization(ConstructorSign

2.2.4 Mã hành vi

Mã hành vi (advice) là đoạn mã định nghĩa hành vi được đan vào mã nguồn tại điểm điểm nối [12][15] Mã hành vi được thực thi trước (before advice), sau ({after advice}), hoặc xung quanh (around advice) một điểm nối Mã hành vi có thể được sử dụng để đưa ra thông báo trước khi đoạn mã tại điểm nối được thực thi lưu vết hoặc kiểm tra lỗi Trong AspectJ định nghĩa ba loại mã hành vi sau

 Mã hành vi trước là loại mã được thực thi trước các điểm nối,

 Mã hành vi sau là loại mã được thực thi ngay sau các điểm nối,

 Mã hành vi xung quanh là loại mã mạnh nhất, nó bao gồm cả mã hành vi trước và sau Mã hành vi xung quanh có thể chỉnh sửa đoạn mã tại điểm nối, nó có thể thay thế, thậm chí bỏ qua sự thực thi của điểm nối đó Mã hành vi xung quanh phải khai báo giá trị trả về cùng kiểu với kiểu trả về của điểm nối Trong mã hành vi xung quanh, sự thực thi của điểm nối được thể hiện thông qua proceed() Nếu trong mã hành vi không gọi proceed() thì sự thực thi của điểm nối sẽ bị bỏ qua

Bảng 2.2 biểu diễn một khía cạnh với mã hành vi trước và sau Như vậy điểm nối và mã hành vi kết hợp với nhau tạo nên quy tắc thực thi cắt ngang động: hướng cắt xác định các điểm cắt cần thiết còn mã hành vi cung cấp các hành động sẽ xảy ra tại điểm nối đó

Bảng 2.2 Ví dụ về một khía cạnh với mã hành vi trước và sau

Giả sử có pointcut được khai báo như sau

*.tong(int,int))

Trang 18

Ta có thể xây dựng các advice như sau:

- Before advice thực hiện lưu vết

 Có thể sử dụng các định danh phạm vi truy cập ({public, private, protect}) cho nó Ngoài ra khía cạnh còn có thể có định danh phạm vi truy cập

“privileged”, định danh này cho phép khía cạnh có thể truy cập đến các thành viên riêng của các lớp mà chúng cắt ngang,

 Có thể khai báo khía cạnh trừu tượng bằng từ khóa abstract,

 Khía cạnh không thể được thể hiện hóa trực tiếp,

 Khía cạnh có thể kế thừa các lớp và các khía cạnh trừu tượng khác, có thể thực thi các giao diện nhưng không thể kế thừa từ các khía cạnh cụ thể (không trừu tượng),

 Khía cạnh có thể nằm trong các lớp và các giao diện

Bảng 2.3 Cấu trúc cơ bản của một khía cạnh

[access specification] aspect <AspectName>

Trang 19

2.3 Ngôn ngữ mô hình hóa JML (Java modeling language)

JML (Java Modeling Language)[7][10] là ngôn ngữ đặc tả hành vi, được sử dụng để đặc tả hành vi của các mô đun trong ngôn ngữ Java JML là sự kết hợp phương pháp thỏa thuận với phương pháp đặc tả dựa trên mô hình của ngôn ngữ Larch [13] JML sử dụng logic Hoare [14] kết hợp với việc đặc tả các tiền/ hậu điều kiện (pre-/post-condition) và các bất biến (invariant) của các thuộc tính, các cấu trúc

Các đặc tả JML được thêm vào mã Java dưới dạng các chú giải (annotation) bên trong các chú thích (comment) Các chú thích trong ngôn ngữ Java được hiểu như là các chú giải JML khi nó bắt đầu bằng ký tự “@” Ví dụ trong Hình

2 minh họa việc sử dụng JML đặc tả cho lớp Purse Trong đó, trường balance được đặc tả với bất biến (invariant) là balance luôn trong đoạn từ 0 đến MAX_BALANCE Trường pin là một mảng thuộc kiểu byte với bất biến là pin

có đúng 4 phần tử và các phần tử chỉ có giá trị từ 0 đến 9

public class Purse { final int MAX_BALANCE; int balance;

//@ invariant 0 <= balance &&

balance <= MAX_BALANCE;

byte[] pin;

/*@ invariant pin != null &&

pin.length == 4 && (\forall int i; 0<=i&&i<4;

int debit(int amount) throws PurseException {

if (amount <= balance) { balance -= amount; return balance; }

else { throw new PurseException("overdrawn by " + amount); }

}

Trang 20

}

Hình 2.2: Ví dụ minh họa về đặc tả JML

Phương thức debit nhận vào đối số amount là đầu vào Phương thức này sẽ trừ amount vào balance và trả về giá trị của balance sau khi trừ trong trường hợp balance lớn hơn hoặc bằng amount Trong trường hợp balance nhỏ hơn amount, một ngoại lệ PurseException sẽ được trả về Tiền điều kiện (requires) của phương thức này là amount phải lớn hơn hoặc bằng 0; hậu điều kiện (ensures) là balance bị trừ đi một lượng amount và trả về kết quả sau khi trừ Phương thức này còn có một hậu điều kiện nữa cho trường hợp phương thức trả

về ngoại lệ (signals)

2.4 Kết luận

Trong chương này luận văn đã trình bày một số kiến thức cơ sở được sử dụng cho phương pháp kiểm chứng một số ràng buộc của kịch bản tại thời điểm thực thi được trình bày trong chương 3 và chương 4

Ngày đăng: 27/04/2016, 07:36

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1. Trịnh Thanh Bình, Luận án TS, “Kiểm chứng các thành phần Java tương tranh”, ĐHQGHN, 2011 Sách, tạp chí
Tiêu đề: Kiểm chứng các thành phần Java tương tranh
2. Vũ Sỹ Vương, Khóa luận tốt nghiệp, “Kiểm chứng đặc tả UML cho tác tử phần mềm ”, Đại học Công nghệ, ĐHQG Hà Nội, 2009.Tiếng Anh Sách, tạp chí
Tiêu đề: Kiểm chứng đặc tả UML cho tác tử phần mềm
3. B. Berard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci, and P. Schnoebelen. 2010.Systems and Software Verification: Model- Checking Techniques and Tools (1st ed.). Springer Publishing Company, Incorporated Sách, tạp chí
Tiêu đề: Systems and Software Verification: Model-Checking Techniques and Tools
4. Glenford J. Myers and Corey Sandler. 2004. The Art of Software Testing. John Wiley &amp; Sons Sách, tạp chí
Tiêu đề: The Art of Software Testing
5. Melvin Fitting. 1990. First-Order Logic and Automated Theorem Proving. David Gries (Ed.). Springer-Verlag New York, Inc., New York, NY, USA Sách, tạp chí
Tiêu đề: First-Order Logic and Automated Theorem Proving
7. G. Booch, J. Rumbaugh, and I. Jacopson. The Unified Modeling Language User Guide, 2 nd edition. Addison-Wesley, 2005 Sách, tạp chí
Tiêu đề: The Unified Modeling Language User Guide, 2"nd" editio
9. Alan O’Callagan. The Object Constraint Language, CSCI3007 Component Based Development Sách, tạp chí
Tiêu đề: Alan O’Callagan
10. M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3 rd Edition. Addison Wesley, 2003 Sách, tạp chí
Tiêu đề: UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3"rd" Edition
12. Ramnivas Laddad. AspectJ in Action Practical Aspect-Oriented Programming. Manning Publications Co.,2003, Chapter 3 Sách, tạp chí
Tiêu đề: AspectJ in Action Practical Aspect-Oriented Programming
13. OMG. Unified Modeling Language. OMG, Version 2.0 March 2006 Sách, tạp chí
Tiêu đề: Unified Modeling Language
14. R.S. Pressman. Software Engineering, A Practitioner’s Approach, 5 th edition. Thomas Casson, 2001 Sách, tạp chí
Tiêu đề: Software Engineering, A Practitioner’s Approach, 5"th"edition
15. J. D. Gradecki and N. Lesiecki. Mastering AspectJ Aspect-Oriented Programming in Java. Wiley Publishing Inc, 2003.Website Sách, tạp chí
Tiêu đề: Mastering AspectJ Aspect-Oriented Programming in Java
6. Andreas Bauer, Martin Leucker, and Christian Schallhart. 2011. Runtime Verification for LTL and TLTL. ACM Trans. Softw. Eng. Methodol. 20, 4, Article 14 (September 2011), 64 pages Khác
8. Colyer, A. Clement, G. Harley, and M. Webster. Eclipse AspectJ: Aspect- Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools. Addison Wesley Professional Publisher, 2004 Khác
11. Truong Anh Hoang, Nguyen Thanh Binh, Nguyen Viet Ha. Checking method call sequences using aspect-oriented programming Khác

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w