Jakob Nielsen 於 1995 年提出了” 10 Usability Heuristics for User Interface Design”[21]，
說明了十大原則去說明要如何改善軟體的易用程度，內容說到軟體應該在適當的時間內，
3.3 樣板標記 (Skeketon Annotation)
BDD 開發方法一般而言是由正規表示法對應到整合測試碼，透過產生框架並且提供開 發者依據測試框架撰寫測試程式並實作，而本論文利用 BDD 結合 TDD 的方法實作智能 合約開發工具，首先會遇到幾個問題，其一是要用什麼語法撰寫測試程式碼，其二是要 如何協助智能合約的開發，使一般未熟悉區塊練開發的開發人員更為容易入手。
智能合約是由 Ethereum 提供之特殊語法 Solidity 撰寫智能合約，因此，第一個考量 為使用 Solidity 撰寫智能合約測試程式碼，但用此方法目前則會遭遇到很大的困難。舉 例來說，在撰寫智能合約時必須在 Solidity 程式碼中撰寫版本等資訊，並且需熟知 Solidity 語法風格，且目前 Solidity 語法仍不支持字串陣列的回傳等，且當錯誤發生時，區塊鏈 系統不會給予有用的錯誤回饋，目前 Ethereum 提供的錯誤回饋通常只會給予失敗及成 功兩種為簣。故測試程式碼的語言本研究選擇使用 javascript 作為測試程式之語法，提
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
供更彈性的測試環境來解決 Solidity 語法尚不成熟所帶來的挑戰。另外，本研究使用 BDD 結合 TDD 作為開發方法協助開發人員可以更容易的開發目標程式，使用此種方法會產 出程式碼框架，開發人員可以利用填空的方式撰寫測試程式或智能合約內容。在這種做 法中本研究提供一種樣板標記，使得開發人員在撰寫測試程式碼時，使用本論文提出之 工具預先產出下一步驟程式碼之框架，開發人員僅需要用填空的方式將內容填入即可 (圖 11)。
圖 11: 創建專案
在創建專案時本論文提供更友善的介面，供創建者理解目標程式碼的物件為何，並 且預先產出 javascript 在呼叫智能合約時所需要的基礎元件，例如智能合約創建後的位 址、應用程式二維介面（application binary interface,abi）以及位元碼（Bytecode）如圖 12。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 12: JavaScript 呼叫智能合約基礎元件
而撰寫整合測試時本研究提供樣板標記語法(圖 13)，使用類似 meta-annotation 的方 式提供開發者將方法的框架寫入設計之註解標記中，例如“///＠method“表示樣板標記前 置詞，利用目前最常使用的 JSON 格式作為物件判別，其中 contract 表示智能合約名稱，
而 name 表示其方法名稱，以及 argument 表示該方法所用到的參數個數。
圖 13: 整合測試框樣板標記
以圖 14 為例，在此範例中開發者在撰寫整合測試時，設計了“addPoint“方法，並 且此方法的參數個數為“1“，開發者可在此透過註解標記協助撰寫框架，表示該方法存 在於”LoaltyPointAA”智能合約中，並且此方法參數個數為”1”。
圖 14: 整合測試框樣板標記範例
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
有了整合測試的註解標記，本平台會在第一次執行單元測試時偵測此註解，即平台 會產出該方法的單元測試框架（圖 16），而開發者可以在設計單元測試時設計再該方法 是否會改變區塊鏈內原本資料的狀態（圖 15），若會則在“isConstant”的部分則設定 為”true”。
圖 15:單元測試樣板標記
圖 16: 單元測試樣板標記範例
最後，單元測試撰寫完畢後，平台會依照樣板標記提供的內容產出智能合約程式碼 框架，開發者可以依照此框架來撰寫智能合約，並繼續執行 BDD 結合 TDD 開發方法。
3.4 生成帶入
Pattern-Oriented Software Architecture Volume 4（POSA 4）[22]提到了分散式系統的主要 設計模式，其中說明到當 client side 要遠端存取服務時則必須透過特別的資料格式（data format）以及網路協議（networking protocol）才能達成，一種做法是將元件的資料格式 化以及協議處理都交給發佈的 client side 負責，但這樣的做法會造成過度依賴該 client side，若其他 client side 遠端呼叫時該 client side 沒有解碼好該資料及處理協議，或者甚 至中途離開了，則該元件便無法使用。
另一種理想的方式為將元件獨立化（location-independent），使得遠端呼叫與本地
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
的使用介面（Introspective Interface），故當發佈者把 client proxy 發佈至分散式系統後，
遠端或本地端在做存取時可以透過使用介面對被發佈的元件做存取。
而在區塊鏈系統中，智能合約撰寫完成後會將智能合約程式碼編譯成二維碼
（Bytecode），後將此二維碼擺放至區塊鏈中，當廣播至各個節點的時候，各節點可直 接執行二維碼，不需要重新編譯後才能執行而浪費節點們的資源，但當智能合約已將二 維碼擺放至區塊鏈時，若要使用智能合約上的方法而僅有二維碼卻無法達成，其原因為 當智能合約已被編譯成二維碼，若要呼叫方法時必須透過應用程式二維介面（application binary interface,ABI）將其解碼後，將參數帶入重新編碼再執行。也就是說，欲呼叫一智 能合約方法，除了智能合約位址外，還必須要擁有該智能合約的 Bytecide 以及 ABI 才可 進行呼叫。
一個簡單的智能合約範例如圖 17 所示，此合約包含了一個建構子與一個方法，當 合約建立時指定所有人為誰，且提供原持有人一個轉移持有人權限的方法。
圖 17: 智能合約範例
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
當撰寫完智能合約後開法者必須嘗試編譯此智能合約，而目前以太坊提供的智能合 約編譯器為 solc，在編譯前開發者必須詳讀安裝以及使用方法，並且確保編譯的作業系 統沒有限制，否則將會編譯失敗。
舉例來說，在 Windows 作業系統上，檔案命名規則不允許檔案名稱中包含 “:”，但 若以上述智能合約為例，solc 在編譯時若 Solidity 檔名為”Contracts.sol”，則會產出
“Contracts:Ownable.bin”，而此種檔案名稱將會被拒絕，必須參考其他 solc 的設定文件使 輸出檔名合乎作業系統檔案命名規則。
當撰寫完成智能合約並且成功編譯後會產出 Bytecode 及 ABI，Bytecode 為中間代 碼，可透過直譯器轉譯後提供智能合約可以在虛擬機上運行，而 ABI 為智能合約的介面 整體來說如圖 18 所示。
圖 18: 智能合約編譯完成後所產出之 Bytecode 及 ABI
因此，基於本論文是使用 javascript 語言撰寫測試程式碼的前提下，在基礎建設的 部分除了協助開發者將基礎元件設立好外，另外還將編譯器整合至平台中當編譯完成後 會將該智能合約之 Bytecode 及 ABI 帶入至測試程式碼中，減輕開發者的負擔。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 19: 測試程式將 ABI 及 Bytecode 帶入
如圖 19 所示，當開發者依照 BDD 結合 TDD 開發方法，執行編譯後，平台會以自 動帶入之形式將值帶入至物件，開發者可直接使用此物件。