An object in OOA represents a single typical but unspecified instance of something in the real world - any airplane, I don't care which one, as long as it is typical. The object-oriented analyst distinguishes this concept from that of a specified instance: Airplane number N2713A, Air Force One, or The Spirit of St. Louis, for example.
Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change.
Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem.
MDA per se is relaxed about exactly what models it transforms, so long as the modeling language in which the models are expressed can be defined.
In the bad old days before MDA, (conceptual) models served only to facilitate communication between customers and developers and act as blueprints for construction. Nowadays, MDA establishes the infrastructure for defining and executing transformations between models of various kinds.
What's the point of having metamodels, and why should you care? Because models must be stated in a way that yields a common understanding among all involved parties, we need a way to specify exactly what a model means. Metamodels allow you to do just that: They specify the concepts of the language you're using to specify a model.
What's really going on is that Executable UML is a concurrent specification language.