>From what I can tell the node elements on a UML2 activity diagram would be anything that implements the eclipse ActivityNode interface. The majority of those also implementing Action interface. For Action there are many subtypes.
Normally in ArgoUML we have had one Fig per model element type. I'm considering a different pattern for this development. The problem our current pattern gives us is evident with FigClass and FigInterface. What if we wanted a refactoring type tool to convert a class to an interface? We'd have to - - Delete the whole FigClass remembering it position and what edges are attached to it. - Delete the class model element remembering associations, attributes and operations - Create an interface model element restore the associations, attributes and operations - Create a new FigInterface and restore the position - Recreate the edges with their previous layout. With so many different types of action I think there is an increased likelihood of the user changing their mind and wanting to change the precise type. My thoughts are to have a FigAction as the concrete class for all action types. This class will have a decorator that indicates what subtype it is actually represents. That subtype can modify its appearance and behaviour of FigAction. A conversion operation will still of course have to delete the model element and create the new one (unless the eclipse API gives a way to convert - that would be nice). For the GUI though it becomes a lot neater. The edges are still attached to the FigAction even if its owning model element and decorator have changed. In hindsight this would have been great at the level of FigNodeModelElement. It would break our dependency on that class for inheritance, made the profile work a lot more straightforward and allowed this kind of change in many places. A good lesson if the diagrams are ever reworked in eclipse-GEF. Bob On 15 July 2010 08:06, Thomas Neustupny <[email protected]> wrote: > Hi Bob, > > great news! > >> I confess this was rather - "monkey see, monkey do". I followed an >> example elsewhere and this seems to work.See below for my first >> attempt to implement a build method in EUML > > I always feel the same when working on UML2 support! Anyway, we'll end with a > lot of UML2 code that looks "UML1"-stylish because of the old names and the > mimicking UML1 flows. That will leave a lot of work even after everything > works. > > (Keep up making progress with new diagram types, meanwhile I'm struggling > with ecore extensions in xmi after applying a profile.) > > Cheers, > Thomas > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2633358 > > 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=2633621 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]]
