Sorry for spending so long getting back to this I've been rather preoccupied with work matters.
Although we have problems in adapting the to the EUML repository my gut feeling is that creating our own would not be the right way to go. Some way of auto-generating a wrappers around EUML may be useful though. We have a very limited team here and it would worry me that we are stretching ourselves too far to develop our own model or if we lose the required skills to do so we have gone too far down one path. In theory there should be far more than our small team working on improving the tools within eclipse. Our biggest problem at the moment does not appear to be with the model itself but with actually creating the new diagram types for UML2. I'm finding it difficult to find the time myself at the moment. I recently raised issue http://argouml.tigris.org/issues/show_bug.cgi?id=6161 - if we could get our diagrams to construct themselves by interpreting some XML file in a similar way to how our properties panels now build I think we can reduce much of our the effort in future and reduce the overall code size. I still think we also need to consider an alternative interface to our current model interface (facade). History and problems with the model interface can be found here - http://argouml.tigris.org/wiki/Model_Interface_History and here http://argouml.tigris.org/wiki/Model_Interface_Criticisms I'm still putting all my arguments together for what I've been referring to as the Repository Interface. I think that interface requires a lot less detail than either UML1.4 or UML2 would suggest we need. For the property panels much of the code doesn't care about the model element its dealing with. It just looks up in the XML of what needs to be displayed and calls the model interface to get the detail. It doesn't actually go as far as I'd like with this, I think I can move more logic into the model that is currently in the property panel module. Once the GUI of ArgoUML is XML driven the code then becomes a lot more generic. Double clicking an compartment of a compartmentbox need only determine the model element that owns the compartmentbox (owner) and they type of compartmentbox clicked (type) and do - type.createElement(owner); For what I have documented so far on the Repository Interface see - http://argouml.tigris.org/wiki/Repository_Comparison_With_Model_Interface There has been some criticism that such an interface would be difficult to use for more specific tasks that are not driven by some XML file. For example our code generation and reverse engineering code would likely become quite clunky looking if there weren't more specific classes and methods available. Typically though this would be limited to those classes that correlate to programming languages such as Class, Interface, Attribute, Operation, Parameter etc. These have remained fairly static between UML releases and where they do differ has been easy to code around. I agree that for these some more specific interfaces would required and for this I'm considering another layer on top of the Repository Interface, the Repository Facade. This layered approach makes sense to me, the first layer being as simple as possible wrapping and hiding the repository implementation (MDR or EUML) and the second layer adding just enough detail to make the interface easier to use (the true purpose of a facade which I fear we fail with in our current model facade). Use of either layer by ArgoUML should be valid. Regards Bob ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2668353 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]]
