体育馆团体预约系统
UML软件工程项目日志
May,23th ,2019
项目日志
May 22th,晚上21:40
地点&沟通方式：微信
内容：各对象参数内容，数据库涉及范围，修改过程模型，建立数据模型
May 23th,晚上21:40
总结文档，书写博客
结构化需求分析概述
- 功能分解图（功能需求优先级、主要涉众优先级）
根据上周的UML功能介绍图改进，分清了层次，以及优先级
- 需求细化与优先级划分
1. 功能需求：
场馆管理，添加、删除、修改场馆信息
客户团体通过页面提交资料和认证请求，由管理员在后台审核认证
所有北理工学生可登录页面查看体育馆预约情况
认证后的团体单位负责人可进行团体登录，选择场馆+场地编号+时间段，交由系统审核
系统对预约请求进行审核，符合条件（不与课程和其他预约冲突、时间段有效、数量在限制以内、诚信合格）则预约成功
签到（外设签到），不诚信签到记录
团体诚信管理
使用后签到离开
团体个人中心——我的团体：预约记录（历史、当前） 诚信信息
2. 非功能需求
*前台信息交互：前台登入网站核实，打印批条（提前对预约场地清场）
馆内导航
场馆介绍
用户数据管理，信息数据安全保护+隐私保护
电脑（Win/Mac/Linux）和移动端（ios/android）可用
轻量
- 涉众分析
1. 涉众分类：
系统管理员：可以进行场馆管理，团体用户认证审核，诚信数据修改，设置黑名单
认证的团体：社团、学生组织、校单位在提交认证通过后可以进行场馆预约使用，查询自己以及其他团体信息
理工学生&教职工：仅可登录网站查看场馆预约使用情况，不可预约
2. 涉众优先级：
系统管理员（总管场馆、用户成员以及内部数据）
认证团体（系统最主要用户）
理工学生&教职工（非甲方要求用户，仅提供查看功能）
过程建模
考虑实际情况，分清对象，改进了上周的过程原型
1. 场馆管理过程：
场馆添加——场馆编辑——场馆删除
2. 团队认证、预约、使用过程
查询——登录（认证）——预约（取消）——使用——结束
数据建模
我们通过与整理上周的数据，并访问了一些团队单位，借鉴其他预约系统（如图书馆预约系统等），得到了基本对象的输入输出数据参数，以及这些对象之间的关系
数据对象：用户团体数据、场馆信息、预约信息
- 管理员信息——管理员姓名、管理员编号、管理密码
- 团体信息——注册编号、团体名称、团体规模（大概多少人）、常用场馆、团体负责人、团体负责人联系方式
- 场地信息——场馆名、场地编号、场地状态（空、使用中、维护中）、联系人
- 预约信息——时段（开始、结束）、预约场地编号、预约团体用户、预约团体用户编号、联系人、联系人联系方式
- 工具：MySQL workbench
原文地址：https://www.cnblogs.com/BIT2019UML06/p/10916447.html