Specification of an Architecture Meta-Model - SPES 2020

Specification of an Architecture Meta-Model
It is often useful to instantiate one component several times. For instance, a component
design contains two actuators of the same kind. The respective component is defined
once and instantiated twice. This provides high reuse capabilities.
1.3.3 Integration Concepts
The SPES Meta-Model will consist of a common concept core meta-model, eventual
general core extensions as well as domain specific extensions.
The SPESMM Meta-Model contains common modeling concepts which are generally
needed such as component based design, data types, expressions, requirements
and tracebility. These concepts are based on HRC, EAST-ADL2, and MARTE.
Domain specific meta-models like EAST-ADL2 can be tailored to extend the
SPESMM core meta-model. This allows domain specific models as well as a general
interface to such models based on the SPES Meta-Model and therefore enables
model-based tool interoperability.
For the purpose of clear packaging meachanisms meta-models which are tailored for
the SPES Meta-Model shall only reference own classes, classes of parallel respectively
own sub packages or classes which belong to more general concepts like the common
core. Thus classes of a generalized meta-model package shall not reference classes of
an extension package because this would make the extension package belong to the
generalized package.
In order to integrate a foreign meta-model into the SPES artifacts and relationships
which are related to common concepts of the SPES core meta-model have to be identified.
Based on such a concept identification the respective meta-model can be tailored
to extend the common concepts.
1.4 Differences between the Meta-Model and the
Profile
Since the SPESMM is a meta-model it relies on its own semantics. Therefore a conversion
of the meta-model to a profile is not an easy step since UML already provides
some semantics and structures which are not always compatible with the SPESMM
semantics. A second issue is the absence of a decompositional context reference.
UML only allows for a component to be decomposed one level deeper. So if a
modeler talks about an instance within a type (part of a class) he can not know how
many instances of the described type itself exist. In a deep decomposition hierarchy
the user has to be able to identify the context in which the instance is used. Therefore
we introduced part and port references for the mapping relation, see Section 2.2.9 for
more details on the mapping relation. Since the profile would hardly be usable with
such a deep context reference decomposition we “flattened” these context references,
so they now are tags in the mapping stereotype.
4/135