you're reading...

Distinguishing Model-Driven from Model-Based

It appears there is still somewhat controversial or divided on the uses of the term “model-driven” or “model-based”, although the former seems more popular, in such as software engineering.

For example, the introduction of ECMDA 2010 stated that “Model-Based Engineering (MBE) is an approach to the design and development of software and systems […]”, then, from ECMDA 2011, it is replaced by “Model Driven Engineering (MDE)”. In ECMFA 2013, however, model-based seems back again on the home page: “Model-Based Engineering (MBE) is an approach to the design, analysis and development of software and systems […]”—model-based or mode-driven? the selection seems still a little in confusion. Another example I’m seen is shown by the Bran Selic’s Foreword of the new book Advances and Applications in Model-Driven Engineering (IGI Global, August 2013), where “model-based” is used throughout but at the end, Selic wrote down: “We will know that this has been achieved when the term “model-based” (or “model-driven,” if you prefer)—chosen initially to draw attention to models and related technologies—becomes redundant because it is self-evident.”

In general, there is no standard answer for such the selection problem. However, I identified two different cases which are just respectively suitable to be referred to as the two different terms, “model-based” and “model-driven”. It is better to discuss the issue on a clearer target, a function (and then extend to such as a system has some functions). In a preparing paper of mine [1], I suggest defining

a function is model-based if it is based on the model(s) of the functional target, i.e. the thing that will be influenced by the function; thus, say a system is model-based if its major functions are model-based.

In the paper, I call that identity between the thing being modeled and the target of the function based on the model. Further, defining

a model-based function/system is model-driven, if the model is changeable in the system at runtime, e.g., allows to change it when the function is executing or before each execution.

And the model-driven is indeed the situation that conforms to the principles of Model-Driven Mechanism (MDM). According to the definitions above, “model-based” is used in the most general sense and “model-driven” is in a relative specific sense. The distinction is, in the latter the models are evolutionary in its working system and in the former, the models can be both fixed or evolutionary. Furthermore,  saying an engineering/development approach model-based/model-driven is under the sense that considering the approach as a system which is working on the models of the deserved targets (the product, output), for example, see Using Model Driven Mechanism to Explain Model Driven Software Development.

One contribution of above definitions is the clarification for some details or subtle distinction which are often overlooked, they are important for design a function/system that working on some models.

Based on the definitions, for some general concepts such as a field or style of software engineering, it seems “model-based” is more appropriate selection, for example, either “chosen initially to draw attention to models and related technologies” (Selic 2013) or “Considering models as first class entities and any software artifact as a model or as a model element” (Bézivin 2006) are suitable to “model-based”, and it seems it is not necessary to limit it in a relative narrow sense. However, for such an engineering/development approach, even if based on the strict definitions, the teams “model-driven engineering” and “model-driven software/system development” are indeed equal to “model-based engineering” and “model-based software/system development” while the major models are as a model of the deserved system, because for such the concepts, based on some  fixed models is meaning less. One benefit of “model-driven” is that emphasizing the variability and the leading role of models in a working system.

[1] It is titled as “Towards a Holistic View of Model-Working System and General Modeling Relationship”. Some related issues see General Modeling Relationship, A Class Diagram for Model Working System, and An illustration for Triple Modeling Relation and Note.

About TY

interested in models & modeling, software, information systems, applications & engineering for enterprises


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s



Subscribe notifications of new posts by email.

Join 60 other followers

%d bloggers like this: