Skip to content
This repository has been archived by the owner on Jan 5, 2021. It is now read-only.

Why is a composite state required to have a default initial pseudostate? #3206

Open
leonwilly opened this issue Sep 20, 2020 · 1 comment
Open

Comments

@leonwilly
Copy link

leonwilly commented Sep 20, 2020

In section 14.2.3.2 in the UML Specification under Region reads

"Default activation means that execution starts with the Transition originating from the initial Pseudostate of the Region,
if one is defined. However, no specific approach is defined if there is no initial Pseudostate that exists within the
Region. One possible approach is to deem the model ill defined. An alternative is that the Region remains inactive,
although the State that contains it is active. In other words, the containing composite State is treated as a simple (leaf)
State."

I am wondering why you chose the Ill defined form of the recommendation?

In my particular use case a multi-stage furnace when the controller turns on it enters Stage 1 after a period of time and some conditions are met it may need to enter Stage 2. Stage 2 can't be active unless Stage 1 is active. Therefor to appropriately model this behavior Stage 2 should be nested in Stage 1. Stage 3 would be nested in Stage 2 and so on. Because when the controller shuts off it must exit and disable each stage in order. I could circumvent this by adding an On / Off to each composite stage with an initial transition into the Off state. I could also use submachine states for each Stage but the latter two approaches require more work and having an enabled State with a region that is inactive seems less verbose. I understand if you don't agree I am just curious as to your thoughts on allowing that approach?

@leonwilly leonwilly changed the title Why is a composite state required to have a default entry? Why is a composite state required to have a default initial pseudostate? Sep 20, 2020
@terfloth
Copy link
Contributor

terfloth commented Sep 22, 2020

YAKINDU tends to be as strict as possible on validation topics in general. This provides more guidance for the user to construct correct models. Following this approach we consider this case as a modeling error as the substates of such a composite stet or region are always not reachable resulting in dead states and transitions. From the tools implementation point oof view we could also simply follow the alternative approach mentioned in the UML specification. This approach implies that the regions with their substates will be ignored. Of course YAKINDU could mark the regions with a warning stating this fact. Nevertheless YAKINDU uses warnings for potentially problematic constructs and errors for constructs which are surely faulty.

Regarding your example it can make sense to use a state hierarchy to model the different stages. But i can't see how using regions which can't be entered can help you in constructing the furnace as these would be ignored anyway and thus would have no effect. That's what the alternative UML proposal implies.

By the way In YAKINDU regions can be entered using entries / initial pseudo states or direct transitions into the region.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants