1.介绍

AADL(Architecture And Analysis Design Language)是一种常用的实时嵌入式系统建模语言。AADL模型可以通过第三方工具实现对规范的早期分析，验证系统的功能特性和非功能属性，甚至为目标硬件平台生成代码。这些第三方工具之一是CAT，即消费分析工具箱，它与AADL编辑器OSATE集成。 另一方面，Marte(实时嵌入式系统建模和分析)Profile[8]通常用于实时嵌入式系统的建模和分析。如图1所示，除其他外，它允许在实时操作系统平台上描述应用程序的部署，以构建独立平台模型(PIM)(独立于硬件平台)，并再次描述在构建平台特定模型(PSM)的硬件平台上部署该PIM。在那里，如果可以从上面的MartePSM获得AADL PSM，则可以使用AADL工具环境。可以使用两种方法，第一种方法是创建UML AADL概要文件并使用它注释Marte PSM(参见图1)，然后将此UML/AADL PSM转换为AADL模型，第二种方法是定义Marte元素到AADL元素的映射，并直接将Marte PSM转换为AADL PSM。然后，使用特定于平台的信息对此AADL PSM进行改进，例如，处理器将通过特定于技术的引用(ARM7TDMI、PPC 405等)进一步完善。

图1.模型驱动 设计：从MARTE到AADL。

2 Marte To AADL模型变换

我们建立了UML Marte和AADL语言结构之间的映射，这些构造与Marte规范中描述的构造略有不同(参见附件A：使用Marte的指导示例)。我们在这里提出的映射是不同的；最重要的原因是我们希望映射是抽象的，这意味着我们的转换将把Marte模型抽象为AADL模型。M.Fauere在[8]中提出的映射没有涵盖所有的Marte刻板印象。然后，它只能被那些已经知道他们正在为AADL建模的Marte用户使用，就好像他们正在使用他们的UML工具作为AADL编辑器，其中Marte概要文件被部分使用，并且被用作AADL配置文件。在我们的例子中，我们的目标是使用Marte建模的Marte用户，甚至不知道可以进一步使用AADL分析工具。这就是为什么我们至少在可能的情况下必须考虑所有MARTE配置文件的原因，第一种情况
MARTE用作AADL编辑器，因为更适合使用特定的AADL UML配置文件，所以它没有用。

我们定义的模型转换过程由一个OCL约束步骤[9]和一个模型转换步骤(即核心转换“Marte To AADL”)组成。第一步将验证输入Marte模型是否遵守某些设计规则以获得有效的AADL模型。然后执行Marte To AADL模型转换，生成AADL模型。

3 Marte到AADL映射

A。包层次结构

发出一个AADL模型有一个平面层次结构(图2)。这意味着它只有一个表示AADL规范的根元素，其中可以有子包(包不包含其他包)。在UML中，根模型包含其他的程序包；它是一个类似树的层次结构。在AADL中，可以通过文件系统目录来模拟包的层次结构。AADL模型具有以下层次结构：

图2. AADL模型层次结构。

在UML中，层次结构也是一种设计信息，对设计人员对系统的理解有着重要的意义。这就是为什么当我们将Marte模型转换为AADL时，我们需要跟踪这些信息。为此，我们使用名称空间：“XUPWithMJPEG：：PK_Application：：Package_IPC”

这为包提供了以下ATL转换规则：

在这里，UML包中的qualifiedName返回带有名称空间的名称

B.将UML类图层次结构映射到AADL类型和实现层次结构

在第一种方法中，我们使用UML类等抽象布尔字段来区分AADL类型和AADL实现；这是避免使用额外构造型的解决方案。但是我们最终决定为每个UML类创建一个AADL类型和一个AADL实现，因为第一种方法就像使用Marte作为AADL编辑器。使用第一种方法，我们必须添加许多OCL约束来验证我们没有在语义上非法AADL配置。例如，从非抽象类继承的抽象类将导致AADL类型扩展AADL实现，这在AADL中是非法的。 我们还必须选择将哪些UML关系映射到AADL实现关系，以及将哪些UML关系映射到AADL扩展关系。 我们区分了三种UML配置情况（图3），可以将其视为等同于AADL的AADL：

图3.使用UML实现AADL类型

我们注意到，我们无法使用接口来描述AADL类型，因为UML接口不是capsulatedClassifier（不能具有端口）。 实际上，我们只能使用类来定义端口，这是体系结构建模的重要方面。

我们可以使用实现来描述AADL类型，但是在复合图中，在一个实现元素中，我们将无法继承在相应类中声明的端口，我们只能通过继承来实现这一点，此外，我们还认为应该将这个表示法保留到总线/数据访问AADL构造中。这就是为什么只有第二种情况(图3)是可能的。

我们还必须防止某些人在不对应于同一类别(处理器、总线、线程…)的两个类之间使用泛化。这就是产生更多OCL约束的预转换验证步骤的作用。

在AADL中，我们还将同一组件类别中的两个抽象类或来自同一组件类别的两个非抽象类之间的泛化的使用映射到了扩展机制上。

图4.在UML中可以找到四种概括的组合。

使用UML中的归纳法可以得出四种可能性（图4）。 每种可能性对应于不同的AADL构造：

• 第一个映射到AADL实现。
• 第二个在AADL中变得毫无意义。
• 映射到AADL扩展结构的第三和第四种情况。

正如我们已经说过的，第一个选择导致了一个复杂的映射，即使用Marte作为AADL编辑器。它还产生了太多的OCL约束，极大地影响了设计活动，因为除了设计语言之外，设计者还必须了解所有的规则。我们最终选择了一个不同的映射，这对设计人员来说要容易得多，他们不需要比UML和Marte知道更多的设计规则。这种映射包括将每个类分割成一个类型及其实现，并将UML泛化映射到下表1所示的AADL的“EXTEND”机制(这里，用带有黑头箭头描述了“Extended”AADL机制，AADL中的蓝色箭头描述了“实现”AADL机制)。

下面的示例(图5)说明了该映射如何将任何UML/Marte配置转换为AADL，只需对初始Marte模型进行一个假设。

表格1 将UML类和广义映射到AADL

图5. UML类图转换。 （ClassB和ClassD是抽象的）

通过这种映射，我们将永远不会在实现之间进行扩展，只要这两者都没有问题，就不会有问题。表示是等效的。 此映射还可以将每个UML概括的层次结构转换为AADL中的等效扩展的层次结构。

C.将MARTE构造映射到AADL组件类别

MART提供了比AADL更详细的设计可能性。事实上，所有的AADL构造都在Marte中有它们的映射，但另一种方式则不正确。例如，在Marte中，我们有一个HwProcessor和一个HwComputingResource。它们都可以在AADL处理器中转换，但是AADL中的设计细节将是粗粒度的。另一个例子是Marte中的HwBridge，它在AADL中没有等效的。因此，必须在AADL中将其抽象为一个通用设备，该设备在Marte中与HwDevice相对应。

正如我们已经说过的，我们试图使这个映射成为Marte到AADL的抽象。这就是为什么我们将每个AADL组件类别映射到一组Marte模型元素。

表2 本节中已建立的映射

理想状态，应该用像SysML：Block这样的原型来描述AADL系统组件类别，但是我们不想只对一个原型强加对另一个UML配置文件的依赖。这就是为什么我们也将一个没有刻板印象的类映射到系统的一般概念中。

Marte中的一些原型不能抽象到AADL结构中：

• 因为它太抽象了：例如，‘TimingResource’可以是一个硬件或软件组件。对于这种情况，我们选择了一个默认映射(参见表3、行1和表2)，以便有一个完整的映射。但是，使用低度的OCL约束，我们会向用户发出警告，让他知道这个问题。
• 因为AADL根本不支持设计的这个方面。例如，“HwEndPoint”或“HwPort”，这些方面没有在AADL中描述。在这种情况下，我们根本不考虑这些信息，但OCL警告约束将通知设计人员有关这些问题的信息(见表3行号3)。

表3 非抽象的哑光元素的警告约束

表4 AADL组件类别之间的组成可能性

在AADL中，子程序类别是“顺序可执行的源文本”。 在UML中，这对应于“类中的操作”。 在AADL中，子程序类型可以具有不同的实现。 在UML中，操作的方法可以是 OpaqueBehavior（自然语言，编程语言等），状态机或活动。 然后我们可以使用OpaqueBehaviors 作为描述AADL子程序类型的不同AADL实现的操作方法。 这是我们可以使用UML找到的更自然的映射。 区别在于UML :: OpaqueBehavior包含在定义它的类中 而在AADL中，子程序是独立定义的，并在另一个组件中实例化。 但是随着我们正在改变 将更多的约束语言（在此方面）转换为更通用的语言，这不会导致不同的语义。

将UML类属性映射到AADL构造由映射到AADL组件类别的类类型的UML类属性转换为由相应的AADL实现组件键入的子组件。将不对应于AADL组件类别的UML属性转换为AADL属性，并为每个属性创建一个新的AADL属性定义。

抽象类的UML属性必须传播到所有专门化类。这只是通过使用UML：：分类器的UMLAPI getAllAttributes()方法来完成的，而不是使用更常见的Classfier.properties属性：

AADL中的组成受某些限制（请参阅表4）。 这些约束通过选择OCL过滤器应用于我们的映射中。 在上面的示例中，memorySubComponent AADL组件属性将仅包含使用select语句作为内存的元素：

A 其结果是，UML/Marte中的非法属性输入将被忽略。例如，如果UML类构造型“MemoryPartition”(映射到AADL流程)具有另一个类构造型“HwBus”(映射到AADL总线)的属性，则不会引发错误，因为SELECT语句将忽略非法属性。这就是为什么将OCL警告约束添加到OCL验证步骤中的原因。下面的OCL代码显示了一个警告约束的示例，该约束的结果将用于告诉设计器将忽略Class属性：

映射UML接口、使用和实现UML/Marte设计器定义端口类型。必须定义两种类型的端口：

• 将连接到组件的端口的类型。
• 组件将提供的端口类型，以允许其他组件连接到该端口。

然后，设计器为类的端口设置这些类型(也是类)。最后，他连接了相应的端口。此配置映射到“Required Bus Access”AADL构造(数据相同，参见图6)。

图6. UML接口用法和实现到AADL构造的映射。

图7.映射到“需要总线访问”配置的设计示例。

此配置（图7）映射到系统，内存，处理器，总线和设备类别的“需要总线访问”功能：在此示例中，每个具有用DataAccessPort类键入的端口的元素都将具有«必需的总线 access»元素，其任何具有端口的总线都可实现MoDELS 2010 ACES-MB研讨会论文集，其中两个busConnector端口均由DataAccessPort键入，该端口使用由BusGenericPort类实现的BusAccess接口 在BusOPB类中键入数据端口。

在UML中，即使使用和实现的接口不相同，也可以连接两个端口。在本例中，其中busConnector端口连接到一个端口，该端口由实现比BusAccess更多接口的类键入。这种情况至少应该引起一个警告。这是UML非正式性的结果。事实上，在UML中，只能连接“兼容”端口[10]。这意味着我们必须定义端口之间的兼容性意味着什么。这是一个UML语义变化点。计算机科学不喜欢语义变异点，这就是为什么我们必须定义这种“兼容性”。我们将其定义为：连接到连接器的可连接元素如果由使用或实现相同接口的类键入，则它们是兼容的。至少一个人必须使用这个接口，并且必须实现它。

F.在UML/MARTE中连接到其所属类属性的端口

通过数据或总线类型端口公开的类属性可以转换为提供数据/总线访问。有两种情况：

• 情境1：属性直接连接到边界端口。
• 情境2：属性通过自己的一个端口连接到边界端口。

我们的映射支持这两种情况，并且提供的数据/总线分类器将直接连接到边界端口。图8显示了两个例子：

图8.连接到其自己的Class属性的端口的两种情况的示例。

表5连接到其自己的类属性映射的端口。

G。将UML/MART端口映射到AADL结构

M.Fauere[8]定义了UML/Marte端口到AADL的映射。我们的映射是Marte到AADL的映射，因此它必须涵盖更多的可能性，以便向AADL抽象更多的情况。事实上，M.Fauere的映射是AADL到Marte的映射，也就是说，它回答了一个问题：“如何使用Marte指定AADL设计？”我们正在回答一个不同的问题：“我们如何将Marte规范转换为AADL？”

AADL数据端口在UML中对应于标准的UML：Port，因为“端口表示分类器与其环境之间的交互点”[10]。除其他外，MarteFlow港增加了方向。事实上，在Marte中，“Flowport已经被引入，以支持组件之间的浮雕通信模式”[8]。AADL事件/(事件数据)端口对应于消息端口或ClientServerPort。在[8]中，“消息端口支持请求/回复通信模式”。最后，在AADL中事件端口和事件数据端口之间的区别是，一个事件数据端口是被键入的(在元模型中有一个数据分类器属性)。

表6 UML / MARTE映射

结论与观点

本文所描述的映射是通用的，除了对端口及其类型的描述和AADL语言所强加的语义之外，还可以在不让设计者知道我们映射的细节的情况下使用。

转换规则很好地处理了源语言和目标语言之间的语法差异，因为我们使用的ATL工具使得调用Java代码成为可能，通过Java代码，我们可以完成计算机所能做的一切。其他仅基于声明性规则的语言可能提供不完整的转换。因此，必须同时具有声明性规则和命令式编程。当映射足够简单时，声明性规则简化了规则的定义。但在某些情况下，使用命令式编程是必不可少的。

模型转换提出的核心问题是语义差距问题。“我们如何解决语义空白”这个问题？需要回答。阅读源和目标规范中建模方面的定义，然后对它们进行比较可能会成为一项非常繁重的工作。一些为M2M转换而设计的映射是在没有进入这个细节级别的情况下构建的，这不可避免地给出了一个明显可以接受的翻译，但是源模型和目标模型的底层语义将有不同的含义。

解决M2M转换是一个反复出现的问题，需要采取更系统的方法来提高效率。这个系统化的问题可以通过描述“M2M分辨率模式”来回答。有些模式已经被采用，但没有被精确描述，比如将转换分解为n个转换链，其中每个转换都是两个语义上接近的元模型之间的简单转换。描述这些模式将从手工过程的状态到工程过程的状态进行模型转换。本文不是一份M2M分辨率模式文件，但我们在这里展示了其他一些明显的模式：

• 抽象模式：源模型元素可以映射到更通用的目标模型元素，而目标模型元素的细节较少，比如将传感器抽象到通用设备。
• 投影模式：目标域的表现力低于源域，然后进行投影以减少信息进入目标域的“维度”。就像将模型元素从具有静态和动态描述的语言转换为纯体系结构语言一样。
• 设计禁止模式：源域不那么严格是建模可能性的术语；如果像现在这样转换到目标域，有些情况是无稽之谈。禁止使用约束验证阶段的这些情况是解决这个问题的办法。

如果您希望了解更多信息：

• 欢迎访问建模者频道 http://modeler.org.cn/
• 也欢迎直接联系我们 zhgx@uml.net.cn ，010-62670969

下载pdf版：《将MARTE UML配置文件映射到AADL》

后记

希望您读了此文后有所受益。

如果您有经验乐于分享，欢迎投稿给我们。

如果您对我们的培训、咨询和工具感兴趣：