基于云協(xié)作平臺的客戶端設計與實現(xiàn)畢業(yè)論文

1、<p>　　題目：基于云協(xié)作平臺的客戶端設計與實現(xiàn)</p><p>　　基于云協(xié)作平臺的客戶端設計與實現(xiàn)</p><p><b>　　摘要</b></p><p>　　云協(xié)作平臺其理論依據(jù)來源于云計算，是基于互聯(lián)網，將共享的軟硬件資源和信息,通過云資源調度管理系統(tǒng)（JH scheduler），按需提供給計算機和其他設備，并對這些設備進

2、行管理。云協(xié)作平臺通常提供通用的通過瀏覽器訪問的應用，軟件和數(shù)據(jù)可存儲在數(shù)據(jù)中心。瀏覽器和服務器結構雖然簡化了客戶端電腦載荷，減輕了系統(tǒng)維護與升級的成本和工作量，降低了用戶的總體成本，然而瀏覽器和服務器結構也有一些自身無法克服的缺點?，F(xiàn)如今，瀏覽器種類繁多，良莠不齊，這樣，就引發(fā)了一個很難做到平衡的問題——瀏覽器的兼容性問題，還有一個根問重要的是：如果要將本地的一些應用程序集成到云平臺，瀏覽器就顯得捉襟見肘了?？蛻舳说某霈F(xiàn)恰恰解決了以上

3、問題。</p><p>　　本文基于云協(xié)作平臺，以瀏覽器實現(xiàn)的功能為設計參考，重點在于節(jié)省系統(tǒng)軟硬件資源，避免不同瀏覽器帶來的瀏覽器兼容性問題，增強云協(xié)作平臺前端的可擴展性，并為客戶端增加一些與服務端交互的工具，提高云協(xié)作平臺的用戶體驗和產品的認可度?？蛻舳说膶崿F(xiàn)是以觀察者模式為設計模式，以QT GUI為開發(fā)框架，使用Thrift，Boost等第三方工具庫。做到與瀏覽器端高度一致，與服務器端接口兼容，又具有客戶端

4、特色的云協(xié)作平臺的用戶前端軟件。</p><p>　　通過幾個月的學習和努力，熟悉了服務器端的運行機制，以及服務器和瀏覽器的交互過程，在此基礎上參考瀏覽器端實現(xiàn)的用戶操作界面，實現(xiàn)了與瀏覽器端功能相同的客戶端。經過測試，運行穩(wěn)定，可以投放使用。</p><p>　　關鍵詞:云協(xié)作平臺；JH scheduler；客戶端；QT GUI</p><p>　　Design

5、and Implementation of the Client On Cloud Collaboration Platform</p><p><b>　　Abstract</b></p><p>　　Cloud collaboration platform the theoretical basis from the cloud computing, Intern

6、et based, will be shared hardware and software resources and information be provided to computers and other equipment, and management of these devices. Cloud collaboration platforms usually provide generic application th

7、rough the browser, software and data can be stored in the data center. The browser and the server mechanism while simplifying the client computer load, reduce the cost and the workload of system ma</p><p>　　

8、In this paper, cloud based collaboration platform, the browser functions as a design reference, Through resource scheduling management system (JH scheduler)， focused on saving the system software and hardware resources,

9、avoid browser compatibility problems caused by cloud browser, enhanced collaboration platform front-end scalability, and to increase the number of interactive tools for the client and server, improve the recognition of c

10、loud cooperation platform user experience and product the. T</p><p>　　Through several months of study and work, familiar with the operation mechanism of the server, and the server and browser interaction pro

11、cess, the user operation interface on the basis of browser implementation, achieved with the same client browser function. After testing, stable operation, can be put in use.</p><p>　　Key Words: Cloud collab

12、oration platform ; JH scheduler ;The client;QT GUI</p><p><b>　　目錄</b></p><p><b>　　摘要I</b></p><p>　　AbstractII</p><p><b>　　1 緒論1</b&g

13、t;</p><p>　　1.1課題設計背景1</p><p>　　1.2課題設計的目的和意義1</p><p>　　1.3課題的主要研究工作1</p><p>　　1.4 論文結構安排2</p><p>　　2 課題設計的關鍵技術3</p><p>　　2.1 資源調度管理系統(tǒng)簡介

14、3</p><p>　　2.2 觀察者模式簡介4</p><p>　　2.2.1 概述4</p><p>　　2.2.2 解決的問題4</p><p>　　2.2.3 模式中的角色4</p><p>　　2.2.4 模式解讀5</p><p>　　2.2.5 模式總結5</p&

15、gt;<p>　　2.3 Thrift庫6</p><p>　　2.3.1 Thrift簡介6</p><p>　　2.3.2 Thrift架構6</p><p>　　2.3.3 支持的數(shù)據(jù)傳輸格式、數(shù)據(jù)傳輸方式和服務模型7</p><p>　　2.3.4 Thrift使用7</p><p>　

16、　2.4 Boost庫8</p><p>　　2.4.1 Boost庫簡介8</p><p>　　2.4.2 Boost的log庫8</p><p>　　2.5 QT GUI簡介10</p><p>　　2.5.1 QT GUI簡介和功能特點10</p><p>　　2.5.2 信號和槽10</p&g

17、t;<p>　　2.5.3 樣式表11</p><p>　　2.5.4 QtWebKit12</p><p>　　3 系統(tǒng)需求分析14</p><p>　　3.1 用戶需求分析14</p><p>　　3.2 性能需求分析15</p><p>　　3.3 數(shù)據(jù)需求分析17</p>

18、<p>　　4 系統(tǒng)概要設計19</p><p>　　4.1 軟件體系結構設計19</p><p>　　4.2 系統(tǒng)的數(shù)據(jù)庫設計19</p><p>　　4.3 系統(tǒng)的功能模塊設計20</p><p>　　5 系統(tǒng)詳細設計與實現(xiàn)22</p><p>　　5.1 登陸頁面的設計與實現(xiàn)22</

19、p><p>　　5.2 登陸后界面的設計與實現(xiàn)23</p><p>　　5.3 功能模塊的設計與實現(xiàn)26</p><p>　　5.3.1 文件傳輸26</p><p>　　5.3.2 執(zhí)行遠端命令26</p><p>　　5.3.3 查看節(jié)點信息27</p><p>　　5.3.4 啟動遠

20、程桌面27</p><p>　　5.3.5 管理遠程桌面27</p><p>　　5.3.6 提交作業(yè)27</p><p>　　5.3.7 作業(yè)數(shù)據(jù)管理27</p><p><b>　　6 系統(tǒng)測試28</b></p><p>　　6.1軟件測試基礎理論28</p>&l

21、t;p>　　6.1.1 軟件測試定義28</p><p>　　6.1.2 軟件測試基本概念28</p><p>　　6.2 軟件測試目的29</p><p>　　6.3 軟件測試方法分類29</p><p>　　6.3.1 靜態(tài)測試與動態(tài)測試29</p><p>　　6.3.2 黑盒與白盒測試29&l

22、t;/p><p>　　6.3.3 單元測試、集成測試、系統(tǒng)測試、驗證測試和確認測試30</p><p>　　6.4 系統(tǒng)測試30</p><p>　　6.4.1 測試用例設計要求30</p><p>　　6.4.2 系統(tǒng)各個模塊測試用例31</p><p>　　6.5測試報告34</p><p

23、><b>　　7 總結35</b></p><p><b>　　參考文獻36</b></p><p><b>　　致謝37</b></p><p><b>　　附錄40</b></p><p><b>　　1 緒論</b>

24、;</p><p>　　1.1課題設計背景</p><p>　　2006年8月9日，google首席執(zhí)行官埃里克·施密特(Eric Schmidt)在搜索引擎大會(SES San Jose 2006)首次提出“云計算”(Cloud Computing)的概念。之后包括Google 、IBM、雅虎、惠普、英特爾，以及戴爾在內的世界頂尖級IT公司為推動

25、和發(fā)展云計算不遺余力，爭先恐后。云計算理論逐步成熟和結構趨于完整，基于云計算的產品應運而生，云協(xié)作平臺就是其中的一個典型。</p><p>　　云協(xié)作平臺其理論依據(jù)來源于云計算，自然是基于互聯(lián)網，將共享的軟硬件資源和信息,通過運行于服務器端的資源調度管理系統(tǒng)（JH scheduler）統(tǒng)一協(xié)調，按需提供給計算機和其他設備，并對這些設備進行管理。云協(xié)作平臺通常提供通用的通過瀏覽器訪問的應用，軟件和數(shù)據(jù)可存儲在數(shù)據(jù)中

26、心。瀏覽器和服務器結構雖然簡化了客戶端電腦載荷，減輕了系統(tǒng)維護與升級的成本和工作量，降低了用戶的總體成本，然而瀏覽器和服務器結構也有一些自身無法克服的缺點?，F(xiàn)如今，瀏覽器種類繁多，良莠不齊，這樣，就引發(fā)了一個很難做到平衡的問題——瀏覽器的兼容性問題，還有一個更為重要的是：如果要將本地的一些應用程序集成到云協(xié)作平臺，瀏覽器就顯得捉襟見肘了?？蛻舳说某霈F(xiàn)恰恰解決了以上問題。</p><p>　　1.2課題設計的目的和

27、意義</p><p>　　瀏覽器能夠實現(xiàn)的功能，客戶端同樣也可以實現(xiàn)，但這并不是說，客戶端就可以完全取代瀏覽器來實現(xiàn)與云平臺的交互，完成生產實踐。瀏覽器旨在其靈活性，可移動性，而客戶端旨在其高度的集成性，以及其普適性，即可以集成操作系統(tǒng)上的所有應用，更方便的為用戶提供服務；普適性在于操作系統(tǒng)的較為明確，程序開發(fā)有的放矢，這樣也大大降低了開發(fā)成本，和開發(fā)、維護周期?？蛻舳?服務器結構能充分發(fā)揮客戶端PC的處理能力，

28、很多工作可以在客戶端處理后再提交給服務器，這樣可以提高工作效率，縮短工作時間，使云平臺能夠更高效、快捷的工作?？蛻舳?服務器結構在數(shù)據(jù)安全性方面也明顯高于瀏覽器/服務器結構，可以較為容易地實現(xiàn)多層認證。</p><p>　　1.3課題的主要研究工作</p><p>　　由于云協(xié)作平臺的瀏覽器版已經實現(xiàn)，而客戶端版是盡量和瀏覽器版保持一致，因此，熟悉服務器端運行機制和瀏覽器版的基本結構使得開

29、發(fā)客戶端變得有的放矢，也就相對容易的多了。服務器端的為java web實現(xiàn)，客戶端實現(xiàn)是用C++實現(xiàn)，兩者之間需要一個可以相互調用的接口。除此之外，從服務器端拿到的數(shù)據(jù)列表需要顯示在客戶端的對話框頁面，而這些數(shù)據(jù)列表是在瀏覽器端已經</p><p>　　實現(xiàn)的，在對話框上能夠直接顯示web頁面，就使得開發(fā)工作量減輕許多，這樣也為客戶端節(jié)省了響應時間。</p><p>　　1.4 論文結構安

30、排</p><p>　　本論文共有四章，具體組織如下：</p><p>　　第一章：通過對已經實現(xiàn)的云協(xié)作平臺的Web端功能分析，提出客戶端開發(fā)的目的和意義，此次研究的主要任務，以及本次論文的組織結構。</p><p>　　第二章：主要介紹資源調度管理系統(tǒng)（JH scheduler）和開發(fā)本系統(tǒng)所采用的相關技術，包括設計模式中的觀察者模式，Thrift庫、Boost

31、庫以及QT GUI編程等。</p><p>　　第三章：系統(tǒng)需求分析，其中包括用戶需求分析、性能需求分析、數(shù)據(jù)需求分析。</p><p>　　第四章：系統(tǒng)概要設計，從軟件體系結構，數(shù)據(jù)庫設計，系統(tǒng)功能模塊設計等方面敘述。</p><p>　　第五章：系統(tǒng)詳細設計與實現(xiàn)，用戶登錄頁面，操作界面，以及各個功能模塊的實現(xiàn)。</p><p><

32、b>　　第六章：系統(tǒng)測試</b></p><p><b>　　第七章：總結</b></p><p>　　2 課題設計的關鍵技術</p><p>　　云協(xié)作平臺是通過資源調度管理系統(tǒng)，統(tǒng)一對用戶作業(yè)需求進行動態(tài)管理、分配資源的協(xié)作的系統(tǒng)。一般是基于互聯(lián)網，也有用專業(yè)網的情況。云協(xié)作平臺的主要功能是：分工合作、資源控制、作業(yè)管理等

33、功能。</p><p>　　2.1 資源調度管理系統(tǒng)簡介</p><p>　　資源調度管理系統(tǒng)(以下稱JH Scheduler)是一個集資源監(jiān)控和分布式應用調度為一體的云計算的基礎架構管理中間件，利用JH Scheduler可以快速的建立起一個完整企業(yè)級應用服務平臺。它可以監(jiān)控、調度、管理網絡上的10臺到上千臺不同操作系統(tǒng)的服務器、工作站和虛擬機，把它們作為云計算資源集中管理起來為多種類型

34、的應用軟件提供統(tǒng)一服務平臺。 JH Scheduler具有完備的和可擴展的資源定義、監(jiān)控等功能，包括硬件資源、操作系統(tǒng)、軟件許可證資源、存儲資源等等，并且為應用軟件提供多種接口來使用這些云計算資源，從而輕易實現(xiàn)應用軟件的并行分布式運行和彈性計算，完成從傳統(tǒng)的以服務器為中心的計算模式向以應用服務為中心的計算模式遷移。 JH Scheduler支持多種類型應用軟件的通用中間件，包括CAD/CAE軟件、制造業(yè)設計軟件、石油勘探分析軟件、模擬仿

35、真軟件、科學計算軟件等，這些不同類型的應用軟件可以同時使用JH Scheduler管理的應用集群，從而實現(xiàn)計算資源的充分共享。 由JH Scheduler管理的應用集群系統(tǒng)具有高可用性，用戶可以配置多個管理節(jié)點，即使只有一個JH Schedule</p><p>　　為了使計算資源得到高效使用，JH Scheduler內置多種高效的管理調度策略，包括先來先服務、用戶/用戶組資源配額管理、基于隊列的優(yōu)先級設置、資源

36、公平共享調度、獨占式作業(yè)調度、搶占式作業(yè)調度等，基于這些策略，JH Scheduler把應用軟件的每一次執(zhí)行實例作為一個作業(yè)來進行調度和管理，并為管理員和作業(yè)的用戶提供方便的作業(yè)狀態(tài)監(jiān)控和友好的用戶界面。此外，JH Scheduler還有可擴展的接口，可以為特殊的管理調度需求定制策略。 由JH Scheduler管理的應用集群系統(tǒng)具有高可靠性，作業(yè)在沒有資源的情況下將在系統(tǒng)中排隊等待資源。即使在執(zhí)行過程中計算節(jié)點出現(xiàn)故障，JH Sche

37、duler仍然可以把作業(yè)重新調度到其它機器上繼續(xù)執(zhí)行。 </p><p>　　作為云計算基礎架構產品，JH Scheduler與其基礎之上的Web portal產品提供安全友好的用戶管理和使用界面；通過與JH License Manager集成管理應用集</p><p>　　群系統(tǒng)的許可證資源，并提供專門針對許可證資源的先進調度；通過與JH Analytics集成為用戶提供豐富的資源使用和

38、作業(yè)調度報表功能，以及詳盡靈活的計費系統(tǒng)。 </p><p>　　JH Scheduler產品的總體結構如圖2.1所示。</p><p>　　圖2.1 JH scheduler 總體結構圖</p><p>　　2.2 觀察者模式簡介</p><p><b>　　2.2.1 概述</b></p><p&

39、gt;　　觀察者模式有時被稱作發(fā)布/訂閱模式，觀察者模式定義了一種一對多的依賴關系，讓多個觀察者對象同時監(jiān)聽某一個主題對象。這個主題對象在狀態(tài)發(fā)生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。</p><p>　　2.2.2 解決的問題</p><p>　　將一個系統(tǒng)分割成一個一些類相互協(xié)作的類有一個不好的副作用，那就是需要維護相關對象間的一致性。我們不希望為了維持一致性而使各類緊

40、密耦合，這樣會給維護、擴展和重用都帶來不便。觀察者就是解決這類的耦合關系的。</p><p>　　2.2.3 模式中的角色</p><p>　　抽象主題（Subject）：它把所有觀察者對象的引用保存到一個聚集里，每個主題都可以有任何數(shù)量的觀察者。抽象主題提供一個接口，可以增加和刪除觀察者對象。</p><p>　　具體主題（ConcreteSubject）：將有關

41、狀態(tài)存入具體觀察者對象；在具體主題內部狀態(tài)改變時，給所有登記過的觀察者發(fā)出通知。</p><p>　　抽象觀察者（Observer）：為所有的具體觀察者定義一個接口，在得到主題通知時更新自己。</p><p>　　具體觀察者（ConcreteObserver）：實現(xiàn)抽象觀察者角色所要求的更新接口，以便使本身的狀態(tài)與主題狀態(tài)協(xié)調。</p><p>　　2.2.4 模式

42、解讀</p><p>　　實現(xiàn)觀察者模式有很多形式，比較直觀的一種是使用一種“注冊——通知——撤銷注冊”的形式。如圖2.2詳細的描述了這樣一種過程：</p><p>　　圖2.2觀察者模式實現(xiàn)過程</p><p><b>　　觀察者</b></p><p>　?。∣bserver）將自己注冊到被觀察對象（Subject）

43、中，被觀察對象將觀察者存放在一個容器（Container）里。</p><p><b>　　被觀察</b></p><p>　　被觀察對象發(fā)生了某種變化（如圖中的SomeChange），從容器中得到所有注冊過的觀察者，將變化通知觀察者。</p><p><b>　　撤銷觀察</b></p><p>

44、;　　觀察者告訴被觀察者要撤銷觀察，被觀察者從容器中將觀察者去除。</p><p>　　觀察者將自己注冊到被觀察者的容器中時，被觀察者不應該過問觀察者的具體類型，而是應該使用觀察者的接口。這樣的優(yōu) 點是：假定程序中還有別的觀察者，那么只要這個觀察者也是相同的接口實現(xiàn)即可。一個被觀察者可以對應多個觀察者，當被觀察者發(fā)生變化的時候，他可以將消息 一一通知給所有的觀察者?；诮涌冢皇蔷唧w的實現(xiàn)——這一點為程序提供了

45、更大的靈活性。</p><p>　　2.2.5 模式總結</p><p><b>　　優(yōu)點</b></p><p>　　觀察者模式解除了主題和具體觀察者的耦合，讓耦合的雙方都依賴于抽象，而不是依賴具體。從而使得各自的變化都不會影響另一邊的變化。</p><p><b>　　缺點</b></p&

46、gt;<p>　　依賴關系并未完全解除，抽象通知者依舊依賴抽象的觀察者。</p><p><b>　　適用場景</b></p><p>　　當一個對象的改變需要給變其它對象時，而且它不知道具體有多少個對象有待改變時。</p><p>　　一個抽象某型有兩個方面，當其中一個方面依賴于另一個方面，這時用觀察者模式可以將這兩者封裝在獨立

47、的對象中使它們各自獨立地改變和復用。</p><p>　　2.3 Thrift庫</p><p>　　2.3.1 Thrift簡介</p><p>　　Thrift是一個跨語言的服務部署框架，最初由Facebook于2007年開發(fā)，2008年進入Apache開源項目。Thrift通過一個中 間語言(IDL, 接口定義語言)來定義RPC的接口和數(shù)據(jù)類型，然后通過一個編

48、譯器生成不同語言的代碼（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml）,并由生成的代碼負責RPC協(xié)議層和傳輸層的實現(xiàn)。</p><p>　　2.3.2 Thrift架構</p><p>　　圖2.3 Thrift架構</p><p>　　Thrif

49、t實際上是實現(xiàn)了C/S模式，通過代碼生成工具將接口定義文件生成服務器端和客戶端代碼（可以為不同語言），從而實現(xiàn)服務端和客戶端跨語 言的支持。用戶在Thrift描述文件中聲明自己的服務，這些服務經過編譯后會生成相應語言的代碼文件，然后用戶實現(xiàn)服務（客戶端調用服務，服務器端提服務）便可以了。其中protocol（協(xié)議層, 定義數(shù)據(jù)傳輸格式，可以為二進制或者XML等）和transport（傳輸層，定義數(shù)據(jù)傳輸方式，可以為TCP/IP傳輸，內存

50、共享或者文件共享等）被用作運行時庫。</p><p>　　2.3.3 支持的數(shù)據(jù)傳輸格式、數(shù)據(jù)傳輸方式和服務模型</p><p>　?。?）支持的傳輸格式</p><p>　　TBinaryProtocol – 二進制格式.</p><p>　　TCompactProtocol – 壓縮格式</p><p>　　TJS

51、ONProtocol – JSON格式</p><p>　　TSimpleJSONProtocol –提供JSON只寫協(xié)議, 生成的文件很容易通過腳本語言解析。</p><p>　　TDebugProtocol – 使用易懂的可讀的文本格式，以便于debug</p><p>　　（2）支持的數(shù)據(jù)傳輸方式</p><p>　　TSocket -

52、阻塞式socker</p><p>　　TFramedTransport – 以frame為單位進行傳輸，非阻塞式服務中使用。</p><p>　　TFileTransport – 以文件形式進行傳輸。</p><p>　　TMemoryTransport – 將內存用于I/O. java實現(xiàn)時內部實際使用了簡單的ByteArrayOutputStream。<

53、/p><p>　　TZlibTransport – 使用zlib進行壓縮， 與其他傳輸方式聯(lián)合使用。當前無java實現(xiàn)。</p><p>　　（3）支持的服務模型</p><p>　　TSimpleServer – 簡單的單線程服務模型，常用于測試</p><p>　　TThreadPoolServer – 多線程服務模型，使用標準的阻塞式IO。

54、</p><p>　　TNonblockingServer – 多線程服務模型，使用非阻塞式IO（需使用TFramedTransport數(shù)據(jù)傳輸方式）</p><p>　　2.3.4 Thrift使用</p><p>　?。?）編譯安裝：./configure –》make –》make install</p><p>　?。?）利用Thri

55、ft部署服務</p><p>　　主要流程：編寫服務說明，保存到.thrift文件–》根據(jù)需要，編譯.thrift文件，生成相應的語言源代碼–》根據(jù)實際需要，編寫client端和server端代碼。</p><p>　　a）.thrift文件編寫</p><p>　　一般將服務放到一個.thrift文件中，服務的編寫語法與C語言語法基本一致，在.thrift文件中有

56、主要有以下幾個內容：變量聲明、數(shù)據(jù)聲明（struct）和服務接口聲明（service, 可以繼承其他接口）。 </p><p>　　b）client端和server端代碼編寫 </p><p>　　client端和server端代碼要調用編譯.thrift生成的中間文件。</p><p>　　在client端，用戶自定義CalculatorClient類型的對象（用

57、戶在.thrift文件中聲明的服務名稱是Calculator，則生成的中間代碼中的主類為CalculatorClient），該對象中封裝了各種服務，可以直接調用（如client.ping()）,然后thrift會通過封裝的rpc調用server端同名的函數(shù)。在server端，需要實現(xiàn)在.thrift文件中聲明的服務中的所有功能，以便處理client發(fā)過來的請求。如圖2.4所示。</p><p>　　圖2.4 cl

58、ient端和server端的書寫</p><p>　　2.4 Boost庫</p><p>　　2.4.1 Boost庫簡介</p><p>　　Boost庫是一個可移植、提供源代碼的C++庫，作為標準庫的后備，是C++標準化進程的開發(fā)引擎之一。Boost庫由C++標準委員會庫工作組成員發(fā)起，其中有些內容有望成為下一代C++標準庫內容。在C++社區(qū)中影響甚大，是不折

59、不扣的“準”標準庫。Boost由于其對跨平臺的強調，對標準C++的強調，與編寫平臺無關。大部分Boost庫功能的使用只需包括相應頭文件即可，少數(shù)（如正則表達式庫，文件系統(tǒng)庫等）需要鏈接庫。</p><p>　　2.4.2 Boost的log庫</p><p><b>　?。?）相關概念</b></p><p>　　日志記錄：一個獨立的消息包，這

60、個消息包還不是實際寫到日志里的消息，它只是一個候選的消息。 </p><p>　　屬性：日志記錄中的一個消息片。 </p><p>　　屬性值：那就是上面所說的屬性的值了，可以是各種數(shù)據(jù)類型。 </p><p>　　日志槽（LOG SINK)：日志寫向的目標，它要定義日志被寫向什么地方，以及如何寫。 </p><p>　　日志源：應用程序寫日

61、志時的入口，其實質是一個logger對象的實例。 </p><p>　　日志過濾器：決定日志記錄是否要被記錄的一組判斷。 </p><p>　　日志格式化：決定日志記錄輸出的實際格式。 </p><p>　　日志核心：維護者日志源、日志槽、日志過濾器等之間的關系的一個全局中的實體。主要在初始化logging library時用到。 </p><p

62、><b>　　（2）框架結構</b></p><p>　　Boost log的框架結構如圖2.5所示：</p><p>　　圖2.5 Boost log的框架結構</p><p>　　A）應用程序在圖的右側，通過一個或多個logger實例發(fā)送日志消息。</p><p>　　B）應用程序也可以出現(xiàn)在左側，那就是一個日

63、志的顯示實例了。</p><p>　　C）一個日志記錄的數(shù)據(jù)中會包括許多屬性。屬性基本上是一個函數(shù)，它的返回值就是屬性值。比如時間不僅是一個函數(shù)（也是一個屬性）。</p><p>　　D）有三種類型的屬性集：全局的，特定線程的，特定源的。前兩個是由logging core來維護的，所以不用再初始化。</p><p>　　全局屬性集中的屬性被連接到所以的日志對象上。&

64、lt;/p><p>　　線程屬性集中的屬性會連接到把它注冊到屬性集時的那個線程。</p><p>　　源屬性集由初始化日志的源來維護的，它會連接到一個特定的源上。</p><p>　　當一個源初始化日志對象的時候，它會從上述的三個屬性集的所有屬性中得到屬性值。這些值會在將來處理。</p><p>　　如果在不同的屬性集中有相同的屬性名字的時候就會

65、造成沖突，解決沖突的方法是全局屬性集的優(yōu)先級最低，源屬性集的優(yōu)先級最高。高優(yōu)先級的屬性會覆蓋低優(yōu)先級的屬性。</p><p>　　E）當組合屬性值的時候，logging core來決定一個屬性是否要被送到sink中，這就是過濾。有兩層過濾，首先應用的是全局中過濾，全局過濾用來快速的過濾掉那些不需要的日志記錄。然后 就是sink指定的過濾了。每個sink都有單獨的過濾器。sink過濾器允許將一個日志記錄定向到一個指

66、定的sink。</p><p>　　F）如果一個日志記錄至少通過了一個sink的話，它就可以用了。這時候就是日志消息格式化的時候了。格式化完成的日志消息和屬性值一起被送到接收它們的sink中。</p><p>　　G）如上圖所示，sink被分為前端和后端兩個部分。這是為了抽象sink的通用功能，如過濾和線程同步。前端由日志庫提供，用戶不大可能再去實現(xiàn)它。而后端 很可能是在日志庫的外面，它來

67、實現(xiàn)對日志記錄的處理。如寫文件，發(fā)送到網絡等。日志庫提供了大部分通常用到的后端程序。 </p><p>　　2.5 QT GUI簡介</p><p>　　2.5.1 QT GUI簡介和功能特點</p><p>　　QT提供了設計師工具，可以很方便的使用鼠標拖拽的方式繪制界面。繪制完畢后自動生成一個界面的.h文件（如ui_mainwindow.h），其中含有一個自動生

68、成的Ui_MainWindow類，這個類中核心的函數(shù)是setupUi，根據(jù)界面向導的不同里面接收一個QWidget *參數(shù)或者QMainWindow *參數(shù)。這個函數(shù)會自動在傳入的QWidget或QMainWindow上根據(jù)設計師繪制的界面創(chuàng)建可視化控件。使用這個自動生成的類有兩種方式，一是在定義QWidget或QMainWindow時創(chuàng)建一個Ui_MainWindow類型的成員ui，在構造函數(shù)中調用其setupUi方法ui.setup

69、Ui(this)，或使用C++特有的多繼承方式，定義子類的時候同時以Ui_MainWindow作為基類，在構造函數(shù)中直接調用setupUi(this)。這時已經可以在自定義部件子類中顯示繪制的界面了。要訪問繪制界面的可視化控件，根據(jù)上述兩種方式使用ui->控件名稱或者控件名稱直接進行引用即可。</p><p>　　2.5.2 信號和槽</p><p>　　在圖形界面編程中，很多時候我

70、們希望一個可視對象發(fā)生某種變化時通知另一個或幾個對象，再一個地說，我們希望任何一類的對象能和其他對象進行通訊。例如，某 個數(shù)值顯示窗口負責顯示某個滾動條對象的當前數(shù)值，當滾動條對象的值發(fā)生變化時，我們希望數(shù)值顯示窗口能收到來自滾動條對象發(fā)送的“數(shù)值改變”的信號，從而改變自己的顯示數(shù)值。 </p><p>　　對于類似以上的問題，較早的工具包使用“回調”的方式來實現(xiàn)。回調是指一個函數(shù)的指針，如果你希望一個處理函數(shù)同

71、志你一些事件，你可以把另一個函數(shù)的指針傳遞給處理函數(shù)。處理函數(shù)在適當?shù)臅r候會調用回調函數(shù)。 </p><p>　　采用回調方式實現(xiàn)對象間的通訊有兩個主要缺點，首先回調函數(shù)不是類型安全的，我們不能確定處理函數(shù)使用了正確的參數(shù)來調用回調函數(shù)，第二，回調函數(shù)和處理函數(shù)間的聯(lián)系非常緊密，因為處理函數(shù)必須知道要調用哪個回調函數(shù)。</p><p>　　在QT開發(fā)環(huán)境中，實現(xiàn)對象間的通訊我們有一種稱為“

72、信號和槽”的機制可以代替回調函數(shù)。信號和槽機制用于實現(xiàn)對象間的通訊，是QT的一個中心特性，恐怕也是QT與其它工具包最不同的地方了。 </p><p>　　信號和槽機制就是：當一個特定的事件發(fā)生時，一個或幾個被指定的信號就被發(fā)射，槽就是一個返回值為void的函數(shù)，如果存在一個或幾個槽和該信號相連接，那在該信號被發(fā)射后，這個（些）槽（函數(shù)）就會立刻被執(zhí)行。 </p><p>　　信號和槽機制是

73、類型安全的，一個信號的簽名必須與它的接收槽的簽名相匹配，這樣編譯器就可以幫助我們檢查類型是否匹配。信號和槽是很寬松的聯(lián)系在一起的，一個發(fā)射信號的對象不用考慮哪個槽會接收這個信號，接收信號的槽的所在對象也不知道要連接的信號是哪個對象發(fā)射的。QT的信號和槽機制可以保證如果你把一個信號和一個槽連接起來后，槽會在正確的時間使用信號的參數(shù)而被調用，信號和槽可以使用任何數(shù)量、類型的參數(shù)。 </p><p>　　QT的窗口部件

74、已經有很多預定義的信號，也有很多預定義的槽，但我們總是通過繼承來加入我們自己的信號和自己的槽，這樣我們就可以處理感興趣的信號 了。凡是從QObject類或者它的某個子類繼承的所有類都可以包含信號和槽。當某個事件發(fā)生后，被指定的信號就會被發(fā)射，它不知道也沒有必要知道是否有 槽連接了該信號，這就是信息封裝。 </p><p>　　槽是可以用來接收信號的正常的對象的成員函數(shù)，一個槽不知道它是否被其它信號連接?？梢园岩粋€

75、信號和一個槽進行單獨連接，這時槽會因為該信號被發(fā)射 而被執(zhí)行；也可以把幾個信號連接在同一個槽上，這樣任何一個信號被發(fā)射都會使得該槽被執(zhí)行；也可以把一個信號和多個槽連接在一起，這樣該信號一旦被發(fā)射，與之相連接的槽都會被馬上執(zhí)行，但執(zhí)行的順序不確定，也不可以指定；也可以把一個信號和另一個信號進行連接，這樣，只要第一個信號被發(fā)射，第二個信號立刻就被發(fā)射。 </p><p><b>　　2.5.3 樣式表<

76、;/b></p><p>　　QT中可以靈活的使用層疊樣式表(CSS)，其語法和css很相似。因為HTML CSS的靈活性，可以很方便的為QT界面設計自己需要的外觀。</p><p>　　（1） 各子對象設置樣式表</p><p>　　部件的對象名調用樣式表，如下:</p><p>　　comboBox->setStyleShee

77、t("QComboBox{border:1pxsolidgray;border-radius:3px;padding:1px18px1px3px;}");</p><p>　　這樣單獨對該部件設置樣式表。需要注意的就是，當后面再次使用setStyleSheet函數(shù)對comboBox設置樣式表時，之前設置的樣式表就不起作用了，也即樣式被現(xiàn)在定義效果的取代了。</p><p&g

78、t;　　如果想定義所有某一類控件(比如界面上所有的QComboBox)一個樣式，可以使用qApp進行設置。</p><p>　　（2）使用qApp設置樣式表</p><p>　　qApp是一個全局對象，使用其設置樣式表之后，部件就固定樣式了，當然，后面使用某個子對象調用setStyleSheet函數(shù)時，會只改變函數(shù)中設置的樣式，其他的樣式不會發(fā)生改變。</p><p&g

79、t;<b>　　比如：</b></p><p>　　qApp->setStyleSheet("QPushButton{border:2pxsolidblue;border-radius:6px;background-color:#E3EAA5;min-width:80px;}QComboBox{border:1pxsolidgray;border-radius:3px;pad

80、ding:1px18px1px3px;}QLineEdit{border:1pxsolidgray;border-radius:5px;padding:08px;selection-background-color:darkgray;}");</p><p>　　這句話定義了按鈕、下拉框、行編輯框的樣式，界面中這三種部件都按照里面定義的樣式顯示。如果后面要對其中一個子部件的樣式進行修改，可以直接調用se

81、tStyleSheet，將需要的樣式覆蓋覆蓋掉之前的，其他的保留，例如</p><p>　　pushButton->setStyleSheet("QPushButton{background-color:red;}");</p><p>　　這樣就只改變按鈕的背景色，邊框大小那些qApp定義好的還是不變。</p><p>　　注意：當很多部

82、件布局在一起時，有時先使用qApp，然后在子部件中設置會出現(xiàn)意想不到的結果，這時只有不用qApp，直接對子部件進行樣式表設置，每次樣式表元素都要設置全，因為單獨設置會覆蓋掉之前的樣式表。</p><p>　　2.5.4 QtWebKit</p><p>　　QtWebkit模塊提供了一個在QT中使用web browser的engine，這使得我們在QT的應用程序中使用萬維網上的內容變得很容

83、易，而且對其網頁內容的控制也可以通過native controls 實現(xiàn)。</p><p>　　QtWebkit具有渲染HTML，XHTML和SVG 文檔，使用CSS排版，運行JavaScript等功能。</p><p>　　在JavaScript 運行環(huán)境和Qt object model直接的橋接技術使得自定義的QObject可以在JavaScript代碼中使用。和Qt network

84、module的整合使得網頁可以通過從服務器，本地文件系統(tǒng)，甚至QT的資源系統(tǒng)中下載。</p><p>　　另外為了提供渲染特性，可以使用HTML元素的contenteditable屬性，使HTML文檔可以被用戶編輯。</p><p>　　為了使用Qtwebkit模塊中的類，我們需要在相關頭文件中加入 #include <QtWebKit>，在工程的pro文件中添加 QT +=

85、webkit語句。</p><p>　　QWebView主要用來查看網頁，一個QWebView的實例中有一個QWebPage。</p><p>　　QWebPage可以訪問這個頁面的文檔結構，它主要描述如Frames，the navigation history, 和編輯內容的the undo/redo stack。</p><p>　　HTML文檔可以嵌套到一個f

86、rameset中個frame中。HTML一個獨立的 frame是通過QWebFrame類展示的。這個類中包含了到JS window object的bridge和用于刷新的QPainter。每一個QWebPage擁有一個QWebFrame作為其main frame，一個main frame可以包含多個child frame。</p><p>　　每一個的Frame都有一個自己的JavaScript Context。

87、QWebFrame::addToJavaScriptWindowObject()可以使Qt C++中的object從JavaScript函數(shù)中訪問。QWebFrame::evaluateJavaScript()可以使用戶在C++代碼中直接運行JavaScript代碼。</p><p>　　一個HTML文檔中獨立的元素可以通過在同一個頁面中的DOM JavaScript 接口訪問。對應的類是QWebElement。

88、可以使用CSS選擇器通過QWebFrame's findAllElements()和findFirstElement()函數(shù)獲取QWebElement對象。</p><p>　　QWebSetting提供了對瀏覽器常用的各種屬性，和各種設置的配置。如：JavaScript enabled，plugin enabled等。通過其默認設置可以顯示所有QWebPage實例的默認配置。個別的屬性可以通過

89、這個頁面的setting來設置。全局的Setting使用QWebSetting::globalSettings(),某個頁面的settings用QWebPage::settings()。</p><p>　　QWebHsitory主要是用來存放QWebPage的訪問歷史記錄，并且提供對于導航到相關頁面的支持。</p><p>　　QWebHistoryInterface提供了一個實現(xiàn)訪問歷

90、史連接的接口。</p><p>　　自從WebKit支持Netscape Plugin API， Qt的應用程序可以顯示當前平臺上可用的常見plugin。為了使plugin的支持性可用，用戶必須安裝對應的plugin，并且當前應用程序的QWebSetting::PluginEnabled設置為可用。</p><p>　　QNetworkAccessManager是一個可以發(fā)送和接收數(shù)據(jù)的異

91、步API。它可以看做是post/put/get/head API。它也提供了對cookie和session的支持。</p><p><b>　　3 系統(tǒng)需求分析</b></p><p>　　云協(xié)作平臺的客戶端是整個云協(xié)作平臺與用戶交互的工具，是連接前端操作與后端處理的樞紐。由于客戶端是直接接觸用戶，就必須具有友好的操作界面，而且操作不能太復雜；操作遠端的軟硬件資源，數(shù)

92、據(jù)在遠距離傳輸又必須保證數(shù)據(jù)的安全性；作為客戶端程序也必須保證其一定范圍的可擴展性。</p><p>　　3.1 用戶需求分析</p><p>　　云協(xié)作平臺是在資源調度管理系統(tǒng)的基礎上，將加入集群中各個節(jié)點的資源，例如Windows節(jié)點上的辦公軟件，專用型開發(fā)軟件，Linux機器上的Fluent等，集成到服務器上，用戶通過客戶端上的相應操作，實現(xiàn)對由用戶通過客戶端直接操作管理。支持遠程啟

93、動桌面，并可將權限范圍內的遠程桌面共享給其他用戶，并支持客戶端和服務端之間的文件互傳。登陸客戶端的用戶是在服務器端的數(shù)據(jù)庫中配置，增刪改查可通過對服務器端對應數(shù)據(jù)表的相應操作，完成相關配置。對于登陸的用戶，有做用戶身份區(qū)分，不同身份的用戶所能看到的桌面應用也不盡相同，這也是可以在服務器端配置的。因此客戶端必須包含以下功能：</p><p><b>　　文件上傳和下載</b></p>

94、;<p>　　用戶可通過文件上傳和下載功能實現(xiàn)服務端和客戶端之間的文件共享，以及遠程桌面的登陸。</p><p><b>　　執(zhí)行遠端命令</b></p><p>　　在實際的生產當中，客戶端和服務器往往不在同一物理地點，客戶端需要實時查看服務端有關信息以便做相應操作，這時，通過客戶端執(zhí)行遠端命令功能就顯得十分重要了。除此之外，提交作業(yè)，啟動桌面也會較多

95、的用到執(zhí)行遠端命令這一功能。</p><p><b>　　查看節(jié)點信息</b></p><p>　　在實際使用過程中，客戶端需要對添加到服務端的節(jié)點資源信息進行實時監(jiān)控，以獲取各個節(jié)點的準確信息，并將節(jié)點信息以數(shù)據(jù)表格的方式顯示給用戶。</p><p><b>　　啟動遠程桌面</b></p><p&g

96、t;　　在服務器端的JH scheduler上配置資源，資源運行節(jié)點狀態(tài)為”ok”，此時啟動遠程桌面，JH scheduler自動為用戶分配資源，用戶等待桌面啟動。桌面啟動后，可將桌面共享給其他用戶，共享模式須有區(qū)分：觀察者模式共享和交互模式共享。如圖3.1所示。</p><p><b>　　管理遠程桌面</b></p><p>　　對于有操作權限的用戶，可以將已有的

97、遠程桌面以觀察者模式或是交互模式共享給其他用戶，以供其他用戶查看或是操作。而管理員可以關閉其他非管理員啟動的遠程桌面，將不再運行的圖形桌面關閉，釋放資源，以實現(xiàn)資源的最大化利用。</p><p>　　圖3.1啟動遠程桌面流程圖</p><p><b>　　提交作業(yè)</b></p><p>　　用戶在登錄客戶端時需做有效性驗證，驗證通過后即可登錄

98、到操作頁面，通過客戶端可以提交一個作業(yè)。此時，服務端需將作業(yè)相關信息，例如作業(yè)號（有JH scheduler自動分配），作業(yè)名（用戶輸入），運行節(jié)點（JH scheduler自動分配），作業(yè)狀態(tài)（JH scheduler根據(jù)作業(yè)運行狀態(tài)設定）等信息插入到服務器端數(shù)據(jù)庫作業(yè)信息列表中。如圖3.2所示。</p><p><b>　　作業(yè)數(shù)據(jù)管理</b></p><p>　

99、　用戶可通過作業(yè)數(shù)據(jù)管理頁面對已經提交的作業(yè)進行查看，包括作業(yè)名、作業(yè)號、運行節(jié)點、開始運行時間、結束時間、運行狀態(tài)等，當作業(yè)條數(shù)較多時，可以將已完成的作業(yè)信息進行刪除操作。</p><p>　　客戶端桌面上顯示的應用圖標是根據(jù)服務器端相應xml文件動態(tài)生成的，所以，客戶端的可擴展性就非常的好了，如果想集成一些更多的應用，只需修改服務器端相應的配置文件即可。</p><p>　　除此之外，

100、客戶端還需易于安裝部署，配置須簡單明白。</p><p>　　3.2 性能需求分析</p><p><b>　　運行環(huán)境</b></p><p>　　作為輕量級的云協(xié)作平臺的用戶訪問終端，客戶端的運行環(huán)境，以及對軟硬件的要求不能太高。具體軟硬件配置如下：</p><p>　　處理器：Intel CORE I3</p

101、><p>　　圖3.2 提交作業(yè)流程</p><p><b>　　內存： 2GB</b></p><p><b>　　硬盤： 50GB</b></p><p>　　操作系統(tǒng)：Windows XP 及以上版本</p><p>　　對于32位或是64位系統(tǒng)，有不同的軟件安裝包以供不

102、同位數(shù)操作系統(tǒng)使用。</p><p><b>　　響應時間</b></p><p>　　由于客戶端需要將用戶操作的相關信息發(fā)送給服務器，服務器得到相關信息后需作出相應操作，此操作會在其他節(jié)點上進行，因此，用戶操作響應時間不能太長，啟動遠程桌面時間不能超過30秒鐘，關閉遠程桌面不能超過3秒鐘，而客戶端的數(shù)據(jù)列表的顯示刷新過程不能超過2秒鐘。</p><

103、;p><b>　　資源消耗</b></p><p>　　作為客戶端程序，有可能會較長時間在客戶機上運行，因此，必須保證不能存在內存泄露，對于程序中從內存開辟的空間，在使用完之后需及時釋放，以節(jié)省內存空間。在客戶端運行時，不能將CPU獨占，使客戶端機器其他功能受到影響。</p><p>　　由于客戶端的數(shù)據(jù)都是從服務器端獲取到，然后再顯示到客戶端相應的位置，其中涉

104、及比較多的是數(shù)據(jù)列表，這樣就為客戶端處理數(shù)據(jù)節(jié)省了大量時間，</p><p>　　使得客戶端程序在本地系統(tǒng)開銷大大減小，從而節(jié)省了客戶端系統(tǒng)的軟硬件資源。</p><p>　　用戶從客戶端登錄成功進入桌面，如果長時間（半個小時）不做任何操作，相當于待機，此時，此時服務器端的session將會過期，繼續(xù)操作會跳到登錄界面，這樣保證了個人操作的相對獨立。</p><p>

105、;　　3.3 數(shù)據(jù)需求分析</p><p>　?。?）E-R圖 根據(jù)需求分析，本系統(tǒng)中涉及到的實體有：用戶，作業(yè)等。如圖3.3是用戶實體的實體屬性圖。</p><p>　　圖3.3 用戶實體屬性圖</p><p>　　除了用戶這一實體外，本系統(tǒng)中還有作業(yè)這一實體，如圖3.4是作業(yè)實體的實體屬性圖。</p><p>　　圖3.4 作業(yè)實體屬性圖

106、</p><p><b>　　（2）數(shù)據(jù)字典</b></p><p><b>　　編號：D1</b></p><p><b>　　名稱：用戶表</b></p><p>　　描述：記錄用戶基本信息</p><p>　　結構：用戶名,密碼,用戶組</p

107、><p><b>　　編號：D2</b></p><p><b>　　名稱：作業(yè)表</b></p><p>　　描述：記錄作業(yè)基本信息</p><p>　　結構：作業(yè)號,作業(yè)名,用戶名,作業(yè)詳情,操作時間,運行節(jié)點</p><p>　　（3）系統(tǒng)主要功能的數(shù)據(jù)流圖 在對系統(tǒng)中所用

108、到的實體模型進行了設計之后，下面就是對各活動圖的描述，對于他們之間的行為和交互作用，以及怎樣進行生效。</p><p>　　用戶功能：用戶登陸系統(tǒng)后進行提交作業(yè)，其中數(shù)據(jù)流程圖如圖3.5所示。</p><p>　　圖3.5 提交作業(yè)數(shù)據(jù)流圖</p><p><b>　　4 系統(tǒng)概要設計</b></p><p>　　客戶端

109、整體采用現(xiàn)在主流的扁平化顯示風格，在設計模式方面采用觀察者模式。</p><p>　　4.1 軟件體系結構設計</p><p>　　用戶使用前端設備，如個人電腦，筆記本電腦、pad等，通過客戶端操作共享資源，數(shù)據(jù)與后端服務器交互，后端服務器與云資源進行交互，下發(fā)操作與數(shù)據(jù)，并獲得數(shù)據(jù)返回，服務器將返回的數(shù)據(jù)返回用戶客戶端進行呈現(xiàn)，如圖4.1所示。</p><p>　

110、　圖4.1 云協(xié)作平臺的整體結構</p><p>　　4.2 系統(tǒng)的數(shù)據(jù)庫設計</p><p>　　本文使用的數(shù)據(jù)庫是PostgreSQL，作為一個在Linux平臺上運行的數(shù)據(jù)庫，它在數(shù)據(jù)管理支持方面有良好的特性，并且可以由人來隨意的進行修改按照自己的意愿擴充接口進而實現(xiàn)需要的功能。</p><p>　　在數(shù)據(jù)庫中建立關系表，數(shù)據(jù)庫包含以下業(yè)務實體：用戶信息表，作業(yè)

111、信息表等。</p><p>　?。?）用戶表 表名：user_info，結構如下表4.1所示。</p><p>　　表4.1 用戶信息表</p><p>　　（2）作業(yè)信息表 表名：job_info，結構如下表4.2所示。</p><p>　　表4.2 作業(yè)信息表</p><p>　　對應的每種業(yè)務實體類型在進行邏輯建

112、模后，通過相應的工具生成到數(shù)據(jù)實體中，所產生的關系如圖4.2所示。</p><p>　　圖4.2 系統(tǒng)整體E-R圖</p><p>　　4.3 系統(tǒng)的功能模塊設計</p><p>　　云協(xié)作平臺客戶端的功能模塊如圖4.3所示：</p><p>　　圖4.3 客戶端功能模塊圖</p><p><b>　　文件上

113、傳和下載：</b></p><p>　　在客戶端和服務端需要文件傳輸功能，用以完成從本地向服務器上傳文件，用戶從服務器端下載文件到本地，還有啟動遠程桌面登錄Windows系統(tǒng)時，也需要拷貝logon文件到遠程機器。</p><p>　　文件傳輸工具使用FTP文件傳輸協(xié)議。有運行于Linux節(jié)點的FTP服務器和Windows上的Client組成。通過命令行輸入完成文件上傳和下載，