Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [modeling-pmc] Waynes question about how a UML2 Profile looks like

Hi Wayne et al.,

to supplement this discussion and to clarify some things, a UML profile
is UML model that extends the UML metaclasses with further attributes,
operations, constraints etc. An extension of a UML metaclass is called a
stereotype, however, a stereotype is not considered as a subclass of the
extended metaclass. There is actually no generalization relationship
among a metaclass and a stereotype, but an extension (kind of
association).

Physically, a UML profile for the UML2 project might be a single UML
model that is dynamically linked with the UML model it extends, or a
"complete" Ecore model implementation, where each Stereotype results in
an EClass instance. The advantage of the second approach is that it
allows several things which are not possible with the dynamic approach
(like derived references, subsets etc.).

As Ed already mentioned, UML profile is a well-known term in the UML
environment since UML 1.x. I don't think this has to be defined or
explained again.

Regards,
Marc-Florian



-----Original Message-----
From: modeling-pmc-bounces@xxxxxxxxxxx
[mailto:modeling-pmc-bounces@xxxxxxxxxxx] On Behalf Of Philipp W. Kutter
| Montages AG
Sent: Sonntag, 17. Juni 2012 00:05
To: modeling-pmc@xxxxxxxxxxx
Subject: [modeling-pmc] Waynes question about how a UML2 Profile looks
like

Hi, Wayne.
 > I'm more curious about the second part of my question. What does a
UML2 Profile look like? Is it just an ecore file, or is there more to
it?

A UML2 Profile is first of all an instance of the UML2-metamodel. The
UML2-metamodel can be considered a model written in ECore to simplify
the situation. Thus one answer to your question is that an UML2 profile
manifests as an UML2 model, using the UML2 constructs to define
profiles.

However, these profile constructs define additional attributes,
references, inheritance for existing UML2 constructs. Thus the idea is
natural, to do this definitions not as instances of the UML2 profile
constructs, but as ECore models, whose classes extend the classes of the
UML2 metamodel.

In the Eclipse work on UML2, as far as I can guess, I assume, that the
profiles are defined and stored as ECore models, but if we would store
them to correct XMI of the UML2 metamodel, I assume they would not be
ECore models, but UML2 models.

Kenn: please correct me if I told something that is fundamentally wrong.

Regards, Philipp






_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc


Back to the top