前言 發展SA/SD這個工具是訊光繼EEP開發平台之後推出的大作，其目標是為了要徹底解決軟體問題。在軟體開發的五個步驟中－需求蒐集、規格開立、系統架構發展、程式開發和上線測試。SA/SD這工具是為了解決規格開立及系統架構發展這兩個問題。 五個步驟所需的人才其實不大一樣。『需求蒐集』往往需對客戶產業要有相當程度了解才能理解、建議及改善客戶的工作流程。因此，人才的取得往往是該產業的從業人員或曾經為該產業發展過類似的軟體。『規格開立』其主要工作是將需求轉化成軟體規格，通常需具備軟體背景才能將達成。至於對使用工具是否熟悉便不是那麼重要。這裡軟體規格指的是軟體畫面、報表及資料流。但因對工具不熟常常藉由大量文件將需求仔細的呈現，以利後段工程的進行。『系統架構發展』其主要的責任是發展出軟體設計標準模板。因此，需要對軟體工具夠熟悉且對軟體發展流程掌握度夠高；例如Master/Detail畫面新增、修改及刪除如何標準化的設計，才能將設計速度、品質拉高，有些專案甚至連命名規則也會規範。『程式開發』則是將規格一行一行變成程式碼，如果專案是一步一步按步就班，此階段人員大致是專注程式開發即可，不過，實務上工程師還需兼具未知技術的研究，才能將專案所遇到各式各樣的問題解決。『上線測試』往往會面臨客戶需求的變更，未知Bug排除及效能不盡理想的交互影響，導致專案的上線需拖延不少時間。其間需要規格開立人員與較高程度工程師排除Bug。 總之一個專案需至少具備三種人才。SA/SD人才、系統架構發展者(俗稱功力較強的人)及程式師。但在台灣具備這三種要求的Team並不多，經常是軟體公司老闆一人身兼數職。所以，台灣軟體公司所發展的軟體往往不大，解決的問題有限。 要解決這困境便要找到一個針對以上所需的人才技能均融入在一起的工具，由SA/SD人員直接將客戶需求轉化成可資上線的程式碼。如此一來，便可大幅降低各個步驟所需的人才大幅節省開發時程。順便也可解決軟體產業特殊情況，在別的產業待越久知識累積越深厚，但在軟體行業，過去所熟練的技術可能在明日變成一無是處。 但SA/SD工具在軟體發展史上，並不是一個新鮮的名詞，根據與使用者近距離接觸了解這些產品的使用心聲發覺成效有限，勉強算的話大概只有文件交付上較為完備之外，如果進一步要根據Code Generation的程式碼上線大概是遙不可及。以台灣人的價值觀，如果花了錢只為了文件交付，大概認同的比例不高。那問題到底在哪裡？ 在回答這問題之前有必要將國內外軟體定位及其要達成目標進行了解。 以OOA/OOD為標準的SA/SD工具，一旦熟知或熟用OOA/OOD觀念之後，不禁要思考OOA與報價單之間關係如何建立?如何利用類別定義(Class Define)與報價單、出貨單之間拉上等號。就原理而言，利用類別定義是可以定義出報價單，但這如同利用組合語言寫報價單並非不可能，而是成本高到不像話。 再以一般Case Tool為例。大概只能滿足一般專案規格需求的二、三成，其理由是：如果仔細分析專案程式技術需求，大致可區分為五方面。畫面、報表、批次作業、權限及系統需求。其中『畫面』又可細分為表單式、計算式。表單式的畫面大致是設計表單然後將之存入資料庫。計算式畫面往往牽涉複雜過帳或複雜畫面呈現。『報表』大概可區分為清冊、交叉分析及複雜統計報表統計。『權限』一般分四層。（1）、功能表。（2）畫面新增、修改、刪除及查詢。（3）欄位控制。（4）資料層控制。『系統需求』例如多資料庫、與Mail結合…。至此，心中應該會有譜為何SA/SD工具只能有二、三成的實用性。原因是有太多的工作無法在SA/SD這工具上實作必須回歸開發工具。如此一來，SA/SD如何與開發工具達成雙向溝通或互相協助變的相當重要。 SA/SD的工具定位 訊光SA/SD的工具定位相當清楚，只針對商業應用程式不包含低階軟體應用程式。將OOA/OOD包裝成規格分析人員熟知的DD及Schema設計、資料匯出匯入、表單設計、報表設計、批次設計。本工具所產生程式碼能讓EEP平台來執行，如此一來SA/SD工具的功能會被延伸至EEP平台，EEP所具備的功能同時也被SA/SD具備。例如，EEP的權限功能、EEP的效能控制及各式各樣的元件，均可在SA/SD中填參數，然後指揮EEP工作。這也是為什麼訊光SA/SD工具會比同類型的產品更實用的原因。 在經過仔細分析訊光SA/SD工具與市場上的工具主要差別之後。接下來是深入探討每個功能要解決的問題。 SA/SD工具分成下列幾大模組： 1. TABLE SCHEMA的維護 2. 資料的匯出匯入 3. 文件的產生 4. 畫面規格UI的輔助設計 5. 批次作業的輔助設計 6. 報表的輔助設計 TABLE SCHEMA 的維護： 在專案開發時期，專案控管人員需極小心維護TABLE SCHEMA之發展，任何TABLE SCHEMA之新增及異動需由工程人員彙報後，由專案控管人員維護，此種做法缺乏彈性及時效性，但若允許工程人員依程式開發需求先行異動再彙報專案控管人員，恐因疏失而造成SCHEMA實際版本與認知有差距，又因要找出其差異性往往需耗時耗力。 談到TABLE SCHEMA 的維護，首先當然就要先了解資料字典 (Data Dictionary) 的定義。資料字典這個名詞應該是大家耳熟能詳的，資料字典係為集中管理系統中所有的欄位資訊的功能，可維持整個系統對命名的一致性。在資料字典中會儲存所有我們在專案中會使用到欄位的規格，除了可以立即查出在畫面上被使用的各個欄位資訊，還可一併修改這些欄位資訊。 然而在系統建置的過程中， 「改變」 是不間斷的發生，所以對於大型專案，就很需要可自動記錄或自動產生的資料字典資料庫！ 另外 SA/SD 工具還融入領域 (Domain) 的觀念，只要使性質相同的欄位同時參照同一個領域欄位，之後的欄位修正可就是得心應手了。 SA/SD 工具中的資料字典主要採取欄位群組的管理，藉由定義 Domain 以便管理欄位的型態、長度、輸入格式、預設值...等等，如圖 (1-1) ，在規格開立時期，使用者即可依照系統的需要先將領域欄位規劃好並指定性質相同的欄位。當系統中所有的欄位都在資料典中集中管理，包括在畫面上使用的各個欄位長也都(▲圖1-1) 可以立即查出，甚至還可一併修改；在畫面及報表設計時，也可利用資料字典的功能來輔助設計人員快速開發，避免因重覆定義所造成的差異性。 SA/SD 工具除了對於資料字典的管理有完善的規劃外，另外也非常注重有效的管理資料檔案規格，將具相關性的資料表加以整合成為一個TableGroup，將資料檔案加以歸類編入，想要尋找某一個資料檔案時，只要確定它屬於哪一類的TableGroup，直接到該分類底下尋找就可以快速的找尋到該資料檔案，如此一來，事前分類不僅節省下您的搜尋資料檔案時間，並能美化您的畫面，讓您有規則的整理歸納資料檔案，使瀏覽時感到簡單整齊，排列方式具人性化，如圖 (1-2) 。另外還提供資料表雙向匯出及匯入的管理功能，並可檢查資料表欄位相依性。 (▲圖1-2) 另外不論是針對 DD 或是 TABLE ， SA/SD 工具都還提供了人性化設計介面的Property Editor編輯器，能更便利的提供使用者異動各個群組中的資料，如圖 (1-3) 。 (▲圖1-3) 在系統上線維護時期， TABALE SCHEMA 之異動更需審慎處理，不當且未察覺之異動恐導致現行系統無法運作，為了避免需遞交變更文件及備份資料庫所耗費的時力， SA/SD 工具需能自動診斷新舊資料庫版本差異，然後利用親和使用介面來協助設計者輕易更新版本。使用上，因為有了診斷功能，使用者能很輕易了解新舊資料庫版本差異所帶來的衝擊，能很精準的評估，免除了一大堆變更文件的交付及資料庫的備份。 SA/SD 工具中的 EEPExecSQL 工具就提供了資料結構比對分析以及資料更新的功能。以 EEPExecSQL 工具更新 SQL File-EEP_Schema 為例，執行診斷功能後，診斷結果如圖 (1-4)。 (▲圖1-4) 診斷結果之狀態說明如下表： 狀態 說明 處理方式 資料結構有異動 快按兩下開啟資料異動處理視窗 資料表不存在 按 自動會產生 欄位順序有變 可不處理 資料結構有異動但沒有任何資料 快按兩下開啟資料異動處理視窗 資料表新增欄位但是鍵值不變 快按兩下開啟資料異動處理視窗 以本例而言，系統表格COLDEF出現紅色，表示資料結構有異動。快按兩下即可開啟維護視窗介面，如圖 (1-5) 。 (▲圖1-5) 維護視窗中第一個區塊為SQL Script in Definition表示這是從SQL File所定義的資料結構，第二個區塊為SQL Scription in Database表示這是資料庫實際上所定義的資料結構，紅色線代表資料結構有異動。上圖可清楚顯示從 SQL File 所定義的資料結構及實際上資料庫所定義的資料結構有差異。 資料結構差異處理的方式如下： 按下 按鈕後，使用者即可自行依照實際需求修改或回覆異動的資料結構，如圖 (1-6) 。 (▲圖1-6) 選取欄位後，會將新舊資料結構帶出來，第一行為SQL File的欄位結構，第二行為實際資料的結構，如圖 (1-7) 。 (▲圖1-7) 比對後，發現欄位的長度有變化，如果想要修正結構的時候，請將第二行的VARCHAR(30)改成VARCHAR(20) 。 按下「R」這個按鈕，此時會將畫面上的語法修正為VARCHAR(20) 。 另外，對於欄位的新增、刪除或是鍵值欄位及資料欄位重覆的處理都有很方便的操作介面。 資料的匯出匯入 在二個時機上，軟體從業人員會花不少時間。（1）是將參數存在資料庫中，然後根據不同時機不同客戶調整參數。這想法本身沒有問題，如果系統參數數量少可以靠人員肉眼判動，如果數量一多勢必會容易犯錯誤把A客戶的參數覆蓋在B客戶上，或客戶願意採用較先版本時，原先客戶字行調動的參數如何不會被不小心覆蓋，便需有賴事先好好的規劃。（2）是不同資料庫往往會需某種程度的資料整合。可能只是某些欄位根據某些條件將A資料庫的某幾個Table中某些欄位，匯入B資料庫的Tables中。這類問題往往需工程師寫所謂匯出匯入程式。花了不少時間，不少測試還不一定能將這類問題完整解決。最好的做法應該要有工具，能由使用者自行定義匯入關係，由系統根據鍵值診斷有幾筆資料將會覆蓋舊資料或新增入資料庫，然後再由使用這決定是否轉入，如此一來才能控制資料轉入品質。 在上面 TABLE SCHEMA 的維護中曾經提到在 SA/SD 工具中可將具相關性的資料表加以整合成為一個 TableGroup ，並將資料檔案加以歸類編入。下面將說明，當您使用SA/SD 工具 Create 出自訂的資料表之後， SA/SD 工具更提供匯入工具將已存在資料庫中的資料表直接匯入 SA/SD 的 TableGroup 中。 圖 (2-1) 為 SA/SD 所提供的匯出匯入工具的功能選單。 (▲圖2-1) 以下依序介紹各項匯出匯入功能： ■Import Tables from DataBase 在指定的 TableGroup 下點選此功能，會出現 ConnectionString 及資 料庫選項視窗，此時只要將資料庫指定正確，並執行即可挑選指定資料庫中的資料表，並匯入 SA/SD 中，執行畫面如圖 (2-2) 。 (▲圖2-2) ■Export/Import DD from DataBase 為了整合EEP及Fastflow的COLDEF(資料字典)資料表，免除重覆定 義及加快開發速度。其中 Import DD from DataBase 表示資料會由資料字典檔(COLDEF)匯入至IPC工具中； Export DD from DataBase表示由 SA/SD 的設定匯出至資料字典檔(COLDEF)。另外可在處理過程中比對原 SA/SD 的設定值及資料庫中資料字典的標題。 另外為了避免將參數存在資料庫中且在調整參數時發生不必要的資料覆蓋之情形以及節省不同資料庫的資料整合時撰寫匯出匯入程式所花費的時間， SA/SD 工具設計了資料更新功能，由使用者自行定義匯入關係，由系統根據鍵值診斷有幾筆資料將會覆蓋舊資料或新增入資料庫，然後再由使用這決定是否轉入，如此一來才控制資料轉入品質。 使用 EEPExecSQL 工具即可用來檢查資料表中的資料，如圖 (2-3) 。可比對出資料在資料庫中及在 SQL File 的差異性，進而依實際的需求更新資料。以MENUITEMTYPE而言，當資料Grid出現紅色表示這筆資料在資料庫中不存在，所以在Status狀態欄中為I，代表要「新增」至資料表中。 (▲圖2-3) 工具本身除了提供診斷功能協助使用者了解資料覆蓋所影響的層面，另外一旦不小心誤蓋，系統會自行 Log ，可隨時回覆原先的資料狀態。按下 執行按鈕，會出現將Log存檔的視窗。 執行完畢後，可再按一次「Diagnose」，來檢查資料是否有新增至資料表。以下圖為例，在資料Grid的視窗中出現綠色，而且在Status狀態欄中為U，代表資料已經存在，而且沒有改變，如圖 (2-4)。 (▲圖2-4) 以 EEPExecSQL 工具更新更新SQL File-EEP_Data為例，開啟 SQL File-EEP_Schema.SQL 後按下 按鈕，執行診斷功能。診斷結果如圖 (2-5) 。 (▲圖2-5) 診斷結果之狀態說明如下表： 狀態 說明 處理方式 U 沒有異動 不處理 M 資料異動 按右鍵「Record in Database」可比對差異 I 資料新增 可Selected 狀態為M及I，為資料之異動或新增，處理方式如下： 按右鍵「Record in Database」可比對差異，如圖 (2-6) 。 (▲圖2-6) 可看出差異性－在資料庫中的CAPTION為“使用者設定”，在SQL File的CAPTION資料為“使用者管理”。 如果要更新資料，請在Selected欄位按一下，此時會出現 * 號，代表這筆資料要處理，或是勾選Select All。勾選Select All，會針對Status是M及I的資料作星號的設定，表示這些資料要處理，如圖 (2-7) 。 (▲圖2-7) 切換每個資料表頁次，查看要需要處理的資料表。 按下 執行按鈕，就會根據所選取的資料作資料異動處理。 點選Message頁次，可查看相關訊息，如圖 (2-8) 。 (▲圖2-8) 文件的產生 一般有受過軟體工程訓練的人都知道良好的專案來自事先需求的蒐集，細部規格系統規劃及測試。這些過程需要完整文件建立，但以台灣人來說，要將專案完成又要有完整的文件並不容易。有可能受限於工程師的素質有可能受限於專案時程。再來是，軟體這行業有其獨特經營困境。往往懂客戶需求將之轉化為軟體規格人員其所熟悉的技術已經過時，經常需與技術人員搭配才能將系統完成。但規格開立人員與程式師的溝通有經驗的人都知道這成本是相當驚人。最好的做法是文件與程式碼的建立是一體兩面。如此一來，規格開立人員與程式師溝通成本才會大量降低。 一般文件的產生方向有二種。（1）利用使用者在SA/SD工具所填入參數產生。（2）是逆向由執行檔產生。各由理由也各有優點，因此訊光SA/AD工具能正向與逆向產生文件。 畫面規格UI的輔助設計 此部份累積訊光長期在工具的努力經驗將之轉化為實用性頗高的模型。以下利用圖示來呈現： 一般SA/SD工具最容易呈現的部分在於UI設計模型部分。容易忽略『表單拋轉』及『資料過帳或表單過帳』，反而使用非常複雜的狀態關聯圖。要使用者花非常多的時間去歸納分析狀態變化，真是相當耗時。 仔細分細一般商業資料流程大致可由此三個步驟歸納而得。 『表單拋轉』：在實務上進貨單的資訊往往與報價單的資訊大致相同。因此，軟體系統會被要求進貨單的資訊可由報價單的資訊轉入。而這樣的案例，在整個軟體系統出現的頻率相當多。其實務的細節是進貨單必須保留欄位，記錄是由哪一類表單轉入，轉入報價單的單號。至於，報價單則必須保留欄位記錄，是否結案，轉出的進貨單的單號。有些更複雜的個案，必須設計挑選UI由系統使用者挑選哪幾筆單號中哪些明細項目，要被轉入。至於進貨單必須隱藏某些欄位，記錄已轉入數量，一旦轉入數量已超過報價單明細項目數量便控制不得再轉入。 『UI設計模型』：拋棄由使用者逐步慢慢分析，一個欄位一個欄位設計，還需注意狀態改變這種做法。改由模板設計內含新增、修改、刪除、查詢及列印等狀態。而且將新增、修改、刪除、查詢及列印等狀態，歸納程六大設計流程。省卻一個欄位一個欄位慢慢分析。 『新增流程』：系統會導引設計者逐步完成。自動編號，欄初始執值。 『修改流程』：系統會導引設計者逐步完成。如何控制某些資料(Reocrd)可修改。 『刪除流程』：系統會導引設計者逐步完成。此筆資料是否真正刪除或只是做Flag。 『查詢流程』：系統會導引設計者逐步完成。查詢畫面的設計及萬用查詢的UI設計。 『列印流程』：系統會導引設計者逐步完成。列印查詢畫面設計、資料結果預覽畫面。 每一個設計流程均會與欄位設計有關。這裡所謂欄位設計是一般由編號帶名稱、欄位不可空白、欄位輸入型態會影響後續欄位的輸入。 『資料過帳或表單過帳：一般工具大概只提供到Table欄位對Table欄位等級的過帳。而未提供表單對表單的過帳。Table對Table的過帳指的是某一個Table的異動(新增、修改及刪除)必須將數值根據鍵值累加、累減或取代別的Table的值。這樣的規劃遇到表單的過帳就顯的力有所未迨。表單過帳指的是一般拆單併單（如請購需根據供應商將請購單拆單成採購單）、自動轉單（例如庫存低於安全庫存自動新增採購單）。花掉程式師最多的時間上線及與SA/SD人員溝通成本是表單過帳。因此強化表單過帳是整套系統的最優先考量。 批次作業的輔助設計 在一般的專案最挑戰的部分是批次作業，往往牽涉庫存量的結算、庫存成本的計算或帳務的統計。因此，不僅例外狀況特多，程式碼計算的時間也長，而且也牽涉資料庫Commit模式（一筆失敗整批取消、一筆失敗忽略跳下筆）。好的工程師會在某一恰當時機記錄Log，以記錄為何計算無法繼續。因此，協助助工程人員設計Log畫面及資料庫Commit模式。 報表的輔助設計 一般工具在報表設計所能提供的輔助其實相當有限。因為報表設計其實有兩個層面的問題。一個是設計階段由開發者動手設計報表、另外是由使用單位動手調動報表此階段稱之為執行期。在設計期的需求往往是需要一個快速開的環境，至於執行期則是著重於彈性、簡易來開發。由於與EEP結合，在EEP功能強大的報表功能如清冊、交叉分析及套表均可在SA/SD使用。真正讓規格人員有能力利用本工具完成接近實務的專案。 最後，利用總表來表現SA/SD的功能。 功能模組 功能項目 TABLE SCHEMA的維護 Schema的設計。 Schema的版本更新。 同一欄位在不同Table的版本比較。 現成資料庫欄位匯入系統當成設計欄位。 資料的匯出匯入 M/D資料關係建立。 M/D資料的匯出 M/D資料的匯入。 M/D資料的匯入，可自行定義資料表及欄位。 匯入可自行Log隨時可回復不需先行備份。 文件的產生 正向文件產生 逆向文件產生 Schema、程式模組、畫面及欄位規格。 畫面規格UI的輔助設計 轉單設計 UI設計 資料過帳或表單過帳 ER Model設計 批次作業的輔助設計 資料庫Commit模式 Log的設計 報表的輔助設計 Design time設計 Run time設計 查詢畫面設計 查詢結果挑選畫面 往下追蹤 清冊 交叉分析 系統安裝環境 1. 產生EEP For Dephi 7.0的程式碼。需有Delphi 7.0才能自動Compiler。 2. 利用ADO與後端資料庫連結。現有資料庫有MS SQL 7.0，MS SQL 2000，ORACLE，INFORMIX。 3. 需與Word 運作才能產生文件。 4. 每一個Client分別授權。 成果預估 在發展週期上 一般專案大概分幾個時期。（1）是需求蒐集期。（2）是系統開發期。（3）是系統上線期。 可預期利用SA/SD工具之後，第（1）及（2）期的時間會大量下降。傳統需兩個人開發一年然後上線八個月的專案，開發一年這部分會被大幅下降至1~2個月。 在發展品質上 由於利用工具發展可確保每一個人開發流程大致一樣，上線的程式碼是依附在EEP平台。因此，工程師即便是缺乏經驗也很容易在辦公室寫出可資上線的 程式碼，進而確保每一個人產出的程式碼品質是可被確保。 教育訓練 由於工具已發展一系列標準設計流程，減少人員自行研發的過程。因此，新進人員比起傳統開發方式較易訓練。

如想看圖檔,請看此word 檔...    http://delphi.ktop.com.tw/loadfile.php?TOPICID=9192197&CC=205583

如想看圖檔,請看此word 檔...    http://delphi.ktop.com.tw/loadfile.php?TOPICID=9192197&CC=205583