Active Knowledge Modeling

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

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

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

UML and MOF

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.