通信基站運(yùn)維綜合管理系統(tǒng)V1.0設(shè)計(jì)說(shuō)明書

1、.第1章 緒論本文主要介紹通信基站運(yùn)維綜合管理系統(tǒng)V1.0的設(shè)計(jì)與實(shí)現(xiàn)。本章首先介紹本系統(tǒng)的背景知識(shí)以及研究意義；然后闡述國(guó)內(nèi)外研究以及開發(fā)的最新動(dòng)態(tài)，最后介紹本文的主要內(nèi)容以及組織結(jié)構(gòu)安排。1.1 研究背景與意義本節(jié)主要介紹本文涉及的一些無(wú)線通信知識(shí)，首先介紹與本文描述的通信基站運(yùn)維綜合管理系統(tǒng)V1.0相關(guān)的WCDMA的概念，UTRAN系統(tǒng)，RAN系統(tǒng)以及Rbs的知識(shí)，然后詳細(xì)描述本系統(tǒng)在WCDMA系統(tǒng)所處的位置和該系統(tǒng)所需要提供的功能。最后再系統(tǒng)闡述本文的研究意義。1.1.1 3G無(wú)線通信相關(guān)知識(shí)WCDMA1：Wideband Code Division Multiple Access寬帶

2、碼分多址。是一種由碼分多址（CDMA），演變而來(lái)的第三代無(wú)線通信技術(shù)。WCDMA采用直接序列擴(kuò)頻碼分多址、頻分雙工方式。WCDMA是一種由3GPP具體制定的，基于GSM MAP核心網(wǎng)，UTRAN為無(wú)線接口的第三代移動(dòng)通信系統(tǒng)。UTRAN：The UMTS Terrestrial Radio Access Network，陸地?zé)o線接入網(wǎng)。信令網(wǎng)和數(shù)據(jù)傳輸網(wǎng)在邏輯上分開2；UTRAN和CN的功能將和傳輸功能完全分開；UTRAN和CN使用的尋址方式將和傳輸功能的尋址方式無(wú)關(guān)；宏分級(jí)（FDD模式）的處理完全在UTRAN內(nèi)，RRC的連接的移動(dòng)性完全由UTRAN控制；定義UTRAN接口時(shí)候，通過(guò)接口的功能

3、的劃分應(yīng)有盡量少的可選項(xiàng)；應(yīng)基于此接口控制的實(shí)體的邏輯模型。UTRAN由一組通過(guò)Iu接口連接到核心網(wǎng)CN的無(wú)線網(wǎng)絡(luò)子系統(tǒng)RNS組成。一個(gè)RNS由一個(gè)無(wú)線網(wǎng)絡(luò)控制器（RNC）和一個(gè)或者多個(gè)節(jié)點(diǎn)（Node B）組成。Rbs通過(guò)Iub接口連接到RNC。圖1.1是UTRAN系統(tǒng)的部分平面結(jié)構(gòu)圖。從圖中可以看出：RNC主要負(fù)責(zé)跟核心網(wǎng)的交互以及與Rbs進(jìn)行交互。Rbs主要負(fù)責(zé)與RNC交互，以及用戶手機(jī)交互。從軟件架構(gòu)的角度，UTRAN主要分為以下3個(gè)邏輯節(jié)點(diǎn)：（1）RNC（Radio Network Controller）無(wú)線網(wǎng)絡(luò)控制器。RNC主要負(fù)責(zé)跟核心網(wǎng)以及Rbs進(jìn)行交互，并且負(fù)責(zé)管理無(wú)線鏈路。R

4、NC控制通過(guò)Rbs的信息量。RNC同時(shí)負(fù)責(zé)建立信道，處理與UE的連接，控制無(wú)線基站的資源的優(yōu)化。WCDMA的Rbs提供無(wú)線資源以及無(wú)線廣播，并且負(fù)責(zé)接受與發(fā)送UE信號(hào)。圖1.1UTRAN系統(tǒng)的平面結(jié)構(gòu)（2）OSS-RC (Operation Support System-Radio and Core) 運(yùn)維支撐系統(tǒng)-無(wú)線基站跟核心網(wǎng)。OSS-RC主要處理從RNC過(guò)來(lái)的操作管理任務(wù)，比如軟件的安裝與升級(jí)，RAN層的管理配置，告警處理等。（3）COMINF (Common Operate&Manage Infrastructure) 通用操作管理架構(gòu)。COMINF主要管理包括從網(wǎng)絡(luò)設(shè)備到O

5、SS-RC所需要攜帶的路由等網(wǎng)絡(luò)協(xié)議。COMINF同時(shí)提供安全性服務(wù)，客戶幫助信息，軟件管理，備份解決方案等服務(wù)。UTRAN的拓?fù)浣Y(jié)構(gòu)和關(guān)鍵節(jié)點(diǎn)的外部接口如圖1.2所示：（節(jié)點(diǎn)跟接口在下圖中僅僅是一個(gè)邏輯插圖，跟實(shí)際情況不一定完全吻合。比如Mub和Iub接口可能承載相同的媒體，W-Rbs也可能以級(jí)聯(lián)拓?fù)涞男问竭B接）Rbs3（Radio Base Station）：WCDMA中的Rbs就是UTRAN系統(tǒng)節(jié)點(diǎn)中基站的特有名稱。Node B是一個(gè)邏輯節(jié)點(diǎn)，負(fù)責(zé)發(fā)送，接收從UE過(guò)來(lái)的信道。Rbs節(jié)點(diǎn)除了處理最基本的功能以外，同時(shí)還控制與監(jiān)管天線設(shè)備。Rbs通過(guò)luant接口或者其他一些專有的規(guī)范標(biāo)準(zhǔn)來(lái)

6、控制與監(jiān)管TMA、RET等天線設(shè)備。Rbs Element Manager：基站管理軟件，并不是UTRAN系統(tǒng)中的一個(gè)獨(dú)立節(jié)點(diǎn)，但是他是Rbs系統(tǒng)的一部分，EM一般運(yùn)行在PC端口，控制了包含一系列操作管理應(yīng)用軟件的安裝。Rbs Cabinet Viewer：機(jī)箱機(jī)柜查看器，是部署在OSS-RC上的一個(gè)應(yīng)用程序，但是他仍然屬于Rbs系統(tǒng)的一部分。機(jī)箱機(jī)柜查看器提供了一個(gè)可視化視圖，并且提供了一個(gè)工具來(lái)處理由事件干擾引起的錯(cuò)誤。圖1.2UTRAN系統(tǒng)的拓?fù)浣Y(jié)構(gòu)圖1.3是Rbs所處的位置以及Rbs與其他節(jié)點(diǎn)的關(guān)系：圖1.3Rbs與RNC、OSS-RC的關(guān)系從圖上可以看出：Rbs主要通過(guò)Mub接口與O

7、SS-RC交互，通過(guò)lub接口與RNC交互，通過(guò)Uu接口與UE交互。管理軟件EM在OSS-RC節(jié)點(diǎn)上，負(fù)責(zé)管理與配置Rbs4。圖1.4是Rbs外部接口的平面圖：圖1.4 Rbs的外部接口Mub：Mub接口是由Rbs所提供的，由管理軟件EM，機(jī)箱機(jī)柜查看器，網(wǎng)絡(luò)管理系統(tǒng)等系統(tǒng)使用。Iub：連接RNC跟Rbs的相關(guān)接口。GUI：（Graphic User Interface）由管理軟件EM或者機(jī)箱機(jī)柜查看器提供，提供了一種用戶友好型的圖形化界面給基站操作人員操作和維護(hù)Rbs。VMI： （Visual and Mechanical Interface），主要提供給基站站點(diǎn)操作人員使用。VMI主要包括

8、可視化指示器（LED燈），手動(dòng)的可操作的開關(guān)/按鈕（復(fù)位鍵）和傳入的外部電源等。另外，裝配的電纜螺絲等都屬于這個(gè)接口。1.1.2 基站管理軟件功能ITU-TTMN: Telecommunications Management Network standard from theITU-T) 國(guó)際電信聯(lián)盟電信標(biāo)準(zhǔn)化部，電信管理網(wǎng)絡(luò)。由于該軟件系統(tǒng)緊緊負(fù)責(zé)基站的管理與配置，暫時(shí)不考慮traffic事件部分，僅考慮操作管理部分。TMN操作管理部分策略主要由：Ø 代理模式的使用，比如OSS-RC作為管理人，Rbs EM作為代理。Ø 使用管理對(duì)象（Managed Object，MO）模

9、型，即管理一系列抽象或者物理或者邏輯上的資源。Ø 管理信息庫(kù)（Management Information Base，MIB）的使用，即一個(gè)存儲(chǔ)了TMN中所有MO的信息庫(kù)。Ø 管理信息模型（Management Information Model，MIM）的使用，即抽象出一個(gè)面向?qū)ο蟮恼Z(yǔ)言來(lái)抽象規(guī)定MO的定義，定義MO數(shù)據(jù)的基本操作。 一個(gè)基本的邏輯架構(gòu)模型如圖1.5所示：圖1.5 TMN管理部分邏輯架構(gòu)模型本文所描述的通信基站運(yùn)維綜合管理系統(tǒng)V1.0是一個(gè)OSS-RC系統(tǒng)下的子系統(tǒng)服務(wù)，從TMN管理部分的架構(gòu)邏輯模型上來(lái)看，該系統(tǒng)處于架構(gòu)的在表現(xiàn)層。通常，配站工程師會(huì)在軟

10、件中對(duì)基站進(jìn)行配置，該軟件系統(tǒng)將用戶配置基站的數(shù)據(jù)信息收集起來(lái)，通過(guò)MO攜帶數(shù)據(jù)，通過(guò)COBRA等公共協(xié)議與指定基站進(jìn)行通信，向下層傳送管理和配置的信息，將所需配置信息發(fā)送到指定基站的中央處理單元，而在基站端，通常會(huì)有一個(gè)類似于接口的子系統(tǒng)，對(duì)發(fā)送過(guò)來(lái)的消息進(jìn)行解析并處理，并將配置信息進(jìn)行反饋。這樣就可以做到基站的安裝跟配置分開進(jìn)行，并且還可以隨時(shí)對(duì)基站進(jìn)行調(diào)控容量，監(jiān)視基站中設(shè)備的狀態(tài)等操作。基站通信結(jié)構(gòu)示意圖如圖1.6所示:圖1.6 基站通信結(jié)構(gòu)本文中通信基站運(yùn)維綜合管理系統(tǒng)V1.0主要提供以下功能：功能特點(diǎn)：1，IT資源可視化，輕松讀懂各種IT數(shù)據(jù)2，業(yè)務(wù)拓?fù)湟晥D，直觀展現(xiàn)出業(yè)務(wù)與IT的

11、關(guān)系3，IT資產(chǎn)管理與IT監(jiān)控管理、運(yùn)維流程管理等無(wú)縫集成，實(shí)現(xiàn)對(duì)以虛擬化和云計(jì)算為核心支撐的IT體系綜合管控。4，完善的IT網(wǎng)絡(luò)運(yùn)維管理體系，依托統(tǒng)一的服務(wù)支持平臺(tái)，形成自動(dòng)化、流程化的服務(wù)支持。技術(shù)特點(diǎn)：1，運(yùn)行環(huán)境安裝配置方便(.NetFramework,Asp.Net,IIS)2，技術(shù)成熟，主流技術(shù)，配套技術(shù)文檔完善，眾多開源或免費(fèi)的文檔或項(xiàng)目可供參考3，擁有眾多新技術(shù)，方便構(gòu)建企業(yè)級(jí)應(yīng)用4，開發(fā)部署工具功能強(qiáng)大5，能與Windows平臺(tái)緊密結(jié)合，最大限度利用系統(tǒng)功能1.1.3 研究意義隨著中興，華為等新興無(wú)線通信公司的崛起，無(wú)線通信行業(yè)的競(jìng)爭(zhēng)越來(lái)越激烈，各大公司紛紛推出了新產(chǎn)品，軟硬

12、件更新速度日益加快，而市場(chǎng)上也出現(xiàn)了基站類型新舊各異，功能各異的復(fù)雜情況，即使是同一站型，也會(huì)因?yàn)樾枨蟮淖儎?dòng)而導(dǎo)致硬件不同，或者設(shè)備參數(shù)不同等問題。將原有硬件進(jìn)行整合，升級(jí)改造，已經(jīng)成為了當(dāng)前3G基站發(fā)展的一個(gè)主流趨勢(shì)。這樣不僅僅可以節(jié)約成本，復(fù)用原有的硬件設(shè)備，提高利用率，同時(shí)可以在更好的兼容基站的原有設(shè)備的基礎(chǔ)上，達(dá)到硬件微小改動(dòng)，功能大大提升，基站大不一樣的特點(diǎn)。目前市場(chǎng)上的一些基站管理配置系統(tǒng)，由于需求已經(jīng)隨著市場(chǎng)的變化而發(fā)生了重大改變，從原有的固定不變，幾乎很少改動(dòng)的硬件架構(gòu)，變成當(dāng)前這種需求隨著市場(chǎng)的變化而迅速變化的情況。以市場(chǎng)為導(dǎo)向的新需求，使得軟件層次的架構(gòu)的變動(dòng)勢(shì)在必行。原有

13、的架構(gòu)層次過(guò)于簡(jiǎn)單，在新項(xiàng)目的開發(fā)中出現(xiàn)了架構(gòu)兼容性不夠，代碼耦合度過(guò)強(qiáng)等問題，導(dǎo)致系統(tǒng)難以維護(hù)，升級(jí)，一旦有新需求變化，總會(huì)進(jìn)行大幅修改，顯然已經(jīng)無(wú)法適應(yīng)產(chǎn)品的不斷更新的新要求。如何設(shè)計(jì)出一個(gè)通用的基站管理系統(tǒng)，滿足需求經(jīng)常變動(dòng)的特點(diǎn)，成為一個(gè)亟待解決的問題，也是本文的主要研究目的。1.2 國(guó)內(nèi)外研究動(dòng)向 愛立信：愛立信的基站管理系統(tǒng)采用了CI/RI（Configuration Item/ResourceItem）的架構(gòu)。將基站資源抽象為一系列Resource Item，將一組相近的資源以聚集的形式構(gòu)成Configuration Item，構(gòu)建出一個(gè)邏輯上的Rbs進(jìn)行配置。該管理系統(tǒng)使用了M

14、VC，Java Bean，SAX等技術(shù)，提供了一個(gè)用戶友好型界面，通過(guò)一個(gè)通用平臺(tái)CPP與基站端進(jìn)行通信。客戶端到基站端的通信使用了COBRA的技術(shù)處理并發(fā)。目前愛立信在市場(chǎng)上的主流基站及新硬件設(shè)備如圖1.7所示5。圖1.7愛立信主流基站及新硬件設(shè)備華為6：提供了一個(gè)基于JAVA Web的網(wǎng)頁(yè)版基站軟件管理系統(tǒng)。該管理系統(tǒng)使用了J2EE架構(gòu)，并且使用了Struts+Hibernate+Spring等比較流行的框架。圖1.8是部分華為在WCDMA市場(chǎng)上的主流基站。圖1.8 華為在WCDMA市場(chǎng)上的主流基站1.3 本文主要內(nèi)容本文一共分為五章，系統(tǒng)的介紹了通信基站運(yùn)維綜合管理系統(tǒng)V1.0的設(shè)計(jì)與實(shí)

15、現(xiàn)，下面從分章節(jié)的角度詳細(xì)闡述本文將要論述的主要內(nèi)容： 第一章：首先介紹了本系統(tǒng)所需要的無(wú)線通信的背景知識(shí)，該系統(tǒng)在UTRAN系統(tǒng)中所處的位置以及該系統(tǒng)所擔(dān)當(dāng)?shù)穆毮艿?，其次介紹了國(guó)內(nèi)外研究開發(fā)的動(dòng)態(tài)，本章最后介紹了本文的主要內(nèi)容。 第二章：主要介紹了本系統(tǒng)的需求分析以及詳細(xì)架構(gòu)設(shè)計(jì)。在需求分析中使用了ADMENS矩陣分析法。架構(gòu)設(shè)計(jì)的時(shí)候先介紹系統(tǒng)的總體架構(gòu)設(shè)計(jì)，再分層分別介紹每一層的設(shè)計(jì)。在介紹的時(shí)候不僅僅介紹了設(shè)計(jì)的思路，同時(shí)從設(shè)計(jì)模式的角度給出了實(shí)現(xiàn)策略。 第三章：根據(jù)上一章設(shè)計(jì)出的架構(gòu)，分架構(gòu)層次，依次詳細(xì)闡述了每一層的實(shí)現(xiàn)過(guò)程。實(shí)現(xiàn)過(guò)程主要以詳細(xì)的UML類圖以及時(shí)序圖為例進(jìn)行闡述，同

16、時(shí)將設(shè)計(jì)過(guò)程中用到的設(shè)計(jì)模式串聯(lián)起來(lái)。 第四章：描述了系統(tǒng)測(cè)試的主要方法，以及本系統(tǒng)測(cè)試的步驟，最后展示了部分測(cè)試用例，同時(shí)總結(jié)了測(cè)試結(jié)果。第五章：總結(jié)了本論文的主要工作，分析系統(tǒng)中一些值得改進(jìn)的地方，并且提出了后續(xù)研究的一些展望。. v.第2章 通信基站運(yùn)維綜合管理系統(tǒng)V1.0的需求分析以及設(shè)計(jì)本章詳細(xì)描述了基站管理系統(tǒng)的需求分析與架構(gòu)設(shè)計(jì)。在需求分析中應(yīng)用了ADMENS矩陣分析法進(jìn)行分析，架構(gòu)設(shè)計(jì)的時(shí)候體現(xiàn)了分層的思想，同時(shí)為了更好的局部結(jié)構(gòu)，設(shè)計(jì)模式在本系統(tǒng)中得到了充分的應(yīng)用。2.1 系統(tǒng)的需求分析通信基站運(yùn)維綜合管理系統(tǒng)V1.0提供了一個(gè)基站管理配置的平臺(tái)，針對(duì)不同種類的基站進(jìn)行配置，

17、同時(shí)提供了對(duì)基站的配置進(jìn)行修改，刪除，以及導(dǎo)入導(dǎo)出配置腳本等功能。在進(jìn)行本文的需求分析的時(shí)候會(huì)借助ADMENS矩陣進(jìn)行分析。ADMENS矩陣7（Architectural Design Method has been Extended to MethodSystem，架構(gòu)設(shè)計(jì)方法已經(jīng)擴(kuò)展到方法體系），又稱為“需求層次-需求方面矩陣”。該矩陣分析法可以幫助架構(gòu)師告別需求列表的陳舊方式，順利過(guò)渡到二維需求觀，借此避免遺漏需求、并進(jìn)一步清理需求間關(guān)系和發(fā)現(xiàn)衍生需求。ADMENS二維矩陣進(jìn)行需求分析的“四步法”主要由以下4個(gè)角度分析：需求結(jié)構(gòu)化，分析約束影響，確定關(guān)鍵質(zhì)量以及確定關(guān)鍵功能。從“需求定義

18、了直接還是間接目標(biāo)”的角度，把需求劃分為3種類型：1. 功能需求：直接體現(xiàn)出各個(gè)需求的目標(biāo)要求。2. 質(zhì)量屬性：由運(yùn)行期質(zhì)量和開發(fā)期質(zhì)量組成。3. 約束需求：由業(yè)務(wù)環(huán)境因素，使用環(huán)境因素以及技術(shù)環(huán)境因素組成。從業(yè)務(wù)級(jí)需求，用戶級(jí)需求，開發(fā)級(jí)需求三個(gè)角度對(duì)本系統(tǒng)的需求進(jìn)行具體分析，形成一個(gè)二維需求分析矩陣?？偨Y(jié)成下表：表2.1 ADMENS矩陣廣義功能質(zhì)量約束業(yè)務(wù)級(jí)需求業(yè)務(wù)目標(biāo)快、好、省技術(shù)性約束法規(guī)性約束技術(shù)趨勢(shì)競(jìng)爭(zhēng)因素與競(jìng)爭(zhēng)對(duì)手遺留系統(tǒng)集成標(biāo)準(zhǔn)性約束分批實(shí)施用戶級(jí)需求用戶需求運(yùn)行期質(zhì)量用戶群特點(diǎn)用戶水平多國(guó)語(yǔ)言開發(fā)級(jí)需求行為需求開發(fā)期質(zhì)量開發(fā)團(tuán)隊(duì)技術(shù)水平開發(fā)團(tuán)隊(duì)磨合程度開發(fā)團(tuán)隊(duì)分布情況開發(fā)團(tuán)

19、隊(duì)業(yè)務(wù)知識(shí)管理：保密要求管理：產(chǎn)品規(guī)劃安裝、維護(hù)2.1.1 業(yè)務(wù)級(jí)需求的分析本段主要依據(jù)：包含客戶或者出資者要達(dá)到的業(yè)務(wù)目標(biāo)、所需要的預(yù)期投入資金、項(xiàng)目的工期進(jìn)度要求，以及要符合哪些標(biāo)準(zhǔn)規(guī)范、對(duì)哪些遺留的系統(tǒng)進(jìn)行整合改造等約束條件，對(duì)論文中闡述的系統(tǒng)進(jìn)行業(yè)務(wù)級(jí)需求分析。下面詳細(xì)闡述本系統(tǒng)需要主要考慮的約束條件。 (1) 客戶的業(yè)務(wù)目標(biāo)以及業(yè)務(wù)愿景。1. 軟件定位：基站管理軟件2. 提供服務(wù)：提供一個(gè)通用的管理配置平臺(tái)，對(duì)同一家公司不同類型，不同硬件的基站進(jìn)行配置。 (2) 客戶的業(yè)務(wù)質(zhì)量1. 兼容新老基站。由于技術(shù)的改革，軟件必須兼容各種各樣的新老基站，在滿足新基站的配置要求的同時(shí)要做到向后兼

20、容。特別是基站硬件的更新，各大無(wú)線通信公司目前都在做整合的研發(fā)，將老基站幾塊硬件板子的功能集成到一塊硬件上的創(chuàng)新研究，軟件變更需要跟硬件的變更同步化，滿足硬件變更所帶來(lái)的配置變更。2. 易于變更配置。同一款基站，很有可能會(huì)配置不同的射頻單元，或者有扇區(qū)變動(dòng)配置的需求，需要提供一個(gè)簡(jiǎn)潔而又實(shí)用的向?qū)?lái)滿足配置的變更，同一種硬件配置也需要能夠方便的修改承載能力等，以達(dá)到資源的利用合理化。 (3) 技術(shù)標(biāo)準(zhǔn)3GPP，以及各大廠商自己制定的標(biāo)準(zhǔn)。 (4) 對(duì)哪些遺留系統(tǒng)進(jìn)行整合 基站零部件種類繁多，各種型號(hào)的基站之間硬件配置有較大區(qū)別，需要一個(gè)擴(kuò)展性很強(qiáng)的系統(tǒng)來(lái)代替原有系統(tǒng)，以便將來(lái)產(chǎn)品進(jìn)一步更新?lián)Q代

21、。2.1.2 用戶級(jí)需求的分析用戶及需求的分析主要從如下幾個(gè)角度入手：用戶需要使用系統(tǒng)來(lái)完成哪些工作，對(duì)質(zhì)量有哪些要求，用戶群及所處的使用環(huán)境方面有哪些要求等條件來(lái)進(jìn)行用戶級(jí)需求分析。下面結(jié)合本系統(tǒng)進(jìn)行分析： （1） 用戶使用系統(tǒng)完成的輔助工作 該系統(tǒng)主要的用戶人員是基站配置人員，他們使用該系統(tǒng)進(jìn)行基站的配置，修改，刪除等操作。配置向?qū)Ю锩娴呐渲庙?xiàng)有一些是有跟具體硬件相關(guān)的默認(rèn)值的，還有一些必須要用戶來(lái)配置，這些配置向?qū)О凑栈镜呐渲昧鞒谭侄鄠€(gè)頁(yè)面進(jìn)行。該基站管理軟件主要提供四個(gè)配置向?qū)Ы缑妫?. 機(jī)箱/機(jī)柜配置向?qū)В?這部分的配置的硬件設(shè)備，除了基帶信號(hào)處理板的配置，還有一些硬件板，通常在交

22、付客戶之前，在工廠就有一些燒制或者錄入的默認(rèn)配置，插入機(jī)箱機(jī)柜中，所以需要在這里一并配置。在這個(gè)配置向?qū)Ю锩嫘枰渲玫闹饕校哼x擇Rbs的類型，配置默認(rèn)的IP地址，接口板等硬件設(shè)備。2. 基站站點(diǎn)配置向?qū)?主要功能是建立扇區(qū)，配置小區(qū)，天線系統(tǒng)的相關(guān)硬件，電纜相關(guān)數(shù)據(jù)，該部分需要配置的硬件組合相對(duì)比較靈活，可以依照基站的承載能力等條件，自由組合配置。3. 修改配置向?qū)?該配置向?qū)П容^特別，該功能的實(shí)現(xiàn)需要借助XML+SAX來(lái)實(shí)現(xiàn)，所以該配置向?qū)У妮斎雰H為XML修改配置文件。該向?qū)е饕渲庙?yè)面僅僅由一個(gè)文件輸入頁(yè)面以及需要修改的目錄結(jié)果組成。4. 導(dǎo)入導(dǎo)出，刪除向?qū)?這幾個(gè)功能也都是通過(guò)XML+

23、SAX實(shí)現(xiàn)，所以該配置向?qū)?，輸?輸出僅僅為XML文件。（2） 質(zhì)量要求1. 操作方便，界面友好。2. 系統(tǒng)具有很強(qiáng)的健壯性，盡量避免系統(tǒng)崩潰。3. 能夠滿足不同的配置的情況下，仍具有較強(qiáng)的可靠性。（3） 客戶需求約束 配站工程師水平參差不齊，提供一個(gè)用戶友好型，簡(jiǎn)潔的配置界面，需要易于操作。2.1.3 開發(fā)級(jí)需求的分析本段主要依據(jù)：開發(fā)人員具體需要實(shí)現(xiàn)什么產(chǎn)品，開發(fā)維護(hù)期間對(duì)質(zhì)量有哪些考慮，開發(fā)團(tuán)隊(duì)有無(wú)影響架構(gòu)的情況等因素來(lái)進(jìn)行需求分析。下面僅考慮本系統(tǒng)開發(fā)中需要用到的約束條件： （1） 開發(fā)人員需要實(shí)現(xiàn)目標(biāo) 一個(gè)用戶友好型的通信基站運(yùn)維綜合管理系統(tǒng)V1.0。需要提供如下基本服務(wù)：1.

24、機(jī)柜機(jī)箱配置：需要實(shí)現(xiàn)機(jī)箱機(jī)柜的配置，以及出廠時(shí)安裝的其他硬件板的所有配置。機(jī)箱機(jī)柜通常會(huì)提供一系列的插槽，相關(guān)的硬件在出廠的時(shí)候分別安裝在具體的插槽中，一并交付，所以這些硬件板需要跟機(jī)柜機(jī)箱配置一同進(jìn)行配置。2. 基站配置：主要負(fù)責(zé)射頻單元硬件的配置，輔助單元（比如風(fēng)扇、電源之類）的配置，以及天線系統(tǒng)相關(guān)設(shè)備的配置，這部分的硬件大多具有可以頻繁更換的特性，所以這部分代碼結(jié)構(gòu)需要盡量松散，耦合度越低越好。3. 導(dǎo)出/刪除功能：導(dǎo)出功能可以導(dǎo)出當(dāng)前Rbs的配置XML文件，可以讓我們?cè)跍y(cè)試環(huán)境中創(chuàng)建相同的用戶配置，也可以給其他站點(diǎn)進(jìn)行相同的配置。刪除功能可以刪除當(dāng)前Rbs中所有不重要的配置，重新配

25、站的情況下可以使用。本系統(tǒng)使用SAX的技術(shù)來(lái)解析XML文件，所以在這里需要提供DTD文件規(guī)范XML文件的格式。4. 修改功能：可以提供給基站操作人員在不停止Rbs的情況下，修改基站的配置的功能。主要有射頻單元的修改，天線的修改，扇區(qū)的增加、刪除，小區(qū)的增加、刪除等等功能。 （2） 開發(fā)期間的質(zhì)量約束1. 以測(cè)試驅(qū)動(dòng)的原則進(jìn)行開發(fā)，盡量做到步步可測(cè)。2. 代碼實(shí)現(xiàn)的時(shí)候盡量多用設(shè)計(jì)模式的原則，降低代碼的耦合度，提高可擴(kuò)展性。 綜上所述，總結(jié)得到的ADMENS矩陣如下表所示：表2.2 ADMENS矩陣（需求層次-需求方面矩陣）功能質(zhì)量約束業(yè)務(wù)級(jí)需求業(yè)務(wù)目標(biāo)及業(yè)務(wù)愿景l(fā) 軟件定位：基站管理軟件l 提

26、供服務(wù)：對(duì)各種類型，各種硬件提供一個(gè)通用性的配站軟件商業(yè)質(zhì)量l 兼容新老基站配置l 容錯(cuò)率高商業(yè)約束l 基站零部件種類繁多l(xiāng) 各種型號(hào)的基站，硬件之間有較大區(qū)別l 需要較強(qiáng)的可擴(kuò)展可擴(kuò)展性，以便將來(lái)產(chǎn)品更新?lián)Q代用戶級(jí)需求潛在用戶l 配站工程師運(yùn)行期質(zhì)量l 操作簡(jiǎn)單，易于上手l 多用性用戶約束l 工程師水平層次不齊，提供一些必要提示l 防御性編程，檢測(cè)未知的配置錯(cuò)誤開發(fā)級(jí)需求開發(fā)期質(zhì)量l 可擴(kuò)展性l 步步可測(cè)開發(fā)方約束l 只有一人l 時(shí)間短工程量大2.2 基站管理軟件系統(tǒng)的架構(gòu)設(shè)計(jì)本節(jié)主要是從整體上對(duì)本通信基站運(yùn)維綜合管理系統(tǒng)V1.0的設(shè)計(jì)進(jìn)行詳細(xì)闡述。本節(jié)主要分兩個(gè)層次來(lái)闡述，先從系統(tǒng)的邏輯架

27、構(gòu)，功能模塊以及魯棒性設(shè)計(jì)三個(gè)角度來(lái)闡述該基站管理軟件系統(tǒng)的設(shè)計(jì)，然后依據(jù)本系統(tǒng)的架構(gòu)層次來(lái)具體闡述每一層的設(shè)計(jì)思路以及實(shí)現(xiàn)策略。2.2.1 系統(tǒng)總體概要設(shè)計(jì)本小節(jié)僅僅是對(duì)系統(tǒng)總體架構(gòu)概要設(shè)計(jì)的介紹，不對(duì)具體細(xì)節(jié)的設(shè)計(jì)與實(shí)現(xiàn)做分析。本節(jié)從系統(tǒng)的邏輯架構(gòu)，功能模塊以及魯棒性設(shè)計(jì)三個(gè)角度來(lái)闡述該基站管理軟件系統(tǒng)的概要設(shè)計(jì)。 系統(tǒng)的邏輯架構(gòu)基站管理軟件系統(tǒng)的邏輯架構(gòu)圖見圖2.1。該系統(tǒng)的設(shè)計(jì)思路以企業(yè)應(yīng)用架構(gòu)模式中流行的三層架構(gòu)為基礎(chǔ)，根據(jù)本系統(tǒng)的需求分析而衍生出來(lái)的五層架構(gòu)，每一層都依托在其下層之上來(lái)構(gòu)建，上層使用下層定義的各種接口，而下層對(duì)上層如何調(diào)用一無(wú)所知。另外，每一層對(duì)自己的

28、上層隱藏其實(shí)現(xiàn)細(xì)節(jié)。各層之間盡量做到相對(duì)透明89。在表現(xiàn)層中使用了當(dāng)前最流行的MVC框架模式進(jìn)行設(shè)計(jì)，在邏輯實(shí)現(xiàn)層中，參照企業(yè)級(jí)應(yīng)用架構(gòu)中的領(lǐng)域邏輯層的設(shè)計(jì)思路，上層參照服務(wù)層構(gòu)建，將本系統(tǒng)所提供的服務(wù)獨(dú)立出一層，成為功能模塊層，對(duì)表現(xiàn)層提供服務(wù)，下層邏輯實(shí)現(xiàn)層使用領(lǐng)域模式，使用一系列對(duì)象來(lái)承擔(dān)相關(guān)邏輯，數(shù)據(jù)層分為2層，上層物理數(shù)據(jù)層是對(duì)物理硬件的一一對(duì)應(yīng)，并且與MO進(jìn)行聚集處理，下層邏輯數(shù)據(jù)層則是對(duì)應(yīng)所在公司的Manage Object架構(gòu)，使用一些簡(jiǎn)單的POJO來(lái)構(gòu)建數(shù)據(jù)庫(kù)，同時(shí)可以使用這些數(shù)據(jù)類承載本系統(tǒng)的配置信息，與其他子系統(tǒng)進(jìn)行數(shù)據(jù)通信。圖2.1基站軟件系統(tǒng)的邏輯架構(gòu)多層次的架構(gòu)體系

29、，使得系統(tǒng)的靈活性極大增強(qiáng)，每層僅僅對(duì)其上下層負(fù)責(zé)，降低了系統(tǒng)的耦合度，可以將一個(gè)新硬件的需求給軟件代碼帶來(lái)的影響在最小范圍內(nèi)擴(kuò)散，很好的滿足頻繁增加新特性的需求。同時(shí)在每層之間按模塊劃分的策略和設(shè)計(jì)模式的大量應(yīng)用，優(yōu)化了系統(tǒng)的局部細(xì)節(jié)，極大降低了各個(gè)子模塊之間的耦合度10。 表現(xiàn)層的設(shè)計(jì)概要：該層采用當(dāng)今世界主流的GUI設(shè)計(jì)模式：MVC（Model-View-Controller）模式，即模型-視圖-控制器模式，MVC模式可以按照模型、繪圖表達(dá)方式和行繪圖為等角色把一個(gè)應(yīng)用系統(tǒng)的各個(gè)部分解耦分割開來(lái)。使用該模式，可以將本系統(tǒng)中的圖形界面的繪制跟圖形界面的控制分開，很好的滿足了設(shè)計(jì)目標(biāo)11。同

30、時(shí)由于該基站管理配置系統(tǒng)的配置向?qū)ы?yè)面中有許多共同的插件，可以將將視圖端以及控制器端共有的部分抽象到他們的父類，在父類中實(shí)現(xiàn)對(duì)頁(yè)面的控制等共有的邏輯，這樣的設(shè)計(jì)思想體現(xiàn)出了軟件設(shè)計(jì)模式中的里氏代換原則以及依賴倒轉(zhuǎn)原則。子類繼承時(shí)通過(guò)裝飾模式等設(shè)計(jì)方法來(lái)實(shí)現(xiàn)各自頁(yè)面不同的視圖，加減頁(yè)面12都不會(huì)對(duì)原來(lái)的架構(gòu)有影響，滿足開閉原則，對(duì)應(yīng)的視圖以及控制器僅僅通過(guò)模型端進(jìn)行交互，滿足迪米特法則1314。邏輯控制層部是整個(gè)系統(tǒng)中對(duì)配置行為進(jìn)行控制的地方，同時(shí)也負(fù)責(zé)Rbs對(duì)象的創(chuàng)建等工作，該層分兩層實(shí)現(xiàn)： 功能模塊層設(shè)計(jì)概要：該層主要采用建造模式來(lái)實(shí)現(xiàn)，以功能模塊層的需求為依據(jù)分別建造，提供各種各樣的產(chǎn)品。

31、對(duì)應(yīng)于該管理軟件的功能，給出其相對(duì)應(yīng)的類來(lái)提供目標(biāo)功能模塊，組裝構(gòu)建等細(xì)節(jié)等實(shí)現(xiàn)部分則對(duì)上層透明，該層并不負(fù)責(zé)細(xì)節(jié)邏輯的實(shí)現(xiàn)，而是一些實(shí)現(xiàn)功能的組合，具體的實(shí)現(xiàn)通過(guò)代理模式的思想交由下層負(fù)責(zé)?；诖?，該層主要是一些功能等創(chuàng)建組合的控制的接口，通過(guò)這些接口來(lái)調(diào)用下層的邏輯實(shí)現(xiàn)層，并委托下層來(lái)實(shí)現(xiàn)需要的邏輯。每一個(gè)功能對(duì)應(yīng)一個(gè)建造類，通過(guò)建造模式，可以做到復(fù)用邏輯實(shí)現(xiàn)層的零件產(chǎn)品，同時(shí)各功能模塊之間相對(duì)保持透明，滿足迪米特法則。 邏輯實(shí)現(xiàn)層設(shè)計(jì)概要：該層建立一個(gè)全部由對(duì)象組成的領(lǐng)域?qū)樱瑏?lái)對(duì)目標(biāo)對(duì)象的業(yè)務(wù)建模，其中每一個(gè)對(duì)象僅僅負(fù)責(zé)一個(gè)單一的功能的實(shí)現(xiàn)。由于業(yè)務(wù)的具體行為是經(jīng)常變化的，因此易于修改和

32、測(cè)試對(duì)邏輯實(shí)現(xiàn)層來(lái)說(shuō)十分重要。該層主要采用享元模式來(lái)進(jìn)行構(gòu)建，內(nèi)蘊(yùn)對(duì)象主要來(lái)存儲(chǔ)跟該邏輯對(duì)象配置相關(guān)的一些常量數(shù)據(jù)，外蘊(yùn)對(duì)象主要來(lái)存儲(chǔ)該邏輯對(duì)象需要配置的數(shù)據(jù)對(duì)象。該層的主要功能是：向下調(diào)用下層數(shù)據(jù)層中的數(shù)據(jù)，并對(duì)數(shù)據(jù)直接進(jìn)行讀寫等操作，實(shí)現(xiàn)一些獨(dú)立的，單一的，簡(jiǎn)單化功能，向上接受上一層功能模塊層的委托調(diào)用，實(shí)現(xiàn)功能模塊層的需求15?；竟芾碥浖到y(tǒng)的數(shù)據(jù)操作部分主要集中在這一層，產(chǎn)品中有一系列的數(shù)據(jù)操作方法，對(duì)數(shù)據(jù)層的數(shù)據(jù)類進(jìn)行讀寫操作。 數(shù)據(jù)層部分：該層分為2層，上層為物理數(shù)據(jù)層，與具體基站的物理硬件一一對(duì)應(yīng)，下層為POJO層，作為與整個(gè)UTRAN系統(tǒng)的接口，將系統(tǒng)系統(tǒng)高層定義的MO與本軟

33、件系統(tǒng)的數(shù)據(jù)進(jìn)行一個(gè)一一映射。通常為了滿足硬件結(jié)構(gòu)的變化，系統(tǒng)定義出的MO也會(huì)相應(yīng)隨之調(diào)整，結(jié)構(gòu)并不穩(wěn)定。如果數(shù)據(jù)層采用單一的層次，那么由于不停變化的需求，會(huì)導(dǎo)致數(shù)據(jù)層的經(jīng)常改動(dòng)，影響架構(gòu)的穩(wěn)定性16。 物理數(shù)據(jù)層設(shè)計(jì)概要：該層采用合成/聚集原則調(diào)用POJO層的數(shù)據(jù)對(duì)象，創(chuàng)建構(gòu)建成不同型號(hào)的物理硬件的一系列對(duì)象，與真正的物理硬件一一對(duì)應(yīng)17。POJO層設(shè)計(jì)概要：POJO，即簡(jiǎn)單的Java對(duì)象，僅包含一些屬性以及一些get，set方法，并不包含業(yè)務(wù)方法。該層主要作用就是提供一些最基本的數(shù)據(jù)供上層使用，對(duì)系統(tǒng)定義的MO數(shù)據(jù)進(jìn)行一一映射，轉(zhuǎn)化成本系統(tǒng)所能夠使用的數(shù)據(jù)。 產(chǎn)品的功能模塊結(jié)

34、構(gòu)產(chǎn)品的功能模塊結(jié)構(gòu)見圖2.2。用戶需要先選定Rbs基站的型號(hào)，該系統(tǒng)則會(huì)根據(jù)用戶的選擇生成相應(yīng)的基站配置界面，接下來(lái)就可以進(jìn)行機(jī)箱機(jī)柜cabinet、站點(diǎn)site、扇區(qū)、天線系統(tǒng)等基站主要硬件的配置。該管理軟件同時(shí)提供了修改modify/導(dǎo)出export/刪除delete等功能，修改modify功能可以在不重啟基站的情況下，調(diào)整基站的扇區(qū)、載波配置等設(shè)備的負(fù)載量等配置信息；導(dǎo)出export功能則可以將當(dāng)前基站的配置以XML的格式一次導(dǎo)出，以便下次配站使用；刪除Delete功能則是可以將基站當(dāng)前配置刪除，方便用戶重新配站。圖2.2產(chǎn)品的功能模塊結(jié)構(gòu)圖 系統(tǒng)概要設(shè)計(jì)的魯棒性分析系統(tǒng)

35、概要設(shè)計(jì)的魯棒圖見圖2.3。 從圖中可以看到，當(dāng)工程師選定了Rbs基站的類型以后，會(huì)有一個(gè)相對(duì)應(yīng)的工廠方法，生成該Rbs基站相對(duì)應(yīng)的實(shí)例，該實(shí)例以創(chuàng)建最大化的方式，初始化該基站的所有功能服務(wù)，并且保存該類型的基站所特有的數(shù)據(jù)邏輯。該基站的實(shí)例對(duì)象采用單例模式，在整個(gè)配置過(guò)程中只有這一個(gè)實(shí)例對(duì)象，方便記錄基站的配置信息以及對(duì)基站配置信息的修改信息。接下來(lái)的各種功能實(shí)現(xiàn)部分主要是對(duì)Rbs基站的配置數(shù)據(jù)進(jìn)行操作，所以可以直接對(duì)這個(gè)單例對(duì)象進(jìn)行操作。各功能模塊之間都做了很好的隔離，控制部分相對(duì)獨(dú)立，每個(gè)功能對(duì)于其他功能沒有影響，一個(gè)地方出錯(cuò)了并不影響其他功能的使用，有很好的魯棒性。圖2.3 系統(tǒng)概要設(shè)

36、計(jì)的魯棒圖2.2.2 POJO層的設(shè)計(jì) MO（ManageObject）策略通常MO由高層系統(tǒng)工程師來(lái)設(shè)計(jì)與實(shí)現(xiàn)，將Rbs中的資源邏輯抽象為一系列對(duì)象，再由面向?qū)ο蟮能浖Z(yǔ)言如Java，C+，在各自子系統(tǒng)實(shí)現(xiàn)細(xì)節(jié)，再由MO之間屬性的交互，來(lái)實(shí)現(xiàn)不同子系統(tǒng)間數(shù)據(jù)的交互。MO從高層體現(xiàn)出一致性，即各個(gè)子系統(tǒng)所使用的MO，雖然分屬各自的子系統(tǒng)，但是必須完全一樣。一般Rbs基站的軟件架構(gòu)采用數(shù)據(jù)驅(qū)動(dòng)的方式，各個(gè)子系統(tǒng)相對(duì)獨(dú)立，僅僅依賴數(shù)據(jù)的傳遞進(jìn)行通信。MO就是數(shù)據(jù)交互的關(guān)鍵，MO承載了各自子系統(tǒng)的數(shù)據(jù)信息。一個(gè)MO中通常會(huì)包含兩類參數(shù)：Ø 屬性，Attributes：跟MO抽

37、象的資源相關(guān)的參數(shù)變量，這些資源可以在配置的時(shí)候給他們賦值，資源的狀態(tài)也可以通過(guò)讀取這些值來(lái)獲得。Ø 行為，Actions：表示所能對(duì)一個(gè)MO采用的行動(dòng)，比如加鎖，刪除等。本文所要實(shí)現(xiàn)的通信基站運(yùn)維綜合管理系統(tǒng)V1.0，實(shí)際上就是采用一系列的Java類來(lái)對(duì)應(yīng)MO，將配置信息存到MO中，通過(guò)配置這些MO的attributes和actions來(lái)實(shí)現(xiàn)對(duì)基站的配置，最后講收集到的所有配置信息，發(fā)送到中央處理單元中。圖2.4是一個(gè)采用了MO模型的Rbs基站的示意圖：圖2.4 Rbs基站的MOM模型上圖中矩形代表Rbs節(jié)點(diǎn)整體，正面是Rbs從系統(tǒng)的角度所能看到的資源，側(cè)面則是對(duì)Rbs資源的抽象：

38、MOM（MO Model）。從圖上可以看出：MO模型即是對(duì)Rbs系統(tǒng)的角度所能看到的資源的另一種表示所構(gòu)建成的模型：抽象成為一系列可以管理的對(duì)象MO，從一系列對(duì)象的角度來(lái)看Rbs的資源。表2.3的MO取自愛立信Rbs基站，6601型號(hào)遠(yuǎn)程基站，slot的信息表。表2.3Slot信息表Possible parentsubrackPossible childrenAuxPlugInUnitBbifBoardPlugInUnitActionsupdateConfiguration()AttributesactiveSwAllocationproductDatareservedBySlotIdslot

39、NumberslotStateSlot：是對(duì)機(jī)框中插槽資源的一個(gè)抽象。從該表中可以看出：slot的父親節(jié)點(diǎn)只有一個(gè)，機(jī)框subrack；可能的孩子節(jié)點(diǎn)有3個(gè)，可插入插槽單元PlugInUnit，比如基帶板，射頻板，信號(hào)過(guò)濾板等；遠(yuǎn)程單元AuxPlugInUnit，比如傾角調(diào)整器RET，塔放TMA等；一種基帶板與射頻單元的交互接口BbifBoard。該MO的action僅有一個(gè)：updateConfiguration。表示如果該基站是自動(dòng)配置，則該action會(huì)觸發(fā)該插槽下硬件單元的自動(dòng)配置行為。6個(gè)Attributes分別表示：activeSwAllocation表示此刻該插槽是否有PlugI

40、nUnit在使用，如果沒有PlugInUnit在次插槽被配置使用，則該屬性的值為空。productData屬性描述當(dāng)前插入單元的信息，該屬性一旦賦值，則無(wú)論其插入硬件板是否工作，該值都不會(huì)變，該屬性的值只有在slot換新硬件板的時(shí)候才會(huì)改變。reservedBy該屬性以一個(gè)列表形式存在，是儲(chǔ)備這個(gè)MO的所有MO的一個(gè)列表。SlotId，該屬性的值是用來(lái)組成RDN的。slotNumber該屬性的值從左往右開始數(shù)起，從1開始，用來(lái)表示插槽位置的。slotState屬性用來(lái)表明該插槽的狀態(tài)。該MO的是在其父親MO的創(chuàng)建的時(shí)候創(chuàng)建的，并且不能被刪除。該MO插槽的數(shù)目是在其父親節(jié)點(diǎn)subrack中定義的

41、。 MO的查找：RDN與LDNRDN：Relative Distinguished Name，相對(duì)標(biāo)識(shí)名。RDN的命名跟該MO的父親節(jié)點(diǎn)相關(guān)。這個(gè)屬性的值在他被建立的時(shí)候就定義好了，并且不能改變。LDN：Local Distinguished Name，本地專有名稱。由該Rbs節(jié)點(diǎn)中一系列的RDN所形成的一個(gè)獨(dú)一無(wú)二的名字。RDN在查找父子節(jié)點(diǎn)的MO時(shí)候使用，LDN在全局查找MO的使用。 圖2.5是RNC中的一個(gè)MO的結(jié)構(gòu)，由下可以看出RDN跟LDN如何命名，以及LDN是如何由RDN所形成的：圖2.5 一個(gè)使用RND/LDN的MO結(jié)構(gòu)由上圖可以看出RncFunction這個(gè)MO的

42、RDN=RncFunctionId="0"，由于RncFunction本身就是根節(jié)點(diǎn)，所以LDN等于RDN。UtranCell這個(gè)MO的RDN=UtranCellId="100"，LDN等于該MO的RDN加上這個(gè)MO所有父節(jié)點(diǎn)的RDN，所以UtranCell的LDN=RncFunctionId="0"，UtranCellId="100"，同理，Rach這個(gè)MO的RDN=RachId="0"，LDN=RncFunctionId="0"，UtranCellId="100

43、"，RachId="0"。表中的MO的RDN命名規(guī)則：從機(jī)框最左邊的插槽開始，第一個(gè)插槽slot為：slot=1。因此該MO的RDN=SlotId="1"。 MO的映射機(jī)制MO的映射機(jī)制采用POJO模式策略。從高層系統(tǒng)規(guī)定定義的MO到該軟件配置管理系統(tǒng)的數(shù)據(jù)庫(kù)所采用的映射技術(shù)由POJO模式實(shí)現(xiàn)。POJO：Plain Old Java Object，簡(jiǎn)單Java對(duì)象。POJO是一個(gè)簡(jiǎn)單的普通的Java對(duì)象，它不包含業(yè)務(wù)邏輯或者持久化邏輯等，沒有從任何類繼承，不擔(dān)當(dāng)任何特殊的角色，也沒有實(shí)現(xiàn)任何接口，更沒有被其他框架侵入的Java對(duì)象

44、。每一個(gè)MO由一個(gè)POJO來(lái)負(fù)責(zé)實(shí)現(xiàn)，由一個(gè)具體的Java類來(lái)代表一個(gè)MO，Java中的字段設(shè)置成私有的，分別表示MO中的attribute跟action。一系列的get/set方法來(lái)負(fù)責(zé)數(shù)據(jù)的讀寫。2.2.3 物理數(shù)據(jù)層的設(shè)計(jì)POJO層對(duì)應(yīng)的數(shù)據(jù)庫(kù)數(shù)據(jù)，MO數(shù)據(jù)，僅僅只是系統(tǒng)高層對(duì)Rbs資源的一個(gè)邏輯抽象，并不完全對(duì)應(yīng)具體硬件。整個(gè)UTRAN系統(tǒng)中，各個(gè)子系統(tǒng)之間的通信，是需要MO來(lái)傳遞數(shù)據(jù)的，而我們對(duì)Rbs的配置，實(shí)際上僅僅是對(duì)具體的一個(gè)類型的Rbs的具體硬件的配置，這兩者之間有一些區(qū)別。所以需要有一層數(shù)據(jù)層，來(lái)實(shí)現(xiàn)邏輯數(shù)據(jù)MO跟具體硬件的參數(shù)配置的映射關(guān)系。以下將從MO樹的建立，物理數(shù)據(jù)

45、的建立和物理數(shù)據(jù)的實(shí)現(xiàn)策略三個(gè)方面具體闡述該層主要的設(shè)計(jì)步驟。 MO樹的建立由于在POJO層使用了POJO數(shù)據(jù)，所以僅僅只有g(shù)et/set方法，并沒有任何關(guān)系，也沒有任何邏輯，需要在這一層給MO數(shù)據(jù)建立關(guān)系。這樣不僅可以實(shí)現(xiàn)各個(gè)MO之間的的先后順序，父子關(guān)系，依賴關(guān)系等邏輯，同時(shí)還可以使得邏輯控制層對(duì)MO數(shù)據(jù)的管理、使用更加方便。圖2.6是系統(tǒng)高層定義的MO結(jié)構(gòu)樹的一部分：圖2.6MO結(jié)構(gòu)樹以系統(tǒng)高層定義的MO樹為基礎(chǔ)，本基站管理配置系統(tǒng)需要構(gòu)建的樹的示意圖如圖2.7所示：圖2.7 MO結(jié)構(gòu)示意圖所有的MO都有一個(gè)共同的根節(jié)點(diǎn)Root Node，由上圖信息可知，樹的根節(jié)點(diǎn)為Man

46、agedElement這個(gè)對(duì)象，在這之下依次掛著各個(gè)MO。建立MO樹的規(guī)則是根據(jù)系統(tǒng)對(duì)MO結(jié)構(gòu)圖的定義以及MO定義的信息表中可能的父類，可能的子類的信息來(lái)建立的：在本基站管理軟件系統(tǒng)的Java類中，用3個(gè)類來(lái)實(shí)現(xiàn)MO樹的創(chuàng)建，如圖2.8所示：圖2.8MO樹的代碼結(jié)構(gòu)Node類提供建立樹的一些最基本的方法，如getDepth、getChild、getParent方法等。MONode類繼承了Node類，在此基礎(chǔ)上擴(kuò)展了一些方法，提供關(guān)于MO屬性的一些操作，比如lockable，deletable方法。MOProxyNode類同樣繼承自Node類，這個(gè)類跟MoNode不同，擴(kuò)展的方法主要是用來(lái)獲取這

47、個(gè)類，以及獲取相關(guān)的MO。 物理數(shù)據(jù)的建立這一層的主要目的就是：建立一個(gè)對(duì)應(yīng)具體類型的Rbs，具體硬件的配置的數(shù)據(jù)層。這一層主要是將抽象管理對(duì)象MO的數(shù)據(jù)與具體硬件配置的數(shù)據(jù)聯(lián)系起來(lái)，基站軟件管理配置系統(tǒng)從用戶的角度來(lái)看，僅僅是對(duì)具體硬件進(jìn)行配置，而并不是對(duì)抽象的MO的配置，所以需要一層數(shù)據(jù)層，來(lái)進(jìn)行抽象數(shù)據(jù)與具體數(shù)據(jù)的轉(zhuǎn)換。下面以射頻單元硬件為例，分析本通信基站運(yùn)維綜合管理系統(tǒng)V1.0是如何將抽象管理對(duì)象MO的數(shù)據(jù)與具體硬件配置的數(shù)據(jù)進(jìn)行轉(zhuǎn)換的。圖2.9是愛立信一個(gè)遠(yuǎn)程射頻單元的硬件實(shí)例圖：圖2.9 愛立信遠(yuǎn)程射頻單元的硬件實(shí)例從圖中可以看出，這個(gè)遠(yuǎn)程射頻單元已經(jīng)進(jìn)行了很好的封

48、裝，其實(shí)內(nèi)部集成了上行信號(hào)處理板，下行信號(hào)處理板，空口等硬件，該硬件的外部則有連接基帶信號(hào)處理板的接口以及連接天線的接口等，這些硬件的具體分配資源不需要本系統(tǒng)進(jìn)行深入配置，在下層子系統(tǒng)會(huì)有針對(duì)細(xì)節(jié)的配置，但是遠(yuǎn)程射頻單元的型號(hào)，上下行信號(hào)處理板、空口等硬件的數(shù)目，外部接口的連接信息，是否發(fā)射分級(jí)，是否串聯(lián)等信息，這些配置信息都是需要在配置這個(gè)遠(yuǎn)程射頻單元的時(shí)候同時(shí)配置的。而在系統(tǒng)高層定義的MO里面并沒有一個(gè)具體的MO與該硬件對(duì)應(yīng)，統(tǒng)一歸類為AuxPlugInUnit這個(gè)MO，僅僅通過(guò)auType這個(gè)屬性來(lái)區(qū)分具體的類型。MO的定義高度抽象化，不會(huì)涉及細(xì)節(jié)，或者具體硬件。AuxPlugInUni

49、t信息如表2.4所示：表2.4AuxPlugInUnit信息表ActionsreadRepairDelivNote()reconfigureProgramPrepare()restartAuxUnit()AttributesadministrativeStatealramStatusauTypeAuxPlugInUnitIdpiuTypeproductNumberreservedByserialNumberuniqueHwIdunitType由上表可以看出，這個(gè)MO跟實(shí)際硬件之間并不完全匹配，比如與外部其他硬件的接口連線部分，沒有任何屬性可以用來(lái)保存與基帶信號(hào)處理板的連接配置或者與天線單元的連

50、接配置，而保存這個(gè)連接配置信息的屬性卻屬于另一個(gè)MO，DigitalCable中。根據(jù)具體產(chǎn)品信息，該硬件實(shí)際使用到的所有MO如表2.5所示：表2.5遠(yuǎn)程射頻單元硬件使用的MO實(shí)際硬件抽象MO遠(yuǎn)程射頻單元DigitalCableAuxPlugInUnitSectorAntennaAntennaBranchAntFeederCable于是我們可以使用合成/聚合復(fù)用原則，建立一個(gè)Java類，其中包含了屬于這個(gè)硬件的所有MO的一個(gè)聚集，這樣可以通過(guò)配置這個(gè)類來(lái)配置這個(gè)硬件，同時(shí)間接配置了相關(guān)的MO。 該層具有十分重要的意義，是將抽象管理對(duì)象MO與具體硬件實(shí)例緊密聯(lián)系起來(lái)的橋梁?；拒浖芾砼渲孟到y(tǒng)僅

51、僅是對(duì)具體硬件進(jìn)行配置，而并不是對(duì)抽象的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ù)用原則以及合成模式這兩個(gè)策略。下面分別具體闡述這兩種策略以及在本系統(tǒng)中采用的原因：合成/聚合復(fù)用原則：又叫做合成復(fù)用原則（CRP），指在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分；新對(duì)象通過(guò)向這些對(duì)象的委派達(dá)到復(fù)用已有功能的目的。使用合成/聚合復(fù)用原則的原因有：1 新對(duì)象存取成分對(duì)象的唯一方法是通過(guò)成分對(duì)象的接口。本層的數(shù)據(jù)給下層MO數(shù)據(jù)

52、層賦值只會(huì)調(diào)用POJO類中的set方法。2 這種復(fù)用支持包裝。3 這種復(fù)用所需的依賴較少。不同于繼承的實(shí)現(xiàn)，這樣實(shí)現(xiàn)的耦合度極低，有助于數(shù)據(jù)的靈活組合，利于架構(gòu)的解耦。一旦有新硬件或者硬件的改動(dòng)，改變起來(lái)比較方便。4 每一個(gè)新類可以將重點(diǎn)集中在一個(gè)任務(wù)上。本層物理數(shù)據(jù)層每一個(gè)類的主要任務(wù)就是將MO層的POJO類進(jìn)行集成，以匹配真實(shí)物理硬件。 合成模式：屬于對(duì)象的結(jié)構(gòu)模式，有時(shí)候又叫做“部分-整體”模式。合成模式將對(duì)象組織到樹結(jié)構(gòu)中，可以用來(lái)描述整體與部分的關(guān)系。這樣設(shè)計(jì)使得我們可以找到一種無(wú)需一對(duì)多的關(guān)系即可獲得一對(duì)多的行為的替代方式。使用合成模式的主要原因有：1 有一些物理硬件可以做進(jìn)一步的

53、集成，集成化是未來(lái)無(wú)線基站硬件的趨勢(shì)，在該層就進(jìn)行必要的數(shù)據(jù)集成，可以很好的滿足將來(lái)的需求變化。2 在一些集成了的硬件板的處理上，上層邏輯層不直接調(diào)用不直接配置的數(shù)據(jù)類，而是通過(guò)調(diào)用實(shí)際配置的數(shù)據(jù)類來(lái)進(jìn)行委派。這樣可以增加代碼的復(fù)用性。3 在物理數(shù)據(jù)層就對(duì)數(shù)據(jù)進(jìn)行必要的集成，當(dāng)對(duì)集成硬件進(jìn)行數(shù)據(jù)配置的時(shí)候，可以通過(guò)父類進(jìn)行數(shù)據(jù)的遍歷，而不并每一次都去遍歷所有的子類，這樣可以減少數(shù)據(jù)配置中的錯(cuò)誤。 合成模式的UML結(jié)構(gòu)圖18如圖2.10所示：圖2.10 合成模式該圖是合成模式中樹結(jié)構(gòu)的一個(gè)靜態(tài)結(jié)構(gòu)。最上方出現(xiàn)的父類節(jié)點(diǎn)，左下方是一個(gè)樹葉節(jié)點(diǎn)，右下方是一個(gè)樹枝節(jié)點(diǎn)，可以含有其他節(jié)點(diǎn)，如果沒有其他節(jié)

54、點(diǎn)，則也退化成樹葉節(jié)點(diǎn)。由于本層數(shù)據(jù)層的設(shè)計(jì)只是聚集下層POJO層中的MO數(shù)據(jù)，使之與實(shí)際物理硬件對(duì)應(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)的搭建的時(shí)候，使用合成模式的思想，但是并不完全依照合成模式來(lái)構(gòu)建，因?yàn)楸鞠到y(tǒng)設(shè)計(jì)的一個(gè)主要目的就是給原來(lái)的系統(tǒng)解耦合，盡量做到低耦合，而且這兩層數(shù)據(jù)之間并沒有強(qiáng)耦合關(guān)系，所以不需要繼承的方式來(lái)實(shí)現(xiàn)，而是將下層數(shù)據(jù)層中的類以合成/聚集的方式使用。以上文中出現(xiàn)的遠(yuǎn)程射頻單元為例，依據(jù)合成模式的思想，設(shè)計(jì)如圖2.11所示：圖2.1

55、1 遠(yuǎn)程射頻單元的聚集模式在該圖中，處于父節(jié)點(diǎn)位置的就是本層需要設(shè)計(jì)的數(shù)據(jù)類，遠(yuǎn)程射頻單元類，5個(gè)子節(jié)點(diǎn)由表2.5中可以得到。跟合成模式不同，在這里并不使用繼承，而是使用聚集來(lái)實(shí)現(xiàn)，遠(yuǎn)程射頻單元以聚集的方式將這五個(gè)POJO類聚集到父類中，使之成為一個(gè)整體。這樣同樣可以做到在向上層提供數(shù)據(jù)服務(wù)的時(shí)候，以一個(gè)整體的行為，以一對(duì)一的關(guān)系來(lái)進(jìn)行交互，而不是傳統(tǒng)一對(duì)多的方式。這樣在邏輯控制層中，可以通過(guò)僅僅調(diào)用這一個(gè)數(shù)據(jù)類，就可以達(dá)到同時(shí)調(diào)用這5個(gè)MO類的數(shù)據(jù)的功能。2.2.4 邏輯實(shí)現(xiàn)層的設(shè)計(jì)本節(jié)主要介紹了該層的實(shí)現(xiàn)策略，同時(shí)結(jié)合本層的主要功能需求，詳細(xì)分析了采用享元模式的原因。本層只負(fù)責(zé)簡(jiǎn)單單一的行

56、為邏輯，即每一個(gè)類只負(fù)責(zé)一種邏輯，邏輯的組合則交給上層2021。 邏輯實(shí)現(xiàn)層的實(shí)現(xiàn)策略：享元模式。享元模式是對(duì)象的結(jié)構(gòu)模式。享元模式以共享的方式高效的支持大量的細(xì)粒度對(duì)象。享元對(duì)象區(qū)分內(nèi)蘊(yùn)狀態(tài)和外蘊(yùn)狀態(tài)。一個(gè)內(nèi)蘊(yùn)狀態(tài)是存儲(chǔ)在享元對(duì)象內(nèi)部的，并且是不會(huì)隨著環(huán)境改變而有所不同的。因此一個(gè)享元可以具有內(nèi)蘊(yùn)狀態(tài)并且內(nèi)蘊(yùn)狀態(tài)可以共享。一個(gè)外蘊(yùn)狀態(tài)是隨環(huán)境改變而改變的、不可以共享的狀態(tài)。享元對(duì)象的外蘊(yùn)狀態(tài)必須由客戶端保存，并在享元對(duì)象被創(chuàng)建之后，在需要使用的時(shí)候再傳入到享元對(duì)象內(nèi)部。外蘊(yùn)狀態(tài)不可以影響享元對(duì)象的內(nèi)蘊(yùn)狀態(tài)，他們之間是相互獨(dú)立的。 圖2.12是享元模式的結(jié)構(gòu)示意圖：圖2.12 享元模式在上圖中

57、，享原工廠負(fù)責(zé)創(chuàng)建和管理享元對(duì)象。這個(gè)角色必須保證享元對(duì)象可以被系統(tǒng)適當(dāng)?shù)毓蚕怼．?dāng)一個(gè)對(duì)象調(diào)用一個(gè)享元對(duì)象的時(shí)候，享元工廠會(huì)檢查系統(tǒng)中是否已經(jīng)有了一個(gè)符合要求的享元對(duì)象。如果已經(jīng)有了，享元工廠角色就應(yīng)當(dāng)提供這個(gè)已有的享元對(duì)象，如果系統(tǒng)中沒有一個(gè)適當(dāng)?shù)南碓獙?duì)象的話，享元工廠角色就應(yīng)當(dāng)創(chuàng)建一個(gè)合適的享元對(duì)象。抽象享元角色是所有享元類的超類，為這些類定義出需要實(shí)現(xiàn)的公共接口，外蘊(yùn)狀態(tài)可以在該類的方法中以入?yún)⒌男问絺魅?。具體享元對(duì)象角色負(fù)責(zé)內(nèi)蘊(yùn)享元的創(chuàng)建和管理享元對(duì)象。不可共享的享元角色負(fù)責(zé)用來(lái)實(shí)現(xiàn)那些不可以共享的享元的創(chuàng)建和管理。結(jié)合本層的功能，使用享元模式的理由：1. 一個(gè)系統(tǒng)有大量的對(duì)象。本系統(tǒng)中，每一個(gè)MO都會(huì)對(duì)應(yīng)一個(gè)POJO，同時(shí)在物理數(shù)據(jù)層中進(jìn)一步的合成，所以會(huì)出現(xiàn)大量的數(shù)據(jù)對(duì)象。2. 這些對(duì)象耗費(fèi)大量的內(nèi)存。一個(gè)功能服務(wù)在邏輯控制層會(huì)被分解成為很多簡(jiǎn)單邏輯，每一個(gè)簡(jiǎn)單邏