Nghiên cứu ứng dụng “NModel” trong việc phát triển hệ thống nhúng thời gian thực

Thông thường, một cách rất phổ biến để kiểm thử phần mềm cho hệ thống nhúng nói chung đó là chạy phần mềm trên chương trình giả lập phần cứng, chương trình giả lập ở đây có thể là một vi

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ HẠNH

NGHIÊN CỨU ỨNG DỤNG “NMODEL” TRONG VIỆC PHÁT

TRIỂN HỆ THỐNG NHÚNG THỜI GIAN THỰC

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội - Năm 2014

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ HẠNH

NGHIÊN CỨU ỨNG DỤNG “NMODEL” TRONG VIỆC PHÁT

TRIỂN HỆ THỐNG NHÚNG THỜI GIAN THỰC

Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS TS Đặng Văn Đức

Hà Nội - Năm 2014

LỜI CAM ĐOAN

Tôi xin cam đoan rằng nội dung và những kết quả của luận văn tốt nghiệp này

là do tôi tự nghiên cứu dưới sự hướng dẫn của PGS.TS Đặng Văn Đức Trong toàn bộ nội dung của luận văn, những điều được trình bày là của cá nhân tôi hoặc được tổng hợp từ nhiều nguồn tài liệu khác Tất cả các tài liệu tham khảo đều được trích dẫn rõ ràng ở phần cuối của luận văn

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời cam đoan của mình

Hà Nội, ngày 10 tháng 06 năm 2014

Học viên

Nguyễn Thị Hạnh

LỜI CẢM ƠN

Trong quá trình học tập và nghiên cứu tại khoa Công nghệ thông tin trường Đại học Công nghệ - Đại học Quốc gia Hà Nội, đến nay tôi đã hoàn thành chương trình học và luận văn tốt nghiệp Tôi không thể quên gửi lời cảm ơn tới các thầy cô, gia đình

và bạn bè

Đầu tiên, tôi xin được bày tỏ lòng biết ơn sâu sắc tới sự giúp đỡ của giảng viên hướng dẫn PGS.TS Đặng Văn Đức Trong suốt thời gian làm luận văn, thầy đã giúp

đỡ và chỉ bảo nhiệt tình để tôi có thể hoàn thành luận văn đạt được kết quả tốt

Tôi cũng xin gửi lời cám ơn đến tập thể các thầy cô giáo trong Khoa CNTT –

ĐH Công Nghệ - ĐH Quốc Gia Hà Nội cùng các bạn học viên cao học khóa K18 đã tạo điều kiện cho tôi tiếp thu kiến thức, làm việc theo nhóm và có một môi trường học tập tốt nhất

Cuối cùng, tôi xin gửi lời cảm ơn tới gia đình tôi – những người thân đã động viên tôi bằng cả vật chất lẫn tinh thần trong suốt thời gian tôi học tập

Tuy rằng, tôi đã cố gắng hết sức trong quá trình làm luận văn nhưng không thể tránh khỏi thiếu sót, tôi rất mong nhận được những góp ý của thầy cô và các bạn

Hà Nội, ngày 10 tháng 06 năm 2014

Học viên

Nguyễn Thị Hạnh

MỤC LỤC

LỜI CAM ĐOAN 3

LỜI CẢM ƠN 4

MỤC LỤC 5

DANH MỤC CÁC HÌNH VẼ 8

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

1.1 Đặt vấn đề 10

1.2 Nội dung nghiên cứu 10

1.3 Tầm quan trọng của kiểm thử dựa trên mô hình 11

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

CHƯƠNG 2 TỔNG QUAN VỀ HỆ THỐNG NHÚNG 12

2.1 Các khái niệm về hệ thống nhúng 12

2.1.1 Hệ thống nhúng 12

2.1.2 Hệ thời gian thực 13

2.2 Cấu trúc phần cứng hệ thống nhúng 14

2.2.1 Các thành phần cơ bản 14

2.2.1.1 Đơn vị xử lý trung tâm (CPU) 14

2.2.1.2 Bộ nhớ 14

2.2.1.3 Thiết bị ngoại vi 15

2.2.1.4 Bus địa chỉ, bus dữ liệu và bus điều khiển 17

2.2.2 Một số nền phần cứng nhúng thông dụng 18

2.2.2.1 Vi điều khiển nhúng 18

2.2.2.2 Chip DSP 19

2.3 Kiến trúc phần mềm nhúng 19

2.3.1 Kiến trúc Round-Robin (RR) 19

2.3.2 Kiến trúc Round-Robin với ngắt (RRI) 20

2.3.3 Kiến trúc Lập lịch dòng chức năng (FQS) 21

2.3.4 Kiến trúc Hệ điều hành thời gian thực (RTOS) 21

2.4 Hệ điều hành thời gian thực 22

2.4.1 Khái niệm hệ điều hành thời gian thực 22

2.4.2 Tác vụ (Task) và trạng thái tác vụ 23

2.4.3 Queue và các trạng thái của queue 24

2.4.4 Các phương pháp lập lịch 26

CHƯƠNG 3 NGHIÊN CỨU VỀ KIỂM THỬ VÀ PHÂN TÍCH DỰA TRÊN MÔ HÌNH 28

3.1 Tổng quan 28

3.1.1 Khái niệm NModel 28

3.1.2 Khái niệm chương trình mô hình 28

3.1.3 Khái niệm phân tích dựa trên mô hình 29

3.1.4 Khái niệm kiểm thử dựa trên mô hình 29

3.1.5 Chương trình mô hình trong quy trình phần mềm 30

3.2 Hệ thống với các mô hình hữu hạn 30

3.2.1 Chương trình mô hình 30

3.2.1.1 Hành động (Action) 30

3.2.1.2 Hành vi (Behavior) 31

3.2.1.3 Cấu trúc chương trình mô hình hợp đồng C# 31

3.2.2 Thăm dò và phân tích chương trình mô hình hữu hạn 32

3.2.2.1 Máy trạng thái hữu hạn (FSM-Finite State Machines) 32

3.2.2.2 Thăm dò 33

3.2.2.3 Phân tích 36

3.2.3 Cấu trúc chương trình mô hình với thành phần (Composition) 36

3.2.3.1 Điều khiển kịch bản (Scenario control) 37

3.2.3.2 Thành phần (Composition) 37

3.2.4 Kiểm thử hệ thống đóng 43

3.2.4.1 Tạo bộ kiểm thử (test suite) cho phương pháp kiểm thử ngoại tuyến (Offline) 43

3.2.4.2 Dấu vết và giới hạn 43

3.2.4.3 Bản khai thác kiểm thử (Test harness) và việc thực thi kiểm thử (Test execution) 44

3.2.4.4 Hạn chế của kiểm thử ngoại tuyến 46

3.2.5 Kiểm thử các hệ thống với trạng thái phức tạp 46

3.2.5.1 Kiểm thử “on-the-fly” 46

3.2.5.2 Các chiến lược 50

CHƯƠNG 4 XÂY DỰNG DEMO VÀ KIỂM THỬ HỆ THỐNG VỚI NMODEL 53

4.1 Giới thiệu NModel 53

4.1.1 Cài đặt NModel 53

4.1.2 Cách sử dụng các công cụ mpv, otg, ct 53

4.1.2.1 Công cụ mpv 53

41.2.2 Công cụ otg 54

4.1.2.3 Công cụ ct 54

4.2 Xây dựng và thực nghiệm với demo hệ thống client/server 55

4.2.1 Mô tả bài toán 55

4.2.2 Kiểm thử demo bằng NModel 57

4.2.2.1 Kiểm thử ngoại tuyến (Offline) 57

4.2.2.2 Kiểm thử on-the-fly 65

CHƯƠNG 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 67

5.1 Kết luận 68

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

TÀI LIỆU THAM KHẢO 69

PHỤ LỤC 70

DANH MỤC CÁC HÌNH VẼ

Hình 2.1: Mẫu xe trong cuộc thi Micom Car Rally (chip Renesas H8) 12

Hình 2.2: Một số hệ thống nhúng thông dụng như robot, máy in và điện thoại 13

Hình 2.3:Cấu trúc CPU 14

Hình 2.4: Kiến trúc bộ nhớ Von Neumann và Havard 15

Hình 2.5: Cấu trúc ghép nối giữa máy tính và thiết bị ngoại vi 16

Hình 2.6: Chu kỳ hoạt động bus dồn kênh 18

Hình 2.7: Kiến trúc nguyên lý của VĐK với cấu trúc Havard 19

Hình 2.8: Minh họa kiến trúc RR bằng giả mã và đồ thị 20

Hình 2.9: Minh họa kiến trúc RRI bằng giả mã 21

Hình 2.10: So sánh kiến trúc RTOS và OS chuẩn 22

Hình 2.11: Cấu trúc hệ điều hành thời gian thực 23

Hình 2.12: Cấu trúc của một Task cơ bản 24

Hình 2.13: Các trạng thái của task 24

Hình 2.14: Hàng đợi Queue 25

Hình 2.15: Trạng thái của Queue 25

Hình 2.16: Phân loại các phương pháp lập lịch 26

Hình 2.17: Giản đồ thời gian thực hiện lịch của tác vụ 27

Hình 3.1: Sơ đồ hoạt động của MBT 29

Hình 3.2: Mô hình chữ V trong phát triển phần mềm dựa trên mô hình 30

Hình 3.3: Một thuật toán thăm dò đầy đủ 35

Hình 3.4: Chương trình mô hình M1 38

Hình 3.5: Chương trình mô hình M2 39

Hình 3.6: MP M1xM2 - sản phẩm của M1 và M2 39

Hình 3.7: Phần mở rộng vòng lặp của M1 39

Hình 3.8: Phần mở rộng vòng lặp của M2 40

Hình 3.9: MP M1xM2, các trạng thái đôi và hành động phù hợp 41

Hình 3.10: Các trạng thái , hành động trong M1xM2 41

Hình 3.11: M1 dưới dạng FSM text file 42

Hình 3.12: Bag implementation 47

Hình 3.13: Bag Model 48

Hình 3.14: Một tính năng của mô hình và kịch bản 49

Hình 3.15: Bag stepper 50

Hình 3.16: Giao diện IStrategy 51

Hình 4.1 Thiết bị điều khiển từ xa – Hệ thống Client/Server 55

Hình 4.2: Giao thức client/server 56

Hình 4.3: FSM đúng của MP hợp đồng 58

Hình 4.4: FSM của MP kịch bản 59

Hình 4.5: FSM của MP kịch bản kết hợp với MP hợp đồng 59

Hình 4.6: FSM của test suite được tạo với MP hợp đồng 62

Hình 4.7: FSM của test suite được tạo khi MP hợp đồng biên soạn với MP kịch bản 63 Hình 4.8: Kết quả kiểm thử ngoại tuyến với trường hợp sử dụng MP hợp đồng 64

Hình 4.9: Kết quả kiểm thử ngoại tuyến với trường hợp sử dụng điều khiển kịch bản (MP hợp đồng được biên soạn với MP kịch bản) 64

Hình 4.10: Kết quả kiểm thử ngẫu nhiên khi sử dụng MP hợp đồng 66

Hình 4.11: Kết quả kiểm thử ngẫu nhiên khi sử dụng điều khiển kịch bản (1) 66

Hình 4.12: Kết quả kiểm thử ngẫu nhiên khi sử dụng điều khiển kịch bản (2) 67

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

Ngày nay, các hệ thống nhúng rất phát triển với những ứng dụng rộng rãi trong nhiều lĩnh vực công nghiệp và đời sống Các hệ thống nhúng có kiến trúc phần cứng cũng như phần mềm rất đa dạng và phong phú Như chúng ta đã biết, trong phát triển phần mềm thì hoạt động kiểm thử có vai trò hết sức quan trọng, mang tính sống còn của sản phẩm và với phần mềm nhúng cũng không phải là ngoại lệ Sự phát triển của

hệ thống nhúng kéo theo những yêu cầu phát triển của hoạt động kiểm thử phần mềm nhúng

Thông thường, một cách rất phổ biến để kiểm thử phần mềm cho hệ thống nhúng nói chung đó là chạy phần mềm trên chương trình giả lập phần cứng, chương trình giả lập ở đây có thể là một vi điều khiển ảo cũng có thể là một chương trình mô phỏng hình dung cả một hệ thống mạch bao gồm vi điều khiển và các thiết bị khác

Tuy nhiên hiện nay, hệ thống nhúng ở Việt Nam mới phát triển khá khiêm tốn

so với thế giới, và lĩnh vực kiểm thử nhúng lại càng khiêm tốn hơn Có rất ít các bài báo, các tài liệu nói về hoạt động kiểm thử nhúng cũng như không có nhiều công cụ hỗ trợ cho việc kiểm thử này Do đó, việc nghiên cứu và tìm hiểu các phương pháp, các

kỹ thuật kiểm thử cũng như công cụ cho phần mềm nhúng là một vấn đề cần thiết hiện nay, nó sẽ góp phần thúc đẩy sự phát triển của lĩnh vực hệ thống nhúng, một lĩnh vực giàu tiềm năng nhưng mới chỉ bước đầu phát triển ở việt nam

Trong luận văn này, tôi chọn nghiên cứu kiểm thử dựa trên mô hình với NModel trong việc phát triển phần mềm nhúng, cụ thể là kiểm thử cho bài toán về hệ thống Client/Server – một thiết bị điều khiển từ xa có sử dụng cảm biến nhiệt độ

1.2 Nội dung nghiên cứu

Mục tiêu của luận văn: Mục tiêu đặt ra là nghiên cứu phương pháp kiểm thử dựa trên mô hình để hỗ trợ cho việc phát triển hệ thống nhúng

Nhiệm vụ của luận văn: Trong luận văn này, nhiệm vụ chính là nghiên cứu ứng dụng cụ thể NModel sau đó áp dụng kiểm thử bài toán thiết bị điều khiển từ xa Client/Server

Luận văn tập trung nghiên cứu và khảo sát tổng quan về lý thuyết hệ thống nhúng; lý thuyết phân tích và kiểm thử dựa trên mô hình và các kỹ thuật kiểm thử phần mềm; luận văn cũng nghiên cứu về các loại chương trình mô hình trong NModel

để kiểm thử bài toán về thiết bị điều khiển từ xa Client/Server Từ những hiểu biết về phân tích và kiểm thử phần mềm, luận văn đã áp dụng quy trình của các phương pháp kiểm thử ngoại tuyến và kiểm thử trực tuyến (on-the-fly) để kiểm thử bài toán

Hệ thống Client/Server – thiết bị điều khiển từ xa là bài toán về hệ thống nhúng đơn giản nhưng đầy đủ, không sử dụng hệ điều hành nhúng Các chương trình được viết bằng ngôn ngữ C# và kiểm thử được chạy mô phỏng bằng công cụ NModel

1.3 Tầm quan trọng của kiểm thử dựa trên mô hình

Trong phát triển phần mềm, các kiểm thử viên thường thực hiện công việc bằng phương pháp truyền thống nên đôi khi bị nhàm chán vì công việc lặp đi lặp lại, tốn thời gian để thực hiện kiểm thử Do đó, kiểm thử dựa trên mô hình sẽ khắc phục được một số vấn đề như sau:

 Quá trình sinh ca kiểm thử là tự động nên sẽ rút ngắn thời gian làm phần mềm, chất lượng phần mềm được cải thiện hơn, sinh ra nhiều ca kiểm thử và phát hiện nhiều lỗi

 Loại bỏ được sự nhàm chán và tính chủ quan khi làm việc nên giúp cho các kiểm thử viên hài lòng với công việc của mình

 Tự động tạo và kiểm tra để tránh các ca kiểm thử trùng nhau hoặc không hữu hiệu

 Khi có yêu cầu thay đổi hệ thống thì việc thay đổi các ca kiểm thử chỉ việc thay đổi mô hình của hệ thống

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

Các phần còn lại của luận văn có cấu trúc như sau:

Chương 2 trình bày tổng quan về hệ thống nhúng và phần mềm nhúng

Chương 3 trình bày về lý thuyết phân tích và kiểm thử dựa trên mô hình, và hệ thống với các mô hình hữu hạn

Chương 4 giới thiệu về cách cài đặt và cách sử dụng công cụ NModel, trình bày

về bài toán và kết quả thực nghiệm kiểm thử hệ thống Client/Server – thiết bị điều khiển từ xa

Cuối cùng là kết luận về quá trình nghiên cứu, đưa ra các kết quả đạt được, và hướng nghiên cứu tiếp theo

CHƯƠNG 2 TỔNG QUAN VỀ HỆ THỐNG NHÚNG 2.1 Các khái niệm về hệ thống nhúng

2.1.1 Hệ thống nhúng

Ngày nay, xung quanh ta có rất nhiều thiết bị, đồ dùng liên quan đến hệ thống nhúng như đồng hồ kỹ thuật số, ô tô, hoặc những sản phẩm lớn như đèn giao thông, máy giặt, hệ thống kiểm soát các máy năng lượng hạt nhân Vậy thực chất “hệ thống nhúng là gì?” Có rất nhiều khái niệm về hệ thống nhúng Tuy nhiên, theo [1]: “Hệ thống nhúng 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ẹ Đó là các hệ thống tích hợp cả phần cứng

và phần mề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 hóa điều khiển, quan trắc và truyền tin”

Không giống như các máy tính đa chức năng, hệ thống nhúng được thiết kế để thực hiện một chức năng chuyên biệt nào đó Nó có đặc điểm là hoạt động ổn định và

có tính năng tự động hóa cao

Sau đây là một số ví dụ điển hình về hệ thống nhúng:

 Các hệ thống dẫn đường trong không lưu, hệ thống định vị toàn cầu, vệ tinh

 Các thiết bị gia dụng: tủ lạnh, lò vi sóng, lò nướng

 Các thiết bị kết nối mạng: router, hub, gateway

 Các thiết bị văn phòng: máy photocopy, máy fax, máy in, máy scan

 Các thiết bị y tế: máy thẩm thấu, máy điều hòa nhịp tim

 Các máy trả lời tự động

 Dây chuyền sản xuất tự động trong công nghiệp, robots

Hình 2.1: Mẫu xe trong cuộc thi Micom Car Rally (chip Renesas H8)

Hình 2.2: Một số hệ thống nhúng thông dụng như robot, máy in và điện thoại

2.1.2 Hệ thời gian thực

Thời gian thực rất khó định nghĩa chính xác Thông thường, trong các bài toán điều khiển hay gặp thuật ngữ “thời gian thực” Vậy thời gian thực nên được hiểu như thế nào cho đúng? Thời gian thực là yêu cầu khắt khe về sự ràng buộc thời gian, có nghĩa là: Các yêu cầu của hệ thống phải đảm bảo thoả mãn các hành vi của hệ thống được thực hiện đúng trong khung thời gian cho trước hoàn toàn xác định Khung thời gian này được xác định bởi yêu cầu của hệ thống

Về cơ bản, thời gian thực được phân ra thành hai loại là thời gian thực cứng (hard real-time) và thời gian thực mềm (soft real-time) Theo [1], hai loại thời gian thực được định nghĩa như sau:

 Thời gian thực cứng là khi hệ thống hoạt động với yêu cầu thỏa mãn sự ràng buộc trong khung thời gian cứng tức là nếu vi phạm thì sẽ dẫn đến hoạt động của toàn hệ thống bị sai hoặc phá hủy

 Thời gian thực mềm là khi hệ thống hoạt động với yêu cầu thoản mãn ràng buộc trong khung thời gian mềm, nếu vi phạm và sai lệch nằm trong khoảng cho phép thì hệ thống vẫn có thể hoạt động được và chấp nhận được

Ví dụ với hệ thời gian thực cứng: Máy hỗ trợ nhịp tim cho bệnh nhân khi phẫu thuật Thuật toán điều khiển phụ thuộc vào thời gian nhịp tim của người bệnh, nếu thời gian này bị trễ thì tính mạng của người bệnh sẽ gặp nguy hiểm

Ví dụ với hệ thời gian thực mềm: Cây rút tiền tự động ATM Khi ta đưa thẻ ATM vào máy, có thể do nghẽn mạng mà việc rút tiền bị trễ vài giây thậm chí vài phút thì ta vẫn có thể kiên nhẫn chờ đợi mà không gây thiệt hại gì cho người rút tiền

Các lĩnh vực ứng dụng của hệ thống nhúng: Ngày nay, có rất nhiều các ứng dụng của hệ thống nhúng đang được sử dụng và sẽ tiếp tục tăng nhanh trong tương lai Một số lĩnh vực và sản phẩm thị trường của các hệ thống nhúng có thể được nhóm như sau:

 Các thiết bị điều khiển

 Lĩnh vực truyền thông

 Thiết bị y tế

Bộ xử lý trung tâm bao gồm đơn vị logic toán học ALU (Arthimetic Logic Unit), bộ giải mã (decoder), bộ tuần tự (sequencer) và các thanh ghi

Trong tài liệu [1], cơ chế làm việc của CPU được giải thích như sau:

Bộ giải mã chuyển đổi các lệnh lưu trữ ở trong bộ mã chương trình thành các mã mà ALU có thể hiểu được và thực thi Bộ tuần tự có nhiệm vụ quản

lý dòng dữ liệu trao đổi qua bus dữ liệu của vi xử lý Các thanh ghi được sử dụng để CPU lưu trữ tạm thời các dữ liệu chính cho việc thực thi các lệnh

và chúng có thể thay đổi nội dung trong quá trình hoạt động của ALU Hầu hết các thanh ghi của vi xử lý đều là các bộ nhớ được tham chiếu và hội nhập với khu vực bộ nhớ và có thể được sử dụng như bất kỳ khu vực nhớ khác

2.2.1.2 Bộ nhớ

Bộ nhớ là một yêu cầu tài nguyên quan trọng không chỉ trong hệ thống nhúng

mà trong mọi hệ thống khác Ngay cả hệ thống con người cũng cần bộ nhớ Về kiến

trúc bộ nhớ được chia làm hai loại cơ bản là kiến trúc bộ nhớ Von Neumann và Havard

Kiến trúc bộ nhớ von Neumann và Havard được biểu diễn như trong hình 2.4

Hình 2.4: Kiến trúc bộ nhớ Von Neumann và Havard

Kiến trúc Von Neumann không phân biệt vùng chứa dữ liệu và mã chương trình Chúng đều được truy xuất trên cùng một đường Còn với kiến trúc Havard thì phân biệt vùng lưu mã chương trình và dữ liệu Mã chương trình chỉ có thể lưu và thực hiện trong vùng chứa ROM và dữ liệu cũng chỉ được lưu và trao đổi trong vùng RAM Ngày nay, trong các vi xử lý nhúng kiến trúc bộ nhớ Havard được sử dụng nhiều hơn

so với kiến trúc bộ nhớ von Neumann Ví dụ Chip vi điều khiển nhúng hay sử dụng cấu trúc Havard là 8031, PIC, Atmel AVR90S Lý do kiến trúc Harvard được dùng nhiều là nó có ưu điểm nổi bật hơn von Neumann Nó có hai kênh tách biệt để truy nhập vào vùng bộ nhớ dữ liệu và mã chương trình Điều đó giúp cho mã chương trình

và dữ liệu có thể được truy nhập đồng thời và làm tăng tốc độ luồng trao đổi với bộ xử

lý

2.2.1.3 Thiết bị ngoại vi

Máy tính hay hệ vi xử lý trao đổi dữ liệu với môi trường bên ngoài thông qua các thiết bị ngoại vi Các thiết bị ngoại vi bao gồm:

 Các thiết bị vào chuẩn như bàn phím, chuột

 Các thiết bị ra chuẩn như màn hình, máy in

 Các bộ nhớ ngoài chuẩn như ổ cứng, CD ROM

 Các hệ đo lường, điều khiển

Cấu trúc ghép nối giữa máy vi tính và thiết bị ngoại vi được thể hiện trong hình 2.5

Bộ phối ghép nằm giữa máy vi tính và các thiết bị ngoài, đóng vai trò trung chuyển dữ liệu giữa chúng Khi truyền dữ liệu từ máy tính ra thiết bị ngoài thì nó đóng

vai trò nhận dữ liệu từ máy tính và là nguồn cấp dữ liệu cho thiết bị ngoài Ngược lại, khi truyền dữ liệu từ thiết bị ngoài vào thì bộ phối ghép lại đóng vai trò nhận dữ liệu từ thiết bị ngoài và là nguồn cấp dữ liệu cho máy tính Bộ phối ghép làm nhiệm vụ phối hợp trao đổi dữ liệu giữa máy tính và thiết bị ngoài về mức công suất của tín hiệu, dạng tín hiệu, tốc độ và phương thức trao đổi

Hình 2.5: Cấu trúc ghép nối giữa máy tính và thiết bị ngoại vi

Phối hợp về mức và công suất tín hiệu: Máy tính thường có mức tín hiệu là

(0V, 5V) Trong khi đó, các thiết bị ngoài hoặc ở mức cao (± 15V, ± 48V ) hoặc rất thấp (˂ 1V) Do đó, bộ phối ghép phải biến đổi các mức tín hiệu trên cho phù hợp Công suất tín hiệu trên bus dữ liệu rất nhỏ (cỡ vài chục mA), trong khi thiết bị ngoài lại cần công suất lớn hơn nhiều Do đó, bộ phối ghép phải biến đổi công suất cho phù hợp

Phối hợp về dạng dữ liệu (tín hiệu): Bộ phối ghép phải đảm bảo tính tương

thích về cơ chế trao đổi dữ liệu giữa máy tính và thiết bị ngoại vi

Phối hợp về tốc độ trao đổi dữ liệu: Máy tính hoạt động với tốc độ cao còn

các thiết bị ngoại vi hoạt động với tốc độ chậm hơn Do đó, bộ phối ghép phải có khả năng cấp, nhận dữ liệu nhanh với máy tính còn với thiết bị ngoại vi thì ngược lại

Phối hợp về phương thức trao đổi dữ liệu

Nếu việc trao đổi dữ liệu do máy tính yêu cầu thì quá trình diễn ra như sau: Máy tính đưa lệnh điều khiển để khởi động bộ phối ghép hoặc thiết bị ngoại vi Máy tính đọc tín hiệu trả lời, nếu có tín hiệu sẵn sàng mới trao đổi tin, nếu không thì thêm

một chu kỳ chờ và đọc lại trạng thái Máy tính trao đổi tin khi đọc thấy trạng thái sẵn sàng

Nếu việc trao đổi tin do thiết bị ngoại vi yêu cầu thì việc trao đổi diễn ra khi: Thiết bị ngoại vi gửi yêu cầu trao đổi tin tới bộ xử lý ngắt của khối ghép nối (KGN) Nếu có nhiều thiết bị ngoại vi cùng gửi yêu cầu thì KGN xử lý theo mức ưu tiên ngắt định trước rồi đưa yêu cầu trao đổi tin cho máy tính Máy tính nhận yêu cầu, chuẩn bị trao đổi và gửi tín hiệu xác nhận sẵn sàng trao đổi KGN nhận và truyền tín hiệu xác nhận cho thiết bị ngoại vi Thiết bị ngoại vi trao đổi tin với KGN còn khối ghép nối trao đổi với máy tính (nếu là đưa tin vào) hoặc máy tính trao đổi tin với KGN và KGN trao đổi với thiết bị ngoại vi (nếu là đưa tin ra)

2.2.1.4 Bus địa chỉ, bus dữ liệu và bus điều khiển

Bus địa chỉ: là các đường dẫn tín hiệu logic một chiều, nó làm nhiệm vụ truyền

địa chỉ tham chiếu đến các khu vực nhớ và chỉ ra nơi mà dữ liệu được lưu trữ trong không gian bộ nhớ Trong quá trình hoạt động, CPU sẽ điều khiển bus địa chỉ để truyền dữ liệu giữa CPU và bộ nhớ Dữ liệu được lưu trữ thường là 8 bít, 16 bít, hoặc

32 bít tùy vào cấu trúc từng loại vi xử lý và vi điều khiển Đối với vi điều khiển thì địa chỉ dữ liệu thường được đánh theo khối 8 bít CPU có thể truy nhập trực tiếp vào các khu vực bộ nhớ bằng địa chỉ tham chiếu Nếu vi xử lý có N bít địa chỉ thì nó có thể đánh được 2N địa chỉ khu vực mà CPU có thể tham chiếu tới Các khu vực được đánh địa chỉ theo qui ước bắt đầu từ 0 và tăng dần đến 2N-1 Độ rộng của bus dữ liệu thường

là 16, 20, 24 hoặc 32 bít

Bus dữ liệu: là các kênh truyền tải thông tin theo hai chiều giữa CPU và bộ nhớ

hay các thiết bị ngoại vi vào ra CPU điều khiển bus dữ liệu để đọc và viết dữ liệu hoặc

mã lệnh thực thi Độ rộng của bus dữ liệu xác định được lượng dữ liệu có thể truyền và trao đổi trên bus Tốc độ truyền dữ liệu được tính theo đơn vị là [byte/s]

Bus điều khiển: Theo tài liệu [1], bus điều khiển được giải thích như sau:

Bus điều khiển phục vụ truyền tải các thông tin dữ liệu để điều khiển hoạt động của hệ thống Thông thường các dữ liệu điều khiển bao gồm các tín hiệu chu kỳ để đồng bộ các nhịp chuyển động và hoạt động của hệ thống Bus điều khiển thường được điều khiển bởi CPU để đồng bộ hóa nhịp hoạt động và dữ liệu trao đổi trên các bus Trong trường hợp vi xử lý sử dụng dồn kênh bus dữ liệu và bus địa chỉ tức là một phần hoặc toàn bộ bus dữ liệu sẽ được sử dụng chung chia sẻ với bus địa chỉ thì cần một tín hiệu điều khiển để phân nhịp truy nhập cho phép chốt lưu trữ thông tin địa chỉ mỗi khi bắt đầu một chu kỳ truyền

Ví dụ về bus điều khiển: Ví dụ về hoạt động của hệ thống bus địa chỉ và dữ liệu dồn kênh được chỉ ra trong hình 2.6 Đây là hoạt động điển hình trong họ vi điều khiển

8051

Hình 2.6: Chu kỳ hoạt động bus dồn kênh 2.2.2 Một số nền phần cứng nhúng thông dụng

Ngày nay, các chủng loại chip khả trình phát triển nhanh chóng với mật độ tích hợp cao đang có tác động đáng kể đến sự thay đổi trong việc thiết kế các nền phần cứng thiết bị xử lý và điều khiển số Mỗi chủng loại có những đặc điểm và phạm vi ứng dụng và không ngừng phát triển để đáp ứng cho các yêu cầu công nghệ một cách tốt nhất Có rất nhiều loại chíp khả trình có thể sử dụng cho các bài toán thiết kế hệ thống nhúng như Chip DSP (Digital Signal Processing), họ vi xử lý/vi điều khiển nhúng (Microprocessor/Microcontroller) và các Chip khả trình trường (FPD-Field Programmable Device)

2.2.2.1 Vi điều khiển nhúng

Ngày nay, vi điều khiển nhúng là một chủng loại rất điển hình và được dùng phổ biến Chúng được ra đời và sử dụng theo sự phát triển của các chip xử lý ứng dụng cho máy tính Các nhà chế tạo cung cấp các họ vi xử lý điều khiển có rất nhiều như

Intel, Atmel, Motorola, Infineon Chúng cũng có cấu trúc tương tự như các chip xử lý

phát triển cho PC nhưng đơn giản hơn nhiều về công năng và tài nguyên Chủ yếu là các chip có độ rộng bus dữ liệu là 8 bít, 16 và 32 bít Vi điều khiển nhúng được tích hợp thêm các ngoại vi, các ngoại vi thường là các khối chức năng ngoại vi thông dụng như bộ định thời gian, bộ đếm, bộ chuyển đổi A/D, giao diện song song, nối tiếp Tùy theo mục đích ứng dụng mà mức độ tích hợp ngoại vi cũng khác nhau Nếu thực tế các ứng dụng yêu cầu độ tích hợp cao thì sẽ sử dụng giải pháp tích hợp trên chip, nếu không thì các chip đều cung cấp giải pháp mở rộng ngoại vi đáp ứng cho số lượng ứng dụng rộng và mềm dẻo

Ví dụ về kiến trúc nguyên lý của vi điều khiển (VĐK) với cấu trúc Havard:

Hình 2.7: Kiến trúc nguyên lý của VĐK với cấu trúc Havard

2.2.2.2 Chip DSP

Theo tài liệu [1], chip DSP được giải thích như sau:

DSP vẫn được biết tới như một loại vi điều khiển đặc biệt với khả năng xử

lý nhanh để phục vụ các bài toán yêu cầu khối lượng và tốc độ xử lý tính toán lớn Với ưu điểm nổi bật về độ rộng băng thông của bus và thanh ghi tích lũy, cho phép ALU xử lý song song với tốc độ đọc và xử lý lệnh nhanh hơn các loại vi điều khiển thông thường Chip DSP cho phép thực hiện nhiều lệnh trong một nhịp nhờ vào kiến trúc bộ nhớ Havard

Khi phải sử dụng DSP thì định dạng biểu diễn toán học sẽ là một yếu tố quan trọng để phân loại và được quan tâm Hiện nay, chúng được phân loại theo hai kiểu là dấu phảy động và dấu phảy tĩnh Đây cũng là yếu tố quan trọng đối với người thiết kế

để lựa chọn DSP phù hơp với ứng dụng của mình Các DSP dấu phảy tĩnh thường là

16 bít hoặc 24 bít còn các DSP dấu phảy động thường là 32 bít

Hình 2.8: Minh họa kiến trúc RR bằng giả mã và đồ thị

Các ứng dụng có thể áp dụng kiến trúc round robin như máy bán hàng tự động, máy ATM, hoặc thiết bị gia dụng như lò vi sóng Round robin có ưu điểm là phương pháp thăm dò rất đơn giản, đủ tốt để sử dụng, chi phí phát triển thấp, chu kỳ phát triển ngắn Tuy nhiên, kiến trúc này cũng có nhược điểm là không thể xử lý những vấn đề phức tạp, rất lãng phí thời gian để kiểm tra các thiết bị kể cả khi thiết bị đó không cần phục vụ hoặc trong trường hợp có quá nhiều thiết bị cần phục vụ thì phương án thăm

dò tỏ ra không hiệu quả, gây chậm trễ cho các thiết bị đó

2.3.2 Kiến trúc Round-Robin với ngắt (RRI)

Kiến trúc Round-Robin với ngắt (Round-Robin with Interrupts - RRI) là kiến trúc hỏi vòng có ngắt Các tác vụ cấp bách được xử lý trong một dịch vụ thường xuyên

bị gián đoạn, có một bộ cờ để xử lý theo dõi trong vòng lặp chính Nếu không có gì cấp bách xảy ra thì sau đó bộ vi xử lý tiếp tục hoạt động luân chuyển vòng Quản lý các tác vụ quanh vòng lặp Kiến trúc RRI có thể được minh họa bằng giả mã như hình 2.9

Lợi thế rõ ràng của RRI là thời gian đáp ứng với các tác vụ ưu tiên cao được cải thiện Tuy ISR luôn luôn có ưu tiên hơn vòng lặp chính (tức vòng lặp chính sẽ luôn luôn dừng lại bất cứ điều gì nó đang làm để phục vụ ngắt), nhưng nó vẫn còn khá đơn giản Thời gian đáp ứng trong trường hợp xấu nhất cho một tác vụ ưu tiên thấp là tổng thời gian thực hiện đối với tất cả các mã lệnh trong vòng lặp chính cộng với tất cả các thủ tục gián đoạn dịch vụ Hơn nữa, với sự ra đời của ngắt thì vấn đề chia sẻ dữ liệu có thể xảy ra

Hình 2.9: Minh họa kiến trúc RRI bằng giả mã

2.3.3 Kiến trúc lập lịch dòng chức năng (FQS)

Kiến trúc lập lịch dòng chức năng (Function-Queue Scheduling - FQS) là kiến trúc thô sơ của kiến trúc hệ điều hành mà nó đang được sử dụng cho máy tính đa năng Tất cả các yêu cầu được đặt vào hàng đợi và mỗi một yêu cầu có một mức độ ưu tiên nhất định Vi xử lý sẽ tùy theo cơ chế lập lịch để phục vụ những yêu cầu nào trước FQS có rất nhiều cơ chế lập lịch ví dụ như lập lịch ưu tiên thứ tự trước sau (đến trước phục vụ trước), lập lịch ưu tiên theo độ ưu tiên (độ ưu tiên cao hơn thì được phục vụ trước), lập lịch ưu tiên những yêu cầu đơn giản trước, lập lịch giả song song (mỗi yêu cầu được phục vụ một thời gian ngắn rồi quay lại phục vụ tiếp sau khi phục vụ thiết bị khác)

FQS có ưu điểm là tất cả các yêu cầu đều được phục vụ, không có một yêu cầu nào được bỏ qua Tuy nhiên, FQS không đánh giá được yêu cầu nào phải thực hiện bao nhiêu thời gian, tốn bao nhiêu tài nguyên

2.3.4 Kiến trúc hệ điều hành thời gian thực (RTOS)

Kiến trúc hệ điều hành thời gian thực (Real-Time Operating Systems – RTOS)

có ba đặc điểm khác biệt so với các kiến trúc khác đó là: (1) Quá trình điều khiển giữa các chu trình ngắt và mã nguồn thực thi tác vụ được quản lý bởi RTOS (tức là không cần dùng biến chia sẻ) (2) RTOS quyết định lập lịch các tác vụ thay vì dùng một vòng lặp chính để quyết định xem tác vụ thực thi tiếp theo là gì hoặc ngắt tiếp theo là gì (3) RTOS có thể tạm dừng một tác vụ đang thực thi để thực thi tác vụ khác

RTOS là kiến trúc tốt hơn các kiến trúc khác vì nó có thể đáp ứng các yêu cầu ràng buộc về thời gian (ràng buộc thời gian cứng, ràng buộc thời gian mềm), chịu lỗi cao và cho phép xử lý đa nhiệm Do đó, RTOS có các ưu điểm sau: Thay đổi bất kỳ tác vụ nào trong Round robin hoặc lập lịch theo hàng đợi Thay đổi tới tác vụ có độ ưu tiên thấp hơn trong RTOS không ảnh hưởng đến thời gian đáp ứng của các tác vụ có

độ ưu tiên cao hơn RTOS được sử dụng rộng rãi và là giải pháp thật sự cần thiết cho các hệ thống yêu cầu ràng buộc về thời gian đáp ứng Tuy nhiên, RTOS vẫn có nhược điểm là cần thêm một số thời gian để xử lý các thông tin về tác vụ trước và sau khi đưa

nó vào xử lý trong CPU nên hiệu suất sử dụng bị ảnh hưởng Ngoài ra, chi phí cao khi mua các sản phẩm thương mại

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

2.4.1 Khái niệm hệ điều hành thời gian thực

Hệ điều hành thời gian thực được định nghĩa theo [1]: “Hệ điều hành thời gian thực – RealTime Operating Systems (RTOS) là phần mềm điều khiển chuyên dụng thường được dùng trong những ứng dụng điện toán nhúng có tài nguyên bộ nhớ hạn chế và yêu cầu ngặt nghèo về thời gian đáp ứng tức thời, tính sẵn sàng cao và khả năng

tự kiểm soát một cách chính xác.”

RTOS có khả năng tách biệt với ứng dụng, vì thế nếu có một chương trình bị

“chết” hay hoạt động không hợp lệ thì RTOS có thể cô lập chương trình này một cách nhanh chóng, kích hoạt cơ chế phục hồi và bảo vệ các chương trình khác hay chính bản thân hệ điều hành khỏi các hậu quả của các lệnh sai Cơ chế bảo vệ cũng được áp dụng để tránh tình trạng tràn bộ nhớ do các chương trình gây ra

Hệ điều hành thời gian thực là hệ điều hành hỗ trợ khả năng xây dựng các hệ thống thời gian thực

Hình 2.10: So sánh kiến trúc RTOS và OS chuẩn

Hệ điều hành với phần lõi là hạt nhân phải đảm bảo các tác vụ chính sau:

 Xử lý ngắt: Lưu trữ ngữ cảnh chương trình tại thời điểm xuất hiện ngắt Nhận dạng và lựa chọn đúng bộ xử lý và phục vụ dịch vụ ngắt

 Điều khiển quá trình hoạt động: Tạo và kết thúc quá trình/tác vụ Lập lịch và điều phối hoạt động hệ thống Định thời

 Điều khiển ngoại vi: Xử lý ngắt Khởi tạo giao tiếp vào ra

Hình 2.11: Cấu trúc hệ điều hành thời gian thực

2.4.2 Tác vụ (Task) và trạng thái tác vụ

Tác vụ là một luồng thực thi độc lập mà có thể cạnh tranh chiếm quyền thực thi Mỗi một ứng dụng đƣợc chia làm nhiều tác vụ để tối ƣu khả năng đáp ứng vào ra trong luật thời gian Một tác vụ đƣợc định nghĩa là một tập hợp các tham số và cấu trúc dữ liệu Thành phần của một tác vụ bao gồm: tên tác vụ, ID, độ ƣu tiên, khối điều khiển tác vụ, ngăn xếp và các thủ tục thực thi tác vụ Các thành phần của một tác vụ đƣợc thể hiện trong hình 2.12

Các trạng thái của một tác vụ: Tại bất cứ thời điểm nào, mỗi tác vụ tồn tại một trong các trạng thái nhƣ sẵn sàng (Ready), đang thực thi (Running) hoặc khóa (Blocked) Khi hệ thống nhúng thời gian thực chạy, mỗi tác vụ thay đổi từ trạng thái này đến trạng thái khác theo quy luật logic của một máy trạng thái hữu hạn FSM (Finite state machine) Các chuyển đổi trạng thái đƣợc thể hiện trong hình 2.13

Ready: Tất cả dữ liệu cần thiết có sẵn và tác vụ đƣợc chuẩn bị chạy khi bộ vi xử

lý có sẵn Nhiều tác vụ có thể sẵn sàng bất cứ lúc nào, và sẽ chạy theo thứ tự ƣu tiên

Running: Mã tác vụ đang đƣợc thực thi bởi bộ vi xử lý Tại bất kỳ thời điểm nào cũng chỉ có duy nhất một tác vụ có thể đƣợc chạy

Blocked: Một tác vụ có thể bị khóa và chờ đợi dữ liệu cho một sự kiện xảy ra Một tác vụ nếu không đƣợc ƣu tiên thì sẽ khóa sau khi chạy để hoàn thành Tại một thời điểm, nhiều nhiệm vụ có thể bị khóa

Hình 2.12: Cấu trúc của một Task cơ bản

Hình 2.13: Các trạng thái của task 2.4.3 Queue và các trạng thái của queue

Hàng đợi Queue là một máy giao tiếp dữ liệu giữa các Task Một message Queue là một đối tượng tương tự như Buffer (bộ nhớ đệm) thông qua Task hoặc ISR

để gửi và nhận “thông điệp” (message) để giao tiếp và đồng bộ dữ liệu Nó giữ thông điệp tạm thời từ bên gửi (sender) cho đến khi bên nhận được định trước (intended receiver) sẵn sàng đọc dữ liệu

Khi một thông điệp Queue đƣợc tạo ra lần đầu, nó đƣợc gán vào một khối quản

lý Queue, gồm các thông tin tên thông điệp, ID, bộ nhớ đệm, chiều dài Queue, độ dài tối đa mỗi thông điệp, một hay nhiều danh dách các task đang chờ

Hình 2.14: Hàng đợi Queue

Các trạng thái của Queue đƣợc thể hiện rõ trong hình 2.15: Mỗi Queue có thể

có một trong các trạng thái nhƣ rỗng (Empty), không rỗng (Not Empty) hoặc đầy (Full)

Hình 2.15: Trạng thái của Queue

2.4.4 Các phương pháp lập lịch

Khái niệm lập lịch được nêu trong tài liệu [1]: “Lập lịch là một phép thực hiện phân bổ và gán quy trình thực thi các tác vụ cho bộ xử lý sao cho mỗi tác vụ được thực hiện hoàn toàn”

Hình 2.16: Phân loại các phương pháp lập lịch

Tùy vào loại hình tác vụ mà người ta phân ra hai phương pháp lập lịch là có chu

kỳ và không có chu kỳ

Lập lịch non-preemptive được mô tả như trong tài liệu [1]: Phương pháp

này đảm bảo các tác vụ được thực hiện hoàn thành mỗi khi thực thi, vì vậy

thời gian đáp ứng cho các sự kiện khác có thể lâu Lập lịch preemptive: Phương pháp này khắc phục nhược điểm của lập lịch non-preemptive khi có

thời gian thực thi các tác vụ lâu Các tác vụ sẽ được thực hiện và có thể bị ngắt giữa chừng để phục vụ thực thi các tác vụ khác Cơ chế lập lịch này cho phép đảm bảo thời gian đáp ứng cho các sự kiện và tác vụ ngắn và

nhanh hơn Lập lịch offline/tĩnh: Việc lập lịch được thực hiện dựa trên các

hiểu biết hoặc dự báo về các sự kiện tác vụ thực hiện trong hệ thống và được quyết định tại thời điểm thiết kế và được áp dụng cố định trong suốt

quá trình hoạt động của hệ thống Lập lịch online/động: Bộ xử lý thực hiện

việc lập lịch trong quá trình thực thi dựa trên cơ sở các thông tin hoạt động hiện hành của hệ thống Sơ đồ lập lịch là không xác định trước và thay đổi động theo quá trình thực hiện

Ví dụ về lập lịch cho hệ thống đa nhiệm với hai tác vụ (thể hiện trong hình 2.17) Trong đó, tác vụ 1 thực hiện theo chu kỳ và tác vụ 2 thực hiện không theo chu

kỳ với thời gian thực thi lớn hơn thời gian chu kỳ lặp lại của tác vụ 1

Hình 2.17: Giản đồ thời gian thực hiện lịch của tác vụ

CHƯƠNG 3 NGHIÊN CỨU VỀ KIỂM THỬ VÀ PHÂN TÍCH DỰA TRÊN

MÔ HÌNH 3.1 Tổng quan

3.1.1 Khái niệm NModel

NModel là một khung làm việc (framework) kiểm thử và phân tích dựa trên mô hình cho các chương trình mô hình được viết bằng C# Kiểm thử trên cơ sở mô hình thường được áp dụng cho các giao thức truyền tin, ứng dụng web, các hệ thống điều khiển nhúng và giao diện người sử dụng đồ họa

NModel bao gồm bốn công cụ để phục vụ cho việc kiểm thử đó là: mpv (Model Program Viewer), mp2dot (Model Program to Dot), otg (Offline Test Generator), ct (Conformance Tester)

Để sử dụng NModel, thì chương trình mô hình phải được viết bằng ngôn ngữ C# Sau đó có thể sử dụng công cụ mpv để trực quan hoá (visualize) và phân tích hành

vi của chương trình mô hình đó và xác nhận xem nó có chạy đúng với ý định đã đặt ra

và kiểm tra lỗi thiết kế Để thực hiện việc kiểm thử thì sử dụng bộ chạy test ct, và phải viết một bản khai thác kiểm thử (test harness) bằng C#

Cách cài đặt và cách sử dụng bộ công cụ NModel sẽ được trình bày chi tiết trong chương 4

3.1.2 Khái niệm chương trình mô hình

Khi cần đặc tả những gì mà chương trình sẽ làm bằng cách viết một chương trình khác đơn giản hơn thì chương trình đó được gọi là chương trình mô hình Nó có

thể được định nghĩa rõ ràng hơn như trong tài liệu [4]: “Một chương trình mô hình là

một chương trình mà nó mô tả hành vi của một chương trình hoặc hệ thống khác”

Thông thường, chương trình mô hình (MP-Model Program) sẽ nhỏ gọn và đơn giản

hơn so với việc thực hiện (Impl - implementation) MP có thể được phân tích để kiểm

tra các lỗi thiết kế trong Impl, và có thể tạo ra các ca kiểm thử cho Impl

Trong NModel, các MP được dùng trong hai cách đó là: MP hợp đồng (contract model program) và MP kịch bản (scenario model program) Trong đó, MP hợp đồng biểu diễn cho tất cả các hành vi được phép của Impl còn MP kịch bản biểu diễn cho một tập hợp số lần chạy của một trường hợp kiểm thử

Hiện nay, NModel hỗ trợ hai ngôn ngữ để viết các chương trình mô hình đó là: C# và một biểu diễn có giới hạn cho các máy trạng thái hữu hạn (FSMs-Finite State Machines) Các MP hợp đồng thường được viết bằng C#, còn các MP kịch bản thường được biểu diễn dưới dạng FSMs

Một chương trình mô hình C# sử dụng các thuộc tính và kiểu dữ liệu từ thư viện NModel Nó sử dụng các không gian tên và tham chiếu NModel.dll Các phương thức trong MP biểu diễn các hành động (các đơn vị hành vi) của Impl Các biến trong

MP biểu diễn trạng thái (thông tin được lưu trữ) của Impl

3.1.3 Khái niệm phân tích dựa trên mô hình

“Phân tích dựa trên mô hình là sử dụng một MP để gỡ lỗi và cải thiện các đặc

tả cũng như các thiết kế, bao gồm các bản mô tả và các giao thức kiến trúc.”[4] MP

được viết bằng ngôn ngữ C# hoặc biểu diễn dưới dạng máy trạng thái hữu hạn (FSM)

MP hoàn toàn được phân tích tự động

Ngoài ra, MP có thể được phân tích một cách kỹ lưỡng hơn bởi một kỹ thuật được gọi là thăm dò Thăm dò là một kỹ thuật cơ bản để phân tích các MP, nó đạt hiệu quả trong nhiều lần chạy mô phỏng Việc thăm dò thực hiện các phương thức của MP một cách tự động

Trong NModel, công cụ mpv (Model Program Viewer) thực hiện việc thăm dò

và hiển thị các kết quả như một sơ đồ chuyển trạng thái Các chuyển đổi trạng thái (các lời gọi phương thức) được thể hiện dưới dạng mũi tên

3.1.4 Khái niệm kiểm thử dựa trên mô hình

Kiểm thử dựa trên mô hình (MBT – Model-based testing) là kiểm thử dựa trên một mô hình mô tả cách chương trình hoạt động, mô hình được sử dụng để sinh các ca kiểm thử (test cases) một cách tự động

Theo tài liệu [4] thì “Kiểm thử dựa trên mô hình là một kỹ thuật kiểm thử mà

các hoạt động của hệ thống được chạy thử trong một thời gian sẽ được dự đoán trước,

nó được thực hiện bởi một đặc tả hình thức hoặc một mô hình của hệ thống.”

MBT thực chất là một tập hợp các đặc tả đầu vào của phần mềm Nó thực sự có

ý nghĩa cho kiểm thử chức năng và nó chính là một kỹ thuật kiểm thử hộp đen MBT được dựa vào tiền đề rằng độ ổn định và tin cậy của quy trình kiểm thử có thể đảm bảo chất lượng cao của phần mềm

Sơ đồ đơn giản cho thấy cách MBT hoạt động được mô tả trong hình 3.1:

Hình 3.1: Sơ đồ hoạt động của MBT

3.1.5 Chương trình mô hình trong quy trình phần mềm

Các chương trình mô hình có thể thay đổi cách phát triển phần mềm Các sản phẩm phát triển có thể được kiểm chứng và kiểm thử sớm hơn trong dự án Việc phân tích với các chương trình mô hình có thể kiểm tra bản đặc tả và thiết kế giống như kiểm thử đơn vị kiểm tra mã lệnh (code), do đó các vấn đề có thể được phát hiện và sửa ngay lập tức Cũng tương tự như việc phát triển phần mềm theo kiểu truyền thống, các chương trình mô hình cũng tuân thủ theo các bước trong quy trình theo mô hình chữ V

Hình 3.2: Mô hình chữ V trong phát triển phần mềm dựa trên mô hình

Để thực hiện kiểm thử phù hợp, kiểm thử viên phải viết một bản “test harness” (khai thác kiểm thử) mà cặp đôi Impl với mô hình thông qua công cụ kiểm thử Bản

“test harness” này làm cho sự tương ứng giữa mô hình và Impl hoàn toàn rõ ràng Viết bản khai thác, và thực hiện bước tiếp theo, đóng vòng lặp từ mô hình quay trở lại Impl

Nó xác nhận mô hình với một mức độ triệt để không phải dễ dàng đạt được trong các

dự án mà không sử dụng các mô hình để kiểm thử

3.2 Hệ thống với các mô hình hữu hạn

3.2.1 Chương trình mô hình

3.2.1.1 Hành động (Action)

“Hành động (Actions) là các đơn vị của hành vi” Trong nhiều loại hệ thống, gồm các hệ thống máy tính, hành vi được tạo thành từ các bước rời rạc không liên tục Mỗi bước là một hành động Một hành động có thể được tạo nên bởi một số hành động nhỏ hơn, nhưng một hành động là nguyên tử có nghĩa là: khi nó bắt đầu, nó chạy đến khi hoàn thành mà không bị ngắt hoặc được hình thành trước (preempted) bởi một hành động khác Đối với mỗi loại hành động trong Impl đều có một phương thức trong

MP Khi MP chạy, mỗi lời gọi phương thức biểu diễn một hành động trong Impl

“Trạng thái là thông tin được lưu trữ trong một chương trình hoặc hệ thống tại một thời điểm” Trạng thái của Impl được biểu diễn bởi các biến của MP Mỗi nhiệm

vụ cụ thể của các giá trị cho các biến trong MP biểu diễn một trạng thái cụ thể (1 tình huống) của Impl Các biến trong MP biểu diễn trạng thái Impl được gọi là các biến trạng thái (để phân biệt chúng với các biến địa phương của MP, các tham số, ) Các biến trạng thái trong MP không cần tương ứng chính xác cho các biến chương trình trong Impl; chúng có thể biểu diễn thông tin không được lưu trữ trong các biến Impl (vd: các thông điệp chuyển tiếp)

Tất cả các chương trình hoặc hệ thống đều bắt đầu với một trạng thái khởi tạo Trạng thái khởi tạo thường là trạng thái rỗng hoặc nhàn rỗi (idle) Hành vi sẽ tiếp tục cho đến khi hệ thống đạt được một trạng thái chấp nhận (accepting state) Một trạng thái chấp nhận thường là một trạng thái mà mục tiêu của chương trình đã đạt được Hệ thống có thể dừng lại ở một trạng thái chấp nhận hoặc nó có thể tiếp tục bắt đầu công việc mới Một chuỗi các hành động bắt đầu trong trạng thái khởi tạo và kết thúc trong trạng thái chấp nhận được gọi là một đường chạy (run) hoặc một dấu vết (trace) Một đường chạy không được kết thúc trong trạng thái mà chưa là trạng thái chấp nhận nhưng nếu MP không xác định bất kỳ trạng thái chấp nhận nào thì một đường chạy có thể kết thúc ở trạng thái bất kỳ Các đường chạy của một MP là một chuỗi các lời gọi phương thức

Một kịch bản là một bộ sưu tầm các đường chạy thích hợp với một số tình huống cụ thể hoặc mục đích, chẳng hạn như một bộ kiểm thử (test suite) Một MP kịch bản định nghĩa một kịch bản; nó có thể thực hiện tất cả các đường chạy của kịch bản Một MP kịch bản thường có một bộ sưu tầm nhỏ các đường chạy, thỉnh thoảng chỉ có một đường Thông thường, một MP chỉ mô hình một tập con hoặc một lát (slice) tính năng của Impl Một MP biểu diễn Impl ở một mức độ trừu tượng mà nhiều chi tiết bị

bỏ qua hoặc đơn giản hóa

3.2.1.3 Cấu trúc chương trình mô hình hợp đồng C#

Cấu trúc MP: Một MP phải bao gồm các câu lệnh using để sử dụng không

gian tên của thư viện mô hình NModel Tất cả không gian tên này được cung cấp bởi

thư viện NModel.dll Một MP được biên dịch tới một thư viện

Csc /t: library / r: “%DEVPATH% \NModel.dll” [Ten MP].cs

Trong đó DEVPATH là một biến môi trường mà lưu trữ đường dẫn tới thư mục chứa thư viện, VD: C: \Program Files\NModel\bin

Mỗi MP được code theo không gian tên của nó Một MP bao gồm các hành động và các biến đã được định nghĩa bởi các kiểu đã được khai báo trong không gian tên của nó Tên của không gian tên là tên MP Một MP có thể bao gồm nhiều hơn một

phải thực hiện qua các bước sau:

 Bước 1: Phân tích sơ bộ để quyết định mục đích của MP

 Bước 2: Chọn hành động, tính năng cần mô hình

 Bước 3: Chọn các biến trạng thái

 Bước 4: Lập trình MP theo cấu trúc

3.2.2 Thăm dò và phân tích chương trình mô hình hữu hạn

3.2.2.1 Máy trạng thái hữu hạn (FSM-Finite State Machines)

Theo tài liệu [4], FSM được định nghĩa như sau: “Một FSM chỉ đơn giản là một

bộ sưu tập hữu hạn các phép chuyển trạng thái Các thành phần trong FSM gồm có: đối số đầu tiên là trạng thái khởi tạo, đối số tiếp theo là một danh sách các trạng thái chấp nhận, và đối số cuối cùng là một danh sách các phép chuyển trạng thái Trong

đó, mỗi phép chuyển trạng thái là một bộ ba: trạng thái hiện tại, hành động (nhãn chuyển tiếp), và trạng thái tiếp theo”

Các đường chạy và các kịch bản (Runs and scenarios)

Mỗi FSM mô tả tất cả những đường chạy mà có thể đạt được bằng cách đi qua một đường xung quanh các nút và các liên kết trong đồ thị của nó Đây là một mô tả phi hình thức của thuật toán để tạo ra một đường chạy: Bắt đầu trong trạng thái khởi tạo Trong một trạng thái mà có những chuyển tiếp sang các trạng thái tiếp theo, lựa chọn bất kỳ trạng thái nào Nếu một trạng thái đạt đến mức không có chuyển tiếp đi thì

đường chạy kết thúc trong trạng thái đó Hoặc, nếu trạng thái đã được chỉ định một trạng thái chấp nhận thì đường chạy kết thúc trong trạng thái chấp nhận đó

Khái niệm kịch bản theo tài liệu [4]: “Một bộ sưu tập các đường chạy liên quan

được gọi là một kịch bản Toàn bộ bộ sưu tập các đường chạy có thể được sinh từ một FSM được gọi là kịch bản được định nghĩa bởi FSM”

FSMs kịch bản và FSM đúng (the true FSM)

Khái niệm FSMs kịch bản theo tài liệu [4]: “Một FSM mà mục đích của nó là

để định nghĩa một kịch bản được gọi là một FSM kịch bản” Nó có thể định nghĩa nhiều FSMs kịch bản khác nhau cho bất kỳ MP nào; mỗi FSM kịch bản khác nhau định nghĩa một bộ sưu tập các đường chạy khác nhau Có một FSM có thể tạo ra tất cả các đường chạy của một MP đó là FSM đúng của nó Khi MP có một số lượng trạng thái và hành động nhỏ, nó có thể viết ra FSM đúng của nó

3.2.2.2 Thăm dò

Việc thăm dò sẽ tự động sinh ra một FSM từ một chương trình mô hình FSM

có thể được sử dụng để trực quan hoá, phân tích và tạo test ngoại tuyến Trong phần này, cách thăm dò một MP với thư viện và các công cụ sẽ được giải thích

Việc truy cập chương trình mô hình:

Trước hết, xét ví dụ về phương thức và lớp factory của một MP NewsReader như sau:

public static class Factory

LibraryModelProgram từ chương trình mô hình được biên dịch Tất cả các công cụ

truy cập MP gián tiếp bằng cách gọi các phương thức của đối tượng này

Phương thức factory nên được đặt vào trong lớp factory của riêng nó Lớp factory luôn luôn có cùng hình thức, chỉ có một vài định danh phải được thay đổi cho

mỗi MP cụ thể Lớp factory phải được khai báo public static Các lớp chứa biến trạng thái và các phương thức hành động của MP không cần public mà chúng mặc định là truy cập private Tên lớp factory thường đặt là Factory và phương thức factory đặt là

Create Trong phần thân của phương thức factory, tại hàm tạo LibraryModelProgram

đối số của toán tử typeof phải cùng lớp Đối số thứ hai là một chuỗi chứa tên của

không gian tên MP

Để gọi một công cụ trên một MP, tham chiếu hội đồng chứa MP được biên dịch

và cung cấp tên đầy đủ của phương thức factory trong hội đồng đó Ví dụ lệnh gọi mpv trên MP NewsReader là:

Việc thăm dò và quan sát MP trong khi phát triển có thể kiểm tra thường xuyên xem nó có hoạt động như ý định hay không Ngay khi một vài hành động được viết mã (code) thì đã có thể bắt đầu việc thăm dò

Thăm dò tương tác và mô phỏng:

Công cụ mpv cũng có thể thăm dò tương tác, thực hiện và hiển thị một vài chuyển tiếp tại một thời điểm dưới sự điều khiển của người dùng Việc thăm dò tương tác tạo nên sự thuận tiện hơn để mô phỏng các đường chạy cụ thể Mô phỏng để kiểm tra xem đường chạy thành công hay bị chết

Thuật toán thăm dò:

Trong phần này, cách làm việc của việc thăm dò sẽ được giải thích bằng một thuật toán (hình 3.3) Để sử dụng công cụ mpv khi phân tích các MP hữu hạn thì không cần phải hiểu thuật toán Nhưng nếu phân tích các MP vô hạn thì phải cung cấp thêm thông tin để hướng dẫn thăm dò Việc thăm dò tạo ra một FSM từ một MP, tự động lựa chọn các hành động để thực hiện, giám sát và ghi chép mỗi chuyển trạng thái khi nó xảy ra

 State: Trạng thái của một MP được biểu diễn bởi một từ điển kết hợp mỗi tên

biến trạng thái với giá trị của nó

 Action: Lời gọi của một hành động gồm có tên phương thức hành động và tất cả

 State InitialState: Thuộc tính trả về trạng thái khởi tạo của MP

 Set<Action> GetActions(State s): Phương thức trả về tập hợp hành động được kích hoạt trong trạng thái s

 State GetTargetState(State s, Action a): Phương thức trả về trạng thái tiếp theo đạt được bằng cách thực hiện hành động a trong trạng thái hiện tại s

Hình 3.3: Một thuật toán thăm dò đầy đủ

 Set<T>: Bộ không theo thứ tự của các phần tử có kiểu T, với các hàm

tạo Set<T>(), Set<T>(x,y,z), và phương thức Add, mà trong đó s.Add(x)

trả về một tập hợp mới có chứa tất cả các phần tử của tập s và phần tử x

 Sequence<T>: Bộ có thứ tự các phần tử thuộc kiểu T, với các thuộc tính Head (phần tử đầu tiên), Tail(tất cả nhưng trừ phần tử đầu tiên), và

phương thức AddFirst (đẩy một phần tử lên đầu), và AddLast (nối thêm

một phần tử vào cuối)

Hình 3.3 chỉ ra một thuật toán thăm dò hoàn toàn Frontier là bộ các trạng thái

đã đạt được nhưng các chuyển tiếp được kích hoạt của nó chưa được thực hiện Khi việc thăm dò bắt đầu, chỉ có trạng thái khởi tạo là thuộc vào tập Frontier Việc thăm dò tiếp tục (proceed) bằng cách thực hiện các chuyển tiếp được kích hoạt trong Frontier Khi thực hiện, một chuyển tiếp đạt được một trạng thái mà trước đó chưa đạt được, trạng thái đó được thêm vào tập Frontier Khi tất cả các chuyển tiếp được kích hoạt trong một trạng thái đã được thực hiện, trạng thái đó được gỡ bỏ từ tập Frontier và được thêm vào bộ sưu tập các trạng thái đã được thăm dò Thuật toán kết thúc khi tập Frontier rỗng (Chú ý rằng nếu MP là hữu hạn thì thuật toán luôn luôn có kết thúc)

3.2.2.3 Phân tích

Việc phân tích nhằm phát hiện ra các lỗi thiết kế của các hệ thống Có hai loại

phân tích là phân tích an toàn (Safety analysis) và phân tích hoạt động được (liveness)

Phân tích an toàn

Theo tài liệu [4]: “Phân tích an toàn là kiểm tra bất cứ điều gì xấu có thể xảy ra

Nó tìm kiếm các trạng thái không an toàn vi phạm các yêu cầu an toàn Các yêu cầu được thể hiện bằng biểu thức Boolean được gọi là một bất biến (invariant) mà bất biến được cho là đúng trong mọi trạng thái có thể đạt được.”

Theo tài liệu [4], “Một trạng thái không an toàn là một trạng thái mà một bất biến là sai Đối với các công cụ, một bất biến là một trường, thuộc tính hoặc phương

thức Boolean với thuộc tính [StateInvariant].”

Phân tích an toàn phụ thuộc vào việc viết một bất biến diễn tả thuộc tính an toàn mà ta muốn kiểm tra Cần phải xem xét đâu là những trạng thái được phép (tức trạng thái làm cho bất biến đúng) và những trạng thái bị cấm (tức trạng thái làm cho bất biến sai) Việc xác định các trạng thái an toàn đòi hỏi sự phán đoán và sự hiểu biết mục đích của chương trình.Việc thăm dò có thể tìm tất cả các trạng thái không an toàn trong FSM đã được tạo ra

Phân tích tính hoạt động được

Theo tài liệu [4] thì “Phân tích tính hoạt động được là kiểm tra xem có bất cứ điều gì tốt sẽ xảy ra Nó tìm kiếm các trạng thái chết mà từ trạng thái đó mục tiêu không thể đạt được Các yêu cầu hoạt động được thể hiện bằng cách xác định các trạng thái chấp nhận mà tại đó mục tiêu đạt được Việc xác định các trạng thái chấp nhận bằng cách viết một biểu thức điều kiện Boolean mà biểu thức này luôn đúng trong mọi trạng thái chấp nhận.”

Theo tài liệu [4] thì “Một trạng thái chết là một trạng thái mà từ đó một trạng thái chấp nhận không thể đạt được” Đối với các công cụ, một điều kiện trạng thái chấp nhận là một trường, thuộc tính hoặc phương thức Boolean được dán nhãn với

thuộc tính [AcceptingStateCondition]

Phân tích tính hoạt động được phụ thuộc vào việc viết một điều kiện trạng thái chấp nhận mà mục tiêu chương trình có ý định đạt được Một trạng thái chấp nhận thường được định nghĩa là một trạng thái mà chương trình được phép dừng lại Tuy nhiên, nhiều chương trình có bộ điều khiển nhúng không bao giờ dừng lại Để sử dụng phân tích tính hoạt động được với hệ thống như vậy thì định nghĩa phải được mở rộng Khi đó, một trạng thái chấp nhận được định nghĩa là một trạng thái mà mục đích chương trình đạt được Trong đó, một vài đơn vị làm việc hay tác vụ được hoàn thành, không có phần công việc hay tác vụ bị bỏ dở

3.2.3 Cấu trúc chương trình mô hình với thành phần (Composition)

Cơ chế để cấu trúc các MP ở quy mô lớn đó là thành phần (composition) Cơ chế này rất linh hoạt nên có thể được sử dụng theo nhiều cách Nó được sử dụng để giới hạn việc phân tích và kiểm thử với các kịch bản cụ thể được quan tâm

3.2.3.1 Điều khiển kịch bản (Scenario control)

Theo tài liệu [4] thì “Vấn đề giới hạn việc phân tích và kiểm thử các đường chạy cụ thể được quan tâm được gọi là điều khiển kịch bản”

Điều khiển kịch bản là cần thiết vì một MP hành động thường được viết như một bản đặc tả hoặc bản hợp đồng (contract) Do đó, nó mô tả tất cả mọi thứ mà Impl phải làm, có thể làm và không thể làm Kết quả là MP thường mô tả một số lượng lớn các đường chạy Khi phân tích và đặc biệt là khi kiểm thử, các kiểm thử viên thường không muốn xem xét tất cả các đường chạy này mà họ muốn giới hạn việc xem xét của mình với một kịch bản cụ thể (gồm có một bộ sưu tập các đường chạy có lẽ chỉ có một đường là thích hợp)

3.2.3.2 Thành phần (Composition)

Khái niệm thành phần [4]: “Thành phần là việc kết hợp các chương trình mô hình riêng biệt vào một MP mới được gọi là sản phẩm (product) Sản phẩm được hình thành bằng cách soạn các MP M1 và M2 được viết M1xM2 hoặc M1*M2.”

Thành phần được thực hiện tự động bởi các công cụ phân tích và kiểm thử khi nhiều MP được đặt tên trên dòng lệnh Sau đó, các công cụ có thể phân tích hoặc kiểm thử từ sản phẩm Thành phần được sử dụng cho bản điều khiển kịch bản Sau đây, là phần giải thích cách mà thành phần được thực hiện và mô tả một số kiểu bổ sung cho việc viết mã các MP làm cho nó dễ dàng để viết các kịch bản cho thành phần

Thành phần có thể hiểu được (Understanding composition)

Thành phần kết hợp các MP riêng biệt có không gian tên riêng biệt và có thể được biên dịch vào các hội đồng riêng biệt Bất kỳ số lượng MP nào đều được chấp nhận bởi tất cả các công cụ

Sản phẩm của hai hoặc nhiều MP có tất cả các biến trạng thái và tất cả hành động của mỗi chương trình được biên soạn Ý tưởng chính trong thành phần là: các hành động được chia sẻ có cùng tên trong hai hoặc nhiều chương trình được biên soạn

là một hành động trong sản phẩm Chúng thực hiện cùng nhau, và có thể chỉ thực hiện khi tất cả các hành động đồng thời được kích hoạt trong mỗi chương trình của chúng

Yêu cầu trong thành phần là các hành động được chia sẻ phải được kích hoạt đồng thời trong mọi chương trình được biên soạn, chúng xảy ra thường xuyên có tác dụng giới hạn hành vi và loại bỏ một vài đường chạy Đó là lý do tại sao thành phần là hữu ích cho điều khiển kịch bản

Tuy nhiên, có một ngoại lệ quan trọng là: Các hành động không được chia sẻ có thể xen kẽ vào thứ tự bất kỳ trong sản phẩm, và có thể thực hiện bất cứ khi nào chúng được kích hoạt trong các chương trình riêng của chúng Nếu muốn ngăn chặn việc xen

kẽ này thì phải thêm những hành động đó tới các MP khác và vô hiệu hóa các hành động đó ở mọi trạng thái trong các MP khác

Xét một ví dụ nhỏ sau: M1 và M2 là các MP, M1 có các hành động A() và B(2) tạo nên các chuyển tiếp từ trạng thái khởi tạo 0 đến trạng thái 1 và đến trạng thái chấp nhận 2 (hình 3.4) M2 có các hành động B() và C() tạo nên các chuyển tiếp từ trạng