BBS論壇系統(tǒng)概要設計說明書

1 壇系統(tǒng)概要設計說明書 寫目的 本文檔作為 概要設計說明文檔，用于與用戶確定最終的目標，并成為協(xié)議文本的一部分，同時也是本系統(tǒng)設計人員的基礎文檔。 要設計說明書目的 本概要設計說明書說明了 壇系統(tǒng)設計的整體結構。 期讀者 本系統(tǒng)開發(fā)人員及維護人員。 景 壇，或者稱為社區(qū)，是電子商務網(wǎng)站中一種常見功能，也是互聯(lián)網(wǎng)上一種極為常見的互動交流服務。它為上網(wǎng)用戶提供了也各自由的討論區(qū)。通過論壇可以向用戶提供開放性的分類專題討論區(qū)服務，同時注冊的用戶 可以根據(jù)需要在論壇上發(fā)表文章，交流技術經(jīng)驗，或者提出問題并表達自己的觀點。不僅如此，上網(wǎng)的用戶還可以在論壇中看到他人發(fā)表的文章，并且能夠?qū)υ撐恼逻M行評論。 一般情況下， 不同主題分為多個布告欄，其設立多是依據(jù)使用者的要求和喜好，但多具有信件交流、軟件交流、信息發(fā)布等功能。 目前，大部分 教育機構、研究機構或商業(yè)機構管理，大多有自己的撥入電話號碼，用戶只需電腦、調(diào)制解調(diào)器和電話線就可通過電話撥號登錄 點。 待開發(fā)軟件系統(tǒng)的名稱 壇系統(tǒng) 2 項目的任務提出者 項目的任務開發(fā)者 義 文檔中涉及的專業(yè)詞匯 1、 華人民共和國國家標準的英文縮寫字母 2、構件：具有某種功能的可重用的軟件模版單元，表示了系統(tǒng)中主要的計算元素和數(shù)據(jù)存儲。 3、邏輯視圖：描述支持系統(tǒng)的功能需求的視圖。 4、開發(fā)視圖：也稱模塊視圖，主要側重于軟件模塊的組織和管理描述。 詞說明 1、 、 術使用 程語言編寫類 封裝產(chǎn)生動態(tài)網(wǎng)頁的處理邏輯。網(wǎng)頁還能通過 問存在于服務端的資源的應用邏輯。 網(wǎng)頁邏輯與網(wǎng)頁設計和顯示分離，支持可重用的基于組件的設計，使基于 應用程序的開發(fā)變得迅速和容易 3、 是一個 架（ 它 用于快速開發(fā) 用。 現(xiàn)的重點在 C(， 包 括我們定制的 為 V(供了一系列定制標簽（ 但 乎沒有涉及 M(所以 以采用 現(xiàn)的任何形式的商業(yè)邏輯。 考資料 1、本軟件項目規(guī)劃依據(jù)標準為國家表準： 88； 2、技術參考資料 （ 1） 目實訓 架技術（ 21 世紀高等學校實用軟件工程教育規(guī)劃教材） 楊少波 等編著 清華大學出版社 2008 年 5 月 （ 2） 目實訓 架技術（ 21 世紀高等學校實用軟件工程教育規(guī)劃教材） 楊少波 等編著 清華大學出版社 2008 年 5 月 （ 3） 目實訓 設計模式（ 21 世紀高等學校實用軟件工程教育規(guī)劃教材） 楊少波 等編著 清華大學出版社 2008 年 5 月 （ 4） 目實訓 架技術（ 21 世紀高等學校實用軟件工程教育規(guī)劃教材） 3 楊少波 等編著 清華大學出版社 2008 年 10 月 第二章 總體設計（系統(tǒng)架構設計） 求規(guī)定 入輸出要求 界面風格：要求整體界面美觀，有清晰的層次感，布局簡潔、合理。同時保證后臺的管理頁面和前臺的服務頁面保持風格的一致。 間 要 求 時間需求 :在軟件方面，響應時間，更新處理時間都比較快且迅速， 系統(tǒng)響應時間不能超過 20 秒。 活性 要求 靈活性 :當用戶需求，如操作方式，運行環(huán)境，結果精度，數(shù)據(jù)結構等其他軟件接口等發(fā)生變化時，設計的軟件能做出適當調(diào)整 ， 靈活性非常大。 行環(huán)境 備 1、主機類型如表 2 2機類型 類別 服務器標準配置 騰 2。 0上 內(nèi)存 256好 512上 硬盤 120G 以上 其他 無特殊要求 2、網(wǎng)絡類型：百 兆高速局域網(wǎng) 3、存貯器容量：大容量存貯器 4 4、其他特殊設備：網(wǎng)絡打印機，復印機 撐軟件 1、 操作系統(tǒng)： 003 2、 數(shù)據(jù)庫管理系統(tǒng)： 上版本數(shù)據(jù)庫 3、 其他支撐軟件： 以上版本 4、 應用服務器 ： 上 本設計概念和處理流程 統(tǒng)概述 1、系統(tǒng)采用基于 輕量級 B/S 架構體系 上論壇系統(tǒng)采用 B/S 架構（瀏覽器 /服務器）模式來實現(xiàn)?？紤]到系統(tǒng)應用性、安全性、可擴展性與可維護性，決定采用基于 輕量 級架構體系。其體系結構圖如下所示： 2、為什么對本項目要應用輕量級的框架技術 輕量級容器的設計目標是為了能夠避免如下所有這些麻煩事情，基于以下的各個優(yōu)點，我們決定在本項目中采用輕量級的框架技術。 侵略性的 碼依賴于 對容器的依賴 (代碼不能在 器之外工作 ) 只提供固定的一組功能 ,不具備配置能力 啟動時間長 部署過程取決于特定的產(chǎn)品，無法通用 統(tǒng)架構示圖 1、本論壇系統(tǒng)的整體架構設計為 構組成 5 （ 1）對于表 示層 經(jīng)驗表明，最好的方法是選擇已存在的并已得到證明了的 用框架，而不是自己去設計和開發(fā)新的框架。我們擁有多個可選擇的框架，如 ，在本項目中，我們選擇采用 （ 2） 可以用來創(chuàng)建業(yè)務邏輯層 如果應用是分布式的，采用具有 口的 一個好的選擇；由于本系統(tǒng)是一個典型的不需要遠程訪問的 用，因此選用 充分利用 架的 特性，將是實現(xiàn)業(yè)務邏輯層的更好選擇。 （ 3）在持久層中由于需要利用關 系型數(shù)據(jù)庫實現(xiàn)數(shù)據(jù)的持續(xù)化，但在應用中可以存在多種方法可用來實現(xiàn)： 是最為靈活的方法，然而，低級的 以使用，而且質(zhì)量差的 碼很難運轉(zhuǎn)良好 一種分離數(shù)據(jù)訪問代碼和處理 昂貴的方法，它是以應用服務器為中心的方法，即 是將應用與某種數(shù)據(jù)庫類型而是 器約束在一起。 O/R 架：一個 架采用以對象為中心的方法實現(xiàn)數(shù)據(jù)持續(xù)化，一個以對象為中心的應用易于開發(fā)并具有高 度的可移植性 及 。在本項目中我們選用 2、架構示圖 本系統(tǒng)采用了多層非分布式的構架，上圖展示了系統(tǒng)的分層以及每一層中所采用的技術和對應的框架，并且各層將存在于同一個 器中。 3、該形式的總體架構設計的主要特點 （ 1）遵循 2兩個主要的原則：“多層架構、松藕合” 由于采用分層的設計方式，各個模塊功能相互獨立封裝，層與層之間關聯(lián)少，保 持松耦合連接，穩(wěn)定性高，便于擴展和維護。 （ 2）本項目中的每一層所采用的技術都是可替換的 例如 以被 者 換掉， 替換 在每個層中都不同程度地應用了 常用的設計模式 使用基于 輕量級架構，從而使得系統(tǒng)易于測試；便于移植；“開發(fā) 期短。 擔表示層和控制層的角色） 利 用行各種對象的管理 ） 現(xiàn)數(shù)據(jù)訪問和 O/R 相互集成 對 行管理 示層（ 制層 務處理層 據(jù)訪問層 前 端 控制器類 業(yè) 務 控 制類 業(yè)務處理基類 業(yè)務 接口 數(shù) 據(jù) 操作類 數(shù) 據(jù) 連 接類 持久實體類 數(shù) 據(jù) 訪問服務 數(shù) 據(jù) 訪問操作 業(yè)務處理類 業(yè)務實體類 6 4、各層中的組件 （ 1）表示層由 件實現(xiàn)，利用了 的構造標簽技術，在用戶瀏覽界面利用表單構造網(wǎng)頁的整體結構 （ 2）控制層由 的 件實現(xiàn)，并利用 裝 面中的表單。將頁面整體作為對象處理，在相應的 中調(diào)用業(yè)務邏輯，完成業(yè)務功能。 前端控制層： ，并且對它加以擴展。 業(yè)務中心控制層：各個業(yè)務 （標準 和 ） （ 3）業(yè)務處理層由 的 管理 業(yè)務處理基類：將各個業(yè)務功能模塊中共同的部分抽象出，從而完成一些共同的功能。 各個業(yè)務處理類：完成具體的應用功能的各個模塊 （ 4）數(shù)據(jù)訪問 層由 架來提供技術支持 數(shù)據(jù)庫操作（ ：完成對數(shù)據(jù)庫數(shù)據(jù)的相關操作（增、刪、解、查詢等）。 數(shù)據(jù)持久（ ：針對應用系統(tǒng)中的各個數(shù)據(jù)庫表提供對應的 層中應用了相應的主流的 架技術 1、服務器端表示層 架完成如下工作 客戶端表單進入的驗證； 管理請求和響應； 提供控制器來完成頁面流轉(zhuǎn)和向業(yè)務邏輯層的委托； 返回到客戶端頁面顯示。 其它：標簽技術、 熟技術、 術等 2、業(yè)務邏輯層 架完成如下工作 為服 務器段表示層提供松散的耦合； 處理真實的企業(yè)級應用； 事務管理的選擇； 協(xié)調(diào)各種業(yè)務邏輯對象之間的依賴關系； 為持久層和業(yè)務邏輯層之間提供松散耦合； 實現(xiàn)持久層的業(yè)務邏輯。 其它： 解藕（類與類、系統(tǒng)本身脫離容器） 一地解決系統(tǒng)中一些“切面” 象的管理由容器完成） 通 容器服務（事務、數(shù)據(jù)庫連接池） 已經(jīng)提供了 包裝其它的框架（簡化） 3、持久層 架完成如下工作 對數(shù) 據(jù)庫進行查詢，得到持久化對象 對數(shù)據(jù)庫進行添加、刪除、修改的動作并以 進行。 域模型層 成如下工作：為各層之間數(shù)據(jù)交互服務，同時也在持久層部分可以描述一個實體，并與 行轉(zhuǎn)換。 其它： 屏蔽數(shù)據(jù)庫的差異性 以面向?qū)ο蟮臄?shù)據(jù)庫訪問（減少了 各種對象關系 O/R 現(xiàn) 7 技術成熟 統(tǒng)一的事務管理實現(xiàn) 提供各種緩存技術以提高速度（性能） 統(tǒng)基于 計 體架構設計模型組件 控制調(diào)度層 表示層中的請求 業(yè)務處理層 表示層中的業(yè)務成功顯示 數(shù)據(jù)訪問層 表示層中的業(yè)務失敗顯示 據(jù)庫 采用 的 于 術的數(shù)據(jù)訪問組件（ 定義的標簽 用戶 圖助手組件 務基類和面向業(yè)務接口編程 各種具體的業(yè)務組件 各種具體的業(yè)務組件 各種具體的業(yè)務組件 各種具體的業(yè)務組件 的各種標簽庫中的標簽 式 式 式 復合視圖 模式 式 基于 數(shù)據(jù)庫連接池 8 統(tǒng)結構（系統(tǒng)各個組件設計） 系結構包圖（架構包圖） 件設計圖（系統(tǒng)中的各個組件） 圖與接口設計（各個組件中的相關的類和接口） 1、數(shù)據(jù)訪問層組件 9 采用一個 件實現(xiàn)數(shù)據(jù)訪問操作 分別采用不同的 件實現(xiàn)數(shù)據(jù)訪問操作 10 2、業(yè)務處理層組件 11 3、控制層組件 12 4、表示層組件 統(tǒng)總體類圖（以體現(xiàn)類之間的關系） 13 第三章 系統(tǒng)數(shù)據(jù)結構設計 據(jù)庫邏輯結構設計 體關系（ 1、邏輯圖（ 14 2、物理圖（ 據(jù)庫表的邏輯設計 1、 息數(shù)據(jù)庫表結構及數(shù)據(jù)字典定義表 注意： 對數(shù)據(jù)庫表中的結構設計，最后應該給出下面的對每個字段的詳細說明。 字 段 名 標 識 符 類型及長度 有無空值 主鍵 識 id 動編號） 無 者 題 字段名 標識符 類型及長度 是否允許為空 主鍵 主題 ID K 主題作者 0) 主題標題 0) 回復數(shù) 發(fā)表時間 0) 最后回復時間 0) 內(nèi)容 6) 15 點擊數(shù) 情圖片 所屬類型 ID 所屬版塊 ID 用戶 ID 是否為精華帖 是否置頂主題 是否禁止回復 所屬類型：原創(chuàng)、轉(zhuǎn)貼、問題、灌水、建議、種子、資料、下載 2、 復信息表結構及數(shù)據(jù)字典定義表 字段名 標識符 類型及長度 是否允許為空 主鍵 回復帖 ID K 所屬主題 ID 回復作者 0) 回復時間 0) 回復表情 ID 回復標題 0) 回復內(nèi)容 ot 3、 類標題數(shù)據(jù)庫表結構及數(shù)據(jù)字典定義表 字段名 標識符 類型及長度 是否允許為空 主鍵 16 版塊 ID K 版塊題目 0) 版塊內(nèi)容 55) 版主 0) 副版主 0) 版塊主題總和 版塊當天帖子總和 最后回復的時間 0) 最后回復的作者 0) 4、用戶信息數(shù)據(jù)庫表結構及數(shù)據(jù)字典定義表 字段名 標識符 類型及長度 是否允許為空 主鍵 用戶 ID 否 戶名 0) 否 用戶性別 (男 0，女 1) ) 否 用戶密碼 6) 否 用戶 0) 否 用戶取回密碼問題 0) 否 用戶取回密碼答案 0) 否 用戶角色 ) 否 用戶生日 0) 用戶地址 0) 注冊時間 0) 否 用戶頭像 55) 5) 用戶簽名檔 17 最后登錄時間 0) 否 用戶發(fā)表的主題數(shù)總和 用戶回復的主題數(shù)總和 用戶被刪的帖子總和 用戶被推薦精華帖總和 用戶登錄次數(shù) 是否被禁言 5、管理員的數(shù)據(jù)庫表及數(shù)據(jù)字典定義表 6、用戶聯(lián)系數(shù)據(jù)庫表結構及數(shù)據(jù)字典定義表 7、用戶角色數(shù)據(jù)庫表結構及數(shù)據(jù)字典定義表 字段名 標識符 類型及長度 是否允許空 主鍵 18 角色 ID K 角色名稱 0) 用戶 ID 下面為說明在 創(chuàng)建出各個數(shù)據(jù)庫