Hi All I think we currently have far too much wiring in FigNodeModelElement (and FigEdgeModelElement) it is getting far too large and cumbersome and the idea of having a large inheritance tree from there is too restricting and hasn't been the best design pattern for us.
In the UML2 activity diagram module I am attempting to make a divergence from this. I started off realizing that we shouldn't be using inheritance but instead a state pattern. All nodes should be the same concrete class but the way in which they are drawn should be allowed to be changed by assigning another class to it that adds that detail of behaviour. This became apparent to me when the profiles work was implemented. If a profile wants to change the way a Fig is drawn there are currently all sorts of hacks in FigNodeModelElement to call different flavours of the setBounds method and hide all the work that the concreate classes would otherwise try to do to display the Fig. If the way to draw just becomes a state then we have a state for drawing rectangular Figs, a state for drawing oval Figs, a state for drawing compartment box figs that can be assigned at any time. If a profile wants to change that state then that is no problem. Those states can be reused and the state can be changed so that a Fig can have its display behaviour changed for other purposes (e.g. an Interface can draw as a classifierbox but with a state change it draws as a lollipop instead). I have started to implement the state pattern in the UML2 activity diagrams with FigBaseNode as the only FigNode for all types. There are various state classes that allow that node to draw itself as is appropriate, currently RectDisplayState, RRectDisplayState, PentagonDisplayState and ConcavePentagonDisplayState for each of the types of node display of activity diagram elements. The very long term plan is that FigBaseNode will replace FigNodeModelElement but for now it must inherit from it as too much of the rest of our code relies on that abstract class. I am also about to start work so that the state added to the Fig is determined at runtime by interpreting an XML file rather than being hard coded. This will be very much like the current property panel XML files and so allow us to build Figs with the ease that we can now specify property panels without any worries about complex inheritance hierarchies of code. For activities this will be fairly simple, something like this <rect type="ObjectNode" /> <rrect type="CallBehaviorAction" /> <rrect type="CreateObjectAction" /> <rrect type="DestroyObjectAction" /> <pentagon type="SendSignalAction" /> <concave-pentagon type="AcceptEventAction" /> When at some later date this is implemented for class diagrams then a UML1.4 example might look like this <compartmentbox type="Class"> <compartment type="Attribute" /> <compartment type="Operation" /> </compartmentbox> <compartmentbox type="Interface"> <compartment type="Operation" /> </compartmentbox> <compartmentbox type="Enumeration"> <compartment type="EnumerationLiteral" /> <compartment type="Operation" /> </compartmentbox> Similarly to the property panels I think this will result in a massive reduction of our codebase and ease maintainability of the Figs. With all the drawing being in some state then we should result in greater reuse of code and more consistent behaviour. Regards Bob ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2683897 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]]
