Loading... # 概述 SysML，即System Modeling Language、系统建模语言，是由对象管理组织（Object Management Group，OMG）在对UML2.0 的子集进行重用和扩展的基础上，提出的一种新的系统建模语言，以作为系统工程的标准建模语言。 SysML图包括9种，即：模块定义图、内部模块图、包图、用例图、活动图、序列图、状态机图、参数图、需求图，其中模块定义图、内部模块图、包图属于结构图，用例图、活动图、序列图、状态机图属于行为图。其具体关系如下图所示。  SysML图由元素类型和规则组成，元素类型即是SysML语言的“词汇”，规则即是SysML语言的“语法”，每种图均有各自的元素类型和规则，系统工程师在规则的约束下组织元素类型，即形成了SysML模型图。 # 用例图（Use Case Diagram) 简单来说，用例是特定的一系列动作，系统可以通过用例与外部角色来交互，以提供服务。从实践的角度，用例要定义系统边界，边界内是系统，边界外是外部角色，再按照某种规则（如时间、业务逻辑、组成单元等）对系统进行划分，形成用例。  用例图中的用例有两种连接关系，即<<include>>和<<extend>>，它们的含义如下： * <<include>> 表示一个用例包含另一个用例，即要完成包含用例就一定要执行被包含用例。 例如上图中，如果要删除用户那就必须要关闭账户。 * <<extend>> 表示一个用例扩展到另一个用例，这里有一点需要注意：在执行一个被扩展用例时，不一定执行扩展用例。即扩展用例的执行是受条件限制的，是可选的。 例如上图中，查看账户细节不一定会查看历史和查看订单。 # 模块定义图（Block Definition Diagram，BDD） 模块定义图是最常见的SysML图，可以在BDD中显示不同类型的模型元素和关系。在BDD中显示的模型元素包括模块、角色、值类型、约束模块、接口等，都是其他模型元素的类型，它们会出现在其他8种SysML图中。 BDD类似于UML中的类图。  模块（Block）是SysML结构的基本单元，可以使用模块为系统中或者系统外部环境中任意一种感兴趣的实体类型创建模型。 类似于UML的类图间的关系，SysML模块间也存在关联、泛化和依赖关系，其中关联又可以分为引用关联和组合关联。 # 内部定义图（Internal Block Diagram，IBD） 内部模块图（IBD）是系统的静态视图，制定了单个模块的内部结构，表达了系统的组成部分必须如何组合才能构建有效的系统，还会显示系统如何与外部角色相连接。 在复杂大系统设计过程中，采用IBD与BBD互相补充的方法，不仅可以描述完整的系统静态结构，还可以实现系统的组成分解、功能分配、任务和接口下发等功能，极大的提高了工作效率，减少了出错几率。  # 包图（Package Diagram） 包图是现实系统模型的组织方式时所创建的图。系统模型的组织方式由包的层级关系决定。系统模型没有唯一的正确结构，不同的方法会有不同的模型结构，项目的目标不同，模型结构产生的效果也不同。 包图会传达关于模型本身结构的信息，一旦确定了项目有效的模型结构，创建包图会很有用，可以为利益相关者提供一种针对结构容易理解的视图。  > 包图与BBD的区别 > > 包图可以显示包，也可以显示它们包含的元素：模块、执行者、值类型、约束模块、接口以及流规范。 > > BBD可以显示定义的元素——模块、执行者、值类型、约束模块、接口和流规范——以及包含它们的包。 > > **一个建议**：当想要把图的重点放在元素的定义以及它们之间的关系上时，创建BBD；当想要把图的重点放在包和它们之间的关系上时，创建包图。另外，尽管合法，但还是避免在BDD中显示包。 # 活动图（Activity Diagram） 活动图可以表示各式各样的活动，甚至可以描述最复杂的行为，活动图擅长通过行为表示事件或数据的流动，关注系统操作时，对象是如何在行为的执行过程中被修改的。 活动图的优势是可读性强，是有效的分析工具，一般情况下是首先要创建的行为图，可以使用活动图与利益相关者或项目成员沟通。  # 序列图（Sequence Diagram） 活动图可读性强，但在详细设计阶段，就不那么适用了，活动图并没有明确说明随着时间推移而发生的行为和事件的序列，也没有明确表达系统与外界、系统内部发生的交互。同时，由于活动图中并行及选择结构的存在，系统会存在多种可能性，但活动图并没有针对场景进行设计。 这时就需要序列图了，序列图是一种行为图，是对行为的精确说明，说明随着时间推移而发生的行为和事件序列。当需要精确地指定实体之间的交互、某场景内交互的时候，序列图就是非常好的选择。 序列图包括生命线、消息及组合片段等元素，序列图绘制比较灵活，可针对某场景单独绘制序列图，也可通过组合片段提供的并行、选择、循环等操作，将多场景结合在一起。  精确度和可读性不可兼得，随着行为中控制逻辑的复杂，序列图变得不可读。因此，通常用序列图作为图形化的测试案例说明书，用它来显示某单一场景。序列图表达了行为执行的顺序、哪个结构执行哪种行为、哪个结构会触发哪种行为，这是图形转换成源代码的前提。 # 状态机图（State Machine Diagram） 状态机图是一种行为图，关注的是系统中的结构如何根据随时间发生的事件改变状态。一个系统有时会拥有一系列定义好的状态，在系统操作过程中可以处以那些状态。如点灯有“打开”和“关闭”两种状态，通过对“打开开关”、“关闭开关”等事件做出响应，在状态之间迁移。状态机图中包含状态、转移线、各种节点。  # 参数图（Parametric Diagram） 参数图是一种独特的SysML图，用于说明系统的约束，这些约束一般以数学模型的方式表达。需求中的性能需求，可以在参数图中体现。通过把数学表达式（SysML中叫约束模块，ConstraintBlock）中的每个变量与模型的某个值绑定，即可向模型使用数学表达式。通过这种方式，可以创建任意复杂的数学模型，然后把它和任意复杂的系统模型的各种组成部分绑定。  # 需求图（Requirement Diagram） 基于文字的需求是系统工程中的重要产品，在SysML中，通过创建用例来替代基于文字的功能性需求，创建约束表达式来替代基于文字的非功能性需求。然而，如果项目没有创建基于文字的需求，而需要显示需求及需求与其他模型元素之间关系的时候，可以创建需求图。 需求图是非常有价值的图，可以直观的显示需求，并展示需求与其他模型元素之间的关系，可以建立需求之间，需求与包、用例、模块、约束模块之间的关系。 在需求图中可以建立的需求关系包括：包含、跟踪、继承、改善、满足、验证。 * 包含关系（include）：与包和模块一样，需求可以包含模型层次关系中其他的元素，但是比包和模块多了一种约束，需求只能包含需求。 * 跟踪关系（trace）：跟踪关系是一种弱关系，表达了一种基本的依赖关系，对提供方元素的修改可能会导致客户端元素修改的需要。 * 继承关系（derive）：继承关系表示客户端的需求继承了提供方的需求。 * 改善关系（refine）：改善关系表示客户端的元素要比提供方的元素更加具体，没有那么抽象。 * 满足关系（satisfy）：满足关系是一种断言，说明客户端模块的实例会满足提供方的需求，提供方必须是需求，没有对客户端出现的元素进行限制，一般情况下是模块。 * 验证关系（verify）：验证关系的提供方必须是需求，没有对客户端出现的元素进行限制，一般情况下是测试案例。测试案例是一种行为，可以是活动、交互或状态机，当执行的时候会证明系统满足提供方的需求。  # 参考文献 【1】德里吉提. SysML精粹[M]. 机械工业出版社, 2015. 【2】[揭开SysML神秘面纱](http://www.360doc.com/content/16/0603/19/33965478_564803114.shtml) 【3】[在用例图中，应该如何区分《include》和《extend》这两个原型？](http://www.cnblogs.com/bookideas/archive/2010/11/11/1874968.html) 【4】[【SysML】模块定义图(BDD, Block Definition Diagram)](http://blog.csdn.net/systemengineeringlab/article/details/70155392) © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏
