UML 2.5 实战：从需求到类图的 3 步建模法（附公务员招考系统案例）

在软件工程实践中，UML类图设计往往是初学者最易卡壳的环节。教科书上的理论定义看似清晰，但面对实际业务需求时，如何准确识别类、属性和关系？本文将以公务员招考系统为例，拆解一套经实战验证的三步建模法，帮助开发者跨越从理论到实践的鸿沟。

1. 需求文本的语义解构技术

自然语言描述的需求文档是建模的起点，但直接跳转到画图常导致关键元素遗漏。有效的语义解构需要系统化的文本标记技术：

[考生] [报名]时需提交[身份证号][姓名][报考专业]（行政/法律/财经）， 招考办为每位考生生成唯一[准考证号]。[用人单位]公布各专业[招聘人数]， 考试后招考办发布[成绩单]并确定[录取分数线]，按专业对考生[总分]排序。 [录用单位]根据排序结果发放[录用通知书]，副本留存招考办[备案]。

标记规则：

• 方括号标注候选类名（如考生、用人单位）
• 圆括号标注枚举值（如专业类型）
• 下划线标注候选属性（如身份证号、总分）
• 波浪线标注关键操作（如报名、排序）

注意：同一名词在不同语境可能属于不同类别，例如"招考办"作为组织机构是候选类，而作为动作主体则提示需要操作方法。

2. 候选类筛选与关系推导

通过语义解构得到的初始元素需要经过严格过滤。下表展示公务员系统中的核心类筛选过程：

关系推导技巧：

1. 组合关系：当部分对象不能脱离整体存在时（如考生与成绩单）
2. 聚合关系：当部分对象可独立于整体存在时（如用人单位与岗位）
3. 依赖关系：临时性使用（如录用流程调用成绩计算服务）

// 专业枚举类示例 public enum MajorType { ADMINISTRATIVE, // 行政 LEGAL, // 法律 FINANCE // 财经 }

3. 类图精炼与模式应用

初步类图往往存在结构冗余，需要通过设计模式进行优化。公务员系统的典型问题及解决方案：

问题1：多专业录取规则差异

• 原始方案：在考生类中硬编码专业判断逻辑
• 优化方案：采用策略模式封装录取算法

@startuml interface AdmissionStrategy { +isAdmitted(Applicant): boolean } class AdministrativeStrategy implements AdmissionStrategy class LegalStrategy implements AdmissionStrategy class FinanceStrategy implements AdmissionStrategy class Applicant { -major: MajorType -scores: Map<Subject, Double> +calculateTotalScore(): double } class AdmissionService { -strategy: AdmissionStrategy +setStrategy(MajorType) +checkAdmission(Applicant): boolean } Applicant --> AdmissionService AdmissionService o--> AdmissionStrategy @enduml

问题2：录用状态追踪

• 原始方案：简单使用布尔标志位
• 优化方案：状态模式管理全生命周期

@startuml interface ApplicantState { +nextState(): void +printNotice(): void } class RegisteredState implements ApplicantState class ExamTakenState implements ApplicantState class AdmittedState implements ApplicantState class RejectedState implements ApplicantState class Applicant { -state: ApplicantState +changeState() +printNotice() } Applicant --> ApplicantState @enduml

4. 公务员系统完整类图实现

综合上述技术，最终类图需体现三个设计层次：

1. 业务实体层（红色区域）：

   • Applicant（考生）
   • Department（用人单位）
   • ExamPaper（考卷）

2. 流程控制层（蓝色区域）：

   • AdmissionController（录取控制器）
   • ScoreCalculator（成绩计算器）
   • NoticeGenerator（通知生成器）

3. 基础设施层（绿色区域）：

   • PDFExporter（PDF导出服务）
   • SMTPClient（邮件发送客户端）
   • DatabaseAccess（数据库访问对象）

关键关联关系说明：

• Department与Position为1对多聚合关系
• Applicant与ExamResult为组合关系
• AdmissionService依赖ScoringPolicy接口

提示：实际建模时应使用颜色区分不同层次，但交付版本建议转为黑白图示以避免工具兼容性问题。保持每个包的类数量不超过7±2个，符合米勒定律的认知负荷原则。

5. 建模质量检查清单

完成类图设计后，使用以下checklist进行验证：

1. 完整性验证：

   • [ ] 所有需求文档中的名词是否都有对应模型元素？
   • [ ] 每个类的必要属性是否完整？
   • [ ] 跨类操作是否明确了调用关系？

2. 一致性验证：

   • [ ] 同类关系是否使用相同建模方式？（如全部使用接口或全部使用继承）
   • [ ] 相似业务概念是否采用统一命名规范？

3. 可扩展性验证：

   • [ ] 新增专业类型是否需要修改核心类？
   • [ ] 成绩计算规则变化是否影响其他模块？

4. 性能考量：

   • [ ] 频繁访问的属性是否设置为派生属性？
   • [ ] 关联关系的导航方向是否优化？

在公务员系统案例中，我们特别增加了AdmissionCache类来缓存录取排序结果，避免每次访问都重新计算排名。这种实现细节虽然不必体现在概念模型阶段，但在详细设计时必须考虑。