Tas,
Even just helping answer questions already makes a you a contributor.
So does testing and providing quality bugzilla reports. What you
meant to say, to put words in your mouth :-), is that you are not a
committer. Folks with a track record of providing quality patches for
bug fixes and feature enhancements can certainly pave their way toward
becoming a committer should they so desire. The same is true for any
project at Eclipse...
Tas Frangoullides wrote:
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@xxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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@xxxxxxxxxxxxxxxxx...
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
|