Is UML Suitable for Model-Driven Applications?

March 13, 2009

During the past decade, model-driven software engineering has matured through the standards developed by the OMG (Object Management Group). Model-driven architectures (commonly known as MDA) and model-driven applications are complementary approaches to developing new IT solutions. Business level enterprise models serve as an excellent starting point for conventional software application development. The main objective of model-driven applications however, is not to increase the amount of software code, but rather to create a new kind of software platform that can be configured and repurposed through modeling, rather than programming. There are therefore some clear differences between MDA and model-driven applications:

  • MDA is driven by software engineers, and modeled using constructs from object oriented programming. Model-driven applications should be driven by business users, and modeled using business concepts. “The general consensus is that the business-driven approach works best.” Business process modelling “fizzled in the late ’90s because it demanded that business analysts learn principles of software engineering.” (Infoworld, 2004).
  • MDA applies modeling at design time to define the software structures for programmers to fill in. Users build AKMs at runtime to create and manage the products, organization, processes, and systems of their enterprise.
  • AKM require domain specific modeling while MDA primarily models the software domain.

These differences generate widely different modeling technology requirements, which you can read more about here. In order to deeply understand modeling, AKM advocates study of psychology, sociology, and philosophy, while MDA requires understanding of programming, mathematics, and software design.

The figure below positions the AKM approach in an MDA framework. An AKM platform executes enterprise models to create true model-driven applications. Through interactive execution, it removes the barrier between design and run time, bringing control of software services to the users’ fingertips.

Layered MDA execution platforms

Layered MDA execution platforms

Model-driven application platforms plug in and utilize services from underlying BPM, SOA and COTS applications. These services are integrated through modeling. Sometimes, however, wrappers must be developed in order to enable model configuration of less flexible platforms. Going one level down, enterprise models of routine business processes can be converted to BPM models and executed on a BPM system. While these services will not be as agile as the AKM solutions, we apply models to integrate them in a richer context of enterprise structures. Executable BPMs thus become pluggable task templates for AKM solutions. Similarly, we may also follow the MDA approach to make even longer de-tours between modeling and execution, down to the web service or hard-coded application layers. These different development cycles are illustrated below, from rapid model-driven applications development (in green) to BPM and MDA development with much longer cycle times.

Application development lifecycles for different platforms

Application development lifecycles for different platforms

Combined AKM and MDA thus offer a portfolio of model-driven development approaches, all starting with and integrated through a business-driven enterprise model.


Object oriented modeling frameworks such as UML (Unified Modeling Language) and MOF (Meta Object Facility) define a modeling language as a set of classes. The elements of a model are instantiated from these classes. Classes define the expected properties and behavior of the objects, and the relationships it can have with other objects. During several years of research and industrial experience with meta-modeling, we have seen several problems with this approach

  • Metamodeling is only possible through classes that are instantiated, and not e.g. through templates that are copied, which is easier to grasp for most end users.
  • Modeling and metamodeling is done in different ways, using different concepts. This complicates the user experience.
  • Unforeseen exceptions at the instance level, such as the addition of a property or a relationship, cannot be modeled.
  • Instance evolution, where different classes may reflect different states in the lifecycle of an object, is poorly handled.
  • Multiple inheritance and instantiation is often prohibited, making it difficult to capture multiple dimensions of an element.
  • Aspects or facets cannot be used to extend the local meaning of a concept through cross-cutting mix-in inheritance.
  • Strict inheritance is too rigid for evolving systems, where cancellation inheritance is needed, allowing removal of inherited features.
  • Properties are treated as second class elements, existing only as part of an object. There is poor support for decomposing and specializing properties into attributes, parameter trees and multiple value sets, and you cannot classify or describe properties with properties, making it more or less impossible to manage property structures.
  • Relationships are seen as simple one- or two-way links. The tasks and decisions that create and sustain a relationship cannot be captured, making it difficult to grasp the precise meaning and status of each link.

For model-driven applications and knowledge architectures we apply

  • Instance-orientation and templates to handle dynamic change and evolution,
  • Inherent reflection, whereby and element can be regarded as an instance in one view and a class in another, integrating modeling and metamodeling, using the same techniques and allowing the same operations on instances and classes,
  • Model-configured multi-dimensional inheritance and instantiation,
  • Properties as first class elements, which can have relationships, parts, specializations etc.,
  • Relationships that can be decomposed into task and object structures,
  • Multiple views can contain different aspects, decompose objects into different dimensions, removing the single consistent global view constraint and the tyranny of the dominant decomposition.

4 Responses to “Is UML Suitable for Model-Driven Applications?”

  1. Good Article. But what do you mean by “templates”? Heia Norge. Er model-driven vanlig i Norge? Virker nesten som om det fins mange interesserte der.

    • The way I see it, a template is a reusable component that combines metadata (schema, structure, forms, available types, available services, rules, behaviour etc.) with data (default propertiy values and parts). In contrast to a class, a template is applied by copy, rather than instatiation. To ordinary people (non-programmers) this is much easier to grasp. It also means that you apply the same techniques to model templates as you do for modeling particular instances. A template is a starting point, intended to be incomplete, with details (data and possibly metadata) to be added by the users. Some complex templates define patterns, that can be merged into the usage context according to rules, eg. connecting interfaces and roles.
      Document templates, spreadsheet templates, process templates and modeling templates are typical examples. Modeling templates are the most complex, typically including a framework for the content, as well as metadata that define the content types to be applied according to the modeling methodology. Most enterprise architecture tools use such a template constructs to allow extensibility.

    • Yes, I’d say “model-driven” is big in Norway. Particularly the Information Systems group at NTNU, Trondheim, has done lots of interesting research over the past 15 years (at least I think so, but then I worked there). There is also a group around the university and SINTEF in Oslo, which is more into formal models. They’ve been active in OMG.
      In industry, there were several innovative tools developed during the 90s. Metis is the one I worked with. It received the first “creativity award” from the Norwegian Computer Society (DnD) in 1991, and was a powerful modeling and metamodeling tool for large enterprise models. Taskon, based on Trygve Reenskaugs role modeling, was quite innovative and recognized. I think Sysdeco also did interesting work. has done model-driven business intelligence for about a decade.

      I’d say Microsoft’s random choice of a city name for their new project can be rationalized as meaningful, post-hoc.

  2. […] have earlier argued against class-based metamodeling, on the grounds that the separation of data and metadata is […]

Leave a Reply

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

You are commenting using your 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: