Skip to content

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.

Scope of Application

The method requires executable model semantics, not merely UML-shaped documentation.

  • 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

Class and association diagrams define objects; state/event models and action language determine behavior. A verifier runs the model, while a model compiler translates it. A diagram missing operational actions is descriptive UML, not yet an executable model.

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

Partition domains, define typed data and lifecycle states, then give transitions unambiguous actions. Run cases in a verifier, translate with declared compiler rules, and check target behavior separately.

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.

Relationships to Other Abstractions

Local relationship map for Executable UMLParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Executable UMLDOMAINPrime abstraction: Representation — presupposesRepresentationPRIME

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

Neighborhood in Abstraction Space

Executable UML sits in a moderately populated region (42nd 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