校友網的設計與實現畢業論文(編輯修改稿)

　

【文章內容簡介】 下圖圖316 留言管理數據流程圖 吐槽墻管理數據流程圖 數據流程分析： 吐槽管理主要包括吐槽審核和吐槽登記兩個模塊。 流向吐槽墻審核處理P15的數據流包括F10吐槽信息。流出吐槽墻審核處理P15的數據流包括F18審核不通過、F21審核通過。 流向吐槽墻登記處理P16的數據流包括F21審核通過。流出吐槽墻登記處理P16的數據存儲有D9吐槽表。詳細數據流程如下圖圖317 吐槽管理數據流程圖 班級管理數據流程圖 數據流程分析：班級管理分為留言管理、班級管理兩個模塊。 留言模塊分析與單獨的留言管理數據流程分析類似。流向P17班級審核處理的數據流為F6班級創建信息。流出班級審核處理P17的數據流為F18審核不通過、F21審核通過。流向班級登記處理P18的數據流為F21審核通過，流出班級登記處理P18的數據存儲為D6班級表。流向加入班級審核處理P19的數據流為F27用戶加入班級申請和實體E3班長。流出加入班級審核處理P19的數據流為F18審核不通過、F28用戶加入班級并更新班級表。詳細數據流程如下圖圖318 班級管理數據流程圖 群組管理數據流程圖數據流程分析： 群組管理主要分為群組管理、日志管理兩個模塊。 群組管理分析結果類似于班級管理數據流分析。日志管理分析結果與獨立日志管理數據流圖分析類似，但發表的日志和評論中只有群組管理員有修改刪除權力，普通用戶只有查看的權力。不同于班級管理的是群組管理員有修改群組資料和注銷群組的權力。詳細數據流程如下圖圖319 群組管理數據流程圖 通訊錄管理數據流程圖 數據流程分析：通訊錄管理分為班級建立、通訊錄管理兩個模塊。 班級建立模塊分析與單獨的班級管理數據流程分析類似。流向通訊錄審核處理P20的數據流為F8通訊錄信息。流出通訊錄審核處理P20的數據流為F18審核不通過、F21審核通過。流向通訊錄登記處理P21的數據流為F21審核通過，流出班通訊錄登記處理P21的數據存儲為D7通訊錄表。流向加入通訊錄刪除處理P22的實體E1用戶。流出通訊錄刪除處理P22的數據存儲為D7通訊錄表。詳細數據流程如下圖圖320 通訊錄管理數據流程圖 數據流程分析：后臺管理分為查看或刪除日志（說說、留言、用戶、班級、群組）、添加管理員管理兩個模塊。 因為刪除說說、留言、用戶、班級、群組的數據流與查看或刪除日志的數據流分析類似，所以在此只列舉出刪除日志的數據流圖。流向查詢處理P26的數據流為F4日志內容。流出查詢處理P26的處理為P4日志審核和數據流F21審核通過。流向添加管理員設和處理P27的數據流為F33管理員信息，流出添加管理員設和處理P27的數據流F18審核不通過、F34添加管理員成功。詳細數據流程如下圖圖321 后臺管理數據流程圖 數據字典（見附錄1）數據字典，有一種解釋就是一種用戶可以訪問的記錄數據庫和應用程序源數據的目錄。主動數據字典是指在對數據庫或應用程序結構進行修改時，其內容可以由DBMS自動更新的數據字典。被動數據字典是指修改時必須手工更新其內容的數據字典。數據字典在需求分析階段被建立。數據字典是一個預留空間，一個數據庫，這是用來儲存信息數據庫本身。數據字典則是系統中各類數據描述的集合,是進行詳細的數據收集和數據分析所獲得的主要成果。數據字典通常包括數據項\數據結構\數據流\數據存儲和處理過程五個部分。其中數據項是數據的最小組成單位若干個數據項可以組成一個數據結構數據字典通過對數據項和數據結構的 定義來描述數據流、數據存儲的邏輯內容。數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合.數據字典還有另一種含義，是在數據庫設計時用到的一種工具，用來描述數據庫中基本表的設計，主要包括字段名、數據類型、主鍵、外鍵等描述表的屬性的內容。 數據庫設計 概念結構設計（CDM圖）人們把數據庫設計分為需求分析、概念結構設計、邏輯結構設計、物理結構設計、數據庫實施、數據庫運行與維護6個階段。概念結構設計就是對信息世界進行建模，常用的概念模型是CDM模型和ER模型， 于1976年提出來的。本系統概念結構設計采用CDM模型結構，CDM圖則使用power designer繪制。CDM圖由實體、聯系、關聯三者構成，實體包括實體名稱、實體屬性（包括主鍵），聯系由聯系名稱、屬性構成。具體而言，該CDM模型包括11個實體（用戶、班級、群組、通訊錄、日志、留言、說說、評論、在線聊天、吐槽墻、圖片）組成，其中以用戶實體為中心。各個實體之間有聯系，分別為用戶與用戶之間的好友聯系、用戶與群組之間的用戶群組聯系、用戶與通訊錄之間的個人通訊錄聯系、班級與通訊錄之間的班級通訊錄聯系、用戶與班級的用戶班級聯系、群組與日志之間的群組話題聯系、班級與日志之間的班級留言聯系、日志和評論之間的日志回復聯系、留言與評論之間的留言評論聯系、說說與評論之間的說說評論聯系等等。各個實體的屬性組成詳見附錄二（基本表結構）。本系統具體CDM圖如下：圖322 CDM圖 物理結構設計（PDM圖） 數據庫物理設計是后半段。將一個給定邏輯結構實施到具體的環境中時，邏輯數據模型要選取一個具體的工作環境，這個工作環境提供了數據存儲結構與存取方法，這個過程就是數據庫的物理設計。物理結構依賴于給定的DBMS和和硬件系統，因此設計人員必須充分了解所用RDBMS的內部特征、存儲結構、存取方法。本系統PDM圖是在CDM圖的基礎上，由power designer自動生成的。具體PDM圖如下：圖323 PDM圖4 系統設計系統設計階段的主要目的是，將系統分析階段所提出的、充分反映了用戶需求的系統邏輯方案轉換成可以實施的、基于計算機與網絡技術的物理（技術）方案。系統設計階段的主要任務是從信息系統的總體目標出發，根據系統分析階段對系統的邏輯功能的要求，并考慮到經濟、技術和運行環境等方面的條件，確定系統的總體結構和系統組成部分的技術方案，提出系統的實施計劃。系統總體結構設計應遵循以下幾條主要原則： 合理性原則 在系統設計時，充分考慮系統的容量及功能的擴充，方便系統擴容及平滑升級。系統對運行環境(硬件設備、軟件操作系統等)具有較好的適應性，不依賴于某一特定型號計算機設備和固定版本的操作系統軟件。 經濟性原則 在滿足系統功能及性能要求的前提下，盡量降低系統建設成本，采用經濟實用的技術和設備，利用現有設備和資源，綜合考慮系統的建設、升級和維護費用。系統符合向上兼容性、向下兼容性、配套兼容和前后版本轉換等功能。 實用性原則 本系統提供清晰、簡潔、友好的中文人機交互界面，操作簡便、靈活、易學易用，便于管理和維護。具有公安行業風格界面和公安行業習慣操作的客戶端界面。在快速操作處理突發事件上有較高的時效性，能夠滿足公安聯網指揮的統一行動。 規范性原則 系統中采用的控制協議、編解碼協議、接口協議、媒體文件格式、傳輸協議等符合國家標準、行業標準和公安部頒布的技術規范。系統具有良好的兼容性和互聯互通性。 可維護性原則 系統操作簡單，實用性高，具有易操作、易維護的特點，系統具有專業的管理維護終端，方便系統維護。并且，系統具備自檢、故障診斷及故障弱化功能，在出現故障時，能得到及時、快速地進行自維護。 可擴展性原則 系統具備良好的輸入輸出接口，可為各種增值業務提供接口。 開放性原則 系統設計遵循開放性原則，能夠支持多種硬件設備和網絡系統，軟硬件支持二次開發。各系統采用標準數據接口，具有與其他信息系統進行數據交換和數據共享的能力。 系統總體功能結構圖 圖41 系統總體功能結構圖如上圖，系統總共分為11個功能，分別為注冊管理、登錄管理、日志管理、說說管理、留言管理、班級管理、群組管理、吐槽墻管理、通訊錄管理、在線聊天管理、系統后臺管理。詳細功能劃分如下： 注冊管理功能結構圖如下圖，注冊管理功能主要有新用戶操作，其提供個人信息即可注冊一個賬號，之后登錄就不需要再注冊。其包括用戶個人信息錄入、系統審核、賬號密碼信息生成。 圖42 注冊管理功能結構圖 登錄管理功能結構圖如下圖，登錄管理功能主要是針對已注冊的用戶，其通過已注冊的昵稱和密碼作為登錄輸入的賬號密碼，即可登錄進入系統。登錄功能包括賬號密碼錄入、個人信息修改。 圖43 登錄管理功能結構圖 日志管理功能結構圖如下圖，日志管理功能主要是針對已登錄的用戶，其可以在系統內發表日志。具體功能包括日志信息錄入、日志信息評論、日志信息修改、日志信息刪除等。 圖44 日志管理功能結構圖 說說管理功能結構圖如下圖，說說管理功能主要是針對已登錄的用戶，其可以在系統內發表說說。具體功能包括說說信息錄入、說說信息評論等。 圖45 說說管理功能結構圖 留言管理功能結構圖如下圖，留言管理功能主要是針對已登錄的用戶，其可以在系統內發表留言。具體功能包括留言信息錄入、留言信息評論等。 圖46 留言管理功能結構圖 班級和通訊錄管理功能結構圖如下圖，班級和通訊錄管理功能主要是針對班級創建者而設立的，班長可以管理班級內的留言、評論、通訊錄。具體功能包括班級信息錄入、留言信息錄入、評論信息錄入、通訊錄信息錄入、班級信息修改、通訊錄信息修改等。 圖47 班級管理功能結構圖 群組管理功能結構圖如下圖，群組管理功能主要是針對群組創建者而設立的，群組管理員可以管理群組內的留言、評論、群組信息。具體功能包括群組信息錄入、留言信息錄入、評論信息錄入、群組信息修改、群組信息刪除等。 圖48 群組管理功能結構圖 吐槽墻管理功能結構圖如下圖，吐槽墻管理功能主要是針對所有用戶，用戶都可以在吐槽墻內發表自己的觀點，并對觀點進行評論。具體功能包括吐槽墻信息錄入、評論信息錄入等。 圖49 吐槽墻管理功能結構圖 系統后臺管理功能結構圖如下圖，系統后臺管理功能主要是針對管理員的，管理員能在登錄的情況下對留言進行刪除、對說說進行刪除、日志刪除、用戶刪除、評論刪除等。 圖410 后臺管理功能結構圖 代碼設計代碼是代表事物名稱、屬性、狀態的符號，為了便于計算機處理一般用數字，字母或它們的組合表示。代碼為事物提供一個概要而不含糊的認定，便于數據的存儲和檢索。從而提高處理的效率、精度和數據的全局一致性。合理的編碼結構是信息處理系統是否具有生命力的一個重要因素，因此，在一套實用的系統中，有一套良好的編碼體系是十分重要的。在編碼設計過程中，遵循以下原則：在邏輯上要滿足用戶的需求。一個代碼應唯一表示它所代表的事物或屬性。代碼設計時要預留足夠的位置。代碼設計要系統化、標準化本系統涉及的代碼設計有一下： 電話代碼 代碼名稱：電話號碼 代碼格式: xxxxxxxxxxx 代碼示例：07345332362 07311234567 0238765432電話號碼編號分為兩部分，第一部分編號有三位或四位，它代表電話區號，代表該地區編號，0734代表衡陽，023代表重慶。第二部分為后七位或八位代表電話的編號，是隨機的。這兩部分必須是數字。 郵箱代碼 代碼名稱：郵箱地址 代碼格式: _x@ 代碼示例：865645781@ 547687@ 987678@編號第一到@之前代表賬號，是一個隨機編號，@代表格式符，@，qq代表騰訊郵箱，163代表網易郵箱，.代表郵箱后綴，是固定格式。 表結構設計（見附錄2） 輸入輸出設計 用戶界面是指軟件系統與用戶交互的接口，也就是通常所說的輸入、輸出界面，而輸入輸出(I/O)設計對于用戶今后系統使用的方便和安全可靠性來說都是十分重要的。一個好的輸入設計系統設計可以為用戶和系統雙方帶來良好的工作環境；一個好的輸出設計可以為管理者提供快捷、明了、有效、實用的管理和控制信息 。輸出是由計算機對輸入的原始信息進行加工處理，形成高質量的有效信息，并使之具有一定的格式，提供管理者使用，這也是輸出設計的主要職責和目標。輸入設計的出發點是確保向信息系統提供正確的信息，輸入設計必須根據輸出設計的要求來確定。 界面設計規范 總體目標 以規范作為基本原則，在此框架內進行合理的擴展和變化，將站點內的每個模塊服從于整個站點，模塊頁面與“高內聚”的控制代碼緊密的結合在一起，同時對應于應用程序基于系統的架構分析。 具體要求有以下： 界面色彩要求：計算機屏幕的發光成像和普通視覺成像有很大的不同，應該注意這種差別作出恰當的色彩搭配。對于需用戶長時間使用的系統，應當使用戶在較長時間使用后不至于過于感到視覺疲勞為宜。例如輕松的淡彩為主配色，灰色系為主配色等等。切忌色彩過多，花哨艷麗，嚴重妨礙用戶視覺交互。 界面平面版式要求：系統樣式排版整齊劃一，盡可能劃分不同的功能區域于固定位置，固定的格式，方便用戶導航使用；排版不宜過于密集，保留一定的“留白”區域，減輕查看時的視覺疲勞。 數據顯示集中原則：各種列表在頁面中往往是傳遞信息的核心，盡量集中的表現出來，并提供必要的關聯數據、表等恰當的組織起來，并且在視覺上使用戶很容易察覺數據之間的關系，并方便查看、編輯等；冗長拖沓的數據組織形