淺談財務管理系統使用者可定製性技術論文

淺談財務管理系統使用者可定製性技術論文

　　1引言

　　目前，不管在行政事業單位，還是在生產企業單位，財務管理系統是一個較典型的應用系統。在軟體工程界，很多軟體組織在現有的開發環境下使用了各種可能的方法與途徑進行過此方面應用系統的設計與實現，但是還存在一些共同的問題，主要表現在:

　　(1)按通用系統來進行設計，把業務的主要邏輯或計算公式存放在資料庫中，除系統表以外設計模式，大部分表採用自定義方式，保證所開發的財務管理系統能用於所有學校或行政企業單位。

　　(2)從介面和業務分離到分散式多層體系結構，包括介面和業務的邏輯分離、介面與業務的物理分離、介面和業務的空間分離。

　　(3)系統與其他系統的資料匯入與匯出的設計。

　　(4)各種自定義報表的設計。

　　(5)在建立型模式、結構型模式以及行為型模式系列中選擇合式的模式運用到本系統中。

　　(6)功能物件、協調物件以及資料物件的如何設計，才能使系統性能達到最佳。

　　(7)系統的安全性考慮，如基於角色的訪問控制管理問題等。

　　為使得財務管理系統具有使用者可定製性，以軟體複用技術為設計理念，利用面向物件程式設計思想，充分使用元件開發、模式設計的思想、分散式多層體系結構等現代軟體工程關鍵詞彙，便於人們在軟體開發中的交流與溝通，有助於實現應用程式的功能，有助於建立一個複雜的架構。每個模式提供元件、作用以及相互關係的預定義集。

　　系統採用演進軟體開發過程模型，使用面向物件軟體開發方法，貫徹設計模式思想，採用分散式多層體系結構與DCOM/COM+元件等技術[4，5，6，7]來實現財務管理系統的業務邏輯，主要有對工資類、津貼類、福利類、加班類、獎勵類以及其他類各項收入進行日常管理(包括日常資料修改、查詢及報表列印)，能夠按指定要求將六類收入彙總統計，方便對各項資料進行財務分析;根據人事資訊資料，對各類人員的資訊增加修改、查詢;根據財務核算要求任意新增、修改各大類明細專案;以工資號為主鍵，透過手工修改、成批修改、公式修改待等方式方便、靈活地修改人各收入類資料設計模式，降低資料集操作的工作量，提高工作效率;根據各項指定條件(單個條件或組合條件)，方便、快捷地篩選資料;自定義報表輸出，根據業務需要，將系統中的查詢資料、彙總資訊及變動資訊實時列印或轉換成Excel表的形式輸出;在校園網環境中，允許多使用者同時登入系統;介面人性化設計，充分考慮財務核算人員的操作思路，直觀反映財務管理要求，方便人機資訊交換。

　　2財務管理系統架構使用者可定製性技術

　　財務管理系統架構使用者可定製性體現在:真正的軟體複用和高度的互操作性[8]，開發者可利用它組合成不同的應用系統;介面的可靠性，元件介面是不變的，介面是穩定的;可擴充服務，每個元件是自主的，有其獨自的功能，只能透過介面與外界通訊;具有強有力的基礎設施，為了元件有機地組織在一起;具有構建和組合元件的工具，可以方便地增加和替換應用中的元件，充分發揮可複用的優勢，實現客戶應用程式的組裝和升級。在開發鹽城師範學院財務管理系統時設計模式，採用了COM/DCOM元件技術。透過該系統可以對學院的教職的收入的六大組成部分(工資、福利、津貼、加班、獎勵和其它)的資訊進行輸入、匯入、匯出、查詢、統計、修改、列印和生成銀行報盤。

　　系統採用三層結構，客戶端表示層由FORM窗體組成，可實現COM元件的呼叫，業務邏輯和資料訪問由一組用Delphi實現的COM元件構成。為了便於維護、升級和實現分散式應用，在實現過程中，又將業務邏輯層和資料訪問層分離開，客戶端不直接呼叫資料訪問層，而是透過業務邏輯層來呼叫資料庫，如圖1所示。

　　圖1 三層結構示意圖

　　中間層元件對所用到的資料庫中的表示進行了封裝，形成了元件。透過介面為表現層提供服務。建立Remote Data Module業務邏輯，確定應用程式伺服器的名稱、例項屬性以及伺服器所使用的執行緒模型等資訊。然後向空白窗體中加入非視覺化的VCL元件。

　　本系統中主要ADOConection， ADOCommand，ataSetProvider， ADODataSet等元件，如圖2所示。 圖2 系統資料存取元件 表現層的主要元件包括登入元件，資料查詢元件，資料修改元件，個人資訊專案管理元件，基本表管理元件，銀行報盤元件，公式設定元件，資訊初始化元件設計模式，生成彙總資料元件和報表列印元件等。

　　3財務管理系統模組使用者可定製性技術

　　3.1 資料庫模組使用者可定製性技術

　　為使本系統具有通用性，後臺可使用不同的資料庫，如Access資料庫、SQL資料庫等。而應用程式中提供使用者訪問資料庫的某一專用的資料集物件往往難以勝任這種多變的需求。由於資料庫的連線和訪問機制比較複雜。如果將資料庫連線方式寫死在程式中，將不利於今後的維護和複用。如果客戶端能夠建立一個通用的資料集物件建立方法來建立資料集物件，就可以解決這個問題。這樣，物件的建立方法要與要建立的物件就可以分離開來，達到去耦的效果。

　　如圖3所示，是一個用於資料庫訪問的工廠方法設計模式圖，圖中的TDataFactory和TDataSet分別是工廠方法模式中的工廠類和產品類。它們都是抽象類，負責維護工廠和新產品之間的關係，TDataFactroy負責建立TDataSet物件。

　　圖3 工廠模式

　　顯然，系統事先無法知道會使用何種型別的資料庫以及使用何種資料庫連線機制。只知道何時有一個新的資料集物件要被建立，但不知道所要建立的是哪一種資料集物件。這就是說系統將實際建立工作委派到TDFactory類的派生中了。而這個抽象類TDFactory提供建立資料集物件的抽象方法CreateDataSet，它相當於一個虛構造子，而具體工廠類建立具體產品的過程是透過多型來實現的。

　　3.2系統介面模組使用者可定製性技術

　　不同使用者對系統介面的要求不同，有的使用者喜歡使用傳統的按鈕介面，有的使用者喜歡使用選單介面。鹽城師範學院財務部門的操作人員就有這兩種不同的需求。本系統透過使用抽象工廠模式實現兩種操作介面，即按鈕介面和選單介面。

　　如圖4所示，是一個抽象工廠的設計模式。在這個例子中設計模式，包含了命令按鈕和選單兩種風格的窗體，即兩個產品系列。這樣便於改變產品族，維護產品的一致性。為了維護產品的一致性，定義了一個抽象類TFormMaker，TForMaker類宣告一個介面來建立各種元件的原型。同時又由這些元件的抽象類及具體類負責產生元件的例項。TFormMaker的介面提供統一的操作為所有元件產生新的物件例項。客戶端呼叫這些介面的操作來得到一個元件例項，但卻和具體實現相隔離，因為客戶端沒有必須瞭解所用到的那些產生例項的具體類。

　　圖4 抽象工廠模式

　　這裡TFormMaker有許多派生類分別建立需要的元件，每一個派生類都是一個例項具體產品生產的具體工廠，由它們來實現建立不同風格的元件的操作。如在TFormMaker的派生類中有一個CreateButton，客戶只需與TFormMaker這個抽象的介面CreateButton溝通而不必理會到底是由哪一個具體類建立了按鈕。TFormMaker同時強調具體類之間的依賴性，這就是說不同的TFormMaker所產生的例項實際上是不同具體工廠的不同例項。

　　3.3資料顯示模組使用者可定製性技術

　　在本系統的開發中，用到大量的資料感知元件，透過這些元件來顯示資料表中的記錄。為了適應不同資料庫的連線要求，使增加新的資料庫和資料庫存取標準而無須修改客戶端的資料顯示程式。因此在本系統中作為建造者的'新產品也就有TTable、TADOTable等多種形態。如果將建立資料集物件的方法從其表現中分離開來，由可抽象為以下的演算法步驟:建立資料庫的連線，建立資料集物件，啟用並返回資料集物件。

　　在系統開發的過程中，由於要涉及到多個表，而對各個表的操作介面是完全相同的。用建造者模式能夠簡化程式的編寫設計模式，使程式介面簡潔。而且有利於系統的擴充。工資資料表和津貼資料表關係如圖5所示。

　　圖5 建造者模式

　　3.4檔案轉換模組使用者可定製性技術

　　在系統開發過程中，我們開發一個通用的元件，用於實現將資料庫中符合條件的表的內容轉換成Excel檔案或文字檔案。這樣設計的好處是既可以在自己的本系統中使用這一元件，也可在其它系統中使用該元件。在實際開發中需要用到這種轉換的場合很多。另外如果以後要轉換成其它格式的檔案，只要在介面卡類中進行修改就可以了，客戶端的程式完全不用修改。

　　但在使用這一模式時，也容易犯這樣的錯誤，在設計Adapter時不願犧牲Adaptee物件的多餘功能 ，轉換了過多的Adaptee介面並使介面變得複雜。在實際應用中往往是功能單一且通用、對其它條件依賴性較少的少數介面。所以在設計Adapter模式時要考慮為Adaptee找到一個窄介面，即可用於匹配的最小操作集。系統中用於轉換成類圖如圖6所示。 圖6 介面卡模式 3.5資料的顯示、查詢和修改模組使用者可定製性技術

　　在系統開發中，有很多的地方用到資料的顯示、查詢和修改。用到了“顯示資料”——“資料物件”——“後臺資料”就對應了“表現層”(介面)——“邏輯層”(業務)——“持久層”(資料庫或其它檔案)。這是程式設計師在程式設計應用程式時應該遵循的Class-Type體系結構。透過這種結構，應用程式會因為減少了內部的耦合性而顯著提高程式的健壯性。如果使用者介面層要獲得資訊，則必須與業務層的物件互動，然後再透過業務層物件從持久層獲得儲存在持久層中的物件。這樣就能禁止使用者層物件直接訪問持久層物件中的資料。也就是說你可以改變物件的儲存方式，而不需改變你的應用程式介面和報表，如圖7所示。

　　圖7 橋接模式

　　3.6資料的顯示、查詢和修改模組使用者可定製性技術

　　在系統開發的過程中，要涉及對多個表的操作，如對錶進行初始化。儘管對不同的表進行操作，但對錶的操作方法是一樣的。如果讓使用者直接對錶進行操作設計模式，則會對錶產生很大的依賴性，如何增加一個門面層，則會減少這種依賴關係，可以提供子系統的獨立性和可移植性。系統中對多個表進行定義的簡化圖如圖所示。使用者透過operate實現對不同表的操作。門面模式圖如圖8所示。

　　圖8 門面模式

　　4結束語

　　本文對“元件化軟體設計方法與設計模式等技術”進行了實踐，，從使用者可定製的角度設計應用系統，保證所設計系統具有良好的適應性、可維護性:反映教職工基本資料可以由系統管理員隨意定義，並方便管理員增加或刪除;所有報表結構可以動態定義，可以根據單位需求的變化進行變動;設計了結構良好的資料匯入與匯出功能，方便應用系統間的資料互動;採用了基於角色的訪問控制方式，由系統管理員定義多級角色，再根據使用者業務需要，為每個使用者分配不同的角色。這樣保證系統具有良好的可管理性與安全性。

　　參考文獻

　　[1]JeffreyK.H.Mak， Precise Modeling of Design Patterns in UML. Proseeding of the 26thInternational Conference on Software Engineering(ICSE2004):101-120

　　[2]NeelamSoundarajan and Jason D.Hallstrom， Responsibilites and Rrewards: SpecifyingDesign Patterns. Proseeding of the 26th International Conference on SoftwareEngineering(ICSE2004).

　　[3]王俊峰，戚曉濱.設計模式和UML. 計算機應用研究. 1998，5:27-29.

　　[4]CarmaMcClure.軟體複用標準指南.北京:電子工業出版社.2004

　　[5]於長華.基於三層C/S模型的大型關係資料庫應用系統最佳化設計技術. 計算機工程與應用. 1999，11:90-92.

　　[6]蔣建平，梁新元，舒紅平.基於元件和中介軟體的裝配式軟體系統模型.計算機工程與應用2004，34:137

　　[7]Pressman RS.Software Engineering:A Practitioner’s Approach[M].5thed，McGraw-Hill Companies Inc，2000

　　[8]梅宏，陳鋒，馮耀東，楊傑.基於軟體體系結構、面向元件的軟體開發方法.軟體學報，2003，14(4):721-73