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]]
