利用CASE Tool萃取VB系統邏輯

VB在主從架構盛行的年代，與Delphi並駕齊驅，是企業廣泛採用的程式語言。然而在微軟推出新一代的.NET技術之後，由於VB轉換為物件導向的技術有實務上的困難，因此在微軟宣布終止VB技術支援之後，企業的VB系統面臨遲早必須重寫的命運。

然而行之有年的系統，冒然改寫的風險，在於長久累積的營運知識，若隱藏在密密麻麻的程式邏輯中，沒有文件化的資訊可參考的話，任何幅度的更動，都必須回頭檢視程式碼。

數小時內拆解VB程式各項結構
要解決這樣的問題，可以選擇具備逆向工程機制的軟體產品，反向剖析系統的設計架構。以VB To Xupper為例，它可解構VB程式相關的使用者介面、程式邏輯與資料庫結構，轉入至Xupper。該套工具主要由松技網路資料庫與肯美資訊兩家公司合作研發。

Xupper中的模型圖，大部分均可透過VB to Xupper轉換器全部轉入Xupper，包括實體關聯圖、資料字典、系統架構圖、資料儲存庫矩陣關聯圖、GUI及程式邏輯圖等。不過該功能並不處理商業流程圖與業務規則，因為這兩項本是設計階段需要自製的部分，無法逆向產出。

實際操作VB To Xupper轉換的步驟並不困難。在這套系統中，解讀資料庫結構只需2個步驟，而VB程式的轉入則包括轉入GUI、程式與資料庫關聯圖及程式流程圖，需3道手續。

轉入所需的時間依系統規模而定，簡單的資料結構或單一VB檔案，約在數分鐘內完成。若以松技網路資料庫本身的Firmus ERP為例，整套產品轉入耗時約2～3小時。

解讀資料庫，勾勒架構設計
Xupper的資料字典模組羅列資料庫所有的欄位名稱與解釋，而表格關聯圖則顯示每個資料表所包含的欄位。VB to Xupper解讀資料結構的順序，是先讀取欄位轉入資料字典，再轉入ERD目錄，最後組合欄位完成表格關聯圖。

這樣的設計與產品研發地的習慣有關，Xupper是日本公司研發的產品，當地對於正規化的要求很高，資料結構的設計必須先決定欄位命名，再決定欄位所屬的資料表，最後才畫關聯圖。

而且欄位名稱不能重複，在資料字典中，即使不同資料表的欄位，命名也不允許重複。這樣的作法，與臺灣多數的資料結構設計習慣不同，所以利用VB to Xupper逆向解構資料結構時，可能發生欄位名稱相同的情況，此時，VB to Xupper便會發出警告訊息。

舉例來說，在不同資料表具備相同欄位名稱的情況下，若欄位的長度設定不同，例如同樣是「Name」欄位，有的長度是10，有的長度卻是8，那麼在轉入Xupper時，系統將自動取最大長度，以統一長度規格。

其次，欄位名稱相同在Xupper中是不合法的設計，因此顧問團隊將針對客戶的情況，彈性調整轉入Xupper的方式，在不影響現行資料結構的情況下，區隔欄位的命名。

從畫面、資料表關聯到程式邏輯，逐步拆解設計邏輯
轉入資料結構之後，下一步是解讀程式碼，步驟包括轉入GUI、分析每個程式所使用的資料表，以及程式邏輯。「轉入GUI」功能將GUI轉入Xupper，可以幫助開發者整理GUI之間的關聯性，並在Xupper中模擬執行，了解每個控制項將觸發的畫面或者程序。

而程式與資料庫的關聯性，則透過Xupper的分析矩陣圖，則以C（Create）、R（Read）、U（Update）、D（Delete）標示每一隻程式對每個資料表做了哪些處理。

程式邏輯的部分，VB to Xupper則解讀程式碼，將業務處理流程的邏輯轉入DLCP（Data Life Cycle Procedure）模組。用意是將較難理解的程式碼，轉化成圖形化的流程圖，並提供程式碼與流程圖的對照。

COBOL程式也有逆向轉換工具
然而，系統的逆向工程很難單靠工具完成，仍有客製化及輔導的需求，松技與肯美兩家供應商均能提供相關的顧問諮詢服務。

松技網路資料庫當初開發轉換器的目的，是為了萃取多年以來累積在程式碼中的產業知識，作為後續轉向ASP.NET的基礎。很快地，他們發現企業VB系統升級的需求不在少數，此外，金融界COBOL程式逆向工程的需求也很殷切，因此也開發出COBOL程式轉入Xupper的工具。這些逆向工程的機制，對Xupper而言，將擴展出更多元的應用。文⊙李延華

資料結構轉入Xupper

1. 解讀資料庫結構 設定VB to Xupper轉換工具連結資料庫之後，1點選「讀取SQL」讀取資料結構，2按「轉入ERD」，即開始將資料的欄位與結構轉入Xupper。

↓

2. 產生資料字典 轉入Xupper的所有資料庫欄位，將先彙整集中到「資料字典」。

↓

3. 產生ERD表格 欄位轉入資料字典後，再剖析各個欄位所歸屬的表格，產生實體關聯圖。