diff --git a/example/2026届网络工程毕业设计论文撰写规范-(应用开发类).md b/example/2026届网络工程毕业设计论文撰写规范-(应用开发类).md
new file mode 100644
index 0000000..24b37cd
--- /dev/null
+++ b/example/2026届网络工程毕业设计论文撰写规范-(应用开发类).md
@@ -0,0 +1,307 @@
+# 2026届网络工程毕业设计
+
+# 论文撰写规范(应用开发类)
+
+中文摘要 (3-5 个关键词)
+
+# 英文摘要
+
+# 目录
+
+# 第1章绪论
+
+1.1 课题来源及意义
+
+1.2 课题研究现状
+
+1.3当前存在的问题
+
+1.4 课题研究目标
+
+# 第2章主要技术和框架
+
+2.1 主要技术 (开发系统或平台所需相关技术的介绍)
+
+# 2.2 框架和开发模式(开发系统或平台所使用的框架和开发模式的介绍)
+
+# 第3章XXXXX的系统分析
+
+# 3.1需求分析(包括功能需求分析和性能需求分析)
+
+3.2可行性分析(包括技术可行性、操作可行性、经济可行性,社会可行性等)
+
+3.3 用例图(根据系统角色划分用例图,若有两个角色就有两个用例图)
+
+3.3.1 用户用例图(需先对用例图进行描述,其实也就是对该系统的用户角色进行权限分析,再画出具体用户用例图,用例图如下所示)
+
+
+
+
+
+图3.1用户用例图
+
+
+3.3.2 管理员用例图(需先对用例图进行描述,其实也就是对该系统的用户角色进行权限分析,再画出具体用户用例图,用例图如下所示)
+
+
+
+
+
+图3.2管理员用例图
+
+
+3.4 用例描述(用例描述是对用例图中用例的详细说明,它详细阐述了用例的功
+
+能实现过程、输入输出、前置条件、后置条件以及可能的异常情况等,是对用例图
+
+的补充和细化,使系统功能更加清晰具体。需分别对每个用例列举3个左右的用
+
+例描述。)
+
+例:(1)用户管理地址用例描述如下表3.1所示。
+
+
+表 3.1 用户管理地址用例描述
+
+
+
| 用例名称:管理地址 |
| 执行者:用户 |
| 简要说明:用户对收货地址进行添加、修改、删除等管理操作 |
| 基本事件流:
+1.用户登录平台,进入地址管理界面
+2.系统显示已有地址列表
+3.用户选择添加新地址,输入详细地址信息,验证通过后存储地址
+4.若修改地址,系统更新后提示成功,若删除地址,确认操作后数据库移除该地址记录 |
| (2)用户查看商品用例描述如下表3.2所示。
+表3.2用户查看商品用例 |
| 用例名称:查看商品 |
| 执行者:用户 |
| 简要说明:用户分类浏览平台上的闲置商品 |
| 基本事件流:
+1.用户登录平台,进入查看商品界面
+2.选择商品分类,如闲置书籍、衣服、手机等;
+3.系统加载并显示该分类下的商品列表
+4.用户可点击具体商品,查看详细信息,如介绍、图片、价格等 |
+
+# 3.5 系统性能分析
+
+# 第4章XXXXX的系统设计
+
+4.1系统功能设计(先总体概述一段该系统的主要角色有哪几个,分别包含什么主
+
+要功能,再给出功能结构图。)
+
+具体如图4.1和图4.2所示。
+
+
+
+
+
+图4.1用户功能结构图
+
+
+
+
+
+
+图4.2管理员功能结构图
+
+
+4.2 类图(根据给定的初步类图,详细描述每个类的属性、方法以及类之间的具体关系。)
+
+
+
+
+
+图4.3系统类图
+
+
+4.3 序列图(展示了对象之间随时间顺序发生的消息传递,通常用于描述用例的实现过程或系统中某个功能的动态行为。至少需列举系统角色各一个序列图,在给出序列图之前还需将过程的详细步骤写出。如:用户登录序列图、管理员删除账号序列图。)
+
+
+
+
+
+图4.4用户购买商品功能序列图
+
+
+4.4 活动图(活动图可以清晰地描述系统的动态行为和工作流程。例如,在描述一个在线购物系统的订单处理流程时,可以通过活动图展示从用户下单到订单完成的各个步骤。论文中至少需描述各个角色各一个活动的活动图,如用户更新个人信息活动图,管理员删除用户信息活动图。)
+
+# 4.4.1 用户填写个人信息活动图
+
+用户填写个人信息过程可分为以下几步:
+
+(1) 用户输入验证账号密码。
+
+(2) 数据库查询用户数据,并判断用户是否存在。
+
+(3) 登录成功后,用户填写个人信息并提交。
+
+(4) 系统接收提交的个人信息后,将其发送至数据库进行更新保存。
+
+(5) 用户确认信息更新无误后,更新界面。
+
+用户填写个人信息活动图如下图4.7所示。
+
+
+
+
+
+图4.7 用户填写个人信息活动图
+
+
+# 4.5 数据库设计
+
+撰写说明:
+
+本章是重点章节,很多同学搞不清概念设计、逻辑设计和物理设计的关系,请参见另外一个文档《2026届网络工程毕业论文第4章-数据库设计撰写规范(应用开发类补充说明).docx》:
+
+4.5.1 概念设计(概念设计包括两部分:实体属性图(不少于8个实体,每个实体
+
+标明属性图的主码)和总体E-R图)
+
+# (1) 管理员实体
+
+管理员实体属性图如图4.9所示。
+
+
+
+
+
+图4.9管理员实体属性图
+
+
+# (2)用户实体
+
+用户实体属性图如图4.10所示。
+
+
+
+
+
+图4.10用户实体属性图
+
+
+
+
+
+
+图4.系统E-R图(标明各个实体之间的关联)
+
+
+4.5.2 逻辑设计(将E-R图中的实体关系转换为逻辑结构设计,即关系模式。
+
+其中,一个实体转换为 1 个单独的关系模式。
+
+实体间联系有3种,1:1,1:n,n:m。
+
+1:n 联系要将 1 端实体如用户的主码加入到 n 端如评论实体的关系模式中。
+
+n:m 联系要将联系如上图中的购买转换成一个单独的关系模式,并将两端的主
+
+码放入该关系模式作为属性。)关系模式中需标明主外码
+
+上图转换为逻辑结构如下所示:
+
+(1) 用户表:(用户 id, 用户账号, 密码, 用户姓名, 性别, 联系电话, 头像, 积分,余额)
+
+(2) 管理员表: (管理员 id, 创建时间, 管理员名称, 密码, 管理员类型)
+
+(3) 收货地址表:(收货地址id,用户id,地址,收货人,电话,是否为默认地址)
+
+(4) 购物车表:(购物车id,商品表名,商品,商品名称,图片,购买数量,单价,会员价,商品类型)
+
+(5) 订单表:(订单id,订单编号,用户id,规格,上架时间,商品详情,团购价,拼团人数)
+
+(6) 团购商品表:(团购商品id,购买数量,价格,折扣价,总价,商品类型id,支付类型,物流,购物车id)
+
+(7) 商品类型表:(商品类型 id,创建时间,类型数量)
+
+(8) 评论表:(评论id,用户id,头像,用户名,评论内容,回复内容)
+
+(9) 公告表:(公告id,创建时间,标题,简介,图片,内容,管理员id)
+
+(10) 购买表:(用户 id,团购商品 id,购买日期,购买时间)(购买表的外键为:
+
+用户id,团购商品id)
+
+4.5.3 物理设计(将上述关系模式转换为一个个物理表结构,一个关系模式转换为一个物理表,至少包含8张物理表)
+
+如:(1)系统根据MySQL数据库数据存储的特性设计数据库关系表:
+
+
+表 4.1 管理员表 (admin 表)
+
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
| admin_id | 管理员 id | int | 10 | 主键 |
| admin_name | 管理员姓名 | varchar | 10 | 非空 |
| admin_password | 管理员密码 | varchar | 20 | 非空 |
| admin_email | 管理员邮箱 | varchar | 20 | 非空 |
| admin_phone | 管理员手机号 | varchar | 11 | 非空 |
+
+
+表 4.2 用户表 (user 表)
+
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
| user_id | 用户id | int | 10 | 主键 |
| user_name | 用户昵称 | varchar | 10 | 非空 |
| user_password | 用户密码 | varchar | 20 | 非空 |
| user/mobile | 用户电话 | varchar | 11 | 非空 |
| user_realname | 用户真实姓名 | varchar | 10 | 非空 |
| user_score | 信誉分 | int | 4 | 非空 |
+
+
+表4.3商品表 (product表)
+
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
| product_id | 商品id | int | 10 | 主键 |
| product_name | 商品名称 | varchar | 10 | 非空 |
| product_title | 商品概要 | varchar | 50 | 非空 |
| product_intro | 商品详情 | varchar | 100 | 非空 |
+
+4.6图形界面设计(实现某一个具体功能的界面设计,至少系统中各角色各列举1
+
+# 个功能界面设计)
+
+如:删除购物车界面设计
+
+
+
+
+
+图4. 删除购物车界面设计图
+
+
+# 第5章XXXXX的系统实现
+
+只写出主要功能的实现结果即可,并给出运行截图(不写用户注册、登录),
+
+运行截图中需输入数据的地方要有数据输入,且输入的数据必须真实,不可输入
+
+类似 1111 类数据。可按系统角色进行实现,再进行角色详细功能实现。如:
+
+# 5.1 用户功能模块
+
+# 5.1.1 购物车
+
+# 5.1.2 我的订单
+
+··
+
+# 5.2 管理员功能模块
+
+# 5.2.1 账号管理
+
+# 5.2.2 订单管理
+
+··
+
+# 第6章XXXXX的系统测试
+
+# 6.1 系统测试概述
+
+6.1.1 测试的背景
+
+6.1.2 测试的意义
+
+6.1.3 测试的环境
+
+# 6.2 系统测试用例设计
+
+6.2.1XXXX功能测试
+
+6.2.2XXXX功能测试
+
+6.2.3XXXX功能测试
+
+6.2.4 安全性测试
+
+6.2.5 兼容性测试
+
+# 第7章结论
+
+参考文献
+
+致谢
+
+附录
\ No newline at end of file
diff --git a/example/2106090117-佟欣鑫-论文.docx b/example/2106090117-佟欣鑫-论文.docx
new file mode 100644
index 0000000..ee80d8c
Binary files /dev/null and b/example/2106090117-佟欣鑫-论文.docx differ
diff --git a/example/__pycache__/format_thesis_docx.cpython-314.pyc b/example/__pycache__/format_thesis_docx.cpython-314.pyc
new file mode 100644
index 0000000..77e587b
Binary files /dev/null and b/example/__pycache__/format_thesis_docx.cpython-314.pyc differ
diff --git a/example/format_thesis_docx.py b/example/format_thesis_docx.py
new file mode 100644
index 0000000..66caf4d
--- /dev/null
+++ b/example/format_thesis_docx.py
@@ -0,0 +1,341 @@
+from docx import Document
+from docx.enum.text import WD_ALIGN_PARAGRAPH, WD_BREAK
+from docx.oxml import OxmlElement
+from docx.oxml.ns import qn
+from docx.shared import Cm, Pt, RGBColor
+import re
+
+SRC = r"/Users/apple/code/bs/mying/example/萌贝母婴商城毕业论文初稿-2026版.docx"
+DST = r"/Users/apple/code/bs/mying/example/萌贝母婴商城毕业论文初稿-2026版-排版.docx"
+
+
+def set_style_font(
+ style,
+ east_asia_font: str,
+ size_pt: float,
+ bold: bool | None = None,
+ west_font: str = "Times New Roman",
+):
+ font = style.font
+ font.name = west_font
+ font.size = Pt(size_pt)
+ if bold is not None:
+ font.bold = bold
+ font.color.rgb = RGBColor(0, 0, 0)
+ rfonts = style.element.get_or_add_rPr().get_or_add_rFonts()
+ rfonts.set(qn("w:ascii"), west_font)
+ rfonts.set(qn("w:hAnsi"), west_font)
+ rfonts.set(qn("w:eastAsia"), east_asia_font)
+
+
+def set_runs_font(
+ paragraph,
+ east_asia_font: str,
+ size_pt: float,
+ bold: bool | None = None,
+ west_font: str = "Times New Roman",
+):
+ for run in paragraph.runs:
+ run.font.name = west_font
+ run.font.size = Pt(size_pt)
+ if bold is not None:
+ run.font.bold = bold
+ run.font.color.rgb = RGBColor(0, 0, 0)
+ rpr = run._element.get_or_add_rPr()
+ rfonts = rpr.get_or_add_rFonts()
+ rfonts.set(qn("w:ascii"), west_font)
+ rfonts.set(qn("w:hAnsi"), west_font)
+ rfonts.set(qn("w:eastAsia"), east_asia_font)
+
+
+def set_runs_common(paragraph, italic: bool | None = None, color_black: bool = True):
+ for run in paragraph.runs:
+ if italic is not None:
+ run.font.italic = italic
+ if color_black:
+ run.font.color.rgb = RGBColor(0, 0, 0)
+
+
+def is_numbered_paragraph(paragraph) -> bool:
+ ppr = paragraph._p.pPr
+ if ppr is None:
+ return False
+ return ppr.numPr is not None
+
+
+def iter_table_paragraphs(table):
+ for row in table.rows:
+ for cell in row.cells:
+ for p in cell.paragraphs:
+ yield p
+ for t in cell.tables:
+ yield from iter_table_paragraphs(t)
+
+
+def format_table_paragraph(p, bold: bool = False):
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ fmt = p.paragraph_format
+ fmt.line_spacing = 1.0
+ fmt.space_before = Pt(0)
+ fmt.space_after = Pt(0)
+ fmt.first_line_indent = Pt(0)
+ set_runs_font(p, "宋体", 10.5, bold=bold)
+ set_runs_common(p, italic=False, color_black=True)
+
+
+def set_table_style_like_template(table):
+ tbl = table._tbl
+ tbl_pr = tbl.tblPr
+ if tbl_pr is None:
+ tbl_pr = OxmlElement("w:tblPr")
+ tbl.insert(0, tbl_pr)
+
+ tbl_style = tbl_pr.find(qn("w:tblStyle"))
+ if tbl_style is None:
+ tbl_style = OxmlElement("w:tblStyle")
+ tbl_pr.append(tbl_style)
+ tbl_style.set(qn("w:val"), "Table Grid")
+
+ tbl_w = tbl_pr.find(qn("w:tblW"))
+ if tbl_w is None:
+ tbl_w = OxmlElement("w:tblW")
+ tbl_pr.append(tbl_w)
+ tbl_w.set(qn("w:type"), "pct")
+ tbl_w.set(qn("w:w"), "4997")
+
+ tbl_jc = tbl_pr.find(qn("w:jc"))
+ if tbl_jc is None:
+ tbl_jc = OxmlElement("w:jc")
+ tbl_pr.append(tbl_jc)
+ tbl_jc.set(qn("w:val"), "center")
+
+ tbl_cell_mar = tbl_pr.find(qn("w:tblCellMar"))
+ if tbl_cell_mar is None:
+ tbl_cell_mar = OxmlElement("w:tblCellMar")
+ tbl_pr.append(tbl_cell_mar)
+ for edge, width in (("top", "120"), ("bottom", "120"), ("left", "140"), ("right", "140")):
+ elem = tbl_cell_mar.find(qn(f"w:{edge}"))
+ if elem is None:
+ elem = OxmlElement(f"w:{edge}")
+ tbl_cell_mar.append(elem)
+ elem.set(qn("w:w"), width)
+ elem.set(qn("w:type"), "dxa")
+
+ tbl_borders = tbl_pr.find(qn("w:tblBorders"))
+ if tbl_borders is None:
+ tbl_borders = OxmlElement("w:tblBorders")
+ tbl_pr.append(tbl_borders)
+ for edge in ("top", "left", "bottom", "right", "insideH", "insideV"):
+ elem = tbl_borders.find(qn(f"w:{edge}"))
+ if elem is None:
+ elem = OxmlElement(f"w:{edge}")
+ tbl_borders.append(elem)
+ elem.set(qn("w:val"), "single")
+ elem.set(qn("w:sz"), "4")
+ elem.set(qn("w:color"), "auto")
+ elem.set(qn("w:space"), "0")
+
+ for row in table.rows:
+ tr_pr = row._tr.get_or_add_trPr()
+ tr_height = tr_pr.find(qn("w:trHeight"))
+ if tr_height is None:
+ tr_height = OxmlElement("w:trHeight")
+ tr_pr.append(tr_height)
+ tr_height.set(qn("w:val"), "620")
+ tr_height.set(qn("w:hRule"), "atLeast")
+
+ for cell in row.cells:
+ tc_pr = cell._tc.get_or_add_tcPr()
+ v_align = tc_pr.find(qn("w:vAlign"))
+ if v_align is None:
+ v_align = OxmlElement("w:vAlign")
+ tc_pr.append(v_align)
+ v_align.set(qn("w:val"), "center")
+
+ tc_borders = tc_pr.find(qn("w:tcBorders"))
+ if tc_borders is None:
+ tc_borders = OxmlElement("w:tcBorders")
+ tc_pr.append(tc_borders)
+ for edge in ("top", "left", "bottom", "right"):
+ elem = tc_borders.find(qn(f"w:{edge}"))
+ if elem is None:
+ elem = OxmlElement(f"w:{edge}")
+ tc_borders.append(elem)
+ elem.set(qn("w:val"), "single")
+ elem.set(qn("w:sz"), "4")
+ elem.set(qn("w:color"), "auto")
+ elem.set(qn("w:space"), "0")
+
+
+def set_table_header_gray(table):
+ if not table.rows:
+ return
+ for cell in table.rows[0].cells:
+ tc_pr = cell._tc.get_or_add_tcPr()
+ shd = tc_pr.find(qn("w:shd"))
+ if shd is None:
+ shd = OxmlElement("w:shd")
+ tc_pr.append(shd)
+ shd.set(qn("w:val"), "clear")
+ shd.set(qn("w:color"), "auto")
+ shd.set(qn("w:fill"), "D9D9D9")
+
+
+def cleanup_paragraph_spaces(paragraph):
+ runs = paragraph.runs
+ if not runs:
+ return
+ for run in runs:
+ if run.text:
+ run.text = re.sub(r"[ \t]{2,}", " ", run.text)
+ runs[0].text = runs[0].text.lstrip(" \t\u3000")
+ runs[-1].text = runs[-1].text.rstrip(" \t\u3000")
+
+
+def remove_redundant_blank_paragraphs(doc):
+ prev_blank = False
+ for p in list(doc.paragraphs):
+ text = p.text.replace("\u3000", " ").strip()
+ is_blank = text == ""
+ if is_blank and prev_blank:
+ p._element.getparent().remove(p._element)
+ continue
+ prev_blank = is_blank
+
+
+def add_page_break_between_chapters(doc):
+ chapter_pattern = re.compile(r"^第\s*\d+\s*章")
+ chapter_paragraphs = []
+ for p in list(doc.paragraphs):
+ text = p.text.replace("\u3000", " ").strip()
+ if not text or not chapter_pattern.match(text):
+ continue
+ chapter_paragraphs.append(p)
+
+ for index, p in enumerate(chapter_paragraphs):
+ if index == 0:
+ continue
+ prev = p._element.getprevious()
+ has_page_break = False
+ if prev is not None:
+ for br in prev.findall('.//w:br', {'w': 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'}):
+ if br.attrib.get('{http://schemas.openxmlformats.org/wordprocessingml/2006/main}type') == 'page':
+ has_page_break = True
+ break
+ if not has_page_break:
+ break_paragraph = p.insert_paragraph_before("")
+ break_paragraph.add_run().add_break(WD_BREAK.PAGE)
+
+
+def set_first_line_two_chars(paragraph, twips: int = 420, chars: int = 200):
+ ppr = paragraph._p.get_or_add_pPr()
+ ind = ppr.find(qn("w:ind"))
+ if ind is None:
+ ind = OxmlElement("w:ind")
+ ppr.append(ind)
+ ind.set(qn("w:firstLine"), str(twips))
+ ind.set(qn("w:firstLineChars"), str(chars))
+
+
+def apply_para_format(paragraph, line_spacing: float, first_line_pt: float | None = None, align=None):
+ fmt = paragraph.paragraph_format
+ fmt.line_spacing = line_spacing
+ fmt.space_before = Pt(0)
+ fmt.space_after = Pt(0)
+ if first_line_pt is not None:
+ fmt.first_line_indent = Pt(first_line_pt)
+ set_first_line_two_chars(paragraph)
+ if align is not None:
+ paragraph.alignment = align
+
+
+def format_paragraph(p):
+ style_name = p.style.name if p.style is not None else ""
+ if style_name == "Heading 1":
+ apply_para_format(p, 1.5, 0, WD_ALIGN_PARAGRAPH.CENTER)
+ set_runs_font(p, "黑体", 22, True)
+ elif style_name == "Heading 2":
+ apply_para_format(p, 1.5, 32)
+ set_runs_font(p, "黑体", 16, True)
+ elif style_name == "Heading 3":
+ apply_para_format(p, 1.5, 28)
+ set_runs_font(p, "黑体", 14, True)
+ elif style_name == "Heading 4":
+ apply_para_format(p, 1.5, 24)
+ set_runs_font(p, "黑体", 14, True)
+ set_runs_common(p, italic=False, color_black=True)
+ elif is_numbered_paragraph(p) or style_name.startswith("List Number"):
+ p.paragraph_format.line_spacing = 1.5
+ set_runs_font(p, "宋体", 12)
+ set_runs_common(p, color_black=True)
+ else:
+ apply_para_format(p, 1.5, 24)
+ set_runs_font(p, "宋体", 10.5)
+ set_runs_common(p, color_black=True)
+
+
+def set_page_layout(doc):
+ for section in doc.sections:
+ section.page_width = Cm(21.0)
+ section.page_height = Cm(29.7)
+ section.top_margin = Cm(2.5)
+ section.bottom_margin = Cm(2.5)
+ section.left_margin = Cm(2.5)
+ section.right_margin = Cm(2.5)
+ section.header_distance = Cm(1.5)
+ section.footer_distance = Cm(1.75)
+
+
+def main():
+ doc = Document(SRC)
+
+ normal = doc.styles["Normal"]
+ h1 = doc.styles["Heading 1"]
+ h2 = doc.styles["Heading 2"]
+ h3 = doc.styles["Heading 3"]
+ h4 = doc.styles["Heading 4"]
+
+ set_style_font(normal, "宋体", 10.5)
+ normal.paragraph_format.line_spacing = 1.5
+ normal.paragraph_format.first_line_indent = Pt(21)
+
+ set_style_font(h1, "黑体", 22, True)
+ h1.paragraph_format.line_spacing = 1.5
+ h1.paragraph_format.first_line_indent = Pt(0)
+
+ set_style_font(h2, "黑体", 16, True)
+ h2.paragraph_format.line_spacing = 1.5
+ h2.paragraph_format.first_line_indent = Pt(32)
+
+ set_style_font(h3, "黑体", 14, True)
+ h3.paragraph_format.line_spacing = 1.5
+ h3.paragraph_format.first_line_indent = Pt(28)
+
+ set_style_font(h4, "黑体", 14, True)
+ h4.font.italic = False
+ h4.paragraph_format.line_spacing = 1.5
+ h4.paragraph_format.first_line_indent = Pt(24)
+
+ set_page_layout(doc)
+
+ for p in doc.paragraphs:
+ format_paragraph(p)
+ cleanup_paragraph_spaces(p)
+
+ for t in doc.tables:
+ set_table_style_like_template(t)
+ set_table_header_gray(t)
+ for row_index, row in enumerate(t.rows):
+ for cell in row.cells:
+ for p in cell.paragraphs:
+ format_table_paragraph(p, bold=(row_index == 0))
+ cleanup_paragraph_spaces(p)
+
+ remove_redundant_blank_paragraphs(doc)
+ add_page_break_between_chapters(doc)
+ doc.save(DST)
+ print(DST)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/example/markdown_to_docx.py b/example/markdown_to_docx.py
new file mode 100644
index 0000000..94ea066
--- /dev/null
+++ b/example/markdown_to_docx.py
@@ -0,0 +1,97 @@
+from __future__ import annotations
+
+from pathlib import Path
+import re
+from docx import Document
+
+
+INPUT_MD = Path("/Users/apple/code/bs/mying/example/萌贝母婴商城毕业论文初稿-2026版.md")
+OUTPUT_DOCX = Path("/Users/apple/code/bs/mying/example/萌贝母婴商城毕业论文初稿-2026版.docx")
+
+
+def is_table_separator(line: str) -> bool:
+ stripped = line.strip()
+ if not stripped.startswith("|"):
+ return False
+ core = stripped.strip("|").replace(" ", "")
+ return bool(core) and all(ch in "-:|" for ch in core)
+
+
+def split_table_row(line: str) -> list[str]:
+ raw = line.strip().strip("|")
+ return [cell.strip() for cell in raw.split("|")]
+
+
+def convert_markdown_to_docx(md_text: str, doc: Document) -> None:
+ lines = md_text.splitlines()
+ i = 0
+
+ while i < len(lines):
+ line = lines[i]
+ stripped = line.strip()
+
+ if not stripped:
+ doc.add_paragraph("")
+ i += 1
+ continue
+
+ # Table block
+ if stripped.startswith("|") and i + 1 < len(lines) and is_table_separator(lines[i + 1]):
+ headers = split_table_row(lines[i])
+ i += 2
+ rows: list[list[str]] = []
+ while i < len(lines):
+ row_line = lines[i].strip()
+ if not row_line.startswith("|"):
+ break
+ rows.append(split_table_row(lines[i]))
+ i += 1
+
+ cols = max(1, len(headers))
+ table = doc.add_table(rows=1, cols=cols)
+ for c in range(cols):
+ table.cell(0, c).text = headers[c] if c < len(headers) else ""
+
+ for row in rows:
+ cells = table.add_row().cells
+ for c in range(cols):
+ cells[c].text = row[c] if c < len(row) else ""
+ continue
+
+ # Heading
+ heading_match = re.match(r"^(#{1,6})\s+(.*)$", stripped)
+ if heading_match:
+ level = min(4, len(heading_match.group(1)))
+ text = heading_match.group(2).strip()
+ doc.add_heading(text, level=level)
+ i += 1
+ continue
+
+ # Ordered list
+ if re.match(r"^\d+\.\s+", stripped):
+ text = re.sub(r"^\d+\.\s+", "", stripped)
+ doc.add_paragraph(text, style="List Number")
+ i += 1
+ continue
+
+ # Unordered list
+ if stripped.startswith("- "):
+ doc.add_paragraph(stripped[2:].strip(), style="List Bullet")
+ i += 1
+ continue
+
+ # Plain paragraph
+ doc.add_paragraph(stripped)
+ i += 1
+
+
+def main() -> None:
+ md_text = INPUT_MD.read_text(encoding="utf-8")
+ doc = Document()
+ convert_markdown_to_docx(md_text, doc)
+ doc.save(OUTPUT_DOCX)
+ print(OUTPUT_DOCX)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/thesis/chapter3.md b/thesis/chapter3.md
new file mode 100644
index 0000000..ec3a37b
--- /dev/null
+++ b/thesis/chapter3.md
@@ -0,0 +1,128 @@
+# 第3章 养老院管理系统的系统分析
+
+## 3.1 需求分析
+
+### 3.1.1 功能需求分析
+
+通过对养老院日常运营管理流程的深入调研和分析,本系统的功能需求可从管理员、护工和家属三个角色维度进行梳理。
+
+(1)管理员功能需求
+
+管理员是系统的核心管理角色,负责养老院的全面运营管理工作。管理员的功能需求包括:运营数据概览,能够实时查看在住长者数量、护工数量、家属数量和累计收入等关键运营指标;账号管理,能够创建、编辑护工和家属账号,重置用户密码,启用或禁用账号;长者档案管理,能够录入、修改和删除长者的基本信息,包括姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级等;排班管理,能够按日期和班次为护工安排工作任务,支持排班的创建、修改和删除;账单管理,能够按月为长者生成费用账单,包含床位费、护理费、餐饮费和其他费用,支持账单的编辑和删除;反馈处理,能够查看家属提交的服务反馈,并进行回复和状态更新;通知公告管理,能够发布面向不同角色的通知信息。
+
+(2)护工功能需求
+
+护工是养老院一线服务人员,负责长者的日常护理工作。护工的功能需求包括:查看个人排班信息,能够按日期查看自己的班次安排和工作任务;护理记录管理,能够在线记录每次护理服务的内容,支持上传图片等附件作为护理凭证;健康监测记录,能够录入长者的日常体征数据,包括体温、收缩压、舒张压、心率等指标,并添加备注说明;交班记录管理,能够在换班时记录当班期间的重要事项和注意事项,确保信息的有效传递;查看通知,能够接收管理员发布的工作通知和培训安排。
+
+(3)家属功能需求
+
+家属是养老院服务的间接受益者,关注老人在院的生活和健康状况。家属的功能需求包括:查看亲人档案,能够查看与自己关联的长者的基本信息;查看护理记录,能够远程了解老人每日的护理服务内容;查看健康记录,能够查看老人的体征监测数据,及时了解老人的健康状况;账单查看与支付,能够查看老人的月度费用账单明细,并通过在线方式完成支付;服务反馈,能够对养老院的服务提出意见、建议或投诉,并查看管理员的回复;查看通知,能够接收养老院发布的探视时间调整等通知信息。
+
+### 3.1.2 性能需求分析
+
+除功能需求外,本系统还需满足以下性能需求:
+
+(1)响应时间:系统页面的加载时间应控制在3秒以内,数据查询操作的响应时间应控制在2秒以内,确保用户获得流畅的使用体验。
+
+(2)并发处理能力:系统应能够支持至少50个用户同时在线操作,在高峰时段不出现明显的性能下降。
+
+(3)数据安全性:用户密码应采用加密存储,系统应实现基于角色的访问控制,防止未授权的数据访问。Token应设置合理的有效期,过期后需重新登录。
+
+(4)数据完整性:系统应确保数据的一致性和完整性,关键操作应进行数据验证,防止无效数据的录入。
+
+(5)可用性:系统应具有良好的容错能力,在出现异常情况时能够给出友好的错误提示,不影响系统的整体运行。
+
+## 3.2 可行性分析
+
+### 3.2.1 技术可行性
+
+本系统采用的技术栈均为当前主流的成熟技术。后端采用Spring Boot 3框架,该框架经过多年的发展和迭代,已被广泛应用于各类企业级项目中,具有完善的文档支持和活跃的社区生态。MyBatis作为持久层框架,提供了灵活的SQL映射能力,能够满足各种复杂的数据库操作需求。MySQL数据库性能稳定、运维成本低,完全能够满足本系统的数据存储需求。前端采用Vue 2框架和Element UI组件库,两者的结合已成为管理后台开发的标准方案,拥有丰富的组件和完善的文档。Sa-Token认证框架轻量高效,能够快速实现系统的安全认证需求。综上所述,本系统在技术层面完全可行。
+
+### 3.2.2 操作可行性
+
+本系统采用B/S架构,用户只需通过浏览器即可访问系统,无需安装额外的客户端软件,降低了使用门槛。系统界面采用Element UI组件库构建,风格统一、布局清晰、操作直观,符合用户的使用习惯。系统针对不同角色设计了差异化的功能菜单,用户登录后只能看到与自己角色相关的功能模块,避免了功能冗余带来的困扰。对于管理员和护工等专业用户,系统提供了表格化的数据展示和表单化的数据录入方式,操作流程简洁明了。对于家属用户,系统提供了简洁的信息查看界面和便捷的在线支付功能。因此,本系统在操作层面具有良好的可行性。
+
+### 3.2.3 经济可行性
+
+本系统的开发和运行成本较低。开发工具方面,系统采用的Spring Boot、Vue、MySQL、MyBatis等技术框架均为开源免费软件,无需支付许可费用。开发环境方面,使用IntelliJ IDEA或VS Code等开发工具即可完成开发工作。部署方面,系统可以部署在普通的云服务器上,一台配置为2核4GB内存的云服务器即可满足中小型养老机构的使用需求,年度服务器费用在数千元以内。与购买商业化养老管理软件相比,自主开发的系统不仅成本更低,还可以根据养老机构的实际需求进行定制化开发。因此,本系统在经济层面具有明显的可行性优势。
+
+### 3.2.4 社会可行性
+
+养老服务信息化建设是国家政策大力支持的方向。国务院和各级地方政府多次发文要求加快养老服务领域的信息化建设,推动"互联网+养老"的发展。本系统的开发符合国家政策导向,有助于提升养老机构的管理水平和服务质量,满足老年人及其家属对高质量养老服务的需求。同时,系统的推广应用有助于推动养老行业的数字化转型,促进养老服务行业的健康发展。因此,本系统在社会层面具有良好的可行性和积极的社会意义。
+
+## 3.3 用例图
+
+### 3.3.1 管理员用例图
+
+管理员是系统的最高权限角色,拥有系统的全面管理功能。管理员登录系统后,可以进行运营概览查看、账号管理、长者档案管理、排班管理、账单管理、反馈处理和通知公告管理等操作。其中,账号管理包含添加账号、编辑账号和重置密码三个子用例;长者档案管理包含添加长者、编辑长者信息和删除长者三个子用例。管理员用例图如图3.1所示。
+
+
+
+图3.1 管理员用例图
+
+### 3.3.2 护工用例图
+
+护工是系统的一线操作角色,主要负责长者的日常护理和健康监测工作。护工登录系统后,可以进行查看排班、护理记录管理、健康监测记录、交班记录管理和查看通知等操作。其中,护理记录管理包含添加护理记录和上传附件两个子用例;健康监测记录包含记录体征数据子用例;交班记录管理包含添加交班记录子用例。护工用例图如图3.2所示。
+
+
+
+图3.2 护工用例图
+
+### 3.3.3 家属用例图
+
+家属是系统的信息查看和服务反馈角色,主要通过系统了解老人在养老院的生活和健康状况。家属登录系统后,可以进行查看亲人档案、查看护理记录、查看健康记录、账单支付、服务反馈和查看通知等操作。其中,账单支付包含查看账单明细和在线支付两个子用例;服务反馈包含提交反馈和查看反馈回复两个子用例。家属用例图如图3.3所示。
+
+
+
+图3.3 家属用例图
+
+## 3.4 用例描述
+
+### 3.4.1 管理员管理长者档案用例描述
+
+管理员管理长者档案用例描述如表3.1所示。
+
+表3.1 管理员管理长者档案用例描述
+
+| 项目 | 描述 |
+|------|------|
+| 用例名称 | 管理长者档案 |
+| 执行者 | 管理员 |
+| 简要说明 | 管理员对养老院长者的基本信息进行添加、修改、删除等管理操作 |
+| 前置条件 | 管理员已登录系统 |
+| 基本事件流 | 1. 管理员登录系统,进入长者档案管理页面;2. 系统显示已有长者列表,包含姓名、性别、身份证号、房间号、护理等级、状态等信息;3. 管理员点击"添加长者"按钮,在弹出的表单中输入长者的详细信息,包括姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级、状态和备注,提交后系统验证数据并保存;4. 若需修改长者信息,管理员点击对应长者的"编辑"按钮,修改相关信息后提交保存;5. 若需删除长者记录,管理员点击"删除"按钮,确认后系统移除该长者记录 |
+| 后置条件 | 长者档案信息更新成功,数据库中的数据保持一致 |
+
+### 3.4.2 护工添加护理记录用例描述
+
+护工添加护理记录用例描述如表3.2所示。
+
+表3.2 护工添加护理记录用例描述
+
+| 项目 | 描述 |
+|------|------|
+| 用例名称 | 添加护理记录 |
+| 执行者 | 护工 |
+| 简要说明 | 护工在完成护理服务后,在线记录护理内容并可上传附件 |
+| 前置条件 | 护工已登录系统 |
+| 基本事件流 | 1. 护工登录系统,进入护理记录页面;2. 护工选择被护理的长者;3. 护工填写护理内容,包括护理服务的具体描述;4. 护工可选择上传图片等附件作为护理凭证;5. 护工选择记录时间,默认为当前时间;6. 护工点击提交按钮,系统验证数据后保存护理记录;7. 系统提示添加成功,护理记录列表自动刷新 |
+| 后置条件 | 护理记录保存成功,家属可通过系统查看该记录 |
+
+### 3.4.3 家属在线支付账单用例描述
+
+家属在线支付账单用例描述如表3.3所示。
+
+表3.3 家属在线支付账单用例描述
+
+| 项目 | 描述 |
+|------|------|
+| 用例名称 | 在线支付账单 |
+| 执行者 | 家属 |
+| 简要说明 | 家属查看老人的月度费用账单并完成在线支付 |
+| 前置条件 | 家属已登录系统,且存在未支付的账单 |
+| 基本事件流 | 1. 家属登录系统,进入账单支付页面;2. 家属选择要查看账单的长者;3. 系统显示该长者的所有账单列表,包含月份、总金额和支付状态;4. 家属查看未支付账单的明细,包括床位费、护理费、餐饮费和其他费用;5. 家属点击"支付"按钮,选择支付方式;6. 系统处理支付请求,更新账单状态为已支付,记录支付信息;7. 系统提示支付成功 |
+| 后置条件 | 账单状态更新为已支付,生成对应的缴费记录 |
+
+## 3.5 系统性能分析
+
+本系统在性能方面进行了多维度的考量和优化设计。在数据库层面,对高频查询字段建立了索引,如护理记录表和健康记录表的elder_id字段、排班表的nurse_id和date组合字段等,有效提升了数据查询效率。在接口设计层面,采用RESTful风格的API设计,请求和响应数据采用JSON格式,数据传输量小、解析速度快。在安全性能方面,用户密码采用BCrypt算法进行加密存储,Token采用UUID格式生成,有效防止了密码泄露和Token伪造风险。在前端性能方面,Vue框架的虚拟DOM机制减少了不必要的页面重绘,Element UI组件的按需加载策略降低了前端资源的加载时间。系统整体架构采用前后端分离模式,前端静态资源可通过CDN加速分发,后端服务可通过水平扩展提升处理能力,具有良好的性能扩展空间。
diff --git a/thesis/chapter4.md b/thesis/chapter4.md
new file mode 100644
index 0000000..0f0db29
--- /dev/null
+++ b/thesis/chapter4.md
@@ -0,0 +1,382 @@
+# 第4章 养老院管理系统的系统设计
+
+## 4.1 系统功能设计
+
+本系统面向管理员、护工和家属三类用户角色,各角色拥有不同的功能权限。管理员作为系统的最高权限角色,负责系统的全面运营管理,包括运营概览、账号管理、长者档案管理、排班管理、账单管理、反馈处理和通知公告管理七大功能模块。护工作为一线服务角色,拥有工作台、我的排班、护理记录、健康监测、交班记录和通知中心六大功能模块。家属作为信息查看角色,拥有家属首页、亲人档案、每日动态、健康记录、账单支付、服务反馈和通知中心七大功能模块。
+
+管理员功能结构图如图4.1所示。
+
+
+
+图4.1 管理员功能结构图
+
+护工功能结构图如图4.2所示。
+
+
+
+图4.2 护工功能结构图
+
+家属功能结构图如图4.3所示。
+
+
+
+图4.3 家属功能结构图
+
+## 4.2 类图
+
+本系统的数据模型采用关系型数据库设计,共包含11个数据实体,各实体之间通过外键关联形成完整的数据关系网络。系统类图采用IE Crow's Foot标记法展示各实体的属性和实体间的关系。核心实体包括用户表(sys_user)、长者表(elder)、家属长者关联表(family_elder)、排班表(schedule)、护理记录表(care_record)、健康记录表(health_record)、交班记录表(handover)、通知表(notice)、反馈表(feedback)、账单表(bill)和缴费记录表(payment_record)。
+
+主要的实体关系包括:用户(护工角色)与排班、护理记录、健康记录、交班记录之间为一对多关系;用户(家属角色)与长者之间通过家属长者关联表形成多对多关系;长者与护理记录、健康记录、账单、反馈之间为一对多关系;账单与缴费记录之间为一对多关系;用户(管理员角色)与通知之间为一对多关系。系统类图如图4.4所示。
+
+
+
+图4.4 系统类图
+
+## 4.3 序列图
+
+### 4.3.1 用户登录序列图
+
+用户登录过程涉及用户、系统前台、后台系统和数据库四个参与者之间的交互。具体步骤如下:
+
+(1)用户在浏览器中打开系统登录页面。
+
+(2)用户输入用户名和密码,点击登录按钮。
+
+(3)系统前台将登录请求发送至后台系统的认证接口(POST /api/auth/login)。
+
+(4)后台系统接收请求后,向数据库查询该用户名对应的用户信息。
+
+(5)数据库返回查询结果。
+
+(6)后台系统使用BCrypt算法验证用户输入的密码与数据库中存储的加密密码是否匹配。
+
+(7)验证通过后,后台系统调用Sa-Token框架生成UUID格式的Token。
+
+(8)后台系统将Token、用户角色和用户信息返回给系统前台。
+
+(9)系统前台将Token和角色信息存储到浏览器的localStorage中。
+
+(10)系统前台根据用户角色自动跳转到对应的功能首页。
+
+用户登录序列图如图4.5所示。
+
+
+
+图4.5 用户登录序列图
+
+### 4.3.2 护工添加护理记录序列图
+
+护工添加护理记录过程涉及护工、系统前台、后台系统和数据库四个参与者之间的交互。具体步骤如下:
+
+(1)护工在系统中进入护理记录页面。
+
+(2)系统前台向后台系统请求长者列表数据。
+
+(3)后台系统从数据库查询长者信息并返回。
+
+(4)系统前台展示长者列表供护工选择。
+
+(5)护工选择目标长者,填写护理内容,可选择上传附件。
+
+(6)系统前台将护理记录数据提交至后台系统(POST /api/nurse/care-records)。
+
+(7)后台系统自动关联当前登录护工的ID,设置记录时间,将数据插入数据库。
+
+(8)数据库返回插入结果。
+
+(9)后台系统将创建成功的响应返回给系统前台。
+
+(10)系统前台显示添加成功提示,并刷新护理记录列表。
+
+护工添加护理记录序列图如图4.6所示。
+
+
+
+图4.6 护工添加护理记录序列图
+
+## 4.4 活动图
+
+### 4.4.1 用户登录活动图
+
+用户登录过程可分为以下几步:
+
+(1)用户在登录页面输入用户名和密码。
+
+(2)系统前台将登录信息提交至后台系统。
+
+(3)后台系统向数据库查询用户数据。
+
+(4)数据库返回查询结果,后台系统判断用户是否存在以及密码是否正确。
+
+(5)若验证失败,系统返回错误提示,用户需重新输入。
+
+(6)若验证成功,后台系统生成Token并返回给前台。
+
+(7)前台存储Token信息,跳转至对应角色的系统首页。
+
+用户登录活动图如图4.7所示。
+
+
+
+图4.7 用户登录活动图
+
+### 4.4.2 管理员处理反馈活动图
+
+管理员处理反馈过程可分为以下几步:
+
+(1)管理员登录系统,进入反馈处理页面。
+
+(2)系统前台向后台系统请求所有反馈数据。
+
+(3)后台系统从数据库查询反馈列表并返回。
+
+(4)管理员查看反馈列表,选择需要处理的反馈。
+
+(5)管理员填写回复内容,更新反馈状态。
+
+(6)系统前台将回复信息提交至后台系统。
+
+(7)后台系统更新数据库中的反馈记录。
+
+(8)系统提示回复成功,反馈列表自动刷新。
+
+管理员处理反馈活动图如图4.8所示。
+
+
+
+图4.8 管理员处理反馈活动图
+
+## 4.5 数据库设计
+
+### 4.5.1 概念设计
+
+概念设计阶段采用E-R图(实体-关系图)描述系统的数据模型。本系统共包含11个实体,以下列举8个核心实体的属性图。
+
+(1)用户实体
+
+用户实体包含用户ID(主码)、用户名、密码、姓名、电话、角色和状态等属性。用户实体属性图如图4.9所示。
+
+
+
+图4.9 用户实体属性图
+
+(2)长者实体
+
+长者实体包含长者ID(主码)、姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级、状态和备注等属性。长者实体属性图如图4.10所示。
+
+
+
+图4.10 长者实体属性图
+
+(3)排班实体
+
+排班实体包含排班ID(主码)、护工ID、日期、班次和任务等属性。排班实体属性图如图4.11所示。
+
+
+
+图4.11 排班实体属性图
+
+(4)护理记录实体
+
+护理记录实体包含记录ID(主码)、长者ID、护工ID、内容、附件和记录时间等属性。护理记录实体属性图如图4.12所示。
+
+
+
+图4.12 护理记录实体属性图
+
+(5)健康记录实体
+
+健康记录实体包含记录ID(主码)、长者ID、护工ID、体温、收缩压、舒张压、心率、备注和记录时间等属性。健康记录实体属性图如图4.13所示。
+
+
+
+图4.13 健康记录实体属性图
+
+(6)账单实体
+
+账单实体包含账单ID(主码)、长者ID、月份、床位费、护理费、餐饮费、其他费用、总计和状态等属性。账单实体属性图如图4.14所示。
+
+
+
+图4.14 账单实体属性图
+
+(7)反馈实体
+
+反馈实体包含反馈ID(主码)、家属ID、长者ID、类型、内容、评分、状态和回复等属性。反馈实体属性图如图4.15所示。
+
+
+
+图4.15 反馈实体属性图
+
+(8)通知实体
+
+通知实体包含通知ID(主码)、标题、内容、目标角色、目标用户ID和创建者ID等属性。通知实体属性图如图4.16所示。
+
+
+
+图4.16 通知实体属性图
+
+系统总体E-R图展示了各实体之间的关联关系,如图4.17所示。
+
+
+
+图4.17 系统E-R图
+
+### 4.5.2 逻辑设计
+
+将E-R图中的实体关系转换为关系模式,具体如下:
+
+(1)用户表:(用户ID,用户名,密码,姓名,电话,角色,状态,创建时间,更新时间)
+
+(2)长者表:(长者ID,姓名,性别,身份证号,出生日期,房间号,入住日期,护理等级,状态,备注)
+
+(3)家属长者关联表:(关联ID,家属ID,长者ID,关系,创建时间)。外键:家属ID引用用户表,长者ID引用长者表。
+
+(4)排班表:(排班ID,护工ID,日期,班次,任务,创建时间,更新时间)。外键:护工ID引用用户表。
+
+(5)护理记录表:(记录ID,长者ID,护工ID,内容,附件URL,记录时间,创建时间)。外键:长者ID引用长者表,护工ID引用用户表。
+
+(6)健康记录表:(记录ID,长者ID,护工ID,体温,收缩压,舒张压,心率,备注,记录时间,创建时间)。外键:长者ID引用长者表,护工ID引用用户表。
+
+(7)交班记录表:(记录ID,护工ID,日期,内容,创建时间)。外键:护工ID引用用户表。
+
+(8)通知表:(通知ID,标题,内容,目标角色,目标用户ID,创建者ID,创建时间)。外键:创建者ID引用用户表。
+
+(9)反馈表:(反馈ID,家属ID,长者ID,类型,内容,评分,状态,回复,创建时间,更新时间)。外键:家属ID引用用户表,长者ID引用长者表。
+
+(10)账单表:(账单ID,长者ID,月份,床位费,护理费,餐饮费,其他费用,总计,状态,创建时间,支付时间)。外键:长者ID引用长者表。
+
+(11)缴费记录表:(记录ID,账单ID,家属ID,金额,支付方式,支付时间)。外键:账单ID引用账单表,家属ID引用用户表。
+
+### 4.5.3 物理设计
+
+系统根据MySQL数据库数据存储的特性设计数据库关系表,以下列举主要的物理表结构。
+
+表4.1 用户表(sys_user表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 用户ID | BIGINT | - | 主键,自增 |
+| username | 用户名 | VARCHAR | 50 | 非空,唯一 |
+| password | 密码 | VARCHAR | 100 | 非空 |
+| name | 姓名 | VARCHAR | 50 | 非空 |
+| phone | 电话 | VARCHAR | 30 | - |
+| role | 角色 | VARCHAR | 20 | 非空 |
+| status | 状态 | TINYINT | - | 非空,默认1 |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| updated_at | 更新时间 | DATETIME | - | 自动更新 |
+
+表4.2 长者表(elder表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 长者ID | BIGINT | - | 主键,自增 |
+| name | 姓名 | VARCHAR | 50 | 非空 |
+| gender | 性别 | VARCHAR | 10 | - |
+| id_card | 身份证号 | VARCHAR | 30 | 非空,唯一 |
+| birthday | 出生日期 | DATE | - | - |
+| room_no | 房间号 | VARCHAR | 20 | - |
+| check_in_date | 入住日期 | DATE | - | - |
+| care_level | 护理等级 | VARCHAR | 20 | - |
+| status | 状态 | VARCHAR | 20 | - |
+| remark | 备注 | VARCHAR | 200 | - |
+
+表4.3 护理记录表(care_record表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 记录ID | BIGINT | - | 主键,自增 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| nurse_id | 护工ID | BIGINT | - | 非空 |
+| content | 护理内容 | VARCHAR | 500 | - |
+| attachment_url | 附件URL | VARCHAR | 200 | - |
+| record_time | 记录时间 | DATETIME | - | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+
+表4.4 健康记录表(health_record表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 记录ID | BIGINT | - | 主键,自增 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| nurse_id | 护工ID | BIGINT | - | 非空 |
+| temperature | 体温 | DECIMAL | 4,1 | - |
+| bp_systolic | 收缩压 | INT | - | - |
+| bp_diastolic | 舒张压 | INT | - | - |
+| heart_rate | 心率 | INT | - | - |
+| note | 备注 | VARCHAR | 200 | - |
+| record_time | 记录时间 | DATETIME | - | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+
+表4.5 账单表(bill表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 账单ID | BIGINT | - | 主键,自增 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| month | 月份 | VARCHAR | 7 | 非空 |
+| bed_fee | 床位费 | DECIMAL | 10,2 | - |
+| care_fee | 护理费 | DECIMAL | 10,2 | - |
+| meal_fee | 餐饮费 | DECIMAL | 10,2 | - |
+| other_fee | 其他费用 | DECIMAL | 10,2 | - |
+| total | 总计 | DECIMAL | 10,2 | - |
+| status | 状态 | VARCHAR | 20 | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| paid_at | 支付时间 | DATETIME | - | - |
+
+表4.6 排班表(schedule表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 排班ID | BIGINT | - | 主键,自增 |
+| nurse_id | 护工ID | BIGINT | - | 非空 |
+| date | 日期 | DATE | - | 非空 |
+| shift | 班次 | VARCHAR | 20 | - |
+| task | 任务 | VARCHAR | 200 | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| updated_at | 更新时间 | DATETIME | - | 自动更新 |
+
+表4.7 反馈表(feedback表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 反馈ID | BIGINT | - | 主键,自增 |
+| family_id | 家属ID | BIGINT | - | 非空 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| type | 类型 | VARCHAR | 20 | - |
+| content | 内容 | VARCHAR | 500 | - |
+| rating | 评分 | INT | - | - |
+| status | 状态 | VARCHAR | 20 | - |
+| reply | 回复 | VARCHAR | 500 | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| updated_at | 更新时间 | DATETIME | - | 自动更新 |
+
+表4.8 通知表(notice表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 通知ID | BIGINT | - | 主键,自增 |
+| title | 标题 | VARCHAR | 100 | 非空 |
+| content | 内容 | VARCHAR | 1000 | - |
+| target_role | 目标角色 | VARCHAR | 20 | - |
+| target_user_id | 目标用户ID | BIGINT | - | - |
+| created_by | 创建者ID | BIGINT | - | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+
+## 4.6 图形界面设计
+
+### 4.6.1 长者档案管理界面设计
+
+管理员的长者档案管理界面采用经典的管理后台布局,左侧为导航菜单,右侧为主内容区域。主内容区域顶部设有"添加长者"操作按钮,下方为长者信息数据表格,表格列包括姓名、性别、身份证号、房间号、护理等级、状态和操作列。操作列提供编辑和删除按钮。点击添加或编辑按钮时,弹出表单对话框供用户输入或修改长者信息。长者档案管理界面设计图如图4.18所示。
+
+
+
+图4.18 长者档案管理界面设计图
+
+### 4.6.2 健康监测界面设计
+
+护工的健康监测界面同样采用左侧导航、右侧内容的布局。主内容区域上方为数据录入表单,包含长者选择下拉框、体温输入框、收缩压输入框、舒张压输入框、心率输入框、备注输入框和记录时间选择器,以及提交按钮。表单下方为健康记录数据表格,展示已录入的历史健康监测数据。健康监测界面设计图如图4.19所示。
+
+
+
+图4.19 健康监测界面设计图
diff --git a/thesis/chapter5_6_7.md b/thesis/chapter5_6_7.md
new file mode 100644
index 0000000..0cc7bdf
--- /dev/null
+++ b/thesis/chapter5_6_7.md
@@ -0,0 +1,203 @@
+# 第5章 养老院管理系统的系统实现
+
+## 5.1 管理员功能模块
+
+### 5.1.1 运营概览
+
+管理员登录系统后,首先进入运营概览页面。该页面以卡片形式展示养老院的四项核心运营指标:在住长者数量、护工数量、家属数量和累计收入。系统通过调用后端统计接口(GET /api/admin/stats)获取实时数据,后端从数据库中分别统计各角色用户数量和已支付账单的总金额,将结果以JSON格式返回给前端。前端使用Element UI的el-row和el-card组件进行布局展示,四个指标卡片等宽排列,直观呈现养老院的整体运营状况。
+
+### 5.1.2 账号管理
+
+账号管理页面为管理员提供了系统用户的全生命周期管理功能。页面顶部设有角色筛选下拉框,管理员可按角色(护工、家属)筛选用户列表。用户列表以数据表格形式展示,包含用户名、姓名、角色、状态等字段。管理员可执行以下操作:点击"添加账号"按钮,在弹出的对话框中填写用户名、密码、姓名、电话和角色信息,提交后系统调用后端接口创建新用户,密码经BCrypt加密后存储;点击"编辑"按钮可修改用户的姓名、电话和状态信息;点击"重置密码"按钮可为用户设置新密码;通过状态开关可启用或禁用用户账号。
+
+### 5.1.3 长者档案管理
+
+长者档案管理页面实现了长者基本信息的增删改查功能。页面以数据表格展示所有长者的信息,包括姓名、性别、身份证号、房间号、入住日期、护理等级和状态等字段。管理员点击"添加长者"按钮后,系统弹出包含姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级、状态和备注等字段的表单对话框。表单提交后,前端调用后端接口(POST /api/admin/elders)将数据保存至数据库。编辑功能复用同一表单组件,通过回填已有数据实现信息修改。删除操作需经二次确认,防止误操作。
+
+### 5.1.4 排班管理
+
+排班管理页面采用日历视图与列表视图相结合的设计。页面上方展示月度日历,管理员可通过点击日期查看当日的排班详情。日历下方以表格形式展示选定日期的所有排班记录,包括护工姓名、班次(早班、中班、夜班)和工作任务。管理员可创建新的排班记录,需选择护工、日期、班次并填写任务描述。系统支持排班的编辑和删除操作,同时支持按日期范围查询排班数据,便于管理员进行周度或月度排班规划。
+
+### 5.1.5 账单管理
+
+账单管理页面实现了养老院费用账单的全流程管理。管理员可按长者筛选账单列表,表格展示账单的月份、床位费、护理费、餐饮费、其他费用、总计金额和支付状态。创建账单时,管理员选择长者和月份,分别填写各项费用金额,系统自动计算总计金额。账单创建后状态默认为"未支付",待家属完成支付后状态自动更新为"已支付"。管理员可编辑未支付的账单信息,也可删除错误创建的账单记录。
+
+### 5.1.6 反馈处理
+
+反馈处理页面展示所有家属提交的服务反馈信息。反馈列表以表格形式呈现,包含反馈类型(建议、投诉等)、反馈内容、评分、提交时间和处理状态等字段。管理员点击某条反馈的"回复"按钮后,在弹出的对话框中填写回复内容并更新处理状态(如"已处理"),提交后系统调用后端接口(PUT /api/admin/feedback)更新反馈记录。家属可在自己的反馈列表中查看管理员的回复内容。
+
+### 5.1.7 通知公告管理
+
+通知公告管理页面支持管理员向不同角色发布通知信息。页面上方设有"发布通知"按钮,点击后弹出表单对话框,管理员需填写通知标题、通知内容,并选择目标角色(护工、家属或全部)。通知发布后,对应角色的用户在登录系统后可在通知中心页面查看该通知。通知列表以表格形式展示已发布的所有通知,包含标题、目标角色和发布时间等信息。
+
+## 5.2 护工功能模块
+
+### 5.2.1 护理记录
+
+护理记录页面是护工日常工作中使用频率最高的功能模块。页面上方为护理记录录入表单,护工需选择被护理的长者,填写护理内容的详细描述,可选择上传图片等附件作为护理凭证(通过调用文件上传接口POST /api/files/upload实现),并选择记录时间。表单提交后,系统自动关联当前登录护工的ID,将护理记录保存至数据库。页面下方以列表形式展示该长者的历史护理记录,包含记录时间、护理内容和附件链接等信息,便于护工回顾和参考。
+
+### 5.2.2 健康监测
+
+健康监测页面用于记录长者的日常体征数据。录入表单包含长者选择、体温(摄氏度)、收缩压(mmHg)、舒张压(mmHg)、心率(次/分钟)、备注和记录时间等字段。护工完成体征测量后,在表单中录入各项数据并提交,系统将数据保存至健康记录表。页面下方展示该长者的历史健康监测数据列表,家属也可通过家属端查看这些数据,实现了健康信息的透明共享。
+
+### 5.2.3 交班记录
+
+交班记录页面用于护工在换班时记录当班期间的重要事项。录入表单包含日期选择和交班内容两个字段,护工填写当班期间需要交接的注意事项、特殊情况等信息后提交保存。页面下方展示当前护工的历史交班记录列表,按时间倒序排列,便于接班护工查阅前一班次的工作情况,确保护理服务的连续性。
+
+### 5.2.4 我的排班
+
+我的排班页面以月度日历视图展示护工个人的排班信息。护工可通过切换月份查看不同时间段的排班安排,点击具体日期可查看当日的班次和工作任务详情。系统通过调用后端接口(GET /api/nurse/schedules/range)按日期范围获取排班数据,前端将数据渲染到日历组件上,直观展示护工的工作安排。
+
+## 5.3 家属功能模块
+
+### 5.3.1 亲人档案
+
+亲人档案页面展示与当前登录家属关联的所有长者信息。系统通过家属长者关联表(family_elder)查询当前家属关联的长者ID列表,再从长者表中获取对应的详细信息。页面以表格形式展示长者的姓名、性别、房间号和护理等级等基本信息,家属可直观了解老人的入住情况。
+
+### 5.3.2 每日动态
+
+每日动态页面允许家属查看老人的护理服务记录。页面顶部设有长者选择下拉框,家属选择目标长者后,系统加载该长者的所有护理记录列表。列表展示每条记录的时间、护理内容和附件信息。系统在后端进行权限校验,确保家属只能查看与自己关联的长者的护理记录,防止越权访问。
+
+### 5.3.3 健康记录
+
+健康记录页面的设计与每日动态页面类似,家属选择长者后可查看该长者的所有健康监测数据。列表展示记录时间、体温、收缩压、舒张压、心率和备注等信息,家属可通过这些数据了解老人的健康趋势,及时发现异常情况。
+
+### 5.3.4 账单支付
+
+账单支付页面实现了家属在线查看和支付账单的功能。家属选择长者后,系统展示该长者的所有账单列表,包含月份、总金额和支付状态。对于未支付的账单,家属可点击"支付"按钮,选择支付方式后完成支付。系统调用后端支付接口(POST /api/family/bills/{id}/pay),后端更新账单状态为"已支付",同时在缴费记录表中插入一条支付记录,记录支付金额、支付方式和支付时间。
+
+### 5.3.5 服务反馈
+
+服务反馈页面为家属提供了向养老院提交意见和建议的渠道。页面上方为反馈提交表单,家属需选择关联的长者,选择反馈类型(建议、投诉等),填写反馈内容,并可进行服务评分。提交后系统将反馈保存至数据库,状态默认为"新建"。页面下方展示家属已提交的所有反馈记录,包含反馈内容、提交时间、处理状态和管理员回复等信息,实现了反馈的闭环管理。
+
+# 第6章 养老院管理系统的系统测试
+
+## 6.1 系统测试概述
+
+### 6.1.1 测试的背景
+
+系统测试是软件开发过程中不可或缺的重要环节,其目的是验证系统是否满足需求规格说明中定义的各项功能和性能要求。本系统作为一个面向养老机构的管理平台,涉及长者信息管理、护理服务记录、健康数据监测、费用结算等关键业务功能,任何功能缺陷或数据错误都可能影响养老服务的质量和安全。因此,对系统进行全面、系统的测试具有重要意义。
+
+### 6.1.2 测试的意义
+
+通过系统测试,可以发现和修复系统中存在的功能缺陷和性能问题,确保系统在交付使用前达到预期的质量标准。具体而言,功能测试可以验证各功能模块是否按照需求正确实现;安全性测试可以检验系统的身份认证和权限控制机制是否有效;兼容性测试可以确保系统在不同浏览器和设备上的正常运行。系统测试的充分开展有助于提升用户对系统的信任度和满意度。
+
+### 6.1.3 测试的环境
+
+本系统的测试环境配置如下:
+
+| 项目 | 配置 |
+|------|------|
+| 操作系统 | Windows 11 / macOS Sonoma |
+| 处理器 | Intel Core i7 / Apple M2 |
+| 内存 | 16GB |
+| 数据库 | MySQL 8.0 |
+| JDK版本 | JDK 17 |
+| 浏览器 | Google Chrome 120、Mozilla Firefox 121、Microsoft Edge 120 |
+| 后端服务器 | Spring Boot内嵌Tomcat |
+| 前端开发服务器 | Vue CLI DevServer |
+
+## 6.2 系统测试用例设计
+
+### 6.2.1 长者档案管理功能测试
+
+表6.1 长者档案管理功能测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-001 | 添加长者 | 姓名:张明远,性别:男,身份证号:110101195501010011,出生日期:1955-01-01,房间号:C301,入住日期:2024-06-15,护理等级:一级,状态:在住 | 系统提示添加成功,长者列表中出现新记录 | 系统提示添加成功,列表正确显示新长者信息 | 是 |
+| TC-002 | 编辑长者信息 | 将张明远的房间号从C301修改为C302 | 系统提示修改成功,列表中房间号更新为C302 | 修改成功,数据正确更新 | 是 |
+| TC-003 | 删除长者 | 选择张明远,点击删除并确认 | 系统提示删除成功,列表中不再显示该长者 | 删除成功,记录已移除 | 是 |
+| TC-004 | 添加重复身份证号 | 输入已存在的身份证号110101194001010011 | 系统提示身份证号已存在,添加失败 | 系统正确提示错误信息 | 是 |
+
+### 6.2.2 护理记录管理功能测试
+
+表6.2 护理记录管理功能测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-005 | 添加护理记录 | 选择长者:陈国强,内容:协助进行上午康复训练,包括手臂伸展和腿部活动,记录时间:2024-06-15 10:00 | 系统提示添加成功,记录列表中出现新记录 | 添加成功,记录正确显示 | 是 |
+| TC-006 | 上传附件 | 选择一张护理现场照片上传 | 文件上传成功,附件链接正确显示 | 上传成功,可正常预览 | 是 |
+| TC-007 | 查看护理记录 | 家属端选择长者陈国强查看护理记录 | 显示该长者的所有护理记录列表 | 列表正确显示,数据完整 | 是 |
+
+### 6.2.3 健康监测功能测试
+
+表6.3 健康监测功能测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-008 | 记录体征数据 | 选择长者:李秀兰,体温:36.5,收缩压:125,舒张压:82,心率:75,备注:状态良好,记录时间:2024-06-15 14:30 | 系统提示记录成功,数据列表中出现新记录 | 记录成功,数据正确显示 | 是 |
+| TC-009 | 家属查看健康记录 | 家属端选择长者李秀兰查看健康记录 | 显示该长者的所有健康监测数据 | 数据正确显示,包含体温、血压、心率等信息 | 是 |
+
+### 6.2.4 安全性测试
+
+表6.4 安全性测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-010 | 未登录访问 | 直接访问/admin/dashboard页面 | 系统自动跳转到登录页面 | 正确跳转到登录页面 | 是 |
+| TC-011 | 越权访问 | 护工账号尝试访问/admin/users页面 | 系统拒绝访问,跳转到护工首页 | 正确拒绝,跳转到护工工作台 | 是 |
+| TC-012 | 错误密码登录 | 输入正确用户名和错误密码 | 系统提示密码错误 | 正确提示"密码错误" | 是 |
+| TC-013 | 禁用账号登录 | 使用已被禁用的账号登录 | 系统提示账号已被禁用 | 正确提示"账号已被禁用" | 是 |
+| TC-014 | 家属越权查看 | 家属尝试查看非关联长者的护理记录 | 系统提示无权访问 | 正确提示"无权访问该亲属" | 是 |
+
+### 6.2.5 兼容性测试
+
+表6.5 兼容性测试用例
+
+| 测试编号 | 测试项目 | 测试环境 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-015 | Chrome浏览器 | Google Chrome 120,Windows 11 | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+| TC-016 | Firefox浏览器 | Mozilla Firefox 121,Windows 11 | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+| TC-017 | Edge浏览器 | Microsoft Edge 120,Windows 11 | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+| TC-018 | macOS环境 | Google Chrome,macOS Sonoma | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+
+# 第7章 结论
+
+本文针对养老院日常运营管理中存在的信息化程度低、管理效率不高、家属沟通不畅等问题,设计并实现了一套基于Spring Boot的养老院管理系统。系统采用前后端分离的B/S架构,后端基于Spring Boot 3 + MyBatis + MySQL技术栈,前端基于Vue 2 + Element UI技术栈,通过Sa-Token框架实现了安全可靠的身份认证和基于角色的权限控制。
+
+系统面向管理员、护工和家属三类用户角色,实现了以下核心功能:管理员可进行运营数据概览、账号管理、长者档案管理、排班管理、账单管理、反馈处理和通知公告管理;护工可查看个人排班、记录护理服务内容、录入健康监测数据、管理交班记录和查看通知;家属可查看亲人档案、了解护理动态、查看健康记录、在线支付账单、提交服务反馈和接收通知。
+
+通过系统分析、系统设计、编码实现和系统测试等完整的软件开发流程,本系统已实现了预期的各项功能目标。测试结果表明,系统功能完善、运行稳定、安全可靠,能够有效提升养老院的信息化管理水平,改善家属与养老机构之间的信息沟通效率,为养老服务质量的提升提供了有力的技术支撑。
+
+当然,本系统仍存在一些可以改进和完善的方面。在功能层面,后续可以增加数据统计分析和可视化图表功能,为管理决策提供更直观的数据支持;可以引入消息推送机制,实现重要通知的实时提醒;可以增加移动端适配,方便护工和家属通过手机使用系统。在技术层面,可以引入Redis缓存提升系统的并发处理能力;可以采用微服务架构提升系统的可扩展性;可以集成物联网设备实现健康数据的自动采集。这些改进方向将在后续的研究和开发工作中逐步实现。
+
+## 参考文献
+
+[1] 国家统计局. 2024年国民经济和社会发展统计公报[R]. 北京: 国家统计局, 2025.
+
+[2] 国务院. 关于推进养老服务发展的意见[Z]. 国办发〔2019〕5号, 2019.
+
+[3] 国务院. "十四五"国家老龄事业发展和养老服务体系规划[Z]. 国发〔2021〕35号, 2021.
+
+[4] Craig Walls. Spring Boot实战[M]. 丁雪丰, 译. 北京: 人民邮电出版社, 2016.
+
+[5] 尤雨溪. Vue.js设计与实现[M]. 北京: 人民邮电出版社, 2022.
+
+[6] 李刚. 疯狂Java讲义(第6版)[M]. 北京: 电子工业出版社, 2022.
+
+[7] 王珊, 萨师煊. 数据库系统概论(第6版)[M]. 北京: 高等教育出版社, 2023.
+
+[8] 张开涛. 亿级流量网站架构核心技术[M]. 北京: 电子工业出版社, 2017.
+
+[9] 刘增辉. MyBatis从入门到精通[M]. 北京: 电子工业出版社, 2017.
+
+[10] 方志朋. 深入理解Spring Cloud与微服务构建[M]. 北京: 人民邮电出版社, 2018.
+
+[11] 张卫滨. Java持久化之MyBatis3[M]. 北京: 电子工业出版社, 2015.
+
+[12] 陈雄华, 林开雄. Spring Boot编程思想(核心篇)[M]. 北京: 电子工业出版社, 2019.
+
+## 致谢
+
+时光荏苒,四年的大学生活即将画上句号。在毕业论文完成之际,我要向所有给予我帮助和支持的人表达最诚挚的感谢。
+
+首先,我要衷心感谢我的指导老师。在毕业设计的整个过程中,老师给予了我悉心的指导和耐心的帮助。从选题方向的确定、系统架构的设计到论文的撰写修改,老师都提出了许多宝贵的意见和建议,使我受益匪浅。老师严谨的治学态度和丰富的专业知识深深影响了我,为我今后的学习和工作树立了榜样。
+
+其次,我要感谢大学四年来所有教导过我的老师们。正是各位老师的辛勤付出和无私奉献,使我掌握了扎实的专业知识和技能,为本次毕业设计的顺利完成奠定了坚实的基础。
+
+同时,我要感谢我的同学和朋友们。在毕业设计期间,他们与我分享技术经验、讨论解决方案,在遇到困难时给予我鼓励和帮助,使我能够克服各种挑战,顺利完成系统的开发工作。
+
+最后,我要特别感谢我的家人。感谢他们多年来的默默支持和无私付出,是他们的关爱和鼓励给了我不断前进的动力。
+
+在今后的学习和工作中,我将继续努力,不断提升自己的专业能力和综合素质,以更好的成绩回报所有关心和帮助过我的人。
diff --git a/thesis/diagrams/activity_feedback.drawio b/thesis/diagrams/activity_feedback.drawio
new file mode 100644
index 0000000..024b23a
--- /dev/null
+++ b/thesis/diagrams/activity_feedback.drawio
@@ -0,0 +1,73 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/activity_feedback.png b/thesis/diagrams/activity_feedback.png
new file mode 100644
index 0000000..97351c1
Binary files /dev/null and b/thesis/diagrams/activity_feedback.png differ
diff --git a/thesis/diagrams/activity_login.drawio b/thesis/diagrams/activity_login.drawio
new file mode 100644
index 0000000..f6e9aad
--- /dev/null
+++ b/thesis/diagrams/activity_login.drawio
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/activity_login.png b/thesis/diagrams/activity_login.png
new file mode 100644
index 0000000..8551601
Binary files /dev/null and b/thesis/diagrams/activity_login.png differ
diff --git a/thesis/diagrams/admin_func_structure.drawio b/thesis/diagrams/admin_func_structure.drawio
new file mode 100644
index 0000000..8c7f394
--- /dev/null
+++ b/thesis/diagrams/admin_func_structure.drawio
@@ -0,0 +1,107 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/admin_func_structure.png b/thesis/diagrams/admin_func_structure.png
new file mode 100644
index 0000000..0ada5f8
Binary files /dev/null and b/thesis/diagrams/admin_func_structure.png differ
diff --git a/thesis/diagrams/admin_usecase.drawio b/thesis/diagrams/admin_usecase.drawio
new file mode 100644
index 0000000..d584bfe
--- /dev/null
+++ b/thesis/diagrams/admin_usecase.drawio
@@ -0,0 +1,82 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/admin_usecase.png b/thesis/diagrams/admin_usecase.png
new file mode 100644
index 0000000..13753df
Binary files /dev/null and b/thesis/diagrams/admin_usecase.png differ
diff --git a/thesis/diagrams/class_diagram.drawio b/thesis/diagrams/class_diagram.drawio
new file mode 100644
index 0000000..e4e58e3
--- /dev/null
+++ b/thesis/diagrams/class_diagram.drawio
@@ -0,0 +1,58 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/class_diagram.png b/thesis/diagrams/class_diagram.png
new file mode 100644
index 0000000..bcd4c7f
Binary files /dev/null and b/thesis/diagrams/class_diagram.png differ
diff --git a/thesis/diagrams/entity_bill.drawio b/thesis/diagrams/entity_bill.drawio
new file mode 100644
index 0000000..ade817d
--- /dev/null
+++ b/thesis/diagrams/entity_bill.drawio
@@ -0,0 +1,33 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_bill.png b/thesis/diagrams/entity_bill.png
new file mode 100644
index 0000000..bd0f4e4
Binary files /dev/null and b/thesis/diagrams/entity_bill.png differ
diff --git a/thesis/diagrams/entity_care_record.drawio b/thesis/diagrams/entity_care_record.drawio
new file mode 100644
index 0000000..bdb570f
--- /dev/null
+++ b/thesis/diagrams/entity_care_record.drawio
@@ -0,0 +1,27 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_care_record.png b/thesis/diagrams/entity_care_record.png
new file mode 100644
index 0000000..f3de86d
Binary files /dev/null and b/thesis/diagrams/entity_care_record.png differ
diff --git a/thesis/diagrams/entity_elder.drawio b/thesis/diagrams/entity_elder.drawio
new file mode 100644
index 0000000..958fb51
--- /dev/null
+++ b/thesis/diagrams/entity_elder.drawio
@@ -0,0 +1,33 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_elder.png b/thesis/diagrams/entity_elder.png
new file mode 100644
index 0000000..107a36e
Binary files /dev/null and b/thesis/diagrams/entity_elder.png differ
diff --git a/thesis/diagrams/entity_feedback.drawio b/thesis/diagrams/entity_feedback.drawio
new file mode 100644
index 0000000..adf17e4
--- /dev/null
+++ b/thesis/diagrams/entity_feedback.drawio
@@ -0,0 +1,33 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_feedback.png b/thesis/diagrams/entity_feedback.png
new file mode 100644
index 0000000..3cc828c
Binary files /dev/null and b/thesis/diagrams/entity_feedback.png differ
diff --git a/thesis/diagrams/entity_health_record.drawio b/thesis/diagrams/entity_health_record.drawio
new file mode 100644
index 0000000..fc2c632
--- /dev/null
+++ b/thesis/diagrams/entity_health_record.drawio
@@ -0,0 +1,33 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_health_record.png b/thesis/diagrams/entity_health_record.png
new file mode 100644
index 0000000..f997d13
Binary files /dev/null and b/thesis/diagrams/entity_health_record.png differ
diff --git a/thesis/diagrams/entity_notice.drawio b/thesis/diagrams/entity_notice.drawio
new file mode 100644
index 0000000..72ca2ea
--- /dev/null
+++ b/thesis/diagrams/entity_notice.drawio
@@ -0,0 +1,27 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_notice.png b/thesis/diagrams/entity_notice.png
new file mode 100644
index 0000000..cb5db9e
Binary files /dev/null and b/thesis/diagrams/entity_notice.png differ
diff --git a/thesis/diagrams/entity_schedule.drawio b/thesis/diagrams/entity_schedule.drawio
new file mode 100644
index 0000000..75b31f6
--- /dev/null
+++ b/thesis/diagrams/entity_schedule.drawio
@@ -0,0 +1,25 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_schedule.png b/thesis/diagrams/entity_schedule.png
new file mode 100644
index 0000000..4aaf633
Binary files /dev/null and b/thesis/diagrams/entity_schedule.png differ
diff --git a/thesis/diagrams/entity_user.drawio b/thesis/diagrams/entity_user.drawio
new file mode 100644
index 0000000..c1f7597
--- /dev/null
+++ b/thesis/diagrams/entity_user.drawio
@@ -0,0 +1,49 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/entity_user.png b/thesis/diagrams/entity_user.png
new file mode 100644
index 0000000..b826137
Binary files /dev/null and b/thesis/diagrams/entity_user.png differ
diff --git a/thesis/diagrams/er_diagram.drawio b/thesis/diagrams/er_diagram.drawio
new file mode 100644
index 0000000..3d373ac
--- /dev/null
+++ b/thesis/diagrams/er_diagram.drawio
@@ -0,0 +1,106 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/er_diagram.png b/thesis/diagrams/er_diagram.png
new file mode 100644
index 0000000..d1ca940
Binary files /dev/null and b/thesis/diagrams/er_diagram.png differ
diff --git a/thesis/diagrams/family_func_structure.drawio b/thesis/diagrams/family_func_structure.drawio
new file mode 100644
index 0000000..67c9c75
--- /dev/null
+++ b/thesis/diagrams/family_func_structure.drawio
@@ -0,0 +1,74 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/family_func_structure.png b/thesis/diagrams/family_func_structure.png
new file mode 100644
index 0000000..2de9e6f
Binary files /dev/null and b/thesis/diagrams/family_func_structure.png differ
diff --git a/thesis/diagrams/family_usecase.drawio b/thesis/diagrams/family_usecase.drawio
new file mode 100644
index 0000000..5f0974a
--- /dev/null
+++ b/thesis/diagrams/family_usecase.drawio
@@ -0,0 +1,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/family_usecase.png b/thesis/diagrams/family_usecase.png
new file mode 100644
index 0000000..74185a5
Binary files /dev/null and b/thesis/diagrams/family_usecase.png differ
diff --git a/thesis/diagrams/nurse_func_structure.drawio b/thesis/diagrams/nurse_func_structure.drawio
new file mode 100644
index 0000000..0158aba
--- /dev/null
+++ b/thesis/diagrams/nurse_func_structure.drawio
@@ -0,0 +1,66 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/nurse_func_structure.png b/thesis/diagrams/nurse_func_structure.png
new file mode 100644
index 0000000..3a623f3
Binary files /dev/null and b/thesis/diagrams/nurse_func_structure.png differ
diff --git a/thesis/diagrams/nurse_usecase.drawio b/thesis/diagrams/nurse_usecase.drawio
new file mode 100644
index 0000000..25dab79
--- /dev/null
+++ b/thesis/diagrams/nurse_usecase.drawio
@@ -0,0 +1,50 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/nurse_usecase.png b/thesis/diagrams/nurse_usecase.png
new file mode 100644
index 0000000..e8c2856
Binary files /dev/null and b/thesis/diagrams/nurse_usecase.png differ
diff --git a/thesis/diagrams/sequence_care_record.drawio b/thesis/diagrams/sequence_care_record.drawio
new file mode 100644
index 0000000..251436f
--- /dev/null
+++ b/thesis/diagrams/sequence_care_record.drawio
@@ -0,0 +1,91 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/sequence_care_record.png b/thesis/diagrams/sequence_care_record.png
new file mode 100644
index 0000000..4979311
Binary files /dev/null and b/thesis/diagrams/sequence_care_record.png differ
diff --git a/thesis/diagrams/sequence_login.drawio b/thesis/diagrams/sequence_login.drawio
new file mode 100644
index 0000000..0794329
--- /dev/null
+++ b/thesis/diagrams/sequence_login.drawio
@@ -0,0 +1,83 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/sequence_login.png b/thesis/diagrams/sequence_login.png
new file mode 100644
index 0000000..5eb8b76
Binary files /dev/null and b/thesis/diagrams/sequence_login.png differ
diff --git a/thesis/diagrams/ui_wireframe_elder.drawio b/thesis/diagrams/ui_wireframe_elder.drawio
new file mode 100644
index 0000000..20c4b44
--- /dev/null
+++ b/thesis/diagrams/ui_wireframe_elder.drawio
@@ -0,0 +1,75 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/ui_wireframe_elder.png b/thesis/diagrams/ui_wireframe_elder.png
new file mode 100644
index 0000000..28979ff
Binary files /dev/null and b/thesis/diagrams/ui_wireframe_elder.png differ
diff --git a/thesis/diagrams/ui_wireframe_health.drawio b/thesis/diagrams/ui_wireframe_health.drawio
new file mode 100644
index 0000000..079ddc3
--- /dev/null
+++ b/thesis/diagrams/ui_wireframe_health.drawio
@@ -0,0 +1,64 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/thesis/diagrams/ui_wireframe_health.png b/thesis/diagrams/ui_wireframe_health.png
new file mode 100644
index 0000000..dcdb5c1
Binary files /dev/null and b/thesis/diagrams/ui_wireframe_health.png differ
diff --git a/thesis/generate_docx.py b/thesis/generate_docx.py
new file mode 100644
index 0000000..355cbc7
--- /dev/null
+++ b/thesis/generate_docx.py
@@ -0,0 +1,564 @@
+#!/usr/bin/env python3
+"""
+Generate formatted DOCX thesis from markdown files.
+Matches the style of the reference document (2106090117-佟欣鑫-论文.docx).
+
+Formatting spec (from reference analysis):
+- Page: A4 (11906x16838 twips), margins 2.5cm all sides
+- Normal text: 宋体/Times New Roman, 小四(12pt/sz=24), line spacing 1.5x(360twips), first-line indent 2chars
+- Heading 1 (章): 黑体/Times New Roman, 二号(22pt/sz=44), bold, centered, spacing before/after
+- Heading 2 (节): 黑体/Arial, 小三(15pt/sz=32 half-pt), bold, left
+- Heading 3 (小节): 黑体, 四号(14pt/sz=28), bold, left
+- Title (摘要/Abstract): 黑体, 小三(15pt/sz=32), bold, centered
+- Caption: 黑体, 五号(10.5pt/sz=20)
+- Header: 大连科技学院2026届本科毕业设计(论文)
+- Footer: page numbers
+- TOC styles: toc1=黑体14pt, toc2=宋体14pt indent
+"""
+
+import os
+import re
+import sys
+from docx import Document
+from docx.shared import Pt, Cm, Inches, Twips, RGBColor
+from docx.enum.text import WD_ALIGN_PARAGRAPH
+from docx.enum.table import WD_TABLE_ALIGNMENT
+from docx.enum.section import WD_ORIENT
+from docx.oxml.ns import qn, nsdecls
+from docx.oxml import parse_xml
+from lxml import etree
+
+THESIS_DIR = os.path.dirname(os.path.abspath(__file__))
+DIAGRAMS_DIR = os.path.join(THESIS_DIR, 'diagrams')
+
+# ─── Helper functions ───
+
+def set_run_font(run, cn_font='宋体', en_font='Times New Roman', size=Pt(12), bold=False, italic=False):
+ """Set font for a run with both Chinese and English fonts."""
+ run.font.size = size
+ run.font.bold = bold
+ run.font.italic = italic
+ run.font.name = en_font
+ r = run._element
+ rPr = r.find(qn('w:rPr'))
+ if rPr is None:
+ rPr = parse_xml(f'')
+ r.insert(0, rPr)
+ rFonts = rPr.find(qn('w:rFonts'))
+ if rFonts is None:
+ rFonts = parse_xml(f'')
+ rPr.insert(0, rFonts)
+ rFonts.set(qn('w:eastAsia'), cn_font)
+ rFonts.set(qn('w:ascii'), en_font)
+ rFonts.set(qn('w:hAnsi'), en_font)
+
+
+def set_paragraph_spacing(paragraph, line_spacing=360, before=0, after=0, first_line_chars=None, first_line=None):
+ """Set paragraph spacing and indentation."""
+ pPr = paragraph._element.find(qn('w:pPr'))
+ if pPr is None:
+ pPr = parse_xml(f'')
+ paragraph._element.insert(0, pPr)
+
+ # Spacing
+ spacing = pPr.find(qn('w:spacing'))
+ if spacing is None:
+ spacing = parse_xml(f'')
+ pPr.append(spacing)
+ if line_spacing:
+ spacing.set(qn('w:line'), str(line_spacing))
+ spacing.set(qn('w:lineRule'), 'auto')
+ if before:
+ spacing.set(qn('w:before'), str(before))
+ if after:
+ spacing.set(qn('w:after'), str(after))
+
+ # Indentation
+ if first_line_chars or first_line:
+ ind = pPr.find(qn('w:ind'))
+ if ind is None:
+ ind = parse_xml(f'')
+ pPr.append(ind)
+ if first_line_chars:
+ ind.set(qn('w:firstLineChars'), str(first_line_chars))
+ if first_line:
+ ind.set(qn('w:firstLine'), str(first_line))
+
+
+def add_body_paragraph(doc, text, cn_font='宋体', en_font='Times New Roman', size=Pt(12),
+ bold=False, alignment=None, first_line_indent=True, line_spacing=360):
+ """Add a normal body paragraph."""
+ p = doc.add_paragraph()
+ if alignment:
+ p.alignment = alignment
+ run = p.add_run(text)
+ set_run_font(run, cn_font, en_font, size, bold)
+ if first_line_indent:
+ set_paragraph_spacing(p, line_spacing=line_spacing, first_line_chars=200, first_line=480)
+ else:
+ set_paragraph_spacing(p, line_spacing=line_spacing)
+ return p
+
+
+def add_heading_chapter(doc, text):
+ """Add chapter heading (第X章) - 黑体 二号 bold centered."""
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run(text)
+ set_run_font(run, '黑体', 'Times New Roman', Pt(22), bold=True)
+ set_paragraph_spacing(p, line_spacing=360, before=312, after=312)
+ return p
+
+
+def add_heading_section(doc, text):
+ """Add section heading (X.X) - 黑体 小三 bold left."""
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.LEFT
+ run = p.add_run(text)
+ set_run_font(run, '黑体', 'Times New Roman', Pt(15), bold=True)
+ set_paragraph_spacing(p, line_spacing=360, before=156, after=156)
+ return p
+
+
+def add_heading_subsection(doc, text):
+ """Add subsection heading (X.X.X) - 黑体 四号 bold left."""
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.LEFT
+ run = p.add_run(text)
+ set_run_font(run, '黑体', 'Times New Roman', Pt(14), bold=True)
+ set_paragraph_spacing(p, line_spacing=360, before=78, after=78)
+ return p
+
+
+def add_title(doc, text):
+ """Add a title (摘要, Abstract, etc.) - 黑体 小三 bold centered."""
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run(text)
+ set_run_font(run, '黑体', 'Times New Roman', Pt(15), bold=True)
+ set_paragraph_spacing(p, line_spacing=360, before=240, after=60)
+ return p
+
+
+def add_caption(doc, text):
+ """Add figure/table caption - 黑体 五号 centered."""
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run(text)
+ set_run_font(run, '黑体', 'Times New Roman', Pt(10.5), bold=False)
+ set_paragraph_spacing(p, line_spacing=360, before=60, after=60)
+ return p
+
+
+def add_image(doc, image_path, width=None):
+ """Add an image centered."""
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run()
+ if os.path.exists(image_path):
+ if width:
+ run.add_picture(image_path, width=width)
+ else:
+ # Auto-size but max width ~14cm
+ from PIL import Image
+ try:
+ img = Image.open(image_path)
+ w, h = img.size
+ max_width = Cm(14)
+ aspect = h / w
+ if Cm(w * 2.54 / 96) > max_width:
+ run.add_picture(image_path, width=max_width)
+ else:
+ run.add_picture(image_path, width=Cm(min(w * 2.54 / 96, 14)))
+ except ImportError:
+ run.add_picture(image_path, width=Cm(14))
+ else:
+ run.add_text(f'[图片缺失: {image_path}]')
+ set_paragraph_spacing(p, line_spacing=360)
+ return p
+
+
+def add_table_from_md(doc, headers, rows):
+ """Add a formatted table from markdown table data."""
+ table = doc.add_table(rows=1 + len(rows), cols=len(headers))
+ table.alignment = WD_TABLE_ALIGNMENT.CENTER
+
+ # Set table style
+ tbl = table._tbl
+ tblPr = tbl.find(qn('w:tblPr'))
+ if tblPr is None:
+ tblPr = parse_xml(f'')
+ tbl.insert(0, tblPr)
+ borders = parse_xml(
+ f''
+ ''
+ ''
+ ''
+ ''
+ ''
+ ''
+ ''
+ )
+ tblPr.append(borders)
+
+ # Header row - gray background, bold text, vertical center
+ for i, h in enumerate(headers):
+ cell = table.cell(0, i)
+ cell.text = ''
+ # Gray background
+ shading = parse_xml(f'')
+ cell._element.find(qn('w:tcPr')).append(shading) if cell._element.find(qn('w:tcPr')) is not None else None
+ tcPr = cell._element.find(qn('w:tcPr'))
+ if tcPr is None:
+ tcPr = parse_xml(f'')
+ cell._element.insert(0, tcPr)
+ shading = tcPr.find(qn('w:shd'))
+ if shading is None:
+ shading = parse_xml(f'')
+ tcPr.append(shading)
+ else:
+ shading.set(qn('w:fill'), 'D9D9D9')
+ # Vertical center
+ vAlign = tcPr.find(qn('w:vAlign'))
+ if vAlign is None:
+ vAlign = parse_xml(f'')
+ tcPr.append(vAlign)
+ p = cell.paragraphs[0]
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run(h.strip())
+ set_run_font(run, '黑体', 'Times New Roman', Pt(10.5), bold=True)
+ set_paragraph_spacing(p, line_spacing=300)
+
+ # Data rows - vertical center
+ for r_idx, row in enumerate(rows):
+ for c_idx, cell_text in enumerate(row):
+ if c_idx < len(headers):
+ cell = table.cell(r_idx + 1, c_idx)
+ cell.text = ''
+ # Vertical center
+ tcPr = cell._element.find(qn('w:tcPr'))
+ if tcPr is None:
+ tcPr = parse_xml(f'')
+ cell._element.insert(0, tcPr)
+ vAlign = tcPr.find(qn('w:vAlign'))
+ if vAlign is None:
+ vAlign = parse_xml(f'')
+ tcPr.append(vAlign)
+ p = cell.paragraphs[0]
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run(cell_text.strip())
+ set_run_font(run, '宋体', 'Times New Roman', Pt(10.5), bold=False)
+ set_paragraph_spacing(p, line_spacing=300)
+
+ return table
+
+
+def setup_page(doc):
+ """Set up page size, margins, headers, footers."""
+ section = doc.sections[0]
+ section.page_width = Twips(11906)
+ section.page_height = Twips(16838)
+ section.top_margin = Cm(2.5)
+ section.bottom_margin = Cm(2.5)
+ section.left_margin = Cm(2.5)
+ section.right_margin = Cm(2.5)
+ section.header_distance = Cm(1.27)
+ section.footer_distance = Cm(1.27)
+
+ # Header
+ header = section.header
+ header.is_linked_to_previous = False
+ hp = header.paragraphs[0]
+ hp.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = hp.add_run('大连科技学院2026届本科毕业设计(论文)')
+ set_run_font(run, '宋体', 'Times New Roman', Pt(9), bold=False)
+ # Add bottom border to header paragraph
+ pPr = hp._element.find(qn('w:pPr'))
+ if pPr is None:
+ pPr = parse_xml(f'')
+ hp._element.insert(0, pPr)
+ pBdr = parse_xml(
+ f''
+ ''
+ ''
+ )
+ pPr.append(pBdr)
+
+ # Footer with page number
+ footer = section.footer
+ footer.is_linked_to_previous = False
+ fp = footer.paragraphs[0]
+ fp.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ # Add page number field
+ run = fp.add_run()
+ fldChar1 = parse_xml(f'')
+ run._element.append(fldChar1)
+ run2 = fp.add_run()
+ instrText = parse_xml(f' PAGE ')
+ run2._element.append(instrText)
+ run3 = fp.add_run()
+ fldChar2 = parse_xml(f'')
+ run3._element.append(fldChar2)
+ set_run_font(run, '宋体', 'Times New Roman', Pt(9))
+ set_run_font(run2, '宋体', 'Times New Roman', Pt(9))
+ set_run_font(run3, '宋体', 'Times New Roman', Pt(9))
+
+
+def add_cover_page(doc):
+ """Add the thesis cover page."""
+ # Blank lines for spacing
+ for _ in range(3):
+ p = doc.add_paragraph()
+ set_paragraph_spacing(p, line_spacing=360)
+
+ # University name
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run('大连科技学院')
+ set_run_font(run, '黑体', 'Times New Roman', Pt(26), bold=True)
+ set_paragraph_spacing(p, line_spacing=360)
+
+ # Thesis type
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run('毕业设计(论文)')
+ set_run_font(run, '黑体', 'Times New Roman', Pt(26), bold=True)
+ set_paragraph_spacing(p, line_spacing=360, after=600)
+
+ # Title
+ for _ in range(2):
+ p = doc.add_paragraph()
+ set_paragraph_spacing(p, line_spacing=360)
+
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run('论文题目:基于Spring Boot的养老院管理系统的设计与实现')
+ set_run_font(run, '黑体', 'Times New Roman', Pt(16), bold=True)
+ set_paragraph_spacing(p, line_spacing=480)
+
+ # Blank lines
+ for _ in range(4):
+ p = doc.add_paragraph()
+ set_paragraph_spacing(p, line_spacing=360)
+
+ # Info fields
+ info_fields = [
+ ('学 院:', '网络与通信学院'),
+ ('专 业:', '网络工程'),
+ ('学 号:', ' '),
+ ('学生姓名:', ' '),
+ ('指导教师:', ' '),
+ ]
+ for label, value in info_fields:
+ p = doc.add_paragraph()
+ p.alignment = WD_ALIGN_PARAGRAPH.CENTER
+ run = p.add_run(label)
+ set_run_font(run, '宋体', 'Times New Roman', Pt(14), bold=False)
+ run2 = p.add_run(value)
+ set_run_font(run2, '宋体', 'Times New Roman', Pt(14), bold=False)
+ # Add underline to value
+ run2.font.underline = True
+ set_paragraph_spacing(p, line_spacing=480)
+
+ # Page break
+ doc.add_page_break()
+
+
+def parse_markdown_files():
+ """Parse the 4 thesis markdown files and return structured content."""
+ files = [
+ os.path.join(THESIS_DIR, '论文.md'),
+ os.path.join(THESIS_DIR, 'chapter3.md'),
+ os.path.join(THESIS_DIR, 'chapter4.md'),
+ os.path.join(THESIS_DIR, 'chapter5_6_7.md'),
+ ]
+
+ content = []
+ for f in files:
+ with open(f, 'r', encoding='utf-8') as fh:
+ content.append(fh.read())
+
+ return '\n\n'.join(content)
+
+
+def process_markdown(doc, md_text):
+ """Process markdown text and add to document with proper formatting."""
+ lines = md_text.split('\n')
+ i = 0
+ in_table = False
+ table_headers = []
+ table_rows = []
+ skip_toc = False
+
+ while i < len(lines):
+ line = lines[i].rstrip()
+
+ # Skip empty lines
+ if not line.strip():
+ i += 1
+ continue
+
+ # Skip the TOC section
+ if line.strip() == '## 目录':
+ skip_toc = True
+ i += 1
+ continue
+ if skip_toc:
+ if line.startswith('# ') or line.startswith('## 摘要'):
+ skip_toc = False
+ else:
+ i += 1
+ continue
+
+ # Main title (skip - already on cover page)
+ if line.startswith('# 基于') or line.startswith('# 第'):
+ text = line.lstrip('# ').strip()
+ if '第' in text and '章' in text:
+ add_heading_chapter(doc, text)
+ i += 1
+ continue
+
+ # 摘要 / Abstract title
+ if line.strip() == '## 摘要':
+ add_title(doc, '摘 要')
+ i += 1
+ continue
+ if line.strip() == '## Abstract':
+ doc.add_page_break()
+ add_title(doc, 'Abstract')
+ i += 1
+ continue
+
+ # Keywords line
+ if line.startswith('关键词:') or line.startswith('关键词:'):
+ p = doc.add_paragraph()
+ run = p.add_run('关键词:')
+ set_run_font(run, '黑体', 'Times New Roman', Pt(12), bold=True)
+ run2 = p.add_run(line.split(':', 1)[1] if ':' in line else line.split(':', 1)[1])
+ set_run_font(run2, '宋体', 'Times New Roman', Pt(12))
+ set_paragraph_spacing(p, line_spacing=360)
+ i += 1
+ continue
+ if line.startswith('Keywords:') or line.startswith('Key words:'):
+ p = doc.add_paragraph()
+ run = p.add_run('Key words: ')
+ set_run_font(run, 'Times New Roman', 'Times New Roman', Pt(12), bold=True)
+ kw_text = line.split(':', 1)[1].strip() if ':' in line else ''
+ run2 = p.add_run(kw_text)
+ set_run_font(run2, 'Times New Roman', 'Times New Roman', Pt(12))
+ set_paragraph_spacing(p, line_spacing=360)
+ # Page break after English abstract keywords
+ doc.add_page_break()
+ i += 1
+ continue
+
+ # Section headings
+ if line.startswith('## '):
+ text = line[3:].strip()
+ # Check if it's a special section
+ if text in ['参考文献']:
+ doc.add_page_break()
+ add_heading_chapter(doc, text)
+ elif text in ['致谢']:
+ doc.add_page_break()
+ add_heading_chapter(doc, '致 谢')
+ else:
+ add_heading_section(doc, text)
+ i += 1
+ continue
+
+ # Subsection headings
+ if line.startswith('### '):
+ text = line[4:].strip()
+ add_heading_subsection(doc, text)
+ i += 1
+ continue
+
+ # Image
+ img_match = re.match(r'!\[(.+?)\]\((.+?)\)', line)
+ if img_match:
+ alt_text = img_match.group(1)
+ img_path = img_match.group(2)
+ full_path = os.path.join(THESIS_DIR, img_path)
+ add_image(doc, full_path)
+ i += 1
+ continue
+
+ # Figure/table caption (line like "图4.1 xxx" or "表4.1 xxx")
+ if re.match(r'^(图|表)\d+\.\d+', line.strip()):
+ add_caption(doc, line.strip())
+ i += 1
+ continue
+
+ # Table detection
+ if '|' in line and line.strip().startswith('|'):
+ # Parse table
+ if not in_table:
+ in_table = True
+ # Parse header
+ cells = [c.strip() for c in line.strip().strip('|').split('|')]
+ table_headers = cells
+ i += 1
+ # Skip separator line
+ if i < len(lines) and '---' in lines[i]:
+ i += 1
+ table_rows = []
+ continue
+ else:
+ cells = [c.strip() for c in line.strip().strip('|').split('|')]
+ table_rows.append(cells)
+ i += 1
+ # Check if next line is still table
+ if i >= len(lines) or not lines[i].strip().startswith('|'):
+ in_table = False
+ add_table_from_md(doc, table_headers, table_rows)
+ table_headers = []
+ table_rows = []
+ continue
+
+ # Reference items [1], [2], etc.
+ ref_match = re.match(r'^\[(\d+)\]\s*(.+)', line.strip())
+ if ref_match:
+ p = doc.add_paragraph()
+ run = p.add_run(line.strip())
+ set_run_font(run, '宋体', 'Times New Roman', Pt(10.5))
+ set_paragraph_spacing(p, line_spacing=360)
+ i += 1
+ continue
+
+ # Numbered items like (1), (2)
+ num_match = re.match(r'^(\d+)', line.strip())
+ if num_match:
+ add_body_paragraph(doc, line.strip(), first_line_indent=True)
+ i += 1
+ continue
+
+ # Normal body text
+ if line.strip():
+ add_body_paragraph(doc, line.strip(), first_line_indent=True)
+
+ i += 1
+
+
+def main():
+ doc = Document()
+
+ # Setup page
+ setup_page(doc)
+
+ # Cover page
+ add_cover_page(doc)
+
+ # Parse and process markdown
+ md_text = parse_markdown_files()
+ process_markdown(doc, md_text)
+
+ # Save
+ output_path = os.path.join(THESIS_DIR, '基于Spring Boot的养老院管理系统的设计与实现.docx')
+ doc.save(output_path)
+ print(f'Thesis saved to: {output_path}')
+ print(f'File size: {os.path.getsize(output_path) / 1024:.1f} KB')
+
+
+if __name__ == '__main__':
+ main()
diff --git a/thesis/screenshots/admin_bills.png b/thesis/screenshots/admin_bills.png
new file mode 100644
index 0000000..45624b1
Binary files /dev/null and b/thesis/screenshots/admin_bills.png differ
diff --git a/thesis/screenshots/admin_dashboard.png b/thesis/screenshots/admin_dashboard.png
new file mode 100644
index 0000000..d0c1f10
Binary files /dev/null and b/thesis/screenshots/admin_dashboard.png differ
diff --git a/thesis/screenshots/admin_elders.png b/thesis/screenshots/admin_elders.png
new file mode 100644
index 0000000..d828aa4
Binary files /dev/null and b/thesis/screenshots/admin_elders.png differ
diff --git a/thesis/screenshots/admin_feedback.png b/thesis/screenshots/admin_feedback.png
new file mode 100644
index 0000000..2f4dc8f
Binary files /dev/null and b/thesis/screenshots/admin_feedback.png differ
diff --git a/thesis/screenshots/admin_notices.png b/thesis/screenshots/admin_notices.png
new file mode 100644
index 0000000..6a5a939
Binary files /dev/null and b/thesis/screenshots/admin_notices.png differ
diff --git a/thesis/screenshots/admin_schedules.png b/thesis/screenshots/admin_schedules.png
new file mode 100644
index 0000000..8e83975
Binary files /dev/null and b/thesis/screenshots/admin_schedules.png differ
diff --git a/thesis/screenshots/admin_users.png b/thesis/screenshots/admin_users.png
new file mode 100644
index 0000000..fd1df87
Binary files /dev/null and b/thesis/screenshots/admin_users.png differ
diff --git a/thesis/screenshots/family_bills.png b/thesis/screenshots/family_bills.png
new file mode 100644
index 0000000..1407aaa
Binary files /dev/null and b/thesis/screenshots/family_bills.png differ
diff --git a/thesis/screenshots/family_care.png b/thesis/screenshots/family_care.png
new file mode 100644
index 0000000..90ef4c8
Binary files /dev/null and b/thesis/screenshots/family_care.png differ
diff --git a/thesis/screenshots/family_elders.png b/thesis/screenshots/family_elders.png
new file mode 100644
index 0000000..433159e
Binary files /dev/null and b/thesis/screenshots/family_elders.png differ
diff --git a/thesis/screenshots/family_feedback.png b/thesis/screenshots/family_feedback.png
new file mode 100644
index 0000000..0fa6fff
Binary files /dev/null and b/thesis/screenshots/family_feedback.png differ
diff --git a/thesis/screenshots/family_health.png b/thesis/screenshots/family_health.png
new file mode 100644
index 0000000..c623e5a
Binary files /dev/null and b/thesis/screenshots/family_health.png differ
diff --git a/thesis/screenshots/login.png b/thesis/screenshots/login.png
new file mode 100644
index 0000000..707d3ae
Binary files /dev/null and b/thesis/screenshots/login.png differ
diff --git a/thesis/screenshots/nurse_care.png b/thesis/screenshots/nurse_care.png
new file mode 100644
index 0000000..9d28078
Binary files /dev/null and b/thesis/screenshots/nurse_care.png differ
diff --git a/thesis/screenshots/nurse_handovers.png b/thesis/screenshots/nurse_handovers.png
new file mode 100644
index 0000000..c72e1bc
Binary files /dev/null and b/thesis/screenshots/nurse_handovers.png differ
diff --git a/thesis/screenshots/nurse_health.png b/thesis/screenshots/nurse_health.png
new file mode 100644
index 0000000..ea0fc33
Binary files /dev/null and b/thesis/screenshots/nurse_health.png differ
diff --git a/thesis/screenshots/nurse_schedules.png b/thesis/screenshots/nurse_schedules.png
new file mode 100644
index 0000000..35127b0
Binary files /dev/null and b/thesis/screenshots/nurse_schedules.png differ
diff --git a/thesis/基于Spring Boot的养老院管理系统的设计与实现.docx b/thesis/基于Spring Boot的养老院管理系统的设计与实现.docx
new file mode 100644
index 0000000..c77a8d7
Binary files /dev/null and b/thesis/基于Spring Boot的养老院管理系统的设计与实现.docx differ
diff --git a/thesis/毕业论文_完整版.md b/thesis/毕业论文_完整版.md
new file mode 100644
index 0000000..2dd2abf
--- /dev/null
+++ b/thesis/毕业论文_完整版.md
@@ -0,0 +1,945 @@
+# 基于Spring Boot的养老院管理系统的设计与实现
+
+## 摘要
+
+随着我国人口老龄化进程的不断加快,养老服务需求日益增长,传统的养老院管理模式已难以满足现代化管理的要求。本文针对养老院日常运营管理中存在的信息化程度低、管理效率不高等问题,设计并实现了一套基于Spring Boot的养老院管理系统。该系统采用前后端分离的B/S架构,后端基于Spring Boot 3框架,使用MyBatis作为持久层框架,MySQL作为数据库,Sa-Token实现身份认证与权限控制;前端采用Vue 2框架结合Element UI组件库构建用户界面。系统面向管理员、护工和家属三类用户角色,实现了长者档案管理、护工排班管理、护理记录管理、健康监测记录、交班记录管理、账单管理与在线支付、服务反馈处理以及通知公告等核心功能模块。本文从系统需求分析、系统设计、数据库设计、系统实现和系统测试等方面对该系统进行了详细阐述。测试结果表明,该系统功能完善、运行稳定,能够有效提升养老院的信息化管理水平和服务质量。
+
+关键词:养老院管理系统;Spring Boot;Vue;前后端分离;B/S架构
+
+## Abstract
+
+With the accelerating aging of China's population, the demand for elderly care services is growing rapidly. Traditional nursing home management models can no longer meet the requirements of modern management. This thesis addresses the problems of low informatization and inefficient management in daily nursing home operations by designing and implementing a nursing home management system based on Spring Boot. The system adopts a front-end and back-end separated B/S architecture. The back-end is built on the Spring Boot 3 framework, using MyBatis as the persistence layer framework, MySQL as the database, and Sa-Token for authentication and authorization. The front-end uses the Vue 2 framework combined with the Element UI component library. The system serves three user roles: administrators, nurses, and family members, implementing core functional modules including elder profile management, nurse scheduling, care record management, health monitoring records, shift handover management, billing and online payment, service feedback processing, and notice management. This thesis provides a detailed description of the system from the perspectives of requirements analysis, system design, database design, system implementation, and system testing. Test results show that the system is fully functional and runs stably, effectively improving the informatization management level and service quality of nursing homes.
+
+Keywords: Nursing Home Management System; Spring Boot; Vue; Front-end and Back-end Separation; B/S Architecture
+
+## 目录
+
+第1章 绪论
+第2章 主要技术和框架
+第3章 养老院管理系统的系统分析
+第4章 养老院管理系统的系统设计
+第5章 养老院管理系统的系统实现
+第6章 养老院管理系统的系统测试
+第7章 结论
+参考文献
+致谢
+
+# 第1章 绪论
+
+## 1.1 课题来源及意义
+
+随着我国经济社会的快速发展和医疗卫生条件的持续改善,人均寿命不断延长,人口老龄化问题日益突出。根据国家统计局发布的数据,截至2024年底,我国60岁及以上老年人口已超过2.97亿,占总人口的比重超过21%,标志着我国已正式进入中度老龄化社会。预计到2035年,老年人口将突破4亿,届时每3个人中就有1位老年人。面对如此庞大的老年群体,养老服务体系的建设和完善成为关系国计民生的重大课题。
+
+养老院作为机构养老的重要载体,承担着为失能、半失能及高龄老人提供专业化照护服务的重要职责。然而,当前我国大量养老机构仍然采用传统的手工记录和纸质档案管理方式,存在信息记录不完整、数据查询困难、工作流程繁琐、家属沟通不畅等诸多问题。这些问题不仅降低了养老机构的管理效率,也影响了老年人的服务体验和生活质量。
+
+在此背景下,利用现代信息技术手段,开发一套功能完善、操作便捷的养老院管理系统,对于提升养老机构的管理水平和服务质量具有重要的现实意义。本课题来源于对养老行业信息化建设需求的深入调研,旨在通过构建一个集长者档案管理、护理服务记录、健康监测、排班管理、费用结算和家属互动于一体的综合管理平台,为养老机构的数字化转型提供技术支撑。
+
+本课题的研究意义主要体现在以下几个方面:第一,通过信息化手段实现养老院日常管理的规范化和标准化,减少人工操作失误,提高管理效率;第二,建立完善的长者健康档案和护理记录体系,为老年人的健康管理提供数据支持;第三,搭建家属与养老机构之间的信息沟通桥梁,使家属能够及时了解老人的生活和健康状况,增强家属的信任感和满意度;第四,为养老机构的运营决策提供数据分析支持,促进养老服务行业的高质量发展。
+
+## 1.2 课题研究现状
+
+近年来,随着"互联网+养老"理念的深入推进,国内外学者和企业在养老信息化领域开展了大量的研究和实践工作。
+
+在国外,发达国家的养老信息化建设起步较早,已形成较为成熟的体系。美国的养老机构普遍采用电子健康记录(EHR)系统,实现了老年人健康数据的数字化管理和跨机构共享。日本作为全球老龄化程度最高的国家之一,在智慧养老领域投入了大量资源,开发了多种基于物联网和人工智能技术的养老服务系统,如智能健康监测设备、远程医疗平台等。欧洲各国也在积极推进养老服务的数字化转型,通过建立统一的养老服务信息平台,实现了养老资源的优化配置和服务质量的持续改进。
+
+在国内,养老信息化建设虽然起步相对较晚,但发展势头迅猛。政府层面,国务院先后出台了《关于推进养老服务发展的意见》《"十四五"国家老龄事业发展和养老服务体系规划》等政策文件,明确提出要加快养老服务领域的信息化建设。技术层面,基于Java EE、Spring Boot等技术框架的养老管理系统已有较多研究成果。例如,部分学者提出了基于SSM(Spring+SpringMVC+MyBatis)框架的养老院管理系统方案,实现了老人信息管理、护理服务管理等基本功能。也有研究者采用微服务架构,构建了可扩展的智慧养老服务平台。在商业领域,一些企业推出了面向养老机构的SaaS化管理平台,提供了从入住管理到费用结算的全流程解决方案。
+
+然而,现有的养老院管理系统仍存在一些不足之处:部分系统功能单一,仅关注某一方面的管理需求,缺乏系统性和完整性;部分系统的用户界面设计不够友好,操作复杂,不利于非技术人员使用;部分系统缺乏对家属端的支持,无法满足家属远程了解老人状况的需求;部分系统的技术架构较为陈旧,难以适应快速变化的业务需求。
+
+## 1.3 当前存在的问题
+
+通过对多家养老机构的实地调研和对现有养老管理系统的分析,本文总结出当前养老院管理中存在的主要问题如下:
+
+(1)信息管理手段落后。许多养老机构仍然依赖纸质档案和Excel表格进行日常管理,长者的基本信息、健康数据、护理记录等分散在不同的文件和表格中,数据的录入、查询和统计工作耗时费力,且容易出现数据丢失和不一致的情况。
+
+(2)护理服务记录不规范。护工的日常护理工作缺乏标准化的记录流程,护理内容、时间、责任人等关键信息记录不完整,导致护理服务质量难以追溯和评估。同时,护工之间的交班信息传递主要依靠口头沟通,容易造成信息遗漏。
+
+(3)健康监测数据管理薄弱。老年人的体温、血压、心率等日常健康监测数据缺乏系统化的记录和管理手段,无法形成连续的健康趋势分析,不利于及时发现老年人的健康异常情况。
+
+(4)家属沟通渠道不畅。家属了解老人在养老院的生活和健康状况主要依靠电话询问或实地探访,信息获取不及时、不全面。家属对养老服务的意见和建议也缺乏有效的反馈渠道。
+
+(5)财务管理效率低下。养老院的费用计算涉及床位费、护理费、餐饮费等多个项目,手工计算容易出错。缴费方式单一,家属需要到院缴费,不够便捷。
+
+## 1.4 课题研究目标
+
+针对上述问题,本课题的研究目标是设计并实现一套功能完善、操作便捷、安全可靠的养老院管理系统。具体目标包括:
+
+(1)建立完善的长者电子档案管理体系,实现长者基本信息、入住信息、护理等级等数据的数字化管理,支持信息的快速录入、查询和修改。
+
+(2)构建标准化的护理服务记录系统,支持护工在线记录每日护理内容,支持附件上传,实现护理服务的全程可追溯。
+
+(3)实现健康监测数据的系统化管理,支持体温、血压、心率等体征数据的录入和查询,为老年人的健康管理提供数据支撑。
+
+(4)开发护工排班管理功能,支持管理员按日期和班次进行排班,护工可在线查看个人排班信息,提高排班管理的效率和透明度。
+
+(5)实现账单管理和在线支付功能,支持管理员按月生成费用账单,家属可在线查看账单明细并完成支付,简化缴费流程。
+
+(6)搭建家属与养老机构之间的信息互动平台,家属可远程查看老人的护理记录、健康数据和费用信息,并可在线提交服务反馈和建议。
+
+(7)实现通知公告管理功能,支持管理员向不同角色发布通知信息,确保重要信息的及时传达。
+
+(8)采用前后端分离的技术架构,确保系统具有良好的可维护性和可扩展性,为后续功能升级奠定基础。
+
+# 第2章 主要技术和框架
+
+## 2.1 主要技术
+
+### 2.1.1 Java语言
+
+Java是一种面向对象的高级编程语言,由Sun Microsystems公司于1995年推出,现由Oracle公司维护。Java语言具有跨平台性、面向对象、安全性高、多线程支持等特点,是目前企业级应用开发中使用最为广泛的编程语言之一。本系统后端开发采用Java 17版本,该版本是Java的长期支持(LTS)版本,提供了更好的性能优化和语言特性支持。Java语言丰富的类库和成熟的生态系统为本系统的开发提供了坚实的技术基础。
+
+### 2.1.2 JavaScript语言
+
+JavaScript是一种轻量级的解释型脚本语言,最初被设计用于网页的客户端交互,现已发展成为一种功能强大的全栈开发语言。JavaScript具有动态类型、基于原型的面向对象、函数式编程等特性。在本系统中,JavaScript主要用于前端页面的交互逻辑开发,配合Vue框架实现了丰富的用户界面交互效果。
+
+### 2.1.3 MySQL数据库
+
+MySQL是一款开源的关系型数据库管理系统,由瑞典MySQL AB公司开发,现属于Oracle公司。MySQL以其高性能、高可靠性、易用性和低成本等优势,成为全球最受欢迎的开源数据库之一。MySQL支持标准的SQL语言,提供了完善的事务处理、索引优化、数据备份与恢复等功能。本系统采用MySQL作为数据存储方案,数据库字符集设置为utf8mb4,以支持中文字符和特殊字符的存储。
+
+### 2.1.4 HTML5与CSS3
+
+HTML5是超文本标记语言的第五个主要版本,提供了更丰富的语义化标签和多媒体支持能力。CSS3是层叠样式表的最新版本,引入了圆角、阴影、渐变、动画等新特性,使网页的视觉表现更加丰富。在本系统中,HTML5和CSS3用于构建前端页面的结构和样式,配合Element UI组件库实现了美观、统一的用户界面。
+
+## 2.2 框架和开发模式
+
+### 2.2.1 Spring Boot框架
+
+Spring Boot是由Pivotal团队开发的基于Spring框架的快速开发框架,旨在简化Spring应用的初始搭建和开发过程。Spring Boot通过自动配置、起步依赖和内嵌服务器等特性,大幅降低了Spring应用的配置复杂度。本系统采用Spring Boot 3.2.5版本,该版本基于Spring Framework 6,要求Java 17及以上版本,支持Jakarta EE 10规范。Spring Boot的核心优势包括:自动配置机制减少了大量的XML配置文件;起步依赖简化了Maven依赖管理;内嵌Tomcat服务器使应用可以独立运行;Actuator模块提供了应用监控和管理功能。
+
+### 2.2.2 MyBatis持久层框架
+
+MyBatis是一款优秀的半自动化ORM(对象关系映射)持久层框架,它支持自定义SQL、存储过程以及高级映射。与全自动化的ORM框架(如Hibernate)不同,MyBatis允许开发者直接编写SQL语句,在保持灵活性的同时提供了对象与数据库表之间的映射功能。本系统使用MyBatis Spring Boot Starter 3.0.3版本,通过注解方式定义SQL映射,配合MyBatis的驼峰命名自动转换功能(map-underscore-to-camel-case),实现了Java实体类属性与数据库字段之间的自动映射。
+
+### 2.2.3 Sa-Token认证框架
+
+Sa-Token是一款国产的轻量级Java权限认证框架,主要解决登录认证、权限验证、Session会话管理、单点登录等安全相关问题。相比Spring Security等重量级安全框架,Sa-Token具有API设计简洁、学习成本低、功能丰富等优点。本系统采用Sa-Token 1.37.0版本,使用UUID风格的Token,配置了86400秒(24小时)的Token有效期,支持同端多人登录和Token共享。通过@SaCheckRole注解实现了基于角色的访问控制,确保不同角色的用户只能访问其权限范围内的功能。
+
+### 2.2.4 Vue前端框架
+
+Vue是一款用于构建用户界面的渐进式JavaScript框架,由尤雨溪于2014年创建。Vue的核心特性包括响应式数据绑定、组件化开发、虚拟DOM、指令系统等。本系统采用Vue 2.7版本,结合Vue Router实现了前端路由管理,通过Axios库实现了与后端API的HTTP通信。Vue的组件化开发模式使得前端代码结构清晰、复用性高,有效提升了开发效率。
+
+### 2.2.5 Element UI组件库
+
+Element UI是由饿了么前端团队开发的一套基于Vue 2的桌面端UI组件库,提供了丰富的预制组件,包括表格、表单、对话框、导航菜单、日期选择器等。Element UI遵循一致的设计规范,组件风格统一、交互友好,能够帮助开发者快速构建美观、专业的管理后台界面。本系统使用Element UI 2.15版本,充分利用了其提供的布局容器、数据表格、表单验证等组件,大幅减少了前端界面的开发工作量。
+
+### 2.2.6 前后端分离开发模式
+
+本系统采用前后端分离的开发模式,前端和后端作为两个独立的项目进行开发和部署。后端通过RESTful API向前端提供数据服务,前端通过HTTP请求调用后端接口获取数据并渲染页面。这种开发模式的优势在于:前后端可以并行开发,提高开发效率;前后端通过标准化的API接口进行通信,降低了耦合度;前端可以独立部署和更新,不影响后端服务;便于后续扩展移动端等多终端应用。在开发阶段,前端通过Vue CLI的代理配置将API请求转发到后端服务器,实现了前后端的无缝对接。
+
+# 第3章 养老院管理系统的系统分析
+
+## 3.1 需求分析
+
+### 3.1.1 功能需求分析
+
+通过对养老院日常运营管理流程的深入调研和分析,本系统的功能需求可从管理员、护工和家属三个角色维度进行梳理。
+
+(1)管理员功能需求
+
+管理员是系统的核心管理角色,负责养老院的全面运营管理工作。管理员的功能需求包括:运营数据概览,能够实时查看在住长者数量、护工数量、家属数量和累计收入等关键运营指标;账号管理,能够创建、编辑护工和家属账号,重置用户密码,启用或禁用账号;长者档案管理,能够录入、修改和删除长者的基本信息,包括姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级等;排班管理,能够按日期和班次为护工安排工作任务,支持排班的创建、修改和删除;账单管理,能够按月为长者生成费用账单,包含床位费、护理费、餐饮费和其他费用,支持账单的编辑和删除;反馈处理,能够查看家属提交的服务反馈,并进行回复和状态更新;通知公告管理,能够发布面向不同角色的通知信息。
+
+(2)护工功能需求
+
+护工是养老院一线服务人员,负责长者的日常护理工作。护工的功能需求包括:查看个人排班信息,能够按日期查看自己的班次安排和工作任务;护理记录管理,能够在线记录每次护理服务的内容,支持上传图片等附件作为护理凭证;健康监测记录,能够录入长者的日常体征数据,包括体温、收缩压、舒张压、心率等指标,并添加备注说明;交班记录管理,能够在换班时记录当班期间的重要事项和注意事项,确保信息的有效传递;查看通知,能够接收管理员发布的工作通知和培训安排。
+
+(3)家属功能需求
+
+家属是养老院服务的间接受益者,关注老人在院的生活和健康状况。家属的功能需求包括:查看亲人档案,能够查看与自己关联的长者的基本信息;查看护理记录,能够远程了解老人每日的护理服务内容;查看健康记录,能够查看老人的体征监测数据,及时了解老人的健康状况;账单查看与支付,能够查看老人的月度费用账单明细,并通过在线方式完成支付;服务反馈,能够对养老院的服务提出意见、建议或投诉,并查看管理员的回复;查看通知,能够接收养老院发布的探视时间调整等通知信息。
+
+### 3.1.2 性能需求分析
+
+除功能需求外,本系统还需满足以下性能需求:
+
+(1)响应时间:系统页面的加载时间应控制在3秒以内,数据查询操作的响应时间应控制在2秒以内,确保用户获得流畅的使用体验。
+
+(2)并发处理能力:系统应能够支持至少50个用户同时在线操作,在高峰时段不出现明显的性能下降。
+
+(3)数据安全性:用户密码应采用加密存储,系统应实现基于角色的访问控制,防止未授权的数据访问。Token应设置合理的有效期,过期后需重新登录。
+
+(4)数据完整性:系统应确保数据的一致性和完整性,关键操作应进行数据验证,防止无效数据的录入。
+
+(5)可用性:系统应具有良好的容错能力,在出现异常情况时能够给出友好的错误提示,不影响系统的整体运行。
+
+## 3.2 可行性分析
+
+### 3.2.1 技术可行性
+
+本系统采用的技术栈均为当前主流的成熟技术。后端采用Spring Boot 3框架,该框架经过多年的发展和迭代,已被广泛应用于各类企业级项目中,具有完善的文档支持和活跃的社区生态。MyBatis作为持久层框架,提供了灵活的SQL映射能力,能够满足各种复杂的数据库操作需求。MySQL数据库性能稳定、运维成本低,完全能够满足本系统的数据存储需求。前端采用Vue 2框架和Element UI组件库,两者的结合已成为管理后台开发的标准方案,拥有丰富的组件和完善的文档。Sa-Token认证框架轻量高效,能够快速实现系统的安全认证需求。综上所述,本系统在技术层面完全可行。
+
+### 3.2.2 操作可行性
+
+本系统采用B/S架构,用户只需通过浏览器即可访问系统,无需安装额外的客户端软件,降低了使用门槛。系统界面采用Element UI组件库构建,风格统一、布局清晰、操作直观,符合用户的使用习惯。系统针对不同角色设计了差异化的功能菜单,用户登录后只能看到与自己角色相关的功能模块,避免了功能冗余带来的困扰。对于管理员和护工等专业用户,系统提供了表格化的数据展示和表单化的数据录入方式,操作流程简洁明了。对于家属用户,系统提供了简洁的信息查看界面和便捷的在线支付功能。因此,本系统在操作层面具有良好的可行性。
+
+### 3.2.3 经济可行性
+
+本系统的开发和运行成本较低。开发工具方面,系统采用的Spring Boot、Vue、MySQL、MyBatis等技术框架均为开源免费软件,无需支付许可费用。开发环境方面,使用IntelliJ IDEA或VS Code等开发工具即可完成开发工作。部署方面,系统可以部署在普通的云服务器上,一台配置为2核4GB内存的云服务器即可满足中小型养老机构的使用需求,年度服务器费用在数千元以内。与购买商业化养老管理软件相比,自主开发的系统不仅成本更低,还可以根据养老机构的实际需求进行定制化开发。因此,本系统在经济层面具有明显的可行性优势。
+
+### 3.2.4 社会可行性
+
+养老服务信息化建设是国家政策大力支持的方向。国务院和各级地方政府多次发文要求加快养老服务领域的信息化建设,推动"互联网+养老"的发展。本系统的开发符合国家政策导向,有助于提升养老机构的管理水平和服务质量,满足老年人及其家属对高质量养老服务的需求。同时,系统的推广应用有助于推动养老行业的数字化转型,促进养老服务行业的健康发展。因此,本系统在社会层面具有良好的可行性和积极的社会意义。
+
+## 3.3 用例图
+
+### 3.3.1 管理员用例图
+
+管理员是系统的最高权限角色,拥有系统的全面管理功能。管理员登录系统后,可以进行运营概览查看、账号管理、长者档案管理、排班管理、账单管理、反馈处理和通知公告管理等操作。其中,账号管理包含添加账号、编辑账号和重置密码三个子用例;长者档案管理包含添加长者、编辑长者信息和删除长者三个子用例。管理员用例图如图3.1所示。
+
+
+
+图3.1 管理员用例图
+
+### 3.3.2 护工用例图
+
+护工是系统的一线操作角色,主要负责长者的日常护理和健康监测工作。护工登录系统后,可以进行查看排班、护理记录管理、健康监测记录、交班记录管理和查看通知等操作。其中,护理记录管理包含添加护理记录和上传附件两个子用例;健康监测记录包含记录体征数据子用例;交班记录管理包含添加交班记录子用例。护工用例图如图3.2所示。
+
+
+
+图3.2 护工用例图
+
+### 3.3.3 家属用例图
+
+家属是系统的信息查看和服务反馈角色,主要通过系统了解老人在养老院的生活和健康状况。家属登录系统后,可以进行查看亲人档案、查看护理记录、查看健康记录、账单支付、服务反馈和查看通知等操作。其中,账单支付包含查看账单明细和在线支付两个子用例;服务反馈包含提交反馈和查看反馈回复两个子用例。家属用例图如图3.3所示。
+
+
+
+图3.3 家属用例图
+
+## 3.4 用例描述
+
+### 3.4.1 管理员管理长者档案用例描述
+
+管理员管理长者档案用例描述如表3.1所示。
+
+表3.1 管理员管理长者档案用例描述
+
+| 项目 | 描述 |
+|------|------|
+| 用例名称 | 管理长者档案 |
+| 执行者 | 管理员 |
+| 简要说明 | 管理员对养老院长者的基本信息进行添加、修改、删除等管理操作 |
+| 前置条件 | 管理员已登录系统 |
+| 基本事件流 | 1. 管理员登录系统,进入长者档案管理页面;2. 系统显示已有长者列表,包含姓名、性别、身份证号、房间号、护理等级、状态等信息;3. 管理员点击"添加长者"按钮,在弹出的表单中输入长者的详细信息,包括姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级、状态和备注,提交后系统验证数据并保存;4. 若需修改长者信息,管理员点击对应长者的"编辑"按钮,修改相关信息后提交保存;5. 若需删除长者记录,管理员点击"删除"按钮,确认后系统移除该长者记录 |
+| 后置条件 | 长者档案信息更新成功,数据库中的数据保持一致 |
+
+### 3.4.2 护工添加护理记录用例描述
+
+护工添加护理记录用例描述如表3.2所示。
+
+表3.2 护工添加护理记录用例描述
+
+| 项目 | 描述 |
+|------|------|
+| 用例名称 | 添加护理记录 |
+| 执行者 | 护工 |
+| 简要说明 | 护工在完成护理服务后,在线记录护理内容并可上传附件 |
+| 前置条件 | 护工已登录系统 |
+| 基本事件流 | 1. 护工登录系统,进入护理记录页面;2. 护工选择被护理的长者;3. 护工填写护理内容,包括护理服务的具体描述;4. 护工可选择上传图片等附件作为护理凭证;5. 护工选择记录时间,默认为当前时间;6. 护工点击提交按钮,系统验证数据后保存护理记录;7. 系统提示添加成功,护理记录列表自动刷新 |
+| 后置条件 | 护理记录保存成功,家属可通过系统查看该记录 |
+
+### 3.4.3 家属在线支付账单用例描述
+
+家属在线支付账单用例描述如表3.3所示。
+
+表3.3 家属在线支付账单用例描述
+
+| 项目 | 描述 |
+|------|------|
+| 用例名称 | 在线支付账单 |
+| 执行者 | 家属 |
+| 简要说明 | 家属查看老人的月度费用账单并完成在线支付 |
+| 前置条件 | 家属已登录系统,且存在未支付的账单 |
+| 基本事件流 | 1. 家属登录系统,进入账单支付页面;2. 家属选择要查看账单的长者;3. 系统显示该长者的所有账单列表,包含月份、总金额和支付状态;4. 家属查看未支付账单的明细,包括床位费、护理费、餐饮费和其他费用;5. 家属点击"支付"按钮,选择支付方式;6. 系统处理支付请求,更新账单状态为已支付,记录支付信息;7. 系统提示支付成功 |
+| 后置条件 | 账单状态更新为已支付,生成对应的缴费记录 |
+
+## 3.5 系统性能分析
+
+本系统在性能方面进行了多维度的考量和优化设计。在数据库层面,对高频查询字段建立了索引,如护理记录表和健康记录表的elder_id字段、排班表的nurse_id和date组合字段等,有效提升了数据查询效率。在接口设计层面,采用RESTful风格的API设计,请求和响应数据采用JSON格式,数据传输量小、解析速度快。在安全性能方面,用户密码采用BCrypt算法进行加密存储,Token采用UUID格式生成,有效防止了密码泄露和Token伪造风险。在前端性能方面,Vue框架的虚拟DOM机制减少了不必要的页面重绘,Element UI组件的按需加载策略降低了前端资源的加载时间。系统整体架构采用前后端分离模式,前端静态资源可通过CDN加速分发,后端服务可通过水平扩展提升处理能力,具有良好的性能扩展空间。
+
+# 第4章 养老院管理系统的系统设计
+
+## 4.1 系统功能设计
+
+本系统面向管理员、护工和家属三类用户角色,各角色拥有不同的功能权限。管理员作为系统的最高权限角色,负责系统的全面运营管理,包括运营概览、账号管理、长者档案管理、排班管理、账单管理、反馈处理和通知公告管理七大功能模块。护工作为一线服务角色,拥有工作台、我的排班、护理记录、健康监测、交班记录和通知中心六大功能模块。家属作为信息查看角色,拥有家属首页、亲人档案、每日动态、健康记录、账单支付、服务反馈和通知中心七大功能模块。
+
+管理员功能结构图如图4.1所示。
+
+
+
+图4.1 管理员功能结构图
+
+护工功能结构图如图4.2所示。
+
+
+
+图4.2 护工功能结构图
+
+家属功能结构图如图4.3所示。
+
+
+
+图4.3 家属功能结构图
+
+## 4.2 类图
+
+本系统的数据模型采用关系型数据库设计,共包含11个数据实体,各实体之间通过外键关联形成完整的数据关系网络。系统类图采用IE Crow's Foot标记法展示各实体的属性和实体间的关系。核心实体包括用户表(sys_user)、长者表(elder)、家属长者关联表(family_elder)、排班表(schedule)、护理记录表(care_record)、健康记录表(health_record)、交班记录表(handover)、通知表(notice)、反馈表(feedback)、账单表(bill)和缴费记录表(payment_record)。
+
+主要的实体关系包括:用户(护工角色)与排班、护理记录、健康记录、交班记录之间为一对多关系;用户(家属角色)与长者之间通过家属长者关联表形成多对多关系;长者与护理记录、健康记录、账单、反馈之间为一对多关系;账单与缴费记录之间为一对多关系;用户(管理员角色)与通知之间为一对多关系。系统类图如图4.4所示。
+
+
+
+图4.4 系统类图
+
+## 4.3 序列图
+
+### 4.3.1 用户登录序列图
+
+用户登录过程涉及用户、系统前台、后台系统和数据库四个参与者之间的交互。具体步骤如下:
+
+(1)用户在浏览器中打开系统登录页面。
+
+(2)用户输入用户名和密码,点击登录按钮。
+
+(3)系统前台将登录请求发送至后台系统的认证接口(POST /api/auth/login)。
+
+(4)后台系统接收请求后,向数据库查询该用户名对应的用户信息。
+
+(5)数据库返回查询结果。
+
+(6)后台系统使用BCrypt算法验证用户输入的密码与数据库中存储的加密密码是否匹配。
+
+(7)验证通过后,后台系统调用Sa-Token框架生成UUID格式的Token。
+
+(8)后台系统将Token、用户角色和用户信息返回给系统前台。
+
+(9)系统前台将Token和角色信息存储到浏览器的localStorage中。
+
+(10)系统前台根据用户角色自动跳转到对应的功能首页。
+
+用户登录序列图如图4.5所示。
+
+
+
+图4.5 用户登录序列图
+
+### 4.3.2 护工添加护理记录序列图
+
+护工添加护理记录过程涉及护工、系统前台、后台系统和数据库四个参与者之间的交互。具体步骤如下:
+
+(1)护工在系统中进入护理记录页面。
+
+(2)系统前台向后台系统请求长者列表数据。
+
+(3)后台系统从数据库查询长者信息并返回。
+
+(4)系统前台展示长者列表供护工选择。
+
+(5)护工选择目标长者,填写护理内容,可选择上传附件。
+
+(6)系统前台将护理记录数据提交至后台系统(POST /api/nurse/care-records)。
+
+(7)后台系统自动关联当前登录护工的ID,设置记录时间,将数据插入数据库。
+
+(8)数据库返回插入结果。
+
+(9)后台系统将创建成功的响应返回给系统前台。
+
+(10)系统前台显示添加成功提示,并刷新护理记录列表。
+
+护工添加护理记录序列图如图4.6所示。
+
+
+
+图4.6 护工添加护理记录序列图
+
+## 4.4 活动图
+
+### 4.4.1 用户登录活动图
+
+用户登录过程可分为以下几步:
+
+(1)用户在登录页面输入用户名和密码。
+
+(2)系统前台将登录信息提交至后台系统。
+
+(3)后台系统向数据库查询用户数据。
+
+(4)数据库返回查询结果,后台系统判断用户是否存在以及密码是否正确。
+
+(5)若验证失败,系统返回错误提示,用户需重新输入。
+
+(6)若验证成功,后台系统生成Token并返回给前台。
+
+(7)前台存储Token信息,跳转至对应角色的系统首页。
+
+用户登录活动图如图4.7所示。
+
+
+
+图4.7 用户登录活动图
+
+### 4.4.2 管理员处理反馈活动图
+
+管理员处理反馈过程可分为以下几步:
+
+(1)管理员登录系统,进入反馈处理页面。
+
+(2)系统前台向后台系统请求所有反馈数据。
+
+(3)后台系统从数据库查询反馈列表并返回。
+
+(4)管理员查看反馈列表,选择需要处理的反馈。
+
+(5)管理员填写回复内容,更新反馈状态。
+
+(6)系统前台将回复信息提交至后台系统。
+
+(7)后台系统更新数据库中的反馈记录。
+
+(8)系统提示回复成功,反馈列表自动刷新。
+
+管理员处理反馈活动图如图4.8所示。
+
+
+
+图4.8 管理员处理反馈活动图
+
+## 4.5 数据库设计
+
+### 4.5.1 概念设计
+
+概念设计阶段采用E-R图(实体-关系图)描述系统的数据模型。本系统共包含11个实体,以下列举8个核心实体的属性图。
+
+(1)用户实体
+
+用户实体包含用户ID(主码)、用户名、密码、姓名、电话、角色和状态等属性。用户实体属性图如图4.9所示。
+
+
+
+图4.9 用户实体属性图
+
+(2)长者实体
+
+长者实体包含长者ID(主码)、姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级、状态和备注等属性。长者实体属性图如图4.10所示。
+
+
+
+图4.10 长者实体属性图
+
+(3)排班实体
+
+排班实体包含排班ID(主码)、护工ID、日期、班次和任务等属性。排班实体属性图如图4.11所示。
+
+
+
+图4.11 排班实体属性图
+
+(4)护理记录实体
+
+护理记录实体包含记录ID(主码)、长者ID、护工ID、内容、附件和记录时间等属性。护理记录实体属性图如图4.12所示。
+
+
+
+图4.12 护理记录实体属性图
+
+(5)健康记录实体
+
+健康记录实体包含记录ID(主码)、长者ID、护工ID、体温、收缩压、舒张压、心率、备注和记录时间等属性。健康记录实体属性图如图4.13所示。
+
+
+
+图4.13 健康记录实体属性图
+
+(6)账单实体
+
+账单实体包含账单ID(主码)、长者ID、月份、床位费、护理费、餐饮费、其他费用、总计和状态等属性。账单实体属性图如图4.14所示。
+
+
+
+图4.14 账单实体属性图
+
+(7)反馈实体
+
+反馈实体包含反馈ID(主码)、家属ID、长者ID、类型、内容、评分、状态和回复等属性。反馈实体属性图如图4.15所示。
+
+
+
+图4.15 反馈实体属性图
+
+(8)通知实体
+
+通知实体包含通知ID(主码)、标题、内容、目标角色、目标用户ID和创建者ID等属性。通知实体属性图如图4.16所示。
+
+
+
+图4.16 通知实体属性图
+
+系统总体E-R图展示了各实体之间的关联关系,如图4.17所示。
+
+
+
+图4.17 系统E-R图
+
+### 4.5.2 逻辑设计
+
+将E-R图中的实体关系转换为关系模式,具体如下:
+
+(1)用户表:(用户ID,用户名,密码,姓名,电话,角色,状态,创建时间,更新时间)
+
+(2)长者表:(长者ID,姓名,性别,身份证号,出生日期,房间号,入住日期,护理等级,状态,备注)
+
+(3)家属长者关联表:(关联ID,家属ID,长者ID,关系,创建时间)。外键:家属ID引用用户表,长者ID引用长者表。
+
+(4)排班表:(排班ID,护工ID,日期,班次,任务,创建时间,更新时间)。外键:护工ID引用用户表。
+
+(5)护理记录表:(记录ID,长者ID,护工ID,内容,附件URL,记录时间,创建时间)。外键:长者ID引用长者表,护工ID引用用户表。
+
+(6)健康记录表:(记录ID,长者ID,护工ID,体温,收缩压,舒张压,心率,备注,记录时间,创建时间)。外键:长者ID引用长者表,护工ID引用用户表。
+
+(7)交班记录表:(记录ID,护工ID,日期,内容,创建时间)。外键:护工ID引用用户表。
+
+(8)通知表:(通知ID,标题,内容,目标角色,目标用户ID,创建者ID,创建时间)。外键:创建者ID引用用户表。
+
+(9)反馈表:(反馈ID,家属ID,长者ID,类型,内容,评分,状态,回复,创建时间,更新时间)。外键:家属ID引用用户表,长者ID引用长者表。
+
+(10)账单表:(账单ID,长者ID,月份,床位费,护理费,餐饮费,其他费用,总计,状态,创建时间,支付时间)。外键:长者ID引用长者表。
+
+(11)缴费记录表:(记录ID,账单ID,家属ID,金额,支付方式,支付时间)。外键:账单ID引用账单表,家属ID引用用户表。
+
+### 4.5.3 物理设计
+
+系统根据MySQL数据库数据存储的特性设计数据库关系表,以下列举主要的物理表结构。
+
+表4.1 用户表(sys_user表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 用户ID | BIGINT | - | 主键,自增 |
+| username | 用户名 | VARCHAR | 50 | 非空,唯一 |
+| password | 密码 | VARCHAR | 100 | 非空 |
+| name | 姓名 | VARCHAR | 50 | 非空 |
+| phone | 电话 | VARCHAR | 30 | - |
+| role | 角色 | VARCHAR | 20 | 非空 |
+| status | 状态 | TINYINT | - | 非空,默认1 |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| updated_at | 更新时间 | DATETIME | - | 自动更新 |
+
+表4.2 长者表(elder表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 长者ID | BIGINT | - | 主键,自增 |
+| name | 姓名 | VARCHAR | 50 | 非空 |
+| gender | 性别 | VARCHAR | 10 | - |
+| id_card | 身份证号 | VARCHAR | 30 | 非空,唯一 |
+| birthday | 出生日期 | DATE | - | - |
+| room_no | 房间号 | VARCHAR | 20 | - |
+| check_in_date | 入住日期 | DATE | - | - |
+| care_level | 护理等级 | VARCHAR | 20 | - |
+| status | 状态 | VARCHAR | 20 | - |
+| remark | 备注 | VARCHAR | 200 | - |
+
+表4.3 护理记录表(care_record表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 记录ID | BIGINT | - | 主键,自增 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| nurse_id | 护工ID | BIGINT | - | 非空 |
+| content | 护理内容 | VARCHAR | 500 | - |
+| attachment_url | 附件URL | VARCHAR | 200 | - |
+| record_time | 记录时间 | DATETIME | - | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+
+表4.4 健康记录表(health_record表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 记录ID | BIGINT | - | 主键,自增 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| nurse_id | 护工ID | BIGINT | - | 非空 |
+| temperature | 体温 | DECIMAL | 4,1 | - |
+| bp_systolic | 收缩压 | INT | - | - |
+| bp_diastolic | 舒张压 | INT | - | - |
+| heart_rate | 心率 | INT | - | - |
+| note | 备注 | VARCHAR | 200 | - |
+| record_time | 记录时间 | DATETIME | - | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+
+表4.5 账单表(bill表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 账单ID | BIGINT | - | 主键,自增 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| month | 月份 | VARCHAR | 7 | 非空 |
+| bed_fee | 床位费 | DECIMAL | 10,2 | - |
+| care_fee | 护理费 | DECIMAL | 10,2 | - |
+| meal_fee | 餐饮费 | DECIMAL | 10,2 | - |
+| other_fee | 其他费用 | DECIMAL | 10,2 | - |
+| total | 总计 | DECIMAL | 10,2 | - |
+| status | 状态 | VARCHAR | 20 | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| paid_at | 支付时间 | DATETIME | - | - |
+
+表4.6 排班表(schedule表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 排班ID | BIGINT | - | 主键,自增 |
+| nurse_id | 护工ID | BIGINT | - | 非空 |
+| date | 日期 | DATE | - | 非空 |
+| shift | 班次 | VARCHAR | 20 | - |
+| task | 任务 | VARCHAR | 200 | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| updated_at | 更新时间 | DATETIME | - | 自动更新 |
+
+表4.7 反馈表(feedback表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 反馈ID | BIGINT | - | 主键,自增 |
+| family_id | 家属ID | BIGINT | - | 非空 |
+| elder_id | 长者ID | BIGINT | - | 非空 |
+| type | 类型 | VARCHAR | 20 | - |
+| content | 内容 | VARCHAR | 500 | - |
+| rating | 评分 | INT | - | - |
+| status | 状态 | VARCHAR | 20 | - |
+| reply | 回复 | VARCHAR | 500 | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+| updated_at | 更新时间 | DATETIME | - | 自动更新 |
+
+表4.8 通知表(notice表)
+
+| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
+|----------|----------|----------|------|-----------|
+| id | 通知ID | BIGINT | - | 主键,自增 |
+| title | 标题 | VARCHAR | 100 | 非空 |
+| content | 内容 | VARCHAR | 1000 | - |
+| target_role | 目标角色 | VARCHAR | 20 | - |
+| target_user_id | 目标用户ID | BIGINT | - | - |
+| created_by | 创建者ID | BIGINT | - | - |
+| created_at | 创建时间 | DATETIME | - | 默认当前时间 |
+
+## 4.6 图形界面设计
+
+### 4.6.1 长者档案管理界面设计
+
+管理员的长者档案管理界面采用经典的管理后台布局,左侧为导航菜单,右侧为主内容区域。主内容区域顶部设有"添加长者"操作按钮,下方为长者信息数据表格,表格列包括姓名、性别、身份证号、房间号、护理等级、状态和操作列。操作列提供编辑和删除按钮。点击添加或编辑按钮时,弹出表单对话框供用户输入或修改长者信息。长者档案管理界面设计图如图4.18所示。
+
+
+
+图4.18 长者档案管理界面设计图
+
+### 4.6.2 健康监测界面设计
+
+护工的健康监测界面同样采用左侧导航、右侧内容的布局。主内容区域上方为数据录入表单,包含长者选择下拉框、体温输入框、收缩压输入框、舒张压输入框、心率输入框、备注输入框和记录时间选择器,以及提交按钮。表单下方为健康记录数据表格,展示已录入的历史健康监测数据。健康监测界面设计图如图4.19所示。
+
+
+
+图4.19 健康监测界面设计图
+
+# 第5章 养老院管理系统的系统实现
+系统的登录界面是所有用户访问系统的入口。用户在登录页面输入账号和密码,系统验证通过后根据用户角色自动跳转到对应的功能首页。登录界面如图5.1所示。
+
+
+
+图5.1 系统登录界面
+
+
+## 5.1 管理员功能模块
+
+### 5.1.1 运营概览
+
+管理员登录系统后,首先进入运营概览页面。该页面以卡片形式展示养老院的四项核心运营指标:在住长者数量、护工数量、家属数量和累计收入。系统通过调用后端统计接口(GET /api/admin/stats)获取实时数据,后端从数据库中分别统计各角色用户数量和已支付账单的总金额,将结果以JSON格式返回给前端。前端使用Element UI的el-row和el-card组件进行布局展示,四个指标卡片等宽排列,直观呈现养老院的整体运营状况。
+
+运营概览界面如图5.2所示。
+
+
+
+图5.2 运营概览界面
+
+### 5.1.2 账号管理
+
+账号管理页面为管理员提供了系统用户的全生命周期管理功能。页面顶部设有角色筛选下拉框,管理员可按角色(护工、家属)筛选用户列表。用户列表以数据表格形式展示,包含用户名、姓名、角色、状态等字段。管理员可执行以下操作:点击"添加账号"按钮,在弹出的对话框中填写用户名、密码、姓名、电话和角色信息,提交后系统调用后端接口创建新用户,密码经BCrypt加密后存储;点击"编辑"按钮可修改用户的姓名、电话和状态信息;点击"重置密码"按钮可为用户设置新密码;通过状态开关可启用或禁用用户账号。
+
+账号管理界面如图5.3所示。
+
+
+
+图5.3 账号管理界面
+
+### 5.1.3 长者档案管理
+
+长者档案管理页面实现了长者基本信息的增删改查功能。页面以数据表格展示所有长者的信息,包括姓名、性别、身份证号、房间号、入住日期、护理等级和状态等字段。管理员点击"添加长者"按钮后,系统弹出包含姓名、性别、身份证号、出生日期、房间号、入住日期、护理等级、状态和备注等字段的表单对话框。表单提交后,前端调用后端接口(POST /api/admin/elders)将数据保存至数据库。编辑功能复用同一表单组件,通过回填已有数据实现信息修改。删除操作需经二次确认,防止误操作。
+
+长者档案管理界面如图5.4所示。
+
+
+
+图5.4 长者档案管理界面
+
+### 5.1.4 排班管理
+
+排班管理页面采用日历视图与列表视图相结合的设计。页面上方展示月度日历,管理员可通过点击日期查看当日的排班详情。日历下方以表格形式展示选定日期的所有排班记录,包括护工姓名、班次(早班、中班、夜班)和工作任务。管理员可创建新的排班记录,需选择护工、日期、班次并填写任务描述。系统支持排班的编辑和删除操作,同时支持按日期范围查询排班数据,便于管理员进行周度或月度排班规划。
+
+排班管理界面如图5.5所示。
+
+
+
+图5.5 排班管理界面
+
+### 5.1.5 账单管理
+
+账单管理页面实现了养老院费用账单的全流程管理。管理员可按长者筛选账单列表,表格展示账单的月份、床位费、护理费、餐饮费、其他费用、总计金额和支付状态。创建账单时,管理员选择长者和月份,分别填写各项费用金额,系统自动计算总计金额。账单创建后状态默认为"未支付",待家属完成支付后状态自动更新为"已支付"。管理员可编辑未支付的账单信息,也可删除错误创建的账单记录。
+
+账单管理界面如图5.6所示。
+
+
+
+图5.6 账单管理界面
+
+### 5.1.6 反馈处理
+
+反馈处理页面展示所有家属提交的服务反馈信息。反馈列表以表格形式呈现,包含反馈类型(建议、投诉等)、反馈内容、评分、提交时间和处理状态等字段。管理员点击某条反馈的"回复"按钮后,在弹出的对话框中填写回复内容并更新处理状态(如"已处理"),提交后系统调用后端接口(PUT /api/admin/feedback)更新反馈记录。家属可在自己的反馈列表中查看管理员的回复内容。
+
+反馈处理界面如图5.7所示。
+
+
+
+图5.7 反馈处理界面
+
+### 5.1.7 通知公告管理
+
+通知公告管理页面支持管理员向不同角色发布通知信息。页面上方设有"发布通知"按钮,点击后弹出表单对话框,管理员需填写通知标题、通知内容,并选择目标角色(护工、家属或全部)。通知发布后,对应角色的用户在登录系统后可在通知中心页面查看该通知。通知列表以表格形式展示已发布的所有通知,包含标题、目标角色和发布时间等信息。
+
+通知公告管理界面如图5.8所示。
+
+
+
+图5.8 通知公告管理界面
+
+## 5.2 护工功能模块
+
+### 5.2.1 护理记录
+
+护理记录页面是护工日常工作中使用频率最高的功能模块。页面上方为护理记录录入表单,护工需选择被护理的长者,填写护理内容的详细描述,可选择上传图片等附件作为护理凭证(通过调用文件上传接口POST /api/files/upload实现),并选择记录时间。表单提交后,系统自动关联当前登录护工的ID,将护理记录保存至数据库。页面下方以列表形式展示该长者的历史护理记录,包含记录时间、护理内容和附件链接等信息,便于护工回顾和参考。
+
+护理记录界面如图5.9所示。
+
+
+
+图5.9 护理记录界面
+
+### 5.2.2 健康监测
+
+健康监测页面用于记录长者的日常体征数据。录入表单包含长者选择、体温(摄氏度)、收缩压(mmHg)、舒张压(mmHg)、心率(次/分钟)、备注和记录时间等字段。护工完成体征测量后,在表单中录入各项数据并提交,系统将数据保存至健康记录表。页面下方展示该长者的历史健康监测数据列表,家属也可通过家属端查看这些数据,实现了健康信息的透明共享。
+
+健康监测界面如图5.10所示。
+
+
+
+图5.10 健康监测界面
+
+### 5.2.3 交班记录
+
+交班记录页面用于护工在换班时记录当班期间的重要事项。录入表单包含日期选择和交班内容两个字段,护工填写当班期间需要交接的注意事项、特殊情况等信息后提交保存。页面下方展示当前护工的历史交班记录列表,按时间倒序排列,便于接班护工查阅前一班次的工作情况,确保护理服务的连续性。
+
+交班记录界面如图5.11所示。
+
+
+
+图5.11 交班记录界面
+
+### 5.2.4 我的排班
+
+我的排班页面以月度日历视图展示护工个人的排班信息。护工可通过切换月份查看不同时间段的排班安排,点击具体日期可查看当日的班次和工作任务详情。系统通过调用后端接口(GET /api/nurse/schedules/range)按日期范围获取排班数据,前端将数据渲染到日历组件上,直观展示护工的工作安排。
+
+我的排班界面如图5.12所示。
+
+
+
+图5.12 我的排班界面
+
+## 5.3 家属功能模块
+
+### 5.3.1 亲人档案
+
+亲人档案页面展示与当前登录家属关联的所有长者信息。系统通过家属长者关联表(family_elder)查询当前家属关联的长者ID列表,再从长者表中获取对应的详细信息。页面以表格形式展示长者的姓名、性别、房间号和护理等级等基本信息,家属可直观了解老人的入住情况。
+
+亲人档案界面如图5.13所示。
+
+
+
+图5.13 亲人档案界面
+
+### 5.3.2 每日动态
+
+每日动态页面允许家属查看老人的护理服务记录。页面顶部设有长者选择下拉框,家属选择目标长者后,系统加载该长者的所有护理记录列表。列表展示每条记录的时间、护理内容和附件信息。系统在后端进行权限校验,确保家属只能查看与自己关联的长者的护理记录,防止越权访问。
+
+每日动态界面如图5.14所示。
+
+
+
+图5.14 每日动态界面
+
+### 5.3.3 健康记录
+
+健康记录页面的设计与每日动态页面类似,家属选择长者后可查看该长者的所有健康监测数据。列表展示记录时间、体温、收缩压、舒张压、心率和备注等信息,家属可通过这些数据了解老人的健康趋势,及时发现异常情况。
+
+健康记录界面如图5.15所示。
+
+
+
+图5.15 健康记录界面
+
+### 5.3.4 账单支付
+
+账单支付页面实现了家属在线查看和支付账单的功能。家属选择长者后,系统展示该长者的所有账单列表,包含月份、总金额和支付状态。对于未支付的账单,家属可点击"支付"按钮,选择支付方式后完成支付。系统调用后端支付接口(POST /api/family/bills/{id}/pay),后端更新账单状态为"已支付",同时在缴费记录表中插入一条支付记录,记录支付金额、支付方式和支付时间。
+
+账单支付界面如图5.16所示。
+
+
+
+图5.16 账单支付界面
+
+### 5.3.5 服务反馈
+
+服务反馈页面为家属提供了向养老院提交意见和建议的渠道。页面上方为反馈提交表单,家属需选择关联的长者,选择反馈类型(建议、投诉等),填写反馈内容,并可进行服务评分。提交后系统将反馈保存至数据库,状态默认为"新建"。页面下方展示家属已提交的所有反馈记录,包含反馈内容、提交时间、处理状态和管理员回复等信息,实现了反馈的闭环管理。
+
+服务反馈界面如图5.17所示。
+
+
+
+图5.17 服务反馈界面
+
+# 第6章 养老院管理系统的系统测试
+
+## 6.1 系统测试概述
+
+### 6.1.1 测试的背景
+
+系统测试是软件开发过程中不可或缺的重要环节,其目的是验证系统是否满足需求规格说明中定义的各项功能和性能要求。本系统作为一个面向养老机构的管理平台,涉及长者信息管理、护理服务记录、健康数据监测、费用结算等关键业务功能,任何功能缺陷或数据错误都可能影响养老服务的质量和安全。因此,对系统进行全面、系统的测试具有重要意义。
+
+### 6.1.2 测试的意义
+
+通过系统测试,可以发现和修复系统中存在的功能缺陷和性能问题,确保系统在交付使用前达到预期的质量标准。具体而言,功能测试可以验证各功能模块是否按照需求正确实现;安全性测试可以检验系统的身份认证和权限控制机制是否有效;兼容性测试可以确保系统在不同浏览器和设备上的正常运行。系统测试的充分开展有助于提升用户对系统的信任度和满意度。
+
+### 6.1.3 测试的环境
+
+本系统的测试环境配置如下:
+
+| 项目 | 配置 |
+|------|------|
+| 操作系统 | Windows 11 / macOS Sonoma |
+| 处理器 | Intel Core i7 / Apple M2 |
+| 内存 | 16GB |
+| 数据库 | MySQL 8.0 |
+| JDK版本 | JDK 17 |
+| 浏览器 | Google Chrome 120、Mozilla Firefox 121、Microsoft Edge 120 |
+| 后端服务器 | Spring Boot内嵌Tomcat |
+| 前端开发服务器 | Vue CLI DevServer |
+
+## 6.2 系统测试用例设计
+
+### 6.2.1 长者档案管理功能测试
+
+表6.1 长者档案管理功能测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-001 | 添加长者 | 姓名:张明远,性别:男,身份证号:110101195501010011,出生日期:1955-01-01,房间号:C301,入住日期:2024-06-15,护理等级:一级,状态:在住 | 系统提示添加成功,长者列表中出现新记录 | 系统提示添加成功,列表正确显示新长者信息 | 是 |
+| TC-002 | 编辑长者信息 | 将张明远的房间号从C301修改为C302 | 系统提示修改成功,列表中房间号更新为C302 | 修改成功,数据正确更新 | 是 |
+| TC-003 | 删除长者 | 选择张明远,点击删除并确认 | 系统提示删除成功,列表中不再显示该长者 | 删除成功,记录已移除 | 是 |
+| TC-004 | 添加重复身份证号 | 输入已存在的身份证号110101194001010011 | 系统提示身份证号已存在,添加失败 | 系统正确提示错误信息 | 是 |
+
+### 6.2.2 护理记录管理功能测试
+
+表6.2 护理记录管理功能测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-005 | 添加护理记录 | 选择长者:陈国强,内容:协助进行上午康复训练,包括手臂伸展和腿部活动,记录时间:2024-06-15 10:00 | 系统提示添加成功,记录列表中出现新记录 | 添加成功,记录正确显示 | 是 |
+| TC-006 | 上传附件 | 选择一张护理现场照片上传 | 文件上传成功,附件链接正确显示 | 上传成功,可正常预览 | 是 |
+| TC-007 | 查看护理记录 | 家属端选择长者陈国强查看护理记录 | 显示该长者的所有护理记录列表 | 列表正确显示,数据完整 | 是 |
+
+### 6.2.3 健康监测功能测试
+
+表6.3 健康监测功能测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-008 | 记录体征数据 | 选择长者:李秀兰,体温:36.5,收缩压:125,舒张压:82,心率:75,备注:状态良好,记录时间:2024-06-15 14:30 | 系统提示记录成功,数据列表中出现新记录 | 记录成功,数据正确显示 | 是 |
+| TC-009 | 家属查看健康记录 | 家属端选择长者李秀兰查看健康记录 | 显示该长者的所有健康监测数据 | 数据正确显示,包含体温、血压、心率等信息 | 是 |
+
+### 6.2.4 安全性测试
+
+表6.4 安全性测试用例
+
+| 测试编号 | 测试项目 | 测试输入 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-010 | 未登录访问 | 直接访问/admin/dashboard页面 | 系统自动跳转到登录页面 | 正确跳转到登录页面 | 是 |
+| TC-011 | 越权访问 | 护工账号尝试访问/admin/users页面 | 系统拒绝访问,跳转到护工首页 | 正确拒绝,跳转到护工工作台 | 是 |
+| TC-012 | 错误密码登录 | 输入正确用户名和错误密码 | 系统提示密码错误 | 正确提示"密码错误" | 是 |
+| TC-013 | 禁用账号登录 | 使用已被禁用的账号登录 | 系统提示账号已被禁用 | 正确提示"账号已被禁用" | 是 |
+| TC-014 | 家属越权查看 | 家属尝试查看非关联长者的护理记录 | 系统提示无权访问 | 正确提示"无权访问该亲属" | 是 |
+
+### 6.2.5 兼容性测试
+
+表6.5 兼容性测试用例
+
+| 测试编号 | 测试项目 | 测试环境 | 预期结果 | 实际结果 | 是否通过 |
+|----------|----------|----------|----------|----------|----------|
+| TC-015 | Chrome浏览器 | Google Chrome 120,Windows 11 | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+| TC-016 | Firefox浏览器 | Mozilla Firefox 121,Windows 11 | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+| TC-017 | Edge浏览器 | Microsoft Edge 120,Windows 11 | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+| TC-018 | macOS环境 | Google Chrome,macOS Sonoma | 系统所有功能正常运行,界面显示正确 | 功能正常,界面显示完整 | 是 |
+
+# 第7章 结论
+
+本文针对养老院日常运营管理中存在的信息化程度低、管理效率不高、家属沟通不畅等问题,设计并实现了一套基于Spring Boot的养老院管理系统。系统采用前后端分离的B/S架构,后端基于Spring Boot 3 + MyBatis + MySQL技术栈,前端基于Vue 2 + Element UI技术栈,通过Sa-Token框架实现了安全可靠的身份认证和基于角色的权限控制。
+
+系统面向管理员、护工和家属三类用户角色,实现了以下核心功能:管理员可进行运营数据概览、账号管理、长者档案管理、排班管理、账单管理、反馈处理和通知公告管理;护工可查看个人排班、记录护理服务内容、录入健康监测数据、管理交班记录和查看通知;家属可查看亲人档案、了解护理动态、查看健康记录、在线支付账单、提交服务反馈和接收通知。
+
+通过系统分析、系统设计、编码实现和系统测试等完整的软件开发流程,本系统已实现了预期的各项功能目标。测试结果表明,系统功能完善、运行稳定、安全可靠,能够有效提升养老院的信息化管理水平,改善家属与养老机构之间的信息沟通效率,为养老服务质量的提升提供了有力的技术支撑。
+
+当然,本系统仍存在一些可以改进和完善的方面。在功能层面,后续可以增加数据统计分析和可视化图表功能,为管理决策提供更直观的数据支持;可以引入消息推送机制,实现重要通知的实时提醒;可以增加移动端适配,方便护工和家属通过手机使用系统。在技术层面,可以引入Redis缓存提升系统的并发处理能力;可以采用微服务架构提升系统的可扩展性;可以集成物联网设备实现健康数据的自动采集。这些改进方向将在后续的研究和开发工作中逐步实现。
+
+## 参考文献
+
+[1] 国家统计局. 2024年国民经济和社会发展统计公报[R]. 北京: 国家统计局, 2025.
+
+[2] 国务院. 关于推进养老服务发展的意见[Z]. 国办发〔2019〕5号, 2019.
+
+[3] 国务院. "十四五"国家老龄事业发展和养老服务体系规划[Z]. 国发〔2021〕35号, 2021.
+
+[4] Craig Walls. Spring Boot实战[M]. 丁雪丰, 译. 北京: 人民邮电出版社, 2016.
+
+[5] 尤雨溪. Vue.js设计与实现[M]. 北京: 人民邮电出版社, 2022.
+
+[6] 李刚. 疯狂Java讲义(第6版)[M]. 北京: 电子工业出版社, 2022.
+
+[7] 王珊, 萨师煊. 数据库系统概论(第6版)[M]. 北京: 高等教育出版社, 2023.
+
+[8] 张开涛. 亿级流量网站架构核心技术[M]. 北京: 电子工业出版社, 2017.
+
+[9] 刘增辉. MyBatis从入门到精通[M]. 北京: 电子工业出版社, 2017.
+
+[10] 方志朋. 深入理解Spring Cloud与微服务构建[M]. 北京: 人民邮电出版社, 2018.
+
+[11] 张卫滨. Java持久化之MyBatis3[M]. 北京: 电子工业出版社, 2015.
+
+[12] 陈雄华, 林开雄. Spring Boot编程思想(核心篇)[M]. 北京: 电子工业出版社, 2019.
+
+## 致谢
+
+时光荏苒,四年的大学生活即将画上句号。在毕业论文完成之际,我要向所有给予我帮助和支持的人表达最诚挚的感谢。
+
+首先,我要衷心感谢我的指导老师。在毕业设计的整个过程中,老师给予了我悉心的指导和耐心的帮助。从选题方向的确定、系统架构的设计到论文的撰写修改,老师都提出了许多宝贵的意见和建议,使我受益匪浅。老师严谨的治学态度和丰富的专业知识深深影响了我,为我今后的学习和工作树立了榜样。
+
+其次,我要感谢大学四年来所有教导过我的老师们。正是各位老师的辛勤付出和无私奉献,使我掌握了扎实的专业知识和技能,为本次毕业设计的顺利完成奠定了坚实的基础。
+
+同时,我要感谢我的同学和朋友们。在毕业设计期间,他们与我分享技术经验、讨论解决方案,在遇到困难时给予我鼓励和帮助,使我能够克服各种挑战,顺利完成系统的开发工作。
+
+最后,我要特别感谢我的家人。感谢他们多年来的默默支持和无私付出,是他们的关爱和鼓励给了我不断前进的动力。
+
+在今后的学习和工作中,我将继续努力,不断提升自己的专业能力和综合素质,以更好的成绩回报所有关心和帮助过我的人。
diff --git a/thesis/论文.md b/thesis/论文.md
new file mode 100644
index 0000000..fa42623
--- /dev/null
+++ b/thesis/论文.md
@@ -0,0 +1,127 @@
+# 基于Spring Boot的养老院管理系统的设计与实现
+
+## 摘要
+
+随着我国人口老龄化进程的不断加快,养老服务需求日益增长,传统的养老院管理模式已难以满足现代化管理的要求。本文针对养老院日常运营管理中存在的信息化程度低、管理效率不高等问题,设计并实现了一套基于Spring Boot的养老院管理系统。该系统采用前后端分离的B/S架构,后端基于Spring Boot 3框架,使用MyBatis作为持久层框架,MySQL作为数据库,Sa-Token实现身份认证与权限控制;前端采用Vue 2框架结合Element UI组件库构建用户界面。系统面向管理员、护工和家属三类用户角色,实现了长者档案管理、护工排班管理、护理记录管理、健康监测记录、交班记录管理、账单管理与在线支付、服务反馈处理以及通知公告等核心功能模块。本文从系统需求分析、系统设计、数据库设计、系统实现和系统测试等方面对该系统进行了详细阐述。测试结果表明,该系统功能完善、运行稳定,能够有效提升养老院的信息化管理水平和服务质量。
+
+关键词:养老院管理系统;Spring Boot;Vue;前后端分离;B/S架构
+
+## Abstract
+
+With the accelerating aging of China's population, the demand for elderly care services is growing rapidly. Traditional nursing home management models can no longer meet the requirements of modern management. This thesis addresses the problems of low informatization and inefficient management in daily nursing home operations by designing and implementing a nursing home management system based on Spring Boot. The system adopts a front-end and back-end separated B/S architecture. The back-end is built on the Spring Boot 3 framework, using MyBatis as the persistence layer framework, MySQL as the database, and Sa-Token for authentication and authorization. The front-end uses the Vue 2 framework combined with the Element UI component library. The system serves three user roles: administrators, nurses, and family members, implementing core functional modules including elder profile management, nurse scheduling, care record management, health monitoring records, shift handover management, billing and online payment, service feedback processing, and notice management. This thesis provides a detailed description of the system from the perspectives of requirements analysis, system design, database design, system implementation, and system testing. Test results show that the system is fully functional and runs stably, effectively improving the informatization management level and service quality of nursing homes.
+
+Keywords: Nursing Home Management System; Spring Boot; Vue; Front-end and Back-end Separation; B/S Architecture
+
+## 目录
+
+第1章 绪论
+第2章 主要技术和框架
+第3章 养老院管理系统的系统分析
+第4章 养老院管理系统的系统设计
+第5章 养老院管理系统的系统实现
+第6章 养老院管理系统的系统测试
+第7章 结论
+参考文献
+致谢
+
+# 第1章 绪论
+
+## 1.1 课题来源及意义
+
+随着我国经济社会的快速发展和医疗卫生条件的持续改善,人均寿命不断延长,人口老龄化问题日益突出。根据国家统计局发布的数据,截至2024年底,我国60岁及以上老年人口已超过2.97亿,占总人口的比重超过21%,标志着我国已正式进入中度老龄化社会。预计到2035年,老年人口将突破4亿,届时每3个人中就有1位老年人。面对如此庞大的老年群体,养老服务体系的建设和完善成为关系国计民生的重大课题。
+
+养老院作为机构养老的重要载体,承担着为失能、半失能及高龄老人提供专业化照护服务的重要职责。然而,当前我国大量养老机构仍然采用传统的手工记录和纸质档案管理方式,存在信息记录不完整、数据查询困难、工作流程繁琐、家属沟通不畅等诸多问题。这些问题不仅降低了养老机构的管理效率,也影响了老年人的服务体验和生活质量。
+
+在此背景下,利用现代信息技术手段,开发一套功能完善、操作便捷的养老院管理系统,对于提升养老机构的管理水平和服务质量具有重要的现实意义。本课题来源于对养老行业信息化建设需求的深入调研,旨在通过构建一个集长者档案管理、护理服务记录、健康监测、排班管理、费用结算和家属互动于一体的综合管理平台,为养老机构的数字化转型提供技术支撑。
+
+本课题的研究意义主要体现在以下几个方面:第一,通过信息化手段实现养老院日常管理的规范化和标准化,减少人工操作失误,提高管理效率;第二,建立完善的长者健康档案和护理记录体系,为老年人的健康管理提供数据支持;第三,搭建家属与养老机构之间的信息沟通桥梁,使家属能够及时了解老人的生活和健康状况,增强家属的信任感和满意度;第四,为养老机构的运营决策提供数据分析支持,促进养老服务行业的高质量发展。
+
+## 1.2 课题研究现状
+
+近年来,随着"互联网+养老"理念的深入推进,国内外学者和企业在养老信息化领域开展了大量的研究和实践工作。
+
+在国外,发达国家的养老信息化建设起步较早,已形成较为成熟的体系。美国的养老机构普遍采用电子健康记录(EHR)系统,实现了老年人健康数据的数字化管理和跨机构共享。日本作为全球老龄化程度最高的国家之一,在智慧养老领域投入了大量资源,开发了多种基于物联网和人工智能技术的养老服务系统,如智能健康监测设备、远程医疗平台等。欧洲各国也在积极推进养老服务的数字化转型,通过建立统一的养老服务信息平台,实现了养老资源的优化配置和服务质量的持续改进。
+
+在国内,养老信息化建设虽然起步相对较晚,但发展势头迅猛。政府层面,国务院先后出台了《关于推进养老服务发展的意见》《"十四五"国家老龄事业发展和养老服务体系规划》等政策文件,明确提出要加快养老服务领域的信息化建设。技术层面,基于Java EE、Spring Boot等技术框架的养老管理系统已有较多研究成果。例如,部分学者提出了基于SSM(Spring+SpringMVC+MyBatis)框架的养老院管理系统方案,实现了老人信息管理、护理服务管理等基本功能。也有研究者采用微服务架构,构建了可扩展的智慧养老服务平台。在商业领域,一些企业推出了面向养老机构的SaaS化管理平台,提供了从入住管理到费用结算的全流程解决方案。
+
+然而,现有的养老院管理系统仍存在一些不足之处:部分系统功能单一,仅关注某一方面的管理需求,缺乏系统性和完整性;部分系统的用户界面设计不够友好,操作复杂,不利于非技术人员使用;部分系统缺乏对家属端的支持,无法满足家属远程了解老人状况的需求;部分系统的技术架构较为陈旧,难以适应快速变化的业务需求。
+
+## 1.3 当前存在的问题
+
+通过对多家养老机构的实地调研和对现有养老管理系统的分析,本文总结出当前养老院管理中存在的主要问题如下:
+
+(1)信息管理手段落后。许多养老机构仍然依赖纸质档案和Excel表格进行日常管理,长者的基本信息、健康数据、护理记录等分散在不同的文件和表格中,数据的录入、查询和统计工作耗时费力,且容易出现数据丢失和不一致的情况。
+
+(2)护理服务记录不规范。护工的日常护理工作缺乏标准化的记录流程,护理内容、时间、责任人等关键信息记录不完整,导致护理服务质量难以追溯和评估。同时,护工之间的交班信息传递主要依靠口头沟通,容易造成信息遗漏。
+
+(3)健康监测数据管理薄弱。老年人的体温、血压、心率等日常健康监测数据缺乏系统化的记录和管理手段,无法形成连续的健康趋势分析,不利于及时发现老年人的健康异常情况。
+
+(4)家属沟通渠道不畅。家属了解老人在养老院的生活和健康状况主要依靠电话询问或实地探访,信息获取不及时、不全面。家属对养老服务的意见和建议也缺乏有效的反馈渠道。
+
+(5)财务管理效率低下。养老院的费用计算涉及床位费、护理费、餐饮费等多个项目,手工计算容易出错。缴费方式单一,家属需要到院缴费,不够便捷。
+
+## 1.4 课题研究目标
+
+针对上述问题,本课题的研究目标是设计并实现一套功能完善、操作便捷、安全可靠的养老院管理系统。具体目标包括:
+
+(1)建立完善的长者电子档案管理体系,实现长者基本信息、入住信息、护理等级等数据的数字化管理,支持信息的快速录入、查询和修改。
+
+(2)构建标准化的护理服务记录系统,支持护工在线记录每日护理内容,支持附件上传,实现护理服务的全程可追溯。
+
+(3)实现健康监测数据的系统化管理,支持体温、血压、心率等体征数据的录入和查询,为老年人的健康管理提供数据支撑。
+
+(4)开发护工排班管理功能,支持管理员按日期和班次进行排班,护工可在线查看个人排班信息,提高排班管理的效率和透明度。
+
+(5)实现账单管理和在线支付功能,支持管理员按月生成费用账单,家属可在线查看账单明细并完成支付,简化缴费流程。
+
+(6)搭建家属与养老机构之间的信息互动平台,家属可远程查看老人的护理记录、健康数据和费用信息,并可在线提交服务反馈和建议。
+
+(7)实现通知公告管理功能,支持管理员向不同角色发布通知信息,确保重要信息的及时传达。
+
+(8)采用前后端分离的技术架构,确保系统具有良好的可维护性和可扩展性,为后续功能升级奠定基础。
+
+# 第2章 主要技术和框架
+
+## 2.1 主要技术
+
+### 2.1.1 Java语言
+
+Java是一种面向对象的高级编程语言,由Sun Microsystems公司于1995年推出,现由Oracle公司维护。Java语言具有跨平台性、面向对象、安全性高、多线程支持等特点,是目前企业级应用开发中使用最为广泛的编程语言之一。本系统后端开发采用Java 17版本,该版本是Java的长期支持(LTS)版本,提供了更好的性能优化和语言特性支持。Java语言丰富的类库和成熟的生态系统为本系统的开发提供了坚实的技术基础。
+
+### 2.1.2 JavaScript语言
+
+JavaScript是一种轻量级的解释型脚本语言,最初被设计用于网页的客户端交互,现已发展成为一种功能强大的全栈开发语言。JavaScript具有动态类型、基于原型的面向对象、函数式编程等特性。在本系统中,JavaScript主要用于前端页面的交互逻辑开发,配合Vue框架实现了丰富的用户界面交互效果。
+
+### 2.1.3 MySQL数据库
+
+MySQL是一款开源的关系型数据库管理系统,由瑞典MySQL AB公司开发,现属于Oracle公司。MySQL以其高性能、高可靠性、易用性和低成本等优势,成为全球最受欢迎的开源数据库之一。MySQL支持标准的SQL语言,提供了完善的事务处理、索引优化、数据备份与恢复等功能。本系统采用MySQL作为数据存储方案,数据库字符集设置为utf8mb4,以支持中文字符和特殊字符的存储。
+
+### 2.1.4 HTML5与CSS3
+
+HTML5是超文本标记语言的第五个主要版本,提供了更丰富的语义化标签和多媒体支持能力。CSS3是层叠样式表的最新版本,引入了圆角、阴影、渐变、动画等新特性,使网页的视觉表现更加丰富。在本系统中,HTML5和CSS3用于构建前端页面的结构和样式,配合Element UI组件库实现了美观、统一的用户界面。
+
+## 2.2 框架和开发模式
+
+### 2.2.1 Spring Boot框架
+
+Spring Boot是由Pivotal团队开发的基于Spring框架的快速开发框架,旨在简化Spring应用的初始搭建和开发过程。Spring Boot通过自动配置、起步依赖和内嵌服务器等特性,大幅降低了Spring应用的配置复杂度。本系统采用Spring Boot 3.2.5版本,该版本基于Spring Framework 6,要求Java 17及以上版本,支持Jakarta EE 10规范。Spring Boot的核心优势包括:自动配置机制减少了大量的XML配置文件;起步依赖简化了Maven依赖管理;内嵌Tomcat服务器使应用可以独立运行;Actuator模块提供了应用监控和管理功能。
+
+### 2.2.2 MyBatis持久层框架
+
+MyBatis是一款优秀的半自动化ORM(对象关系映射)持久层框架,它支持自定义SQL、存储过程以及高级映射。与全自动化的ORM框架(如Hibernate)不同,MyBatis允许开发者直接编写SQL语句,在保持灵活性的同时提供了对象与数据库表之间的映射功能。本系统使用MyBatis Spring Boot Starter 3.0.3版本,通过注解方式定义SQL映射,配合MyBatis的驼峰命名自动转换功能(map-underscore-to-camel-case),实现了Java实体类属性与数据库字段之间的自动映射。
+
+### 2.2.3 Sa-Token认证框架
+
+Sa-Token是一款国产的轻量级Java权限认证框架,主要解决登录认证、权限验证、Session会话管理、单点登录等安全相关问题。相比Spring Security等重量级安全框架,Sa-Token具有API设计简洁、学习成本低、功能丰富等优点。本系统采用Sa-Token 1.37.0版本,使用UUID风格的Token,配置了86400秒(24小时)的Token有效期,支持同端多人登录和Token共享。通过@SaCheckRole注解实现了基于角色的访问控制,确保不同角色的用户只能访问其权限范围内的功能。
+
+### 2.2.4 Vue前端框架
+
+Vue是一款用于构建用户界面的渐进式JavaScript框架,由尤雨溪于2014年创建。Vue的核心特性包括响应式数据绑定、组件化开发、虚拟DOM、指令系统等。本系统采用Vue 2.7版本,结合Vue Router实现了前端路由管理,通过Axios库实现了与后端API的HTTP通信。Vue的组件化开发模式使得前端代码结构清晰、复用性高,有效提升了开发效率。
+
+### 2.2.5 Element UI组件库
+
+Element UI是由饿了么前端团队开发的一套基于Vue 2的桌面端UI组件库,提供了丰富的预制组件,包括表格、表单、对话框、导航菜单、日期选择器等。Element UI遵循一致的设计规范,组件风格统一、交互友好,能够帮助开发者快速构建美观、专业的管理后台界面。本系统使用Element UI 2.15版本,充分利用了其提供的布局容器、数据表格、表单验证等组件,大幅减少了前端界面的开发工作量。
+
+### 2.2.6 前后端分离开发模式
+
+本系统采用前后端分离的开发模式,前端和后端作为两个独立的项目进行开发和部署。后端通过RESTful API向前端提供数据服务,前端通过HTTP请求调用后端接口获取数据并渲染页面。这种开发模式的优势在于:前后端可以并行开发,提高开发效率;前后端通过标准化的API接口进行通信,降低了耦合度;前端可以独立部署和更新,不影响后端服务;便于后续扩展移动端等多终端应用。在开发阶段,前端通过Vue CLI的代理配置将API请求转发到后端服务器,实现了前后端的无缝对接。
diff --git a/uml_describe/e-r图绘制要求.md b/uml_describe/e-r图绘制要求.md
new file mode 100644
index 0000000..e3463fa
--- /dev/null
+++ b/uml_describe/e-r图绘制要求.md
@@ -0,0 +1,59 @@
+这张图片展示的是一张复杂的 **E-R 图(实体 - 关系图)**,描述了一个电商系统(可能是蛋糕店)的数据库概念模型。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表,请结合以下内容与样式规范进行绘制:
+
+### 1. 整体布局逻辑:以“用户”为核心的网状结构
+* **核心实体**:**“用户”** 位于图表的中心位置,作为连接左右两侧业务的枢纽。
+* **左侧业务**:涉及客服、订单、浏览行为。
+* **右侧业务**:涉及购买、购物车、蛋糕商品及分类。
+* **元素形状**:
+ * **矩形**:代表 **实体**(如:用户、订单、蛋糕)。
+ * **菱形**:代表 **关系**(如:购买、联系、管理)。
+ * **椭圆形**:代表 **属性**(如:购买时间、问题解决状态)。
+* **连线**:所有连接线均为黑色细实线,线上标注有基数(1, n, m)来表示一对多或多对多关系。
+
+### 2. 详细节点与连接关系(从左至右)
+
+请按照以下逻辑绘制各个模块:
+
+**模块一:左侧客服与订单**
+1. **客服 - 联系 - 用户**:
+ * 左侧矩形 **“客服”** 通过菱形 **“联系”** 连接到中心矩形 **“用户”**。
+ * **基数**:客服端标 **“m”**,用户端标 **“n”**(多对多)。
+ * **属性**:菱形“联系”上方连出一个椭圆 **“问题解决状态”**。
+2. **订单 - 创建 - 用户**:
+ * 上方矩形 **“订单”** 通过菱形 **“创建”** 连接到中心矩形 **“用户”**。
+ * **基数**:订单端标 **“n”**,用户端标 **“1”**(一个用户创建多个订单)。
+
+**模块二:下方浏览行为**
+3. **用户 - 浏览 - 轮播图**:
+ * 中心矩形 **“用户”** 向下通过菱形 **“浏览”** 连接到下方矩形 **“轮播图”**。
+ * **基数**:用户端标 **“n”**,轮播图端标 **“m”**。
+ * **属性**:菱形“浏览”左侧连出一个椭圆 **“浏览数量”**。
+
+**模块三:右侧核心购物流程(重点复杂区域)**
+4. **用户 - 购买 - 蛋糕**:
+ * 中心矩形 **“用户”** 向右通过菱形 **“购买”** 连接到右侧矩形 **“蛋糕”**。
+ * **基数**:用户端标 **“n”**,蛋糕端标 **“m”**。
+ * **属性**:菱形“购买”上下各连出一个椭圆,分别为 **“购买时间”** 和 **“购买总价”**。
+
+5. **蛋糕 - 管理/加入 - 购物车**(此处结构较紧密,需注意层级):
+ * 右侧矩形 **“蛋糕”** 上方有一个菱形 **“管理”**。
+ * 右上方矩形 **“购物车”** 下方有一个菱形 **“加入”**。
+ * **连接逻辑**:
+ * “蛋糕”向上连到“管理”菱形,基数标 **“1”**。
+ * “管理”菱形向上连到“加入”菱形?或者“购物车”? *(注:原图此处逻辑略显复杂,看似是 购物车--(m)--加入--(n)--管理--(1)--蛋糕 的链式结构,或者是 购物车与蛋糕通过“加入”和“管理”两个关系连接)。*
+ * **属性**:菱形 **“加入”** 的右侧连出两个椭圆:**“加入时间”** 和 **“加入数量”**。
+ * **基数标注**:购物车端标 **“m”**,中间连接处标 **“n”**。
+
+6. **蛋糕 - 进行 - 蛋糕分类**:
+ * 右侧矩形 **“蛋糕”** 向下通过菱形 **“进行”** 连接到右下角矩形 **“蛋糕分类”**。
+ * **基数**:蛋糕端标 **“1”**,蛋糕分类端标 **“n”**。
+
+### 3. 绘图执行建议
+* **对齐**:以“用户”为中心,左右实体尽量保持水平对称感。
+* **基数标注**:在连接实体和关系的线条靠近实体的一端,清晰地写上 **1、n 或 m**。
+* **属性位置**:属性椭圆应紧邻其所属的关系菱形或实体矩形,不要离得太远。
+* **风格**:保持黑白线稿,无填充色,线条清晰。
+
+按照以上描述,你就可以绘制出一张结构完整的“蛋糕电商系统 E-R 图”。
\ No newline at end of file
diff --git a/uml_describe/功能结构图绘制要求.md b/uml_describe/功能结构图绘制要求.md
new file mode 100644
index 0000000..391b278
--- /dev/null
+++ b/uml_describe/功能结构图绘制要求.md
@@ -0,0 +1,51 @@
+这张图片展示的是一张标准的 **系统功能结构图(Function Structure Diagram)** 或 **层级图(Hierarchy Chart)**。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表(仅替换内容),请遵循以下**视觉与结构规范**:
+
+### 1. 整体布局逻辑:自上而下的树状层级
+
+图表采用严格的 **“顶 - 下”垂直层级布局**,呈现出一种从总标题到具体功能模块的分解结构。
+
+- **顶层(Level 0)**:唯一的**总标题**区域。
+- **根节点层(Level 1)**:系统的**核心角色或入口**,位于标题正下方。
+- **一级功能层(Level 2)**:**主要功能模块**,呈水平横向排列。
+- **二级功能层(Level 3)**:**细分功能模块**,呈垂直纵向排列,悬挂在对应的一级功能下方。
+
+### 2. 元素样式规范
+
+- **节点形状**:
+ - 图中所有的功能节点(除了最顶部的标题框略扁外)均使用 **竖向的长方形**(高大于宽,宽高比约为 1:2 或 1:2.5)。
+ - 所有矩形框均为白色填充,黑色细实线边框。
+- **标题框**:
+ - 位于画布最顶端中央,是一个横向的长方形,作为整个图表的总标题。
+
+### 3. 连接线与关系规范(关键结构)
+
+- **线条类型**:所有连接线均为 **黑色细实线**。
+- **走向与风格**:
+ - 采用 **正交连线(直角折线)** 风格。线条只包含水平线和垂直线,没有斜线。
+ - **无箭头**:线条两端均无箭头,仅表示层级归属关系。
+- **连接逻辑**:
+ - **顶层连接**:从根节点(Level 1)的上边缘中心引出一条垂直线,连接到总标题框的下边缘中心。
+ - **一级分发**:从根节点(Level 1)的下边缘中心引出一条垂直短线,然后分叉出一条长水平线。从这条长水平线上,向下引出多条垂直短线,分别连接到一级功能层(Level 2)每个矩形的上边缘中心。
+ - **二级分发**:对于有子功能的一级节点,从其下边缘中心引出一条垂直短线,分叉出一条短水平线,再向下引出垂直线连接到二级功能层(Level 3)的矩形上边缘。
+
+### 4. 层级分布细节(结构模板)
+
+为了完美复刻结构,请注意以下分支逻辑(假设一级功能有 N 个):
+
+- **部分节点无子级**:并非所有一级功能下方都有二级功能。结构中应保留部分“叶子节点”(即一级功能下不连接任何矩形)。
+- **一对多关系**:
+ - 部分一级功能下方连接 **2个** 二级功能矩形(并排排列)。
+ - 部分一级功能下方连接 **3个** 二级功能矩形(并排排列)。
+- **对齐方式**:
+ - 一级功能层的矩形顶部对齐,底部对齐,间距均匀。
+ - 二级功能层的矩形在各自的父节点下方居中对齐。
+
+### 5. 绘图执行建议
+
+1. **字体**:文字在矩形框内 **垂直书写**(从上到下)或 **横向书写**(根据框的长宽比,此图中文字是竖向排列的,即从上往下读)。*修正观察:仔细看图,文字是竖向排列的,例如“注册登录”是竖着写的。* -> **重要修正:矩形框内的文字方向为竖排(从上到下)。**
+2. **颜色**:全黑白,无背景色。
+3. **间距**:一级功能模块之间的水平间距应保持一致;二级功能模块组之间的水平间距应与一级模块对应。
+
+按照以上规范绘制,你将得到一张结构清晰、专业的系统功能模块图模板。
\ No newline at end of file
diff --git a/uml_describe/实体图绘制要求.md b/uml_describe/实体图绘制要求.md
new file mode 100644
index 0000000..fcb756c
--- /dev/null
+++ b/uml_describe/实体图绘制要求.md
@@ -0,0 +1,46 @@
+这张图片展示的是一张标准的 **E-R 图(实体 - 关系图)** 中的 **实体属性图**。它主要用于描述数据库中某一个具体实体(表)所包含的字段(属性)。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表,请结合以下内容与样式规范进行绘制:
+
+### 1. 整体布局逻辑:中心辐射状
+* **核心**:画布正中央放置一个矩形,代表**实体**。
+* **周围**:椭圆形代表**属性**,分布在实体的左右两侧,呈发散状排列。
+
+### 2. 元素样式规范
+* **实体节点**:
+ * **形状**:**矩形**(长方形)。
+ * **位置**:画布绝对中心。
+ * **内容**:填写实体名称,例如 **“管理员”**。
+* **属性节点**:
+ * **形状**:**椭圆形**(扁圆)。
+ * **位置**:围绕在实体矩形的周围。
+ * **内容**:填写具体的字段名。
+* **连接线**:
+ * **样式**:**黑色细实线**。
+ * **箭头**:**无箭头**,仅表示归属关系。
+ * **走向**:从椭圆的边缘直接连接到矩形的边缘。
+
+### 3. 具体内容与分布(从上到下)
+
+请按照以下布局绘制具体的节点:
+
+* **中心实体**:
+ * 矩形框内文字:**“管理员”**
+
+* **左侧属性列(共3个,垂直排列)**:
+ 1. 最上方椭圆:**“管理员ID”**
+ 2. 中间椭圆:**“管理员昵称”**
+ 3. 最下方椭圆:**“管理员密码”**
+ * *连接*:这三个椭圆的右侧边缘均引出直线,汇聚连接到中心矩形的左侧边缘。
+
+* **右侧属性列(共2个,垂直排列)**:
+ 1. 上方椭圆:**“上次登录时间”**
+ 2. 下方椭圆:**“管理员真实姓名”**
+ * *连接*:这两个椭圆的左侧边缘均引出直线,汇聚连接到中心矩形的右侧边缘。
+
+### 4. 绘图执行建议
+* **对齐**:左侧的三个椭圆左边缘或中心线尽量对齐;右侧的两个椭圆右边缘或中心线尽量对齐。
+* **间距**:椭圆与矩形之间保持适当的距离,不要贴得太近,以便清晰展示连接线。
+* **风格**:保持极简黑白风格,线条流畅,无填充色。
+
+按照以上规范,你就可以绘制出一张清晰的“管理员实体属性 E-R 图”。
\ No newline at end of file
diff --git a/uml_describe/时序图绘制要求.md b/uml_describe/时序图绘制要求.md
new file mode 100644
index 0000000..29633c8
--- /dev/null
+++ b/uml_describe/时序图绘制要求.md
@@ -0,0 +1,46 @@
+这张图片展示的是一张标准的 **UML 序列图(Sequence Diagram)**,具体描述的是**“用户注册”**这一业务流程的交互时序。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表,请结合以下内容与样式规范进行绘制:
+
+### 1. 顶部角色布局(从左至右)
+图表顶部水平排列了四个参与者,它们是整个交互的主体:
+* **最左侧**:是一个**火柴人图标**,下方标签为**“用户”**。
+* **中间偏左**:是一个**矩形框**(带阴影),标签为**“国联商城系统前台”**。
+* **中间偏右**:是一个**矩形框**(带阴影),标签为**“后台系统”**。
+* **最右侧**:是一个**矩形框**(带阴影),标签为**“数据库”**。
+
+### 2. 垂直生命线结构
+* 从每个顶部角色的底部中心,都向下延伸出一条**垂直的虚线**,贯穿整个图表,代表时间的流逝。
+* 在这些虚线上,覆盖着**细长的白色矩形条(激活条)**,表示该角色在特定时间段内处于“活动/工作”状态。
+ * **用户**的激活条最长,贯穿了大部分流程。
+ * **系统前台**、**后台系统**和**数据库**的激活条则是分段出现的,对应具体的处理时间。
+
+### 3. 交互流程与连线样式(从上到下)
+图表通过水平箭头线展示消息传递,**实线代表请求/操作,虚线代表返回/响应**。请按照以下顺序绘制:
+
+**第一阶段:进入与输入(左侧交互)**
+1. **自循环**:在“用户”的激活条上,画一个**向左弯曲的实线箭头**指回自己,标签为**“进入系统前台”**。
+2. **请求**:从“用户”指向“系统前台”画一条**实线箭头**,标签为**“提示输入注册信息”**。
+3. **请求**:从“用户”指向“系统前台”画一条**实线箭头**,标签为**“输入注册信息”**。
+
+**第二阶段:提交与验证(向右传递)**
+4. **请求**:从“系统前台”指向“后台系统”画一条**实线箭头**,标签为**“提交注册信息”**。
+5. **请求**:从“后台系统”指向“数据库”画一条**实线箭头**,标签为**“验证注册信息”**。
+
+**第三阶段:处理与添加(中间交互)**
+6. **返回**:从“后台系统”指回“系统前台”画一条**虚线箭头**,标签为**“返回验证码”**。
+7. **返回**:从“用户”指回“系统前台”画一条**虚线箭头**,标签为**“提示注册验证码信息”**(注:此处原图逻辑略显特殊,看似是系统提示用户)。
+8. **请求**:从“后台系统”指向“数据库”画一条**实线箭头**,标签为**“添加注册数据”**。
+
+**第四阶段:结果返回(向左回流)**
+9. **返回**:从“数据库”指回“后台系统”画一条**虚线箭头**,标签为**“返回添加结果”**。
+10. **返回**:从“后台系统”指回“系统前台”画一条**虚线箭头**,标签为**“返回注册结果”**。
+11. **最终反馈**:在“用户”的激活条底部,画一个**自循环箭头**(或指向下方),标签为**“显示注册成功”**。
+
+### 4. 样式细节总结
+* **线条**:所有连接线均为细黑线。请求用实线,返回用虚线(短划线)。
+* **箭头**:所有箭头均为开放式或实心三角形箭头,指向消息接收方。
+* **文字**:所有标签文字位于箭头的上方或下方,字体清晰,无衬线。
+* **阴影**:顶部的系统矩形框带有轻微的右下角阴影,增加立体感。
+
+按照这个包含具体业务内容的结构去画,就能完美复刻这张“用户注册流程时序图”。
\ No newline at end of file
diff --git a/uml_describe/活动图绘制要求.md b/uml_describe/活动图绘制要求.md
new file mode 100644
index 0000000..150ca05
--- /dev/null
+++ b/uml_describe/活动图绘制要求.md
@@ -0,0 +1,43 @@
+这张图片展示的是一张带有 **泳道(Swimlanes)的 UML 活动图(Activity Diagram)**。它主要用于描述一个业务流程在不同责任主体(角色/系统)之间的流转逻辑。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表,请结合以下内容与样式规范进行绘制:
+
+### 1. 整体布局与泳道结构
+* **布局**:图表被两条垂直的细实线分割为 **三列(三个泳道)**。
+* **表头**:每一列的顶部都有一个矩形标题栏,标明了该泳道的责任主体。从左到右依次为:
+ * **左列**:**“用户”**
+ * **中列**:**“后台系统”**
+ * **右列**:**“数据库”**
+
+### 2. 节点样式规范
+* **开始节点**:位于最左侧泳道(用户)的顶部,是一个 **黑色的实心圆**。
+* **活动节点**:所有的操作步骤均使用 **圆角矩形** 表示(白色填充,黑色细边框)。
+* **判断节点**:位于中间泳道(后台系统)的中部,是一个 **菱形**,用于表示条件分支。
+* **结束节点**:位于最左侧泳道(用户)的底部,是一个 **黑色的实心圆,外部套有一个同心圆环**(牛眼图)。
+
+### 3. 具体流程与连线内容(从上到下)
+请按照以下逻辑顺序绘制节点和连接线(箭头):
+
+**第一阶段:发起与验证**
+1. **开始**:从“用户”泳道的黑色实心圆出发,画一条向下箭头,指向圆角矩形 **“验证密码”**。
+2. **跨泳道交互**:从“用户”的“验证密码”右侧引出一条水平实线箭头,指向中间“后台系统”泳道的圆角矩形 **“验证密码”**。
+3. **跨泳道交互**:从“后台系统”的“验证密码”右侧引出一条水平实线箭头,指向右侧“数据库”泳道的圆角矩形 **“数据验证”**。
+
+**第二阶段:逻辑判断**
+4. **回流判断**:从“数据库”的“数据验证”底部引出一条折线箭头,指回中间“后台系统”泳道的 **菱形判断框**。
+ * 菱形框内的文字大致为:**“验证...是否正确”**(或类似的判断逻辑)。
+5. **分支路径**:
+ * **路径 A(否/失败)**:从菱形左侧引出一条 **虚线箭头**,向左穿过泳道线,指回左侧“用户”泳道的 **“验证密码”** 节点上方(形成循环)。线上标注文字 **“否”**。
+ * **路径 B(是/成功)**:从菱形左侧(或底部)引出一条 **实线箭头**,向左穿过泳道线,指向左侧“用户”泳道下方的节点。线上标注文字 **“是”**。
+
+**第三阶段:后续处理与结束**
+6. **后续活动**:在“用户”泳道中,接上一步的“是”路径,向下连接到圆角矩形 **“保存”**(或者是“保存信息”)。
+7. **最终活动**:从“保存”向下画箭头,连接到圆角矩形 **“登录成功”**。
+8. **结束**:从“登录成功”向下画箭头,连接到最底部的 **结束节点(同心圆)**。
+
+### 4. 绘图细节建议
+* **线条**:流程线主要为黑色实线箭头,表示正常的流程流转;表示“验证失败/重试”的回路使用了 **虚线**,以示区别。
+* **对齐**:同一泳道内的节点垂直居中对齐;跨泳道的交互节点尽量保持水平高度一致,使画面整洁。
+* **字体**:使用清晰的无衬线字体,字号适中。
+
+按照以上描述,你就能绘制出一张逻辑清晰、结构标准的“用户登录验证流程活动图”。
\ No newline at end of file
diff --git a/uml_describe/用例图绘制要求.md b/uml_describe/用例图绘制要求.md
new file mode 100644
index 0000000..db6201a
--- /dev/null
+++ b/uml_describe/用例图绘制要求.md
@@ -0,0 +1,45 @@
+这张图片展示的是一张标准的 **UML 用例图(Use Case Diagram)**。为了让你或他人能够绘制出完全相同风格和结构的图表(仅替换内容),请遵循以下**视觉与结构规范**:
+
+### 1. 整体布局逻辑:三层辐射状结构
+图表采用清晰的 **“左 - 中-右”水平流向布局**,呈现出一种从单一源头向多级功能发散的树状结构。
+
+* **第一层(最左侧)**:唯一的**参与者(Actor)**区域。
+* **第二层(中间)**:**核心功能模块**区域,呈垂直单列排列。
+* **第三层(最右侧)**:**细分/子功能**区域,根据中间层的需求呈分散的组状排列。
+
+### 2. 元素样式规范
+
+* **参与者(Actor)**:
+ * **位置**:画布最左侧,垂直方向居中。
+ * **形状**:标准的 UML 火柴人图标(圆形头部,线条躯干和四肢)。
+ * **标签**:图标正下方居中放置文本标签。
+
+* **用例节点(Use Cases)**:
+ * **形状**:所有功能节点均使用 **扁长的椭圆形**(宽高比约为 3:1 或 4:1)。
+ * **样式**:白色填充,黑色细实线边框。
+ * **排列**:
+ * **中间列**:垂直均匀分布,形成整齐的一列。
+ * **右侧列**:根据逻辑关系分组,每组内的椭圆垂直紧凑排列,组与组之间留有较大空隙以对应中间层的不同节点。
+
+### 3. 连接线与关系规范(关键结构)
+
+这张图包含两种截然不同的连接关系,必须严格区分:
+
+* **第一级连接(参与者 -> 核心功能)**:
+ * **线条类型**:**黑色实线**。
+ * **箭头**:**无箭头**(或者是简单的直线连接)。
+ * **走向**:从左侧参与者出发,呈放射状连接到中间列每一个椭圆的左侧边缘。
+
+* **第二级连接(核心功能 -> 细分功能)**:
+ * **线条类型**:**黑色虚线**(短划线)。
+ * **箭头**:线条末端带有 **开放式箭头**(空心三角形),指向右侧的细分功能椭圆。
+ * **关系标签**:在每条虚线的上方或中间,必须标注特定的构造型文本,格式为 **«include»**(即单词前后带有尖括号样式的符号)。
+ * **逻辑关系**:表现为一对多的关系。中间的一个椭圆可能引出 0 条、1 条或多条虚线指向右侧。
+
+### 4. 绘图执行建议
+
+1. **对齐**:确保中间列的椭圆左边缘大致对齐;右侧的椭圆组根据其对应的中间椭圆垂直居中。
+2. **间距**:中间列椭圆之间的垂直间距应保持一致;右侧各组之间的垂直间距应明显大于组内椭圆之间的间距,以体现层级归属。
+3. **字体**:使用清晰的无衬线字体(如 Arial, Helvetica, 微软雅黑),字号统一,保持黑白单色风格,不要使用任何背景色或阴影。
+
+按照以上规范绘制,你将得到一张结构严谨、风格专业的用例图模板,只需填入具体的业务内容即可。
\ No newline at end of file
diff --git a/uml_describe/界面设计图绘制要求.md b/uml_describe/界面设计图绘制要求.md
new file mode 100644
index 0000000..b276a12
--- /dev/null
+++ b/uml_describe/界面设计图绘制要求.md
@@ -0,0 +1,50 @@
+这张图片展示的是一张标准的 **UI 线框图(Wireframe)** 或 **网页低保真原型图**。它具体描绘了一个电商网站的 **“购物车”页面** 布局。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表,请结合以下内容与样式规范进行绘制:
+
+### 1. 整体布局逻辑:经典网页结构
+图表采用标准的 **“上 - 中-下”垂直分层布局**,模拟了浏览器窗口的显示效果。
+* **顶部(Header)**:全局导航栏。
+* **次顶部(Sub-Header)**:页面标题/面包屑。
+* **中部(Main Content)**:核心数据表格区域。
+* **底部(Footer/Action Bar)**:结算操作区域。
+
+### 2. 元素样式规范
+* **形状**:所有元素(按钮、输入框、图片占位符)均使用 **矩形**。
+* **风格**:极简黑白线稿。所有矩形均为 **白色填充,黑色细实线边框**。
+* **文字**:文字位于矩形框内部或上方,作为标签,字体清晰。
+
+### 3. 详细区域绘制指南(从上到下)
+
+**第一层:顶部导航栏**
+* **左侧**:画一个较大的横向矩形,内部文字为 **“春日蛋糕甜品”**(代表 Logo 或网站名称)。
+* **右侧**:水平排列 **7个** 小矩形按钮/链接。
+ * 前5个为导航: **“首页”**、**“所有商品”**、**“下午茶点”**、**“生日蛋糕”**、**“草莓红颜”**。
+ * 后3个为用户功能: **“登录”**、**“注册”**、**“购物车”**。
+
+**第二层:页面标题栏**
+* 在导航栏下方,画一个长条矩形,靠左放置,内部文字为 **“我的购物车”**。
+
+**第三层:商品列表表格(核心区域)**
+这是一个隐形的表格结构,分为 **表头** 和 **内容行**。
+* **表头行**:不画框,直接写文字标签,从左到右依次为: **“商品”**、**“单价”**、**“数量”**、**“小计”**、**“操作”**。
+* **内容行(商品项)**:
+ * **最左侧**:画一个 **正方形** 大框(代表商品图片占位符),内部可画个叉或写“图片”。
+ * **图片右侧**:画一个横向矩形(代表 **“蛋糕名称”**)。
+ * **数据列**:在“单价”、“数量”、“小计”下方,分别对应画 **3个** 小矩形框,内部文字分别为 **“价格”**、**“数量”**、**“价格”**(代表金额)。
+ * **最右侧**:在“操作”下方画一个矩形按钮,文字为 **“增加/减少”**。
+
+**第四层:底部结算栏**
+* 位于图表的最右下角。
+* 画两个并排的矩形框。
+ * 左边一个标签为 **“合计:”**。
+ * 右边一个按钮为 **“去结算”**。
+
+### 4. 绘图执行建议
+* **对齐**:
+ * 顶部导航的右侧按钮组右对齐。
+ * 表格内的元素(图片、名称、价格框)要严格按照上方的表头文字垂直对齐。
+* **间距**:表格行内的元素水平间距要拉大,模拟表格列的宽度;底部结算区要与上方商品列表保持较大的垂直间距。
+* **比例**:商品图片框(正方形)应明显大于价格输入框(小矩形)。
+
+按照以上规范,你就可以绘制出一张清晰的“电商购物车页面 UI 线框图”。
\ No newline at end of file
diff --git a/uml_describe/类图绘制要求.md b/uml_describe/类图绘制要求.md
new file mode 100644
index 0000000..4938c3b
--- /dev/null
+++ b/uml_describe/类图绘制要求.md
@@ -0,0 +1,54 @@
+这张图片展示的是一张标准的 **数据库实体关系图(ER Diagram, ERD)**, specifically 使用了 **IE Crow's Foot Notation(IE 乌鸦脚符号法)** 来表示关系。
+
+为了让你或他人能够绘制出完全相同风格和结构的图表(仅替换具体的表名和字段),请遵循以下**视觉与结构规范**:
+
+### 1. 整体布局逻辑:网状/链式分布
+图表采用 **非严格的网格布局**,实体(表)分布在画布的各个区域,通过逻辑关系连接。
+* **核心结构**:通常有一个或几个核心实体位于中心或关键位置,其他关联实体围绕其分布(上下左右)。
+* **排列方式**:实体框大致呈“左 - 中-右”或“上 - 中-下”的错落分布,避免线条过度交叉。
+
+### 2. 元素样式规范
+
+* **实体框(Tables/Entities)**:
+ * **形状**:标准的 **矩形框**。
+ * **内部结构**:采用 **分段式设计**。
+ * **顶部(标题栏)**:高度较窄,背景填充为 **浅灰色**(或淡蓝色),文字 **加粗** 且 **居中**,显示表名。
+ * **下部(字段区)**:高度较高,背景为 **白色**,文字左对齐,列出该表的属性/字段列表。
+ * **边框**:细黑实线边框。
+
+* **文字排版**:
+ * 字体为标准的无衬线字体(如 Arial, 宋体)。
+ * 字段列表通常每行一个属性,紧凑排列。
+
+### 3. 连接线与关系规范(关键结构)
+
+这是该图最核心的特征,必须严格遵循 **IE Crow's Foot(乌鸦脚)** 标准:
+
+* **线条类型**:
+ * 使用 **正交折线**(直角线),即线条只能横平竖直,转弯处为90度,不能使用斜线,保持画面整洁。
+ * 线条分为 **实线** 和 **虚线** 两种:
+ * **实线**:通常表示强制关系(Mandatory)。
+ * **虚线**:通常表示可选关系(Optional)。
+
+* **端点符号(基数标记)**:
+ * 线条的两端必须带有表示“一对多”关系的符号:
+ * **单竖线(|)**:表示“一”(One)。
+ * **双竖线(||)**:表示“强制一”(Mandatory One)。
+ * **圆圈(O)**:表示“零”(Zero/Optional)。
+ * **三叉线/乌鸦脚(<)**:表示“多”(Many)。
+ * **组合示例**:
+ * 一端是单竖线,另一端是乌鸦脚 = **一对多 (1:N)**。
+ * 一端是圆圈加竖线,另一端是乌鸦脚 = **零对多 (0..1 : N)**。
+
+### 4. 绘图执行建议
+
+1. **工具选择**:使用支持 ER 图的专业工具(如 Visio, Draw.io, PowerDesigner, Navicat 等),选择 "IE Crow's Foot" 模板。
+2. **配色方案**:
+ * 背景:白色。
+ * 框体:黑框。
+ * 标题栏:浅灰色填充(约 10%-20% 黑度)。
+ * 线条:黑色。
+3. **空间留白**:实体框之间保持足够的距离,以便容纳折线和关系符号,避免文字重叠。
+4. **层级感**:虽然 ER 图是网状的,但尽量将主表(如用户表、订单表)放在视觉中心或左侧,将关联表(如详情表、日志表)放在周围。
+
+按照以上规范,你可以绘制出一张专业的、工程标准的数据库设计图。
\ No newline at end of file