I have had this question on my mind for a while and now I actually had to put it to the test in a real project.
I have a system where there are explicit requirements for power consumption. There are three so called power states that the system must have:
- Operational state
- Max 45 mA
- Standby state
- Max 5 mA
- Sleep state
- Max 0,6 mA
The transitions between these states will be controllable by external signals. I therefore created a separate use case for this called StartUp_Shutdown (SU_SD), see below:
I also added the Unpowered and Powered states.
The system also contains a control function. The modes of this function according to the requirement will be:
I created a separate use case for this and called it Shift Gear (SG):
When the control function is Off, it is supposed to enter a lower power consumption state and here is where my brain starts to hurt. Apparently the SG uc needs to communicate with the SU_SD uc, since when the SG uc is Off, it is supposed to enter sleep or standby in the other uc in order to satisfy the requirement. But then I hear the echo of your words on p 152 in Agile Systems Engineering that good use cases are independent and that only in an extremely rare case do you (< 1%) do you need to have an association between use cases in order to co-simulate them.
I don't understand this. For me there is typically always an association with the power states of a system and the different modes of the different main functions of the system. Even in your own Harmony aMBSE Deskbook you have the stm for the Uc_ControlAirSurfaces that contains the same states as in the Start Up use case proving that the use cases are dependent!
So I am now thinking on how to solve this, should I have create an execution context for both use cases simultaneously? Or should I merge the two use cases to one? I am thinking about about having a Composited block owning a stm as you suggests in State Machine Corner Episode 6: Return of the AND-States which would then contain the two use case blocks.