在系统建模领域，序列图作为动态行为建模的核心工具，通过元素间的消息传递直观展现交互过程。这种交互单元由特定元素构成，这些元素需具备连接能力，我们通常称其为交互角色（Interaction Roles）。
值得注意的是，序列图中的角色并非传统意义上的类或对象（这与部分建模者的理解存在差异），其本质更贴近协作场景中的类型化角色或组合结构中的组成部分。角色命名遵循"角色标识:类型标识"的格式，冒号分隔的两部分均可单独省略，但不可同时空缺。由于角色不具备对象特性，其名称禁止使用下划线标注（早期UML版本曾允许此操作）。当省略角色标识时，该位置可由符合类型的任意角色替代；若省略类型标识，则需确保该角色在当前场景中具备充分适用性，不受具体类别的限制。
在角色标识后方，可能出现用方括号包裹的选择标识符"[selector]"，该标识用于指定多值角色中的特定元素，但需注意它不属于角色名称的组成部分。实际应用中，选择标识符多采用数值索引形式，用于定位类型化元素集合中的特定成员。
下图（图示1）展示基础序列图案例：
图示1 基础序列图示例
该图呈现两个交互角色：标识为current的Patron类型角色与未命名的CirculationSystem类型角色。如前述规则，角色名称也可仅保留角色标识而省略类型信息。
序列图中的角色必须满足可连接性要求，常规绘制方式是在图表顶部以矩形框表示，框内标注角色名称（如图示1所示）。根据角色构造型差异，其可视化形式存在多种变体，常见变体如图示2所示。
图示2 角色可视化形态对比
建模实践中存在将用例图中的执行者（Actors）直接作为序列图角色的现象。但需明确的是，UML标准规定用例图的执行者不具备序列图可连接元素的资格。有趣的是，主流建模工具普遍支持这种非常规用法。当系统视角发生转换时（例如描述子系统交互），这种变通处理常被视为合理方案——此时其他交互子系统均被视作执行者，尽管它们本质上是完整系统的组成部分。包含执行者的序列图案例见图示3。
图示3 含执行者的序列图
每个角色下方延伸的虚线被称为生命周期轨迹（Lifeline），这条时间轴按垂直方向记录事件的发生序列。在图示1中，Patron角色首先向CirculationSystem发送mayIBorrowBooks消息，随后获得yesYouMay的响应消息。
从单一时间轴观察，垂直方向即代表时序关系。因此Patron端接收yesYouMay消息必然晚于其发送mayIBorrowBooks消息；而CirculationSystem端接收mayIBorrowBooks消息必然早于其发送yesYouMay消息。需注意不同时间轴上水平对齐的事件并不代表同步发生，例如mayIBorrowBooks消息在Patron端的发送时刻必定早于CirculationSystem端的接收时刻。
消息标注通常以括号结尾（如mayIBorrowBooks()）。业务建模层面由于侧重概念性交互描述，往往省略括号以保持抽象性；而在功能建模层面，括号内的参数说明则至关重要，它能精确传递实现细节信息。
常规序列图中，所有生命周期轨迹均起始于图表顶端。但存在动态创建的特殊情况，此时新轨迹的起点位于创建节点，之后便可与现有轨迹正常交互。图示4展示Lifeline2动态创建Lifeline3后，二者开展标准交互的过程。
图示4 动态生命周期轨迹创建
动态创建的生命周期轨迹自创建节点开始"存活"，而顶端起始的轨迹往往在交互开始前就已存在。同理，交互结束后各轨迹通常保持存活状态。通过终止符号"×"可明确标注轨迹的终结（如图示5），终止后的轨迹不再参与后续交互。
图示5 生命周期轨迹终止示意
相关文章
