【正文】 因?yàn)槭且粋€(gè)配置軟件，界面部分是主要部分，該部分的設(shè)計(jì)好壞直接影響用戶體現(xiàn)，所以必須要設(shè)計(jì)的周詳，實(shí)現(xiàn)的巧妙，因此本小節(jié)從如下四個(gè)部分來相信介紹表現(xiàn)層的實(shí)現(xiàn)過程：本系統(tǒng)跟OSSRC高層的交互以及啟動(dòng)過程，表現(xiàn)層抽象類的關(guān)系以及實(shí)現(xiàn)過程，MVC的在本系統(tǒng)中的具體應(yīng)用，同時(shí)因?yàn)橛肵ML腳本配置基站需要在界面部分輸入XML文件，因此解析XML文件的SAX技術(shù)的實(shí)現(xiàn)過程也在此部分介紹。同時(shí)由于在使用代理模式的思想的時(shí)候可以有一個(gè)preCheck以及PostCheck的過程，所以更加有利于產(chǎn)品的正確創(chuàng)建。 以代理模式的思想為核心，這兩層之間的交互的實(shí)現(xiàn)流程步驟描述如圖： 邏輯控制層的時(shí)序圖 Rbs類發(fā)送configRequset請(qǐng)求到功能模塊層的FunctionController類，F(xiàn)unctionController類在創(chuàng)建之前會(huì)調(diào)用preCheck方法做一個(gè)提前檢查，然后再發(fā)送config請(qǐng)求到邏輯實(shí)現(xiàn)層的LogicController類，LogicController類創(chuàng)建完成以后返回消息給FunctionController類，F(xiàn)unctionController類還需要調(diào)用postCheck方法來做一個(gè)檢查，再返回消息給Rbs類。 邏輯實(shí)現(xiàn)層跟功能模塊層的關(guān)系 這兩層邏輯層之間并不是孤立的，他們之間的調(diào)用關(guān)系主要采用代理模式的思想實(shí)現(xiàn)，這兩層之間的調(diào)用關(guān)系在本系統(tǒng)中的應(yīng)用的UML類圖如下所示： 代理模式實(shí)現(xiàn)的UML圖 Rbs類收到用戶頁面的配置請(qǐng)求，有一個(gè)configRequest方法需要從功能服務(wù)層中調(diào)用一個(gè)配置，功能服務(wù)層中的config方法在收到Rbs的請(qǐng)求以后，向真實(shí)主題邏輯控制層調(diào)用config方法，在那里實(shí)現(xiàn)配置。SiteBuilder類以合成的關(guān)系持有SiteLocation類、SectorCapability類、SectorEquipment類、Hsdpa類這四個(gè)類，這四個(gè)類是基站站點(diǎn)類的零件類。： 基站站點(diǎn)功能配置類的UML圖可以看出該子模塊的構(gòu)建跟機(jī)箱機(jī)柜配置服務(wù)子模塊的構(gòu)建很類似。CabinetBuilder類以合成關(guān)系持有CabEquipment類，PowerSupply類，ClimateSystem類，ETM類這四個(gè)類，這四個(gè)類相當(dāng)于機(jī)箱機(jī)柜類創(chuàng)建過程中的零件。下面將以機(jī)箱機(jī)柜配置服務(wù)配置類跟基站站點(diǎn)服務(wù)配置類為例展示構(gòu)建過程。 ： Rbs類的UML圖AbstractRbs類以聚集的方式持有AbstractCabinet類、AbstractSite類、AbstractModify類、AbstractDelete類這四個(gè)類，這四個(gè)類分別向Rbs提供機(jī)箱機(jī)柜配置，基站站點(diǎn)配置服務(wù)，修改服務(wù)，刪除服務(wù)的功能，而他們分別以建造模式構(gòu)建自己部分的服務(wù)。在產(chǎn)品端，對(duì)工廠方法稍做修改，AbstractRbs不再是抽象類，子類的實(shí)例化需要父類的幫助。如果有新加Rbs基站，則只需要?jiǎng)?chuàng)建一對(duì)具體工廠、具體Rbs基站類即可，抽象工廠、抽象基站類并不需要改變。 Rbs類的實(shí)現(xiàn)Rbs類的實(shí)現(xiàn)主要需要實(shí)現(xiàn)兩個(gè)部分，Rbs類的創(chuàng)建過程，Rbs類的內(nèi)部具體構(gòu)建。 功能模塊層的實(shí)現(xiàn)本段主要介紹兩個(gè)子模塊的實(shí)現(xiàn)過程，Rbs類的實(shí)現(xiàn)以及功能模塊類的實(shí)現(xiàn)，同時(shí)在最后總結(jié)了邏輯實(shí)現(xiàn)層跟功能模塊層這兩層之間的關(guān)系。RemoteRUManager扮演了外蘊(yùn)享元的角色，這里進(jìn)行RemoteRadioUnit類中數(shù)據(jù)的創(chuàng)建以及配置等功能。下圖以RadioUnitManager為例，展示了本層的實(shí)現(xiàn)過程： 邏輯實(shí)現(xiàn)層的享元模式實(shí)現(xiàn)的UML圖ManagerFactory類中g(shù)etManagerInstance方法提供RadioUnitManager類的一個(gè)實(shí)例。RemoteRadioUnit類會(huì)根據(jù)需要分別來創(chuàng)建實(shí)例，最后check方法來檢查創(chuàng)建過程是否出錯(cuò)，創(chuàng)建成功后返回OK。這個(gè)類以聚集的形式持有POJO層中五個(gè)相關(guān)的數(shù)據(jù)類，該類包含一系列的set/get方法，當(dāng)對(duì)這個(gè)類進(jìn)行配置的時(shí)候[33]，就可以調(diào)用該類所持有的相對(duì)應(yīng)的MO實(shí)例中的set方法進(jìn)行配置，間接配置了POJO類。 物理數(shù)據(jù)的實(shí)現(xiàn)物理數(shù)據(jù)層主要是將零散的MO數(shù)據(jù)進(jìn)行組合，同時(shí)以與真實(shí)硬件一一對(duì)應(yīng)的關(guān)系向上層提供具有實(shí)際意義的數(shù)據(jù)模型。MONode類提供了加鎖，刪除相關(guān)的方法，一個(gè)MO從樹上刪除的時(shí)候，必須先加鎖才能刪除，同時(shí)還要將相關(guān)的子節(jié)點(diǎn)同時(shí)進(jìn)行加鎖跟刪除的動(dòng)作，由getDeletedObjectInOrder跟getLockableObjectsInOrder這兩個(gè)方法來實(shí)現(xiàn)。： 建立MO樹類的UML圖建立MO樹的時(shí)候需要用到這三個(gè)類，由上可以看出這三個(gè)類的主要功能分別是：Node類主要負(fù)責(zé)提供建立樹結(jié)構(gòu)的基本方法，如setDepth，setParent，appendChild這3個(gè)方法。下面從這兩個(gè)方面來描述。其他類的實(shí)現(xiàn)都跟這個(gè)類相似，就不一一舉例了。： Slot類的UML圖從上圖中可以看出，slot這個(gè)MO的每一個(gè)屬性都對(duì)應(yīng)該類的一個(gè)屬性，reservedBy這個(gè)屬性比較特殊，是MO系統(tǒng)本身的內(nèi)在屬性，不會(huì)改變，也不用給用戶配置，在這個(gè)MO類中將其值以硬編碼的方式存儲(chǔ)起來即可，所以不需要set方法，只有g(shù)et方法。 POJO數(shù)據(jù)層的實(shí)現(xiàn)該層的實(shí)現(xiàn)相對(duì)比較簡單，主要依賴于系統(tǒng)高層定義的MO信息，本層建立MO與類的一一對(duì)應(yīng)關(guān)系即可。本章將結(jié)合上一章的分析，從細(xì)節(jié)上對(duì)系統(tǒng)每層的實(shí)現(xiàn)部分做詳細(xì)的描述。整體上，界面GUI部分使用了MVC架構(gòu)來實(shí)現(xiàn)，同時(shí)在抽象類中實(shí)現(xiàn)對(duì)頁面的控制等共有的邏輯，這樣的設(shè)計(jì)思想體現(xiàn)出了軟件設(shè)計(jì)模式中的里氏代換原則以及依賴倒轉(zhuǎn)原則，而子類繼承時(shí)通過適配器模式等設(shè)計(jì)方法來繪制各自頁面不同的view，對(duì)應(yīng)的視圖以及控制器僅僅通過模型端進(jìn)行交互，滿足迪米特法則。在本基站管理配置系統(tǒng)中，從視圖端以及控制器端抽象出共同部分，抽象到他們的父類AbstractView ，AbstractController中，使用抽象類來實(shí)現(xiàn)MVC架構(gòu)的重要的宏觀邏輯，各頁面的子類僅僅通過適配器模式僅僅來滿足本頁面繪制的繪制需求，并不參與高層抽象類的邏輯。即針對(duì)抽象編程的原則。View類負(fù)責(zé)實(shí)現(xiàn)viewer接口中的方法[31]。而眾多的頁面，每個(gè)頁面所需要的組件，GUI的繪制也各不相同，可以在每一個(gè)頁面的繪制的時(shí)候，分別使用類的適配器模式，來適配抽象父類。這些源類不一定要有很復(fù)雜的接口。在以下各種情況下使用適配器模式： 1. 系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。下面分別來介紹這兩個(gè)模式，同時(shí)具體分析在該層中采用的原因。 3. 負(fù)責(zé)控制展示當(dāng)前所需要的的GUI組件。在本系統(tǒng)中，控制器端由一個(gè)controller類實(shí)現(xiàn)，主要負(fù)責(zé)： 1. 創(chuàng)建當(dāng)前基站，當(dāng)前頁面所實(shí)際需要的GUI。與此同時(shí)，控制器端會(huì)通知所有的登記了的視圖刷新顯示給出用戶的表示。當(dāng)用戶端與相應(yīng)的視圖發(fā)生交互時(shí)，用戶可以通過視窗更新模型的狀態(tài)，而這種更新是通過控制器端進(jìn)行的。在本系統(tǒng)中，視圖端由一個(gè)view類實(shí)現(xiàn)，主要負(fù)責(zé)： 1. 處理所有的GUI組件 2. 向用戶提供真實(shí)的接口，在本系統(tǒng)中由控制器類調(diào)用。在每個(gè)視圖里面，由于視圖可以嵌套，所以可以采用合成模式來管理界面上的控件。在本系統(tǒng)中的模型端遵循如下原則： 1. 每一個(gè)配置向?qū)Ф加幸粋€(gè)模型類，用來存儲(chǔ)所有的配置改動(dòng) 2. 如果配置向?qū)е型救∠?，則Rbs基站上不需要任何改動(dòng)。在這些公開的方法中，有一些是取值方法，讓系統(tǒng)其它部分可以得到模型端的內(nèi)部狀態(tài)參數(shù)，其它一些改值方法則允許外部修改模型端的內(nèi)部狀態(tài)。所以使用MVC模式將會(huì)是一個(gè)非常有效的策略。 MVC架構(gòu)模式 表現(xiàn)層界面的架構(gòu)主要采用當(dāng)今世界主流的GUI設(shè)計(jì)模式：MVC（ModelViewController）模式，即模型視圖控制器模式來實(shí)現(xiàn)。前兩個(gè)配置向?qū)Р粌H僅有XML配置文件一鍵式配置，還可以圖形化界面分步配置，而后兩個(gè)配置向?qū)H僅提供XML腳本文件配置功能。 表現(xiàn)層的設(shè)計(jì)本小節(jié)主要介紹了表現(xiàn)層設(shè)計(jì)時(shí)候所用到的一些設(shè)計(jì)模式，由于界面設(shè)計(jì)的技術(shù)已經(jīng)發(fā)展的比較成熟，所以本文采用的技術(shù)也是當(dāng)今世界上比較主流的技術(shù)，比如MVC模式以及適配器模式。 邏輯控制層的總結(jié)邏輯控制層在整個(gè)基站管理配置軟件中處于核心位置，由于業(yè)務(wù)行為是經(jīng)常變化的，如果僅僅將業(yè)務(wù)行為的處理都放在一層中實(shí)現(xiàn)，系統(tǒng)的邏輯將會(huì)十分龐大而復(fù)雜，而且會(huì)隨著需求的變化，在反復(fù)修改之后變的越來越難以維護(hù)，因此可以將業(yè)務(wù)行為分解成兩層來實(shí)現(xiàn)。所以本系統(tǒng)可以提供多少功能給用戶，Rbs類中就應(yīng)該包含代理這些功能的類的實(shí)例。子類Rbs6601W中，則是一個(gè)靜態(tài)工廠方法來getInstance創(chuàng)建自己的實(shí)例，這樣就滿足了單例模式，同時(shí)克服了單例模式不能繼承的缺點(diǎn)。在getInstance方法中調(diào)用的時(shí)候，通過查看register變量的鍵與值來實(shí)現(xiàn)單例模式，如果值為空，則去創(chuàng)建該基站類型的單例類，如果值不為空，則直接返回該單例類。 }}由于本段只需要關(guān)心Rbs基站的創(chuàng)建，所以以上代碼只有創(chuàng)建部分，并不包含其他功能實(shí)現(xiàn)的代碼。 }}在子類Rbs6601W中：public class Rbs6601W extends AbstractRbs{ public static final String Rbs6601= Rbs6601W。 (Error happened when create Rbs!)。 } if((name) == null) { try{ (name, (name).newInstance())。 } protected AbstractRbs() {} static public AbstractRbs getInstance(String name) { if(name == null) { (No Rbs Type to create!)。 static { AbstractRbs aRbs = new AbstractRbs()。登記式單例模式：餓漢式單例類跟懶漢式單例類均不可繼承，因此本文的基站管理配置系統(tǒng)使用登記式單例模式，子類允許父類以構(gòu)造子調(diào)用產(chǎn)生實(shí)例，由父類實(shí)例化并登記。單例模式有以下的特點(diǎn)：1. 單例類只能有一個(gè)實(shí)例。單例模式：是對(duì)象的創(chuàng)建模式，單例模式確保某一個(gè)類只有一個(gè)實(shí)例，而且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例。每一個(gè)Rbs基站對(duì)應(yīng)一個(gè)Java類，所有的類都繼承自共有的父類AbstractRbs，目前支持的Rbs都包括在內(nèi)。 ： Rbs類的軟件代碼架構(gòu) Rbs類是一個(gè)接口類，用來提供外部接口，提供一些必要的方法給其他模塊調(diào)用，這個(gè)類并不屬于工廠方法模式的一部分，主要是用來提供接口通信，滿足接口隔離原則。 無線通信基站的發(fā)展日新月異，各大公司紛紛順應(yīng)時(shí)代，不斷推出具有新功能的新型基站，基站型號(hào)雖然會(huì)有經(jīng)常增加的特點(diǎn)，但是與原有基站在配置上有許多類似之處，所以本文所要實(shí)現(xiàn)的基站管理配置系統(tǒng)，為了滿足需求經(jīng)常變動(dòng)這個(gè)條件，在Rbs基站的創(chuàng)建的時(shí)候，必須采用一種滿足開閉原則的設(shè)計(jì)模式，在添加新的Rbs基站類的時(shí)候，才能做到盡量小的修改，滿足設(shè)計(jì)的初衷，所以采用工廠方法模式來設(shè)計(jì)Rbs基站，是一個(gè)很好的選擇。同時(shí)由于使用了多態(tài)性，工廠方法模式保持了簡單工廠模式的優(yōu)點(diǎn)，同時(shí)克服了它的缺點(diǎn)。工廠方法模式的用意是定義一個(gè)創(chuàng)建產(chǎn)品對(duì)象的工廠接口，將實(shí)際創(chuàng)建工作推遲到子類中進(jìn)行，從而在核心的工廠類不在負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，而具體的創(chuàng)建工作則由子類負(fù)責(zé)。 Rbs基站類的設(shè)計(jì)思路 本小節(jié)將從Rbs基站類的創(chuàng)建以及Rbs基站類的構(gòu)成兩個(gè)方面來闡述Rbs基站類的的設(shè)計(jì)思路： Rbs基站類的創(chuàng)建策略：工廠方法模式+登記式單例模式。建造模式將產(chǎn)品的結(jié)構(gòu)和產(chǎn)品的零件建造過程隱藏了起來，把對(duì)建造過程進(jìn)行指揮的責(zé)任和具體建造者零件的責(zé)任分割開來，這樣的設(shè)計(jì)體現(xiàn)出了責(zé)任的分工以及產(chǎn)品的封裝性。這樣就可以通過建造模式，將配置該功能服務(wù)類轉(zhuǎn)化為配置該對(duì)象的零件類的過程，而配置該對(duì)象的零件類的過程就可以交付給下層，邏輯控制層來實(shí)現(xiàn)，本層并不需要關(guān)心具體配置細(xì)節(jié)。，功能模塊層所需要提供的功能服務(wù)，可以以一個(gè)類來表示，配置這種功能服務(wù)，相當(dāng)于配置此類的對(duì)象實(shí)例。在本系統(tǒng)中，很多硬件的配置具備一定的依賴性，比如基站站點(diǎn)site的配置中，塔放TMA只有在特定的基站中才可以配置，必需先配置扇區(qū)，才能配置載波的頻點(diǎn)等配置。在某個(gè)性質(zhì)沒有賦值之前，另一個(gè)性質(zhì)無法賦值。比如站點(diǎn)site的配置服務(wù)類，需要配置射頻單元，天線系統(tǒng)等對(duì)象，才能作為一個(gè)完整的服務(wù)來提供給用戶，配置到一半的時(shí)候，基站站點(diǎn)的功能無法實(shí)現(xiàn)。使用建造模式可以在不需要知道所要構(gòu)建的的復(fù)雜產(chǎn)品對(duì)象有哪些零件，每個(gè)產(chǎn)品對(duì)象對(duì)應(yīng)的零件對(duì)象有何區(qū)別，是如何建造出來的，以及怎樣組件產(chǎn)品的情況下，進(jìn)行構(gòu)建，建造模式有很好的封裝性，這樣的特性非常適合在復(fù)雜架構(gòu)中使用。一個(gè)復(fù)雜的產(chǎn)品對(duì)象常常會(huì)由不同的零件對(duì)象構(gòu)成，這些零件對(duì)象可以叫做產(chǎn)品的內(nèi)部表象。： 建造模式在這里Rbs類扮演了客戶端的角色，通過調(diào)用建造Builder接口類的retrieveResult方法可以得到目標(biāo)功能，而這個(gè)功能的構(gòu)架過程對(duì)Rbs類是透明的。建造模式是對(duì)象的創(chuàng)建模式。刪除則是刪除當(dāng)前Rbs配置的數(shù)據(jù)信息。 4. 導(dǎo)出刪除export/delete服務(wù)：該部分功能服務(wù)相對(duì)比較簡單，分2部分。他們都可以修改的配置有：扇區(qū)的承載能力，扇區(qū)的數(shù)據(jù)，其中扇區(qū)的承載能力中可以配置扇區(qū)的小區(qū)。修改天線功能中可以修改的配置有：天線分支部分的修改，饋線電纜的修改，塔放TMA的修改，電子傾角調(diào)整期RET的修改。這個(gè)模塊最大的好處即是可以在不重新啟動(dòng)基站的情況下，針對(duì)基站周圍小區(qū)的情況相應(yīng)的調(diào)整基站的配置。 （2） 如果機(jī)箱機(jī)柜服務(wù)沒有配置，則需要首先配置機(jī)箱機(jī)柜cabine