9 messages in org.tigris.argouml.devRe: [argouml-dev] the road to UML2| From | Sent On | Attachments |
|---|---|---|
| Thomas Neustupny | Mar 31, 2009 12:32 am | |
| Bob Tarling | Mar 31, 2009 2:57 am | |
| Bob Tarling | Mar 31, 2009 6:29 am | |
| Thomas Neustupny | Mar 31, 2009 12:31 pm | |
| Tom Morris | Mar 31, 2009 1:20 pm | |
| Dave Thompson | Apr 1, 2009 5:08 am | |
| Linus Tolke | Apr 1, 2009 10:17 pm | |
| Thomas Neustupny | Apr 2, 2009 3:02 am | |
| Thomas Neustupny | Apr 3, 2009 3:12 pm |
| Subject: | Re: [argouml-dev] the road to UML2 | |
|---|---|---|
| From: | Thomas Neustupny (thn...@gmx.de) | |
| Date: | Mar 31, 2009 12:31:34 pm | |
| List: | org.tigris.argouml.dev | |
Hi Bob!
This page splits out work on property panels as if they are a part of working on a diagram. That is not really the case. We could have someone work on panels for just those elements on a class diagram but the user can still load some XMI that contain other elements that will fail if they select them in the explorer and they display in an incomplete property panel.
I'd suggest the blocks in that wiki for Class Diagram Implementation, Use Case Diagram Implementation are reorgansied to contain also other relevant subsystem as main blaock such as Property Panels and Explorer. I don't think we can release any single diagram until those are working.
I'm happy to edit the wiki if this is agreeable but didn't want to go to the effort unless others follow my logic.
You are absolutely right, put the explorer, persistence, property panels and
whatever is needed to the appropriate sections. We can later restructure it
again as soon as the dependencies get clearer. Thanks for clarifying.
Could we instead split a second explorer implementation following UML2 design with ArgoUML loading one or the other depending on the UML implementation? (hopefully there will still be some common logic we can keep in just one place).
I don't know if this is needed, and how much work it would be to let only one
explorer instance handle both UML1.x and UML2.x elements, so I can't say
anything here (yet). I have not found in Bogdan's reports that the explorer
needed a significant change, he only wrote that he needed to change the core
ArgoUML because he had not the time to use mementos but wanted to demonstrate
undo/redo.
If we can first get the explorer into its own eclipse subproject we can have only the eUML launcher include the replacement at startup and current standard Argo load the existing explorer.
If I understand correctly this also supports further modularization, am I right?
It seems to be one possible approach.
Christian (penyaskito) and myself are concentrating at the moment on revisiting the XML property panel module from his last GSOC in order to get that in a state for release.
The module is driven from an XML file that is derived from the UML1.4 metamodel. The intention is then to drive that same module from an XML derived from the UML2.x metamodel.
This allows us to contribute towards UML2.x without actually getting directly involved in the eUML subsystem.
I agree. Christian (Penyaskito) already told me about it. Great! Can you add
this to the wiki then?
For this reason I'd appreciate it if people kept enhancements to our current property panels to a minimum. Please wait on the replacement panels (or contribute you work there) or you will be giving us more work to do to complete the replacement.
OK.
My intention after this was to work on visualizing templates in FigClass. I think thats long overdue but if others think I would do better to contribute elsewhere then please suggest.
It is really a missing feature, even for UML 1.4, and as a CG/RE module
developer (for Java), I appreciate that work.
I see Tom has made some recent commits to eUML, that is good to see. I wonder if Bogdan still intends to contribute. It is those two devs with most experience in this area.
Yes I wish he could review our ideas/plans.
What are your plans Thomas?
I wanted to concentrate on UML2 only in the core project, and then only on the
Java module. (I'll try at least.)
The first one: How will the legacy UML 1.4 projects be handled? I think if we can make it a little easier by doing a "hard cut" (and maintain two ArgoUML separated streamlines for a while: UML1.4 and UML 2.x). Because I don't know how much it takes to create a migration tool. The worst would be to make ArgoUML deal with both UML1.4 and UML2 models...
What do you mean by separate stream?
Two branches with regular releases: the 0.28 (UML1.4) based stable trunk with
maintainance releases, and the eUML based developer releases. In the eUML branch
I'd be willing to radically tear down all bridges to UML 1.4 (maybe an project
upgrade to UML2 feature only) and break everything in a first step, then build
up feature by feature again, but I know that this is probably not what others
think.
I think the best would be to make ArgoUML deal with both UML1.4 and UML2 but I don't know for how long this will be practically possible.
Uhm... :-)
Maybe that's the better approach. I only thought: the more it hurts, the more
effort is taken to make it work again (quick but painful). :D
I don't see why we can't have a release that can still do all of UML1.4 and can also do just class diagrams in UML2 with extra diagrams being added over time.
Yes, probably. I don't know. Bogdans suggestion for a GSoC participant was: "The
student should implement the model subsystem's interfaces, but this should be
done incrementally. Incrementally means that you will implement what is needed
in the model subsystem for a specific functionality." But maybe for us as the
team another approach is more appropriate.
How about this - ArgoUML moves to release 1.0 then every subsequent release is 1.x until we have the final UML2 diagram and go to release 2.0
The 1.0 release for me would be your 2.0 release. So I'd move to 0.30 first.
(For others 1.0 might stand for full RCP support and eclipse integration.)
Thomas
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1498928
To unsubscribe from this discussion, e-mail:
[dev-...@argouml.tigris.org].
To be allowed to post to the list contact the mailing list moderator, email:
[lin...@tigris.org]