GIỚI THIỆU
Đặ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 độ.
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.
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.
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.
TỔNG QUAN VỀ HỆ THỐNG NHÚNG
Các khái niệm về 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
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
Hệ thống nhà thông minh
Cấu trúc phần cứng hệ thống nhúng
2.2.1.1 Đơn vị xử lý trung tâm (CPU)
CPU là viết tắt của chữ “Central Processing Unit” Nó là đơn vị xử lý trung tâm đóng vai trò nhƣ bộ não chịu trách nhiệm thực thi các phép tính và thực hiện các lệnh
CPU là một mạch tích hợp phức tạp gồm hàng triệu transitor trên một bảng mạch nhỏ
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
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ý
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 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 2 N đị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 2 N -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:
Kiến trúc phần mềm nhúng
Kiến trúc phần mềm đơn giản nhất có thể đƣợc gọi là “round robin” Kiến trúc Round robin không có ngắt, tổ chức phần mềm bao gồm một vòng lặp chính Trong đó, bộ vi xử lý rất đơn giản, nó làm nhiệm vụ thăm dò từng thiết bị đính kèm theo lần lƣợt và cung cấp dịch vụ nếu có yêu cầu Sau khi tất cả các thiết bị đã đƣợc phục vụ thì vòng lặp bắt đầu lại từ đầu Kiến trúc phần mềm Round robin đƣợc minh họa bằng đồ thị và đoạn giả mã nhƣ hình 2.8
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.
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ờ
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
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ụ
NGHIÊN CỨU VỀ KIỂM THỬ VÀ PHÂN TÍCH DỰA TRÊN MÔ HÌNH
Tổng quan
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:
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
Hệ thống với các mô hình hữu hạn
“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
“Hành vi của một chương trình hoặc hệ thống là bộ sưu tập đầy đủ của tất cả các đường chạy mà nó có thể thực thi” Một MP hợp đồng là một bản đặc tả mô tả tất cả hành vi đƣợc phép của Impl: nó mô tả mọi thứ mà Impl phải làm, có thể làm, và không được làm Mọi đường chạy mà một MP hợp đồng có thể thực thi biểu diễn một đường chạy mà Impl của nó phải có khả năng thực thi Một MP hợp đồng không thể thực thi bất cứ đường chạy nào thì Impl của nó bị cấm thực thi Một MP hợp đồng thường có bộ sưu tầm đường chạy lớn
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 lớp (hoặc các kiểu khác) using NModel; using NModel.Attributes; using NModel.Execution; namespace [ten MP]
{ Định nghĩa các biến Khai báo biến trạng thái
Trạng thái dữ liệu Các điều kiện cho kiểm thử (thường là điều kiện trạng thái chấp nhận) Chi tiết các hành động
Phương thức factory (là phương thức tạo đối tượng chương trình mô hình)
Các bước xây dựng một MP hợp đồng: Để xây dựng một MP thì chúng ta 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ó
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 { public static ModelProgram Create() { return new LibraryModelProgram(typeof(Factory).Assembly,
XÂY DỰNG DEMO VÀ KIỂM THỬ HỆ THỐNG VỚI NMODEL
Cài đặt NModel
Để cài đặt NModel, máy tính phải có NET và không cần thiết phải có Visual Studio
Phiên bản Net có thể làm việc là Framwork NET 3.5 Nếu có sẵn phiên bản 2 hoặc 3 thì cũng làm việc được Sau đó làm theo các bước sau để cài đặt :
Bước 1 : Download Nmodel.msi Mở và cài đặt (chọn Typical Install)
Việc thực thi file msi cài đặt thư viện Nmodel, 4 chương trình mpv, mp2dot, otg, và ct, và trợ giúp trực tuyến (online help) Đây là tất cả những gì cần chạy chương trình, tạo và sử dụng các chương trình mô hình của riêng mình
Bước 2: Để chạy mpv, công cụ bố cục đồ họa (the graph layout engine) GLEE phải đƣợc cài đặt Chú ý rằng GLEE sử dụng giấy phép bản quyền ít hơn Nmodel
Sau khi đã cài đặt cả NModel và GLEE, thì phải copy GLEE DLLs vào trong thƣ mục bin của NModel Trong quá trình cài đặt nơi mà cả hai đƣợc cài đặt ở vị trí mặc định, điều đó có thể được thực hiện bằng đường dẫn:
Cd C: \Program Files\Microsoft Research\GLEE\bin Copy *.dll…\ \ \Nmodel\bin
Ngoài mpv ra, mp2dot (Model Program to Dot) cũng có thể đƣợc sử dụng
Chương trình mp2dot không yêu cầu GLEE, và được bao gồm bởi giấy phép bản quyển của NModel nên dễ dàng hơn
Bước 3: Sau khi cài đặt xong phải thiết lập biến môi trường bằng cách:
Nhấn phải chuột vào biểu tƣợng Computer Khi đó, xuất hiện hộp thoại, chọn Remote Settings =>chọn Advanced => chọn Environment Variables => chọn Path =>
Copy đường dẫn C:\Windows\Microsoft.NET\Framework\v3.5 và C:\Program Files\NModel\bin trong ổ C và dán vào ô Variable value và chọn OK.
Cách sử dụng các công cụ mpv, otg, ct
Công cụ mpv đƣợc sử dụng để hình dung và phân tích hành vi của một hoặc nhiều chương trình Nó thực hiện thăm dò, nó tạo ra một máy trạng thái hữu hạn FSM từ một MP MPV hiển thị đồ thị của FSM đƣợc tạo, đồng thời khảo sát và hiển thị thành phần của tất cả các chương trình mô hình được có tên trên dòng lệnh, nó có thể là các MP C# hoặc các FSM MPV cung cấp nhiều lựa chọn (trên dòng lệnh và giao diện sử dụng của nó) để điều chỉnh đồ thị được hiển thị, lưu trữ và khôi phục các kết quả của việc thăm dò Nó cũng cung cấp cơ sở để kiểm tra các trạng thái (biến chương trình và giá trị của chúng), và để khám phá các chương trình tương tác (từng bước, làm việc chuyển tiếp từ một vài trạng thái quan tâm)
Bằng cách tìm kiếm FSM, mpv có thể thực hiện phân tích an toàn để kiểm tra xem hệ thống có đạt đƣợc các trạng thái bị cấm không, và phân tích tính hoạt động đƣợc để xác định các trạng thái chết
Công cụ mpv đòi hỏi phần mềm GLEE phải đƣợc cài đặt Các công cụ còn lại không yêu cầu GLEE
Cách sử dụng (Usage) mpv: mpv [/reference:]*[/mp:]* /initialTransitions:]*
[/stateShape:{Box|Circle|Diamond|Ellipse|Octagon|Plaintext}]*
[/direction:{TopToBottom|LeftToRight|RightToLeft|BottomToTop}]*
[/testSuite:]* [/fsm:]* [/startTestAction:]*
Ví dụ: mpv @mpv args.txt mpv /fsm:M1.txt /fsm:M2.txt mpv /testSuite:ContractTest.txt mpv /r:NewsReaderUI.dll NewsReader.Factory.Create mpv /r:NewsReaderUI.dll /mp:NewsReader mpv /r:Controller.dll Reactive.Factory.Create /safetyCheckIsOn+ mpv /r:Controller.dll /mp:Reactive /safetyCheckIsOn+
Công cụ otg
Công cụ otg tạo ra một bộ kiểm thử ngoại tuyến (offline test suite) mà đạt đƣợc độ bao phủ liên kết của máy trạng thái hữu hạn (FSM) đƣợc tạo ra từ một MP Sau đó, bộ kiểm thử có thể đƣợc thực hiện bởi Conformance Tester (công cụ ct)
Cách sử dụng otg: otg [/reference:]* [/mp:]* [/file:]*
[/append[+|-]]* [/fsm:]* * @
Ví dụ: otg @otg args.txt otg /r:ClientServer.dll ClientServer.Factory.Create /fsm:Scenario.txt otg /r:ClientServer.dll /mp:ClientServer /fsm:Scenario.txt otg /r:ClientServer.dll ClientServer.Factory.Create /file:ContractTest.txt otg /r:ClientServer.dll /mp:ClientServer /file:ContractTest.txt
4.1.2.3 Công cụ ct Để thực hiện các test bằng cách sử dụng test runner ct, một bản khai thác kiểm thử phải đƣợc viết bằng C# để kết nối thực hiện đến ct Một bộ kiểm thử đƣợc tạo ra từ một MP bởi công cụ otg, hoặc ct có thể tạo ra các ca kiểm thử trực tiếp từ một MP khi test run thực thi, và một chiến lƣợc tùy chỉnh có thể đƣợc viết bằng C# mà ct sử dụng để tối đa hóa độ bao phủ theo tiêu chí đƣợc xác định ct /iut: [/modelStepper:] /reference:+
[/coverage:]* [/steps:]* [/maxSteps:]*
[/timeout:]* [/continueOnFailure[+|-]]* [/logfile:]*
[/randomSeed:]* [/overwriteLog[+|-]]* [/testSuite:]*
[/fsm:]* [/startTestAction:]* * @
Ví dụ: ct @ct args.txt ct /r:Stepper.dll /iut:ClientServerImpl.Stepper.Create /testSuite:ContractTest.txt ct /r:ClientServer.dll ClientServer.Factory.Create /r:Stepper.dll ^ /iut:ClientServerImpl.Stepper.Create /fsm:Scenario.txt /runs:1 ct /r:ClientServer.dll /mp:ClientServer /r:Stepper.dll ^ /iut:ClientServerImpl.Stepper.Create /fsm:Scenario.txt /runs:1
Xây dựng và thực nghiệm với demo hệ thống client/server
Trong luận văn này, tôi chọn bài toán về hệ thống nhúng để kiểm thử với NModel là thiết bị điều khiển từ xa – hệ thống client/server Bài toàn này đƣợc tham khảo trong tài liệu [4] Đây là một ứng dụng nhỏ nhưng tương đối đầy đủ Mục đích của bài toán là phát triển một hệ thống thiết bị phòng thí nghiệm bao gồm một cảm biến nhiệt độ kết nối với một máy tính nhúng, một mạng, và một máy tính khác đƣợc sử dụng để lưu trữ và phân tích dữ liệu (hình 4.1) Trên máy tính nhúng (Server) có một chương trình giám sát nhiệt độ được cài đặt Trên máy tính khác (Client) có một chương trình khai thác dữ liệu được cài đặt Các chương trình giao tiếp với nhau qua mạng bằng cách sử dụng giao thức TCP/IP (hình 4.2), vì vậy client có thể sử dụng internet để kết nối tới một server trong một nhà máy ở xa hoặc trạm thời tiết
Hình 4.1 Thiết bị điều khiển từ xa – Hệ thống Client/Server
Trước khi kiểm thử và phân tích ứng dụng demo được mô tả, tôi sẽ giải thích một số vấn đề về cách mà chương trình làm việc
Hai chương trình thực hiện cùng một giao thức, một thỏa thuận về cách làm việc cùng nhau Một giao thức đƣợc xác định bởi các quy tắc để hình thành những thông điệp và các quy tắc mà ràng buộc theo thứ tự các thông điệp Trong demo này,
Trong giao thức này, máy chủ bắt đầu trước, và đợi một kết nối từ một máy khách
Máy khách kết nối tới máy chủ và gửi một lệnh yêu cầu một phép đo nhiệt độ Máy chủ phản hồi bằng cách gửi trả lại nhiệt độ Sau đó máy khách có thể gửi một dòng lệnh khác, hoặc có thể đóng kết nối và thoát Nếu client đóng, server có thể đợi một client khác để kết nối, hoặc có thể thoát Server có thể chỉ chứa một kết nối client tại một thời điểm
Hình 4.2: Giao thức client/server
Giao thức của demo đƣợc thực hiện bằng cách sử dụng các socket, một giao diện lập trình ứng dụng API cho giao tiếp qua mạng TCP/IP Socket API là một trong những kỹ thuật cơ bản của Internet và quen thuộc với nhiều nhà phát triển Khung làm việc Net cung cấp một thực hiện của API này trong lớp Socket trong không gian tên
Thiết lập một kết nối yêu cầu nhiều bước, trong đó mỗi một đối tác gọi các phương thức trong socket API Trong Server, Socket tạo một socket nghe (a listener socket), Bind liên kết nó với một địa chỉ IP và số cổng, và Listen chuẩn bị cho một kết nối Accept thực hiện kết nối và tạo một connection socket để sử dụng cho kết nối
Trong Client, Socket tạo một cổng và Connect thực hiện kết nối Khi kết nối đƣợc thực hiện, cả hai đối tác gọi Send và Receive để trao đổi thông điệp Trong giao thức của demo, client gửi đầu tiên Cả hai đối tác gọi Close để kết thúc kết nối Client đóng trước Cuối cùng, server gọi Close trên socket nghe của nó
Giống như hầu hết các ứng dụng, chương trình “Monitor” và “Logger” của demo sử dụng các thƣ viện Chúng không gọi trực tiếp API các socket Net Thay vì đó, chúng gọi các phương thức trong lớp Client và Server được xây dựng Những lớp này là các hàm bao (wrappers) cho các socket, Net cung cấp một API tương tự nhưng đơn giản mà nó là chuyên ngành cho các ứng dụng thiết bị điều khiển từ xa Mỗi một phương thức hàm bao Socket, Bind gọi phương thức socket Net với tên giống nhau, nhưng sử dụng ít tham số hơn, hoặc các tham số thuận tiện hơn Ví dụ, các phương thức Receive của client và Send của Server xử lý các số dấu chấm phẩy động (các mẫu nhiệt độ) mà không phải là mảng của byte
4.2.2 Kiểm thử demo bằng NModel 4.2.2.1 Kiểm thử ngoại tuyến (Offline)
Quy trình kiểm thử chương trình bằng NModel thông qua các bước sau: xây dựng implementation, viết MP, sử dụng mpv để hình dung và phân tích, sử dụng otg để sinh bộ kiểm thử tự động, cuối cùng là sử dụng công cụ ct để chạy một bộ kiểm thử
Bước đầu tiên là xây dựng hai MP đầu vào từ thực hiện (implementation) client/server đã đƣợc xây dựng, đó là MP hợp đồng ClientServer (M1) và MP kịch bản (M2):
Mục đích của M1: là biểu diễn hệ thống phân tán với các chương trình chạy trên hai máy tính đƣợc kết nối mạng Client và Server thực hiện trong một chủ để duy nhất, đan xen các cuộc gọi phương thức của chúng theo một trật tự phù hợp với giao thức của chúng (hình 4.2) Tự động sinh và kiểm chứng các test run
Các hành động: Các hành động của client và server là riêng biệt Việc gửi và nhận của client không giống với việc gửi và nhận của server Do đó, các hành động bao gồm: ClientSend, ServerSend, ClientReceive, và ServerReceive
Các biến trạng thái: Trong ví dụ này, có hai loại ràng buộc theo trình tự đó là:
Socket phải đƣợc tạo (Created), đƣợc kết nối (Connected), và đóng theo giao thức Các hành động gửi và nhận phải thay thế, luôn luôn bắt đầu với hành động gửi Do đó, có 3 biến trạng thái cho trạng thái điều khiển là: ClientSocket, ServerSocket và Phase
Trạng thái dữ liệu: là nhiệt độ được lưu trữ trong bộ đệm nhận dữ liệu của client clientBuffer
Giá trị mong đợi trả về đƣợc tính toán sẵn: giới hạn 2 nhiệt độ là 99.9 và 100.0
Viết mã: các mã đƣợc viết bằng C# theo cấu trúc MP (chi tiết trong phần phụ lục)
MP kịch bản M2: được biểu diễn bởi máy trạng thái hữu hạn, M2 được lưu trữ trong file scenario.txt:
Transitions( t(0,ServerSocket(),1), t(1,ServerBind(),2), t(2,ServerListen(),3), t(3,ClientSocket(),4), t(4,ClientConnect(),5), t(5,ServerAccept(),6), t(6,ClientClose(),7), t(7,ServerCloseConnection(),8), t(8,ServerClose(),9)))
Bước thứ hai, sau khi đã có các MP đầu vào thì tiến hành phân tích chúng bằng công cụ mpv theo trình tự sau:
Khởi động chương trình cmd.exe
Gõ lệnh >build.bat để xây dựng các chương trình thư viện
Gõ lệnh >mpv @mpv_contract.txt để hiển thị FSM đúng của MP Khi đó đƣợc kết quả nhƣ hình 4.3:
Hình 4.3: FSM đúng của MP hợp đồng
Hình 4.3 hiển thị toàn bộ các trạng thái và đường chạy (runs) của MP, trạng thái được đánh dấu đường viền đậm là trạng thái kết thúc (trạng thái chấp nhận) Các trạng
Gõ lệnh >mpv @mpv_scenario.txt để hiển thị FSM của MP kịch bản Kết quả là FSM chỉ có duy nhất một đường chạy được hiển thị như trong hình 4.4
Hình 4.4: FSM của MP kịch bản
Gõ lệnh >mpv @mpv_composition.txt để hiển thị FSM của MP kịch bản đƣợc biên soạn cùng với MP hợp đồng (FSM có sử dụng điều khiển kịch bản) Kết quả , ta nhận đƣợc thể hiện trong hình 4.5 FSM này đã đƣợc giới hạn tối ƣu về số lượng đường chạy so với FSM của MP hợp đồng
Bước thứ ba, tạo các bộ kiểm thử (test suite) bởi công cụ otg:
