Introducing Unimod

Lately I have been working on a skunkworks project that I call Unimod. “Unimod” is supposed to stand for “universal modelling”, which describes what Unimod is supposed to be: a low-level, highly generic modelling platform on top of which you can construct modelling environments.

For example, you may think that object-oriented modelling is quite simple: you have classes with attributes and associations, and you can instantiate them into objects with values and links. Only six modelling primitives and we can express so many things. But this is not that simple. Take, for example, the classic question “what is a class?” From a structural perspective, a class has a name and a collection of attributes. Each attribute, in turn, has a name and a data type, at least. For some people, operations (or methods) are essential components of classes too. For some other people they are not essential. And what about events? Are events (in the C# sense) part of a class? We can enrich the basic object-oriented approach with more complex constructs. For example, many find the concept of interface (again, in its C# or Java sense) very useful, and definitely part of the object-oriented approach. So, must the interface concept be a modelling primitive too?

It is clear that there is no such a thing as the object-oriented paradigm, but different collections of modelling primitives that are more or less object-oriented. This is even more notorious if we look at the mechanisms that can act on the primitives. For example, what is instantiation? Most people would agree that instantiation is a core concept of the object-oriented paradigm. From a simplistic viewpoint, instantiation can be seen as the creation of an object from a class. If we want to specify the semantics of instantiation, however, and assuming we have a well-defined specification of all the relevant modelling primitives, we must say something like “instantiation is the process of creating an object, associating it to a given class, and creating a value slot in the object for each owned or inherited attribute of the class”. This is a richer specification, but perhaps not yet complete. What about initial values? What about links (from associations)? What if our conception of object-orientation allows for multiple inheritance? In this case, what should we do with name clashes coming from inheriting two attributes with the same name?

As we can see, specifying the very core of object orientation is not simple. Things get much more complicated if we want to introduce “exotic” extensions such as potency and deep instantiation (as described by Atkinson & Kühne), or powertype patterns and clabjects (as described by Gonzalez-Perez and Henderson-Sellers). And, of course, object-orientation is only one paradigm. There is entity-relationship, aspects, agents, services, components, and so on.

So, when a developer says that she is using an object-oriented approach, what does she really mean? She is probably using classes and attributes. But, is she using properties? Events? Interfaces? Multiple inheritance? Tool makers need to know, to a great level of detail, what are the modelling primitives that you are using, and what mechanisms can be applied to them. Also, and very importantly, methodologists need to take the modelling primitives into account when developing process-related specifications. For example, imagine a methodology containing a sentence such as “the objective of this task is to determine the operations of each class in the system”. Depending on the exact meaning of “class” and “operation”, the semantics of this sentence can change dramatically. To start with, a sentence like this assumes that an object-oriented approach is being followed (or, at least, one in which the concepts of “class” and “operation” exist). And it is also assuming that classes can be determined first, and operations added to them later. Whether or not this makes sense depends on the specification of these modelling primitives and the mechanisms that operate on them. This is why defining processes without having defined a modelling infrastructure first is useless. But I digress.

Unimod tries to provide a platform for the formal definition of modelling environments. So, using Unimod, you would be able to define what modelling primitives you want in your modelling language, what mechanisms can operate on them, and actually create models with those primitives and execute these mechanisms on them, and see what happens. In a sense, Unimod is a modelling meta-language of an extremely low level, since it must be able to represent any modelling language.

Unimod is composed of:

  • A set of very basic modelling primitives.
  • A formal language, called UniLan, which can express operations on instances of these primitives.
  • A collection of software tools that support these primitives and language.

Unimod primitives are not class, attribute, etc. Although one may be able to represent any modelling language using object-oriented constructs as a metamodel (very much like MOF pretends to do), these primitives are too complex and high-level. Why should anybody need a meta-language with 20 concepts in order to represent with it a language with only 4? Unimod has only 4 modelling primitives: Model, Frame, Slot and Method.

A slot is just a triplet (name, type, value), i.e. a named typed value. For example, (“Age”, int, 38), or (“Name”, string, “César”). A frame is simply an identifiable collection of zero or more slots. And a model is a collection of zero or more frames.

Methods also belong to frames, like slots, but are a bit more complex. They are, like in OO languages, encapsulated callable functions, and have a list of typed arguments and a return type. We need to extend the previous definition of frame to say that a frame is an identifiable collection of zero or more slots, plus zero or more methods. The “identifiable” bit means that every frame has an id that can be used to retrieve that frame or refer to it. A sample frame with id 1 and two slots is shown below:

@1 { Name: string = "César", Age: int = 38 }

Unimod implements a basic set of data types: boolean (bool), integer (int), float, datetime, string, binary and reference (ref). The first five are self-explanatory. The binary data type represents a blob, or unstructured data of arbitrary length. The reference data type implements a pointer mechanism that allows a slot to hold a reference to a frame (in the same model). For example, imagine the following frames:

@1 { Name: string = "César", Spouse: ref = @2 }
@2 { Name: string = "Isabel" }

The frame with id 1 (expressed as @1) has a Name slot and a Spouse slot, which points to frame @2. Reference slots store the referred id rather than a physical link, so broken references are, in principle, possible.

For those OO folks out there, remember: a frame is not an object, and a slot is not an attribute value. The formal differences are evident.

To be continued.


1 Response to “Introducing Unimod”

  1. 1 Reinier Post 22 August 2006 at 18:23

    i like this kind of thing. My question is, of course, why Unimod and not something that already existed. How is it different from comparable formalisms, and how are its requirements different so as to justify those differences?
    For instance, there is an UniMod ( It uses finite state automata which is quita a simple formalism. What’s wrong with state machines? Can your UniLan express them? What else do you need?
    Another thing your frames and slots remind me of is frame logic (
    Can your UniLan express frame logic? What else do you need?
    It also reminds me of RDF (, which also defines information in terms of triplets. Additional stuff has been defined on top of it that lets you do inferencing and stuff but seems more primitive and static than frame logic. You on the other hand seem to be more programming oriented with those “methods”, but as long as you don’t say whether and if so how the contents of a method can be specified, I’m not even sure whether to call a Unimod/UniLan description a specification or an implementation.
    By far the closest of everything that pops into my head is Lisp, or some variant of it. Lisp (at least the core) is simpler than your formalism and avoids certain choices that I’m not sure you need (e.g. the idea to attach “methods” to frames is not at all natural to many modellers). Why not just offer Lisp?
    Finally, the relational and ER modeling people are not going to like this. To them, identifiers and references are dirty implementation, not specification. They believe you can talk about names and ages because they are values you can observe and communicate, and they don’t believe you can refer to and communicate a “frame” other than through its attribute values. So they would insist on your frames being stripped of ids, and representing just tuples of values. Consequently their operations are generic, defined not on individual objects (your “frames”), but on categories of objects with the same attributes (relations) and expressed in generic terms (query expressions). I think that for high-level conceptual descriptions this makes a whole lot more sense than your pointer structures and executable methods. Why do you reject it, or is it encompassed?

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

Follow me on Twitter


%d bloggers like this: