Executable UML¶

A model-driven software method that adds executable actions to UML-style domain and state models.

Version: v1 · 2026-09-28 · History
Domain-specific #: 9347
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Model Driven Engineering, Software Engineering → Computer Science & Software Engineering

Core Idea¶

Executable UML, particularly the xtUML method, turns a restricted UML-style model into an operational specification. It organizes subject domains, classes and associations, state machines, events, and action-language procedures so that model instances can change in a defined way. The decisive step beyond a diagram is not graphical appearance but sufficient execution semantics.

A verifier can run the model independently of a selected implementation platform, and a model compiler can translate the same conceptual structure toward target code. This separation permits testing domain behavior before platform choices, while leaving architecture and integration concerns for later stages. OMG fUML and ALF address neighboring executable-semantics questions but should not be silently equated with every xtUML method or toolchain.

Structural Signature¶

Sig role-phrases:

Domain partition — Separates modeled subject matters and their bridges before platform-specific implementation. It is central. Counterfactual: Without a domain boundary, implementation concerns can be mixed into the subject model.
Class and association model — Defines typed entities, attributes, and relations whose instances carry state. It is constitutive. Counterfactual: A set of pretty diagrams without operative domain data is not an executable domain model.
State and event model — Specifies behavior through states, event-triggered transitions, and procedures. It is constitutive. Counterfactual: A static class diagram alone cannot run the modeled lifecycle.
Action semantics — Defines executable changes to attributes, instances, relations, and event generation. It is constitutive. Counterfactual: If transition actions are unspecified, the model remains an outline rather than executable behavior.
Model execution — Runs or verifies the platform-independent behavior before target translation. It is central. Counterfactual: No executable interpretation makes 'executable' only aspirational.
Target translation — Applies compiler rules to produce implementation artifacts for a chosen platform. It is central. Counterfactual: A model may still be executable without a selected target, but loses this method's model-to-code trajectory.

What It Is Not¶

Not any UML picture. A static diagram alone does not specify executable behavior.
Not handwritten implementation code. The model is a higher-level specification with target translation.
Not target-code testing alone. Model verification checks a distinct representation.
Not identical to all fUML/ALF work. Those are neighboring specifications with their own scope.
Closest near-miss. Executing generated code is not the same as simulating the platform-independent model, and fUML/ALF is a related OMG standard family rather than a guarantee of xtUML identity.

Scope of Application¶

Domain modeling. Express entities and associations independent of one programming language.
Behavior specification. Define states, events, and actions that determine instance evolution.
Model verification. Exercise a platform-independent model and inspect outcomes.
Model compilation. Translate subject semantics into a target technology under explicit compiler rules.

Clarity¶

A class diagram says what objects can exist; state and event models say when behavior occurs; action language says what changes. Executable UML requires their coherent semantics. A verifier running the model is distinct from a generated program running on a target, even if the latter is compiled from the former.

Manages Complexity¶

Large systems contain domain logic, user interfaces, storage, security, and platform details. Partitioning domains and compiling from an abstract model helps manage these layers, but only if cross-domain bridges and generated-code assumptions are made explicit. An underspecified model merely relocates ambiguity rather than removing it.

Abstract Reasoning¶

Identify the subject domain and its external bridges.
Define classes, attributes, associations, and instances.
Specify states, events, transitions, and actions.
Execute representative scenarios in a model verifier.
Translate to a chosen target with declared compiler rules.
Test that generated behavior preserves the modeled intent across interfaces.

Knowledge Transfer¶

The method applies literally to software domains modeled with executable UML-compatible semantics, independent of a particular target language. State machines in hardware or business process diagrams may share a structural pattern but are not thereby xtUML models. The transferable idea is running a typed behavioral model before code generation; the named method retains its UML profile and action semantics.

Examples¶

Canonical¶

The BridgePoint MC-3020 guide supplies an autosampler class diagram and an initialization function. Action-language statements create a CAR and ROW, relate them across association R1, and initialize probe attributes; the same instances can be used in Verifier simulation and target execution. This published tool example maps structure, actions, model execution, and translation without claiming the guide establishes all possible UML execution standards.

Mapped back: Domain partition → autosampler domain in the guide; Class and association model → CAR, ROW, probe classes and R1 relation; State and event model → model behavior beyond initialization is represented by the xtUML state framework; not demonstrated by this excerpt alone; Action semantics → create, relate, and attribute assignment statements; Model execution → the Verifier uses initialized instances in simulation; Target translation → MC-3020 uses the same initialization for target build.

Applied / In Practice¶

BridgePoint's published MicrowaveOven sample model has Oven, Door, Turntable, Beeper, Light, and Magnetron classes, named associations, Door states Open and Closed, and Object Action Language behavior. In the vendor's documented test sequence, opening the door sets its is_secure attribute false and sends a cancel_cooking event to the Oven; another modeled scenario opens and closes the door while scheduling a cooking interval. The test subsystem executes the model's own event behavior. This is an actual tool-supplied model, not evidence that a physical appliance was deployed from the generated code.

Mapped back: Domain partition → Microwave Oven and Test Subsystem packages; Class and association model → Oven/Door and other classes with their named relationships; State and event model → Door Open/Closed and cancel_cooking event; Action semantics → OAL attribute assignment and event generation; Model execution → documented test sequence exercises the application model; Target translation → BridgePoint's model-to-code capability is documented, but the tour does not show a deployed appliance.

Boundary Case¶

Imagine an ATM drawing showing Account and Withdrawal classes with a statechart labeled 'Idle' and 'Dispense' but no defined action for debit, balance check, or event handling. It communicates a design, yet cannot determine a transaction result. Add unambiguous action semantics and event behavior and it becomes eligible for executable interpretation. This is a conceptual comparison, not a claim about a shipped ATM model.

Mapped back: Domain partition → hypothetical ATM subject matter; Class and association model → Account and Withdrawal diagram; State and event model → named states but incomplete transition behavior; Action semantics → absent in near miss; defined debit/check actions needed; Model execution → cannot reliably run before semantics are added; Target translation → translation cannot fill missing business behavior.

Structural Tensions¶

T1 — Abstract Domain Model versus Platform Commitment. Separating subject semantics from technology aids retargeting, but a compiler and runtime must eventually choose data layouts, scheduling, and interfaces.

Diagnostic: Which behavior belongs to the domain and which to the target architecture?

T2 — Readable Diagram versus Complete Execution Rule. Simple diagrams communicate well yet omit enough detail to run; adding actions makes behavior testable but increases modeling burden.

Diagnostic: Could a verifier decide the next state from this model alone?

T3 — Model Verification versus Generated Implementation. A model may simulate correctly while integration or code generation introduces target-specific failures. Neither stage substitutes for checking the other.

Diagnostic: Was the claim established in the verifier, target code, or both?

Structural–Framed Character¶

Executable UML is mixed-framed: typed state changes can be executed and checked, while the language and method are human-defined software artifacts. Evaluative weight: an executable model is testable, not automatically a faithful or maintainable implementation; its behavior depends on its specified semantics and domain model. Human-practice-bound: without modelers, action definitions, and execution tooling, the named method does not operate, even though its formal transitions can be analyzed once specified. Institutional origin: restricted UML/xtUML conventions and model compiler contracts fix its identity; a free-form flowchart is not made executable by labeling it so. Vocabulary travels: model, state machine, and code generation recur across engineering, but the UML profile and action language are particular. Import versus recognize: translating one valid xtUML model to another target language retains the method, whereas running an unrelated statechart is analogy.

The portable skeleton is a typed behavioral model made runnable before a final implementation is chosen, an explicit future-prime candidate here. The live Formalization prime names the conversion of informal practice into rule-governed form; the resulting Executable UML method is not itself that process. Its character: a software-modeling language and workflow whose executable semantics are more specific than the general idea of formal models.

Structural Core vs. Domain Accent¶

Skeletal core. Typed entities and state-changing actions make a model executable before a target implementation is chosen. Domain-bound accent. xtUML restricts UML notation and uses action language, state machines, and model compiler rules. Replace those with a free-form flowchart and one may retain behavior modeling, but not Executable UML. Why not a prime. The exact software-language commitments are essential.

This entry presupposes Representation.

Current DAG placement. Live prime Formalization is the process of making an informal practice explicit and rule-governed; Executable UML is a particular software language/method and its models, not an instance of that process itself. No verified strict language-genus parent is available.
Neighboring standards. OMG fUML and ALF specify executable subsets or action notation but do not collapse tool-specific xtUML method identities.

Relationships to Other Abstractions¶

Current abstraction Executable UML Domain-specific

Parents (1) — more general patterns this builds on

Executable UML presupposes Representation Prime

Executable UML presupposes Representation: the parent's defining role is necessary to the child's frozen mechanism or criterion.

Hierarchy path (1) — routes to 1 parentless root

Executable UML → Representation → Abstraction

Neighborhood in Abstraction Space¶

Executable UML sits in a moderately populated region (42^nd percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Formal Systems & Discrete Structures (18 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Ordinary UML documentation. Tell: May depict classes and states without enough semantics to run.
Model compiler. Tell: A translator that consumes an executable model, not the model/method itself.
Verifier. Tell: A tool that runs model behavior before target deployment.
fUML/ALF. Tell: Adjacent standardized execution/action semantics with separate conformance boundaries.

References¶

BridgePoint/xtUML project, “Frequently Asked Questions,” https://github.com/xtuml/bridgepoint/blob/master/doc-bridgepoint/process/FAQ.md (xtUML profile, action language, Verifier, and model compiler).
BridgePoint Model Compiler User Guide, “Dynamic Initialization,” https://xtuml.github.io/docs/mcug/ch08s02.html (autosampler class diagram, initialization statements, simulation/target relation).
xtUML.org, xtUML Quick Start Guide, https://xtuml.org/wp-content/uploads/2012/12/xtUML-Quick-Start-Guide.pdf (vendor's MicrowaveOven model, Door state/action behavior, and executable test scenarios).
Object Management Group, “Specifications Catalog,” https://www.omg.org/technology/documents/bms_spec_catalog.htm (fUML and ALF as adjacent standard families, not xtUML synonyms).
Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Executable_UML (revision 1297277608).
Preserved source candidate: https://github.com/xtuml/masl
Preserved source candidate: https://www.omg.org/spec/ALF/
Preserved source candidate: http://executableumlbook.com

The xtUML project and its guides support the autosampler construction and a distinct MicrowaveOven executable-model case. The ATM contrast is expressly analytic. The OMG catalog is used only to locate adjacent standards, not to assert that their semantics or conformance are identical to BridgePoint's method.