Một thuật toán thăm dò đầy đủ

Một phần của tài liệu (LUẬN văn THẠC sĩ) 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 (Trang 35 - 38)

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 để

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

thái 0 đến 1 và lặp lại, ở đây trạng thái 0 vừa là trạng thái khởi tạo vừa là trạng thái chấp nhận (hình 3.5). Sản phẩn của chúng là M1xM2 xuất hiện trong hình 3.6. Tất cả 3 hành động xuất hiện trong sản phẩm.

Một phần của tài liệu (LUẬN văn THẠC sĩ) 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 (Trang 35 - 38)

Tải bản đầy đủ (PDF)

(74 trang)