掌中生活——项目系统设计与数据库设计

这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践团队作业三——概要设计与数据库设计
团队名称	掌中生活（LifeMap）
这个作业的目标	完成项目的系统设计与数据库设计：确定体系结构与功能模块划分，完成 ER 分析与表结构设计，给出设计类图与系统安全、权限方案，回答需求分析阶段的评审问题，并制定到学期末的开发计划
其他参考文献	见文末参考文献

---

交付物链接：

• 华为云团队仓库
• 掌中生活_系统设计说明书.pdf
• 掌中生活_数据库设计说明书.pdf
• 掌中生活_系统设计和数据库设计答辩PPT.pdf

写在最前面：一次重要的形态调整。 本次设计对项目形态做了一次重大决策：由选题阶段的 Web 端设想（Vue + Spring Boot + MySQL）调整为单设备本地移动应用（Android 原生 + SQLite 单文件数据库，无网络权限）。原因在需求分析阶段已充分讨论并登记于 SRS 附录 B——本系统收纳证件、合同、账单与账号凭据等高度敏感的个人信息，"数据不出本机"本身就是一个安全特性。这一调整贯穿本文全部设计：没有服务端、没有 HTTP 接口、没有数据库服务器，安全边界从"网络防线"收缩为"设备与数据库之间"。本文所有图表均取自《系统设计说明书 V1.0》与《数据库设计说明书 V2.0》，图号与文档一致，便于对照阅读。

---

目录

---

一、系统与数据库设计

1.1 体系结构设计

总体形态：掌中生活 LifeMap 是单设备、单进程、完全离线的移动应用。全部数据（SQLite 数据库、附件文件、备份包）落在应用私有沙箱内，密钥托管于系统安全区。系统在"架构风格比较"中对比了经典三层、MVVM + 仓储、整洁架构三种候选风格后，最终采用 "四层 + 网关"混合架构：纵向分为表示层、应用服务层、领域层、基础设施层，依赖方向严格自上而下；平台能力（生物识别、通知、时钟、文件选择）全部经网关接口注入，上层不直接绑定任何平台 API。

上图是《系统设计说明书》的图 2-1。四层之外，右侧三条"层间约束"是本次设计最有分量的部分：表示层不持有数据访问与解密能力（凡页面代码出现 SQL 或加解密调用即判为设计违规），一次用户操作只对应一个事务边界（新建记录涉及五张表的写入必须同成败），加密与密钥只在基础设施层收口。这三条约束把"受保护记录在列表里只显示掩码"从编码纪律变成了结构上无法违反的性质。

存储分区同样遵循"边界唯一"的原则：lifemap.db 是唯一结构化数据源，附件文件按 user_id 分目录存放于私有目录（库中只存相对路径），备份包 .lmbk 自包含可换机恢复，诊断日志经审计组件过滤后只留错误码与时间戳。图中加密边界清晰标出：受保护字段与附件在进入存储之前完成加密，任何一层都拿不到"明文落盘"的路径。

部署形态因此极为简单：一份 APK 安装包即全部交付物，无服务端、无数据库服务器、无运维监控。系统安全区、系统通知、相机/相册等设备能力全部由操作系统提供，应用只经网关调用——旧设备上能力缺失时以降级方式运行而不是崩溃。

技术选型（详细论证见系统设计说明书 2.5 节）：

• 移动端框架：Android 原生（Kotlin）+ Jetpack（跨端方案待定，架构已把不确定性收敛在网关层）
• 本地数据库：SQLite 3.45+（Room 持久化库提供编译期 SQL 校验）
• 加密：AES-256-GCM（自带完整性校验，密文被篡改可检出）；口令派生 PBKDF2-HMAC-SHA256（迭代 ≥ 100000）
• 通知：系统本地通知（无网络权限下唯一可行的提醒通道）；生物识别：BiometricPrompt（应用不接触原始生物特征）

设计思路：这个项目的业务复杂度不在"功能多"，而在两处——敏感数据的存取与展示、日期推导提醒。体系结构的每一次取舍都围绕这两处展开：四层架构保证加密有唯一边界、明文有唯一出口；网关注入保证时钟可替换、提醒逻辑可穷举测试；单机形态保证"数据不出本机"这一最重要的隐私承诺天然成立。

1.2 功能模块层次设计

模块划分直接承接 SRS 的功能结构，把 21 条功能需求组织为九个业务模块 A～I，外加一组跨模块复用的公共支撑组件 Z。划分结果与需求归属见下图。

模块清单与职责（摘录）：

模块	职责	承载需求
A 账号与安全	本地账号生命周期、敏感级别策略、加密存取、二次验证	FR-01～FR-07
B 记录管理	记录的创建、编辑、删除、详情组装	FR-08～FR-11
C 分类与标签	类别预置数据维护、标签即时创建与合并	FR-12
D 附件归档	拍照/相册/文件导入、缩略图、预览、巡检	FR-13
E 本地数据	持久化、结构升级迁移、加密备份与恢复	FR-14, FR-21
F 状态跟踪	未处理/处理中/已完成三态流转与留痕	FR-15
G 关键日期	日期节点维护、重复规则、提前天数	FR-16
H 提醒通知	提醒任务生成、待办扫描排序、到期通知送达	FR-17～FR-19
I 检索	关键词搜索与多条件筛选	FR-20
Z 公共支撑	密钥、掩码投影、校验、日期计算、审计留痕	支撑全部

模块划分中有两处值得一提的打磨：一是"状态跟踪"从记录管理中独立为 F 模块——推演 FR-15 时发现状态变更要写日志、触发待办重算、联动关闭提醒，职责已超出 CRUD 范畴；二是模块依赖矩阵暴露的环形依赖（B → F → H → B）通过领域事件解决：F 只发布 StatusChanged 事件，H 订阅后自行关闭任务，依赖方向保持单向。

设计思路：层次化遵循"越向下越具体"：模块层定义"谁负责什么"，页面层把 P1～P10 十个页面绑定到 ViewModel 与服务，服务层给出方法签名与事务边界，领域层承载 12 个领域类与四个规则对象（SensitivityPolicy、MaskProjector、DateCalculator、StatusMachine）。每一层的产出都可以单独评审、单独测试。

1.3 ER 分析

数据库设计采用概念 → 逻辑 → 物理三层递进（对应 GB/T 8567 的分层要求）。概念层从 21 条功能需求中按"独立生命周期 + 多属性 + 被功能引用"三条标准提取出 15 个实体、15 条联系；另有 5 个概念被明确判定为不建模——"提醒"拆为 DateNode 与 ReminderTask 两个实体（配置与运行实例生命周期不同），"搜索条件""加密密钥""用户角色""统计报表"分别由查询语句、密钥模块、应用层策略、视图承载。

15 条联系按聚合关系切成三张 ER 图：

记录聚合：record 是聚合根，向下连五个子实体——凭据（1:0..1，仅账号凭据类记录拥有）、标签（经 record_tag 连接表，N:M）、附件（1:N，≤9 个）、日期节点（1:N，≤5 个）、提醒任务（由节点派生，1:N）。注意标签与记录之间是"两跳"连接：标签属于账号、可被多条记录复用，直接存标签文本会导致改名遍历、统计全表扫描。

账号聚合：app_user 是另一个聚合根，下连偏好（1:1，必须存在）、分类默认值（1:N，账号建立时由触发器写入四条）、标签（1:N，账号内唯一）。category 是全文唯一不受账号约束的实体——四行系统常量，所有账号共享；它与 user_category_setting 共同构成"账号 × 分类"联合主键。

审计与支撑：三个实体对父对象的依赖强度用删除策略区分——status_log 强依赖（记录删除即级联消失，脱离记录的状态日志无意义）；access_log 弱依赖（记录删除后 record_id 置空、日志保留，审计价值恰在"记录已不存在之后"）；file_cleanup_queue 连账号侧也可空（账号删除后孤儿文件仍需清理）。

同一概念在三层的表述逐层具体化，以"台账记录"为例：概念层只有属性清单；逻辑层确定码与函数依赖（全部关系达到 BCNF）；物理层把 remark 拆为 remark_plain 与 remark_cipher 两列、amount 拆为 amount_minor 与 amount_cipher 两列——这一拆分是本次数据库设计最重要的决定，让"明密互斥"成为库内 CHECK 约束可直接检验的不变量。

设计思路：先给联系清单表、再画 ER 图，是刻意安排的阅读顺序——表可以逐行核对，图只能整体意会。15 条联系中每条都标了基数与参与度，因为"子端 0..1"决定物理层外键加 UNIQUE、"参与度可空"决定 ON DELETE SET NULL，概念层的每个断言都能落到物理层的列可空性、唯一约束与删除动作三件事上。

1.4 表结构设计

15 张表共 119 个字段、16 个索引、14 个触发器、2 个视图，按生命周期一致性划分为五个数据域：

五个数据域（账号与偏好、记录与证据、时间与提醒、审计、技术支撑）的划分依据是"同域内的表同时创建、同时删除、同时备份"，备份、清理、迁移都可以按域成组处理。

建表必须按外键依赖由浅到深的四层顺序执行，否则外键会引用到尚不存在的表。全部 DDL 集中在 517 行可执行脚本 sql/lifemap_schema.sql（附录 A 全文收录），幂等可重复执行。

核心表 record 的字段设计最能体现本项目的特点：remark_* 与 amount_* 各有明密两列，sensitivity 决定此刻哪一列有效——"必填"与"必须为 NULL"成对出现，第三种形态（明密并存、有密文无版本号）会被 8 条 CHECK 直接拒绝。

以 record 表为例的完整字段定义（全文见数据库设计说明书第 5 章）：

字段	类型	约束与说明
record_id	INTEGER	主键，AUTOINCREMENT
user_id	INTEGER	FK→app_user，CASCADE；账号隔离的根条件
category_id	INTEGER	FK→category，RESTRICT；记录必属一类
name	TEXT	记录名称，1~50 字符；明文（列表页需要显示）
sensitivity	TEXT	敏感级别，CHECK IN ('PLAINTEXT','PROTECTED')
status	TEXT	处理状态，CHECK IN ('PENDING','DOING','DONE')
remark_plain / remark_cipher	TEXT / BLOB	备注明/密文，互斥
amount_minor / amount_cipher	INTEGER / BLOB	金额（分）明/密文，互斥
crypto_version	INTEGER	密钥版本，有任一密文列时必须非空
created_at / updated_at	TEXT	ISO 8601 UTC 文本

其他关键设计决定（完整论证见数据库设计说明书第 5、8 章）：

• 数据类型刻意极简：只用 INTEGER / TEXT / BLOB 三种。金额存"分"（INTEGER，浮点误差不可接受）；时间存定长 ISO 8601 UTC 文本（字符串比较即时间比较，可用 GLOB 校验格式）；密文存 BLOB（不做 Base64 编码，避免 33% 膨胀）。
• 两处有意反范式：reminder_task.user_id 冗余（提醒扫描是最高频查询，避免三层 join），由 trg_reminder_owner 触发器保证属主一致；tag.normalized_name 冗余（SQLite 的 NOCASE 只处理 ASCII，中文全半角判重靠归一化列 + 唯一约束）。
• 14 个触发器分三类：数量上限（标签 ≤5、节点 ≤5、附件 ≤9）、账号隔离（跨账号绑定/日志直接拒绝）、存储形态一致（受保护记录不得存明文列、切换敏感级别前子实体必须已迁移）。全部用 RAISE(ABORT) 抛出带编码的错误消息（DBAC-xx），测试脚本按错误码精确断言。
• 删除策略三态：级联（随记录消失的附属物）、RESTRICT（系统常量分类不可删）、SET NULL（审计与清理信息必须比业务数据活得更久）。
• 验收即文档：verify_db.py 的 17 项验收用例（DB-AC-01～17）全部通过，实测输出见附录 C——包括"删除记录后 access_log 保留且 record_id 置空"这类容易被口头上"承诺"却从未验证的行为。

设计思路：数据库设计的立场是"约束下沉到库"——凡能用 CHECK、UNIQUE、外键、触发器表达的正确性要求，绝不只写在应用代码里。原因很直接：应用代码有无数条路径，库内约束只有一处；一条 PRAGMA foreign_keys = ON（SQLite 默认关闭外键！）在连接工厂统一执行，就是全部引用完整性。代价是 SQL 写法受 SQLite 方言约束，但换来的是每一处安全不变量都可以被一条 SQL 验证。

---

二、类图、系统安全和权限设计

2.1 设计类图

设计类图与需求分析阶段领域类图的关系是"演进而非重画"：12 个领域类保持映射关系不变，本次新增的是需求阶段刻意不画的三类——边界类（服务与仓储接口）、控制类（八个服务类承担用例编排与事务边界）、基础设施类（把加密、时钟、生物识别等平台差异收敛为可替换构件）。设计类图按业务链路组织，下面两张图分别给出记录管理主链路与账号、密码与权限安全链路。

上图以 RecordService 为核心给出记录管理主链路的完整类结构：表示层（RecordListActivity / RecordEditActivity）只调用服务层；服务层由 RecordService 牵头，与 ReminderService（提醒同步与到期扫描）、AttachmentService（附件导入与校验）协作；领域对象 Record 携带 category / sensitivity / status 等核心属性；数据访问统一经由 RecordRepository 等仓储接口。图中有两个值得注意的规则对象：SensitivityPolicy 统一"判定级别"——全系统只有它决定一个字段要不要加密；MaskProjector 统一"投影明文或掩码"——记录列表、详情、通知三处展示都必须经它生成字符串，这两者分别对应 1.1 节提到的单一加密边界与明文出口唯一。

上图给出账号、密码与权限安全链路的类结构：LoginActivity → AccountService（login / changePassword / resetPassword / switchAccount）；PermissionPolicy 承担权限判定（canView / canEdit / requireVerify）；UnlockSession 触发二次验证，配合 VerificationCounter（maxFail = 5、lockMinutes = 5）做失败计数与锁定；SessionManager 管理会话生命周期；KeyStore 封装系统安全区的密钥存取（requireCipher / wrap），应用代码不直接接触密钥句柄；展示侧仍统一经 MaskProjector 投影。

两张图共同的依赖纪律：服务层只依赖仓储接口与网关接口（不依赖实现），仓储实现是唯一接触 SQL 的位置，领域层不感知任何平台 API——这正是 2.3 节账号隔离与安全不变量能够在代码层被审计的前提。

2.2 系统安全设计

安全设计从威胁建模开始：先明确要防谁（手机被借用翻看、丢失后暴力破解、恶意应用读私有目录、日志泄漏、备份包被截获、截图外泄、剪贴板监听、在线猜口令八类威胁），再逐条给出对策（完整威胁模型见系统设计说明书 5.1 节）。加密方案分三层：口令派生（PBKDF2-HMAC-SHA256，迭代 ≥100000，独立盐）、业务数据加密（AES-256-GCM，每字段独立 nonce）、备份包加密（独立口令派生密钥包裹 DEK）。

每个密文单元格存的不是裸密文，而是带自描述头的密文信封：4 字节 magic 快速识别损坏、2 字节版本号支持密钥轮换、12 字节随机 nonce、密文、16 字节 GCM 认证标签。更关键的是 AAD（认证附加数据）——解密时用 user_id + record_id + field_code + crypto_version 四个值重新拼出 AAD 参与校验，把密文"钉"在特定的一行一字段上：攻击者即使把 B 行的密文整段复制到 A 行，GCM 校验直接失败。没有 AAD，这种"密文搬家"攻击完全无法被发现。

写入与读取路径成对收敛在 CryptoService：先加密、后入库，明文列保持 NULL；SELECT 只取密文列，解密在仓储方法返回前完成，明文从不出现在 SQL 语句里。解密失败一律按"数据不可用"处理、不降级为返回空串——否则用户会在不知情下覆盖真实数据。

密钥体系分三层（KEK 存系统安全区 / DEK 由 KEK 派生 / 备份密钥由用户口令派生不存储），其中"登录密码不参与数据加密"是最重要的决策：忘记密码可本地重置而不丢数据，备份包可脱离本机恢复；代价是设备已解锁时安全强度依赖二次验证，SRS S-05 要求界面明示这一点，设计规定了 P9/P10 两处固定文案。

同一份数据在不同身份下的可见性由上图矩阵统一规定，三条规则值得单独说明：锁态下可读名称与状态、不可读备注与金额（这是"名称存明文、备注存密文"分级设计的直接支撑）；凭据口令只能单条读取、不能批量（批量接口等于给了一次性导出全部口令的通道）；访问日志本身在锁态下可读（用户需要确认"有没有人在我不知情时看过我的凭据"）。

防泄漏的最后一道防线在"不经意"的输出通道：列表与搜索结果一律经掩码投影（金额显示 ¥••••••、账号按 138****0000 掩码）；通知文案只含记录名称与剩余天数；受保护页面设置 FLAG_SECURE 禁截图、切后台整屏模糊；剪贴板复制后 30 秒自动清空；日志与异常只携带字段名与错误码、绝不携带字段值。

设计思路：安全设计有一条贯穿始终的原则——"不静默降级"。设备安全区不可用时，系统绝不悄悄改用明文存储，必须提示用户开启设备锁，并提供一条需用户显式确认的"暂不加密"路径。安全上唯一允许的妥协方式，是让用户知道自己在妥协。

2.3 权限设计

本系统是单机单用户（可多账号）应用，刻意不引入 RBAC——没有服务端、没有管理员角色，生搬角色-权限模型只会增加攻击面。权限设计的重心放在两处：

两级访问控制（对比见系统设计说明书 5.5 节）：

维度	应用登录锁	二次验证
触发时机	启动应用、后台返回超过宽限期	打开受保护记录详情、受保护附件
验证方式	登录口令（主）	生物识别（首选）、登录口令（回退）
有效期	保持登录期间长期有效	默认 2 分钟，可配 0～10 分钟
失效时机	改密、重置、切换账号	超时、点"隐藏"、切后台、切换账号

验证会话（UnlockSession）的三个设计要点：会话与记录绑定而非全局永久解锁；四种失效路径收敛到同一个 invalidate() 方法，确保没有任何路径遗漏重置；失败计数在应用侧维护（各厂商生物识别失败回调不一致），连续 5 次失败锁定 5 分钟，锁定状态内存与 preference 双写——应用被强杀重启后锁定仍然有效，否则用户可以通过杀进程绕过锁定。

二次验证的流程分支也曾交给 LLM 做覆盖性检查：把八种分支场景（生物识别可用且通过 / 不可用回退密码 / 失败 5 次锁定 / 有效期内不重复验证 / 点击隐藏 / 切后台掩码 / 切换账号清空状态 / 搜索与待办不出明文）交给模型核对覆盖情况，结果如下表——模型仅部分覆盖，缺失项由人工补全后落到设计的具体位置：

人工增补的三项都对应了真实的安全要求：锁定不区分"账号不存在"与"密码错误"（S-18，防账号枚举）、切换账号清空全部验证状态与已展示明文（S-11，写入 UnlockSession.revokeAll）、受保护记录在搜索与待办中不出现明文（落到 Z2 掩码投影的四种场景）。这些增补最终全部体现在系统设计说明书的图 7-2 二次验证时序图中。

账号隔离四层约束（数据库设计说明书 7.6 节）：数据模型层所有业务表都有 user_id；外键策略层业务数据随账号级联删除、审计日志 SET NULL 保留；触发器层拦截跨账号的关联写入（trg_record_tag_owner 等三个触发器）；接口层所有仓储方法强制首参 userId、WHERE 条件统一拼接。另有一个易被忽视的细节：**越权访问统一返回"不存在"**，不区分"没有这条记录"与"不属于你"，避免通过返回差异探测他人数据的存在性。数据库侧还有"视图管列、DAO 管行"的分工——v_record_summary 等视图从列层面移除所有敏感列，行级过滤由数据访问层调用时追加。

设计思路：权限设计回答的问题是"谁能看到什么"。SQLite 没有用户与角色对象，所以答案不能依赖数据库内置能力，只能靠四层约束叠加：任何一层单独失效都不会直接导致泄露，但四层合起来，账号 A 的会话无法通过任何接口获得账号 B 的任何一个字段值。

---

三、改进分析

3.1 上次评审问题的回答与改进

（1）需求分析博客评论区问题

Q1：是否支持拍照自动识别关键字？

答：不支持，且本次设计明确其边界。自动识别对应 SRS 的 FR-22（OCR 自动识别），属 P2 迭代需求，不在首期 21 条需求范围内。本次设计为其保留了扩展点：附件模块接受 JPG/PNG/HEIC/PDF 四类文件、附件表以 MIME 类型与存储键建模，未来接入 OCR 只需在导入流程后增加识别步骤，不改变表结构；网关注入的架构也保证新增能力不影响现有模块。

Q2："未处理""处理中""已完成"是状态取值，不是变量。

答：接受指正，已在全文档统一表述。三态正式定义为 status 字段的枚举取值 PENDING / DOING / DONE，由库内 CHECK 约束强制合法取值；状态迁移由领域层 StatusMachine（纯函数）表达，九种迁移（含非法迁移）可穷举测试；每次实际变化由触发器校验后写入 status_log 留痕。系统设计说明书 1.5 节还专门澄清了另一组易混概念：类别（Category，物品/财务/证件/账号凭据）与敏感级别（Sensitivity，明文可见/受保护）是两个正交维度，代码中统一使用 category 与 sensitivity 两个不同字段名，不得混用。

（2）针对上次作业的改进部分与改进过程

改进过程有完整的版本记录可查（两份文档的修订记录）：

改进项	需求分析阶段的问题	本次设计的改进	过程
技术形态	选题阶段设想 Web 端（Vue+Spring Boot+MySQL），SRS 附录 B 登记"原生/跨端待定"	确定为单设备移动应用（Android 原生 + SQLite），架构分层、存储、部署全章按新形态重写	系统设计 V0.1 定框架 → V0.3 补模块接口流程 → V1.0 统稿
用例图占位	SRS 5.4 节记载"系统用例图依赖技术边界，占位待补"	技术方案确定后，功能模块分解图（图 3-1）完整承载了用例到模块的归属	系统设计 3.1 节
敏感级别口径	SRS 附录 B-7：原型默认级别严于文档，约定按"就严"执行	落实为数据：证件类、账号凭据类默认 PROTECTED 写入 trg_user_bootstrap 触发器，"安全默认"不再靠界面提示而是靠数据本身	数据库设计 5.2.4、10.1
找回方式冲突	原型展示短信验证码重置，与首期"无网络权限"冲突	FR-04 本地重置（本地验证项 + 一次性恢复码）进入表结构；短信找回明确 FR-27 不做	系统设计 1.2 边界清单
数据库文档质量	—	数据库设计 V1.0 → V2.0 六项结构性重写：ER 图归位概念章、新增接口设计章、附录贴入 517 行可执行脚本、17 项验收实测输出	数据库设计 0.3 节变更说明

3.2 驱动 LLM 协助完成设计的 3 个示例

本次设计在两个文档的产出过程中，全程以 LLM 作为"生成候选方案 + 提供检查视角"的助手：涉及业务边界的选择与最终是否采用，均由小组结合需求文档与实测结果确定。以下三个示例覆盖系统设计与数据库设计两侧，均附原始截图。

示例一：LLM 辅助功能模块层次划分（系统设计侧）

系统设计 3.1 节的模块划分需要把 21 条功能需求组织为九个模块 A～I，且必须同时满足三条硬约束：单设备本地运行不申请网络权限、敏感字段加密与二次验证集中实现、模块之间禁止双向依赖。我们把这项任务连同约束一起交给 LLM，提示词按"角色设定—输入材料—任务要求—约束条件—输出格式"五要素组织：

LLM 给出了 2～3 套候选划分方案，并指出了跨模块协作清单。人工复核与采纳：其中"把状态跟踪独立为一个模块"的思路被采纳——推演 FR-15 时发现状态变更要写日志、触发待办重算、联动关闭提醒，职责已超出记录管理的 CRUD 范畴，最终定为 F 模块。LLM 指出的"提醒依赖记录、状态又联动提醒"的环形协作问题，由小组决定用领域事件（StatusChanged）解决，保持依赖方向单向。

示例二：LLM 辅助数据库概念设计——实体识别与联系校验（数据库设计侧）

数据库概念层需要从 21 条 FR 中提取实体、确定联系基数，并回答一个关键问题：日期周期配置与每次提醒的执行状态是否适合放在同一张表中。我们把这个"合并 vs 拆分"的两难问题连同全部需求要点一起交给 LLM：

LLM 按"独立生命周期 + 主要属性"给出了候选实体清单，并对提醒拆表给出了倾向性分析。随后我们把模型给出的联系基数逐条对照需求条文做人工校验，形成下表：

人工复核与采纳：凭据信息只是记录的一种扩展 → 采纳，合并为 record 与 credential 两张表、主键共用 record_id（FR-08 规定仅账号凭据类有此字段）；记录与标签 M:N → 采纳，增设 record_tag 关联表；节点与任务 1:N → 采纳，并在 reminder_task 上对 node_id 建唯一索引；节点日期允许为过去、仅提示不拦截 → 人工补充；附件正文不入库、只存 file_path → 采纳。最终确定 15 个实体与 15 条联系，搜索条件、密钥、统计报表等概念被明确排除在实体之外。

示例三：LLM 辅助关系模式审查——规范化、约束与删除策略（数据库设计侧）

关系模式初步完成后，我们把 15 个关系模式整体交给 LLM，要求从规范化、完整性约束和删除策略三个方面审查，并点名要求回答 reminder_task.user_id 冗余取舍、明密文列设计、数量上限约束的实现方式、CASCADE / RESTRICT / SET NULL 的逐项选择等问题（同一对话两张截图）：

LLM 的审查结论：多数关系在补齐候选键后可达到 BCNF，主要风险不在拆表，而在候选键缺失、派生字段冗余、跨表归属无法约束；reminder_task.user_id 经节点与记录可间接得到，保留该列会使任务表不满足 BCNF。

人工复核与采纳：我们没有简单删除该列——提醒扫描是最高频查询，冗余后单表可扫、避免三层 join，最终保留为有意的反范式设计，并把 LLM"禁止独立修改"的建议落实为 trg_reminder_owner 触发器保证属主一致；LLM 建议的候选键逐条采纳（account_id 唯一、tag 按用户+归一化名联合唯一、storage_key 唯一、credential.record_id 唯一、reminder_task 按节点+到期日联合唯一）；删除策略也在这轮审查中逐项定下——access_log 只断开记录引用（SET NULL）而非随记录删除、file_cleanup_queue 的 user_id 允许为空以保证账号删除后孤儿文件仍可清理。此后的第三轮使用（建表脚本与测试核对，成果为 verify_db.py 的 17 项验收全部通过）也延续了同一模式：LLM 列出异常场景，小组补充测试数据、编写断言并实际执行。

小结：三次使用中 LLM 的角色始终是"生成候选 + 挑错"——模块怎么分、表怎么拆、冗余留不留，最终决定权都在小组。它压缩的是整理与检查的时间，设计判断无法外包。

---

四、团队绩效

4.1 工作流程

本次作业从 10 月 16 日发布，10 月 23 日（周五）下午课堂答辩，交付物包括两份说明书、答辩 PPT、评审表和本博客。流程沿用上次验证过的机制并针对"两份文档"的特点做了调整：

1. 分工认领：系统设计说明书按章节认领（架构/模块/安全/接口各一章），数据库设计说明书由负责人单独维护，任务在群里公示。
2. 版本化迭代：系统设计 V0.1 → V0.2 → V0.3 → V1.0 四轮；数据库设计 V1.0 → V2.0 两轮。每轮修订记录写明修订人与修订说明，评审意见闭环。
3. 每日同步与检查点：每晚群里报进度；10-19、10-20、10-21 三个检查点对照里程碑验收。
4. 讲述人审查：答辩讲述人提前通读两份说明书与 PPT，问题反馈到群，相关同学修改。
5. 上传验证：PDF 上传华为云后用无痕窗口逐一验证链接。

协作记录截图：

第一张截图记录了两条协作主线：陈瀚楷发布"五组掌中生活评审表（系统设计和数据库设计）"腾讯在线文档（所有人可编辑），全组实时填写；组长逐人核对交付物状态——"上次作业的说明书缺少的图片加进去，修改图片之后有重新上传到华为云仓库吗"，并安排"系统设计说明书封面改一下，然后 pdf 版本也上传到华为云仓库下"，保证仓库里的文档与本地最新版一致。

第二张截图是讲述人审查机制的实证：讲述人通读答辩 PPT 后逐条反馈问题——"第 13-15 页实际展示了类和用况，没有看到数据流、泳道的改进结果，既是内容缺项，也会让目录和正文对不上"；"第 18 页写了工作流程和成员负责事项，但没有贡献比例，作业要求明确提到组员分工和贡献度比例"。问题反馈到群后，相关同学补齐 PPT 内容并重新上传，最终版本即交付物链接中的答辩 PPT。

4.2 组员分工

成员	本次分工
黄炫文（组长）	任务分工与调配；系统设计说明书统稿（V1.0 定稿）；作业博客撰写与上传
陈志	数据库设计说明书 V1.0 首次成稿（逻辑模型、物理表结构、约束、索引、事务与备份设计）
吴军峰	数据库设计说明书 V2.0 重构（概念章 ER 图、接口设计章、附录脚本与验收输出、图表重绘）；系统设计框架搭建（V0.1）
胡昊	系统设计说明书架构、数据与安全三章（V0.2）
杨俊鑫	课堂答辩讲述；审查协调（通读两份文档与 PPT，反馈问题推动修改）
李天赐	系统安全设计章节协助；答辩 PPT 制作
陈瀚楷	系统设计和数据库设计评审表；设计评审记录整理

4.3 组员贡献度

贡献度按实际投入工时估算，经全员复核确认：黄炫文作为组长承担任务调配、系统设计统稿与博客撰写上传，贯穿全程，略上浮至 16%；吴军峰完成数据库说明书 V2.0 重构并搭建系统设计框架，投入较重，计 15%；杨俊鑫承担课堂答辩讲述与文档 PPT 通读审查，计 15%；陈志完成数据库 V1.0 首稿、胡昊撰写系统设计架构数据安全三章，各计 14%；李天赐协助安全章节并制作答辩 PPT，陈瀚楷负责评审表填写与评审记录整理，计 13%。整体差距控制在 3 个百分点以内，体现"尽量均摊、按实际工时微调"的原则，七人合计 100%。

学号	工作内容	贡献度
102400415	组长：任务分工与调配、系统设计统稿、作业博客与上传	16%
102400411	数据库设计说明书 V1.0	14%
102400427	数据库设计说明书 V2.0 重构、系统设计框架	15%
102400414	系统设计说明书架构、数据与安全章节	14%
102400331	答辩讲述与审查协调	15%
102400418	安全章节协助、答辩 PPT	13%
102400410	评审表与设计评审记录	13%

---

五、开发计划安排

5.1 预期开发计划时间安排

课程共 10 次大作业、每周一节，每周五下午课堂汇报。本次（第 5 次 / 团队第 3 次）答辩后，开发计划按课程日历与后续作业节点对齐：Alpha 冲刺（作业6）与 Beta 冲刺（作业10）构成两轮冲刺，完整覆盖作业要求"至少攘括 11 月中下旬冲刺阶段"的时段。

时间	课程节点	开发阶段	主要工作	里程碑 / 产出
10-20 ~ 10-23	作业5：系统设计与数据库设计答辩（10.23 周五下午）	设计定稿	设计文档定稿、评审表、答辩演练	M6：设计文档 v1.0 + 答辩材料
10-23 ~ 10-29	作业6：站立式会议 + Alpha 冲刺（一）	工程搭建与核心记录	每日站会；Android 工程初始化（Gradle/CI）、执行 517 行建表脚本、Room 接入；A 账号模块；B/C/F/G 记录闭环	M7：可运行骨架 + 注册登录 + 记录闭环（录入→查看→处理）
11-03 ~ 11-05	作业7：LLM 结合探索	Alpha 冲刺（二）+ LLM 实践	站会持续；D 附件、H 提醒（AttachmentStore、NotificationScheduler）；用 LLM 辅助开发（代码生成、测试用例、缺陷分析）并形成实践记录	M8：提醒可用 + 附件闭环 + LLM 实践记录
11-06 ~ 11-11	作业8：CodeArts 团队实战总结	冲刺收尾	加密集成（KeyVault/CryptoBox/AAD）、二次验证、I 检索、待办视图；CodeArts 分支 / Issue / 提交规范总结	M9：全功能联调版本
11-12 ~ 11-26	作业9：软件评测（两周）	测试与评测	缺陷修复、DBAC 17 项 + 接口级验收回归、兼容性适配（Android 8 真机）；对他组软件进行评测，收集本组软件的评测意见并整改	M10：测试报告 + 评测整改闭环
11-27 ~ 12-04	作业10：Beta 冲刺 + 事后诸葛亮	Beta 冲刺	E 备份恢复、APK 打包签名、演示脚本与演练；冲刺复盘（事后诸葛亮）	M11：可安装版本 + 复盘记录
12月（期末）	个人技术总结 + 项目总结	收尾	文档归档、个人技术总结、项目总结	M12：全部学期交付物

5.2 预期开发计划分工安排

成员	角色	负责的详细开发部分	主要活跃阶段
黄炫文	组长 / PM	进度管理、站会主持、接口联调协调、演示与博客文档统筹	全程
胡昊	数据访问层	Room 与六个仓储实现、record/credential/tag 业务表开发、建表脚本维护	M7~M9
陈志	数据库与提醒	数据库验收脚本（verify_db.py）、提醒任务生成与状态推进逻辑	M7~M8
杨俊鑫	前端 A	注册登录（P1/P9）、记录编辑与详情（P4/P5）、附件上传预览（P6）	M7~M9
吴军峰	前端 B	首页待办（P2）、记录列表（P3）、搜索筛选（P8）、设置（P10）与 UI 规范	M8~M9
李天赐	安全	KeyVault/CryptoBox 加密实现、密文信封与 AAD、UnlockSession 二次验证	M9~M10
陈瀚楷	测试	单元测试与接口级验收（IF 系列）、缺陷跟踪、测试报告、软件评测配合	M10~M11

---

六、总结

本次作业完成了掌中生活 LifeMap 的系统设计与数据库设计：系统侧以"四层 + 网关"架构承载 9 模块 + Z 公共组件，加密边界与明文出口各收敛到唯一位置；数据库侧以概念 → 逻辑 → 物理三层递进，15 张表、119 字段、14 触发器，安全不变量全部可由 SQL 验证，17 项验收用例实测通过。设计与需求之间以 FR 编号全程追踪（系统设计说明书表 10-1、数据库设计说明书附录 B），下一步按第五节计划进入编码阶段。

---

参考文献

国家标准与规范

• GB/T 8567-2006《计算机软件文档编制规范》
• GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》
• GB/T 35273-2020《信息安全技术 个人信息安全规范》

技术文档与书籍

• SQLite 官方文档 3.45 版（PRAGMA 语义、触发器行为、WAL 模式）
• 《构建之法——现代软件工程》（邹欣）

作业帖参考教程

• UML 之类图
• UML 类图详解
• 详解设计模式六大原则
• 数据库表结构设计的几条准则
• 数据库表设计（一对多、多对多）
• 常见 web 攻击方法及防御手段总结
• 用户密码加密
• JavaWeb 项目前后端分离
• RBAC 用户、角色、权限、组设计方案