[news.eclipse.tools.uml2] Re: Why UML2 metamodel is "flattened" ?

["Antonio Carrasco Valero" <acv@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Tas, Kenn, thanks a lot for the rationale and explainations,
fully consistent with with the reality of the problem and solutions of UML2 
implementation
and indeed with comments from EdMerks and others at Eclipse Summit.

- By the way, a most memorable event. Loved it!


--- Many Objects in Memory ---
I understand that using the composition/delegation approach to Java 
implementation of multiple inheritance, creates more complex object 
networks.

I observe that the choice of approach (composition/delegation) is driven by 
the need to avoid duplicating method implementations (and data slots 
declaration) in multiple classes,
quite an important requirement in EMF, as developers must be able to 
customize code,
and do it in a single place - not everywhere a certain structure or behavior 
happens to be inherited into.

But, I hope that we can find other technical solutions,
such that fully compliant UML2 implementations can be produced,
while preserving our investiment in current usages of UML2
- and ironing out one or two wrinkles in the alignment between Eclipse and 
OMG.

I look forward to James work about UML2 extension.


--- Metamodels and Profiles ---
The rendering of Metamodels as Profiles of UML
is a common practice since the unification at the famous OOPSLA'95,
and mandatory in OMG standards.
Indeed, the last non-UML-aligned submission BOCA
(Business Object Component Architecture, 1998) was rejected,
and the following submissions had to include (and were in fact named after)
a UML Profile rendering of their Metamodels
(i.e. UML Profiles for CORBA, for EDOC, for EAI, and for SPEM, among 
others).

Similarly, this reflected the duality of vendor camps,
the one partial to UML "final" (as in Java classes, not extensible) tool 
vendors,
and the MOF alternative.

It was my understanding that OMG's UML2 effort tried to resolve both 
problems,
by enabling the goal of a family of UML languages,
with enhanced interopeability by commonality of reusable semantics,
and unequivocal adoption of MOF as the metamodelling language of choice.

Today, Eclipse proves to the community at large,
how modelling tools can be extended with new semantics and syntax,
that become first class citizens of the tool, as the ones originally shipped 
by the vendor.



---  ---
In short:
I observe that most of the audience is being driven towards
non UML pure unrelated Domain Specific Languages
or to Profiling mechanisms in "final" UML tools.

Therefore I see no real market or user need for "final" tools,
and that the choices made, about which approaches to enable and facilitate,
are strongly influenced by the market dominance efforts
that Microsoft, IBM and Sun must engage themselves in,
to better guarantee their long term success.

On the other side, the community at large is now much better equipped than 
10 years ago,
in a big part, thanks to these very same dominance efforts of the market 
leaders,
but also to many others that wanted interoperable domain specific modelling.

After the amount of talent I've seen since July in
the ECDMA, JISBD and Eclipse Summit,
it won't surprise me a bit, if somebody comes up and publish
open source implementations of UML2 and MOF
that are fully aligned with the standards,
yet still righfully Eclipse.

Cheers!











"Tas Frangoullides" <tas.frangoullides@xxxxxxxxxxxxxxxxxx> wrote in message 
news:egeg97$r7l$1@xxxxxxxxxxxxxxxxxxxx
> Hi Antonio,
>
>
>
> I'm not sure I can answer all your questions but I've done some 
> heavyweight and lightweight extensions using uml2/emf and so some of what 
> I've learnt might be useful.
>
>
>
> Kenn once attempted to explain all the pains of retaining the hierarchical 
> structure of UML2 in the implementation but my head overheated before I 
> could absorb all of it. If I rememeber correctly one of the reasons the 
> Eclipse UML2 implementation was flattened is because it produced way too 
> many objects in memory, even for moderate sized models. I think the UML2 
> spec has since been updated to reflect this and the flat structure of 
> Eclipse UML2 is compliant. Personally I think this was a good thing also 
> because I find navigating the metamodel hard enough without having several 
> definitions of each element, and the API would have been way more complex. 
> Also, because the flattening is only done at the final stage of generating 
> the implementation you don't loose any of the cherry-picking potential of 
> the complete metamodel.
>
>
>
> If you want  you can define your meta model based on any part of the UML 
> superstructure or infrastructure and use the UML2 Codegen to generate 
> implementations. When I first starting learning about the UML metamodel I 
> was very interested in the prospect of reusing the infrastructure and 
> unmerged superstructure but in practice I've found extending complete 
> specification produces better and more flexible results.
>
>
>
> Although profiling is still not as flexible as metamodel extensions it 
> does have some advantages and is much improved in version 2.1 of the spec, 
> especially compared to UML 1.x.. The big advantage is you don't have to 
> write your own model editor and can reuse the UML diagramming capabilities 
> of your UML tool. However, profiles are trickier to extract data out of 
> when processing them but you can get round this by defining both a 
> heavyweight and lightweight extension. What I've done in the past is 
> define a nice clean metamodel (often based on UML2, at other times just an 
> EMF model) and then defined a UML2 profile equivalent. I then implement a 
> transformation between a profiled UML2 model an instance of my metamodel. 
> This gives me model instances that are clean and easy to traverse without 
> having to develop a new diagram editor. If you have diagramming 
> requirements beyond the UML2 diagrams then you've got lots of work to do 
> either way. If you are interested in this sort of thing then I recommend 
> taking a look at the GMF project.
>
>
>
> Hope that is of some use,
>
> Tas.
>
>
>
> "Antonio Carrasco Valero" <acv@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in 
> message news:eg8csf$2pv$1@xxxxxxxxxxxxxxxxxxxx
>>I am trying to produce a metamodel, not a Profile
>>  - as EMF provides such a rich metamodel implementation platform,
>>  that is not worth to put up with the lightweight profiling approach .
>>
>> My well-informed customers require their language to be as integrated as 
>> possible
>> with the UML Family of Languages promise of UML2,
>> and explicitly require to reuse as much reuse as possible of UML2 
>> semantics.
>>
>> But, Eclipse UML2 metamodel implementation has flattened all the UML 
>> modeling elements,
>> - therefore, their semantics and sintax -
>> and only offers the "leaf" specifications.
>> For example, in UML2 (infra & supra),
>> there are 4 (unless I missed some) Class specifications,
>> each incorporating selected semantics and syntax.
>>
>> My question is:
>>
>> How does Eclipse UML2 implementation support the OMG (and my customer's) 
>> requirement
>> of facilitating a UML2 family of languages,
>> as opposed to forcing most users to "profile" rather than metamodel ?
>>
>> My customer is specially sensitive to UML profiling,
>> because of their unfulfilled expectations in UML1.x profiling with RRose,
>> and perceive that it is a significant risk,
>> to expressing their semantically rich domain and technology models,
>> instantiating profiled vainilla UML elements,
>> rather than fully customized metamodels.
>>
>> How should I educate my customers about the profile-biased Eclipse UML2 
>> implementation ?
>>
>> Thanks,
>> ACV
>>
>>
>>
>>
>
>