In What Is Model-Driven Application, mentioned that almost only one of the quite similar use for the term “model-driven application” (MDApp for shot by me) I’ve seen so far, is from the essays by Håvard Jørgensen (Havard Jorgensen) in 2009 on the blog of Frank Lillehagen and he . The principles and some comments of mine, see Table 1.
Table 1. Jorgensen’s 8 principles for model-driven applications with some discussions.
|Jorgensen’s 8 Principles||Discussions|
|1. Models should be visual and graphical.||This is a very realistic and common principle – it should be done as possible for real applications, though it’s indeed not essential to “graphical”. In my definition of MDApp, the applied model must be both human-understandable / operational and computer-treatable. The human belongs to business-people (the users *), and the model needs to be well accessible to them, for reading (understanding), updating (evolving) and doing some operations on / with. Graphical is a common property that makes a model more friendly to the user, but not at all; it’s even more important that has detailed textual description in the natural language. Note that the well-accessible to model may be not depended on, even somehow without the modeling language – the user interface to model is a basic property of an MDApp platform.|
|2. A modeling language is not a programming language.||I do agree but admit may not fully understand his related explanation at all. If introduce the term DSL, it needs to be clarified that, is it for modeling the things in a domain, or the software for the app on the domain? is the domain an IT domain or business domain?In addition, I’m always deliberately avoided the topic of modeling language, also in this blog so far; a model is indeed not necessarily dependent on a particular language, isn’t it?|
|3. Metamodeling is modeling.||I’ve more consideration on this issue, some related with that why I don’t use metamodel but “modeling knowledge” for model-driven mechanism (MDM) in general. But I quite agree his explanation for this principle:
|4. Reuse is best supported by templates and patterns.||I think this is about the reuse of models, there’s another traditional term reference model; that’s one of the critical issues in practice, and quite different from the reuse of code / programs. The term “template” and “pattern” here need to be distinguished from common programming terms.|
|5. The essence of a model element is its context.||I’ll also relate this issue to relational model. That’s the relational worldview.|
|6. A model is a federation of multiple views.||This maybe requires more consideration yet. It may be related a hard topic: what is A model. I prefer to say that one can make multiple models each as a view for the same thing, and “Every view is a partial representation, and views are mutually reflective, contributing to each others’ meaning.”|
|7. A model is always in flux.||That is, evolutionary, it must based on MDM, model-driven mechanism.|
|8. Models should be interpreted pragmatically and executed interactively.||Must see his explanation: “There should be no separation between design time and runtime, and no compilation.” And it’s with deeper meaning: “Behaviour should be modelled separately from structure, to enable flexible binding.” In MDM, it is shown as the separated parts of the applied mode, the operational device, and yet, especially, the third part: modeling knowledge (metamodels).In addition, as emphasizing the difference between modeling (models) and programming (program), I suggest that it should be avoided to use the term execute to models.|
* They may be the business analysts, definitely a part of users for MDApp.
These principles sound very experienced, realistic, and enlightening; no surprisingly, they are quite in line with my thoughts – understanding based on them, his concept of model-driven applications should be also very consistent with mine. This is because that, any of the application has the features, that is, “running on some evolutionary applied model of the target thing” (from here), will follows some common principles. Although I’ve not seen a special definition of him, from the 8 principles and more on their blog, I see Jorgensen’s model-driven app shows some characteristics as below:
- The target thing is outside computer, is “with the business knowledge of people, rather than the program and data structures of the computer.” (by Frank Lillehagen ) The applied model in their model-driven application is enterprise model, so, their model-driven application is enterprise-model-driven application. This is partially reflected in the 8 principles, such as #1: I think the emphasis to visual and graphical is usually not for modeling exports but the general users to model.
- The applied model is evolutionary at runtime of the app. This can be seen in the principles #7, 8, and also #3 (in his explanation); #4 is indeed depended on such the properties. All of these principles can be derived from MDM.
A comparison between Jorgensen’s 8 principles and my work , in Table 2.
Table 2. A comparison for the principles for MDApp between Jorgensen’s and my work.
|Jorgensen’s 8 Principles ||Corresponding Principles in |
|1. Models should be visual and graphical.||Human-understandable / operational and computer-treatable (Sec. 2.2)|
|2. A modeling language is not a programming language.||No deal with the relevant topic.|
|3. Metamodeling is modeling.||There are more comprehensive conception with this topic, such as MDM and the multiple uses.|
|4. Reuse is best supported by templates and patterns.||Not special discussion about that.However, the principles covered in MDM is the basis to such the functions, for example, the independence, timeliness (runtime), evolvability, etc. of the applied model (Sec. 5.3). MDM discovered more specific rules for these issues, for example, the distinction and relative relationship between applied model and modeling knowledge (metamodel).|
|5. The essence of a model element is its context.||Not special discussion about that.|
|6. A model is a federation of multiple views.||Not special discussion about that.|
|7. A model is always in flux.||The evolvability of applied model (evolutionary; Sec.2.2, 5.3); the MDM is fundamental the answer to that how to realize such feature.|
|8. Models should be interpreted pragmatically and executed interactively.||MDM is essential principle behind them, all the principles covered in MDM are relevant, such as the independence, the timeliness, the evolvability of applied model, the program-model decoupling, the relationships between applied model, metamodel (modeling knowledge) and operational device (Sec 5.3)|
The concept of model-driven application of Jorgensen and Lillehagen is quite consistent with mine. I further definitely define it as a system, a architecture, and a set of ideas or the study. I suggest that to use model-driven application (MDApp) as a proper noun; that’s a very meaningful and promising direction for both industry and academia.
 Jørgensen, Håvard. “Principles for Model-Driven Applications.” Active Knowledge Modeling. March 13, 2009. http://activeknowledgemodeling.com/2009/03/13/principles-for-model-driven-applications/.
 Lillehagen, Frank. “What is Active Knowledge Modeling?” Active Knowledge Modeling. March 12, 2009. http://activeknowledgemodeling.com/2009/03/12/hello-world/.
 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).