Luận văn kiểm chứng giao diện phần mềm bằng phương pháp mô hình hóa event b

logic mệnh đề va lý thuyết tập hợp kết hợp với công cụ mã nguồn mở Rodin cho phép sinh và kiểm chứng một cách tự động, Nhận thấy được tim quan trọng của việc kiểm chứng giao điện người

DẠI HỌC QUOC GIA HA NOI TRUONG DAI HOC CONG NGHE

NGUYEN XUAN TRUONG

KIEM CHUNG GIAO DIEN PHAN MEM BANG PHUONG PHAP

MO HINH HOA EVENT - B

LUẬN VĂN THẠC Si CO!

NGHE THONG TIN

HA NOI, 2016

KIEM CHUNG GIAO DIEN PHAN MEM BANG PRUONG PHAP

MO HINH HOA EVENT —B

Ngành: Công nghệ thông tia

Chuyên ngành: Kỹ thuật phân mềm

Mã số: 60.48.01.03

` THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS TRƯƠNG NINH THUẬN

1,2016

LOI CAM DOAN

Tôi xim cam đoan toàn bộ nội dung bản luận văn là do téi tim 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

đẫ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 16 rang 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 06 năm 2016

Người cam đoan

Rguyễn Xuân Irường.

LỜI CẢM ƠN

Em xin gửi lời cảm ơn chân thành đến các thầy, các cô khoa Công nghệ Thông Tin — Trường Đại học Công nghệ — Đại học Quốc gia Hà Nội đã lận tinh đạy dỗ, truyền đạt cho chúng em nhiều kiến thức, kinh nghiệm quý báu trong suất quá thời gian học tập tại trường Em xin gửi lời cảm ơn sâu sắc tới thầy TG8.T§ Trương Ninh Thuận — Phó chủ nhiệm khoa công nghệ thông tin —

Trường Đại học Công nghệ ĐIIQGIIN đã tận tỉnh chỉ bảo, hướng dẫn, định

hướng cho em đổ em hoàn thành luận văn tốt nghiệp này

Cuối cùng em xin cảm ơn gia đình, bạn bè, đồng nghiệp đã luôn động

viên ủng hộ vả lạo mại điều kiện tốt nhất trong suốt quá trình học tập và hoàn

thành luận văn này Với việc tìm hiểu và nghiền cửu về lĩnh vực, công cụ còn tương đối mới mẻ cùng với kiến thức còn nhiều hạn chế, nên không tránh khỏi

những thiểu sót Em rất mong nhận dược những ý kiến dong gop quý báu của

thây cô và các bạn đề luận văn được hoản thiện hơn

TIà Nội, tháng 06 năm 20L6

Học viên

Nguyễn Xuân Trường

Chueng 2 TONG QUAN VE KLEM CHUNG GIAO DLEN PHAN MEM

2.2 Các phương pháp kiểm chứng giao diện - - 12

2

Chương 3 KIỂM CIIỨNG GIAO DIEN PIIAN MEM BANG PITUONG

4.1 Tổng quan về các ứng dụng trên điện thoại đi ding - 34

4.11 Các thánh phần cơ bản của một ứng dụng Android 35

43 Mô hình hóa vả kiểm chứng giao diện ứng dụng, Note - 4

A Dic ti context Note_C ctia img dụng Note - 58

B Dac ta machine Note M ciia (mg dung Note 58

3

DANII MUC KY IIEU VA CIC! VIET TAT

Integrated Development Environment Graphical User Interface

Proof Obligations Invariant

Deadlock Freeness

Variant

well-definedness

Bang 2.2 Luật chứng mình TNV với sự kiện evt

Bảng 3.1 Chuyển đổi từ GUI tới Event-B

Bang 4.1 Bảng CSDL ghi chú Note

Bang 4.2 Mô tả cửa số giao diện MainActivity

Bảng 4.3 Mô tá sơ bộ các đối tượng của cửa số giao điện OrcatcActivity

Bang 4.4 Mô tả sơ bộ các đối tượng của cửa số giao diện EdiLAcUvity

Bảng 4.5 Mô tả sơ bộ các đối tượng của cửa số giao diện ViewActivity

Cau tric context

Vi du va context trong Hvent-H

Cấu trúc machine trong Event-B

Cầu trúc của Evưnt trong Bvent-B

Vi du machine trong Event-b

Ví dy Event trong Bvent-B

Vi du về mối quan hệ Refinement trong Event-B,

Sơ dé định nghĩa sự kiện

Định nghĩa sự kiện evL

Giao diễn đồ hoa cua céng cu Rodin

Symbols View

Event-B Explorer, Menu bar

Quy trinh kiểm chứng tổng quat

Quy trình kiểm chứng chỉ tiết

Cơ chế Back Stack

Quy trình xây dựng Acivity Diagram

Sơ đồ Activity Diagram

40

Event chọn chức năng, View ~ we ST

Các Event trên các đối tượng cúa các cửa số ee SD

Cửa số Statistics trong trường hợp lỗi

Cửa số Statistics trong trưởng hop di .35

7

Chương 1 GIỚI TIHỆU

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

Ngày nay phần mềm có mặt trong hầu hết các lĩnh vực: Giáo dục, truyền

thông, ngân hàng, sản xuất chẺ tạo, quản trị, y tế, khoa học kỹ thuật, hàng không

vũ trụ, giải trí, Giúp con người giải quyết hầu hết các công việc và dan thay thế con người Đại đa số phần mềm hiện nay được xây dựng với một giao điện

đỗ họa người dùng Graphical LIser Interfaoe (GUL) thân thiện và người sử dụng

en ga kt lân ote ab AD a

chỉ việc tương tác với giao diện của phân mêm

Việc phát triển phần mềm dần hưởng tới đưa ra sản phẩm có giao điện dé

sử dụng, có tính thắm mỹ cao và đảm bảo được các chức năng cần thiết Tuy

nhiên không phái lúc nào các GUI của phần mềm khi dược xây dựng diều dâm

bao được tính dễ ding, bố cục hợp lý, các chức năng hoạt động một cách chính

xác như mong muốn Lỗi phần mềm chủ yếu xuất hiện trong quá trình tương tác

như: Các phần tử trên @UI hiển thị bất thường khó quan sát và thao tác, các

chức năng thực hiện không như dự định, các thông báo hiển thị sai, thử tự xuất hiện của các cửa số không chính xác, , dẫn tới thực hiện sai, gây mắt mát dữ

liêu, gây mất an toản thiệt hại về kinh tế và có thế nguy hại tới tính mạng của

người sử đụng, Vì vậy, Cần phải thực hiện kiểm thử giao diện phần mềm để kiểm tra các chức năng, sự nhất quản, khš năng tầm nhìn, khá năng tương thích

đảm bảo phủ hợp với các thông số trong đặc tả thiết kế, phát hiện lỗi và sửa

chữa kịp thời hoặc bất cứ vấn đề bất thường nàn có thể 06 oda giáo điện là và

cùng quan trọng và là một thách thức lớn trong quá trình xây dựng phần mềm

Kiểm chứng giao diện phần mềm là một quy trình gồm nhiều công việc khác nhau trên nhiễu đối tượng của giao diện Irong đó việc kiểm chứng thứ tự

hiển thị của các cửa số giao điện là một yếu tế quan trọng và cần thiết, có thể

thấy người sứ dụng làm việc với phần mềm chủ yếu thông qua các cửa số giao

điện qua đó người dùng có thể giao tiếp, tương tác, trao đỗi nhập xuất thông tin

với phần mềm Từ một chức năng trong cửa số này có thể gọi Lới một hoặc nhiều

cửa số khác, Lại mỗi một thời điểm chỉ có một sửa số được làm việc Các trạng

thái và thứ tự xuất hiện của các giao diện cần đấm bảo chính xác với lời gợi tới

nó Khi cửa số hiển thị không đúng với thứ tự ứng chức năng định sẵn sẽ đưa tới

người dùng những thông In và hành động sai điều này gây ra những hậu quả

khé lường

Tử trước tới nay có nhiều phương pháp kiểm chứng, kiểm thử được áp

đụng để kiểm chứng, kiểm thử các bản đặc tả thiết kế giao điện phần mềm như kiểm chứng tĩnh, kiểm chứng động, kiểm thử hộp đen, Tuy nhiên mỗi phương

pháp lại bộc lô những ưu và nhược điểm riêng Với kiểm chứng tĩnh lại phụ

thuộc chủ yếu vào kiến thức với kinh nghiệm khả năng phân tích của người

kiểm thử và thường tốn nhiều thời gian Trong khi đó kiểm chừng động thì lại

được áp dụng trong quá trình thưc hiện của phần mềm và sử dụng các kỹ thuật

kiểm thứ tủy theo cấp độ như kiểm thử modul hay kiểm thử đơn vị, phương

pháp này tốt cho việc tìm lỗi nhưng lại đòi bởi thực biện chương trình tức là việc

kiểm chứng chỉ thực hiện sau khi đã có mã nguôn Phương pháp Event-B là một

phương pháp mô hình hóa cho phứp mô hình hóa các thành phần, đối tượng olla

hệ thống phần mễm dưa trên các ký hiệu toán học logic mệnh đề va lý thuyết

tập hợp kết hợp với công cụ mã nguồn mở Rodin cho phép sinh và kiểm chứng

một cách tự động,

Nhận thấy được tim quan trọng của việc kiểm chứng giao điện người

dùng của phần mễm mà cụ thể là kiểm chứng thứ tự xuất hiện của các cửa số

giao diện củng với ưu điểm của phương pháp Event-B và công cụ Rodin, nên tác

giả đã mạnh dạn đề xuất đề tải “Kiểm chứng giao diện phần mềm bằng

phương pháp mô hình hóa Event — B” nhằm nghiên cứu phương pháp kiểm chứng giao điện chung và tập trung vào xây dựng phương pháp kiểm chúng thir

tự xuất hiện của các cửa sỐ giao điện phần mềm cho các ứng đụng trên thiết bị di

động

12 Nội dung nghiên cứu

Để tài tập trung vào việc nghiên cứu đặc điểm của giao diện phần mềm,

các vấn để liên quan tới kiểm chứng giao diện phần mềm, các phương pháp

kiểm chứng giao diễn Nghiên cứu mỗ hình, cấu trúc, ký pháp của phương pháp

mô hình hóa Event-B Tìm hiểu nguyên lý, chức năng của công cụ Rodin Tử

những nghiền cứu có được xây dựng một phương pháp mô hình hóa và kiểm

chứng chung, xây dựng phương pháp kiểm chứng thứ tự xuất hiên của các cửa

số giao diện người đủng của các ứng dụng di động, toàn bộ quá trình nghiên cứu

được triển khai gồm các công việc: xây dựng quy trình thực hiện tổng quái, xây

dựng quy trỉnh chỉ tiết, xây dụng các mô hình giao diện trừu tượng tống quát thông qua các định nghĩa, xây dựng các bộ quy tắc chuyển đổi tham chiêu tương

ứng từ mô hình trửu tượng vào trong Event-B

Ấp đụng vào kiểm chứng tự động thứ lự thực hiện của các cửa số giao diện của ứng dung tạo ghi chủ Note chạy trên hệ điều hành Android của thiết bị

di động

1.3 Đông gúp của dễ tài

Nghiên cứu để xuất phương pháp để kiểm chứng giao điện người dùng

phần mềm ở giai đoạn thiết kế bằng phương pháp mô hình hóa Exvem-B, đá

chính là kiểm chứng sự tuân thủ về thứ tự của các cửa số giao diện, giúp các nha

phát triển có thể phát hiện và tránh các lỗi không mong muốn của giáo điện hoặc

những giả thiết không hợp lý của bản đặc tả thiết kế của giao diện trong quá

trình xây dựng phần mềm trước khi cài đặt

1.4 Câu trúc của luận văn

Phân nội dung của luận văn được cấu trúc thành 4 chương chính như sau:

Chương 1 Giới thiệu

Giới thiệu về các yêu cầu khách quan, chủ quan, cơ sỡ khoa học, thực tiễn

nghiên cứu vả xây dung dé tai

10

Chương 2 Tống quan về kiểm chứng giao diện phần mềm và Phương pháp

mô hình hia Event-B

Giới thiệu một cách chỉ tiết về giao điện phần mềm cũng như các vẫn dễ

về kiếm chứng giao điện phần mềm, các phương pháp kiểm chứng giao diện Bao gầm những kiển thức tổng quan về phương pháp mô hình hóa Event-B, mé

tả cầu trúc của mỏ hình, các thành phần, giải thích ý nghĩa của các thành phần,

cấu trúc của mệnh đề chứng minh và phân loại Nêu rỡ tập các ký hiệu toán học

trong cú pháp của mô hình Trình bày cách sử dụng vả kiểm chứng Lự động với

công cụ Rodin

Chương 3: Kiếm chứng giao diện phẫn mềm bằng phương pháp Event-B

Tập trung vào việc xây dựng quy trình kiểm chứng tổng quát và chỉ tiết

cho các giao diện ứng dụng như: xây dựng quy trình thực hiện, xây dựng mô hình chung trên các định nghĩa, xây đựng quy trỉnh chỉ tiết, đưa ra các luật

chuyển đổi tổng quát và mệnh để chứng minh tổng quát chung,

Chương 4 Ấp dụng phương pháp kiểm chứng giao diện ứng dụng trên thiết

bị di động với Event-B

Trình bảy tổng quan về ứng dụng trên thiết bị đi động Android và ứng

đụng Note Áp dụng phương pháp dã nghiên cứu được vào mô hình hóa và kiểm

chứng thứ tự các cửa số của ứng đụng Note Soạn thảo, biên tập mô hỉnh thu

được và kiểm chứng tự động với công cụ Rodin

Kết luận và hướng phát triển

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

triển tiếp theo

Phụ lục

Trinh bảy một oách chỉ tiết về các mô hình trong EvenL-B của ứng dựng

Note da chuyển đối và mô hình hóa

ll

Chuong 2 TONG QUAN VE KIEM CHUNG GIAO DIEN PHAN MEM

VÀ PHƯƠNG PHÁP MÔ HÌNH HÓA EVENT-B

2.1 Giao diện người dùng

Giao diện người dùng Graphical user interfaces (GUI) là giao diện đồ họa của chương trình cho phép người sử dụng giao tiếp với máy tính và các thiết bị

điện tử thông qua tương tác với các đối tượng đồ họa như: nút ấn, menu, hộp

nhập, , thay vì chỉ là các dòng lệnh đơn thuần như trong Hình 2.2 GUI được

sử dụng phổ biến trong máy tính, các thiết bị cầm tay, các thiết bị đa phương

tiện trong văn phòng hoặc nhà ở

Con người tương tác với phần mềm thông qua các đối tượng đồ họa: cửa

số, biểu tượng và các menu Có nhiều phương pháp để tương tác, điều khiển như

thông qua việc sử dụng một con chuột, bàn phím hoặc cũng có thể sử dụng bằng cách sử dụng các phím tắt bàn phím, phím mũi tên, hoặc thông qua giao diện cảm ứng

GUI cung cấp cho người dùng một cách giao tiếp khác với các chương, trình máy, biến các chương trình phức tạp trở nên bắt mắt và dễ dùng hơn Một

ví dụ minh họa về GUI thể hiện trong Hình 2.1 Mech enay ren

nagennunninin si - dJ Phgmldenenae eome — d tham da Gió - đ n€yvRuabey: BE Newman heo gigtdiadiiots

i ron 9 a en re ,, 1., ing ah nga pe an

mạo mg Tahoma Qi) Bie nec eg

ites) sie

Hình 2.1 Giao diện đỗ họa người dùng

Hình 2.2 Giao diện dòng lệnh

2.2 Các phương pháp kiểm chứng giao diện

Kiểm chứng giao diện là quá trình gồm nhiều kỹ thuật kiểm tra, kiểm thử

giao diện phân mêm đề đảm bảo các chức năng tương ứng của giao diện đồ họa

người dùng của phần mềm phải phủ hợp với thông số kỹ thuật bằng văn bản tức

là các bản đặc tả, thiết kế của nó [1]

Kiêm chứng những khiêm khuyết trong giao diện rât khó khăn bởi vì một

số lỗi giao diện chỉ biểu lộ trong những điều kiện đặc biệt Các lỗi thường xảy ra trên giao diện khi: một thành phần gọi tới các thành phần khác và gây ra lỗi

trong khi sử dụng giao diện của nó, thành phần được gắn với các giả thiết về ứng

c thành

xử của nó với thành phần được gọi, nhưng thành phần nay lai sai, c:

phân gọi và thành phân được gọi thao tác với tốc độ khác nhau và những dữ liệu

cũ lại được truy nhập, v.v

Ngoài chức năng phát hiện lỗi, kiểm chứng giao diện còn đánh giá các

yếu tổ thiết kế như bồ cục, màu sắc, phông chữ, cỡ chữ, nhãn, hộp văn bản, định

dạng văn bản, ghỉ chủ, các nút, danh sách, các biểu tượng, liên kết, xử lý các sự

kiện bàn phím, sự kiện chuột và nôi dung

Kiêm chứng giao diện có thê phân chia vào việc xem xét hai khía cạnh chính [5]

s Khả năng sử dụng của giao diện

"_ Tính thâm mỹ, bắt mắt

Mau sac

13

Hình khối và biểu tượng (lcon)

Vị trí, kích thước của các đỗi tượng mút ẩn, hộp nhập,

—_ Ngễn ngữ: các ký hiệu, từ viết tắt, chính tã

"Sự diều hưởng

—_ Thông qua thao tác để truy cập qua công cụ hoặc thực đơn

— sé lượng các thao tác chọn và các thao tác chọn kết hợp

—_ Các phím tắt và các tùy chọn nâng cao

+ Tính logic của giao diện

= Pham vi cia vùng đữ liệu vào/ra

— Input box

Check box Drop down window list

— Button lya chon

=_ Hành vi của giao diện được cài đặt chặt chế với từng bỗi cảnh

—_ Khi người dùng gọi trình tự sáo chức năng trên GUL

Quá trình kiểm chứng giao diện người dùng của ứng dụng để phát hiện

nếu ứng dụng có chức năng không chính xác Kiểm chứng giao diện áp dụng các

kỹ thuật kiếm thử, các kỹ thuật kiểm thử này dé cập đến việc thiết lập các nhiệm

vụ thực hiện và so sánh kết quả cùng với kết quả dự kiến và khả năng lặp lại

cùng một tập cáo nhiệm vụ nhiều lần với đữ liệu đầu vào khác nhau và cùng một

mức độ chính xác Kiếm chứng giao diện thực hiện kiểm tra cách xử lý ứng

dung bản phim và chuột sự kiện, làm thế nào cáo thành phần GLII khác nhau như: menubars, thánh công cụ, hộp thoại, nút nhân, hình ảnh, sự kiện khi

người sử dụng tương tác có thực hiện theo đúng cách mong muốn hay không

Thực hiện kiểm chứng giao diện cho ứng dụng sớm trong chu kỳ phát triển phần mém sẽ tăng tốc độ phát triển, cải thiện chất lượng và gidm thiểu rủi ro về phía

14

cuối của chu kỳ Kiểm chứng giao diện có nhiều phương phap khic nhau mai

phương pháp sẽ có những ưu nhược điểm riêng, có thể được thực theo hướng

tĩnh hoặc động và có thể áp dụng tương ứng nhiều kỹ thuật kiểm thử một cách

thú công hoặc có thể được thực hiện Lự động với việc sử dụng một chương trinh

phần mềm

3.3.1 Phương pháp tĩnh

Trong phương pháp nảy áp dụng kỹ thuật phân tích tĩnh, kiểm thử bằng

tay dựa trên kinh nghiệm va kiến thức của người kiểm thử, nó được thực hiện

bởi chỉnh người kiểm thử Phương pháp Heuristic được sử dụng trong kiểm thứ bằng tay, trong đó một nhóm các chuyên gia nghiên cứu các phần mềm dễ tìm ra

vấn để Màn hình giao diện được kiểm thử bằng tay bởi các người kiểm thử,

những hành dộng và phan héi của giao diễn dược so sánh với mục tiểu thiết kế

vả các yêu cầu của người sử đụng, sự khác biệt giữa mong đợi của người sử

đụng và các bước thiết kế thiết kế cần thiết bởi giao diện, khả năng sử dụng của

giao điện Việc kiểm thử bằng tay giúp phát hiện nhiều lỗi qua mỗi ca kiểm thử,

lỗi được tim thấy sẽ cung cấp gợi ý để tìm lỗi khác, có thể tìm được những lỗi

mà các phương pháp chứng tự động khó có thé tìm thấy Kiểm thử bằng tay

thường được sử dụng, tốt cho kiểm thir lao diện ứng dụng dầu, thăm dò Mặt khác kiêm chứng bãi g tay thường tỏ ra không hiệu quá và gây tốn thời gian khi

việc kiểm chứng cần lặp lại ca kiểm thử nhiều lần, phụ thuộc vào kiến thức và

khả năng của người kiếm thử [1]

2.2.2 Phương pháp động

Phương pháp thường áp dụng một số kỹ thuật kiểm thử và kiểm thứ giao

điện tự động như kỹ thuật kiểm thử black-box (hộp đen) với các mô hình black-

box được sử dụng để tạo các ca kiểm thử cho kiểm thứ giao diện, phương pháp

đông là quy trình 4p dụng nhiều kỹ thuật và công cụ kiểm thử thực hiện một tập

hợp các nhiệm vụ kiểm chứng tự động và so sánh kết quả thu được với đầu ra

mong đợi Kỹ thuật kiểm chứng giao diện tự động được áp dụng lá một giải

¢ vin đề mà kiểm thử giao dién bing lay trong kiểm

chứng tĩnh còn chưa lâm được Phương pháp áp dụng kiểm thử tự động được

thực hiện thông qua các công cụ được xây dựng sẵn miễn phí hoặc mắt phi:

© Công cụ Capiuro-Rcplay: lá một công cụ nắm bắt và chạy lại gác thứ nghiệm dã chụp của phiên lâm việc của người sử đụng (dầu vào vả các

sự kiện) và lưu trữ chúng trong các kịch bản (mỗi phiên) phù hợp sẽ

dược sử dụng dễ chạy lại các phiên người dũng Hoạt động bằng hai chế

độ tương tác thực hiện khác nhau và cung cấp lợi thế kiểm tra đầu ra,

đầu ra của ca kiểm thử được ghi lai [1]

* WUnit-Testing frameworks: cung cấp sự linh hoạt, hỗ trợ kiểm tra hướng phát triển và thực hiện công việc kiểm tra Lự động

* Model based testing: Mét mé hinh 14 mét mé ta đề họa hành vi của hệ

thống, Nó giúp người phát triển hiểu và dự doán các hành vị hệ thống

Mô hình giúp tao các ca sử dụng kiểm thử hiệu quả các yêu cầu của hề

thống Theo nhu câu sử đụng dé được xem xét để thử nghiệm mô hình

này dựa trên thức thi phiên làm việc của người sử dụng lựa chọn từ một

mô hình của giao diện, quá trình này gồm: xây dựng mô hình, xác định đầu vào chờ mô hình, tính toán kết quả dự kiến cho các mô hình, chay

thử nghiệm, so sánh kết quả thực tế với kết quả dự kiến, quyết định về

hành động khác trên mô hình

16

2.3 Téng quan vé Event-B

Event-B được phát triển bởi tác giả J.R Abrial, 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, được phát triển từ phương

pháp Ð Event-B sử dụng chủ yếu các ký hiệu Loán học, logic mệnh đẻ, lý thuyết

tập hợp để mô hình hóa hệ thống Cho phép tỉnh chỉnh mô hình hóa hệ thống

theo các mức từ trừu Lượng tới cụ thể và sử dụng các chứng mình toán học để xắc mình tính nhất quán giữa các mức độ tỉnh chính

Các ký hiệu, cú pháp của Denl-B có thể được soạn thảo và chứng mình

tự động bằng công cụ Rodin Platfrom được tích hợp trong Kelipse-IIDE

(Integrated Development Environment), Công cụ Rodin hỗ trợ cho phép soạn

tháo các ký hiệu và chứng minh các tính chất toán hạc một cách hiệu quã, lả một

công cụ mã nguồn mở được cập nhật liên tuc tai trang web Event-B.org [9] Một

mô hình Event-B thường mã hóa các hệ thông chuyển đãi trạng thái trong đỏ các biển sẽ đại diện cho các trạng thái, các sự kiện event đai điện cho việc chuyển từ

trạng thái tới một trạng thái khác của hệ thống Một mô hình trong Event-B

được tạo thành bới hai loại thành phần cơ bản sau: machimes và context

Machimes bao gồm các phần đặc tả động của mô hỉnh, trong khi đó contexts

chứa các phần đặc tả tĩnh của mỗ hình

Một mô hình có thể chỉ chứa các contexts hoặc cdc machines hoặc là cả hai loai, Machines va contexts có các mỗi quan hệ qua lại với nhau: một

machine có thé refined bởi một machine khác và một context có thể exfended

bởi một context khác, một machine có thế sees một hoặc một vài context Mối

quan hé va cu trúc oủa machinos vả oontexts được thể hiện trong Hình 2.3 |4]

EVENTS

Hình 2.3 Cầu trúc mối va quan hệ của các thành phần mô hình trong Event-B

2.3.1 Context

Context dùng để đặc tả những phần tĩnh của một mô hình, mỗi context

trong Event-B có một tên duy nhất Một context có thể tham chiếu tới các thành phần được định nghĩa trong context mà nó extends Context duoc tao thành từ các mệnh đề được mô tả trong Hình 2.4 các mệnh đẻ này được định nghĩa như sau [4]

Mệnh đề *Extends” chỉ ra một danh sách các context mà context hiện

tại mở rộng

Ménh dé “Sets” chi mét tập hợp các mô tả chìu tượng và liệt kê các

loại, kiểu

Mệnh đề “Constants” là một danh sách các hằng số được đưa vào

context Hằng số trong các context và trong các context mà extends từ

nó phải có định danh khác nhau

Mệnh đề “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) Ménh dé “Theorems” 1a một danh sách các biểu thức logic gọi là định

lý và là thành phần cần chứng minh trong context

18

CONTEXT

INSTANTS AXIOMS

Dùng để đặc tả những thành phần động của mô hình, một machine trong

Hvent-B phải có một tên duy nhất và khác với tất cả các context va machine

Mệnh đề *Variables” là một danh sách các biển khác nhau được sử

dụng trong machine, các biến phải không được trùng tên Tuy nhiên

không giống như trong context một số biến cỏ thể trùng tên với các

biến trong machine trửu tượng

Mệnh dễ “Tnvariants” là một đanh sách các biểu thức logic toán học

khác nhau gọi là các vị từ má các biển phải thôa mãn Mỗi invariants

sẽ dược gắn một nhãn

Ménh dé “Events” gồm một đanh sách các events của machime Một

event tạo ra một hanh động làm thay đổi piả trị và trạng thai của các

biến Một event trong Event-B sẽ được cấu thành bởi một ràng buộc Œ

(, v) và một hành động A (t, v) với t là một tham số nào đỏ và v là

biến Hình 2.7 mô tả cầu trúc của event.

Hình 2.7 Cầu trúc của Event trong Event-B

s_ Các hành động của sự kiện có thể biểu diễn dưới dạng xác định hoặc không xác định, có thể có nhiều hành đông trong một sự kiện Hình 2.8 là một ví

dụ về machine va Hinh 2.9 là ví dụ về event

MACHINE changette REFINES SEES Somesets VARTABLES peds_color INVARIANTS

1nV1 peds_color € {red, green}

EVENTS

INITIALISATION # STATUS

ordinary

Hinh 2.8 Vi du machine trong Event-B

grd2 > new.value = TRUE = peds.colour = ved

Hinh 2.9 Vi du Event trong Event-B

2.3.3 Ký hiệu toán học trong Event-B

Phương pháp mô hình hóa Event-B sử dụng ngôn ngữ toán học cơ sở để

mô hình hóa gồm logic bậc nhất và lý thuyết tập hợp cơ sở cùng với các kiểu dữ liêu, có thể thấy ngôn ngữ toán học đóng một vai trỏ vô cùng quan trong trong

mô hình Event-B [4]

© Các phép toán logic bậc nhất cơ bản gồm: Phép tuyển v, phép hội A,

phép phủ định —, phép kéo theo =>, tương đương <>, lượng từ với mọi V„

lượng từ tồn tại 3 Bảng 2.1 mô tả các phép toán Từ các phép toán logic cơ

sở tạo nên các biểu thức logic được gọi là các vị từ trong các invariants và trong các ràng buộc (guards) của các event trong mô hình của Event-B

Đảng 2.1: Các phép toán logic

Tên phép toán Ký hiệu

22

* Các phép toán tập hợp: phép hop \, phép giao 4, phép hiệu \, quan hệ bao ham — quan hệ thuộc =

© Cac kiểu dữ liệu

Kiểu nguyên lả kiểu dữ liệu số được ký hiệu là #

— Kiểu logic ký hiệu là BOOL chỉ nhận một trong 2 giá trị BOOL-{TRUE, FALSE}

—_ Kiểu tập hợp đo người dùng định nghĩa

—_ Kiểu tip con oa mat lap ký hiệu là IP

2.3.4 Tỉnh chỉnh

Tỉnh chỉnh (relinemenU là giai đoạn cải đặt hay cụ thể hóa một machine

hoặc một contexL trừu tượng thành một machimc hoặc một contcxt cụ thể hơn,

chỉ tiết hơn bằng việc bổ sung vào các đặc tả [9] [4] Xiột machine có thể refmes

một machine trừu tượng, một contcxt có thể oxtends một contcxt lrừu tượng nav

đó Một cvent trong machine trừu tượng có thể được rcfincs thành một hoặc một

số sự kiện trong machine cy thể Các thành phần cia machine va context trim

tượng duge sir dung trong cac machine va context Wong (mg refines va extends

từ chúng Hình 2.10 là ví dụ mô tả mỗi quan hệ giữa machine và context trừu tượng và các tinh chỉnh của chúng

Hình 2.10 Ví dụ về mối quan hệ Refinement trong Event-B

23

2.3.5 Mệnh để chứng mình

Mệnh đề chứng mình POs (Proaf Obligations) là những biểu thức logic

mà cần phải được chứng minh trong mô hình Iivem-B, việc chứng minh nhằm

đảm bảo các machine là an toàn POs được thực hiện một cách tự động nhở công

cụ Rodin Platform vì vậy người ta cỏn gọi lá chứng mình tự động Roảm thực

hiện kiểm tra tữnh (bao gỗm phân tích từ vựng, phân tích cú pháp, loại kiểm tra)

các machine và context và sau đó đưa ra những mệnh để cần chứng minh và đưa

vào trong một file để chứng minh ty dong [4]

Các mệnh để chứng minh trong Event-B được mô tả thành các luật chứng minh và được địmh nghĩa thảnh các loại khác nhau như: lnvarlant preservation

CNV), Variant (VAR), Deadlock Freeness (DLF), Theorem (THM), well-

definedness (WID), , ching duve sinh ra lu déng trong Rodin Để xác dịnh các luật theo từng sự kiện thì có thể sử dụng hệ thống so dé định nghĩa sự kiện như

Tinh 2.11 [9]

evi

Hình 2.11 Sơ đồ định nghĩa sự kiên

© Vi du Invariant preservation proof obligation rule (TNV): luật chứng minh nay dam bio ring mỗi bit bién invariant trong machme được bảo

quân bởi một sự kiện event Néu cho mét sự kiện evt và một bắt biến invG, c, v} thi mệnh để chimg minh cé tén la “evil / inv / INV” va ven sur kiện được định nghĩa như Hình 2.12 thi sẽ có luật tương ứng sẽ được thể

hiện trong Báng 2.2 |4]

24

any x where

Gs, 6 vx) then

w|Bdls, Gg wx Vv)

Hình 2.12 Dịnh nghĩa sự kiện evt

Bảng 2.2 Luật chứng mình TNV với sự kiện evt

Invariants va theorems I(s, ¢, v)

Vị từ trước và sau khi sự kiện BẢ, 6, vụ x, v2)

|

Thay đổi của các bắt biến inv(s c, v’)

2.3.6 Céng cu Redin

Trong luận văn nảy sử dụng phiên bản Rodin 32 cấp nhật ngảy

22/09/2015 là một LDE dựa trên Eclipse được cung cấp hỗ trợ xây dung, tinh

chỉnh, mô hình hóa và chứng minh các mô hình trong Event-B [9] Rodin 1a bd

cung cụ mã nguồn mở bao gồm trinh soan thảo, thực thi, tự động tạo bộ chứng

minh, tài liệu hỗ trợ, , với giao điện đỗ họa trực quan trong môi trường Eclipse

nó sẽ là công cụ lý tưởng để xây dựng các mô hình của EvenI-Ð Hình 2.13 là vỉ

đụ về giao điện của bộ công cụ nảy

Hình 2.13 Giao diện đỗ họa của công cu Rodin

© Menu bar

Cung cấp các phương thức hỗ trợ, chỉnh sửa tập tin và các chức năng

đặc biệt khác của Event-B Menu bar Được mô tả trong Hình 2.16 bao

gồm một số mục quan trọng trọng [9]:

© Event-B menu: khi người dùng mở machine hoặc context sẽ xuất hiện một số trình thuật sĩ cho phép tạo một số yếu tố có sẵn trong

mô hình Event-B cho người dùng,

© Tool bar: cung cấp các phím tắt cho các lệnh quen thuộc như lưu, in, hủy

và phục hồi thao tác Các thanh công cụ cũng cung cấp các phím tắt cho

các trình thuật sĩ để tạo ra các yếu tố như tiên đề, các hằng số, liệt kê bộ,

® Editor View: chứa các hoạt đông biên tập của Event-B

© _ Symbols View: được thiết kế để cung cấp cho người dùng một cách thuận tiên để thêm các biểu tượng toán học cho các biên tập mô hình khác nhau Nếu một trình biên tập được mở và một file văn bản đang hoạt động (con

trỏ nhấp nháy ), nhấp chuột vào một biểu tượng thì sẽ chèn nó ở vị trí hiện tại, Symbols View được mô tả trong Hình 2.14

26

e Event-B Explorer

Cửa số này cho phép người phát triển quản lý các dự án của mình như truy

cập mở, đóng, tạo mới hoặc xóa bỏ Cửa sổ thường nằm bên trái của màn

hình nhưng cũng có thể thay đổi nêu người dùng muốn Giao diện của Event-

B Explorer được mô tả trong Hình 2.15 [9]

Wy Symbols £3 |) Type Environment eo

Hinh 2.15 Event-B Explorer

File Edit Navigate Search Project Run Refactor Event-8 Windov

27

Chuong 3 KIEM CHUNG GIAO DIEN PHAN MEM BANG PHUONG

PHÁP MÔ HÌNH HÓA EVENT-B

3.1 Phương pháp chung

Giao diện phần mềm nói chung và giao diện của các ứng dụng trên thiết

bị di động nói riêng, thường thiết kế gồm các đối tượng để người dùng tương tác

lấy thông tin, thao tác của người dùng nên các đối tượng sẽ phát sinh ra các sự

kiên và hành động được cài đặt sẵn sẽ thực thi một công việc nào đó sau khi sự

kiện xảy ra Các đối tượng thường là: Cửa số, Text Box, Combo Box, List Box,

Radio Button/Option Button, Check Box/Tick Box, Report,

Sử dụng phương pháp mô hình hóa Event-B để mô hình hóa và kiểm

chứng thứ tự xuất hiện của các cửa số giao sẽ giúp người phát triển hiểu rõ hơn,

kiểm tra được tính đúng đắn và phát hiện ra những lỗi trên các cửa số giao diện

không mong muốn Quy trình mô hình hóa và kiểm chứng giao diện tổng quát bằng phương pháp Event-B là quá trình chuyển đổi các thành phần tương ứng

của giao điện như các yêu câu, thuộc tính, đặc tả, ràng buộc về thứ tự thực hiện

của các cửa số sang các yếu tố, thành phần trong cấu trúc mô hình của mô hình trong Event-B, sau đó biên tập và kiểm chứng tự động bằng công cụ Rodin Quy trình tổng quát của phương pháp được thể hiện trong sơ đồ Hình 3.1

Í Đặc tá, bản thiết kế của

GUL Luật chuyến đối

Biên tập, soạn thảo

Hình 3.1 Quy trình kiểm chứng tổng quát

28

3.2 Phương pháp chi tiét

‘Tix quy trinh tang quát của phương pháp trong Hình 3.1 ta đi thực hiện cụ thể hóa nó bằng các bước chỉ tiết cụ thể hơn được mô tả trong [inh 3.2 trong

đỏ

«Đặc tá, bản thiết kế của GUI: là những tải liệu đặc tả về thiết kế, những

yêu cầu về chức năng mong muốn sẽ xây dụng của giao điện

s Mô hình GUI trừu tượng: lả mô hình trùu tượng tổng quát cho các giao

diện ứng dụng phần mềm, mô hình được xây dựng thông qua các dịnh nghĩa được mô tả trang mục 3.3

=_ Mê hình Event-B trừu tượng: lả mô hình trừu tượng chung có dược dựa trên chuyển đối từ các luật được định nghĩa trong mục 3.3 và bảng 3.]

«_ Sơ dễ hoạt dộng: là sơ dễ thể hiện thứ tự thực hiện và hoạt động của các

cửa số giao diện như mong muốn của người thiết kế

e Mô hình Kvcnf-B cho ứng dụng cụ thế: lả mô hình cụ thể có được khi thực hiện mô hình hóa trên một ứng dụng cụ thể đựa trên các mô hình

trừu tượng và các luật chuyển đổi Tủy thco loại ứng dựng số có gách xây

đựng tương ứng

e_ Mệnh để chứng minh (POs) tổng quát: là mệnh để tổng quát chung của giao điện cần phải chứng minh hay xác minh, mệnh đề được xây dựng ở

mục 3.4

Các bước thực hiện của quy trính chỉ tiết trong IIình 3.2 được đánh đầu

bằng các số thứ tự và dược thực hiện như sau: bước dầu tiên là di xây dựng một

mô hình hóa giao diện một cách trửu tượng chung cho các giao diện ứng dụng

bằng cách đưa ra cdc định nghĩa tông quát Bước thử hai từ những định nghĩa

tổng quát đi xây dựng các luật mô hình hóa chuyển đối tương ứng từ mô hình của giao diện sang mô hình trong Event-B bước này chỉnh là bước tĩnh chỉnh mô

hình trừu tượng, tử kết quá bước một và các luật đưa ra mục tiêu cần chứng

minh chung, qua bude 2 ta thu được các quy tắc chuyển đổi tổng quát cho thành

phần trong mỗ hình giao điện vào EvenL-Ð kết quả của bước này sẽ được sử

29

dung dé lam khung tham chiếu và kết hợp với kết quả của bước số 4 dé tao ra

một bản mô hình hóa đặc tả giao diện hoàn chỉnh trong Hvent-B Hước số 3 và

Ấ 4 tờ và sân của mỗi ñ  cần thể cần mà hà 22 củ

SỐ 4 tủy vào giao diện của mỗi ứng dụng cụ thê cân thê cần mô hình hóa cùng

với băn đặc tả thiết ởm với những giá thuyế

dao điện và chức năng của

nó từ đó chuyển đổi thành biểu đỗ hoạt đồng tương ứng của ứng dựng, từ sơ đồ

nảy có thể thấy được nguyên lý hoạt động và các thứ tự mà khi thực thị giao

diện theo đặc tả, kết quá thu được sẽ dùng cho bước tiếp theo Hước số bốn tử sơ

đỗ hoạt động có được kết hợp thêm đặc tả thiết kế để đem mô hình hóa bằng

việc tham hiểu tới sáo luật chuyển đổi ở bước hai đỂ đặc tả sang các thành phần

tương ứng trong Event-B ở bước này thì tủy thuộc vào img dụng má sẽ có

những chuyển đổi thích hợp, kết quả của bước này tạo ra một mô hình trong

Tvent-P có thể gồm một hoặc nhiều thành phân machine và context Bước năm

tại đây đem mô hình đã thu được ở bước bến tham chiếu vào mô hình trừu tượng ở bước hai để đảm bảo tuân thủ các định nghĩa và luật, tỉnh chỉnh để thu

được mô hình cuối củng là các machine va context cu thé, dem két quả dưa vào

công cu Rodin Bude số 6 sử dung céng cu Rodin tạo tự động các mục tiêu cần

chứng mình Pos và thực hiện kiểm chứng tự động Bước 7 từ kết quả thu được ở

bước 6 sẽ kết hợp với biểu đồ hoạt động ban đầu đưa ra kết quả kiểm chứng để

đánh giá sự vi phạm hay không các yêu cầu về giao diện đã đặt ra và từ đó để có

những chỉnh sửa phủ hợp