- CLA需要具備的軟體技能
一般QSM架構：
- 中等的英文閱讀能力
- 了解Library
- 了解User Event、Queue
- 了解FGV
- 了解Module Ext/Inter-Connection設計
物件導向Actor Framework(AF)架構：
- 中等的英文閱讀能力
- 了解Library
- 了解物件導向
- 了解Module Ext/Inter-Connection設計
而目前所了解擅長物件導向的使用者並不多，
剛好之前在國外論壇交流時又發現了一個模組化的方法，
剛好之前在國外論壇交流時又發現了一個模組化的方法，
因此這次CLA考試個人只有考前一天晚上練習模組化方式，
其他文件完全沒看，特別親身測試看看這個方法是否通用。
其他文件完全沒看，特別親身測試看看這個方法是否通用。
等了快一個月才收到CLA通過通知，
最終確認透過模組化QSM進行考試，是相對簡單且安全的。
(雖然等待過程一度以為自己把CLA玩掉了www
最終確認透過模組化QSM進行考試，是相對簡單且安全的。
(雖然等待過程一度以為自己把CLA玩掉了www
- 可參考的準備資源
前文提及之模組化的文件原始檔可提供參考，
這份文件將如何進行模組化說明得十分清楚，
可以參考它的細節，但個人針對部分功能有修改內容。
也建議各位如果要使用這個方式，
不妨也自行修改成適合自己寫作風格的架構，減少錯誤發生。
也建議各位如果要使用這個方式，
不妨也自行修改成適合自己寫作風格的架構，減少錯誤發生。
此外本文說明可參考官方提供的考試資源進行比對：
這個檔案只有架構只有架構只有架構，內容細節請自行練習。
最後，下文所有圖片皆可點選放大。
- 考試方式
這大概是最重要的，CLA的考試跟CLD一樣，
都是交付紙本以及隨身碟，要求受測者閱讀紙本需求之後，
規劃出符合需求的程式架構，並且將程式碼存入隨身碟，
最後將紙本及隨身碟放回信封彌封。
特別注意可以使用考試電腦內的所安裝的LabVIEW相關模組，
但是任何外部資源或程式碼都不可以使用，只能自己現場寫。
如果使用外部資源而被指出，則絕對過不了CLA認證。
如果使用外部資源而被指出，則絕對過不了CLA認證。
考試時間跟CLD一樣是四個小時，可能會認為時間不太夠，
但其實只要求寫程式架構，實際的程式不用可以執行出結果。
如果真的把考試當實作寫，大概等同為下一次考試做準備。
綜合評價70分就可以通過，個人認為覺得比CLD簡單就是。
綜合評價70分就可以通過，個人認為覺得比CLD簡單就是。
評分標準為：
- User interface and block diagram style : 10 points
- Documentation : 20 points
- Requirements coverage : 30 points
- Architecture development : 40 points
- 閱讀能力
CLA的試題全部都是英文的，受測者的閱讀能力肯定少不了。
雖然考試的需求內容不需要全部了解就可以作答，
但是也不能差到requirement documentation無法掌握重點。
真的看不懂關鍵字詞，Word的翻譯功能請先行Google一下。
考試的電腦是有安裝office的，但這只能做為緊急之用。
因為沒那麼多時間讓你一個一個查字典...
真的看不懂關鍵字詞，Word的翻譯功能請先行Google一下。
考試的電腦是有安裝office的，但這只能做為緊急之用。
因為沒那麼多時間讓你一個一個查字典...
- 架構選用
任何你想要用的架構都可以，只要能把需求完成即可。
說實話，拿AF打CLA大概是無敵的。
因為目前在台北考試的LabVIEW版本支援AF，
這也代表AF所有功能是內建的，因此可以省下非常多時間。
個人比較過至少省下半小時以上。
但是缺點就是會的人不多，所以這篇主要在講QSM。
要使用內建的QMH也可以，只是個人認為修改的地方太多，
因此對於不熟QMH的受測者來說，花費的時間相同，
建議重新寫一個可以自行掌握的架構比較穩定。
要使用內建的QMH也可以，只是個人認為修改的地方太多，
因此對於不熟QMH的受測者來說，花費的時間相同，
建議重新寫一個可以自行掌握的架構比較穩定。
- 系統準備
還沒開始考試前，通常已經在位置上待機了，
此時可以先設定自己的作業環境，以爭取更多的作答時間。
為了要能夠更快的架構VI及其圖示，
建議修改電腦的地區以及語言選項：
修改之後，Icon Editor的字型就不會有毛邊，
也就代表可以透過文字來區別Icon，
而不用花大量的時間來畫圖。
此外，建議變更Quick Drop的快速鍵設定，
為了爭取時間，Ctrl+W自動接線這個功能，
以及Ctrl+T自動將Label分邊的這兩個功能會很吃香。
為了讓Block Diagram(BD)變得整齊，取消View as Icon，
同時增加Label顯示讓subVI更容易閱讀，
建議調整以下兩個功能設定：
建議調整以下兩個功能設定：
- 考試須知
完成了以上的設定修改之後，
就可以等待教育訓練專員給你題目，
拿到題目之後請先確認信封袋上是你個人的資料，
無誤之後便可拆封，拿出隨身碟跟題目卷。
可以先將資料先存在電腦，完成作答再將資料轉到隨身碟。
或是直接在隨身碟作答，各有優缺點。
但無論哪一種，請在最後交卷前確認隨身碟內資料是最新的。
同時小心複製作業，一旦操作錯，拿舊資料蓋掉新資料，
那就恭喜下次再連絡。
但無論哪一種，請在最後交卷前確認隨身碟內資料是最新的。
同時小心複製作業，一旦操作錯，拿舊資料蓋掉新資料，
那就恭喜下次再連絡。
試題卷請勿嘗試把它拆開，文件上有註明：拆開就過不了。
接著，第一張試題大概就是告訴你些考試須知，
最重要的就是不可洩漏任何試題內容，
因此這份分享文件使用公開的範例試題，
後續講解的都是指範例試題中ATM的文件(100528-01.pdf)。
看完了一開始的須知，
接著第二張會告訴你架構須包含以下項目：
- Project with hierarchy
- Main VI
- Shell (stub) modules and subVIs
- Interface for hardware
- Important data structures
- Inter-process communication mechanisms
- Application Programmers Interfaces (APIs) for all modules
- Error handling strategy
- Application shutdown strategy
同時也指出受測者不需要完成架構以外的實際功能撰寫，
但是需要留下架構Requirement cover tag：
[Covers: ID]
這個描述會出現在題目卷中，同時隨身碟內也會有檔案，
提供受測者複製出來使用。
Requirement cover tag可以被標註在：
- VI Documentation Property
- Control Documentation Property
- Project or Library Documentation Property
- Comments on the front panel or block diagram
簡單說，可以想像自己是個設計者，下面有很多工程師。
你負責設計一個程式架構，由工程師去實作它，
在任何你需要工程師寫程式碼的地方，寫上需求註解，
同時加上題目要求的 Cover ID。
此外題目如果要求元件等其他須由你完成佈署的，
同樣會有Cover ID可以讓你貼在元件或Front Panel(FP)上。
如果有完成需求但沒有加上Cover ID，很抱歉，不計分。
如果有完成需求但沒有加上Cover ID，很抱歉，不計分。
- 介面需求
接下來Section II就是題目的開始，
首先會先定義介面跟系統說明。
例如範例第三頁有畫了三張介面圖，
這代表著需求三個subsystem的人機介面要受測者去佈署。
漂不漂亮不是重點，整齊、結構性才是重點。
例如位置要跟需求一樣、資料類型是否有適當的選用，
有沒有適當的使用Cluster等。
每個元件到底是用哪種資料類型的哪種元件，
基本上後續的規格都會說明，
可以參考範例第七頁User Interface Requirements內容。
建議畫面可以大致先確認即可，先不用急著寫題目。
接著一定要看的是Overview。
這一小段文章將會是讓你最快了解系統在幹嘛。
- 系統定義
第四頁開始會告訴你這個系統需要哪些subsystem，
每個subsystem在幹嘛等等。
這邊最重要的就是釐清考試到底要寫那些subsystem出來。
以範例而言，它提到了：
- Controller
- User console
- Simulated
- Physical
- Display console
- Simulated
- Physical
- Sensor interface
- Simulated
- Hardware
- Configuration Database
- Simulated
- Embedded
- Error Handler
這也就代表以上這些內容必須被寫出來。
到此為止應可以掌握接下來要寫的範例架構subsystem內容，
從一開始到這邊花費應不到15分鐘，練習時請注意時間掌握。
尤其想要越級打怪的更是要特別注意時間壓力。
到此為止應可以掌握接下來要寫的範例架構subsystem內容，
從一開始到這邊花費應不到15分鐘，練習時請注意時間掌握。
尤其想要越級打怪的更是要特別注意時間壓力。
- 定義泛用架構資料夾內容
已知題目需要哪些subsystem，在還沒寫Requirement之前，
務必先把架構寫完，切勿一邊寫Requirement一邊寫架構，
除非你是使用AF，不然就是嫌時間太多。
一次解決架構需求，後續建立Requirement才會順利。
首先在桌面或隨身碟內建立考試用的資料夾，
務必先把架構寫完，切勿一邊寫Requirement一邊寫架構，
除非你是使用AF，不然就是嫌時間太多。
一次解決架構需求，後續建立Requirement才會順利。
首先在桌面或隨身碟內建立考試用的資料夾，
同時佈署子資料夾內容如下：
- Module，內含系統定義的subsystem
- User Event，用於subsystem之間的通訊
- _template，用於建立模組範本
做好資料夾結構之後，再開啟空白專案，
同時把資料夾往專案內拖曳，就可一次完成資料結構佈署。
然後記得隨時存檔，因為你不知道考試過程會不會突然，
突然，突然LabVIEW Crash... :(
資料結構佈署完畢之後，可以先做最簡單的User Event API。
- User Event API
因為題目要求Inter-process communication mechanisms，
因此建立User Event API，並讓其扮演跨subsystem通訊，
然而subsystem之間呼叫可以透過public APIs，
所以在User Event API只使用離開程式這個功能。
首先在專案下建立Event的Library及其圖示。
建立完畢之後，接著需要實作Event API的功能。
首先在此資料傳遞選用的方式是FGV，
透過FGV主要是方便資料存取，不用拉一堆線，
同時也不會產生Race condition。
在該Library下建立Event FGV：
其中包含Event State: Exit Program
此外還有FGV的Action: Create, Read, Destory
記得，所有定義的物件都需要設定Type Def.，
然後將定義的物件都存放於個別目錄如TypeDef，
姑且不論是否影響分數，如果沒有設定然後需要大量修改，
你會發現這很浪費時間，然後時間不夠會很想死。
此外所有的定義物件時，VI Documentation建議寫：
This control is used for named action.
或是This control is execute the named action.
這樣就不用煩惱要根據不同的東西寫不同的註解，
只要好好地對物件命名就好。
定義完畢後，即可繼續完成User Event中唯一的API。
API的VI documentation則建議寫：
This VI is used for named action.
或是This VI is execute the named action.
雖然偷懶但是絕對節省大量的時間，又達到註解的目的。
此時的專案資料結構如下：
到此為止完成User Event API的撰寫。
- 建立Template Module資料結構
接著要開始寫subsystem架構，此架構在此選用QSM，
原因是Enum定義比較有型，比起String base的QMH來的嚴謹。
重點是寫APIs時會十分快速。
首先在_Template資料夾中建立資料夾及Library如下：
每個子資料夾依據權限負責存放不同功能的程式：
- Private Controls：模組內物件定義
- Private VIs：模組內部通訊使用VI
- Public Control：公開的物件定義
- Public VIs：公開的APIs
記得設定資料夾權限：
- 建立Template Module Inter-Comm APIs
基礎規畫完畢之後，要透過Queue建立模組內通訊的機制。
一樣在Library Private APIs下建立Queue FGV，
首先是Queue State: Create, Read, Destory：
接著是預先建立Module共用 Action: Initialize, Error, Exit
最後建立State Message的資料結構：
三個物件都完成之後即可建立該Queue FGV：
在此特別修改的是透過Call chain來定義Queue的名稱。
FGV完成之後同樣的可以接著建立Enqueue, Dequeue的API：
製作API後，記得妥善的定義該API的名稱，
最好以該API的完整功能進行命名，此外也別忘了編輯Icon。
- 建立Template Module External-Comm APIs
當有了Enqueue的功能之後，就可以進一步的製作模組的APIs
這些APIs提供模組內部或模組間的命令及資料傳遞，
如下圖為Initialize功能的API：
這些APIs提供模組內部或模組間的命令及資料傳遞，
如下圖為Initialize功能的API：
由於考試不需實際傳遞資料，所以Data的接腳只是好看而已。
重點在於Enum的State，它才代表該API的實際功能。
再次強調，存檔時建議命名跟State一樣或更完整功能名稱。
屆時使用APIs時，subVI的Label等同功能註解，
Label充當註解讓程式更好閱讀外，也讓受測者也少寫一些。
然後別忘了編輯Icon，簡單的文字即可。
然後別忘了編輯Icon，簡單的文字即可。
當需要製作下一個API，建議直接透過複製的方法：
這樣複製出來只需要重新命名功能名稱，
例如修改state為Exit後就可完成新的API。
透過複製來大幅降低撰寫API時間，這技巧也可運用在後頭。
唯一注意的是複製VI之後避免忘了改新VI的程式碼跟Icon。
比較特殊的則是Error API，在此設計成具備Error Handler功能：
到此為止，完成所有的APIs功能建立。
- 建立Template Module主程式
當工具都有了，就要來架構範本的主程式，
其中包含Module Initialize、Event Handler以及Message Handler
這部分可以依照個人寫作風格加以修改，增加撰寫流暢度。
首先建立Module Initialize：
初始化分成兩步，一個是讀取User event並且產生註冊
一個是透過FGV產生module queue並且加入initialize API。
接著建立Event Handler：
產生Dynamic Event後將state取出判斷，
但因為Enum State只有Exit Program，所以只需處理相關功能，
考試很注重Reference Close及Error Handler，這部分別輕忽了。
最後建立Message Handler：
Message Handler的設計完全相同於QMH架構，
不同是本範例前端放的是Dequeue，State後放的則是Error，
這樣可以省下很多功夫來解釋資料傳遞跟錯誤處理。
最後儲存Main.vi後的資料結構如下：
Main VI的 Documentation就比較不一樣：
This is the TOP VI of the module.
到此完成Library Template的撰寫。
- 透過複製建立subsystem
接下來透過另存Library的方式可以快速建立subsystem。
複製時直接命名Library，同時存放在正確的資料夾位置：
此外複製完畢後記得要逐一修改Library的圖示及字樣：
最後完成所有的subsystem原型後，別忘了要增加Launcher：
其中包含透過Event API建立以及刪除Event，
此外就是各subsystem的呼叫及Error Handler。
Launcher的Documentation則是：
This is the Launcher of the System.
到此完成系統架構的設置。
透過複製Library，基本上共用的功能都完成了，
包含之前的註解也是，超級方便。
如果有稍作練習，完成這些系統預部屬應該會花45分鐘，
練到很熟的話甚至35分鐘就寫完了。
但特別注意這個範例所有的subsystem，其實都是複製出來的。
因此建立template要超級謹慎，因為一個地方設定錯誤，
複製後就變成六個錯誤，修改就會很痛苦！
所以在追求時間的撰寫速度以及謹慎檢查的平衡上要拿捏好。
- Definitions & Terminology
完成程式架構後繼續回到題目。
這次仔細看Definitions，它會說明各subsystem負責的內容。
此外，Terminology是很重要的資訊。
它會提到後續功能的術語，只有這一頁請花點時間看一下，
避免繼續看規格時完全不了解系統在幹嘛。
- Requirements
這邊才是正式的所有需求，
Requirements是由一堆Cover ID所組成的，例如SI、UI等，
每一種Cover ID其實就是在描述一個功能需求，
以範例來說就包含了以下需求：
- 系統描述
- Simulation Interface Requirements
- User Interface Requirements
- Initial State Requirements
- User Message Requirements
- 行為描述
- Idle State Requirements
- Login State Requirements
- Balance Inquiry State Requirements
- Deposit State Requirements
- Withdrawal State Requirements
- Fast Cash State Requirements
- Terminate State Requirements
- Inactivity Timeout Requirements
- 資料庫描述
- Configuration Database Requirements
- 錯誤描述
- Error Handling Requirements
最簡單的就是系統、資料庫以及錯誤描述。
Simulation Interface Requirements是系統功能說明。
所以Cover ID一般會貼在專案說明，或是Launcher內。
User Interface Requirements則是人機介面定義，
FP上面的物件資料類型的定義在這邊會寫得很清楚，
會很詳細的說明每個元件要做什麼，不實作故快速看過就好。
所以Cover ID貼在元件說明，或是FP上即可。
Initial State Requirements則是初始化要做的事情，
所以Cover ID會貼在各模組的Initialize中。
User Message Requirements是顯示元件可能會有的需求，
基本上Cover ID也是貼在顯示元件旁邊，
但是如果有附上文件檔告訴你該顯示什麼文字，
別想太多，寫註解請工程師參照該文件即可，不用實作。
不然會浪費很多時間。
Configuration Database Requirements則是資料庫需求，
這邊其實是在考資料結構及存取，例如範例第13頁，
它會定義把什麼資料透過什麼方法存取。
資料結構必須妥善定義，存取的部分則寫註解不要實作。
Cover ID則是貼在定義或註解旁邊。
Error Handling Requirements是最簡單的，
文件定義數種錯誤state，直接做出state並說明就結束了。
Cover ID直接存在於state中，一樣不需實作內容。
至於行為描述則會根據題目不一樣而不同，
這部分就看受測者的規劃能力。
- Cover ID與對應API的建議
基本上行為描述一樣只需要將文字檔的[Covers: SIxxx]，
貼到你撰寫或設計或部屬的相對位置就有分數。
講起來很簡單，但實際實作麻煩的就是如何交代這些需求。
一般是建議將每個需求做成一個state，然後產生相對的API，
例如取得某面板的物件→寫成API，
設定面板的顯示器→寫成API
未來當需求內需要取得物件資料，就直接拉API出來用即可。
這時候就考驗受測者最大化API的能力。
簡單講，如何寫最少的API，然後可以用在最多的地方。
以考試來說不用顧慮太多現實的問題，反正程式不需要會動。
所以API開出來，只要在state中描述你希望工程師如何操作，
或是資料行為是什麼，剩下的就是丟API跟Cover ID就對了。
如果API規劃的合理又可以包山包海，
如更新Indicator→透過說明然後全部使用一個API
取得Control→透過說明然後全部使用一個API
取得Sensor→透過說明然後全部使用一個API
取得Sensor→透過說明然後全部使用一個API
那就可以省下大量寫API程式的時間。
基本上後半段的作業時間就會變成：
看Requirement→整理→產生module state→產生API→
產生對應Module Message Handler→看下一個Requirement
- 親身嘗試的建議
時間的掌握很重要，越急會越寫不出來。
理論上有練習，到完成所有預佈署的程式碼頂多花一個小時。
也就代表還有三個小時可以處理所有的Requirement。
只要不手殘眼殘腦殘，那麼時間是十分足夠的。
只要不手殘眼殘腦殘，那麼時間是十分足夠的。
只要物件/VI的註解有寫，documentation的分數就很多。
以個人為例，因為英文不好加上幾乎沒練習，
因此BD內完全沒有註解，但是註解還是拿了19/20。
由此猜測註解這邊的分數主要取決於物件/VI的註解。
由此猜測註解這邊的分數主要取決於物件/VI的註解。
那BD內的註解沒寫，哪邊會被扣分，
答案是Architecture Development，這邊只拿到30/40。
因為架構內沒有交代API細節項目該如何處理。
不過API的名稱有打開，所以執行流程似乎沒被扣分。
這也可以假設，只要完成預設的架構，API也有好好寫出來，
Architecture的分數並不會被扣到哪邊去。
同時在QSM+模組化的架構下，寫作Style拿了9/10。
這也意味著，只要不要拉線太混亂，物件亂重疊等，
基本上Style分數也不會差到哪邊去。
這也意味著，只要不要拉線太混亂，物件亂重疊等，
基本上Style分數也不會差到哪邊去。
最後Cover ID超重要一定要貼上，即便功能看不懂也沒關係。
想辦法把Requirement變成一種State，透過API下命令即可。
只要有地方放Cover ID，就一定有分數。
想辦法把Requirement變成一種State，透過API下命令即可。
只要有地方放Cover ID，就一定有分數。
以這次題目有近一半看不懂，只好照需求打state然後做API，
結果Requirements Coverage居然拿了 27/30。
最終實驗結果，透過模組化的方法來預佈署程式，
只要了解測驗的重點，那麼70%以上應該不會太難。
- 莫名其妙的結論
這個實驗不是說只要照攻略打就能無視能力低等通關，
而是能力這件事情在依照規範寫出API時就會展現出來。
如果能力不足，就算照表操課硬學了這套方法，
考試時還是會不知道如何規劃State及API，而導致時間不足。
同樣的如果沒有準備考試方法，那麼就算能力超人，
但是全部從頭來寫，時間依舊不足。
這也是為什麼說拿AF來打CLA超級簡單的原因...
拿OO內建API直接打Requirement可能不用三小時就寫完了，
前提是題目都看得懂的話啦。
Anyway要重新考一次，我絕對會選AF...
但是使用QSM，也有透過模組化這種相對簡單的考法就是。
拿OO內建API直接打Requirement可能不用三小時就寫完了，
前提是題目都看得懂的話啦。
Anyway要重新考一次，我絕對會選AF...
但是使用QSM，也有透過模組化這種相對簡單的考法就是。
以上簡單說明，無法確保用同樣的方法寫會拿到同樣的分數，
畢竟沒看過評分標準，只能透過臆測來評斷，
這種方式目前測試完畢過關的有2/2，若各位看了這篇文章，
使用這個方式應考通過，再煩請回報一下，
我會修改數值來增加後續閱讀者信心。
最後希望這篇文章可以提供想要而不敢考CLA的人一個方向。
畢竟沒看過評分標準，只能透過臆測來評斷，
這種方式目前測試完畢過關的有2/2，若各位看了這篇文章，
使用這個方式應考通過，再煩請回報一下，
我會修改數值來增加後續閱讀者信心。
最後希望這篇文章可以提供想要而不敢考CLA的人一個方向。
或一個勇氣。
