you're reading...
App & Architecture, Fundamentals

How the Modeling Knowledge Works in Model-Driven Mechanism

In the three parts of a model-driven mechanism (MDM) structure, “modeling knowledge” might be somewhat vague words since I have not fund more appropriate term yet. Some of terms such as “metamodels”, “specifications”, “rules” and so on may be more clear concept but I somewhat tend to regard them as one kind of the knowledge, for the general concept of MDM. The term metamodel, in the context of software development, especially MDE, seems enough to be used for discussing about MDM [1], and in principle, the metamodel under any special definition is able to be used to construct an specific MDM structure.

Any kind of the knowledge is about how the applied model works and to be formulated; the knowledge itself works by two basic ways: one is to modeling the applied model by modeler; one is to guide or govern the operational device to produce certain operations for (related with) the target thing being modeled by the applied model, which are corresponding to the two meanings of “modeling”: to build a model and to work as a model. The later is further appeared in two manners: to be reflected or embodied in the design and construction of the device (e.g. to be coded in the program); to be read and interpreted, used the knowledge (as some data) when the device is working. These are summarized as follows:

  1. By the modeler of the applied model: making the applied model according to the knowledge.
  2. By the operational device: utilizing the knowledge in the functionality / behavior, and the knowledge can be
    – embodied in the design and construction of the device by the designer;
    – read and used when the device is working.

The figure below is adopted from Yu (2013) [2] that shows a typical structure for using MDM in software, which can be regarded as a basic structure of model-driven application (MDApp) [3], in which the modeling knowledge is replaced by metamodel, the operational device of an MDM is separated as two typical modules [4]: the model driver (engine) access the data of the applied model and provide the basic operations (e.g., via APIs, services or compiler / interpreter to some language) for it; and the operator to achieve the functions of the system which related with the target, and there is a modeler which provides the function for modeling the applied model.


Figure: A basic structure of model-driven application adopted from Yu (2013)

[1] For example, Seidewitz (2003) defined “A metamodel is a specification model for a class of SUS where each SUS in the class is itself a valid model expressed in a certain modeling language.” From: Seidewitz, Edwin. “What models mean.” Software, IEEE 20, no. 5 (2003): 26-32. Note that for an MDM structure, the SUS (system under study) is not usually (or not only) the software system but the target thing what the software will be applied for. A relatively narrow definition such as in MOF 1.4 by OMG, where metamodel is “A model that defines the language for expressing a model.” (Glossary, p.10)

[2] 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). Note that the title of book be changed by publisher, the original title is “Progressions and Innovations in Model-Driven Software Engineering.” Updated on 13 Mar)

[3] I’m writing a series of essays to introduce this idea, it can be list by the tag MDApp on this blog.

[4] The modeler may be not to be regarded a part of the operational device in basic MDM structure, it may also be accessed the applied model directly… in fact, on the basic structure, there are still many of options.

Updated the note [4], 12 Mar 2013

About TY

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



  1. Pingback: Multiple Model-Driven Mechanism: Making Metamodel Evolutionary at Runtime | THINK IN MODELS - March 13, 2013

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s



Subscribe notifications of new posts by email.

Join 62 other followers

%d bloggers like this: