We build models to increase productivity, under the justified assumption that it's cheaper to manipulate the model than the real thing. Models then enable cheaper exploration and reasoning about some universe of discourse. One important application of models is to understand a real, abstract, or hypothetical problem domain that a computer system will reflect. This is done by abstraction, classification, and generalization of subject-matter entities into an appropriate set of classes and their behavior.
The subject matter may be far away from the implementation, such as the bank under study, or it may be relatively close to the implementation, such as a database. Similarly, the language we use to express the model may exhibit a high degree of abstraction or it may be a low-level language. The UML may serve as the modeling language in all of these cases, though we generally use some subset of it.
In the bad old days before MDA, these 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.
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. How to do that is the topic of the next chapter.