【文章內(nèi)容簡介】 的值是用來組成RDN的。slotNumber該屬性的值從左往右開始數(shù)起，從1開始，用來表示插槽位置的。slotState屬性用來表明該插槽的狀態(tài)。該MO的是在其父親MO的創(chuàng)建的時候創(chuàng)建的，并且不能被刪除。該MO插槽的數(shù)目是在其父親節(jié)點(diǎn)subrack中定義的。 MO的查找：RDN與LDN RDN：Relative Distinguished Name，相對標(biāo)識名。RDN的命名跟該MO的父親節(jié)點(diǎn)相關(guān)。這個屬性的值在他被建立的時候就定義好了，并且不能改變。 LDN：Local Distinguished Name，本地專有名稱。由該Rbs節(jié)點(diǎn)中一系列的RDN所形成的一個獨(dú)一無二的名字。 RDN在查找父子節(jié)點(diǎn)的MO時候使用，LDN在全局查找MO的使用。 ，由下可以看出RDN跟LDN如何命名，以及LDN是如何由RDN所形成的： 一個使用RND/LDN的MO結(jié)構(gòu)由上圖可以看出RncFunction這個MO的RDN={RncFunctionId=0}，由于RncFunction本身就是根節(jié)點(diǎn)，所以LDN等于RDN。UtranCell這個MO的RDN={UtranCellId=100}，LDN等于該MO的RDN加上這個MO所有父節(jié)點(diǎn)的RDN，所以UtranCell的LDN={RncFunctionId=0，UtranCellId=100}，同理，Rach這個MO的RDN={RachId=0}，LDN={RncFunctionId=0，UtranCellId=100，RachId=0}。表中的MO的RDN命名規(guī)則：從機(jī)框最左邊的插槽開始，第一個插槽slot為：slot=1。因此該MO的RDN={SlotId=1}。 MO的映射機(jī)制 MO的映射機(jī)制采用POJO模式策略。從高層系統(tǒng)規(guī)定定義的MO到該軟件配置管理系統(tǒng)的數(shù)據(jù)庫所采用的映射技術(shù)由POJO模式實(shí)現(xiàn)。POJO：Plain Old Java Object，簡單Java對象。POJO是一個簡單的普通的Java對象，它不包含業(yè)務(wù)邏輯或者持久化邏輯等，沒有從任何類繼承，不擔(dān)當(dāng)任何特殊的角色，也沒有實(shí)現(xiàn)任何接口，更沒有被其他框架侵入的Java對象。每一個MO由一個POJO來負(fù)責(zé)實(shí)現(xiàn)，由一個具體的Java類來代表一個MO，Java中的字段設(shè)置成私有的，分別表示MO中的attribute跟action。一系列的get/set方法來負(fù)責(zé)數(shù)據(jù)的讀寫。 物理數(shù)據(jù)層的設(shè)計(jì) POJO層對應(yīng)的數(shù)據(jù)庫數(shù)據(jù)，MO數(shù)據(jù)，僅僅只是系統(tǒng)高層對Rbs資源的一個邏輯抽象，并不完全對應(yīng)具體硬件。整個UTRAN系統(tǒng)中，各個子系統(tǒng)之間的通信，是需要MO來傳遞數(shù)據(jù)的，而我們對Rbs的配置，實(shí)際上僅僅是對具體的一個類型的Rbs的具體硬件的配置，這兩者之間有一些區(qū)別。所以需要有一層數(shù)據(jù)層，來實(shí)現(xiàn)邏輯數(shù)據(jù)MO跟具體硬件的參數(shù)配置的映射關(guān)系。以下將從MO樹的建立，物理數(shù)據(jù)的建立和物理數(shù)據(jù)的實(shí)現(xiàn)策略三個方面具體闡述該層主要的設(shè)計(jì)步驟。 MO樹的建立由于在POJO層使用了POJO數(shù)據(jù)，所以僅僅只有g(shù)et/set方法，并沒有任何關(guān)系，也沒有任何邏輯，需要在這一層給MO數(shù)據(jù)建立關(guān)系。這樣不僅可以實(shí)現(xiàn)各個MO之間的的先后順序，父子關(guān)系，依賴關(guān)系等邏輯，同時還可以使得邏輯控制層對MO數(shù)據(jù)的管理、使用更加方便。： MO結(jié)構(gòu)樹以系統(tǒng)高層定義的MO樹為基礎(chǔ)，： MO結(jié)構(gòu)示意圖所有的MO都有一個共同的根節(jié)點(diǎn)Root Node，由上圖信息可知，樹的根節(jié)點(diǎn)為ManagedElement這個對象，在這之下依次掛著各個MO。建立MO樹的規(guī)則是根據(jù)系統(tǒng)對MO結(jié)構(gòu)圖的定義以及MO定義的信息表中可能的父類，可能的子類的信息來建立的：在本基站管理軟件系統(tǒng)的Java類中，用3個類來實(shí)現(xiàn)MO樹的創(chuàng)建，： MO樹的代碼結(jié)構(gòu)Node類提供建立樹的一些最基本的方法，如getDepth、getChild、getParent方法等。MONode類繼承了Node類，在此基礎(chǔ)上擴(kuò)展了一些方法，提供關(guān)于MO屬性的一些操作，比如lockable，deletable方法。MOProxyNode類同樣繼承自Node類，這個類跟MoNode不同，擴(kuò)展的方法主要是用來獲取這個類，以及獲取相關(guān)的MO。 物理數(shù)據(jù)的建立這一層的主要目的就是：建立一個對應(yīng)具體類型的Rbs，具體硬件的配置的數(shù)據(jù)層。這一層主要是將抽象管理對象MO的數(shù)據(jù)與具體硬件配置的數(shù)據(jù)聯(lián)系起來，基站軟件管理配置系統(tǒng)從用戶的角度來看，僅僅是對具體硬件進(jìn)行配置，而并不是對抽象的MO的配置，所以需要一層數(shù)據(jù)層，來進(jìn)行抽象數(shù)據(jù)與具體數(shù)據(jù)的轉(zhuǎn)換。下面以射頻單元硬件為例。： 愛立信遠(yuǎn)程射頻單元的硬件實(shí)例 從圖中可以看出，這個遠(yuǎn)程射頻單元已經(jīng)進(jìn)行了很好的封裝，其實(shí)內(nèi)部集成了上行信號處理板，下行信號處理板，空口等硬件，該硬件的外部則有連接基帶信號處理板的接口以及連接天線的接口等，這些硬件的具體分配資源不需要本系統(tǒng)進(jìn)行深入配置，在下層子系統(tǒng)會有針對細(xì)節(jié)的配置，但是遠(yuǎn)程射頻單元的型號，上下行信號處理板、空口等硬件的數(shù)目，外部接口的連接信息，是否發(fā)射分級，是否串聯(lián)等信息，這些配置信息都是需要在配置這個遠(yuǎn)程射頻單元的時候同時配置的。而在系統(tǒng)高層定義的MO里面并沒有一個具體的MO與該硬件對應(yīng)，統(tǒng)一歸類為AuxPlugInUnit這個MO，僅僅通過auType這個屬性來區(qū)分具體的類型。MO的定義高度抽象化，不會涉及細(xì)節(jié)，或者具體硬件。： AuxPlugInUnit信息表ActionsreadRepairDelivNote()reconfigureProgramPrepare()restartAuxUnit()AttributesadministrativeStatealramStatusauTypeAuxPlugInUnitIdpiuTypeproductNumberreservedByserialNumberuniqueHwIdunitType由上表可以看出，這個MO跟實(shí)際硬件之間并不完全匹配，比如與外部其他硬件的接口連線部分，沒有任何屬性可以用來保存與基帶信號處理板的連接配置或者與天線單元的連接配置，而保存這個連接配置信息的屬性卻屬于另一個MO，DigitalCable中。根據(jù)具體產(chǎn)品信息，： 遠(yuǎn)程射頻單元硬件使用的MO實(shí)際硬件抽象MO遠(yuǎn)程射頻單元DigitalCableAuxPlugInUnitSectorAntennaAntennaBranchAntFeederCable 于是我們可以使用合成/聚合復(fù)用原則，建立一個Java類，其中包含了屬于這個硬件的所有MO的一個聚集，這樣可以通過配置這個類來配置這個硬件，同時間接配置了相關(guān)的MO。 該層具有十分重要的意義，是將抽象管理對象MO與具體硬件實(shí)例緊密聯(lián)系起來的橋梁?；拒浖芾砼渲孟到y(tǒng)僅僅是對具體硬件進(jìn)行配置，而并不是對抽象的MO的配置。在這一層可以進(jìn)行數(shù)據(jù)的轉(zhuǎn)換，轉(zhuǎn)換成UTRAN中通用的MO數(shù)據(jù)，這樣就可以供其他子系統(tǒng)使用。這一層起到承上啟下的作用。 物理數(shù)據(jù)的實(shí)現(xiàn)策略 本層物理數(shù)據(jù)的實(shí)現(xiàn)策略主要采用合成/聚合復(fù)用原則以及合成模式這兩個策略。下面分別具體闡述這兩種策略以及在本系統(tǒng)中采用的原因：合成/聚合復(fù)用原則：又叫做合成復(fù)用原則（CRP），指在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新對象通過向這些對象的委派達(dá)到復(fù)用已有功能的目的。使用合成/聚合復(fù)用原則的原因有：1． 新對象存取成分對象的唯一方法是通過成分對象的接口。本層的數(shù)據(jù)給下層MO數(shù)據(jù)層賦值只會調(diào)用POJO類中的set方法。2． 這種復(fù)用支持包裝。3． 這種復(fù)用所需的依賴較少。不同于繼承的實(shí)現(xiàn)，這樣實(shí)現(xiàn)的耦合度極低，有助于數(shù)據(jù)的靈活組合，利于架構(gòu)的解耦。一旦有新硬件或者硬件的改動，改變起來比較方便。4． 每一個新類可以將重點(diǎn)集中在一個任務(wù)上。本層物理數(shù)據(jù)層每一個類的主要任務(wù)就是將MO層的POJO類進(jìn)行集成，以匹配真實(shí)物理硬件。 合成模式：屬于對象的結(jié)構(gòu)模式，有時候又叫做“部分整體”模式。合成模式將對象組織到樹結(jié)構(gòu)中，可以用來描述整體與部分的關(guān)系。這樣設(shè)計(jì)使得我們可以找到一種無需一對多的關(guān)系即可獲得一對多的行為的替代方式。使用合成模式的主要原因有：1． 有一些物理硬件可以做進(jìn)一步的集成，集成化是未來無線基站硬件的趨勢，在該層就進(jìn)行必要的數(shù)據(jù)集成，可以很好的滿足將來的需求變化。2． 在一些集成了的硬件板的處理上，上層邏輯層不直接調(diào)用不直接配置的數(shù)據(jù)類，而是通過調(diào)用實(shí)際配置的數(shù)據(jù)類來進(jìn)行委派。這樣可以增加代碼的復(fù)用性。3． 在物理數(shù)據(jù)層就對數(shù)據(jù)進(jìn)行必要的集成，當(dāng)對集成硬件進(jìn)行數(shù)據(jù)配置的時候，可以通過父類進(jìn)行數(shù)據(jù)的遍歷，而不并每一次都去遍歷所有的子類，這樣可以減少數(shù)據(jù)配置中的錯誤。 合成模式的UML結(jié)構(gòu)圖[18]： 合成模式 該圖是合成模式中樹結(jié)構(gòu)的一個靜態(tài)結(jié)構(gòu)。最上方出現(xiàn)的父類節(jié)點(diǎn)，左下方是一個樹葉節(jié)點(diǎn)，右下方是一個樹枝節(jié)點(diǎn)，可以含有其他節(jié)點(diǎn)，如果沒有其他節(jié)點(diǎn)，則也退化成樹葉節(jié)點(diǎn)。由于本層數(shù)據(jù)層的設(shè)計(jì)只是聚集下層POJO層中的MO數(shù)據(jù)，使之與實(shí)際物理硬件對應(yīng)，所以本系統(tǒng)只需要使用二層樹結(jié)構(gòu)的合成模式即可，即父節(jié)點(diǎn)作為物理數(shù)據(jù)層中的數(shù)據(jù)類使用，子節(jié)點(diǎn)取自下層POJO數(shù)據(jù)層。本層的客戶端是上層的邏輯控制層[19]。在本層物理數(shù)據(jù)層架構(gòu)的搭建的時候，使用合成模式的思想，但是并不完全依照合成模式來構(gòu)建，因?yàn)楸鞠到y(tǒng)設(shè)計(jì)的一個主要目的就是給原來的系統(tǒng)解耦合，盡量做到低耦合，而且這兩層數(shù)據(jù)之間并沒有強(qiáng)耦合關(guān)系，所以不需要繼承的方式來實(shí)現(xiàn)，而是將下層數(shù)據(jù)層中的類以合成/聚集的方式使用。以上文中出現(xiàn)的遠(yuǎn)程射頻單元為例，依據(jù)合成模式的思想，： 遠(yuǎn)程射頻單元的聚集模式 在該圖中，處于父節(jié)點(diǎn)位置的就是本層需要設(shè)計(jì)的數(shù)據(jù)類，遠(yuǎn)程射頻單元類。跟合成模式不同，在這里并不使用繼承，而是使用聚集來實(shí)現(xiàn)，遠(yuǎn)程射頻單元以聚集的方式將這五個POJO類聚集到父類中，使之成為一個整體。這樣同樣可以做到在向上層提供數(shù)據(jù)服務(wù)的時候，以一個整體的行為，以一對一的關(guān)系來進(jìn)行交互，而不是傳統(tǒng)一對多的方式。這樣在邏輯控制層中，可以通過僅僅調(diào)用這一個數(shù)據(jù)類，就可以達(dá)到同時調(diào)用這5個MO類的數(shù)據(jù)的功能。 邏輯實(shí)現(xiàn)層的設(shè)計(jì)本節(jié)主要介紹了該層的實(shí)現(xiàn)策略，同時結(jié)合本層的主要功能需求，詳細(xì)分析了采用享元模式的原因。本層只負(fù)責(zé)簡單單一的行為邏輯，即每一個類只負(fù)責(zé)一種邏輯，邏輯的組合則交給上層[20][21]。 邏輯實(shí)現(xiàn)層的實(shí)現(xiàn)策略：享元模式。享元模式是對象的結(jié)構(gòu)模式。享元模式以共享的方式高效的支持大量的細(xì)粒度對象。享元對象區(qū)分內(nèi)蘊(yùn)狀態(tài)和外蘊(yùn)狀態(tài)。一個內(nèi)蘊(yùn)狀態(tài)是存儲在享元對象內(nèi)部的，并且是不會隨著環(huán)境改變而有所不同的。因此一個享元可以具有內(nèi)蘊(yùn)狀態(tài)并且內(nèi)蘊(yùn)狀態(tài)可以共享。一個外蘊(yùn)狀態(tài)是隨環(huán)境改變而改變的、不可以共享的狀態(tài)。享元對象的外蘊(yùn)狀態(tài)必須由客戶端保存，并在享元對象被創(chuàng)建之后，在需要使用的時候再傳入到享元對象內(nèi)部。外蘊(yùn)狀態(tài)不可以影響享元對象的內(nèi)蘊(yùn)狀態(tài)，他們之間是相互獨(dú)立的。 ： 享元模式 在上圖中，享原工廠負(fù)責(zé)創(chuàng)建和管理享元對象。這個角色必須保證享元對象可以被系統(tǒng)適當(dāng)?shù)毓蚕怼．?dāng)一個對象調(diào)用一個享元對象的時候，享元工廠會檢查系統(tǒng)中是否已經(jīng)有了一個符合要求的享元對象。如果已經(jīng)有了，享元工廠角色就應(yīng)當(dāng)提供這個已有的享元對象，如果系統(tǒng)中沒有一個適當(dāng)?shù)南碓獙ο蟮脑?，享元工廠角色就應(yīng)當(dāng)創(chuàng)建一個合適的享元對象。抽象享元角色是所有享元類的超類，為這些類定義出需要實(shí)現(xiàn)的公共接口，外蘊(yùn)狀態(tài)可以在該類的方法中以入?yún)⒌男问絺魅?。具體享元對象角色負(fù)責(zé)內(nèi)蘊(yùn)享元的創(chuàng)建和管理享元對象。不可共享的享元角色負(fù)責(zé)用來實(shí)現(xiàn)那些不可以共享的享元的創(chuàng)建和管理。 結(jié)合本層的功能，使用享元模式的理由： 1. 一個系統(tǒng)有大量的對象。本系統(tǒng)中，每一個MO都會對應(yīng)一個POJO，同時在物理數(shù)據(jù)層中進(jìn)一步的合成，所以會出現(xiàn)大量的數(shù)據(jù)對象。 2. 這些對象耗費(fèi)大量的內(nèi)存。一個功能服務(wù)在邏輯控制層會被分解成為很多簡單邏輯，每一個簡單邏輯都對應(yīng)配置最基本的物理硬件數(shù)據(jù)，這些物理硬件數(shù)據(jù)類通常由一些POJO類合成，所以一次配置可能會需要加載許多類，耗費(fèi)大量內(nèi)存。 3. 這些對象的狀態(tài)中的大部分都可以外部化。 4. 這些對象可以按照內(nèi)蘊(yùn)狀態(tài)分成很多的組，當(dāng)把外蘊(yùn)對象從對象中剔除時，每一組都可以僅用一個對象代替。 5. 軟件系統(tǒng)不依賴于這些對象的身份，這些對象是不可分辨的。軟件系統(tǒng)在用戶看來只需要依賴于RBS對象類，而下層是如何實(shí)現(xiàn)的是不需要知道的，而且也不需要辨認(rèn)。 6. 系統(tǒng)需要維護(hù)一個記錄了系統(tǒng)已有的所有享元的表。 功能模塊層的設(shè)計(jì) 該層是全文的核心部分，同時本軟件系統(tǒng)實(shí)際配置的Rbs類也將在本層創(chuàng)建。本小節(jié)總共分五個部分，首先介紹了本層在本系統(tǒng)中的位置以及所起的作用，其次按順序介紹每一個功能，然后介紹該層的設(shè)計(jì)原理以及設(shè)計(jì)時候所使用的設(shè)計(jì)模式，接著詳細(xì)介紹Rbs基站類的設(shè)計(jì)思路以及實(shí)現(xiàn)策略，最后對整個邏輯控制層做一個簡要總結(jié)。 本層在本系統(tǒng)中的位置以及所起的作用本文描述的基站管理軟件配置系統(tǒng)所需要提供的功能服務(wù)在本層劃分，產(chǎn)品的功能結(jié)構(gòu)圖中的功能在本層中體現(xiàn)。本系統(tǒng)通過這個功能模塊層，來定義應(yīng)用程序的邊界，類似于服務(wù)層，在功能模塊層中建立一組可用的操作集合，并在每個操作內(nèi)部協(xié)調(diào)應(yīng)用程序的響應(yīng)，在這一層，將該系統(tǒng)所能提供的服務(wù)，按照功能劃分，獨(dú)立成為各個子模塊，同時在這一層封裝了該系統(tǒng)的應(yīng)用的業(yè)務(wù)邏輯，事務(wù)控制及其操作實(shí)現(xiàn)中的響應(yīng)協(xié)調(diào)等[22]。該層同時負(fù)責(zé)Rbs的初始化創(chuàng)建等[23]。Rbs基站的設(shè)計(jì)根據(jù)需求分析，需要一個支持開閉原則的設(shè)計(jì)模式，本系統(tǒng)采用工廠方法模式進(jìn)行設(shè)計(jì)。每一個具體的Rbs對象都會持有該Rbs所支持的相應(yīng)的功能服務(wù)，如果該Rbs基站不支持的服務(wù)，則相應(yīng)的Rbs實(shí)例中不應(yīng)當(dāng)包含這類服務(wù)。 軟