UML课设社区健康管理系统：从建模到可运行代码的完整路径

简介这份资源是面向软件工程、UML课程设计学习者与系统分析入门者的社区健康管理系统建模资料包围绕《UML在社区健康管理系统设计中的应用》展开帮助读者理解如何用统一建模语言完成从需求到设计的完整表达。包内共16个文件以6个cpp源文件与6个h头文件为主体对应居民、医生、健康数据、健康建议等核心类的实现骨架另含2个docx设计文档、1个mdl建模文件与1个txt说明压缩包约418KB体量轻便、结构清晰。内容覆盖用例图、类图、状态图、活动图、序列图、部署图与包图等多种图形化建模视角可用于梳理健康档案管理、预约挂号、健康咨询、疾病预防与健康数据分析等模块的静态结构与动态交互。已有100人学习适合作为课设参考、建模练习与答辩材料帮助读者快速把握系统参与者、类关系与业务流程的组织方式。1. 社区健康管理系统课设一份 UML 大作业从建模到能跑起来的完整路径很多同学拿到「UML 课设社区健康管理系统」这个题目时第一反应是打开 Visio 画几张用例图、类图交差结果答辩时被追问「你的类图怎么落到代码」「健康档案和随访记录到底谁关联谁」就卡壳。这份课设真正要解决的不是画图而是用 UML 把社区健康管理这类业务讲清楚居民建档、慢病随访、预约挂号、健康宣教、数据统计这几块怎么拆成对象、怎么定关系、怎么让图能指导实现。它适合软件工程、计算机相关专业的课设或毕设前期建模也适合想补 UML 落地能力的新手。下面我按自己带课设的习惯把建模思路、工具选型、代码骨架和踩坑点一次讲透让你交上去的不只是几张图而是一套能自圆其说的设计。2. 先想清楚业务边界社区健康管理系统到底要建哪些模2.1 从「谁在用」倒推用例而不是先画框社区健康管理系统的核心角色其实不多但很容易画乱。我一般先列角色居民、社区医生、护士/随访员、系统管理员。居民关心的是建档、查报告、预约医生关心的是接诊、开随访计划、看健康档案随访员关心的是执行随访、记录指标管理员管账号和基础数据。把这四类角色的诉求列成一句话再转成用例就不会出现「登录」这种被拆成十几个用例的低级错误。常见做法是先画一张用例总图再按模块拆分子图。总图里系统边界框写「社区健康管理系统」角色放框外用例放框内。注意用例名要用「动词名词」比如「建立健康档案」「录入随访记录」不要写「档案管理」这种含糊的词否则后面类图没法对应。2.2 用例图到类图的映射规则用例图画完不能直接扔要能映射到类。我的经验是每个用例至少对应一个控制类或实体类的方法。比如「建立健康档案」用例实体类是Resident居民和HealthRecord健康档案控制类是HealthRecordService。这样后面画类图时方法名直接来自用例逻辑就顺了。下面这张表是我常用的角色-用例-类映射课设里可以直接套角色核心用例对应实体类对应控制类居民建档、预约、查报告Resident、AppointmentResidentService社区医生接诊、开随访计划Doctor、FollowUpPlanFollowUpService随访员执行随访、记录指标FollowUpRecord、IndicatorFollowUpService管理员账号管理、基础数据维护User、DictDataAdminService2.3 用活动图把「随访」这条主线跑通随访是社区健康管理里最典型的业务流程也是课设里最能体现你建模深度的地方。我建议用活动图把「医生开随访计划 → 系统生成待办 → 随访员执行 → 录入指标 → 异常触发提醒」这条线画出来。活动图里要体现判断节点指标正常走归档异常走复诊提醒。这样后面状态图就有依据。画活动图时注意泳道划分按角色分泳道不要按功能分。泳道名就是角色名动作放在对应泳道里。这样答辩时老师一眼能看出谁干什么比堆一堆文字强得多。2.4 状态图别漏掉「档案状态」和「随访状态」很多课设只画了类图和用例图状态图随便糊弄。其实社区健康管理系统里有两个状态机很关键健康档案状态新建→激活→归档和随访计划状态待执行→执行中→已完成→已取消。这两个状态图能体现你对业务生命周期的理解。画状态图时状态名用过去分词或形容词比如「已归档」「执行中」转移线上写触发事件和守卫条件。比如「待执行 → 执行中」的触发事件是「随访员接单」守卫条件是「计划未过期」。这些细节写上去图就有说服力。3. 工具选型与建模顺序别一上来就打开画图软件3.1 建模工具怎么选轻量优先别被工具绑架课设时间紧工具选错很耽误事。我一般推荐两类一类是纯画图工具比如 draw.io、StarUML、PlantUML另一类是带代码生成能力的比如 Enterprise Architect、Visual Paradigm。如果你只是想交图draw.io 足够如果你想图能导出代码骨架StarUML 或 PlantUML 更合适。PlantUML 的好处是文本化改起来快还能进 Git 管理。缺点是样式不如拖拽工具好看。我的建议是课设正文用 PlantUML 写导出 PNG 放报告里如果老师要求交源文件再补一份 draw.io 的。这样既快又稳。3.2 建模顺序用例→活动→类→状态→顺序→部署顺序错了会反复返工。我踩过的坑是先画类图结果用例没理清类图里全是拍脑袋的属性。正确顺序应该是用例图定角色和功能边界活动图跑通核心业务流程类图从用例和活动里抽实体、控制、边界类状态图补关键对象生命周期顺序图挑两三个核心场景画交互部署图说明系统怎么部署这个顺序的好处是每一步都有上一步的依据不会凭空造类。课设里顺序图不用画太多挑「居民预约」和「随访录入」两个场景就够。3.3 用 PlantUML 写类图的最小示例下面这段是我常用的类图骨架直接改类名就能用startuml class Resident { -id: String -name: String -phone: String register(): void queryRecord(): HealthRecord } class HealthRecord { -recordId: String -createTime: Date -status: String activate(): void archive(): void } class FollowUpPlan { -planId: String -planDate: Date -status: String execute(): void cancel(): void } Resident 1 -- 1 HealthRecord : owns HealthRecord 1 -- * FollowUpPlan : contains enduml这段代码里Resident和HealthRecord是一对一HealthRecord和FollowUpPlan是一对多。注意关联关系上的多重性要写清楚很多课设这里乱标导致后面数据库设计对不上。表示 public 方法-表示 private 属性这是 UML 基本规范别写反。3.4 顺序图只画关键路径别贪多顺序图最容易画成流水账。我的做法是只画两条一条是「居民预约」一条是「随访录入」。每条顺序图里对象不超过 5 个消息不超过 10 条。消息名要和方法名对应比如createAppointment()、saveRecord()。这样后面写代码时顺序图就是现成的调用链。4. 从 UML 到可运行代码把类图落成 Spring Boot 骨架4.1 类图到实体类的映射规则类图里的实体类直接对应 JPA 实体或 MyBatis 的 POJO。属性对应字段方法对应 Service 层方法。注意类图里的关联关系要转成外键或中间表。比如Resident和HealthRecord是一对一数据库里就在health_record表加resident_id外键。下面是一个实体类示例用 Java 写Entity Table(name health_record) public class HealthRecord { Id private String recordId; OneToOne JoinColumn(name resident_id) private Resident resident; private Date createTime; private String status; // 激活档案对应状态图里的「新建→激活」 public void activate() { if (NEW.equals(this.status)) { this.status ACTIVE; } } // 归档档案对应状态图里的「激活→归档」 public void archive() { if (ACTIVE.equals(this.status)) { this.status ARCHIVED; } } }这段代码里OneToOne和JoinColumn就是类图关联关系的落地。activate()和archive()方法里加了状态判断对应状态图的守卫条件。这样代码和模型是对得上的答辩时能讲清楚。4.2 控制类怎么落成 Service类图里的控制类对应 Spring 的Service。比如FollowUpService里应该有createPlan()、executePlan()、saveRecord()这几个方法方法名来自顺序图的消息。Service 里不要写太多业务逻辑复杂逻辑抽到领域服务或工具类。Service public class FollowUpService { Autowired private FollowUpPlanRepository planRepository; // 创建随访计划对应活动图里的「医生开计划」 public FollowUpPlan createPlan(String recordId, Date planDate) { FollowUpPlan plan new FollowUpPlan(); plan.setPlanId(UUID.randomUUID().toString()); plan.setPlanDate(planDate); plan.setStatus(PENDING); return planRepository.save(plan); } // 执行随访对应状态图里的「待执行→执行中」 public void executePlan(String planId) { FollowUpPlan plan planRepository.findById(planId) .orElseThrow(() - new RuntimeException(计划不存在)); if (PENDING.equals(plan.getStatus())) { plan.setStatus(RUNNING); planRepository.save(plan); } } }这里createPlan()里状态初始化为PENDINGexecutePlan()里判断状态再改和状态图完全对应。参数recordId和planDate来自用例输入别漏。4.3 数据库表怎么从类图推类图里的实体类直接转表关联关系转外键。下面这张表是我从类图推出来的核心表结构表名对应类关键字段外键residentResidentid, name, phone无health_recordHealthRecordrecord_id, create_time, statusresident_idfollow_up_planFollowUpPlanplan_id, plan_date, statusrecord_idfollow_up_recordFollowUpRecordrecord_id, indicator, valueplan_id注意follow_up_record里的indicator和value是随访指标比如血压、血糖。这两个字段别设计成固定列否则指标一多就要改表。常见做法是用纵表或者 JSON 字段存。4.4 用顺序图验证调用链写完 Service 后拿顺序图对一遍调用链。比如「随访录入」顺序图里随访员调FollowUpController.saveRecord()Controller 调FollowUpService.saveRecord()Service 调FollowUpRecordRepository.save()。如果代码里多了一层或少了一层说明模型和实现脱节了要回去改图或改代码。5. 课设避坑那些年我们画错和写错的细节5.1 用例图里把「登录」画成用例现象用例图里出现「用户登录」「修改密码」这种用例和业务用例混在一起。原因把系统功能当业务用例了。解决登录属于系统级功能放到部署图或组件图里说明用例图只保留业务价值明显的用例比如「建立健康档案」「执行随访」。5.2 类图里属性全是 String现象类图里所有属性都写String包括日期、状态、金额。原因图省事没想清楚类型。解决日期用Date状态用枚举Status金额用BigDecimal。类型写清楚后面代码生成才不会全是字符串。5.3 状态图漏了取消和异常分支现象状态图只有正常流程没有「已取消」「异常」状态。原因只画了主路径。解决随访计划要有「已取消」状态健康档案要有「异常」状态。转移线上写清楚触发事件比如「居民取消预约」触发「待执行→已取消」。5.4 顺序图消息名和代码方法名对不上现象顺序图里写saveData()代码里写insertRecord()。原因画图和写代码两拨人或者自己画完就忘了。解决顺序图消息名直接复制代码方法名或者反过来代码方法名从顺序图里抄。保持一致答辩时才能对着讲。5.5 部署图只画一台服务器现象部署图里只有一台服务器所有组件堆一起。原因没考虑分层部署。解决至少画三层——客户端、应用服务器、数据库服务器。如果课设要求不高画两台也行但别只画一台显得没设计。6. 进阶技巧让课设从「能交」变成「能讲」6.1 用 PlantUML 的 include 机制管理多张图课设图多了以后改一个类名要改好几张图。PlantUML 支持!include可以把公共类定义抽到一个文件里其他图引用。这样改一处所有图同步更新。具体做法是建一个common.puml里面定义Resident、HealthRecord这些类其他图里用!include common.puml引入。6.2 给类图加约束体现设计深度类图里可以加 OCL 约束比如「健康档案的创建时间不能晚于当前时间」「随访计划的执行日期不能早于计划日期」。这些约束写在类图下方的注释框里或者用{constraint}标注。答辩时老师看到这个会觉得你不仅会画图还懂约束。6.3 用状态图驱动单元测试状态图里的每个转移都可以写一个单元测试。比如「待执行→执行中」的测试用例创建一个PENDING状态的计划调用executePlan()断言状态变成RUNNING。这样状态图就不是摆设而是测试依据。课设里加两三个这种测试代码质量立刻不一样。6.4 部署图里加一句「本课设不涉及真实部署」课设的部署图是逻辑部署不是让你真买服务器。图里画清楚节点和组件就行旁边加一句说明「本图仅为逻辑部署示意实际部署需考虑负载均衡和安全策略」。这样既完整又不会让老师追问你服务器配置。6.5 最后检查图、代码、文档三者一致交之前做一次一致性检查用例图里的用例类图里有没有对应方法状态图里的状态代码里有没有对应枚举顺序图里的消息Service 里有没有对应方法。三者对不上答辩必被问。我一般会列一张对照表逐条打勾。这个习惯帮我省了很多后悔药。希望帮到你。本文还有配套的精品资源点击获取