Có nên sử dụng chương trình Rules Engine để quản lý cấu trúc nghiệp vụ trong ứng dụng IoT không?

Biết một ngôn ngữ có nghĩa là có thể hiểu và nói được nhiều câu từ chưa từng được nói và nghe trước đây. Đối với con người chúng ta, thật tự nhiên khi nói những điều như “Tom thích bóng đá và bánh kếp”. Nhưng đối với những người không phải là nhà phát triển, họ phải bỏ ra nỗ lực rất nhiều thì may ra mới có thể dịch được những câu như vậy sang ngôn ngữ máy tính. Nếu chúng ta thực sự viết câu nói trên theo ngôn ngữ của chương trình máy tính, điều đó có nghĩa là (đối với máy), “Tom chỉ hạnh phúc khi xem bóng đá trong khi ăn bánh kếp”.

Vì vậy, khi viết phần mềm, những gì bạn đang làm về cơ bản là dịch các yêu cầu của người dùng (câu chuyện của con người được mô tả bằng ngôn ngữ của con người) thành các quy tắc (các cấu trúc có điều kiện được viết bằng ngôn ngữ máy tính). Và trong khi làm điều đó, bạn cần nhận thức được sự khác biệt giữa logic nói của con người và logic nói trên máy tính để bạn không kết luận “Tom chỉ tìm thấy hạnh phúc khi xem bóng đá trong khi ăn bánh kếp”.

Vì ngôn ngữ máy tính bao gồm cả Logic đề xuất (giả định rằng thế giới chứa các sự kiện) và Logic thứ tự (giả định rằng thế giới chứa các đối tượng, quan hệ và chức năng), cho nên người ta có thể lập luận rằng hai yếu tố gồm các nhà phát triển được trang bị tốt kỹ năng và ngôn ngữ máy tính là tất cả những gì cần thiết để cho phép họ viết bất kỳ thuật toán và câu lệnh điều kiện (quy tắc) cần thiết để dịch một yêu cầu của con người thành mã.

Theo lập luận của các nhà khoa học, điều đó là không đúng, chủ yếu là do ba khó khăn chính cản trở các nhà phát triển - khó khăn đầu tiên được đưa ra bởi sự phức tạp của logic, như chúng ta sẽ thấy dưới đây. Còn khó khăn thứ hai và thứ ba (do thời gian và sự không chắc chắn mang lại) sẽ được đề cập trong các bài viết tiếp theo.

Vì vậy, bây giờ, hãy xem xét kỹ hơn về quá trình xây dựng các ứng dụng phần mềm bằng logic máy tính được tạo thành từ các cấu trúc có điều kiện.

Boolean Algebra là ngôn ngữ của toán học và máy móc (tương đương với Logic đề xuất) và nó có các cấu trúc chính xác và được xác định rõ ràng để tạo nên từ vựng của nó.

Vì vậy, hãy nhìn vào cách chúng ta đọc bảng này:

Chẳng hạn, Quy tắc De Morgan nói như sau: phủ định của "a và b" tương đương với "không phải là a hoặc không phải là b", trong khi phủ định của "a hoặc b" tương đương với "không phải a và không phải b".

Bây giờ, hãy tưởng tượng một chương trình phần mềm trong đó nhiều câu lệnh sử dụng Boolean Algebra được nối với nhau. Các câu lệnh có điều kiện càng dài thì càng khó kiểm tra tính hợp lệ của chúng bằng cách đọc mã một mình. Chẳng hạn, các câu lệnh này tương đương: (a = b && c == d)), (a

Khó khăn trong việc xác minh logic dự định cũng có thể được đo lường bằng một số gọi là độ phức tạp chu kỳ, mà Thomas McCabe đã đưa ra vào năm 1976. Độ phức tạp theo chu kỳ là một phép đo định lượng của số lượng đường dẫn độc lập tuyến tính thông qua mã nguồn của chương trình. Mặc dù tính hữu ích của nó là thước đo chất lượng phần mềm vẫn còn bị nghi ngờ, nhưng nói chung, để kiểm tra đầy đủ một mô-đun, tất cả các đường dẫn thực hiện thông qua mô-đun phải được kiểm tra. Điều này cũng ngụ ý rằng một mô-đun có độ phức tạp cao hơn là khó hiểu hơn, vì lập trình viên phải hiểu các con đường khác nhau và kết quả của các con đường đó.

Như các nhà thiết kế mạch có thể chỉ ra, có các phương pháp như đơn giản hóa Boolean và ánh xạ Karnaugh để đơn giản hóa logic máy tính. Bản đồ K có thể giúp ích, nhưng ai đó muốn đọc mã thì phải hiểu ý nghĩa của nó, một thứ hoàn toàn không dễ dàng như với Bản đồ K.

Vì vậy, những gì chúng ta đã thấy là sự phức tạp của logic đã mang lại hai rào cản lớn cho các nhà phát triển đang cố gắng dịch các yêu cầu của người dùng thành các câu lệnh (quy tắc) chính xác khi thiết kế phần mềm:

1. Đầu tiên, con người thường sử dụng các câu nói "không chuẩn logic" khi diễn đạt các quy tắc sử dụng ngôn ngữ nói
2. Thứ hai, ngay cả khi các công trình này được mã hóa chính xác, con người vẫn khó kiểm tra logic dự định của mình nếu các câu điều kiện quá dài.

Theo bài viết này rằng đây là một trong những thách thức mà việc sử dụng một chương trình Rules Engine có thể giải quyết.

Xây dựng logic phức tạp cho các ứng dụng IoT với chương trình Rules Engine

Logic ứng dụng thực tế rất phức tạp. Nó chắc chắn sẽ liên quan đến nhiều biến hơn bất kỳ ví dụ nào trong sách giáo khoa. Logic phức tạp được tạo thành từ các cấu trúc logic bậc cao (HOL), đó là lý do tại sao lại quan trọng cần chương trình Rules Engine hỗ trợ chúng. Để quản lý điều đó, chương trình Rules Engine nên hỗ trợ như sau:

1. Kết hợp nhiều kết quả nhiều định dạng ngoại nhị phân của các hàm (Quan sát) trong Quy tắc, vượt ra ngoài các trạng thái đúng hoặc sai của Boolean

Kết hợp nhiều trạng thái nhiều kết quả định dạng ngoài nhị phân là những gì chúng ta làm. Ví dụ, ở đây là chúng ta sẽ tính đến vô số yếu tố trước khi chúng ta quyết định có nên đi du lịch thành phố vào cuối tuần hay không. Cụ thể, chúng ta xem xét thời tiết (bao gồm các trạng thái: mưa nhẹ, bão lớn, tuyết, bầu trời nhiều mây, bầu trời đầy nắng) kết hợp với ngày trong tuần, chi phí chuyến bay và chỗ ở, v.v.

2. Xử lý các điều kiện bỏ phiếu đa số trong Quy tắc Rules Engine

Bỏ phiếu đa số đề cập đến việc thực hiện hành động dựa trên hầu hết các điều kiện cho hành động đó được đáp ứng, nhưng không nhất thiết là tất cả. Khả năng này rất quan trọng, ví dụ, trong các hệ thống chẩn đoán chăm sóc sức khỏe trong đó chỉ một số chỉ số có thể chỉ ra một vấn đề y tế chứ không phải tất cả các chỉ số mới đưa ra được kết quả. Một ví dụ khác mà nó được sử dụng là trong các hệ thống điều khiển "fly in wire", đó là máy tính dự phòng sẽ tiến hành dự đoán ba lần bay Boeing 777, sao chép các tính toán trong ba bộ xử lý và sau đó thực hiện bỏ phiếu đa số để xác định kết quả cuối cùng.

3. Xử lý các giả định có điều kiện dựa trên kết quả của các quan sát trước đó

Một giả định dựa trên quan sát trước đó là: "Nếu máy gặp trục trặc, thì kiểm tra cơ sở dữ liệu tài sản; nếu không, không làm gì cả."

Logic phức tạp và kích thước thời gian là hai trong số những thách thức lớn nhất trong phát triển ứng dụng IoT mà một công cụ quy tắc có thể giải quyết. Cái thứ ba được đưa ra bởi khái niệm về sự không chắc chắn, mà chúng ta sẽ giải quyết trong các bài viết sau. Hãy theo dõi!