How could I achieve to have a statechart referenced as a subchart of multiple non-concurrent states?

I'm using the file-based approach of RiC.
So I have a file which has its statechart, which is hierachical.
Some of the deeper states have exactly the same behaviour.
Is it possible to create the sub-statechart of this states once and reference (or instantiate) it for every other state which is using it?

sounds like a bad design ...

Hi Ulf,

you might be right, but it was done straight Top-Down.

Consider a system with say 4 states and the system changes its state cyclically. Each of this states has sub-charts and in this seperate subcharts there are states with the same behaviour.

How would a good design look like in this case?

it's hard so decide wheter you have a bad design or not - in my opinion there is no bad or good design - you can call it sub-optimal (german expression) if you want

If you have same common statecharts in several common subcharts I would say that we have at least some redundancy ... which is indeed sub-optimal

(1) One solution or approach (design pattern or guideline) in this case would be to isolate the common part and put them seperately ... for example in form of a parallel statechart .in the same class (or file in your case)... (2) or you put the common things into a seperate class ...

there are probably many possibilities how to make it closer to optimal ...

I'm well aware that redundancy is a problem, that's why I've posted this question.

What I've done so far is that I have some common functions which are called by states that do the same. But only for states which have a trivial function.

For more complex states I usually create nested statecharts since I'd like to animate and illustrate this function as statechart.

If I could model the function's behaviour as statechart and in every state with this behaviour I call this function.

But I think there is no possibillity to achieve this in the file based approach. If someone has a hint to guide me in the right direction to achieve this I would be happy.

Hi Make

... defining a function with a statecharts sounds very wired to me ... but I do not want to end up in endless discussions again about naming conventions or what to do and how

I just want to provide an answer to your initial question..

... the "Feature" you're requesting is not available ... you're problem (in my opinion) is a design issue not a tool issue

BTW.. working on you webpage project ... you will have it on friday ...

My suggestion - use a mixture of the file based approach and the class approach.

My understanding (reading the above Use Case) is, that you need mutliple instances of the same Sub-Statechart.

So why not create an additional class, which contains just that one sub-statechart as it's main statechart.

Each file with a statechart needing that sub-statechart would then define an instance of that class (which contains the instance of the sub-statemachine).

If the file's statemachine enters a state, which is modeled as a sub-statechart, then one would call the Initializer (Ctor) and the startBehavior of the defined instance (=> running it's default transition).
Any incoming event to the file would be forwarded to the nested instance, while staying in that state (by just calling the nested object's takeEvent()) in the action of a reaction-in-state of the outer state).
This requires one reaction-in-state per event to be forwarded to the nested object.
An event leaving the nested state would simply leave the outer state without being forwarded to the nested object (unless you need to trigger an exit-action of a nested state in there).
Leaving the nested statemachine should work without destroying the nested objects (just ignore it's existance) - it would be re-initialized at it's next entry.

Just as a suggestion - I've never tried that myself, but I believe it should work.

Regards,
Luke.

Hi make,

as I'm facing quite the same problem - have you found a working solution for your purpose in the meantime? If so, would be nice if you could explain that a little bit.

Alternatively - is anybody of you aware of how to model operations in RiC, where Rhapsody can also generate code for?
I tried to use ActivityDiagrams, but RiC does not generate code for those (only in RiC++).
I'm aware that Flowcharts might do the trick - but to my understanding Flowcharts are not part of UML and therefore not my preferred solution.
If anybody has an idea on how to model operations (ideally where I could also model/use events inside, similar as statecharts), I'd appreciate your answer.

Thanks,
Michael

Yes ... Flowchart is not UML but the Rhapsody flowchart is a subset of the UML Activity Diagram (aka as Flowchart ...)

@Mickey: thx for your comment

One additional question: can someone explain to me what you mean by "file based approach" vs. "class approach". Is this a concept that's only used in RiC?

a file is a file is a simple c file and .... static singeleton (Classic Source Based Approach aka codecentric)

a class can be instantiated many many many times (Object Oriented Approach)

ok that's more or less the nature in OOP. I was just confused when Skywalker suggested "use a mixture of the file based approach and the class approach" - and on how to make those distinctions in RiC.

but thanks and regards,
Michael