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

["Tas Frangoullides" <tas.frangoullides@xxxxxxxxxxxxxxxxxx>]

Hi Antonio,

I would consider a fair number of the UML metamodel extensions I've created 
DSLs and did not find the flatenning a problem. I am yet to grasp how the 
flattening is restricting you. Would you mind explaining this with some sort 
of example? I am very interested in understanding your point.

Tas.

"Antonio Carrasco Valero" <acv@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in 
message news:eh0rj7$fv$1@xxxxxxxxxxxxxxxxxxxx
> Thanks Kenn,
>
> YES! Eclipse UML implementation is aligned with UML2.1 standard
> (here I refer to the subject of merged packages).
>
> The choice of flattening the whole metamodel into a single package,
> is indeed a standard simplification that has been incrementally
> added to UML2 in its various revisions over the last 3 years.
> (for details, see paragraphs at the end of the message).
>
> No (M1) modeler user with a "final" tool like Rational Architect
> would ever notice the flattening, nor needs to concern him or herself with 
> this.
>
> Granted!
>
>
> But as an Eclipse plug-in, where a great (and big) community
> is in the business of metamodeling and tooling
> the choice of Not Providing implementations of the merged/receiving 
> packages
> is in my opinion unfortunate:
> As explained in previous message,
> I fear their absence does not help in interoperability of DSLs,
> and makes Metamodelling by specialization of Eclipse UML2.1 
> implementation,
> a burden identical to that of Profiling
> as one has to suffer the whole merged specifications,
> and all their referenced elements,
> as opposed to just the semantics needed.
>
> I believe that it is possible and recommendable to supply to the community
> an implementation with the result packages,
> as well as the "intermediate" merged/receiving.
>
> Any interested parties ? - or are all already in the non-UML, discrete DSL 
> mindset ?
>
> Cheers,
> Antonio Carrasco Valero
> Model Driven Development sl
>
>
>
>
>
>
> Point 7.13.2 Package Merge of 2003´s OMG´s UML2.0 Superstructure Final 
> Adopted specification document 03-08-02 stated in the third paragraph:
>
> "A package merge is a relationship between two packages, where the 
> contents of the target package (the one pointed at) is
> merged with the contents of the source package through specialization and 
> redefinition, where applicable.
> This is a mechanism that should be used when elements of the same name are 
> intended to represent the same concept,
> regardless of the package in which they are defined. A merging package 
> will take elements of the same kind with the same
> name from one or more packages and merge them together into a single 
> element using generalization and redefinitions.
> It should be noted that a package merge can be viewed as a short-hand way 
> of explicitly defining those generalizations and
> redefinitions. The merged packages are still available, and the elements 
> in those packages can be separately qualified.."
>
>
>
> Then, point 7.3.40 Package Merge 2004´s OMG´s UML2.0 Superstructure Final 
> Adopted specification document 05-07-04 stated in the first two 
> paragraphs:
>
> "A package merge between two packages implies a set of transformations, 
> whereby the contents of the package to be
> merged are combined with the contents of the receiving package. In cases 
> in which certain elements in the two packages
> represent the same entity, their contents are (conceptually) merged into a 
> single resulting element according to the formal
> rules of package merge specified below.
> As with Generalization, a package merge between two packages in a model 
> merely implies these transformations, but the
> results are not themselves included in the model. Nevertheless, the 
> receiving package and its contents are deemed to
> represent the result of the merge, in the same way that a subclass of a 
> class represents the aggregation of features of all of
> its superclasses (and not merely the increment added by the class). Thus, 
> within a model, any reference to a model
> element contained in the receiving package implies a reference to the 
> results of the merge rather than to the increment that
> is physically contained in that package."
>
>
>
>
> Then, point 7.3.40 Package Merge 2006´s OMG´s UML2.1 Superstructure Final 
> Adopted specification document 06-04-02 stated in its first paragraphs:¨
> "A package merge is a directed relationship between two packages that 
> indicates that the contents of the two packages are
> to be combined. It is very similar to Generalization in the sense that the 
> source element conceptually adds the
> characteristics of the target element to its own characteristics resulting 
> in an element that combines the characteristics of
> both.
> This mechanism should be used when elements defined in different packages 
> have the same name and are intended to
> represent the same concept. Most often it is used to provide different 
> definitions of a given concept for different purposes,
> starting from a common base definition. A given base concept is extended 
> in increments, with each increment defined in
> a separate merged package. By selecting which increments to merge, it is 
> possible to obtain a custom definition of a
> concept for a specific end. Package merge is particularly useful in 
> meta-modeling and is extensively used in the definition
> of the UML metamodel.
> Conceptually, a package merge can be viewed as an operation that takes the 
> contents of two packages and produces a new
> package that combines the contents of the packages involved in the merge. 
> In terms of model semantics, there is no
> difference between a model with explicit package merges, and a model in 
> which all the merges have been performed."
>
>
>
> "Kenn Hussey" <khussey@xxxxxxxxxx> wrote in message 
> news:eh0i4a$6ro$1@xxxxxxxxxxxxxxxxxxxx
>> Antonio,
>>
>> Just to be clear, the UML2 implementation of the UML specification IS in 
>> fact fully alligned with, and conformant to, the UML 2.1(.1) standard...
>>
>> Kenn
>>
>> "Antonio Carrasco Valero" <acv@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in 
>> message news:eh0gbv$q74$1@xxxxxxxxxxxxxxxxxxxx
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>