系统建模语言（通常称为SysML）是一种专为系统工程应用设计的建模语言。它旨在捕捉、分析和设计复杂系统。无论您是在从事航空航天项目、汽车设计还是软件架构，理解术语对于利益相关者之间的清晰沟通都至关重要。本指南解析了该领域中使用的核心词汇，帮助您清晰地掌握技术领域。
系统建模语言入门 🏗️
SysML扩展了统一建模语言（UML），以更好地满足系统工程的需求。虽然UML主要关注软件，但SysML涵盖了系统的物理、信息和行为方面。它依赖于一组图表和元素来描述系统如何运作。掌握这些术语使工程师能够创建既精确又易于理解的模型。
刚开始时，经常会遇到缩写词和特定定义。本术语表涵盖了您在图表和文档中常见到的最频繁的术语。目标是提供上下文，而不仅仅是定义，以确保您理解每个术语在整体建模工作中的作用。
核心结构元素 🔨
系统的结构定义了其物理或逻辑组成。在SysML中，这主要通过“块”（Blocks）来描述。块代表一个结构单元，可以是组件、零件或系统本身。它是定义系统由什么构成的基本构建块。
- 块： 具有明确定义接口和行为的结构单元。它封装了功能和数据。
- 零件： 在更大块结构内的一个块的具体实例。它表示系统内部的一个组件。
- 属性： 块的一个属性，用于描述数据或特征。属性可以具有类型，例如整数或字符串。
- 引用属性： 一个链接到另一个块实例的属性。这创建了一种连接关系，但不包含所有权。
- 值属性： 一个持有简单值（如数字或文本）的属性，而不是对另一个对象的引用。
理解块与零件之间的区别至关重要。块定义类型，而零件定义配置中的具体实例。例如，一个发动机 可能是一种块类型，而一辆发动机 安装在一辆汽车 中的发动机则是一个零件。
理解需求 📝
需求定义了系统必须执行的功能或必须满足的约束条件。它们是验证和确认的基础。在SysML中，需求被视为一等公民，可以与模型中的其他元素建立关联。
- 需求： 必须满足的条件或能力。它是可追溯到模型其他部分的特定元素。
- 追溯： 表示一个元素源自或满足另一个元素的关系。常用于将需求与设计元素关联。
- 细化： 一种关系，表示一个元素比另一个元素提供更详细的信息。例如，一个高层次的需求可能会被细化为详细规范。
- 满足： 一种关系，表示一个设计元素满足某个特定需求。
- 验证： 一种关系，表示一个测试用例或活动确认了需求已满足。
有效的需求管理可确保最终产品符合利益相关者的需求。使用追踪功能可使工程师看到变更的影响。如果需求发生变化，您可以向下追踪，查看哪些设计模块或行为受到影响。
行为图 🔄
行为描述了系统随时间或对事件的响应方式。SysML 支持多种图类型来可视化这种行为。每种类型根据交互的复杂程度服务于特定目的。
活动图
活动图关注控制流和数据流。它们类似于流程图，但增加了对并发活动和对象流的支持。
- 活动： 由事件触发的计算阶段。它是活动图中的主要元素。
- 控制流： 活动发生的顺序。它决定了执行的顺序。
- 对象流： 活动之间数据或对象的移动。它展示了哪些内容被生成和消耗。
- 输入端口： 活动接收数据或对象的点。
- 输出端口： 活动发送数据或对象的点。
状态机图
状态机建模了元素可能处于的不同状态以及它如何根据事件在这些状态之间转换。
- 状态： 对象生命周期中的一个条件或情况，在此期间对象执行某些活动或等待事件。
- 转换： 从一个状态到另一个状态的移动。转换由事件触发。
- 事件： 在特定时间发生的某种事情，导致状态转换。它可以是信号、调用、时间延迟或条件的变化。
- 保护条件： 一个布尔表达式，必须为真才能发生转换。
- 历史： 一种伪状态，用于记住复合状态的最后一个活动子状态。
顺序图
顺序图展示了对象随时间的交互。它们有助于理解系统各部分之间消息的流动。
- 生命线： 表示类或对象在时间上的一个实例。
- 消息： 一个对象到另一个对象的通信。它可以是同步的或异步的。
- 激活： 对象执行操作的期间。
- 组合片段： 交互的分组，例如循环或可选部分。
关系与连接 🔗
关系定义了元素之间如何相互作用。它们是将模型连接在一起的粘合剂。选择正确的关系对于准确建模至关重要。
| 关系 | 描述 | 用例 |
|---|---|---|
| 关联 | 一种结构关系，表示一种类型的对象与另一种类型的对象相连。 | 一般连接，无所有权。 |
| 聚合 | 整体-部分关系，其中部分可以独立于整体存在。 | 弱所有权，例如部门拥有员工。 |
| 组合 | 强整体-部分关系，其中部分不能脱离整体而存在。 | 强所有权，例如房屋拥有房间。 |
| 泛化 | 父子关系，其中子类从父类继承特性。 | 类层次结构或继承。 |
| 实现 | 一种关系，其中一个元素实现另一个元素的接口。 | 接口实现。 |
聚合和组合常常被混淆。关键区别在于生命周期管理。在组合中，如果整体被销毁，其部分也会被销毁；而在聚合中，部分在整体被销毁后仍然存在。
约束和参数 📏
并非所有信息都能通过视觉方式捕捉。约束允许您添加必须遵守的规则。参数有助于定义与系统相关的数值。
- 约束块： 一种表示一组约束的块类型。它可以应用于其他模型元素。
- 约束属性： 约束块中表示特定规则的属性。
- 参数块： 用于定义系统参数的块。它包含可设置的变量。
- 参数属性： 参数块中的属性。这些通常用于尺寸设定或配置。
- OCL（对象约束语言）： 一种用于指定约束的正式语言。它允许进行精确的数学定义。
使用约束可确保模型遵循物理定律或业务规则。例如，一个约束可能规定车辆的重量不能超过某个限制。参数允许您通过更改这些值来运行模拟，而无需改变结构。
关键图表概要 📊
为了帮助记忆，以下是该语言中可用的主要图表类型的概要。每种图表在建模生命周期中都有其独特的作用。
| 图表类型 | 关注点 | 主要元素 |
|---|---|---|
| 块定义图（BDD） | 结构与分类 | 块、关系、需求 |
| 内部块图（IBD） | 内部结构 | 部件、属性、流 |
| 需求图 | 需求管理 | 需求、追溯、细化 |
| 用例图 | 功能需求 | 参与者、用例、关系 |
| 活动图 | 行为流程 | 活动、流程、泳道 |
| 状态机图 | 状态转换 | 状态、转换、事件 |
| 顺序图 | 随时间变化的交互 | 生命线、消息、激活 |
| 参数图 | 约束与方程 | 约束、参数、变量 |
在实际场景中应用术语 🌍
了解定义只是第一步。正确应用这些术语需要理解工作流程。典型的建模过程从需求开始。您可以通过需求图来定义系统需要完成的任务。
接下来，您使用块定义图来定义系统结构。在这里，您为主要组件创建块并定义它们之间的关系。您可以使用组合关系来表明系统由子系统构成。然后，使用内部块图来展示这些组件如何在内部连接。在这里，您定义数据流和接口。
接下来建模行为。如果系统具有复杂逻辑，适合使用状态机图。如果涉及流程，活动图更为合适。顺序图有助于澄清操作过程中特定部分之间的交互。
最后，使用参数图添加约束。这确保了物理限制得到遵守。在整个过程中，追溯关系将所有内容与原始需求联系起来。这确保了每个设计元素都有利益相关者定义的明确目的。
常见的错误陷阱，需避免 ⚠️
即使是经验丰富的工程师在定义术语时也可能出错。了解常见错误有助于保持模型质量。
- 过度使用泛化：除非必要，否则不要创建过深的继承层次。这会使模型变得复杂。
- 结构与行为混用：将结构图与行为图分开。不要在块定义图中放入行为逻辑。
- 忽略追溯：未能将需求与设计元素关联，会使验证变得困难。
- 模糊的约束： 避免编写模糊的约束条件。使用OCL以确保精确性。
- 忽略参数： 未能定义参数会限制系统仿真或分析的能力。
术语总结 📚
掌握系统建模语言的术语是一个过程。这需要实践和接触真实模型。通过理解诸如块、需求和关系等核心术语，你可以打下坚实的基础。本术语表提供了一个参考点，但真正的熟练程度来自于实际应用。
一致性是关键。确保在整个项目中统一使用术语。当利益相关者理解这种语言时，沟通将得到改善。这可以减少错误并加快开发进度。现代系统的复杂性要求精确的建模，而准确的术语正是实现这一点的工具。
在继续使用这些概念时，遇到不熟悉的术语可随时参考本指南。元素之间的关系往往比定义本身更为重要。关注各部分如何连接形成整体。这种整体性视角正是系统工程的本质。