1. 为什么需要从对象思维开始我第一次接触UML2建模时犯了一个典型错误直接打开工具画图。结果画出来的类图就像数据库表设计完全失去了面向对象的精髓。后来才明白UML2的核心不是画图工具而是一种对象思维的表达方式。对象思维与传统结构化思维最大的区别在于看待问题的方式。举个例子设计一个图书馆管理系统时结构化思维会问系统需要哪些功能然后列出借书还书查询等功能模块对象思维则会问系统涉及哪些实体先识别出读者图书借阅记录等对象这种思维转变带来的好处是显而易见的。去年我参与的一个电商项目初期用结构化方法设计了二十多个功能模块后期需求变更时牵一发而动全身。改用对象思维重构后核心领域对象商品、订单、用户保持稳定只需调整对象间的协作方式就能适应新需求。2. UML2核心元素实战解析2.1 类图不只是画方框很多初学者把类图画成了方框连线的简单游戏其实每个元素都有深意。来看一个支付系统的例子class Payment { amount: Double status: PaymentStatus process(): Boolean refund(): Boolean } class CreditCardPayment { cardNumber: String expiryDate: Date process(): Boolean } Payment |-- CreditCardPayment这个简单的类图至少传达了五层信息抽象层级Payment是抽象概念CreditCardPayment是具体实现封装边界外部只能调用process()和refund()方法继承关系箭头方向表明泛化关系多态可能所有子类都可以被当作Payment处理状态管理status字段暗示有状态转换2.2 时序图对象协作的导演脚本我曾用时序图重构过一个混乱的订单流程效果立竿见影。关键是要把握三个要点生命线代表对象实例不是类消息箭头类型同步/异步决定调用方式组合片段(alt, loop等)是流程控制的语法糖participant Customer as C participant OrderSystem as O participant PaymentGateway as P C - O: submitOrder() O - O: validate() alt 验证通过 O - P: processPayment() P -- O: paymentResult O - C: confirm() else 验证失败 O - C: reject() end这个图清晰地展示了订单提交的完整流程分支逻辑的处理方式各对象的职责边界3. 从需求到设计的转换技巧3.1 名词动词分析法这是我常用的需求分析方法分三步走标出需求文档中的所有名词→候选对象标出所有动词→候选方法分析名词间的关系→类关联例如读者借阅图书这个需求名词读者、图书动词借阅关系读者与图书之间存在借阅关联3.2 四色原型建模法对于复杂领域我推荐使用四色原型时刻间隔(Moment-Interval)代表业务事件如借阅记录角色(Role)参与者身份如读者角色物品(Thing)物理对象如图书副本描述(Description)元数据如图书分类这种方法特别适合需要追溯历史状态的系统比如图书馆的借阅历史管理。4. 高级设计模式在UML中的表达4.1 策略模式实现支付系统最近一个电商项目中我们这样设计支付模块interface PaymentStrategy { pay(amount: Double): Boolean } class CreditCardStrategy { -cardNumber: String pay(amount: Double): Boolean } class AlipayStrategy { -accountId: String pay(amount: Double): Boolean } class PaymentContext { -strategy: PaymentStrategy setStrategy(s: PaymentStrategy) executePayment(): Boolean } PaymentStrategy |.. CreditCardStrategy PaymentStrategy |.. AlipayStrategy PaymentContext o-- PaymentStrategy这个设计带来了三个好处新增支付方式不影响现有代码可以在运行时切换策略业务逻辑与支付实现解耦4.2 状态模式处理订单生命周期订单状态管理是个经典问题用状态模式可以优雅解决class Order { -state: OrderState process() cancel() } interface OrderState { process(o: Order) cancel(o: Order) } class NewState { process(o: Order) cancel(o: Order) } class PaidState { process(o: Order) cancel(o: Order) } Order -- OrderState OrderState |.. NewState OrderState |.. PaidState实际项目中我们还用状态图补充说明了状态转换规则确保业务逻辑清晰可见。5. 团队协作中的UML实践要点5.1 建模规范三原则在带领团队实践UML建模时我制定了三个铁律一图一用每张图只表达一个视角结构/行为/交互三层抽象概念层→规格说明层→实现层逐步细化两维验证静态结构图与动态行为图要能互相印证5.2 模型版本控制技巧UML图也要纳入版本管理我们的做法是使用PlantUML等文本化建模工具按功能模块分目录存储提交时附带变更说明重要版本生成图片归档这样在回溯设计决策时可以清晰地看到演进过程。6. 常见陷阱与应对策略6.1 过度建模问题曾见过一个系统设计了200多个类最后根本无法维护。我的经验法则是核心领域模型不超过30个类单个包内的类不超过7±2个继承层次不超过3层当发现模型过于复杂时应该检查是否违背了单一职责原则考虑引入门面模式简化接口重新评估抽象层级是否合理6.2 性能与模型的平衡有个项目初期严格按DDD建模结果查询性能很差。我们的解决方案是写操作仍用领域模型读操作使用专门的DTO和查询模型通过CQRS模式实现读写分离这样既保持了设计的纯洁性又满足了性能要求。
