專利名稱：一種基于文檔樹和消息泵的插件式軟件設(shè)計方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計算機軟件設(shè)計領(lǐng)域，具體涉及ー種對計算機上軟件復(fù)用的一種強化
管理方法。
背景技術(shù)：
·
軟件的エ業(yè)化使得軟件復(fù)用已經(jīng)從通用類庫進化到了面向領(lǐng)域的應(yīng)用框架。應(yīng)用框架強調(diào)的是軟件的設(shè)計重用性和系統(tǒng)的可擴展性，以縮短大型應(yīng)用軟件系統(tǒng)的開發(fā)周期，提高開發(fā)質(zhì)量。面對這種發(fā)展趨勢，呼之欲出的便是ー種全新的、開放性的、高擴展性的架構(gòu)體系，即插件式軟件設(shè)計，按功能塊的方式劃分軟件。交互軟件通常在軟件架構(gòu)設(shè)計上，采用MVC即Model (模型)-View (視圖)-Controller (控制器)的分層方式,Event (事件)導(dǎo)致Controller改變Model或View,或者同時改變兩者。只要Controller改變了 Model的數(shù)據(jù)或者屬性，所有依賴Model的View都會自動更新。類似的，只要Controller改變了 View, View會從依賴的Model中獲取數(shù)據(jù)來刷新自己。結(jié)合插件式設(shè)計，可以將插件按照業(yè)務(wù)邏輯分為模型、視圖和控制器。在此技術(shù)背景下，文檔管理、模塊間通信和視圖管理就成為設(shè)計的重點和難點。以現(xiàn)有技術(shù)中的SharpDevelop為例SharpDeve I op是一個用于制作C#或者VB. NET的項目而設(shè)計的一個編輯器，其自身是ー個開源的使用C#語言實現(xiàn)的IDE (集成開發(fā)環(huán)境)，其設(shè)計思想被用戶廣泛的使用。在SharpDevelop軟件的3. 2. O. 5777版本的開源代碼中，文檔數(shù)據(jù)管理、模塊間通信和視圖管理使用如下解決方法。如圖I所示，每類文檔對應(yīng)ー個文檔類，通過建立一個三級扁平化的文檔樹來管理各類文檔對象。樹的根節(jié)點是Solution,根節(jié)點有SolutionItem(及派生類)和SolutionFolder等孩子節(jié)點，其中SolutionItem (及派生類)為葉子節(jié)點，SolutionFolders (即為project文件夾)節(jié)點有Projectltem (及派生類)葉子節(jié)點，如圖2所示的類關(guān)系圖中，模塊間通信是通過接ロ調(diào)用來處理和解決插件間模塊的通信，通過事件(Event)的訂閱來處理插件內(nèi)部的模塊間通信。文檔視圖管理是由統(tǒng)一的平臺(DefaultWork bench)管理兩種視圖，兩種視圖分別是面板視圖容器和文檔視圖容器。ー個或者多個文檔對應(yīng)一個文檔視圖或者面板類，文檔視圖或者面板類都由實現(xiàn)了 IViewContent接ロ的類對象來管理，如某個· Cs文件視圖由TextEditorDisplayBindingWrapper來管理和操作，在打開Cs文件時，系統(tǒng)將新建一個TextEditorDisplayBindingWrapper對象，該對象由Defaultfforkbench的文檔視圖容器管通。雖然SharpDevelop是ー個極優(yōu)秀的開源軟件，但是在解決文檔管理、模塊間通信和視圖管理難題上還有一點瑕疵，具體如下一、在文檔管理上存在以下問題I、采用扁平化管理文檔，固然有ー些優(yōu)點，但是對具體類的依賴太大，不容易抽象出統(tǒng)ー的文檔接ロ，可擴展性差；比如在上例中，某軟件的根節(jié)點不是Solution而是其他的，那么就需要大量的改動軟件；
2、沒有將文檔管理和文檔數(shù)據(jù)(如名字、描述信息)分離，違背軟件的単一職責(zé)原則(SRP)；3、對于有層級關(guān)系的數(shù)據(jù)(如工程中有文件夾，文件夾中又有文件夾)，無法在數(shù)據(jù)結(jié)構(gòu)中體現(xiàn)出來；4、此扁平化管理不便于文件在加載時拆分和保存時合并；5、樹形結(jié)構(gòu)局部遍歷時效率較低。ニ、在模塊間通信方面存在如下問題 插件間的模塊通信，不是將消息分類而是直接通過接ロ調(diào)用，不滿足軟件的開放-封閉性原則(OCP)。三、在文檔視圖管理方面存在如下問題I、視圖分為兩類，由統(tǒng)一的平臺(DefaultWorkbench)管理,難以擴展面板和文檔視圖之外的特殊視圖，不滿足開放-封閉性原則(OCP)；2、框架和文檔的粘合在一起，不易于軟件維護和擴展。

發(fā)明內(nèi)容
在現(xiàn)有技術(shù)的基礎(chǔ)上，本發(fā)明需要解決如下三個問題I、文檔管理由文檔管理模塊的主要數(shù)據(jù)，插件間數(shù)據(jù)管理即文檔間數(shù)據(jù)管理，包括文檔組織結(jié)構(gòu)、生命和遍歷等，在軟件復(fù)用的工作方式下如何更好的管理文檔是軟件設(shè)計中必須解決的難題。2、模塊間通信在通常的基于插件式設(shè)計、MVC架構(gòu)的軟件中，需要通信的有視圖與模型層、模型層之間及模型層與控制層之間。一個優(yōu)秀的軟件，應(yīng)滿足軟件遵循開放——封閉原則(OCP)，因此，在建立一種方案來完成插件間的數(shù)據(jù)通信時，通信雙方應(yīng)不依賴具體類(或者對象)。3、文檔視圖管理交互軟件中有文檔視圖，包括單文檔多視圖和多文檔多視圖。在功能上，視圖將文檔數(shù)據(jù)顯示出來，通過操作視圖來完成文檔數(shù)據(jù)的更新，因此，在基于上文描述的技術(shù)背景中，軟件設(shè)計者應(yīng)提供ー套管理視圖的技術(shù)方案，包括視圖的組織結(jié)構(gòu)、生命和遍歷等。針對上述問題本方案提供ー種利用各插件中模型層的數(shù)據(jù)組成文檔樹，以樹形結(jié)構(gòu)來管理文檔的內(nèi)容，來克服上述問題，具體方案如下一種基于文檔樹和消息泵的插件式軟件設(shè)計方法，按功能將軟件拆分成多個插件和內(nèi)核，ー個插件對應(yīng)著ー個或多個功能模塊，每個插件分為模型層、視圖層和控制層，其特征在于，將所有插件中模型層里的數(shù)據(jù)和文檔抽取出來構(gòu)成ー個樹形結(jié)構(gòu)的管理文檔，其中步驟I、將構(gòu)成文檔樹根節(jié)點的文檔所對應(yīng)的插件作為主插件；步驟2、由掛接在根節(jié)點文檔下的文檔所對應(yīng)的插件為非主插件，并形成根節(jié)點的子節(jié)點，其中子節(jié)點包括受根節(jié)點管理的子節(jié)點及受其自身管理的下一級子節(jié)點。為方便掛接子節(jié)點所述管理文檔建立一套主插件和非主插件的掛接標準，此文檔樹內(nèi)的所有文檔都遵循此掛接標準。為擴展方便所述子節(jié)點是根據(jù)管理關(guān)系而掛接在受其管理的節(jié)點下，此時上一級的管理節(jié)點成為其父節(jié)點。
為方便雙方消息傳遞兩個相互連接的父節(jié)點和子節(jié)點之間通過相互注冊事件建立雙向鏈接。為提高管理效效率在加載文件時，管理文檔對有實體文件的文檔直接解析并根據(jù)文件信息創(chuàng)建文檔，對沒有獨立實體文件的文檔，其信息在對應(yīng)XML格式文件的ー個節(jié)點上，在保存模型數(shù)據(jù)時，對有實體文件的文檔，直接保存為XML格式的文件，對沒有實體文件的文檔，將此文件實例成ー個XML格式的節(jié)點，由其父節(jié)點接管此XML格式的節(jié)點并保存。為使消息傳遞到每個節(jié)點在文檔樹中包括兩個由消息鏈組成的消息泵，一個消息泵為自上而下，此時由發(fā)生事件改變的節(jié)點作為消息泵的消息源，接到事件消息后，由此節(jié)點開始一直將事件消息向下發(fā)送到所有的子節(jié)點；另ー個消息泵為自下而上，此時管理文檔的某個子節(jié)點接到事件消息后，即向其父節(jié)點發(fā)送該事件消息，直到發(fā)送到根節(jié)點為止，根節(jié)點對此事件消息進行處理后，再將此事件消息發(fā)送給掛接在其下的每個子節(jié)點。為方便各層之間管理數(shù)據(jù)根據(jù)軟件中每類文檔所對應(yīng)的框架，相應(yīng)的文檔樹中 每個文檔也都對應(yīng)此框架，框架用于文檔管理和視圖管理，框架對象在組件加載時由組件創(chuàng)建，框架創(chuàng)建視圖對象和回收視圖對象。本發(fā)明通過抽象類Document (即姆個文檔的基類)和DocumentFolder建立文檔樹形的管理文檔，在文檔樹內(nèi)按功能模塊而不是實體文件來劃分文檔類，簡化保存和加載插件時對文件的拆分和合并，在建立文檔樹時通過父子節(jié)點間相互訂閱事件的方式來建立消息鏈，此方式隔離了模塊間的直接通信，而是將消息進行分類，消息的發(fā)送方和接收方僅知道消息類別而不用知道消息雙方的具體類。加快和簡化了模塊間通信的速度，提高了系統(tǒng)的擴展性和可維護性。在插件視圖管理方面，采用框架容器統(tǒng)ー管理視圖，插件在被加載時再注冊框架對象和文檔類型，在插件內(nèi)部形成框架視圖和文檔一一對應(yīng)的關(guān)系。本方法使得新插件的文檔數(shù)據(jù)只要派生于同一基類，那么就可以將此文檔連接到文檔樹上，極易于軟件功能擴展。建立統(tǒng)ー的插件視圖管理容器，又有可擴充的插件框架，極易于開發(fā)人員對插件視圖的功能擴展，滿足開放-封閉性原則(OCP)，而且框架和文檔的分離，也便于軟件維護和擴展。將文檔管理和插件數(shù)據(jù)(如名字、描述信息)分離，滿足了軟件的單ー職責(zé)原則(SRP)，便于實體文件在加載時拆分及拆分后保存時的合并，按功能模塊劃分文件樹，使得樹形結(jié)構(gòu)遍歷簡便。


圖I現(xiàn)有技術(shù)中三級扁平化文檔管理結(jié)構(gòu)示意圖。圖2現(xiàn)有技術(shù)中文檔管理的類關(guān)系圖。圖3本發(fā)明的文檔樹結(jié)構(gòu)示意圖。圖4圖3文檔樹結(jié)構(gòu)下的實例。圖5消息鏈自上而下傳送示意圖。圖6消息鏈自下而上傳送示意圖。圖7文檔視圖管理結(jié)構(gòu)示意圖。
具體實施例方式根據(jù)本發(fā)明公開的方法建立的是ー個交互式軟件，采用內(nèi)核-插件式開發(fā)技木，基于MVC(模型、視圖和控制)的軟件體系結(jié)構(gòu)，創(chuàng)新的運用了文檔樹、消息泵和框架管理等技術(shù)，解決了文檔管理、模塊間通信和視圖管理的設(shè)計難題。本方案將軟件按照功能模塊拆分成多個插件，每個插件劃分為模型層、視圖層、控制層，在通常情況下，一個插件包括一個或者多個子功能模塊，將各個子功能模塊的數(shù)據(jù)管理部分抽取出來，作為該插件的管理文檔。本發(fā)明以文檔樹的方式處理管理文檔中的內(nèi)容，將軟件中各個插件的子功能模塊的數(shù)據(jù)管理部分抽取出來，作為該功能模塊被管理文檔管理的依據(jù)，管理文檔采用XML文件格式保存每個插件的數(shù)據(jù)，其中管理文檔的具體結(jié)構(gòu)如下首先按功能將軟件拆分成多個插件和內(nèi)核，一個插件對應(yīng)著一個或多個功能模塊，每個插件分為模型層、視圖層和控制 層，將所有插件中模型層里的數(shù)據(jù)和文檔抽取出來構(gòu)成ー個管理文檔，此管理文檔為樹形 結(jié)構(gòu)的文檔樹，其中將構(gòu)成文檔樹根節(jié)點的文檔所對應(yīng)的插件作為主插件，由掛接在根節(jié)點文檔下的文檔所對應(yīng)的插件為非主插件，并形成根節(jié)點的子節(jié)點，其中子節(jié)點包括受根節(jié)點管理的子節(jié)點及受其自身管理的下一級子節(jié)點。如圖3、4所示，建立文檔樹結(jié)構(gòu)，其中主插件的文檔為樹的根節(jié)點，非主插件通過向管理文檔中的管理它的對象(相當于父節(jié)點)注冊，將文檔掛接到管理對象文檔上形成其子節(jié)點，如project由solution管理，那么project文檔掛接到solution文檔上，此管理對象成為該文檔的父節(jié)點，父節(jié)點和子節(jié)點之間通過相互注冊事件的方式，在文檔樹的對象間建立“雙向消息鏈”，按此方式組織和管理各個插件中的數(shù)據(jù)模型。本方案利用文檔樹來管理文檔，這棵樹可以沿葉子節(jié)點方向無限擴展，樹的根節(jié)點可以由開發(fā)人員自己定義(只要派生于同一基類即可)，不僅如此，本發(fā)明將模型層中的數(shù)據(jù)抽象出來，作為樹的葉子節(jié)點，由文檔values鏈表管理，以免和模型層中的文檔管理混淆。結(jié)合圖3的文檔樹，下面結(jié)合圖4給出ー個實例，假設(shè)管理文檔的根節(jié)點為Solution, Solution管理著多個Project,姆個Project又管理多個Folder和cs文件,而Folder 又管理多個 cs 文件。圖 4 中省略了 Values、DocumentFolders 和 Documents。如圖4所示，本方案將文檔的基類設(shè)定為Document類，其中SolutionDoc、ProjectDoc 和 TextEditorDoc 類均派生于 Document 類，Solution、Pro ject 和 TextEditor均實現(xiàn)了 IModel接ロ。本方案采用面向?qū)ο蠓椒ǎ瑢④浖兴胁寮奈臋n抽象于ー個文檔基類(Document),基類(Document)提供添加子文檔和文件夾、刪除子文檔和文件夾等的方法，在子文檔和文件夾被操作的同時，父子文檔(或者文件夾)之間將自動注冊事件，建立起“雙向消息鏈”。文件拆分和合并方面，本方案并不是所有的文檔對都維護ー個獨立的實體文件，那么對于沒有實體文件的對象，文檔將維護ー個XML節(jié)點，在保存模型層中的數(shù)據(jù)時，文檔向父節(jié)點提供ー個XML節(jié)點對象(XMLNode)，在加載模型層的數(shù)據(jù)時，父節(jié)點將為它提供ー個XML節(jié)點對象。具體文檔樹的建立方式如下由于采用了樹形結(jié)構(gòu)<Project id=”0” oid count^O1' defauitConfiguration^'O1^
<roots>
〈Folder id=”0” extensions="redace” name=1'Model Files”〉
<eiements>
<FileRefid='OM persi stAs=(!ABC.REDACE" />
</elemeiits>
</Folder>
</roots>
</Projeci>此時約定節(jié)點關(guān)鍵字Folder為Folder文檔(管理文件夾數(shù)據(jù)的文檔)，此實體文件對應(yīng)的文檔是project文件,那么project文檔在加載數(shù)據(jù)時,將創(chuàng)建Folder文檔，并將xml中Folder節(jié)點的子節(jié)點信息(如elements)和屬性信息(如id、extensions)賦值到Folder文檔中。本方案中文件的拆分和合并極其簡便。對于派生于Document類而沒有實體文件的文檔，它在加載和保存時維護ー個XML節(jié)點對象(XMLNode)，在保存吋，將它的信息生成ー個XML對象，并提交各父節(jié)點，在加載數(shù)據(jù)吋，由父節(jié)點給它賦值ー個XML節(jié)點對象(XMLNode)，此節(jié)點將解析XML節(jié)點對象(XMLNode)。本方案通過消息泵處理模型層間通信?；贛VC的技術(shù)中，不管是通過視圖層或者控制層來改變模型層，還是模型層自身發(fā)生改變，最終都是模型層發(fā)生變更，再由模型層通知視圖層，刷新視圖，文檔是模型層的主要載體，因此，只要解決了文檔樹間的通信，那么模型層間通信就迎刃而解。文檔樹有兩個消息泵，即自上到下和自下到上。兩種方式都由消息鏈組成，消息鏈是建立在文檔樹的基礎(chǔ)上，在往某節(jié)點對象(Document或者DocumentFolder)添加子節(jié)點時,兩節(jié)點將相互訂閱事件(Event),形成雙向消息鏈。如圖5所示，自上到下，文檔樹的根節(jié)點是泵的消息源，事件觸發(fā)是泵的動力，一直沿子節(jié)點方向廣播發(fā)送。不妨以“保存事件”為例說明。文檔樹根節(jié)點將捕獲到的“保存事件”發(fā)給所有的子節(jié)點，子節(jié)點收到事件消息后，不僅保存自己數(shù)據(jù)，還將消息發(fā)送給它的子節(jié)點，此消息一直到子節(jié)點的終點才停止發(fā)送。其中Doc、Docs、Folder 和 Folders 分別為 Document、Documents、DocumentFolder和 DocumentFolders 的縮寫。如圖6所示，自下到上，文檔樹的某節(jié)點(不一定是葉子節(jié)點)是泵的消息源，事件觸發(fā)是泵的動力，一直沿父節(jié)點方向發(fā)送。不妨以“屬性修改事件”為例說明。如某個對象模型捕獲到“屬性修改事件”，那么它將向父節(jié)點發(fā)送該消息，父節(jié)點再向自己的父節(jié)點發(fā)送該消息，最終文檔樹的根節(jié)點將接收到此消息，根節(jié)點處理完消息后，再將此事件消息發(fā)送給每個插件的框架對象，框架對象將此消息發(fā)送給各自的視圖對象，視圖對象根據(jù)需要處理消息。如圖7所示，本方案的文檔視圖管理是，每個文檔都分別對應(yīng)ー個框架，由框架管理文檔和視圖，其中框架對象在插件被加載時即創(chuàng)建，在打開文檔時，使用者將找到文檔對應(yīng)的框架，由框架創(chuàng)建視圖對象，顯示文檔內(nèi)容，在關(guān)閉文檔時，也由框架回收此視圖對象。在插件被加載時，插件為每種視圖創(chuàng)建ー個框架對象，并將框架對象與文檔類型注冊到文檔視圖管理容器中。在用戶點擊打開某個實體文件C時，那么點擊事件將從文檔視圖容器中查找文檔，C對應(yīng)的框架C，再由框架C 去創(chuàng)建和管理文檔C對應(yīng)的視圖C，并顯示視圖C。文檔管理器適合于各類文檔視圖，易于擴展。
權(quán)利要求
1.一種基于文檔樹和消息泵的插件式軟件設(shè)計方法，按功能將軟件拆分成多個插件和內(nèi)核，一個插件對應(yīng)著一個或多個功能模塊，每個插件分為模型層、視圖層和控制層，其特征在于，將所有插件中模型層里的數(shù)據(jù)和文檔抽取出來構(gòu)成ー個管理文檔，此管理文檔為樹形結(jié)構(gòu)的文檔樹，其中 步驟I、將構(gòu)成文檔樹根節(jié)點的文檔所對應(yīng)的插件作為主插件； 步驟2、由掛接在根節(jié)點文檔下的文檔所對應(yīng)的插件為非主插件，并形成根節(jié)點的子節(jié)點，其中子節(jié)點包括受根節(jié)點管理的子節(jié)點及受其自身管理的下一級子節(jié)點。
2.如權(quán)利要求I所述的ー種基于文檔樹和消息泵的插件式軟件設(shè)計方法，其特征在干，所述管理文檔建立一套主插件和非主插件的掛接標準，此文檔樹內(nèi)的所有文檔都遵循此掛接標準。
3.如權(quán)利要求I所述的ー種基于文檔樹和消息泵的插件式軟件設(shè)計方法，其特征在于，所述子節(jié)點是根據(jù)管理關(guān)系而掛接在受其管理的節(jié)點下，此時上ー級的管理節(jié)點成為其父節(jié)點。
4.如權(quán)利要求3所述的ー種基于文檔樹和消息泵的插件式軟件設(shè)計方法，其特征在于，兩個相互連接的父節(jié)點和子節(jié)點之間通過相互注冊事件建立雙向鏈接。
5.如權(quán)利要求I所述的ー種基于文檔樹和消息泵的插件式軟件設(shè)計方法，其特征在于，在加載文件時，管理文檔對有實體文件的文檔直接解析并根據(jù)文件信息創(chuàng)建文檔，對沒有獨立實體文件的文檔，其信息在對應(yīng)XML格式文件的一個節(jié)點上，在保存模型數(shù)據(jù)時，對有實體文件的文檔，直接保存為XML格式的文件，對沒有實體文件的文檔，將此文件實例成ー個XML格式的節(jié)點，由其父節(jié)點接管此XML格式的節(jié)點并保存。
6.如權(quán)利要求I所述的ー種基于文檔樹和消息泵的插件式軟件設(shè)計方法，其特征在于，在文檔樹中包括兩個由消息鏈組成的消息泵，ー個消息泵為自上而下，此時由發(fā)生事件改變的節(jié)點作為消息泵的消息源，接到事件消息后，由此節(jié)點開始一直將事件消息向下發(fā)送到所有的子節(jié)點；另ー個消息泵為自下而上，此時文檔樹的某個子節(jié)點接到事件消息后，即向其父節(jié)點發(fā)送該事件消息，直到發(fā)送到根節(jié)點為止，根節(jié)點對此事件消息進行處理后，再將此事件消息發(fā)送給掛接在其下的每個子節(jié)點。
7.如權(quán)利要求I所述的ー種基于文檔樹和消息泵的插件式軟件設(shè)計方法，其特征在于，根據(jù)軟件中每類文檔所對應(yīng)的框架，相應(yīng)的文檔樹中每個文檔也都對應(yīng)此框架，框架用于文檔管理和視圖管理，框架對象在組件加載時由組件創(chuàng)建，框架創(chuàng)建視圖對象和回收視圖對象。
全文摘要
本發(fā)明公開一種基于文檔樹和消息泵的插件式軟件設(shè)計方法，按功能將軟件拆分成多個插件，一個插件對應(yīng)著一個或多個功能模塊，每個插件分為模型層、視圖層和控制層，將所有插件中模型層里的數(shù)據(jù)和文檔抽取出來構(gòu)成一個樹形結(jié)構(gòu)的管理文檔。本方案加快和簡化了模塊間通信的速度，提高了系統(tǒng)的擴展性和可維護性。在插件視圖管理方面，采用框架容器統(tǒng)一管理視圖，本方法使得新插件的文檔數(shù)據(jù)只要派生于同一基類，那么就可以將此文檔連接到文檔樹上，極易于軟件功能擴展。
文檔編號G06F9/44GK102722368SQ20121015895
公開日2012年10月10日 申請日期2012年5月21日 優(yōu)先權(quán)日2012年5月21日
發(fā)明者余佳, 冀建偉, 張保乾, 張智慧, 張 浩, 王建忠, 齊敏 申請人:中國廣東核電集團有限公司, 北京廣利核系統(tǒng)工程有限公司