全部学习汇总: ​GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!

       继续学习AUTOSAR,看一下官方文档。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_元模型

       2 UML 在 AUTOSAR 模板中的使用

       AUTOSAR 元模型被定义为 UML 模型。 因此,理解 AUTOSAR 模板文档需要 UML 的基本知识。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_子类_02

       2.1 UML 图

       AUTOSAR 模板文档中的图与 UML 2.0 一致。 即使某些元素可能未在特定图表中显示以简化理解,也假定底层模型(AUTOSAR 元模型)是完整的。

       尽管如此,类表显示了所有相关信息。

       图表的着色通常在周围的文本中进行解释。 但总的来说,浅绿色的元类是从 ASAM/MSR 中获取的。

       实例引用的表示如图 5.9 所示(参见 [TPS_GST_00044])。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_autosar_03

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_子类_04

       2.2 AUTOSAR 元模型层次结构

       AUTOSAR 模板的完整元模型层次结构如图 2.1 所示。与 OMG 使用的经典四层架构不同,显示了五个元级别。从最低、最具体的元级别开始,它们是:

       • M0:AUTOSAR 对象

       这是工作中 AUTOSAR 系统的实现:例如,执行包含挡风玻璃刮水器控制软件的软件映像的真实 ECU。

       • M1:AUTOSAR 模型

       此元级别的模型由 AUTOSAR 开发人员构建。 他们可以定义一个称为“挡风玻璃雨刷器”的软件组件,其中有一组连接到另一个软件组件的端口等等。 在这个级别上,描述 AUTOSAR 系统所需的所有工件都是详细的,包括可重用的类型以及此类类型的特定实例。

       AUTOSAR 软件被加载到各个车辆的各个 ECU 中。此加载意味着 M1 模型已实例化。

       请注意,这样的 AUTOSAR 模型可以使用从 XML 到 C 甚至 PDF 的各种格式来表示。

       • M2:AUTOSAR 元模型

       在此元级别上定义了 AUTOSAR 模板的词汇表。 这些词汇稍后可供基于 AUTOSAR 的 ECU 系统的开发人员使用。

       例如,在 M2 上定义,在 AUTOSAR 中,我们有一个名为“软件组件”的实体,其中聚合了一个名为“端口”的实体。这个定义确保 AUTOSAR 软件组件的开发人员可以描述他的特定组件及其端口。 此描述称为 AUTOSAR 模型并驻留在 M1 上。

       • M3:AUTOSAR 模板的UML 配置文件

       M2 上的AUTOSAR 模板是根据M3 上定义的元模型构建的。 如前所述,这是将 UML 与特定 UML 配置文件一起使用,以更好地支持模板建模工作。

       形式上 M2 上的模板仍然是 UML 的一个实例,但同时应用模板配置文件,即需要遵守配置文件中的构造型设置的额外规则。 配置文件的相关详细信息在第 2.3 章和第 2.4 章中指定。

     请注意,AUTOSAR 模型可以使用从 XML 到 C 甚至 PDF 的各种格式来表示。 这些格式之间的转换称为“转换”,而 AUTOSAR 模型遵循 AUTOSAR 元模型这一事实称为“实例化”。 因此,AUTOSAR 模型 (M1) 被称为 AUTOSAR 元模型 (M2) 的实例。

       小结:终于对之前各个文档中提到的M1、M2等概念有了一个明确的了解。我印象中看其他的文档的时候,我都在笔记中写了一下接下来需要注意弄清楚这些究竟是一个什么概念,现在终于找到了答案。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_元模型_05

                                   这是元模型的架构

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_开发人员_06

       2.3 构造型

       AUTOSAR 模板配置文件使用以下构造型:

       atpAbstract 适用于关系(关联、聚合)

       这表明关系是抽象的。 每个具体的子类中都需要有专门的关系来重新定义抽象关系。这种刻板印象是为了在图表中提供更好的可视化。 关系是抽象的这一事实是通过在模型中将角色定义为“派生的”来建模的。 在图中的角色名称前也用“/”表示。

       atpAbstract 的关系只存在于超类中,不会继承到子类。 它们需要在 subclasses中重新定义。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_元模型_07

       atpDerived 适用于关系(关联、聚合)

       这表明关系通过继承存在于子类中。 它进一步表明,在 M1 模型中,关系是从其他信息计算(导出)的。

       有两种类型的计算:

       – 一般

       表示通过抽象关系注释中描述的方法计算值。 例如,atpBase 被计算为第一个 atpContextElement 的容器。

       – 派生联合

       表示它是作为所有具体关系的联合派生的。

     例如,从 AtpClassifier 到 AtpFeature 与角色 atpFeature 的聚合是 atpDerived ,SwComponentType 除了组件、端口等之外还有一个 atpFeature 关联。这个 atpFeature 被计算为具体特征的并集。

       派生联合意味着对于给定的组件类型,其 atpFeature 属性保存其端口及其包含的组件原型及其包含的连接器。 这允许在抽象级别定义实例引用。

       有关详细信息,请参阅第 5 章。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_子类_08

       atpMixed 适用于类

       这仅适用于元类并指示没有混合文本的混合内容模型。

846_AUTOSAR_TPS_GenericStructureTemplate2_UML的使用1_元模型_09

       atpMixedString 适用于类

       这是具有混合文本的混合内容模型。 这仅适用于元类。

       更多详细信息请参见第 2.3.1 章节。

       这部分主要看了AUTOSAR模板中UML的使用、UML图以及UML中对AUTOSAR软件架构表达的描述方式。在这部分内容中,找到了一些之前疑惑的答案。之后,引出了构造性的分类以及简单的初步描述。