Extending Model Functionality

Problem

How can we extend the functionality of our information and information model without becoming language specific?

Although information can be interpreted and implemented in many ways, frequently we will want to provide possible implementations so applications can automatically extend their capabilities in interesting new ways.

Forces

If we put the implementation into the information we will make the information less general. If we provide no implementation (when we have one) we make the information less knowledgeable and capable than we could have.

MONDO Approach

Describe implementation details in the same knowledge form as all our other information and loosely associate/link Classes to Types through possible Implementations.

We can represent a Java class as (the MONDO recipe in OML):

<JavaClass
    name        = "COM.chimu.kernel.basicTypes.Period"
    version     = "v0.1"
    vmRequired  = "1.1"
    description = "This is a simple Period which uses java.util.Dates
                   as its start and end values"
    bytecodes   = <Binary encoding=hex [[cafebabe...2000a]]>
>

This is readable to both Java and non-Java systems. A non-Java system may not understand the bytecodes, but it can understand everything else and work with the information usefully.

Next we can associate this class with a particular Type in our model.

<Implementation
    type     = <Type stub name="Period">
    language = "Java"
    class    = <Class stub name= "COM.chimu.kernel.primitives.Period">
>

The loose association is (relatively) complete, and a particular program can decide whether it can use and wants to use a Java implementation of the Type Period. It can also check whether the VM level is acceptable. We can similarly provide a Smalltalk or ".dll" implementation (assuming we can move the ".dll" around).

None of this had any effect on our original instance and model:

<Period
    start = <Date iso="1997-10-01">
    end   = <Date>
>

<Model types=(
    //...
    <Type
        name = "Period"
        description = "A range of dates"
        properties = (
            <Property name="start" type=<Type stub name="Date"> >
            <Property name="end"   type=<Type stub name="Date"> >
        )
        constructors = (
            <Constructor ("start" "end")>
        )
    >
    //...
)>

So they still describe "pure" general knowledge and we can still use them independently of all the language-localized implementations.

Tradeoffs

Generally, it is a win-win situation. Implementation can be reasoned about and chosen without directly coupling it into the information itself. The architecture itself is also no more complicated, but only has new objects and classes to represent implementation information. A negative might be the added complexity of the:

instance--[interpretation]--model--[implementation]--classes

associations, but the complexity can be selected as needed. Another negative might be the required base functionality of an ObjectBuilder, but generally ObjectBuilders must be able to simply model (e.g. as an object with properties) anything they can not understand in more detail.

See

The MONDO Design addition on "Modeling and Implementing, Objects and Recipes". http://www.chimu.com/projects/mondo/design/index.html#additions