全部學習彙總： https://github.com/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”，它具有左右控制端口。 組合體内部的連接配接器将左車窗控制器的端口連接配接到主要制器的左端口，将右車窗控制器的端口連接配接到主要制器的右端口。