【正文】 表現(xiàn)層設(shè)計的架構(gòu)模式以及多頁面實現(xiàn)所采用的模式兩個方面分別來闡述。 MVC架構(gòu)模式 表現(xiàn)層界面的架構(gòu)主要采用當今世界主流的GUI設(shè)計模式：MVC（ModelViewController）模式，即模型視圖控制器模式來實現(xiàn)。在本基站管理配置系統(tǒng)的多個配置向?qū)е?，在許多不同的頁面對象中，存在著一些共同的數(shù)據(jù)，組件等。所以使用MVC模式將會是一個非常有效的策略。 MVC結(jié)構(gòu)圖模型端：提供一些功能性接口，也是一系列公開的方法，通過這些公開方法，便可以取得模型端的所有功能。在這些公開的方法中，有一些是取值方法，讓系統(tǒng)其它部分可以得到模型端的內(nèi)部狀態(tài)參數(shù)，其它一些改值方法則允許外部修改模型端的內(nèi)部狀態(tài)。這其中最重要的，必須有一個方法登記視圖，以便在模型端的內(nèi)部狀態(tài)發(fā)生變化時，可以通知視圖端，這里采用觀察者模式，加上監(jiān)聽器，以提供登記和通知視圖所需接口。在本系統(tǒng)中的模型端遵循如下原則： 1. 每一個配置向?qū)Ф加幸粋€模型類，用來存儲所有的配置改動 2. 如果配置向?qū)е型救∠瑒tRbs基站上不需要任何改動。多個視圖端：使用MVC模式可以允許多個視圖端存在，并且可以在需要的時候動態(tài)的登記上所需要的視圖，這正是該層使用MVC模式的主要原因。在每個視圖里面，由于視圖可以嵌套，所以可以采用合成模式來管理界面上的控件。在多個視圖里面，可以抽象出每個視圖的共同部分，將其提到父類中，并且采用適配器模式來適配父類，簡化設(shè)計。在本系統(tǒng)中，視圖端由一個view類實現(xiàn)，主要負責： 1. 處理所有的GUI組件 2. 向用戶提供真實的接口，在本系統(tǒng)中由控制器類調(diào)用。多控制器端：MVC模式的視圖端是與MVC模式的控制器端結(jié)合使用的，該端也采用適配器模式。當用戶端與相應的視圖發(fā)生交互時，用戶可以通過視窗更新模型的狀態(tài)，而這種更新是通過控制器端進行的?？刂破鞫送ㄟ^調(diào)用模型端的改值方法更新其狀態(tài)值。與此同時，控制器端會通知所有的登記了的視圖刷新顯示給出用戶的表示。這意味著在視圖端對象和控制器端對象之間會有觀察者模式的應用，并且通常視圖跟控制器是成對出現(xiàn)的。在本系統(tǒng)中，控制器端由一個controller類實現(xiàn)，主要負責： 1. 創(chuàng)建當前基站，當前頁面所實際需要的GUI。 2. 創(chuàng)建基本的GUI組件，比如標題等。 3. 負責控制展示當前所需要的的GUI組件。 多頁面配置向?qū)У膶崿F(xiàn)多頁面配置向?qū)У膶崿F(xiàn)所采用的策略有：適配器模式+依賴倒轉(zhuǎn)原則。下面分別來介紹這兩個模式，同時具體分析在該層中采用的原因。適配器（Adapter）模式：把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不同不匹配而無法在一起工作的兩個類能夠在一起工作。在以下各種情況下使用適配器模式： 1. 系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。 2. 想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進的類的一些工作。這些源類不一定要有很復雜的接口。 本基站管理配置系統(tǒng)使用的是類的適配器模式，： 適配器模式本系統(tǒng)中由于有4個配置向?qū)В恳粋€配置向?qū)Ф夹枰芏嗯渲庙撁?，這些頁面各不相同，卻有部分的數(shù)據(jù)以及組件完全一樣，所以可以將面板的繪制，標題的繪制等相同的組件抽象出來，放到父類中去實現(xiàn)。而眾多的頁面，每個頁面所需要的組件，GUI的繪制也各不相同，可以在每一個頁面的繪制的時候，分別使用類的適配器模式，來適配抽象父類。如上圖所示，AbstractView類為一個提取了公共部分的抽象父類，本模式就是使用類的適配器來適配這個類，在viewer類中提供各自view類繪圖所需要的特有的接口，同時viewer類中的接口提供給各自的控制器controller類來調(diào)用。View類負責實現(xiàn)viewer接口中的方法[31]。依賴倒轉(zhuǎn)原則，Dependence Inversion Principle（DIP）：要依賴于抽象，不要依賴于具體，要針對接口編程，不針對實現(xiàn)編程。即針對抽象編程的原則。一個具體Java類只實現(xiàn)Java接口和抽象Java類中申明過的方法，而不應當給出多余的方法。在本基站管理配置系統(tǒng)中，從視圖端以及控制器端抽象出共同部分，抽象到他們的父類AbstractView ，AbstractController中，使用抽象類來實現(xiàn)MVC架構(gòu)的重要的宏觀邏輯，各頁面的子類僅僅通過適配器模式僅僅來滿足本頁面繪制的繪制需求，并不參與高層抽象類的邏輯。這樣的架構(gòu)同時滿足了開閉原則。整體上，界面GUI部分使用了MVC架構(gòu)來實現(xiàn)，同時在抽象類中實現(xiàn)對頁面的控制等共有的邏輯，這樣的設(shè)計思想體現(xiàn)出了軟件設(shè)計模式中的里氏代換原則以及依賴倒轉(zhuǎn)原則，而子類繼承時通過適配器模式等設(shè)計方法來繪制各自頁面不同的view，對應的視圖以及控制器僅僅通過模型端進行交互，滿足迪米特法則。第3章 基站管理配置軟件系統(tǒng)的實現(xiàn)第3章 前一章系統(tǒng)的分析了產(chǎn)品的需求，詳細介紹了系統(tǒng)的架構(gòu)層次，每一層的設(shè)計思路以及實現(xiàn)策略，所采用的設(shè)計模式等。本章將結(jié)合上一章的分析，從細節(jié)上對系統(tǒng)每層的實現(xiàn)部分做詳細的描述。本章主要以類圖以及時序圖的形式，按照系統(tǒng)架構(gòu)從底層往上依次闡述每一層的具體實現(xiàn)方式，并加以必要的解釋說明[32]。 POJO數(shù)據(jù)層的實現(xiàn)該層的實現(xiàn)相對比較簡單，主要依賴于系統(tǒng)高層定義的MO信息，本層建立MO與類的一一對應關(guān)系即可。在每一個類中僅有g(shù)et/set方法用來存儲取值，并沒有多余的邏輯，這也是POJO類的特色。： Slot類的UML圖從上圖中可以看出，slot這個MO的每一個屬性都對應該類的一個屬性，reservedBy這個屬性比較特殊，是MO系統(tǒng)本身的內(nèi)在屬性，不會改變，也不用給用戶配置，在這個MO類中將其值以硬編碼的方式存儲起來即可，所以不需要set方法，只有g(shù)et方法。其他的屬性都可以改變，所以都有g(shù)et/set方法。其他類的實現(xiàn)都跟這個類相似，就不一一舉例了。 物理數(shù)據(jù)層的實現(xiàn)本層主要負責實現(xiàn)兩個部分，MO樹的建立跟物理數(shù)據(jù)的實現(xiàn)。下面從這兩個方面來描述。 MO樹的建立由第二章設(shè)計時候的分析可知，建立MO樹的時候主要用到Node類，MONode類，MOProxyNode類這三個類。： 建立MO樹類的UML圖建立MO樹的時候需要用到這三個類，由上可以看出這三個類的主要功能分別是：Node類主要負責提供建立樹結(jié)構(gòu)的基本方法，如setDepth，setParent，appendChild這3個方法。MONode類跟MOProxyNode都繼承自Node類，分別進行了擴展。MONode類提供了加鎖，刪除相關(guān)的方法，一個MO從樹上刪除的時候，必須先加鎖才能刪除，同時還要將相關(guān)的子節(jié)點同時進行加鎖跟刪除的動作，由getDeletedObjectInOrder跟getLockableObjectsInOrder這兩個方法來實現(xiàn)。MOProxyNode類主要用來提供從MO樹上取相對應的MO的方法，如調(diào)用getMO（String）方法，通過MO的LDN入?yún)ⅲ瑏慝@取這個MO。 物理數(shù)據(jù)的實現(xiàn)物理數(shù)據(jù)層主要是將零散的MO數(shù)據(jù)進行組合，同時以與真實硬件一一對應的關(guān)系向上層提供具有實際意義的數(shù)據(jù)模型。 聚集模式的UML圖 RemoteRadioUnit類在該圖中處于核心位置，這個類對應于真實的物理硬件遠程射頻單元，包括了這個硬件所有需要配置的參數(shù)的數(shù)據(jù)。這個類以聚集的形式持有POJO層中五個相關(guān)的數(shù)據(jù)類，該類包含一系列的set/get方法，當對這個類進行配置的時候[33]，就可以調(diào)用該類所持有的相對應的MO實例中的set方法進行配置，間接配置了POJO類。： 創(chuàng)建物理數(shù)據(jù)的時序圖從邏輯實現(xiàn)層的RemoteManager類發(fā)來create消息，觸發(fā)本層中的RemoteRadioUnit類創(chuàng)建相應的數(shù)據(jù)。RemoteRadioUnit類會根據(jù)需要分別來創(chuàng)建實例，最后check方法來檢查創(chuàng)建過程是否出錯，創(chuàng)建成功后返回OK。 邏輯實現(xiàn)層的實現(xiàn)該層主要是一些單一的邏輯，相當于功能模塊層中一些配置行為實現(xiàn)的原材料，這些原材料在功能模塊層調(diào)用，來建造具有配置意義的邏輯實現(xiàn)。下圖以RadioUnitManager為例，展示了本層的實現(xiàn)過程： 邏輯實現(xiàn)層的享元模式實現(xiàn)的UML圖ManagerFactory類中g(shù)etManagerInstance方法提供RadioUnitManager類的一個實例。RadioUnitManager類中consistencyCheck方法用來做創(chuàng)建前的檢查，create方法可以將外蘊享元的形式傳進來。RemoteRUManager扮演了外蘊享元的角色，這里進行RemoteRadioUnit類中數(shù)據(jù)的創(chuàng)建以及配置等功能。RUData類扮演了內(nèi)蘊享元的角色，該類中存了跟這個硬件配置相關(guān)的一些不變量，這些變量不需要用戶配置，但是在創(chuàng)建過程中需要用來進行邏輯判斷，控制創(chuàng)建過程[35]。 功能模塊層的實現(xiàn)本段主要介紹兩個子模塊的實現(xiàn)過程，Rbs類的實現(xiàn)以及功能模塊類的實現(xiàn)，同時在最后總結(jié)了邏輯實現(xiàn)層跟功能模塊層這兩層之間的關(guān)系。下面從這三方面分別闡述實現(xiàn)過程。 Rbs類的實現(xiàn)Rbs類的實現(xiàn)主要需要實現(xiàn)兩個部分，Rbs類的創(chuàng)建過程，Rbs類的內(nèi)部具體構(gòu)建。： 實現(xiàn)Rbs類的UML圖抽象工廠類的創(chuàng)建方法返回AbstractRbs類，具體工廠的建造方法可以通過調(diào)用具體Rbs類的getInstance方法來創(chuàng)建Rbs對象。如果有新加Rbs基站，則只需要創(chuàng)建一對具體工廠、具體Rbs基站類即可，抽象工廠、抽象基站類并不需要改變。根據(jù)需求，工廠類跟抽象工廠類兩者可以合并，將工廠方法退化成簡單工廠方法。在產(chǎn)品端，對工廠方法稍做修改，AbstractRbs不再是抽象類，子類的實例化需要父類的幫助。這樣既可以滿足工廠方法的開閉原則，又可以實現(xiàn)單例模式。 ： Rbs類的UML圖AbstractRbs類以聚集的方式持有AbstractCabinet類、AbstractSite類、AbstractModify類、AbstractDelete類這四個類，這四個類分別向Rbs提供機箱機柜配置，基站站點配置服務(wù)，修改服務(wù)，刪除服務(wù)的功能，而他們分別以建造模式構(gòu)建自己部分的服務(wù)。 功能模塊類的實現(xiàn)本系統(tǒng)主要提供機箱機柜配置功能，基站站點配置功能，修改功能，刪除功能這四個功能模塊。下面將以機箱機柜配置服務(wù)配置類跟基站站點服務(wù)配置類為例展示構(gòu)建過程。： 機箱機柜功能配置類的UML圖AbstractCabinet類是一個抽象接口，用來提供構(gòu)建機箱機柜服務(wù)功能所需要的創(chuàng)建方法，CabinetBuilder類繼承自AbstractCabinet類，實現(xiàn)了這些創(chuàng)建方法，同時有ConfigManager方法來負責零件類的創(chuàng)建過程。CabinetBuilder類以合成關(guān)系持有CabEquipment類，PowerSupply類，ClimateSystem類，ETM類這四個類，這四個類相當于機箱機柜類創(chuàng)建過程中的零件。創(chuàng)建完成以后，返回產(chǎn)品類，本例中產(chǎn)品類是CabinetConfig類扮演，configManager方法負責創(chuàng)建過程中的細節(jié)邏輯的控制。： 基站站點功能配置類的UML圖可以看出該子模塊的構(gòu)建跟機箱機柜配置服務(wù)子模塊的構(gòu)建很類似。AbstractSite類是一個抽象接口，用來提供基站站點服務(wù)功能所需奧的創(chuàng)建方法，SiteBuilder類繼承該類，用來實現(xiàn)本子模塊服務(wù)功能的具體創(chuàng)建過程。SiteBuilder類以合成的關(guān)系持有SiteLocation類、SectorCapability類、SectorEquipment類、Hsdpa類這四個類，這四個類是基站站點類的零件類。configManager方法負責創(chuàng)建過程中的細節(jié)邏輯的控制。 邏輯實現(xiàn)層跟功能模塊層的關(guān)系 這兩層邏輯層之間并不是孤立的，他們之間的調(diào)用關(guān)系主要采用代理模式的思想實現(xiàn)，這兩層之間的調(diào)用關(guān)系在本系統(tǒng)中的應用的UML類圖如下所示： 代理模式實現(xiàn)的UML圖 Rbs類收到用戶頁面的配置請求，有一個configRequest方法需要從功能服務(wù)層中調(diào)用一個配置，功能服務(wù)層中的config方法在收到Rbs的請求以后，向真實主題邏輯控制層調(diào)用config方法，在那里實現(xiàn)配置。這樣通過委托調(diào)用就可以將這兩層控制層串聯(lián)起來。 以代理模式的思想為核心，這兩層之間的交互的實現(xiàn)流程步驟描述如圖： 邏輯控制層的時序圖 Rbs類發(fā)送configRequset請求到功能模塊層的FunctionController類，F(xiàn)unctionController類在創(chuàng)建之前會調(diào)用preCheck方法做一個提前檢查，然后再發(fā)送config請求到邏輯實現(xiàn)層的LogicController類，LogicController類創(chuàng)建完成以后返回消息給FunctionController類，F(xiàn)unctionController類還需要調(diào)用postCheck方法來做一個檢查，再返回消息給Rbs類。這樣這兩層就聯(lián)系起來了。同時由于在使用代理模式的思想的時候可以有一個preCheck以及PostCheck的過程，所以更加有利于產(chǎn)品的正確創(chuàng)建。 表現(xiàn)層的實現(xiàn)表現(xiàn)層的實現(xiàn)是基于MVC的架構(gòu)，同時有適配器等設(shè)計模式的應用以及針對抽象編程等思想的體現(xiàn)。因為是一個配置軟件，界面部分是主要部分，該部分的設(shè)計好壞直接影響用戶體現(xiàn)，所以必須要設(shè)計的周詳，實現(xiàn)的巧妙，因此本小節(jié)從如下四個部分來相信介紹表現(xiàn)層的實現(xiàn)過程：本系統(tǒng)跟OSSRC高層的交互以及啟動過程，表現(xiàn)層抽象類的關(guān)系以及實現(xiàn)過程，MVC的在本系統(tǒng)中的具體應用，同時因為用XML腳本配置基站需要在界面部分輸入XML文件，因此解析XML文件的SAX技術(shù)的實現(xiàn)過程也在此部分介紹。 本系統(tǒng)與OSSRC的關(guān)系以及系統(tǒng)啟動本系統(tǒng)是UTRAN系統(tǒng)中寄宿于OSSRC的一個具有基站管理配置功能的軟件，因此需要實現(xiàn)OSSRC中提供的接口以供OSSRC調(diào)用，即可以啟動本系統(tǒng)，使用