(LUẬN văn THẠC sĩ) kiểm chứng giao diện phần mềm bằng phương pháp mô hình hóa event b

GIỚI THIỆU

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

Ngày nay, phần mềm đã trở thành một phần thiết yếu trong hầu hết các lĩnh vực như giáo dục, truyền thông, ngân hàng, sản xuất, quản trị, y tế, khoa học kỹ thuật, hàng không vũ trụ và giải trí Chúng giúp con người giải quyết nhiều công việc và dần thay thế vai trò của con người Phần lớn phần mềm hiện tại được thiết kế với giao diện đồ họa người dùng (GUI) thân thiện, cho phép người sử dụng dễ dàng tương tác với các chức năng của phần mềm.

Việc phát triển phần mềm hiện nay tập trung vào việc tạo ra sản phẩm có giao diện dễ sử dụng, thẩm mỹ cao và đầy đủ chức năng cần thiết Tuy nhiên, không phải lúc nào giao diện người dùng (GUI) cũng đảm bảo tính dễ dùng và bố cục hợp lý, dẫn đến những lỗi phần mềm trong quá trình tương tác như hiển thị bất thường, chức năng không hoạt động đúng, thông báo sai, và thứ tự cửa sổ không chính xác Những lỗi này có thể gây ra sai sót, mất dữ liệu, thiệt hại kinh tế, và thậm chí nguy hiểm đến tính mạng người sử dụng Do đó, việc kiểm thử giao diện phần mềm để đảm bảo các chức năng, sự nhất quán, khả năng tầm nhìn và khả năng tương thích với thiết kế là vô cùng quan trọng, đồng thời phát hiện và sửa chữa kịp thời các vấn đề bất thường 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à quy trình quan trọng, bao gồm nhiều công việc khác nhau liên quan đến các đối tượng của giao diện Một yếu tố cần thiết trong quy trình này là kiểm chứng thứ tự hiển thị của các cửa sổ giao diện, vì người dùng chủ yếu tương tác với phần mềm thông qua các cửa sổ này Mỗi chức năng trong cửa sổ có thể gọi tới một hoặc nhiều cửa sổ khác, nhưng chỉ có một cửa sổ được sử dụng tại mỗi thời điểm Do đó, trạng thái và thứ tự xuất hiện của các giao diện cần được đảm bảo chính xác để tránh những thông tin và hành động sai lệch, điều này có thể dẫn đến những hậu quả khó lường cho người dùng.

Trong lĩnh vực kiểm thử và kiểm chứng thiết kế giao diện phần mềm, nhiều phương pháp như kiểm chứng tĩnh, kiểm chứng động và kiểm thử hộp đen đã được áp dụng, mỗi phương pháp đều có những ưu và nhược điểm riêng Kiểm chứng tĩnh phụ thuộc vào kiến thức và kinh nghiệm của người kiểm thử, thường tốn nhiều thời gian, trong khi kiểm chứng động được thực hiện trong quá trình phát triển phần mềm với các kỹ thuật kiểm thử khác nhau như kiểm thử modul hay kiểm thử đơn vị, giúp phát hiện lỗi nhưng chỉ thực hiện sau khi có mã nguồn Phương pháp Event-B nổi bật với khả năng mô hình hóa các thành phần hệ thống phần mềm bằng các ký hiệu toán học và logic, kết hợp với công cụ mã nguồn mở Rodin, cho phép tự động sinh và kiểm chứng.

Nhận thức được tầm quan trọng của việc kiểm chứng giao diện người dùng phần mềm, tác giả đề xuất nghiên cứu đề 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” Đề tài này nhằm tìm hiểu phương pháp kiểm chứng giao diện tổng quát và đặc biệt tập trung vào việc kiểm chứng thứ tự xuất hiện của các cửa sổ giao diện cho ứng dụng di động, sử dụng ưu điểm của phương pháp Event-B và công cụ Rodin.

Nội dung nghiên cứu

Đề tài nghiên cứu đặc điểm giao diện phần mềm và các vấn đề liên quan đến kiểm chứng giao diện, bao gồm các phương pháp kiểm chứng và mô hình hóa Event-B Nghiên cứu nguyên lý và chức năng của công cụ Rodin nhằm xây dựng phương pháp mô hình hóa và kiểm chứng chung Phương pháp này tập trung vào kiểm chứng thứ tự xuất hiện của các cửa sổ giao diện người dùng trong ứng dụng di động Quá trình nghiên cứu bao gồm xây dựng quy trình tổng quát và chi tiết, phát triển các mô hình giao diện trừu tượng thông qua định nghĩa, và thiết lập bộ quy tắc chuyển đổi từ mô hình trừu tượng sang Event-B Cuối cùng, áp dụng vào kiểm chứng tự động thứ tự thực hiện của các cửa sổ giao diện trong ứng dụng ghi chú Note trên hệ điều hành Android.

Đóng góp của đề tài

Nghiên cứu giới thiệu một phương pháp kiểm chứng giao diện người dùng phần mềm trong giai đoạn thiết kế thông qua mô hình hóa Event-B Phương pháp này tập trung vào việc xác minh thứ tự hiển thị của các cửa sổ giao diện, giúp các nhà phát triển phát hiện và ngăn chặn những lỗi không mong muốn cũng như các giả thiết không hợp lý trong bản đặc tả thiết kế giao diện Điều này diễn ra trước khi phần mềm được cài đặt, nâng cao chất lượng sản phẩm.

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:

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 dựng đề tài.

TỔNG QUAN VỀ KIỂM CHỨNG GIAO DIỆN PHẦN MỀM VÀ PHƯƠNG PHÁP MÔ HÌNH HÓA EVENT-B

Giao diện người dùng

Giao diện người dùng đồ họa (GUI) cho phép người sử dụng tương tác với máy tính và thiết bị điện tử thông qua các đối tượng đồ họa như nút ấn, menu và hộp nhập, thay vì chỉ sử dụng các dòng lệnh đơn giản GUI được ứng dụng rộng rãi trong máy tính, thiết bị cầm tay và các thiết bị đa phương tiện tại văn phòng hoặc trong gia đình.

Con người tương tác với phần mềm thông qua các đối tượng đồ họa như cửa sổ, biểu tượng và các menu Việc điều khiển và tương tác này có thể được thực hiện thông qua nhiều phương pháp khác nhau, bao gồm sử dụng chuột, bàn phím hoặc các phím tắt bàn phím, phím mũi tên Ngoài ra, giao diện cảm ứng cũng là một phương thức phổ biến để người dùng tương tác với phần mềm.

Giao diện đồ họa người dùng (GUI) mang đến cho người dùng một phương thức tương tác mới với các chương trình máy tính, giúp biến những ứng dụng phức tạp trở nên hấp dẫn và dễ sử dụng hơn Ví dụ về GUI được minh họa trong Hình 2.1.

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

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

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

Kiểm chứng giao diện là quá trình sử dụng nhiều kỹ thuật để kiểm tra và thử nghiệm giao diện phần mềm, nhằm đảm bảo rằng các chức năng của giao diện đồ họa người dùng phù hợp với các thông số kỹ thuật đã được ghi chép, bao gồm các bản đặc tả và thiết kế.

Việc kiểm chứng các khiếm khuyết trong giao diện gặp nhiều khó khăn do một số lỗi chỉ xuất hiện trong điều kiện đặc biệt Các lỗi giao diện thường xảy ra khi một thành phần gọi đến các thành phần khác, dẫn đến sự cố trong quá trình sử dụng Điều này có thể xảy ra khi thành phần gọi dựa vào những giả thiết không chính xác về hành vi của thành phần được gọi, hoặc khi hai thành phần này thao tác với tốc độ khác nhau Thêm vào đó, việc truy cập dữ liệu cũ cũng có thể gây ra các lỗi trong giao diện.

Kiểm chứng giao diện không chỉ phát hiện lỗi mà còn đánh giá các yếu tố thiết kế quan trọng 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, ghi chú, các nút, danh sách, biểu tượng, liên kết, và xử lý các sự kiện bàn phím cũng như chuột.

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]:

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

 Tính thẩm mỹ, bắt mắt

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

 Vị trí, kích thước của các đối tượng nút ấn, hộp nhập, …

 Ngôn ngữ, các ký hiệu, từ viết tắt, chính tả

 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

 Phạm vi của vùng dữ liệu vào/ra

 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ự các chức năng trên GUI

Quá trình kiểm chứng giao diện người dùng ứng dụng nhằm phát hiện chức năng không chính xác thông qua các kỹ thuật kiểm thử Những kỹ thuật này bao gồm việc thiết lập nhiệm vụ, so sánh kết quả thực tế với kết quả dự kiến, và lặp lại các nhiệm vụ với dữ liệu đầu vào khác nhau để đảm bảo tính chính xác Kiểm chứng giao diện cũng kiểm tra cách ứng dụng xử lý các sự kiện từ bàn phím và chuột, cũng như cách các thành phần GUI như menu, thanh công cụ, và nút nhấn hoạt động khi người dùng tương tác Thực hiện kiểm chứng giao diện sớm trong chu kỳ phát triển phần mềm giúp tăng tốc độ phát triển, cải thiện chất lượng và giảm thiểu rủi ro Có nhiều phương pháp kiểm chứng khác nhau, mỗi phương pháp có ưu nhược điểm riêng, có thể thực hiện theo cách tĩnh hoặc động, và có thể áp dụng các kỹ thuật kiểm thử thủ công hoặc tự động hóa thông qua phần mềm.

Phương pháp kiểm thử Heuristic áp dụng kỹ thuật phân tích tĩnh và kiểm thử bằng tay dựa trên kinh nghiệm của người kiểm thử Nhóm chuyên gia nghiên cứu phần mềm để phát hiện vấn đề, trong khi giao diện được kiểm thử bằng tay để so sánh hành động và phản hồi với mục tiêu thiết kế và yêu cầu người sử dụng Việc này giúp phát hiện nhiều lỗi và cung cấp gợi ý để tìm ra lỗi khác, đặc biệt là những lỗi mà phương pháp tự động khó phát hiện Kiểm thử bằng tay hiệu quả cho kiểm thử giao diện ứng dụng đầu và thăm dò, nhưng có thể tốn thời gian và không hiệu quả khi cần lặp lại nhiều lần, phụ thuộc vào kiến thức và khả năng của người kiểm thử.

Phương pháp kiểm thử giao diện tự động thường sử dụng kỹ thuật kiểm thử black-box để tạo các ca kiểm thử, đồng thời áp dụng nhiều công cụ và kỹ thuật khác nhau nhằm thực hiện các nhiệm vụ kiểm chứng tự động Kỹ thuật này giúp khắc phục những hạn chế của kiểm thử giao diện bằng tay trong quy trình kiểm chứng tĩnh Việc áp dụng kiểm thử tự động được thực hiện thông qua các công cụ có sẵn, bao gồm cả miễn phí và mất phí, nhằm đảm bảo kết quả thu được so sánh chính xác với đầu ra mong đợi.

Công cụ Capture-Replay là một giải pháp hiệu quả để ghi lại và tái hiện các thử nghiệm từ phiên làm việc của người dùng, bao gồm cả đầu vào và các sự kiện Nó lưu trữ thông tin này trong các kịch bản tương ứng, cho phép chạy lại các phiên người dùng một cách dễ dàng Công cụ hoạt động với hai chế độ tương tác khác nhau, mang lại lợi ích trong việc kiểm tra đầu ra, đồng thời ghi lại kết quả của các ca kiểm thử.

 Unit-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 tự động

Kiểm thử dựa trên mô hình là một phương pháp sử dụng mô hình đồ họa để mô tả hành vi của hệ thống Phương pháp này giúp các nhà phát triển hiểu rõ hơn về cách thức hoạt động của hệ thống và dự đoán các hành vi có thể xảy ra, từ đó nâng cao hiệu quả kiểm thử.

Mô hình kiểm thử hiệu quả giúp xác định các yêu cầu của hệ thống thông qua việc thực thi phiên làm việc của người sử dụng Quá trình này bao gồm xây dựng mô hình, xác định đầu vào, tính toán kết quả dự kiến, chạy thử nghiệm và so sánh kết quả thực tế với kết quả dự kiến Dựa trên những so sánh này, quyết định về các hành động tiếp theo trên mô hình sẽ được đưa ra.

Tổng quan về Event-B

Event-B, được phát triển bởi 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, dựa trên phương pháp B Phương pháp này sử dụng các ký hiệu toán học, logic mệnh đề và lý thuyết tập hợp để mô hình hóa hệ thống, cho phép tinh chỉnh từ mức độ trừu tượng đến cụ thể Bên cạnh đó, Event-B còn sử dụng các chứng minh toán học để xác minh tính nhất quán giữa các mức độ tinh chỉnh của mô hình.

Event-B là một ngôn ngữ mô hình hóa mạnh mẽ, cho phép soạn thảo và chứng minh tự động thông qua công cụ Rodin Platform tích hợp trong Eclipse-IDE Rodin là một công cụ mã nguồn mở, hỗ trợ hiệu quả trong việc xây dựng các ký hiệu và chứng minh các tính chất toán học, với các bản cập nhật thường xuyên từ trang web Event-B.org Mô hình Event-B thường được sử dụng để mã hóa các hệ thống chuyển đổi trạng thái, trong đó các biến đại diện cho các trạng thái và các sự kiện thể hiện sự chuyển đổi giữa các trạng thái Một mô hình Event-B bao gồm hai thành phần cơ bản: machines, chứa phần đặc tả động, và contexts, chứa phần đặc tả tĩnh của mô hình.

Một mô hình có thể bao gồm các contexts, machines, hoặc cả hai loại Machines và contexts tương tác với nhau: một machine có thể được cải tiến bởi một machine khác, trong khi một context có thể được mở rộng bởi một context khác Đồng thời, một machine có thể nhận diện một hoặc nhiều context Mối quan hệ và cấu trúc giữa machines và contexts được minh họa trong Hình 2.3.

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

Context trong Event-B được sử dụng để mô tả các phần tĩnh của mô hình, với mỗi context mang một tên duy nhất Một context có khả năng tham chiếu đến các thành phần được định nghĩa trong context mà nó mở rộng Cấu trúc của context được hình thành từ các mệnh đề, như được trình bày trong Hình 2.4, và các mệnh đề này được định nghĩa cụ thể theo tài liệu tham khảo [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 đề “Sets” chỉ 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à danh sách các hằng số được đưa vào ngữ cảnh (context) Các hằng số trong ngữ cảnh và trong các ngữ cảnh mở rộng từ nó cần phải có định danh khác nhau để đảm bảo tính rõ ràng và không bị nhầm lẫn.

Mệnh đề "Axioms" bao gồm danh sách các tiên đề liên quan đến hằng số trong biểu thức logic, và các axioms này sẽ được sử dụng làm giả thuyết trong các mệnh đề chứng minh Pos (Proof obligations).

 Mệnh đề “Theorems” là 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

Sees refines refines sees extends sees

Hình 2.4 Cấu trúc của một context

Hình 2.5 minh họa một ngữ cảnh có tên là Array, được sử dụng để tìm kiếm một giá trị trong một mảng có kích thước n Trong đó, a là hằng số đại diện cho tên mảng, và x là giá trị cần tìm.

Hình 2.5 Ví dụ context trong Event-B

Trong mô hình Event-B, mỗi máy (machine) cần có một tên duy nhất, khác biệt với tất cả các ngữ cảnh (context) và máy khác Điều này giúp xác định rõ ràng các thành phần động của mô hình, đảm bảo tính chính xác và nhất quán trong quá trình phát triển.

CONTEXT Array CONSTANTS n //array size a //the array to search in x //value to search in a

END trong mô hình Một machine được cấu tạo bởi các thành phần là các mệnh đề được mô tả trong Hình 2.6 và định nghĩa như sau [4]:

 Mệnh đề “Refines” gồm các machine trừu tượng mà machine hiện tại tinh chỉnh từ các machine đó

Mệnh đề "Sees" là một danh sách các ngữ cảnh mà máy móc tham chiếu đến Máy có khả năng sử dụng các tập hợp và hằng số được định nghĩa rõ ràng trong các ngữ cảnh được khai báo trong mệnh đề "sees" của nó.

Mệnh đề "Variables" liệt kê các biến khác nhau được sử dụng trong machine, yêu cầu các biến này không được trùng tên Tuy nhiên, trong một số ngữ cảnh, có thể có các biến trùng tên với các biến trong machine trừu tượng.

Mệnh đề "Invariants" bao gồm các biểu thức logic toán học, được gọi là các vị từ, mà các biến cần phải thỏa mãn Mỗi invariant sẽ được gán một nhãn riêng biệt.

Mệnh đề "Events" trong Event-B bao gồm danh sách các sự kiện của máy, mỗi sự kiện tạo ra hành động làm thay đổi giá trị và trạng thái của các biến Một sự kiện trong Event-B được cấu thành từ một ràng buộc G(t, v) và một hành động A(t, v), trong đó t là tham số và v là biến Cấu trúc của sự kiện được mô tả rõ ràng trong Hình 2.7.

Hình 2.6 Cấu trúc của machine trong Event-B

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

Các hành động trong sự kiện có thể được biểu diễn dưới dạng xác định hoặc không xác định, và một sự kiện có thể chứa nhiều hành động khác nhau Ví dụ, Hình 2.8 minh họa một máy, trong khi Hình 2.9 thể hiện một sự kiện cụ thể.

Hình 2.8 Ví dụ machine trong Event-B

EVENT REFINES ANY WHERE WITH THEN END

Hình 2.9 Ví dụ 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ở, bao gồm logic bậc nhất và lý thuyết tập hợp, cùng với các kiểu dữ liệu, cho thấy vai trò quan trọng của toán học trong mô hình Event-B.

Các phép toán logic bậc nhất cơ bản bao gồm phép tuyển (∨), phép hội (∧), 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 (∃) Bảng 2.1 trình bày các phép toán này Những phép toán logic cơ sở này được sử dụng để tạo ra các biểu thức logic, được gọi là các vị từ trong các invariants và ràng buộc (guards) của các sự kiện trong mô hình Event-B.

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

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

 Các phép toán tập hợp: phép hợp , phép giao , phép hiệu \, quan hệ bao hàm , quan hệ thuộc 

 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 do người dùng định nghĩa

 Kiểu tập con của một tập ký hiệu là ℙ

Phương pháp chung

Giao diện phần mềm, đặc biệt là trên thiết bị di động, được thiết kế với các đối tượng để người dùng tương tác và lấy thông tin Những đối tượng này sẽ phát sinh sự kiện và hành động được lập trình sẵn để thực hiện các công việc cụ thể khi sự kiện xảy ra Các đối tượng thường gặp bao gồm: Cửa sổ, Text Box, Combo Box, List Box, Radio Button, Check Box, và Report.

Phương pháp mô hình hóa Event-B giúp người phát triển mô hình hóa và kiểm chứng thứ tự xuất hiện của các cửa sổ giao diện, từ đó nâng cao khả năng hiểu biết, kiểm tra tính đúng đắn và phát hiện lỗi không mong muốn Quy trình này bao gồm việc chuyển đổi các thành phần của giao diện như yêu cầu, thuộc tính, đặc tả và ràng buộc thứ tự thực hiện sang các yếu tố trong cấu trúc mô hình Event-B Sau đó, các mô hình được biên tập và kiểm chứng tự động bằng công cụ Rodin, với quy trình tổng quát được minh họa trong sơ đồ Hình 3.1.

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

Phương pháp chi tiết

Dựa trên quy trình tổng quát của phương pháp được trình bày trong Hình 3.1, chúng ta sẽ cụ thể hóa nó thông qua các bước chi tiết hơn như mô tả trong Hình 3.2.

Đặc tả và bản thiết kế của GUI bao gồm các tài liệu chi tiết về thiết kế và yêu cầu chức năng mong muốn cho giao diện Những tài liệu này đóng vai trò quan trọng trong việc xác định các yếu tố cần thiết để xây dựng một giao diện người dùng hiệu quả.

Mô hình GUI trừu tượng là một khái niệm tổng quát cho các giao diện ứng dụng phần mềm, được phát triển dựa trên các định nghĩa chi tiết đã được trình bày trong mục 3.3.

 Mô hình Event-B trừu tƣợng: là mô hình trừu tượng chung có đượ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.1

 Sơ đồ hoạt động: là sơ đồ 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ế

Mô hình Event-B cho ứng dụng cụ thể là quá trình xây dựng mô hình dựa trên các mô hình trừu tượng và các luật chuyển đổi, nhằm ứng dụng cho một trường hợp cụ thể Cách thức xây dựng mô hình sẽ được điều chỉnh tùy thuộc vào loại ứng dụng đang được phát triển.

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

Quy trình chi tiết được mô tả trong Hình 3.2 bao gồm các bước thực hiện sau: Bước đầu tiên là xây dựng mô hình hóa giao diện ứng dụng một cách trừu tượng thông qua các định nghĩa tổng quát Tiếp theo, từ những định nghĩa này, các luật mô hình hóa chuyển đổi được xây dựng để tinh chỉnh mô hình trừu tượng sang mô hình Event-B, tạo ra các quy tắc chuyển đổi cho thành phần giao diện Bước ba và bốn tùy thuộc vào từng giao diện cụ thể, cần mô hình hóa cùng với bản đặc tả thiết kế và các giả thuyết liên quan, từ đó chuyển đổi thành biểu đồ hoạt động của ứng dụng Bước bốn kết hợp sơ đồ hoạt động với đặc tả thiết kế, tham chiếu các luật chuyển đổi để tạo ra mô hình Event-B với các thành phần machine và context Bước năm tham chiếu mô hình đã thu được vào mô hình trừu tượng để đảm bảo tuân thủ các định nghĩa và luật, từ đó tinh chỉnh để có mô hình cuối cùng đưa vào công cụ Rodin Bước sáu sử dụng Rodin để tự động tạo các mục tiêu cần chứng minh và thực hiện kiểm chứng Cuối cùng, bước bảy kết hợp kết quả kiểm chứng với biểu đồ hoạt động ban đầu để đánh giá sự tuân thủ các yêu cầu giao diện và thực hiện các chỉnh sửa cần thiết.

Hình 3.2 Quy trình kiểm chứng chi tiết

Mô hình hóa giao diện phần mềm

Giao diện người dùng của phần mềm bao gồm các cửa sổ và đối tượng trong cửa sổ, cùng với trạng thái của chúng Nó cũng liên quan đến các sự kiện hoặc tập hợp các sự kiện diễn ra trên các đối tượng cửa sổ và các thông báo liên quan.

Chúng ta có thể mô hình hóa và định nghĩa một cách trừu tượng các thành phần của giao diện qua một số định nghĩa như sau:

 Định nghĩa 1: Một giao điện ứng dụng cơ bản là một bộ 6 UI= trong đó G là tập các cửa sổ giao điện, A là tập các hành động,

S là tập các trạng thái, E là tập các sự kiện, C là tập các ràng buộc, M là tập các thông báo

 Định nghĩa 2: Một cửa sổ giao diện là một bộ 7 g ∈ G, g= trong đó P là tập các thuộc tính, A là tập các hành động,

O đại diện cho tập hợp các đối tượng trên giao diện, S_g là tập hợp các trạng thái của cửa sổ, E_g là tập hợp các sự kiện liên quan đến g, C_g là tập hợp các ràng buộc của g, và M_g là tập hợp các thông báo có trong g.

Một đối tượng trên giao diện được định nghĩa là một bộ 5 phần tử, ký hiệu là o = Trong đó, p_o đại diện cho tập các thuộc tính của đối tượng, a_o là tập các hành vi có thể xảy ra, s_o là tập các trạng thái của đối tượng, e_o là tập các sự kiện liên quan đến đối tượng, và c_o là tập các ràng buộc mà đối tượng cần tuân thủ.

Dựa trên các định nghĩa cơ bản, chúng ta có thể xây dựng một bộ luật chuyển đổi nhằm chuyển đổi từ mô hình giao diện ứng dụng sang mô hình trong sự kiện.

B, chuyển đổi được thể hiện trong Bảng 3.1 Các luật chuyển đổi được mô tả cụ thể như sau:

Luật 1 quy định rằng giao diện ứng dụng UI= sẽ được chuyển đổi thành một máy và một ngữ cảnh trừu tượng trong Event-B, ký hiệu là Trong đó, e ∈ E đại diện cho một sự kiện của máy UM.

 Luật 2: Các thuộc tính của cửa sổ và các đối tượng trên cửa sổ sẽ được chuyển thành các biến VARIABLES

Luật 3 quy định rằng các thành phần của giao diện như thuộc tính, cửa sổ, đối tượng và trạng thái sẽ được chuyển đổi thành các hằng số (CONSTANTS) và tập hợp (SET) Đồng thời, các quy định và quy ước liên quan sẽ được xác định thành các tiên đề (AXIOMS) trong ngữ cảnh cụ thể.

 Luật 4: Các ràng buộc về thứ tự xuất hiện của cửa sổ sẽ được chuyển thành các INVARIANTS

Luật 5 quy định rằng khi các sự kiện xảy ra, các hành động của cửa sổ sẽ được chuyển đổi thành các sự kiện EVENT và các Action trong sự kiện của máy trong Event-B.

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

Tên Mô tả Mô hình hóa

Luật 3 Thành phần thuộc tính, trạng thái

Luật 5 Action, sự kiện Event, Action

Công đoạn mô hình hóa này là đi thực hiện bước 1 và 2 trong quy trình Hình 3.2.

Á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

Tổng quan về các ứng dụng trên điện thoại di động

Sự bùng nổ công nghệ thông tin và gia tăng sử dụng điện thoại di động, cùng với cạnh tranh mạnh mẽ trong lĩnh vực này, đã tạo ra sự phát triển mới Lập trình trên thiết bị di động hiện đang trở thành một lĩnh vực đầy tiềm năng.

Hiện nay, Android là lựa chọn lý tưởng cho các nhà phát triển và lập trình viên muốn xây dựng ứng dụng di động nhanh chóng và hiệu quả, nhờ vào tiềm năng thị trường rộng lớn Các nền tảng như iOS, Windows Phone cũng có thể được sử dụng, nhưng Android nổi bật với khả năng tiếp cận người dùng lớn hơn.

Android là hệ điều hành phổ biến với tính bảo mật cao, hỗ trợ công nghệ tiên tiến và tương thích với nhiều phần cứng Được phát triển liên tục bởi Google, Android thu hút đông đảo nhà phát triển nhờ mã nguồn mở và cộng đồng lớn Sự phát triển mạnh mẽ của các ứng dụng game và di động trên nền tảng này là minh chứng cho sự thành công của nó Để phát triển ứng dụng trên Android, lập trình viên cần kiến thức về Java và sử dụng các công cụ như Eclipse, Android Studio, Genymotion cùng với các thư viện JDK và Android SDK, tất cả đều miễn phí cho người phát triển.

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

Các thành phần tạo nên một ứng dụng Android được chia làm 6 loại bao gồm [10]:

Activity là một màn hình duy nhất với giao diện người dùng cho phép người dùng quan sát và tương tác Chẳng hạn, trong một ứng dụng email, có một Activity hiển thị danh sách email, một Activity khác để soạn thảo email, và một Activity bổ sung cung cấp giao diện để đọc email.

Dịch vụ (Service) là một thành phần quan trọng trong hệ điều hành Android, chạy ẩn và không hiển thị cho người dùng thấy Thành phần này thường được sử dụng để cập nhật dữ liệu và đưa ra các cảnh báo (Notification) cần thiết, giúp ứng dụng hoạt động hiệu quả hơn mà không cần tương tác trực tiếp với người dùng.

 Content Provider kho dữ liệu chia sẻ Content Provider được sử dụng để quản lý và chia sẻ dữ liệu giữa các ứng dụng

Intent là nền tảng quan trọng để truyền tải thông báo trong ứng dụng Nó được sử dụng để gửi thông điệp nhằm khởi tạo một Activity hoặc Service, từ đó thực hiện các công việc mong muốn Ví dụ, khi mở một trang web, Intent sẽ được gửi đi để tạo ra một trải nghiệm người dùng mượt mà.

Activity mới hiển thị trang web đó

 Broadcast Receiver thành phần thu nhận các Intent bên ngoài gửi tới

Để phát triển một ứng dụng thay thế cho chức năng gọi điện mặc định trên Android, cần sử dụng một Broadcast Receiver để nhận diện các Intent liên quan đến cuộc gọi đến.

 Notification đưa ra các cảnh báo mà không làm cho các Activity phải ngừng hoạt động

4.1.2 Cơ chế quản lý các Activity

Activity là thành phần quan trọng nhất trong việc xây dựng ứng dụng Android, được quản lý theo dạng stack Khi một Activity mới được khởi tạo, nó sẽ được xếp lên đầu stack và trở thành running activity, trong khi các Activity trước đó sẽ bị tạm dừng Mỗi Activity có thể khởi chạy Activity khác, và khi một Activity mới được khởi chạy, Activity trước đó sẽ bị stop và được lưu vào back stack Khi người dùng nhấn nút back, hệ thống sẽ lấy các Activity đã lưu trong back stack để hiển thị lên màn hình Back stack này hoạt động theo nguyên tắc “vào sau, ra trước”.

Hình 4.1 Cơ chế Back Stack [10]

- active (running): Activity đang hiển thị trên màn hình (foreground)

- paused: Activity vẫn hiển thị (visible) nhưng không thể tương tác (lost focus)

- stop: Activity bị thay thế hoàn toàn bởi Activity mới sẽ tiến đến trạng thái stop

- killed: Khi hệ thống bị thiếu bộ nhớ, nó sẽ giải phóng các tiến trình theo nguyên tắc ưu tiên hoặc khi kết thúc ứng dụng

Vòng đời của một Activity được thể hiện qua sơ đồ Activity State Hình 4.2 [10]

Ứng dụng Note

Trong cuộc sống bận rộn hàng ngày, việc nhớ hết các công việc và sự kiện quan trọng là một thách thức lớn Để khắc phục tình trạng này, ứng dụng tạo ghi chú là một giải pháp hiệu quả Ứng dụng Note, chạy trên nền tảng Android, cung cấp các chức năng cơ bản như thêm, sửa, xóa và xem ghi chú, giúp người dùng quản lý công việc một cách dễ dàng và hiệu quả.

4.2.2 Ứng dụng Note Được xây dựng nhằm mục đích tạo các ghi chú của người dùng với cấu trúc cơ sở dữ liệu gồm một bảng có tên là Note có cấu trúc được mô tả trong Bảng 4.1 [11]

Bảng 4.1: Bảng CSDL ghi chú Note

Tên cột Kiểu dữ liệu Ràng buộc Mô tả

Note_Id int Primary Key Khóa chính

Note_Title text Ghi chú ngắn

Ứng dụng bao gồm bốn cửa sổ giao diện chính, gồm MainActivity, EditActivity, CreateActivity và ViewActivity Trong đó, MainActivity là màn hình giao diện chính xuất hiện đầu tiên khi ứng dụng khởi động.

 Cửa sổ giao diện MainActivity

Giao diện MainActivity bao gồm nhiều đối tượng khác nhau, được tóm tắt trong Bảng 4.2 và có thể được xem chi tiết hơn qua Hình 4.3, là file mã lệnh XML thiết kế cho giao diện này.

Bảng 4.2: Mô tả cửa sổ giao diện MainActivity

ListView Control (hiển thị danh sách các note)

 Cửa sổ giao diện CreateActivity

Cửa sổ giao diện CreateActivity bao gồm nhiều đối tượng khác nhau, được tổng quan hóa trong Bảng 4.3 và có thể được xem chi tiết qua file mã lệnh XML thiết kế giao diện trong Hình 4.4.

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

Event buttonSaveClicked Button_Click buttonCancelClicked Button_Click

 Cửa sổ giao diện EditActivity

Cửa sổ giao diện EditActivity bao gồm nhiều đối tượng khác nhau, được tóm tắt trong Bảng 4.4 và có thể được xem chi tiết hơn qua Hình 4.5, là file mã lệnh XML thiết kế giao diện.

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

Event buttonSaveClicked Button_Click buttonCancelClicked Button_Click

 Cửa sổ giao diện ViewActivity

Cửa sổ giao diện ViewActivity hiển thị các đối tượng khác nhau, được tóm tắt trong Bảng 4.5 và có thể được xem chi tiết hơn qua Hình 4.6, thể hiện file mã lệnh XML thiết kế giao diện.

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