Hello Bob!
This sounds great!
How does this fit with the persistance (saving and loading)? Is there a
Visitor walking through the States to save all information?
/Linus
2010/11/20 Bob Tarling <[email protected]>
> 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]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2683915
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]]
