Hello Thomas!
Just like Tom, I am not very enthusiastic about splitting the code base in
two or stop the development and releasing of ArgoUML while we move to UML2.
I think we need to do it in small steps to keep the team alive.
Because of how we have built ArgoUML, the Model subsystem is the subsystem
at the root of this and as such it leaves very much room for improvement.
The big question, that we are still struggling with after so many years is
how to build it with the ever changing UML standards.
At one end, we have the "Plug in the specification and press
generate"-alternative that was the vision for NS-UML, MDR and Ecore that was
chosen when ArgoUML moved from a homegrown model to NS-UML. At the other end
we have the "We define our own API and hide the insides"-alternative that we
embarked on with the move from NS-UML to MDR and that I hope will also take
us to the Ecore/EMF-solution so this is not really the issue.
The issue is how we shall evolve "our API" to best fit with the requirements
of UML2. As I understand UML2 I have identified, in this respect, two big
changes that we need to consider on a high level:
- Separation into Infrastructure/Superstructure, and
- Diagram Interchange.
These are both so fundamental that we need to consider making changes to the
architecture of ArgoUML to better fit with the future of UML. Other changes,
I consider small in that they are only adding new elements and diagrams
or altering the meaning of existing elements and diagrams. Even though they
are small I think they will take most of the time to complete.
The separation in Infrastructure/Superstructure directly affects the Model
subsystem in that we could consider reorganizing the Model subsystem in two
levels to mimic the separation in the specification. I have not yet
understood if there is any benefit to gain from this. If this is just a
question of labelling, a solution where we think of the Infrastructure part
as "generated from the specification" and implemented by MDR or Ecore/EMF
and the current Model subsystem API is relabeled to reflect the
Superstructure part will take us a long way in the mindset without a lot of
code changes.
The Diagram Interchange doesn't directly affect the Model subsystem but it
highlights the fact that we have a rather weak mechanism of saving the
diagram information. I would like us to move towards also saving the diagram
information in MDR or Ecore/EMF according to the given specification. This
change is not directly connected to the UML2 change but affects the role of
the Model subsystem. One of my questions, that would affect the ArgoUML
architecture, is if the Diagram Interchange is based on the Infrastructure
level or if it has its own low-level specification. In the first case we
should rethink the Model subsystem, Diagrams subsystem, and the Persistence
subsystem and what their responsibilities are. In the second case we could
keep with the current architecture while moving the Diagrams subsystem over
to MDR or Ecore/EMF (even if I feel that the rethinking is in place also in
this case).
Concluding this, I think we could work on three fronts:
- Fixing up the Euml model implementation and adding the new UML2
elements and diagrams. This can be done by diagram type or by some other
criteria. This is probably most of the work and I hope that this work is
already in progress.
- Discussing the pros and cons of reorganizing the Model subsystem to fit
the Infrastructure/Superstructure separation. This could end up in some
fundamental changes that hopefully are easy to do with help of the Eclipse
refactoring tool.
- Move the Diagrams subsystem over to the Diagram Interchange save
format.
/Linus
2009/4/9 Thomas Neustupny <[email protected]>
> Hi Tom!
>
> > > Different usage of the model subsystem will require a lot of
> > if-Statements
> > > in ArgoUML, checking for Model.getFacade().getUMLVersion(). Is this the
> > > right way to go? (As I said before, I'd prefer to abandon a release
> that
> > both
> > > supports UML1 and UML2, so NO such if-Statements, is this
> indiscutabel?)
> >
> > I think there should be strong (overwhelming) evidence to support
> > abandoning the existing API and forking the code base before
> > considering such a drastic move. I'd be surprised to hear that you've
> > implemented enough of the eUML subsystem to have reached that
> > conclusion already. If you do decide that the Model API can't do it's
> > job, you should throw it out and start over with a clean design. Just
> > about the only thing the current design has going for it is that it
> > supports the existing application.
>
> With your hints for further developing the API for eUML I see
> no problem to use it both for UML1 and UML2. It's the usage of
> the API that differs for UML1 and UML2, so that the code gets
> complicated with all those UML version checking if-statements.
> I'm for forking ArgoUML to a UML1 version and UML2 version, both
> using the *same* model API!
>
> From the user perspective:
>
> Either ArgoUML will be a hybrid UML1/UML2 tool that can handle
> both, or there will be two ArgoUML tools (one for UML1 and one
> for UML2) and a one-way conversion facility. I believe the
> latter is sufficient, because I can't imagine why it is needed
> to work with UML1 and UML2 project in one tool. If conversion
> to UML2 is not possible or for some other reason not desirable,
> then one can still work with ArgoUML 0.28.
>
> So I see no real value in a hybrid ArgoUML, only headache:
> - all code (e.g. diagram code, RE/CG subsystem, notation, all
> modules) will get cluttered, hard to maintain and probably
> error prone
> - learning curve for new developers will get steeper (they
> must take care to not brake the UML1 behavior of Argo)
> - both UML1 and UML2 UML specifications will be relevant
> - new features need will potentially also needed to be
> developed for UML1 simultaneously, which could slow down
> further development (e.g. DI support)
> - team structure is not suitable for this complicating factor
> (we're just small and slow working team of volunteering
> developers, which of course is nobodies fault, it's just the
> way it is)
>
> Just my thoughts about this, for now I'll of course work
> further towards supporting both UML1 and UML2 at the same
> time.
>
> > > For methods only used in either UML1 or UML2, I'd propose to have them
> > > both in the model subsystem, and then let the appropriate
> "wrong"/unused
> > > method throw a new kind of Exception
> >
> > That's what I defined org.argouml.model.NotImplementedException for
> > during the UML 1.3 -> 1.4 transition. Is there a reason it can't be
> > used? The eUML module subclasses it as
> > org.argouml.model.euml.NotYetImplementedException for things which are
> > transitional, but MDR can throw root exception for things which are
> > never going to be implemented.
>
> Thanks, this is exactly what I need! So the default implementation
> in eUML is throwing a NotYetImplementedException, which eventually
> will be replaced by some functional implementation or a definite
> NotImplementedException (for UML1 relevant API methods), right?
>
> > Note that it's not an option (unless you are abandoning compatibility)
> > to throw this on a permanent basis for something in the existing API.
> > The methods would need to be deprecated and removed.
>
> I guess you are talking about methods that are not needed/wanted
> neither in the eUML nor in MDR implementation?
>
> Thanks for your feedback, it clarified a lot for me! Really helpful
> if you begin working with eUML.
>
> 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=1610506
>
> 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=1625134
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]]
