UML统一建模语言中三种重要的行为图它们各自关注系统动态行为的不同侧面时序图Sequence Diagram强调对象间消息传递的时间顺序。核心元素包括对象生命线Lifeline垂直虚线表示对象在一段时间内的存在顶部为矩形框标注对象名如:Order或customer:Customer激活框Activation Bar / Execution Occurrence生命线上方的窄矩形表示对象正在执行某操作的时间段消息Message带箭头的水平实线同步调用、虚线返回消息、带空心箭头的虚线异步信号按自上而下严格时序排列体现调用先后与嵌套关系如自调用、循环、条件片段用alt/opt/loop等组合片段标注。活动图Activity Diagram类比“增强版流程图”侧重业务流程或操作逻辑的控制流与数据流。关键元素包括动作节点Action圆角矩形表示原子操作如“验证用户”控制流Control Flow实线箭头表示执行顺序分支与合并Decision Merge Nodes菱形节点含守卫条件如[balance 0]支持多出口分支与单入口合并分叉与汇合Fork Join Nodes粗横线实现并发并行执行如同时发送邮件和短信还可包含泳道Swimlane划分责任主体如“用户”“系统”“支付服务”。状态图State Machine Diagram刻画单个对象在其生命周期内响应事件所经历的状态变化。核心要素有状态State圆角矩形含状态名如Processing可含内部活动entry/exit/do行为转移Transition带箭头实线连接两状态标注格式为事件[守卫条件]/动作如submit[valid]/startProcessing()初始状态⚫与终止状态⚪分别表示状态机起点与终点支持复合状态正交区域、历史状态等以建模复杂行为。三者关系互补时序图聚焦“谁在何时对谁做了什么”活动图聚焦“整个流程如何流转与并发”状态图聚焦“一个对象如何随事件改变自身状态”。startuml title 简化订单状态图示例 [*] -- Created Created -- Paid : pay[amount0] Paid -- Shipped : ship Shipped -- Delivered : deliver Delivered -- [*] enduml在UML时序图中条件判断如“仅当库存充足时才发送发货通知”不能直接在单条消息上标注守卫条件如[stock ≥ required]——这是常见误区。UML标准2.5明确规定普通消息箭头本身不承载守卫条件条件逻辑必须通过组合片段Combined Fragment来显式建模。✅ 正确做法使用altalternative组合片段alt片段用于表示互斥的条件分支其内部包含一个或多个交互片段Interaction Operand每个Operand带有一个守卫表达式guard格式为[条件]且仅有一个Operand可执行满足守卫条件者。 示例建模步骤将涉及条件的消息如“发送发货通知”及其前置/后续相关操作整体包裹在alt片段内定义两个Operand[库存充足]→ 包含checkStock()返回 true 后发出sendShippingNotice()消息[库存不足]→ 包含发出sendOutOfStockAlert()或触发补偿流程所有生命线在alt区域内保持连续激活框随分支动态伸缩。 文本示意PlantUML 风格alt [库存充足] inventory:Inventory - order:Order : checkStock() order:Order -- warehouse:Warehouse : sendShippingNotice() else [库存不足] order:Order -- customer:Customer : sendOutOfStockAlert() end⚠️ 补充说明optoption片段适用于单条件可选执行如[isExpress] sendExpressLabel()等价于alt [cond] ... else [else] skip守卫条件应语义清晰、可判定避免模糊表述如“通常足够”且通常基于已知属性或前序消息返回值条件判断的决策点本身如 if 判断逻辑一般不建模为独立对象而是隐含在片段控制逻辑中若需强调决策对象可用decision节点属活动图范畴时序图中不推荐。