MagicDraw-BDD图

木头人的星辰大海

已于 2022-07-14 11:18:47 修改

阅读量2.1k

点赞数

分类专栏： MagicDraw学习笔记文章标签：学习

于 2022-07-13 15:34:44 首次发布

本文链接：https://blog.csdn.net/qq_42984090/article/details/125765272

版权

MagicDraw学习笔记专栏收录该内容

10 篇文章 27 订阅

订阅专栏

什么是BDD？

BDD是块定义图；在BDD中显示的模型元素——模块、执行者、值类型、约束模块、流说明、接口——都是其他模型元素的类型，它们会出现在其他8种SysML图中。

把出现在BDD中的元素叫做定义元素；

什么时候创建BDD？

官方说法：创建BDD的时机一般发生在执行系统工程活动中，例如：利益相关者需求分析、需求定义、架构设计、性能分析、测试案例开发、集成。

实际上：随时都可以创建BDD。

BDD的命名

BDD中头部命名的元素通常是在模型层级结构某处创建的包。

SYSML模块

定义和实例之间的区别涉及系统设计最基本的概念，并且在SysML中经常出现。

某些类型的模型元素（例如：模块、值类型、约束模块）表示对类型的定义；其他类型的模型元素（例如：组成部分属性、值属性、约束属性）代表那些类型的实例。类似于变成语言中的类定义和类实例。

什么是模块？

模块是SysML结构中的基本单元。可以使用模块为系统中或者系统外部环境中任意一种感兴趣的实体类型创建模型。模块代表的是实体的类型，而不是一个实例的类型。（有点绕）

模块就是MagicDraw中的一个个方块。

模块的注释是带有元类型<>的矩形，后面是名称分隔框中的名称，如下图所示。必须显示模块的名称分隔框。通常会显示另外的可选分隔框（如组成部分、参考、值、约束、操作、接受、标准端口、流端口、完整端口、代理端口、流属性、结构等），其中会显示模块的特性。特性有两种:结构特性（也叫做属性）和行为特性。

模块的5中结构特性（属性）

组成部分属性

模块包含的别的结构；
是一种所属关系，所属关系意味着一个组成部分属性一次只能属于一个复杂结构。一个组成部分属性可以从复杂结构的一个实例上移除，然后添加到另一个复杂结构的实例上。

<part name> : <type> [<Multiplicity>]
其中组成部分名称（part name）由建模者定义，类型（type）一般是在系统模型某处创建的模块的名称。多重性（Multiplicity）是一种约束，限制复杂对象中组成部分属性的实例数量，以单个整数或者一系列整数表示（多重性一般默认为1）。如果你想要一个组成部分属性代表任意数量的实例，那么就可以把多重性设置为0…，也就是“0或者多个”。或者，可以把多重性设置为，那是0…*的缩写。

引用属性

引用属性代表模块外部的一种结构；
不表示所属关系；
引用属性可以大概描述为“需要”的关系；
带有引用属性的模块因为某种目的需要那个外部结构，或者是为了提供一种服务，或者为了交换事件、能量或者数据。
<reference name> : <type> [<Multiplicity>]。其中引用名称（reference name）由建模者定义，类型（type）一般是在系统模型某处创建的模块或执行者的名称。多重性（Multiplicity）是引用属性能够表示的实例的数量限制。

值属性

值属性可以代表一个数字（某种类型）、一个布尔值或者一个字符串。当和约束属性结合的时候，值属性会特别有用，那样可以构建系统的数学模型。
<value name> : <type> [<Multiplicity>] = <default value>。
值的名称（value name）由建模者定义。类型（type）必须是已在系统模型中某处创建的值类型的名称。多重性（Multiplicity）是值属性能够持有的值的数量的限制。默认值（default value）是可选信息，代表它所属模块的实例第一次创建的时候赋予值属性的值。某些值属性会持有赋予的值，其他会持有从系统模型中其他值属性继承(计算)得到的值。为了表示一个值属性是继承得来的、需要在它的名称之前放置一个斜杠(/)。

约束属性

约束属性一般代表一种数学关系（一个等式或者不等式），它会使用一系列值属性。在这里所需要的模型精确度要比大多数建模项目所需要的都高。

“<constraint name> : <type>”。约束名称（constraint name）由建模者定义。类型（type）必须是已在系统模型某处创建的约束模块的名称。约束模块只是一种特殊的模块——创建它是为了封装可重用的约束表达式。最常见的情况下，约束表达式是一个等式或者不等式。

端口

代表结构边缘不同交互点的一种属性，通过那些点外部实体可以和那个结构交互——或者是提供服务，或者是请求服务，或者是交换事件、能量和数据。

当建模者为模块添加端口的时候，其实就是把一种结构针对它的环境建模为一个黑盒；结构的内部实现会对客户端隐藏。那些客户端只知道结构的接口（它所提供和请求的服务，以及能够流入、流出的事件、能量和数据的类型）。

需要特别声明的是，接口会将模块的客户端与所有特定的内部实现解耦（类似于java语言中的interface接口，但端口可以表示更加抽象的层次）。端口可以代表所需要建模的任意类型的交互点。

现在MagicDraw中有四种端口，其中（标准）端口和流端口在SYSML v1.3之后不再推荐使用，只是为了向后兼容暂时保留。

代理端口和完整端口均可以制定自己的流属性。

两种端口都具有嵌套能力。我建议尽量不要显示嵌套端口。端口的标签会占用图上的大量空间。如果你的图变得不可读，那么你从显示嵌套端口获得的任何价值都没有意义了。

显示嵌套端口可以显示多个连接器，并为每个连接器显示特定的连接点。

不同点：完整端口用于模块的组成部分属性；代理端口不代表任何物理的事物。

完整端口 full port

完整端口创建后会建立一个Block，代理端口创建后会自动创建一个Interface Block。

V1.3之后，模块所拥有的任何端口都可以指定通过该端口的流属性，也可以指定在那个端口提供和请求的服务。

完整端口代表拥有它的模块的组成部分属性一一恰好存在于那个模块边界的组成部分属性。和其他组成部分属性一样，完整端口的类型也是由模块决定的。和所有组成部分属性一样，完整端口可以拥有并执行行为，并可以拥有内部结构（也就是说，它可以拥有自己内嵌的组成部分属性）。

solar Array 完整端口可以拥有井执行行为（例如， Solar
Panel 模块中的generate Electricity 操作）。这意味着solar Array 完整端口可以接受项目，以某种方式做出响应，并可能会对其进行转换，然后输出其他项目（可能类型会与它接受的输入不同）。

代理端口 proxy port

代理端口在本质上不同于完整端口。它不代表拥有它的模块的组成部分属性。事实上，它并不代表任何物理的事物。代理端口代表拥有它的端口的外部接口。更准确的说法是，它代表了拥有它的模块（或它的组成部分属性）的行为和结构特性的子集，而且它们可以被外部模块所访问。

和完整端口不同，代理端口不会执行行为，也没有内部结构（也就是内嵌的组成部分属性）。它听起来像是其他东西的代理，“其他东西”或者是拥有它的模块本身，或者是它的内部组成部分。我能够想到的最佳比喻就是，代理端口像是位于模块边界上的门户，通过它，模块可以和外部模块交换服务和流属性的子集。

代理端口也可以定义操作，表示的是内部组成部分通过代理端口提供的对外特性。

选择使用哪种端口没有强制规定，团队内部应该形成自己的建模规范和标准。

模块之间的关系

关联

引用关联

引用属性代表模块外部的结构——模块因为某种目的需要与之连接的结构。引用属性和组成部分属性分别和经常在模块之间创建并在BDD中显示的两类关联相关：引用关联和构成关联。关联只是表示系统中这些结构化关系的另一种标识法。

BDD中引用关联的标识法是两个模块之间的实线。如果一端有箭头表示单向的访问，如果两端都没有箭头则表示双向访问（箭头端为被访问端）。

关联可以有多种标签。可以选择在线的中间位置显示关联的名称，还可以选择在线的任一端显示角色名称和多重性。

关联名称是由建模者定义的字符串，描述能够存在于两个模块的实例之间的关联类型。如下图，引用关联的名称是电力电缆，这个名称描述的是一种关联类型，它可以存在于正确组装的卫星中电子电力子系统和飞行计算机之间。其中，图中下面的BDD显示的是同一模型的等价视图，只是它使用的是引用分隔框标识法，而不是引用关联。

引用分割框标识法不直观，不好用。

组合关联

两个模块之间的组合关联表示结构上的分解。

组合端的模块实例由一些组成部分端模块的实例组合而成。BDD中组合关联的标识法是两个模块之间的实线，在组合端有实心的菱形。

泛化

表示两种元素之间的继承关系 —— 一个更加一般化的元素，叫做超类型，以及一个更具体的元素，叫做子类型。泛化的标识法是一条实线，在超类型的一端带有空心的三角箭头（如下图所示）。

泛化是可传递的。泛化表示子类型会继承超类型的所有特性：结构化特性（属性）和行为特性（操作和接收）。除了它继承的特性之外，子类型还可能拥有超类型所不具备的其他特性。因此，建模者通常会称子类型是超类型的一种特殊情况。

泛化的作用：

抽象是非常强大的设计原则；它表示的是可直换性，意味着在需要超类型的地方，也会接受子类型。这种实践在设计中创造了可扩展性。如果客户的需求在生命周期中发生变更，你需要向卫星设计中添加一种新类型的传感器，那么你只需要在系统模型中定义S e n s or 模块新的子类型，这项添加操作对于所有引用了Sensor 模块的客户端（像飞行计算机）来说都是透明的。因为所有这些原因，把泛化构建到你的模型中，在生命周期进展，你需要修改系统设计时候，它会大大减少所需的时间，这种功能会直接转化为成本上的节省。

依赖

依赖是可以在 BDD中显示的第三类关系。依赖意味着：模型中的一种元素，客户端，依赖于模型中的另一种元素，提供者。依赖表示当提供者元素发牛改变时、客户端元素可能也需要改变。

依赖在BDD中：标记是带有箭头的虚线，箭头方向从客户端指口提供者。

最常见的情况是，你在两种模型元素之间创建依赖，只是为了确立二者之间的可跟踪性。当你对设计做出变更的时候，依赖关系让你可以使用模型工具来影响下面的影响。对一种元素做出变更的时候，你可以查询模型工具，以生成模型中可能被变更影响的其他元素的列表；模型工具会遍历你在元素之间创建的一系列依赖，从而生成那个列表。

注意， Sy sML 定义了特定类型的依赖关系（例如：包导人、视点符合以及几种需求关系）。尽管依赖很少在BOD 中显示，但通常会在包图和需求图中显示特定类型的赖。