UML期末大作业(失物招领系统)

1/1UML期末大作业(失物招领系统)

U

M

L

设

计

性

实

验

报

告

校内失物招领系统

学院软件与通信工程学院

同学姓名刘洋学号0133620专业软件工程届别13级

指导老师廖汗成

二零一五年十二月十五日

名目

1、需求分析(3)

1.1开发背景及意义(3)

1.2系统功能及目标(3)

2、系统建模(4)

2.1创建系统用例模型(4)

2.1.1确定参加者(4)

2.1.2参加者用例(4)

2.1.3管理员用例图(7)

2.2创建系统静态模型(9)

2.2.1创建系统静态模型(9)

2.3创建系统动态模型(11)

2.3.1创建序列图(11)

2.3.2创建活动图(12)

2.3.3创建组件图(12)

2.3.4创建部署图(13)

3数据库设计(14)

3.1数据库设计的基本规范(14)

3.1.1开发规范(14)

3.1.2命名规范(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我发布过的寻物信息(17)

3.2.3.3我发布过的招领信息(17)

3.2.3.4我评论过的信息(17)

3.2.3.5我保藏的信息(17)

3.2.4发布寻物/招领信息(18)

4.后台管理(18)

4.1权限管理(18)

4.2物品类管理(18)

4.2.1物品所属类管理(18)

4.2.2物品管理(19)

4.2.3校区管理(19)

4.2.4拟定初始化物品类管理(19)

4.3订单管理(20)

4.3.1招领订单管理(20)

4.3.2寻物订单管理(21)

5.试验总结(22)

5.1UML建模总结(22)

5.2数据库设计总结(22)

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一般用户用例图

2.更改联系方式用例描述

3.拾物或者拾物信息发布

5.发表评论用例描述

2.1.3管理员用例图

管理员可以将用户设为管理员，对已发布信息进行增删查改，可以设置用户权限，删除评论，增加信息分类，发布通知公告。

用户列表

通知管理

图2-2管理员用例图

1.发布通知用例描述

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寻物信息列表

3.2.1.1寻物具体信息

显示用户点击进入寻物信息后列表呈现信息：

3.2.1.2寻物信息搜寻

3.2.2招领信息列表

招领模块下，根据时间降序排列出系统foundInfoList表的信息。

3.2.2.1招领具体信息

显示用户点击进入招领信息后列表呈现信息：

3.2.2.2寻物信息搜寻

3.2.3个人信息列表

3.2.3.1用户基本信息

3.2.3.2我发布过的寻物信息

显示我发布过得寻物信息列表，按时间降序排列

3.2.3.3我发布过的招领信息

点击进入某条记录显示此条记录招领具体信息。（删除？）3.2.3.4我评论过的信息

点击进入某条记录显示此条记录具体信息。（删除？）

3.2.3.5我保藏的信息

点击进入某条记录显示此条记录具体信息。（取消保藏？）

3.2.4发布寻物/招领信息

4.后台管理

4.1权限管理

4.1.1用户权限管理

●配置用户登录后台管理权限

●配置系统管理员修改基本表权限

●配置系统管理员对权限配置操作权限

4.2物品类管理

4.2.1物品所属类管理

包含物品类表的增删查改、分页操作。

4.2.2物品管理

二级列表物品大类选择：

三级列表物品名称列表，包含物品类表的增删查改、分页操作。

4.2.3校区管理

4.2.4拟定初始化物品类管理

4.3订单管理

4.3.1招领订单管理

二级菜单选择：

三级菜单数据显示：

包含订单的固定发布时间段查找、固定拾物时间段查找、信息标题及订单好查找、分页、排序操作。

物品具体信息显示：

4.3.2寻物订单管理

包含订单的固定发布时间段查找、固定拾物时间段查找、信息标题及订单好查找、分页、排序操作。

物品具体信息显示：

5.试验总结

5.1UML建模总结

UML是一种软件建模语言，可以对任何具有静态结构和动态行为的系统进行建模。在关注它建模特性的同时更要关注它的过程特性--在什么时间做什么工作，用什么模型，让哪些人来做。对系统用户而言，软件的开发模型向他们描述了软件开发者对软件系统需求的理解。让系统用户查看软件对象模型并且找到其中的问题，可以使开发者不至于从一开头就发生错误。对软件开发而言，软件的对象模型有助于他们对软件的需求以及系统的架构和功能进行沟通。

在UML建模过程中的一个体会,用例图是UML中最简洁也是最简单的一种图。说它简洁是由于它采纳了面对对象的思想，又是基于用户视角的，绘制特别简单，简洁的图形表示让人一看就懂。说它简单是由于用例图往往不简单掌握，要么过于简单，要么过于简洁。用例图表示了角色和用例以及它们之间的关系。类图可以关心我们更直观的了解一个系统的体系结构。通过关系和类表示的类图，可以图形化的方式描述一个系统的设计部分。在UML面对对象中，对象图是类图的实例，几乎使用与类图完全相同的标识。它们的不同点在于对象图显示类的多个对象实例，而不是实例的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。挨次图，描述了对象之间动态的交互关系，着重体现对象间消息传递的时间挨次。还有就是挨次图由一组对象构成，每个对象分别带有一条竖线，称作对象的生命线，它代表时间轴，时间沿竖线向下延长。UML面对对象中挨次图描述了这些