[news.eclipse.modeling.mdt.uml2] Re: Best way to create an uml-approxima

[Kenn Hussey <Kenn.Hussey@xxxxxxxxx>]

Timothy,

Have you read the Wiki article on this subject (see 
http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Customizing_UML2_Which_Technique_is_Right_For_You/article.html)? 
You may find that it provides some useful information and/or decision 
criteria that you had not considered... Ultimately, though, there's no 
one "best" way to extend/re-use the UML metamodel; it all depends on 
what you are trying to accomplish and how much risk you're willing to 
entertain...

Kenn


Timothy Marc wrote:
> Hey you,
>
> after all my questions concerning the uml metamodel etc., you can 
> imagine, that i have to build a metamodel, that is partially very close 
> to the UML::Classes package. We have a controverse discussion, about 
> what is the best way to do this. We will have a lot of transformations 
> from the UML to our metamodel, in particular structural aspects like 
> Classes, etc. Here are the different opinions:
>
> 1. Reuse the kernel package by applying the merge mechanism to all the 
> packages and subpackages in the UML::Class package. This will provide 
> exactly the same strcuture as it is in the UML, and with EMF wonderful 
> capability to evaluate ocl expression, most of the additional operations 
> had not to be reimplemented.
> -> imho, this is right, but all the derived properties had to be 
> implemented again. So, this is an error-prone process.
>
> 2. Extending the uml metamodel is a good alternative, since we are in 
> the uml scope and therefore, we need no explicit transformation from uml 
> to our metamodel. An element X extend UML::Class is of course an 
> UML::Class, so that we can change the models between the UML and our scope.
> -> imho, this is the worth idea, because with this, we need the full UML 
> model, which is not necessary for us. Beyond that fact, it is not easy 
> to particpate to all these associations etc., so a detailled knowledge 
> of the UML is needed, that is not given by everyone.
>
> 3. Reimplement the concepts we needed from cratch with respect to the 
> UML metamodel. This provides a very flexible, yet independent mechanism, 
> to evluate our metamodel, uncoupled from the UML.
> -> i prefer this one. I know, reimplementing the classes kernel is not 
> very comfortable, but the best solution for our situation.
>
> To sum-up all this stuff: i think, point 1 or 3 are the most practical 
> ones, since they allows us to restrict or change some aspects of the 
> uml. In opposite, this is not compatibl with the UML, so everytime, we 
> need aspects from our metamodel, we had to convert the UML model into an 
> instance of our model.
>
> Is this mostly correct, and if so, are there other causes i can exhibit 
> in the upcoming discussion wiht my colleagues and my boss?
>
> Thx
> Timothy