UML期末大作業(yè)(失物招領系統(tǒng))

1/1UML期末大作業(yè)(失物招領系統(tǒng))

U

M

L

設

計

性

實

驗

報

告

校內(nèi)失物招領系統(tǒng)

學院軟件與通信工程學院

同學姓名劉洋學號0133620專業(yè)軟件工程屆別13級

指導老師廖汗成

二零一五年十二月十五日

名目

1、需求分析(3)

1.1開發(fā)背景及意義(3)

1.2系統(tǒng)功能及目標(3)

2、系統(tǒng)建模(4)

2.1創(chuàng)建系統(tǒng)用例模型(4)

2.1.1確定參加者(4)

2.1.2參加者用例(4)

2.1.3管理員用例圖(7)

2.2創(chuàng)建系統(tǒng)靜態(tài)模型(9)

2.2.1創(chuàng)建系統(tǒng)靜態(tài)模型(9)

2.3創(chuàng)建系統(tǒng)動態(tài)模型(11)

2.3.1創(chuàng)建序列圖(11)

2.3.2創(chuàng)建活動圖(12)

2.3.3創(chuàng)建組件圖(12)

2.3.4創(chuàng)建部署圖(13)

3數(shù)據(jù)庫設計(14)

3.1數(shù)據(jù)庫設計的基本規(guī)范(14)

3.1.1開發(fā)規(guī)范(14)

3.1.2命名規(guī)范(14)

3.2基本表及其說明(14)

3.2.1尋物信息列表(14)

3.2.1.1尋物具體信息(15)

3.2.1.2尋物信息搜尋(15)

3.2.2招領信息列表(15)

3.2.2.1招領具體信息(16)

3.2.2.2尋物信息搜尋(16)

3.2.3個人信息列表(16)

3.2.3.1用戶基本信息(16)

3.2.3.2我發(fā)布過的尋物信息(17)

3.2.3.3我發(fā)布過的招領信息(17)

3.2.3.4我評論過的信息(17)

3.2.3.5我保藏的信息(17)

3.2.4發(fā)布尋物/招領信息(18)

4.后臺管理(18)

4.1權限管理(18)

4.2物品類管理(18)

4.2.1物品所屬類管理(18)

4.2.2物品管理(19)

4.2.3校區(qū)管理(19)

4.2.4擬定初始化物品類管理(19)

4.3訂單管理(20)

4.3.1招領訂單管理(20)

4.3.2尋物訂單管理(21)

5.試驗總結(22)

5.1UML建模總結(22)

5.2數(shù)據(jù)庫設計總結(22)

1、需求分析

1.1開發(fā)背景及意義

現(xiàn)今社會生活中，隨著人們生活需求的日益多元化，人們所持有的物質(zhì)資源也隨之豐富，最直觀的表現(xiàn)就是人們所擁有的物品無論從種類還是數(shù)量上都大幅增加，這就造成了人們對自己全部的物品在看管方面難度的加大，再加之日益加快的生活節(jié)奏，就更導致了人們遺棄、丟失物品的狀況時有發(fā)生。這種現(xiàn)象在面積相對較小，而人口特殊密集的高校校內(nèi)來說更是屢見不鮮。老師和同學們時常丟失個人物品，如書籍、手機、錢包、一卡通等現(xiàn)象時有發(fā)生。經(jīng)過調(diào)查發(fā)覺，失主往往由于不能準時的找回失物而造成很多麻煩和不少的損失（像很多同學由于丟失一卡通而造成了用餐、進入圖書館、借書等很多不便）。另一方面，物品的拾取者也由于沒用取得失主的聯(lián)系方式而不能準時的把拾取物交還到失主手上。而傳統(tǒng)的失物招領服務中心，采納的還是拾取者上交、手工備案、人工查詢的方式。但是隨之物品的增多這種管理方式的工作量不斷加大，這種做法就存在費時費勁、缺乏時效性、不利于調(diào)動拾取者樂觀性等缺點。基于以上分析，我們認為建立一個網(wǎng)上失物招領系統(tǒng)是特別必要的。一方面，一旦網(wǎng)站建立好之后，拾到失物的同學可以在第一時間將失物信息發(fā)布到網(wǎng)上，而不是找張紙寫上“失物招領”四個大字后貼到公告欄。另一方面，有一個系統(tǒng)處理失物信息，就削減了人工處理的工作量。

1.2系統(tǒng)功能及目標

此失物招領系統(tǒng)旨在給拾主一個可信任的軟件發(fā)布拾到的物品，讓失主更簡單地找到丟失的物品，同時不至于消失讓失主冒領、錯領等現(xiàn)象。失主和拾主主要針對注冊過該軟件的全部群體。為完成上述功能，提出以下相應的需求：

1、在數(shù)據(jù)庫中存儲失主發(fā)布的丟失物品信息以及拾主或各個失物招領信任點發(fā)布拾獲物品信息，并便利有效地進行相應的數(shù)據(jù)操作和管理，這其中包括：

*物品信息的錄入、刪除、修改

*物品信息的模糊查詢

*物品信息的多關鍵字檢索

2、能夠?qū)隙〝?shù)量的注冊過的失主信息進行相應的存儲和管理，這其中包括：

*失主信息的錄入、刪除、修改

*失主的統(tǒng)計與查詢

3、能夠?qū)隙〝?shù)量的注冊過的拾主信息進行相應的存儲和管理，這其中包括：

*拾主信息的錄入、刪除、修改

*拾主的統(tǒng)計與查詢

4、能夠?qū)κе髋c拾主發(fā)布的物品信息進行匹配比較，并根據(jù)匹配的從高到低的挨次為失主推舉

5、能夠?qū)π枰慕y(tǒng)計結果供應打印和輸出。

6、為了不消失失主冒領、錯領的現(xiàn)象，以及為了保證拾主信息的保密性平安性，讓拾主供應部分拾獲物品信息，只有當失主全部答對時，才可以得到拾主的信息。

7、能夠保證肯定的平安機制，需要信息管理人員的優(yōu)先級以及數(shù)據(jù)信息授權訪問，防止隨便刪改，同時供應信息備份的服務。

2、系統(tǒng)建模

2.1創(chuàng)建系統(tǒng)用例模型

2.1.1確定參加者

創(chuàng)建系統(tǒng)用例的第一步是確定系統(tǒng)的參加者。失物招領系統(tǒng)的參加者包含以下三種：

(1)用戶：發(fā)布失物或者拾物信息的主體。

(2)系統(tǒng)管理員：負責失物招領系統(tǒng)的操作和后臺維護。

(3)系統(tǒng)數(shù)據(jù)庫：參加系統(tǒng)完成各項功能的整個過程。

2.1.2參加者用例

一般用戶在本系統(tǒng)中能夠發(fā)布失物信息或者拾物信息，發(fā)表評論，修改評論，刪除評論修改個人資料（包括別名，性別，郵箱，手機號碼），修改密碼，將某條尋物信息或拾物信息加入自己保藏。

修改個人信息

圖2-1-2一般用戶用例圖

2.更改聯(lián)系方式用例描述

3.拾物或者拾物信息發(fā)布

5.發(fā)表評論用例描述

2.1.3管理員用例圖

管理員可以將用戶設為管理員，對已發(fā)布信息進行增刪查改，可以設置用戶權限，刪除評論，增加信息分類，發(fā)布通知公告。

用戶列表

通知管理

圖2-2管理員用例圖

1.發(fā)布通知用例描述

2.2創(chuàng)建系統(tǒng)靜態(tài)模型

2.2.1創(chuàng)建系統(tǒng)靜態(tài)模型

從前面的需求分析中，我們可以依據(jù)主要的類對象：用戶，系統(tǒng)管理員和信息等創(chuàng)建完整的類圖如圖下圖所示

圖2-3類圖

1.用戶類主要包含了用戶信息包括唯一ID，用戶名,密碼,性別，姓名，聯(lián)系方式，出

生年月，最終一次登陸時間，是否為管理員。

2.招領信息類主要包含拾物分類信息，包括唯一ID，拾物類型，拾物圖片，發(fā)布人姓

名，發(fā)布人聯(lián)系方式，拾物時間等。

3.尋物信息類主要包含失物分類信息，包括唯一ID，失物類型，失物圖片，發(fā)布人姓

名，發(fā)布人聯(lián)系方式，失物也許時間等。

4.保藏類，主要包括保藏人，保藏信息編號，保藏時間，保藏信息類型。

5.校區(qū)類主要是校區(qū)名稱，校區(qū)對應學校。

6.物品類別類主要拾物或失物詳細是屬于哪一個類型，有類型名稱和類型編號。

7.附件類包含了發(fā)布的招領信息和尋物信息的各種附件，主要有上傳人編號，上傳時

間，信息類型等。

8.評論類包含了發(fā)布信息的人和發(fā)布評論的人的編號，以及類型、信息編號等。

2.3創(chuàng)建系統(tǒng)動態(tài)模型

系統(tǒng)的動態(tài)模型可以使用交互作用圖、狀態(tài)圖和活動圖來描述

2.3.1創(chuàng)建序列圖

1.用戶發(fā)布失物或者拾物活動的步驟分為：（1）同學在登錄界面輸入自己賬號密碼登錄（2提交包含賬號密碼的表單（3）系統(tǒng)驗證賬號密碼（3）進入信息發(fā)布頁面（4）填寫并且提交表單信息（5）數(shù)據(jù)庫增加信息如下圖所示。

圖2-3-1發(fā)布信息時序圖

2.3.2創(chuàng)建活動圖

信息發(fā)布活動圖，主要描述信息發(fā)布時的流程

圖2-6信息發(fā)布活動圖2.3.3創(chuàng)建組件圖

失物招領系統(tǒng)進行剖析分成各個組件：

2.3.4創(chuàng)建部署圖

失物招領系統(tǒng)主要分成了web服務，數(shù)據(jù)庫兩大部分：

3數(shù)據(jù)庫設計

3.1數(shù)據(jù)庫設計的基本規(guī)范

3.1.1開發(fā)規(guī)范

（1）遵守數(shù)據(jù)的設計規(guī)范3NF規(guī)定

（2）一行記錄必需表內(nèi)唯一，表必需有主鍵。

（3）時間使用DateTime

（4）在主外鍵的選擇上應留意：為關聯(lián)字段創(chuàng)建外鍵、全部的鍵都必需唯一、避開使用復合鍵、外鍵總是關聯(lián)唯一的鍵字段

3.1.2命名規(guī)范

（1）對象名稱應當精確?????完整地描述了對象的含義。

（2）數(shù)據(jù)庫對象的命名應當避開和系統(tǒng)原有的對象名稱（如：系統(tǒng)表、系統(tǒng)存儲過程等）混淆。

（3）對象名稱中不同的單詞間應當能夠便利的區(qū)分開。

（4）使用Pascal命名規(guī)章

3.2基本表及其說明

3.2.1尋物信息列表

3.2.1.1尋物具體信息

顯示用戶點擊進入尋物信息后列表呈現(xiàn)信息：

3.2.1.2尋物信息搜尋

3.2.2招領信息列表

招領模塊下，根據(jù)時間降序排列出系統(tǒng)foundInfoList表的信息。

3.2.2.1招領具體信息

顯示用戶點擊進入招領信息后列表呈現(xiàn)信息：

3.2.2.2尋物信息搜尋

3.2.3個人信息列表

3.2.3.1用戶基本信息

3.2.3.2我發(fā)布過的尋物信息

顯示我發(fā)布過得尋物信息列表，按時間降序排列

3.2.3.3我發(fā)布過的招領信息

點擊進入某條記錄顯示此條記錄招領具體信息。（刪除？）3.2.3.4我評論過的信息

點擊進入某條記錄顯示此條記錄具體信息。（刪除？）

3.2.3.5我保藏的信息

點擊進入某條記錄顯示此條記錄具體信息。（取消保藏？）

3.2.4發(fā)布尋物/招領信息

4.后臺管理

4.1權限管理

4.1.1用戶權限管理

●配置用戶登錄后臺管理權限

●配置系統(tǒng)管理員修改基本表權限

●配置系統(tǒng)管理員對權限配置操作權限

4.2物品類管理

4.2.1物品所屬類管理

包含物品類表的增刪查改、分頁操作。

4.2.2物品管理

二級列表物品大類選擇：

三級列表物品名稱列表，包含物品類表的增刪查改、分頁操作。

4.2.3校區(qū)管理

4.2.4擬定初始化物品類管理

4.3訂單管理

4.3.1招領訂單管理

二級菜單選擇：

三級菜單數(shù)據(jù)顯示：

包含訂單的固定發(fā)布時間段查找、固定拾物時間段查找、信息標題及訂單好查找、分頁、排序操作。

物品具體信息顯示：

4.3.2尋物訂單管理

包含訂單的固定發(fā)布時間段查找、固定拾物時間段查找、信息標題及訂單好查找、分頁、排序操作。

物品具體信息顯示：

5.試驗總結

5.1UML建模總結

UML是一種軟件建模語言，可以對任何具有靜態(tài)結構和動態(tài)行為的系統(tǒng)進行建模。在關注它建模特性的同時更要關注它的過程特性--在什么時間做什么工作，用什么模型，讓哪些人來做。對系統(tǒng)用戶而言，軟件的開發(fā)模型向他們描述了軟件開發(fā)者對軟件系統(tǒng)需求的理解。讓系統(tǒng)用戶查看軟件對象模型并且找到其中的問題，可以使開發(fā)者不至于從一開頭就發(fā)生錯誤。對軟件開發(fā)而言，軟件的對象模型有助于他們對軟件的需求以及系統(tǒng)的架構和功能進行溝通。

在UML建模過程中的一個體會,用例圖是UML中最簡潔也是最簡單的一種圖。說它簡潔是由于它采納了面對對象的思想，又是基于用戶視角的，繪制特別簡單，簡潔的圖形表示讓人一看就懂。說它簡單是由于用例圖往往不簡單掌握，要么過于簡單，要么過于簡潔。用例圖表示了角色和用例以及它們之間的關系。類圖可以關心我們更直觀的了解一個系統(tǒng)的體系結構。通過關系和類表示的類圖，可以圖形化的方式描述一個系統(tǒng)的設計部分。在UML面對對象中，對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。它們的不同點在于對象圖顯示類的多個對象實例，而不是實例的類。一個對象圖是類圖的一個實例。由于對象存在生命周期，因此對象圖只能在系統(tǒng)某一時間段存在。挨次圖，描述了對象之間動態(tài)的交互關系，著重體現(xiàn)對象間消息傳遞的時間挨次。還有就是挨次圖由一組對象構成，每個對象分別帶有一條豎線，稱作對象的生命線，它代表時間軸，時間沿豎線向下延長。UML面對對象中挨次圖描述了這些