| 这个作业属于哪个课程 | 2501_CS_SE_FZU |
|---|---|
| 这个作业要求在哪里 | 团队作业------概要设计和数据库设计 |
| 这个作业的目标 | 完成项目系统设计和数据库设计 |
| 其他参考文献 | 《构建之法（第三版)》 《系统设计说明书》《数据库设计说明书》国标规范文本 |
目录
- GitCode仓库链接
- 琼港计划_系统设计说明书
- 琼港计划_数据库设计说明书
- 琼港计划_系统和数据库设计答辩ppt
- 1.系统设计
- 2.数据库设计
- 3.类图
- 4.系统安全和权限设计
- 5.改进分析
-
- [一、 系统设计方面的改进](#一、 系统设计方面的改进)
- [二、 数据库设计方面的改进](#二、 数据库设计方面的改进)
- 6.团队绩效
GitCode仓库链接
琼港计划_系统设计说明书
琼港计划_数据库设计说明书
琼港计划_系统和数据库设计答辩ppt
1.系统设计
1.1体系结构设计
用户输入：通过Input Manager处理用户输入信号。
图形界面：GUI System负责用户界面渲染。
错误处理：Error Manager管理系统错误和异常。
事件管理：Event Manager负责事件分发和处理。
场景管理：Scene Manager管理游戏场景和对象。
图形渲染：Graphical Rendering负责视觉渲染。
音频渲染：Audio Rendering处理游戏音效。
游戏循环：Game Loop驱动游戏主循环。
资源管理：Resource Manager管理游戏资源。
实体管理：Entity Manager管理游戏实体。
1.2功能模块层次图
2.数据库设计
2.1ER分析
效果模块中，所有卡牌实体（包括食谱卡、员工卡、资源卡、营销卡以及boss）均通过效果ID（effectid）这一相同方式与核心的效果表（tbeffect）建立外键关联。这种统一的关联机制意味着，游戏中的每一种卡牌其具体能力、升级行为或特殊作用，都并非硬编码在卡牌自身，而是通过effectid动态引用并执行效果表中预先定义好的逻辑（由classpath和method_name指定）。该设计将效果的具体实现与卡牌实体进行了解耦，通过效果表这一中心化配置点，实现了对所有卡牌效果的统一管理与灵活调配，从而支撑游戏内各类卡牌功能的动态调用与扩展。
游戏分数模块包含游戏成果统计表和游戏日志表。游戏成果统计表记录每局游戏的最终得分和金币数据。游戏日志表记录构成最终得分的各个分数组成部分。两个表通过游戏ID关联，共同完成游戏分数的统计功能。
2.2表结构设计
食材卡实体
食谱实体
员工卡实体
供货卡实体
营销卡实体
效果实体
Boss实体
游戏统计实体
玩家操作日志实体
3.类图
4.系统安全和权限设计
4.1 安全性设计
4.1.1 身份验证机制
建立严格的身份验证体系，对系统管理员和后台管理用户实施强密码策略。密码要求包含大小写字母、数字和特殊字符，且长度不低于12位。系统会定期要求用户更新密码，并对密码尝试次数进行限制，防止暴力破解攻击。
4.1.2 访问控制与权限管理
采用基于角色的精细化访问控制模型，为不同层级的用户分配差异化的数据访问权限。管理员用户拥有完整的系统管理权限，普通运营人员仅能访问其业务范围内的数据和功能模块。系统会记录所有用户的操作轨迹，确保权限使用的可追溯性。
4.1.3 注入防护
在数据库访问层实施严格的安全防护措施，对所有用户输入参数进行有效性验证和转义处理。系统强制使用参数化查询和预编译语句，从根本上杜绝注入漏洞。同时，对数据库操作进行语法分析，检测并拦截可疑的数据库操作。
4.1.4 数据加密存储
对系统中的敏感数据采用多层加密保护。用户密码使用Bcrypt强哈希算法进行不可逆加密存储，个人身份信息等敏感数据使用AES加密算法进行加密存储。密钥管理采用分级保护机制，确保即使数据文件泄露，攻击者也无法轻易获取明文信息。
4.1.5 操作审计与日志记录
建立完善的操作审计体系，详细记录所有用户的关键操作行为，包括登录登出、数据查询、数据修改、配置变更等。审计日志包含操作时间、用户身份、操作类型、操作对象等完整信息，并采用防篡改技术确保日志的完整性。
4.1.6 安全监控与入侵检测
部署多层次的安全监控系统，实时监测数据库的访问模式和操作行为。系统会基于预设的安全规则和机器学习算法，自动识别异常访问模式、高频操作、非授权访问等可疑行为，并及时发出安全警报。
4.1.7 数据备份与灾难恢复
制定完善的数据备份策略，采用全量备份与增量备份相结合的方式，定期对数据库进行完整备份。建立多地域的数据容灾体系，确保在发生系统故障或数据损坏时能够快速恢复业务，最大程度减少数据损失和服务中断时间。
5.改进分析
一、 系统设计方面的改进
V1.0版本的缺点：刚性架构，难以扩展
缺点描述：早期版本可能采用了一种"硬编码"式的架构。例如，每个员工（小丑）的效果被直接编写在Employee类的庞大switch-case或if-else语句中。添加一个新员工，就需要程序员修改核心代码，重新编译整个游戏。
带来的问题：
策划与开发强耦合：策划人员无法独立配置新卡牌，必须依赖开发人员，极大拖慢了内容更新速度。
代码臃肿且脆弱：Employee类会变得极其庞大，修改一个员工的效果可能会意外影响其他效果，测试和调试困难。
无法支持数据驱动：游戏内容更新几乎等同于版本更新，不灵活。
V2.0文档的改进：
引入了"效果（Effect）"抽象层：从类图中可以看到，RecipeCard（食谱卡）、EmployeeCard（员工卡）等都与Effect（效果）关联。这标志着系统从"面向具体卡牌"转变为"面向抽象效果"。
实现了数据驱动设计：卡牌的能力不再硬编码，而是通过关联的Effect来定义。这使得策划可以通过配置数据（如数据库中的tbeffect表）来调整或创建新卡牌，而无需修改程序代码。这是本次迭代最核心的进步。
V1.0版本的缺点：模块界限模糊，高耦合
缺点描述：游戏逻辑、UI渲染、数据存取等代码可能混杂在一起，没有清晰的界限。例如，一个处理点击卡牌的方法，可能同时包含了判断逻辑、分数计算、播放动画和更新数据库。
带来的问题：代码可读性差，难以维护和单元测试。修改UI可能影响游戏逻辑，反之亦然。
V2.0文档的改进：
清晰的模块层次图：文档中展示了如Input Manager、GUI System、Game Loop、Resource Manager等模块，体现了关注点分离的原则。
初步的分层架构：虽然体系结构图较为概念化，但已能看出将用户输入、界面渲染与核心游戏逻辑分离的意图，为低耦合、高内聚的代码结构奠定了基础。
二、 数据库设计方面的改进
V1.0版本的缺点：僵化的表结构
缺点描述：早期数据库设计可能为每种卡牌类型（员工、食谱）创建了完全独立的表，每个表都包含该卡牌独有的字段（如员工的retire_risk，食谱的ingredient_requirement）。如果要实现一个具有复杂新效果的卡牌，就需要频繁地修改表结构。
带来的问题：数据库 schema 不稳定，每次添加新卡牌类型都可能需要ALTER TABLE操作，这在产品上线后是高风险行为。
V2.0文档的改进：
引入核心的tbeffect表：这是数据库设计上革命性的改进。它通过一种"元数据"的方式，将卡牌的行为与卡牌的实体解耦。
极高的灵活性和可扩展性：现在，要添加一个具有全新效果的卡牌，只需在tbeffect表中插入一条新记录，并在相应的卡牌表中设置对应的effectid即可。无需修改任何表结构。这完美支持了游戏后期大量新增卡牌的需求。
V1.0版本的缺点：缺乏游戏数据记录与分析能力
缺点描述：早期版本可能只保存了最简单的玩家进度（如解锁的卡牌、最高分），而没有记录每局游戏的详细数据。
带来的问题：当出现Combo强度失衡（太强或太弱）时，策划人员无法追溯对局历史来分析问题根源，只能凭感觉或大量手动测试来调整，效率低下。
V2.0文档的改进：
设计了详细的tbgame_log表：该表记录了每局游戏的详细操作日志。这不仅用于存档/读档，更重要的是为游戏平衡性分析提供了数据支撑。
支持数据驱动的平衡调整：通过分析日志，可以统计出哪些员工卡、食谱卡的使用率和胜率最高，哪些Combo被频繁触发。这使得数值调整从"凭经验"变为"看数据"，更加科学和高效。
6.团队绩效
| 学号 | 姓名 | 工作内容 | 贡献度 |
|---|---|---|---|
| 102300314 | 黄逸涵 | 《系统设计说明书》和 博客编写 | 10% |
| 102300124 | 林哲纶 | 《系统设计说明书》 和 绘图（ER图，类图等） | 10% |
| 103200323 | 施涵 | 《系统设计说明书》和《数据库设计说明书》 | 20% |
| 062300243 | 滕柏宇 | 《系统设计和数据库设计答辩PPT》 | 10% |
| 172209065 | 林伟豪 | 《系统设计和数据库设计答辩PPT》 | 10% |
| 102300228 | 杨欣潼 | 答辩汇报，博客编写 | 10% |
| 102300319 | 陈启航 | 《系统设计和数据库设计评审表》 | 10% |
| 102300311 | 方林升 | 《数据库设计说明书》和 博客编写 | 10% |
| 102300201 | 陈吕萌 | 《数据库设计说明书》和 绘图（ER图，类图等） | 10% |