計算機專業(yè)畢業(yè)論文參考

　　作為計算機專業(yè)人才培養(yǎng)的主力軍,高校究竟要培養(yǎng)出什么樣的人才,我們必須重新審視和定位。下面是學習啦小編給大家推薦的計算機專業(yè)畢業(yè)論文參考，希望大家喜歡!

　　計算機專業(yè)畢業(yè)論文參考篇一

　　《高校信息門戶網站群建設管理應用問題研究及對策》

　　摘要：該文對數字化校園信息門戶網站群在建設、管理、應用過程中所遇到的問題進行了深入的研究與探討，在此基礎上結合高校自身特點，從建設、管理、應用方面考慮分析，對如何創(chuàng)建一個標準規(guī)范、系統架構全面可靠、系統運行安全穩(wěn)定、管理高效統一、應用站群內容豐富的高校信息門戶網站群給出了相應的對策。

　　關鍵詞：信息門戶;網站群;對策

　　高校數字化校園網站群建設管理應用中，如何進行硬件及系統資源合理選型、個性化需求分析、特殊功能定制、系統架構最優(yōu)化設計、部署模式選擇是整個環(huán)節(jié)中關鍵的問題。在系統管理環(huán)節(jié)也會產生管理員專業(yè)技術水平低、操作混亂、權限不明確、安全意識不高的問題。在系統應用過程中更會經常出現無安全意識而導致的核心信息泄露、網站模板設計單調無新意、發(fā)布信息混亂、站點內容更新不及時等諸多問題。

　　對此，該文對網站群建設管理應用過程中出現的問題進行深入的研究和分析，就如何創(chuàng)建一個智能化、個性化、安全化的高效穩(wěn)定網站群給出相應的策略及解決方案。

　　1 高校信息門戶網站群發(fā)展趨勢、特點及應用現狀分析

　　高校信息門戶網站群的建設及發(fā)展大致可概括為五個階段[1]。第一階段的發(fā)展為自然網站群，此階段的特點是未經規(guī)劃，各自獨立。第二階段的發(fā)展為從各個獨立網站的某些方面進行整體規(guī)劃，統一或分期實施，但學校和各院系部門網站的關系仍然在一個層級上，沒有上下級關系，且各站點相互獨立，信息資源不能共享。第三個階段為整合網站群，因學校業(yè)務的需要，將分散在不同物理位置的獨立站點整合在一起，實現信息資源的共享。但這樣形成的網站群存在很大的缺陷，信息不能充分共享、不能統一管理、不能統一升級網站后臺、不能做到整個網站群的聯合信息資源數據檢索。第四階段為用網站群內容管理系統，統一規(guī)劃、統一實施或分期實施，以解決第三代網站群存在缺陷。第五階段為動態(tài)內容管理概念。目前信息門戶網站群在高校中的建設及應用正處于第二代與第三代門戶網站群初期過渡時期。隨著動態(tài)內容管理概念的提出及相關平臺的推出，將引領我國高校網站及門戶網站群建設及應用的新方向[2]。

　　2 高校信息門戶網站群在建設管理應用中存在問題分析

　　信息門戶網站群通過統一規(guī)范、標準，規(guī)劃建立在統一技術架構基礎之上，按照一定的隸屬關系組織在一起，既可以統一管理、協同工作，亦可分角色管理、靈活方便，基于特定權限共享呈送的網站集合[3]。

　　校園信息門戶網站群的建設在系統建設先期首先要做好高校網站建設的全面規(guī)劃和組織協調工作，尤其對一個網站集群系統來講其成功與否與建站前的網站規(guī)劃有著極為重要的關系。一個網站的規(guī)劃不應該只是宏觀的，而應盡可能全面、詳細、具體。涉及到網站內容方面的規(guī)劃，要精心設計網站架構和模板版面，在網頁的美工設計、頁面的兼容性、頁面文件的大小、頁面上圖片的使用等方面都要有全面、細致的考慮。但是在具體建設實施應用過程中，情況卻并非如此。

　　2.1信息門戶網站群管理應用中系統架構問題

　　高校數字化校園信息門戶網站群在建設應用前期由于沒有對整個應用平臺做合理的架構設計，大多數高校出于對硬件成本的考慮，在架設平臺中采用后臺制作服務、前臺發(fā)布服務以及數據庫服務集中部署到單臺服務器上，或設計采用后臺制作服務及數據庫服務部署到一臺服務器，前臺發(fā)布服務部署到另外一臺服務器較前者更合理的部署及發(fā)布方式。此兩種設計架構及部署方式在系統運行應用中都會不同程度的造成服務器的超負載超并發(fā)數的工作，一旦在某一時段出現大并發(fā)的服務訪問請求易造成整個服務癱瘓。因服務的高度集中，當同時進行網站維護的人員非常多時，制作服務器請求響應會顯得異常緩慢。此設計架構模式及部署方式勢必會將服務器的IP地址網絡配置信息暴露在公網上，會對整個系統的運行安全造成高入侵概率。

　　2.2信息門戶網站群管理應用中角色問題

　　信息門戶網站群在管理應用中由于系統設計標準統一規(guī)范，學校系統管理員先期會在整個平臺中建好各個院系部門的二級網站，各相關應用單位選派部門系統管理員，中心對選派的部門管理員進行系統的培訓，從模板的制作、部門人員的管理、欄目及頻道的新建與綁定到最后部門站點欄目下文章信息的發(fā)布等系統化的操作演示與講解，讓參培人員掌握站點建設流程及操作。但是在高校實際應用過程中，大多數院系部門選派的參培人員是行政老師或者辦公室教學秘書等非技術專業(yè)人員。這些人員由于工作崗位性質的關系更迭頻率比較大，接替的站點管理員由于沒有受過任何的培訓，那么對部門的整個站點應用肯定也無從下手，勢必阻礙部門站點的日常應用維護及更新工作。

　　參培人員計算機水平不同，有很大一部分管理員是與計算機專業(yè)無關的，缺少計算機基本相關理論知識及應用技術。經過培訓后只能掌握比較死板的操作流程，不能做到對部門站點應用的擴展及創(chuàng)新。

　　部門站點管理員安全意識淡薄，在部門站點二級首頁任意添加后臺管理員登陸入口。有的管理員由于自身本職工作量較繁重加上自己對網站技術不懂就任意指派學生或者校外人員代為部門站點管理員。這些都會給整個系統平臺平穩(wěn)運行造成安全隱患。

　　2.3信息門戶網站群管理應用中模板問題

　　信息門戶網站群在管理應用中由于平臺要求各網站風格不同但站點實現集成，那么在應用中就要使用到模板。在模板的制作過程中，需要HTML、CSS、Jscript、JAVA技術及Photoshop、Dreamweaver等工具的使用。這些專業(yè)技術及工具，對大多數部門站點管理員來說是不可能具有的。那么很多院系部門受到專業(yè)技術上的限制就只能采用中心提供的幾套固有風格的模板，從而造成了幾個學院部門使用同一套風格模板的情況。

　　某些院系部門因受到技術水平的限制，就花錢請校外的具有相關技術人員定做模板，由于這些校外人員不熟悉平臺內部架構及應用規(guī)范，做好的模板上傳到平臺后因不兼容不能使用。

　　系統沒有對模板管理模塊中對上傳模板大小及數目的設置，應用過程中很多站點管理員就不加任何處理和限制的上傳模板，造成系統資源的巨大浪費及日常維護的管理混亂。此外，系統在角色的授權及權限控制管理設計方面存在不合理性。

　　2.4信息門戶網站群管理應用中功能需求增加及擴展問題

　　信息門戶網站群在管理應用中實現了對各站點的高度集成，在使用中部門功能特殊性需要實現某些特殊的功能模塊，比如：學生處需要增加一個功能模塊實現對本年度全校十佳校園學生的投票及最后數據統計、圖表顯示等。而目前運行的門戶網站群無此項功能，因受到擴展接口的開放性、開發(fā)周期及開發(fā)人員，以及隨時提出的特殊功能需求多樣性、不確定性的影響，不能發(fā)揮應用平臺的最大化效能。

　　3 門戶網站群建設管理應用中問題對策

　　3.1 平臺架構設計應用對策

　　針對在體系架構問題分析中的情況，提出以下體系結構、設計架構及部署模式。在體系結構中可采用系統呈上下級結構，自上而下統一管理，然而每站點又相對獨立。每個站點可以擁有獨立的一個或多個域名，以及各自獨立的站點管理。站點上下級結構UML如圖1所示，上級站點包含(擁有)下級站點。

　　在系統架構設計及部署模式中采用分散式的負載均衡集群，分散式設計與部署以站點為單位，把對各級站點的維護壓力分散到不同的服務器上。制作服務器的站點分配可以靈活配置，在一臺制作服務器上可以選擇部署一個或多個動態(tài)站點。管理職責明確，不同的制作服務器可以由不同的部門來管理。分散式設計及部署示意圖如圖2所示：

　　分散式設計及部署模式與集中式設計及部署模式應用比較中，雖然集中式減輕了管理負擔，節(jié)省了硬件方面的投入，但是在學校實際的應用環(huán)境中會帶來服務運行及訪問性能、服務及數據安全、數據存儲及動態(tài)實時增長等方面的問題。分散式設計及部署方式較好的解決了這些問題，其可以較好的解決在大并發(fā)數大訪問量的情況下減輕服務器的運行壓力，加快訪問數據請求及相應速度。無論運行在外層的發(fā)布服務器還是內部的制作服務器、數據庫服務器、文件服務器在安全性能上都提高了很多。一旦某臺制作或者發(fā)布服務器出現硬件故障，或者因漏洞被黑客入侵，那么服務或者數據處理會自動切換到狀態(tài)正常服務器。采用數據、文件與服務分離，進一步保障了數據、文件的安全，提升了其交互的處理時間。也符合系統站點多，數據量時刻增長，大數據的需求特性。數據服務器、文件服務器、制作服務器相互之間可以使用內部網絡地址，發(fā)布服務器采用雙網卡，一個設置公網地址提供對外服務，一個設置內部地址提供與制作服務器的互聯。進一步增加服務系統的訪問安全級別。

　　3.2網站群管理應用中角色權限問題對策

　　針對各站點管理員應用群體，各院系部門需從實際出發(fā)，考慮所指派的本部門站點管理員的更迭頻率，安排不易變動的并具有計算機相關技術的專業(yè)性老師做為站點管理員。站點管理員通過中心專門的技術人員多次培訓與日常技術支持，熟練掌握平臺的操作及使用，嚴格按照操作規(guī)范及流程，并在使用過程中提高安全意識。

　　系統角色權限管理設計中采用分級授權、多級權限控制的方式。分級委派授權機制，上級站點管理員可以指定下級站點的信息管理范圍、人員管理范圍以及功能組件使用范圍;而下級站點的管理員又可以把其權限范圍內信息、功能組件委派授權給更下一級站點。

　　當上級站點給下級指定信息范圍之后，下級站點就可以發(fā)展壯大其站點內的信息，而這些信息自然地屬于上級站點。這種模式極大地減少了各級管理員的權限分配、信息維護的工作量，管理起來非常方便。分級授權模式結構示意圖如圖3所示：

　　在某個具體的站點內，系統對信息的訪問控制有很嚴格而又靈活的策略。站點管理員可以靈活設置信息所屬的權限組，允許哪些人瀏覽，允許哪些人編輯;甚至還可以對ip地址進行限制，比如在單位時允許訪問某些信息，回到家就不允許訪問了。多權限控制模式UML示意圖如圖4所示。

　　在一個站點內可以創(chuàng)建多個不同的權限組。每個權限組內可以綁定多個人員。每個權限組可以綁定多個欄目，用于限定此權限的信息范圍。每個權限組上可以設置訪問ip限定。這樣權限組內的人員可以對該組綁定的欄目下的文章擁有一定的操作權限。不同類別的權限組代表了能夠進行的不同操作：審核發(fā)布、起草送審、瀏覽等。

　　3.3網站群管理應用中模板問題對策

　　模板設計與制作需要專業(yè)知識與技術，在學校應用過程中各院系部門也不可能都能提供以為具有較高的相關技術的站點管理人員，那么就要考慮整個項目中要有中心單位提供一位具有較高專業(yè)知識及技術的技術人員來專門負責模板的設計與開發(fā)工作。各院系部門特色不同，網站風格自然也就多樣。要滿足站點多風格異的特性，有一位專門負責模板設計與開發(fā)的技術人員較為合理。同時也保障了系統使用及訪問上的安全性。

　　系統模板功能模塊設計中增加對模板上傳的操作功能，實現對上傳模板的審核與控制。從而進一步增強對模板的規(guī)范性管理與應用。保證系統平臺的安全使用及運行。

　　3.4網站群管理應用中功能擴展問題對策

　　在系統平臺部署完運行過程中出現的特殊功能需求問題，需要在系統開發(fā)前期提出預留的功能接口，以便在需求出現的時候有開發(fā)人員在短時間內得以實現。在系統平臺功能模塊中提供RSS信息抓取及展現的功能，支持Portlet界面集成，支持第三方組件的功能，一旦系統功能有此需求及良好的兼容性，就能得到及時的實現與應用。除此系統最好提供好以經實現的接口和功能組件，如BBS論壇、在線調查、留言、待辦提醒、領導信箱、信息數據統計等等。

　　4 結束語

　　高校信息門戶網站群平臺可以快速地搭建多個信息相互關聯的網站;每個站點可以擁有多套模板;在應用中確實給我們帶來了便利及實用，但在管理應用中確實還存在著很多不合理性，該文通過對門戶網站群平臺使用過程中出現的問題分析，給出了相應的解決辦法，以期系統平臺能在高校信息化建設中發(fā)揮高大的作用。

　　參考文獻：

　　[1] 徐兵，王克強，徐為民.基于信息資源整合的高校信息化建設模式[J].教育信息化，2004(7)：68-70.

　　[2] Detlor B.Corporate portal as information infrastructure：Towards a framework for portal design.International Journal of Information Management.2002(20)：91-101.

　　[3] 朱永虎，張選平，譚小鵬，等.Jetspeed一企業(yè)信息門戶的實現[J].計算機應用研究，2003(3)：155-157.

　　[4] 張為普.關于企業(yè)門戶的研究[M].中國機械工程，2003，14(15)：1313-1316.

　　[5] 李剛.輕量級J2EE企業(yè)應用實踐一一Struts+Spring+Hibernate整合開發(fā)[M].北京：電子工業(yè)出版社，2007：311-392.

　　[6] Rick Greenwald.Jim Mibery.Oracle AS Portal寶典[M].北京：電子工業(yè)出版社，2003：156-201.

　　[7] 王爽.高校網站群管理系統的設計[J].西安文理學院學報：自然科學版，2011(14)：78-79.

　　[8] 李春子.網站集群式管理在高校中的應用分析[J].數字技術與應用，2010(5)：81-82.

點擊下頁還有更多>>>計算機專業(yè)畢業(yè)論文參考