# 一、Schema范式设计 ## 训练计划及任务执行模块 ### 训练计划模块描述 根据用户所需要的健身目标，生成的整个训练计划，训练计划中包含了很多子任务。 ### 任务执行模块描述 记录各类型子任务以及每项任务的执行情况 #### 任务类型 - 一次性任务 - 周期性任务（每日、每周、每月） #### 任务状态 - 一次性任务，可以在任务数据中直接标注完成 - 周期性任务，虽然整体有完成状态，但是每次的执行都需要有单独的表来记录。 ## 具体范式设计 ### 1. 表设计 #### 1.1 训练计划表 (TrainingPlan) | 字段 | 类型 | 说明 | |----------|--------------|------------------| | objectId | String | 唯一标识符 | | createdAt | Date | 创建时间 | | user | Pointer | 关联用户 | | goal | String | 健身目标 | | content | String | 训练计划详情 | | tasks | Array> | 关联的子任务 | #### 1.2 任务表 (Task) | 字段 | 类型 | 说明 | |-----------|--------------|----------------------------| | objectId | String | 唯一标识符 | | createdAt | Date | 创建时间 | | plan | Pointer | 关联训练计划 | | type | String | 任务类型（一次性任务/周期性任务） | | name | String | 任务名称 | | status | String | 任务状态（未完成/已完成） | | count | Number | 执行次数 | | duration | Number | 持续时间 | | frequency | String | 周期性任务的频率（每日/每周/每月，可选） | #### 1.3 任务执行记录表 (TaskExecution) | 字段 | 类型 | 说明 | |----------|--------------|------------------------| | objectId | String | 唯一标识符 | | createdAt | Date | 创建时间 | | task | Pointer | 关联任务 | | execDate | Date | 执行日期 | | status | String | 执行状态（完成/未完成） | #### 1.4 用户表 (User) | 字段 | 类型 | 说明 | |----------|--------------|------------------| | objectId | String | 唯一标识符 | | createdAt | Date | 创建时间 | | username | String | 用户名 | | email | String | 用户邮箱 | | password | String | 用户密码 | ### 2. PlantUML 类图表示 以下是使用PlantUML表示的类图： ```plantuml @startuml class User { +objectId: String +createdAt: Date +username: String +email: String +password: String } class TrainingPlan { +objectId: String +createdAt: Date +goal: String +content: String } class Task { +objectId: String +createdAt: Date +type: String +name: String +status: String +count: Number +duration: Number +frequency: String } class TaskExecution { +objectId: String +createdAt: Date +execDate: Date +status: String } User "1" -- "0..*" TrainingPlan : owns TrainingPlan "1" -- "0..*" Task : contains Task "1" -- "0..*" TaskExecution : executes @enduml ``` ##打卡签到模块 ###模块描述 用户表是_User表 用户每日登录后，可以打卡签到，记录用户的签到时间，和日期，且每日只能打卡签到一次。 ### 1. 用户表 (_User) #### 表名：User #### 字段： - **objectId**：String (用户唯一标识) - **username**：String (用户名) - **email**：String (用户邮箱) - **createdAt**：Date (创建时间) - **updatedAt**：Date (更新时间) --- ## 2. 签到记录表 (SignInRecord) #### 表名：SignInRecord #### 字段： - **objectId**：String (签到记录唯一标识) - **user**：Pointer (用户，外键，关联到User表) - **signInDate**：Date (签到日期) - **createdAt**：Date (创建时间) --- ### 3. 设计注意事项 - 在 **SignInRecord** 表中，`user` 字段使用 `Pointer` 来表示与用户表的关联。 - 每个用户每天只能有一条签到记录，因此在 **SignInRecord** 表中，`user` 和 `signInDate` 的组合应当是唯一的。 - `createdAt` 字段用于记录每条记录的创建时间，以便于后续的数据追踪。 #### PlantUML 类图表示 ```plantuml @startuml class User { +objectId: String +username: String +email: String +createdAt: Date +updatedAt: Date } class SignInRecord { +objectId: String +user: Pointer +signInDate: Date +createdAt: Date } User "1" -- "0..*" SignInRecord : has @enduml ``` # 二、业务逻辑描述 ## 训练计划的完整逻辑 ### 计划生成逻辑 用户在APP内，通过文本生成整个训练计划。 #### 数据来源 - **用户输入**：用户的健身需求等。 - **用户体征**：性别、年龄、体重等。 #### 结果存储 - **TrainingPlan** - 计划目标 `goal`：计划需求标题。 - 计划详情 `content`：完整计划内容。 ### 根据训练计划结果，排期生成任务 #### 数据来源 - **计划详情** `content`。 #### 文本生成 ```json [ { "objectId": "task_001", "createdAt": "2024-12-01T10:00:00Z", "plan": "TrainingPlan_001", "type": "一次性任务", "name": "30分钟有氧运动", "status": "未完成", "count": 1, "duration": 30, "frequency": null }, { "objectId": "task_002", "createdAt": "2024-12-01T10:00:00Z", "plan": "TrainingPlan_001", "type": "周期性任务", "name": "每周力量训练", "status": "已完成", "count": 4, "duration": 60, "frequency": "weekly" }, { "objectId": "task_003", "createdAt": "2024-12-01T10:00:00Z", "plan": "TrainingPlan_001", "type": "周期性任务", "name": "每日步行1万步", "status": "未完成", "count": 8, "duration": 60, "frequency": "daily" }, { "objectId": "task_004", "createdAt": "2024-12-01T10:00:00Z", "plan": "TrainingPlan_001", "type": "周期性任务", "name": "每月体重测量", "status": "已完成", "count": 1, "duration": 10, "frequency": "monthly" }, { "objectId": "task_005", "createdAt": "2024-12-01T10:00:00Z", "plan": "TrainingPlan_001", "type": "一次性任务", "name": "参加健身课程", "status": "未完成", "count": 1, "duration": 45, "frequency": null } ] ``` ### 计划执行的逻辑 #### 用户在 TodoList 页面，加载所有计划和子任务。 - 用户主动填写执行情况并提交。 #### 数据存储 - **TaskExecution**：记录每次用户执行情况提交的数据，并在提交后，根据 **Task** 中持续时间和次数条件，来判断 **Task** 本身是否标记完成。 #### 计划的完成和统计分析 - 连表查询，分析用户计划完成的总体情况和进度。 ### 训练计划业务逻辑图例 **提示词**：{业务逻辑}，您是一名专业的产品经理，请您将上述逻辑的每个过程，用 PlantUML 的时序图表示出来。 ### 业务逻辑图例 下面是根据您提供的业务逻辑描述所生成的 **PlantUML** 时序图。这个时序图展示了训练计划的生成、执行和完成统计分析的各个过程： ```plantuml @startuml actor User entity APP entity TrainingPlan entity Task entity TaskExecution User -> APP: 输入健身需求和体征信息 APP -> TrainingPlan: 生成训练计划 APP -> Task: 根据计划生成任务 User -> APP: 查看任务和子任务 User -> APP: 提交任务执行情况 APP -> TaskExecution: 记录执行情况 APP -> Task: 判断任务是否完成 APP -> User: 展示任务完成情况 @enduml ``` ### 解释 1. **训练计划生成逻辑**：通过用户输入的健身需求和体征信息，生成训练计划，并存储到 **TrainingPlan** 表中。 2. **任务生成**：根据训练计划的内容生成相关任务，每个任务存储到 **Task** 表中，并关联到相应的训练计划。 3. **任务执行**：用户在 TodoList 页面查看任务，并提交执行情况。每次执行情况记录在 **TaskExecution** 表中。 4. **任务完成标记**：通过任务的持续时间和次数条件，判断任务是否标记为完成。 5. **计划统计分析**：通过连表查询，分析用户任务完成的整体情况和进度。