239
社区成员
发帖
与我相关
我的任务
分享团队作业 概要设计和数据库设计
| 这个作业属于哪个课程 | FZU_university |
|---|---|
| 这个作业要求在哪里 | 团队作业 概要设计和数据库设计 |
| 这个作业的目标 | 系统设计与数据库设计 |
| 其他参考文献 | 《构建之法》、数据库设计说明书 |
目录
- 华为云仓库地址
- 1. 系统和数据库设计
- 1.1 体系结构设计图
- 1.2 功能模块层次图
- 1.3 数据库ER图设计
- 1.4 数据库表结构设计
- 2. 类图
- 3. 系统安全设计和权限设计
- 4. 改进分析
- 5. 团队协作
- 5.1 工作流程
- 5.2 任务分配和贡献度
- 6. 开发计划安排
- 6.1 时间安排
- 6.2 分工安排
华为云仓库地址
华为云团队仓库链接
fulifuli_系统设计说明书.pdf
fulifuli_数据库设计说明书.pdf
fulifuli_系统设计和数据库设计答辩PPT.pdf
1. 系统和数据库设计
1.1 体系结构设计图
1.1.1. 系统架构（单体式）
1.1.2. 系统架构（分布式）
这是本产品未来如果扩大业务规模后会采用的架构，考虑到起步时资金较少（硬件配置不足以支撑），暂不采用此类架构。
1.1.3 系统架构设计思路
在设计我们的视频网站系统架构时，我们采取了分层结构的原则，以确保系统的可扩展性、可维护性和高性能。以下是我们设计思路的详细阐述：
用户界面层（User Interface Layer）：
- 该层主要负责与用户进行交互，支持多种客户端（如浏览器和移动端）。
- 通过Hertz HTTP框架，用户能够方便地发送请求和接收数据，确保交互的快速响应。
中间件选择：
- 我们引入了JSON Web Token（JWT）进行身份验证和信息交换，确保用户的安全和数据的完整性。
- Sentinel被用来进行流量防卫，保护系统免受流量攻击，提高系统的稳定性。
- 使用Go语言相关的中间件，充分发挥Go语言的并发处理能力，提升系统的性能。
领域层（Domain Layer）：
- 领域层包含六大核心功能模块：用户管理、视频管理、社交互动、用户互动、举报功能以及动态更新。这些模块相互独立，又能协同工作，以满足用户多样化的需求。
- 通过将功能模块化，我们能够在未来更方便地进行功能扩展和升级。
数据存储：
- 非结构化数据（如图片、视频和音频）被存储在OSS中，以支持大规模数据的存储和访问。
- 领域层与基础设施层的数据库进行交互，使用MySQL作为持久化层，确保数据的可靠存储和快速访问。同时，利用Redis作为缓存层，提升数据的读取速度和系统的整体性能。
推荐系统：
- 引入Gorse推荐系统框架，旨在为用户提供个性化的推荐功能，提升用户体验，增加用户粘性。
分布式系统构想：
- 最终目标是构建一个分布式系统，以支持更高的并发访问和更好的可扩展性。在条件和资金允许的情况下，我们计划将各个功能模块拆分为独立的服务，利用微服务架构实现灵活部署和管理。
通过这样的设计思路，我们的系统架构不仅能满足当前的功能需求，还具备良好的扩展性和适应未来发展的能力。
1.1.4 基于上下文的事件驱动系统
Golang作为一门非传统面向对象编程语言，无法直接套用工厂模式来实现Strategy设计模式。为了应对这一挑战，本产品巧妙融合了微服务的核心理念，采用事件驱动（Event-Drive）机制作为替代方案，以此实现Strategy设计模式。
在设计中，我们定义了一个结构体，该结构体不仅包含了系统上下文信息（Context），还涵盖了请求上下文信息（RequestContext），我们将其命名为“事件（Event）”。这一设计充分满足了业务处理的需求。同时，我们引入了“分派者（Assigner）”这一角色，它负责处理并分发事件。无论是单体式的Task Assigner，还是分布式的RPC Client，都是分派者的具体实例。分派者能够依据上下文信息对事件进行细致区分，并据此完成业务的精准分发。从更深层次来看，这一设计正是微服务架构（或分布式架构）精髓的体现。在微服务架构中，各个微服务之间需要借助分派者进行数据的高效交流与协作。尽管在很多时候，我们更倾向于将分派者称为“Client”，但为了避免与UI层的Client产生混淆，我们仍坚持使用“分派者”这一术语。我们可以给出如下定义：
（1） Request Receiver：是系统接收外部请求的入口点。它负责监听来自客户端的请求，并将这些请求解析为系统内部可识别的事件对象。这个过程可能涉及对请求数据的验证、格式化以及必要的预处理，以确保数据的有效性和一致性。Request Receiver通常与系统的API网关或前端控制器相结合，为外部用户提供统一的访问接口。
（2） Assigner：是事件驱动架构中的核心组件之一。它负责接收来自Request Receiver的事件对象，并根据事件中的上下文信息（如事件类型、优先级、目标服务等）进行智能路由。Assigner可能采用复杂的算法或策略来决定哪个Service最适合处理当前事件。此外，Assigner还负责跟踪事件的处理状态，并在必要时进行重试或故障转移。
（3） Service：是执行具体业务逻辑的微服务单元。每个Service都封装了一组相关的业务功能，并对外提供API接口以供其他组件调用。在事件驱动的架构中，Service会监听来自Assigner的事件通知，并根据事件的内容执行相应的业务操作。这些操作可能涉及数据查询、数据更新、业务规则验证等。Service之间通过消息传递进行通信，以实现松耦合和高度可扩展性。
（4） Response Sender：是系统向外部客户端发送响应的出口点。它负责接收来自Assigner或Service的处理结果，并将这些结果封装成客户端可理解的响应格式。这个过程可能包括数据的格式化、加密、压缩等处理，以确保响应的准确性和安全性。Response Sender通常与系统的API网关或前端控制器相结合，为外部用户提供统一的响应接口。
在这样的架构中，Request Receiver首先捕获并解析来自客户端的请求，将其转化为事件对象并传递给Assigner。Assigner根据事件的上下文信息进行智能路由，将事件分发到相应的Service进行处理。Service执行具体的业务逻辑，并将处理结果返回给Assigner。最后，Response Sender接收处理结果，并将其封装成响应格式发送回客户端。
1.2 功能模块层次图
设计思路：
识别核心功能：从整体系统需求开始，确定系统的主要功能区块，如用户模块、视频模块、社交模块等。
分解子模块：将每个核心功能进一步细分为子模块，例如用户模块可以分解为注册、登录、信息编辑等子模块。
定义模块接口：确定模块之间的接口，即模块如何相互通信和交互数据。例如，用户模块的“用户注册”子模块需要与数据库模块交互以保存用户信息。
流程图设计：为每个子模块设计流程图，展示用户或系统在该模块内的操作流程。例如，用户注册流程可能包括填写信息、提交信息、验证信息、创建账户等步骤。
性能指标定义：为每个模块和子模块确定性能指标，如响应时间、数据精度等，并确保设计可以满足这些指标。
用户交互设计：考虑用户如何与每个模块交互，包括用户界面设计、用户体验考量等。
安全性和隐私：确保每个模块在设计时考虑了安全性和隐私保护，特别是涉及用户数据的模块。
技术选型：根据模块功能和性能要求，选择合适的技术和框架来实现模块。
模块间的依赖关系：确定模块之间的依赖关系，并在层次图中清晰表示出来。
迭代和反馈：设计初稿后，与团队成员进行讨论，收集反馈，并根据反馈进行迭代改进。
文档和规范：为每个模块编写详细的技术文档和实现规范，以便开发和维护。
其中，以用户模块设计为例
- 顶层模块：用户模块。
- 子模块：
- 用户注册
- 用户登录
- 用户信息
- 搜索用户
- 忘记密码
- 子模块功能：
- 用户注册：填写表单 -> 提交信息 -> 验证信息 -> 创建账户 -> 发送确认短信。
- 用户登录：输入用户名和密码 -> 验证身份 -> 进入主界面。
- 用户信息：显示个人信息 -> 允许编辑 -> 保存更改。
- 搜索用户：输入搜索词 -> 显示匹配的用户列表。
- 忘记密码：输入邮箱 -> 发送重置链接 -> 用户重置密码。
- 性能指标：响应时间应在2秒以内，数据精度需高，兼容性强，可重用性一般。
- 流程处理逻辑：例如，用户注册流程图会详细展示从用户填写信息到系统存储信息的整个过程。
1.3 数据库ER图设计
设计思路：
需求分析
视频平台的主要业务流程涉及：- 用户注册与管理。
- 视频的上传、评论、点赞等操作。
- 动态发布、互动（评论、点赞等）。
- 用户间的私信功能。
- 举报、审核等功能，用于维护平台内容的合法性。
- 为了支持上述功能，我们将数据库设计为多个表，分别存储用户、视频、评论、动态、举报、点赞等数据。我们也需考虑扩展性、安全性和效率优化，通过索引、关联关系、时间戳及软删除等设计，保证数据查询与更新的效率。
ER（实体关系）分析
以下为主要实体及其关系：- User：代表平台用户，管理用户信息。
- Video：代表用户上传的视频内容。
- Comment：用户对视频的评论，支持二级评论。
- Activity：用户发布的动态内容。
- Message：用户之间的私信功能。
- Report：举报功能，包括对视频、评论、动态等内容的举报。
- Like：点赞功能，针对视频、评论、动态的用户行为。
- Tag：管理视频标签及其关联关系。
1.4 数据库表结构设计
Activity表
id：bigint 类型，用来存储动态的唯一标识符。user_id：bigint 类型，用来存储与动态关联的用户ID。content：varchar 类型，长度为255，被标记为非空，用来存储动态的文本内容。media_url：varchar 类型，长度为255，用来存储活动的媒体文件（如图片或视> 频）的URL地址。visit_count：bigint 类型，用来存储动态被访问的次数。created_at：bigint 类型，用来存储动态创建的时间戳。updated_at：bigint 类型，用来存储动态最后更新的时间戳。deleted_at：bigint 类型，如果动态需要被删除，则存储删除的时间戳，记为被删除。
ActivityComment表
id：bigint 类型，用来存储动态评论的唯一标识符。user_id：bigint 类型，用来存储发表评论的用户ID。activity_id：bigint 类型，用来存储评论所属的动态ID。parent_id：bigint 类型，用来存储父评论的ID，如果是直接评论则为-1。content：varchar 类型，长度为255，用来存储评论的内容。created_at：bigint 类型，用来存储评论创建的时间戳。updated_at：bigint 类型，用来存储评论最后更新的时间戳。deleted_at：bigint 类型，如果评论需要被删除，则存储删除的时间戳，记为被删除。
ActivityCommentLike表
user_id：bigint 类型，用来存储点赞用户的ID。comment_id：bigint 类型，用来存储被点赞的评论的ID。created_at：bigint 类型，用来存储点赞操作创建的时间戳。deleted_at：bigint 类型，如果点赞需要被取消，则存储取消的时间戳，记为被取消。
ActivityCommentReport表
id：bigint 类型，用来存储举报记录的唯一标识符。user_id：bigint 类型，用来存储举报用户的ID。comment_id：bigint 类型，用来存储被举报的评论的ID。reason：varchar 类型，长度为255，用来存储举报的原因。created_at：bigint 类型，用来存储举报创建的时间戳。status：varchar 类型，长度为255，用来存储举报的处理状态。resolved_at：bigint 类型，用来存储举报解决的时间戳。admin_id：bigint 类型，用来存储处理举报的管理员ID。
ActivityLike表
user_id：bigint 类型，用来存储点赞用户的ID。activity_id：bigint 类型，用来存储被点赞的动态的ID。created_at：bigint 类型，用来存储点赞操作创建的时间戳。deleted_at：bigint 类型，如果点赞被取消，则存储取消的时间戳，记为被取消。
ActivityReport表
id：bigint 类型，用来存储动态举报的唯一标识符。user_id：bigint 类型，用来存储举报者的ID。activity_id：bigint 类型，用来存储被举报的动态的ID。reason：varchar 类型，长度为255，用来存储举报的原因。created_at：bigint 类型，用来存储举报创建的时间戳。status：varchar 类型，长度为255，用来存储举报的处理状态。resolved_at：bigint 类型，用来存储举报解决的时间戳。admin_id：bigint 类型，用来存储处理举报的管理员ID。
Follow表
follower_id：bigint 类型，用来存储关注者的用户ID。followee_id：bigint 类型，用来存储被关注者的用户ID。created_at：bigint 类型，用来存储关注关系创建的时间戳。deleted_at：bigint 类型，如果关注关系需要被删除，则存储删除的时间戳，记为被删除。
Message表
id：bigint 类型，用来存储消息的唯一标识符。from_user_id：bigint 类型，用来存储发送者的用户ID。to_user_id：bigint 类型，用来存储接收者的用户ID。content：varchar 类型，长度为255，用来存储消息的内容。created_at：bigint 类型，用来存储消息创建的时间戳。deleted_at：bigint 类型，如果消息需要被删除，则存储删除的时间戳，记为被删除。
Review表
id：bigint 类型，审核ID，唯一标识每条审核记录。video_id：bigint 类型，视频ID，表示被审核的视频的唯一标识符。reviewer_id：bigint 类型，审核者ID，表示进行审核的用户的唯一标识符。submitted_at：bigint 类型，提交时间，记录审核请求提交的时间戳。reviewed_at：bigint 类型，审核时间，记录审核结果处理完成的时间戳。review_result：varchar 类型，长度为255，审核结果，记录审核的结果说明（如通过、未通过等）。
Tag表
id：bigint 类型，标签ID，唯一标识每个标签。tag_name：varchar 类型，长度为255，标签名称，表示标签的具体名称，具有唯一性。created_at：bigint 类型，创建时间，记录标签创建的具体时间。deleted_at：bigint 类型，删除时间，记录标签被删除的时间，若未删除则为 NULL。
User表
uid：这是一个 bigint 类型的字段，用来存储用户的唯一标识符。username：这是一个 varchar 类型的字段，用来存储用户的用户名，最大长度为255个字符。password：这也是一个 varchar 类型的字段，用来存储用户的密码，最大长度为255个字符。role：varchar 类型的字段，用来存储用户的角色或权限级别，最大长度为255个字符。avatar_url：varchar 类型的字段，用来存储用户头像的URL地址，最大长度为255个字符。created_at：bigint 类型的字段，用来存储记录创建的时间戳。updated_at：bigint 类型的字段，用来存储记录最后更新的时间戳。deleted_at：bigint 类型的字段，如果用户需要被删除，则存储删除的时间戳，记为被删除。mfa_secret：varchar 类型的字段，用来存储多因素认证（MFA）的秘密，最大长度为255个字符。mfa_enable：tinyint 类型的字段，用来表示是否启用了多因素认证，1表示启用，0表示未启用。
Video表
id：BIGINT 类型，用来存储视频的唯一标识符。user_id：BIGINT 类型，用于存储与视频关联的用户的唯一标识符，确保与用户表的关联。video_url：VARCHAR(255) 类型，存储视频文件的 URL 地址，便于访问和播放视频内容。cover_url：VARCHAR(255) 类型，存储视频封面图片的 URL 地址，用于展示视频的缩略图。title：VARCHAR(255) 类型，存储视频的标题，便于用户识别和搜索。description：VARCHAR(255) 类型，存储视频的描述信息，提供视频内容的简要概述。visit_count：BIGINT 类型，存储视频的访问次数，以用于统计和分析用户行为。created_at：BIGINT 类型，存储视频创建的时间戳，记录视频上传时间。updated_at：BIGINT 类型，存储视频最后更新的时间戳，跟踪视频内容的修改历史。deleted_at：BIGINT 类型，如果视频需要被删除，则存储删除的时间戳，记为被删除。
VideoComment表
id：bigint 类型，用来存储视频评论的唯一标识符。user_id：bigint 类型，用来存储发表评论的用户ID。video_id：bigint 类型，用来存储评论所属的视频ID。parent_id：bigint 类型，用来存储父评论的ID，如果是直接评论则为-1。content：varchar 类型，长度为255，用来存储评论的内容。created_at：bigint 类型，用来存储评论创建的时间戳。updated_at：bigint 类型，用来存储评论最后更新的时间戳。deleted_at：bigint 类型，如果评论需要被删除，则存储删除的时间戳，记为被删除。
VideoCommentLike表
user_id：bigint 类型，用来存储点赞用户的ID。comment_id：bigint 类型，用来存储被点赞的评论的ID。created_at：bigint 类型，用来存储点赞操作创建的时间戳。deleted_at：bigint 类型，如果点赞需要被取消，则存储取消的时间戳，记为被取消。
VideoCommentReport表
id：bigint 类型，用来存储举报记录的唯一标识符。user_id：bigint 类型，用来存储举报用户的ID。comment_id：bigint 类型，用来存储被举报的评论的ID。reason：varchar 类型，长度为255，用来存储举报的原因。created_at：bigint 类型，用来存储举报创建的时间戳。status：varchar 类型，长度为255，用来存储举报的处理状态。resolved_at：bigint 类型，用来存储举报解决的时间戳。admin_id：bigint 类型，用来存储处理举报的管理员ID。
VideoLike表
user_id：bigint 类型，用来存储点赞用户的ID。video_id：bigint 类型，用来存储被点赞的视频的ID。created_at：bigint 类型，用来存储点赞操作创建的时间戳。deleted_at：bigint 类型，如果点赞被取消，则存储取消的时间戳，记为被取消。
VideoReport表
id：bigint 类型，用来存储视频举报的唯一标识符。user_id：bigint 类型，用来存储举报者的ID。video_id：bigint 类型，用来存储被举报的视频的ID。reason：varchar 类型，长度为255，用来存储举报的原因。created_at：bigint 类型，用来存储举报创建的时间戳。status：varchar 类型，长度为255，用来存储举报的处理状态。resolved_at：bigint 类型，用来存储举报解决的时间戳。admin_id：bigint 类型，用来存储处理举报的管理员ID。
VideoTag表
video_id：bigint 类型，表示与标签关联的视频的唯一标识符。tag_id：bigint类型，表示与视频关联的标签的唯一标识符。created_at：bigint 类型，记录视频与标签关联的具体时间。deleted_at：bigint 类型，记录关联被删除的时间，若未删除则为 NULL。
设计思路：
用户管理 (User)
- 该表是系统的核心，存储用户的基本信息，如用户名、密码、电子邮箱、角色等。
- 用户的头像通过
avatar_url存储，允许用户个性化其个人资料。 created_at,updated_at,deleted_at字段用于管理用户的生命周期，包括注册、更新和注销。
内容发布 (Video, Activity, Tag, VideoTag)
Video和Activity表存储用户上传的视频和动态内容。- 视频和动态都有
user_id字段，表示内容与用户的关系。 Tag表存储视频和动态的标签，而VideoTag表作为关联表，将视频与标签多对多关联起来。
社交互动 (Follow, VideoComment, ActivityComment, VideoLike, ActivityLike)
Follow表存储用户之间的关注关系。VideoComment和ActivityComment表存储用户对视频和动态的评论。VideoLike和ActivityLike表存储用户对视频和动态的点赞。
消息通信 (Message)
Message表存储用户之间的私信信息。- 包含发送者和接收者的用户ID，以及消息内容和时间戳。
用户反馈 (VideoReport, ActivityReport, VideoCommentReport, ActivityCommentReport)
- 这些表存储用户对不适当内容的举报。
- 包括举报者ID、被举报内容的ID、举报原因、举报状态和管理员处理信息。
内容审核 (Review)
Review表存储视频内容的审核记录。- 包括视频ID、审核者（管理员）ID、审核提交和处理的时间戳，以及审核结果。
在设计数据库表结构时，以下是一些关键点：
- 数据一致性：确保所有相关表通过外键正确关联，如用户ID、视频ID、动态ID等。
- 数据完整性：使用适当的数据类型和长度，确保数据存储的准确性和效率。
- 安全性：密码字段应该只存储密码的哈希值，不应该存储明文密码。
- 扩展性：设计时考虑未来可能的功能扩展，如增加新的社交特性或内容类型。
- 性能：考虑索引关键字段以提高查询效率，如用户ID、视频ID等。
- 软删除：使用
deleted_at字段实现软删除，保留数据的完整性，同时允许恢复。
每个表都应该有一个唯一的主键，如 id 字段，以便于快速查找和引用。外键用于维护表之间的关系，并确保引用完整性。
2. 类图
设计思路：
用户中心的设计:
- 用户(User)是中心实体，几乎所有功能都是围绕用户设计的。
- 用户可以进行常见的社交活动，如上传视频、发表评论、关注其他用户、发送私信等。
内容创作和分享:
- 视频(Video)类是内容创作的核心，用户可以上传视频，这是平台的主要功能之一。
- 视频类与用户类关联，表明每个视频都有一个上传者。
- 视频类还与评论(Comment)和标签(Tag)关联，表明视频可以被评论和分类。
社交互动:
- 评论(Comment)类允许用户对视频进行反馈，增加了用户间的互动。
- 关注(Follow)类体现了社交网络的特性，用户可以关注其他用户，形成社交关系网。
消息通信:
- 消息(Message)类提供了用户之间私信的功能，增强了用户间的直接交流。
用户反馈和参与:
- 动态(Post)类允许用户发布非视频内容，如状态更新或图片，增加了平台的互动性。
- 举报(Report)类让用户可以报告不适当的内容，这对于社区的健康至关重要。
- 点赞(Like)类为视频、动态和评论提供了点赞功能，这是用户参与和内容推广的重要机制。
平台审核:
- 审核(Review)类让平台可以审核用户视频，防止不当视频放出。
3. 系统安全设计和权限设计
防SQL注入：
- 使用参数化查询避免将用户输入直接嵌入到SQL语句中，防止恶意代码执行。
- 输入验证与过滤，确保数据格式、类型和长度正确。
- 遵循最小权限原则，限制数据库用户权限，降低潜在攻击带来的危害。
CSRF防御：
- 使用CSRF Token验证请求的合法性，避免恶意跨站请求。
- 引入HTTP Referer验证以确认请求来源，但不能依赖此方式作为唯一手段。
- 实施双因素认证（MFA）等额外的安全策略以进一步增强安全性。
XSS防御：
- 严格的输入验证，对所有用户输入进行处理，并对输出的内容进行HTML转义。
- 使用Content-Security-Policy（CSP）等安全头部限制执行脚本的来源。
DDOS防御：
- 使用Sentinel作为流量控制工具，通过QPS限制和线程控制来减少DDOS攻击对系统的影响。
- 实现预热模式和匀速排队等机制，使系统在面对突发流量时能逐步扩展响应能力。
多因素认证（MFA）：
- 采用基于TOTP算法的多因素认证，生成动态一次性密码，确保即使密码被窃取也无法再次使用。
用户密码安全：
- 使用MD5加密并结合加盐处理，确保即使同样的密码也会产生不同的加密结果，增加破解难度。
基于RSA的用户数据保护：
- RSA加密保护用户敏感信息的传输，确保只有拥有私钥的接收方能够解密数据，防止中间人攻击。
基于AWS S3的对象存储加密：
- 对存储在AWS S3的对象启用AES-256加密，并使用KMS管理加密密钥，确保数据传输和存储的安全。
健壮性设计：
- 状态码与响应时间的设置，保证前端能及时了解请求结果，并防止系统因长时间等待而卡死。
- 数据库操作限制避免过多请求同时访问数据库，防止数据库过载。
- 输入检测与数据转换确保用户输入的数据符合预期，避免格式不匹配带来的错误。
通过以上设计，系统能够有效抵御多种常见安全威胁，并具备较高的健壮性和可扩展性，保证在面对高并发访问或潜在安全威胁时仍能保持稳定运行。
4. 改进分析
改进类图，增加审核类，优化类之间的关系
具体如下：
用户类 (User)
- 改进前: 用户类与评论类的关系是依赖关系。
- 改进后: 用户类与评论类的关系应该是关联关系，因为用户不仅可以发表评论，还应该能查看和管理自己的评论历史。
视频类 (Video)
- 改进前: 视频类与用户类的关系仅限于上传。
- 改进后: 视频类与用户类的关系应该扩展到收藏和点赞，因为用户与视频的交互不仅限于上传，还包括收藏和点赞等行为。
审核类 (Audit)
- 新增: 引入审核类是为了确保平台内容的质量和合规性。这个类将负责审核用户上传的视频、动态和评论，确保它们不违反平台规则。
审核类 (Audit)
(1) 概述
- 审核类用于管理内容的审核流程，确保内容符合平台规范。
(2) 属性
- 审核ID: 审核的唯一标识符。
- 审核员ID: 进行内容审核的管理员ID。
- 内容ID: 待审核内容的ID。
- 审核状态: 当前内容的审核状态。
- 审核结果: 审核后的结果描述。
- 审核时间: 审核操作的时间戳。
(3) 操作
- 审核内容: 允许审核员对内容进行审核。
- 更改审核状态: 允许审核员更新内容的审核状态。
- 记录审核结果: 记录审核的具体结果。
(4) 类关系
- 审核类与视频类、动态类、评论类关联，表示审核可以针对这些内容类型。
5. 团队协作
5.1 工作流程
总体安排：
- 10.16-10.17（周四）分配小组&分配任务
- 10.17-10.20（周日）完成两个小组主要任务
- 10.21-10.22（周二）ppt制作，工作成果审核，华为云上传，总结整理团队协作，博客撰写，答辩准备，评审表制作
具体情况：
并且本次使用飞书进行协同工作，工作效率更快，贡献记录更准
| 版本号 | 修订日期 | 修订内容 | 修改原因 | 修订人 | 审核人 | 状态 |
|---|---|---|---|---|---|---|
| V1.0 | 2024/10/17 | 完成初稿 | 陈奕逵、林佳圣、林家豪 | 陈奕逵 | 已完成 | |
| V1.1 | 2024/10/18 | 功能模块、接口设计 | 补充内容 | 陈奕逵、林佳圣、林家豪 | 陈奕逵 | 已完成 |
| V1.2 | 2024/10/19 | 接口设计 | 补充内容 | 陈奕逵 | 陈奕逵 | 已完成 |
| 版本号 | 修订日期 | 修订内容 | 修改原因 | 修订人 | 审核人 | 状态 |
|---|---|---|---|---|---|---|
| V1.0 | 2024/10/18 | 完成初稿 | 罗鸿远 刘思睿 江祖权 李滨 | 罗鸿远 | 已完成 | |
| V1.1 | 2024/10/19 | ER图、逻辑结构设计 | 补充内容 | 罗鸿远 刘思睿 江祖权 李滨 | 罗鸿远 | 已完成 |
| V1.2 | 2024/10/22 | 类图 | 补充内容 | 罗鸿远 | 罗鸿远 | 已完成 |
5.2 任务分配和贡献度
| 成员列表 | 工作内容 | 贡献度比例（%） |
|---|---|---|
| 倪墨 | 审核《系统设计说明书》和《数据库系统设计说明书》，参与类图修改，参与博客撰写，参与ppt制作，答辩 | 12.0 |
| 陈奕逵 | 系统设计组长，《系统设计说明书》架构设计、接口设计 | 16.2 |
| 林佳圣 | 数据流图，《系统设计说明书》软件功能结构、系统功能模块，制作评审表 | 11.8 |
| 林家豪 | 用例图、《系统设计说明书》系统功能模块，参与博客撰写 | 11.8 |
| 罗鸿远 | 数据库设计组长，数据库设计，表结构设计，审核修改《数据库系统设计说明书》 | 13.1 |
| 刘思睿 | 参与ER分析和画ER图，修改类图，参与PPT制作 | 11.8 |
| 江祖权 | 主要撰写《数据库设计说明书》，画新ER图 | 11.5 |
| 李滨 | 参与ER分析和画ER图，表达“团队项目的预期开发计划时间安排、团队项目的预期开发计划分工安排”，参与PPT制作 | 11.8 |
6. 开发计划安排
6.1 时间安排
6.2 分工安排
| 成员 | 角色 | 开发任务安排 |
|---|---|---|
| 222200320林佳圣 | 前端 | 动态发布界面和评论功能实现、响应式设计与用户体验优化 |
| 222200403刘思睿 | 前端 | 视频上传界面设计与实现、消息界面开发 |
| 222200406李滨 | 前端 | 用户注册和登录界面开发、用户信息修改界面设计 |
| 222200122林家豪 | 后端 | 用户模块（用户注册、登录和信息管理）、工具接口（数据处理与集成接口） |
| 222200316陈奕逵 | 后端 | 视频模块、社交模块、动态模块、互动模块、风纪模块 |
| 222200425倪墨 | 前端测试 | 负责前端功能测试与用户体验反馈，进行安全性测试，包括XSS和其他安全漏洞 |
| 222200323罗鸿远 | 后端测试 | 负责后端接口测试，确保API功能正常，进行性能测试与压力测试，评估系统稳定性 |
| 222200405江祖权 | 测试支持 | 协助测试团队，收集反馈和整理测试结果，文档的撰写 |
...全文
请发表友善的回复…
发表回复
