学习建模语言只是MBSE路上的第一步。建模语言会定义 语法 ：决定特定模型的形式是否良好的一系列规则。那些规则不会指定如何和什么时候使用语言来创建模型；也不会指定任何特定的建模方法。

相反， 建模方法 类似于路线图；它是建模团队创建系统模型要执行的一系列设计任务的文档。更准确的说法是，它是确保团队中所有人都以一致的方式构建模型，并朝着同一个目标努力的文档。没有这样的指导，团队中每个成员构建到系统模型中的内容就会在广度、深度和准确度方面有很大区别。

和所有项目类似，MBSE项目也需要一个计划，而每个计划首先要声明目的。你的团队首先要回答以下问题：你为什么要建模？更准确的说法是，建模工作期望得到什么结果？你创建的模型是否只作为所有设计决定的权威中心记录？你是否需要从模型自动生成文本产出物，用于评审和批准？你会使用模型来管理需求可跟踪性，并执行下游影响分析吗？你会使用模型来执行另一种配置的优劣势研究吗？系统模型会与专门的公式计算工具和模拟工具整合，以直接执行模型吗？模型本身会是下游设计和开发团队工作——像软件、硬件、可靠性/可用性/性能分析——的输入项吗？模型会包含在开发后验证系统程序集的整合测试以及接受性测试的案例吗？这些问题的答案会决定团队建模工作的 目的 。

一旦你的团队已经明确了那些目的，你就可以回答一系列新问题。系统的外部环境有多少需要建模？系统的哪些部分需要建模？哪些行为需要建模？你需要以多么深入的程度解析内部结构和行为？在模型中需要有哪些细节？哪些细节可以忽略（可以留给开发团队在实现的时候细化）？这些问题的答案会决定构建系统模型的 范围 。

对范围的定义会设置团队工作的目标；它让你的团队可以决定模型何时才算完成。说得直白一点，你的团队需要随着时间的推移让模型不断发展，因为需求会改变，团队会做出新的设计决定。在这种情境下，“完成”意味着模型满足了你在项目计划中概述的目的。

模型的范围还决定了团队将会遵循的建模方法。文献已经记录了多种建模方法。你的团队可以采纳其中一种已经存在的方法，对其进行剪裁以满足你的需要和目的。如果没有一种适合你，那么还可以创建自定义的建模方法。然而，那些内容不在本书的讨论范围之内。

这里的重点在于帮助你精通SysML这门建模语言，而不是教你某种特定的建模方法。SysML与方法无关；你可以使用SysML创建系统模型，不管你认为对于自己的需求哪种建模方法最合适。然而，我在此使用了一些篇幅来列举一些众所周知的建模方法（以及一些参考，其中提供了更深入的内容）来帮助你。

· 方法 ：INCOSE面向对象系统工程方法（Object Oriented Systems Engineering Method，OOSEM）

· 参考 ：Friedenthal、anford等著，《A Practical Guide to SysML，Second Edition：The Systems Modeling Language》（Boston：MK/OMG出版社，2011）

· 方法 ：Weilkiens系统建模（System Modeling，SYSMOD）方法

· 参考 ：Weilkiens、Tim著，《Systems Engineering with SysML/UML：Modeling，Anal-ysis，Design》（Boston：MK/OMG出版社，2008）

· 方法 ：IBM Telelogic Harmony-SE

· 参考 ：Hoffmann、Hans-Peter著，“（Harmony-SE/SysML Deskbook：Model-Based Systems Engineering with Rhapsody）”，Rev.1.51，Telelogic/I-Logix白皮书（Telelogic AB，2006年5月）

这些建模方法广泛分布在系统工程生命周期的多个阶段中。并非这些方法规定的所有步骤都适用于你的项目。你所采用的任何建模方法都需要剪裁，以满足你的项目的特殊需要。不过，这些方法都是很好的开始。 5IbUHfKQ+bbCoU5aarw/BKNIsZignS+Dh1yya+q2GBCBIBcI6OP/jv4FspgdY8UT