标签：数据项 失主 导论 用户 信息 拾遗 软件工程 失物 失物招领
实验一 软件需求描述
1.1 系统需求描述
失主：注册、登录系统，系统审核信息有效性，有效性是指提供的学号姓名学号联系方式是否符合规格，审核通过则注册、登录成功；进入系统后，失主可以通过拾遗者提供的失物信息表查找，通过描述细化失物的范围，系统会返回查找到失物会联系拾遗者领回，查找失败后会记录在失物登记表。
拾遗者：注册、登录系统，系统审核信息有效性，有效性是指拾遗者提供的姓名学号联系方式等是否正确符合规格。审核通过则注册、登录成功；进入系统后，拾遗者上传提供失物的信息，系统审查信息的有效性，有效性是指捡到的失物是否符合基本的失物特征，保证不能出现除了失物以外的其他信息，审查成功后失物信息将发布到失物信息表上，系统对拾遗者发布的信息进行分类整理后，返回发布信息成功通知单给拾遗者。
管理员：注册、登录系统，系统审核信息有效性，有效性是指管理员提供的姓名联系方式等是否正确符合规格。审核通过则注册、登录成功；进入系统后，管理员可以修改失主和拾遗者的信息。
失物招领管理系统：具有三个功能分区，分别是：用户管理、失物查询、失物发布；用户管理功能实现每一位使用系统的用户都需要先注册、登录再进入系统；其次提供了管理员可以修改用户信息的功能。失物查询功能实现了失主查询失物的功能，并且可以实现审查信息的有效性并提供找回失物的方式。失物发布功能实现了发布失物信息并且审查拾遗者发布信息的有效性。
1.2 系统相关者
失主、拾遗者、管理员
1.3 数据流分析
（1） 顶层DF
失物招领顶层数据流图如图1.1所示。
图1.1 失物招领系统顶层DFD
（2） 功能层DFD如图1.2所示。
图1.2 功能层DFD
（3） 细节层DFD失物查询层的DFD分解层如图1.3所示。
图1.3 失物查询层DFD分解
（4） 失物发布层的DFD分解层如图1.4所示。
图1.4 失物发布层DFD分解
（5）用户管理层的DFD分解层如图1.5所示。
图1.5 用户管理层DFD分解
1.4 数据字典
（1） 数据项定义
账号的数据项定义如表1.1所示。
表1.1 数据项“账号”的条目
|
数据项名：账号 |
|
别名：登陆账号 |
|
取值范围及含义： 00000~99999 按照注册的顺序分发账号 |
|
备注：每个用户在登录系统时应该用账号登录 |
密码的数据项定义如表1.2所示。
表1.2 数据项“密码”的条目
|
数据项名：密码 |
|
别名：登录密码 |
|
取值范围及含义： 1 {字符} 20 （数字+字符） |
|
备注：每个用户的账号和密码必须一一对应的用于登录系统 |
姓名的数据项定义如表1.3所示。
表1.3数据项“姓名”的条目
|
数据项名：姓名 |
|
别名：真实姓名 |
|
取值范围及含义： 1 {字符} 10 （汉字） |
|
备注：代表的是登录用户的真实姓名 |
类型的数据项定义如表1.4所示。
表1.4 数据项“类型”的条目
|
数据项名：类型 |
|
别名：用户类型 |
|
取值范围及含义： A B C |
|
备注：A代表的是失主 B代表的是拾遗者 C代表的是管理员 |
联系方式的数据项定义如表1.5所示。
表1.5 数据项“联系方式”的条目
|
数据项名：联系方式 |
|
别名：手机号码 |
|
取值范围及含义： 00000000000~9999999999 |
|
备注：代表的是用户的电话联系方式，必须是十一位有效的数字 |
地点的数据项定义如表1.6所示。
表1.6 数据项“地点”的条目
|
数据项名：地点 |
|
别名：物品丢失/捡拾地点 |
|
取值范围及含义： 1 {字符} 20（汉字字符） |
|
备注：代表的是失物的丢失地点或者捡到地点 |
名称的数据项定义如表1.7所示。
表1.7 数据项“名称”的条目
|
数据项名：名称 |
|
别名：失物名称 |
|
取值范围及含义： 1 {字符} 10（汉字字符） |
|
备注：代表的是失物的名字 如：耳机、项链、手表等等 |
时间的数据项定义如表1.8所示。
表1.8 数据项“时间”的条目
|
数据项名：时间 |
|
别名：丢失时间/捡拾时间 |
|
取值范围及格式： “00：00”…“23：59” |
|
备注：代表的是失主丢失失物的时间或者拾遗者捡到物品的时间，规定必须用“：”间隔开。 |
细节描述的数据项定义如表1.9所示。
表1.9 数据项“细节描述”的条目
|
数据项名：细节描述 |
|
别名：失物具体细节描述 |
|
取值范围及含义： 1 {字符} 30（汉字字符） |
|
备注：代表的是失物的具体细节的描述 |
学号的数据项定义如表1.10所示。
表1.10 数据项“学号”的条目
|
数据项名：学号 |
|
别名：失主和拾遗者的学号 |
|
取值范围及含义： 20000000~25000000 |
|
备注：代表的是学生入学年份和身份标识，一共八位学号，包括入学年份（4位）+学生序号（4位） |
年的数据项定义如表1.11所示。
表1.11 数据项“年”的条目
|
数据项名：年 |
|
别名：年份 |
|
取值范围及含义： 2000~2500 |
|
备注：代表的是失物丢失的年份 |
月的数据项定义如表1.11所示。
表1.12 数据项“月”的条目
|
数据项名：月 |
|
别名：月份 |
|
取值范围及含义： 1~12 |
|
备注：代表的是失物丢失的月份 |
日的数据项定义如表1.13所示。
表1.13 数据项“日”的条目
|
数据项名：日 |
|
别名：日期 |
|
取值范围及含义： 1~31 |
|
备注：代表的是失物丢失的日期 |
昵称的数据项定义如表1.14所示。
表1.14 数据项“昵称”的条目
|
数据项名：昵称 |
|
别名：用户昵称 |
|
取值范围及含义： 1 {字符} 10（汉字字符） |
|
备注：代表的是用户在系统中的称呼 |
（2）数据流定义
领回通知单的数据流定义如表2.1所示。
表2.1 数据流“领回通知单”的字典条目
|
数据流名：领回通知单 别名 ： href="https://cn.bing.com/dict/search?q=Claim&FORM=BDVSP6&cc=cn" Claim notification form 数据流的来源：加工1.5领回失物 数据流的去向：拾遗者 数据流组成：名称+地点+细节描述+昵称+学号+联系方式+时间 备注：无 |
用户信息单的数据流定义如表2.2所示。
表2.2 数据流“用户信息单”的字典条目
|
数据流名：用户信息单 别名 ：User information form 数据流的来源：3.3用户信息管理、3.2用户信息分类 数据流的去向：管理员 数据流组成：昵称+学号+联系方式+账号+密码 备注：无 |
发布成功通知单的数据流定义如表1.3所示。
表2.3 数据流“发布成功通知单”的字典条目
|
数据流名：发布成功通知单 别名 ：Publishing href="https://cn.bing.com/dict/search?q=success&FORM=BDVSP6&cc=cn" success notification form 数据流的来源：2.3系统分类管理 数据流的去向：拾遗者 数据流组成：名称+地点+细节描述+时间 备注：无 |
（3）数据存储
失物信息表的数据存储如表1.3所示。
表2.4 数据存储“失物信息表”的字典条目
|
数据存储名称：失物信息表 |
|
编号：F1 |
|
简述：是经过按拾遗者提供的失物信息统计得到的失物信息表 |
|
流入的数据流：来源于拾遗者填写提供的失物信息 |
|
流出的数据流：去向是失主查询失物信息 |
|
数据存储组成：名称+地点+细节描述+昵称+学号+联系方式+时间 |
|
备注：无 |
失物登记表的数据存储如表2.5所示。
表2.5 数据存储“失物登记表”的字典条目
|
数据存储名称：失物登记表 |
|
编号：F2 |
|
简述：是经过按失主查询的失物信息统计得到的失物登记表 |
|
流入的数据流：来源于 |
|
流出的数据流：去向是 |
|
数据存储组成：名称+地点+细节描述+昵称+学号+联系方式+时间 |
|
备注：无 |
用户信息表的数据存储如表1.3所示。
表2.6 数据存储“用户信息表”的字典条目
|
数据存储名称：用户信息表 |
|
编号：F3 |
|
简述：是经过按用户填写的信息整理统计得到的用户信息表 |
|
流入的数据流：一方面来源于失主和拾遗者用户信息的结果，另一方面来自于管理员的信息 |
|
流出的数据流：去向是管理员操作和修改用户信息 |
|
数据存储组成：昵称+学号+联系方式+账号+密码 |
|
备注：无 |
1.5 加工逻辑
（1）加工2.1系统审查失物信息的结构化语言如下。
输入失物信息
按拾遗者提供的失物信息分类
检索“失物登记表”文件，获得失物登记的表单
对于输入的失物信息进行失物匹配
begin
如果 失物登记表有相同的信息
则
失物匹配成功，进而联系失主领回
否则
失物匹配失败，发布失物信息到“失物信息表”文件
End
（2）加工3.1用户登录决策树如图2.1用户登录决策树所示。
图2.1用户登录决策树
（3）加工1失物查询功能IPO图如图2.2所示。
图2.2失物查询功能IPO图
（4）加工2失物发布功能IPO图如图2.3所示。
图2.3失物查询功能IPO图
（5）实体关系图ER图如图2.4所示。
图2.4 实体关系ER图
1.6 软件非功能需求
硬件环境需求：PC端以及客户端。
软件环境需求：windows10系统或者Linux系统。
性能需求：目前市面上的主流的中端显卡例如Geforce 9800 gt，能够达到低端显卡也能运行这个系统，目的是服务学生，大部分的学生的个人电脑和学校的台式电脑也基本可以达到这个标准。
安全性需求： 能够做到对客户以及系统的个人信息能够完善保存，系统不易被盗取信息与技术；并且能根据用户的类别设置访问权限，并且对用户的访问权限或者用户的信息进行直接操作。
可靠性需求：在发生故障以后的易恢复性，发布新版本以后做到回滚方案，以备异常紧急处理，在系统出错后做好容错处理。
易用性需求：系统使用简单，便于操作，便于学习，并且用户界面美观，具有一定观赏性。
实验二 软件结构设计
2.1 软件结构设计
1. 将功能层数据流图化分边界，如图2.1所示。
图2.1化分边界的数据流图
2.按SD方法将数据流图转换为软件结构图，如图2.2所示。
图2.2 功能层的SC图
3.失物查询层的划分边界的DFD图，数据流图为事务型，如图2.3所示。
图2.3 化分边界的失物查询层DFD
4.根据失物查询层化分边界的DFD，画出的SC图，如图2.4所示。
图2.4 失物查询层的SC图
图2.2与图2.4其中：
1 OC1为用户或管理员的操作命令
2 OC2为失主的操作命令
3 D1为寻找失物
4 D2为无效需求单
5 D3为有效需求单
6 D4为需求范围
7 D5为调用失物信息单查看
8 D6为查询失败通知单
9 D7为查询成功通知单
5.失物发布层的划分边界的DFD图，数据流图为事务型，如图2.5所示。
图2.5 化分边界的失物发布层的DFD
6.根据失物发布层化分边界的DFD，画出的SC图，如图2.4所示。
图2.6采购层的SC图
图2.6其中：
10 OC3为拾遗者的操作命令
11 D1为失物信息
12 D2为无效信息单
13 D3为审查成功通知单
14 D4为信息匹配失败通知单
15 D5为信息匹配成功通知单
16 D6为发布信息成功通知单
2.2 详细设计-程序流程图
(1) 用户管理中登录程序流程图，如图2.7。
图2.7 审查有效性程序流程图
实验三 系统用例分析
3.1 系统需求陈述
校园失物招领管理系统。主要负责校园学生寻找和发布失物。
失主：注册、登录系统，系统审核信息有效性，有效性是指提供的学号姓名学号联系方式是否符合规格，审核通过则注册、登录成功；进入系统后，失主可以通过拾遗者提供的失物信息表查找，通过描述细化失物的范围，系统会返回查找到失物会联系拾遗者领回，查找失败后会记录在失物登记表。
拾遗者：注册、登录系统，系统审核信息有效性，有效性是指拾遗者提供的姓名学号联系方式等是否正确符合规格。审核通过则注册、登录成功；进入系统后，拾遗者上传提供失物的信息，系统审查信息的有效性，有效性是指捡到的失物是否符合基本的失物特征，保证不能出现除了失物以外的其他信息，审查成功后失物信息将发布到失物信息表上，系统对拾遗者发布的信息进行分类整理后，返回发布信息成功通知单给拾遗者。
管理员：注册、登录系统，系统审核信息有效性，有效性是指管理员提供的姓名联系方式等是否正确符合规格。审核通过则注册、登录成功；进入系统后，管理员可以修改失主和拾遗者的信息。
失物招领管理系统：具有三个功能分区，分别是：用户管理、失物查询、失物发布；用户管理功能实现每一位使用系统的用户都需要先注册、登录再进入系统；其次提供了管理员可以修改用户信息的功能。失物查询功能实现了失主查询失物的功能，并且可以实现审查信息的有效性并提供找回失物的方式。失物发布功能实现了发布失物信息并且审查拾遗者发布信息的有效性。
3.2 功能提取
3.2.1 识别相关者
失主、拾遗者、管理员
3.2.2 建立系统的业务列表
业务列表如表1-1所示。
|
参与者 |
用例 |
说明 |
|
失主（loster） |
浏览失物信息 （Browse lost property information） |
失主可以通过直接实时查看失物信息 |
|
发布招领信息 （Release the claim information） |
失主未搜索到失物信息后可以发布失物招领信息 |
|
|
查询招领信息 （Query found information） |
失主可以通过关键字搜索或直接查询招领信息 |
|
|
在线交流（Online communication） |
失主可以与拾遗者进行在线交流 |
|
|
申请领回（To apply for claim） |
失主找到失物后可以向系统和拾遗者申请领回失物 |
|
|
拾遗者（Gleanings person） |
浏览招领信息 （Browse for found information） |
拾遗者可以直接查看实时招领信息 |
|
搜索招领信息 （Search for found information） |
拾遗者可以通过关键字搜索招领信息 |
|
|
发布失物信息 （Release lost property information） |
拾遗者捡到失物后可以发布失物信息 |
|
|
在线交流（Online communication） |
拾遗者与失主可以进行在线交流 |
|
|
申请提供（Apply for providing） |
拾遗者提供失物领回申请以便失主可以领回失物 |
|
|
管理员（Administrator） |
用户权限管理 （User privilege management） |
管理员可以对用户权限进行修改 |
|
用户信息管理 （User information management） |
管理员可以对用户信息进行输入和修改 |
表1-1 业务列表
3.3 校园失物招领管理系统的包图
校园失物招领管理系统包图如图1-1所示。
包图说明： 该包图包括：“用户界面”、“业务逻辑”、“用户接口”、“数据库”四个包以及包间关系。其中用户界面与逻辑界面存在依赖关系；业务逻辑、用户接口与数据库之间存在依赖关系；同时，用户接口与业务逻辑之间也存在依赖关系。
图1-1 校园失物招领管理系统包图
3.4 用例图建立
校园失物招领管理系统用例图如图1-2所示。
图1-2 系统用例图
3.5 系统用例说明
系统用例说明如表1-2所示。
|
用例名称 |
注册 |
|
用例ID |
UC01 |
|
主要业务参与者 |
用户（失主 / 拾遗者） |
|
简要描述 |
用户输入自身信息注册账号 |
|
基本事件流 |
用户输入 用户名、密码、学号、手机号等基本信息 |
|
扩展事件流 |
系统将信息添加到用户信息库 |
|
用户场景 |
注册成功 / 注册失败 |
|
关系描述 |
“用户信息管理”是“注册”的扩展 |
|
前置条件 |
无 |
|
后置条件 |
无 |
|
异常 |
若输入不符合条件则显示注册失败 |
|
限制与约束 |
必须填写完必填项，如用户名、密码、学号、手机号等，且同一个用户名或学号不能同时重复注册，学号，手机号需要符合格式 |
表1-2 注册的用例说明
|
用例名称 |
登录 |
|
用例ID |
UC02 |
|
主要业务参与者 |
用户（失主 / 拾遗者） |
|
简要描述 |
用户输入用户名和密码登录账号 |
|
基本事件流 |
用户输入用户名和密码进行登录，若登陆成功则赋予其对应的权限 |
|
扩展事件流 |
密码输入错误，弹出提示信息再次输入，重新登录 |
|
用户场景 |
登录成功 / 登录失败 |
|
关系描述 |
“登录”用例包含“用户权限管理”用例 |
|
前置条件 |
该用户已经注册 |
|
后置条件 |
无 |
|
异常 |
若密码输入错误三次以上，封锁账号一段事件，封锁时间结束后才可以再次登录账号 |
|
限制与约束 |
必须输入正确且匹配的用户名和密码 |
表1-3 登录的用例说明
|
用例名称 |
浏览招领信息 |
|
用例ID |
UC03 |
|
主要业务参与者 |
失主 |
|
简要描述 |
失主浏览多条招领信息的主要信息 |
|
基本事件流 |
失主对多条招领信息进行浏览，招领信息按照发布时间排序，最新发布的信息在前 |
|
扩展事件流 |
选择物品类别（书 / 校园卡 / 身份证 等） |
|
用户场景 |
浏览到目标信息 / 没有浏览到目标信息 |
|
关系描述 |
“申请领回”是“浏览招领信息”的扩展 |
|
前置条件 |
无 |
|
后置条件 |
无 |
|
异常 |
无 |
|
限制与约束 |
无 |
表1-4 浏览招领信息的用例说明
|
用例名称 |
申请领回 |
|
用例ID |
UC04 |
|
主要业务参与者 |
失主 |
|
简要描述 |
失主看到目标招领信息后，申请领会此信息中的物品 |
|
基本事件流 |
失主点击“申请领回”按钮后，回答拾遗者设置的验证问题，若全部回答正确，则将获得在线交流的权限，招领信息状态为申请中状态 |
|
扩展事件流 |
无 |
|
用户场景 |
获得在线交流的权限 / 未获得在线交流的权限 |
|
关系描述 |
“申请领回”是“浏览招领信息”的扩展 |
|
前置条件 |
该用户已经登陆 |
|
后置条件 |
无 |
|
异常 |
无 |
|
限制与约束 |
无 |
表1-5 申请领回失物的用例说明
|
用例名称 |
搜索招领信息 |
|
用例ID |
UC05 |
|
主要业务参与者 |
拾遗者 |
|
简要描述 |
失主输入关键词搜索相关招领信息 |
|
基本事件流 |
失主输入关键词搜索相关招领信息，搜索结果按符合关键词数量排列，符合更多关键词的信息在前，相同数量是按发布时间排序 |
|
扩展事件流 |
无 |
|
用户场景 |
搜索到目标信息 / 未搜索到目标信息 |
|
关系描述 |
“选择分类”是“搜索招领信息”的扩展 |
|
前置条件 |
无 |
|
后置条件 |
无 |
|
异常 |
无 |
|
限制与约束 |
至少需要输入一个关键字 |
表1-6 搜索招领信息的用例说明
|
用例名称 |
在线交流 |
|
用例ID |
UC06 |
|
主要业务参与者 |
用户（失主 / 拾遗者） |
|
简要描述 |
失主和拾遗者在线交流 |
|
基本事件流 |
失主和拾遗者在线交流并确认失物情况 |
|
扩展事件流 |
无 |
|
用户场景 |
失主和拾遗者确认失物情况 |
|
关系描述 |
无 |
|
前置条件 |
该用户已经登录 并且对于失主 回答正确拾遗者提出的相关问题 |
|
后置条件 |
无 |
|
异常 |
无 |
|
限制与约束 |
交流中系统若检测到不良信息将切断联系并警告双方 |
表1-7 在线交流的用例说明
3.6 建立顺序图
校园失物招领管理系统管理员管理用户信息顺序图如图1-3所示。
图1-3 管理员管理用户信息顺序图
3.7 建立类图
校园失物招领管理类图如图1-4所示。
图1-4 校园失物招领管理系统类图
3.8 建立用例活动图
校园失物招领管理系统失主寻找失物用例活动图如图1-5所示。
图1-5 寻找失物用例活动图
标签：数据项,失主,导论,用户,信息,拾遗,软件工程,失物,失物招领 来源： https://www.cnblogs.com/WScoconut/p/16063983.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。