Specification of an Architecture Meta-Model - SPES 2020

1.3.1 Motivation
Specification of an Architecture Meta-Model
The SPESMM provides interoperability between tools and services. Many tools have
internal meta-models or provide connectivity to open meta-models such as MARTE
[Obj08b] or SysML [Obj08a]. Other tools or services might provide support for such
meta-models but this is not the general case. When connecting tools and services with
a heterogeneous set of meta-models, there is a strong need for data exchange. Point-topoint
connections between specific tools are always possible and have to be regarded
as well. But the support of a new tool with a foreign meta-model requires providing
data exchange solutions to all tools which shall communicate with the tool. In cases
where the full semantics of the model have to be supported and specific artifacts have
to be accessed this is useful.
Generally, tools do not know all foreign meta-model concepts. So an interface to all
kinds of models would either be only structural without semantics or has to provide
all possible semantics which is difficult to capture and such a “world interface” would
not be useful. In many cases it is only relevant to identify more abstract concepts and
artifacts with generic semantics i. e. when browsing models or for common analysis
and simulation techniques. For this purpose the SPES Meta-Model will provide a
technique to access common concepts, artifacts and relationships in models of metamodels.
Such meta-models are integrated by performing a tailoring process in which
meta-model artifacts and relationships are mapped to the concepts of the SPES Meta-
Model. The SPES Meta-Model provides core structure and semantics. Models can
therefore be completely stored in the SPESMM for full model exchange and have
furthermore a generic interface as defined by the SPES Meta-Model.
In order to generally support a large number of modeling tools the SPES metamodel
is also presented as a UML Profile, relying on UML models extended through
stereotypes. Consequently, the profile approach is not as flexible as the meta-model,
but we were able to identify missing UML concepts present in the SPESMM and to
integrate them into the profile. Thus, in some SPESMM descriptions there are hints as
to how the specific meta-model artifact is represented in the profile.
1.3.2 Meta-Model Requirements
Recent meta-model approaches like EAST-ADL2 [ATE08], AADL [FGH06], SysML
[Obj08a] or HRC [JMM08] contain structural features such as components, ports, and
connectors. In conjunction with the requirements from Deliverable D3.1.A [WTR09]
we deduced general meta-model requirements for the SPESMM. In the following we
provide a concept of common structural artifact kinds and a description of the composition
concepts.
The SPESMM will enable heterogeneous component design. Each of the mentioned
meta-models contains artifacts which resemble components. The kind of a component
thereby depends on the abstraction level and on the subject architecture in which the
component shall be placed. For instance, on the one hand a functional draft can con-
2/135