类图 – 类图建模实战：从需求到设计的全流程 🛠️

关键字：词汇建模、协作建模、数据库建模

1. 对系统的词汇建模：定义系统的“核心概念”📚

把业务中的“实体”转化为类，明确每个类的职责、属性和操作——比如图书馆系统中的“读者”“图书”“借阅记录”，都是系统词汇。

步骤：
– 识别业务中的实体（比如从用例中找“谁在做什么”）；
– 给每个实体分配职责（比如“读者负责借阅图书”）；
– 补充属性（比如“读者有姓名、学号”）和操作（比如“读者可以‘借阅()’”）。

2. 对简单协作建模：描述类之间的“互动逻辑”🤝

类不是孤立的，要描述类如何协作完成功能——比如“订单类”和“支付类”协作完成“支付订单”的流程。

步骤：
– 识别要完成的功能对应的“机制”（比如“支付机制”）；
– 找出参与协作的类、接口；
– 定义类之间的关系（比如“订单关联支付”），并检查逻辑是否合理。

3. 对逻辑数据库建模：把类映射为“数据库表”🗄️

类图可以替代 E - R 图，把需要“永久存储”的类转化为数据库表——比如“用户类”对应“用户表”，类的属性对应表的字段。

步骤：
– 识别需要永久存储的类（比如“订单”“用户”）；
– 细化类的属性（比如“订单号”设为唯一主键）；
– 简化复杂关系（比如把 N 元关联拆成多个二元关联）。

关键字：正向工程、逆向工程、模型与代码同步

🚀 正向工程：从类图生成代码

把类图中的类、属性、操作映射为编程语言代码（比如 Java 类）——但 UML 比代码更丰富，会有部分信息丢失（比如抽象类的注释）。

🔍 逆向工程：从代码生成类图

把已有的代码（比如 Java 文件）转化为类图，方便梳理现有系统的结构——但代码中的细节（比如局部变量）不会显示在类图中，需要人工补充信息。

关键字：SOLID 原则、开闭原则、里氏替换原则

1. 开闭原则（OCP）：对扩展开放，对修改关闭 ✨

新增功能时，不修改原有代码，而是扩展新类——比如订单支付功能，新增“支付宝支付”时，不用改订单类，只需新增“支付宝支付类”实现“支付接口”。

❌ 坏设计：订单类直接关联“微信支付类”“支付宝支付类”，新增支付方式要改订单类；
✅ 好设计：订单类关联“支付接口”，所有支付类实现该接口，新增支付方式只需加新类。

2. 里氏替换原则（LSP）：子类可以完全替代父类 👨‍👦

子类必须能“无缝替换”父类，不会破坏原有逻辑——比如“正方形类”继承“矩形类”后，不能修改“设置宽高”的逻辑（否则替换后会出错）。

3. 依赖倒置原则（DIP）：依赖抽象，不依赖具体 🔧

高层模块（比如“订单类”）不直接依赖低层模块（比如“微信支付类”），而是依赖抽象（比如“支付接口”）——这样低层模块变化时，高层模块不用改。

4. 接口分离原则（ISP）：接口要“小而专”，不要“大而全”🧩

不要设计“万能接口”，要拆分出细粒度的接口——比如“动物接口”拆成“会游泳接口”“会飞接口”，让不同动物只实现自己需要的接口。

5. 单一职责原则（SRP）：一个类只做一件事 🎯

每个类只有一个职责——比如“订单类”只负责订单信息，“支付类”只负责支付逻辑，不要把两者混在一个类里。

从需求出发，先识别“用户”“机票”“订单”等核心类，定义类的属性（比如“机票有航班号、日期”），再描述类之间的关系（比如“用户关联订单”“订单关联机票”），最后遵循设计原则优化（比如用接口实现不同的支付方式）。

🎉

类图建模不仅是“画类和关系”，更是用设计原则让系统“易扩展、易维护”——掌握这一套流程，就能从业务需求转化为健壮的面向对象设计啦~

要不要我帮你整理一份 类图建模的步骤清单，方便你按流程完成自己的类图设计？

一、类图建模的 3 种核心用法：覆盖系统设计全场景 📌