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

["Kenn Hussey" <khussey@xxxxxxxxxx>]

Tas,

Yes, we do have plans to integrate support for OCL (which may include 
generation of code to evaluate constraints) in response to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105199. Of course help is 
always welcome (and in short supply)...

Kenn

"Tas Frangoullides" <tas.frangoullides@xxxxxxxxxxxxxxxxxx> wrote in message 
news:ehclfu$cc0$1@xxxxxxxxxxxxxxxxxxxx
> Antonio,
>
> You might be mistaking me for a contributor, which I am not, but like 
> yourself I am very appreciative of what all the developers provide. I just 
> try to participate in the groups and help out where I can.
>
> I don't know what direction the UML project is going with its 
> implementation of validations. I am looking at the direction of the OCL 
> project putting 2 and 2 together and probably making 5. Maybe Kenn could 
> provide insight.
>
> I've not used MOFscipt but it looks interesting. It would really cool if 
> the MOFscript editor could be used to edit OCL in ecore or UML models, 
> which could then be processed using the OCL plugins from the EMFT project.
>
> Tas.
>
>> Antonio Carrasco Valero wrote:
>
>> Marvelous!
>> And, of course, despite all this talk,
>> I love what you people and all this community has done with Eclipse ...
>> Yep! I?ll try it!
>> (to create a UML2 implementation in multiple dependent plugins, similar 
>> to original UML2 packaging) ...
>> then build a DSL with it!
>> Thanks a lot for helping me in clarifiying my worries, and showing a 
>> direction.
>>
>> Yes! I use OCL and MOFscript in the couple DSLs I?m prototyping.
>> - are you saying that a good part of UML2 validation is or will be
>> specified as OCL in the ecore files,
>> as opposed as in manually edited methods .?
>> ... therefore minimizing impact of those worries of mine about
>> partial generation ?
>> By the way, and totally off-topic:
>> I?d like to have MOFscript people contribute their assisted editor to the 
>> edition of OCL constrains on ecore models :
>> the coding cycle gets ridiculously long (for an old fashioned 
>> Smalltalker) unless hacking OCL strings "under the roof" with the 
>> debugger.
>> -- lucky as we are that OCL is fully reflective, caches nothing,
>> and does no attempt in generating any code/classes !!
>
> "Tas Frangoullides" <tas.frangoullides@xxxxxxxxxxxxxxxxxx> wrote in 
> message news:44bf8f218ef3817251abde1de1e2547e$1@xxxxxxxxxxxxxxxxxx
>> Antonio,
>>
>> All of the things you describe here should be possible but I haven't 
>> tried them myself. Note that the UML2 project gets to a flattened model 
>> by merging the infrastructure and superstructure. If you take a look at 
>> the source in cvs for org.eclipse.uml2.uml you will find all the 
>> infrastructure and superstructure models that are used. It also merges in 
>> the APIs convenience methods from a seperate model too.
>>
>> Also, getting to an implementation of a DSL might not be as tricky as you 
>> think. The majority is generated from the model and generally only 
>> custom/convenience methods and validations need to be coded. The UML2 
>> codegen should do the rest. Validations might also be generated soon (see 
>> http://www.eclipse.org/articles/Article-EMF-Codegen-with-OCL/article.html).
>>
>> So I'd say it has been designed to do what you want... its just waiting 
>> for you to try it :-)
>>
>> Tas.
>> Antonio Carrasco Valero wrote:
>>
>>> Dear All,
>>
>>> Ok. I see your point now ! (it was actually very clearly stated, below)
>>
>>>>>>>> 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.
>>
>>> I can always reuse selected parts of UML,
>>> by selecting from it the metamodel I need,
>>> and generating using the UML2 Code Gen.
>>
>>> So you are absolutely right that DSLs can very well reuse selected parts 
>>> of UML.
>>
>>> This opens a few questions - or rather, experiments I'll have to 
>>> conduct,
>>> where I could use some guidance ?
>>
>>> - Is it right that the better way to generate subsets is to prune the 
>>> CodeGen model,
>>>   rather than the source eCore(s) ?
>>> - Has UML Code Gen been tested, regenerating from "subsets" of the UML2 
>>> eCore?
>>> - Does it retains manual tweaks in all needed methods ?
>>> - Does it leave autogenerated or manually tweaked methods of feature 
>>> that have been removed from the eCore ?
>>>    how much approximate effort to write something to do it ?
>>
>>
>>> Asuming this works ok,
>>> then we have a nice amount of interoperability, because of the shared 
>>> metaelements.
>>
>>> But interoperability of instances of different DSL metamodels,
>>> having reused the same UML2 metamodel elements,
>>> and same UML2 reuse technique (as mentioned above),
>>> would still be referencing different Java implementation classes
>>> (and refering as metaclasses to different instances of eClass).
>>
>>> Therefore, it follows that it is possible - with the technique you 
>>> described -
>>> to produce implementations of diverse portions of the UML2 metamodel.
>>
>>> Then, I would choose to generate as separate plug-ins,
>>> portions of the metamodel coindident with the packages un the UML2 spec,
>>> with plugin dependencies in a graph that would closely match
>>> the merge dependencies between packages in the last UML2.1 spec.
>>
>>> Finally, I'd produce an implementation of a fully merged metamodel,
>>> reusing the above (this, may require some new automation - or 100 
>>> hands!).
>>
>>> With these plug ins distributed and freely available,
>>> and if the audience chooses to reuse selections of them,
>>> as "supertypes" when producing DSLs,
>>> then we would attain the greatest degree of Interoperability
>>> by Commonality.
>>
>>> Having exactly the same supertype implementations,
>>> for example sharing the ability of being a contained in a container,
>>> means that any metamodels' Package-like instance,
>>> may receive as contents an instance of another metamodel's Packageable.
>>
>>> Now, that'd be a nice level of tool extensibility.
>>
>>> I guess that this level of incremental build up
>>> of the Family of UML languages
>>> has been contemplated in the strategy of major tool vendors.
>>
>>> I surely hope that the choice made has been to exploit this approach in 
>>> its right time in the future.
>>> May be we can contribute, by experimenting, then hopefully showing to 
>>> the community,
>>> how this can be embraced earlier.
>>
>>> Cheers,
>>> Antonio Carrasco Valero
>>> Model Driven Development ltd.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> "Antonio Carrasco Valero" <acv@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in 
>>> message news:eh8ilv$gi2$1@xxxxxxxxxxxxxxxxxxxx
>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>
>