Login | Register
My pages Projects Community openCollabNet

Discussions > The Developers' mailing list > [argouml-dev] Progress (or lack of) with UML2

argouml
Discussion topic

Back to topic list

[argouml-dev] Progress (or lack of) with UML2

Author bobtarling
Full name Bob Tarling
Date 2009-07-26 16:22:02 PDT
Message 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

« Previous message in topic | 1 of 11 | Next message in topic »

Messages

Show all messages in topic

[argouml-dev] Progress (or lack of) with UML2 bobtarling Bob Tarling 2009-07-26 16:22:02 PDT
     Re: [argouml-dev] Progress (or lack of) with UML2 thn Thomas Neustupny 2009-07-27 12:29:30 PDT
         Re: [argouml-dev] Progress (or lack of) with UML2 bobtarling Bob Tarling 2009-07-27 14:59:00 PDT
             Re: [argouml-dev] Progress (or lack of) with UML2 linus Linus Tolke 2009-08-08 10:47:51 PDT
                 Re: [argouml-dev] Progress (or lack of) with UML2 bobtarling Bob Tarling 2009-10-02 04:12:16 PDT
                     Re: [argouml-dev] Progress (or lack of) with UML2 linus Linus Tolke 2009-10-02 09:24:10 PDT
                         Re: [argouml-dev] Progress (or lack of) with UML2 bobtarling Bob Tarling 2009-10-02 09:26:57 PDT
                             Re: [argouml-dev] Progress (or lack of) with UML2 thn Thomas Neustupny 2009-10-03 14:56:18 PDT
                                 Re: [argouml-dev] Progress (or lack of) with UML2 linus Linus Tolke 2009-10-04 10:33:36 PDT
                                 Re: [argouml-dev] Progress (or lack of) with UML2 linus Linus Tolke 2009-10-05 22:09:34 PDT
                             Re: [argouml-dev] Progress (or lack of) with UML2 linus Linus Tolke 2009-10-04 10:17:34 PDT
Messages per page: