  State machines are used ubiquitously in engineering software-intensive
systems. UML State Machines extend simple finite state machines with powerful
constructs. Among the many extensions, there is one seemingly simple and
innocent language construct that fundamentally changes state machines' reactive
model of computation: doActivity behaviors. DoActivity behaviors describe
behavior that is executed independently from the state machine once entered in
a given state, typically modeling complex computation or communication as
background tasks. However, the UML specification or textbooks are vague about
how the doActivity behavior construct should be appropriately used. This lack
of guidance is a severe issue as, when improperly used, doActivities can cause
concurrent, non-deterministic bugs that are especially challenging to find and
could ruin a seemingly correct software design. The Precise Semantics of UML
State Machines (PSSM) specification introduced detailed operational semantics
for state machines. To the best of our knowledge, there is no rigorous review
yet of doActivity's semantics as specified in PSSM. We analyzed the semantics
by collecting evidence from cross-checking the text of the specification, its
semantic model and executable test cases, and the simulators supporting PSSM.
We synthesized insights about subtle details and emergent behaviors relevant to
tool developers and advanced modelers. We reported inconsistencies and missing
clarifications in more than 20 issues to the standardization committee. Based
on these insights, we studied 11 patterns for doActivities detailing the
consequences of using a doActivity in a given situation and discussing
countermeasures or alternative design choices. We hope that our analysis of the
semantics and the patterns help vendors develop conformant simulators or
verification tools and engineers design better state machine models.
