ara::com 与 AUTOSAR 元模型的关系总结
原文链接：AUTOSAR_EXP_ARAComAPI的7章笔记（6）
整体说明
先是表明此前解释 ara::com API 思想和机制时未涉及具体 AP 元模型清单部分，本章旨在阐明 ara::com 与相关元模型部分的关系，且是较高层次的基本理解性介绍，并非对 AUTOSAR 元模型的全面阐释。
与 AUTOSAR_TR_AdaptiveMethodology 的关联
- 相关元素及关联情况：介绍了服务接口、部署等元素间相互关联受部署信息影响。AUTOSAR 自适应平台方法学涵盖构建自适应系统的过程、活动、工作产品以及相关角色等内容。
- AP 软件开发步骤及相关作用：AP 软件开发有架构和设计、软件开发、集成和部署等主要步骤。其中集成和部署步骤对 ara::com API 工作意义重大，能生成聚合服务接口和端口的 ARXML 文件。AP 应用程序依靠服务接口和端口交换信息，AP 平台的提供端口与所需端口分别用于生成服务骨架类和代理类，二者借此与其他平台集群、应用程序通信。此外还提及服务实例配置及其在清单中的体现，以及 Executable 的实例化特点与执行清单的作用。
服务接口
从 ara::com 角度看，服务接口是最重要的元模型元素，它定义了 ara::com 代理或骨架的签名相关内容，5.1 节内容可看作是其简化版本，且明确 ara::com 的代理类和骨架类由服务接口生成。
软件组件
- 定义与表达：AUTOSAR 方法论中软件组件是比接口更高层次元素，用良好定义的接口描述可重用软件部分。AUTOSAR 清单规范定义了 SoftwareComponentType 模型元素，其有具体子类型，其中 AdaptiveApplicationSwComponentType 对 AP 应用软件开发人员最重要，该元素由 C++ 代码实现，通过端口表达组件对外提供或需要的服务接口，提供端口和所需端口有不同表意。
- 代码实现与重用情况：结合图展示了模型视图与代码实现的关联，软件组件类型 A 的所需端口基于 ara::com 代理类实例实现，类型 B 的提供端口基于骨架类实例实现。还指出 SoftwareComponentType 实现代码可重用，区分了代码中显式多次实例化 C++ 类和通过多次启动运行同一个 Executable 隐式多次实例化这两种情况，并说明前者属 “实现层面” 范畴。
AP 应用程序 / Executable 和进程
AP 应用程序由 1 到 n 个 Executable 组成，Executable 由 CompositionSwComponentType 实例化构建。集成商决定启动哪些 AP 应用程序及其相关 Executable 的次数，启动后的 AP 应用程序会依据所含 Executable 数量变为相应数量的进程，此为 “部署层面”，并通过示例图展示了相关的部署情况。
基于 ara::com 的应用程序代码中使用元模型标识符
- 实例说明符相关问题：解释对元模型 /ara::com 关系的阐述有助于理解 ResolveInstanceIDs 中 instance specifier 结构，因仅靠模型端口名称无法在最终实例化中明确识别对象，相同组件实现可能多次实例化并在不同进程启动，所以实例 ID 需分配给有独特标识的对象，集成商要做技术映射决定传输绑定及具体实例 ID。
- 获取唯一标识符及相关要求：介绍在具体例子中不同层级实例化的软件组件如何获得唯一名称，进而从 Executable / 进程角度形成唯一标识符。对 AP 软件组件开发人员而言，构建实例说明符转换为特定标识符或使用时有特定形式要求，且要考虑组件不一定由自己部署等情况，按相应方式使用或传递 <上下文标识符>，同时指出 AUTOSAR AP 未规定相关转换等操作，取决于实现者，对于可多次实例化的相关组件，< 上下文标识符 > 构造函数参数可能是解决问题的自然办法。