Hi Linus I think we shouldn't align ourselves to tightly to any structure as the OMG could then break us at any time in some future release. Much of own package structure is based around UML1.3 which makes little sense now. We should think of our needs for these interfaces first.
However chapter 9 of the MOF Core Specification (06-01-01) is closest to what I have in mind for the first level level wrapper. However there would be some differences. 1. I would have add and remove methods as well as the set method specified here so that we can easily things like add operations to a class. 2. I would have MetaType class, instances of which would be the factory classes 3. I would have no Package at this level 4. I would have have methods such as canAdd and canSet so that a caller can test what the particular UML element version being wrapped is able to contain (e.g. UML 1.4 would return false when testing attribute in an interface whereas UML2 would return true) 5. The factory methods of MetaType will take an existing element as an argument. The newly created element will be assigned to that existing owner as soon as it is created. This prevents the possibility of creating a model element and having it left outside the model. Using the above I think the XML property panels would shrink down in code size massively as there is a lot of work in there at the moment that is effectively one big switch statement to determine.which specific methods of the model interface to use. If we can also drive the Figs by XML then we will have the same result there. "Element" then becomes the most basic type of object we pass around representing a UML element rather than our current use of a dumb Object as a token. I'm currently wondering if there are other things we should allow at this level that can be done with any Element. e.g. Provide methods to get Stereotypes and TaggedValues and define the interfaces for those here also. The RepositoryFacade level would be extensions of the Element from RepositoryInterface and would only be a small subset of the model elements available in UML2. There is no need to create some of the more esoteric elements used by activity diagrams and state diagrams if the diagram code doesn't need it and the property panel code doesn't need it. Bob On 6 October 2010 06:19, Linus Tolke Tigris <[email protected]> wrote: > These two levels, do they fit well with the UML2 > Infrastructure/Superstructure-separation? > /Linus > > Den 6 oktober 2010 03.14.53 UTC+2 skrev Bob Tarling <[email protected]>: >> >> 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]] > > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2668503 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]]
