目录
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用户操作需求
输入的信息都封装在数据结构当中,不能独立存在,在向数据库中提交数据时必须一起提交而不能逐项提交。输入数据的类型必须和定义的数据类型相匹配。