一、設定會計科目
（一）新增、修改、刪除會計科目
從圖 4-18 的系統初步設計類別圖中，可以看到無論是大分類設定、小分類 設定還是細項會計科目設定，都可能會建立Insert、Modify、Delete 物件處理新 增、修改、刪除等作業。這樣的做法會產生效能上的問題，因為若是使用者在系 統執行期間執行了很多次的新增、修改、刪除，會導致過多的Insert、Modify、
Delete 物件被重覆生成使用，進而對系統造成沉重負擔。
根據本研究之設計樣式導入流程，由於此處並無聚合關係或組合關係，因此 導入流程的第一大項判斷條件可直接略過。此外，雖然此處有生成物件的需求，
但由於此處最主要的考量為效能上的問題，且效能瓶頸發生在大量可共用的小型 物件被重覆使用，因此可略過導入流程的第二大項判斷條件，選擇進入第三大項 判斷條件，導入Flyweight 樣式。同時由於負責管理可共用小型物件的物件需要 Flyweight 樣式結合 Singleton
圖4-25 系統設計類別圖—新增、修改、刪除會計科目（資料來源：本研究）
（二）顯示已建檔會計科目清單
從圖4-19 的系統初步設計類別圖中，可以看到由於大分類、小分類以及細 項會計科目設定的畫面中所呈現的科目資料皆不盡相同，因此分別需要建立不同 的物件幫助其抓取其所需的會計科目資料。但若是以圖4-19 中的方式建立物件，
會加強類別之間的連結關係，相對降低程式日後修改的彈性。
依據本研究所提出之設計樣式導入流程，雖然此處含有聚合關係，但由於此 處的聚合關係只是單純的將從資料庫中擷取出來的資料逐筆存放為動態陣列，並 沒有牽涉到複雜的巡訪動作、操作內容，因此導入流程的第一大項判斷條件中的 三項細部判斷條件皆可直接略過。但由於此處有生成物件的需求，且又希望能不 用事先得知該生成何物件，因此可選擇進入第二大項判斷條件中的第二項細部判 斷條件，導入Factory Method 樣式。此外，由於 QueryMainAccount、
QuerySubAccount、QueryAllSubAccount、QueryDetailAccount 等四個類別中除了 生成物件的實作方式外其餘的演算法則皆大致相同，因此可再將Factory Method 樣式結合Template Method 樣式。導入設計樣式的設計類別圖將如下圖所示：
圖4-26 系統設計類別圖—顯示已建檔會計科目清單（資料來源：本研究）
二、維護傳票
（一）新增、修改、刪除傳票
此處所面臨的問題，和「設定會計科目」使用案例中的「新增、修改、刪除 會計科目」作業相同。根據本研究之設計樣式導入流程，由於此處並無聚合關係 或組合關係，因此導入流程的第一大項判斷條件可直接略過。此外，雖然此處有 生成物件的需求，但由於此處最主要的考量為效能上的問題，且效能瓶頸發生在 大量可共用的小型物件被重覆使用，因此可略過導入流程的第二大項判斷條件，
選擇進入第三大項判斷條件，導入Flyweight 樣式。同時由於負責管理可共用小 型物件的物件需要成為隨處可用的單一個體，因此我們可再進一步將Flyweight 樣式結合Singleton 樣式。導入設計樣式後的系統設計類別圖將如下圖所示：
圖4-27 系統設計類別圖—新增、修改、刪除傳票（資料來源：本研究）
（二）查詢傳票
此處所面臨的問題，和「設定會計科目」使用案例中的「顯示已建檔會計科 目清單」作業相同。雖然此處含有聚合關係，但由於此處的聚合關係只是單純的 將從資料庫中擷取出來的資料逐筆存放為動態陣列，並沒有牽涉到複雜的巡訪動 作、操作內容，因此導入流程的第一大項判斷條件中的三項細部判斷條件皆可直 接略過。但由於此處有生成物件的需求，且又希望能不用事先得知該生成何物 件，因此可選擇進入第二大項判斷條件中的第二項細部判斷條件，導入Factory Method 樣式。此外，由於 QueryById、QueryByType、QueryByKeyword、
QueryByDate 等四個類別中除了生成物件的實作方式外其餘的演算法則皆大致 相同，因此可再將Factory Method 樣式結合 Template Method 樣式。導入設計樣 式的設計類別圖將如下圖所示：
圖4-28 系統設計類別圖—查詢傳票（資料來源：本研究）
（三）新增傳票畫面上文字輸入區和按鈕的互動
在前面的使用案例說明一節中，曾提過在新增傳票時，必須至少輸入一筆分 錄記錄才能將此筆傳票存入資料庫中。此外，使用者也有可能會在新增傳票時遺 漏某些必填欄位就進行存檔動作。因此，在設計新增傳票畫面時，有必要將畫面 上的文字輸入區和按鈕間的互動設定好。若是使用者還沒輸入任一筆交易記錄，
或是還沒填好某些必填欄位，就讓「存檔」這個按鈕保持在不能按的狀態。欲實 現這樣的功能，物件之間的互動關係將會相當複雜。
根據本研究之設計樣式導入流程，由於此處並無聚合關係或組合關係、沒有 生成物件的需求、沒有效能上的考量，因此導入流程的前三大項判斷條件可直接 略過，但由於此處物件之間的互動相當複雜，且發訊者和收訊者之間是呈現多對 多的關係，因此可運用Mediator 樣式將設計最佳化。導入 Mediator 樣式後的設 計類別圖將如下圖所示：
圖4-29 系統設計類別圖—新增傳票畫面上文字輸入區和按鈕的互動（資料來 源：本研究）
三、過帳
由於「過帳」的類別結構已相當簡單，所以不需導入任何設計樣式。
四、編製日常報表
由於「編製日常報表」的類別結構已相當簡單，所以不需導入任何設計樣式。
五、編製財務報表
由於「編製財務報表」的類別結構已相當簡單，所以不需導入任何設計樣式。
如前所述，若是以一般樣式對應的方式導入設計樣式，設計人員首先必需對 二十三則GoF 設計樣式有著相當程度的理解，才能依個人判斷決定設計樣式的 取捨途徑。但若是依循本研究所提出之流程進行設計樣式的導入工作，則可根據 從系統初步設計類別圖中發掘出的問題，先逐一找出可運用的設計樣式，再進一 步研讀此設計樣式的定義、目的及優缺點，判斷是否確實要將此設計樣式導入系 統的設計中。如此一來，可有效縮短設計人員判斷決定設計樣式取捨途徑的時程。