1

Given a System that contains two components, A and B, and

The System starts up A and B concurrently. Now A can go through states {A.Starting, A.Ready}, and B can be in states {B.Starting, B.DoingX, B.DoingY}. (Events to transition between A's and B's states are named accordingly: B.doingx => B goes to B.DoingX etc...)

A and B state machine from yuml.me

I want to model that

  • While A is in A.Starting, or B is in B.Starting, the System is "Starting"
  • The System is in state "DoingX" when A is in A.Ready and B is in B.DoingX
  • The System is in state "DoingY" when A is in A.Ready and B is in B.DoingY

System state machine from yuml.me

If I'm not mistaken, the fork/join pseudo-states could be used here.

But do these model elements have the declarative semantics of the composed state mentioned above? Is there another way to model this?

(Note: the diagrams are from http://yuml.me)

xtofl
  • 40,723
  • 12
  • 105
  • 192
  • I intend to add a picture to show what I mean. – xtofl Oct 19 '11 at 09:16
  • As a suggestion, I usually keep separate "fork" symbols (1 arrow in, many arrow out) from "join" symbols (many arrow in, 1 arrow out). And shadow the "join" symbol. It helps modelling. – umlcat Oct 19 '11 at 22:57

1 Answers1

3

Why don't you just pull these apart? Here's another idea on how you could model it (assuming I understood it correctly) :

  • a state "Starting", that contains the states you refer to as A.Starting and B.Starting in parallel regions (you can use fork/joins here, or just rely on the default behavior of all regions being activated when "Starting" state is entered)

  • another state "Doing" that contains a region with your "A.Ready" state and another parallel region, that contains the two states "B.DoingX" and "B.DoingY".

If you really need to have an overall "DoingX" state, then you may have to create two states that correspond to A.Ready.

Anyways, on a broader perspective: I believe your point of view is a little bit off here, when you say that the "System is in state ...". Rather, the system modeled by such a state machine is in a set of states. So normally, I would be perfectly happy to say that "the system is currently in A.Ready and B.DoingX".

Maybe all you need is a change of terminology. What about this:

The system is in configuration "DoingX" when A.Ready and B.DoingX states are active ?

In response to the comment: Yes, this is standard, here's the corresponding part from the superstructure specification (version 2.4 beta):

In a hierarchical state machine more than one state can be active at the same time. [...] the current active “state” is actually represented by a set of trees of states starting with the top-most states of the root regions down to the innermost active substate. We refer to such a state tree as a state configuration.

Frank
  • 10,461
  • 2
  • 31
  • 46
  • Thanks for the point of view - I was hoping for that. Is the term 'configuration' made up, or is it standard? – xtofl Oct 20 '11 at 06:59