【正文】 理，對不同高校的教學模式的研究還不夠。 監(jiān)控系統(tǒng)的功能往往較為詳細和強大。 但是 C/S架構(gòu)還是存在比較明顯的缺點的，它的不同的電腦上存在界面不統(tǒng)一的情況，所以，這些程序在不同的電腦上運行時，復(fù)用性、集成性和擴展性都存在很大的問題，這些問題通過 C/S模式很難克服。而且， B/S架構(gòu)有開放的和統(tǒng)一的接口標準，這樣，不同的 B/S 服務(wù)器就能實現(xiàn)動態(tài)交互，提供了系統(tǒng)的信息處理能力和用戶服務(wù)能力 [12]。 第二章：介紹 基于 GRPS 的 高校機房遠程監(jiān)控終端 統(tǒng)開發(fā)的相關(guān)理論基礎(chǔ)，例如 GPRS 技術(shù)、開發(fā)模式 和開發(fā)技術(shù)等。主要包括系統(tǒng)的層次結(jié)構(gòu)的設(shè)計、主要模型的設(shè)計和數(shù)據(jù) 庫 的設(shè)計等。 對系統(tǒng)開發(fā)和論文中所做的工作進行總結(jié)，并提出了進一步工作的展望。雖然這種改造并沒有花費太多成本，但是得到的數(shù)據(jù)傳輸?shù)?速率卻相當可觀。 圖 21 是 基于分組的通信過程示意圖。在 中使用通用語言進行程序開發(fā)，這就使得其適應(yīng)性非常強。 有非常高的管理性能。 C o m m o n L a n g u a g e R u n t i m e ( 通 用 語 言 進 行 時 )W i n d o w s 操 作 系 統(tǒng)A S P . N E TW i n d o w sF o r mA S P . N E T W e bS e r v i c e sE n t e r p r i s eS e r v i c e sA D O . N E T. N E T F r a m e w o r k C l a s s L i b r a r y ( . N e t 框 架 類 庫 )應(yīng) 用 程 序圖 22 .Net 框架 下面，本文就對這三部分進行分析： (Common Language Runtime)，這部分是 在操作系統(tǒng) 的 最上層 的 ， 它是被 所有 .Net 語言所 公用的 基礎(chǔ) 組件， CRL 的作用主要是配合程序的執(zhí)行的組件。因為這些改寫的 是一些專門提供 Web 服務(wù)的 模型 和控件，所以才將其單獨管理。 數(shù)據(jù)庫開發(fā)技術(shù) 基于 GRPS 的 高校機房遠程監(jiān)控終端 是一個綜合性的應(yīng)用系統(tǒng) [18]。 1988 年， SQL Server 推出第一個 OS/2 版 本，是一個關(guān)系型數(shù)據(jù)庫系統(tǒng)管理，首先利用 Sybase，艾什頓 Tate 和微軟公司共同開發(fā)的。 本文 設(shè)計的高校機房遠程監(jiān)控終端 管理的核心是 SQL Server 20xx 數(shù)據(jù)的引擎。統(tǒng)一建模語言 UML，簡稱，它不僅是一種軟件設(shè)計中的應(yīng)用，還是用于標準的系統(tǒng)建模和設(shè)計 [20]。UML 的應(yīng)用已經(jīng)非常成熟，在不同的領(lǐng)域類， UML 都已經(jīng)完成了很多成功的建模的案例。 UML 的發(fā)展雖然是面向?qū)ο蟮姆治龊驮O(shè)計的產(chǎn)物，但是它并不是只能描述面向?qū)ο蟮姆治龊驮O(shè)計，它也可以描述面向過程的分析與設(shè)計。而可以完成 UML 的工具有很多，本系統(tǒng)選擇使用微軟公司的 Microsoft Visio 來完成。但是他們也不是完全沒有關(guān)聯(lián)的，他們 通過公開的借口連接，使得整個系統(tǒng)成為一個有機的整體。但是實際上， Model的所有內(nèi)部業(yè)務(wù)邏輯都是封裝的，對外僅僅是提供一個公共的訪問接口，這樣，系統(tǒng)的維護性就更高，模塊間的獨立性也就更好。 控制器 (Controller)的作用是完成視圖和模型之間的信息的接收和轉(zhuǎn)發(fā)，它就是一個控制作用，本身并不進行業(yè)務(wù)邏輯處理。 的分層式三層的，從前往后依次是表示層、業(yè)務(wù)層和數(shù)據(jù)層 [25]。通過 aspx 頁面的展示來實現(xiàn)系統(tǒng)的視圖部分的內(nèi)容。一些在試圖控制器中沒有的控件，程序設(shè)計員也可以利用這些已有的控件進行組合產(chǎn)生?？刂破髦械倪壿嬁刂苾?nèi)容就是在 .cs 文件中實現(xiàn)的。其他所有的控制器函數(shù)都必須繼承該函數(shù)才能執(zhí)行操作。這樣就能在很大程度上調(diào)高代碼的復(fù)用性。但是這種傳統(tǒng)的方法不利于系統(tǒng)的升級和維護。這樣數(shù)據(jù)庫的訪問都是通過封裝的類來完成的。其中 GPRS 技術(shù)是進行高校機房個遠程監(jiān)控的核心技術(shù)，圍繞該技術(shù)通過軟件開發(fā)的方式建立一個機房遠程監(jiān)控終端。 基于 GRPS 的高校機房遠程監(jiān)控終端 需求分析 是系統(tǒng)進行開發(fā)的第一步。需求分析文檔的主要內(nèi)容是系統(tǒng)的用例、系統(tǒng)的邊界和系統(tǒng)的參與人員。 需求分析時首先考慮 該系統(tǒng)面向的是誰？有什么特征。 系統(tǒng)可行性分析 基于 GRPS 的高校機房遠程監(jiān)控終端 可行性研究的目的，就是用最小的代價在盡可能短的時間內(nèi)確定 基于 GRPS 的高校機房遠程監(jiān)控終端 是否能夠解決。 本系統(tǒng)是 機房遠程監(jiān)控終端 ，從需求分析過程中，首先是可行性分析。如果使用者對該系統(tǒng)不支持，或者使用起來不方便。 (3)經(jīng)濟上 的可行性 主要是關(guān)于支出和系統(tǒng)開發(fā)成本估算成本是否處于平衡狀態(tài)的帳戶。本系統(tǒng)就是通過 GPRS 基礎(chǔ)架構(gòu)來實現(xiàn)對 高校機房 的監(jiān)控。 數(shù)據(jù)采集完成后要將數(shù)據(jù)進行傳輸，這是系統(tǒng)傳輸層需要完成的工作。 數(shù)據(jù)傳輸?shù)奖O(jiān)控端就要對數(shù)據(jù)進行處理，這是業(yè)務(wù)層需要完成的工作。 系統(tǒng)性能 需求分析 基于 GRPS 的高校機房遠程監(jiān)控終端 的開發(fā)目的是為了 滿足 高校教 機房 的監(jiān)控需求而開發(fā)的，開發(fā)系統(tǒng)的目的是為了 提高 教務(wù)部門 和實驗管理部門對于機房的監(jiān)控 效率和質(zhì)量。所以系統(tǒng)主要包含 基于 GPRS 技術(shù)的 高校機房遠程監(jiān)控終端 的 所有內(nèi)容和流程。最好能夠使得系統(tǒng) 的界面和用戶的 Windows 操作系統(tǒng)在風格上保持一定的兼容性。 哈爾濱理工大學工程碩士學位論文 12 要考慮到我們開發(fā)的 基于 GRPS 的高校機房遠程監(jiān)控終端 并不是一個孤立的系統(tǒng)，它要和 高校 院?，F(xiàn)存的很多的信息管理系統(tǒng)進行信息的共享和傳輸，這就要在系統(tǒng)進行設(shè)計和開發(fā)時，充分考慮系統(tǒng)的接口的設(shè)計，使得系統(tǒng)能夠和高?，F(xiàn)在正在運行的系統(tǒng)能夠互相兼容。 本章小結(jié) 本章主要對軟件工程生命周期的最為關(guān)鍵的階段 —— 需求分析階段進行描述。 除了速度快之外，硬件還要能夠連續(xù)工作并且 易于擴展 。 機房遠程監(jiān)控終端需要包括 監(jiān)控終端、電源、打印機等設(shè)備。 高校機房遠程監(jiān)控終端的設(shè)計中，數(shù)據(jù)通信模塊 的作用非常重要，它起到了連接監(jiān)控設(shè)備和監(jiān)控終端的作用。 綜上所述 ， 本課題使用的數(shù)據(jù)通信模塊式NORDIC 公司的 nRF2401 芯片。 ATmega128L 處理器 由 32 個通用工作寄存器、 128K 字節(jié)的可編程 Flash、 4K 字節(jié)的 EEPROM、 53 個通用 I/O 口線、 4K 字節(jié)的 SRAM、8 通道 10 位 ADC、實時時鐘 RTC、 SPI 串行端口、 2 個 USART、可編程看門狗定時器、 JTAG 測試接口。 因為 在機房中設(shè)置的無線監(jiān)控設(shè)備的功耗比較低，所以無線監(jiān)控設(shè)備如果是空閑的，就可以直接用 未處理的 I/O 驅(qū)動 就可以 ， 不需要額外的電哈爾濱理工大學工程碩士學位論文 14 源。 型號為 CR2032，該電池為 紐扣電池 ，其 工作輸出電壓為 2~3V， 電流量為大約 200mAh。 需要將采集到的數(shù)據(jù)的信息情況通過數(shù)據(jù)通信模塊上傳到監(jiān)控終端 ，所以 數(shù)據(jù)采集 節(jié)點的設(shè)計是整個 GRPS 網(wǎng)絡(luò)的核心內(nèi)容。但是系統(tǒng)的 SPI 端口和中斷系統(tǒng)卻不會空閑，它們隨時會接受系統(tǒng)發(fā)送的中斷請求。 數(shù)據(jù)庫的設(shè)計 數(shù)據(jù)庫內(nèi)容的設(shè)計也是系統(tǒng)詳細設(shè)計的主要內(nèi)容，數(shù)據(jù)庫的 設(shè)計包括邏輯設(shè)計和物理設(shè)計： 哈爾濱理工大學工程碩士學位論文 15 邏輯設(shè)計是數(shù)據(jù)庫設(shè)計的第一步。設(shè)計數(shù)據(jù)庫的實體需要通過一種模型來實現(xiàn)，這種模型成為實體關(guān)系模型。筆者在本文中使用的是 SQL Server 20xx 數(shù)據(jù)庫，是一種關(guān)系型數(shù)據(jù)庫，所以該數(shù)據(jù)庫的物理設(shè)計就是設(shè)計二維關(guān)系表。通過第三章的需求分析，得出系統(tǒng)的主要實體有用戶實體、客戶端實體、主機實體、組實體和文件實體等。 現(xiàn)在的最常用的數(shù)據(jù)庫是關(guān)系數(shù)據(jù)庫。 (user_info) 用戶信息表記錄著用戶的帳號、密碼和級別等信息，不同級別的用戶擁有不同權(quán)限，這里設(shè)置了三種用戶級別：普通用戶，可以查看所有監(jiān)控點的實時視頻信息高級用戶除了擁有普通用戶的所有權(quán)限外，還可以進行本地和遠程存儲視頻回放以及對實時視頻進行錄像超級用戶叩除了擁有高級用戶的所有權(quán)限外，還可以進行系統(tǒng)管理。具體的表結(jié)構(gòu)如表 42 所示 表 41 用戶信息表 字段名 說 明 類 型 長 度 可否為空 主鍵 UserID 用戶編號 varchar 8 否 是 UserName 用戶名 varchar 10 否 否 UserPassword 密碼 varchar 15 否 否 Realname 真實姓名 varchar 10 否 否 表 42 客戶 端狀態(tài)信息表 字段名 說 明 類 型 長 度 可否為空 主鍵 ProcessID 進程編號 varchar 8 否 是 ProcessName 進程名 varchar 10 否 否 ProcessStatus 進程狀態(tài) varchar 10 否 否 (capture_info) 視頻采集主機信息表記錄著視頻采集主機名字、地址、所屬監(jiān)控組和活躍狀態(tài)等信息，其中活躍狀態(tài)指示了視頻主機是否在線。具體如表 44 所示。 表 44 視頻采集主機信息表 字段名 說 明 類 型 長 度 可否為空 主鍵 HostID 主機編號 varchar 8 否 是 ProcessID 進程編號 varchar 8 否 是 HostStatus 主機狀態(tài) varchar 10 否 否 表 45 組信息表 字段名 說 明 類 型 長 度 可否為空 主鍵 GroupID 組編號 varchar 8 否 是 GroupAdrress 組播地址 varchar 16 否 是 GroupPort 組播端口 varchar 10 否 否 (video) 視頻文件信息表記錄著存儲視頻文件的名字、所在的采集服務(wù)器地 址和在該服務(wù)器上存放路徑。通過設(shè)計的結(jié)果可以得出結(jié)論：系統(tǒng)在硬件和軟件上的設(shè)計都必須符合GRPS 網(wǎng)絡(luò)的特點，必須以 GPRS 網(wǎng)絡(luò)為依托進行系統(tǒng)硬件和軟件的設(shè)計和部署，然后在此基礎(chǔ)上進行數(shù)據(jù)庫的設(shè)計和部署。 要建立會話，首先要指明會話的地址和端口。 會話建立后，還需要調(diào)用 addSessionINPO 記錄會話的相關(guān)信息，以備查詢或管理。 在結(jié)束會話后，還需要把該會話信息從鏈表中刪除。 —— StopSendVideo 停止發(fā)送視頻接口主要功能是在指定會話中停止發(fā)送視頻。 —— SendRecordVideo 當組管理服務(wù)器發(fā)出遠程回放的命令時，通過發(fā)送錄像接口就可以把本地錄像視頻發(fā)送給請求主機。 圖 42 視頻編碼流程 從圖 42 可以 看出，基于 MPEG4 的視頻編碼的流程 為： 。 ，運動估計的目的是為了找出和當前宏塊最接近的宏塊，將其作為當前宏塊的參考宏塊。 DCT 變換。煉化后的值也需要編碼在碼流中的，只有這樣才能在視頻解碼時通過該值來進行反量化，恢復(fù)出視頻的原始值?？梢圆捎?DC 的方式來減少系數(shù)值。為了和解碼端統(tǒng)一，需要在運動估計的時候，在前 一個重建幀中為當前宏塊尋找一個最匹配宏塊。所以，在進行視頻編碼時，需要通過Bitstream forming 模塊先將碼流頭的信息寫入輸出流文件中，然后才是視頻幀的內(nèi)容。往輸出流文件中寫數(shù)據(jù)是以幀為單位的，當前幀的所有相關(guān)數(shù)據(jù)完成后，才是下一幀的數(shù)據(jù)，按照這樣的順序，直到所有幀編碼完成。 將一個編碼器打開，其中編碼器的函數(shù)參數(shù)分別為視頻的寬、視頻的高、幀率碼率、主要幀的間隔、編碼類型、數(shù)據(jù)類型和量化值的大小。 將一個編碼器關(guān)閉并將資源釋放。 哈爾濱理工大學工程碩士學位論文 22 設(shè)置一個幀率碼率。 設(shè)置一個量化值的大小。 GetMode(int *nMode)。 圖 43 視頻解碼流程 筆者只是對 MPEG4 的編解碼 SDK 解碼部分的 API 進行一下分析。 將一個解碼器打開，解碼器函數(shù)的參數(shù)分別是視頻的寬、視頻的高、數(shù)據(jù)類型。 哈爾濱理工大學工程碩士學位論文 23 將一個解碼器關(guān)閉并將資源釋放。 圖 53 工具條模塊 視頻顯示模塊 視頻顯示模塊如圖 54 所示，視頻顯示模塊中每一個通道對應(yīng)一路信號，畫面的分割可以通過點擊畫面分割按扭彈出菜單進行選擇，分別有一畫面、四畫面、九畫面、十六畫面、二十五畫面和三十六畫面。 單元測試 是測試的最小單位，要進行成功的單元測試，必須要有極為詳細的設(shè)計文檔。 單元測試 也是唯一一種由開發(fā)者 來完成 的測試。所以，他們既完成單元代碼的編寫，又完成單元測試代碼的編寫。當系統(tǒng)的每個模塊開發(fā)完成，需要將所有的模塊集成為一個完整的系統(tǒng)，也就是說將每個模塊加入到系統(tǒng)中來，集成測試主要是測試接口連接是否正確，一般由專門的測試團隊來完成。無論系統(tǒng)采取的是面向過程的開發(fā)方式還是面向?qū)ο蟮拈_發(fā)方式，集成測試都是非常必要的。 集成測試 的 主要目的 是判斷整個系統(tǒng)的業(yè)務(wù)流程和數(shù)據(jù)處理方式是否是符合客戶需求的