软工课程设计失物招领管理系统.docx
《软工课程设计失物招领管理系统.docx》由会员分享,可在线阅读,更多相关《软工课程设计失物招领管理系统.docx(18页珍藏版)》请在冰豆网上搜索。
软工课程设计失物招领管理系统
概要设计说明书
1引言
编写目的
该系统专为失物招领中心设计,以期简化工作流程,提高管理员的工作效率。
背景
日常生活中,当我们丢失物品后往往苦于寻找,要不是得登报,就得到处张贴寻物启事。
同时,拾主捡到物品若希望归还,也是麻烦重重。
如果有一个系统健全的失物招领机构,可以说减少了市民很多麻烦。
最重要的是,当今我国正在努力建设和谐社会,政府重视城市居民道德素质的提高,所以,弘扬拾金不昧的优秀传统,构建文明城市是政府义不容辞的一项责任。
基于目前国内该系统也是初步投入使用,在功能和应用方面还有待完善,我们加入自己的新点子,比如说表扬栏,失物过期提醒等进行开发,对于开设了失物招领中心的城市来说很适合。
同时,这是一个比较小型的系统,其开发成本不会很高,预算合理。
价格低廉也使它适合学校使用。
这个系统在以后应该会得到广泛的应用并日臻完善。
定义
Varchar:
是一种比char更加灵活的数据类型,同样用于表示字符数据,但是Varchar可以保存可变长度的字符串。
…
Datetime:
是一种日期时间的转换方式,有很大种,如()的格式为2010-10-2020:
51:
12
参考数据
《软件工程设计案例教程》清华大学出版社
《软件工程案例教程》机械工业出版社
《软件工程》高等教育出版社
2总体设计
需求规定
说明对本系统的主要的输入输出项目、处理的功能性能要求。
)
本系统主要的输入输出有:
失物的信息、报失的信息、留言信息、查询信息。
本系统的性能要求主要包括:
对精度、时间特性和灵活性的要求。
本系统的功能要求主要包括:
输入输出、数据管理能力、故障处理能力等。
运行环境
硬件环境
本系统的硬件环境如下。
客户机:
普通PC
CPU:
P4以上
;
内存:
256MB以上
能够运行以上或者Netscape以上版本的机器
分辨率:
推荐使用1024×768像素
Web服务器
CPU:
P4
内存:
1GB以上
硬盘:
80GB以上
网卡:
KMb/s速度网卡
;
数据库服务器
CPU:
P4
内存:
1GB以上
硬盘:
80GB以上
软件环境
本系统的软件环境如下。
操作系统:
UNIX/Linux/Windows2000或以上版本
数据库:
SQLServer2000
:
开发工具包:
JDKVersion服务器:
Tomcat
浏览器:
IE以上
基本设计概念和处理流程
模块设计
按照功能分解,本系统分为网上用户端系统和管理端系统。
根据页面流的设计,管理端系统又分为登录管理、用户管理、失物信息管理、报失信息管理和信息公布管理5个模块。
如下图所示:
上述粗略的程序结构图中:
:
管理端:
是指失物招领中心的管理员。
网上客户端:
是指失主。
登录管理:
通过输入用户名和密码实现用户登录。
用户管理:
用户是指管理员,包括“用户列表”、“用户信息”、“修改用户信息”、“增加用户信息”、“删除用户信息”。
失物信息管理:
包括捡拾物品信息的增加、删除、修改(逾期失物信息作为失物的一个属性)
报失信息管理:
包括报失物品信息的增加、删除、修改(过期报失信息作为报失信息的一个属性)。
信息公布管理:
包括留言信息的增加、删除,查询失物的信息(查询时分为普通查询和高级检索),失物部分信息增加、删除、修改。
!
结构
功能模块
子功能模块
标识符
功能描述
与其它各模块的关系
网上客户端
—
Web_User
报失(报失物品的输入)、信息的查询、留言
部分调用失物信息管理传给数据库的信息
管理端
登录管理
Loading
管理管理端的登录
调用用户管理设置的用户名和密码的正确性,是进入系统的入口
用户管理
User_Manage
管理员可以在用户管理接口中对用户进行添加、删除、修改、查询。
管理员进入系统的权限设置
失物信息管理
(
Pick_Information
完成捡拾物品信息的添加、修改和删除等维护功能
给数据库提供失物信息,供网上用户端和信息公布管理使用
报失信息管理
Loser_Information
完成报失信息的添加、修改和删除等维护功能
给数据库提供失物信息,供信息公布管理使用
信息公布管理
Voice_Information
输出部分失物信息、查询(普通查询和高级检索)、用户留言等功能
调用失物信息管理和报失信息管理的数据进行信息输出或查询
功能需求与程序的关系
各项功能需求的实现同各块程序的分配关系如下:
*
管理员登录
管理员信息增加
管理员信息删除
管理员信息修改
管理员信息查询
失物信息增加
失物信息删除
】
登录管理
·
用户管理
…
失物信息管理
<
报失信息管理
—
信息公布管理
、
失物信息修改
报失物品信息增加
报失物品信息删除
报失物品信息修改
留言信息增加
留言信息删除
#
失物信息查询
登录管理
…
用户管理
:
失物信息管理
.
报失信息管理
|
信息公布管理
)
3接口设计
用户接口
用户接口的设计按照友好性、中文化、可靠性的原则,结合失物招领管理系统的应用环境,用户接口的设计思想:
根据失物招领管理系统的4个子系统的组成,各子系统的应用基本上是这次设计的。
因此,要规范操作命令和方法、用户接口、菜单结构、移动提示、弹出弹入图符、警告提示的信息、说明文本的提示。
失物显示信息只能用文字简单介绍。
由于系统的应用面对不同的层次,而不同层次的用户对于数据库的访问是有限制的,因此,用户对信息的访问要进行授权控制。
系统在使用中出现的错误用中文提示。
#
对用户的操作进行规范和限制,防止数据库级的错误。
用户的命令输入和系统的回答信息:
用户通过输入给定的网址进入接口,接口会出现最近拾到的物品,还有很多信息分类提示,包括失物、报失、信息公布、信息查询等。
进入失物信息接口,用户可以看到最近丢失的物品的信息,进入报失接口,系统提示用户登录,如果是第一次登录,系统就提示用户注册,用户按照要求用键盘输入用户名和密码后,系统检验输入信息是否正确,如果正确,进入接口,填写相关的失物信息,进入信息公布接口,用户可以看到包括失物招领信息,报失物品信息,及留言板信息,进入信息查询接口,关闭接口只有鼠标点击右上角的关闭即可。
外部接口
失物招领管理系统与外部的交往繁多,管理人员要将最新的失物拾物信息以最快的速度更新,通过Internet网与外界紧密联系,以便让失主尽早看到。
由于系统在Internet上有自己的网址,各地的失主,拾到物品者或者游客也可以通过Internet了解失物或者拾到物品的处理信息,让物品的去处更加清楚。
内部接口
登录管理子系统和用户管理子系统共同使用保存管理员信息的一个数据库。
用户管理子系统对该数据库信息增加、删除和修改,而登录管理子系统只是对数据库进行查询。
,
失物信息管理子系统和信息公布管理子系统共同使用保存捡拾物品信息的一个数据库。
失物信息管理子系统对该数据库进行增加、删除和修改,信息公布管理子系统则是调用该数据库中的一部分信息和对该数据库进行查询。
4运行设计
运行模块组合
管理端运行模块
管理端运行在管理接口,显示失物信息,失主的报失信息,信息的公布。
管理员输入时启动接受数据模块,经过调用后,接受模块得到数据,将调用网络传输模块,将输入数据通过网络传送到服务器,并等待服务器返回信息。
接收到数据后,调用数据处理模块对数据库进行访问,随即调用数据输出模块,对信息进行处理,产生相应的输出。
网上用户端模块
网上用户接口,显示报失信息,信息公布等。
失主注册信息后可以发布自己的失物信息,数据经网络服务器接收,传送至接收模块。
接收到数据后,调用数据验证模块对数据库进行验证,完成后调用网络发送模块,将信息返回用户。
运行控制
【
客户端运行控制
在各模块中,需对运行控制进行正确的判断,选择正确的运行控制路径。
在网络传输时,用户端在发送数据后,将等待服务器的确认收到信号,收到后,再次等待服务器发送回答数据,然后对数据进行确认。
服务器在接到数据后发送确认信号,在对数据处理、访问数据库后,将返回信息送回用户端,并等待确认。
管理端运行控制
管理端发送资料后传输到服务器,服务器接到数据后对数据访问、处理,经过调用数据,将返回信息送回管理端。
运行控制将严格按照各模块间函数调用关系来实现。
运行时间
运行时间由计算机配置、程序编码的加载时间和数据调用时间等因素决定。
网络硬件对运行时间有最大的影响,当网络负载量大时,对操作反应将受到很大的影响。
所以将采用高速ATM网络,实现用户端与服务器之间的连接,以减少网络传输上的时间。
5系统数据结构设计
逻辑结构设计要点
【
登录记录
表名:
dy_sUserLogon
描述:
记录用户登录信息,主要包括用户ID和密码。
更新:
本表格的内容为自己维护。
字段
类型
名称
默认值
.
说明
UserID
typeid
用户ID
0000
管理员的工作号
UserName
Varchar(30)
$
用户描述
admin
管理员名称描述
UserPW
Varchar(30)
用户密码
0000
%
LogonDate
Datetime
最后登录时间
记录管理员最后一次登录这个系统的时间
UpdateDate
Datetime
最后数据更新时间
~
用户记录
表名:
dy_sUser
描述:
记录用户(管理员)的基本信息以便管理。
更新:
本表格的内容为自己维护。
字段
&
类型
名称
默认值
说明
UserID
typeid
用户ID
0000
*
管理员的工作号
UserName
Varchar(30)
用户描述
admin
管理员名称描述
UserPW
Varchar(30)
【
用户密码
0000
UserPhone
Varchar(30)
使用者的联系方式
管理员的电话号码,以便联系
!
UpdateDate
Datetime
最后数据更新时间
失物信息记录
表名:
dy_Pickgoods
$
描述:
记录捡拾物品的信息、捡拾人的信息和捡拾物品的存储时间和地点。
更新:
本表格的内容为自己维护。
字段
类型
名称
默认值
说明
pick_name
>
Varchar(30)
失物的名称
pick_trait
Varchar(30)
捡拾物品特点
、
捡拾物品特点描述
pick_place
Varchar(30)
捡拾地点
描述物品被捡到的地点
pick_time
Datetime
`
捡拾时间
描述物品被捡到的日期
pname
Varchar(30)
捡拾人名称
<
pcontact_way
Varchar(30)
捡拾人联系方式
store_place
Varchar(30)
物品存储地点
。
物品在失物招领中心存放的地点,以便领取时查找
sdate
Datetime
上交物品的日期
捡拾人把物品交到失物招领中心的时间
store_time
"
int
物品存储时间
0
物品在失物招领中心存放的时间,以便以后对物品进行处理
hand_way
Varchar(30)
物品的处理方式
·
物品最终的处理方式(领走或是捐赠)
报失信息记录
表名:
dy_Lostgoods
描述:
记录丢失物品的信息和失主信息。
更新:
本表格的内容为自己维护。
字段
类型
;
名称
默认值
说明
lost_name
Varchar(30)
报失物品名称
【
lost_trait
Varchar(30)
报失物品特点
报失物品特点描述
lost_place
Varchar(30)
丢失地点
。
空
若失主知道物品丢失的地点,则填写,否则不填
lost_time
Datetime
丢失时间
空
若失主知道物品丢失的时间段,则填写,否则不填
lname
%
Varchar(30)
报失人名称
lcontact_way
Varchar(30)
报失人联系方式
|
ldata
Datetime
报失日期
报失人向系统报失当天的日期
time
int
报失时间
0
报失信息存储时间,以便以后对报失信息进行处理
信息公布记录
表名:
dy_Public
描述:
记录留言信息。
更新:
本表格的内容为自己维护。
$
字段
类型
名称
默认值
说明
Information
Varchar(100)
留言
%
空
描述失主对捡拾人或失物招领中心的感谢,或是其他方面的建议,若没有则不填
物理结构设计要点
登录记录
表名:
dy_sUserLogon
描述:
记录用户(管理员)登录信息,主要包括用户ID和密码。
更新:
本表格的内容为自己维护。
字段
》
名称
存储要求
索引
说明
UserID
用户ID
存储类型根据管理员自己定义
有
—
UserName
用户描述
存储的是变长的字符
有
UserPW
用户密码
【
存储的是变长的字符
用户密码需要保密
LogonDate
最后登录时间
根据Datetime调用的函数,日期的存储格式有所不同,如()的默认格式为2010-10-614:
23:
33
,
UpdateDate
最后数据更新时间
根据Datetime调用的函数,日期的存储格式有所不同,如()的默认格式为2010-10-614:
23:
33
用户记录
表名:
dy_sUser
描述:
记录用户(管理员)的基本信息以便管理。
更新:
本表格的内容为自己维护。
字段
名称
存储要求
索引
说明
UserID
`
用户ID
存储类型根据管理员自己定义
有
UserName
用户描述
存储的是变长的字符
有
(
UserPW
用户密码
存储的是变长的字符
用户密码需要保密
UserPhone
使用者的联系方式
$
存储的是变长的字符(数字0-9)
UpdateDate
最后数据更新时间
根据Datetime调用的函数,日期的存储格式有所不同,如()的默认格式为2010-10-614:
23:
33
]
失物信息记录
表名:
dy_Pickgoods
描述:
记录捡拾物品的信息、捡拾人的信息和捡拾物品的存储时间和地点。
更新:
本表格的内容为自己维护。
字段
名称
存储要求
^
索引
说明
pick_name
捡拾物品名称
存储的是变长的字符(一般是汉字)
pick_trait
捡拾物品特点
存储的是变长的字符
有
捡拾物品特点描述
pick_place
捡拾地点
存储的是变长的字符
有
!
描述物品被捡到的地点
pick_time
捡拾时间
根据Datetime调用的函数,日期的存储格式有所不同,如()的默认格式为2010-10-614:
23:
33
描述物品被捡到的日期
name
捡拾人名称
¥
存储的是变长的字符
contact_way
捡拾人联系方式
存储的是变长的字符(数字0-9)
需要保密
%
store_place
物品存储地点
存储的是变长的字符
有
store_time
物品存储时间
存储的正整数
!
hand_way
物品的处理方式
存储的是变长的字符
有
[
报失信息记录
表名:
dy_Lostgoods
描述:
记录丢失物品的信息和失主信息。
更新:
本表格的内容为自己维护。
字段
名称
存储要求
索引
~
说明
lost_name
报失物品名称
存储的是变长的字符
lost_trait
报失物品特点
"
存储的是变长的字符
有
lost_place
丢失地点
存储的是变长的字符
有
|
lost_time
丢失时间
根据Datetime调用的函数,日期的存储格式有所不同,如()的默认格式为2010-10-614:
23:
33
name
失主名称
存储的是变长的字符
contact_way
失主联系方式
存储的是变长的字符(数字0-9)
time
报失时间
存储的正整数
有
信息公布记录
表名:
dy_Public
描述:
记录留言信息。
更新:
本表格的内容为自己维护。
字段
名称
存储要求
索引
说明
Information
留言
存储的是变长的字符
有
6系统出错处理设计
出错信息
程序在运行时主要会出现两种错误:
由于输入信息错误或输入方式无法满足要求时产生的错误。
须在操作成功判断及输入数据验证模块由数据进行数据分析,判断错误类型,再生成相应的错误提示语句,送到输出模块中。
2、由于其他问题,如网络传输超时等,产生的问题。
对于软错误,可在出错的相应模块中输出简单的出错语句,并将程序重置,返回输入阶段。
出错信息必须给出相应的出错原因。
补救措施
故障出现后可能采取的变通措施,包括:
a.当原始系统数据万一丢失时启用的副本的建立和启动的技术,例如使失物及相关信息可以随时存盘,最好能通过程序使之及时把信息记录到磁盘上去;
b.采取人工方式及时记录信息;
c.在网络传输方面,可考虑建立一条成本较低的后备网络,以保证当主网络断路时数据的通信。
在硬件方面要选择较可靠、稳定的服务器机种,保证系统运行时的可靠性。
系统维护设计
系统数据维护
维护方面可使用SQLSERVER的数据库维护功能机制。
例如,定期为数据库进行后备,维护管理数据库死锁问题和维护数据库内数据的一致性等。
安全保密设计
由于数据的传输上需要通过网络传输,为对用户数据进行保密,需要在网络的传输过程中对数据进行加密。
这个工作主要是准备网络包,及解开网络包这两个模块,它们各对数据进行加密及解密还原工作。
在加密算法选择上将使用RSA加密算法。