Hello Ludger!
Thank you very much for presenting your ideas on how to proceed with this.
Reading this I am not as optimistic as you on the complexity of this.
Among other things you have identified XMI import/export as one of the
requirements but you haven't mentioned how this is solved. In the current
solution this is provided by the UML repository (MDR or eUML) together with
the "promise" to implement the standard. In your solution the import/export
would require translations from the standardized UML 1.5 or UML 2.0 model to
the ArgoUML model.
Since both MDR and eUML are repositories generated from MOF models, the only
difference between your ArgoUML model solution and the current solution is
that in your solution there is always two models at play, the ArgoUML model
and the standard. On the other hand, by just locking down the UML version we
would get the benefits you talk about without having to implement anything.
I.e. we could then stop updating the application for every change of the
standard and instead start implementing conversions scripts to import/export
future versions of the model.
Looking at it like this, I think it is better to adapt the application to
standard changes than to work with new import/export conversions. Mostly
because if the standard change, it changes because there is some new
requirement on an Element. It would be backword to first implement some
conversion of the import, then implement the new Element within an old
static model and finally some conversion script for conversion on export. I
think it is easier and more straight-forward to take the new version of the
standard for each update, plug it into eUML or MDR and then fix the things
that break and implement the new requirements on Elements, i.e. what we
currently are doing.
/Linus
2010/9/30 Ludger Solbach <[email protected]>
> 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
> exchange
>
> 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
> projects
>
> 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
> significantly.
>
> 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 version.
>
> 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 cumbersome).
>
> 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),
>
> Ludger
> ___________________________________________________________
> Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
> Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02
>
> ------------------------------------------------------
>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2666636
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
> To be allowed to post to the list contact the mailing list moderator,
> email: [[email protected]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2667915
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
