Application Conﬁguration via UML Instance Speciﬁcations

Ansgar Radermacher, Shuai Li and Matteo Morelli

CEA, LIST, Laboratory of Model Driven Engineering for Embedded Systems, P. C. 174, Gif-sur-Yvette, 91191, France

Keywords:

UML, Instance Modeling, Conﬁguration.

Abstract:

One way to design complex systems is to use a model driven approach. Model Driven Engineering (MDE)

promotes the use of models are primary artifact for analysis, design and implementation of a system. In

this paper, we focus on component-based models including classes (representing components), hierarchical

composition (classes with parts) and instance speciﬁcations. Instance speciﬁcations describe instances of a

system, i.e. provide values for (a subset of) the attributes of class attributes. However, the use of instance

speciﬁcations without additional tool support is tedious, since several references need to be setup. This paper

will show some mechanisms (notably tables) to ease the usability. There are also different ways to organise

instance speciﬁcations which have advantages and inconveniences. This paper lists them and provide hints in

which situation a certain variant could be used. Code generation from models needs to take instance conﬁgu-

ration into account, but application conﬁguration via instances is still not fully supported by all tools. We will

show how code generated from instance speciﬁcations can look like. This code becomes more interesting for

adaptive applications that need to change between different conﬁgurations at runtime.

1 INTRODUCTION

The modeling of systems is often based on compos-

ite structures, i.e. a system contains several subsys-

tems or components which in turn can contain fur-

ther subsystems or components. In such a hierarchi-

cal structure, composite classes have parts which in

turn are typed with other classes. A typical case is a

top-level class describing the functional architecture

of a system. The system is made-up of several (possi-

bly composite) software components with conﬁgura-

tion parameters, which can be set to different values

depending on different analysis scenarios the designer

wants to study. How can such a system be conﬁgured?

In many domains, the conﬁguration is speciﬁed

using Excel tables and then (more or less) manually

reﬂected in code or conﬁguration ﬁles. But it is pos-

sible to do the conﬁguration on the model level. This

has the advantage of enabling systematic and auto-

mated consistency validation of model information,

which is taken into account by code generation.

The use of UML mechanisms for conﬁguration

purposes is part of an initiative to ease (and if pos-

sible automate) modeling tasks. For instance, some

conﬁguration data can be computed from model in-

formation. If behavior descriptions in the the model

are for instance enriched with execution time infor-

mation, a schedulability analysis can decide whether

the system is schedulable and –if yes– automatically

calculate suitable task priorities that become part of

the system conﬁguration.

Classes in UML have a set of properties that can

capture conﬁguration values, either via a default value

or an instance speciﬁcation that describes a possible

instance of this class. While UML has a quite com-

plete set of modeling mechanisms for instances, there

are different ways of using these which have differ-

ent advantages and disadvantages. Additional tooling

is required to ease the usability of instance speciﬁca-

tions.

The organisation of the paper is the following.

Section 2 describes the meta-model of UML in-

stance speciﬁcations, their properties and use as de-

scribed in the standard. Section 3 sketches a simple

example application which we want to conﬁgure and

several ways to combine default values and instance

speciﬁcations. Section 4 shows tooling support, on

the one hand oriented to enhance usability, on the

other hand to show the impact of instance speciﬁca-

tions on the code generation. Section 5 discusses re-

lated work. The conclusion and future work are pre-

sented in section 6.

Radermacher, A., Li, S. and Morelli, M.

Application Conﬁguration via UML Instance Speciﬁcations.

DOI: 10.5220/0007583104950502

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 495-502

ISBN: 978-989-758-358-2

495

Figure 1: Meta-Model of UML instance speciﬁcation (UML speciﬁcation 2.5.1, section 9.8).

2 UML INSTANCE

SPECIFICATIONS

In this section, we describe an instance speciﬁcation

in detail. The current UML 2.5.1 standard(OMG,

2017) describes instance speciﬁcation as follows

“An InstanceSpeciﬁcation represents the possi-

ble or actual existence of instances in a modeled

system and completely or partially describes

those instances.

A Slot speciﬁes that an instance modeled by an

InstanceSpeciﬁcation has a value or values for

a speciﬁc StructuralFeature, which shall be a

StructuralFeature that is related to a classiﬁer of

the InstanceSpeciﬁcation owning the Slot by be-

ing a direct attribute, inherited attribute, private

attribute in a generalization, or a memberEnd if

the classiﬁer is an Association, but excluding re-

deﬁned StructuralFeatures. The values in a Slot

shall conform to the deﬁning StructuralFeature

of the Slot (in type, multiplicity, etc.). The val-

ues in a Slot are speciﬁed using ValueSpeciﬁca-

tions.”

Figure 1 shows the meta-model deﬁnition of UML

instance speciﬁcations, as in section 9.8 of the UML

2.5.1 speciﬁcation. An instance speciﬁcation is part

of a package, it can play the role of a deployed artifact

(if it deﬁnes an artifact) and can also be a deployment

target.

An attribute of an instance speciﬁcation is the

classiﬁer: a list of classiﬁers that a speciﬁcation clas-

siﬁes. In most cases, an instance speciﬁcation refer-

ences a single classiﬁer, often a class or data type.

The set of slots describes values for structural fea-

tures (typically properties of a class or datatype) of

the instance. Not all properties of the InstanceSpec-

iﬁcation need be represented by Slots, in which case

the InstanceSpeciﬁcation is a partial description. An

InstanceSpeciﬁcation may represent an instance at a

point in time (a snapshot). Changes to the instance

may be modeled using multiple InstanceSpeciﬁca-

tion, one for each snapshot. Section 9.8.3 of (OMG,

2017) states

“It is important to keep in mind that Instance-

Speciﬁcation is a model element and should not

be confused with the instance that it is model-

ing. As an InstanceSpeciﬁcation may only par-

tially determine the properties of an instance,

there may actually be multiple instances in the

modeled system that satisfy the requirements of

the InstanceSpeciﬁcation. On the other hand,

an InstanceSpeciﬁcation may model a situa-

tion which is not actually supposed to occur in

the modeled system, in which case no instance

meeting the requirements of the InstanceSpeci-

ﬁcation may ever actually occur in the system.”

An InstanceValue is a ValueSpeciﬁcation that refer-

ences an InstanceSpeciﬁcation. Any slots in the In-

stanceSpeciﬁcation then provide values for the corre-

sponding StructuralFeatures of the instance by eval-

uating the ValueSpeciﬁcations associated with those

slots.

Please note that an InstanceValue does not own

the InstanceSpeciﬁcation to which it refers; multiple

InstanceValues may refer to the same InstanceSpeci-

ﬁcation (OMG, 2017).

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

496

Instance speciﬁcations have to respect a set of

constraints, notably:

• An InstanceSpeciﬁcation can act as a De-

ployedArtifact if it represents an instance of an

Artifact.

• Each slot must reference a different deﬁning fea-

ture to avoid conﬂicting values for this feature

• The deﬁning feature of each slot is a Struc-

turalFeature (directly or inherited) of a classiﬁer

of the InstanceSpeciﬁcation.

• An InstanceSpeciﬁcation can act as a Deploy-

mentTarget if it represents an instance of a Node

and functions as a part in the internal structure of

an encompassing Node.

3 EXAMPLES

Let us look at a very simple example of a robotic com-

ponent. A mapper component has two conﬁguration

attributes: a boolean indicating whether it is work-

ing indoor or not and a noOfScans attribute that indi-

cates the number of scans per second to be done. In

UML, the component is modeled as a class with at-

tributes. Figure 2 shows the associated class diagram

containing the attributes along with their default val-

ues. On the model level, the default values for the

two attributes are a LiteralBoolean and a LiteralInte-

ger, respectively. See also the Papyrus4Robotics web-

page

AcmeMapper

indoor: Boolean = true

noOfScans: Integer = 5

Figure 2: A simple class with two attributes.

Now consider that the component is used in a spe-

ciﬁc system in which we want to conﬁgure one of the

values in a different way. Figure 3 shows a “system”

class with three parts. Each of the part is typed with a

different robotic component. The part m is typed with

the class AcmeMapper – m is thus an attribute with

aggregation kind “composite”.

We choose to provide a default value for m that

changes the noOfScans attributes of the AcmeMap-

per. Here, the default value is an InstanceValue el-

ement that points to a separate instance speciﬁcation

Getting started with Papyrus4Robotics: https://robmo

sys.eu/wiki/baseline:environment tools:getting started with

papyrus4robotics

SystemComponentArchitecture

m: AcmeMapper

pMap

p: EmcaPlanner

pPlan

rMap

useAdd

a: Adder

addSvc

MapMap

Figure 3: A component assembly by means of a composite

class.

for the AcmeMapper. Unlike the InstanceValue ref-

erence, the instance speciﬁcation cannot be stored

within the default value, i.e. the user has to de-

cide (typically following a convention) in which pack-

age he wants to put the speciﬁcation. In our case,

we choose to create a separate top-level package

instances in which we place the instance (and simi-

lar ones for the two other components in our system).

Figure 4 shows the instance speciﬁcation. It as-

signs a different value (15) to the noOfScans at-

tribute, i.e. overrides the default value on class level.

Note that this instance speciﬁcation is partial in the

sense that it does not re-deﬁne a value for all attributes

of the class.

IS for AcmeMapper

noOfScans : Integer = 15

Figure 4: An instance speciﬁcation for the AcmeMapper

class.

The scheme above works ﬁne with a single hi-

erarchy level. In case of nested components, it

is also possible to override the default value at

multiple levels. If we now assume that class

SystemComponentArchitecture describes a sub-

system in a more generic architecture deﬁnition, we

can add a default value for the attribute within the

generic architecture (container) that describes ﬁrst the

subsystem and then overrides the default value for the

part m with an additional slot.

In this case, the slots of the top-level instance

speciﬁcation use an InstanceValue that in turn points

to an instance speciﬁcation at the second level. As

shown in Figure 5, it is thus possible to describe to

override the default value for m with an instance spec-

iﬁcation that re-assigns the value 10 to the noOfScans

attribute. Please note, that we only show a subset of

Application Conﬁguration via UML Instance Speciﬁcations

497

TopLevelS: TopLevelSystem

subsystem = SubIS

SubIS: SystemComponentArchitecture

m : AcmeMapper = IS' for AcmeMapper

IS' for AcmeMapper: AcmeMapper

noOfScans : Integer = 10

Figure 5: A set of hierarchical instance speciﬁcations.

the slot values to simplify the ﬁgure.

It is possible that some instances are shared.

Imagine that an additional component, e.g. the plan-

ner is accessed by multiple components. While it is

possible to make this explicit via ports and external

connections as shown in diagram 3, it is also possi-

ble to access a the planner via an internal attribute

as a shared component (an attribute with aggregation-

kind = shared). In case of the example, the planner

would be an internal shared attribute within the map-

per and adder. Figure 6 shows a variant of the mapper

component that accesses the planner via a shared in-

stance, graphically denoted by the dashed line. The

motivation for using shared components is to “inter-

nalize” commonly used components instead of have

a large number of connections in bigger systems that

all point to a set of common components. However, it

must be unambiguous to which component the shared

attributes refer to and that at least one instance exists.

The former is not a strict condition: while it becomes

ambiguous to which instance a shared attributes refers

to when we only take the class composition into ac-

count and multiple instances exist, an instance-value

in the set of instance speciﬁcations would explicitly

reference exactly one instance. The tree structure

formed as in Figure 5 becomes a graph structure with

shared elements. Yet, it might be useful to impose ad-

ditional rules that avoid the ambiguity already on the

class level, either by adding the constraint that there

must be exactly one non-shared attribute in the par-

ent composition structure for each shared attribute or

setting up precedence rules which reference should be

chosen.

Discussion. The nesting of instance speciﬁcations

is quite difﬁcult to handle for a user, as we will see in

section 4. But besides of this aspects, another ques-

tion is to which extent default values should be used.

As we have seen in the previous section, we can al-

ways override a default value with an instance speci-

AcmeMapper'

p: EmcaPlanner

Figure 6: Access to shared instance speciﬁcations.

ﬁcation referenced from a higher level.

In some cases, we want to reuse an existing com-

ponent assembly (represented by a composite class

such as SystemComponentArchitecture) in differ-

ent contexts. For attributes that are likely to keep their

conﬁguration value, the assignment of default values

make sense. For others, it is preferably not to use a

default value but to require a conﬁguration via an in-

stance speciﬁcation.

Such a tree of instance speciﬁcation has been

shown in the Figure 5. As already mentioned, it is not

possible to reﬂect the tree structure via a real nesting

of instance speciﬁcations since a value cannot directly

represent a new instance speciﬁcation but point only

indirectly to another instance (via an InstanceValue).

While this has been done with the intention to favor

reuse of instance speciﬁcations, it requires a ﬂat rep-

resentation of a tree-like structure (of which some el-

ements might be shared). One way of managing the

hierarchy is to use a suitable naming convention by

encoding for instance the tree path (separated e.g. via

“.”) in the path, e.g. topIS.subIS.m. In order of

being effective, tool support is required to update the

names whenever part names change or the hierarchy

changes.

The possibility of sharing is a powerful modeling

mechanism that simpliﬁes the access to commonly

used components. But it needs to be used carefully

to avoid ambiguities.

The systematic use of (nested) instance speciﬁ-

cations for conﬁguration purposes can be compared

with an approach that is called deployment plan

(OMG, 2006) in the context of the CORBA compo-

nent model: a set of conﬁguration values along with

deployment information. In some projects, we’ve al-

ready used a hierarchy of instance speciﬁcations to

describe the application components. In addition, an-

other set of instance speciﬁcations describes deploy-

ment targets, i.e. a set of hardware nodes containing

conﬁgurable attributes such as the amount of RAM or

ROM. Allocation information points from instances

of software components to instances of hardware

nodes.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

498

Figure 7: Use a table to conﬁgure default values.

4 TOOLING

This section is split into two parts. In the ﬁrst, we

show ways to ease the modeling of default values and

associated instances. In the second, we show code

generation support from models containing instance

speciﬁcations.

4.1 Enhanced Usability of Instance

Speciﬁcations

The creation of instance speciﬁcations can be quite te-

dious, as already sketched in section 3. The user has

to specify the referenced classiﬁer and then add a slot

for each attribute that needs to be conﬁgured. The slot

in turn requires the selection of the deﬁning feature

reference and a value speciﬁcation. If the attribute to

conﬁgure is a primitive type holding a numerical (in-

teger or real), boolean or string value, UML provides

appropriate value deﬁnitions such as LiteralInteger,

LiteralReal, LiteralBoolean or LiteralString. As al-

ready mentioned, composite data types require an ad-

ditional instance speciﬁcation that is referenced from

an InstanceValue. The latter is also used for enumera-

tion literals (which are effectively instance speciﬁca-

tions).

Additional tool support is required to ease the cre-

ation and visualization of instance values. Figure 7

shows a table that conﬁgures a set of default values

of a class, specially the AcmeMapper introduced in

section 3. This table is an extension of the Papyrus

UML modeler that has been provided in the context

of a customization for the robotics domain (without

being actually speciﬁc for that domain). When the

class to conﬁgure is selected, all attributes are shown

(optionally only showing attributes that are tagged as

conﬁguration attributes). The user can simply enter

a value in a string from and the tool will automati-

cally chose a suitable value deﬁnition depending on

the attribute type. Please note that this table is only an

Eclipse Papyrus, see eclipse.org/papyrus

additional notation – the model still contains standard

UML instance and value speciﬁcations.

Figure 8 shows a quite similar table in case of se-

lecting a part in the component assembly, in this case

the part m representing an instance of the AcmeMapper

component. The table shows the conﬁguration at-

tributes of the referenced component. If the part has

a default value referencing an instance speciﬁcation,

the table checks whether one of the slots in the in-

stance speciﬁcation overrides a default value on the

class level. An overridden value is shown with a yel-

low background. If the user edits a value, the asso-

ciated slot and value will be automatically created.

If the user enters a new value and no instance spec-

iﬁcation exists yet, it will be created ﬁrst (using the

naming convention to place the instance speciﬁcation

in a speciﬁc package) and the classiﬁer reference is

setup accordingly. If the ﬁeld value corresponds ei-

ther to the default value on the class level or is empty,

the corresponding slot in the instance speciﬁcation is

removed.

These two tables simplify the conﬁguration via in-

stance speciﬁcations considerably. An additional tool

support (which is part of the Payprus extension SW

designer

) manages the automatic creation of a tree-

like set of instance speciﬁcations from a composite

class with parts that are typed with other classes. Fig-

ure 9 shows different deployments of an application.

Each of these deployments is represented by a pack-

age containing a set of generated instance speciﬁca-

tions. The naming of the instance speciﬁcation name

reﬂects the hierarchical decomposition. The user has

the possibility to update the names of instance speci-

ﬁcations via a command in the context menu. This is

required after changes of part names or of the compo-

sitions hierarchy.

The instances also contain allocation information.

If an instance speciﬁcation is selected, a table as in

Figure 8 is shown. We plan to use a hierarchical table

to enable an easy navigation to different levels within

wiki.eclipse.org/Papyrus Software Designer

Application Conﬁguration via UML Instance Speciﬁcations

499

Figure 8: Use a table to conﬁgure values for a part typed with a given component.

Figure 9: Multiple deployments.

the tree structure.

Compared to the diagrams shown for instance in

Figure 5, tables scale much better: a table with hun-

dreds of entries is still quite easy to handle, whereas a

diagram should not represent more than a dozen in-

stance speciﬁcations. As the relationships between

instances are typically tree like (optionally with some

sharing) the graphical representation does not provide

an added value and (hierarchical) tables are a good

representation of the underlying conﬁguration data.

Thus, tools change the way a user perceives the in-

stance speciﬁcation metaclass and its relations (e.g.

composition of instance speciﬁcations).

4.2 Code Generation from Instance

Speciﬁcations

The speciﬁcation of conﬁguration data needs to be re-

ﬂected in the generated code. In case of Papyrus SW

designer, code generation for C++ and Java is sup-

ported. Default values are directly initialized in the

Listing 1: Attribute conﬁguration in boot-strap code in C++.

v o i d B o o t L o a der : : i n i t ( ) {

/ / c o n f i g u r e a t t r i b u t e s

m a i n I n s t a n c e . p u ll C o n Th r e ad . p r i o r i t y

= 5 ;

m a i n I n s t a n c e . f i f o c o n n e c t o r . m s iz e =

3 0 ;

m a i n I n s t a n c e . c r e a t e C o n n e c t i o n s ( ) ;

. . .

generated class deﬁnitions. In case of a deployment

plan, boot-strap code for each deployment target is

generated. This code contains the instance conﬁgura-

tion. In this case, the conﬁguration of all non-default

attributes is done by this top-level boot-strap code.

The code in listing 1 shows the attribute conﬁguration

for one of the deployments in Figure 9.

This example is interesting, since one of the con-

ﬁguration attributes has a speciﬁc semantics – thread

priorities could be the result of a scheduling analysis

at the model level. The advantage of doing the con-

ﬁguration at the model level is that the relevant infor-

mation is centralized within the model.

5 RELATED WORK

Instance speciﬁcations are a powerful modeling in-

strument. Their use is not new, but surprisingly lit-

tle work has been done to describe systematically

how these can be use to conﬁgure applications. Most

work is part of either tutorials and tool descriptions.

The tool MagicDraw from NoMagic provides accel-

erations based on drag & drop to assign a classi-

ﬁer to an instance speciﬁcation or to assign a de-

fault value to a property (NoMagic, 2019a). How-

ever, there is no support for automatically creating a

set of instance speciﬁcations from a composition of

classiﬁers. If a larger number of instance speciﬁca-

tions needs to be managed, NoMagic recommends the

use instance tables as well to enhance usability, see

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

500

(NoMagic, 2019b). Instance tables are also used by

another Papyrus extension, the MOKA (CEA, 2019)

tool that enables the direct execution of (fUML) mod-

els. The documentation for Rhapsody contains in-

formation about instance modeling (IBM, 2019), but

does not give any hints on how to use these systemat-

ically. Rhapsody simpliﬁes the assignment of values

via popup dialogs in which values could be entered

directly instead of explicitly having to chose the re-

spective UML element (such as LiteralString or Lit-

eralInteger).

The work done in (Agarwal et al., 2000) states

that traditional class-based models are not sufﬁcient

in case of enterprise models, but need to be accompa-

nied by instance models. The management of these

instance models needs to be facilitates by tools. How-

ever, the work is not speciﬁc for UML models and

does not cover the possibilities of UML instance spec-

iﬁcations. Whole-part relationships have been ex-

amined by (Guizzardi et al., 2002), the paper deals

with the aggregation vs. composition aspects between

classes and instances. While the paper is speciﬁc for

UML (the relatively old version 1.4), it does not par-

ticularly deal with instances. Sharing of instances is

an important concept in the FRACTAL component

model (Bruneton et al., 2006).

Many tools generate code from UML models, but

most do not mention speciﬁc support for generating

code from instance models. In case of Rhapsody, de-

fault values are either initialized via assignment or in

the constructor.

(Ciccozzi et al., 2012) presented a mechanism to

support full code generation from UML models. The

approach that has been used in the European project

CHESS, contains a dedicated model of component

and port instances, taking multiplicity information

into account. The latter assures that a port of a compo-

nent instance interacting with others has the matching

multiplicity (e.g. two, if the component instance inter-

acts with two others) and to generate the appropriate

code. Assuring that multiplicity information matches

is the subject of (Mammar and Laleau, 2014) which

attacks this issue in a more formal way using the B

language.

In case of Papyrus SW designer already men-

tioned in section ref sec:tooling, the support is

twofold: it supports the initialization of default val-

ues as well as an initialization via boot-strap code that

might override the default values. The tool also takes

multiplicity information into account and has a val-

idation rules that check whether these are matching.

An extension of this tool supporting the (re-) conﬁg-

uration of instances at run-time is presented in (Hus-

sein et al., 2017). A UML state-machines captures

the different application states along with transitions

that are triggered by adaptation events. Each state is

coupled with a deployment plan, i.e. a set of instance

speciﬁcation that correspond to this state.

6 CONCLUSION

In this paper, we have shown how to use UML in-

stance speciﬁcations to conﬁgure a system. While

UML instance speciﬁcations are quite powerful, their

usage needs additional tool support to improve usabil-

ity. Tables are a suitable and saleable way to conﬁgure

instances – and ease the transition for developers that

are use to conﬁguration via Excel tables. While not

being new, there is surprisingly little work that list

different ways to organize these instances, e.g. the

use of default values, the possibility override these or

the sharing of instance speciﬁcations. Putting the ap-

plication conﬁguration into the model enables a ﬁrst

validation on the model level.

We have also shown that UML lacks the possi-

bility of nesting of instance speciﬁcation. While in-

stances values can point to other instance speciﬁca-

tions, the instance speciﬁcations can now own other

instance speciﬁcations.

Code generation support is required, if the gener-

ated code should actually take the conﬁguration val-

ues into account. This becomes more interesting, if

we take re-conﬁgurable applications into account that

are able to change between different conﬁgurations.

The work underlying this paper has been partially

funded by the RobMoSys project from the European

Union’s Horizon 2020 research and innovation pro-

gramme under grant agreement No 732410.

REFERENCES

Agarwal, R., Bruno, G., and Torchiano, M. (2000). Instance

modeling – beyond object-oriented modeling. In Pro-

ceedings of the 3rd International Conference on Infor-

mation Technology (CIT 2000).

Bruneton, E., Coupaye, T., Leclercq, M., Qu

ema, V., and

Stefani, J.-B. (2006). The FRACTAL component

model and its support in Java. Software-practice and

Experience, 36:1257–1284.

CEA (last visited 2019). Papyrus MOKA User Guide.

https://wiki.eclipse.org/Papyrus/UserGuide/ModelEx

ecution.

Ciccozzi, F., Cicchetti, A., and Sj

odin, M. (2012). Full Code

Generation from UML Models for Complex Embed-

ded Systems. In Second International Software Tech-

nology Exchange Workshop (STEW) 2012.

Application Conﬁguration via UML Instance Speciﬁcations

501

Guizzardi, G., Herre, H., and Wagner, G. (2002). Towards

Ontological Foundations for UML Conceptual Mod-

els. In Meersman, R. and Tari, Z., editors, On the

Move to Meaningful Internet Systems 2002: CoopIS,

DOA, and ODBASE, pages 1100–1117, Berlin, Hei-

delberg. Springer.

Hussein, M., Nouacer, R., and Radermacher, A. (2017).

Safe adaptation of vehicle software systems. Journal

Microprocessors & Microsystems, 52:272–286.

IBM (last visited 2019). Instance speciﬁcations in UML.

https://www.ibm.com/support/knowledgecenter/SS8P

J7 9.5.0/com.ibm.xtools.modeler.doc/topics/cinstance

spec.html.

Mammar, A. and Laleau, R. (2014). A Proved Approach

for Building Correct Instances of UML Associations:

Multiplicities Satisfaction. In 21st Asia-Paciﬁc Soft-

ware Engineering Conference, volume 1, pages 438–

445.

NoMagic (last visited 2019a). Instance Speciﬁcation.

https://docs.nomagic.com/display/MD183/Instance+

Speciﬁcation.

NoMagic (last visited 2019b). Instance Table. https://

docs.nomagic.com/display/MD183/Instance+table.

OMG (2006). Deployment and Conﬁguration of Compo-

nent Based Distributed Applications, v4.0. OMG doc-

ument formal/2006-04-02.

OMG (2017). Uniﬁed Modeling Language (OMG UML),

Version 2.5.1. OMG Document formal/2017-12-05.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

502