基於UML的畢業設計管理系統的分析與設計

基於UML的畢業設計管理系統的分析與設計

      <本段與標題無關，自行略過 最近各類忙，天氣不錯，導師心情不錯：「咱們要寫一個關於UML的專著」，一句話：「一個完整的系統貫穿整個UML的知識」；我：「--o---k--」。忙裏偷閒，先回顧一下吧>

      畢業設計是實現本科教學培養目標的重要環節，從選題到答辯通常須要四至六個月的時間，其間工做量很大，尤爲須要保留大量的文件，以便於管理者對畢業設計工做進行監督。傳統的、人工的方式管理各項事務和文件檔案，存在着諸如效率低、準確性差等缺點，對高效、合理地安排畢業設計很不方便。
      利用計算機和WWW網絡技術實現高校畢業設計的管理勢在必行，製做畢業設計期間的教學管理、頻繁的師生交流，以及大篇幅的論文管理，如今只要經過計算機就能夠方便快捷的來完成。所以畢業設計管理系統的應用可以爲用戶提供充足的信息和快捷的查詢手段。
      經過互聯網和校園網進行各學院畢業設計選題、中期、答辯和後期的流程管理。各階段都要教務長來開通和關閉，對整個畢業設計的流程進行管理。其中系統的用戶信息來自於現教務管理系統。

一.畢業設計管理系統的整體需求

1.整體業務流程 
      畢業設計的管理流程劃分爲四個基本步驟，見圖1-1。

圖1-1 畢業設計管理流程

2.系統功能框圖
      系統整體功能框圖見圖1-2。系統按照工做流程劃分出四個主要功能模塊，另外該系統還應提供登陸功能模塊和系統維護功能模塊,其中系統維護模塊包括身份管理、數據維護和流程管理三個子模塊。每一個模塊完成的功能見表1-1。

圖1-2 系統整體功能框圖

3.整體功能分類描述
系統整體功能分類描述見表1-1

表1-1 整體功能分類

功能類別/標識符	目標描述
選題管理	完成教師立題、學生選題的雙向選擇過程。最終達到每人一題。
進行過程管理	完成教師與學生交流、中期檢查、教師與學生互評過程。
答辯管理	完成答辯準備工做，提交答辯結果。
後期處理	完成收集、上報材料，統計成績，評優過程。
登陸管理	提供用戶登陸驗證及用戶權限查詢的功能。
系統維護	系統維護包括：身份管理、流程管理和數據維護三個子功能塊。

二.創建用例模型

1.建模思想
      用例是對一個活動者(actor)使用系統的一項功能時所進行的交互過程的一個文字描述序列。用例是表明系統中各個項目相關人員之間就係統的行爲所達成的契約。軟件的開發
      過程能夠分爲需求分析、設計、實現、測試等階段，用例把全部這些都捆綁在一塊兒，用例分析的結果也爲預測系統的開發時間和預算提供依據，保證項目的順利進行。所以能夠，軟件開發過程是用例驅動的。

 用例分析的步驟能夠按下面的順序進行：
(1) 找出系統外部的參與者和外部系統，肯定系統的邊界和範圍。
(2) 肯定每個參與者所指望的系統行爲。
(3) 把這些系統行爲命名爲用例。
(4) 使用泛化、包含、擴展等關係處理系統行爲的公共或變動部分
(5) 編制每個用例的腳本。
(6) 繪製用例圖。
(7) 區分主事件流和異常狀況的事件流，若是須要能夠把表示異常狀況的事件流做爲單獨的用例處理。
(8) 細化用例圖，解決用例間的重複與衝突問題。

      採用用例分析法捕獲用戶的需求，其中一個比較困難的工做是肯定系統應該包含哪些用例，以及如何有效地發現這些用例。事實上，在作用例分析時，並無一個固定的方式或方法來發現用例，並且對同一個系統，每每會同時存在多種解決方案，但其中某些方案會比另外一些方案好。與設計和實現階段相比，需求分析階段更多的仍是依賴於分析人員的我的經驗和領域知識。

2.用例模型
2.一、用例定義

      用例經過某種途徑與系統交互。從系統外部執行者的角度來描述系統須要提供哪些功能,並指明這些功能的執行者(用例)是誰。確保全部角色都被徹底識別出來。

      本系統用戶羣分爲四大類:教務管理員、畢業設計專家組、教師和學生。各種用戶用不一樣的職責和權限。本系統的用例於表2-1中。

表2-1 系統的用例定義

用例名稱	用力職能
教務管理員	完成擬題和選題公告、論文選題管理、優秀論文展現、手動操做選題、發佈選題、分配答辯教師、管理答辯小組、論文推優、工做總結、處理論文材料、留言刪除等相關管理功能
畢業設計專家組	審覈論文題目、審覈論文、參與答辯等
教師	參與擬題，指導學生、評審論文等相關功能
學生	參與選題、提交論文、進行答辯等功能
系統維護員	主要負責系統維護、系統公告、用戶添加、數據維護等

2.二、系統頂層例圖

      用例是參與者與系統的交互過程,表明系統爲其參與者所執行的有價值的操做,表達了系統的功能需求和行爲。用例的用途是在不揭示系統內部構造的狀況下定義連貫的行爲。用例能夠在執行過程當中持續接受參與者的輸入信息,能夠描述系統向用戶提供的有價值的功能。
      用例不只是描述需求的工具,還能夠驅動開發過程,經過對用例的建立、整合,開發設計人員能夠構建一系列實現這些用例的設計和實現模型。系統頂層用例的構建,可使得系統總體性的呈現並被建模人員把握。經過前述需求分析的結果,能夠得出頂層用例,其中涉及的參與者及其活動系統頂層用例圖如圖2-1所示:

圖2-1：系統頂層用例圖

2.三、用例的細化（主要模塊的用例）
      每個用例都是一個參與者與系統在交互中執行的有關事務序列。從畢業論文指導交互系統的用例抽象,能夠肯定以下的主要模塊的用例: 畢設選題管理、畢設進行過程管理、畢設答辯管理、畢設後期處理等。

      從系統總的用例來創建用例圖,這樣設計在項目開始階段對理解系統的要求和目標都有好處,但須要進一步細化,劃分爲更具體的一些用例,以便深刻分析系統的要求和目標。

1）畢設選題管理
      畢業設計選題管理中中的參與者包括教務、畢業設計專家、教師和學生。教務發佈擬題要求、管理雙向選題、發佈題目和公佈選題結果；專家組對論文題目進行評審，並給出意見；教師根據擬題要求擬題和提交題目的任務說明，並經過學生的選題狀況選擇學生；學生根據選題要求選擇論文題目等。選題管理用例圖如圖2-2所示：

圖 2-2 選題管理用例圖

      畢業設計選題部分各子功能描述見表2-2。

表2-2 選題管理功能及用例描述

名稱、標識符	執行用例	描述
發佈擬題要求	教務管理	根據畢業學生和學院要求發佈本屆畢業設計信息和擬題要求： ▪畢業班級、專業、人數； ▪畢業設計日程安排； ▪各環節的表格；
確立題目	教師 教務管理	①指導教師根據擬題要求擬題並提交： 要求：不與他人重題；不與上屆重題；不是網上抄襲； 題目：名稱；實現功能；技術要求； ②專家組評審：畢業設計專家組對指導教師提交的題目進行評審，如不合格提出修改意見反饋給教師，指導教師從新擬題並提交； ③發佈題目：教務人員對專家組提交的合格畢業設計題目進行發佈。
雙向選題	學生 教師 教務管理	①學生初選題目：學生對發佈的論文題目進行初選，每人最多選擇三個設計題目，每一個設計題目可被三個學生備選； ②指導教師選擇學生：指導教師能夠查閱本身題目的初選結果，並初選學生一名。 ③初選結果調整：教務人員關閉雙向選題，對沒被選擇的題目和沒被選擇的學生手工進行調整， 最終肯定導師和學生。
發佈選題結果	教務管理	發佈最終選題結果。此後學生和教師均可查詢到選題結果。

2）畢設進行過程管理
      畢設進行過程管理中的參與者包括教務、畢業設計專家、教師和學生。教務開通指導園地，進行開題管理，教務存檔中期報告等活動；畢業設計專家組對學生提交的開題報告進行評審，如不合格提出修改意見反饋給學生，學生重寫開題報告並提交；指導教師收取中期報告並送審中期報告；學生與老師經過一下外部接口通訊，學生提交開題報告和中期報告。畢業設計進行過程管理用例圖如圖2-3所示：

圖 2-3 畢業設計進行過程管理用例圖

      畢業設計進行過程管理部分各子功能描述見表2-3。

表2-3 進行過程管理功能及用例描述

名稱、標識符	執行用例	描述
指導園地	學生 教師 教務管理	教務人員開通指導園地，學生與老師經過一下外部接口通訊：（目前只設計提交通訊方式功能，帶之後完善與外部系統的接口通訊。） ▪畢設論壇 ▪電子郵件 ▪QQ羣
開題管理	學生 教師 教務管理	①學生提交開題報告。 ②教務下載全部開題報告，並分派給各專家組審閱。 ③專家組評審：畢業設計專家組對學生提交的開題報告進行評審，如不合格提出修改意見反饋給學生，學生重寫開題報告並提交； ④教務存檔開題報告：教務人員上傳開題報告到中期過程數據庫。 ⑤教務關閉開題：關閉開題，同時開通中期檢查。
中期檢查	學生 教師 教務管理	①學生提交中期報告。 ②指導教師收取中期報告：指導教師能夠離線審閱中期報告； ③指導教師送審中期報告 ④教務存檔中期報告：教務人員上傳中期報告到中期過程數據庫。 ⑤教務關閉中期檢查。

3）畢設答辯管理

      畢設答辯管理中的參與者包括教務、畢業設計專家、教師和學生。其中教務教務人員安排答辯同時開通論文評審並分配評審論文，教務存檔評審結果等；專家組對學生進行答辯並提交答辯記錄和成績評定；教師指導審查論文初稿並提出修改意見，學生依此修改並再次提交；學生修稿、提交論文，參加答辯，上傳材料等。畢設答辯管理用例圖2-4所示：

圖2-4 畢設答辯管理用例圖

      畢業設計答辯管理部分各子功能描述見表2-4。

表2-4 答辯管理功能及用例描述

名稱、標識符	執行用例	描述
前期準備	教師 教務管理	①交收論文初稿：學生上交初稿，教師審查並提出修改意見，學生依此修改並再次提交。 ②答辯申請：進過教師贊成後，學生能夠提出答辯申請。 ③教務人員安排答辯，同時開通論文評審。
論文評閱	學生 教師 教務管理	①指導教師評審：指導教師對本身學生評審並提交評審意見。 ②教務分配評審論文：分配結果要求，審閱該論文的教師不應論文的指導教師。 ③審閱教師評審：審閱教師對該學生評審並提交評審意見。 ④教務存檔評審結果：教務人員上傳、瀏覽評審結果。 ⑤教務關閉論文評審：關閉論文評審，同時開通答辯過程。
答辯過程	學生 教師 教務管理	①學生答辯：專家組提交答辯記錄和成績評定。 ②教務關閉答辯過程。

4）畢設後期處理

畢設答辯管理中的參與者包括教務、教師和學生。教務統計分析成績、發佈成績，教務歸檔論文，評審優秀教師、學生等；學生申請優秀論文；指導教師申請優秀指導。畢設後期處理用例圖如圖2-5所示：

圖2-5 畢設後期處理用例圖

      畢業設計後期處理部分各子功能描述見表2-5。

表2-5 後期處理功能及用例描述

名稱、標識符	執行用例	描述
成績管理	教務管理	①教務統計分析成績： ▪按教師指導學生論文成績平均分統計。 ▪按教師指導學生數統計。 ▪按學生成績統計。 ②教務人員發佈成績。
論文歸檔	學生 教師 教務管理	①教務歸檔論文:教務將論文入庫，教務、教師與學生可瀏覽。 ②教務提交、瀏覽輔助材料。 ③教務文檔備份清理。
評優管理	學生 教師 教務管理	①學生申請優秀論文：學生提交評優申請。 ②指導教師申請優秀指導：教師提交評優申請。 ③教務評審優秀教師、學生。

5）登陸管理

      登陸管理中的參與者包括教務、畢業設計專家、教師和學生。畢業設計登陸管理是全部合法用戶進入系統的惟一路徑。畢業設計登陸管理根據用戶的不一樣類型提供不一樣的功能服務。其中教務長與數據維護人員可進入系統的維護平臺進行操做。普通用戶只進入工做流程平臺。登陸管理用例圖如圖2-6所示：

圖2-6 登陸管理用例圖

      畢業設計登陸管理部分各子功能描述見表2-6。

表2-6 登陸管理功能及用例描述

名稱、標識符	執行用例	描述
登陸管理	教務管理 專家 教師 學生	①數據維護人員和教務長登陸時，便可登陸到系統維護平臺也可登陸到工做流程平臺。 ②教師、學生和普通教務登陸後，進入工做流程平臺。系統依據用戶類別不一樣，提供的功能頁面也不一樣。

6）系統維護

      系統維護中的參與者包括教務長和系統數據維護員。系統維護模塊分爲三個子模塊：①身份管理；②流程管理；③數據維護。身份管理又分爲用戶管理和角色管理。數據維護分爲用戶信息導入導出和備份清理畢設文檔。系統維護用例圖如圖所圖2-7和2-8所示：

2-7 系統維護（數據維護人員）用例圖

 

2-8 系統維護（教務長）用例圖

      畢業設計管理中系統維護部分各子功能描述見表2-7。

表2-7 系統維護功能及用例描述

名稱、標識符	執行用例	描述
身份管理	教務長	①教務長登陸後，能夠對用戶進行增、刪、改、查操做。 ②教務長登陸後，可爲用戶受權。無受權用戶不能進入畢業設計管理系統。 ③教務長登陸後，能夠對角色進行增、刪、改、查操做。
流程管理	教務長	教務長登陸後，可對畢業設計工做流程進行全程的管理。流程管理的功能包括： ①開通選題管理 ②關閉選題管理 ③開通進行過程管理 ④關閉進行過程管理 ⑤開通答辯管理 ⑥關閉答辯管理 ⑦開通後期處理 ⑧關閉後期處理。
數據維護	數據維護人員 教務長	①數據維護人員登陸後，可導入導出用戶信息。導入導出用戶信息是數據庫文件形式。 ▪導入用戶信息包括：     導入學生信息；     導入教師信息。 ▪導出用戶信息包括：     導出學生信息；     導出教師信息。 注：導出用戶信息功能是爲之後其餘系統的信息導入設計的。 ②教務長登陸後，可備份清除畢業設計文檔,三年以上的畢設文檔備份、清除。

3.總結

      用例模型基本實現了全部的需求，並增長了部分需求，如在選題時，學生可能會根據興趣及教師的研究方向進行選題，因此增長了教師信息、學生信息等；增長了相互留言功能。
      下面的這些啓發性原則能夠幫助分析人員發現用例：和用戶交互。尋找用例的一個途徑就是和系統的潛在用戶會面、交談。可能不一樣的用戶對系統的描述會是徹底不一樣的，即便是同一個用戶，他對系統的描述也多是模糊的、不一致的，這時就須要分析員作出判斷和抉擇。把本身看成參與者，與設想中的系統進行交互。 肯定用例和肯定參與者不能截然分開。

     一些原則來幫助發現用例，如經過回答下列問題來幫助發現用例：
    ． 參與者的主要任務是什麼？
    ．參與考須要瞭解系統的什麼信息，須要修改系統的什麼信息？
    ．參與者是否須要把系統外部的變化通知系統?？
    ．參與者是否但願系統把異常狀況的變化通知本身？

      隨着經驗的不斷積累，對於如何尋找用例會逐漸造成本身的也能夠經過與其餘人的交流來提升本身的分析水平。

三.創建領域模型

1.建模思路
      概念模型是從用例模型映射到類的第一步。概念模型是將用例模型向計算機表示的進一步過渡。概念模型就是劃分類的結果。主要表達用類圖，輔以順序圖。類圖建模是UML靜態建模機制中的一個重點,信息結構和系統行爲均需藉助它來描述。類圖建立工做主要包括建立類、標識類之間的結構關係。
      首先肯定類,其次再肯定其屬性和操做;最後將類與類之間的關聯、依賴、繼承、聚合關係在圖中標示出來,就獲得類圖。
      在尋找類時,能夠根據功能把類分紅三種類型:實體類、邊界類和控制類。邊界類位於系統與外界的交接處,包括全部窗體、報表、打印機等硬件接口以及其餘系統的接口,邊界類使角色能與系統交互,而每一個角色要使用用例與系統交互至少要有一個邊界類。實體類保存要放進永久存儲體的信息,在系統運行時,實體類在內存中保存信息。控制類負責協調其餘類的工做。實體對象類表示系統中的信息存儲,它們通常用於表示系統所管理的核心概念。實體對象是被動和永久性的。它們的主要職責是存儲和管理系統中的信息。
2.領域模型
      根據建模思想對每一個用例分別能夠找出三種類：邊界類、邏輯類和實體類；將全部找到的三種類集中綜合在一塊兒獲得三大模型：視圖模型、邏輯模型和實體模型。
      原始類的劃分可採用表格表示三大模型，根據要求再進一步細化。
      根據《畢業設計管理系統需求描述》的選題過程能夠獲得三大模型以下：

表3-1 畢業設計管理管理系統劃分出的視圖模型（邊界類）

用例	邊界類	說明
登陸	LoginForm	爲用戶提供登陸界面，不一樣用戶進入不一樣的界面
發佈信息	PublishInfoForm	教務發佈擬題要求、論文題目、最終選題結果等的發佈界面
雙向選題工程管理	TopicseletionForm	教務開啓和關閉雙向選題工程的界面
手工調整選題	AdjustForm	教務調整雙向選題的界面
更新教師信息	UpdateTeacherForm	教師更新信息的界面
查看擬題要求	DemandForm	教師查看擬題要求界面，重要的一個過程
查詢題目選情和選擇學生	TeaselectionForm	教師查詢本身題目的選擇狀況和選擇學生界面
處理論文題目	ManageTopicsForm	教師提交論文題目、修改論文題目的界面
更新學生信息	UpdateStudentForm	學生更新信息的界面
學生選題	StuselectionForm	學生查看選題指南、查詢題目、選擇題目等的選題界面，進入界面會首先顯示選題指南
文件管理	File	上傳和下載文件的界面
評審題目	ReviewTopicsForm	畢業設計專家在線審覈論文題目的界面

 

表3-2 畢業設計管理管理系統劃分出的邏輯模型（邏輯類）

用例	邏輯類	說明
登陸	Login_Operation	經過Login爲用戶提供身份驗證，驗證成功才能進入系統
發佈信息	PublishInfo_Operation	教務發佈管理，經過Administrator，當發佈題目時更新Topics一條記錄等
雙向選題工程管理	Topicseletion_Operation	教務開啓和關閉雙向選題工程，關閉實質是將選題功能屏蔽掉
手工調整選題	Adjust_Operation	教務調整雙向選題，經過調用RegisterTopics修改選題狀況
更新教師信息	UpdateTeacher_Operation	教師信息更新，經過Teacher的TUpdateInfo邏輯修改我的信息
查看擬題要求	Demand_Operation	教師調用teacher類的ViewDmand查看擬題要求
查詢題目選情和選擇學生	Teaselection_Operation	教師經過QuerySelected查詢本身題目被選狀況，經過SelecteStudent邏輯選擇學生
處理論文題目	ManageTopics_Operation	教師經過teacher處理題目
更新學生信息	UpdateStudent_Operation	學生經過Student類SUpdateInfo操做更新信息
學生選題	Stuselection_Operation	學生選題邏輯，經過實體類Student，選擇題目SelecteTopics向選題註冊表單插入一條記錄，ModifyTopics更新選題註冊表單等
文件管理	File_Operation	上傳和下載文件
評審題目	ReviewTopics_Operation	畢業設計專家在線審覈論文題目，經過點擊經過按鈕，觸發Topics類加入一條題目，不經過點擊留言給教師
留言	Message_Operation	處理用戶之間留言邏輯類

 

表3-3 畢業設計管理管理系統劃分出的實體模型（實體類）

用例	實體類	說明
登陸類	Login	用戶身份，用戶的學號、工號，用戶的姓名、密碼等信息
學生類	Student	學生信息，學號、姓名、聯繫方式、班級等信息
教師類	Teacher	教師信息，工號、姓名、職稱、我的簡介等信息
畢設專家組類	Expert	專家信息，記錄工號、專家簡介等信息
教務類	Administrator	教務信息，教務的工號、教務的級別、教務的信息
畢設題目類	Topics	畢業設計題目，包含題目名稱、所屬專業、指導教師、任務說明等信息
題目登記類	RegisterTopics	題目登記，記錄每一次學生選擇論問題或教師選擇題目的信息，並寫入數據庫

      經過以上面向對象分析方法能夠獲得系統中完成選題功能的領域模型（初始類圖）如圖3-1所示：

圖3-1 選題功能的初始類圖

      附：視圖類、邏輯類和實體類表中的函數參看下圖

圖3-2 選題功能的初始類圖（Eglish）

3.總結
      本實驗很好的實現了領域模型和系統邏輯處理的對應，從而獲得了邊界類、邏輯類和實體類。找邊界類時，注意邊界類位於系統與外界的交接處；邏輯類主要是操做類；實體對象類表示系統中的信息存儲,通常會有對應的表單。
      類找到後，要用rose進行建模。UML中的類圖具備充分強大的表達能力和豐富的語義，是建模時很是重要的一個圖。

1．類之間能夠有關聯、彙集、組合、泛化、依賴等關係。
2．關聯是類圖中比較重要的一個概念，一些相關的概念有關聯名、關聯角色、關聯類、關聯上的角色、限定關聯、自返關聯、二元關聯、N元關聯等。
3．關聯類是用於描述關聯自己的特性。
4．帶有限定符的關聯稱爲限定關聯，限定符的做用就是在給定關聯一端的定符值之後，可肯定另外一端的一個對象或對象集。
5．派生屬性和派生關聯是指能夠從其餘屬性和關聯計算推演獲得的屆性和關聯，在生成代碼時，派生屬性和派生關聯不產生相應的代碼。
6．抽象類和接口爲oo設計提供了抽象機制。
7．版型是UMI‘相F常重要的一種擴展機制，uML之因此有強大並且靈活的表示能力，與版型這種擴展機制有很大的關係。
8．邊界類、控制類和實體類是對類的一種劃分，它們都是類的版型。

四.創建數據模型

1.建模思路
      邏輯結構設計階段的任務就是將概念結構設計階段完成的概念模型轉化成能被特定數據庫管理系統支持的數據模型,也便是關係模型。這些模型在功能、性能、完整性和一致性約束及數據庫可擴充性都須要知足用戶需求。
      首先根據前面的實驗，實體-聯繫圖提供了表示實體型、屬性和聯繫的方法,可用來描述現實世界的概念模型。對畢業設計管理系統的實體關係(E-R)分析是創建在UML系統模型基礎上的。E-R分析的目的是肯定系統中全部實體之間的關係和實體的屬性,畫出E-R圖,爲數據庫建模打下基礎。畫E-R圖一般使用自底向下的設計方法,首先對局部視圖進行分析設計,而後再實現視圖集成。畫E-R圖以下：

圖4-1 畢設選題管理E-R圖

 

圖4-2 畢設進行過程管理E-R圖

圖4-3 畢設答辯及後期管理E-R圖

2.實體類關係模型
      由系統的實體類能夠設計表以下：
      DBMS：SQL server 2008 R2
      數據庫名稱：graduation_project_management

表4-1 專家信息表

字段	數據類型	是否容許空	備註	註釋
expert_id	char(15)	否	主鍵	專家的工號
expert_name	char(10)	否		專家的姓名
expert_password	char(15)	否		專家的登陸密碼
expert_introduction	nvarchar(MAX)	否		專家的我的信息，爲大值數據類型最多能夠存儲2^30-1個字節的數據，大數據類型可檢索
user_type	int	否	user_type=0	user_type=0，身份爲專家，登錄後進入專家頁面

表4-2 教務員信息表

字段	數據類型	是否容許空	備註	註釋
admin_id	char(15)	否	主鍵	教務員的工號
admin_name	char(10)	否		教務員的姓名
admin_ password	char(15)	否		教務員的登陸密碼
admin_ introduction	nvarchar(MAX)	是		教務員的我的信息
user_type	int	否	user_type=1或user_type=2	user_type=1爲普通教務員， user_type=2爲教務長

表4-3 學生信息表

字段	數據類型	是否容許空	備註	註釋
stu_id	char(15)	否	主鍵	學生的學號
stu_ name	char(10)	否		學生的姓名
stu_password	char(15)	否		密碼，默認爲學號後6位
stu_ sex	char(2)	否		學生性別
stu_ department	char(20)	否		學生系別
stu_ class	char(10)	否		學生班級
stu_ introduction	nvarchar(MAX)	否		學生我的簡介
stu_tel	char(11)	否		學生聯繫方式
user_type	int	否	user_type=3	user_type=3表明學生

表4-4 教師信息表

字段	數據類型	是否容許空	備註	註釋
tea_id	char(15)	否	主鍵	教師的工號
tea_ name	char(10)	否		教師的姓名
tea_password	char(15)	否		密碼，默認爲工號後6位
tea_ sex	char(2)	否		教師的性別
tea_title	char(10)	否		教師的職稱
tea_ introduction	nvarchar(MAX)	否		教師我的簡介
tea_tel	char(11)	否		教師聯繫方式
user_type	int	否	user_type=4	user_type=4表明教師

表4-5 論文題目信息表

字段	數據類型	是否容許空	備註	註釋
topic_ id	char(20)	否	主鍵	論文題目的編號，教師擬題會上傳至此表，不符合題目可被修改或刪除
topic_ name	char(10)	否		題目的名稱
tea_id	char(15)	否	外鍵	命題教師的工號
topic_note	nvarchar(MAX)	否		題目任務說明

表4-6 選題註冊信息表

字段	數據類型	是否容許空	備註	註釋
choice_ id	char(15)	否	主鍵	每一個學生選擇3個題目後選題註冊信息表會增長3個choice_ id記錄，當教師選中學生後，其餘的記錄會被刪除，這樣論文就被選定了
topic_ id	char(15)	否	外鍵	論文題目的編號
tea_id	char(15)	否		教師的工號
stu_id	char(15)	否		學生的學號

表4-7 文件管理表

字段	數據類型	是否容許空	備註	註釋
file_id	Int(50)	否	主鍵，自增加	文件的編號
use_id	char(15)	否		用戶的編號，能夠是工號或學號
file_name	char(30)	否		文件的名字
file_discription	nvarchar(MAX)	是		文件的描述
file_type	int	否		文件的類型， 0示開題報告， 1示論文初稿， 2示論文終稿， 3示論文題目， 4.表示最終選題結果 5表示論文成績 6論文進度 7擬題要求 8選題要求
file_path	nvarchar(MAX)	否		文件的路徑
up_time	datetime	否		文件上傳的時間
download_time	datetime	否		文件下載的時間

表4-8 論文成績表

字段	數據類型	是否容許空	備註	註釋
topic_ id	char(15)	否	主鍵	論文題目
stu_id	char(15)	否		論文對應的學生學號
all_grade	nvarchar(MAX)	否		答辯的各項成績，以「,」隔開
result	char(10)	否		答辯總成績
apprise	char(10)	否		是否爲優秀論文

表4-9 留言信息表

字段	數據類型	是否容許空	備註	註釋
messgae_id	Int(50)	否	主鍵,自增加	留言信息的編號
messgae_title	char(50)	否		留言信息的標題
messgae_content	nvarchar(MAX)	否		留言信息的內容
messgae_from	char(15)	否		發送留言者的工號或學號，須要表的鏈接顯示姓名
messgae_to	char(15)	否		接受留言者的工號或學號，須要表的鏈接顯示姓名
messgae_time	datetime	否		留言發送的時間
is_viewed	int	否		標示位， 0表示留言已被查看 1表示未被查看

表4-10 權限管理表

字段	數據類型	是否容許空	備註	註釋
poedorm_id	int(50)	否	主鍵,自增加	權限的編號
poedorm_name	char(15)	否		權限的名字
poedorm_state	int	否		權限的狀態，0爲禁用，1爲啓用
poedorm_description	nvarchar(MAX)	否		權限的說明
poedorm_date	datetime	否		權限添加的時間

      在rose中進行數據建模，模型中只給出了關鍵字字段和索引項，各表的所有字段請參考以上10個表。創建關係模型以下：

圖4-4 畢設選題關係模型

圖4-5 畢設答辯及後期處理關係模型

3.總結
      本實驗實現了數據模型和系統處理數據的對照。首先應該畫出E_R圖，根據E-R圖及前面的實驗設計出系統的表，進而用rose畫出相應的數據模型。
      在rose中數據建模時必定要先在組件圖上創建Database，再在邏輯視圖中創建Schemas，而後在Schemas創建Data Model Diagram,最後雙擊在Data Model Diagram畫表和創建表的關係。

五.進行Web建模

1.建模思路

      Web建模主要考慮兩方面的問題，一是如何表示Web應用系統的體系結構，另外一個是如何表示Web應用系統中一些特有的概念。
      用UML對Web系統建模影響比較大的一種版型擴展方法稱爲WAE（Web Application Extension，Jim Conallen提出），已被多個UML建模工具採用。WAE定義了一些常見Web系統的建模元素，能夠用這些版型對Web建模，而且Rose提供了Web系統的逆向工程。

   Web建模的基本問題 ：

（1）Web應用系統採用的HTTP協議是一種客戶、服務器間無狀態、無鏈接協議，所以頁面之間傳遞的信息須要使用Session或cookie對象來保存；

（2）Web的客戶端多樣化（不一樣瀏覽器、不一樣操做系統）；

（3）Web系統有特有的概念和元素：HTML、表單Form、網頁框架Frameset，Jsp，Servlet等；

（4）Web應用系統的設計模式經常使用MVC模式。

 

      MVC模式的思想：表示信息結構的數據是相對穩定的，而對數據的操做和表示是可變部分、常變部分。該模式支持軟件可重用性。如圖5-1：

 

圖5-1 MVC模式

 

用Rose建模的主要過程以下（全部操做都應在Web Modeler 選項下進行）：

① Tools→Option→Notation中設置Web Modeler（能夠根據模型產生jsp文件）；

② 建立虛擬目錄：存放之後建立的全部頁面，在Logical view下 右擊鼠標，選擇Web Modeler→New→Virtual Directory；

③ 建立服務器頁：在虛擬目錄名上右擊，選擇Web Modeler→New→Server page（Rose會同時建立對應服務器頁，客戶端頁面）（Server-client由Server動態產生）；

④ 建立客戶端頁：在虛擬目錄名上右擊，選擇Web Modeler→New→Client Page；

⑤ 建立表單：右擊客戶獨立類的端頁，選擇Web Modeler→New→HTML Form在Title下建立Form表單；

⑥ 在表單中添加各類版型的HTML交互控件元素

⑦ 將Web元素拖入類圖窗口，創建他們之間的關聯關係。

 

2.WEB模型
2.一、首先建立虛擬目錄（virtual directory）：

1) 在Logical View下，選Web Modeler→New→virtual directory
2）選擇platform(平臺語言)爲 jsp
3) 設置URL Name爲：http:/www.zstugpm.com
4）Virtual Directory Name爲：zstugpm
    這時虛擬目錄爲版型爲《Virtual Directory》的包Demo (完成上述設置後，在URL地址爲：http:/www.zstugpm.com的全部web 頁面均放在zstugpm包內。)
5) Physical Location (物理路徑名)可設置爲：D:\code

2.二、WEB建模
      按照實驗要求和前面實驗的基礎，進行登陸建模，學生主頁、教師主頁、教務主頁和專家主頁的建模，學生選題流程建模，教師選題流程建模，教務選題流程建模，專家選題流程建模。
1）登陸WEB建模
      用戶輸入用戶名和密碼，選擇身份（學生，教師，教務，專家），驗證成功進入對應的主頁面。

圖5-2 登陸WEB建模

2）學生主頁WEB建模
      利用rose的拓展機制加入用於Frameset建模的版型。StudentMianPage類表示一個frameset（本身定義的版型）。Index類表示導航區。Content類表示點擊導航區域中的不一樣連接時，不一樣的Web頁面在Content中顯示（教師主頁、教務主頁和專家主頁的建模同窗生主頁的建模相同）。如圖5-3所示：

圖5-3 學生主頁WEB建模

3）學生選題流程建模
      學生先登陸到學生主頁面，可進入關於選題頁面（SelectTopics）和我的信息管理頁面（Infomation）。進入選題頁面，可選擇進入選題頁面和修改選題頁面；進入我的信息頁面課添加或更新我的信息。

圖5-4 學生選題流程建模

4）教師選題流程建模
      登錄後進入教師主頁面，可進入擬題頁面和選擇學生頁面。進入擬題頁面，繼而會顯示擬題的要求，能夠擬新的題目和修改題目；進入選擇學生頁面選擇本身敢興趣的學生。

圖5-5教師選題流程建模

5）教務選題流程建模
      教務登陸到教務主頁面，可進入選題相關的發佈頁面、雙向選題管理頁面、調整選題頁面。發佈信息頁面Publish可連接到發佈擬題和選題要求頁面PublishInfo、發佈論文題目頁面PublishTopics、發佈最終選題結果頁面PublishResult。調整選題頁面，要提交表單到ManageSelectServer服務器頁。管理選題過程有開啓和關閉選題過程的按鈕。

圖5-6教務選題流程建模

6）專家選題流程建模
      登陸後進入專家主頁面，連接進入評審頁面，可進入未評審頁面和編輯已評審頁面。評審條目利用javabean技術創建listing.java從數據庫獲取。添加評價須要提交表單到AddReview服務器頁，修改評價須要提交表單到EditReview服務器頁。:專家選題流程建模如圖5-7：

圖5-7 專家選題流程建模

3.總結
      本實驗實現了實驗要求，使用Rational Rose進行Web建模的方法和步驟。
      在Rose2003下對Web應用系統建模，須要先在Tools Options Notation 標籤中設置Default爲Web Modeler。這時能夠根據模型特色分別生成 .jsp, .asp或.html文件。
      Servlet建模:Servlet是用Java語言編寫在服務器上運行的程序。它接受來自客戶端的請求，並把處理結果返回客戶端。編寫Servlet類一般繼承GenericServlet或HttpServlet類。所以Java中有兩種類型的 Servlet在Rose中分別是用版型《Http_Servlet》或《Generic_Servlet》來表示。 在Rose中,用Tools→Java/J2EE→NewServlet 來建立Servlet類。
      Web建模是UML擴展機制之一（版型）的應用、系統建模時根據須要可再利用該擴展機制建立新版型，知足建模須要。
      建好模型後進行正向工程，產生代碼框架，再進行代碼開發，可減小開發工做量。Web應用模型的類圖各頁面關係清晰，便於分析、修改模型。

附：《基於UML的畢業設計管理的分析與設計》rose源文件。

完

歡迎轉載。轉載請註明轉載字樣，標註原做者和原博文地址。