XML Diagram Elements
We currently have far too much wiring in FigNodeModelElement and FigEdgeModelElement. They have grown 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.
This proposal is to resolve this in the same way as the XML property panels removed our complex inflexible Prop classes.
The advantages that will come are expected to be the same.
- Less complex hierarchies of code
- Clear structure of layout
- Reuse of code
- Simplified editing
- Separate layout from implementation (we could write eclipse GEF code to render elements based on the same XML design)
The easiest way to see the advantage is an example definition for Class, Interface, Enumeration.
Examples
<compartmentbox type="Class"> <compartment type="Attribute" /> <compartment type="Operation,Reception" /> </compartmentbox> <compartmentbox type="Interface"> <compartment type="Operation,Reception" /> </compartmentbox> <compartmentbox type="Enumeration"> <compartment type="EnumerationLiteral" /> <compartment type="Operation,Reception" /> </compartmentbox>
Handling differences in UML2
An alternative set of definitions can exist for UML2 that can manage and separate the differences in behaviour required
e.g. The UML2 XML definition can define Interface as
<compartmentbox type="Interface"> <compartment type="Attribute" /> <compartment type="Operation,Reception" /> </compartmentbox>
Current Implementations
The principles described above have been used for the implementation of UML2 Activity Diagrams.
These are of far simpler construction than classifiers so there is just one element that describes each node. These are as follows
<rrect type="CallBehaviorAction" /> <rrect type="CreateObjectAction" /> <rrect type="DestroyObjectAction" /> <pentagon type="SendSignalAction" /> <concave-pentagon type="AcceptEventAction" /> <rect type="ActivityParameterNode" /> <rect type="CentralBufferNode" /> <rect type="DataStoreNode" />
This definition is in the file diagram.xml in the Activity2 project (note the definitions are in the toolbar section of that XML file and these may later move)
FigBaseNode is the concrete FigNode class that is built for all of these nodes. The construction of each instance of FigBaseNode is assisted by DiagramElementBuilder.buildDiagramElement.
Next Steps
State Diagrams
Much of what is being design for Activity Diagrams can be reused for State Diagrams. We want this to be modular.
Code that is useful for multiple diagrams should be moved into a separate module that is used by both Ativity and State. Is this the first time we have module dependencies?
Notation
There is no Notation yet implemented in Activity Diagrams.
How is this best done?
Do we automatically map based on the type attribute. So that
<rrect type="CreateObjectAction" />
creates a rectangle containing a text field with the correct notation linked internally in the code from the identifier "CreateObjectAction"
or do we do like this
<rrect type="CreateObjectAction" notation="org.argouml.notations.MyNotationClass" >
Separate Toolbar Definition from Element Definition
Currently diagram.xml is interpreted to get both the toolbar layout and also define the XML structure of each element.
When more complex Figs with compartments are used it will be required to separate the toolbar definition from the diagram element internal definition.
The toolbar definition will stay in the diagram module and the element definitions will move to the common module that all diagram modules access.
This file is elements.xml and is currently unused in the Activity module. It is required to move this file to the common diagram module. DiagramElementBuilder will also be in that common module and so be interpreting a local file.