You are currently browsing the category archive for the ‘MDE (Model Driven Engineering)’ category.

We have a definition for scientific symbolic framework at:

In this post we use it for a domain specific purpose, for handling a navigator, the software JvnMobileGis.

For analyzing this kind of practical application together with its source, there is a relevant approach in modeling, MDE, and the concepts CIM, PIM and PSM: Computation Independent Model, Platform Independent and Platform Specific Models. Some parts of them are domain specific (DS) and some implementation specifics (IS).

A specific framework for a navigator using symbolic analysis

We define the symbolic analysis framework for navigating in 10 levels as follows:

  1. Ontology is a set of domain specific (DS) concepts for a navigator plus implementation specific (IS) symbols.  Concepts can be regarded as non-grounded higher level symbols. Navigator concepts are the map, the objects, the feature of the object, a road etc. The implementation specific concepts are a menu, a user interface, a database, a socket etc.
  2. Epistemology is a set of transformation rules from concepts to IS symbols. There are two directions: one to develop software and map features to code and another transformation principles how symbols could be connected into concepts. Both transformation directions need some knowledge and they create new knowledge. They describe semantics of each symbol in the ontology.
  3. Paradigm is here reductionist: how to describe ontology and epistemology and the theories and methods as atomic elements. Its “competitor” is holistic approach.
  4. Methodology is a set of theories how ontology will be transformed using epistemology to information, capable of expressing knowledge. There are domain specific theories for the product, the navigator plus implementation specific theories for the software expressed as a symbolic notation.
  5. Method is any way to use the framework in practice. Some methods are for the product, the UI and some for developing software and some for analyzing it.
  6. Tool is a specific means to apply the method in practice. A tool can be any tool, which applies (here) symbolic execution or symbolic analysis, for example for simulating code. The user can work as a tool, too, in order to make something that is impossible for the computer, or something for checking what computer does correctly, or not.
  7. Activity is a human interaction intended for understanding code. The high level types of activities are a) using the product, b)  forward engineering for creating artefacts or c) reverse engineering: finding a bug, browsing code in order to understand some principles etc.
  8. Action is a piece of activity: using the product or forward or reverse engineering.
  9. Sub-action is a part of an action. Lowest sub-actions are primitives like reading an item, making a decision etc.
  10. Lowest level is practical data for the method, tool, activity, action and sub-action. In symbolic analysis practical data can be non-symbolic or symbolic. Non-symbolic data in a program can have any type of the type system of the original source code. Symbolic data can have at most any type in the ontology. It is then very much richer than the non-symbolic notation.

Using the levels 1-10 a complete conceptual framework for any programming language and any operating system and for any application area can be written. There are – as we know – limitations how to ground concepts, but we can model them in many phases using the modeling technology. After the modeling process we can in most cases sharpen our concepts into the symbolic level.

Some links


In MDE its is said that everything is a model

  • A lambda-model, where  lambda means any specific Technology Space
  • An XML document is an XML-model
  • A Java source program is a Java-model
  • An UML model is a MDA-model
  • etc.

In MDE each Technology Space is rooted in a metametamodel (M3)  defining a representation scheme and basic type system. It distinguishes between intra-space and inter-space operations.

Symbolic atomistic model

From the  symbolic point-of-view we say that everything is a symbol except an object and the interpretation (see Gallery). Every particle that we can see is either a real life object or a sign illustrating other things. Symbol is an agreement about a relation from it to correponding other symbols or objects. Recognizing this relation is an interpretation. Collecting interpretations into user’s brain means collecting a model into his memory.

Symbol is then the main carrier of information in models.

Symbols can be formalized if there is a well-formed semantics to describe its interpretations.

There is a challenge of symbol grounding, which limits formalizing symbols.  Considering the atomistic model the model is formal if symbols are formal. That is why symbol grounding is actual.

Links to model definitions and related topics:

  1. Bezivin: Models and Models.
  2. Gudwin: Computational Semiotics
  3. Harnard: Symbol Grounding.

In Wiki: A model transformation in Model Driven Engineering takes as input a model conforming to a given metamodel and produces as output another model conforming to a given metamodel.

In Wiki: Model Transformation Language in systems and software engineering is a language for model transformation

In Wiki: A transformation language is a computer language designed to transform some input text in a certain formal language into a modified output text that meets some specific goal.

Some links:

  1. A Taxonomy of Model Transformations (see).

From Wiki: Feature Oriented Programming (FOP) or Feature Oriented Software Development (FOSD) is a general paradigm for program synthesis in software product lines.

Some links:

  1. FeatureHouse: Language-Independent, Automated Software Composition.

From WikiSoftware product lines, or software product line development, refers to software engineering methods, tools and techniques for creating a collection of similar software systems from a shared set of software assets using a common means of production.

Some links:

  1. Software Product Lines.
  2. SEI-institute, Carnegie-Mellon University: Software Product Lines

A feature model is a compact representation of all the products of an SPL in terms of features. Feature models are visually represented by means of feature diagrams. Feature models are widely used during the whole product line development process and are commonly used as input to produce other assets such as documents, architecture definition, or pieces of code.

Some links:

  1. Rossel et al. Feature Model to Product Architectures: Applying MDE to Software Product Lines
  2. D. Batory. Feature Models, Grammars, and Propositional Formulas
  3. Wiki Feature Model:

Megamodel is a model of MDE,  which explains what is a model, a metamodel, a transformation, but also what is a transformation model, a model transformation, a model of model, a meta-model of transformation, and any combination of these terms. The figure from link 1.

MegModel_ELUsing megamodel it is possible to formulate model transactions, simulating the model,  and making queries, abstractions and specializatios based on model information.

Some links:

  1. Jean-Marie Favre and Tam NGuyen. Towards a Megamodel to Model: Software Evolution Through Transformations.
  2. Atlas, Megamodel Management.

Erkki Laitila, PhD (2008) computer engineer (1977)