the documented analysis so precise that it is possible to implement the analysis model directly by translation rather than by elaboration. In Shlaer–Mellor terminology this is called recursive design. In current (2011) terminology, we would say the Shlaer–Mellor method uses a form of model-driven architecture (MDA) normally associated with the Unified Modeling Language (UML). By taking this translative approach, the implementation is always generated (either manually, or more typically, automatically) directly from the analysis. This is not to say that there is no design in Shlaer–Mellor, rather that there is considered to be a virtual machine that can execute any Shlaer–Mellor analysis model for any particular hardware/software platform combination. This is similar in concept to the virtual machines at the heart of the Java programming language and the Ada programming language, but existing at analysis level rather than at programming level. Once designed and implemented, such a virtual machine is re-usable across a range of applications. Shlaer–Mellor virtual machines are available commercially from a number of tool vendors, notably Abstract Solutions, Mentor Graphics and Pathfinder Solutions. Semantic decomposition Shlaer–Mellor proposes a semantic decomposition in multiple (problem) domains. The split between analysis and design models: The analysis domain expresses precisely what the system must do, the design domain is a model of how the Shlaer–Mellor virtual machine operates for a particular hardware and software platform. These models are disjoint, the only connection being the notation used to express the models. Decomposition within the analysis domain where system requirements are modelled, and grouped, around specific, disjoint, subject matters. To return to the earlier passenger train example, individual semantic models may be created based on door actuators, motor controls, and braking systems. Each grouping is considered, and modelled, independently. The only defined relationship between the groupings are dependencies e.g. a passenger train application may depend on both door actuation and motor control. Braking systems may depend upon motor control. Domain models of door actuators, motor controls, and braking systems would typically be considered as generic re-usable service domains whereas the passenger train controller domain is likely to be a very product-specific application domain. A particular system is composed of domains and the defined bridges between the domains. A bridge is described in the terms of the assumptions held by the domain acting as a client bridged to a domain acting as a server. Precise action language One of the requirements for automated code