實驗一 軟件需求描述
1.1 系統需求描述
失主：注冊、登錄系統，系統審核信息有效性，有效性是指提供的學號姓名學號聯系方式是否符合規格，審核通過則注冊、登錄成功；進入系統后，失主可以通過拾遺者提供的失物信息表查找，通過描述細化失物的范圍，系統會返回查找到失物會聯系拾遺者領回，查找失敗后會記錄在失物登記表。
拾遺者：注冊、登錄系統，系統審核信息有效性，有效性是指拾遺者提供的姓名學號聯系方式等是否正確符合規格。審核通過則注冊、登錄成功；進入系統后，拾遺者上傳提供失物的信息，系統審查信息的有效性，有效性是指撿到的失物是否符合基本的失物特征，保證不能出現除了失物以外的其他信息，審查成功后失物信息將發布到失物信息表上，系統對拾遺者發布的信息進行分類整理后，返回發布信息成功通知單給拾遺者。
管理員：注冊、登錄系統，系統審核信息有效性，有效性是指管理員提供的姓名聯系方式等是否正確符合規格。審核通過則注冊、登錄成功；進入系統后，管理員可以修改失主和拾遺者的信息。
失物招領管理系統：具有三個功能分區，分別是：用戶管理、失物查詢、失物發布；用戶管理功能實現每一位使用系統的用戶都需要先注冊、登錄再進入系統；其次提供了管理員可以修改用戶信息的功能。失物查詢功能實現了失主查詢失物的功能，並且可以實現審查信息的有效性並提供找回失物的方式。失物發布功能實現了發布失物信息並且審查拾遺者發布信息的有效性。
1.2 系統相關者
失主、拾遺者、管理員
1.3 數據流分析
（1） 頂層DF
失物招領頂層數據流圖如圖1.1所示。
圖1.1 失物招領系統頂層DFD
（2） 功能層DFD如圖1.2所示。
圖1.2 功能層DFD
（3） 細節層DFD失物查詢層的DFD分解層如圖1.3所示。
圖1.3 失物查詢層DFD分解
（4） 失物發布層的DFD分解層如圖1.4所示。
圖1.4 失物發布層DFD分解
（5）用戶管理層的DFD分解層如圖1.5所示。
圖1.5 用戶管理層DFD分解
1.4 數據字典
（1） 數據項定義
賬號的數據項定義如表1.1所示。
表1.1 數據項“賬號”的條目
| 數據項名：賬號 |
| 別名：登陸賬號 |
| 取值范圍及含義： 00000~99999 按照注冊的順序分發賬號 |
| 備注：每個用戶在登錄系統時應該用賬號登錄 |
密碼的數據項定義如表1.2所示。
表1.2 數據項“密碼”的條目
| 數據項名：密碼 |
| 別名：登錄密碼 |
| 取值范圍及含義： 1 {字符} 20 （數字+字符） |
| 備注：每個用戶的賬號和密碼必須一一對應的用於登錄系統 |
姓名的數據項定義如表1.3所示。
表1.3數據項“姓名”的條目
| 數據項名：姓名 |
| 別名：真實姓名 |
| 取值范圍及含義： 1 {字符} 10 （漢字） |
| 備注：代表的是登錄用戶的真實姓名 |
類型的數據項定義如表1.4所示。
表1.4 數據項“類型”的條目
| 數據項名：類型 |
| 別名：用戶類型 |
| 取值范圍及含義： A B C |
| 備注：A代表的是失主 B代表的是拾遺者 C代表的是管理員 |
聯系方式的數據項定義如表1.5所示。
表1.5 數據項“聯系方式”的條目
| 數據項名：聯系方式 |
| 別名：手機號碼 |
| 取值范圍及含義： 00000000000~9999999999 |
| 備注：代表的是用戶的電話聯系方式，必須是十一位有效的數字 |
地點的數據項定義如表1.6所示。
表1.6 數據項“地點”的條目
| 數據項名：地點 |
| 別名：物品丟失/撿拾地點 |
| 取值范圍及含義： 1 {字符} 20（漢字字符） |
| 備注：代表的是失物的丟失地點或者撿到地點 |
名稱的數據項定義如表1.7所示。
表1.7 數據項“名稱”的條目
| 數據項名：名稱 |
| 別名：失物名稱 |
| 取值范圍及含義： 1 {字符} 10（漢字字符） |
| 備注：代表的是失物的名字 如：耳機、項鏈、手表等等 |
時間的數據項定義如表1.8所示。
表1.8 數據項“時間”的條目
| 數據項名：時間 |
| 別名：丟失時間/撿拾時間 |
| 取值范圍及格式： “00：00”…“23：59” |
| 備注：代表的是失主丟失失物的時間或者拾遺者撿到物品的時間，規定必須用“：”間隔開。 |
細節描述的數據項定義如表1.9所示。
表1.9 數據項“細節描述”的條目
| 數據項名：細節描述 |
| 別名：失物具體細節描述 |
| 取值范圍及含義： 1 {字符} 30（漢字字符） |
| 備注：代表的是失物的具體細節的描述 |
學號的數據項定義如表1.10所示。
表1.10 數據項“學號”的條目
| 數據項名：學號 |
| 別名：失主和拾遺者的學號 |
| 取值范圍及含義： 20000000~25000000 |
| 備注：代表的是學生入學年份和身份標識，一共八位學號，包括入學年份（4位）+學生序號（4位） |
年的數據項定義如表1.11所示。
表1.11 數據項“年”的條目
| 數據項名：年 |
| 別名：年份 |
| 取值范圍及含義： 2000~2500 |
| 備注：代表的是失物丟失的年份 |
月的數據項定義如表1.11所示。
表1.12 數據項“月”的條目
| 數據項名：月 |
| 別名：月份 |
| 取值范圍及含義： 1~12 |
| 備注：代表的是失物丟失的月份 |
日的數據項定義如表1.13所示。
表1.13 數據項“日”的條目
| 數據項名：日 |
| 別名：日期 |
| 取值范圍及含義： 1~31 |
| 備注：代表的是失物丟失的日期 |
昵稱的數據項定義如表1.14所示。
表1.14 數據項“昵稱”的條目
| 數據項名：昵稱 |
| 別名：用戶昵稱 |
| 取值范圍及含義： 1 {字符} 10（漢字字符） |
| 備注：代表的是用戶在系統中的稱呼 |
（2）數據流定義
領回通知單的數據流定義如表2.1所示。
表2.1 數據流“領回通知單”的字典條目
| 數據流名：領回通知單 別名 ： href="https://cn.bing.com/dict/search?q=Claim&FORM=BDVSP6&cc=cn" Claim notification form 數據流的來源：加工1.5領回失物 數據流的去向：拾遺者 數據流組成：名稱+地點+細節描述+昵稱+學號+聯系方式+時間 備注：無 |
用戶信息單的數據流定義如表2.2所示。
表2.2 數據流“用戶信息單”的字典條目
| 數據流名：用戶信息單 別名 ：User information form 數據流的來源：3.3用戶信息管理、3.2用戶信息分類 數據流的去向：管理員 數據流組成：昵稱+學號+聯系方式+賬號+密碼 備注：無 |
發布成功通知單的數據流定義如表1.3所示。
表2.3 數據流“發布成功通知單”的字典條目
| 數據流名：發布成功通知單 別名 ：Publishing href="https://cn.bing.com/dict/search?q=success&FORM=BDVSP6&cc=cn" success notification form 數據流的來源：2.3系統分類管理 數據流的去向：拾遺者 數據流組成：名稱+地點+細節描述+時間 備注：無 |
（3）數據存儲
失物信息表的數據存儲如表1.3所示。
表2.4 數據存儲“失物信息表”的字典條目
| 數據存儲名稱：失物信息表 |
| 編號：F1 |
| 簡述：是經過按拾遺者提供的失物信息統計得到的失物信息表 |
| 流入的數據流：來源於拾遺者填寫提供的失物信息 |
| 流出的數據流：去向是失主查詢失物信息 |
| 數據存儲組成：名稱+地點+細節描述+昵稱+學號+聯系方式+時間 |
| 備注：無 |
失物登記表的數據存儲如表2.5所示。
表2.5 數據存儲“失物登記表”的字典條目
| 數據存儲名稱：失物登記表 |
| 編號：F2 |
| 簡述：是經過按失主查詢的失物信息統計得到的失物登記表 |
| 流入的數據流：來源於 |
| 流出的數據流：去向是 |
| 數據存儲組成：名稱+地點+細節描述+昵稱+學號+聯系方式+時間 |
| 備注：無 |
用戶信息表的數據存儲如表1.3所示。
表2.6 數據存儲“用戶信息表”的字典條目
| 數據存儲名稱：用戶信息表 |
| 編號：F3 |
| 簡述：是經過按用戶填寫的信息整理統計得到的用戶信息表 |
| 流入的數據流：一方面來源於失主和拾遺者用戶信息的結果，另一方面來自於管理員的信息 |
| 流出的數據流：去向是管理員操作和修改用戶信息 |
| 數據存儲組成：昵稱+學號+聯系方式+賬號+密碼 |
| 備注：無 |
1.5 加工邏輯
（1）加工2.1系統審查失物信息的結構化語言如下。
輸入失物信息
按拾遺者提供的失物信息分類
檢索“失物登記表”文件，獲得失物登記的表單
對於輸入的失物信息進行失物匹配
begin
如果 失物登記表有相同的信息
則
失物匹配成功，進而聯系失主領回
否則
失物匹配失敗，發布失物信息到“失物信息表”文件
End
（2）加工3.1用戶登錄決策樹如圖2.1用戶登錄決策樹所示。
圖2.1用戶登錄決策樹
（3）加工1失物查詢功能IPO圖如圖2.2所示。
圖2.2失物查詢功能IPO圖
（4）加工2失物發布功能IPO圖如圖2.3所示。
圖2.3失物查詢功能IPO圖
（5）實體關系圖ER圖如圖2.4所示。
圖2.4 實體關系ER圖
1.6 軟件非功能需求
硬件環境需求：PC端以及客戶端。
軟件環境需求：windows10系統或者Linux系統。
性能需求：目前市面上的主流的中端顯卡例如Geforce 9800 gt，能夠達到低端顯卡也能運行這個系統，目的是服務學生，大部分的學生的個人電腦和學校的台式電腦也基本可以達到這個標准。
安全性需求： 能夠做到對客戶以及系統的個人信息能夠完善保存，系統不易被盜取信息與技術；並且能根據用戶的類別設置訪問權限，並且對用戶的訪問權限或者用戶的信息進行直接操作。
可靠性需求：在發生故障以后的易恢復性，發布新版本以后做到回滾方案，以備異常緊急處理，在系統出錯后做好容錯處理。
易用性需求：系統使用簡單，便於操作，便於學習，並且用戶界面美觀，具有一定觀賞性。
實驗二 軟件結構設計
2.1 軟件結構設計
1. 將功能層數據流圖化分邊界，如圖2.1所示。
圖2.1化分邊界的數據流圖
2.按SD方法將數據流圖轉換為軟件結構圖，如圖2.2所示。
圖2.2 功能層的SC圖
3.失物查詢層的划分邊界的DFD圖，數據流圖為事務型，如圖2.3所示。
圖2.3 化分邊界的失物查詢層DFD
4.根據失物查詢層化分邊界的DFD，畫出的SC圖，如圖2.4所示。
圖2.4 失物查詢層的SC圖
圖2.2與圖2.4其中：
1 OC1為用戶或管理員的操作命令
2 OC2為失主的操作命令
3 D1為尋找失物
4 D2為無效需求單
5 D3為有效需求單
6 D4為需求范圍
7 D5為調用失物信息單查看
8 D6為查詢失敗通知單
9 D7為查詢成功通知單
5.失物發布層的划分邊界的DFD圖，數據流圖為事務型，如圖2.5所示。
圖2.5 化分邊界的失物發布層的DFD
6.根據失物發布層化分邊界的DFD，畫出的SC圖，如圖2.4所示。
圖2.6采購層的SC圖
圖2.6其中：
10 OC3為拾遺者的操作命令
11 D1為失物信息
12 D2為無效信息單
13 D3為審查成功通知單
14 D4為信息匹配失敗通知單
15 D5為信息匹配成功通知單
16 D6為發布信息成功通知單
2.2 詳細設計-程序流程圖
(1) 用戶管理中登錄程序流程圖，如圖2.7。
圖2.7 審查有效性程序流程圖
實驗三 系統用例分析
3.1 系統需求陳述
校園失物招領管理系統。主要負責校園學生尋找和發布失物。
失主：注冊、登錄系統，系統審核信息有效性，有效性是指提供的學號姓名學號聯系方式是否符合規格，審核通過則注冊、登錄成功；進入系統后，失主可以通過拾遺者提供的失物信息表查找，通過描述細化失物的范圍，系統會返回查找到失物會聯系拾遺者領回，查找失敗后會記錄在失物登記表。
拾遺者：注冊、登錄系統，系統審核信息有效性，有效性是指拾遺者提供的姓名學號聯系方式等是否正確符合規格。審核通過則注冊、登錄成功；進入系統后，拾遺者上傳提供失物的信息，系統審查信息的有效性，有效性是指撿到的失物是否符合基本的失物特征，保證不能出現除了失物以外的其他信息，審查成功后失物信息將發布到失物信息表上，系統對拾遺者發布的信息進行分類整理后，返回發布信息成功通知單給拾遺者。
管理員：注冊、登錄系統，系統審核信息有效性，有效性是指管理員提供的姓名聯系方式等是否正確符合規格。審核通過則注冊、登錄成功；進入系統后，管理員可以修改失主和拾遺者的信息。
失物招領管理系統：具有三個功能分區，分別是：用戶管理、失物查詢、失物發布；用戶管理功能實現每一位使用系統的用戶都需要先注冊、登錄再進入系統；其次提供了管理員可以修改用戶信息的功能。失物查詢功能實現了失主查詢失物的功能，並且可以實現審查信息的有效性並提供找回失物的方式。失物發布功能實現了發布失物信息並且審查拾遺者發布信息的有效性。
3.2 功能提取
3.2.1 識別相關者
失主、拾遺者、管理員
3.2.2 建立系統的業務列表
業務列表如表1-1所示。
| 參與者 |
用例 |
說明 |
| 失主（loster） |
瀏覽失物信息 （Browse lost property information） |
失主可以通過直接實時查看失物信息 |
| 發布招領信息 （Release the claim information） |
失主未搜索到失物信息后可以發布失物招領信息 |
|
| 查詢招領信息 （Query found information） |
失主可以通過關鍵字搜索或直接查詢招領信息 |
|
| 在線交流（Online communication） |
失主可以與拾遺者進行在線交流 |
|
| 申請領回（To apply for claim） |
失主找到失物后可以向系統和拾遺者申請領回失物 |
|
| 拾遺者（Gleanings person） |
瀏覽招領信息 （Browse for found information） |
拾遺者可以直接查看實時招領信息 |
| 搜索招領信息 （Search for found information） |
拾遺者可以通過關鍵字搜索招領信息 |
|
| 發布失物信息 （Release lost property information） |
拾遺者撿到失物后可以發布失物信息 |
|
| 在線交流（Online communication） |
拾遺者與失主可以進行在線交流 |
|
| 申請提供（Apply for providing） |
拾遺者提供失物領回申請以便失主可以領回失物 |
|
| 管理員（Administrator） |
用戶權限管理 （User privilege management） |
管理員可以對用戶權限進行修改 |
| 用戶信息管理 （User information management） |
管理員可以對用戶信息進行輸入和修改 |
表1-1 業務列表
3.3 校園失物招領管理系統的包圖
校園失物招領管理系統包圖如圖1-1所示。
包圖說明： 該包圖包括：“用戶界面”、“業務邏輯”、“用戶接口”、“數據庫”四個包以及包間關系。其中用戶界面與邏輯界面存在依賴關系；業務邏輯、用戶接口與數據庫之間存在依賴關系；同時，用戶接口與業務邏輯之間也存在依賴關系。
圖1-1 校園失物招領管理系統包圖
3.4 用例圖建立
校園失物招領管理系統用例圖如圖1-2所示。
圖1-2 系統用例圖
3.5 系統用例說明
系統用例說明如表1-2所示。
| 用例名稱 |
注冊 |
| 用例ID |
UC01 |
| 主要業務參與者 |
用戶（失主 / 拾遺者） |
| 簡要描述 |
用戶輸入自身信息注冊賬號 |
| 基本事件流 |
用戶輸入 用戶名、密碼、學號、手機號等基本信息 |
| 擴展事件流 |
系統將信息添加到用戶信息庫 |
| 用戶場景 |
注冊成功 / 注冊失敗 |
| 關系描述 |
“用戶信息管理”是“注冊”的擴展 |
| 前置條件 |
無 |
| 后置條件 |
無 |
| 異常 |
若輸入不符合條件則顯示注冊失敗 |
| 限制與約束 |
必須填寫完必填項，如用戶名、密碼、學號、手機號等，且同一個用戶名或學號不能同時重復注冊，學號，手機號需要符合格式 |
表1-2 注冊的用例說明
| 用例名稱 |
登錄 |
| 用例ID |
UC02 |
| 主要業務參與者 |
用戶（失主 / 拾遺者） |
| 簡要描述 |
用戶輸入用戶名和密碼登錄賬號 |
| 基本事件流 |
用戶輸入用戶名和密碼進行登錄，若登陸成功則賦予其對應的權限 |
| 擴展事件流 |
密碼輸入錯誤，彈出提示信息再次輸入，重新登錄 |
| 用戶場景 |
登錄成功 / 登錄失敗 |
| 關系描述 |
“登錄”用例包含“用戶權限管理”用例 |
| 前置條件 |
該用戶已經注冊 |
| 后置條件 |
無 |
| 異常 |
若密碼輸入錯誤三次以上，封鎖賬號一段事件，封鎖時間結束后才可以再次登錄賬號 |
| 限制與約束 |
必須輸入正確且匹配的用戶名和密碼 |
表1-3 登錄的用例說明
| 用例名稱 |
瀏覽招領信息 |
| 用例ID |
UC03 |
| 主要業務參與者 |
失主 |
| 簡要描述 |
失主瀏覽多條招領信息的主要信息 |
| 基本事件流 |
失主對多條招領信息進行瀏覽，招領信息按照發布時間排序，最新發布的信息在前 |
| 擴展事件流 |
選擇物品類別（書 / 校園卡 / 身份證 等） |
| 用戶場景 |
瀏覽到目標信息 / 沒有瀏覽到目標信息 |
| 關系描述 |
“申請領回”是“瀏覽招領信息”的擴展 |
| 前置條件 |
無 |
| 后置條件 |
無 |
| 異常 |
無 |
| 限制與約束 |
無 |
表1-4 瀏覽招領信息的用例說明
| 用例名稱 |
申請領回 |
| 用例ID |
UC04 |
| 主要業務參與者 |
失主 |
| 簡要描述 |
失主看到目標招領信息后，申請領會此信息中的物品 |
| 基本事件流 |
失主點擊“申請領回”按鈕后，回答拾遺者設置的驗證問題，若全部回答正確，則將獲得在線交流的權限，招領信息狀態為申請中狀態 |
| 擴展事件流 |
無 |
| 用戶場景 |
獲得在線交流的權限 / 未獲得在線交流的權限 |
| 關系描述 |
“申請領回”是“瀏覽招領信息”的擴展 |
| 前置條件 |
該用戶已經登陸 |
| 后置條件 |
無 |
| 異常 |
無 |
| 限制與約束 |
無 |
表1-5 申請領回失物的用例說明
| 用例名稱 |
搜索招領信息 |
| 用例ID |
UC05 |
| 主要業務參與者 |
拾遺者 |
| 簡要描述 |
失主輸入關鍵詞搜索相關招領信息 |
| 基本事件流 |
失主輸入關鍵詞搜索相關招領信息，搜索結果按符合關鍵詞數量排列，符合更多關鍵詞的信息在前，相同數量是按發布時間排序 |
| 擴展事件流 |
無 |
| 用戶場景 |
搜索到目標信息 / 未搜索到目標信息 |
| 關系描述 |
“選擇分類”是“搜索招領信息”的擴展 |
| 前置條件 |
無 |
| 后置條件 |
無 |
| 異常 |
無 |
| 限制與約束 |
至少需要輸入一個關鍵字 |
表1-6 搜索招領信息的用例說明
| 用例名稱 |
在線交流 |
| 用例ID |
UC06 |
| 主要業務參與者 |
用戶（失主 / 拾遺者） |
| 簡要描述 |
失主和拾遺者在線交流 |
| 基本事件流 |
失主和拾遺者在線交流並確認失物情況 |
| 擴展事件流 |
無 |
| 用戶場景 |
失主和拾遺者確認失物情況 |
| 關系描述 |
無 |
| 前置條件 |
該用戶已經登錄 並且對於失主 回答正確拾遺者提出的相關問題 |
| 后置條件 |
無 |
| 異常 |
無 |
| 限制與約束 |
交流中系統若檢測到不良信息將切斷聯系並警告雙方 |
表1-7 在線交流的用例說明
3.6 建立順序圖
校園失物招領管理系統管理員管理用戶信息順序圖如圖1-3所示。
圖1-3 管理員管理用戶信息順序圖
3.7 建立類圖
校園失物招領管理類圖如圖1-4所示。
圖1-4 校園失物招領管理系統類圖
3.8 建立用例活動圖
校園失物招領管理系統失主尋找失物用例活動圖如圖1-5所示。
圖1-5 尋找失物用例活動圖