> - Undo support, I think only the UML2 modules will have it, while the UML1 > parts not?
Any work in euml should take undo into support and follow the examples there that we already have. What I'm not convinced of is the support for undo in other parts of ArgoUML/GEF. I did some work on adding undo support to GEF but it hasn't had any testing and I wouldn't expect it to work without any problems first time around. So I wouldn't want to make any promises to users to expect this until we see what results we get. > - Model API: keep one, or have two (create a new for UML2)? Just expand what we have for now. If we create new methods for UML2 that are simply not implemented by UML1.4 I think that is no problem. I think we do need to build a far better UML model interface but we can't do that now, it's increasing the scope of our work again. > > I think both will be solved. So, how to start, so that an explorer module for > UML2 can be > made, and that both "New" and "Load" will work? After we discussed you mail, > I (or > whoever wants) can document our plan in the dev wiki. > Presumably ProjectBrowser should trash the previous explorer instance after load and replace with whatever new one is required. But we do need some extension point from which a plug-in can register itself as an explorer (providing an identifier of what UML model it is for). We also need the current model interface to be able to swap between MDR impl and euml impl during project load. That needs some further thought. Regards Bob. > -------- Original-Nachricht -------- >> Datum: Mon, 27 Jul 2009 00:22:00 +0100 >> Von: Bob Tarling <[email protected]> >> An: [email protected] >> Betreff: [argouml-dev] Progress (or lack of) with UML2 > >> It seems little if anything is being done with UML2 at the moment. >> >> This seems to me to be very much due to lack of any architectural >> steering. >> >> I'll do my best to remedy this by putting forward some ideas. >> >> I understand that there are some who are unhappy with the idea of >> ArgoUML being developed to support both UML1.4 and UML2. There have >> been some discussions on the IRC channel questioning why this decision >> was made. Why not branch ArgoUML (with UML 1.4) now and begin to write >> the next release of ArgoUML (with UML2.x) cutting out any of the old >> 1.4 stuff we would no longer want to support in a new release. >> >> The problem I have with that is exactly what we have seen so far. The >> move to UML2.x has stalled. So what happens to any of the other fixes >> and enhancements made to trunk? Do we do the extra work to make some >> changes to trunk and branch so that we have some improvements we can >> release as 0.30 even if we haven't got UML2 complete? >> >> The arguments I've seen to branch have been because code (that nobody >> has made visible yet) is becoming to complex with if statements to >> manage different features of UML1.4 and UML2. >> >> I really would like to see some examples of this so I could understand >> the problems. >> >> To my mind for UML2.x the two largest jobs other than the euml >> implementation are the property panels and the explorer. >> >> The work I'm doing at the moment (admittedly very slowly) is to >> complete the implementation of property panels by XML files. I >> wouldn't like to undersell what is needed to then replace that with >> UML2 based XML files. However it will certainly make it easier for >> UML1.4 and UML2.x to be interchangeable in the property panels. >> >> If the explorer is so difficult and complex to work on then why not >> start a new plug-in for a UML2.x explorer rather than branch our >> existing code? When loading a project we can use our current existing >> explorer in the left side compartment if UML1.4 or use the explorer2 >> plug-in if UML2.x. This way we can keep some common base classes or >> helper methods for used by both but essentially replace the explorer >> entirely with the new version for UML2.x. >> >> This gives all the advantages of branching but keeps us the ability to >> still load UML1.4 in trunk and release that trunk at any time we are >> prepared. >> >> I really don't know enough about all the diagram changes that are >> involved. But the same principle can be used to replace diagrams. >> >> The UML1.4 sequence diagram is a plug-in already. That registers >> itself with the DiagramFactory in SequenceDiagramModule. >> >> If we modify DiagramFactory so that diagrams register themselves with >> some list of identifiers that they are compatible with then ArgoUML >> can decide at runtime which diagram factories to call at runtime. >> >> So if UMLSequenceDiagram was registered as "UML1.4,UML2.x" then >> ArgoUML would make the action to create that diagram visible no matter >> which version of UML was relevant for the current project. >> >> But alternatively UMLSequenceDiagram could be registered as"UML1.4" >> and only available when the current project is UML1.4. This would not >> be visible to the user when the current project is UML2.x. If its seen >> as too difficult to make UMLSequenceDiagram compatible with both we >> can then introduce a new UMLSequenceDiagram2 class in a new plug-in >> that is registered as "UML2.x". >> >> The NewProject menu I'd expect to become >> >> New->UML 1.4 Project >> New->UML 2.x Project >> >> And this is how the projects initial UML type would be set. >> >> When loading a project we have no great issue. We just load the UML >> type from the argo file. The correct diagram will load anyway using >> the reflection mechanism in persistence. >> >> After load or new project we need to hide/show the relevant explorer >> and hide/show the relevant new diagram actions. >> >> With working towards UML2 we need to begin working on allowing this >> architecture. >> >> On top of that we should >> 1) Continue implementing euml model implementation as far as we >> require for first release. >> 2) Property panels complete >> 3) Explorer complete >> 4) UML2 class diagram complete >> >> To my mind that would be enough for our first UML2.x release. >> >> I fear if we try to do more than this then we will just delay and >> delay and never get there. If we can get just one diagram type >> available but ability to view full model in explorer and panels then >> we can begin to develop other diagrams in subsequent releases. >> >> Regards >> >> Bob. >> >> >> >> >> >> The solution I would prefer >> >> ------------------------------------------------------ >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2375727 >> >> 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]] > > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2376115 > > 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=2376155 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]]
