Áp dụng ngôn ngữ lập trình maude việc phát triển phần mềm cho hệ thống nhúng và thời gian thực

Lý do chọn đề tài Trong những năm gần đây, trên thế giới, phương pháp hình thức đã dần được áp dụng vào việc phát triển phần mềm nhúng - vốn là một trong số những đề tài hấp dẫn với các

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

NGUYỄN TIẾN THÀNH

ÁP DỤNG NGÔN NGỮ LẬP TRÌNH MAUDE THEO PHƯƠNG PHÁP HÌNH THỨC VÀO VIỆC PHÁT TRIỂN PHẦN MỀM CHO

MỤC LỤC

MỤC LỤC 2

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT 6

DANH MỤC CÁC BẢNG 7

DANH MỤC HÌNH VẼ 7

LỜI CAM ĐOAN 8

MỞ ĐẦU 9

1 Lý do chọn đề tài 9

2 Lịch sử tìm hiểu 9

3 Mục đích tìm hiểu, đối tượng, phạm vi tìm hiểu của luận văn 10

3.1 Mục đích tìm hiểu 10

3.2 Đối tượng tìm hiểu 10

3.3 Phạm vi tìm hiểu 10

4 Các luận điểm cơ bản và đóng góp mới 11

5 Phương pháp nghiên cứu 11

CHƯƠNG I: TỔNG QUAN 13

1.1 Các hệ thống nhúng và thời gian thực 13

1.1.1 Hệ thống nhúng 13

1.1.2 Phần mềm nhúng 15

1.1.3 Một số đặc thù trong yêu cầu đối với phần mềm nhúng 17

1.1.4 Mô phỏng, giả lập, biên dịch nhúng và gỡ rối nhúng 19

1.1.5 Tìm hiểu về các dự án nhúng đã có 22

1.2 Phương pháp hình thức 24

1.2.1 Tổng quan về phương pháp hình thức 24

1.2.2 Nguyên nhân 27

1.3 Ngôn ngữ lập trình Maude 28

1.3.1 Tổng quan về Maude 28

1.3.2 Nguyên nhân chọn lựa 31

CHƯƠNG II: LẬP TRÌNH PHƯƠNG TRÌNH 33

2.1 Nền tảng đại số 33

2.1.1 Đại số đơn tập hợp 33

2.1.2 Đại số đa tập hợp 34

2.1.3 Tiên đề hóa bằng phương trình 35

2.1.4 Áp dụng phương trình: 38

2.2 Thuật ngữ viết lại 39

2.2.1 Ví dụ 39

2.2.2 Tính dừng 40

2.2.3 Tính hội tụ 41

2.2.4 Tính kết hợp và tính giao hoán 41

2.3 Cơ bản về Maude 42

2.3.1 Ví dụ 42

2.3.2 Tái sử dụng thành phần 45

2.3.3 Tính kết hợp và tính giao hoán 46

2.3.4 Cài đặt và sử dụng Maude 47

2.4 Tập con và phương trình thành viên 48

2.4.1 Tập con 49

2.4.2 Tiên đề thành viên 51

2.5 Lập trình hướng đối tượng 52

2.5.1 Lớp và đối tượng 52

2.5.2 Kế thừa và đa hình 54

2.5.3 Design Pattern 56

2.6 Kiểm chứng mô hình 58

2.6.1 Tính bất biến 59

2.6.2 Kiểm chứng mô hình với tính bất biến 59

2.6.3 Kiểm chứng đường biên: 61

2.6.4 Trừu tượng hóa mô hình 62

2.6.5 Bài toán đối sánh văn bản 63

2.6.6 Phát biểu lại bài toán 65

2.6.7 Kiểm chứng mô hình và chứng minh thuật toán 67

2.7 Logic thời gian tuyến tính 70

2.7.1 Cơ bản về LTL 70

2.7.2 Đối sánh văn bản thời gian thực 73

CHƯƠNG III: PHÁT TRIỂN ỨNG DỤNG NHÚNG 75

3.1 Xây dựng giải pháp đối sánh văn bản cho phần mềm 75

3.1.1 Phát biểu bài toán 75

3.1.2 Giới thiệu link-4.1b 75

3.1.3 Yêu cầu về cấu trúc dữ liệu 76

3.1.4 Sử dụng Visitor Pattern 81

3.2 Thiết kế phần mềm 87

3.2.1 Quyết định về chiến lược thiết kế 88

3.2.2 Quyết định về chiến thuật thiết kế 93

3.2.3 Quyết định về cài đặt 93

3.3 Phát triển phần mềm Listen English on PDA trên N770 93

3.3.1 Các công cụ hỗ trợ cho Maemo SDK 94

3.3.2 Những chú ý trong quá trình sử dụng máy Nokia N770 96

CHƯƠNG IV: KẾT QUẢ VÀ BÀN LUẬN 98

4.1 Kết quả 98

4.2 Bàn luận 100

KẾT LUẬN VÀ KIẾN NGHỊ 102

1 Kết luận 102

2 Kiến nghị 102

TÀI LIỆU THAM KHẢO 104

PHỤ LỤC 105

A Cài đặt bộ giả lập cho Nokia N770 trên máy PC 105

B Nâng quyền người dùng trên thiết bị Nokia N770 110

C Mã nguồn Maude minh họa mẫu thiết kế Visitor Pattern: 112

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT

API Application Programmable Interface - Giao diện lập trình ứng dụng

CMU Carnegie Mellon University - Đại học Carnegie Mellon

CPU Central Processing Unit - Đơn vị xử lý trung tâm

FPGA Field-programmable gate array - Vi mạch dùng cấu trúc mảng phần tử

logic mà người dùng có thể lập trình được GCC GNU Compiler Collections - Tập hợp trình biên dịch GNU

GPL GNU General Public License - Giấy phép Công cộng GNU

HdS Hardware Dependent Software - Phần mềm phụ thuộc phần cứng J2ME Java 2th Mobile Edition - Java, phiên bản thứ hai dành cho di động LTL Linear Temporal Logic - Logic thời gian tuyến tính

NASA National Aeronautics and Space Administration - Cục Quản trị Hàng

không và Không gian Quốc gia

PC Personal Computer - Máy vi tính cá nhân

PDA Personal Digital Assistant - Thiết bị trợ giúp số cá nhân

PVS Prototype Verification System - Hệ thống xác thực mẫu thử

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

RTOS Real Time Operating System - Hệ điều hành thời gian thực

DANH MỤC CÁC BẢNG

Bảng 1.1: So sánh hệ thống nhúng và máy tính thông thường (Desktop) 15

Bảng 2.1 : Lời bình luận về các từ ở trong đoạn văn 64

Bảng 2.2: Lời bình luận về các từ đứng đầu đoạn văn và đứng cuối đoạn văn 64

Bảng 3.1 Các thuộc tính của lớp Element 78

Bảng 3.2: Các thuộc tính của lớp IToken 79

Bảng 3.3: Các phương thức chính của lớp IToken 80

Bảng 3.4: Các quyết định về thiết kế phần mềm 88

Bảng 4.1: So sánh nội dung của văn bản chuẩn và văn bản tự tạo 98

DANH MỤC HÌNH VẼ Hình 2.1: Dạng đệ quy của thuật toán 68

Hình 2.2: Biểu đồ hoạt động của hai tiến trình p, q theo thời gian 71

Hình 2.3: Biểu đồ hoạt động của tiến trình p và tiến trình N p 71

Hình 2.4: Biểu đồ hoạt động của tiến trình p, q và tiến trình p U q 72

Hình 2.5: Biểu đồ hoạt động của tiến trình p và tiến trình <> p 72

Hình 3.1: Cách thức sử dụng link-4.1b: dùng chương trình C++ để chạy công cụ này 76 Hình 3.2: Mô hình của mẫu thiết kế Visitor Pattern 82

Hình 3.3: Visitor và các lớp con của nó 83

Hình 3.4: Cấu trúc của mẫu thiết kế Visitor Pattern .84

Hình 3.5: Cấu trúc của ITokenFactory 84

Hình 3.7: Kiểu dáng kiến trúc đường ống và bộ lọc 89

Hình 3.8: Kiến trúc của Parse theo ngôn ngữ ADL của Acme 90

Hình 3.9: Bên trong của bộ lọc “Init_Tokens” 90

Hình 3.10: Bên trong của bộ lọc “Arrangement_Tokens” 91

Hình 3.11: Bên trong của bộ lọc “Choose_Tokens” 92

Hình 3.12: Bên trong bộ lọc Assign_Tokens 92

LỜI CAM ĐOAN Tôi xin cam đoan luận văn "Áp dụng ngôn ngữ lập trình Maude theo

phương pháp hình thức vào việc phát triển hệ thống nhúng và thời gian thực" do

bản thân thực hiện dưới sự hướng dẫn của Phó giáo sư, Tiến sĩ Huỳnh Quyết Thắng - Viện Công nghệ thông tin và Truyền thông - Trường Đại học Bách khoa Hà Nội, là không sao chép nguyên văn của bất kỳ một luận văn nào đã được công bố Nội dung luận văn có tham khảo và sử dụng các tài liệu, thông tin được đăng tải trên các tác phẩm, tạp chí và các trang web theo danh mục tài liệu tham khảo của luận văn Các kết quả chạy thử nghiệm là số liệu trung thực

Tác giả luận văn

Nguyễn Tiến Thành

MỞ ĐẦU

1 Lý do chọn đề tài

Trong những năm gần đây, trên thế giới, phương pháp hình thức đã dần được áp dụng vào việc phát triển phần mềm nhúng - vốn là một trong số những đề tài hấp dẫn với các đơn vị nghiên cứu, các công ty liên quan đến truyền thông, công nghiệp và các hãng phát triển phần mềm trên toàn thế giới Với mong muốn tìm hiểu những lý thuyết,

kỹ thuật và công nghệ để xây dựng các ứng dụng theo phương pháp đó, tôi đã chọn đề tài cho luận văn là: “Áp dụng ngôn ngữ lập trình Maude theo phương pháp hình thức vào việc phát triển phần mềm cho hệ thống nhúng và thời gian thực”

Tác giả Mike Holloway làm việc trong nhóm phương pháp hình thức của NASA (từ năm 1992) đã từng có tổng kết của mình về việc áp dụng phương pháp hình thức trong phát triển phần mềm trong bài báo: “Why engineers should consider formal methods” vào tháng 10 năm 1997

Năm 1996, nhóm tác giả Manuel Clavel và José Meseguer đã công bố tài liệu đầu tiên về Maude Đến năm 2000, tác giả Olveczky đã công bố tài liệu đầu tiên về đặc

tả và phân tích hệ thống thời gian thực: “Specification and Analysis of Real-Time and Hybrid Systems in Rewriting Logic”

Năm 2002, tác giả Eker và José Meseguer đã công bố tài liệu đầu tiên về logic thời gian tuyến tính với Maude: “The Maude LTL Model Checker” Tiếp thu thành tựu

của các nhà khoa học đi trước, được PGS.TS Huỳnh Quyết Thắng hướng dẫn, tôi đã cố gắng thực hiện đề tài: "Áp dụng ngôn ngữ lập trình Maude theo phương pháp hình thức vào việc phát triển phần mềm cho hệ thống nhúng và thời gian thực"

3 Mục đích tìm hiểu, đối tượng, phạm vi tìm hiểu của luận văn

3.1 Mục đích tìm hiểu

Muốn xây dựng được phần mềm tốt dành cho các thiết bị nhúng, ngoài việc phải

có nguồn nhân lực thành thạo các ngôn ngữ lập trình nhúng và phải tuân thủ theo đúng quy trình phát triển phần mềm nhúng, các dự án phát triển cũng cần phải áp dụng các thành tựu hiện nay của ngành công nghệ phần mềm Việc phát triển phần mềm nhúng,

dù tiến hành trên các thiết bị không phải là thời gian thực, cũng có các đặc thù của riêng nó mà các lập trình viên nếu chỉ quen lập trình trên máy vi tính sẽ rất bất ngờ khi gặp phải vấn đề Trong phạm vi của luận văn, tôi xin trình bày về các quá trình xây dựng một phần mềm nhúng cho thiết bị PDA Nokia N770 Việc xây dựng ứng dụng cho thiết bị này đã áp dụng các lý thuyết của kiến trúc phần mềm, các lý thuyết đặc tả yêu cầu và kiểm chứng mô hình và tuân thủ theo quy trình phát triển phần mềm nhúng

3.2 Đối tượng tìm hiểu

Luận văn tập trung tìm hiểu các vấn đề cơ bản về phương pháp hình thức; lý thuyết của đại số trừu tượng; các công nghệ, giải pháp, công cụ của Maude vào việc xây dựng mô hình toán học cho các ứng dụng phần mềm cụ thể

Với mong muốn giúp đẩy nhanh quá trình học tiếng Anh, luận văn đã có các công sức vào vấn đề đối sánh văn bản và đối sánh văn bản thời gian thực Do giới hạn nên luận văn chỉ phát triển phần mềm đối sánh văn bản cho thiết bị nhúng Nokia N770

3.3 Phạm vi tìm hiểu

Trên cơ sở của mục đích tìm hiểu và đối tượng tìm hiểu, luận văn đã xác định phạm vi tìm hiểu ở phương pháp hình thức về vấn đề nguồn gốc xuất hiện, cơ sở lý thuyết và phạm vi áp dụng của phương pháp hình thức vào việc phát triển phần mềm nói chung Với ngôn ngữ lập trình Maude, luận văn tập trung vào tìm hiểu các vấn đề

cơ bản với Core Maude, các nguyên lý hướng đối tượng của Full Maude và phương pháp áp dụng Real Time Maude Bằng việc ứng dụng mẫu thiết kế Visitor Pattern vào việc xây dựng chương trình Maude, sau đó luận văn đã áp dụng kiểm chứng mô hình vào phân tích Với các bản phân tích đó, đã xây dựng thành công ứng dụng đối sánh văn bản trên thiết bị nhúng Nokia N770

4 Các luận điểm cơ bản và đóng góp mới

Luận văn đã có tìm hiểu về việc áp dụng các nguyên lý của phương pháp hình thức; các nguyên lý, mô hình, công cụ và kỹ thuật của ngôn ngữ lập trình phương trình Maude; kiến trúc phần mềm; các mẫu thiết kế cũng như các lý thuyết của đối sánh văn bản vào trong xây dựng ứng dụng cho thiết bị nhúng Tiếp theo đó là luận văn đã đưa

ra một số giải pháp cho việc mô hình hóa phần mềm, cài đặt thuật toán với ngôn ngữ Maude cũng như áp dụng mô hình của Real time Maude vào việc phân tích với một ứng dụng đề xuất Ứng dụng đề xuất đó cũng nhằm mục đích luyện đọc tiếng Anh nhưng do nhiều nguyên nhân đã khiến cho luận văn chưa thể đưa ra được phần mềm cụ thể mà mới dừng lại ở mức phân tích yêu cầu Đóng góp mới của luận văn là xây dựng được chương trình Maude theo mẫu thiết kế hướng đối tượng Visitor Pattern mà hiện giờ các mẫu thiết kế Design Pattern chưa được đề cập trong các tài liệu về Maude Một đóng góp mới nữa của luận văn là về hai ứng dụng được đề cập đến: cả ứng dụng luyện nghe tiếng Anh và ứng dụng đề xuất luyện đọc tiếng Anh hiện thời chưa xuất hiện trên các trang web học tiếng Anh, chưa có phần mềm xuất hiện trên máy tính cá nhân và chưa có trên thiết bị di động Một đóng góp nữa là lần đầu tiên đã áp dụng phương pháp hình thức cho quá trình phát triển ứng dụng trên thiết bị nhúng Nokia N770

5 Phương pháp nghiên cứu

Sau khi xác định rõ yêu cầu cho ứng dụng, tôi đã thực hiện việc chọn lựa thiết bị nhúng phù hợp Bên cạnh đó, tôi đã sử dụng ngôn ngữ Maude để áp dụng phương pháp hình thức trong đặc tả yêu cầu và kiểm chứng mô hình cho ứng dụng dự định phát triển Phương pháp đọc và tìm hiểu tài liệu được tiến hành chủ yếu sau khi xác định cơ sở lý

luận cho đề tài Để giải quyết tốt vấn đề đặt ra của đề tài, cần tiến hành tìm hiểu lý thuyết về khoa học đánh giá cũng như một số vấn đề về lý thuyết có liên quan đã trình bày trong phần đối tượng tìm hiểu của luận văn Để có thể có được phần mềm trên một thiết bị nhúng thích hợp, tôi đã tìm hiểu các kiến thức trao đổi về kinh nghiệm phát triển phần mềm nhúng và áp dụng được các kiến thức này để có được phần mềm cụ thể

Để xác định được một ứng dụng cụ thể, tôi đã có các suy nghĩ, tìm hiểu để có thể xây dựng được một phần mềm với yêu cầu không quá khó, không quá vượt khả năng của mình cũng như không quá đơn giản để có thể vận dụng các thế mạnh của phương pháp hình thức cũng như ngôn ngữ lập trình Maude

Tôi xin được cảm ơn thầy giáo PGS.TS Huỳnh Quyết Thắng đã tận tình hướng dẫn và tạo điều kiện cho tôi hoàn thành luận văn

và điều khiển Để có thể tồn tại và phát triển, các sản phẩm công nghiệp và tiêu dùng cần phải thường xuyên đổi mới và ngày càng có nhiều chức năng tiện dụng và thông minh hơn Các chức năng này phần lớn do các chương trình nhúng tạo nên Phần mềm nhúng là một lĩnh vực công nghệ then chốt cho sự phát triển kinh tế của nhiều quốc gia trên thế giới như Nhật Bản, Hàn Quốc, Phần Lan và Trung Quốc

1.1.1.1 Khái niệm

Hệ thống nhúng (Embedded system) là một thuật ngữ để chỉ một hệ

thống có khả năng tự trị được nhúng vào trong một môi trường hay một hệ thống mẹ [7] Đó là các hệ thống tích hợp cả phần cứng và phần phềm phục vụ

các bài toán chuyên dụng trong nhiều lĩnh vực công nghiệp, tự động hoá điều

khiển, quan trắc và truyền tin Đặc điểm của các hệ thống nhúng là hoạt động

ổn định và có tính năng tự động hoá cao

Các hệ thống nhúng thường được sản xuất hàng loạt với số lượng lớn Hệ thống nhúng rất đa dạng, phong phú về chủng loại Đó có thể là những thiết bị cầm tay nhỏ gọn như đồng hồ kĩ thuật số và máy chơi nhạc, hoặc những sản phẩm lớn như đèn giao thông, bộ kiểm soát trong nhà máy hoặc hệ thống kiểm soát các máy năng lượng hạt nhân Xét về độ phức tạp, hệ thống nhúng có thể rất đơn giản với một vi điều khiển hoặc rất phức tạp với nhiều đơn vị, các thiết

bị ngoại vi và mạng lưới được nằm gọn trong một lớp vỏ máy lớn

Các thiết bị PDA hoặc máy tính cầm tay cũng có một số đặc điểm tương

tự với hệ thống nhúng như các hệ điều hành hoặc vi xử lý điều khiển chúng nhưng các thiết bị này không phải là hệ thống nhúng thật sự bởi chúng là các thiết bị đa năng, cho phép sử dụng nhiều ứng dụng và kết nối đến nhiều thiết

bị ngoại vi

1.1.1.2 So sánh máy tính thông thường

Bảng sau liệt kê ra một vài điểm khác nhau cơ bản giữa hệ thống nhúng

và hệ thống máy tính thông thường (máy tính desktop) :

- Hạn chế tài nguyên không đáng

kể

- Hạn chế tài nguyên đáng kể : Dung lượng bộ nhớ, tốc độ chip, hiệu năng các thiết bị,…

- Kiến trúc phần cứng đã được

chuẩn hóa, phần mềm mang

tính trừu tượng cao

- Phần cứng chuyên dụng, phần mềm phụ thuộc chặt chẽ vào phần cứng

- Tương tác với môi trường gián

tiếp

- Tương tác với môi trường trực tiếp

- Yêu cầu về ổn định tương đối

(lỗi có thể chấp nhận được) - Yêu cầu về tính ổn định cao (zero-bug)

- Yêu cầu về cài đặt thường

không phức tạp

- Yêu cầu về cài đặt và triển khai phức tạp

- Các ứng dụng thường không

ràng buộc về thời gian

- Các ứng dụng thường là ứng dụng thời gian thực

Bảng 1.1: So sánh hệ thống nhúng và máy tính thông thường (Desktop)

1.1.2 Phần mềm nhúng

Phần mềm nhúng là một chương trình được viết, biên dịch trên máy tính và nạp vào một hệ thống khác (gọi tắt là KIT) bao gồm một hoặc nhiều bộ vi xử lý đã được cài sẵn một hệ điều hành, bộ nhớ ghi chép được, các cổng giao tiếp với các phần cứng khác…

1.1.2.1 Khái niệm

Một hệ thống nhúng có hai phần cấu thành là phần cứng và phần mềm Phần mềm nhúng, nói một cách đơn giản, là phần mềm được thiết kế cho các hệ nhúng và chạy trên các hệ nhúng1

Trong hệ thống nhúng, phần mềm tương tác với khối lõi (CPU) và thông qua

đó cung cấp khả năng điều khiển hoạt động các thành phần khác của hệ thống từ phía người dùng

1.1.2.2 Hệ điều hành thời gian thực:

Hệ điều hành thời gian thực (Real-time operating system- RTOS) là một loại hệ điều hành hoạt động theo kiểu đa nhiệm, có khả năng hỗ trợ việc quản lý

và đồng bộ hóa tiến trình, quản lý bộ nhớ, liên lạc giữa các tiến trình, và vào/ra RTOS được thiết kế để có thể chạy các ứng dụng thời gian thực ở trên đó

• Phần mềm ứng dụng hoặc các middleware2 độc lập phần cứng, chạy bên trên lớp HdS

• RTOS giống như một lớp nằm dọc, nó đưa ra các dịch vụ cho cả các phần phụ thuộc và độc lập phần cứng và có thể được sử dụng bởi các lớp phần mềm nhúng khác

Trong khi phần mềm ứng dụng có tính tái sử dụng và khả chuyển do sự độc lập phần cứng, phần mềm nhúng cũng phải được cấu trúc sao cho đạt đuợc

sự khả chuyển và tái sử dụng Ví dụ, các thuật giải DSP (Digital Signal Processing – xử lý tín hiệu số) được tối ưu hóa cao sẽ sử dụng được đầy đủ ưu thế của mỗi tính năng phần cứng Tuy nhiên, đối với kiểu phần mềm này, các phương án tái sử dụng xem ra khó áp dụng hơn

Những tính chất đặc biệt của phần mềm nhúng ảnh hưởng tới phương pháp thiết kế Sự phụ thuộc phần cứng ám chỉ sự kết hợp giữa việc thiết kế phần mềm nhúng với thiết kế phần cứng

1.1.2.4 Vấn đề thiết kế và phát triển phần mềm nhúng:

Nói chung, quy trình phát triển phần mềm nhúng tương tự như các mẫu phát triển phần mềm cổ điển Thường thì tất cả các pha như đặc tả; thiết kế mức đỉnh; thiết kế chi tiết; thực hiện; kiểm thử đơn vị; tích hợp và kiểm thử tích hợp; lượng giá hệ thống và kiểm thử chấp nhận (acceptance test) đều có mặt Tuy nhiên, tích hợp và kiểm thử tích hợp ở đây chủ yếu ám chỉ sự tích hợp với nền tảng phần cứng Có nhiều công cụ phát triển nổi tiếng trong thế giới phần mềm

đa năng cũng áp dụng được cho phần mềm nhúng

Tuy nhiên, sự quan hệ mật thiết của phần mềm nhúng và nền tảng phần cứng bên dưới đòi hỏi vài công cụ đặc biệt, nhất là trong các trường hợp :

• Biên dịch ở máy chủ và ở máy đích

2 Middleware : phần mềm trung gian, dùng để nối các phần mềm trên các hệ thống khác nhau lại

• Gỡ lỗi bản đích

• Kiểm tra phần cứng và đưa ra

Do bản chất, thiết kế phần mềm nhúng phải sử dụng các công cụ đặc trưng liên quan tới phần cứng như các bộ mô phỏng tập lệnh, mô phỏng và giả lập phần cứng, và trình gỡ lỗi phân tán Thiết kế phần mềm nhúng có nghĩa là ta phải đóng nhiều vai khác nhau trong quá trình thiết kế hệ thống:

• Người thiết kế hệ thống : tách biệt phần cứng – phần mềm

1.1.3 Một số đặc thù trong yêu cầu đối với phần mềm nhúng

Việc phát triển các phần mềm nhúng phải đảm bảo các yêu cầu khắt khe hơn

so với phát triển phần mềm trên máy PC Một phần do thiết bị nhúng có cấu hình thấp hơn so với máy PC, phải đảm bảo việc quản lý bộ nhớ chặt chẽ Một lý do khác nữa là các thiết bị nhúng có thiết kế rất đặc biệt, nhiều thiết bị thậm chí không

có card âm thanh như máy PC mà thay vào đó là tồn tại một bộ vi xử lý tín hiệu số riêng để giải quyết các yêu cầu về đa phương tiện Ngoài ra ở các thiết bị nhúng có

hệ điều hành hoàn chỉnh, chúng ta khi thiết kế ra phần mềm ứng dụng phải tuân thủ chặt chẽ các yêu cầu kiến trúc phần mềm cũng như các tiêu chuẩn đóng gói phần mềm

Như với các thiết bị có cài đặt hệ điều hành Maemo (một phiên bản của hệ điều hành Debian Linux dành cho thiết bị nhúng ) có yêu cầu về cấu trúc của các file mã nguồn của một ứng dụng

1.1.3.1 Yêu cầu của phần mềm nhúng

Yêu cầu của phần mềm nhúng phụ thuộc vào các yêu cầu của hệ nhúng mà

nó được cài đặt / triển khai Có một vài yêu cầu chung nhất đối với các phần mềm nhúng :

• Tính khả chuyển (portability)

• Thời gian thực (real-time)

Dưới đây là những điểm khác nhau quan trọng nhất giữa yêu cầu phát triển phần mềm ứng dụng và phần mềm nhúng :

- Các yêu cầu cụ thể về phần cứng : định thời (timing), thời gian thực, hiệu suất của các hàm truy nhập phần cứng, sự phụ thuộc trực tiếp vào kiến trúc phần cứng

- Việc phát triển của phần mềm nhúng áp dụng sự pha trộn giữa các phương pháp top-down và bottom-up

- Sự đồng bộ phức tạp trong quá trình phát triển toàn bộ sản phẩm

- Phần mềm nhúng thường được yêu cầu chạy trên phần cứng không ổn định hoặc không lệ thuộc phần cứng đến mức có thể được

1.1.3.2 Quy trình phát triển phần mềm nhúng

Quy trình phát triển phần mềm nhúng, tồn tại những pha khác biệt với phần mềm trên các máy tính thông thường Quy trình này luôn phải quan tâm đến việc kiểm thử trên bộ giả lập và sau đó là thiết bị thật để có thể cho ra một phần mềm hoạt động tốt trên thực tế Các pha của quy trình phát triển phần mềm nhúng như sau [9]:

1) Tạo một dự án cho ứng dụng, xác định đầy đủ các tài liệu như đặc tả yêu cầu hệ thống, đặc tả yêu cầu phần mềm, kiến trúc phần mềm …

2) Tạo ra hoặc cập nhật các mã nguồn và các tài nguyên cần thiết

3) Thiết kế các giao diện

4) Biên dịch chương trình ra một bộ có thể chạy trên giả lập

5) Chạy và kiểm thử trên bộ giả lập

6) Sửa các lỗi tồn tại của chương trình

7) Biên dịch chương trình ra một bộ chạy được trên thiết bị thật

8) Chạy và kiểm thử

9) Sửa các lỗi tồn tại của chương trình

10) Đóng gói phần mềm cho thiết bị

11) Cài đặt và sử dụng phần mềm trên thiết bị

1.1.4 Mô phỏng, giả lập, biên dịch nhúng và gỡ rối nhúng

Một trong những điều gây kinh hãi cho các lập trình viên mới chuyển sang làm ở các hệ thống nhúng là sự kém tin cậy cũng như các rắc rối của các bộ mô phỏng, giả lập, biên dịch và gỡ rối nhúng Các bộ này không phải khi nào cũng được thiết kế một cách đúng đắn và chúng chưa thể được đưa vào kiểm thử kỹ càng như các phần mềm chạy trên máy tính thông thường Đến như máy ảo JVM trên thiết bị nhúng [8] cũng bị phàn nàn về các lỗi của nó thì chúng ta cũng sẽ không mấy ngạc nhiên ở các bộ mô phỏng, giả lập, biên dịch và gỡ rối nhúng này Đặc biệt là khi chúng được phát triển bởi các hãng không chuyên về sản xuất phần mềm, phát triển cho các dòng máy không quá phổ biến và lại dựa trên một số nền tảng của cộng đồng mã nguồn mở

1.1.4.1 Mô phỏng và giả lập

Như đã đề cập ở phần trước, hầu hết các phần mềm nhúng được phát triển trên một hệ thống và được cài đặt trên một hệ thống khác Hệ thống được nạp vào gọi là hệ thống đích, nó có các bộ xử lý, bộ vi điều khiển, bộ nhớ,…

Kỹ thuật phát triển phần mềm nhúng được thực hiện dựa vào ý tưởng giả lập (Emulation) và mô phỏng (Simulation)[7]

A Giả lập

Các mạch FPGA được sử dụng để xây dựng hệ thống mô phỏng lại toàn

bộ hành vi của hệ thống đích Khi phát triển, các module phần mềm được tải vào bộ nhớ của hệ thống mô phỏng Mọi thao tác lập trình và gỡ rối sau đó sẽ được thực hiện trên hệ mô phỏng này

B Mô phỏng

Khi xây dựng các thành phần phần mềm, chúng ta không xây dựng trực tiếp trên các thành phần phần cứng Một phần vì trong nhiều trường hợp, thành phần phần mềm và phần cứng được phát triển đồng thời, tại thời điểm phát triển phần mềm, chúng ta mới chỉ có các nguyên mẫu đặc tả phần cứng chứ chưa có một nền tảng hoàn chỉnh Một lý do khác là chi phí xây dựng phần mềm trực tiếp trên hệ thống nhúng thường cao hơn rất nhiều, điều này có thể làm vi phạm yêu cầu về giá thành sản phẩm phần mềm nhúng Để giải quyết vấn đề này, chúng ta thường sử dụng các bộ phần mềm mô phỏng (KIT) được cài đặt trên các máy tính đa năng, để hỗ trợ cho việc lập trình

Thực chất, bộ mô phỏng cũng có các nhược điểm của nó Nhược điểm lớn nhất của nó là do bộ mô phỏng chỉ giả lập bộ xử lý chứ nó không tiến hành xây dựng các giả lập cho các thành phần phần cứng khác của thiết bị Tuy bộ mô phỏng

có những tồn tại như vậy, nhưng nó vẫn có hữu ích khi các dự án phải tiến hành mà các thành phần phần cứng của thiết bị nhúng chưa được sản xuất hoặc được xây dựng xong.[7]

biên dịch này phải đảm bảo không phụ thuộc vào kiến trúc phần cứng đang được triển khai Sau đó, các file object này được liên kết với nhau sử dụng các

bộ liên kết, để tạo thành một file object duy nhất, gọi là chương trình tái cấp phát được Cuối cùng, các địa chỉ bộ nhớ vật lý phải được chuyển tới các offset tương đối trong các chương trình tái cấp phát được, trong một tiến trình gọi là tái cấp phát (relocation)

Tất cả các bộ công cụ hỗ trợ trên: bao gồm trình biên dịch, bộ liên kết và

bộ cấp phát đều được đặt trên các máy tính thông thường [7], [5] Còn bộ gỡ rối,

do đặc thù của lập trình nhúng nên bộ gỡ rối thường phải có mặt trên thiết bị thật Tuy vậy để đề phòng việc bộ gỡ lỗi có thể không hoạt động thật tốt trên mọi thiết bị thật nên các nhà phát triển thường tích hợp luôn trình gỡ rối trên các

bộ giả lập

Các công cụ hỗ trợ đó được cài đặt trên bộ giả lập nhưng bộ giả lập không phải là thành phần tương tác trực tiếp với hệ điều hành của máy tính cá nhân mà

nó tương tác với một bộ hỗ trợ đa nền tảng (cross – platform)

Kết quả của ba bước này là chương trình mã máy có khả năng chạy trên các hệ thống nhúng, có phần đặc tả giống với hệ thống mô phỏng được dùng để thiết kế phần mềm

1.1.4.3 Gỡ rối nhúng

Các lỗi trong phần mềm nhúng có thể đến từ bản thân phần mềm, hoặc do tương tác với các hệ thống phần cứng gặp lỗi Gỡ rối nhúng, do đó, đòi hỏi phải hiểu biết sâu sắc về hệ thống đích mà chương trình sẽ được cài đặt

Đối với các lỗi phía phần mềm, quá trình gỡ rối có thể được thực hiện nhờ vào các bộ gỡ rối (debugger) cài đặt phía KIT

Đối với lỗi phía phần cứng, chúng ta phải sử dụng các kỹ thuật khác để gỡ rối Một kỹ thuật được sử dụng phổ biến trong gỡ rối nhúng là sử dụng đèn LED Các tín hiệu đầu ra của chương trình được sử dụng như các tín hiệu kích hoạt

đèn LED bật hay tắt, nhờ vào đó chúng ta có thể kiểm tra các điểm kiểm tra (checkpoint) trong chương trình đã đạt được hay chưa Bằng cách thử lần lượt với các điểm kiểm tra đáng ngờ,chúng ta có thể thực hiện được các gỡ rối cần thiết cho phần mềm nhúng

1.1.5 Tìm hiểu về các dự án nhúng đã có

Việc tìm hiểu về nguyên nhân thất bại của các dự án lập trình nhúng là một việc rất quan trọng

Theo một số nhà nghiên cứu đúc rút được kinh nghiệm từ các dự án J2ME (dự

án lập trình nhúng cho Mobile sử dụng Java) [8] thì việc lập trình nhúng bản thân

nó tồn tại các khó khăn sau đây:

A Truy xuất các API trong hệ điều hành

Việc không thể truy xuất được dễ dàng các API của hệ điều hành cũng như các tính năng của các ứng dụng này theo các nhà nghiên cứu là do vấn đề bản quyền của các API này cũng như do sự khác biệt tinh vi về hệ điều hành giữa từng nhà sản xuất thiết bị

B Không xác định rõ thiết bị để phát triển ứng dụng

Việc thống nhất các thiết bị đích giữa nhà phát triển và khách hàng trước khi thiết kế và tiến hành giai đoạn đầu của dự án cũng khá quan trọng

Nếu nhắm vào nhiều loại thiết bị, khách hàng thường muốn ứng dụng tận dụng được các tính năng của các thiết bị kỹ thuật cao, trong khi vẫn hỗ trợ được các thiết

bị cũ phổ thông trên thị trường Nếu gặp trường hợp này, phải bảo đảm rằng các tính năng chuyên biệt cho một loại thiết bị đặc thù phải được bàn bạc đồng ý trước với khách hàng Cốt yếu phải nhấn mạnh với khách hàng tầm quan trọng của việc thỏa thuận trước các thiết bị đích Đừng để khách hàng “lén” bổ sung thêm thiết bị

mà không đánh giá được mức độ ảnh hưởng đến dự án

Có những dự án mà khởi đầu khách hàng nhắm vào điện thoại thông minh kỹ thuật cao, sau đó, vào giữa dự án đột nhiên quyết định dự án không có thể đứng

vững trên thị trường trừ phi ứng dụng hoạt động được trên các điện thoại kỹ thuật thấp phổ biến trên thị trường Điều này đặt nhà phát triển vào một vị trí “giật lùi”, bởi vì các khách hàng thường không hiểu được mức tác động lớn đến dự án khi quyết định như vậy

Vì vậy trong đề tài này xác định sẽ chỉ làm việc với một thiết bị nhúng duy nhất mà không nhắm đến các thiết bị nào khác và thiết bị được chọn lựa là PDA của Nokia mang nhãn hiệu N770

C Không xác định rõ các đặc tính của thiết bị:

Khi đã xác định được chủng loại thiết bị nhúng, cần phải có sự hiểu rõ các đặc tính của thiết bị đó Nếu dự án nhắm vào một thiết bị mới mà nhà phát triển có rất ít hoặc không có kinh nghiệm, cần phải nghiên cứu tỉ mỉ, thu thập và prototype trên thiết bị mới

Thường không có các tài liệu kỹ thuật toàn diện cho một thiết bị mới và các tài liệu nếu có lại có thể có lỗi và bị sai sót Bằng cách xác định rõ các đặc tính của thiết bị, nhà phát triển có thể thẩm định các tính năng của thiết bị trước khi bắt đầu triển khai ứng dụng

Nếu người dùng hoặc khách hàng e dè về khả năng phát triển dự án, chúng tôi tiến hành một cuộc nghiên cứu tính khả thi để kiểm tra dự án có thể tiến hành với

độ rủi ro ít nhất Ví dụ, khi bắt đầu chuyển một trò chơi J2ME sang thiết bị khác, phải thực hiện một cuộc nghiên cứu khả thi ngắn để bảo đảm rằng trò chơi có thể thực hiện được trên thiết bị mới với sự khác biệt về giới hạn bộ nhớ/tài nguyên và kích thước/màu màn hình

D Lập trình viên thiếu kiến thức kỹ thuật về thiết bị:

Cũng giống như thiếu kinh nghiệm J2ME, một nhân tố liên quan khác có thể tăng độ rủi ro của dự án là lập trình viên không có đủ kiến thức kỹ thuật và kinh nghiệm thực tế về các thiết bị đích Lập trình viên phải quan tâm đến gói API mở rộng độc quyền có trên thiết bị để có thể đưa ra quyết định thiết kế đúng đắn

Lập trình viên cũng phải quan tâm đến các lỗi thường gặp và các biện pháp né tránh các lỗi này trên thiết bị đích Nhiều lỗi trong việc hoạt động của thiết bị thường làm các lập trình viên gặp bối rối Thực tế có một số biện pháp né tránh các lỗi này, nhưng các lập trình viên thường khó chấp nhận các thủ thuận này cũng như lười tìm hiểu các thủ thuật đó

Ít nhất, lập trình viên phải quan tâm đến trang Web của nhà sản xuất thiết bị, thường sẽ cung cấp các tài liệu kỹ thuật quan trọng và có các diễn đàn mà các lập trình viên có thể thảo luận về các đặc tính riêng của một thiết bị cụ thể

E Kiểm thử sớm và kiểm thử trên thiết bị thật

Số đông các khách hàng và lập trình viên không hiểu được tầm quan trọng của việc kiểm thử trên các thiết bị và mạng thực tế Lập trình viên phải bảo đảm họ kiểm thử sớm và trên thiết bị thật sự-đừng dựa vào các bộ giả lập Kiểm thử trên các tất cả phiên bản firmware bởi vì một thiết bị đơn có thể có nhiều đặc tính khác biệt lớn giữa từng phiên bản của hệ điều hành cũng như của giao diện lập trình ứng dụng (API)

Ngoài ra có sự khác biệt rất lớn giữa bộ giả lập và thiết bị thật sự: đó là sự khác biệt về mục đích sử dụng Bộ giả lập được tạo ra với mục đích là hỗ trợ lập trình viên trong việc phát triển các ứng dụng còn thiết bị thật thì lại được thiết kế cực kỳ dễ dùng cho người dùng bình thường và vắng mặt trên thiết bị thật một số lượng không nhỏ các công cụ cũng như các tính năng của bộ giả lập

1.2 Phương pháp hình thức

Nói đến phương pháp hình thức (formal method) là sẽ đề cập đến các ngôn ngữ, kỹ thuật và công cụ được dựa trên cơ sở của logic toán học Phần này sẽ trình bày tổng quan của phương pháp hình thức cũng như về các lý do sử dụng phương pháp hình thức trong phát triển phần mềm

1.2.1 Tổng quan về phương pháp hình thức

Ý tưởng đầu tiên của việc ứng dụng phương pháp hình thức trong quy trình phát triển phần mềm là bắt nguồn từ việc chứng minh sự đúng đắn của chương trình Các kỹ thuật kiểm thử và mô phỏng cũng đã giúp ích phần nào (cũng phải công nhận rằng đó không phải là nhỏ) trong việc chứng minh tính đúng đắn này; tuy vậy như thế vẫn chưa đủ Trong khi các kỹ thuật kiểm thử và mô phỏng thường là đủ tốt cho các bài tập về nhà dành cho sinh viên về thuật toán sắp xếp hoặc thậm chí là cả

hệ điều hành, các kỹ thuật đó có thể không đủ thỏa mãn cho các hệ thống đặt sự an toàn lên trên hết như các nhà máy điện hạt nhân Để đảm bảo tính chính xác của một chương trình, một trong những điều đầu tiên sẽ phải nói là những tính chất nào

mà chương trình phải đáp ứng (Ví dụ như: "Các bộ điều khiển sẽ đóng cửa các nhà máy điện không quá x giây sau khi nhiệt độ đạt đến độ y.") Những yêu cầu này chính xác đến độ có thể được đưa về dạng một công thức toán học Các kỹ thuật toán học (như logic Hoare) có thể được sử dụng để chứng minh rằng chương trình

là đã đảm bảo chính xác các yêu cầu từ phía hệ thống (Quá trình này được gọi là xác minh chương trình - program verification) Tuy nhiên, có vẻ như các lỗi sẽ có thể lẻn vào các chương trình, các giấy tờ chứng minh vẫn có thể là sai ở chỗ nào đó, ngụ ý rằng một “chương trình bảo đảm đúng” có thể không được chính xác sau tất

cả Vì vậy, kỹ thuật xác minh chương trình được hình thức hóa như là tập hợp các quy tắc logic, và chương trình máy tính, được gọi là trình kiểm chứng, đã được phát triển để kiểm tra xem một bằng chứng đã cho liệu có phải là chính xác theo các quy tắc logic Bước tiếp theo là sử dụng định lý để chứng minh, không chỉ để kiểm tra một bằng chứng đã nắm chắc trong tay, mà là để thực sự chứng minh một chương trình nào đó là chính xác Tuy nhiên, tính chất thú vị nhất của chương trình máy tính là không thể tự quyết định được Điều này có nghĩa rằng không có chương trình máy tính mà luôn luôn có thể tựu chứng minh được rằng có một chương trình

đã cho đã đáp ứng được một tính chất nhất định Trong thực tế, con người phải giúp máy tính chứng minh theo những cách khá tinh vi Những con người thực hiện việc

chứng minh đó phải có kiến thức về logic và về chứng minh định lý, cũng như sự hiểu biết sâu sắc của chương trình được giao để phân tích

Việc xác minh chương trình đã giải quyết được phần nào vấn đề trong thực tế

Nó khá khó để xác minh (tự động hoặc "bằng tay") các chương trình dù thậm chí khá nhỏ, một sự thực mà sẽ làm giảm lòng tin vào khả năng chứng minh các chương trình thực sự lớn, phức tạp và đòi hỏi sự chính xác cao Đối với điều này thì

ta nhận thức được rằng việc xác minh chương trình như thế là vô ích Trong khi những kỳ vọng lạc quan nhất ban đầu dành cho xác minh chương trình có thể không được hiện thực hóa, thì các nghiên cứu về xác minh chương trình đã mang lại nhiều

"tác dụng phụ" quan trọng Ví dụ, trong sự phát triển của ngôn ngữ lập trình và phương pháp luận lập trình Hơn nữa, tính hữu ích của xác minh chương trình, đặc biệt là dành cho quá trình phát triển của hệ thống an toàn là quan trọng (safety-critical system), đang dần dần được hiện thực hóa trong ngành công nghiệp Ví dụ,

hệ thống PVS (Prototype Verification System) của học viện SRI có thể đã phát hiện các "lỗi Pentium" trong quá trình lặp đi lặp lại của việc xác minh hình thức Hơn nữa, không chắc rằng các phương pháp kiểm thử tiêu chuẩn sẽ xác định được lỗi Các dự án công nghiệp về xác minh hình thức, bằng cách sử dụng PVS đã tinh tế phát hiện được lỗi trong bộ vi xử lý AAAMP5 của hãng Rockwell và từ đó phát hiện ra khả năng thành công của hệ thống điều khiển phóng tàu con thoi Một số cơ quan chính phủ Mỹ hiện nay đòi hỏi sử dụng các phương pháp hình thức để xác nhận và đặc tả các thành phần trong hệ thống an toàn quan trọng

Kiểm chứng mô hình là việc xác minh chương trình của các hệ thống hữu hạn trạng thái và đã được gọi là một "câu chuyện thành công tuyệt vời." Trái ngược với xác minh chương trình "thông thường", kiểm chứng mô hình là tự quyết định được: Chỉ cần nhập vào chương trình và đưa ra tiêu chuẩn đúng đắn, và các mô hình kiểm tra tự động sẽ cho biết chương trình của bạn là chính xác hay không? Hiện tại [10], kiểm chứng mô hình chưa thực sự ấn tượng và có tiếng vang lắm (trong một hệ

thống hữu hạn trạng thái chúng tôi chỉ có thể liệt kê tất cả các trạng thái và kiểm tra lại các hành vi có thể) Có điều là chúng ta nên biết rằng, hiện nay kiểm chứng mô hình có thể xử lý hệ thống với hơn 10120 trạng thái Kiểm chứng mô hình đã được

áp dụng thành công trong cả quy trình thiết kế các bộ bán dẫn tiên tiến, trong viễn thông và các giao thức gắn kết bộ nhớ cache như giao thức IEEE + Futurebus Nhiều nhà sản xuất bộ vi xử lý đã có trình kiểm chứng mô hình của riêng mình

1.2.2 Nguyên nhân

Xác minh chương trình là bây giờ chỉ là một phần của "phương pháp hình thức" Có những tác giả [10] đã tin rằng phương pháp hình thức đang trở nên rất quan trọng cho sự phát triển của hệ thống phần mềm hiện tại và tương lai sẽ được

áp dụng cho những hệ thống phức tạp như phân tán, di động, hành vi thời gian thực,… Thật vậy, một trong những đóng góp chính của phương pháp hình thức có thể là "trừu tượng hóa" mô hình, với nó, nó sẽ trừu tượng từ các chi tiết - phương pháp hình thức hỗ trợ điều đó, mà làm cho phương pháp đó trên thực tế có thể mô hình hóa và hiểu/phân tích các hệ thống phức tạp Ví dụ, một giao thức giao tiếp tinh vi là khó để có thể hiểu và giải thích cả về những quy trình chi tiết của một tin nhắn đơn được thực sự truyền đi như thế nào Để tập trung vào các khía cạnh thiết

kế giao thức, chúng ta sẽ trừu tượng từ các mô hình chi tiết và trừu tượng quá trình truyền tin nhắn bởi hai trạng thái "đang truyền tin" và "mất tin nhắn"

Các ngôn ngữ thuộc loại phương pháp hình thức được minh chứng về sự khả năng thực thi mạnh mẽ của nó cũng như các mô hình toán học được nhóm ngôn ngữ lập trình này xây dựng để cung cấp một mức độ trừu tượng cao với sự bắt nguồn từ mức chi tiết Nhóm ngôn ngữ hình thức này có thể được coi là một cải tiến hơn nữa trong chuỗi các ngôn ngữ lập tình đang ngày càng trở nên trừu tượng (hoặc

"cao cấp") bắt đầu với lập trình bằng ngôn ngữ máy tính nhị phân, nhóm các ngôn ngữ Assembly, các ngôn ngữ như C, và Java, … Trong mỗi bước tiến hóa như vậy, việc "làm mịn" các ngôn ngữ lập trình được tiếp tục để loại bỏ bớt các liên quan

đến nền tảng của phần cứng máy tính, do đó chúng ta dần dần mất quyền kiểm soát các tài nguyên của máy - tất nhiên là có thể dẫn đến chương trình thực hiện chậm hơn và tốn nhiều bộ nhớ hơn - tuy vậy, sẽ làm cho nó khả thi để phát triển cho các

hệ thống vốn đã ngày càng thêm phức tạp hơn và tinh vi hơn

Để hiểu hoặc đặc tả những gì mà chương trình phải làm, chúng ta phải biết ý nghĩa về cấu trúc của ngôn ngữ lập trình Ý nghĩa này được gọi là ngữ nghĩa Ngữ nghĩa của một ngôn ngữ lập trình bắt buộc về cơ bản tập hợp các quy tắc để thao tác như thế nào với bộ nhớ máy tính Các lý do khiến phải quan tâm về bộ nhớ máy tính như vậy là vì tồn tại các ngôn ngữ phải thao tác với các vị trí bộ nhớ, thường là thao tác với các biến và các con trỏ Điều này là có thể giúp ích cho việc làm bài tập

về nhà của sinh viên, nhưng có lẽ chưa phù hợp về mặt lý luận của các hệ thống phân tán phức tạp Ngữ nghĩa của một đặc tả hình thức thường được coi là một mô hình toán học rõ ràng, được xây dựng như là một đại số, gồm một số tập hợp và/hoặc một số hàm Nó sẽ khiến việc lập trình trở nên dễ dàng hơn nhiều vì lý do chỉ cần quan tâm đến các mô hình toán học trừu tượng hơn là về việc bộ nhớ máy tính được cập nhật như nào, ở đâu, và tại sao? Như vậy, sau khi đã có các mô hình toán học trừu tượng mô phỏng hệ thống, các chức năng và ràng buộc của hệ thống, chúng ta có thể sử dụng nhiều công cụ toán học khác nhau để xác minh nó, để kiểm chứng mô hình nó, cũng như có thể chứng minh tự động những định lý về hệ thống

tại học viện quốc tế SRI (Giáo sư Meseguer hiện đang làm việc tại Đại học Illinois

ở Urbana-Champaign.) Maude là một công cụ hình thức được đánh giá là “tuyệt vời” trong các lĩnh vực của đặc tả đại số [6] và mô hình hóa các hệ thống tương tranh

Ngôn ngữ Maude có định nghĩa các lý thuyết logic viết lại Các kiểu dữ liệu được định nghĩa bởi phương trình đại số và các hành vi động của một hệ thống được định nghĩa bởi các luật viết lại trong đó mô tả một phần nào một trạng thái có thể thay đổi trong một bước Maude hỗ trợ lập trình hướng đối tượng, bao gồm đa

kế thừa và truyền thông không đồng bộ thông qua truyền thông điệp

Trình thông dịch Maude thực thi chương trình phương trình Maude bằng cách bắt đầu với một "biểu thức ban đầu" và áp dụng các phương trình theo quy tắc "từ trái sang phải," cho đến khi không thể áp dụng được phương trình nữa, từ đó tính toán theo hình thức bình thường (hoặc tính "giá trị") của biểu thức Trình thông dịch Maude còn có thể thực hiện việc viết lại chương trình bằng cách, "tự ý" xin viết lại các luật (cũng "từ trái sang phải”) trên biểu thức/trạng thái ban đầu đã cho, cho đến khi luật không thể được áp dụng được nữa hoặc cho đến khi ràng buộc (do người sử dụng quy định) về số lượng thao tác viết lại đã được đạt tới (Các phương trình được áp dụng để viết lại các trạng thái trung gian nhằm đưa về dạng chuẩn của phương trình trước khi một quy tắc viết lại được áp dụng) Lưu ý rằng theo cách này, trình thông dịch chỉ thực hiện một trong các hành vi khác nhau có thể đạt đến

từ nhiều trạng thái ban đầu Nhóm phát triển Maude còn tập trung vào hiệu năng; các phiên bản hiện tại của trình thông dịch có thể thực hiện hàng triệu thao tác viết lại trong một giây, làm cho Maude có thể cạnh tranh về mặt hiệu năng với các ngôn ngữ lập trình thuộc nhóm phương pháp hình thức khác có chung mục đích chung Trong Maude cũng tồn tại hàng loạt các công cụ hỗ trợ cho việc lập trình, kiểm chứng, gỡ rối,… để lập trình viên có thể phát triển các chương trình dễ dàng hơn

Cuối cùng, Maude được cung cấp các thư viện socket hỗ trợ cho lập trình mạng, để chúng ta có thể không chỉ mô hình mô phỏng và phân tích một hệ thống phân tán, mà thực sự phát triển các chương trình phân tán ở trong Maude

Các nhà phát triển Maude nói đến việc sử dụng Maude như là một ngôn ngữ tạo nguyên mẫu cấp cao, trong đó một nguyên mẫu của một hệ thống phần mềm phức tạp có thể được nhanh chóng phát triển, phân tích, và thảo luận để đúc rút kinh nghiệm trước khi một sản phẩm "kết thúc" hạng nặng được xây dựng Nền tảng của Maude, như đã đề cập, làm gồm một nhóm các công cụ rất phức tạp trong đó sử dụng các loại kỹ thuật để cải thiện hiệu suất và sự dễ dàng cho việc đặc tả các hệ thống Việc mở rộng hỗ trợ của Maude cho các đặc điểm của kỹ thuật lập trình hướng đối tượng chưa được tích hợp sẵn Thay vào đó, một nguyên mẫu mở rộng của Maude, được gọi là Full Maude, đã được quy định tại Maude Nguyên mẫu này

có thể giúp các chương trình Maude được xây dựng, phân tích, và sửa đổi khá nhanh chóng một khi người ta bắt đầu sử dụng nó Hiện giờ, sau khi đã có nhiều kinh nghiệm thu được về cách quản lý các đặc điểm kỹ thuật hướng đối tượng trong Maude, cũng như các hiệu quả hỗ trợ cho các đặc điểm kỹ thuật như vậy sẽ được xây dựng vào công cụ Core Maude bằng cách sử dụng C + + và mã máy nhằm đạt được một hiệu suất tối ưu nhất Ngoài ra, ở trường hợp chiến lược lập trình tham số (parameterized programming), nó đã có thể áp dụng được trong Core Maude Và thậm chí người sử dụng có thể viết chiến lược của riêng mình bằng cách sử dụng Maude meta-programming, và tất nhiên họ chỉ làm điều đó sau khi học được những

gì là hữu ích và thường dùng ở tất cả các chiến lược Nếu cách tối ưu hóa các phiên bản của họ là thật sự có ích thì khi có sự cho phép của những tác giả đó, những cải tiến của họ có thể sẽ được tích hợp vào công cụ Maude

Cho đến nay, các lĩnh vực ứng dụng chính của Maude bao gồm: một là đặc tả

kỹ thuật và phân tích nhiều hệ thống an ninh khác nhau và các giao thức truyền thông mạng; thứ hai là tạo mẫu hình cho các ngôn ngữ lập trình (ở phần mở rộng

của Maude để đối phó với các chiến lược, các đối tượng, hệ thống thời gian thực, tính toán di trú, ); thứ ba là mô hình các tế bào sinh học để mô phỏng và phân tích các phản ứng sinh học; thứ tư: đã có một chương trình Maude thực sự được phát triển tại NASA để xác định vị trí của các đối tượng trong không gian; thứ năm là:

đã phát hiện một số lỗi trong phần mềm nhúng và đã được sử dụng bởi các nhà sản xuất xe hơi lớn; thứ sáu là: phân tích hiệu quả các chương trình Java…

1.3.2 Nguyên nhân chọn lựa

Tại sao chúng ta lại cần phải chọn Maude như một công cụ hình thức cho các

hệ thống phân tán? Các lợi thế trực quan chính của công cụ Maude này là nó có thể giúp việc mô hình hóa cấp cao cho một hệ thống và hỗ trợ cho một loạt các kỹ thuật xác nhận (bao gồm cả xây dựng mẫu, thăm dò không gian các trạng thái, kiểm chứng mô hình logic thời gian, chiến lược phân tích cụ thể) Maude chiếm vai trò trung gian giữa kiểm chứng mô hình và chứng minh định lý Trong khi người kiểm chứng mô hình có thể tự động xác minh một đặc điểm kỹ thuật, họ thường chỉ có thể làm như vậy trên các hệ thống hữu hạn trạng thái theo mô hình sử dụng một số hình thức hạn chế như, ví dụ như otomat hữu hạn, Nhiều hệ thống tinh vi có thể không được thuận tiện trong việc hình thức hóa như thế Mặt khác, các chứng minh định lý tự động có khả năng mô hình hóa đầy đủ nhưng, như đã đề cập, khó khăn và tốn kém và không nên được thực hiện trước khi đã áp dụng sơ qua các kỹ thuật xác thực như tạo mẫu và tìm kiếm và các kỹ thuật này đã phát hiện ra hầu hết các lỗi

Kỹ thuật đặc tả của Maude là khá trực quan Các phần tĩnh của một hệ thống được mô tả bởi các phương trình, mà chúng ta đã biết như phương trình toán học ((x + y)2 = x2 +2xy + y2), vật lý (E = mc2), hoặc như fac(n) = if (n>1) then n*fac(n-1) else 1 Các thành phần động của một hệ thống được mô tả bằng cách các quy tắc viết lại, mà chủ yếu đó là các "phương trình một chiều." Với Maude thì không có khó khăn khi xây dựng cho các hệ thống tương tranh hoặc truyền thông Maude có thể mô phỏng các hoạt động của các tiến trình dưới dạng đại số hay các mạng Petri

để mô tả hành vi động của hệ thống Các lý do khác để giải thích tại sao Maude có thể xứng đáng được áp dụng trong việc phát triển phần mềm bao gồm:

- Ở Maude, sự hỗ trợ của lập trình hướng đối tượng được đánh giá là tốt hơn

so với ở các ngôn ngữ khác cũng thuộc phương pháp chính thức

- Các chương trình của Maude cũng như các công cụ của Maude có hiệu suất cao và vững mạnh với cú pháp tương đối trực quan

- Người sử dụng có thể đóng góp nhiều vào việc định ra các quy tắc, định đề, nguyên lý lập trình bằng việc áp dụng kỹ thuật thú vị meta programming, mà còn cho phép cho một loạt các kỹ thuật mô phỏng và phân tích

- Công cụ này được liên tục mở rộng và cải thiện bởi nhóm nghiên cứu vững mạnh [10]

- Đã có một số lượng các kinh nghiệm hợp lý về việc sử dụng các công cụ của Maude cho các nhiệm vụ xây dựng mô hình lớn

CHƯƠNG II: LẬP TRÌNH PHƯƠNG TRÌNH

2.1 Nền tảng đại số

Phương pháp hình thức dựa trên nền tảng là Đại số phổ dụng (Universal Algebra) Phần này sẽ trình bày về một số các khái niệm cơ bản của ngành đại số này và giới thiệu khái niệm tiên đề hóa Đại số phổ dụng vốn là một ngành đại số khá tổng quan và trừu tượng, tuy vậy phương pháp hình thức lại dựa trên ngành đại số này để đưa ra các ứng dụng thực tế cho việc phát triển phần mềm Trong Đại số phổ dụng thì một đại số được đặc trưng bởi: Các tập hợp; các toán tử trên các tập hợp; các phương trình liên quan đến các toán tử - trong đó các phương trình là kết quả của sự tiên đề hóa (không chứng minh) trên các toán tử và các tập hợp

2.1.1 Đại số đơn tập hợp

Đại số đơn tập hợp, đơn giản là một đại số chỉ có một tập hợp trên nó Trong một tập hợp đó, các phần tử đều là cùng kiểu với nhau Tồn tại các toán tử dành cho một tập hợp sao cho việc áp dụng toán tử đó cho các phần tử của tập hợp thì ta vẫn đạt được một phần tử mới thuộc tập hợp đã xác định

là chữ ký Chữ ký được dùng để phân biệt các đại số khác nhau và chữ ký được tạo thành từ tên của tập hợp và danh sách các toán tử Tuy vậy chữ ký không phải là đại

số Một chữ ký không chứa bất kỳ thông tin về các hằng số và mối liên hệ giữa các toán tử Trong trường hợp này, nó là khá rõ ràng rằng 'Nat' là số tự nhiên, "0" là số

tự nhiên bằng không, và 'Succ' là chức năng +1 Tuy nhiên, sự hiểu biết dựa vào kiến thức của chúng ta về ngữ nghĩa (ý nghĩa) thường gắn liền với những tên đặc biệt - không có gì trong định nghĩa thực sự cho chúng ta điều này Chữ ký hiện nay được sử dụng rộng rãi trong cộng đồng đại số - tuy nhiên, nó cũng xuất hiện (có nghĩa là điều tương tự) trong cộng đồng lập trình hướng đối tượng (đặc biệt là Java)

Đó là, cú pháp (tên, số lượng và danh sách của đối số, kiểu giá trị trả về) của một phương thức) mà không cần tham chiếu đến những nội dung bên trong - cách khác, chữ ký là một giao diện: có cú pháp mà không có ý nghĩa Ở phần sau sẽ xem xét làm thế nào để mở rộng chữ ký với ý nghĩa (để phục vụ cho đại số) sử dụng phương trình sau này Chúng ta cần chú ý rằng mã nguồn ở ngay trên không phải là mã nguồn của ngôn ngữ lập trình Maude trong luận văn Khái niệm tiếp theo chúng ta cần đề cập đó là hằng số: Hằng số là một toán tử đặc biệt không có đối số Chính vì

lý do không có đối số mà giá trị trả về của toán tử này luôn không đổi - hay nói cách khác, đây là hằng số

Algebra Bool is

sort Bool

ops tt ff : -> Bool

op not : Bool -> Bool

ops and or : Bool Bool -> Bool

end Algebra

Đại số Bool này có một tập hợp, hai hằng số và ba toán tử; trong đó hằng số tt

và ff có thể hiểu ngầm định là đại diện cho true và false

trả về bất kỳ phần tử nào của một tập hợp trong đại số Ví dụ khi kết hợp hai đại số đơn tập hợp như trên về lại thành một đại số đa tập hợp

Algebra NatBool is

sorts Nat Bool

op 0 : -> Nat

ops tt ff : -> Bool

op Succ : Nat -> Nat

op not : Bool -> Bool

ops and or : Bool Bool -> Bool

op if : Bool Nat Nat -> Nat

end Algebra

Thực ra ở đây, lập trình viên có thể tái sử dụng mã nguồn bằng cách viết câu

lệnh “include” hai đại số đơn tập hợp vốn đã có sẵn (đã được xây dựng ở trên)

Algebra NatBool is

including Nat

including Bool

sorts Nat Bool

op if : Bool Nat Nat -> Nat

end Algebra

Ở đây ta sẽ thấy có một số tình trạng cần phải bàn với thao tác “tái sử dụng”

mã nguồn: đó là việc được phép sửa hay không được phép sửa những nội dung bên trong của các toán tử Chính vì sự phân biệt giữa các chính sách này mà về sau khi

“tái sử dụng” lại mã nguồn ở phương pháp hình thức sẽ có các tùy chọn khác nhau: including, protecting, importing

2.1.3 Tiên đề hóa bằng phương trình

Hãy xem xét lại ví dụ của đại số Bool ở trên, chúng ta có thể thiết lập mối quan hệ giữa các toán tử khác nhau bằng một phương trình hoặc một số phương

trình Trong một phương trình có thể có một hoặc nhiều toán tử khác nhau bên trong Vậy tại sao lại gọi đây là các tiên đề? Thứ nhất là việc thiết lập mối quan hệ giữa các toán tử này không cần chứng minh - tất nhiên là các phương trình này cũng phải thỏa mãn tính dừng và tính hội tụ mà sẽ được thảo luận sau Thứ hai là bất kỳ khi nào hệ thống gặp một biểu thức giống với dạng của vế trái phương trình thì phải lập tức chuyển các biến và các toán tử ở vế trái sang dạng của vế phải Ví

dụ ta có thể định nghĩa một phương trình với toán tử not như sau:

not(not(a)) = a

Vậy kể từ đây bất kỳ khi nào chúng ta gặp biểu thức có dạng not(not(a))

ta sẽ chuyển nó về dạng a như đã định nghĩa ở phương trình trên Các toán tử có mối liên hệ với nhau thông qua phương trình không có điều kiện và/hoặc có điều kiện như sau: dạng X = Y hoặc có dạng X = Y if Z Bây giờ ta sẽ xét ví dụ sau

Algebra Bool is

sort Bool

ops tt ff : -> Bool

op not : Bool -> Bool

ops and or : Bool Bool -> Bool

toán tử and có dạng and(tt, A) = A hoặc có dạng tt and A = A thì điều này cũng

hoàn toàn hợp lệ đối với phương pháp hình thức Người lập trình có thể thoải mái chọn lựa cấu trúc nào hợp lý và dễ hiểu Cuối cùng là việc có thể xây dựng một hay nhiều hằng số là tùy ý dựa trên cơ sở sử dụng các toán tử không có tham số

Sau đây chúng ta sẽ xem xét đến việc sử dụng phương trình có điều kiện trong phương pháp hình thức qua ví dụ dưới:

Algebra NatBool is

including Nat including Bool sorts Nat Bool

op if : Bool Nat Nat -> Nat var B : Bool

vars X Y : Nat ceq if(B,X,Y) = X if B == tt ceq if(B,X,Y) = Y if B == ff end Algebra

Ở đây ceq chính là các phương trình có điều kiện và toán tử == dùng để so sánh bằng giữa hai biến khác nhau, giá trị trả về của toán tử == là giá trị logic Một

điều cần chú ý ở đây là sự cần thiết phải đảm bảo sự chính xác giữa việc khai báo phương trình và hiện thực hóa phương trình; tức là nếu phương trình đã được viết là

ceq thì bắt buộc phải có toán tử if để so sánh cũng như nếu phương trình đã được

viết là eq thì bắt buộc phải không có toán tử điều kiện so sánh ở sau

op Succ : Nat -> Nat

op _+_ : Nat Nat -> Nat

mục đích thực hiện việc tối thiểu hóa biểu thức nào đó, đưa về dạng tối giản hoặc một giá trị cụ thể

2.2 Thuật ngữ viết lại

Với phần 2.1 ở trên chúng ta đã có khái niệm cơ bản về thuật ngữ chữ ký của một đại số và việc một đại số chứa đựng các phép tiên đề hóa bằng phương trình để nhằm cài đặt cụ thể nội dung của chữ ký Tuy vậy không phải mọi phương trình viết ra đều là hợp lệ hoặc có phương trình là hợp lệ nhưng việc tuân thủ phương trình đó sẽ gây ra các hậu quả không đáng có đối với quá trình chuyển đổi biểu thức Phần 2.2 này sẽ trình bày về thuật ngữ “viết lại” cũng như nêu bật các điều kiện cần và đủ để một phương trình có thể được dùng để “viết lại” biểu thức

Logic viết lại (rewriting logic) được đề xuất lần đầu tiên bởi giáo sư José Meseguer [6] Với hình thức logic này, nếu chúng ta diễn đạt hệ thống bằng các phương trình thì

có nghĩa là chúng ta đang sử dụng logic phương trình “viết lại”: thay thế vế trái của phương trình bằng vế phải của phương trình đó Tuy nhiên có một điều kiện cần đó là

số lượng các biến ở vế phải bắt buộc bé hơn số lượng các biến của vế trái

2.2.1 Ví dụ

Tưởng tượng một đại số Bool có chữ ký như sau:

signature Boolean is

sort Bool

ops true, false : Bool op not : Bool -> Bool

op or : Bool Bool -> Bool

end

Chú ý rằng đây vẫn là chương trình giả Maude chứ không phải là chương trình viết bằng ngôn ngữ lập trình Maude thực sự Ở đây ta xây dựng một đại số có chứa các tập phương trình như sau:

vars X, Y, Z : Bool

not(not(X)) = X not(true) = false not(false) = true

X or X = X X or Y = Y or X X or true = true

X or false = X (X or Y) or Z = X or (Y or Z)

Với một biểu thức cho trước, chẳng hạn như (not(true) or false) hoặc (true or

not(false)), chúng ta sẽ áp dụng các phương trình nào trong số các phương trình ở ví

dụ trên để giản lược (tức là “viết lại”) biểu thức đó Do vậy

(not(true) or false), sẽ thành not(true), vì X or false = X

Và not(true) -> false

Xu hướng của các phương trình trong phương pháp hình thức đều là: Dần dần, từng bước một làm giảm số lượng các biến của một biểu thức, và mục đích đưa ra được kết quả cuối cùng là một giá trị cụ thể nào đó (hoặc một tập giá trị cụ thể)

Tất nhiên chúng ta sẽ có một cách chuyển đổi khác như sau:

(not(true) or false), sẽ thành false or false, vì not(true)

= false Và false or false -> false

Hoặc với biểu thức như sau:

(true or not(false)) sẽ viết lại thành (not(false) or true), vì X or Y = Y or X Và (not(false) or true) -> true, vì X or true = true

Ở đây ta thấy tồn tại nhiều cách thức khác nhau để viết lại một biểu thức đã cho và điều may mắn là các cách thức đó dành cho biểu thức này đều khiến biểu thức được “viết lại” thành một giá trị cụ thể Nếu không phải biểu thức đó hoặc các phương trình đó thì có thể ta sẽ gặp phải hàng loạt các cách thức khác nhau lại dẫn đến các kết quả khác nhau, thậm chí là không ra kết quả

2.2.2 Tính dừng

Với biểu thức true or not(false) (áp dụng X or Y = Y or X) để nhận được

not(false) or true Theo như cách chuyển biến ở trên, ta sẽ viết lại để đưa về giá trị

cụ thể Nhưng đó là việc ta “cố ý”, còn trong trường hợp ở đây, nếu tiếp tục áp dụng phương trình X or Y = Y or X thì sẽ gặp phải một vòng lặp vô hạn - chuyển

thành true or not(false) Như vậy nếu ta không xây dựng phương trình thích hợp, thì