体育馆团体预约系统
UML软件工程项目日志
June,9th ,2019
目录
一、 博客地址 1
二、 客户提交内容 1
三、 项目背景 2
四、 项目范围和前景 2
五、 沟通记录 3
六、 甲方确认结果： 6
七、 结构化需求分析概述 6
八、 涉众分析 7
九、 硬数据采样及数据分析 8
十、 过程建模 8
十一、 数据建模 9
十二、 预约系统用例分析 10
十三、 工作计划 12
十四、 本周工作日志 13
十五、 项目总进展 13
一、博客地址
https://www.cnblogs.com/BIT2019UML06/
二、客户提交内容
项目名称：体育馆课外预约系统
项目使用者：全体师生
项目用户需求： 设计线上预约系统，实现以下要求：
- 填写校园卡号或者教师工号，姓名，预约时间，预约场馆号，持续时间，人数，理由 联络人等信息。（这个是一个需要审核的过程 一般只能允许理由为训练 进行比赛等 且团队负责人才可预约 联络人是负责预约签到的）
- 预约时间不能和上课时间冲突（即需自动过滤体育课所占场馆和时间）
- 预约时间不能超过两小时，但如果使用过后后续无人预约则可续约
- 在预约时间之前的10分钟打卡，若违约，则记录在预约档案（详情可参考图书馆预约系统）超过3次 则两个月内不可进行线上预约（至于如何实现 就靠你们自己想了）
- 每项运动的场馆酌情保留2/3空余不可预约（除了大型比赛之外），以便非比赛或者非校队的其余同学进行运动
- 游泳不用预约 ，但可以查询上课时间
- 实现查询和预约功能
- 大型比赛若要占大量场馆，则需找辅导员（因此需要单独设置一个大型比赛预约选项， 只能由辅导员账号申请）
- 预约团体需要进行认证
三、项目背景
2019年春，随着北理工良乡体育馆竣工开放，场地预约成为师生以及一些团体组织活动使用体育馆的方式，面对各种上课、活动等场地占用的情况，我们也需要一个方便师生使用的网络场馆查询预约系统来均衡、解决这些问题。
四、项目范围和前景
基本目标：
移动端或者电脑端win/mac的一个查询预约平台，形式：网页
基本要求：
客户页面分为主页登录界面、查询主页、体育馆楼层场地信息显示页、预约界面、用户信息页面等，系统管理页面有场地更改页面、诚信管理页面
- 用户单位认证、审核：团体用户提交注册认证材料，管理员以联系校团委等方式求证后，审核材料通过
- 场地查询：当前时间体育馆各场馆使用情况显示（空闲、使用中、维修），显示在主页面中
- 课外预约、大型比赛活动审批
- 用户诚信管理：根据打卡时间、场馆使用后卫生情况反馈等进行记录评分
- 体育课程表的输入
高级需求：
- 简约实用的界面设计和预约流程
- 馆内导航
- 批条导出打印
- 用户中心：显示团体自己的基本资料、诚信信息、预约历史、当前预约等信息
- 冲突处理：因为设计为只能预约空闲场地，不存在上课与团体冲突。先到先得
项目前景：
该平台能够帮助师生以及团体查询场地预约情况以方便决策使用体育馆的时间
五、沟通记录
May, 9th 下午 15：00
地点&沟通方式：微信
内容：对需求细节进行了一些了解，确定项目范围
May 9th 晚 21:00
宿舍开会与甲方代表讨论
5月13日，建立问卷星、采访涉众以获取数据，建立原型草图
5月14日
与甲方联系，针对原型建立过程出现的问题进行沟通，功能需求阐述，建立原型
地点&沟通方式：微信
May 30th, 2019
地点：微信
沟通工作细节，分析数据生命期，画UML时序图，着手建立网站产品框架
六、甲方确认结果：
七、结构化需求分析概述
- 功能分解图（功能需求优先级、主要涉众优先级）
- 需求细化与优先级划分
l 功能需求：
场馆管理，添加、删除、修改场馆信息
客户团体通过页面提交资料和认证请求，由管理员在后台审核认证
所有北理工学生可登录页面查看体育馆预约情况
认证后的团体单位负责人可进行团体登录，选择场馆+场地编号+时间段，交由系统审核
系统对预约请求进行审核，符合条件（不与课程和其他预约冲突、时间段有效、数量在限制以内、诚信合格）则预约成功
签到（外设签到），不诚信签到记录
团体诚信管理
使用后签到离开
团体个人中心——我的团体：预约记录（历史、当前） 诚信信息
l 非功能需求
*前台信息交互：前台登入网站核实，打印批条（提前对预约场地清场）
馆内导航
场馆介绍
用户数据管理，信息数据安全保护+隐私保护
电脑（Win/Mac/Linux）和移动端（ios/android）可用
轻量
八、涉众分析
- 涉众分类：
系统管理员：可以进行场馆管理，团体用户认证审核，诚信数据修改，设置黑名单
认证的团体：社团、学生组织、校单位在提交认证通过后可以进行场馆预约使用，查询自己以及其他团体信息
理工学生&教职工个人（游客）：仅可登录网站查看场馆预约使用情况，不可预约
开发维护者：产品开发维护
客户：项目提出者，最终交付的对象
- 涉众优先级：
系统管理员（总管场馆、用户成员以及内部数据）
认证团体（系统最主要用户）
理工学生&教职工个人（游客，非甲方要求用户，仅提供查看功能）
- 制约因素：
复杂的现实情况可能会对需求分析造成困扰
时间短，技术实力可能不够
九、硬数据采样及数据分析
十、过程建模
考虑实际情况，分清对象，改进了上周的过程原型
l 场馆管理过程：
场馆添加——场馆编辑——场馆删除
l 团队认证、预约、使用过程
查询——登录（认证）——预约（取消）——使用——结束
十一、数据建模
我们通过与整理上周的数据，并访问了一些团队单位，借鉴其他预约系统（如图书馆预约系统等），得到了基本对象的输入输出数据参数，以及这些对象之间的关系
数据对象：用户团体数据、场馆信息、预约信息、体育课场馆使用数据
- 管理员信息——管理员姓名、管理员编号、管理密码
- 团体信息——注册编号、团体名称、团体规模（大概多少人）、常用场馆、团体负责人、团体负责人联系方式
- 场地信息——场馆名、场地编号、场地状态（空、使用中、维护中）
- 预约信息——时段（开始、结束）、预约场地编号、预约团体用户、预约团体用户编号、联系人、联系人联系方式
十二、预约系统用例分析
预约系统时序图
1. 用户进入登陆界面，输入登录信息
2. 后台通过数据库进行比对，检验登录信息是否有误，确认登陆
3. 登录平台后，显示场地界面，预约情况等
4. 用户可以浏览各类场馆以及各个场地的使用情况
5. 用户选择需要预约的场馆以及相应场地
6. 后台从数据库中提取场地信息，查询场地的预约状态
7. 如果可预约则反馈给后台，后台提供给用户相应的查询信息
8. 用户发送预约请求
9. 后台接收预约请求，反馈给数据库记录预约信息
10. 后台反馈给用户预约的信息
11. 预约成功
领域模型：
状态图
1、 状态图主体：信息交互。
2、 信息交互中可能存在的稳定状态：
登录状态：用户登录。
查询场馆状态：调用信息库信息查询场馆信息的状态。
场馆预约状态：对所选场馆进行预约的状态。
对局结束状态：信息调用结束后，结束指令之后的状态。
活动图
十三、工作计划
| 阶段 | 时间 | 内容 |
| 前期 | 第11周 |
|
| 12周 | 需求细化，考虑现实情况下制约因素以及解决方案 | |
| 中期 | 12周 | 建立项目原型框架（软件工程实践者的研究方法） |
| 13-14周 | 基本完成模型建立和用户使用需求文档 | |
| 后期 | 15周 | 需求验证，测试完善，反馈，维护 |
| 16周 | 交付工作予甲方验收 |
十四、本周工作日志
June,4th,2019
预约系统用例分析(数据对象、数据信息流动)，领域模型
June,6th,2019
讨论产品实体的结构，着手建立网页产品框架以及实体
十五、项目总进展
| 时间 | 日志 | 进展 | 备注 |
| 第十一周 | May, 9th 下午 15：00 地点&沟通方式：微信 内容：对需求细节进行了一些了解，确定项目范围
May 9th 晚 21:00
|
| 只管理所有场地1/3，个人只提供查看，不提供预约功能 |
| 第十二周 | 5月13日，建立问卷星、采访涉众以获取数据，建立原型草图 5月14日，与甲方联系，针对原型建立过程出现的问题进行沟通，功能需求阐述，建立原型 地点&沟通方式：微信 5月15日，与甲方开会，交流确认进展情况 地点：宿舍 5月16日，制作PPT，书写文档，交由甲方确认，发布博客
|
|
|
| 第十三周 | May 22th,晚上21:40 地点&沟通方式：微信 内容：各对象参数内容，数据库涉及范围，修改过程模型，建立数据模型
May 23th,晚上21:40 总结文档，书写博客
|
| 周五汇报反馈： |
| 第十四周 | May 27th,2019 记录汇报反馈，修改过程模型和功能分解图 May 30th, 2019 沟通工作细节，分析数据生命期，画UML时序图，着手建立网站产品框架 Jun 1st, 2019 总结工作，书写文档 |
|
|
| 第十五周 | June,4th,2019 预约系统用例分析(数据对象、数据信息流动)，领域模型 June,6th,2019 讨论产品实体的结构，着手建立网页产品框架以及实体 文档问题修改，发布博客 June，9th,2019 制作状态图，活动图
|
|
|
| 第十六周 | June，12th，2019 讨论原型系统网页制作的内容细化和功能文档
|
|
|
3056
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
