一、引子
在前面對LabVIEW介紹的文章中，關於框架開發的內容涉及很少。為了講解操作者框架（Actor Framework）的優缺點，也只是拿出來QDSM（Queue-Driven State Machine ）框架進行了比較。
所以，在寫這個開篇之前，其實一直想一篇關於LabVIEW框架開發的文章，講解一下當前的LabVIEW開發環境中，主要有哪些框架，各自的優缺點、使用情景，以及框架的演變歷程。腹稿有了大致的架構，寫完這篇文章，准備再找個時間寫一下。
二、正文
本系列有13個視頻，但是最后一個是基於NXG版本的開發，當前坑比較多，暫不考慮使用。
所以准備寫12篇筆記文章。
首先，進入本系列視頻文章的解讀：
在這個系列中，目的是讓大家了解如何使用Actor Framework，在LabVIEW中開發面向操作者的應用程序。操作者框架是LabVIEW中的一個高級概念，也是當前可以使用的官方支持的快速開發框架。
編程人員總希望以穩定可靠的方式，盡可能多地重用代碼。而Actor Framework（以下文中簡稱AF）滿足這個需求，它支持代碼重用。使用AF還有很多其他好處，當然，也有一些缺點，我們將在這個系列中的后面的文章中介紹這些缺點。
本系列的技術文章講解，需要技術人員可以熟練使用QMH模式，在LabVIEW中進行模塊化軟件開發的能力。
首先，我們將使用QMH模式，編寫一個基本需求，來演示其如何工作的。然后，再使用AF替代，用以表明這可能是一種更好的軟件開發方法。
根據常用的最佳軟件設計原則，我們將代碼分成具有高內聚性和低內聚性的模塊。
為了舉例說明這一點，在一個簡單的數據顯示應用程序中，我們編寫一個數據采集模塊、一個文件i/o模塊、一個用戶界面模塊和一個控制模塊，來組織不同循環之間的所有消息。程序框圖如下：
然后將基本的功能模塊用QMH框架寫出來，如下圖：
用戶界面模塊實際上由兩個循環組成，一個是基於事件的循環，另一個是基於鍵值的循環。
所謂的高內聚性，就是每個模塊都應該有一個明確的目的，只負責一件事，例如用戶界面模塊只負責接收和顯示數據或響應用戶輸入，但它不負責判斷文件是不是你的，也不具備做文件i/o的能力。低耦合，意味着一個模塊不應該依賴於另一個模塊。例如，即使I/O文件沒有加載，用戶界面也應該運行。
所以，內聚性指的是模塊本身如何編寫，而耦合指的是模塊如何依賴於其他模塊。高內聚性的主要好處是它的可讀性，如果你在一個模塊中有密切相關的函數，那么很清楚該模塊做什么的，也使該模塊變得可維護。
舉個可維護性的例子，假如，在寫入一個文件時有一個bug，您知道另一個必須出現在兩個文件I/O模塊中，因此您可以很快的測試那些特定的函數，來判斷問題所在。
因為該模塊只有一個明確的用途，該模塊也變得高度可重用,。
如果您有其他需要使用文件i/o模塊的應用程序，則有一個明確的目的：它們可以在您想要的任意多個應用程序中將其放到您的框圖中，因為低耦合的好處是可維護性，因此對特定模塊的更改僅限於該單個模塊，而不會對其他模塊產生連鎖反應模塊可測試性。因此，單元測試中涉及的模塊可以保持在最低限度。如果所有功能都是一個模塊的一部分，那么您可以使用同一個模塊測試這些功能。
現在我們知道為什么有這些單獨的循環，讓我們來演示如何在循環之間進行通信。
首先，點擊開始按鈕，消息依次在“用戶接口模塊”、“信息處理循環”、“數據采集模塊”進行傳遞，實現了各模塊的功能運行。
綜上，搭建了整個通信系統，即隊列或用戶事件，這些隊列或用戶事件的引用將存儲在功能全局變量（FGVs）中，與其他模塊共享。在實際運行過程中，並非所有模塊都需要實際加載，它們可以在運行時異步動態啟動。
雖然，這只是一個模塊化軟件開發的概況，但基本覆蓋了已知的大多數情況，如果您注意到這些“用戶界面模塊”、“消息處理循環”、“數據采集模塊”，它們都是完全相同的代碼，但是不得不重復它三次，所以如果使用QMH框架，通過努力，可以將部分的邏輯封裝成子程序，放在單獨的項目庫中，以簡化程序，但仍然有些重復。
現在，我們可以使用一種更為結構化的技術，在開發代碼時，最大化將代碼重用和高效使用。而這正是AF所具備的特性。所以在下一篇文章解讀中，要向您展示AF是如何派生的，以便展示它如何解決代碼重用的問題，特別是在這樣的模塊化應用程序中。
原創碼字不易，如有收獲，希望關注、點贊和喜歡。