Root CUIP Metalevel

Posts from February 2010.

Metalevels & Meta-metalevels

It seems like a tongue twister, and sometimes it is. Modeling and metamodeling is always a topic subject to high probability of misinterpretation. At the end, the concepts involved has subtle differences, but talking about then in different levels depending on the properties we want to stress.

My friend Peter Bell posted some time ago, a nice introductory article to models, metamodels and meta-metamodels.

If you have some basic background on databases, the examples Peter provides, will be useful to understand it all.

On the contrary, I usually preffer to explain it starting from the top and then going downto the hill. But I have to recognize than the reverse (as explained by Peter) is probably easy to follow for newcomers.

Now my version:

Take the following concepts: entity, attribute and relation. These are more than enough to create your basic meta-meta-model. With this primitive concepts you can built everything from scratch in every model!

  • OMG / MOF call this level M3.
  • When instantiating these M3 concepts, you can build M2 models and create meta-models for UML class diagrams, or state-machines. For example, UML class can be described as an entity with an attribute called Name, etc.
  • Instantiating M2, it allows you to create M1 models: tipically your business problem to deal with invoices (class Invoice) and customers (class Customer) and its corresponding association relationships.
  • Finally, when instantiating M1 models, you are finally creating living objects in an M0 world (let’s call it: The Reality). For example, customer=ACME and invoice=INV0003 are living objects at your aplication run-time.

Funny and weird, isn’t it. It’s like building aztec pyramids but with a top-down approach.

This layered approach to modeling based in abstraction and instanciation are crucial to undestand MOF, or any meta-modeling tool you ever use.

  • M3 (meta-meta-models) used to be hard-wired in metamodeling tools like MetaEdit, EMT, or MS DSL Tools/Corona.
  • M2 defines the rules for modeling (meta-modeling). A typical metamodel is the UML metamodel hard-wired in each UML tool you use. If your are changing an M1 model, you are creating a new language, in a literal sense. Sample the UML class concept.
  • M1 are each of the instances or models you create with tools like UML. Sample: a class named Customer.
  • An M0 sample would be the object ACME persisted as a row in a table and representing a customer in runtime in one particular software, for example.

Frequently people ask: why we stop at M3? It’s is not possible to have M4? An upper model to M3?

Well, the easy answer to this is No.

However the long response is: Can you find a more simple primitive concepts of entity, attribute & relation in a more abstract way and still be capable to derive/express the same concepts? If this is possible and convenient for your domain, then you just have invented your M4 model.

At the end, you start defining some primitive concepts like axioms: they can not be simplified or divided in simpler parts and ones axioms can not deriver others.

Note that you can use as many levels as needed, but you need a root level containing the axioms to start from and a M0 to set an arbitrary reference for the reality. To my preferences, I would have started to name it in the reverse order, M0 for the axioms, and M3 for reality.

The core metamodeling concepts in MOF, EMF, Meta-Edit and MS models are basically the same if you take a look: entities or core-classes, attributes or properties and relations.

From these primitives, it is easy and convenient to build any syntactic construction needed for the lower levels.

On the contrary, how to incorporate the emerging semantics in each new level is still a topic for strong discussion. But this is another interesting open topic for another post…

Long life to meta-meta-modeling!

MDD talk at UCLM/ABC

To give a talk about my favourite topic, it’s always a pleasure. To give it at home, it’s an invaluable pleasure.

I’ve been invited to talk about MDD in my native university (University of Castilla-La ManchaUCLM at Albacete, Spain) where I started my Computer Science studies. So, I have a lot of good feelings remembering my student days every time I come back there.

On Monday, February 22th, I will be there sharing my points of view and experiences about applying MDD.

Update:

When & where:  February 22th, 18:00 H. Salon de actos de la Escuela Superior de Ingeniería Informática, Albacete (location).

MDD in industrial contexts

I’ve been invited to give a talk in the Software Engineering Master of the University of Leicester, UK. On next Friday 12th, I will be discussing with PhD students real applications of MDD.

On the same line, as pointed by Markus Voëlter, the Ecole des Mines de Nantes is probably the first one offering a Diploma on MDE.

It is nice to see an increasing interest in the academia for MDD/MDSD/MDE/MD*.

Modelling with Essential

After presenting the metamodel DSL, today is the turn for the modelling DSL.

As commented previously, Martin Thiede has a nice prototype called Concrete of a Web editor for model and metamodels. Such work and video also helps to understand the modelling and metamodelling duality.

Coming back to Essential, our tool is also providing a DSL to instantiate a metamodel. But a sample will probably be more illustrative:

Suppose the following simple metamodel:

namespace Core.Class
{
    class ClassModel
    {
        composition List<Class> Classes opposite Model;
    }
    class  Class
    {
        string Name;
        composition List<Attribute> Attributes;
    }
    class Attribute
    {
         string name;
         string Type;
    }
}

You could consider it as a very basic OO model. Intentionally I haven’t added too many details to keep it simple.

If you continue building it; adding operations, arguments, association support and more… at the end, you can have a metamodel comprising a full class diagram of UML, for example. The complexity of the metamodel you want to use is up to you. Having the control of the concepts inside the metamodel you can always add or remove features.

Modelling tools focused in UML, for example, provides this metamodel closed. You can’t change it, it’s a hard-wired standard and you are not allowed to change the core directly (only by extensions points like stereotypes and profiles).

Modelling Language

Now, let’s see how we can create a model using the previous metamodel:

using Core.Class;
namespace MyModel
{
    ClassModel  myClassModel
    {
        Classes = [Customer, Invoice];
    }
    Class Customer
    {
        Name = "Customer";
        Attributes = [Name, Surname];
    }
    Attribute Name
    {
        Name= "Name";
        Type= "string";
    }
    Attribute Surname
    {
        Name= "Name";
        Type= "string";
    }
    Class Invoice
    {
        Name = "Invoice";
        Attributes = [
            Attribute Amount
            {
                Name= "Amount";
                Type= "decimal";
            },
            Attribute InvoiceDate
            {
                Name= "InvoiceDate";
                Type= "date";
            }
        ];
     }
}

In the sample, a basic declaration of two classes (Customer and Invoice) has been instantiated using the concept Class defined in the metamodel. Each metamodel concept is instantiated using it as you would be using a class in Java, C# or C++. Properties are assigned in the natural way one would expect in such languages.

As expected, the using operator imports the metamodel to be employed.

In the lines 26-37 you can see how properties can be also defined inline for list contexts.

Under the curtains, the tool is providing code completion, syntax colorization, error management and real-time parsing as you could expect from a modern IDE.

Essential uses DSL text for serialization but also XML can be derived. This XML document is conformant with an XSD derived from the corresponding metamodel.

Intended usage

Consider now, a basic DB metamodel:

namespace Meta.Database
{
    class Schema
    {
		string Name;
		composition List<Table> Tables;
    }
    class Table
    {
		string Name;
		composition List<Column> Columns;
    }
    class Column
    {
		string Name;
		string SqlType;
    }
}

With this base in mind, you can define a business model containing (Customers, Invoices, etc.) based on a class metamodel and then, look for ways to transform your class model in, for example, a DB model representation. This is called, a M2M transformation (Model to Model). Essential will provide specialized languages to do that.

After that, your derived DB model can again be generated to final code, for example SQL DDL scripts in a given certain dialect. This is generally called a M2T transformation (Model to Text) and again Essential provides tools to describe the transformations.

Basically, to complete all this stuff, we need to introduce two more specialized languages: one for applying transformations, and another one for templates to be converted to final text.

I will focus on templates side on the next post.

Concrete: a Web modeling editor

Martin Thiede has released a video-demo about his last project: Concrete.

It is an original web based meta-model and model editor.

Take a look on it, it makes worthy!

Essential namespace collision

Surfing the Web, I just found this Essential Project. At the same time, I’m working in an MDD tool called Essential.

The first one is related to Enterprise Architecture. The second one is a tool for applying MDD. Both projects are not related in any way. But it’s curious how we collide choosing the same name.

I don’t want to confuse people and fortunately the name is not the key part of our work. So, probably, a rename for our side (as the newcomers) would be gentle an a good choice. I’m open to suggestions for a new name. :)

Essential.Meta: A concise DSL for metamodeling

L'umbracle, Valencia, from the Collection: Life on Mars? By iFovea via flickr.com

In my previous post, I introduced Essential, a custom-developed tool for doing Model Driven Development.

As promised, in this post I will describe the primitives of the first language of the tool: Essential.Meta. This meta-language is helpful to describe the structural aspects of a metamodel.

The input requirements for the language are:

  1. Usable for meta-structure description
  2. Human readable/maintainable
  3. Concise as possible
  4. Easy to understand
  5. Object oriented
  6. Technology agnostic
  7. Textual
  8. Extensible
  9. Scalable
  10. Reusable definitions

Ok, that was the initial wish list. Now, let’s review how we can cope with it and show a short example of how it looks like:

namespace Meta.TownModel
{
    enum Sex  {  Male, Female }

    class Town
    {
        string Name;
        List<Person> Habitants;
        composition List<House> Houses;
    }

    class Person
    {
        string Name;
        string? MiddleName;
        string Surname;
        Sex Sex;
        int? Age;
        List<Person> Children;
        House Home;
    }

    class House
    {
        string Address;
        composition List<Room>0..* Rooms opposite 1..1 House;
    }

    class Room
    {
        string Name;
        decimal? Dimensions;   //In square meters
    }
}

The sample describes a meta-model for describing a town, with its buildings (houses) and inhabitants (persons). Nothing complex, nothing weird if assuming I am using a C/C++/Java/C# syntax and this doesn’t suppose a problem for you. I selected a C-like syntax instead a Pascal or VB flavour due to its less verbosity and a probably biased to what we used get to.

The namespace defines a scope for naming. All of our definitions are enclosed in a namespace. Therefore names of concepts should not collide inside a namespace. Same names are allowed in different namespaces.

As you can see, the main concepts in this language are classes and enumerations.

Enumerations define closed sets of named values helpful to describe domains. Classes on the other hand, have the classical meaning and properties or attributes can be defined for each class.

As usual in object languages each property has a type that could be primitive, an enum, a class type or a composed type.

The primitive data types supported are: string, bool, int, long, decimal, char, date, time & datetime. That should be more than enough, for the moment.

A note to readers: data types here are platform neutral, they are not java string for example, neither a C# string. It was horrible for me to see in a lot of diagramming UML tools whose names I will not cite, early mapping types to implementation languages like java:string and similar things… I sure you understand me. Such feature could be nice if you are doing reverse engineering or documenting code (a bit late BTW). But definitely horrible to see when doing conceptual modelling and haven’t chosen yet the final implementation platform.

Another relevant feature of the language is the cardinality operators. Each property has a cardinality attached to it. Following a Convention over Configuration approach, simple properties like string Name; has an implicit cardinality 1..1. You can also write to make it explicit in the language: string 1..1 Name;

List of things, on the contrary has an implicit cardinality of 0..* (zero to many). However you can further constraint it to 1..* (compulsory multi-valued) or arbitrarily to any pair of minimal and maximal values List<Holes> 18..24 GolfCampHoles;

The next feature to review is the composition keyword. A composition indicates that the property can’t exist alone, without its container. If the container is destroyed, the composed children will disappear also. Containment should be unique for each object; it cannot be contained in two direct containers at the same time. However, transitive containment it’s allowed.

There are some times, when we will be interested not only in one side of the relation between two classes, but also in the others’ end. That’s the case of the Children property. How about reaching the parents? To express it, the language introduces the opposite keyword. In our small sample it can be fully expressed (cardinalities included) as:

List<Person>0..* Children opposite 0:2 Parents;

Make sense, isn’t it? A person can have 0 or many children and let’s say zero, one or two well known parents.

I am still considering if the keyword List<T> could be also removed from the language. One can argue that cardinalities can be more than enough to express the same. However, I am still considering including other composed ADTs (abstract data types) in the future like Set<T> or Stack<T> to cite some of them. So, doors are still open to reconsider it.

Another feature we wanted to add is extensibility: If you are using this metamodel but needs to extend it for your own needs, the language is prepared to allow it. Just add another definition like this in another file and you got it:

namespace Meta.TownModel
{
    class Town
    {
        Person Mayor;
    }
    class Person
    {
        List<Person>0..* Friends opposite 0..* Friends;
    }
    class City : Town   //<--Inheritance sample
    {
        //extra city properties…
    }
}

Now, your town must have a mayor and persons can have friends!

The language allows partial definitions in the same or different files. If the namespace and class name matches, the properties of the Town class and Person class are extended by merging partial definitions.

From the cardinality point of view, Friends is a curious symmetric relation. It is a many-to-many relation but both ends  (the roles) are normally called Friends and not: MyFriends and OthersGuysConsideringMeAFriend but how knows! }:)

As briefly seen, this language is useful to impose rules over data. It constrains the objects/concepts we can describe and the allowed properties.

Intended usage

OK. Some of you are probably thinking: and what in hell it this useful for?

The mail goal is to use the language to describe the domain in which we are planning to apply MDD. With this description, we will describe the concepts, properties and relations of the problem domain we are interested in.

If you are really, really pragmatic, and the analysis and design of the domain for the joy of it doesn’t satisfy you, well, consider then that we can derive (manually or better 100% generated if you prefer) some other interesting and more earthly artefacts:

  1. UML class models (structure), XMI, etc.
  2. XML Schema (XSD),
  3. SQL Schema (relational tables to persist the data),
  4. Classes in Java (POJOs), C# (POCOs), or any other language implementing a pure Domain Model
  5. XML de/serialization code to read/save XML documents been conformant with (2)
  6. Data Access code (DAO) to connect (3) with (4).
  7. Maps to your favorite ORM tool to connect again (3) & (4)
  8. Etcetera, see Domain Driven Design and other approaches.

That’s all for today! This was the first DSL implemented in Essential targeting metamodeling. For more details, a full reference of the Essential.Meta language is described here.

On the next post, we will talk about a second DSL in Essential: the model (object level) language used to instantiate the concepts we just have created.

Thanks for reading! And please share your thoughts about it!