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]]
