I thought I'd just give some feedback of progress. This is going over some ground I've discussed already but I'll reiterate anyway.
The UML2 activity diagram is different enough from the UML1.4 diagram to have developed it as an entirely new diagram. That new diagram has been developed as a module. As this module is isolated from the rest of ArgoUML its given me the opportunity to go back to basics and design a diagram from first principles without having to worry about fitting in with any of the rest of our architecture. What I have achieved so far is 1) Breaking dependency on FigNodeModelElement (breaking away from FigEdgeModelElement will follow) FigNodeModelElement has grown out of control. We know it listens for far too many things and redraws too often. Changing it to improve it could have consequences on any of our existing diagrams. FigNodeModelElement also forces a class knowledge dependency from all diagrams to this class rather than implementing interfaces. So in the UML2 activity diagram I introduced BaseFigNode. That is the FigNode class for all nodes in the activity diagram. BaseFigNode is actually package scope but I have also defined an interface for this which is public. BaseFigEdge also exists but currently extends FigEdgeModelElement. 2) XML defines FigNode layout Nothing extends BaseFigNode. Instead an XML file describes what child Figs need to be added to BaseFigNode for any particular diagram element. As BaseFigNode will have an interface defining it then it is only that interfaces that individual diagrams will need to know. I intend to also define edge structure with XML and do similar for that. I hope that having XML definitions will minimise what has to be written if and when we replace tigris-GEF with some other library. The same definitions should drive an alternative implementation. 3) Notation improvements The existing notation subsystem is strongly tied to FigNodeModelElement and FigSingleLineText. That is why I decided to start fresh with a new implementation which breaks us away from the diagram subsystem which is currently spread throughout core argouml. One rule of the new design is that no text Figs listen to the model. Instead they listen to the notation instances. Notations listen to the model and may filter out sending repeated events to the diagram (although its not that clever as yet). The only Figs that should listen to the model are node/edges listening for delete events and compartments listening for add/remove events. The new notation subsystem is developing in its own module and has interfaces defined. For the activity diagram I have implemented use of the new notation currently just for displaying the name of the states in the diagram (looks a bit messy right now but getting there). Typing directly onto the diagram is not yet implemented but will follow soon - as that will be just state names it should be fairly easy. More complex notation will come when this is used in other diagram types I think. At the moment I'm only implementing UML notations and placing that in the same module as the notations subsystem. Notations for other languages like Java should probably move to the module we already have for that language and those modules should register themselves with the notation subsystem. Next Steps (aside from anything mentioned above) a) Persistence Currently Figs write their class name to the PGML file and loading a project uses reflection. For activity2, all classes will be BaseFigNode or BaseFigEdge. I see changes are likely to be needed to cope with this. b) Diagram subsystem module Currently activity2 contains BaseFigNode and its interface but those classes have potential reuse in other diagrams. Once the activity diagram has matured enough I'll move any candidates for reuse into a Diagram subsystem module. This will not contain any full diagram implementation but will contain those classes and interfaces that are needed by all other diagram modules. So we will have another module that some other modules will depend upon (but no cycles). This matches what we have referred to as the Diagram Subsystem but has not previously been a clearly separated subsystem in our code. c) State diagram Once we have a diagram subsystem physically separate from ArgoUML then the next diagram I will try and implement is the UML2 state diagram. Its needed for UML2 and there are clearly elements of reuse between this and the activity diagram so it seems a logical next step. Other new UML2 diagrams can also be implemented. d) Sequence diagram This is our only other modularised diagram so it would be good to make this consistent with the others. So I'd like to move this away from FigNode/FigEdgeModelElement and use the new notations. e) Other diagrams Gradually other diagram types can come out of ArgoUML into their own module. We should be then able to remove GEF knowledge from core ArgoUML. Regards Bob ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2721438 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]]
