目錄
1. 引言
1.1 目的、小組成員
1.1.1 文檔編寫目的
本要求規格說明書對閑置交換系統進行簡單的分析,給出了系統的數據流圖。系統主要用戶是學生,加深與用戶間的交流,在功能與系統界面上與用戶達成一致的看法,以便於開發出用戶滿意的系統。
1.1.1 小組內成員以及分工
姓名 |
分工 |
劉方東* |
原型開發 |
劉昊昕 |
順序圖 |
梅敏敏 |
狀態圖,博客 |
馬驍馳 |
包圖 |
姚昕怡 |
活動圖 |
李炬坪 |
類圖,測試,美工 |
注: a.‘*’所標識 成員 為小組長 b.所有成員均全程參與文檔整體構建和修訂 |
1.2 項目計划
第一周:與甲方確定需求,討論分工及系統功能,開始文檔初步編寫,問卷設計
第二周:系統靜態圖和動態圖的初步繪制
第三周:圖的描述文檔的編寫,原型的初步開發
第四周:軟件需求規格說明書,設計說明書編寫
第五周:文檔和原型的完善
2. 系統概述
在日常生活中,每個大學生可能都遇到這樣的煩惱,宿舍里堆積了長時間不用的物品,買了新物品卻因為舊物品不知道如何處理而沒有地方擺放,舊的物品直接扔了可惜,想交換卻沒有平台交流和發布。我們計划設計一個閑置物品交易系統,來解決這個煩惱。比如考過四六級的同學,不用聽力的耳機了,卻不知道怎么處理,可以通過這個平台將耳機低價賣給有需要的同學。
本系統以學校為背景,在認真調研和分析了同學對於閑置物品交換的現狀之后,根據學生,需求和各個功能的關系,做出了積極的設計方案。
本系統由學生發布需要交換的閑置物品,將該物品發布到相應的物品分類區,用戶也可在分類區通過分類篩選,查看別人發布的相應分類的物品,有意願的則可以與發布者進行交流及交易。
1.技術可行性
閑置物品交易系統本身問題並不復雜,所需要的技術也不艱深,技術風險無,主要是需要注意功能的具體和明確,系統功能可能會比較繁雜,開發時需要多加留心此外本系統在別的高校已有先例,技術上可以加以借鑒。
2.操作可行性
此閑置物品系統預期操作方式符合大學生的操作流程,各個功能需求間彼此聯系但目標明確,用戶能很方便的理解需求中模糊的概念
3.經濟可行性
該系統並不以盈利為目的,旨在為在校學生交易閑置物品提供一個更好的平台。
4.法律可行性
該系統開發流程的各個步驟以及所采用的代碼都是項目參與人員努力工作后的結果,不存在侵害他人知識產權的可能性
功能簡介:
1、 物品上傳系統:用戶上傳的閑置物品的照片,並填寫閑置物品的信息,上傳的信息會保存到服務器的數據庫。
2、 分類系統:對閑置物品進行分類。
3、 物品審核系統:管理員審核用戶上傳的物品,不合格的會被刪除。
用戶端功能:
管理端功能:
3 需求獲取
問卷調查
4 數據流圖和用例圖
4.1系統數據流圖(DFD)
頂層數據流圖
一層數據流圖
4.2 用例圖
4.2.1 用例圖
4.2.2 描述文檔
用例圖綜述
“閑置物品交換系統”由交易系統和管理系統兩部分組成,通過用戶和管理員共同完成系統功能。
用例1:用戶通過微信小程序進入“閑置物品交換系統”,可以上傳自己的物品信息並展示,也可以選擇聯系其他用戶並交易其物品。
用例2:管理員進入“閑置物品交換系統”后,物品分類管理;站點信息的更新。
用例1:
(1.)參與者:用戶。
(3.)基本事件流:用戶進入系統之后,進行操作。
(4.)擴展事件流:用戶可以參與上傳物品信息,也可以查看他人物品信息。
(5.)關系描述:用戶通過微信小程序進入系統。
(6.)前置條件:無。
(7.)后置條件:無。
(8.)異常:無。
(9.)限制條件:無。
用例2:
(1.)參與者:管理員。
(2.)用例名稱:交易系統管理。
(3.)基本事件流:管理員進入系統進行管理。
(4.)擴展事件流:管理員進行用戶管理,交易物品的管理,站點的更新。
(5.)關系描述:管理員進入系統,進行管理。
(6.)前置條件:無。
(7.)后置條件:無。
(8.)異常:無。
(9.)限制條件:無。
4.3 類圖
4.3.2 類圖描述文檔
4.3.2.1類圖綜述:
圖中,UI類負責界面的繪制,而作為UI的子類,WebUI多出了審核Item的職責。DataAccesser負責邏輯控制與數據庫的交互
4.3.2.2類描述:
類名 |
整體說明 |
屬性 |
服務 |
關聯 |
泛化 |
依賴 |
DataAccesser |
控制程序邏輯 |
user:User items:Item[] ui:UI |
loadItem():Item[] AddItem(Item):void ChangeItem(Item):void DeleteItem(Item):void SetUIData():void |
Item User UI |
|
數據庫 |
UI |
顯示物品 |
Items:Item[] |
ShowItems():void |
DataAccesser, Item |
|
|
WebUI |
顯示物品及審核 |
|
審核Item |
|
UI |
|
WechatUI |
在微信端顯示物品 |
|
|
|
UI |
|
Item |
物品 |
|
|
UI DataAccesser |
|
|
User |
用戶 |
|
|
DataAccesser |
|
|
數據庫 |
|
|
|
|
|
|
4.3.2.3關聯描述:
名稱 |
類型 |
類 |
端點 |
關聯1 |
限定關聯 |
DataAccesser,User |
User |
關聯2 |
限定關聯 |
DataAccesser,Item |
Item |
關聯3 |
限定關聯 |
DataAccesser,UI |
UI |
關聯4 |
限定關聯 |
UI,Item |
Item |
4.3.2.4泛化描述:
父類 |
子類 |
訪問權限 |
約束 |
UI |
WebUI |
public |
無 |
UI |
WechatUI |
public |
無 |
4.3.2.5依賴描述:
名稱 |
所涉及的類 |
依賴類型 |
說明 |
依賴1 |
DataAccesser,數據庫 |
調用 |
無 |
4.3.2.6其他描述:無
4.4 包圖
4.4.1 包圖
4.4.2 包圖描述文檔
4.4.2.1包圖綜述:
Controller包負責邏輯的處理,UI包負責界面的顯示,Controller包與Database包之間有依賴關系。
4.4.2.2包描述
包名 |
種類 |
包圖中模型元素所在文檔 |
UI |
類包 |
見類圖文檔 |
Controller |
類包 |
見類圖文檔 |
Database |
類包 |
見類圖文檔 |
SQL包 |
類包 |
系統包 |
4.4.2.3其他描述:無
4.5 順序圖
4.5.1 順序圖
4.5.2 順序圖描述文檔
4.5.2.1 綜述:
上圖描述了“物品上傳”的順序圖,涉及用戶、DataAccesser,數據庫、管理員四個對象
4.5.2.2 參與者對象描述:
用戶和管理員是參與者,DataAccesser和數據庫是兩個對象。DataAccesser負責實現數據方面的邏輯操作,數據庫負責數據的存儲和查詢。
4.5.2.3 消息描述:
名稱 |
類型 |
發送對象 |
接收對象 |
添加物品 |
同步 |
用戶 |
DataAccesser |
提交 |
同步 |
DataAccesser |
數據庫 |
請求物品信息 |
同步 |
管理員 |
DataAccesser |
查詢物品數據 |
同步 |
DataAccesser |
數據庫 |
返回物品數據 |
同步 |
數據庫 |
DataAccesser |
返回物品數據 |
同步 |
DataAccesser |
管理員 |
[審核通過]保存 |
同步 |
管理員 |
DataAccesser |
保存物品 |
同步 |
DataAccesser |
數據庫 |
審核不通過 |
同步 |
管理員 |
DataAccesser |
4.5.2.4 其他描述:無
4.6 狀態圖
4.6.1狀態圖
Figure 1
Figure 2
4.6.2 狀態圖描述文檔
4.6.2.1文字說明(Figure 1)
4.6.2.1.1綜述:
圖Figure1描述了微信小程序端狀態及狀態間的轉換
4.6.2.1.2狀態描述:
狀態名 |
描述 |
空閑 |
等待用戶指令 |
正在修改個人信息 |
用戶正在修改個人信息 |
正在修改物品信息 |
用戶正在修改某物品的信息 |
正在添加 |
用戶正在添加新的物品 |
正在查看 |
用戶正在查看某物品及相關信息 |
數據庫查詢狀態 |
數據庫正在執行某些操作 |
4.6.2.1.3轉換描述:
源狀態 |
目標狀態 |
轉換事件 |
轉換分支 |
開始 |
空閑 |
微信端打開 |
無 |
空閑 |
結束 |
關閉 |
無 |
空閑 |
正在修改個人信息 |
修改個人信息 |
無 |
空閑 |
正在添加 |
添加物品 |
無 |
空閑 |
正在修改個人物品 |
修改物品 |
無 |
空閑 |
正在查看 |
查看物品詳情 |
無 |
正在修改個人信息 |
空閑 |
取消 |
無 |
正在添加 |
空閑 |
取消 |
無 |
正在修改個人物品 |
空閑 |
取消 |
無 |
正在查看 |
空閑 |
返回 |
無 |
正在修改個人信息 |
數據庫查詢狀態 |
提交 |
無 |
正在添加 |
數據庫查詢狀態 |
提交 |
無 |
正在修改個人物品 |
數據庫查詢狀態 |
提交 |
無 |
數據庫查詢狀態 |
空閑 |
查詢結束 |
無 |
4.6.2.1.4其他描述:無
4.6.2.2文字說明(Figure 2)
4.6.2.2.1綜述:
圖Figure1描述了Web端狀態及狀態間的轉換
4.6.2.2.2狀態描述:
狀態名 |
描述 |
審核狀態 |
等待用戶指令 |
數據庫查詢狀態 |
數據庫正在執行某些操作 |
4.6.2.2.3轉換描述:
源狀態 |
目標狀態 |
轉換事件 |
轉換分支 |
開始 |
審核狀態 |
Web打開 |
無 |
審核狀態 |
結束 |
關閉 |
無 |
審核狀態 |
數據庫查詢狀態 |
通過/不通過 |
無 |
數據庫查詢狀態 |
審核狀態 |
查詢結束 |
無 |
4.6.2.2.4其他描述:無
4.7 活動圖
4.7.1活動圖
4.7.2活動圖描述文檔
1.活動圖綜述:
上圖描述了“閑置物品交換”的活動圖,涉及用戶、管理員、信息3個對象,共同完成物品交換、信息修改功能。
2.參與者對象描述:
“用戶”、“管理員”是參與者,“信息”是操作對象。
3.狀態描述:
狀態名 |
狀態描述 |
物品信息 |
用戶修改已上傳的物品信息 |
物品信息 |
用戶上傳待交換的物品信息 |
審核物品/信息 |
管理員審核物品的信息與狀態 |
物品分類 |
管理員根據物品信息對物品進行分類 |
物品信息與狀態 |
顯示物品信息與狀態 |
信息回執 |
將物品審核不通過的通知反饋給用戶 |
物品條件 |
用戶輸入待檢索的物品關鍵字 |
刪除物品信息 |
管理員刪除已決定交換的兩物品信息 |
交換物品 |
通過快遞等方式實現物品交換 |
個人信息 |
用戶修改個人信息 |
個人信息與狀態 |
在數據庫端同步新的用戶信息 |
4.轉換描述:
原狀態 |
目標狀態 |
轉換事件 |
開始 |
物品信息 |
修改 |
開始 |
物品信息 |
上傳 |
物品信息 |
審核物品/信息 |
提交 |
審核物品/信息 |
物品分類 |
審核合格 |
審核物品/信息 |
信息回執 |
審核不合格 |
物品分類 |
物品信息與狀態 |
上傳同步 |
開始 |
物品條件 |
輸入 |
物品條件 |
物品信息與狀態 |
檢索查詢 |
物品信息與狀態 |
結束 |
不交換 |
物品信息與狀態 |
刪除物品信息 |
交換 |
開始 |
個人信息 |
修改 |
個人信息 |
個人信息與狀態 |
提交 |
5 產品的非功能性需求
5.1 外部接口說明
5.1.1 用戶接口
微信web開發者工具,MySQL數據庫和ProcessOn畫圖工具以及windows word文檔工具 。
5.1.2 軟件接口
各模塊過程之間采用函數調用、參數傳遞、返回值的方式進行消息傳遞。接口傳遞的信息將是以數據結構封裝了的數據,以參數傳遞或返回值的形式在模塊之間傳遞。
5.2 性能需求
1)支持多終端操作;
2)支持多並行操作的用戶同時操作
3)系統響應的時間短
5.2.1服務器的限制
內存:100M;帶寬:1M/s
5.3 屬性
5.3.1友好性
本軟件友好性極強和其他軟件有很好的兼容性。
5.3.2安全性
本軟件存在很好的安全性:
后端對SQL注入進行了過濾
管理員端與用戶端分隔
5.3.3可維護性
該軟件可維護性功能健全。
5.3.4可轉移/換性
本軟件利用開發平台提供的數據轉換功能,可以實現跨平台數據轉換,實現不同數據庫數據間的數據轉換,如:FoxPro、Access、Microsoft SQL Server間的數據轉換。
5.5其他需求
5.5.1用戶操作需求
輸入的信息都封裝在數據結構當中,不能獨立存在,在向數據庫中提交數據時必須一起提交而不能逐項提交。輸入數據的類型必須和定義的數據類型相匹配。