Models and modeling are inevitable and pervasive, this seems it has become a common sense of the community of model driven engineering (MDE) for a long time. For example, in a recent post, Marco Brambilla has highlighted that “you cannot avoid modeling.” Earlier, Jean Bezivin has written at here, said the main idea of MDE “is to consider a level of uniform representation where all artifacts are models,” that is, as his slogan, “Models Everywhere.” Of cause, whether to MDE / MDSD or more general or special subjects, this is only a preliminary understanding.
First, what models are there? David Frankel in his book  presented a basic taxonomy as follow (according to his Figure. 8.1 “Model taxonomy.”)
- Business Model (a.k.a. Domain Model)
- System Model
- Logical Model
- Requirements Model (Computation-Independent)
- Computational Model
- Platform-Independent Model (PIM)
- Platform-Specific Model (PSM)
- Physical Model (Deployment)
In above list, the names with underline are abstract class and others (five) are concrete class. Those five concrete classes are the main kinds of models to an application. In the book he further defined some personas who created or used such the models, which are partially show in the Table 1 below.
Table 1. Some of MDA personas (roles) related to the five kinds of models.
|Kinds of Models||Created By||Used By|
|Business Model||Business analyst||Requirements analyst|
|Requirements Model (C.I.)||Requirements analyst||Application engineer|
|Platform-Independent Model (PIM)||Application engineer||Model transformation tool|
|Platform-Specific Model (PSM)||Model transformation tool||Deployment engineer|
|Physical Model (Deployment)||Deployment engineer||Network administrator|
Such the models are sequentially appeared in the life-cycle, see Figure 1.
Note that there are not the acronym of CIM appeared in the book. In MDA Guide 1.0.1 of OMG, there was somewhat ambiguous definition to CIM. The problem also equally applicable to the requirements model, and it can be more clearly exposed on the Situation for Discussions about MDApps, that is, which one is the object being modeled by a CIM? Is it on the left or right of the gap ? Such problem may be a reason to cause the concept of CIM to be quite disregarded, as well as the requirements model, and maybe including problem model. I think, so-called CIM, requirements model, or problem model is indeed not a model. They are at most to be used as a group of different kinds of models, or, would rather select such as requirements specification, problem description. This is not a counter-example to the understanding mentioned at the beginning, it is a request for more specifically, clearly identify and define the model involved in. For obtaining greater benefits, it is needed to more clear, exact concept of model rather than the more generic or broader.
 Frankel, D. S. “Model Driven Architecture: Applying MDA to Enterprise Computing.” Wiley Publishing, Inc. 2003.
 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).