全部学习汇总： https:///GreyZhang/hack_autosar
继续学习AUTOSAR，看一下官方的文档。
5 AbstractStructure
抽象结构用于定义一种通过特殊化应用的模式。 抽象结构由以下几点进行建立：
• 抽象元类
• 这些元类之间的关系
——标记为 atpAbstract（参见 [TPS_GST_00022]）和/或 atpDerived（参见 [TPS_GST_00023]），
——如果它是 atpDerived 关系的目标被标记为派生的。 这在图中由角色名称前的斜线表示。
派生属性不会出现在 XML 模式中
派生意味着属性不直接在模型中，而是从模型中的其他信息以某种方式计算出来的。 例如，AtpInstanceRef 中的 base 被计算为第一个 atpContext 的容器。
因此，派生关系不会出现在 XML 模式中。
派生关系的特殊化
标记为派生的抽象关系的特化也被标记为派生的，但不一定是抽象的。 这允许指定具体的派生。
派生联合
可以选择将关系的目标标记为派生联合。 在这种情况下，属性被计算为所有具体关系的联合。 这显示在大括号中关系端的图表中。 请注意，对于此类关系，上限多重性显然需要大于 1。
抽象结构由以下方面来应用：
应用抽象结构
• 前面提到的抽象元类的子类。
• 这些子类之间的关系。 这些关系专门用于抽象元类之间的关系。
关系特殊性
有两种特殊性：
• 重新定义
重新定义完全取代了抽象关系。
• 子集
子集对抽象关系有贡献，因此可以通过构建所有子集的并集来推导出它。
特殊化显示在关系端的大括号中的图表中。 请注意，上重数等于 1 的关系只能“重新定义”而不能“子集”。 另一方面，上重数大于 1 的关系只能“子集”而不能“重新定义”。
图 5.1：抽象结构的定义和使用
5.1 可重用的结构层次
5.1.1 动机
在设计系统时，运行时空间中的元素通常共享相同的结构。 一个众所周知的示例域是面向对象编程，其中从同一类实例化的对象都具有由该类指定的相同结构。 一次指定结构然后在设计中的多个位置使用它的能力在汽车领域也很有用。 为了解决这个问题，AUTOSAR 元模型中引入了类型和原型的概念。 类型表示可重用的结构，原型表示在类型内的某个角色中使用这种结构。
考虑图 5.2 中的 M1 模型。 它显示了一个应用程序组件类型“WindowControllerType”，带有一个由“ControlInterface”输入的端口原型“ctrl”，以及一个组合类型“PowerWindowType”，它有两个组件原型，名称为“leftController”和“rightController”，两者都由“WindowControllerType”输入 ”。 因此，类型“WindowControllerType”在“PowerWindowType”组合中使用了两次，一次作为左侧控制器，一次作为右侧控制器。 请注意，尽管端口“ctrl”在“PowerWindowType”中以图形方式出现两次，但实际上仅指定一次，作为“WindowControllerType”结构的一部分。
可重用类型的概念导致平面 M1 模型指定深层、树状 M0 实例的情况。 “PowerWindowType”的 M0 实例的结构（部分）显示在 5.3 中。 可以看出，有两个实例对应于“ctrl”端口，在M1中定义了一次。
事实证明，这种不同角色中的结构重复也会对 M1 模型的水平产生影响。 回到图 5.2，“PowerWindowType”组合还包含一个由“MainControllerType”键入的组件原型“mainController”，它具有左右控制端口。 组合体内部的连接器将左车窗控制器的端口连接到主控制器的左端口，将右车窗控制器的端口连接到主控制器的右端口。
回想一下，尽管左右控制器的“ctrl”端口在图中以图形方式出现了两次，但实际上它们在 M1 规范中只出现了一次 - 类型为“WindowControllerType”。 但是为了很好地定义连接器（例如在 XML 描述中），必须有一种方法可以在 M1 模型规范中区分这两个未来的 M0 实例。 这是因为我们需要将左侧实例附加到主控制器的“leftCtrl”端口，将右侧实例附加到“rightCtrl”端口。 所以问题是如何引用源自相同 M1 模型元素的不同的潜在 M0 实例。 这通过实例引用的概念来解决。
下一节介绍类型、原型和结构元素的抽象层，并提供对这些概念的更详细说明。 下一篇介绍了实例引用的抽象层，并更详细地解释了这个概念。
这次的梳理暂且到此，正好看完了一个大章节中的一个部分。这部分主要是介绍了可重用的架构以及其设计的动机。
