atom feed7 messages in[argouml-dev] On the implementation o...
FromSent OnAttachments
Ludger SolbachSep 30, 2010 8:05 am 
Linus Tolke TigrisOct 4, 2010 2:09 pm 
Bob TarlingOct 5, 2010 6:14 pm 
Linus Tolke TigrisOct 5, 2010 10:19 pm 
Bob TarlingOct 6, 2010 2:12 am 
Linus Tolke TigrisOct 6, 2010 8:08 am 
Bob TarlingOct 7, 2010 1:49 am 
Subject:[argouml-dev] On the implementation of ArgoUML specific UML repositories
From:Ludger Solbach (
Date:Sep 30, 2010 8:05:58 am

Hello everybody,

I'd like to discuss the problems of adapting ArgoUML to new versions of UML and
whether implementing ArgoUML specific UML repositories instead of external UML
repositories (UML2, MDR and NSUML) could improve the situation. I am aware the
current effort of migrating to eUML2 for UML 2 support and it is not my
intention to derail that. But I think the following apporach is worth a few
thoughts (I have created a feature request as Issue 6158 for this).

The requirements of UML repositories for ArgoUML IMHO include: * support for multiple UML versions (at least UML 1.4 and UML 2.0+) with the
same generic mechanisms for model management and editing * full support for moving and deleting model elements and references to model
elements (MDR doesn't seem to shine here) * multi model and profile support * XMI import/export * support for different XMI versions per UML version to allow easy model

This is definitly not a complete list, because I'm not familiar enough with the
internas of ArgoUML, I have to admit.

To support a new UML version, at the moment a new external UML repository is
used, because there are no ArgoUML specific UML repositories. Every external UML
repository has a different interface, different semantics and mechanisms. The
effort needed to switch to a new external repository is quite high because the
new interface, semantics and mechanisms have to be adapted. While the actual
model elements change for each version of UML, IMHO the generic mechanisms for
managing them shouldn't.

The added value of an ArgoUML specific UML repository would be * the mechanisms of the UML repository could be taylored to the needs of
ArgoUML * the semantics and the generic interface mechanisms would stay the same for
different UML versions, so adapting a new UML version would require much less
effort * the direction of development of the repository could be steered by the
ArgoUML community * no need to adapt to different metamodels for new UML versions (eg. EMOF/ECore
instead of OMG-MOF with UML2) * ArgoUML could be more self contained with fewer dependencies on external

The work required to implement an UML repository by hand is quite high in itself
and might be prohibitive for a project like ArgoUML. But there are some
techniques which could lower the required work for such a repository

First of all there is 'Model Driven Software Development'. As each UML version
is defined in a MOF model, a repository for that UML version can be generated
from that MOF model (provided that you have the MOF model and a generator for
MOF). As XMI is defined on MOF and not on specific UML versions, XMI readers and
writers for different XMI versions could be generated from the MOF model of UML.
So a repository for a new UML version would be generated from a MOF model of
that new version with the same repository template. New XMI readers/writers
would require new templates but they could be applied to every UML model

Currently I am using this approach for a generator framework I am working on. I
am using an ArgoUML model of UML 1.4 to generate a read only repository, a XMI
1.2 reader and a XMI 1.2 writer for UML 1.4. The generation is done with a
previous version of the generator framework for which i had modeled the UML
spec as XML schema and generated the UML repository and XMI reader with XSL and
Castor XML (the Schema/XSL/Castor approach proved to be too restricted and

I'm including the UML 1.4 model zargo file, feel free to use or change it as you
like. I'm also including some of the generated artifacts, but these are just for
demonstration the possibilities and not usable standalone (look at the
attachments of Issue 6158).

In the included model, there are currently 3 relevant deviations from the
diagrams in the UML 1.4 spec. 1.) The element 'ObjectLink' is missing, because of multiple inheritance. 2.) One Association of Instance.playedRole is missing because of duplicate
return types in the generated code. 3.) A role name 'comment' is added to the Comment end of the association
ModelElement<->Comment These deviations are just a workaround for me at the moment. With a bit of work,
the problems could be addressed in the generation templates instead of the model
(rendering them more context sensitive of course).

The next technique is AOP with AspectJ as implementation. The hard part of the
generic mechanisms for a model repository IMO is the deletion of model element
references in the repository. Adding model elements or references to model
elements is no problem as long as there is no need to remove them later. To
support deletion of model elements (which is integral for a model editor like
ArgoUML), there has to be a bookkeeping mechanism to keep track where a specific
model element is referenced. Otherwise it is really cumbersome to remove all
references to a model element when the element itself is deleted. There are
quite a few issues in the tracker which are based on the fact, that it is hard
to do so with MDR. The information of the fact where model elements are used and
where references of model elements are used, are clearly defined for UML and are
stored inside of the MOF model (composition vs. aggregation and references). So
as long this information is present in the source code of the repository (e.g.
an annotation on the field), an aspect could refer to that information and
provide a generic mechanism of that bookkeeping.

Here is a possible sketch of that aspect: * whenever a new model element is added, register it with it's xmi id in the
mechanism (eg. a registry inside the aspect) * whenever a reference to a model element is added, register the xmi id of
element which holds the reference with the xmi id of the referred element * whenever a reference to a model element is removed, unregister the xmi id of
element which holds the reference with the xmi id of the referred element * whenever a model element is removed from the model, remove all reference by
iterating the registrated reference holders registered with the xmi id and
remove the reference to the element

A similar aspect (or an enhancement of the previous) could take care of the
model elements in diagrams.

The parts of the code that are directly based on the data in a UML spec model of
a specific version should be generated from that model. The parts of the code
which are not based on the specific UML version but on the UML metamodel (MOF)
could be implemented as generic mechanisms in the templates or as aspects
working on the generated code.

What do you think of this approach in the context of ArgoUML? Is it just
derailing the migration to UML2 or do you think it could be an opportunity to
bring ArgoUML forward?

With kind regards (and curious for your opinions),


___________________________________________________________ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren:


To unsubscribe from this discussion, e-mail:
[]. To be allowed to post to the list contact the mailing list moderator, email: