網站需求說明書

1.1. 項目背景

打造行業網站垂直專業門戶網站。

1.2. 系統目標

創建易用、簡單、穩定、功能強大的後臺管理系統。並保證在網站後臺能實現對欄目、文章、會員、專題、個性化模板的管理。

完成一套簡潔實用、功能完善的前臺系統，包括友好的用戶界面、人性化的功能設計、完善的用戶體驗等。

1.3. 設計原則

本項目所開發的LMS平臺在需求分析和開發中應遵循如下原則：

• 簡單：易用性強；各功能模塊符合業務邏輯，且劃分清晰；平臺易維護；可以基於本平臺方便的進行二次開發。
• 穩定：在目標用戶數量下可以穩定運行。
• 可擴展：在不改動平臺技術架構的前提下——在用戶數量超過預期數量時，可以進行系統增容；可以根據用戶需求發展的狀況進行功能擴展。
• 體系建設的獨立性：要求如下幾個體系應具備獨立性，資源體系，教學體系，測評體系。三個體系相互獨立，相互關聯，相互協調，能夠達到組織學習過程高度的靈活性。
• 接口：具備完善的接口，其餘業務系統經過接口調用邀請用戶加入圈子，實現與其餘業務系統的打通。

1.4. 軟件環境

Linux+Apache2（weblogic）+J2EE+Spring+Hibernate+Oracle

1.5. 技術架構

MVC結構，Hibernate模式

1.6. 性能要求

支持百萬級數據量，系統平臺高速穩定。

雙機熱備＋磁盤陣列＋數據恢復

1.7. 網絡環境

Linux操做系統＋防火牆＋入侵監測＋抗DoS/DdoS攻擊

1.8. 硬件環境

服務器配置：

前臺服務器2臺：DELL或IBM、雙核、4G內存、146G*3硬盤

後臺服務器2臺：DELL或IBM、四核、8G內存、146G*3硬盤

數據庫1臺：DELL或IBM、四核、8G內存、146G*3硬盤

備份服務器2臺：DELL或IBM、四核、8G內存、146G*3硬盤

帶寬：50M獨享

1.9. 目標用戶分析

本平臺的使用者包括四類用戶：業務管理人員、普通用戶、普通會員、收費會員、系統維護人員。

• 業務管理人員

基本狀況：非IT專業技術人員，但具有較強的IT應用能力，網絡環境好。

需 求 點：主要使用本平臺進行資源和信息業務管理。

• 普通用戶

基本狀況：非IT專業技術人員，具有必定的IT應用能力，網絡環境差異大。

需 求 點：主要使用本平臺進行信息查看，關注行業信息動態等，並能夠利用本平臺與業務管理人員、其餘用戶進行交流。

• 普通會員

基本狀況：非IT專業技術人員，具有必定的IT應用能力，網絡環境差異大。

需 求 點：註冊後的用戶即爲普通會員，僅能瀏覽網站免費信息。

• 收費會員

基本狀況：非IT專業技術人員，具有必定的IT應用能力，網絡環境差異大。

需 求 點：註冊後的用戶即爲普通會員，普通會員付費之後，經網站確認後既能夠成爲收費會員，能夠享受免費會員的一切服務，同時能夠享受商機平臺服務，收費諮詢信息服務以及一個信息服務產品。

 

• 系統維護人員

基本狀況：IT專業技術人員，網絡環境較好。

需 求 點：對本平臺的平常運營進行技術維護工做，在必要的狀況下進行必定的功能修改或擴充等開發工做。在特殊狀況下進行系統增容等較大規模的技術維護工做。

 

1. 技術方案

 

下面將從功能結構、應用結構、系統結構、邏輯結構和物理結構五方面闡述本系統的技術方案。

 

1.1. 功能模型

 

 

 

1.2. 應用結構

 

 

 

 

 

應用結構圖

 

應用結構層次設計圖

 

 

 

應用結構層次設計，主要將應用系統分層，每一個層次關注的焦點不一樣，把界面、業務、數據分開；本系統也遵守此原則設計，將分爲3個大層次：表示層、業務邏輯層、數據訪問層，調用關係如圖所示。

 

l 表示層：

 

本系統表示層主要包括三大塊：前臺、後臺和模板，負責從用戶方接收請求傳遞給業務層或者數據訪問層處理，專心處理界面和接口數據交互。

 

l 業務層：

 

此層面專心處理業務邏輯，實現業務的關鍵流程。

 

l 數據訪問層：

 

數據訪問核心部分：數據訪問邏輯組件，它表明調用程序提供對數據庫執行如下任務的方法：

 

² 在數據庫中建立記錄

 

² 讀取數據庫中的記錄並把業務實體數據返回給調用程序

 

² 使用調用程序提供的修改後的業務實體數據更新數據庫中的記錄

 

² 刪除數據庫中的記錄

 

執行上述任務的方法一般稱爲「CRUD」方法，這是由各項任務的首字母組成的一個縮寫詞。一般數據訪問邏輯組件訪問一個單一數據庫，並封裝了針對該數據庫中一個表或一組相關表的數據相關操做

 

 

 

 

 

1.3. 邏輯結構

 

 

 

1.4. 物理結構

 

 

 

1.5. 功能結構

 

 

 

 

 

 

 

2. 系統功能描述

 

2.1. 後臺維護管理系統

 

功能組成：後臺主要有一下幾個功能模塊組成：

 

系統管理、人員數據管理、訂單管理、產品數據管理，廣告管理、內容發佈管理。

 

2.1.1. 系統管理

 

2.1.1.1. 功能組成

 

系統管理主要是對角色權限等功能進行管理，功能分爲：角色管理、權限管理、日誌查詢、我的信息管理。

 

2.1.1.2. 功能描述

 

角色管理：管理員根據功能劃分的不一樣能夠創建不一樣的角色，即不一樣的角色具備不一樣的權限，並能夠賦予不一樣的管理人員。

 

權限管理：能夠根據角色賦予管理員權限，也能夠根據具體的權限對管理員進行賦予權限。

 

日誌查詢：能夠查詢系統記錄的日誌，並根據能夠提取日誌進行分析等功能。

 

我的信息管理：對管理員我的信息密碼等進行維護。

 

2.1.2. 人員數據管理

 

2.1.2.1. 功能組成

 

人員數據主要是對平臺中的全部用戶進行管理，包括普通會員，收費會員，管理員、專家等。具體功能以下：會員管理、管理員管理、專家管理。

 

2.1.2.2. 功能描述

 

會員管理：主要功能包括能夠批量和手動添加普通會員、刪除、停用、修改會員，並能夠將普通會員提高爲收費會員。

 

管理員管理：超級管理員或主管能夠查看管理員信息，角色等，同時能夠增刪查改管理員。

 

專家管理：能夠對專家庫進行維護，可以對專家信息進行增刪查改等操做。

 

2.1.3. 產品數據庫管理

 

2.1.3.1. 功能組成

 

產品數據庫管理主要是針對產品庫、企業庫、商機庫、以及供求關係庫等進行維護和管理。

 

主要由如下幾個部分組成：產品庫管理、企業庫管理、商機庫管理以及供求關係庫的管理

 

2.1.3.2. 功能描述

 

產品庫：對網站現有產品進行維護，爲用戶提供產品服務，具備增刪查改等功能。

 

企業庫管理：對產品相關的企業信息進行維護，爲用戶提供企業信息服務，具備增刪查改等功能。

 

商機庫：同是爲企業創建商機信息、爲用戶提供商機信息服務，具備增刪查改等功能。

 

供求關係信息管理：整理維護用戶及廠家發佈的供求信息，爲用戶和廠家提供尋求及供應交流平臺。

 

2.1.4. 訂單管理

 

2.1.4.1. 功能組成

 

對平臺用戶訂購產品產生的訂單進行管理，分爲未處理訂單，已處理訂單，做廢訂單。

 

2.1.4.2. 功能描述

 

未處理訂單：主要是用戶訂購產品產生的未付費訂單，確認付費之後便可以確認訂單，並給用戶提供產品，同時訂單變爲已處理訂單，也能夠將沒用的訂單做廢變爲做廢訂單。

 

已處理訂單：管理員能夠查看全部已經付費或開通的訂單信息。

 

做廢訂單：管理員能夠查看已經做廢的訂單，同時也能夠恢復訂單爲未處理訂單。

1. 綜合描述

1.1.1. 廣告管理

1.1.1.1. 功能組成

廣告管理主要是對網站的廣告進行管理,主要功能包括廣告類型類型,廣告發布管理,廣告統計.

1.1.1.2. 功能描述

廣告類型管理:主要是根據現有廣告的形式對廣告進行分類管理,包括增刪查改等功能.

廣告發布:發佈廣告,撤回廣告以及編輯廣告.

廣告統計:查詢廣告統計信息,如投放時間,點擊率等.

1.1.2. 內容發佈系統管理

1.1.2.1. 功能組成

內容發佈系統由欄目管理、模版管理、文章發佈管理、專題管理組成。

1.1.2.2. 功能描述

欄目管理：主要是對文章頻道進行維護，功能上包括添加欄目、修改欄目、刪除欄目、發佈欄目、取消發佈、查看欄目等

模版管理：對網站用到的全部模版進行管理，包括增刪查改。

文章發佈管理：經過該平臺，用戶能夠完成相關的文章採集、上傳、編輯（內容修改、附件修改、指定欄目和維度、相關文章列表管理）、文章刪除、發佈、文章撤回修改、刷新、做者庫管理等功能，平臺可能的用戶有編輯（最常使用的用戶）、總編（各頻道、欄目的總編、值班總編等）、系統管理員、程序開發人員和測試人員等。

1. 文章列表

• 文章查詢：文章查詢提供了簡單查詢和複雜查詢兩種方式，其中簡單查詢提供了一些經常使用的查詢條件，複雜查詢則添加了欄目和緯度做爲查詢條件，其中欄目和緯度都從樹上選擇。複雜查詢頁面因爲要生成欄目樹和緯度樹，因此速度比較慢，另外基於欄目和緯度的查詢也很是用查詢條件，因此使用頻率也比較低，目前來看複雜查詢條件頁面存在的意義不是很大。
• 文章錄入、編輯

由編輯將收集到的文章信息錄入發佈系統，爲動態發佈到網站上作準備。

² 基本信息錄入

由編輯人員錄入文章的基本信息，包括文章的標題、簡介、正文、做者、來源、關鍵字等信息，錄入基本信息（文章內容中可使用輔助標籤進行編輯，具體標籤說明參考《賽迪網內容發佈標籤使用說明》）。

² 附件處理

在錄入基本信息以後，能夠同時選擇錄入附件。一次最多隻能上傳十個附件，一次上傳的文件大小不容許超過500K，容許上傳的文件類型以下：

tar、doc、pdf、ppt、gz、tgz、js、rpm、zip、gif、png、jpeg、jpg、css、txt、xml、html、htm、avi、mpeg、mpg、swf，某些功能可能會根據自身須要進一步的縮小上傳文件類型。附件設定支持附件的批量上傳，附件的引用名稱爲文章內容中引用的名稱。

² 文章編輯

點擊肯定後進入文章編輯界面，此時編輯能夠繼續選擇對文章的基本信息進行編輯或者進行文章相關屬性的調整，包括文章附件設定、文章對應欄目緯度設定、相關文章設定、文章擴張屬性設定。

² 相關調整

相關調整模塊能夠設置文章的相關文章，並能夠調整相關文章順序，目前一篇文章最多支持20篇相關文章,重置相關能夠刪除全部已經選擇的相關文章，相關文章的選擇是根據每篇文章的關鍵字由系統動態生成的。已經發布的文章進本內容不能進行編輯，但文章的其餘屬性能夠進行編輯。另外對於產品相關的文章，能夠在確認類別後加入到相關的產品小類或者某個具體的產品之下成爲產品的相關文章。

• 文章撤回編輯：狀態爲發佈的文章不能進行編輯，只有在撤回以後才能進行編輯，撤回將文章狀態從發佈置爲編輯，此時從網站上將不在能看到該文章。撤回編輯後從新發布的文章會將文章在顯示區中的排序時間更新爲最後發佈時間，因此文章對應的在顯示區中的順序也會調至最前。
• 文章刪除：已經發布的文章不能直接刪除，只能在撤回以後刪除。
• 文章發佈時間設定：針對文章的發佈時間進行單獨設定，在文章發佈後一樣能夠對發佈時間進行設定。

1. 文章手工錄入

提供了文章發佈的獨立入口，也能夠由文章列表模塊進入。手工錄入的流程同文章的發佈、編輯，發佈成功後的文章在文章列表部分進行統一維護。

1. 文章快速發佈

將文章基本信息錄入以及文章發佈兩個操做合二爲一，在用戶錄入文章基本信息並選擇欄目以後點擊肯定直接進行發佈，文章的相關設定此處不提供接口。

1. 刷新文章頁面

文章刷新分爲按文章ID刷新以及按照URL刷新兩種狀況，其中按照文章ID刷新主要是經過消息傳遞機制先刷新Middle上的文章對象以後再對Proxy上的文章緩存和靜態頁面進行刷新；而按照URL刷新則是直接對Proxy上的緩存對象以及靜態頁面進行刷新。

1. 做者庫管理

對賽迪集團之下，能夠爲賽迪網提供有效信息的做者進基本信息行統一管理，包括做者信息的增長、刪除、修改、詳細信息查詢、附件上傳。目前文章的做者信息大部分都沒有在做者庫中，因此目前文章與做者信息是做爲兩個相對獨立的實體存在的，而做者信息做爲文章信息的一部分應該與文章很好的結合起來，這樣對於咱們之後進行進一步的統計分析是很是重要的。

 

 

專題管理：對網站的專題進行發佈、編輯、撤回、刪除等操做。

1.1. 網站前臺門戶

登錄：會員登錄門戶系統

註冊：用戶添加我的信息，註冊成爲網站普通會員。

升級會員：普通會員繳納必定費用成爲付費會員，並享用一些付費服務。

個性化設置：用戶能夠根據本身的須要對我的界面進行個性化定製。

搜索：能夠對全站進行搜索。

產品庫查詢：能夠對門戶網站提供的產品進行查詢及瀏覽。

廠家查詢：能夠對產品的相關廠家進行查詢。

商機信息查詢：對廠家提供的商機信息進行查詢。

訂購產品：訂購產品，並進行在線付費。

專家諮詢：查詢我的及行業專業，找尋解決方案。

解決方案查詢：對網站現有方案進行查詢，並付費瀏覽。

各類行業信息動態：查看行業信息新聞/

供求信息發佈：能夠發佈我的需求信息，以尋求須要的產品及解決方案。

專家訪談：聘請專家進行訪談爲用戶解疑答疑，並造成信息庫。

廣告：根據須要在網站上掛接各類廣告。

我的信息：對我的註冊信息進行維護管理。

我的消費明細：查詢我的消費清單。

2. 核心算法

2.1. 前臺：

2.1.1. 會員登錄

    網站註冊用戶在登錄後，會把註冊信息寫入Cookie中，若是檢查Cookie中沒有相應信息，在執行瀏覽文章或購買等操做時，會提示用戶進行登錄。

 

           

2.1.2. 會員註冊

          會員註冊時，首先會把註冊信息寫入passport用戶庫。

 

2.1.3. 文章瀏覽

     

 

2.1.4. 供求信息

      

 

2.1.5. 緩存機制

     爲提供系統性能，減小數據庫訪問，前臺瀏覽欄目頁、報告頁、文章頁的時候，首先訪問系統緩存，若是緩存中有相應內容，從緩存中提取內容；若是沒有，訪問數據庫提取內容，並將內容加入緩存。緩存採用特定的算法，定時清除最近最少訪問的內容。

 

2.2. 後臺：

2.2.1. 文章相關

文章的發佈、撤回、編輯等功能，使用高級編輯功能，實現所見即所得的效果，頁面示意以下。

功能：

1. 採編，網上抓取信息，進行再加工
2. 欄目權限控制

 

 

文章發佈流程

 

       

    

2.2.2. 欄目（商品類別）相關

            完成欄目的添加、修改等維護功能，支持樹型欄目。

 

2.2.3. 訂單相關

一、 完成用戶定購的審覈。

二、 完成客戶購買的訂單審覈

三、 完成用戶定購信息的統計。

2.2.4. 積分相關

           本期尚未肯定的需求，預留功能接口。

2.2.5. 會員相關

一、 統計

        根據會員購買狀況、日期階段、活躍狀態等對會員進行統計。

二、 積分、折扣等信息調整

三、 分類、高級會員，普通會員

 本期尚未明確的需求，預留功能接口。

 

2.3. 公共組件：

2.3.1. 管理員權限分級控制

第一級：系統管理員，擁有系統最高權限，可進行本系統的全部操做。

第二級：業務部門經理，擁有業務最高權限，但不能進行系統參數設置、日誌管理等功能。

第三級：普通操做人員，能夠進行平常文章發佈、報告發布等功能，但不能進行報告審覈。

2.3.2. 分頁組件

前臺和後臺公用分頁組件，可以顯示總記錄數、每頁條數、上一頁、下一頁、各頁連接。

2.3.3. 日誌組件

記錄文章的發佈和撤回、報告的發佈和撤回、訂單的審覈等信息。

2.3.4. Email發送組件

在程序中調用該組件完成Email發送功能。本期使用原系統中的發送郵件組件。

2.3.5. TRS組件（全文搜索數據庫）

【需另行購買，詳情見TRS白皮書 或http://www.trs.com.cn/products/eseism/server/】

完成TRS數據庫的插入、刪除、查詢。使用兩種方式來使用TRS組件：

1、前臺直接調用TRS的頁面查詢接口，查詢文章和報告。

2、在應用程序中調用TRS的JAVA   API ，對TRS數據進行增、刪、查、改操做。

2.3.6. Cache組件

     前臺採用Cache機制，提升訪問效率。本期採用發佈系統中已經成熟應用多年的Cache組件包。

3. UI設計

        爲保證系統平滑過渡，適應客戶和管理員的使用系統，新系統採用和舊系統同樣的風格和樣式。

3.1. 界面佈局

3.1.1. 界面佈局

1． 文字的排布

a.  一般放在最顯著的地方，如整個顯示的中央稍微偏右下；文本的排布總體性好，使瀏覽起來通暢而絲毫沒有阻礙。

b.  文字的大小適中，在不一樣的分辨率下都不會有太大的影響。

c.  文字的顏色不要太多。

2． 圖片的排布

1. 圖片的體積不要太大，同時又要使圖片儘可能清楚，直觀，最大限度的發揮它的做用。
2. 圖片與圖片之間要聯繫凸現，同時又要融爲一個總體，使看起來有條理。

3． 按鈕類單元的排布

1. 頁面上的按鈕，連接，複選框，單選框。同類單元應該儘可能保持大小同樣，左右對齊。按鈕的大小要與界面的大小和空間要協調，避免空曠的界面上放置很大的按鈕。
2. 忌用太長的名稱，省得佔用過多的界面位置。
3. 字體的大小要與界面的大小比例協調, 一般使用的字體中宋體9-12較爲美觀，不多使用超過12號的字體。

4． 表格的排布

1. 表格大小要和界面相適應，不能在表格以外有很大空餘，或者表格過大緊貼整個頁面。
2. 表格的顏色要與界面風格符合，搭配合理協調，反差不宜太大，堅定杜絕刺目的顏色。

5． 文本框類單元的排布

1. 同一列的文本框應該儘可能保持對齊。
2. 若是要求爲只讀的文本框，應該儘可能使用ReadOnly屬性，而不是用Disable屬性。

3.1.2. 界面色彩

1． 不要將全部顏色都用到，儘可能控制在三種色彩之內。

2． 背景和前文的對比儘可能要大(絕對不要用花紋繁複的圖案做背景)，以便突出主要文字內容。

3.2. 界面單元

1． 易用性

1. 完成同一功能或任務的元素應該放在集中位置，儘可能減小鼠標移動的距離。
2. 界面上首先應輸入的和重要信息的控件在Tab順序中應當靠前,位置也應放在窗口上較醒目的位置。
3. 同一界面上的控件數最好不要超過10個，多於10個時能夠考慮使用分頁界面顯示。
4. 默認按鈕要支持Enter及選操做，即按Enter後自動執行默認按鈕對應操做。
5. 複選框和選項框按選擇概率的高底而前後排列。
6. 按功能將界面劃分局域塊，用Frame框括起來,並要有功能說明或標題。
7. 可寫控件檢測到非法輸入後應給出說明並能自動得到焦點。
8. 滾動條的長度要根據顯示信息的長度或寬度能及時變換，以利於用戶瞭解顯示信息的位置和百分比。
9. 各名稱爲日期或時間的控件應統一標準，顯示爲年月日的統一稱爲「日期」，不該是「時間」。
10. 顯示日期（時間）時要有分隔符，如YYYY-MM-DD（HH:MM:SS）
11. 模塊級主界面中的「新建」「修改」「查詢」「刪除」等按鈕應統一順序。
12. 錯誤提示應正確、友好，屏蔽系統級和數據庫級錯誤。
13. 父窗體或主窗體的中心位置應該在對角線焦點附近。
14. 子窗體位置應該在主窗體的左上角或正中。
15. 多個子窗體彈出時應該依次向右下方偏移，以顯示窗體出標題爲宜。
16. 重要的命令按鈕與使用較頻繁的按鈕要放在界面上注目的位置。
17. 容易引發界面退出或關閉的按鈕不該該放在易點位置。橫排開頭或最後與豎排最後爲易點位置。
18. 非法的輸入或操做應有足夠的提示說明。
19. 對運行過程當中出現問題而引發錯誤的地方要有提示，讓用戶明白錯誤出處，避免造成無限期的等待。
20. 提示、警告、或錯誤說明應該清楚、明瞭、恰當。
21. 主界面，最好是大多數界面上要有公司圖標。
22. 登陸界面上要有本產品的標誌，同時包含公司圖標。
23. 助菜單的「關於」中應有版權和產品信息。
24. 公司的系列產品要保持一直的界面風格，如背景色、字體、菜單排列方式、圖標、安裝過程、按鈕用語等應該大致一致。
25. 可以排除可能會使應用非正常停止的錯誤。
26. 能夠避免用戶無心錄入無效的數據。
27. 對可能引發致命錯誤或系統出錯的輸入字符或動做要加限制或屏蔽。
28. 對可能發生嚴重後果的操做要有補救措施。經過補救措施用戶能夠回到原來的正確狀態。
29. 對錯誤操做最好支持可逆性處理，如取消系列操做。
30. 對可能形成等待時間較長的操做應該提供取消功能。
31. 與系統採用的保留字符衝突的要加以限制。
32. 子窗口儘可能屏蔽地址欄，能夠防止用戶非法的在各個頁面間跳轉。

2． 規範性

3． 合理性

4． 獨特性

5． 安全性