=Paper=
{{Paper
|id=Vol-1463/paper2
|storemode=property
|title=Towards a Deep Metamodelling Based Formalization of Component Models
|pdfUrl=https://ceur-ws.org/Vol-1463/paper2.pdf
|volume=Vol-1463
|dblpUrl=https://dblp.org/rec/conf/models/Cicchetti15
}}
==Towards a Deep Metamodelling Based Formalization of Component Models==
https://ceur-ws.org/Vol-1463/paper2.pdf
Towards a deep metamodelling based formalization
of component models
Antonio Cicchetti
School of Innovation, Design and Engineering (IDT)
Mälardalen University, Västerås, Sweden
email: antonio.cicchetti@mdh.se
Abstract—Component-based software engineering (CBSE) is and so forth. Usually, modelling languages support such hierar-
based on the fundamental concepts of components and bindings, chical structure in terms of relationships between a component
i.e. units of decomposition and their interconnections. By adopt- and its sub-components, or between a component and its
ing CBSE, a system is built-up by means of a set of re-usable
parts. This entails that system’s functionalities are appropriately realisations, respectively. Despite this approach is powerful
identified so that implementing components can be accordingly enough to represent complex CBSs from the expressiveness
selected. In turn, this means that each component-based design point-of-view, it requires a careful management of system
is at least made-up of two different instantiation levels, i) one validation. Notably, type correctness checking, that is verifying
for designing the system in terms of components and their whether a component realisation is a valid instance of the
interconnections, ii) and one for linking possible implementation
alternatives for each of the existing components. In general, this component specification, has to be hard-coded in the tool.
twofold instantiation is managed at the same metamodelling Moreover, this check should be re-executed each time changes
level through the use of relationships. Despite such solutions were performed in the component specification and/or in its
are expressive enough to model a component-based system, they realisation. Besides, the relationship solution becomes quickly
cannot represent the instantiation relationship between, e.g., a intricate with the growth of hierarchical decomposition levels.
component and its implementations. As a consequence, validity
checks have to be hard-coded in a tool, while the interconnection Practically, supporting more than two levels of component
between component and implementation have to be managed by nesting poses relevant representation issues, as distinguishing
the user. the quality attributes of a parent component from the ones of
In this paper we propose to exploit deep metamodelling tech- its nested children.
niques for implementing CBSE mechanisms. We revisit CBSE Deep metamodelling [3] is a recent technique introduced in
main concepts through this new vision by showing their counter-
parts in a deep metamodelling based environment. Interestingly, the model-driven engineering (MDE) research field to cope
multiple instantiation levels enhance the expressive power of with multiple instantiation levels. It enhances the usual 4-
CBSE approaches, thus enabling a more precise system design. layered metamodelling architecture [4] (also known as two-
Index Terms—model-driven engineering; component-based level metamodelling) by providing a recursive language ex-
software engineering; component models; deep metamodeling; tension/instantiation structure. In this respect, the deep meta-
instantiation level;
modelling vision fits perfectly with CBSE methodology and
its hierarchical decomposition of software systems [3]. In
I. I NTRODUCTION
fact, deep metamodelling allows to represent a system and its
The increasing complexity of contemporary software sys- components by means of arbitrary decomposition/instantiation
tems and the growing pressures to deliver products faster while levels.
still keeping high quality attributes demands appropriate de- This paper investigates the implementation of a component
velopment solutions. Component-based software engineering model by means of deep metamodelling mechanisms with
CBSE [1] is a well-established methodology that proposes the aim of verifying the feasibility of such a solution. The
to alleviate software development intricacy by studying the initial results illustrated in this work confirm the feasibility
target application as an assembly of composable units (indeed, of the approach and meet the expectations of exploiting deep
software components), each one addressing a particular aspect metamodelling mechanisms. Notably, hierarchical component
of the system. In this way, the complexity of the initial problem structures can be represented in an easier way, while the
can be reduced through its partitioning into smaller sub- conformance check of a component instance against a com-
problems. Moreover, time devoted to development and testing ponent specification is obtained by-construction. Despite both
can be narrowed by promoting the reuse of already existing the component model and the deep metamodelling solution
components across several software development projects [2]. are specific, the discussion is kept generic enough to be repro-
Component-based system (CBS) specifications are intrinsi- ducible with other component models and deep metamodelling
cally hierarchical: i) on the one hand, a component might be approaches.
realised as the composition of several nested components; ii) The paper is organised as follows: next section introduces
on the other hand, a component might have multiple imple- CBSE together with a running example, which will be ex-
mentations distinguished by quality attributes, target platform, ploited in Section III to clarify the issues raising in considering
multiple instantiation levels. Section IV discusses the proposed
formalisation of CBSE concepts through a deep metamod-
elling framework. Eventually, related works are discussed and
conclusions are drawn in Sections VI and VII, respectively.
II. I NSTANTIATION RELATIONSHIPS IN CBSE
CBSE methodology relies on the notion of component, that
is “a unit of composition with contractually specified interfaces
and explicit context dependencies only. A software component
can be deployed independently and is subject to composition
by third party.” [5]. Depending on the application domain,
technological platform, and so on, the concept of component
might include disparate characteristics, which are typically Fig. 3. Two (excerpts of) possible implementations for the PNA system.
defined in a corresponding component model [6]. Therefore,
a CBS is specified by adhering to a well-defined component
model, that prescribes how components, their interconnections, In general, a component can include nested sub-
and their deployment, look like. components, referred to as composite components [6]. This
For example, let us consider a simple Personal Navigation is the case of the GPS Receiver, which has a complex
Assistant (PNA)1 CBS as depicted in Figure 1: it includes internal structure. As shown in Figure 2, GPS antennas
GPS Receiver, Power Management, Navigation (Parallel Receiver) have to coordinate their tasks with
System, and UI components (represented as boxes with Clock and Almanac Store. In particular, satellite avail-
names). For the purpose of this paper, it is sufficient to know abilities depend on the current time and are stored in an
that the Navigation System retrieves geo-positioning almanac.
information from a GPS Receiver and delivers naviga- Eventually, components are attached with one or more
tion data to a user interface (UI component). These inter- implementations, which can be distinguished by quality at-
connections are represented by means of named relation- tributes, supported platforms, and so forth. Notably, for the
ships linking component ports. More precisely, a triangle PNA one might want to prioritise power consumption versus
shaped port represents an (provided) output of a certain precision in a mobile phone while doing the opposite for a
component, while a square represents an (required) input. rescue device. Figure 3 illustrates two implementation alter-
Therefore, Navigation System gets Position infor- natives for the PNA system: in the one shown on the top
mation from GPS Receiver and, after computing relevant half of the picture, a single Database is shared between the
Navigation Data, it delivers them to the UI. implementations of Almanac and UI components, whereas
1 The example has been taken from [7] and readapted for the purpose of
the realisation shown on the bottom half exploits separate
this paper.
databases.
It becomes quickly evident that CBSE methodologies are
intrinsically hierarchical: the generic notion of component
assembly is instantiated by means of a specific component
model (e.g., the simple one used in the example), which in
turn is instantiated into a particular CBS (the PNA system).
Even further, components can be realised in terms of other
components and/or through implementations (as shown in
Figure 2 and 3, respectively). In this respect, it is expectable
that each CBS specification is made-up of only valid in-
stances for the component model, the components defined
Fig. 1. A simple Personal Navigation System. in the system together with their implementations. Some of
these instantiation relationships are managed by-construction:
notably, a CBSE tool is built-up on a well-defined component
model, hence the tool will support the design of CBSs by
means of all and only the concepts offered by the selected
component model (i.e. there is no need to verify that a CBS
specification conforms to the component model).
A number of instantiation relationships however have to be
checked case-by-case, and this validation step has to be ad-
dressed either by the designer, through appropriate constraints
Fig. 2. A simple GPS receiver component. at modelling level (e.g. by means of OCL [8]), or hardcoded
component implementations, would all be represented at the
modelling level (i.e., M).
The conformance validity issues mentioned in Section II
are due to the fact that a certain entity either pertains to the
metamodel or to one of the models conforming to it. Moreover,
at language level, realisation links defined between composite
components and sub-components, and analogously between
components and implementations, cannot guarantee confor-
mance (i.e., they cannot impose type instantiation constraints).
Technically, these relationships link concepts pertaining to
different metamodelling layers that however cannot be repre-
sented in the typical 4-layered metamodelling architecture [3].
Fig. 4. A comparison between 4-layered and deep metamodelling architec-
More specifically, the PNA system in Figure 1 is an instance
tures. of a certain component model, and at the same time the
implementations in Figure 3 are instances of PNA components.
In other words, a certain entity should play the role of a
into the tool. For example, when specifying that the GPS concept definition (MM level in Figure 4) and instance (M level
Receiver composite component in Figure 1 is decomposed in Figure 4) at the same time.
as in Figure 2, the tool should at least verify that input and out- Multiple metamodelling layers allow to appropriately rep-
put ports of the latter component specification are compatible resent instantiation hierarchies, as depicted on the right side
with input and output ports of the former composite compo- of Figure 4: a model can be equally considered as an instance
nent (e.g., matching types). A similar reasoning has to be done conforming to the metamodel on the layer above and as
when considering the interconnection between components a language definition (i.e. as a metamodel itself), for the
and corresponding implementations. More specifically, every layer below. In this way, it is be possible to define a com-
implementation of GPS Receiver should be compatible ponent model as a metamodel a certain CBS specification
with every implementation of Navigation System when conforms to, like it happens for CM and ProCom levels. In
considering the exchange of Position and Output Mode turn, the CBS specification would constitute a metamodel
data (e.g., the implemented setter and getter methods should for which (sub-)component instances could be created (see
match with their types). Regardless whether specified by the ProCom and PNASystem levels, respectively). Eventually,
designer or if hardcoded in the tool, keeping consistent and implementations would be represented in a model conforming
up-to-date validity checks can be time-consuming and error- to a metamodel including simple component definitions (i.e.,
prone, especially when considering complex CBSs. Notably, PNAImpl).
if the system needed a more precise tracking of power status,
the Power Management component could be refined as
IV. A DEEP METAMODELLING FORMALISATION FOR CBSE
providing more details. In turn, these refinements should be
propagated at implementation level by choosing appropriate This section illustrates the proposed formalisation of CBSE
component implementations for both Power Management methodologies into a deep metamodelling framework. The for-
and Navigation System. malisation proceeds step-by-step, from higher abstraction level
concepts towards more and more concrete instantiations of
III. O N THE NEED OF A DEEP METAMODELLING SOLUTION them. In particular, we leverage a specific component model,
Current modelling techniques are usually based on a 4- namely ProCom [9], to implement the example presented in
layered metamodelling architecture [4]: a software system is Section II. Moreover, we exploit MetaDepth [10] as support
represented by means of a model, that is an abstraction of for concretising the formalisation proposal on a specific deep
reality for a given purpose. The model is created by following metamodelling environment. It is worth noting that, despite
a set of well-formedness rules stated in a language definition, the component model and deep metamodelling solution are
referred to as the metamodel. In other words, a metamodel specific, the discussion is kept generic to be extensible to
defines the set of legal abstractions for a certain system. A arbitrary component models and other deep metamodelling
model is said to conform to a metamodel if it adheres to solutions.
the defined well-formedness rules. At the top of the 4-layered In order to develop a system through CBSE methodologies,
architecture there is the meta-metamodel, i.e. a unique minimal it is necessary to preliminarily adopt a specific component
set of concepts needed to create all the possible languages. In model [6]. In the most generic terms, a component model is
this respect, the specification for the example introduced in made-up of components, bindings, and a platform. By adopting
Section II would be supported as shown on the left side of MetaDepth syntax, these concepts are specified as shown in
Figure 4: the MMM layer would be exploited to define a CBSE Listing 1. In particular, Component nodes are bound by
language based on a specific component model (at level MM), means of directional Binding edges (the direction is iden-
while the PNA system, its (sub-)components, bindings, and tified through attributes bindingOut, bindingIn, respec-
tively). A similar reasoning can be done for the Deployment 21 Deployment ProComDeployment(ProComComponent.deployment,
ProComPlatform.in) {}
relationship between Component and Platform nodes. 22 }
It is worth noting that, already at this stage it is possible to
Listing 2. Encoding of (a subset of) the ProCom component model.
put modelling constraints: the noSelfBinding expression
at line 18 prescribes that a component cannot be bound to Once the component model has been defined, it is possi-
itself. Moreover, child multiplicity at line 9 establishes that ble to model a CBS. In our case, we specify the PNA
a Composite must have at list one nested component. system introduced in Section II through ProCom, as shown
1 Model ComponentModel@*{ in Listing 32 . In particular, the Navigation System, Power
2 ext Node Component@*{ Management, and UI components in Figure 1 are mod-
3 bindingIn: Component[*];
4 bindingOut: Component[*]; elled as ProComComponents, while the GPS receiver
5 deployment: Platform[0..1]; as a ProComComposite (see lines 2–13). Moreover,
6 }
7 DataConnections are specified to bind the components
8 ext Node Composite@*: Component{ appropriately, and implicitly define data ports for the corre-
9 child: Component[1..*];
10 } sponding components (lines 16–21).
11 Since GPS is defined as a composite, it is possible to define
12 ext Node Platform{
13 in: Component[*]; it as an assembly of sub-components. In this respect, Listing 3
14 } shows the definition of Almanac Store at lines 23–25
15
16 Edge Binding(Component.bindingOut,Component.bindingIn) {} according to the description of the GPS receiver depicted
17 Edge Deployment(Component.deployment,Platform.in) {} in Figure 2. Furthermore, by choosing the implementation
18 noSelfBinding@* : $Component.allInstances()->forAll(src,tgt
| Binding(src.bindingOut,tgt.bindingIn) implies src!= alternative at the bottom of Figure 3, the almanac is defined as
tgt)$ composite, thus allowing the introduction of a nested database
19 }
component together with its quality attributes (lines 29–34).
Listing 1. Encoding of a generic component model. The nesting specification is completed with the definition
The generic definition given in Listing 1 introduces the nec- of isChildOf relationships, as visualised at lines 36–38.
essary CBSE concepts to create a specific component model. Eventually, a platform is introduced to allow the deployment
Notably, if we would like to define the ProCom component of the PNA system, and component deployments are specified
model, we would need to refine the generic bindings as accordingly (lines 41–47).
ports, since ProCom adopts port-based interfaces. In particular, 12 ProCom PNAModel{
ProComComposite GPS{
we introduce data ports and trigger ports, as illustrated in 3 name = "GPS Receiver";
Listing 2, lines 4–7. Moreover, bindings have to be refined 45 }
correspondingly (lines 18–19). It is important to notice that 6 ProComComponent NS{
ProCom component model is defined in terms of, or better 78 }name = "Navigation System";
instantiates, the generic component model defined in List- 9 ProComComponent UI{
ing 1. This ensures, for instance, that DataConnection 10 11 }
name = "UI";
correctly binds a pair of ProComComponents through their 12 ProComComponent PM{
in_dataPort and out_dataPort, respectively. Other 13 14 }
name = "Power Management";
alternatives, e.g. connecting a port with a child, would have 15
raised type mismatch issues at validation time due to the type 16 DataConnection(GPS.out_dataPort,NS.in_dataPort){name="
Position";}
relationships defined before. 17 DataConnection(NS.out_dataPort,GPS.in_dataPort){name="
OutputMode";}
1 ComponentModel ProCom{ 18 DataConnection(PM.out_dataPort,NS.in_dataPort){name="
2 Component ProComComponent{ PowerStatus";}
3 name: String {id}; 19 DataConnection(UI.out_dataPort,NS.in_dataPort){name="
4 in_dataPort: ProComComponent[*] {bindingIn}; UserInputs";}
5 out_dataPort: ProComComponent[*] {bindingOut}; 20 DataConnection(NS.out_dataPort,UI.in_dataPort){name="
6 in_triggerPort: ProComComponent[*] {bindingIn}; NavigationData";}
7 out_triggerPort: ProComComponent[*] {bindingOut}; 21 DataConnection(NS.out_dataPort,UI.in_dataPort){name="
8 parent: ProComComposite[0..1]; Tracks";}
9 } 22
10 23 ProComComposite AS{
11 Composite ProComComposite: ProComComponent{ 24 name = "Almanac Store";
12 child: ProComComponent[1..*]; 25 }
13 } 26
14 27 ...
15 Platform ProComPlatform{ 28
16 } 29 ProComComponent DB{
17 30 name = "DB";
18 Binding DataConnection(ProComComponent.out_dataPort, 31 encryption: String = "NotDefined";
ProComComponent.in_dataPort) { name: String {id}; } 32 queryLanguage: String = SQL;
19 Binding TriggerConnection(ProComComponent.out_triggerPort,
ProComComponent.in_triggerPort) { name: String {id}; 2 Due to space limitations, some portions of the specification are omitted.
}
20 Edge isChildOf(ProComComponent.parent, ProComComposite. The interested reader can download the full specification at http://www.es.
child) {} mdh.se/∼acicchetti/PNASystem.php .
33 WCET: int = 22; important, the implementations have to obey the constraints
34 }
35
set in the specification: innerAlmanac can only connect
36 isChildOf innerASDB(DB.parent,AS.child); an implementation for the almanac with an implementation of
37 isChildOf innerAlmanac(AS.parent,GPS.child);
38 isChildOf innerUIDB(DB.parent,UI.child);
a GPS (see line 18), while GPSDeployment can only be
39 ... instantiated with an implementation for the GPS (see line 34).
40
41 ProComPlatform PNAPlatform{
The check of such constraints comes “for free” by the system
42 name: String = "PNAPlatform"; specification itself, which acts as a metamodel for the system
43 CPU: String = "FPGA";
44 BUS: String = "EtherNet";
implementation; on the contrary, the 4-layered metamodelling
45 } techniques would require additional coding and/or correctness
46
47 ProComDeployment GPSDeployment(GPS.deployment, PNAPlatform
rule definitions to check relationships consistency.
.in) {} Another relevant aspect to notice is the ease of identifi-
48 ...
49 } cation of type instances, which allows to set properties by
Listing 3. Specification of the PNA system through ProCom.
component implementation, and link each of them to the
appropriate component types. In particular, the two different
An excerpt of the implementation of the PNA system is implementations for the database are equipped with different
specified as shown in Listing 4. In particular, it illustrates the quality attributes and can be included into different composites
details for GPS, almanac, and database components (lines 2– accordingly. Moreover, the deep metamodelling framework
18), together with the ones for UI and its nested database (lines naturally supports the extension of attributes, making it possi-
20–21), consistently to the implementation choice depicted at ble to provide additional implementation details for component
the bottom of Figure 3. Moreover, it shows the declaration of implementations (e.g. cost, size, and so forth) depending on
a platform and corresponding deployments at lines 33–34. target platform sensitiveness.
1 PNAModel pna{ From a higher level of abstraction perspective, the deep
2 GPS gpsImplementation{
3 name = "GPS1"; metamodelling approach enables the definition of advanced
4 } modelling constraints. Notably, the component model might
5
6 AS asImplementation{ define modelling patterns/styles that later on will have to be
7 name = "AS1"; preserved by system specifications in order to be successfully
8 }
9 validated. This could include the number of components,
10 DB dbImplementation1{ the kind/number of allowed bindings, and so on. It is im-
11 name = "DB1";
12 encryption = "none"; portant to notice, once again, that similar constraints could
13 queryLanguage = "SQL"; be implemented also in the usual 4-layered metamodelling
14 WCET = 13;
15 } architectures. However, such a need would require implicit
16 checks that in the long run can become time-consuming and
17 innerDBAS(dbImplementation1,asImplementation);
18 innerAlmanac(asImplementation,gpsImplementation); error-prone.
19
20 UI uiImplementation{ As a drawback, the hierarchical arrangement of CBSs
21 name = "UI1"; specification over multiple metamodelling levels could result
22 }
23 as less intuitive and become less usable when dealing with
24 DB dbImplementation2{ complex systems. In this respect, it is very important to notice
25 name = "DB2";
26 encryption = "none"; that the formalisation is intended to be transparent to the
27 queryLanguage = "SQL"; CBS designer, and should be considered as the underlying
28 WCET = 22;
29 } infrastructure over which a CBS tool would be implemented.
30 MetaDepth is a text-based deep metamodelling environment,
31 innerDBUI(dbImplementation2,uiImplementation);
32 and as a consequence this work adopts the same approach.
33 PNAPlatform platform {} Nonetheless, other existing deep metamodelling tools have
34 GPSDeployment(gpsImplementation.deployment, platform.in);
35 ... already demonstrated the implementability of diagrammatic
36 } layers over a base deep metamodelling technology (notably
Listing 4. An excerpt of the specification of the PNA system implementation. Melanee [11] and the DPF [12]).
The current description of this formalisation in inherently
V. D ISCUSSION top-down, whereas an ideal CBSE approach would promote
At this point it is important to remark several relevant a bottom-up development, where useful pre-existing compo-
aspects related to the PNA system specification. From an nents are identified and picked-up from a repository [13]. In
instantiation procedure point-of-view, the deep metamodelling this respect, the component model can be still described as
framework introduces correctness by-construction. Notably, including a repository, and a valid CBS as being a collection of
once a system is defined as shown in Listing 3, it will component repository elements. In this case, it would be up to
be only possible to introduce component implementations as the CBSE tool to create an appropriate instantiation hierarchy
instances of the defined types (as in Listing 4). Even more based on the selected components.
VI. R ELATED W ORKS R EFERENCES
A preliminary choice in adopting a modelling language is [1] I. Crnkovic, “Component-Based Software Engineering for Embedded
deciding whether opting for a general purpose or a domain- Systems,” in LMO, 2006, p. 13.
[2] I. Crnkovic and M. Larsson, Building Reliable Component-Based Soft-
specific language [14]. In general, the former solutions have ware Systems. Artech House, Inc., 2002.
embedded extension mechanisms (like the prototyping mech- [3] J. D. Lara, E. Guerra, and J. S. Cuadrado, “When and how to use
anisms for the UML [15]), while the latter demand proper multilevel modelling,” ACM Trans. Softw. Eng. Methodol., vol. 24, no. 2,
pp. 12:1–12:46, Dec. 2014.
language extensions through metamodelling activities. With [4] J. Bézivin, “On the Unification Power of Models,” Software and System
respect to this paper, the former mechanisms provide more Modeling, vol. 4, pp. 171–188, 2005.
expressiveness through model instances (by inheritance), while [5] C. Szyperski, Component Software: Beyond Object-Oriented Program-
ming, 2nd ed. Boston, MA, USA: Addison-Wesley Longman Publishing
the latter ones act on the metamodel to provide appropriate Co., Inc., 2002.
refinements. In both cases, the extensions are limited to the [6] I. Crnkovic, S. Sentilles, V. Aneta, and M. R. V. Chaudron, “A classifi-
4-layered metamodelling architecture that does not allow to cation framework for software component models,” IEEE Trans. Softw.
Eng., vol. 37, no. 5, pp. 593–615, Sep. 2011.
introduce multiple instantiation levels. [7] T. Lévêque and S. Sentilles, “Refining extra-functional property val-
The general need for better addressing multiple instan- ues in hierarchical component models,” in Proceedings of the 14th
tiation levels has been recognised in the last decade and International ACM Sigsoft Symposium on Component Based Software
Engineering, ser. CBSE ’11. New York, NY, USA: ACM, 2011, pp.
corresponding solutions have been identified under the name 83–92.
of multilevel (or deep) modelling [10], [12], [16], [17]. In [8] Object Management Group (OMG), http://www.omg.org/spec/OCL/2.0/
some cases, multilevel modelling techniques have been even PDF.
[9] S. Sentilles, A. Vulgarakis, T. Bureš, J. Carlson, and I. Crnković, “A
used to implement domain-specific component-based systems, Component Model for Control-Intensive Distributed Embedded Sys-
notably robots [18] and cloud services [19]. Nonetheless, to tems,” in Proceedings of CBSE. Springer Berlin, 2008, pp. 310–317.
the best of our knowledge this is the first work that proposes a [10] J. de Lara and E. Guerra, “Deep meta-modelling with metadepth,” in
Proceedings of the 48th International Conference on Objects, Models,
general formalisation of CBSE concepts, and in particular of Components, Patterns, ser. TOOLS’10. Berlin, Heidelberg: Springer-
component models, with the aim of enhancing current CBSE Verlag, 2010, pp. 1–20.
techniques. [11] C. Atkinson and R. Gerbig, “Melanie: Multi-level modeling and ontol-
ogy engineering environment,” in Proceedings of the 2Nd International
The problem of managing multiple instantiation levels in Master Class on Model-Driven Engineering: Modeling Wizards, ser.
CBSE has been already tackled by several works, as [7], [20], MW ’12. New York, NY, USA: ACM, 2012, pp. 7:1–7:2.
[21]. In general these works adopt a 4-layered metamodelling [12] Y. Lamo, X. Wang, F. Mantz, W. MacCaull, and A. Rutle, “Dpf work-
bench: A diagrammatic multi-layer domain specific (meta-)modelling
solution, that is, they typically exploit inheritance or other environment,” in Computer and Information Science 2012, ser. Studies
recursive relationships to provide support for containmen- in Computational Intelligence, R. Lee, Ed. Springer Berlin Heidelberg,
t/refinement modelling [7]. Therefore, they leave open the 2012, vol. 429, pp. 37–52.
[13] S. Becker, H. Koziolek, and R. Reussner, “The palladio component
instantiation problems described throughout the paper. model for model-driven performance prediction,” J. Syst. Softw., vol. 82,
no. 1, pp. 3–22, Jan. 2009.
VII. C ONCLUSION AND FUTURE WORKS [14] T. Kosar, N. Oliveira, M. Mernik, J. M. Pereira Varanda, M. Črepinšek,
D. Da Cruz, and P. Henriques Rangel, “Comparing general-purpose and
This paper presents the first steps towards the formalisa- domain-specific languages: An empirical study,” Computer Science and
tion of CBSE concepts in a deep metamodelling framework. Information Systems, vol. 7, pp. 247–264, 2010.
Component-based systems have an intrinsic hierarchical struc- [15] Object Management Group (OMG), “UML Superstructure Specifi-
cation V2.3,” http://www.omg.org/spec/UML/2.3/Superstructure/PDF/,
ture and frequently exploit the “type-instance” pattern [3]. 2011, [Online. Last access: 11/04/2012].
These characteristics have been identified as problematic to [16] C. Atkinson, M. Gutheil, and B. Kennel, “A flexible infrastructure for
be implemented in the usual 4-layered metamodelling archi- multilevel language engineering,” IEEE Trans. Softw. Eng., vol. 35, no. 6,
pp. 742–755, Nov. 2009.
tecture and require better support. In this respect, the formali- [17] B. Neumayr, K. Grün, and M. Schrefl, “Multi-level domain modeling
sation illustrated in this work shows promising improvements with m-objects and m-relationships,” in Proceedings of the Sixth Asia-
and gains with regard to both expressiveness and correctness Pacific Conference on Conceptual Modeling - Volume 96, ser. APCCM
’09. Darlinghurst, Australia, Australia: Australian Computer Society,
checking. Inc., 2009, pp. 107–116.
Future investigation directions will include a more extensive [18] C. Atkinson, R. Gerbig, K. Markert, M. Zrianina, A. Egurnov, and
experimentation of deep metamodelling techniques, especially F. Kajzar, “Towards a deep, domain specific modeling framework
for robot applications,” in Proceedings of the First Workshop on
focusing on the adoption of different component models, in Model-Driven Robot Software Engineering (MORSE). CEUR-WS,
order to verify the malleability of deep metamodelling in com- 2014. [Online]. Available: http://ceur-ws.org/Vol-1319/
ponent adaptation/reconfiguration scenarios [13]. Moreover, [19] A. Rossini, J. de Lara, E. Guerra, and N. Nikolov, “A comparison of two-
level and multi-level modelling for cloud-based applications,” in Mod-
the formalisation will have to be embedded in a CBSE tool to elling Foundations and Applications, ser. Lecture Notes in Computer
better evaluate the usability/scalability aspects related to both Science, G. Taentzer and F. Bordeleau, Eds. Springer International
modelling and analysis tasks. Publishing, 2015, vol. 9153, pp. 18–32.
[20] J. Odell, “Power types,” JOOP, vol. 7, no. 2, pp. 8–12, 1994.
ACKNOWLEDGEMENTS [21] R. C. Goldstein and V. C. Storey, “Materialization,” IEEE Trans. on
Knowl. and Data Eng., vol. 6, no. 5, pp. 835–842, Oct. 1994.
The author would like to thank Jan Carlson and Severine
Sentilles for the interesting preliminary discussions around the
topic covered in this paper.