11组软件工程组队项目失物招领系统——项目汇总

Posted 2020-12-02 bit-1120161967

Github项目地址
https://github.com/ZZZ-JC/lost-and-found.git

 

需求规格说明书：

1      引言

1.1   编写目的

确定失物招领系统的功能、工作原理以及有效性需求，以标准的语言及表述方式整理系统需求，以供开发人员参考。

1.2   项目背景

在校园里，常常有人遗失物品或者捡到物品，但是他们没有一个良好的信息交流平台，只能在自己的朋友圈或者空间里求转发失物或者招领信息，这样的方式使得信息传递的速度非常慢，可能会使失主不能及时找到甚至找不到失物，给生活带来了极大的不便。

1.3   目标需求

本系统旨在方便失主寻找丢失物品、拾主归还捡拾物品，为失主和拾主搭建一个发布信息的平台，发扬拾金不昧的美好品德，体现大学生良好的个人修养。

1.4   约束与限制

前端：html+css+javascript Jquery必要的框架（bootstr/vue）（可以适配手机端的访问）

后端：SSM框架（javaweb）

数据库：mysql

服务器：Tomcat

1.5   术语

术   语	解    释
DFD	系统数据流图
浏览信息	浏览以某种顺序排列的多条只显示主要内容的信息
查看信息	仔细阅读某一条信息的详细内容
失主	丢失物品的用户
拾主	捡到物品的用户
失物信息	失主发布的寻找失物的信息
招领信息	捡物用户发布的寻找失主的信息
申请领回	失主发现招领信息后，申请领回对应物品
申请提供	拾主发现失物信息后，申请提供对应物品
提供申请	名词，属性为提供的申请
失主寻物	失主发现物品丢失后，通过系统寻找物品
拾物寻主	拾主捡拾到物品后，通过系统寻找失主

 

1.6   参考资料

《软件工程基础》 胡思康编著 清华大学出版社

《需求工程与建模》课件

 

2      需求描述

2.1   概述

系统主要分为失物管理、招领管理，并引入悬赏机制——积分，积分累计到一定数量后，可以用来兑换相应的小礼品。

普通用户在未登录时仅可浏览、输入关键词搜索、查看所有失物信息和招领信息。登录用户具有的操作：

• 申请失物，发布失物信息
• 提供拾物，发布所拾物品信息
• 为多人认领的失物提供第三方参考信息

2.2   功能描述

2.2.1 用户注册

用户通过邮箱和手机号进行注册，也可选择第三方账号（QQ，微信等）注册，注册时必须录入工号（学生对应学号/老师对应工号），一个工号只能注册一个账号。

2.2.2 用户权限管理

针对于平台用户（已注册），系统采取了权限分级制度。

整个系统中使用三个级别对用户权限进行管理（0、1、2级），不同权限的用户有不同的功能。

2级为普通用户，权限最低；该级用户在不同事件中可能扮演失主、拾主这两种不同的角色；该级用户可以搜索、查看所有失物信息和招领信息，也可以发布失物信息和招领信息，对自己发布的信息进行修改、撤回。若发现冒领情况，可进行举报。

1级为客服，权限较高；该级用户除2级用户功能外，还可以根据信息急迫程度、物品贵重程度等因素人工置顶或删除相关信息。可以审核举报。

0级为系统管理员，权限最高，该级用户除1级用户功能外，还可以进行用户管理、权限核查、处理举报、修改失物或招领信息状态等操作。

2.2.3 发布失物信息/发布招领（拾到物品）信息

用户在搜索匹配之后未找到所需信息的情况下，可自行发布失物或招领信息。需录入信息如下：

• 物品名称
• 丢失/捡拾时间
• 关键词（设置选项，自行选择）
• 物品图片
• 描述信息
• 积分数量
• 招领信息还需额外设置验证问题。

2.2.4 搜索匹配

用户发布失物/招领信息之后，系统可以根据物品所标注的关键词自动匹配相应的失物/招领信息。

2.2.5 申请失物领取

失主对已发布并且未被认领的招领物品申请领回。功能上允许多人对统一招领信息同时申请失物领取。

申请时需回答验证问题，回答正确后才可与拾主在线交流，进一步确认详细信息。若交流中发现错误，失主和拾主均可拒绝领回，只要有任何一方拒绝领回，则申请终止。若交流中核对成功，则在失主和拾主同时确认接受领回后，填写物品领取时间地点反馈给后台留档，领回行动开始。

最终领回行动结束后双方需在系统修改失物状态为已领回。

2.2.6 申请拾物提供

拾主可对已发布且未领回的失物信息提供拾物。功能上允许允许多人同时对一条失物信息申请拾物提供。

申请需要提供拾物照片，失物发布者收到申请后可以根据提供的照片选择是否接受申请。如果接受拾物提供申请则可以与提供者进行在线交流。

后续操作和“申请失物领回”阶段操作相同。

确认领回后，拾主会获得失主悬赏的“悬赏积分”，失主则会扣除等数量的“悬赏积分”。

2.2.7 积分兑换

注册用户的累积积分可以用来兑换礼品。积分的兑换设定如下：

2.2.8 失物/招领信息状态

失物/招领信息状态分为4种：

• 未发布
• 待申请
• 申请、
• 待领回
• 已领回

2.2.9 举报机制

若发现一条状态为已领回的信息出现冒领情况，普通用户可申请举报，由客服审核举报，若审核成功，由系统管理员处理举报。处理过程为给予冒领者警告或处分，扣除招领用户相应“悬赏积分”，将招领信息状态更改为“待领回”，并开通三方在线交流权限。之后失主可重新领回失物并确认领回，系统管理员在确认领回后收回权限。

举报信息状态分为未提交、待审核、待处理、处理中、已处理、无效。

2.3   用户描述

本系统的适用对象为普通用户（大部分为师生）、客服及管理员。

管理员对计算机熟练程度较高，操作能力等较强。

大部分普通用户对手机基本操作熟练程度较高，掌握注册、登录、填写信息、上传照片等基本操作。不排除部分用户对基本操作不熟悉。因此手机客户端应易操作性强，使所有普通用户能轻松操作此软件。此外，普通用户中可能包含留学生和外教，因此系统应支持英文版本。

客服对计算机及手机基本操作熟练程度较高，可能对个别操作不熟悉。所以客服端系统应易操作性强，使所有客服能够在培训后轻松使用此软件。

前期调查发现，大部分师生认为信息及时性及信息完善程度对失物招领系统来说至关重要，防止冒领现象、增添奖励机制也很有必要。

3      可行性分析

本系统是一个基于Java.Web结构的失物招领系统，采用面向对象技术、数据库技术等先进技术开发的应用程序，现有的开发技术已非常成熟，且被广泛应用于各行各业，利用现有技术完全可以达到功能目标。考虑开发期限较为充裕，预计可以在规定的时间内完成开发。

3.1 操作可行性

本系统的研制和开发充分考虑用户工作流程、计算机操作水平等，尽可能提供更人性化、直观的界面，满足用户要求。系统的操作方式在用户组织内可行。

3.2 经济可行性

本系统为公益性系统，不涉及盈利。

资金投入主要分为：

（1）   基本建设投资：

硬件设备：服务器；

开发环境（IDEA）：Intellij IDEA；

数据库管理系统：MySQL workbench；

前端框架：bootstrap；

后端开发模式：spring+mybatis

软件平台：Apache。

（2）   其他一次性支出：系统设计和开发费用。

（3）   非一次性支出：系统维护费用。

本系统将尽力减少人力、物力费用，缩短了操作时间，最大程度地提高工作效率和系统性能。

3.3 法律可行性

所建议系统的研制和开发都选用正版软件，将不会侵犯他人、集体和国家的利益，不会违反相关的国家政策和法律。

3.4 可行性结论

经上述可行性分析，系统的研制和开发可以立即开始进行。

4      数据流图

（1）数据流图0层

 

 

 

 

（2）数据流图1层

 

5      面向对象的需求分析与建模

5.1   功能模型——用例图

 

5.1.1 用例图综述

“失物招领系统”通过普通用户、客服和系统管理员共同完成，普通用户可在不同事件中可能扮演拾主和失主两种角色，为方便理解，图中将其分别描述。

普通用户主要通过系统完成失主寻物和拾物寻主两大过程，其中失主包括浏览失物信息，搜索失物信息，发布招领信息，接收/拒绝“申请提供”，在线交流的功能；而拾主则是与之对应的有浏览招领信息，搜索招领信息，发布失物信息，接收/拒绝“申请领回”，在线交流的功能。除此之外，任何用户都对可以进行举报

客服主要进行置顶或失物/招领信息处理操作和对举报的审核。系统管理员主要进行用户信息管理和对举报的处理，。

5.1.2 参与者

包括普通用户（失主、拾主）、客服、系统管理员，同时抽象出“用户”。系统管理员是一种特殊的客服。

5.1.3 用例

失主：注册、登录、浏览/搜索/失物信息、发布招领信息、修改招领信息、申请领回、接受/拒绝“申请提供”、在线交流、举报冒领；

拾主：注册、登录、浏览/搜索/招领信息、发布失物信息、修改失物信息、申请提供、接受/拒绝“提供领回”、在线交流、举报冒领；

客服：具有用户的所有用例、置顶失物/招领信息、管理失物/招领信息、处理举报信息；

系统管理员：具有客服的所有用例、用户信息管理

5.1.4 用例间关系

“用户信息管理”是“注册”的扩展；

“处理举报”是“举报冒领”的扩展；

“申请领回”是“浏览失物信息”的扩展；

“申请提供”是“浏览招领信息”的扩展；

“选择分类”是“搜索失物信息”和“搜索招领信息”的扩展；

“发布招领信息”包含“自动匹配”；

“发布失物信息”包含“自动匹配”；

“修改招领信息”是“发布招领信息”的扩展；

“修改失物信息”是“发布失物信息”的扩展；

5.1.5 用例描述

用例编号：UC01

用例名称：注册

参与者：用户

简要说明：用户输入自身信息注册账号。

基本事件流：用户输入用户名、密码、学号等信息。

扩展事件流：系统将其信息增添到用户信息库。

用户场景：注册成功/注册失败

关系描述：“用户信息管理”是“注册”的扩展。

前置条件： 无。

后置条件：无。

异常：若输入不符合条件则注册失败。

限制：必须填写完必填项，如用户名、密码、学号，且同一个用户名或工号不能重复注册，学号需要符合格式。

 

用例编号：UC02

用例名称：登录

参与者：用户

简要说明：用户输入用户名和密码登录账号。

基本事件流：用户输入用户名和密码进行登录，若登录成功则赋予对应权限。

扩展事件流：密码输入错误，弹出提示信息，重新登录。

用户场景：登录成功/登录失败

关系描述：“登录”用例包含“权限管理”用例。

前置条件：该用户已注册。

后置条件：无。

异常：若密码错误五次则登录失败，一小时内不可再次登录。

限制：必须输入用户名和密码。

 

用例编号：UC03

用例名称：举报冒领

参与者：用户

简要说明：。用户发现有其他用户冒领了自己的失物后，可举报冒领。

基本事件流：用户对已领回的信息进行举报，需填写举报理由和相关参考图片。

扩展事件流：无。

用户场景：举报提交成功/举报提交失败

关系描述：“处理举报”是“举报冒领”的扩展。

前置条件：举报的信息状态为已领回。

后置条件：无。

异常：无。

限制：无。

 

用例编号：UC04

用例名称：浏览招领信息

参与者：失主

简要说明：失主浏览多条招领信息的主要信息。

基本事件流：失主对多条招领信息的主要信息进行浏览，招领信息按发布时间排列，最新发布的信息在前。

扩展事件流：选择物品类别（如校园卡、电子设备等）。

用户场景：浏览到目标信息/没浏览到目标信息

关系描述：“申请领回”是“浏览招领信息”的扩展。

前置条件：无。

后置条件：无。

异常：无。

限制：无。

 

用例编号：UC05

用例名称：申请领回

参与者：失主

简要说明：失主看到目标招领信息后，申请领回此信息中的物品。

基本事件流：失主点击“申请领回”按钮后，回答拾主设置的验证问题，若回答正确，则获得在线交流的权限，招领信息状态转换为申请中状态。

扩展事件流：无

用户场景：获得在线交流的权限/未获得在线交流的权限

关系描述：“申请领回”是“浏览招领信息”的扩展。

前置条件：该用户已登录。

后置条件：无。

异常：无。

限制：无。

 

用例编号：UC06

用例名称：搜索失物信息

参与者：失主

简要说明：失主根据关键词搜索相关失物信息。

基本事件流：失主输入关键词搜索相关失物信息，搜索结果按符合关键词数量排列，符合更多关键词的信息在前，相同数量按发布时间排列。

扩展事件流：无

用户场景：搜索到目标信息/没搜索到目标信息

关系描述：“选择分类”是“搜索失物信息”的扩展。

前置条件：无。

后置条件：无。

异常：无。

限制：至少输入一个关键词。

 

用例编号：UC07

用例名称：发布招领信息

参与者：失主

简要说明：失主丢失物品后发布失物信息。

基本事件流：失主点击“发布失物信息”按钮后，录入信息主题、分类、详细描述、悬赏数量等；若点击“确认发布”按钮，则信息发布，信息状态为待申请信息；若点击“保存”按钮，则信息不发布，信息状态为未发布信息。发布后，系统根据关键词自动匹配并罗列相关招领信息，匹配程度越高越靠前。发布前后都可以修改或删除此条信息。

扩展事件流：无。

用户场景：发布成功匹配成功/发布成功匹配失败/发布失败/保存成功/保存失败

关系描述：“发布招领信息”用例包含“自动匹配”用例，有扩展用例“修改招领信息”。

前置条件：该用户已登录。

后置条件：无。

异常：无。

限制：必须填写必填项，如信息主题、分类、详细描述、悬赏数量等。

 

用例编号：UC08

用例名称：浏览招领信息

参与者：拾主

简要说明：拾主浏览多条招领信息的主要信息。

基本事件流：拾主对多条招领信息的主要信息进行浏览，默认按悬赏排列，悬赏越高越前。

扩展事件流：选择物品分类（如卡、电子设备等）、排列方式（发布时间或悬赏）。

用户场景：浏览到目标信息/没浏览到目标信息

关系描述：“申请提供”是“浏览招领信息”的扩展。

前置条件：无。

后置条件：无。

异常：无。

限制：无。

 

用例编号：UC09

用例名称：申请提供

参与者：拾主

简要说明：拾主看到目标招领信息后，申请提供此信息中的物品。

基本事件流：拾主点击“申请提供”按钮后，录入物品照片等信息，等待失主接受或拒绝申请。

扩展事件流：失主接受或拒绝前，拾主可撤回申请。

用户场景：等待失主接受或拒绝申请

关系描述：“申请提供”是“浏览招领信息”的扩展。

前置条件：该用户已登录。

后置条件：无。

异常：无。

限制：必须录入所拾物品的照片。

 

用例编号：UC010

用例名称：搜索招领信息

参与者：拾主

简要说明：失主根据关键词搜索相关招领信息。

基本事件流：失主输入关键词搜索相关招领信息，搜索结果按符合关键词数量排列，符合更多关键词的信息在前，相同数量按发布时间排列。

扩展事件流：无

用户场景：搜索到目标信息/没搜索到目标信息

关系描述：“选择分类”是“搜索招领信息”的扩展。

前置条件：无。

后置条件：无。

异常：无。

限制：至少输入一个关键词。

 

用例编号：UC11

用例名称：发布失物信息

参与者：拾主

简要说明：拾主捡拾到物品后发布招领信息。

基本事件流：拾主点击“发布招领信息”按钮后，录入信息主题、分类、关键词、物品照片等。录入完毕后，若点击“确认发布”按钮，则信息发布，信息状态为待申请信息；若点击“保存”按钮，则信息不发布，信息状态为未发布信息。发布后，系统根据关键词自动匹配并罗列相关失物信息，匹配程度越高越靠前。

扩展事件流：无。

用户场景：发布成功匹配成功/发布成功匹配失败/发布失败/保存成功/保存失败

关系描述：“发布失物信息”用例包含“自动匹配”用例，有扩展用例“修改失物信息”。

前置条件：该用户已登录。

后置条件：无。

异常：无。

限制：必须填写必填项，如信息主题、分类、关键词、物品照片等。

 

用例编号：UC12

用例名称：接受/拒绝“提供申请”

参与者：失主

简要说明：失主收到拾主的“提供申请”后，选择接受或拒绝此申请。

基本事件流：失主查看拾主提供的照片和其他信息，根据自身情况选择接受或拒绝此申请；若接受，则双方获得在线交流权限，失物信息状态转换为申请中。

扩展事件流：无

用户场景：接受“提供申请”/拒绝“提供申请”

关系描述：无。

前置条件：该用户已登录。

后置条件：无。

异常：无。

限制：无。

 

用例编号：UC13

用例名称：在线交流

参与者：失主和拾主

简要说明：。失主和拾主在线交流。

基本事件流：失主和拾主在线进行交流确认失物情况。

扩展事件流：无。

用户场景：失主与拾主想确认失物/招领情况。

关系描述：无。

前置条件：该用户已登录。

后置条件：无。

异常：无。

限制：无。

 

5.1.6 其他描述

因为系统管理员是一种特殊的客服，所以他拥有客服的全部功能，但在此用例图中相同功能被省略，用泛化关系来表示。

5.2   静态模型

5.2.1 类图

 

（1）类图综述

本类图描述了“失物招领系统”业务逻辑中所包含的，初步的类、接口及类间关系。类的识别过程及类间关系识别过程详见“静态模型建模过程”。

（2）类描述

本系统中，主要分为两个大类，即“用户”类与“事件”类，“用户”类包含所有用户的数据及用户支持的相关操作和接口。“事件”类为基类，它派生出“申请失物”事件与“提供拾物”事件。

详见下表：

 

类	属性	服务	关联、泛化、依赖描述
用户	用户Id 密码hash值 用户名 学校 学号 积分 联系方式	注册 登陆 修改个人信息 浏览事件 搜索信息 与其它用户沟通 发布申请失物事件 发布提供拾物事件 接受、拒绝领回物品 确认、撤回领回物品 提交举报	关联->事件 依赖->申请失物 依赖->提供拾物 依赖->举报 派生->客服
事件	事件id 物品 失主id 拾主id 举报信息	修改事件信息 修改举报列表	关联->用户 派生->申请失物 派生->提供拾物
申请失物事件	申请id 申请者id 申请描述 申请状态 提供者id	创建申请信息 修改申请信息 删除申请信息 查询申请信息 查询申请状态	泛化->事件
提供拾物事件	提供id 提供者id 提供描述 提供状态 申请者id	创建提供信息 修改提供信息 删除提供信息 查询提供信息 查询提供状态	泛化->事件
举报	举报id 举报者id 举报事件id 举报描述 举报状态	创建举报信息 修改举报信息 查询举报信息	依赖->用户
物品	物品id 物品名称 物品图片 物品描述 物品保密描述 发现时间 发现地点	修改物品信息 查询物品信息
客服		审核提供信息 审核申请信息 审核举报信息 分类信息管理 删除事件信息 置顶事件信息 删除举报信息	泛化->用户 派生->管理员
管理员		用户信息管理	泛化->客服

（3）关联描述

类“用户”与类“信息”之间互相关联，由于一个用户可能对应0或多个失物、招领信息，而一个失物招领信息可能对应一个或多个用户，故其相互关联分别为0..* 、 1..* 类型。

（4）泛化描述

类“用户”的派生类为“普通用户”、“客服”。而“普通用户”类派生出“失主”和“拾主”类；“客服”又派生出“管理员”类，换而言之，“管理员”相当于提升权限、增加操作类型的客服类。对于某一个特定的事件，某位用户可派生为一个特定的身份，该用户可能在某个事件中扮演“失主”，而在另一事件中扮演“拾主”的身份，而且某一用户可能同时扮演“管理员”和“拾主”两个身份，故“用户”的派生结果是不完全泛化。

（5）依赖描述

类“举报”和接口“结算事件”由于需要对用户进行数据修改、结算操作，故，“用户“和”结算事件“、”举报“被设计为依赖类型。

 

5.2.2 包图

 

包图概述

本文档描述了“失物招领系统”中所包含的初步的包图。包括“用户界面”、“业务逻辑”、“用户接口”、“数据库”四个包及保健关系。其中用户界面与业务逻辑之间存在依赖关系，业务逻辑、用户接口与数据库存在依赖关系，同时，用户接口与业务逻辑之间存在依赖关系。

5.3   动态模型

5.3.1 登录

 

 

活动图综述：描述了“登录”的活动图，涉及普通用户、客服和管理员三个对象。

参与者对象描述：“普通用户”、“客服”和“管理员”都是参与者，他们都能实现登录操作。

状态描述：用户在登录系统时，若无账号，则需先注册，然后登录，否则直接登录，系统确认账号和密码无误后登录成功。

转换描述：在“登录”活动中，有一个分支控制：三种用户在登录此系统时，若已有账号，则直接登录；若无账号，则需先注册，然后再登录。

其他描述：无。

5.3.2 失主寻找物品过程

（1）状态图

 

 

状态图综述：上图描述了“失物信息”对象的状态变化。

状态描述：状态图中描述了“失物信息”的“空白”、“未发布”、“待申请”、“申请中”、“待领回”、“已领回”、“举报中”7个状态。“空白”是描述失物信息的初始过程；“未发布”描述失物信息正处于完善信息的过程中；“待申请”描述失物信息已发布，但失主没有接受任何“提供申请”；“申请中”描述失主已接受“提供申请”，并与拾主在线交流的过程；“待领回”描述失主和拾主经过在线交流后均接受领回，但还未真正领回时的失物信息的状态；“已领回”描述失主和拾主通过见面，最终确认并真正领回物品后的失物信息的状态。

状态转换描述：“物品信息”触发失物信息由“空白”转换为“未发布”；“确认发布”触发失物信息由“未发布”转换为“待申请”；“接受申请”触发失物信息由“待申请”转换为“申请中”；若任何一方“拒绝领回”，触发失物信息由“申请中”转换为“待申请”，若双方均“接受领回”，触发失物信息由“申请中”转换为“待领回”；若任何一方“撤回领回”，触发失物信息由“待领回”转换为“待申请”，若双方均“确认领回”，触发失物信息由“待领回”转换为“已领回”

其他描述：若信息处于“待申请”、“申请中”、“待领回”状态，其他普通用户均可对此信息申请提供。

 

 

 

状态图综述：上图描述了“招领信息”对象的状态变化。

状态描述：状态图中描述了“招领信息”的“空白”、“未发布”、“待申请”、“申请中”、“待领回”、“已领回”、“举报中”7个状态。“空白”是描述招领信息的初始过程；“未发布”描述招领信息正处于完善信息的过程中；“待申请”描述招领信息已发布，但还没有人回答正确验证问题；“申请中”描述已有人回答正确验证问题，并与拾主在线交流的过程；“待领回”描述失主和拾主经过在线交流后，均接受领回，但还未真正领回时的招领信息状态；“已领回”描述失主和拾主通过见面，真正领回物品，并均确认领回后的招领信息的状态。

状态转换描述：“物品信息”触发招领信息由“空白”转换为“未发布”；“确认发布”触发招领信息由“未发布”转换为“待申请”；“回答正确验证问题”触发招领信息由“待申请”转换为“申请中”；若任何一方“拒绝领回”，触发招领信息由“申请中”转换为“待申请”，若双方均“接受领回”，触发招领信息由“申请中”转换为“待领回”；若任何一方“撤回领回”，触发招领信息由“待领回”转换为“待申请”，若双方均“确认领回”，触发招领信息由“待领回”转换为“已领回”

其他描述：若信息处于“待申请”、“申请中”、“待领回”状态，其他普通用户均可对此信息申请领回。

（2）活动图

 

 

活动图综述：描述了“失主寻物”的活动图，涉及失物用户、拾物用户和系统三个对象，他们共同完成失主寻物的过程。

参与者对象描述：“失物用户”和“拾物用户”是参与者，“系统”是对象。系统负责生成不同时期失物/招领信息的不同状态。

状态描述： 失物用户找到相应招领信息后“申请领回”并“回答验证问题”，或是“发布”失物信息等待系统“匹配”或拾物用户“申请提供”，确认基本信息无误后“在线交流”、“见面”进一步确认，然后“领回失物”， “确认领回”后拾物用户“获得悬赏”，系统“将失物/招领信息状态转为已领回”。

转换描述： 在“失主寻物”活动中，有八个分支控制：一是在失物用户浏览招领信息后，发现了对应招领信息申请领回失物；或是未发现招领信息新建失物信息。二是失物用户发布失物信息后，若系统有自动匹配成功的招领信息则直接申请领回；否则等待拾物用户查看。三是拾物用户查看失物信息后，若发现基本信息相符则申请提供；否则继续查看。四是失物用户收到提供的拾物信息后，若发现信息相符就接受提供申请，系统将失物信息状态转为申请中；否则等待下一个申请。五是失物用户在回答验证问题后，若答案正确，则系统将招领信息状态转为申请中；否则失物用户继续浏览招领信息。六是失物用户和拾物用户在线交流后，若接受领回则系统将失物/招领信息状态转为待领回；否则系统将失物/招领信息状态转为待申请。七是系统将失物/招领信息状态转为待申请后，失物用户若已发布过失物信息，则等待拾物用户提供申请；否则继续浏览招领信息。八是失物用户与失物用户见面交流确认后，若确定无误，则失物用户领回失物；否则系统将失物/招领信息状态转为待申请，失物用户继续浏览招领信息或等待拾物用户提供申请。

其他描述：拾物寻主的过程与此类似。

 

（3）顺序图

 

 

顺序图综述：该顺序图描述了失主通过招领信息寻物的过程。涉及失主、拾主、招领信息和积分四个对象。

参与者对象描述：“失主”和“拾主”是两个参与者，“招领信息”和“积分”是两个对象。招领信息负责实现联系失主和拾主的逻辑操作，包括向失主发送验证问题、对拾主的联系权限和更新自身状态。积分负责接收招领成功信息并向拾主发送奖励。

消息描述：拾主捡到失物后，在无失物信息的情况下，发布招领信息。失主看到招领信息后申请领回，并得到招领信息返回的，由拾主依据失物特征设置的“验证问题”。失主回答正确后，招领信息状态转换为“申请中”并赋予失主“与拾主在线交流权限”。失主和拾主进入在线交流状态，进一步确认失主的身份及交换失物的“交接时间、地点”。其间，如果发现信息不相符，双方均可以选择拒绝领回，若有任何一方拒绝领回，招领信息状态改回 “待申请”。在失主领回失物后，失主和拾主都向招领信息发送“确认领回”信息，招领信息在收到双方的“确认领回”信息后，状态转换为“已领回”并将“招领成功”信息发至系统，由系统将“奖励”发送给拾主。

其他描述：无。

 

 

 

顺序图综述：该顺序图描述了失主通过失物信息寻物过程。涉及失主、拾主、失物信息和积分四个对象。

参与者对象描述：“失主”和“拾主”是两个参与者，“失物信息”和“积分”是两个对象。失物信息负责实现联系失主和拾主的逻辑操作，包括向失主发送拾物通知、向拾主发送对失主的联系权限和更新自身状态。积分负责接收招领成功信息并向拾主发送奖励。

消息描述：失主在无招领信息的情况下，发布失物信息。拾主捡到失物并看到失物信息后申请提供，失物信息将“提供申请”推送给失主，失主如果选择“接受提供申请”，失物信息状态转换为“申请中”并赋予拾主“与失主在线交流权限”。失主和拾主进入在线交流状态，进一步确认拾主捡到的失物是否为失主丢失及交换失物的“交接时间、地点”。如果发现信息不相符，双方均可以选择拒绝领回，若有任何一方拒绝领回，招领信息状态改回 “待申请”。。在失主领回失物后，失主和拾主都向失物信息发送“确认领回”信息，失物信息在收到双方的“确认领回”信息后更改自身状态为“已领回”并将“领回成功”信息发至系统，由系统将“奖励”发送给拾主。

其他描述：无。

5.3.3 举报

（1）状态图

 

状态图综述：上图描述了“举报信息”对象的状态变化。

状态描述：状态图中描述了“举报信息”的“空白”、“未提交”、“待审核”、“待处理”、“处理中”、“已处理”、“无效”7个状态。“空白”是描述举报信息的初始过程；“未提交”描述举报信息正处于完善信息的过程中；“待审核”描述举报信息已提交，等待客服审核的过程；“无效”描述客服审核未通过后的举报信息的状态；“待处理”描述客服已审核通过，等待系统管理员处理的过程；“处理中”描述举报信息正在处理，失主重新领回失物的过程；“已处理”描述举报信息已处理完毕，失主已重新领回失物。

状态转换描述：“详细信息”触发举报信息由“空白”转换为“未提交”；“确认提交”触发举报信息由“未发布”转换为“待审核”；“审核未通过”触发举报信息由“待审核”转换为“无效”；“审核通过”触发举报信息由“待审核”转换为“待处理”；“开始处理”触发举报信息由“申待处理”转换为“处理中”；“处理完毕”触发举报信息由“处理中”转换为“已处理”。

其他描述：无。

 

（2）活动图

活动图综述：描述了“举报”的活动图，涉及普通用户、客服和管理员三个对象。

参与者对象描述：“普通用户”、“客服”和“管理员”都是参与者，他们共同完成举报操作。

状态描述：用户发现冒领现象后发送“申请举报”命令并确认，客服“审核举报”，审核通过后管理员“处理举报”，处理完成后正确的失物用户可领回失物。

转换描述：在“举报”活动中，有两个分支控制： 一是用户申请举报后，可确认继续举报并由客服审核举报；或是取消举报。二是客服审核举报后，可确定审核不通过；或是通过并由管理员处理举报。

其他描述：无。

 

（3）顺序图

 

顺序图综述：该顺序图描述了“处理举报”的过程，以举报招领信息为例。涉及失主、拾主、冒领用户、客服、管理员和招领信息七个对象。

参与者对象描述：“失主”、“拾主”、 “冒领用户”、“客服”和“管理员”是五个参与者，“招领信息”是一个对象。招领信息负责实现向失主提供当前失物招领活动的编号，并接收失主的确认领回信息。

消息描述：失主在看到并确认自己的失物被冒领的情况下，将“招领编号”和“投诉理由”发送给客服，并由客服进行人工处理，如果审核通过，就将“失主ID”，“拾主ID”和“冒领用户ID”发送给管理员，由管理员授权给予三人在线交流的权限，并将招领信息状态更改至“待领回”，对冒领用户进行“警告或处分”，并撤销拾主在本次活动中获得的“奖励”。在三人协商完毕后，冒领用户将“交接时间、地点”发送给失主，并交还失物。失主在领回失物后将“确认领回”信息重新发送至招领信息，招领信息更新自身状态至“已领回”，本次活动结束。

其他描述：无。

6     非功能性需求

非功能需求调查表
可靠性
安全性	系统数据的敏感程度	保密
	系统运行环境	Internet，公用服务器，分布式应用，服务器版
	客户组织中的信息保密制度	用户可自由选择将部分信息公开或者隐藏，保证不会泄露隐私信息。
	使用人员	普通用户、客服、管理员（基本均为师生）
事务性	系统业务交叉程度	交叉程度较高
	数据精度要求	精度要求一般
	业务是在线的还是离线的	在线的
	系统集成情况	集成度一般
	是分布式系统还是集成式系统	分布式系统
稳定性	系统的服务能力要求	7*24小时不间断服务
	用户的操作频率	平均每周四次
	业务的及时性	及时性高
	数据的重要程度	重要程度较高
可用性
界面	客户的行业性质	师生为主
	客户的企业文化	年轻人为主
	客户业务的复杂程度	复杂度不高
	使用人员的情况	计算机素质较高
操作习惯	客户之前使用的系统	如QQ、微信之类的系统
	客户喜欢的操作风格	菜单、按钮
文档要求	客户需要联机文档吗	需要
	客户需要在线帮助吗	不需要
	客户的计算机操作水平	较高
有效性
性能	系统的平均访问量	每天800
	系统的峰值访问量	每小时100
	系统的数据流量	同时间数据数量不超过10万
	系统的进发要求	允许同一时间内不超过100个人访问者对同一资源进行访问
	硬件环境	内存：2GM； CPU：Intel  Core2  1.80GHz
可伸缩性	客户业务预期的扩张速度	基本不变
	客户数据量的扩张速度	一般
	使用人数的扩张速度	前一个星期较快，一个月内逐步放缓，然后平均每天新增10人
可扩展性	系统规模会持续扩大吗	有可能
	客户是否有长期系统建设的计划	有
	客户有升级系统的长期计划吗	有
可移植性
硬件环境	客户当前硬件环境	符合此系统要求
	客户是否有长期的硬件厂商合作伙伴	有
	客户的业务是否在快速增长	基本无增长
软件环境	客户和系统的运行环境	Windows
	客户是否有长期的软件提供商	有
	自己是否有长期明确的技术路线	有

 

 

构件图

 

 

 

综述：“学生失物招领系统”构件图描述了实现系统的源程序之间的依赖关系。在“信息查询”包中，“信息查询”通过“失物查询”、“用户查询”和“招领查询”构件的支持，可以实现用户的信息查询；“失物管理”通过调用不同构件的支持，实现用户对系统的相关操作；2级用户可以搜索、查看所有失物信息和招领信息，也可以发布失物信息和招领信息，对自己发布的信息进行修改、撤回。若发现冒领情况，可进行举报。1级用户根据信息急迫程度、物品贵重程度等因素人工置顶或删除相关信息，可以审核举报；0级用户可以通过“系统管理”包对系统进行用户管理、权限核查、处理举报、修改失物或招领信息状态等操作。“系统管理”需要“物品审核”、“权限管理”、“用户信息管理”等不同构件的支持。所有包的首先均需要“数据服务”的支持。

构件描述：“信息查询”包负责查询用户所需信息，“失物管理”包负责“挂失物品”的申请、选定、反馈、举报等功能的实现，“系统管理”负责实现对整个系统相关信息的管理操作，“2级、1级用户界面”负责传递“信息查询”和“失物管理”所需的参数，“0级用户界面”则提供“信息查询”、“失物管理”和“系统管理”所需的参数，“数据服务”通过已有的数据库管理系统所需对数据库进行SQL查询和修改的功能。

构件间关系：“信息查询”包与“2级用户界面”是实现依赖关系，必须由“2级用户界面”提供进行查询的相关参数，如失物地点、时间等查询条件，“信息查询”才能利用“数据服务”的支持获取相关信息。“课程管理”包和三级用户界面都属于实现依赖关系，“课程管理”依赖于三个界面提供进行相关课程操作的参数，如失物类型、反馈类型等。“系统管理”包与“0级用户界面”同样是实现依赖关系，对系统的管理高度依赖管理员的介入，需要提供“0级用户界面”传递大量操作参数，同时，“系统管理”部分功能的实现也依赖于“失物管理”包的支持 “信息查询”包、“失物管理”包和“系统管理”包都与“数据服务”有使用依赖关系，三个包均依赖“数据服务”提供的支持间接实现对数据库的查询和修改。

其它描述：无。

 

配置图及文档

构建图说明文档：

综述：“失物招领系统”配件图描述了软件系统在硬件系统中的部署。配置图说明系统采用三层逻辑结构。“客户端”是应用界面层，部署三级权限用户操作界面（管理员，客服，用户），不同的权限对应不同的功能。“功能逻辑服务器”是逻辑应用层，实现系统的主要功能：失物管理，信息查询，系统管理。“数据库服务器”是数据服务层，提供对数据（失物信息，事件信息，客户信息等）的关系管理。

节点描述：主要有三个节点，分别是“客户端”“功能逻辑服务器”“数据库服务器”，节点里的配置描述如下：“二级用户界面”即“普通客户”，负责传递“失物管理”和“信息查询”所需的参数；“一级用户界面”即“客服”，则提供“失物管理”所需的相关参数；“零级用户界面”，即“管理员”，则负责提供“系统管理”的相关参数以及管理和控制；“数据服务”通过已有的数据库管理系统对数据库进行SQL查询修改和删除的功能；“信息查询”负责查询失物的相关所有信息；“失物管理”负责失物的提交，申请等功能的实现；“系统管理”负责实现对系统相关信息的管理。

节点关系描述：在各节点间，“客户端”和“功能逻辑服务器”之间是实现依赖关系，“功能逻辑服务器”里的“信息查询”和“失物管理”功能都需要客户端用户进行实现，普通用户进行失物查询，申请，举报等功能，客服则实现审核，失物信息发布及管理反馈意见等功能。“功能逻辑服务器”和“数据库”服务器是依赖关系，“功能逻辑服务器”里的数据支持来自数据库。

 

以下是图片原型：

包图

登录活动图

举报活动图

举报顺序图

举报状态图

类图

失物申请顺序图

 

失物信息状态图

失物寻物活动图

 

拾物提供顺序图

 

数据流图0层

数据流图1层

用例图

招领信息状态图