關鍵詞:電子政務、軟件復用、領域架構、層次架構、可復用組織
隨著信息化技術的發展普及,電子化公文管理成為政府機關的一個戰略性課題。為了進一步推動政府信息化的建設,必須進一步研究和開發適應新時代的基于Internet和Intranet的公文管理系統,以提高機關公文辦理效率,提升政府績效。正是在這一市場機遇下,我們研究開發了公文管理系統產品-DocMan公文管理系統(以下簡稱:DocMan)并取得了良好的市場效果。
DocMan公文管理系統是面向政府機關的公文處理系統,是電子政務的主要組成部;因此,DocMan和其他電子政務子系統一樣存在跨平臺、分布、異構以及對原有應用系統進行整合的問題。為了面對各類機關的應用需要,DocMan公文管理系統,采用了多層B/S架構(客戶端瀏覽器層、Web服務器層、應用服務器層、數據庫層)、并采用了J2EE及EJB技術實現系統的分布異構及跨平臺。為了滿足各類機關的需要,DocMan對流行操作系統(Win32系列,Unix系列,linux系列)、Web服務器(Tomcat4.0,IBM WebSphere4.0,BEA WebLogic 5.0)以及數據庫管理系統(Oracle ,SQL Server , Sybase,Infomix,DB2等)都給予支持。在考慮大型機關應用時,我們選用了代理服務器、多并行Web服務器及多應用服務器技術實現系統的負載均衡和流量管理。由于當前分布式數據庫的應用不夠成熟,DocMan采用了集中式數據庫技術實現機關數據的存儲。
現就我們在開發DocMan產品時遇到的有關軟件復用方面的問題、解決方法以及實現策略介紹如下。
一、需求重用
1 企業產品領域的定位
隨著政府上網工程的推進,電子政府與電子政務正逐步走向成熟;并給軟件行業帶來了新的業務領域,而我們所開發的公文管理系統只是電子政務的一小部分;因此我們公司將業務定位于電子政務行業。電子政務需要的軟件產品眾多,而公文管理系統可以看作是政府辦公自動化軟件的一個子系統,在公文管理系統開發完成后,我們將進一步開發政府辦公所需的其他軟件子系統,逐步為政府行業的應用提供全套的解決方案。
2 領域工程核心的識別與抽取
在產品領域定位的指導下,我們經過深入的分析調研,發現所有的事務型系統都有一個共同的特征:工作流程。在ISO9000中也規定任何組織的事務處理必須有標準,規范的工作流程。(在ISO9000中為了實現ISO9000規定的20個質量要素,必須制定相應的體系文件。這個體系文件分為3層:第一層質量手冊,制定組織的質量方針、目標;第二層工作程序,制定為了實現質量目標所定義的工作程序即工作流程;第三層表單,制定了在工作程序運行過程所用的表單。)在系統分析時,可以將這些業務工作流程抽象出來,如公文管理中的收文流程、發文流程、歸檔流程、稽催流程、檔案管理流程等;另在非公文管理的其他的業務中也可以抽取流程如:車輛管理業務流程、會議室管理流程、請假加班流程等等。因此,我們可以建立一個工作流平臺,使所有的業務流程只要在工作流平臺中進行定義就可以運作。從而實現"零代碼編寫的理想目標"。
3 產品非業務性需求分析
一般的應用軟件產品除了完成業務所需要的功能外,還必須有一些支持模塊,以支持系統的正常運行。這些模塊通常包括:組織管理模塊和系統支持模塊。組織管理是機關業務得以正常運作的基礎,這對于每一個電子政務領域內的應用系統來說都是必不可少的。通常系統支持模塊是為了軟件系統的正常運作所提供的必不可少的功能,如系統權限管理、日志管理、數據庫備份/恢復功能等都屬于此類。所有的這些都可以作為我司系列軟件產品的公共模塊加以復用。
4 產品界面風格
對于企業來說,保持系列產品在風格上的一致性是非常重要的。它不但可以減少系列產品的廣告費用,減少系列產品的維護、培訓費用;而且還可以在軟件開發時進行界面風格復用,減少軟件開發費用。因此在企業進行系列產品的開發時保證產品在風格上的一致性、操作方式上的一致性是至關重要的。
二、設計重用
1 領域架構的設計
在產品開發之初,我們識別了所有的業務流程都可以運行于工作流平臺之上。因此,我們在產品設計時,采用了以工作流平臺為核心的領域軟件產品設計架構。如圖1所示。
該工作流平臺除了向產品最終用戶提供流程自定義工具,使用戶無需編程就可以自定義出所需要的工作業務流程,并可對流程流轉過程進行實時監控;之外,還向軟件開發人員提供了快速應用開發工具以及API接口,使開發人員只要調用該工作流平臺API就可以實現復雜流程業務程序。
2 層次架構的設計
在選好系統領域框架和統一開發方針后, 系統構件的開發就應充分利用已有框架所提供的服務和工具;并力求實現大粒度構件重用。通過系統構件的分層,將頻繁變動得業務邏輯層分離出來,實現通用類構件的完全復用。并且在各個模塊之間設計統一的接口,當某一模塊業務邏輯改變時,使系統之間的影響最小,使系統實現即插即用,讓系統容易升級。為此將我們將產品的系統構件模型定義為四個層次:1)系統構件層、2)通用模塊構件層、3)業務構件層、4)表現層。如圖2所示。
圖1 領域構架
圖2 層次構架
?。?)系統構件層,指系統開發平臺本身所提供的類庫包括Java JDK類庫等。
?。?)通用類構件層,是我們產品復用的核心。它不但能實現產品的縱向復用,而且還可以實現系列產品的橫向復用。在這一層主要包含了工作流平臺核心模塊、組織管理模塊、系統管理模塊(包括:權限管理、存取控制、日志管理、數據備份/恢復等等)、頁面風格函數以及JSP的CSS、JS等、字符串處理、數據庫連接、日期處理等等與業務邏輯無關的類函數。
?。?)業務構件層,指為了滿足各個不同業務的需要而設計的軟件包,并在業務軟件包中設置明確的接口,方便業務之間的交互,并可以實現系列產品之間的大粒度構件復用。
?。?)表現層。主要采用JSP、Serverlet頁面來展現業務流程界面。在該層JSP只調用JavaBean業務邏輯接口方法實現業務邏輯的處理,而不涉及任何業務邏輯,在系統中取到用戶與系統交互的作用。
3 面向對象的設計
在系統開發時,我們采用了面向對象的技術。通過面向對象的方法、消息、類、繼承、封裝、多態和實例等機制構造軟件系統,并為軟件復用提供強有力的支持。
?。?)模塊化設計 在設計時我們采用了面向對象的包機制實現對業務流程的模塊劃分,如公文管理系統的發文流程、收文流程。在模塊之間通過定義明確的消息機制與方法接口實現模塊之間的交互。另外,在模塊劃分時,我們還注意到了底層模塊的抽取,盡量將用戶會話接口包與業務實體包相分離;如在工作流平臺設計時我們從中抽取了與用戶接口無關的工作流元模型包和工作流引擎包,他們可以向其他包提供調用接口方法,實現盡可能的大粒度重用。
?。?)類設計 在類設計時,我們采用了類的封裝、繼承、多態等機制實現類設計復用。在類中實現了所有的處理邏輯,這些類中一般都可以提供新增、刪除、修改、查詢四大類操作,并盡可能的提供處理邏輯所需要的方法接口,實現一次編寫處處運行的理想目標。采用繼承和多態機制后子類的實現可以繼承父類的各個屬性與操作,從而避免了相似功能的重復編碼,提高了程序的可維護性,簡潔性、可讀性。
三、代碼重用
在采用上述可復用的分析、設計方法后,系統的實現將變得相對的容易。在各代碼段的實現時,只需要調用明確的接口,就可以實現處理功能,降低了算法的復雜度,大大提高了編碼的效率及程序的可維護性。在編碼時,我們主要采用了JavaBean和JSP技術實現了業務實體邏輯和用戶系統操作接口。在JavaBean中充分采用了Java的優秀的面向對象機制,實現了業務實體類的處理邏輯,并盡可能的達到了JavaBean方法的一次編寫處處運行的目標。在編寫JSP時,我們完全引用了業務邏輯層的JavaBean,從而使JSP的頁面編寫變得簡單,并實現了業務邏輯的封閉性,提高了JSP程序代碼的安全性。
另外,在編碼過程中的一個重要復用是算法的復用。由于在類設計時基本上每一個類都提供了相似的功能,如新增、刪除、修改、查詢,而這些操作的算法基本上是一致的,差別只在于SQL語句的差別;所以在設計編碼時,可以先設計一個基類提供這些功能,在其他類實現時可以繼承基類并重載或應用這些方法,實現算法的重用。
四、復用的組織結構
在軟件復用的過程中,僅僅有軟件復用方法是不夠的,還必須有復用的開發組織結構可以支持。因此,我們在產品開發過程中建立了復用的組織架構。一般的復用的組織架構主要由三組成員組成:復用構件創建組、構件應用組和協調組。復用構件創建組,主要收集歸納并創建可以復用的構件提供給構件應用組使用;構件應用組主要進行業務邏輯的設計與實現,在開發過程中使用構件創建組提供的可復用構件進行業務邏輯的快速實現,并幫助構件創建者歸納,收集可復用構件;協調組主要在構建創建組和構件復用組織間起協調的作用,起到構件的分發推廣的作用,在項目較小時可以由項目經理或系統分析員充當。
其實在軟件復用過程當中,不僅僅通用構件層提供的類函數可以復用,在業務層模塊之間也可相互引用。但是在引用時,也應該盡量避免模塊之間的交互,提高模塊的內劇性、降低模塊間的耦合性。在模塊之間的引用協調也由協調組完成。
五、軟件部件庫
在軟件復用過程當中,我們建立了軟件部件庫以進行可復用構件的推廣使用。在構件創建完成后,創建者將該構件存放于產品項目工程中提供應用組使用;并用JBuilder生成JavaDoc文檔存放于Visual SourceSafe部件文檔庫中以便應用時查詢,同時通知每一個開發成員。
當應用組成員需要調用通用構件或其他模塊的方法或函數時,直接應用即可;如果在軟件部件庫中沒有他需要的方法或函數,則可詢問協調者,由協調者解決該問題。協調者可以通知創建者進行創建提供或用其他方式解決。
六、結論與不足
在公文管理系統及電子政務產品開發過程中,我們主要采用了以上方法進行軟件的復用開發。實現了產品領域橫向的復用和產品開發過程中的縱向層次架構的復用;并在軟件開發過程中采用全程(從需求分析到編碼實現)復用的策略進行軟件開發,從而大大提高了軟件產品的可復用性,提高了軟件開發的生產率,并為后繼產品的開發提供了良好的可復用基礎。但在開發過程中也存在一些不足,有待于我們進一步改善。如:
?。?)系統分析設計的力度不夠。由于在系統開發過程中系統分析設計人力不足,在項目緊任務重的情況下,沒有對分析設計文檔審核就開始編碼實現。因此對分析設計過程中存在的錯誤沒有進行及時改正。另外,對模塊包的劃分也沒有仔細的考慮、驗證,對某些類的設計也不夠合理。
?。?)開發組成員軟件復用意識的不夠。由于開發人員軟件復用意識不夠,在成員之間溝通不力的情況下自行編寫底層構件,從而降低了軟件的可維護性;而更有甚者在業務模塊編寫時,直接在JSP表現層實現對業務邏輯的處理,而沒有抽象為JavaBean,雖然在表面上提升了單個模塊的開發效率,但卻降低了整個開發組織的效率、可重用性以及程序的安全性。
?。?)開發人員面向對象知識的欠缺。在開發過程中由于開發人員面向對象知識的欠缺,在設計實現時沒有采用面向對象技術,從而降低了軟件的可重用性。
?。?)面向對象分析設計工具的欠缺。由于在分析設計過程當中,我們沒有很好的運用Rose等分析設計工具,從而加大了分析設計的難度,降低了文檔的可維護性、修改性和可復用性。
在下一步的開發過程中我們將盡力的改善這些狀況;以便為國家的電子政務事業提供更多更好的軟件產品,為國家電子政務事業的發展作出更大的貢獻。
原文轉自:http://www.anti-gravitydesign.com