通信基站運(yùn)維綜合標(biāo)準(zhǔn)管理專(zhuān)業(yè)系統(tǒng)設(shè)計(jì)項(xiàng)目說(shuō)明指導(dǎo)書(shū)

第1章緒論本文重要簡(jiǎn)介通信基站運(yùn)維綜合管理系統(tǒng)V1.0設(shè)計(jì)與實(shí)現(xiàn)。本章一方面簡(jiǎn)介本系統(tǒng)背景知識(shí)以及研究意義；然后闡述國(guó)內(nèi)外研究以及開(kāi)發(fā)最新動(dòng)態(tài)，最后簡(jiǎn)介本文重要內(nèi)容以及組織構(gòu)造安排。1.1研究背景與意義本節(jié)重要簡(jiǎn)介本文涉及某些無(wú)線通信知識(shí)，一方面簡(jiǎn)介與本文描述通信基站運(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.13G無(wú)線通信有關(guān)知識(shí)WCDMA[1]：WidebandCodeDivisionMultipleAccess寬帶碼分多址。是一種由碼分多址（CDMA），演變而來(lái)第三代無(wú)線通信技術(shù)。WCDMA采用直接序列擴(kuò)頻碼分多址、頻分雙工方式。WCDMA是一種由3GPP詳細(xì)制定，基于GSMMAP核心網(wǎng)，UTRAN為無(wú)線接口第三代移動(dòng)通信系統(tǒng)。UTRAN：TheUMTSTerrestrialRadioAccessNetwork，陸地?zé)o線接入網(wǎng)。信令網(wǎng)和數(shù)據(jù)傳播網(wǎng)在邏輯上分開(kāi)[2]；UTRAN和CN功能將和傳播功能完全分開(kāi)；UTRAN和CN使用尋址方式將和傳播功能尋址方式無(wú)關(guān)；宏分級(jí)（FDD模式）解決完全在UTRAN內(nèi)，RRC連接移動(dòng)性完全由UTRAN控制；定義UTRAN接口時(shí)候，通過(guò)接口功能劃分應(yīng)有盡量少可選項(xiàng)；應(yīng)基于此接口控制實(shí)體邏輯模型。UTRAN由一組通過(guò)Iu接口連接到核心網(wǎng)CN無(wú)線網(wǎng)絡(luò)子系統(tǒng)RNS構(gòu)成。一種RNS由一種無(wú)線網(wǎng)絡(luò)控制器（RNC）和一種或者各種節(jié)點(diǎn)（NodeB）構(gòu)成。Rbs通過(guò)Iub接口連接到RNC。圖1.1是UTRAN系統(tǒng)某些平面構(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（RadioNetworkController）無(wú)線網(wǎng)絡(luò)控制器。RNC重要負(fù)責(zé)跟核心網(wǎng)以及Rbs進(jìn)行交互，并且負(fù)責(zé)管理無(wú)線鏈路。RNC控制通過(guò)Rbs信息量。RNC同步負(fù)責(zé)建立信道，解決與UE連接，控制無(wú)線基站資源優(yōu)化。WCDMARbs提供無(wú)線資源以及無(wú)線廣播，并且負(fù)責(zé)接受與發(fā)送UE信號(hào)。圖1.1UTRAN系統(tǒng)平面構(gòu)造（2）OSS-RC(OperationSupportSystem-RadioandCore)運(yùn)維支撐系統(tǒng)-無(wú)線基站跟核心網(wǎng)。OSS-RC重要解決從RNC過(guò)來(lái)操作管理任務(wù)，例如軟件安裝與升級(jí)，RAN層管理配備，告警解決等。（3）COMINF(CommonOperate&ManageInfrastructure)通用操作管理架構(gòu)。COMINF重要管理涉及從網(wǎng)絡(luò)設(shè)備到OSS-RC所需要攜帶路由等網(wǎng)絡(luò)合同。COMINF同步提供安全性服務(wù)，客戶協(xié)助信息，軟件管理，備份解決方案等服務(wù)。UTRAN拓?fù)錁?gòu)造和核心節(jié)點(diǎn)外部接口如圖1.2所示：（節(jié)點(diǎn)跟接口在下圖中僅僅是一種邏輯插圖，跟實(shí)際狀況不一定完全吻合。例如Mub和Iub接口也許承載相似媒體，W-Rbs也也許以級(jí)聯(lián)拓?fù)湫问竭B接）Rbs[3]（RadioBaseStation）：WCDMA中Rbs就是UTRAN系統(tǒng)節(jié)點(diǎn)中基站特有名稱(chēng)。NodeB是一種邏輯節(jié)點(diǎn)，負(fù)責(zé)發(fā)送，接受從UE過(guò)來(lái)信道。Rbs節(jié)點(diǎn)除了解決最基本功能以外，同步還控制與監(jiān)管天線設(shè)備。Rbs通過(guò)luant接口或者其她某些專(zhuān)有規(guī)范原則來(lái)控制與監(jiān)管TMA、RET等天線設(shè)備。RbsElementManager：基站管理軟件，并不是UTRAN系統(tǒng)中一種獨(dú)立節(jié)點(diǎn)，但是她是Rbs系統(tǒng)一某些，EM普通運(yùn)營(yíng)在PC端口，控制了包括一系列操作管理應(yīng)用軟件安裝。RbsCabinetViewer：機(jī)箱機(jī)柜查看器，是布置在OSS-RC上一種應(yīng)用程序，但是她依然屬于Rbs系統(tǒng)一某些。機(jī)箱機(jī)柜查看器提供了一種可視化視圖，并且提供了一種工具來(lái)解決由事件干擾引起錯(cuò)誤。圖1.2UTRAN系統(tǒng)拓?fù)錁?gòu)造圖1.3是Rbs所處位置以及Rbs與其她節(jié)點(diǎn)關(guān)系：圖1.3Rbs與RNC、OSS-RC關(guān)系從圖上可以看出：Rbs重要通過(guò)Mub接口與OSS-RC交互，通過(guò)lub接口與RNC交互，通過(guò)Uu接口與UE交互。管理軟件EM在OSS-RC節(jié)點(diǎn)上，負(fù)責(zé)管理與配備Rbs[4]。圖1.4是Rbs外部接口平面圖：圖1.4Rbs外部接口Mub：Mub接口是由Rbs所提供，由管理軟件EM，機(jī)箱機(jī)柜查看器，網(wǎng)絡(luò)管理系統(tǒng)等系統(tǒng)使用。Iub：連接RNC跟Rbs有關(guān)接口。GUI：（GraphicUserInterface）由管理軟件EM或者機(jī)箱機(jī)柜查看器提供，提供了一種顧客和諧型圖形化界面給基站操作人員操作和維護(hù)Rbs。VMI：（VisualandMechanicalInterface），重要提供應(yīng)基站站點(diǎn)操作人員使用。VMI重要涉及可視化批示器（LED燈），手動(dòng)可操作開(kāi)關(guān)/按鈕（復(fù)位鍵）和傳入外部電源等。此外，裝配電纜螺絲等都屬于這個(gè)接口。1.1.2基站管理軟件功能ITU-TTMN：TelecommunicationsManagementNetworkstandardfromtheITU-T)國(guó)際電信聯(lián)盟電信原則化部，電信管理網(wǎng)絡(luò)。由于該軟件系統(tǒng)緊緊負(fù)責(zé)基站管理與配備，暫時(shí)不考慮traffic事件某些，僅考慮操作管理某些。TMN操作管理某些方略重要由：代理模式使用，例如OSS-RC作為管理人，RbsEM作為代理。使用管理對(duì)象（ManagedObject，MO）模型，即管理一系列抽象或者物理或者邏輯上資源。管理信息庫(kù)（ManagementInformationBase，MIB）使用，即一種存儲(chǔ)了TMN中所有MO信息庫(kù)。管理信息模型（ManagementInformationModel，MIM）使用，即抽象出一種面向?qū)ο笳Z(yǔ)言來(lái)抽象規(guī)定MO定義，定義MO數(shù)據(jù)基本操作。一種基本邏輯架構(gòu)模型如圖1.5所示：圖1.5TMN管理某些邏輯架構(gòu)模型本文所描述通信基站運(yùn)維綜合管理系統(tǒng)V1.0是一種OSS-RC系統(tǒng)下子系統(tǒng)服務(wù)，從TMN管理某些架構(gòu)邏輯模型上來(lái)看，該系統(tǒng)處在架構(gòu)在體現(xiàn)層。普通，配站工程師會(huì)在軟件中對(duì)基站進(jìn)行配備，該軟件系統(tǒng)將顧客配備基站數(shù)據(jù)信息收集起來(lái)，，通過(guò)MO攜帶數(shù)據(jù)，通過(guò)COBRA等公共合同與指定基站進(jìn)行通信，向下層傳送管理和配備信息，將所需配備信息發(fā)送到指定基站中央解決單元，而在基站端，普通會(huì)有一種類(lèi)似于接口子系統(tǒng)，對(duì)發(fā)送過(guò)來(lái)消息進(jìn)行解析并解決，并將配備信息進(jìn)行反饋。這樣就可以做到基站安裝跟配備分開(kāi)進(jìn)行，并且還可以隨時(shí)對(duì)基站進(jìn)行調(diào)控容量，監(jiān)視基站中設(shè)備狀態(tài)等操作?；就ㄐ艠?gòu)造示意圖如圖1.6所示:圖1.6基站通信構(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關(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)營(yíng)環(huán)境安裝配備以便

(.Net

Framework,

Asp.Net,

IIS)

2，技術(shù)成熟，主流技術(shù)，配套技術(shù)文檔完善，眾多開(kāi)源或免費(fèi)文檔或項(xiàng)目可供參照

3，擁有眾多新技術(shù)，以便構(gòu)建公司級(jí)應(yīng)用

4，開(kāi)發(fā)布置工具功能強(qiáng)大

5，能與Windows平臺(tái)緊密結(jié)合，最大限度運(yùn)用系統(tǒng)功能1.1.3研究意義隨著中興，華為等新興無(wú)線通信公司崛起，無(wú)線通信行業(yè)競(jìng)爭(zhēng)越來(lái)越激烈，各大公司紛紛推出了新產(chǎn)品，軟硬件更新速度日益加快，而市場(chǎng)上也浮現(xiàn)了基站類(lèi)型新舊各異，功能各異復(fù)雜狀況，雖然是同一站型，也會(huì)由于需求變動(dòng)而導(dǎo)致硬件不同，或者設(shè)備參數(shù)不同等問(wèn)題。將原有硬件進(jìn)行整合，升級(jí)改造，已經(jīng)成為了當(dāng)前3G基站發(fā)展一種主流趨勢(shì)。這樣不但僅可以節(jié)約成本，復(fù)用原有硬件設(shè)備，提高運(yùn)用率，同步可以在更好兼容基站原有設(shè)備基本上，達(dá)到硬件微小改動(dòng)，功能大大提高，基站大不同樣特點(diǎn)。當(dāng)前市場(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ì)在必行。原有架構(gòu)層次過(guò)于簡(jiǎn)樸，在新項(xiàng)目開(kāi)發(fā)中浮現(xiàn)了架構(gòu)兼容性不夠，代碼耦合度過(guò)強(qiáng)等問(wèn)題，導(dǎo)致系統(tǒng)難以維護(hù)，升級(jí)，一旦有新需求變化，總會(huì)進(jìn)行大幅修改，顯然已經(jīng)無(wú)法適應(yīng)產(chǎn)品不斷更新新規(guī)定。如何設(shè)計(jì)出一種通用基站管理系統(tǒng)，滿足需求經(jīng)常變動(dòng)特點(diǎn)，成為一種亟待解決問(wèn)題，也是本文重要研究目。1.2國(guó)內(nèi)外研究動(dòng)向愛(ài)立信：愛(ài)立信基站管理系統(tǒng)采用了CI/RI（ConfigurationItem/ResourceItem）架構(gòu)。將基站資源抽象為一系列ResourceItem，將一組相近資源以匯集形式構(gòu)成ConfigurationItem，構(gòu)建出一種邏輯上Rbs進(jìn)行配備。該管理系統(tǒng)使用了MVC，JavaBean，SAX等技術(shù)，提供了一種顧客和諧型界面，通過(guò)一種通用平臺(tái)CPP與基站端進(jìn)行通信?？蛻舳说交径送ㄐ攀褂昧薈OBRA技術(shù)解決并發(fā)。當(dāng)前愛(ài)立信在市場(chǎng)上主流基站及新硬件設(shè)備如圖1.7所示[5]。圖1.7愛(ài)立信主流基站及新硬件設(shè)備華為[6]：提供了一種基于JAVAWeb網(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)簡(jiǎn)介了通信基站運(yùn)維綜合管理系統(tǒng)V1.0設(shè)計(jì)與實(shí)現(xiàn)，下面從分章節(jié)角度詳細(xì)闡述本文將要闡述重要內(nèi)容：第一章：一方面簡(jiǎn)介了本系統(tǒng)所需要無(wú)線通信背景知識(shí)，該系統(tǒng)在UTRAN系統(tǒng)中所處位置以及該系統(tǒng)所擔(dān)當(dāng)職能等，另一方面簡(jiǎn)介了國(guó)內(nèi)外研究開(kāi)發(fā)動(dòng)態(tài)，本章最后簡(jiǎn)介了本文重要內(nèi)容。第二章：重要簡(jiǎn)介了本系統(tǒng)需求分析以及詳細(xì)架構(gòu)設(shè)計(jì)。在需求分析中使用了ADMENS矩陣分析法。架構(gòu)設(shè)計(jì)時(shí)候先簡(jiǎn)介系統(tǒng)總體架構(gòu)設(shè)計(jì)，再分層分別簡(jiǎn)介每一層設(shè)計(jì)。在簡(jiǎn)介時(shí)候不但僅簡(jiǎn)介了設(shè)計(jì)思路，同步從設(shè)計(jì)模式角度給出了實(shí)現(xiàn)方略。第三章：依照上一章設(shè)計(jì)出架構(gòu)，分架構(gòu)層次，依次詳細(xì)闡述了每一層實(shí)現(xiàn)過(guò)程。實(shí)現(xiàn)過(guò)程重要以詳細(xì)UML類(lèi)圖以及時(shí)序圖為例進(jìn)行闡述，同步將設(shè)計(jì)過(guò)程中用到設(shè)計(jì)模式串聯(lián)起來(lái)。第四章：描述了系統(tǒng)測(cè)試重要辦法，以及本系統(tǒng)測(cè)試環(huán)節(jié)，最后展示了某些測(cè)試用例，同步總結(jié)了測(cè)試成果。第五章：總結(jié)了本論文重要工作，分析系統(tǒng)中某些值得改進(jìn)地方，并且提出了后續(xù)研究某些展望。第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)了分層思想，同步為了更好局部構(gòu)造，設(shè)計(jì)模式在本系統(tǒng)中得到了充分應(yīng)用。2.1系統(tǒng)需求分析通信基站運(yùn)維綜合管理系統(tǒng)V1.0提供了一種基站管理配備平臺(tái)，針對(duì)不同種類(lèi)基站進(jìn)行配備，同步提供了對(duì)基站配備進(jìn)行修改，刪除，以及導(dǎo)入導(dǎo)出配備腳本等功能。在進(jìn)行本文需求分析時(shí)候會(huì)借助ADMENS矩陣進(jìn)行分析。ADMENS矩陣[7]（ArchitecturalDesignMethodhasbeenExtendedtoMethodSystem，架構(gòu)設(shè)計(jì)辦法已經(jīng)擴(kuò)展到辦法體系），又稱(chēng)為“需求層次--需求方面矩陣”。該矩陣分析法可以協(xié)助架構(gòu)師告別需求列表陳舊方式，順利過(guò)渡到二維需求觀，借此避免漏掉需求、并進(jìn)一步清理需求間關(guān)系和發(fā)現(xiàn)衍生需求。ADMENS二維矩陣進(jìn)行需求分析“四步法”重要由如下4個(gè)角度分析：需求構(gòu)造化，分析約束影響，擬定核心質(zhì)量以及擬定核心功能。從“需求定義了直接還是間接目的”角度，把需求劃分為3種類(lèi)型：1.功能需求：直接體現(xiàn)出各個(gè)需求目的規(guī)定。2.質(zhì)量屬性：由運(yùn)營(yíng)期質(zhì)量和開(kāi)發(fā)期質(zhì)量構(gòu)成。3.約束需求：由業(yè)務(wù)環(huán)境因素，使用環(huán)境因素以及技術(shù)環(huán)境因素構(gòu)成。從業(yè)務(wù)級(jí)需求，顧客級(jí)需求，開(kāi)發(fā)級(jí)需求三個(gè)角度對(duì)本系統(tǒng)需求進(jìn)行詳細(xì)分析，形成一種二維需求分析矩陣?？偨Y(jié)成下表：表2.1ADMENS矩陣廣義功能質(zhì)量約束業(yè)務(wù)級(jí)需求業(yè)務(wù)目的快、好、省技術(shù)性約束法規(guī)性約束技術(shù)趨勢(shì)競(jìng)爭(zhēng)因素與競(jìng)爭(zhēng)對(duì)手遺留系統(tǒng)集成原則性約束分批實(shí)行顧客級(jí)需求顧客需求運(yùn)營(yíng)期質(zhì)量顧客群特點(diǎn)顧客水平多國(guó)語(yǔ)言開(kāi)發(fā)級(jí)需求行為需求開(kāi)發(fā)期質(zhì)量開(kāi)發(fā)團(tuán)隊(duì)技術(shù)水平開(kāi)發(fā)團(tuán)隊(duì)磨合限度開(kāi)發(fā)團(tuán)隊(duì)分布狀況開(kāi)發(fā)團(tuán)隊(duì)業(yè)務(wù)知識(shí)管理：保密規(guī)定管理：產(chǎn)品規(guī)劃安裝、維護(hù)2.1.1業(yè)務(wù)級(jí)需求分析本段重要根據(jù)：包括客戶或者出資者要達(dá)到業(yè)務(wù)目的、所需要預(yù)期投入資金、項(xiàng)目工期進(jìn)度規(guī)定，以及要符合哪些原則規(guī)范、對(duì)哪些遺留系統(tǒng)進(jìn)行整合改造等約束條件，對(duì)論文中闡述系統(tǒng)進(jìn)行業(yè)務(wù)級(jí)需求分析。下面詳細(xì)闡述本系統(tǒng)需要重要考慮約束條件。(1)客戶業(yè)務(wù)目的以及業(yè)務(wù)愿景。1.軟件定位：基站管理軟件2.提供服務(wù)：提供一種通用管理配備平臺(tái)，對(duì)同一家公司不同類(lèi)型，不同硬件基站進(jìn)行配備。(2)客戶業(yè)務(wù)質(zhì)量1.兼容新老基站。由于技術(shù)改革，軟件必要兼容各種各樣新老基站，在滿足新基站配備規(guī)定同步要做到向后兼容。特別是基站硬件更新，各大無(wú)線通信公司當(dāng)前都在做整合研發(fā)，將老基站幾塊硬件板子功能集成到一塊硬件上創(chuàng)新研究，軟件變更需要跟硬件變更同步化，滿足硬件變更所帶來(lái)配備變更。2.易于變更配備。同一款基站，很有也許會(huì)配備不同射頻單元，或者有扇區(qū)變動(dòng)配備需求，需要提供一種簡(jiǎn)潔而又實(shí)用向?qū)?lái)滿足配備變更，同一種硬件配備也需要可以以便修改承載能力等，以達(dá)到資源運(yùn)用合理化。(3)技術(shù)原則3GPP，以及各大廠商自己制定原則。(4)對(duì)哪些遺留系統(tǒng)進(jìn)行整合基站零部件種類(lèi)繁多，各種型號(hào)基站之間硬件配備有較大區(qū)別，需要一種擴(kuò)展性很強(qiáng)系統(tǒng)來(lái)代替原有系統(tǒng)，以便將來(lái)產(chǎn)品進(jìn)一步更新?lián)Q代。2.1.2顧客級(jí)需求分析顧客及需求分析重要從如下幾種角度入手：顧客需要使用系統(tǒng)來(lái)完畢哪些工作，對(duì)質(zhì)量有哪些規(guī)定，顧客群及所處使用環(huán)境方面有哪些規(guī)定等條件來(lái)進(jìn)行顧客級(jí)需求分析。下面結(jié)合本系統(tǒng)進(jìn)行分析：（1）顧客使用系統(tǒng)完畢輔助工作該系統(tǒng)重要顧客人員是基站配備人員，她們使用該系統(tǒng)進(jìn)行基站配備，修改，刪除等操作。配備向?qū)Ю锩媾鋫漤?xiàng)有某些是有跟詳細(xì)硬件有關(guān)默認(rèn)值，尚有某些必要要顧客來(lái)配備，這些配備向?qū)О凑栈九鋫淞鞒谭指鞣N頁(yè)面進(jìn)行。該基站管理軟件重要提供四個(gè)配備向?qū)Ы缑妫?.機(jī)箱/機(jī)柜配備向?qū)В哼@某些配備硬件設(shè)備，除了基帶信號(hào)解決板配備，尚有某些硬件板，普通在交付客戶之前，在工廠就有某些燒制或者錄入默認(rèn)配備，插入機(jī)箱機(jī)柜中，因此需要在這里一并配備。在這個(gè)配備向?qū)Ю锩嫘枰鋫渲匾校哼x取Rbs類(lèi)型，配備默認(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修改配備文獻(xiàn)。該向?qū)е匾鋫漤?yè)面僅僅由一種文獻(xiàn)輸入頁(yè)面以及需要修改目錄成果構(gòu)成。4.導(dǎo)入導(dǎo)出，刪除向?qū)н@幾種功能也都是通過(guò)XML+SAX實(shí)現(xiàn)，因此該配備向?qū)?，輸?輸出僅僅為XML文獻(xiàn)。（2）質(zhì)量規(guī)定1.操作以便，界面和諧。2.系統(tǒng)具備很強(qiáng)健壯性，盡量避免系統(tǒng)崩潰。3.可以滿足不同配備狀況下，仍具備較強(qiáng)可靠性。（3）客戶需求約束配站工程師水平參差不齊，提供一種顧客和諧型，簡(jiǎn)潔配備界面，需要易于操作。2.1.3開(kāi)發(fā)級(jí)需求分析本段重要根據(jù)：開(kāi)發(fā)人員詳細(xì)需要實(shí)現(xiàn)什么產(chǎn)品，開(kāi)發(fā)維護(hù)期間對(duì)質(zhì)量有哪些考慮，開(kāi)發(fā)團(tuán)隊(duì)有無(wú)影響架構(gòu)狀況等因素來(lái)進(jìn)行需求分析。下面僅考慮本系統(tǒng)開(kāi)發(fā)中需要用到約束條件：（1）開(kāi)發(fā)人員需要實(shí)現(xiàn)目的一種顧客和諧型通信基站運(yùn)維綜合管理系統(tǒng)V1.0。需要提供如下基本服務(wù)：1.機(jī)柜機(jī)箱配備：需要實(shí)現(xiàn)機(jī)箱機(jī)柜配備，以及出廠時(shí)安裝其她硬件板所有配備。機(jī)箱機(jī)柜普通會(huì)提供一系列插槽，有關(guān)硬件在出廠時(shí)候分別安裝在詳細(xì)插槽中，一并交付，因此這些硬件板需要跟機(jī)柜機(jī)箱配備一同進(jìn)行配備。2.基站配備：重要負(fù)責(zé)射頻單元硬件配備，輔助單元（例如電扇、電源之類(lèi)）配備，以及天線系統(tǒng)有關(guān)設(shè)備配備，這某些硬件大多具備可以頻繁更換特性，因此這某些代碼構(gòu)造需要盡量松散，耦合度越低越好。3.導(dǎo)出/刪除功能：導(dǎo)出功能可以導(dǎo)出當(dāng)前Rbs配備XML文獻(xiàn)，可以讓咱們?cè)跍y(cè)試環(huán)境中創(chuàng)立相似顧客配備，也可以給其她站點(diǎn)進(jìn)行相似配備。刪除功能可以刪除當(dāng)前Rbs中所有不重要配備，重新配站狀況下可以使用。本系統(tǒng)使用SAX技術(shù)來(lái)解析XML文獻(xiàn)，因此在這里需要提供DTD文獻(xiàn)規(guī)范XML文獻(xiàn)格式。4.修改功能：可以提供應(yīng)基站操作人員在不斷止Rbs狀況下，修改基站配備功能。重要有射頻單元修改，天線修改，扇區(qū)增長(zhǎng)、刪除，社區(qū)增長(zhǎng)、刪除等等功能。（2）開(kāi)發(fā)期間質(zhì)量約束1.以測(cè)試驅(qū)動(dòng)原則進(jìn)行開(kāi)發(fā)，盡量做到步步可測(cè)。2.代碼實(shí)現(xiàn)時(shí)候盡量多用設(shè)計(jì)模式原則，減少代碼耦合度，提高可擴(kuò)展性。綜上所述，總結(jié)得到ADMENS矩陣如下表所示：表2.2ADMENS矩陣（需求層次--需求方面矩陣）功能質(zhì)量約束業(yè)務(wù)級(jí)需求業(yè)務(wù)目的及業(yè)務(wù)愿景軟件定位：基站管理軟件提供服務(wù)：對(duì)各種類(lèi)型，各種硬件提供一種通用性配站軟件商業(yè)質(zhì)量兼容新老基站配備容錯(cuò)率高商業(yè)約束基站零部件種類(lèi)繁多各種型號(hào)基站，硬件之間有較大區(qū)別需要較強(qiáng)可擴(kuò)展可擴(kuò)展性，以便將來(lái)產(chǎn)品更新?lián)Q代顧客級(jí)需求潛在顧客配站工程師運(yùn)營(yíng)期質(zhì)量操作簡(jiǎn)樸，易于上手多用性顧客約束工程師水平層次不齊，提供某些必要提示防御性編程，檢測(cè)未知配備錯(cuò)誤開(kāi)發(fā)級(jí)需求開(kāi)發(fā)期質(zhì)量可擴(kuò)展性步步可測(cè)開(kāi)發(fā)方約束只有一人時(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)邏輯架構(gòu)，功能模塊以及魯棒性設(shè)計(jì)三個(gè)角度來(lái)闡述該基站管理軟件系統(tǒng)設(shè)計(jì)，然后根據(jù)本系統(tǒng)架構(gòu)層次來(lái)詳細(xì)闡述每一層設(shè)計(jì)思路以及實(shí)現(xiàn)方略。2.2.1系統(tǒng)總體概要設(shè)計(jì)本小節(jié)僅僅是對(duì)系統(tǒng)總體架構(gòu)概要設(shè)計(jì)簡(jiǎn)介，不對(duì)詳細(xì)細(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)圖見(jiàn)圖2.1。該系統(tǒng)設(shè)計(jì)思路以公司應(yīng)用架構(gòu)模式中流行三層架構(gòu)為基本，依照本系統(tǒng)需求分析而衍生出來(lái)五層架構(gòu)，每一層都依托在其下層之上來(lái)構(gòu)建，上層使用下層定義各種接口，而下層對(duì)上層如何調(diào)用一無(wú)所知。此外，每一層對(duì)自己上層隱藏其實(shí)現(xiàn)細(xì)節(jié)。各層之間盡量做到相對(duì)透明[8][9]。在體現(xiàn)層中使用了當(dāng)前最流行MVC框架模式進(jìn)行設(shè)計(jì)，在邏輯實(shí)現(xiàn)層中，參照公司級(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ì)物理硬件一一相應(yīng)，并且與MO進(jìn)行匯集解決，下層邏輯數(shù)據(jù)層則是相應(yīng)所在公司ManageObject架構(gòu)，使用某些簡(jiǎn)樸POJO來(lái)構(gòu)建數(shù)據(jù)庫(kù)，同步可以使用這些數(shù)據(jù)類(lèi)承載本系統(tǒng)配備信息，與其她子系統(tǒng)進(jìn)行數(shù)據(jù)通信。圖2.1基站軟件系統(tǒng)邏輯架構(gòu)多層次架構(gòu)體系，使得系統(tǒng)靈活性極大增強(qiáng)，每層僅僅對(duì)其上下層負(fù)責(zé)，減少了系統(tǒng)耦合度，可以將一種新硬件需求給軟件代碼帶來(lái)影響在最小范疇內(nèi)擴(kuò)散，較好滿足頻繁增長(zhǎng)新特性需求。同步在每層之間按模塊劃分方略和設(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á)方式和行繪圖為等角色把一種應(yīng)用系統(tǒng)各個(gè)某些解耦分割開(kāi)來(lái)。使用該模式，可以將本系統(tǒng)中圖形界面繪制跟圖形界面控制分開(kāi)，較好滿足了設(shè)計(jì)目的[11]。同步由于該基站管理配備系統(tǒng)配備向?qū)ы?yè)面中有許多共同插件，可以將將視圖端以及控制器端共有某些抽象到她們父類(lèi)，在父類(lèi)中實(shí)現(xiàn)對(duì)頁(yè)面控制等共有邏輯，這樣設(shè)計(jì)思想體現(xiàn)出了軟件設(shè)計(jì)模式中里氏代換原則以及依賴(lài)倒轉(zhuǎn)原則。子類(lèi)繼承時(shí)通過(guò)裝飾模式等設(shè)計(jì)辦法來(lái)實(shí)現(xiàn)各自頁(yè)面不同視圖，加減頁(yè)面[12]都不會(huì)對(duì)本來(lái)架構(gòu)有影響，滿足開(kāi)閉原則，相應(yīng)視圖以及控制器僅僅通過(guò)模型端進(jìn)行交互，滿足迪米特法則[13][14]。邏輯控制層部是整個(gè)系統(tǒng)中對(duì)配備行為進(jìn)行控制地方，同步也負(fù)責(zé)Rbs對(duì)象創(chuàng)立等工作，該層分兩層實(shí)現(xiàn)：功能模塊層設(shè)計(jì)概要：該層重要采用建造模式來(lái)實(shí)現(xiàn)，以功能模塊層需求為根據(jù)分別建造，提供各種各樣產(chǎn)品。相應(yīng)于該管理軟件功能，給出其相相應(yīng)類(lèi)來(lái)提供目的功能模塊，組裝構(gòu)建等細(xì)節(jié)等實(shí)現(xiàn)某些則對(duì)上層透明，該層并不負(fù)責(zé)細(xì)節(jié)邏輯實(shí)現(xiàn)，而是某些實(shí)現(xiàn)功能組合，詳細(xì)實(shí)現(xiàn)通過(guò)代理模式思想交由下層負(fù)責(zé)?；诖?，該層重要是某些功能等創(chuàng)立組合控制接口，通過(guò)這些接口來(lái)調(diào)用下層邏輯實(shí)現(xiàn)層，并委托下層來(lái)實(shí)現(xiàn)需要邏輯。每一種功能相應(yīng)一種建造類(lèi)，通過(guò)建造模式，可以做到復(fù)用邏輯實(shí)現(xiàn)層零件產(chǎn)品，同步各功能模塊之間相對(duì)保持透明，滿足迪米特法則。邏輯實(shí)現(xiàn)層設(shè)計(jì)概要：該層建立一種所有由對(duì)象構(gòu)成領(lǐng)域?qū)?，?lái)對(duì)目的對(duì)象業(yè)務(wù)建模，其中每一種對(duì)象僅僅負(fù)責(zé)一種單一功能實(shí)現(xiàn)。由于業(yè)務(wù)詳細(xì)行為是經(jīng)常變化，因而易于修改和測(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)行讀寫(xiě)等操作，實(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ù)類(lèi)進(jìn)行讀寫(xiě)操作。數(shù)據(jù)層某些：該層分為2層，上層為物理數(shù)據(jù)層，與詳細(xì)基站物理硬件一一相應(yīng)，下層為POJO層，作為與整個(gè)UTRAN系統(tǒng)接口，將系統(tǒng)系統(tǒng)高層定義MO與本軟件系統(tǒng)數(shù)據(jù)進(jìn)行一種一一映射。普通為了滿足硬件構(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ì)象，與真正物理硬件一一相應(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)品功能模塊構(gòu)造產(chǎn)品功能模塊構(gòu)造見(jiàn)圖2.2。顧客需要先選定Rbs基站型號(hào)，該系統(tǒng)則會(huì)依照顧客選取生成相應(yīng)基站配備界面，接下來(lái)就可以進(jìn)行機(jī)箱機(jī)柜cabinet、站點(diǎn)site、扇區(qū)、天線系統(tǒng)等基站重要硬件配備。該管理軟件同步提供了修改modify/導(dǎo)出export/刪除delete等功能，修改modify功能可以在不重啟基站狀況下，調(diào)節(jié)基站扇區(qū)、載波配備等設(shè)備負(fù)載量等配備信息；導(dǎo)出export功能則可以將當(dāng)前基站配備以XML格式一次導(dǎo)出，以便下次配站使用；刪除Delete功能則是可以將基站當(dāng)前配備刪除，以便顧客重新配站。圖2.2產(chǎn)品功能模塊構(gòu)造圖系統(tǒng)概要設(shè)計(jì)魯棒性分析系統(tǒng)概要設(shè)計(jì)魯棒圖見(jiàn)圖2.3。從圖中可以看到，當(dāng)工程師選定了Rbs基站類(lèi)型后來(lái)，會(huì)有一種相相應(yīng)工廠辦法，生成該Rbs基站相相應(yīng)實(shí)例，該實(shí)例以創(chuàng)立最大化方式，初始化該基站所有功能服務(wù)，并且保存該類(lèi)型基站所特有數(shù)據(jù)邏輯。該基站實(shí)例對(duì)象采用單例模式，在整個(gè)配備過(guò)程中只有這一種實(shí)例對(duì)象，以便記錄基站配備信息以及對(duì)基站配備信息修改信息。接下來(lái)各種功能實(shí)現(xiàn)某些重要是對(duì)Rbs基站配備數(shù)據(jù)進(jìn)行操作，因此可以直接對(duì)這個(gè)單例對(duì)象進(jìn)行操作。各功能模塊之間都做了較好隔離，控制某些相對(duì)獨(dú)立，每個(gè)功能對(duì)于其她功能沒(méi)有影響，一種地方出錯(cuò)了并不影響其她功能使用，有較好魯棒性。圖2.3系統(tǒng)概要設(shè)計(jì)魯棒圖2.2.2POJO層設(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ú)立，僅僅依賴(lài)數(shù)據(jù)傳遞進(jìn)行通信。MO就是數(shù)據(jù)交互核心，MO承載了各自子系統(tǒng)數(shù)據(jù)信息。一種MO中普通會(huì)包括兩類(lèi)參數(shù)：屬性，Attributes：跟MO抽象資源有關(guān)參數(shù)變量，這些資源可以在配備時(shí)候給她們賦值，資源狀態(tài)也可以通過(guò)讀取這些值來(lái)獲得。行為，Actions：表達(dá)所能對(duì)一種MO采用行動(dòng)，例如加鎖，刪除等。本文所要實(shí)現(xiàn)通信基站運(yùn)維綜合管理系統(tǒng)V1.0，事實(shí)上就是采用一系列Java類(lèi)來(lái)相應(yīng)MO，將配備信息存到MO中，通過(guò)配備這些MOattributes和actions來(lái)實(shí)現(xiàn)對(duì)基站配備，最后講收集到所有配備信息，發(fā)送到中央解決單元中。圖2.4是一種采用了MO模型Rbs基站示意圖：圖2.4Rbs基站MOM模型上圖中矩形代表Rbs節(jié)點(diǎn)整體，正面是Rbs從系統(tǒng)角度所能看到資源，側(cè)面則是對(duì)Rbs資源抽象：MOM（MOModel）。從圖上可以看出：MO模型即是對(duì)Rbs系統(tǒng)角度所能看到資源另一種表達(dá)所構(gòu)建成模型：抽象成為一系列可以管理對(duì)象MO，從一系列對(duì)象角度來(lái)看Rbs資源。表2.3MO取自愛(ài)立信Rbs基站，6601型號(hào)遠(yuǎn)程基站，slot信息表。表2.3Slot信息表PossibleparentsubrackPossiblechildrenAuxPlugInUnitBbifBoardPlugInUnitActionsupdateConfiguration()AttributesactiveSwAllocationproductDatareservedBySlotIdslotNumberslotStateSlot：是對(duì)機(jī)框中插槽資源一種抽象。從該表中可以看出：slot爸爸節(jié)點(diǎn)只有一種，機(jī)框subrack；也許孩子節(jié)點(diǎn)有3個(gè)，可插入插槽單元PlugInUnit，例如基帶板，射頻板，信號(hào)過(guò)濾板等；遠(yuǎn)程單元AuxPlugInUnit，例如傾角調(diào)節(jié)器RET，塔放TMA等；一種基帶板與射頻單元交互接口BbifBoard。該MOaction僅有一種：updateConfiguration。表達(dá)如果該基站是自動(dòng)配備，則該action會(huì)觸發(fā)該插槽下硬件單元自動(dòng)配備行為。6個(gè)Attributes分別表達(dá)：activeSwAllocation表達(dá)此刻該插槽與否有PlugInUnit在使用，如果沒(méi)有PlugInUnit在次插槽被配備使用，則該屬性值為空。productData屬性描述當(dāng)前插入單元信息，該屬性一旦賦值，則無(wú)論其插入硬件板與否工作，該值都不會(huì)變，該屬性值只有在slot換新硬件板時(shí)候才會(huì)變化。reservedBy該屬性以一種列表形式存在，是儲(chǔ)備這個(gè)MO所有MO一種列表。SlotId，該屬性值是用來(lái)構(gòu)成RDN。slotNumber該屬性值從左往右開(kāi)始數(shù)起，從1開(kāi)始，用來(lái)表達(dá)插槽位置。slotState屬性用來(lái)表白該插槽狀態(tài)。該MO是在其爸爸MO創(chuàng)立時(shí)候創(chuàng)立，并且不能被刪除。該MO插槽數(shù)目是在其爸爸節(jié)點(diǎn)subrack中定義。MO查找：RDN與LDNRDN：RelativeDistinguishedName，相對(duì)標(biāo)記名。RDN命名跟該MO爸爸節(jié)點(diǎn)有關(guān)。這個(gè)屬性值在她被建立時(shí)候就定義好了，并且不能變化。LDN：LocalDistinguishedName，本地專(zhuān)有名稱(chēng)。由該Rbs節(jié)點(diǎn)中一系列RDN所形成一種獨(dú)一無(wú)二名字。RDN在查找父子節(jié)點(diǎn)MO時(shí)候使用，LDN在全局查找MO使用。圖2.5是RNC中一種MO構(gòu)造，由下可以看出RDN跟LDN如何命名，以及LDN是如何由RDN所形成：圖2.5一種使用RND/LDNMO構(gòu)造由上圖可以看出RncFunction這個(gè)MORDN={RncFunctionId="0"}，由于RncFunction自身就是根節(jié)點(diǎn)，因此LDN等于RDN。UtranCell這個(gè)MORDN={UtranCellId="100"}，LDN等于該MORDN加上這個(gè)MO所有父節(jié)點(diǎn)RDN，因此UtranCellLDN={RncFunctionId="0"，UtranCellId="100"}，同理，Rach這個(gè)MORDN={RachId="0"}，LDN={RncFunctionId="0"，UtranCellId="100"，RachId="0"}。表中MORDN命名規(guī)則：從機(jī)框最左邊插槽開(kāi)始，第一種插槽slot為：slot=1。因而該MORDN={SlotId="1"}。MO映射機(jī)制MO映射機(jī)制采用POJO模式方略。從高層系統(tǒng)規(guī)定定義MO到該軟件配備管理系統(tǒng)數(shù)據(jù)庫(kù)所采用映射技術(shù)由POJO模式實(shí)現(xiàn)。POJO：PlainOldJavaObject，簡(jiǎn)樸Java對(duì)象。POJO是一種簡(jiǎn)樸普通Java對(duì)象，它不包括業(yè)務(wù)邏輯或者持久化邏輯等，沒(méi)有從任何類(lèi)繼承，不擔(dān)當(dāng)任何特殊角色，也沒(méi)有實(shí)現(xiàn)任何接口，更沒(méi)有被其她框架侵入Java對(duì)象。每一種MO由一種POJO來(lái)負(fù)責(zé)實(shí)現(xiàn)，由一種詳細(xì)Java類(lèi)來(lái)代表一種MO，Java中字段設(shè)立成私有，分別表達(dá)MO中attribute跟action。一系列g(shù)et/set辦法來(lái)負(fù)責(zé)數(shù)據(jù)讀寫(xiě)。2.2.3物理數(shù)據(jù)層設(shè)計(jì)POJO層相應(yīng)數(shù)據(jù)庫(kù)數(shù)據(jù)，MO數(shù)據(jù)，僅僅只是系統(tǒng)高層對(duì)Rbs資源一種邏輯抽象，并不完全相應(yīng)詳細(xì)硬件。整個(gè)UTRAN系統(tǒng)中，各個(gè)子系統(tǒng)之間通信，是需要MO來(lái)傳遞數(shù)據(jù)，而咱們對(duì)Rbs配備，事實(shí)上僅僅是對(duì)詳細(xì)一種類(lèi)型Rbs詳細(xì)硬件配備，這兩者之間有某些區(qū)別。因此需要有一層數(shù)據(jù)層，來(lái)實(shí)現(xiàn)邏輯數(shù)據(jù)MO跟詳細(xì)硬件參數(shù)配備映射關(guān)系。如下將從MO樹(shù)建立，物理數(shù)據(jù)建立和物理數(shù)據(jù)實(shí)現(xiàn)方略三個(gè)方面詳細(xì)闡述該層重要設(shè)計(jì)環(huán)節(jié)。MO樹(shù)建立由于在POJO層使用了POJO數(shù)據(jù)，因此僅僅只有g(shù)et/set辦法，并沒(méi)有任何關(guān)系，也沒(méi)有任何邏輯，需要在這一層給MO數(shù)據(jù)建立關(guān)系。這樣不但可以實(shí)現(xiàn)各個(gè)MO之間先后順序，父子關(guān)系，依賴(lài)關(guān)系等邏輯，同步還可以使得邏輯控制層對(duì)MO數(shù)據(jù)管理、使用更加以便。圖2.6是系統(tǒng)高層定義MO構(gòu)造樹(shù)一某些：圖2.6MO構(gòu)造樹(shù)以系統(tǒng)高層定義MO樹(shù)為基本，本基站管理配備系統(tǒng)需要構(gòu)建樹(shù)示意圖如圖2.7所示：圖2.7MO構(gòu)造示意圖所有MO均有一種共同根節(jié)點(diǎn)RootNode，由上圖信息可知，樹(shù)根節(jié)點(diǎn)為ManagedElement這個(gè)對(duì)象，在這之下依次掛著各個(gè)MO。建立MO樹(shù)規(guī)則是依照系統(tǒng)對(duì)MO構(gòu)造圖定義以及MO定義信息表中也許父類(lèi)，也許子類(lèi)信息來(lái)建立：在本基站管理軟件系統(tǒng)Java類(lèi)中，用3個(gè)類(lèi)來(lái)實(shí)現(xiàn)MO樹(shù)創(chuàng)立，如圖2.8所示：圖2.8MO樹(shù)代碼構(gòu)造Node類(lèi)提供建立樹(shù)某些最基本辦法，如getDepth、getChild、getParent辦法等。MONode類(lèi)繼承了Node類(lèi)，在此基本上擴(kuò)展了某些辦法，提供關(guān)于MO屬性某些操作，例如lockable，deletable辦法。MOProxyNode類(lèi)同樣繼承自Node類(lèi)，這個(gè)類(lèi)跟MoNode不同，擴(kuò)展辦法重要是用來(lái)獲取這個(gè)類(lèi)，以及獲取有關(guān)MO。物理數(shù)據(jù)建立這一層重要目就是：建立一種相應(yīng)詳細(xì)類(lèi)型Rbs，詳細(xì)硬件配備數(shù)據(jù)層。這一層重要是將抽象管理對(duì)象MO數(shù)據(jù)與詳細(xì)硬件配備數(shù)據(jù)聯(lián)系起來(lái)，基站軟件管理配備系統(tǒng)從顧客角度來(lái)看，僅僅是對(duì)詳細(xì)硬件進(jìn)行配備，而并不是對(duì)抽象MO配備，因此需要一層數(shù)據(jù)層，來(lái)進(jìn)行抽象數(shù)據(jù)與詳細(xì)數(shù)據(jù)轉(zhuǎn)換。下面以射頻單元硬件為例，分析本通信基站運(yùn)維綜合管理系統(tǒng)V1.0是如何將抽象管理對(duì)象MO數(shù)據(jù)與詳細(xì)硬件配備數(shù)據(jù)進(jìn)行轉(zhuǎn)換。圖2.9是愛(ài)立信一種遠(yuǎn)程射頻單元硬件實(shí)例圖：圖2.9愛(ài)立信遠(yuǎn)程射頻單元硬件實(shí)例從圖中可以看出，這個(gè)遠(yuǎn)程射頻單元已經(jīng)進(jìn)行了較好封裝，其實(shí)內(nèi)部集成了上行信號(hào)解決板，下行信號(hào)解決板，空口等硬件，該硬件外部則有連接基帶信號(hào)解決板接口以及連接天線接口等，這些硬件詳細(xì)分派資源不需要本系統(tǒng)進(jìn)行進(jìn)一步配備，在下層子系統(tǒng)會(huì)有針對(duì)細(xì)節(jié)配備，但是遠(yuǎn)程射頻單元型號(hào)，上下行信號(hào)解決板、空口等硬件數(shù)目，外部接口連接信息，與否發(fā)射分級(jí)，與否串聯(lián)等信息，這些配備信息都是需要在配備這個(gè)遠(yuǎn)程射頻單元時(shí)候同步配備。而在系統(tǒng)高層定義MO里面并沒(méi)有一種詳細(xì)MO與該硬件相應(yīng)，統(tǒng)一歸類(lèi)為AuxPlugInUnit這個(gè)MO，僅僅通過(guò)auType這個(gè)屬性來(lái)區(qū)別詳細(xì)類(lèi)型。MO定義高度抽象化，不會(huì)涉及細(xì)節(jié)，或者詳細(xì)硬件。AuxPlugInUnit信息如表2.4所示：表2.4AuxPlugInUnit信息表ActionsreadRepairDelivNote()reconfigureProgramPrepare()restartAuxUnit()AttributesadministrativeStatealramStatusauTypeAuxPlugInUnitIdpiuTypeproductNumberreservedByserialNumberuniqueHwIdunitType由上表可以看出，這個(gè)MO跟實(shí)際硬件之間并不完全匹配，例如與外部其她硬件接口連線某些，沒(méi)有任何屬性可以用來(lái)保存與基帶信號(hào)解決板連接配備或者與天線單元連接配備，而保存這個(gè)連接配備信息屬性卻屬于另一種MO，DigitalCable中。依照詳細(xì)產(chǎn)品信息，該硬件實(shí)際使用到所有MO如表2.5所示：表2.5遠(yuǎn)程射頻單元硬件使用MO實(shí)際硬件抽象MO遠(yuǎn)程射頻單元DigitalCableAuxPlugInUnitSectorAntennaAntennaBranchAntFeederCable于是咱們可以使用合成/聚合復(fù)用原則，建立一種Java類(lèi)，其中包括了屬于這個(gè)硬件所有MO一種匯集，這樣可以通過(guò)配備這個(gè)類(lèi)來(lái)配備這個(gè)硬件，同步間接配備了有關(guān)MO。該層具備十分重要意義，是將抽象管理對(duì)象MO與詳細(xì)硬件實(shí)例緊密聯(lián)系起來(lái)橋梁。基站軟件管理配備系統(tǒng)僅僅是對(duì)詳細(xì)硬件進(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è)方略。下面分別詳細(xì)闡述這兩種方略以及在本系統(tǒng)中采用因素：合成/聚合復(fù)用原則：又叫做合成復(fù)用原則（CRP），指在一種新對(duì)象里面使用某些已有對(duì)象，使之成為新對(duì)象一某些；新對(duì)象通過(guò)向這些對(duì)象委派達(dá)到復(fù)用已有功能目。使用合成/聚合復(fù)用原則因素有：新對(duì)象存取成分對(duì)象唯一辦法是通過(guò)成分對(duì)象接口。本層數(shù)據(jù)給下層MO數(shù)據(jù)層賦值只會(huì)調(diào)用POJO類(lèi)中set辦法。這種復(fù)用支持包裝。這種復(fù)用所需依賴(lài)較少。不同于繼承實(shí)現(xiàn)，這樣實(shí)現(xiàn)耦合度極低，有助于數(shù)據(jù)靈活組合，利于架構(gòu)解耦。一旦有新硬件或者硬件改動(dòng)，變化起來(lái)比較以便。每一種新類(lèi)可以將重點(diǎn)集中在一種任務(wù)上。本層物理數(shù)據(jù)層每一種類(lèi)重要任務(wù)就是將MO層POJO類(lèi)進(jìn)行集成，以匹配真實(shí)物理硬件。合成模式：屬于對(duì)象構(gòu)造模式，有時(shí)候又叫做“某些--整體”模式。合成模式將對(duì)象組織到樹(shù)構(gòu)造中，可以用來(lái)描述整體與某些關(guān)系。這樣設(shè)計(jì)使得咱們可以找到一種無(wú)需一對(duì)多關(guān)系即可獲得一對(duì)多行為代替方式。使用合成模式重要因素有：有某些物理硬件可以做進(jìn)一步集成，集成化是將來(lái)無(wú)線基站硬件趨勢(shì)，在該層就進(jìn)行必要數(shù)據(jù)集成，可以較好滿足將來(lái)需求變化。在某些集成了硬件板解決上，上層邏輯層不直接調(diào)用不直接配備數(shù)據(jù)類(lèi)，而是通過(guò)調(diào)用實(shí)際配備數(shù)據(jù)類(lèi)來(lái)進(jìn)行委派。這樣可以增長(zhǎng)代碼復(fù)用性。在物理數(shù)據(jù)層就對(duì)數(shù)據(jù)進(jìn)行必要集成，當(dāng)對(duì)集成硬件進(jìn)行數(shù)據(jù)配備時(shí)候，可以通過(guò)父類(lèi)進(jìn)行數(shù)據(jù)遍歷，而不并每一次都去遍歷所有子類(lèi)，這樣可以減少數(shù)據(jù)配備中錯(cuò)誤。合成模式UML構(gòu)造圖[18]如圖2.10所示：圖2.10合成模式該圖是合成模式中樹(shù)構(gòu)造一種靜態(tài)構(gòu)造。最上方浮現(xiàn)父類(lèi)節(jié)點(diǎn)，左下方是一種樹(shù)葉節(jié)點(diǎn)，右下方是一種樹(shù)枝節(jié)點(diǎn)，可以具有其她節(jié)點(diǎn)，如果沒(méi)有其她節(jié)點(diǎn)，則也退化成樹(shù)葉節(jié)點(diǎn)。由于本層數(shù)據(jù)層設(shè)計(jì)只是匯集下層POJO層中MO數(shù)據(jù)，使之與實(shí)際物理硬件相應(yīng)，因此本系統(tǒng)只需要使用二層樹(shù)構(gòu)造合成模式即可，即父節(jié)點(diǎn)作為物理數(shù)據(jù)層中數(shù)據(jù)類(lèi)使用，子節(jié)點(diǎn)取自下層POJO數(shù)據(jù)層。本層客戶端是上層邏輯控制層[19]。在本層物理數(shù)據(jù)層架構(gòu)搭建時(shí)候，使用合成模式思想，但是并不完全依照合成模式來(lái)構(gòu)建，由于本系統(tǒng)設(shè)計(jì)一種重要目就是給本來(lái)系統(tǒng)解耦合，盡量做到低耦合，并且這兩層數(shù)據(jù)之間并沒(méi)有強(qiáng)耦合關(guān)系，因此不需要繼承方式來(lái)實(shí)現(xiàn)，而是將下層數(shù)據(jù)層中類(lèi)以合成/匯集方式使用。以上文中浮現(xiàn)遠(yuǎn)程射頻單元為例，根據(jù)合成模式思想，設(shè)計(jì)如圖2.11所示：圖2.11遠(yuǎn)程射頻單元匯集模式在該圖中，處在父節(jié)點(diǎn)位置就是本層需要設(shè)計(jì)數(shù)據(jù)類(lèi)，遠(yuǎn)程射頻單元類(lèi)，5個(gè)子節(jié)點(diǎn)由表2.5中可以得到。跟合成模式不同，在這里并不使用繼承，而是使用匯集來(lái)實(shí)現(xiàn)，遠(yuǎn)程射頻單元以匯集方式將這五個(gè)POJO類(lèi)匯集到父類(lèi)中，使之成為一種整體。這樣同樣可以做到在向上層提供數(shù)據(jù)服務(wù)時(shí)候，以一種整體行為，以一對(duì)一關(guān)系來(lái)進(jìn)行交互，而不是老式一對(duì)多方式。這樣在邏輯控制層中，可以通過(guò)僅僅調(diào)用這一種數(shù)據(jù)類(lèi)，就可以達(dá)到同步調(diào)用這5個(gè)MO類(lèi)數(shù)據(jù)功能。2.2.4邏輯實(shí)現(xiàn)層設(shè)計(jì)本節(jié)重要簡(jiǎn)介了該層實(shí)現(xiàn)方略，同步結(jié)合本層重要功能需求，詳細(xì)分析了采用享元模式因素。本層只負(fù)責(zé)簡(jiǎn)樸單一行為邏輯，即每一種類(lèi)只負(fù)責(zé)一種邏輯，邏輯組合則交給上層[20][21]。邏輯實(shí)現(xiàn)層實(shí)現(xiàn)方略：享元模式。享元模式是對(duì)象構(gòu)造模式。享元模式以共享方式高效支持大量細(xì)粒度對(duì)象。享元對(duì)象區(qū)別內(nèi)蘊(yùn)狀態(tài)和外蘊(yùn)狀態(tài)。一種內(nèi)蘊(yùn)狀態(tài)是存儲(chǔ)在享元對(duì)象內(nèi)部，并且是不會(huì)隨著環(huán)境變化而有所不同。因而一種享元可以具備內(nèi)蘊(yùn)狀態(tài)并且內(nèi)蘊(yùn)狀態(tài)可以共享。一種外蘊(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是享元模式構(gòu)造示意圖：圖2.12享元模式在上圖中，享原工廠負(fù)責(zé)創(chuàng)立和管理享元對(duì)象。這個(gè)角色必要保證享元對(duì)象可以被系統(tǒng)恰本地共享。當(dāng)一種對(duì)象調(diào)用一種享元對(duì)象時(shí)候，享元工廠會(huì)檢查系統(tǒng)中與否已有了一種符合規(guī)定享元對(duì)象。如果已有了，享元工廠角色就應(yīng)當(dāng)提供這個(gè)已有享元對(duì)象，如果系統(tǒng)中沒(méi)有一種恰當(dāng)享元對(duì)象話，享元工廠角色就應(yīng)當(dāng)創(chuàng)立一種適當(dāng)享元對(duì)象。抽象享元角色是所有享元類(lèi)超類(lèi)，為這些類(lèi)定義出需要實(shí)現(xiàn)公共接口，外蘊(yùn)狀態(tài)可以在該類(lèi)辦法中以入?yún)⑿问絺魅搿Ｔ敿?xì)享元對(duì)象角色負(fù)責(zé)內(nèi)蘊(yùn)享元?jiǎng)?chuàng)立和管理享元對(duì)象。不可共享享元角色負(fù)責(zé)用來(lái)實(shí)現(xiàn)那些不可以共享享元?jiǎng)?chuàng)立和管理。結(jié)合本層功能，使用享元模式理由：1.一種系統(tǒng)有大量對(duì)象。本系統(tǒng)中，每一種MO都會(huì)相應(yīng)一種POJO，同步在物理數(shù)據(jù)層中進(jìn)一步合成，因此會(huì)浮現(xiàn)大量數(shù)據(jù)對(duì)象。2.這些對(duì)象耗費(fèi)大量?jī)?nèi)存。一種功能服務(wù)在邏輯控制層會(huì)被分解成為諸多簡(jiǎn)樸邏輯，每一種簡(jiǎn)樸邏輯都相應(yīng)配備最基本物理硬件數(shù)據(jù)，這些物理硬件數(shù)據(jù)類(lèi)普通由某些POJO類(lèi)合成，因此一次配備也許會(huì)需要加載許多類(lèi)，耗費(fèi)大量?jī)?nèi)存。3.這些對(duì)象狀態(tài)中大某些都可以外部化。4.這些對(duì)象可以按照內(nèi)蘊(yùn)狀態(tài)提成諸多組，當(dāng)把外蘊(yùn)對(duì)象從對(duì)象中剔除時(shí)，每一組都可以僅用一種對(duì)象代替。5.軟件系統(tǒng)不依賴(lài)于這些對(duì)象身份，這些對(duì)象是不可辨別。軟件系統(tǒng)在顧客看來(lái)只需要依賴(lài)于RBS對(duì)象類(lèi)，而下層是如何實(shí)現(xiàn)是不需要懂得，并且也不需要辨認(rèn)。6.系統(tǒng)需要維護(hù)一種記錄了系統(tǒng)已有所有享元表。2.2.5功能模塊層設(shè)計(jì)該層是全文核心某些，本文設(shè)計(jì)與實(shí)現(xiàn)通信基站運(yùn)維綜合管理系統(tǒng)V1.0所要提供功能服務(wù)都在本層中組合實(shí)現(xiàn)，同步本軟件系統(tǒng)實(shí)際配備Rbs類(lèi)也將在本層創(chuàng)立。本小節(jié)總共分五個(gè)某些，一方面簡(jiǎn)介了本層在本系統(tǒng)中位置以及所起作用，另一方面按順序簡(jiǎn)介每一種功能，然后簡(jiǎn)介該層設(shè)計(jì)原理以及設(shè)計(jì)時(shí)候所使用設(shè)計(jì)模式，接著詳細(xì)簡(jiǎn)介Rbs基站類(lèi)設(shè)計(jì)思路以及實(shí)現(xiàn)方略，最后對(duì)整個(gè)邏輯控制層做一種簡(jiǎn)要總結(jié)。本層在本系統(tǒng)中位置以及所起作用本文描述基站管理軟件配備系統(tǒng)所需要提供功能服務(wù)在本層劃分，產(chǎn)品功能構(gòu)造圖中功能在本層中體現(xiàn)。本系統(tǒng)通過(guò)這個(gè)功能模塊層，來(lái)定義應(yīng)用程序邊界，類(lèi)似于服務(wù)層，在功能模塊層中建立一組可用操作集合，并在每個(gè)操作內(nèi)部協(xié)調(diào)應(yīng)用程序響應(yīng)，在這一層，將該系統(tǒng)所能提供服務(wù)，按照功能劃分，獨(dú)立成為各個(gè)子模塊，同步在這一層封裝了該系統(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ì)依照需求分析，需要一種支持開(kāi)閉原則設(shè)計(jì)模式，本系統(tǒng)采用工廠辦法模式進(jìn)行設(shè)計(jì)。每一種詳細(xì)Rbs對(duì)象都會(huì)持有該Rbs所支持相應(yīng)功能服務(wù)，如果該Rbs基站不支持服務(wù)，則相應(yīng)Rbs實(shí)例中不應(yīng)當(dāng)包括此類(lèi)服務(wù)。圖2.13軟件系統(tǒng)平面圖該層定義了從顧客界面接口所能看到所有功能集合，它封裝了應(yīng)用邏輯業(yè)務(wù)邏輯、事務(wù)控制及其操作實(shí)現(xiàn)中響應(yīng)協(xié)調(diào)等[24]。如圖2.13所示。功能模塊層較好封裝了下層細(xì)節(jié)解決。顧客只關(guān)懷一類(lèi)Rbs基站具備哪一類(lèi)功能，提供了哪些配備服務(wù)，并不需要懂得這些功能與服務(wù)是如何實(shí)現(xiàn)。功能模塊層將這些功能模塊化，Rbs基站類(lèi)詳細(xì)實(shí)現(xiàn)就是依賴(lài)于各個(gè)功能模塊而搭建。Rbs基站配備從顧客角度來(lái)看，是擁有何種配備功能，向顧客提供了何種配備服務(wù)基站，顧客只需要懂得如何配備這些服務(wù)即可。本系統(tǒng)在通過(guò)GUI界面收集到了顧客配備信息數(shù)據(jù)后來(lái)，通過(guò)該層轉(zhuǎn)換與下層進(jìn)行交互，顧客自身并不需要關(guān)懷這些，因此需要一種功能模塊層來(lái)進(jìn)行封裝?；竟芾砼鋫湎到y(tǒng)提供重要服務(wù)本文基站管理配備系統(tǒng)重要提供如下服務(wù)：1.機(jī)箱機(jī)柜cabinet配備服務(wù)：該某些重要配備機(jī)箱機(jī)柜以及輔助系統(tǒng)等。這個(gè)模塊重要配備機(jī)箱機(jī)柜硬件設(shè)備有關(guān)某些信息，尚有某些輔助設(shè)備，例如供電系統(tǒng)，溫度控制系統(tǒng)，ETM板配備等。圖2.14機(jī)箱機(jī)柜配備服務(wù)從上圖可以看出，機(jī)箱機(jī)柜配備可以配備四類(lèi)：機(jī)箱機(jī)柜硬件設(shè)備、供電系統(tǒng)、天氣系統(tǒng)、ETM板配備。其中機(jī)箱機(jī)柜硬件設(shè)備配備包括扇區(qū)配備，這里配備扇區(qū)所需要射頻單元，它是出廠時(shí)候就插入機(jī)箱插槽中，隨著機(jī)箱機(jī)柜一起配備進(jìn)來(lái)射頻單元硬件板，如果是需要光纖遠(yuǎn)程接入，與天線系統(tǒng)相伴射頻單元硬件則并不在這里配備。其她某些硬件設(shè)備配備有：IP地址配備，電纜有關(guān)參數(shù)配備，例如電纜型號(hào)之類(lèi)；BasaBandPoolSettings所需要配備信息重要是基帶信號(hào)解決板與射頻單元硬件板信號(hào)轉(zhuǎn)換接口板類(lèi)型配備，隨著基帶信號(hào)解決板跟射頻單元硬件板不同，相應(yīng)信號(hào)轉(zhuǎn)換接口板類(lèi)型也有所不同。供電系統(tǒng)跟天氣系統(tǒng)配備相對(duì)簡(jiǎn)樸。ETM板重要是用來(lái)接Iub口以太網(wǎng)接入板，重要就是選取哪個(gè)插槽配備。2.基站站點(diǎn)site配備服務(wù)：該某些配備較多，例如扇區(qū)，載波，天線系統(tǒng)，饋線參數(shù)配備都在這個(gè)服務(wù)功能。其她某些硬件配備也在這里進(jìn)行，例如射頻單元承載能力，跟基帶信號(hào)解決板接口連接，塔放TMA，天線傾角RET配備，也屬于這個(gè)功能模塊[25]。圖2.15基站站點(diǎn)配備服務(wù)基站站點(diǎn)配備比較多，由上圖可以看出，一共分四大類(lèi)：站點(diǎn)位置配備，包括扇區(qū)信息配備；扇區(qū)承載能力配備，這里配備射頻單元，重要是遠(yuǎn)程射頻單元與機(jī)箱機(jī)柜中配備不同樣；扇區(qū)硬件配備，這個(gè)配備包括了諸多項(xiàng)，有塔放TMA配備，電子傾角RET配備，天線系統(tǒng)配備，本地社區(qū)配備；以及高速下行Hsdpa配備。在啟用該功能前需要滿足如下兩個(gè)前提：（1）如果本配備服務(wù)已經(jīng)配備過(guò)，重新配備時(shí)候則需要運(yùn)營(yíng)刪除服務(wù)來(lái)清理數(shù)據(jù)。（2）如果機(jī)箱機(jī)柜服務(wù)沒(méi)有配備，則需要一方面配備機(jī)箱機(jī)柜cabinet。3.修改modify服務(wù)：該層重要是對(duì)基站配備修改，可以修改機(jī)箱機(jī)柜中服務(wù)，也可以修改基站站點(diǎn)服務(wù)，因此單獨(dú)成為一種功能模塊。這個(gè)模塊最大好處即是可以在不重新啟動(dòng)基站狀況下，針對(duì)基站周邊社區(qū)狀況相應(yīng)調(diào)節(jié)基站配備。圖2.16修改配備服務(wù)本文所闡述通信基站運(yùn)維綜合管理系統(tǒng)V1.0修改modify功能，當(dāng)前只支持上圖中四個(gè)功能，即修改天線，加扇區(qū)，修改扇區(qū)，刪除扇區(qū)4個(gè)功能，其她修改功能將會(huì)隨著需求提出逐漸完善。修改天線功能中可以修改配備有：天線分支某些修改，饋線電纜修改，塔放TMA修改，電子傾角調(diào)節(jié)期RET修改。加扇區(qū)跟修改扇區(qū)功能本質(zhì)上是同樣，由于加上一種全新扇區(qū)，需要將這個(gè)扇區(qū)有關(guān)參數(shù)都配備上去，才算是一種完整過(guò)程，這些需要配備參數(shù)跟修改扇區(qū)時(shí)候可以修改配備參數(shù)完全一致，因此她們功能在實(shí)現(xiàn)上比較類(lèi)似。她們都可以修改配備有：扇區(qū)承載能力，扇區(qū)數(shù)據(jù)，其中扇區(qū)承載能力中可以配備扇區(qū)社區(qū)。刪除功能則相對(duì)比較簡(jiǎn)樸，僅僅刪除該扇區(qū)以及該扇區(qū)有關(guān)參數(shù)即可。4.導(dǎo)出刪除export/delete服務(wù)：該某些功能服務(wù)相對(duì)比較簡(jiǎn)樸，分2某些。導(dǎo)出服務(wù)是將當(dāng)前Rbs基站配備信息以XML文獻(xiàn)形式導(dǎo)出，以供下次配站時(shí)候可以進(jìn)行相似配備。刪除則是刪除當(dāng)前Rbs配備數(shù)據(jù)信息。功能模塊層實(shí)現(xiàn)方略功能模塊層實(shí)現(xiàn)方略：建造模式[29][30]。建造模式是對(duì)象創(chuàng)立模式。建造模式可以將一種產(chǎn)品內(nèi)部表象與產(chǎn)品生成過(guò)程分割開(kāi)來(lái)，從而可以使一種建造過(guò)程生成具備不同內(nèi)部表象產(chǎn)品對(duì)象。建造模式簡(jiǎn)略類(lèi)圖如圖2.17所示：圖2.17建造模式在這里Rbs類(lèi)扮演了客戶端角色，通過(guò)調(diào)用建造Builder接口類(lèi)retrieveResult辦法可以得到目的功能，而這個(gè)功能構(gòu)架過(guò)程對(duì)Rbs類(lèi)是透明。子類(lèi)ConcretBuilder類(lèi)繼承自建造類(lèi)，實(shí)現(xiàn)retrieveResult辦法，進(jìn)行目的功能類(lèi)詳細(xì)構(gòu)建過(guò)程。一種復(fù)雜產(chǎn)品對(duì)象經(jīng)常會(huì)由不同零件對(duì)象構(gòu)成，這些零件對(duì)象可以叫做產(chǎn)品內(nèi)部表象。不同產(chǎn)品可以有不同內(nèi)部表象。使用建造模式可以在不需要懂得所要構(gòu)建復(fù)雜產(chǎn)品對(duì)象有哪些零件，每個(gè)產(chǎn)品對(duì)象相應(yīng)零件對(duì)象有何區(qū)別，是如何建造出來(lái)，以及如何組件產(chǎn)品狀況下，進(jìn)行構(gòu)建，建造模式有較好封裝性，這樣特性非常適合在復(fù)雜架構(gòu)中使用。結(jié)合本文中通信基站運(yùn)維綜合管理系統(tǒng)V1.0[26]，本層設(shè)計(jì)使用建造模式因素有：有時(shí)候，有些對(duì)象會(huì)有某些重要性質(zhì)，在她們沒(méi)有恰當(dāng)值之前，對(duì)象不能作為一種完整產(chǎn)品使用。例如站點(diǎn)site配備服務(wù)類(lèi)，需要配備射頻單元，天線系統(tǒng)等對(duì)象，才干作為一種完整服務(wù)來(lái)提供應(yīng)顧客，配備到一半時(shí)候，基站站點(diǎn)功能無(wú)法實(shí)現(xiàn)。有些狀況下，一種對(duì)象某些性質(zhì)必要按照某個(gè)順序賦值才故意義。在某個(gè)性質(zhì)沒(méi)有賦值之前，另一種性質(zhì)無(wú)法賦值。這些狀況使得產(chǎn)品自身建造需要涉及到復(fù)雜商業(yè)邏輯。在本系統(tǒng)中，諸多硬件配備具備一定依賴(lài)性，例如基站站點(diǎn)site配備中，塔放TMA只有在特定基站中才可以配備，必須先配備扇區(qū)，才干配備載波頻點(diǎn)等配備。這些涉及到復(fù)雜無(wú)線通信邏輯某些，則可以在建造模式產(chǎn)品類(lèi)內(nèi)部實(shí)現(xiàn)，這樣就可以避免將邏輯分散到系統(tǒng)各個(gè)某些。相應(yīng)到本論文所要描述通信基站運(yùn)維綜合管理系統(tǒng)V1.0中，功能模塊層所需要提供功能服務(wù)，可以以一種類(lèi)來(lái)表達(dá)，配備這種功能服務(wù)，相稱(chēng)于配備此類(lèi)對(duì)象實(shí)例。這個(gè)對(duì)象實(shí)例，就相稱(chēng)于一種有待建造產(chǎn)品，對(duì)象所需要配備流程就是該產(chǎn)品建造過(guò)程，而建造產(chǎn)品過(guò)程，其實(shí)就是建造零件過(guò)程。這樣就可以通過(guò)建造模式，將配備該功能服務(wù)類(lèi)轉(zhuǎn)化為配備該對(duì)象零件類(lèi)過(guò)程，而配備該對(duì)象零件類(lèi)過(guò)程就可以交付給下層，邏輯控制層來(lái)實(shí)現(xiàn)，本層并不需要關(guān)懷詳細(xì)配備細(xì)節(jié)。同步由于本層需要做較多集成，因此往往導(dǎo)致零件構(gòu)造過(guò)程比較復(fù)雜，這時(shí)候就可以將這些零件構(gòu)造過(guò)程，構(gòu)造邏輯外部化到此外一種類(lèi)中來(lái)托管實(shí)現(xiàn)，這個(gè)類(lèi)叫做建造者類(lèi)，專(zhuān)門(mén)來(lái)負(fù)責(zé)建造產(chǎn)品對(duì)象，建造者對(duì)象返還一種所有零件都建造完畢產(chǎn)品對(duì)象。建造模式將產(chǎn)品構(gòu)造和產(chǎn)品零件建造過(guò)程隱藏了起來(lái)，把對(duì)建造過(guò)程進(jìn)行指揮責(zé)任和詳細(xì)建造者零件責(zé)任分割開(kāi)來(lái)，這樣設(shè)計(jì)體現(xiàn)出了責(zé)任分工以及產(chǎn)品封裝性。詳細(xì)建造者零件建造過(guò)程則交由下層來(lái)實(shí)現(xiàn)，體現(xiàn)了架構(gòu)層次化。Rbs基站類(lèi)設(shè)計(jì)思路本小節(jié)將從Rbs基站類(lèi)創(chuàng)立以及Rbs基站類(lèi)構(gòu)成兩個(gè)方面來(lái)闡述Rbs基站類(lèi)設(shè)計(jì)思路：Rbs基站類(lèi)創(chuàng)立方略：工廠辦法模式+登記式單例模式。工廠辦法模式是類(lèi)創(chuàng)立模式，又叫做虛擬構(gòu)造子模式或者多態(tài)性工廠模式。工廠辦法模式用意是定義一種創(chuàng)立產(chǎn)品對(duì)象工廠接口，將實(shí)際創(chuàng)立工作推遲到子類(lèi)中進(jìn)行，從而在核心工廠類(lèi)不在負(fù)責(zé)所有產(chǎn)品創(chuàng)立，而詳細(xì)創(chuàng)立工作則由子類(lèi)負(fù)責(zé)。這個(gè)核心類(lèi)從一種詳細(xì)類(lèi)升格成為了一種抽象類(lèi)，僅僅給出了詳細(xì)子工廠類(lèi)必要實(shí)現(xiàn)接口，至于哪一類(lèi)產(chǎn)品應(yīng)當(dāng)被實(shí)例化這樣細(xì)節(jié)一概不負(fù)責(zé)。同步由于使用了多態(tài)性，工廠辦法模式保持了簡(jiǎn)樸工廠模式長(zhǎng)處，同步克服了它缺陷。工廠辦法模式是簡(jiǎn)樸工廠辦法進(jìn)一步抽象化下模式，這樣可以使得用來(lái)容許系統(tǒng)在不修改詳細(xì)工廠類(lèi)狀況下引進(jìn)新產(chǎn)品，較好支持了開(kāi)閉原則。無(wú)線通信基站發(fā)展日新月異，各大公司紛紛順應(yīng)時(shí)代，不斷推出具備新功能新型基站，基站型號(hào)雖然會(huì)有經(jīng)常增長(zhǎng)特點(diǎn)，但是與原有基站在配備上有許多類(lèi)似之處，因此本文所要實(shí)現(xiàn)基站管理配備系統(tǒng)，為了滿足需求經(jīng)常變動(dòng)這個(gè)條件，在Rbs基站創(chuàng)立時(shí)候，必要采用一種滿足開(kāi)閉原則設(shè)計(jì)模式，在添加新Rbs基站類(lèi)時(shí)候，才干做到盡量小修改，滿足設(shè)計(jì)初衷，因此采用工廠辦法模式來(lái)設(shè)計(jì)Rbs基站，是一種較好選取。工廠辦法模式在本系統(tǒng)中應(yīng)用，Rbs基站簡(jiǎn)要設(shè)計(jì)示意圖如圖2.18所示：圖2.18工廠辦法模式示意圖由上圖可以看出，抽象工廠辦法類(lèi)并不負(fù)責(zé)產(chǎn)品創(chuàng)立，抽象產(chǎn)品類(lèi)是一類(lèi)產(chǎn)品抽象集合，而詳細(xì)Rbs基站類(lèi)型創(chuàng)立交由詳細(xì)工廠類(lèi)來(lái)負(fù)責(zé)，這個(gè)信息可以在機(jī)箱機(jī)柜配備向?qū)е杏深櫩蛠?lái)選取得到，每一種詳細(xì)產(chǎn)品相應(yīng)一種詳細(xì)工廠類(lèi)[27]。圖2.19是Rbs基站類(lèi)在用Java實(shí)現(xiàn)時(shí)候繼承關(guān)系：圖2.19Rbs類(lèi)軟件代碼架構(gòu)Rbs類(lèi)是一種接口類(lèi)，用來(lái)提供外部接口，提供某些必要辦法給其她模塊調(diào)用，這個(gè)類(lèi)并不屬于工廠辦法模式一某些，重要是用來(lái)提供接口通信，滿足接口隔離原則。AbstractRbs類(lèi)扮演一種抽象產(chǎn)品類(lèi)角色，這個(gè)類(lèi)是所有產(chǎn)品對(duì)象共同爸爸。每一種Rbs基站相應(yīng)一種Java類(lèi)，所有類(lèi)都繼承自共有父類(lèi)AbstractRbs，當(dāng)前支持Rbs都涉及在內(nèi)。父類(lèi)提取出Rbs基站共有特性，子類(lèi)將創(chuàng)立行為繼承下來(lái)，并保存各自所特有創(chuàng)立行為以及各自特性。單例模式：是對(duì)象創(chuàng)立模式，，單例模式保證某一種類(lèi)只有一種實(shí)例，并且自行實(shí)例化并向整個(gè)系統(tǒng)提供這個(gè)實(shí)例。這個(gè)類(lèi)成為單例類(lèi)[28]。單例模式有如下特點(diǎn)：1.單例類(lèi)只能有一種實(shí)例。2.單例類(lèi)必要自己創(chuàng)立自己唯一實(shí)例3.單例類(lèi)必要給所有其她對(duì)象提供這一實(shí)例。登記式單例模式：餓漢式單例類(lèi)跟懶漢式單例類(lèi)均不可繼承，因而本文基站管理配備系統(tǒng)使用登記式單例模式，子類(lèi)容許父類(lèi)以構(gòu)造子調(diào)用產(chǎn)生實(shí)例，由父類(lèi)實(shí)例化并登記。以Rbs6601為例，結(jié)合工廠辦法模式進(jìn)行設(shè)計(jì)：AbstractRbs：publicclassAbstractRbsimplementsRbs{ staticprivateHashMapregister=newHashMap(); static { AbstractRbsaRbs=newAbstractRbs(); register.put(aRbs.getClass().getName()，aRbs); } protectedAbstractRbs(){} staticpublicAbstractRbsgetInstance(Stringname) { if(name==null) { System.out.println("NoRbsTypetocreate!");System.exit(1); } if(register.get(name)==null) { try{ register.put(name，Class.forName(name).newInstance()); }catch(Exceptione) { e.printStackTrace(); System.out.println("ErrorhappenedwhencreateRbs!"); } } return((AbstractRbs)register.get(name)); }}在子類(lèi)Rbs6601W中：publicclassRbs6601WextendsAbstractRbs{ publicstaticfinalStringRbs6601="Rbs6601W"； publicRbs6601W(){} staticpublicRbs6601WgetInstance() { return((Rbs6601W)AbstractRbs.getInstance(Rbs6601)); }}由于本段只需要關(guān)懷Rbs基站創(chuàng)立，因此以上代碼只有創(chuàng)立某些，并不包括其她功能實(shí)當(dāng)代碼。在父類(lèi)AbstractRbs中使用一種HashMap類(lèi)型register變量，用register中一對(duì)鍵與值參量來(lái)記錄負(fù)責(zé)創(chuàng)立詳細(xì)Rbs基站類(lèi)型，鍵保存Rbs基站字符型變量名稱(chēng)，值保存該基站單例對(duì)象。在getInstance辦法中調(diào)用時(shí)候，通過(guò)查看register變量鍵與值來(lái)實(shí)現(xiàn)單例模式，如果值為空，則去創(chuàng)立該基站類(lèi)型單例類(lèi)，如果值不為空，則直接返回該單例類(lèi)。在注冊(cè)跟查看時(shí)候，使用了Java中反射機(jī)制[34]，通過(guò)反射查看是哪個(gè)詳細(xì)子類(lèi)來(lái)調(diào)用該辦法，來(lái)創(chuàng)立該子類(lèi)。子類(lèi)Rbs6601W中，則是一種靜態(tài)工廠辦法來(lái)getInstance創(chuàng)立自己實(shí)例，這樣就滿足了單例模式，同步克服了單例模式不能繼承缺陷。Rbs實(shí)現(xiàn)：本系統(tǒng)所采用方略就是：顧客對(duì)基站配備抽象成為本系統(tǒng)對(duì)Rbs類(lèi)配備。因此本系統(tǒng)可以提供多少功能給顧客，Rbs類(lèi)中就應(yīng)當(dāng)包括代理這些功能類(lèi)實(shí)例。一種Rbs類(lèi)持有機(jī)箱機(jī)柜cabinet類(lèi)，基站站點(diǎn)site類(lèi)，修改modify類(lèi)，刪除delete類(lèi)這四個(gè)類(lèi)對(duì)象。邏輯控制層總結(jié)邏輯控制層在整個(gè)基站管理配備軟件中處在核心位置，由于業(yè)務(wù)行為是經(jīng)常變化，如果僅僅將業(yè)務(wù)行為解決都放在一層中實(shí)現(xiàn)，系統(tǒng)邏輯將會(huì)十分龐大而復(fù)雜，并且會(huì)隨著需求變化，在重復(fù)修改之后變?cè)絹?lái)越難以維護(hù)，因而可以將業(yè)務(wù)行為分解成兩層來(lái)實(shí)現(xiàn)。將業(yè)務(wù)行為分解為跟簡(jiǎn)樸單一行為以及一系列行為組合而成具備實(shí)際意義實(shí)際功能服務(wù)行為來(lái)實(shí)現(xiàn)，分別相應(yīng)本系統(tǒng)中邏輯實(shí)現(xiàn)層跟功能模塊層。2.2.6體現(xiàn)層設(shè)計(jì)本小節(jié)重要簡(jiǎn)介了體現(xiàn)層設(shè)計(jì)時(shí)候所用到某些設(shè)計(jì)模式，由于界面設(shè)計(jì)技術(shù)已經(jīng)發(fā)展比較成熟，因此本文采用技術(shù)也是當(dāng)今世界上比較主流技術(shù)，例如MVC模式以及適配器模式。本文所要實(shí)現(xiàn)基站管理軟件系統(tǒng)，提供應(yīng)基站配備人員重要配備界面，有機(jī)箱機(jī)柜cabinet配備向?qū)?，站點(diǎn)site配備向?qū)?，修改modify配備向?qū)В约皩?dǎo)入導(dǎo)出，刪除配備向?qū)?。前兩個(gè)配備向?qū)Р坏珒H有XML配備文獻(xiàn)一鍵式配備，還可以圖形化界面分步配備，而后兩個(gè)配備向?qū)H僅提供XML腳本文獻(xiàn)配備功能。下面將會(huì)從體現(xiàn)層設(shè)計(jì)架構(gòu)模式以及多頁(yè)面實(shí)現(xiàn)所采用模式兩個(gè)方面分別來(lái)闡述。MVC架構(gòu)模式體現(xiàn)層界面架構(gòu)重要采用當(dāng)今世界主流GUI設(shè)計(jì)模式：MVC（Model-View-Controller）模式，即模型-視圖-控制器模式來(lái)實(shí)現(xiàn)。在本基站管理配備系統(tǒng)各種配備向?qū)е?，在許多不同頁(yè)面對(duì)象中，存在著某些共同數(shù)據(jù)，組件等。因此使用MVC模式將會(huì)是一種非常有效方略。MVC構(gòu)造圖見(jiàn)圖2.20。圖2.20MVC構(gòu)造圖模型端：提供某些功能性接口，也是一系列公開(kāi)辦法，通過(guò)這些公開(kāi)辦法，便可以獲得模型端所有功能。在這些公開(kāi)辦法中，有某些是取值辦法，讓系統(tǒng)其他某些可以得到模型端內(nèi)部狀態(tài)參數(shù)，其他某些改值辦法則容許外部修改模型端內(nèi)部狀態(tài)。這其中最重要，必要有一種辦法登記視圖，以便在模型端內(nèi)部狀態(tài)發(fā)生變化時(shí)，可以告知視圖端，這里采用觀測(cè)者模式，運(yùn)用java.util.Obervable類(lèi)中提供辦法，加上監(jiān)聽(tīng)器，以提供登記和告知視圖所需接口。在本系統(tǒng)中模型端遵循如下原則：1.每一種配備向?qū)Ь幸环N模型類(lèi)，用來(lái)存儲(chǔ)所有配備改動(dòng)2.如果配備向?qū)О胪救∠瑒tRbs基站上不需要任何改動(dòng)。各種視圖端：使用MVC模式可以容許各種視圖端存在，并且可以在需要時(shí)候動(dòng)態(tài)登記上所需要視圖，這正是該層使用MVC模式重要因素。在每個(gè)視圖里面，由于視圖可以嵌套，因此可以采用合成模式來(lái)管理界面上控件。在各種視圖里面，可以抽象出每個(gè)視圖共同某些，將其提到父類(lèi)中，并且采用適配器模式來(lái)適配父類(lèi)，簡(jiǎn)化設(shè)計(jì)。在本系統(tǒng)中，視圖端由一種view類(lèi)實(shí)現(xiàn)，重要負(fù)責(zé)：1.解決所有GUI組件2.向顧客提供真實(shí)接口，在本系統(tǒng)中由控制器類(lèi)調(diào)用。多控制器端：MVC模式視圖端是與MVC模式控制器端結(jié)合使用，該端也采用適配器模式。當(dāng)顧客端與相應(yīng)視圖發(fā)生交互時(shí)，顧客可以通過(guò)視窗更新模型狀態(tài)，而這種更新是通過(guò)控制器端進(jìn)行?？刂破鞫送ㄟ^(guò)調(diào)用模型端改值辦法更新其狀態(tài)值。與此同步，控制器端會(huì)告知所有登記了視圖刷新顯示給出顧客表達(dá)。這意味著在視圖端對(duì)象和控制器端對(duì)象之間會(huì)有觀測(cè)者模式應(yīng)用，并且普通視圖跟控制器是成對(duì)浮現(xiàn)。在本系統(tǒng)中，控制器端由一種controller類(lèi)實(shí)現(xiàn)，重要負(fù)責(zé)：1.創(chuàng)立當(dāng)前基站，當(dāng)前頁(yè)面所實(shí)際需要GUI。2.創(chuàng)立基本GUI組件，，例如標(biāo)題等。3.負(fù)責(zé)控制展示當(dāng)前所需要GUI組件。多頁(yè)面配備向?qū)?shí)現(xiàn)多頁(yè)面配備向?qū)?shí)現(xiàn)所采用方略有：適配器模式+依賴(lài)倒轉(zhuǎn)原則。下面分別來(lái)簡(jiǎn)介這兩個(gè)模式，同步詳細(xì)分析在該層中采用因素。適配器（Adapter）模式：把一種類(lèi)接口變換成客戶端所期待另一種接口，從而使原本因接口不同不匹配而無(wú)法在一起工作兩個(gè)類(lèi)可以在一起工作。在如下各種狀況下使用適配器模式：1.系統(tǒng)需要使用既有類(lèi)，而此類(lèi)接口不符合系統(tǒng)需要。2.想要建立一種可以重復(fù)使用類(lèi)，用于與某些彼此之間沒(méi)有太大關(guān)聯(lián)某些類(lèi)，涉及某些也許在將來(lái)引進(jìn)類(lèi)某些工作。這些源類(lèi)不一定要有很復(fù)雜接口。本基站管理配備系統(tǒng)使用是類(lèi)適配器模式，結(jié)合本論文通信基站運(yùn)維綜合管理系統(tǒng)V1.0，設(shè)計(jì)構(gòu)造示意圖如圖2.21所示：圖2.21適配器模式本系統(tǒng)中由于有4個(gè)配備向?qū)?，每一種配備向?qū)Ф夹枰T多配備頁(yè)面，這些頁(yè)面各不相似，卻有某些數(shù)據(jù)以及組件完全同樣，因此可以將面板繪制，標(biāo)題繪制等相似組件抽象出來(lái)，放到父類(lèi)中去實(shí)現(xiàn)。而眾多頁(yè)面，每個(gè)頁(yè)面所需要組件，GUI繪制也各不相似，可以在每一種頁(yè)面繪制時(shí)候，分別使用類(lèi)適配器模式，來(lái)適配抽象父類(lèi)。如上圖所示，AbstractView類(lèi)為一種提取了公共某些抽象父類(lèi)，本模式就是使用類(lèi)適配器來(lái)適配這個(gè)類(lèi)，在viewer類(lèi)中提供各自view類(lèi)繪圖所需要特有接口，同步viewer類(lèi)中接口提供應(yīng)各自控制器controller類(lèi)來(lái)調(diào)用。View類(lèi)負(fù)責(zé)實(shí)現(xiàn)viewer接口中辦法[31]。依賴(lài)倒轉(zhuǎn)原則，DependenceInversionPrinciple（DIP）：要依賴(lài)于抽象，不要依賴(lài)于詳細(xì)，要針對(duì)接口編程，不針對(duì)實(shí)現(xiàn)編程。即針對(duì)抽象編程原則。一種詳細(xì)Java類(lèi)只實(shí)現(xiàn)Java接口和抽象Java類(lèi)中聲明過(guò)辦法，而不應(yīng)當(dāng)給出多余辦法。在本基站管理配備系統(tǒng)中，從視圖端以及控制器端抽象出共同某些，抽象到她們父類(lèi)AbstractView，AbstractController中，使用抽象類(lèi)來(lái)實(shí)現(xiàn)MVC架構(gòu)重要宏觀邏輯，各頁(yè)面子類(lèi)僅僅通過(guò)適配器模式僅僅來(lái)滿足本頁(yè)面繪制繪制需求，并不參加高層抽象類(lèi)邏輯。這樣架構(gòu)同步滿足了開(kāi)閉原則。整體上，界面GUI某些使用了MVC架構(gòu)來(lái)實(shí)現(xiàn)，同步在抽象類(lèi)中實(shí)現(xiàn)對(duì)頁(yè)面控制等共有邏輯，這樣設(shè)計(jì)思想體現(xiàn)出了軟件設(shè)計(jì)模式中里氏代換原則以及依賴(lài)倒轉(zhuǎn)原則，而子類(lèi)繼承時(shí)通過(guò)適配器模式等設(shè)計(jì)辦法來(lái)繪制各自頁(yè)面不同view，相應(yīng)視圖以及控制器僅僅通過(guò)模型端進(jìn)行交互，滿足迪米特法則。第3章通信基站運(yùn)維綜合管理系統(tǒng)V1.0實(shí)現(xiàn)前一章系統(tǒng)分析了產(chǎn)品需求，詳細(xì)簡(jiǎn)介了系統(tǒng)架構(gòu)層次，每一層設(shè)計(jì)思路以及實(shí)現(xiàn)方略，所采用設(shè)計(jì)模式等。本章將結(jié)合上一章分析，從細(xì)節(jié)上對(duì)系統(tǒng)每層實(shí)現(xiàn)某些做詳細(xì)描述。本章重要以類(lèi)圖以及時(shí)序圖形式，按照系統(tǒng)架構(gòu)從底層往上依次闡述每一層詳細(xì)實(shí)現(xiàn)方式，并加以必要解釋闡明[32]。3.1POJO數(shù)據(jù)層實(shí)現(xiàn)該層實(shí)現(xiàn)相對(duì)比較簡(jiǎn)樸，重要依賴(lài)于系統(tǒng)高層定義MO信息，本層建立MO與類(lèi)一一相應(yīng)關(guān)系即可。在每一種類(lèi)中僅有g(shù)et/set辦法用來(lái)存儲(chǔ)取值，并沒(méi)有多余邏輯，這也是POJO類(lèi)特色。圖3.1是Slot這個(gè)MO相應(yīng)UML類(lèi)圖：圖3.1Slot類(lèi)UML圖從上圖中可以看出，slot這個(gè)MO每一種屬性都相應(yīng)當(dāng)類(lèi)一種屬性，reservedBy這個(gè)屬性比較特殊，是MO系統(tǒng)自身內(nèi)在屬性，不會(huì)變化，也不用給顧客配備，在這個(gè)MO類(lèi)中將其值以硬編碼方式存儲(chǔ)起來(lái)即可，因此不需要set辦法，只有g(shù)et辦法。其她屬性都可以變化，因此均有g(shù)et/set辦法。其她類(lèi)實(shí)現(xiàn)都跟這個(gè)類(lèi)相似，就不一一舉例了。3.2物理數(shù)據(jù)層實(shí)現(xiàn)本層重要負(fù)責(zé)實(shí)現(xiàn)兩個(gè)某些，MO樹(shù)建立跟物理數(shù)據(jù)實(shí)現(xiàn)。下面從這兩個(gè)方面來(lái)描述。3.2.1MO樹(shù)建立由第二章設(shè)計(jì)時(shí)候分析可知，建立MO樹(shù)時(shí)候重要用到Node類(lèi)，MONode類(lèi)，MOProxyNode類(lèi)這三個(gè)類(lèi)。圖3.2是這三個(gè)類(lèi)UML圖：圖3.2建立MO樹(shù)類(lèi)UML圖建立MO樹(shù)時(shí)候需要用到這三個(gè)類(lèi)，由上可以看出這三個(gè)類(lèi)重要功能分別是：Node類(lèi)重要負(fù)責(zé)提供建立樹(shù)構(gòu)造基本辦法，如setDepth，setParent，appendChild這3個(gè)辦法。MONode類(lèi)跟MOProxyNode都繼承自Node類(lèi)，分別進(jìn)行了擴(kuò)展。MONode類(lèi)提供了加鎖，刪除有關(guān)辦法，一種MO從樹(shù)上刪除時(shí)候，必要先加鎖才干刪除，同步還要將有關(guān)子節(jié)點(diǎn)同步進(jìn)行加鎖跟刪除動(dòng)作，由getDeletedObjectInOrder跟getLockableObjectsInOrder這兩個(gè)辦法來(lái)實(shí)現(xiàn)。MOProxyNode類(lèi)重要用來(lái)提供從MO樹(shù)上取相相應(yīng)MO辦法，如調(diào)用getMO（String）辦法，通過(guò)MOLDN入?yún)?，?lái)獲取這個(gè)MO。3.2.2物理數(shù)據(jù)實(shí)現(xiàn)物理數(shù)據(jù)層重要是將零散MO數(shù)據(jù)進(jìn)行組合，同步以與真實(shí)硬件一一相應(yīng)關(guān)系向上層提供具備實(shí)際意義數(shù)據(jù)模型。以圖3.3UML圖以遠(yuǎn)程射頻單元為例。圖3.3匯集模式UML圖RemoteRadioUnit類(lèi)在該圖中處在核心位置，這個(gè)類(lèi)相應(yīng)于真實(shí)物理硬件遠(yuǎn)程射頻單元，涉及了這個(gè)硬件所有需要配備參數(shù)數(shù)據(jù)。這個(gè)類(lèi)以匯集形式持有POJO層中五個(gè)有關(guān)數(shù)據(jù)類(lèi)，該類(lèi)包括一系列set/get辦法，當(dāng)對(duì)這個(gè)類(lèi)進(jìn)行配備時(shí)候[33]，就可以調(diào)用該類(lèi)所持有相相應(yīng)MO實(shí)例中set辦法進(jìn)行配備，間接配備了POJO類(lèi)。圖3.4是該層配備數(shù)據(jù)創(chuàng)立過(guò)程時(shí)序圖：圖3.4創(chuàng)立物理數(shù)據(jù)時(shí)序圖從邏輯實(shí)現(xiàn)層RemoteManager類(lèi)發(fā)來(lái)create消息，觸發(fā)本層中RemoteRadioUnit類(lèi)創(chuàng)立相應(yīng)數(shù)據(jù)。RemoteRadioUnit類(lèi)會(huì)依照需要分別來(lái)創(chuàng)立實(shí)例，最后check辦法來(lái)檢查創(chuàng)立過(guò)程與否出錯(cuò)，創(chuàng)立成功后返回OK。3.3邏輯實(shí)現(xiàn)層實(shí)現(xiàn)該層重要是某些單一邏輯，相稱(chēng)于功能模塊層中某些配備行為實(shí)現(xiàn)原材料，這些原材料在功能模塊層調(diào)用，來(lái)建造具備配備意義邏輯實(shí)現(xiàn)。下圖以RadioUnitManager為例，展示了本層實(shí)現(xiàn)過(guò)程：圖3.5邏輯實(shí)現(xiàn)層享元模式實(shí)現(xiàn)UML圖ManagerFactory類(lèi)中g(shù)etManagerInstance辦法提供RadioUnitManager類(lèi)一種實(shí)例。RadioUnitManager類(lèi)中consistencyCheck辦法用來(lái)做創(chuàng)立前檢查，create辦法可以將外蘊(yùn)享元形式傳進(jìn)來(lái)。RemoteRUManager扮演了外蘊(yùn)享元角色，這里進(jìn)行RemoteRadioUnit類(lèi)中數(shù)據(jù)創(chuàng)立以及配備等功能。RUData類(lèi)扮演了內(nèi)蘊(yùn)享元角色，該類(lèi)中存了跟這個(gè)硬件配備有關(guān)某些不變量，這些變量不需要顧客配備，但是在創(chuàng)立過(guò)程中需要用來(lái)進(jìn)行邏輯判斷，控制創(chuàng)立過(guò)程[35