To Do or Not to Do: Semantics and Patterns for Do Activities in UML PSSM State Machines

TL;DR

This paper analyzes the precise semantics of doActivity behaviors in UML state machines as defined by the PSSM specification, uncovering subtle concurrency, event-handling, and finalization nuances that can lead to nondeterministic bugs if misused. It combines normative text, semantic models, test cases, and simulator runs to synthesize actionable insights and identifies 11 patterns that guide when and how to use doActivities across simple, composite, and orthogonal states. The authors emphasize that doActivities fundamentally alter the reactive model by enabling asynchronous execution and external interactions, which necessitates consideration of multiple traces and potential interleavings in both design and verification. The work aims to assist tool vendors and engineers in building conformant simulators and producing safer, more robust state-machine models, with future directions including industrial case studies and guidance for SysMLv2.

Abstract

State machines are used in engineering many types of 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.

Figures (19)

• Figure 1: A state machine model of a measuring component with bad practices to show the risks of semantic misunderstandings. Bold labels show element names. The activity diagram details the behavior of the measureTempAct doActivity.
• Figure 2: Sequence diagram for simulating state machine in \ref{['fig:MeasuringComponent']} using Cameo. Input events: turnOn, measure.
• Figure 3: Simplified execution steps based on trace in \ref{['fig:MeasuringComponentSimulation']}. Notation: gray columns: RTC steps, white columns: stable configurations, boldface in event pool: dispatched event. (Trivial RTC steps where CEs are discarded or events are forwarded to the doActivity are omitted.)
• Figure 4: Overview of the semantic classes defined in fUML and PSSM for state machines and doActivities. Notation: rectangles: UML (meta)classes; other vertices: implicit concepts in PSSM; solid lines: associations; dashed lines: dependencies.
• Figure 5: Ordering constraints of concurrent steps during RTC1 from \ref{['fig:MeasuringComponentSimulation']}. The doActivity is only started, but its execution takes place asynchronously on its own thread. Note that these actions are not atomic, their internal steps can interleave.