軟件體系結構風格、設計模式及其應用

李建東

（蒙自市智慧城市運營管理中心 云南省蒙自市 661199）

根據上級領導的安排，我組織我們單位的技術人員和軟件公司的技術人員為市政府開發一套OA 系統，該系統的使用范圍為全市所有單位，該系統通過接口可以與州級的OA 系統實現互聯。該系統包括辦公管理、發文管理、收文管理、檔案管理、個人事務、圖書管理、信息管理、會議管理以及車輛管理等功能。在該系統的開發中我擔任系統架構設計師（項目負責人）的角色，主要負責系統架構設計和需求分析的工作。

1 軟件體系結構風格概述

軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。組織方式描述了系統的組成構件和這些構件的組織方式。慣用模式則反映眾多系統共有的結構和語義。按照Shaw 和Garlan的分類，軟件體系結構風格分為5 類，其中：

（1）數據流風格，包括批處理序列風格和管道過濾器風格。

（2）調用/返回風格，包括主程序/子程序風格、數據抽象和面向對象風格、分層系統風格。

（3）獨立構件風格，包括進程通信風格、事件驅動系統風格。

（4）虛擬機風格，包括解釋器風格和基于規則的系統。

（5）倉庫風格，包括數據庫風格、黑板系統風格、超文本系統風格。

除了上述5 種風格外比較常用的一種風格是分布式架構風格，它包括客戶機/服務器（C/S）風格、瀏覽器/服務器（B/S）風格。

在管道/過濾器風格中，每個構件都有一組輸入和輸出，數據輸入構件，經過處理以后，產生數據輸出。所以，構件被稱為過濾器，而這種風格中的連接件就好像是數據流傳輸的管道。unix 中shell程序的編寫以及編譯器主要應用了這種風格。在數據抽象和面向對象風格中，數據的表示方法和對它們的相應操作被封裝在一個對象或抽象數據類型當中，在這種風格中構件是對象，或者說是抽象數據類型的實例。而對象間交互的方式是連接件，對象是通過函數和過程調用來進行交互的。數據抽象和面向對象風格的應用十分的廣泛，現在面向對象的系統都屬于這種風格，它經常與其它架構風格一起使用。在事件驅動系統中構件不直接調用一個過程，而是廣播或觸發一個或多個事件。系統中的其它構件中的過程在一個或多個事件中注冊。當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一個模塊中的過程的調用。在面向對象系統中的某事件的單擊事件、雙擊事件就應用了這種風格。在數據庫系統風格中，構件主要有兩類，一類是中央共亨數據源，保存當前系統的數據狀態；另一類是多個獨立處理單元，處理單元對數據元素進行操作。它主要應用在數據庫管理系統中。

2 設計模式概述

設計模式是人們在長期的開發實踐中良好經驗的結晶，它提供了一個簡單、統一的描述方法，使人們可以復用這些軟件設計方法、過程管理經驗。一個設計模式通常由四部分組成：

（1）模式名。模式名就是給模式取的一個助記名。

（2）問題。描述了應該在何時使用模式，即在解決何種問題時可使用該模式。

（3）解決方案。描述設計的組成成分，它們之間的交互以及職責的分配。

（4）效果。描述了模式應用的效果以及使用模式時應權衡的問題，即模式的優缺點。按照目的和用途的不同，設計模式可分為創建型模式、結構型模式和行為型模式三種。創建型模式主要用于創建對象。結構型模式主要用于處理類或對象的組合。行為型模式主要用于描述類或對象的交互以及職責的分配。其中創建型模式包括：工廠方法、抽象工廠、原型模式、單例模式、建造者模式。結構型模式包括：適配器模式、橋接模式、組合模式、裝飾模式、外觀模式、亨元模式、代理模式。行為型模式包括：職責鏈模式、命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式、策略模式、模板方法、訪問者模式。

適配器模式將一個類的接口轉換成客戶需要的另外一個接口，從而使接口不兼容的類可以相互調用。橋接模式將抽象部分與它的實現部分分離，使它們都可以獨立地變化。組合模式將對象組合成樹形結構以表示“整體—部分”的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。裝飾模式可以動態地給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。外觀模式為子系統的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。中介者模式用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用，從而使其松散耦合。

3 軟件體系結構風格的應用

通過對OA 系統需求的獲取和分析，我們知道該系統的用戶主要有兩類，一類是辦公室用戶，他們在辦公室里通過局域網使用OA，而另一類用戶是外出用戶，他們通過Internet 使用OA，而管理員有全市系統管理員和單位系統管理員，全市系統管理員可以添加、刪除全市的所有人員，而單位系統管理員可以添加、刪除本單位的所有人員，該系統的主要功能包括辦公管理、收文管理、發文管理、信息管理、個人事務、檔案管理、圖書管理、會議管理以及車輛管理等。基于上述的需求，我們決定采用C/S 和B/S 的混合架構風格來設計整體架構。而選擇5 種經典架構風格中的某幾種風格來設計內部架構。在該系統的整體架構設計中，外出用戶訪問OA系統，我們采用了B/S 架構。對于外出用戶由瀏覽器通過internet訪問Web 服務器，通過Web 服務器再訪問數據庫服務。這樣做的好處在于外出用戶只需要一臺可以上Internet 的計算機就可以通過瀏覽器使用OA，而無需下載安裝客戶端軟件。出于Internet 網安全性的考慮，我們在Internet 和Web 服務器之間安裝了一臺VPN網關。辦公室用戶訪問OA 系統，我們采用C/S 架構。對于辦公室用戶由客戶端軟件通過局域網直接訪問數據庫服務器。這樣做的好處在于C/S 架構的數據查詢和修改的響應速度較快、交互性較強、網絡負載較小。

在該系統中通過采用管道/過濾器風格，實現通用收文流程和通用發文流程之間的對接。在每個單位中，通用收文流程中收到的外單位發來的公文，可以通過通用收文流程中的選擇發文類別來選擇所需的發文類別，如：局長、副局長、某某科室長、所有人員、某某人等，根據需要也可以多選，然后單擊發文，該文件便通過通用收文流程接口輸出，通用發文流程中有相應的接口對應獲取并分析處理數據，根據發文類別把文件發到相應人員的OA 系統里。通過這種方式減少了文件存儲和轉發、多次人員選擇等的工作量，提高了工作效率。通過采用事件驅動系統，實現了會議安排管理和會議室安排情況、后勤管理的對接。由于整個行政中心的會議室都是共用的，在該系統中會議管理人員只需要按照要求在會議安排管理中輸入參會人數及所需要的軟硬件環境等，并點確定后，系統將自動調出符合輸入參會條件，并且未被安排的會議室安排情況表，并且自動通知負責該會議室的后勤管理人員做好后勤服務準備。當所有后勤管理人員都確定收到這些消息并做好準備后，系統將自動出現某某會議室已做好開會的準備的提示。通過這種方式實現了整個會議安排管理的自動化，無需手動操作更多的內容，當以后改進系統的時候，可以很方便地操作。此外由于該系統是采用面向對象的思想進行的開發，我們在開發系統時抽取了很多類，如：管理員類、某某市管理員類、某某市某某單位管理員類、用戶類、流程類、發文流程類、收文流程類等等，類之間通過繼承實現了重用，類通過實例化生成了對象，對象間通過發送消息進行交互，所以該系統大量使用了數據抽象和面向對象風格。該系統的數據庫管理系統中使用了數據庫系統風格實現了數據的共亨。該系統在Web 頁面中，使用了超文本系統風格實現了構件按照人類的思維方式任意跳轉。

4 設計模式的應用

在該系統開發中，我們也大量使用了設計模式，在頁面設計中使用了裝飾模式，這樣如果用戶對開發的頁面顯示效果不滿意，通過添加具體裝飾類的方法，可以在不影響其它對象的情況下，動態的改變頁面的顯示效果，也可以很方便的撤銷原來的顯示效果。在登錄模塊的設計中，我們采用了外觀模式。登錄模塊根據用戶輸入的用戶名確定該用戶的類別，它是系統管理員還是一般用戶，是全市的系統管理員還是單位的系統管理員。然后根據相應的用戶類別，選擇相應的接口，進入相應的頁面。

在該系統中，需要對用戶和系統管理員進行查找，需要按收發文條數對各單位進行排序。而這些常用的算法在我們的類庫中都有相應的類，為了提高查找和排序的效率，我們決定重用類庫中的快速排序算法類和二分查找算法類。但快速排序算法類和二分查找算法類的接口不是OA 系統所兼容的接口，如果對接口進行修改將導致大量代碼的修改。此時我們采用了適配器模式，把快速排序算法類和二分查找算法類的接口適配成OA 系統所兼容的接口。在短信模塊的設計中，我們使用了中介者模式。在整個模塊中有一個守護進程在一直運行，相當于一個中介者，用戶是否在線，以及新短信存在與否，這些同事對象都是通過守護進程這個中介者與客戶端發生交互的。個人事務的設計中，使用了組合模式。將對象組合成樹形結構以表示“整體—部分”的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。在收發文流程的設計中，我們使用了職責鏈模式。使擬稿者、核稿者、簽發者、發文者等多個對象都有機會處理請求，避免了請求的發送者和接收者之間的耦合關系。

在該系統的開發中我們也遇到了一些問題，一是各單位的電腦形形色色，有配置高的，有配置低的，有的電腦甚至用了十年都沒有更換，然而C/S 架構中的客戶端軟件既要完成用戶與應用間的對話功能，又要處理業務邏輯，這種胖客戶端的形式使某些配置低的電腦很難承當這種負載，從而導致響應速度慢甚至死機的現象，后來我們對辦公室用戶OA 的使用采用了三層C/S 架構，以減輕客戶端的負載。二是開發中不要過度使用設計模式，為了使用設計模式而使用設計模式。使用設計模式的前提是，明確該模式是否符合問題的場景，并且應該權衡利弊，比如使用代理模式能在一定程度上降低系統的耦合度，但缺點是會使請求的處理速度變慢，并且實現代理模式需要額外的工作。在請求處理速度要求高的模塊中，就不適合使用代理模式。

在該項目的開發中，選用了多種軟件體系結構風格及設計模式。整個系統各個模塊相對獨立，實現了松散耦合，使系統具有很好的開放性、易擴展性、易移植性、靈活性。節省了開發和維護成本，提高了系統的開發效率。