What Can Be Done Is What Can Be Modeled
Author: Mountriver TY Yu, Source: EE-Forum.org, Published: 2013-02-19
Excerpt: One of the important feature of model-driven application (MDApp) is the adaptivity based on models. It was summarized as "what can be done is what can be modeled", or reference to the well-known acronym WYSIWYG, say "what you model is what you handle" (WYMIWYH). Although it seems that they are quite close literally, MDApp and related ideas should be distinguished from the most of existing work of MDE/MDSD.
In the work in press, we pointed out an important feature of model-driven application (MDApp), that is, the adaptivity based on models. It is also the meaning of “model-driven” which referred to, it was stated below under the subject of enterprise applications:
What business can be handled on the MDApp are what can be modeled by the business analyst—according to the metamodels; a well-designed platform may be capable to add new model drivers to support certain new business (models).
In other words, for MDApps, what can be done by end users is decided with what been modeled by the models—i.e., the models decide the business which handled by users on an MDApp in run time. In, it was summarized as “what can be done is what can be modeled“, or reference to the well-known acronym WYSIWYG, say “what you model is what you handle” (WYMIWYH). Of course, for an MDApp, that “you” refers to user; the users do modeling maybe differ from the users handle the business been modeled—they are not belonged to the comp of developers for the app platform (software) or the enterprise application providers. In words of the paper, modeling the target things, the business for an MDApp, is a right side job, it is a certain part of so-called application.
In a lot of literature we collected, there are rarely clear exposition of such the ideas; it might be traced back to Brian C. Smith’s thoughts about the mediating models (cf. here and here), and regarded it as a logical starting point to the ideas. Smith summarized the related principles in a slogan: “no computation without representation.” And stated that the representation is “essentially linguistic formulae encoding, in the terms of the model, the facts and data thought to be relevant to the system’s behaviour.” Our ideas, however, are not the duplication of Smith’s thoughts, it goes beyond his early speculation about the representations and inventible mediating models in computation; one of the core principles is model-driven mechanism (MDM) (cf. here). We also clarified and emphasized that the mediating models between computer and so-called real world are the models of the real world things, that is, the models of the target objects which will handled by (in) the applications of computer, and computer software itself is not the model (abstraction) of the real word but has and handle it (see here). What we said “can be done” or “can be handle” are the things / affairs which can be handled on the MDApp platform, it is the business, even can not be simply regarded as the functionality of software. Here, the things been modeled by the applied models are the things which the end users want to process based on computer, but not the software (Objects / Classes) themselves like as in MDE / MDSD.
From the perspective of problem-orientation or function-orientation, the functional problems to the development of the software of an MDApp are usually not the problems faced and handled by the end users, for example, creation, modification or deleting of a sales order. It is on a more abstract (or more generalized) level, for example, “to achieve certain jobs in the life cycle of some kind of entities according the way set by the user”—such the jobs maybe named by users as place an order, review, approval, and implementation, etc., they are not the functions directly coded by programmers one by one, in the development of an MDApp, its implementation by the means including: specify metamodels of the models of certain kind of things, develop the driver (or engine) supports the operations on / for the models according to the metamodels, and formulate the models of instances of the target things (will be used as applied models).
Although it seems that they are quite close literally, MDApp and related ideas should be distinguished from the most of existing work we see in MDE / MDSD field. For MDE / MDSD, one of the basic feature or the core value may be summarized in that what models can be built is what software can be gotten, i.e., what model represented is decides what the software is. That is, on the one hand, what a car you can manufacture is depended on what blueprint you can draw, the code-generation in MDE just like the automatic manufacturing of a car according to the blueprint; on the other hand, the benefit is from the rising of the abstract level to the design work (blueprint)—this upgrade makes designer can ignore more details as much as possible, e.g., just give the functional description and the characteristics without the design of the structure and the material, etc. for the engine. For MDApp, however, this analogy of car is to be that adds an autopilot equipment to a general car: WYMIWYH means that what map you can draw (and input) is what roads it able to identify (to travel). Perhaps a little ironically, over the past decade, we have always emphasized the above differences, the work is still appeared in an MDE monograph. This maybe a reflection of the real situation: much of the work relevant to models and modeling in software community is always surrounded by the main ideas outlined in MDE / MDSD, though there is a slogan “everything is a model”, there is a kind of models to be excluded (at least seriously neglected): they are in fact just the inevitable mediating models of the target things of an application. About this, we also done some discussions with such the concept of CIMs in the paper. In addition, we also found that there is some research about runtime models or models at runtime and adaptive software/system, it seems that is “attached” at MDE / MDSD community too. In fact, I think that this “embarrassment” to positioning is also the characteristic of an innovation.
-  Yu, T.-Y. “Model-Driven Applications: Using Model-Driven Mechanism to Bridge the Gap between Business and IT.” In Progressions and Innovations in Model-Driven Software Engineering. Díaz, V.G. et al. eds. IGI Global, July 2013 (in press). Email me to firstname.lastname@example.org if you want to review it personally quickly.
-  My personal collection of literature in recent years, the quantity, only in the directory of “models and modeling” and to be roughly viewed on the abstract and conclusion, as a conservative estimate, is more than two thousands, which are mainly involved in software, computer science, also philosophy of science, etc.
-  Smith, B. C. “The limits of correctness.” ACM SIGCAS Computers and Society 14, no. 1 (1985): 18-26.
-  Bézivin, J. “On the unification power of models.” Software and Systems Modeling 4, no. 2 (2005): 171-188.
What Can Be Done Is What Can Be Modeled by Mountriver TY Yu is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
GB7714 style: Mountriver TY Yu. What Can Be Done Is What Can Be Modeled[EB/OL]. EE-Forum.org, http://www.ee-forum.org/wp/pub/ty/2013-02-p3479.html, 2013-02-19[2017-03-29 09:28]
Chicago style: Mountriver TY Yu, "What Can Be Done Is What Can Be Modeled", EE-Forum.org, http://www.ee-forum.org/wp/pub/ty/2013-02-p3479.html(accessed 2017-03-29 09:28)
- Prev Post: 模型即所能
Leave a Response
You must be logged in to post a comment.