If by “suppose we made a rule”, one means “suppose the modelers and architects on a given project together agree to make a rule for that project that said…”, one will have managed to make this one example deterministic. In other words, make an assumption at the modeler level and levy a requirement at the architecture level that will “fix” this one example. (And, BTW, the “fix” is made deterministic by making it trivial: in the fixed example the query will always return FALSE since it always completes before the signal is sent.)

This seems like a heavy-weight mechanism to introduce just to deal with a construct that is, IMHO, of questionable value in the first place.

Leon’s response provides a more general mechanism, already built into Executable UML, that allows determinism wherever desired by the modeler WITHOUT adding any additional work at the architectural level.

The suggested change in semantics is not required to make any arbitrary Executable UML domain model deterministic, nor does it seem desirable, nor would it make the Wikipedia description correct in the general case.

Nevertheless I agree that Marc’s original response was correct: his rule makes the specific example deterministic.

--Erick