- 相關推薦
淺談財務管理系統用戶可定制性技術論文
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
【淺談財務管理系統用戶可定制性技術論文】相關文章：
淺談課堂教學的有效性論文06-06
淺談水彩畫的偶然性論文07-27
淺談信息技術與課堂教學論文12-24
《淺談小學教育的重要性》論文（通用7篇）06-28
淺談物資采購計劃準確性的分析與思考論文07-12
淺談高校跨文化交際能力培養的重要性的論文04-15
淺析技術的重要性論文（精選15篇）07-08
淺談幼小銜接的論文04-13
淺談文化自信論文04-25