【正文】 設計 ................................................................................... 19 軟件體系結構設計 ........................................................................................ 19 系統(tǒng)的數(shù)據(jù)庫設計 ........................................................................................ 19 系統(tǒng)的功能模塊設計 .................................................................................... 20 5 系統(tǒng)詳細設計與實現(xiàn) ........................................................................ 22 登陸頁面的設計與實現(xiàn) ................................................................................ 22 登陸后界面的設計 與實現(xiàn) ............................................................................ 23 功能模塊的設計與實現(xiàn) ................................................................................ 26 文件傳輸 .............................................................................................. 26 執(zhí)行遠端命令 ...................................................................................... 26 查看節(jié)點信息 ...................................................................................... 27 啟動遠程桌面 ...................................................................................... 27 管理遠程桌面 ...................................................................................... 27 提交作業(yè) .............................................................................................. 27 作業(yè)數(shù)據(jù)管理 ...................................................................................... 27 6 系統(tǒng)測試 ........................................................................................... 28 軟件測試基礎理論 ......................................................................................... 28 軟件測試定義 ...................................................................................... 28 軟件測試基本概念 .............................................................................. 28 軟件測試目的 ................................................................................................ 29 軟件測試方法分類 ........................................................................................ 29 靜態(tài)測試與動態(tài)測試 .......................................................................... 29 黑盒與白盒測試 .................................................................................. 29 單元測試、集成測試、系統(tǒng)測試、驗證測試和確認測試 .............. 30 系統(tǒng)測試 ........................................................................................................ 30 測試用例設計要求 .............................................................................. 30 系統(tǒng)各個模塊測試用例 ...................................................................... 31 測試報告 ......................................................................................................... 34 7 總結 ................................................................................................... 35 參考文獻 ............................................................................................... 36 致謝 .......................................................................... 錯誤 !未定義書簽。 1 緒論 1 1 緒論 課題設計背景 2020 年 8 月 9 日， google 首 席執(zhí)行官埃里克 之后包括 Google 、 IBM、雅虎、惠普、英特爾，以及戴爾在內(nèi)的世界頂尖級 IT 公司為推動和發(fā)展云計算不遺余力，爭先恐后。 云協(xié)作平臺其理論依據(jù)來源于云計算，自然是基于互聯(lián)網(wǎng)，將共享的軟硬件資源和信息 ,通過運行于服務器端的 資源調(diào)度管理系統(tǒng)（ JH scheduler） 統(tǒng)一協(xié)調(diào)，按需提供給計算機和其他設備，并對這些設備進行管理。瀏覽器和服務器 結構雖然簡化了客戶端電腦載荷，減輕了系統(tǒng)維護與升級的成本和工作量，降低了用戶的總體成本，然而瀏覽器和服務器結構也有一些自身無法克服的缺點?？蛻舳说某霈F(xiàn)恰恰解決了以上問題。瀏覽器旨在其靈活性，可移動性，而客戶端旨在其高度的集成性，以及其普適性，即可以集成操作系統(tǒng)上的所有應用，更方便的為用戶提供服務；普適性在于操作系統(tǒng)的較為明確，程序開發(fā)有的放矢，這樣也大大降低了開發(fā)成本，和開發(fā)、維護周期。 客戶端 /服務器結構在數(shù)據(jù)安全性方面也明顯高于瀏覽器 /服務器結構，可以較為容易地實現(xiàn)多層認證。服務器端的為 java web 實現(xiàn)，客戶端實現(xiàn)是用C++實現(xiàn)，兩者之間需要一個可以相互調(diào)用的接口。 論文結構安排 本論文共有四章，具體組織如下： 第一章：通過對已經(jīng)實現(xiàn)的云協(xié)作平臺的 Web 端功能分析，提出客戶端開發(fā)的目的和意義， 此次研究的主要任務，以及本次論文的組織 結構 。 第三章： 系統(tǒng)需求分析，其中包括用戶 需求分析、 性能需求分析 、 數(shù)據(jù)需求分析 。 第五章：系統(tǒng)詳細設計與實現(xiàn) ，用戶登錄頁面，操作界面，以及各個功能模塊的實現(xiàn)。一般是基于互聯(lián)網(wǎng)，也有用專業(yè)網(wǎng)的情況。 資源調(diào)度管理系統(tǒng)簡介 資源調(diào)度管理系統(tǒng) (以下稱 JH Scheduler)是一個集資源監(jiān)控和分布式應用調(diào)度為一體的云計算的基礎架構管理中間件，利用 JH Scheduler 可以快速的建立起一個完整企業(yè)級應用服務平臺。 JH Scheduler 具有完備的和可擴展的資源定義、監(jiān)控等功能，包括硬件資源、操作系統(tǒng)、軟件許可證資源、存儲資源等等，并且為應用軟件提供多種接口來使用這些云計算資源，從而輕易實現(xiàn)應用軟件的并行分布式運行和彈性 計算，完成從傳統(tǒng)的以服務器為中心的計算模式向以應用服務為中心的計算模式遷移。 由 JH Scheduler 管理的應用集群系統(tǒng)具有高可用性，用戶可以配置多個管理節(jié)點，即使只有一個JH Scheduler 管理節(jié)點正常運行，應用集群服務也不會宕機，做到應用服務的全天候可 用，為用戶和應用提供最佳的計算服務。此外， JH Scheduler 還有可擴展的接口，可以為特殊的管理調(diào)度需求定制策略。即使在執(zhí)行過程中計算節(jié)點出現(xiàn)故障， JH Scheduler 仍然可以把作業(yè)重新調(diào)度到其它機器上繼續(xù)執(zhí)行。 JH Scheduler 產(chǎn)品的總體結構如圖 所示。這個主題對象在狀態(tài)發(fā)生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。我們不希望為了維持一致性而使各類緊密耦合， 這樣會給維護、擴展和重用都帶來不便。 模式中的角色 抽象主題（ Subject）：它把所有觀察者對象的引用保存到一個聚集里，每個主題都可以有任何數(shù)量的觀察者。 具體主題（ ConcreteSubject）：將有關狀態(tài)存入具體觀察者對象；在具體主題內(nèi)部狀態(tài)改變時，給所有登記過的觀察者發(fā)出通知。 5 具體觀察者（ ConcreteObserver）：實現(xiàn)抽象觀察者角色所要求的更新接口，以便使本身的狀態(tài)與主題狀態(tài)協(xié)調(diào)。 如 圖 詳細的描述了這樣一種過程 ： 圖 觀察者模式實現(xiàn)過程 觀察者 （ Observer）將自己注冊到被觀察對象（ Subject）中，被觀察對象將觀察者存放在一個容器（ Container）里。 撤銷觀察 觀察者告訴被觀察者要撤銷觀察，被觀察者從容器中將觀察者去除。這樣的優(yōu) 點是：假定程序中還有別的觀察者，那么只要這個觀察者也是相同的接口實現(xiàn)即可?；诮涌?，而不是具體的實現(xiàn) ——這一點為程序提供了更大的靈活性。從而使得各自的變化都不會影響另一邊的變化。 6 適用場景 當一個對象的改變需要給變其它對象時，而且它不知道具體有多少個對象有待改變時。 Thrift 庫 Thrift 簡介 Thrift 是一個跨語言的服務部署框架，最初由 Facebook于 2020 年開發(fā)， 2020年進入 Apache 開源項目。 Thrift 架構 圖 Thrift 架構 Thrift 實際上是實現(xiàn)了 C/S 模式，通過代碼生 成工具將接口定義文件生成服務器端和客戶端代碼（可以為不同語言）， 從而實現(xiàn)服務端和客戶端跨語 言的支持。其中 protocol（協(xié)議層 , 定義數(shù)據(jù)傳輸格式，可以為二進制或者 XML等）和 transport（傳輸層，定義數(shù)據(jù)傳輸方式，可以為 TCP/IP 傳輸，內(nèi)存共享或者文件共享等）被用 作運行時庫 。 TDebugProtocol – 使用易懂的可讀的文本格式，以便于 debug （ 2）支持的數(shù)據(jù)傳輸方式 TSocket 阻塞式 socker TFramedTransport – 以 frame 為單位進行傳輸，非阻塞式服務中使用。 TMemoryTransport – 將內(nèi)存用于 I/O. java 實現(xiàn)時內(nèi)部實際使用了簡單的ByteArrayOutputStream。當前無 java實現(xiàn)。 TNonblockingServer – 多線程服務模型，使用非阻塞式 IO（需使用TFramedTransport 數(shù)據(jù)傳輸方式） Thrift 使用 （ 1） 編譯安裝： ./configure –》 make –》 make install （ 2） 利用 Thrift 部署服務 主要流程：編寫服務說明，保存到 .thrift 文件 –》根據(jù)需要，編譯 .thrift 文件，生成相應的語言源代碼 –》根據(jù)實際需要，編寫 client 端和 server 端代碼。 b） client 端和 server 端代碼編寫 client 端和 server 端代碼要調(diào)用編譯 .thrift 生成的中間文件。 在 server 端，需要實現(xiàn)在 .thrift 文件中聲明的服務中的所有功能，以便處理 client 發(fā)過來的請求。 8 圖 client