310
社区成员
发帖
与我相关
我的任务
分享共享之舟——GitCode团队实战总结
| 这个作业属于哪个课程 | 软件工程实践-2023 学年-W 班 |
|---|---|
| 这个作业要求在哪里 | 软工实践——GitCode团队实战总结 |
| 这个作业的目标 | 实现世界游泳锦标赛的注册、登录、个人信息、投票、排名、后台等功能 |
| 其他参考文献 | 无 |
目录
- 项目记录
- 项目地址
- 提交截图
- 提交次数
- 运行环境
- 功能需求
- NABCD模型
- N（Need）
- A（Approach）
- B（Benefits）
- C（Competitors）
- D（Delivery）
- 外围功能
- 杀手功能
- 设计实现
- 系统架构
- 功能模块
- 接口设计
- ER图与数据库
- 设计类
- 程序展示
- 基本功能演示
- 排名+用户登出+查看个人信息
- 投票功能（涉及附加功能的投票策略）
- 用户登陆+注册
- 思考的问题
- 投票结果告知用户
- 用户如何快速知道有投票功能并参与投票？
- 防止重复注册
- 合作分工
- 戴聪
- 分工
- 遇见的困难和解决方法
- PSP表格
- 谢凌云
- 分工
- 遇见的困难和解决方法
- PSP表格
- 陈智翔
- 分工
- 遇见的困难和解决方法
- 熊桂根
- 分工
- 遇见的困难和解决方法
- PSP表格
- 蓝有润
- 分工
- 遇见的困难和解决方法
- PSP表格
- 陈卓杨
- 分工
- 贡献度
- 附加功能
- 进阶投票策略
- 后台界面
- 用户管理
- 查看数据
- 压力测试
项目记录
项目地址
提交截图
提交次数
| 成员 | 前端次数 | 后端次数 | 总次数 |
|---|---|---|---|
| 蓝有润 | 2 | 8 | 10 |
| 谢凌云 | 4 | 0 | 4 |
| 熊桂根 | 0 | 5 | 5 |
| 戴聪 | 7 | 0 | 7 |
| 陈智翔 | 4 | 0 | 4 |
| 陈卓杨 | 0 | 0 | 0 |
运行环境
运行环境为腾讯云服务器。运用docker容器装载Springboot jar文件和编译后的Vue文件。
前台地址为http://114.132.55.221/
后台地址为http://114.132.55.221/Admin
建议用已经注册好的账号进行登录，因为后端会检测IP，同一个IP地址不能重复注册。
| 用户名 | 密码 |
|---|---|
| Alice Lee | nmTRgtPlLe |
| Charlie Smith | XADQxB8prA |
| Alexander Morales | 3ETM*h37Bb |
功能需求
NABCD模型
N（Need）
- 支持喜欢的选手。
- 了解选手信息。
A（Approach）
- 提供一个用户友好的网站，创建庞大的选手资料库和实时更新的比赛信息。
B（Benefits）
- 用户可以无缝访问所有功能，无需离开网站。
- 投票功能增加用户参与感，支持他们喜欢的选手。
C（Competitors）
竞争对手：
- DivingWorldCup.com - 提供全面的跳水世界杯信息和直播服务。
- 优点：提供多语言支持，拥有广泛的国际观众基础。
- 缺点：用户界面较为传统，缺乏现代感和互动性。
- DiveChampions.com - 专注于跳水冠军赛的新闻和分析。
- 优点：提供深入的技术分析和专家评论。
- 缺点：缺少视频点播服务，用户参与度有限。
- AquaticFanVoting.net - 一个专门的跳水运动投票网站，提供选手投票和社区互动。
- 优点：社区活跃，用户粘性强。
- 缺点：投票系统较为简单，缺乏高级功能。
我们的优势：
- 独特的实时统计的、具备投票策略的投票系统，能够提高用户的参与度。
我们的改进点：
- 定期更新网站功能，不断维护网站，增加网站核心功能。
D（Delivery）
- 通过社交媒体和体育论坛宣传网站。例如在虎扑等论坛进行宣传。
- 提供独特的用户参与活动，如抽奖、问答和幕后内容。可以通过问卷星抽奖活动进行推广，还能进行用户调研。
- 使用搜索引擎优化（SEO）和在线广告提高可见度。例如在百度或者bing中购买一个前置的广告位。
外围功能
- 用户账户管理：注册、登录、个人资料编辑。
杀手功能
- 实时投票系统：允许用户在比赛中实时投票。
- 投票结果展示：实时更新的投票统计和选手排行榜。
设计实现
系统架构
功能模块
接口设计
ER图与数据库
设计类
程序展示
基本功能演示
排名+用户登出+查看个人信息
投票功能（涉及附加功能的投票策略）
导航栏选择投票，可查看剩余票数，选择选手输入票数并且点击投票按钮后可以完成投票。投票完成后可以看到给哪些运动员投了多少票。
用户登陆+注册
使用已注册的账号，在登陆页面正确输入（可点击显示或隐藏密码）后，并且勾选用户协议，方可登录
在登陆页面点击右下角注册进入，必须要输入所有内容（邮箱等需要符合规范）且点击同意用户协议后方可点击确认注册并成功。
思考的问题
投票结果告知用户
投票完成后，会把用户的投票结果告知给用户，同时结果是实时生成的，当投票完毕后，用户可以立刻进入排名界面查看用户的投票内容。
用户如何快速知道有投票功能并参与投票？
为了让用户快速参与到投票中，我们设置了登陆后的初始界面即为投票界面。
防止重复注册
如下图，10.132.101.159在之前测试时注册了一个账号，第二次注册账号时，因为数据库中含有对应的ip地址，所以注册失败。
合作分工
戴聪
分工
完成登陆页面和注册页面的页面设计与制作，完成用户界面的导航栏、投票页面的部份表格和排名页面的数据读取和导入以及分页设计制作。完成管理员页面的导航栏和排名页面的设计制作、数据的读取导入和分页设计制作。
遇见的困难和解决方法
- 问题：引入图表时页面变成空白且图表的高度无法修改。
解决方法：将引入的组件由echarts改为googlecharts并且修改main.js配置文件后解决页面变成空白的问题。图表最外层为，需要先对的高度进行设定，然后对图表的chartArea在进行修改后解决。 - 问题：编写管理员页面的排名页面数据导入时出现没有任何数据的问题。
解决方法：通过浏览器控制台显示，服务器端返回错误码500表明为后端故障，反馈经后端小伙伴修补后，出现数据处理的问题，在向后端要了具体的json文件并对其进行准确解析后解决。 - 问题：在最后检查阶段发现用户页面的排名表出现排版错误。
解决方法：经过在多个页面进行排查发现，极有可能时重名导致的css混乱，最开始将style改为style scoped用来规避不同页面的css重用，但是仍存在问题，最后通过修改部分命名解决。 - 问题：在设计分页的时候，出现了分页器和页面内容出现排版错乱的问题。
解决方法：在共同的父容器中添加display、justfyflex-direction和justify-content等来安排布局，同时对分页器的长宽、内容位置等进行修改以解决问题。
PSP表格
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 35 |
| • Estimate | • 估计这个任务需要多少时间 | 30 | 35 |
| Development | 开发 | 550 | 807 |
| • Analysis | • 需求分析 | 30 | 32 |
| • Design | • 具体设计 | 90 | 120 |
| • Coding | • 具体编码 | 400 | 510 |
| • Code Review | • 代码复审 | 60 | 80 |
| • Test | • 测试 | 60 | 65 |
| Reporting | 报告 | 50 | 50 |
| • Size Measurement | • 计算工作量 | 20 | 25 |
| • Postmortem & Process Improvement Plan | • 事后总结 | 30 | 25 |
| 合计 | 630 | 892 |
谢凌云
分工
配置axios，负责登陆、注册和个人信息的前后台通信部分。实现登陆和退出的session功能，登陆和未登录的权限访问限制。配置云服务器。
遇见的困难和解决方法
- session部分一开始使用sessionStorage，但是未关闭服务器情况下新开一个窗口，需要重新登陆
解决方法：查询资料得知sessionStorage只能在同tab中使用，localStorage可以在同浏览器中使用，使用localStorage替换sessionStorage成功解决。 - axios在程序中的使用不熟练
解决方法：参考上次结对作业队友完成的代码，同时积极与后端的同学沟通，逐渐完善前后台的通信。
PSP表格
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 10 |
| • Estimate | • 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 500 | 1060 |
| • Analysis | • 需求分析 | 40 | 40 |
| • Design | • 具体设计 | 60 | 100 |
| • Coding | • 具体编码 | 400 | 800 |
| • Code Review | • 代码复审 | 60 | 60 |
| • Test | • 测试 | 60 | 60 |
| Reporting | 报告 | 40 | 40 |
| • Size Measurement | • 计算工作量 | 20 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结 | 20 | 20 |
| 合计 | 550 | 1110 |
陈智翔
分工
和戴聪同学一起进行投票界面和排名界面的开发,我主要负责其中的表格部分,还有投票界面对票数的验证及数据在页面的保存。
遇见的困难和解决方法
- 参与前端开发时,我对vue框架不熟悉,一开始没有采用vue框架开发,在和其他成员的前端程序整合时出现了一些问题。
解决方法:在队员的帮助下,我迅速学习了一下vue框架的用法,将原本纯htmlcss的排名界面整合到了vue框架中。 - 制作投票页面时,在vue框架中css命名发送冲突,导致混乱
解决方法：使用scoped关键字进行作用域化,但是似乎没有完全解决问题，最后通过各个页面尽量唯一化命名避免冲突
熊桂根
分工
设计接口完成接口设计图，我主要负责编写后端代码，完成了后台管理员模块的接口代码编写。使用JMeter模拟大量用户进行投票的压力测试。
遇见的困难和解决方法
- 问题：后端代码编写的过程中，不同层次程序的调用逻辑出现问题。
解决方法：在和其他后端开发人员的交流中，学习JDBC并理解不同层次之间的逻辑调用，控制器层调用业务逻辑层的方法通过sql语句对数据库进行操作将实体存在DAO层中，最后将其发回前端。 - 问题：没有压力测试的经验，在进行模拟百万级用户参与时无从下手。
解决方法：经过查询资料，决定使用开源项目Jmeter进行模拟多用户投票时的压力测试。并进行相关工具的下载和配置。
PSP表格
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 20 |
| • Estimate | • 估计这个任务需要多少时间 | 10 | 20 |
| Development | 开发 | 500 | 745 |
| • Analysis | • 需求分析 | 40 | 50 |
| • Design | • 具体设计 | 60 | 70 |
| • Coding | • 具体编码 | 400 | 500 |
| • Code Review | • 代码复审 | 60 | 60 |
| • Test | • 测试 | 60 | 65 |
| Reporting | 报告 | 50 | 45 |
| • Size Measurement | • 计算工作量 | 20 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结 | 30 | 25 |
| 合计 | 630 | 810 |
蓝有润
分工
完成系统结构图、ER图和数据库的设计。完成后端前台的所有接口，同时测试所有接口与前端的连接。编写前端的用户封禁和投票界面。参与博客的撰写。
遇见的困难和解决方法
- ApplicationJSON的自动转换问题，虽然Springboot中提供了将一些类转化为ResponseEntity的方法，但是对于复杂的类是难以实现自动转化的，因此使用Google的GSON来完成类到JSON的自动转化。
- 请求体到Controller中的RequestBody的转化，对于复杂的请求体，对应的RequestBody类需要严谨的编写，最好避免使用简单的List或Map，容易得不到数据，而是对应的嵌套类来完成。
PSP表格
PSP Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 60 70 • Estimate • 估计这个任务需要多少时间 60 70 Development 开发 660 922 • Analysis • 需求分析 30 32 • Design • 具体设计 90 120 • Coding • 具体编码 420 620 • Code Review • 代码复审 60 80 • Test • 测试 50 80 Reporting 报告 45 65 • Size Measurement • 计算工作量 15 25 • Postmortem & Process Improvement Plan • 事后总结 30 40 合计 总计 765 1057 陈卓杨
分工
参与博客撰写。
贡献度
成员 分工 贡献度 蓝有润 完成系统结构图、ER图和数据库的设计。完成后端前台的所有接口，同时测试所有接口与前端的连接。编写前端的用户封禁和投票界面。参与博客的撰写。 25.5% 谢凌云 配置axios，负责登陆、注册和个人信息的前后台通信部分。实现登陆和退出的session功能，登陆和未登录的权限访问限制。配置云服务器。 17.5% 熊桂根 设计接口完成接口设计图，完成了后台管理员模块的接口代码编写。使用JMeter模拟大量用户进行投票的压力测试。 18.5% 戴聪 完成登陆页面和注册页面的页面设计与制作，完成用户界面的导航栏、投票页面的部份表格和排名页面的数据读取和导入以及分页设计制作。完成管理员页面的导航栏和排名页面的设计制作、数据的读取导入和分页设计制作。 18.5% 陈智翔 和戴聪同学一起进行投票界面和排名界面的开发，负责其中的表格部分，还有投票界面对票数的验证及数据在页面的保存。 12% 陈卓杨 参与博客撰写 8% 附加功能
进阶投票策略
整合到了基础功能中。
后台界面
用户管理
进入管理员页面，导航栏选择用户管理，可以查看用户的基本信息，并对用户的账号进行封禁或者解封的操作。
被封禁的1号用户无法登陆。
查看数据
进入管理员页面，导航栏选择排名，可以查看当前前十名的柱状图以及所有选手的详细排名。
压力测试
使用Jmeter进行压力测试
配置完毕Jmeter，用CSV配置文件实现用户变量。通过线程组启动多条线程，模拟同时多用户进行投票操作的压力测试。
查看聚合报告分析性能。
样本数量：总共进行了952个HTTP请求样本。
平均值：所有样本的平均响应时间为2305毫秒。
中位数：中位数是样本响应时间的中间值，即有一半的样本响应时间小于等于中位数（2051毫秒），另一半大于等于中位数。
90% 百分位：90%的样本响应时间在4458毫秒以内。
95% 百分位：95%的样本响应时间在4548毫秒以内。
99% 百分位：99%的样本响应时间在4914毫秒以内。
最小值：最快的响应时间为6毫秒。
最大值：最慢的响应时间为21059毫秒。
异常 %：异常百分比为5.462%，表示有5.462%的请求响应时间超出了预期范围或发生了异常情况。吞吐量：吞吐量指每秒钟处理的请求数量，这里是0.37848。
接收 KB/sec：接收的数据量，以KB/秒计算，为0.11 KB/秒。
发送 KB/sec：发送的数据量，以KB/秒计算，为0.13 KB/秒。从这份报告可以看出，在1000个线程同时访问时，大部分HTTP请求的响应时间都在较短的范围内，但有5.462%请求响应时间较长或发生异常。经过进一步测试发现在800线程访问时，0.0%的请求响应时间异常，说明压力测试的瓶颈在800-1000之间，在800线程前都是无负担的。而本预计的百万级压力测试也仅在模拟千级用户时就卡住了。查询资料分析原因是线程启用过多，而笔记本内存资源稀缺。要想模拟达到百万级用户同时进行投票访问可能需要使用服务器或多台分布式测试。
...全文
请发表友善的回复…
发表回复
