State machines can be defined at the top level of a model. This feature allows the definition of reusable state machines, to simplify code, or to facilitate separation of concerns.

The example below shows that the statemachine keyword is used to specify a standalone state machine. Such a state machine, by itself, must be syntactically correct, and error messages will be generated, enabling debugging. However, the state machine is not displayed as a diagram and will not result in any code generation unless it is incorporated in one or more classes. The as keyword is used to do incorporate a standalone state machine in a class, as shown in the example.

An alternative, and equivalent, way to define state machines outside of classes is to use traits. A model equivalent to the example below is shown in Example 5 of the page on state machines in traits.

Standalone state machines can be used to make code appear simpler than it does when the state machine is directly incorporated in a class or trait, as there is less indentation, and the statemachine keyword makes it more explicit that what is being described is a state machine.

Standalone state machine used in two classes

// Class Diagram illustrating use of top-level state machine with
// usage in separate classes.
// Note that this could also be accomplished by putting the
// state machine in a trait, and then having each class use the trait

class MotorController {
   motorStatus as deviceStatus;
}

class BrakeController {
   brakeStatus as deviceStatus;
}

// By itself, the following will not generate any code
// but it can be debugged by itself outside of any class
// and can be incorporated in multiple classes, as above
statemachine deviceStatus {
  inactive {
    activate -> booting;
  }
  booting {
    completedStartupChecks -> active;
    startupCriticalErrorDetected -> outOfOrder;
  }
  active {
    runtimeCriticalErrorDetected -> outOfOrder;
    deactivate -> shuttingDown;
  }
  shuttingDown {
    shutdownComplete -> inactive;
  }
  outOfOrder {
    repaired -> inactive;
  }
}

Load the above code into UmpleOnline

Standalone state machine modified when reused

// Class Diagram illustrating standalone state machine being
// modified when it is reused, to add additional events
// states and entry/exit actions

class MotorController {
  Boolean warmup = false;
  motorStatus as deviceStatus {
    // Add a transition to the reused state machine
    cancel booting-> inactive;
    completedStartupWhilewarning  booting -> warm ;
    
    // Add transition with action
    warmSoReady inactive -> / {warmup=true;} booting ;
    
    // Add an entirely new state
    warm {
      go -> active;
    }
    
    // add an entry action to an existing state
    inactive {
      entry / {warmup=false;};
    }
  };
}

// Reusable standalone state machine
statemachine deviceStatus {
  inactive {
    activate -> booting;
  }
  booting {
    completedStartupChecks -> active;
    startupCriticalErrorDetected -> outOfOrder;
  }
  active {
    runtimeCriticalErrorDetected -> outOfOrder;
    deactivate -> shuttingDown;
  }
  shuttingDown {
    shutdownComplete -> inactive;
  }
  outOfOrder {
    repaired -> inactive;
  }
}
// @@@skipphpcompile - contains java code
// @@@skippythoncompile - Contains Java Code

Load the above code into UmpleOnline

Syntax

// State machine elements in Umple. See user manual page: BasicStateMachines
stateMachineDefinition : statemachine [=queued]? [=pooled]? [name] { [[state]]* }

referencedStateMachine : [name] as [definitionName] ( { [[extendedStateMachine]] } | ; )

//Issue 547 and 148
extendedStateMachine# : ( [[comment]]
| [=changeType:+| - |- |*]? [[state]]
| [[standAloneTransition]] )*