畢業(yè)論文-基于VC++遠程控制系統(tǒng)的設(shè)計

宿 州 學 院 畢 業(yè) 論 文 論文題目 基于 C+遠程控制系統(tǒng)的設(shè)計 系 別 信息工程學院 專 業(yè) 計算機科學與技術(shù) 班 級 09 專升本 1 班 學 號 2009110457 學生姓名 劉偉偉 指導(dǎo)教師 （簽名） 完成時間 2011年 3 月 I 摘要 隨著計算機信息現(xiàn)代工業(yè)的發(fā)展 ， 計算機遠程 控制 管理系統(tǒng)越 來越受到 各方面的 重視。本文主要分析了遠程 控制 系統(tǒng)的一些基本功能和組成情況 ， 包括系統(tǒng)的需求分析、系統(tǒng)結(jié)構(gòu)、功能模塊劃分分析等 ， 重點對應(yīng)用程序的實際開發(fā)實現(xiàn)作了介紹。達到了實時性和安全性 ， 且應(yīng)用程序功能完備。同時簡單介紹了 + 程環(huán)境和 功能特點。 本課題設(shè)計是為適應(yīng)遠程控制及協(xié)助的要求 ， 使遠程 控制 提高到計算機的實時水平而設(shè)計的。遠程 控制 包括多項內(nèi)容 ， 本課題設(shè)計只是承建 了其中的一部分即：實時 控制 。本課題設(shè)計 為一個通信應(yīng)用程序 ， 用到了多項技術(shù) ， 諸如：異步模式向?qū)ο缶幊?、軟件工程思?、 。 本系統(tǒng) 采用 + 為開發(fā)工具 , 整個系統(tǒng)操作簡潔、界面友好、功能靈活、實用，實現(xiàn)了包括客戶端屏幕監(jiān)控、文件監(jiān)控及傳輸、進程監(jiān)控、系統(tǒng)服務(wù)和注冊表監(jiān)控 等 基本功能， 基本完成了遠程 控制 中 所 需要到 的主要功能 。 關(guān)鍵詞 ： 套接字 面向?qū)ο?軟件工程 遠程 監(jiān)控 of on + of is by of of of to of It + 6.0 of at is in to on by to up of a of of + + 6.0 as a of is is is of to 目錄 第一章 緒論 . 1 課題背景 . 1 目的以及意義 . 1 第二章 開發(fā)平臺的理論基礎(chǔ) . 2 +及編程模式簡介 . 2 系統(tǒng)架構(gòu)的模式 . 5 術(shù)簡介 . 6 的簡單介紹 . 7 第三章 需求分析 . 9 系統(tǒng)基本情況描述 . 9 系統(tǒng)可行性分析 . 9 功能需求分析 . 10 系統(tǒng)流程圖 . 12 第四章 總體設(shè)計 . 13 使用工具 . 13 系統(tǒng)模塊的設(shè)計 . 13 第五章 系統(tǒng)詳細設(shè)計 . 17 客戶端與服務(wù)器連接設(shè)計 . 17 系統(tǒng)各模塊界面設(shè)計及其實現(xiàn) . 18 第六章 系統(tǒng)測試 . 32 軟件測試基礎(chǔ) . 32 本系統(tǒng)采用的測試方法 . 32 第七章 總結(jié) . 35 參考文獻 . 36 附錄 . 37 致謝 . 44 1 第一章 緒論 課題背景 通常企業(yè)內(nèi)部或者 任務(wù)是通過電話解答疑難問題，努力減少技術(shù)人員到現(xiàn)場服務(wù)或者讓用戶把設(shè)備送到支持中心進行維護。這種技術(shù)支持方式盡管被普遍采用，但效率不高而且大大增加了技 術(shù)支持成本。 通常，技術(shù)支持必須依賴技術(shù)人員和用戶之間的口頭交流來進行，這種交流既耗時又容易出錯。許多商業(yè)用戶對計算機知之甚少，然而當遇到問題時，他們必須向技術(shù)人員提供故障情報及相關(guān)操作。在嘗試解決問題時，技術(shù)人員可能指導(dǎo)用戶執(zhí)行一系列復(fù)雜的過程，而這些過程對用戶來說或許完全不熟悉；如果用戶不能正確的按要求操作，反而使問題惡化。此外，如果通過電話不能解決問題，那么 在 技術(shù)人員親自到用戶現(xiàn)場解決問題之前，計算機將 無法繼續(xù) 使用 ，導(dǎo)致工作延誤 。 目的以及意義 本文正是在 上文提到的 背景下提出的 ， 目的 就 是為了 解決計 算機的遠程操作，降低企業(yè)對軟件的后期維護成本，設(shè)計出一款遠程控制 系統(tǒng) 。 遠程 控制 系統(tǒng) 能使技術(shù)人員直接操作遠程計算機，就像操作本地機器一樣，無須用戶介入，技術(shù)人員技能得到該機器的問題的第一手材料，從而加快了問題的解決。實際上，使用遠程 控制 工具的技術(shù)人員能夠做到解答疑難問題，安裝和配置軟件，把軟件下載到用戶計算機上，配置應(yīng)用程序和系統(tǒng)軟件設(shè)置并可通過實際操作培訓(xùn)用戶。 總之，本課題的設(shè)計與實現(xiàn)具有很大的現(xiàn)實意義。 2 第二章 開發(fā)平臺的理論基礎(chǔ) +及編程模 式簡介 +的簡介 +的資源編輯器能以所見即所得（ is 形式直接編輯程序的用戶界面，為所有資源分配 識號。 把對話框模板與生成的類定義或與已有的類代碼連接起來，為菜單項、控制等資源生成空的處理函數(shù)模板，創(chuàng)建消息映射條目，并將資源 處理函數(shù)連接起來。通過使用 序員的編程工作便簡化為用資源編輯器直觀的設(shè)計界面，完善對話框類代碼，在空的處理函數(shù)模板處填寫響應(yīng)用戶操 作的代碼，這是一種比較完善的可視化編程方法。 但產(chǎn)品名 “ +” 也容易誤導(dǎo)人，讓人認為自己使用的是一個與似的完全可視化的系統(tǒng)。然而，使用 +，開發(fā)人員必須真正地閱讀和編寫 C+代碼。 +向?qū)Э梢怨?jié)省時間和提高精度，但是，程序員也必須理解向?qū)Мa(chǎn)生的代碼，并且，最重要的是，還必須理解 的結(jié)構(gòu)和 作系統(tǒng)的內(nèi)部工作方式 7。 應(yīng)用程序框架 應(yīng)用程序框架的一種定義是：提供一般應(yīng)用程序需要的全部面向?qū)ο筌浖M件的集成集合。 C+流行的一個原因是它可以用類庫擴充。類庫是可在應(yīng)用程序中使用的有關(guān) C+類的集合。應(yīng)用程序框架是類庫的超集。一般的類庫只是一種孤立的類的集合，用來嵌入在任何程序中，但是，應(yīng)用程序框架卻定義了程序的結(jié)構(gòu)。自從 發(fā)布以來， 經(jīng)成為主要的 庫。使用 庫構(gòu)建應(yīng)用程序具有以下優(yōu)點： 1. 是 C+的 2. 應(yīng)用程序框架生成的應(yīng)用程序使用了標準的 結(jié)構(gòu)，具有標準化的用戶接口，這對具有標準用戶界面的 序來說，可以極大的減輕程序員的負擔，使程序員不必過多地考慮界面，可把主要精力放在程序設(shè)計上，以提高程序設(shè)計的效率。 3. 使用應(yīng)用程序框架的應(yīng)用程序不僅小，而且運行速度快，具有很大的靈 3 活性。 裝了 的幾乎所有函數(shù)，能實現(xiàn) 統(tǒng)的任何功能。 4. 架降低了編碼的復(fù)雜性。 5. 應(yīng)用程序框架有豐富的特性，如： C+接口、通用的（非 特有的）類、 “共用根對象 ”類層次結(jié)構(gòu)、流線式多文檔界 面（ 用程序支持等。 6. 強大的功能。除封裝了大部分的 數(shù)外， 提供了應(yīng)用程序本身的數(shù)據(jù)和操作及 操作類。 架的核心是文檔 /視圖結(jié)構(gòu)（ 這是一個很好用、但又往往較難以入門的功能。簡單的說，文檔 /視圖結(jié)構(gòu)就是將數(shù)據(jù)和對數(shù)據(jù)的觀察或數(shù)據(jù)的表現(xiàn)（顯示）相分 離。文檔僅處理數(shù)據(jù)的實際讀、寫操作，視圖則是顯示和處理數(shù)據(jù)的窗口，視圖可以操作文檔中的數(shù)據(jù) 7。 消息映射 在使用 +進行 序設(shè)計時，消息映射是一個非常重要的概念。用程序是消息驅(qū)動的，應(yīng)用程序不能直接得到用戶所做的操作，如鼠標按鍵、鍵盤輸入和窗口移動等。這些操作由操作系統(tǒng)管理，操作系統(tǒng)檢測到操作事件后，便向相關(guān)的應(yīng)用程序發(fā)送消息，應(yīng)用程序響應(yīng)這些消息來完成用戶的操作。 1 消息 的消息是操作系統(tǒng)與應(yīng)用程序之間、應(yīng)用程序 與應(yīng)用程序之間、應(yīng)用程序各對象之間相互控制與傳遞信息的方式。 消息的基本格式如下： 消息名稱； 與消息相關(guān)的 參數(shù)； 與消息相關(guān)的 參數(shù)。 消息主要有以下 3 類。 統(tǒng)消息： 統(tǒng)向窗口發(fā)送的消息，由窗口（ 視圖（ 行響應(yīng)處理。這類消息包括除 息之外的名稱以 控制通知消息：控制或子窗口傳給父窗口的 知的消息。 命令消息：在響應(yīng)用戶接口操作時，將產(chǎn)生 令消息。其參 4 數(shù)指定了用戶接口的標識號，如菜單項和按鈕等 。 2 消息映射過程 在使用 建應(yīng)用程序時， 用程序框架設(shè)置了相應(yīng)的消息處理函數(shù)來響應(yīng)消息，以完成相應(yīng)的操作。消息處理函數(shù)是某些類（通常是窗口類）的成員函數(shù)和程序員在其中編寫響應(yīng)消息時應(yīng)進行操作的代碼。 框架將消息和它們的處理函數(shù)連接起來就是消息映射。消息映射使應(yīng)用程序在接收到消息時調(diào)用對應(yīng)的消息處理函數(shù)來響應(yīng)和處理消息。 創(chuàng)建新類時將為其創(chuàng)建一個消息映射，并為每個類能響應(yīng)的消息 和 命 令 增 加 對 應(yīng) 的 處 理 函 數(shù) 。 在 源 代 碼 中 ， 消 息 映 射 開 始 于，結(jié)束于 ，中間由一系列預(yù)定義的被稱為 “ 條目宏 ” 的宏組成。其基本格式如下： 條目宏 1 條目宏 2 條目宏 3 /) 其中 擁有消息映射的當前類名， 當前類的父類名。條目宏定義了類所處理的消息與其對應(yīng)的函數(shù)。常用的條目宏類型如表 示。 表 消息映射條目宏 消息類型 宏格式 說明 息 息名 命令 D,命令標識號， 更新命令 D,命令標 識號， 控制通知 D,控制標識號， 用戶定義消 D,消息標識號， 息 為處理函數(shù)名 用戶注冊消息 D,消息標識號， 息的處理函數(shù)在 中進行了預(yù)定義，類庫以消息名為基礎(chǔ)定義這些處理函數(shù)的名稱，且 求所有消息處理函數(shù) 聲明為 型。例如，消息 處理函數(shù)在 中的聲明如下： ; 通過 派生類中用同樣的原型定義處理函數(shù)并為該函數(shù)生成消息映射條目，然后由程序員編寫處理函數(shù)代碼，并在派生類中覆蓋了其父類的消息處理函數(shù)。在有些情況下，必須在派生類的消息處理函數(shù)中調(diào)用其父類的消息處理函數(shù)，使 基類能對消息進行處理。 在生成的處理函數(shù)中建議是否應(yīng)調(diào)用父類的消息處理函數(shù)及調(diào)用的次序。除此之外，用戶定義和注冊的消息、命令和控制通知都沒有默認的處理函數(shù)，需要在定義時聲明，一般根據(jù)其 稱來為函數(shù)命名 7。 系統(tǒng)架構(gòu)的模式 C/S 結(jié)構(gòu)，即 戶機 /服務(wù)器 )結(jié)構(gòu)， 軟件系統(tǒng)體系結(jié)構(gòu)，通過將任 務(wù) 合理分配到 和 ，降低了系統(tǒng)的通訊開銷，可以充分利用兩端硬件環(huán)境的優(yōu)勢。 C/S 模式即 構(gòu)模式 構(gòu)，它的發(fā)展經(jīng)歷了兩個階段：從兩層結(jié)構(gòu)到三層結(jié)構(gòu)。 1. 兩層結(jié)構(gòu)：它由兩部分構(gòu)成：前端是客戶機，通常是 要完成用戶界面顯示，接受數(shù)據(jù)輸入，校驗數(shù)據(jù)有效性，向后臺數(shù)據(jù)庫發(fā)請求，接受返回結(jié)果，處理應(yīng)用邏輯；后端是服務(wù)器，運行 供數(shù)據(jù)庫的查詢和管理。應(yīng)用邏輯主要在前端，如在后端則是存儲過程的形式。 2. 三層結(jié)構(gòu)：利用中間件將應(yīng)用分為表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)存儲層三個不同的處理層次。三個層次的劃分是從邏輯上來分的，具體的物理分法可以有多種組合。基于三層結(jié)構(gòu)的應(yīng)用系統(tǒng)不但具備了大型機系統(tǒng)穩(wěn)定、安全和處理能力高等特性，同時擁有開放系統(tǒng)成本低、可擴展性強、開發(fā)周期短等優(yōu)點。而中間件作為構(gòu)造三層結(jié)構(gòu)應(yīng)用系統(tǒng)的基 礎(chǔ)平臺，提供了以下主要功能：負責客戶機與服務(wù)器間、服務(wù)器間與服務(wù)器間的聯(lián)接和通訊；實現(xiàn)應(yīng)用與數(shù)據(jù)庫的高效連接；提供一個三層結(jié)構(gòu)應(yīng)用的開發(fā)、運行、部署和管理的平臺。 6 ， 服務(wù)器端首先監(jiān)聽一個固定端口，客戶端再連接到服務(wù)端，此時服務(wù)端執(zhí)行 作，以接受客戶端的連接 。 此時連接創(chuàng)建成功，則進行數(shù)據(jù)傳輸，待數(shù)據(jù)傳輸完畢，服務(wù)端和客戶端就斷開連接。 圖 2 通信流程 C/S 結(jié)構(gòu)的優(yōu)點 術(shù)在目前程序開發(fā)中得到了廣泛的應(yīng)用 ， 這種技術(shù)的優(yōu)點在于它將處理工作按照一定的比例分配到客戶端和服務(wù)器上去執(zhí)行，這樣減少了網(wǎng)絡(luò)傳輸?shù)墓ぷ髁浚瑥亩侠淼乩昧速Y源，提高了應(yīng)用程序開發(fā)的效率。由于客戶端實現(xiàn)與服務(wù)器的直接相連，沒有中間環(huán)節(jié)，因此響應(yīng)速度快。 術(shù) 簡介 統(tǒng)下的編程，消息 傳遞是貫穿其始終的。這個消息可以簡單理解為一個有特定意義的整數(shù)，正如老故 事片中的 “ 長江長江，我是黃河 ”一個含義。 定義的消息給初學者的印象似乎是 “ 不計其數(shù) ” 的，常見監(jiān)聽 創(chuàng)建 接受 數(shù) 據(jù) 傳 輸 斷開 連接 創(chuàng)建 數(shù) 據(jù) 傳 輸 斷開 7 的一部分消息在 文件中定義。 消息有著非常密切的聯(lián)系，它的中文含義是 “ 鉤子 ” ，這樣理解起來不難得出 “ 消息處理中的一個環(huán)節(jié)，用于監(jiān)控消息在系統(tǒng)中的傳遞，并在這些消息到達最終的消息處理過程前，處理某些特定的消息 ” 。這也是 為不同種類的原因。 在 經(jīng)常 接觸到 用的 天隨著控件， 術(shù)的出現(xiàn)， 諸如控件這些現(xiàn)成的手段不能實現(xiàn)的功能時，因此 還需要借助 初有些人對某些 產(chǎn)生了如何修改這些 之更好的服務(wù)于程序的想法，這樣 過 變一個系統(tǒng) 本的方法就是通過 接觸 ”到需要修改的 變它的地址指向新的自定義的函數(shù)。 3類 以說， 什么特別不同的 也需要通過基本的 越不同進程間訪問的限制，達到修改 的簡單介紹 通過類名就知道這是一個異步非阻塞 什么是異步非阻塞呢？舉個例子：一位體育老師，需要測驗 100位同學的 400米 成績。 老師 每隔 10秒讓一位同學起跑，直到所有同學出發(fā)完 畢；另一邊每有一個同學回到終點就記錄成績，直到所有同學都跑完。 老師 設(shè)計了兩個函數(shù)， 其中一個函數(shù)記錄起跑時間和學生號，該函數(shù)會主動調(diào)用 100次；另一個函數(shù)記錄到達時間和學生號，該函數(shù)是一個事件驅(qū)動的 有同學到達終點時，被動調(diào)用。 老師 主動調(diào)用的函數(shù)是異步的，因為 調(diào)用它 時 ，它并不會 立刻返回 ；這個函數(shù)也是非阻塞的，因為一旦調(diào)用它，它就馬上返回， 不用等待就可以再次調(diào)用它。 這就是異步非阻塞模式。 然而，最不容易被初學 是本課題最要提醒的一點是，客戶方在使用 時，往往返回一個 其它的某些函數(shù)調(diào)用也如此 ，如： ,等 ） ，實際上這不應(yīng)該算作一個錯誤，它是 醒 用戶 ，由于使用了非阻塞以 （ 連接 ） 操作需要時間，不能瞬間建立。 因此 可以 在程序中 等待 ，等它連接成功為止，于是許多程序員就在調(diào)用 之后， )，然后不停地用 或者 查看 8 直到返回成功為止。這是一種錯誤的做法， 不能達到預(yù)期 目的。事實上， 可以在調(diào)用之后等待 事件被觸發(fā)，是要表明 么連接徹底失敗了 。 9 第三章 需求分析 系統(tǒng)基本情況描述 隨著計算機技術(shù)的不斷發(fā)展， 人們 要處理的任務(wù)也越來越多， 工作地點也有可能是多個，在計算機使用的過程中就會遇到這樣那樣的問題 ，從而使得工作變得更加繁重 。 如果將計算機系統(tǒng)進行還原或重裝，一些重要 資料有可能將會丟失。尋求一種方便、高效的方法對出現(xiàn)故障的系統(tǒng)進行修復(fù)已經(jīng)成為人們的迫切需要 。本課題設(shè)計 的使用，能幫助技術(shù)人員方便、高效的修復(fù)遠程系統(tǒng)軟件，提高人們的工作效率，降低系統(tǒng)維護的成本 。 系統(tǒng)可行性分析 可行性研究的任務(wù)不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的方法。 可行性分析實質(zhì)上是要進行一次大大壓縮簡化了的系統(tǒng)分析和設(shè)計的過程，也就是在較高層次上以較抽象的方式進行的系統(tǒng)分析和設(shè)計的過程。 要研究每一種解法的可行性，一般說來，應(yīng)從經(jīng)濟可行性、技術(shù)可行性、 操 作可行性 等方面研究可行性 12。 經(jīng)濟可行性 本課題設(shè)計 成本低廉，要的只是兩個 發(fā)的 址，而且這也多用于局域網(wǎng)或企業(yè)網(wǎng)等內(nèi)網(wǎng)，就更談不上成本上的問題。但是如果需要對程序的質(zhì)量提高可以購買 加密 算法，對傳輸數(shù)據(jù)進行加密。 技術(shù)可行性 本課題設(shè)計 所用到的一系列的技術(shù)已是累積了幾十年的技術(shù)，這些技術(shù)在這么多年的發(fā)展中并沒有被淘汰，反而是越來越來熱門。當初遠程 協(xié)助 這門技術(shù)在 是受網(wǎng)絡(luò)的制約，但是此時這門技術(shù)還是受網(wǎng)絡(luò)技術(shù)制約著。網(wǎng)絡(luò)流量的問題是造成所有通信 程序的不穩(wěn)定性的罪魁禍首。但是 本課題設(shè)計 在局域網(wǎng)中是完全能夠?qū)崿F(xiàn)的，而且也是專門為企業(yè)網(wǎng)內(nèi)部所設(shè)計，因為數(shù)據(jù)信息沒被加密，如果想走 需建立 操作可行性 根據(jù)系統(tǒng)的操作是否簡單易懂，是否為用戶所接受，從操作的角度研究系統(tǒng)的可行性。 本課題設(shè)計 操作簡單，客戶端安裝后無需其它操作，服務(wù)端待客戶端 10 自動連接后，則可以對其屏幕、文件、注冊表等進行操作，完全像操作本地機器一樣簡單 。 綜合以上三方面的可行性分析， 本課題設(shè)計 的操作 是可行的。 功能需求 分析 功能需求是對軟件系統(tǒng)的 一項基本需求，這方面的需求指定系統(tǒng)必須提供的服務(wù)。 根據(jù)對 一般的遠程協(xié)助 的調(diào)查了解， 該系統(tǒng)應(yīng)該至少包含以下幾個功能 ： 1. 服務(wù)端對 客戶端的屏幕監(jiān)控 。 遠程協(xié)助系統(tǒng)就是 要 解決那些 難以 用語言描述的軟件問題， 協(xié)助端（服務(wù)端）如果能實時的看見被協(xié)助端（客戶端）的系統(tǒng)桌面，那將大大提高解決 問題的效率。 當然，為了更方便的操作，協(xié)助端還 必須能 控制被協(xié)助端的鼠標和鍵盤 。 系統(tǒng) 服務(wù)端 桌面監(jiān)控 的 用例圖如圖 3 圖 3面監(jiān)控 用例圖 2. 服務(wù)端對客戶端文件操作 。 服務(wù)端如果僅僅能監(jiān)控客戶端桌面，那幫助也許沒那么大，比如客戶端要修復(fù)一些文件，而在客戶端本地硬盤中又沒有相應(yīng)的修復(fù)工具，此時服務(wù)端也是無能為力的。當然，可以通過 通訊工具傳輸，這樣做畢竟也是很麻煩的，因此服務(wù)端能實現(xiàn)對客戶端 的 文件 遠程操作則是不可或缺 的。 文件操作包括：上傳文件、下載文件、修改文件名、創(chuàng)建文件夾、執(zhí)行遠程程序 等等 。 該 功 能 模 塊 的 用 例 圖 如圖 3示 ： 獲取遠程桌面 控制遠程鼠標 控制遠程鍵盤 遠程協(xié)助系統(tǒng) 11 圖 3件操作用例圖 3. 服務(wù)端對客戶端的高級操作 。 對于維護和修復(fù)一個系統(tǒng)，難免要與系統(tǒng)注冊表、 系統(tǒng) 服務(wù)、進程打交道，在桌面監(jiān)控功能中雖然能實現(xiàn)對這些功能的操作，但是畢竟受到網(wǎng)絡(luò)帶寬的限制，遠程桌面圖片傳輸較慢，實時性較低。 服務(wù)端向客戶端發(fā)送一條命令，客戶端針對該命令分別枚舉出客戶端的注冊表、系統(tǒng)服務(wù)、進程等，再以文本方式發(fā)送給服務(wù)端，服務(wù)端獲取到信息后，則可以對注冊表、系統(tǒng)服務(wù)、進程做刪除、添加、結(jié)束等操作。 4. 消息廣播 。 服務(wù)端可以同時被多個客戶端連接，消息廣播則合適企業(yè)或?qū)W校的管理 。 在該功能中，服 務(wù)端有權(quán)限阻止客戶端發(fā)送的廣播消息，也有權(quán)限向某一客戶端發(fā)送消息。 5. 自動上線 。 自動上線其實就是一種反彈式連接，該功能 只需 應(yīng)用在服務(wù)端動態(tài)的情況 下 。服務(wù)端首先要擁有一個動態(tài)域名，假設(shè)為： ，然后將此時服務(wù)端的 新到一個頁面中，如： ，客戶端則不斷去訪問該頁面，以便獲取服務(wù)端最新的 后連接到服務(wù)端。 6. 進程守護。對于企業(yè)或?qū)W校的多客戶端連接，為了能使得管理順利進行，則需對客戶端進程進行保護，防止被惡意結(jié)束。 上傳文件到客戶端 下載客戶端文件 修 改文件名 遠程協(xié)助系統(tǒng) 創(chuàng)建文件夾 執(zhí)行遠程程序 12 系 統(tǒng)流程圖 安裝好客戶端后，客戶端則會不斷的嘗試連接服務(wù)器， 連接成功了就會根據(jù)服務(wù)端發(fā)送的操作命令執(zhí)行不同的操作，再將結(jié)果返回給服務(wù)端 ，本系統(tǒng)流程圖如圖 3示 ： 圖 3統(tǒng)流程圖 連接服務(wù)端 連接成功 ？ 客戶端程序 服務(wù)端程序 接受并添加客戶端信息 失敗 成功 發(fā)送 登 錄 信息 發(fā)送操作命令 解析命令 屏幕操作 文件操作 注冊表操作 服務(wù)操作 進程操作 發(fā)送結(jié)果 顯示結(jié)果 是否退出？ 退出系統(tǒng) 是 否 13 第四章 總體設(shè)計 經(jīng)過需求分析階段，在軟件需求分析階段已經(jīng)弄清楚了 各種需求，較好地解決了所開發(fā)的系統(tǒng) “ 做什么 ” 的問題，并已在軟件需求說明書和數(shù)據(jù)要求說明書中詳盡和充分地闡明了這些需求以后，下一步就要著手對軟件系統(tǒng)的結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、用戶界面等進行設(shè)計 。 使 用工具 本系統(tǒng)采用 + 為開發(fā)工具 ，客戶端調(diào)試使用 擬機 。 系統(tǒng)模塊的設(shè)計 模塊設(shè)計 本系統(tǒng)面向的對象有兩種，一種是 服務(wù)端 ，一種是 客戶端 。 服務(wù)端只要是向客戶端發(fā)送操作命令，客戶端解析命令后執(zhí)行相應(yīng)操作，然后將結(jié)果返回給服務(wù)端 ，服務(wù)端再將結(jié)果顯示出來 。 屏幕監(jiān)控 模塊 設(shè)計 屏幕監(jiān)控，也就是將客戶端的屏幕截圖，然后發(fā)送給服務(wù)端。由于截圖圖片格式為 幀圖像數(shù)據(jù)量很大，因此在此模塊中引用第三方開源類庫壓 縮庫 截圖在內(nèi)存中壓縮成 式，然后再調(diào)用 壓縮函數(shù)進一步對 縮，最后再發(fā)送給服務(wù)端。鼠標和鍵盤的操作則是通過模擬來實現(xiàn)，在服務(wù)端捕獲鼠標鍵盤操作后，服務(wù)端的命令連接就會將捕獲的結(jié)果發(fā)送到客戶端，客戶端再 通過調(diào)用 兩個 數(shù)進行模擬鼠標鍵盤操作。 該模塊 大致 流程圖 如圖 4示 ： 14 圖 4幕監(jiān)控 大致 流程圖 文件 操作 模塊 設(shè)計 文件操作，包括文件上傳、文件下 載、刪除文件、修改文件名、執(zhí)行遠程程序 。 在文件傳輸過程中，服務(wù)端能顯示傳輸進度，也可以終止傳輸 。 該模塊大致流程圖如圖 4示 ： 發(fā)送截屏命令 解析命令 截屏 圖片壓縮 添加數(shù)據(jù)包尾 發(fā)送數(shù)據(jù) 接收數(shù)據(jù) 是數(shù)據(jù)包尾嗎？ 模擬鼠標點擊移動 模擬鍵盤操作 是 否 數(shù)據(jù)包解壓 顯示圖片 服務(wù)端 客戶端 發(fā)送鍵盤鼠標命令 停止傳輸嗎？ 開始屏幕傳輸 停止屏幕傳輸 是 否 15 圖 4件操作 大致 流程圖 命令操作模塊 設(shè)計 命令操作，包括系統(tǒng)注冊表、服務(wù)、進程、消息廣播、執(zhí)行 啟或關(guān)閉遠程計算機等操作，命令操作傳輸?shù)臄?shù)據(jù)量小，響應(yīng)快 。 為了客戶端程序能正常對進程、服務(wù)等操作，還必須對客戶端進程進行提升權(quán)限操作。 該模塊的功能模塊圖如圖 4示： 發(fā)送命令 解析命令 修改文件名 執(zhí)行遠程程序 服務(wù)端 客戶端 刪除文件 文件傳輸 文件傳輸 發(fā)送結(jié)果 顯示結(jié)果 停止傳輸嗎？ 停止傳輸 是 否 16 圖 4令操作 功能模塊圖 務(wù)器模塊 設(shè)計 對于使用自動上線的用戶來說，如果系統(tǒng)包含 務(wù)器的話就會比較方便，因此在該遠程協(xié)助系統(tǒng)中，嵌入了簡單的 務(wù)器，用戶可以借助這兩個服務(wù)器 ，將服務(wù)端的 新到動態(tài)域名的某個文件中， 使得客戶端能夠自動上線 。 塊設(shè)計 本系統(tǒng)采用 術(shù)對客戶端進程進行守護，達到防止客戶端進程被惡意結(jié)束的目的。 該功能采用了微軟的開源類庫 兩個系統(tǒng) 行 從而實現(xiàn)對客戶端進程進行守護的目的。 遠程協(xié)助系統(tǒng) 遠程 注冊表 管理 遠程服務(wù)管理 遠程 作 遠程進程管理 遠程關(guān)機重啟管理 17 第五章 系統(tǒng)詳細設(shè)計 根據(jù)系統(tǒng)的主要功能及上一章的總體設(shè)計，系統(tǒng)進入 詳細設(shè)計 階段 。 詳細設(shè)計階段的根本目標是確定應(yīng)該怎樣具體地實現(xiàn)所要求的系統(tǒng)，經(jīng)過這個階段的設(shè)計工作，得出對目標系統(tǒng)的精確描述。 由于代碼較多，本章在說明部分功能時，只介紹了相關(guān)的函數(shù)和某些關(guān)鍵的 代碼 語句。 客戶端與服務(wù)器 連接 設(shè)計 載了 接和斷開的消息事 件，用戶可以在這些事件中判斷 連接情況，但是斷開消息事件在一種情況下無法觸發(fā)，也就是網(wǎng)線被拔掉或其中一方斷電時，為了解決這種情況，可以在服務(wù)端和客戶端中都添加一個連接時鐘，周期性的給對方發(fā)送一個心跳包，如果發(fā)送失敗則表示對方已經(jīng)斷開連接 ，此時則進入斷開重連狀態(tài) 。 對于異步非阻塞的 說，連接成功與否是在其 件里 判斷的 ， 該事件函數(shù)原型為： ，傳進的參數(shù)如果等于0，則表示連接成功。 相關(guān)代碼如下： = 0)/如果連接成功 024; 1024; ; ; 0; :&= 0; = | + | + |; 1024; 18 :&= 0; = 系統(tǒng)各模塊界面設(shè)計及其實現(xiàn) 屏幕監(jiān)控 模塊 服務(wù)端向客戶端第一次發(fā)送獲取屏幕命令時，客戶端并非立刻截屏然后 將數(shù)據(jù)發(fā)送 服務(wù)端 ，考慮到 多個 客戶端的屏幕分辨率大小不一致的情況 下 ， 客戶端首次收到服務(wù)端的屏幕監(jiān)控命令后，應(yīng)先將客戶端當前屏幕分辨率發(fā)送給服務(wù)端， 服務(wù)端在窗口上創(chuàng)建一個矩形區(qū)域用于顯示客戶端桌面圖片，然后才是屏幕數(shù)據(jù)的傳輸， 由于客戶端不停的發(fā)送屏幕數(shù)據(jù)，為了能使服務(wù)端區(qū)分每一 幀的屏幕，客戶端在發(fā)送屏幕數(shù)據(jù)前，