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

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

Perfect!
Thanks for your pains in bearing with me in this!

I´ll try and send a true example I can share over the weekend.


In the meanwhile, the general case is that:

If I need to create a metaclass "CarType"
which must have (in adition to car-type-specific) the capabilities to
capture and express:

classification (of its instances)
attribute and reference features
inheritance of specification
containment in packages
namespace for contained elements

(yes, a simple example, the fact that these are what eMOF and eCore expose,
is of no significance for the example)


Then these semantics are well covered with the
UML2::InfraestructureLibrary::Core::Constructs::Class

and if there is no need at all for other (UML) capabilities like:
having behavioral features
having ports
being deployable


We should not need to have to specialize the full Class specification (as
with all packages merged).


Whoever may think, that there is no wrong is having more than less,
then think again:

If specializing the full Class implementation (all merged)
then a pure reflective machinery (for example, as eCore dynamic
instantiation is a pure reflective machinery)
would indeed expose all the characteristics of the full Class specification,

while if we had as independently available,
a Class implementation,
as specified in
UML2::InfraestructureLibrary::Core::Constructs::Class
then the dynamic machinery would explose just the features needed.
(or at least, a more controlled and reduced set of reused UML features).


Of course, in addition to separate packages and class implementations,
the nicest for reuse would be to deliver not one,
but many plugin, such that reusers would have to deploy only selected parts
of UML (and its unavoidable prerequisites).


Hope this helps to understand my problem,
while I produce an example.

Cheers,
Antonio Carrasco Valero
Model Driven Development ltd.


-----







"Tas Frangoullides" <tas.frangoullides@xxxxxxxxxxxxxxxxxx> wrote in message
news:eh6aed$era$1@xxxxxxxxxxxxxxxxxxxx
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>