On Wed, Apr 8, 2009 at 4:49 AM, Thomas Neustupny <[email protected]> wrote:
> it turns out that new methods will be needed for UML2, and even some > of the existing ones have sometimes a different meaning in UML2. The Model API definition isn't tied to the UML specification. We try to keep the names the same or similar to help application developers find what they need, but if the API says it means something different from the spec, that's what it means, so it will never be true that "some of the existing [methods] have sometimes a different meaning in UML2." > Example: getSpecification(handle). In UML2, this method is applicable > to a behaviour (e.g. a method) and returns it's behavioral feature > (e.g. an operation). But in the current implementation, we apply this > method to operations! This sounds like it would be an upwardly compatible change to the API, but if it's not a new method/method signature needs to be defined. > 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. > 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. 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. Don't underestimate how long this takes. There are still parts of ArgoUML (e.g. Tagged Values & Stereotypes) which haven't fully moved from the UML 1.3 to UML 1.4 semantics and API. Tom ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=1600111 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]]
