A Concept of Model
we call an entity model while it plays the role in the situation where the entity has and provides a set of properties directly or indirectly as the substitute for a thing else. (Version on 12 August, 2012)
Here, further suggest that use target to denotes the “thing else”, i.e., the thing being modeled by a model. The target thing of a model can be anything, such as a system, a product, a business process, and a domain, etc. There are quite a few of words for that, such as object, original, prototype, subject (matter), system (under study), and so forth, and hard to say which one is the better. The “target” is very consistent with the point highlighted by MDM: an MDM structure and its applied model have the same target.
The Model-of Relationship
The relationship between a model and its target is directed (asymmetrical), and it has also many of different denotations, for example, conforms-to, represented-by, instance-of, and so on. This is not just a matter of habit, it actually reflects the different understandings and definitions to model. I am eventually more inclined to adopt the most neutral word: model-of (or modeled-by). Its advantage is just lain on the weakness, i.e., does not give any meaning than a definition of model itself so it is suitable for any of definitions. Sometimes people use the term model under a very ambiguous sense in which you are quite hard to clear this relationship, for example, the target thing is often unclear, confused a model and an object which containing model, or confused a model and a class of models, and so on. To those situations, I would rather recommended that instead of the term model, firstly use more specific term which suitable the case, for instance, to requirements model (vs. requirements specification / document), problem model (vs. problem description or definition), even computer-independent model (CIM; a suitable understanding may be referred to a few of kinds of models, see last post).
A Classification for MDApps
Go on the topic, the first class of models for MDApps is the inevitable mediating model of the target things i.e. the applying objects. An MDApp thereby “know” the properties (the attributes, states, etc.) so can make the meaningful operations for the target things outside the system (or says, in real world). There is a significant distinction for the target things: the thing out side the app system and the thing of the system itself. The former makes the system is capable to adopt to the applying objects outside; the later makes it is evolutionary by changing the model at runtime , and this will be a way to use some new technology from MDE, such as the executable models. Another important classification for above models, i.e., applied models, is the models for present state (As Is) and for future state (To Be).
The second class of models for MDApps is belonged to the modeling knowledge, the metamodels in which. A metamodel here provide the properties of some models applied in the MDApp, thus makes the system know how to access and work on / for the applied models. Yet, a significant note about metamodel is that it is also used as an applied model in a multiple model-driven mechanism structure (multi-MDM).
For MDApps, whether needs other kinds of models is depended on the software–the platform to support it. One can also development an MDApp platform in a typical MDE way, but where the requirements and problems will not be the business of the end users of the MDApp but the needs that the functions to support it, the drivers / engines, etc.
A Concise Concept of Domain Model
In addition, have a talk about the term domain. This is a useful and auxiliary concept, it is suggested  that, use the word “domain” against “problem” or “subject”, i.e. “it is referred to the scope, in which the problem or subject (e.g., an application, operation, an affair or business, and so on) are occurred or involved, and more specifically, it is referred to the set of objects or entities with properties and basic relationships.” Under this sense, a model of a domain, or still call it domain model: a model that the target is a domain but not a thing in the domain, is quite close to an ontology.
Table 1. Main models for MDApps and the related roles.
|Classes of Models||Created By||Used By *|
|Models of outside things
(As Is / To Be)
|Business / enterprise analyst / engineer||End user / business staff, MDApp platform / functional tool|
|Models of (parts of) app system
(As Is / To Be)
|Application engineer||MDApp platform / driver / tool (the programs)|
|Metamodels of above models||Architect of MDApps with business / enterprise architect and software architect **||Designer of model driver / tool, model driver / tool (the programs)|
|MDE models||Developer of the MDApp platform||Developer, maintainer|
* The models is used also by the creators themselves.
** For MDApps, the design of metamodels is one of the most important and significant work, which is very specific and professional. It probably needs a special new role here.
 This definition is a result of the uses and thinking about the concept of model for a long time, and have compared dozens of definitions in literature from such as software, Philosophy of Science, etc.
 In fact, there are still many cases under so-called “runtime”, see the comments and the replies on this post.
 Yu, Tong-Ying. “Model-Driven Applications: Using Model-Driven Mechanism to Bridge the Gap between Business and IT.” In Advances and Applications in Model-Driven Software Engineering. Díaz, V.G. et al. eds. IGI Global, August 2013 (in press, see Recent Work on Model-Driven Applications (MDApp).
Update: Add the subtitles to paragraphs, 23 Mar 2013