UML期末大作业失物招领系统.docx
- 文档编号:25394889
- 上传时间:2023-06-08
- 格式:DOCX
- 页数:27
- 大小:225.56KB
UML期末大作业失物招领系统.docx
《UML期末大作业失物招领系统.docx》由会员分享,可在线阅读,更多相关《UML期末大作业失物招领系统.docx(27页珍藏版)》请在冰豆网上搜索。
UML期末大作业失物招领系统
U
M
L
设
计
性
实
验
报
告
校园失物招领系统
学院软件与通信工程学院
学生姓名刘洋学号0******
专业软件工程届别13级
指导教师廖汗成
二零一五年十二月十五日
1、需求分析
1.1开发背景及意义
现今社会生活中,随着人们生活需求的日益多元化,人们所持有的物质资源也随之丰富,最直观的表现就是人们所拥有的物品无论从种类还是数量上都大幅增加,这就造成了人们对自己所有的物品在看管方面难度的加大,再加之日益加快的生活节奏,就更导致了人们遗落、丢失物品的情况时有发生。
这种现象在面积相对较小,而人口特别密集的大学校园来说更是屡见不鲜。
老师和同学们时常丢失个人物品,
如书籍、手机、钱包、一卡通等现象时有发生。
经过调查发现,失主往往因为不能及时的找回失物而造成许多麻烦和不少的损失(像许多同学因为丢失一卡通而造成了用餐、进入图书馆、借书等许多不便)。
另一方面,物品的拾取者也因为没用取得失主的联系方式而不能及时的把拾取物交还到失主手上。
而传统的失物招领服务中心,采用的还是拾取者上交、手工备案、人工查询的方式。
但是随之物品的增多这种管理方式的工作量不断加大,这种做法就存在费时费力、缺乏时效性、不利于调动拾取者积极性等缺点。
基于以上分析,我们认为建立一个网上失物招领系统是非常必要的。
一方面,一旦网站建立好之后,拾到失物的同学可以在第一时间将失物信息发布到网上,而不是找张纸写上“失物招领”四个大字后贴到公告栏。
另一方面,有一个系统处理失物信息,就减少了人工处理的工作量。
1.2系统功能及目标
此失物招领系统旨在给拾主一个可信任的软件发布拾到的物品,让失主更容易地找到丢失的物品,同时不至于出现让失主冒领、错领等现象。
失主和拾主主要针对注册过该软件的所有群体。
为完成上述功能,提出以下相应的需求:
1、在数据库中存储失主发布的丢失物品信息以及拾主或各个失物招领信任点发布拾获物品信息,并方便有效地进行相应的数据操作和管理,这其中包括:
*物品信息的录入、删除、修改
*物品信息的模糊查询
*物品信息的多关键字检索
2、能够对一定数量的注册过的失主信息进行相应的存储和管理,这其中包括:
*失主信息的录入、删除、修改
*失主的统计与查询
3、能够对一定数量的注册过的拾主信息进行相应的存储和管理,这其中包括:
*拾主信息的录入、删除、修改
*拾主的统计与查询
4、能够对失主与拾主发布的物品信息进行匹配比较,并按照匹配的从高到低的顺序为失主推荐
5、能够对需要的统计结果提供打印和输出。
6、为了不出现失主冒领、错领的现象,以及为了保证拾主信息的保密性安全性,让拾主提供部分拾获物品信息,只有当失主全部答对时,才可以得到拾主的信息。
7、能够保证一定的安全机制,需要信息管理人员的优先级以及数据信息授权访问,防止随意删改,同时提供信息备份的服务。
2、系统建模
2.1创建系统用例模型
2.1.1确定参与者
创建系统用例的第一步是确定系统的参与者。
失物招领系统的参与者包含以下三种:
(1)用户:
发布失物或者拾物信息的主体。
(2)系统管理员:
负责失物招领系统的操作和后台维护。
(3)系统数据库:
参与系统完成各项功能的整个过程。
2.1.2参与者用例
普通用户在本系统中能够发布失物信息或者拾物信息,发表评论,修改评论,删除评论修改个人资料(包括别名,性别,邮箱,手机号码),修改密码,将某条寻物信息或拾物信息加入自己收藏。
图2-1-2普通用户用例图
1.修改密码用例描述
用例名称
修改密码
标识符
AC0001
用例描述
用户进行修改密码操作
参与者
用户
状态
前置条件
用户已登录系统
后置条件
密码修改成功
基本操作流程
用户输入目前有效密码
输入新密码
再次输入新密码进行确认
4.提示用户修改密码成功
假设
1.用户已登录系统2.输入了有效密码3两次输入新密码一致
2.更改联系方式用例描述
用例名称
更改联系方式
标识符
AC0002
用例描述
用户更改联系方式操作
参与者
用户
状态
前置条件
用户已登录系统
后置条件
更新联系方式成功
基本操作流程
1.输入新的联系方式
2.提交表单确认
3.修改成功
假设
1.用户已登录系统2.输入信息符合基本格式要求
3.拾物或者拾物信息发布
用例名称
拾物或者拾物信息发布
标识符
AC0003
用例描述
拾物或者拾物信息发布
参与者
用户
状态
前置条件
用户已登录系统
后置条件
拾物或者拾物信息发布成功
基本操作流程
1.选择信息分类(拾物还是拾物)
2.填写物品信息(如名称,形状,颜色,相关标识等)。
填写丢失(拾到)的时间,地点等,填写相关描述
3.提交表单
4.发布成功
假设
1.用户已登录系统2.输入信息符合基本格式要求
4.认领失物用例图
用例名称
认领失物用例图
标识符
AC0004
用例描述
当失主看到丢失物品或者疑似丢失物品是进行认领
参与者
用户
状态
前置条件
用户已登录系统
后置条件
认领成功等待拾主联系确认
基本操作流程
1.浏览到相关信息是,点击认领按钮
2.认领成功
3.等待拾主反馈
假设
用户已登录系统
5.发表评论用例描述
用例名称
发表评论用例描述
标识符
AC0005
用例描述
用户看到消息是可以进行评论发表看法提供相关线索
参与者
用户
状态
前置条件
用户已登录系统
后置条件
评论成功
基本操作流程
1.浏览到相关信息是,填写评论内容
2.输入验证码
3.点击提交按钮
假设
1.用户已登录系统2.输入正确验证码
6.信息加入收藏用例描述
用例名称
加入收藏
标识符
AC0006
用例描述
用户看到一条感兴趣的寻物或拾物信息,如可能与自己有关的,可以将这条信息加入收藏
参与者
用户
前置条件
用户已登录系统
后置条件
加急置顶成功
基本操作流程
1.选择信息点击收藏
假设
1.用户已登录系统
2.1.3管理员用例图
管理员可以将用户设为管理员,对已发布信息进行增删查改,可以设置用户权限,删除评论,增加信息分类,发布通知公告。
图2-2管理员用例图
1.发布通知用例描述
用例名称
发布通知用例
标识符
BC0001
用例描述
如有紧急信息或者需要通知信息发布通告
参与者
管理员
状态
前置条件
管理员已登录系统
后置条件
通告发布成功
基本操作流程
1.进入通告发布页面
2.编辑需要发布的内容
3.点击确定发布
假设
管理员已登录
2.2创建系统静态模型
2.2.1创建系统静态模型
从前面的需求分析中,我们可以依据主要的类对象:
用户,系统管理员和信息等创建完整的类图如图下图所示
图2-3类图
1.用户类主要包含了用户信息包括唯一ID,用户名,密码,性别,姓名,联系方式,出生年月,最后一次登陆时间,是否为管理员。
2.招领信息类主要包含拾物分类信息,包括唯一ID,拾物类型,拾物图片,发布人姓名,发布人联系方式,拾物时间等。
3.寻物信息类主要包含失物分类信息,包括唯一ID,失物类型,失物图片,发布人姓名,发布人联系方式,失物大概时间等。
4.收藏类,主要包括收藏人,收藏信息编号,收藏时间,收藏信息类型。
5.校区类主要是校区名称,校区对应学校。
6.物品类别类主要拾物或失物具体是属于哪一个类型,有类型名称和类型编号。
7.附件类包含了发布的招领信息和寻物信息的各种附件,主要有上传人编号,上传时间,信息类型等。
8.评论类包含了发布信息的人和发布评论的人的编号,以及类型、信息编号等。
2.3创建系统动态模型
系统的动态模型可以使用交互作用图、状态图和活动图来描述
2.3.1创建序列图
1.用户发布失物或者拾物活动的步骤分为:
(1)学生在登录界面输入自己账号密码登录(2提交包含账号密码的表单(3)系统验证账号密码(3)进入信息发布页面(4)填写并且提交表单信息(5)数据库增加信息如下图所示。
图2-3-1发布信息时序图
2.3.2创建活动图
信息发布活动图,主要描述信息发布时的流程
图2-6信息发布活动图
2.3.3创建组件图
失物招领系统进行剖析分成各个组件:
2.3.4创建部署图
失物招领系统主要分成了web服务,数据库两大部分:
3数据库设计
3.1数据库设计的基本规范
3.1.1开发规范
(1)遵守数据的设计规范3NF规定
(2)一行记录必须表内唯一,表必须有主键。
(3)时间使用DateTime
(4)在主外键的选择上应注意:
为关联字段创建外键、所有的键都必须唯一、避免使用复合键、外键总是关联唯一的键字段
3.1.2命名规范
(1)对象名称应当准确完整地描述了对象的含义。
(2)数据库对象的命名应当避免和系统原有的对象名称(如:
系统表、系统存储过程等)混淆。
(3)对象名称中不同的单词间应当能够方便的区分开。
(4)使用Pascal命名规则
3.2基本表及其说明
3.2.1寻物信息列表
招领模块下,按照时间降序排列出系统lostInfoList表的信息:
名称
数据类型
长度
描述
失物图片
Img
首页显示首张图片,可不上传图片,最多上传四张图片
失物所属类
varchar
如“卡片类”
失物信息标题
Varchar
如“丢失建行卡一张”
发布人姓名
varchar
发布人联系方式
Varchar
失物地点
Varchar
失物日期
Date
评论
Text
首页只显示评论数量
3.2.1.1寻物详细信息
显示用户点击进入寻物信息后列表呈现信息:
名称
数据类型
长度
描述
失物图片
Img
可不上传图片,最多上传四张图片
失物所属类
varchar
如“卡片类”
失物信息标题
Varchar
如“丢失建行卡一张”
寻物描述
Varchar
对丢失物品的进一步描述
发布人姓名
varchar
发布人联系方式
Varchar
失物地点
Varchar
失物日期
Date
评论
Text
显示此条寻物信息的评论列表
收藏这条记录
int
点击收藏记录此条信息单号
3.2.1.2寻物信息搜索
名称
描述
校区选择
默认用户校区,可下拉重新选择,必填
物品大类选择
如,“证件类”、“卡片类”等,可不填写
时间范围选择
选择两个小于系统当前时间的时间点,可不选择
关键字
模糊搜索
3.2.2招领信息列表
招领模块下,按照时间降序排列出系统foundInfoList表的信息。
名称
数据类型
长度
描述
拾物图片
Img
首页显示首张图片,可不上传图片,最多上传四张图片
拾物所属类
varchar
如“卡片类”
拾物信息标题
Varchar
如“拾到建行卡一张”
拾物人姓名
varchar
拾物人手机号
Varchar
拾物地点
Varchar
拾物日期
Date
评论
Text
首页只显示评论数量
3.2.2.1招领详细信息
显示用户点击进入招领信息后列表呈现信息:
名称
数据类型
长度
描述
拾物图片
Img
首页显示首张图片,可不上传图片,最多上传四张图片
拾物所属类
varchar
如“卡片类”
拾物信息标题
Varchar
如“拾到建行卡一张”
拾物信息描述
Varchar
对拾到物品的进一步描述
拾物人姓名
varchar
拾物人手机号
Varchar
拾物地点
Varchar
拾物最终所在地点
Varchar
拾物者将拾物最终放置地点
拾物日期
Date
评论
Text
显示此条拾物信息的评论列表
收藏这条记录
int
点击收藏记录此条信息单号
3.2.2.2寻物信息搜索
名称
描述
校区选择
默认用户校区,可下拉重新选择,必填
物品大类选择
如,“证件类”、“卡片类”等,可不填写
时间范围选择
选择两个小于系统当前时间的时间点,可不选择
关键字
模糊搜索
3.2.3个人信息列表
3.2.3.1用户基本信息
名称
描述
学号
姓名
联系方式
QQ,EMAIL,电话任选,至少一个
所属校区
所属学院
所属专业班级
3.2.3.2我发布过的寻物信息
显示我发布过得寻物信息列表,按时间降序排列
名称
数据类型
长度
描述
失物图片
Img
首页显示首张图片
失物所属类
varchar
如“卡片类”
失物信息标题
Varchar
如“丢失建行卡一张”
发布日期
Date
用户发布信息日期
评论
Text
首页只显示评论数量
寻物信息状态
如寻物找到,点击按钮表示寻物信息匹配成功
点击进入某条记录显示此条记录寻物详细信息。
(删除?
)
3.2.3.3我发布过的招领信息
名称
数据类型
长度
描述
拾物图片
Img
首页显示首张图片,
拾物所属类
varchar
如“卡片类”
拾物信息标题
Varchar
如“拾到建行卡一张”
发布日期
Date
用户发布信息日期
评论
Text
首页只显示评论数量
招领信息状态
如拾物找到失主,点击按钮表示招领信息匹配成功
点击进入某条记录显示此条记录招领详细信息。
(删除?
)
3.2.3.4我评论过的信息
名称
数据类型
长度
描述
物品图片
Img
首页显示首张图片,
物品所属类
varchar
如“卡片类”
物品信息标题
Varchar
如“拾到建行卡一张”
物品状态
拾物或失物
评论日期
Date
用户发布信息日期
评论
Text
首页只显示评论数量
点击进入某条记录显示此条记录详细信息。
(删除?
)
3.2.3.5我收藏的信息
名称
数据类型
长度
描述
物品图片
Img
首页显示首张图片,可不上传图片,最多上传四张图片
物品所属类
varchar
如“卡片类”
物品信息标题
Varchar
如“拾到建行卡一张”
物品状态
拾物或失物
拾/失物人姓名
varchar
拾/失物人手机号
Varchar
拾/失物地点
Varchar
拾/失物日期
Date
评论
Text
首页只显示评论数量
点击进入某条记录显示此条记录详细信息。
(取消收藏?
)
3.2.4发布寻物/招领信息
名称
描述
发布状态
拾物或失物,下拉选择
物品图片
最多上传四张图片
物品所属类
如“卡片类”,从系统所列项选择,下拉列表选择
物品信息标题
如“拾到建行卡一张”
物品信息描述
对拾到物品的进一步描述
拾/失物人姓名
系统自动录入登录用户名,可修改
拾/失物人联系方式
选择用户信息(QQ.EMAIL,TEL下拉多选),可手动输入其他联系方式
拾/失物地点
默认用户校区,下拉可重新选择,文本输入具体地点
物品最终所在地点
拾物者将拾物最终放置地点(仅发布招领信息出现此填写框)
拾/失物日期
系统当前时间之前
评论
显示此条拾物信息的评论列表
4.后台管理
4.1权限管理
4.1.1用户权限管理
●配置用户登录后台管理权限
●配置系统管理员修改基本表权限
●配置系统管理员对权限配置操作权限
4.2物品类管理
4.2.1物品所属类管理
包含物品类表的增删查改、分页操作。
数据列表名
描述
物品类ID
所属大类编号,如1001
物品类名称
大类名称,如“卡片类”
使用状态
1表示在使用,0表示暂停使用
4.2.2物品管理
二级列表物品大类选择:
证件类
财物类
生活物品
学习物品
其他
三级列表物品名称列表,包含物品类表的增删查改、分页操作。
数据列表名
描述
物品ID
物品编号,与上一级ID保持前面字段一致,如卡片类下的一卡通为“100101”
物品类名称
物品名称,如一卡通
使用状态
1表示在使用,0表示暂停使用
4.2.3校区管理
校区
状态
麦庐园
1
蛟桥园
1
枫林园
1
青山园
1
4.2.4拟定初始化物品类管理
物品所属类
物品名
证件类
一卡通,水卡,身份证,银行卡,其他证件
财物类
手机,电脑,U盘,钱包,移动电源,其他财物
生活物品
雨伞,眼镜盒,水杯,耳机,衣服,钥匙,其他生活物品
学习物品
书包,书籍,其他学习用品
其他
4.3订单管理
4.3.1招领订单管理
二级菜单选择:
校区
麦庐园
蛟桥园
枫林园
青山园
三级菜单数据显示:
包含订单的固定发布时间段查找、固定拾物时间段查找、信息标题及订单好查找、分页、排序操作。
数据列表名
描述
订单号
以物品所属ID开头,后面六位数字系统自增,如拾到一卡通,订单号为“100101000001”
物品所属类
大类名称,如“卡片类”
物品名
物品名称,如“一卡通”
信息标题
发布者输入标题
信息发布人
发布日期
系统记录的用户发布信息时间
拾物日期
用户填写的信息发布时间
图片
按钮,鼠标移过显示拾物图片(首张)
状态
1表示有效,0表示失效
查看订单详情
点击跳转到订单详细信息显示
物品详细信息显示:
名称
数据类型
长度
描述
拾物图片
Img
最多上传四张图片显示
拾物所属类
varchar
如“卡片类”
拾物信息标题
Varchar
如“拾到建行卡一张”
拾物信息描述
Varchar
对拾到物品的进一步描述
拾物人姓名
varchar
拾物用户账号
发布人一卡通账号
拾物人所属校区
拾物人所属学院
拾物人所属专业班级
拾物人联系方式
Varchar
包括用户填写的所有联系方式
拾物地点
Varchar
拾物最终所在地点
Varchar
拾物者将拾物最终放置地点
拾物日期
Date
信息发布时间
Date
评论
Text
显示此条拾物信息的评论列表
招领状态
是否被用户招领
4.3.2寻物订单管理
包含订单的固定发布时间段查找、固定拾物时间段查找、信息标题及订单好查找、分页、排序操作。
数据列表名
描述
订单号
以物品所属ID开头,后面六位数字系统自增,如拾到一卡通,订单号为“100101000001”
物品所属类
大类名称,如“卡片类”
物品名
物品名称,如“一卡通”
信息标题
发布者输入标题
信息发布人
发布日期
系统记录的用户发布信息时间
失物日期
用户填写的信息发布时间
图片
按钮,鼠标移过显示拾物图片(首张)
状态
1表示有效,0表示失效
查看订单详情
点击跳转到订单详细信息显示
物品详细信息显示:
名称
数据类型
长度
描述
失物图片
Img
最多上传四张图片显示
失物所属类
varchar
如“卡片类”
失物信息标题
Varchar
如“拾到建行卡一张”
失物信息描述
Varchar
对拾到物品的进一步描述
失物人姓名
varchar
失物用户账号
发布人一卡通账号
失物人所属校区
失物人所属学院
失物人所属专业班级
失物人联系方式
Varchar
包括用户填写的所有联系方式
失物地点
Varchar
拾物日期
Date
信息发布时间
Date
评论
Text
显示此条拾物信息的评论列表
寻物状态
失物是否找回
5.实验总结
5.1UML建模总结
UML是一种软件建模语言,可以对任何具有静态结构和动态行为的系统进行建模。
在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作,用什么模型,让哪些人来做。
对系统用户而言,软件的开发模型向他们描述了软件开发者对软件系统需求的理解。
让系统用户查看软件对象模型并且找到其中的问题,可以使开发者不至于从一开始就发生错误。
对软件开发而言,软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。
在UML建模过程中的一个体会,用例图是UML中最简单也是最复杂的一种图。
说它简单是因为它采用了面向对象的思想,又是基于用户视角的,绘制非常容易,简单的图形表示让人一看就懂。
说它复杂是因为用例图往往不容易控制,要么过于复杂,要么过于简单。
用例图表示了角色和用例以及它们之间的关系。
类图可以帮助我们更直观的了解一个系统的体系结构。
通过关系和类表示的类图,可以图形化的方式描述一个系统的设计部分。
在UML面向对象中,对象图是类图的实例,几乎使用与类图完全相同的标识。
它们的不同点在于对象图显示类的多个对象实例,而不是实例的类。
一个对象图是类图的一个实例。
由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
顺序图,描述了对象之间动态的交互关系,着重体现对象间消息传递的时间顺序。
还有就是顺序图由一组对象构成,每个对象分别带有一条竖线,称作对象的生命线,它代表时间轴,时间沿竖线向下延伸。
UML面向对象中顺序图描述了这些对象随着时间的推移相互之间交换消息的过程。
消息用从一务垂直的对象生命线指向另一个对象的生命线的水平箭头表示。
图中还可以根据需要增加有关时间的说明和其他注释。
5.2数据库设计总结
数据库作为一个永久存储形式在应用中发挥着重要的作用。
在数据库设计中,我明白了数据库设计中不是范式越高越好的。
我们要根据我们的应用来决定,一切应该以需求为首要选择,还有就是软件开发中软件需求要明确,通过UML建模,我们从需求分析开始一步一步的完成了系统设计,进而明确了数据库设计需求,让数据库设计更加高效,合理。
软件开发是一门工程学,引入了UML使得开发管理更加高效,稳定,简单。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 期末 作业 失物招领 系统