2019年5月23日项目日志

体育馆团体预约系统

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

 

猜你喜欢

转载自www.cnblogs.com/BIT2019UML06/p/10916447.html