Hi Linus That sounds like some positive feedback for my proposals at last :-)
Certainly it would help to make such a start and get some clearer design and documentation A requirements page on the wiki would be good too Here are a couple of points to be added to such a page 1. The repository used should be project specific so that when ArgoUML can hold multiple projects it can hold a mix of UML1.4 and UML2 projects. 2. Each repository implementation must be a module loaded by our standard plugin mechanism Bob. On 6 October 2010 16:08, Linus Tolke Tigris <[email protected]> wrote: > Do we have enough information to start this work? Can I start by creating > classes and interfaces or drawing class diagrams? > /Linus > > 2010/10/6 Bob Tarling <[email protected]> >> >> 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]] > > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2668839 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]]
