ArCats 的合成引擎提供了狀態平行合成、安全性質檢驗、本文限制與即時 化減技術等幾種複合的功能，使用者可照需求自行選定參數予以設定，參數如
Table 2 表示。我們並以 Figure 4-1 簡單地說明重構前的合成引擎中，程式呼叫的 決策流程。
-c 平行合成時加入 EIP 以進行本文限制
-s 平行合成時加入 SP 以進行安全性質的檢驗
-b1 平行合成時會根據指定的狀態數目進行即時化減
-b2 平行合成時會根據指定的記憶體用量%進行即時化減
-b3 平行合成時會根據 BFS 所展開的每一層進行即時化減 Table 2 The parameter of composition tool
Figure 4-1 The call graph of composition tool before refactoring
Figure 4-1 樹狀似的 call graph 的程式呼叫步驟說明如下：第一層表示系統判 斷讀入的 LTS 型態是否為 CCS。若為 CCS，再檢查使用者是否設定 Context
Constraint 或是 Safety Property 的參數，如果有，則依參數決定要呼叫 Context Constraint 或是 Safety Property 的 method，若皆未設定兩者的參數，表示只需單 純進行平行合成狀態的展開，此時會去呼叫 Enumeration 的 method。
確認完合成方式後，最後 再依使用者給定的參數判斷是否要執行即時化減技 術，若使用者未指定任何即時化減的參數，意即合成時不需最小化。以使用者輸 入的參數為 compose A.ccs B.ccs –c i1.ccs –b3 為例，表示使用者選擇在進行( A ||
B )的平行合成時加入本文限制的檢查，使用的 EIP 名稱為 i1.ccs。在平行合成時，
合成引擎會隨著 Breadth-First 展開每一層狀態，進行即時化減。所以依照此例所 給 定 的 參 數 ， 程 式 經 由 巢 狀 if-else 的 條 件 述 句 分 析 後 ， 最 後 會 呼 叫 ContextConstraintWithLevelBB() 此 method，以進行局部性分析。
由以上敘述以及 Figure 4-1 的示意圖可知，由於要經過層層判斷方能確認使 用那一個 method 進行局部性分析，程式中充滿許多 if-else 的條件判斷式，以達 成逐步確認的效果。所以我們可以對重構前的架構做一總結如下：
（1）非物件導向架構，程式難以擴充或重用
在非物件導向的架構下，最大問題在於程式碼無法重覆利用。假設我們 要在檢驗 Safety Property 時加入即時化減的功能，我們必須實作三個新的
method：分別為 SafetyProperyWithStateBB()、SafetyProperyWithMemoryBB() 以及 SafetyProperyWithLevelBB()。若將規模更進一步擴充，在 ArCats 中新 增 CSP based 的 LTS 進行局部性分析，則原有的 Context Constraint 和 Safety
Property 的合成規則程式碼更如同虛設，必須將 Figure 4-1 中九個 method 全 數重寫。
（2）重複的程式碼
Figure 4-1 樹狀式的 call graph 的呼叫方式，顯示原有的合成引擎中有許 多重複的程式碼散落於各個 method 中。重複的程式碼表示 method 之間有相 同的程式結構，亦會造成程式碼的耦合。耦合的程式碼不僅難以維護，在增
加了新的功能後，很可能還會使得既有程式碼出現錯誤，增加 debug 的負 擔。舉例來說，當我們要修改某一項功能時（例如即時化減技術），由 Figure
4-1 的示意圖中可知，我們必須更動到六個 method。而程式碼需要更改的地 方愈多，程式出現錯誤的可能就愈高。而且修改程式碼時很容易使得既有的 功能，如 Enumeration 或 Context Constraint 受到影響，產生無法預料的錯誤。
（3）重複的邏輯指定
在確定要使用那一個 method 之前，所有 method 都要經過相同的邏輯篩 選程序，首先確認是否為指定的 LTS 型態，再確認合成規則，最後確認即 時化減的方式。當我們新加入 method 或修改原有功能時，除了實作既有的 內容外，還需要到專案多處進行 if-else 的條件式的修正與補進，只為了確保 程式能夠正確的呼叫。因此過多的條件判斷式不僅使得程式碼難以閱讀，要 維護的 method 和成本也會增加。我們希望可以將相關的邏輯處理集中，閱 讀程式碼時就無須在各種條件判斷句之間來回切換，造成理解上的阻礙。