<<<<<<< HEAD # 一、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`。 #### 文本生成 ======= # 一、训练计划及任务执行模块 - 训练计划模块描述 - 根据用户所需要的健身目标，生成的整个训练计划，训练计划中包含了很多子任务。 - 任务执行模块描述 - 记录各类型子任务以及每项任务的执行情况 - 任务类型 - 一次性任务 - 周期性任务（每日、每周、每月） - 任务状态 - 一次性任务，可以再任务数据中直接标注完成 - 周期性任务，虽然整体有完成状态，但是每次的执行都需要有单独的表来记录。 # 表设计 ## 训练计划表 (TrainingPlan) - **objectId**: 唯一标识符 - **createdAt**: 创建时间 - **user**: Pointer (关联用户) - **goal**: String (健身目标) - **content**: String (训练计划详情) - **tasks**: Array (关联的子任务) ## 任务表 (Task) - **objectId**: 唯一标识符 - **createdAt**: 创建时间 - **plan**: Pointer (关联训练计划) - **type**: String (任务类型，如“一次性任务”或“周期性任务”) - **name**: String (任务名称) - **status**: String (任务状态，如“未完成”、“已完成”) - **count**: Number 执行次数 - **duration**: Number 持续时间 - **frequency**: String (周期性任务的频率，如“每日”、“每周”、“每月”，可选) - daily - weekly - monthly - yearly ## 任务执行记录表 (TaskExecution) - **objectId**: 唯一标识符 - **createdAt**: 创建时间 - **task**: Pointer (关联任务) - **execDate**: Date (执行日期) - **status**: String (执行状态，如“完成”、“未完成”) ## 用户表 (User) - **objectId**: 唯一标识符 - **createdAt**: 创建时间 - **username**: String (用户名) - **email**: String (用户邮箱) - **password**: String (用户密码) - **phoneNumber**: String (用户电话) - **sex**: String (用户性别) - **age**: Number (用户年龄) # PlantUML 类图表示 ## 以下是使用 PlantUML 表示的类图： ```plantuml @startuml class TrainingPlan { +objectId: String +createdAt: Date +user: Pointer +goal: String +content: String +tasks: Array } class Task { +objectId: String +createdAt: Date +plan: Pointer +type: String +name: String +status: String +count: Number +duration: Number +frequency: String } class TaskExecution { +objectId: String +createdAt: Date +task: Pointer +execDate: Date +status: String } class User { +objectId: String +createdAt: Date +username: String +email: String +password: String +phoneNumber: String +sex: String +age: Number } TrainingPlan "1" -- "1..*" Task : contains Task "1" -- "0..*" TaskExecution : executes User "1" -- "0..*" TrainingPlan : creates @enduml ``` # 设计说明 - **用户表 (User)**: 存储用户的基本信息。 - **训练计划表 (TrainingPlan)**: 每个用户可以有多个训练计划，每个计划可以包含多个子任务。 - **任务表 (Task)**: 定义了训练计划中的子任务，支持一次性和周期性任务。 - **任务执行记录表 (TaskExecution)**: 记录每个任务的执行情况，便于追踪任务的完成状态。 # 打卡签到模块 - 模块描述 用户表是\_User 表 用户每日登录后，可以打卡签到，记录用户的签到时间，和日期，且每日只能打卡签到一次。 ## 用户表 (\_User) - **表名**：User - **字段**： - objectId: String (用户唯一标识) - username: String (用户名) - email: String (用户邮箱) - createdAt: Date (创建时间) - updatedAt: Date (更新时间) ## 签到记录表 (SignInRecord) - **表名**：SignInRecord - **字段**： - bjectId: String (签到记录唯一标识) - ser: Pointer (用户，外键，关联到 User 表) - ignInDate: Date (签到日期) - reatedAt: Date (创建时间) # 设计注意事项 - 在 `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 ``` ## 说明 - `User` 类表示用户表，包含用户的基本信息。 - `SignInRecord` 类表示签到记录表，记录用户的签到情况。 - 外键 `user` 使用 `Pointer` 表示与用户表的关联。 - 关系表示为“一个用户可以有零到多个签到记录”，符合设计范式。 这种设计确保了数据的完整性和一致性，同时能够满足用户每日只能打卡一次的需求。 # 二、业务逻辑描述 # 训练计划的完整逻辑 ## 计划生成逻辑 - 用户在 APP 内，通过文本生成整个训练计划 - 数据来源 - 用户输入：用户的健身需求等 - 用户体征：性别、年龄、体重等 - 文本生成 - 提示词：训练计划生成提示词 - 结果存储 - TrainingPlan - 计划目标 goal 计划需求标题 - 计划详情 content 完整计划内容 - 根据训练计划结果，排期生成任务 - 数据来源 - 计划详情 content - 文本生成 - 提示词：严格限制 json 格式，输出任务列表（附带当前时- 间，用于时间的生成） - 生成结果：taskList - 循环数组，向 Task 表逐个插入数据。 >>>>>>> 538aa7279b9922f4eaea6729b67ae3a16c956e85 ```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 } ] ``` <<<<<<< HEAD ### 计划执行的逻辑 #### 用户在 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. **计划统计分析**：通过连表查询，分析用户任务完成的整体情况和进度。 ======= ## 计划执行的逻辑 - 用户在 TodoList 页面，加载所有计划和子任务 - 用户主动填写执行情况并提交 - 数据存储 - TaskExecution 记录每次用户执行情况提交的数据，并在提交后，根据 Task 中持续时间和次数条件，来判断 Task 本身是否标记完成。 ## 计划的完成和统计分析 - 连表查询，分析用户计划完成的总体情况和进度 ## 训练计划业务逻辑图例 ```plantuml @startuml actor User participant "APP" as App participant "TrainingPlan" as TP participant "Task" as T participant "TaskExecution" as TE == 计划生成逻辑 == User -> App : 输入健身需求 App -> TP : 创建训练计划 TP -> App : 返回训练计划ID == 计划执行逻辑 == User -> App : 加载所有计划和子任务 App -> T : 查询任务列表 T -> App : 返回任务列表 User -> App : 填写执行情况并提交 App -> TE : 记录执行情况 TE -> App : 返回执行记录ID App -> T : 检查任务完成状态 T -> App : 更新任务状态 == 计划完成和统计分析 == App -> TP : 查询用户计划完成情况 TP -> App : 返回完成情况和进度 App -> User : 显示统计分析结果 @enduml ``` ### 说明： - **用户(User)**在 APP 中输入健身需求和体征信息，APP 生成训练计划并返回。 - APP 根据训练计划生成任务列表并插入任务数据。 - 用户在 TodoList 页面查看计划和子任务，并提交执行情况。 - APP 记录执行情况，并判断任务是否完成。 - 最后，APP 进行统计分析并将结果展示给用户。 >>>>>>> 538aa7279b9922f4eaea6729b67ae3a16c956e85