Principles for Model-Driven Applications

March 13, 2009

Based on 10-15 years of experience in research and development of model-driven applications, I here propose some design principles for active modeling platforms. The objective is to provide end users with a modeling framework that is simple enough for their use, yet powerful enough to define complete executable applications. While most of these principles are known to modeling experts, few are fully supported by the modeling tools currently on the market. The principles deal with modeling language, openness and evolution, reuse and inheritance, multiple views, modeling tools and methodologies.

  1. Models should be visual and graphical.
    … if end users are to model themselves, and to understand other people’s models. Visual languages act as a neutral ground between terminologies specific to different cultures, companies, or disciplines.
  2. A modeling language is not a programming language.
    It should be domain-specific and always open to extension and adaptation. All elements are equal. Relationships, roles, properties, and even values can be modelled separately, assigned features, be related, and structured in part and specialization hierarchies, just like objects.
  3. Metamodeling is modeling.
    Instances and classes should be modelled the same way. The metadata of an element will evolve throughout its lifecycle.
  4. Reuse is best supported by templates and patterns.
    Common classes should be complemented by role specific categories, and cross-cutting aspects organised into multiple dimensions.
  5. The essence of a model element is its context.
    Elements cannot be defined by themselves. The meaning of an element may depend on the meaning of any other element (semantic holism). Inheritance can occur along any relationship, so relationships can be seen as annotations, adding meaning to the elements they connect.
  6. A model is a federation of multiple views.
    Views are autonomous, and may use different types for the same element. Every architecture, or model, is open and incomplete. Every view is a partial representation, and views are mutually reflective, contributing to each others’ meaning.
  7. A model is always in flux.
    Models evolve through different degrees of ambiguity and precision.
  8. Models should be interpreted pragmatically and executed interactively.
    There should be no separation between design time and runtime, and no compilation. Behaviour should be modelled separately from structure, to enable flexible binding.

Common modeling techniques violate most of these principles, and are not ideal for model-driven applications. UML is a visual programming language with poor support for instance modeling, property modeling and domain specific languages. Different views cannot have different metadata, inheritance is constrained and rigid, and encapsulation violates semantic holism and the separation of behaviour from structure. Artificial intelligence, ontologies, and semantic web claim to be knowledge based and provide an executable foundation. The formal logic that these systems are based on is actually even further from the users’ knowledge than programming languages. A formal representation has a precise meaning (violating principle 7) that does not in any way depend on interpretation or context (violating principles 5 and 8).

Still, some modeling technologies show promise. Microsoft’s software factories approach, and more recently their Oslo project, have picked up on domain specific languages, templates and patterns, and on seeing the model as the application. Reflective programming frameworks like CLOS (Common Lisp Object system) follow many of the principles, but their syntax is far from user-friendly (violating principle 1). RDF (The Resource Desciption Framework) is a simple language for partial specification, which allows properties to be treated like objects reflectively. The RDF Schema class system does however share most of the weaknesses of UML. OWL (Web Ontology Language) support property modeling indenpendent of object classes, which is important for industrial data management. OWL Full supports reflection, allowing users to treat all kinds of elements the same and to extend the core metamodels. This variant is however seldom applied, because it cannot guarantee sound formal reasoning for automatic execution. According to our principles, this is not a limitation of the framework. It is a correct reflection of the facts of life, the complexity of real business contexts.

When we get around to it, we plan to describe each of these principles in greater detail, with motivating examples. We  will include brief descriptions of innovative new technologies for model-driven applications, and the tools and languages section will discuss how mainstream technologies can be applied.

Advertisements

5 Responses to “Principles for Model-Driven Applications”


  1. Hi Håvard,
    I recognize a lot of what you write above from reading your thesis. I have reached chapter 6 and I am very fond of what I am reading!

    But it seems that you stopped developing Workware…? Is anybody continuing where you left on the application or developing/using the language in any other way?
    As I understand from the above and other posts at your blog, there are no good alternatives out there?

    I am working on introducing project/workflow management (integrated with groupware) in educational settings (e.g. in order to support project based learning). I am envisaging a kind of Edu-Workware…


    • Thanks a lot, Jeppe! I deeply appreciate your interest in this work. You are right in that a lot of the principles we present in this blog were discovered during the development of Workware.

      Workware was developed as a prototype in a research project during 1997-99. Though we continued to use it in other projects until 2006, few resources were spent on development after 1999, and the core concepts and implementation were not updated. The main objective after 2000 was to facilitate development of a successor as a commercial product by an industrial partner. For various reasons, we were unable to achieve this. In hindsight, working on the PhD turned out to be a dead end.

      Some of the posts in this blog describe attempts to implement similar solutions to Workware on different platforms over the last couple of years. A process and project coordination application that we developed on top of Genus (www.genus.biz) is the most complete operational solution so far, but there is no finished product that we can release to outsiders.


  2. […] a type. You need to see the whole sentence in order to understand which it is. This is one of our core modeling principles, which is especially important for simplifying the […]


  3. […] the very similar use for the term “model driven application” I’ve seen so far, is Principles for Model-Driven Applications and a few relative posts on that blog, posted by Håvard Jørgensen, in 2009. More results by […]


  4. […] —- [1] Jørgensen, Håvard. “Principles for Model-Driven Applications.” Active Knowledge Modeling. March 13, 2009. https://activeknowledgemodeling.com/2009/03/13/principles-for-model-driven-applications/. […]


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

%d bloggers like this: