Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[papyrus-rt-dev] Inheritance in State Machine Diagrams

Hi, Team,

I’ve uploaded a short demonstration of the current (as of today) inheritance support in the state machine diagram, on the inheritance feature branch (builds):


Overall, I’m quite happy with the progress so far, despite some instability here and there and a few regrettable regressions that have been found and fixed — the accounting for inheritance is quite a cross-cutting concern with wide impact.  But my work on the diagrams this week has run into a question (I think not quite a snag) that I’d like to raise here.

As in the Capsule Structure Diagrams, a view of an inherited element references that inherited element as it is defined in the context from which it is inherited, even in a diagram for the inheriting context.  However, this poses a problem for the nested state-machine diagrams for composite states.  A composite state that is inherited may already have a nested diagram in the state machine from which it is inherited.  Because of restrictions in the viewpoint definition, a composite state is only permitted to have one diagram, so the same composite state cannot also have a diagram in the context of a state machine that inherits this state.

On the face of it, that seems already perfectly okay because, if the composite state is inherited, no new diagram is needed:  the diagram exactly as defined in the parent context is complete.  If the redefining state machine doesn’t redefine the composite state to change it in some way, then nobody needs a new diagram of that state.  Besides, there is no clear way that I can see by which to expand the viewpoint definition to account for the inheriting state machine context:  the viewpoint understands only that a composite state has a diagram; it cannot distinguish that a diagram is for a composite state but in the context of an inheriting state machine.

So, I’m thinking that the best thing to do is, if the user really wants to create a diagram for an inherited composite state, to force a redefinition of that composite state in the inheriting state machine.  Any changes that user would make in such a diagram would inevitably result in the composite state being redefined anyways in order to accommodate semantic changes in the state machine that inherits it.  This then provides a distinct composite state element in the inheriting state machine that redefines the inherited composite state, so that each may have its own diagram, according to the viewpoint definitions that we already have.

Thoughts?  Concerns?

Thanks,

Christian

Back to the top