I’ve been struggling with the notions of what is a model, a model type, a view, a diagram etc, so I compiled a small “ontology” (using the term a bit arbitrarily). I tried to reference the MDA and MOF specifications, and for example the MDA one does give a set of definitions (see section 2.2 of the MDA spec), but no mention of diagrams and diagram types is made, so I needed to put my thoughts in order. Correct me if I’m too wrong.

I won’t go into much detail of what a model is. Relevant literature can be found here, here and elsewhere, and in general that’s a bit too big a topic to touch upon right now. So let’s just assume that we know what models are and take it from there.

Now, a metamodel, or model type, is a model that specifies models. Every model needs to “conform to” or “be an instance of” a metamodel. Saying that a model is anything that conforms to a metamodel is a cyclic definition, but if we take MOF as a starting point, it can kind of stand on its feet. A metamodel defines what (types of) entities can be in a model, how they can be related and what constraints must be satisfied by the model in order for it to be well formed.

A view of a model is a “projection” or a “facet” of it. It can be a subset of it or it can be the entire model under a different “light”. A view however does not add information to the model, the information must be already there (i.e. everyting has already been described in a metamodel and the information is present in the model itself).

Views are depicted by diagrams. Every diagram is associated with a particular view of a model, but also contains information such as placement, alignment, colors, shapes etc. Now, there exist diagram types which specify both particular views for which they are applicable as well as particular graphical rules that must be in place for the diagram to be well formed.

A bunch of diagram types, along with a metamodel, make up a graphical notation. There can also be other notations, eg textual (just replace “diagram type” with “grammar”).

Now, a slice of a model is a clear-cut subset of a model. The resulting model conforms to the same metamodel as the original model, only it contains a subset of the elements and element relations of the original model. The slice can then be depicted with the same set of views as the original model. This of course does not account for incomplete slices (where information is lost during slicing), but let’s live with that for now.

Does this make sense?

A nice little excerpt from Thomas Kühne’s “What is a model?“:

A Copy is not a Model

If I build a car according to an original being precise in every minute detail, I have  not constructed a model but a copy. If I use the copy in a crash test, I have not performed a model simulation but a real test run. Copies neither offer the advantages of models (typically cost reduction) nor their disadvantages (typically inaccuracy with regard to the original).

For an example of an inaccurate model consider an electrician who frequently needs to work out which of several light bulbs in the attic is controlled by a particular switch on story below . The electrician is interested in walking the stairs as few times as possible and figures that bulbs and switches have “on” and “off” states and that all visits to the attic just need to generate a unique “on/off” sequence for each bulb so that it can be matched to the same “on/off” sequence of a switch. For three light bulbs one needs three different sequence which can only be generated with a minimum two visits. While this answer is true for the electrician’s model, it is not for reality. In reality the electrician can figure out the correspondence of three bulbs and switches with just one visit to the attic. Hint: The model dropped the fact that light bulbs not only emit light but heat as well and that it takes a while for a light bulb to completely cool down again…

Last year I was a TA for two terms for the same undergrad course (CSC207 Software Design). I just received the student evaluations for my performance as a TA during the winter term, so now I have a clearer view of my performance during the whole year.

There were 9 and 8 evaluation responses during the Fall and Winter terms respectively, and the students gave me a mark from 1 to 7 inclusive, where 1 stands for extremely poor, 4 stands for adequate and 7 for outstanding. Here are my stats:

I think that the stats kind of tell the story of me coming and adapting to Canada. I came last September and for the first term, I really really sucked as a TA. But then, as I slowly became more and more accustomed to the place, the people, the language and the academic environment, things got much better.

I especially note the “enthusiasm” stat. It’s actually surprisingly accurate: the more I got accustomed to this place, the more I started identifying myself with it and regarding it as a place to which I want to contribute. I just feel sorry for the poor students that had to suffer me during my adaptation period…

(The funny part is that) I haven’t actually even touched Xtext yet, but I am utterly excited to participate to the Building DSLs with Xtext session at the coming Eclipse Modeling Day. I spent some time with Omar Badreddin at CASCON last week discussing, among other things, code generators and textual modeling and the like and Xtext came up at some point, sparking my interest for it.

But the thing that definitely changed my attitude from “hey this is interesting”, to  the “ZOMFG I CAN’T WAIT!” electrifying nerdiness  that I’m feeling right now was this fantastically interesting blog post by Sven Efftinge, on the usage of Xtext in the automotive industry (namely BMW). Do read.

(And in case you’re wandering, yes, that’s really Greek reggae and the band is called Locomondo)

Here’s an example of what can be done with Emfatic and EuGENia. The following annotated Ecore metamodel can be used to create a nice Statechart graphical editor.

Here’s the emfatic source:

@namespace(
 uri="http://www.cs.toronto.edu",
 prefix="statechart")

package statechart;

@gmf.diagram(model.extension="sm", diagram.extension="smd")
class StateMachine{
 val State[*] states;
 val Transition[*] transitions;
}

abstract class State {
 ref NormalState[0..1]#submachine parentState;
}

@gmf.node(label="name", label.icon="false", figure="rounded", border.color="0,0,0")
class NormalState extends State{
 attr String[1] name;
 @gmf.compartment(collapsible="true")
 val State[*]#parentState submachine;
}

@gmf.node(label="name", label.icon="false", figure="ellipse", color="0,0,0", border.color="0,0,0", size="1,1")
class InitialState extends State{
 attr String[1] name="start";
}
@gmf.node(label="name", label.icon="false", figure="rectangle", color="0,0,0", border.color="0,0,0", size="1,1")
class FinalState extends State{
 attr String[1] name="end";
}

@gmf.link(label="name", source="start", target="end", target.decoration="arrow", color="0,0,0")
class Transition{
 attr String[1] name;
 ref State[1] start;
 ref State[1] end;
}

The diagram of the resulting Ecore model is (click to enlarge):

And once EuGENia has done its magic (instructions here), the resulting editor looks like this (again, click to enlarge):

Moreover, we can add EVL constraints to the metamodel and validate the resulting models according to them. This is a fairly simple example, but it goes a long way to demonstrate how easy it is to create things like this.

I just read on Ian Skerrett’s blog that the Eclipse Foundation announced the organisation of Eclipse Modeling Days in New York City and Toronto. In Toronto, it will happen on Wednesday, November 18 in IBM’s Toronto Lab in Markham.

According to the press release:

This day-long event is your opportunity to learn about the Eclipse Modeling projects and understand how they can help your organization adopt a model driven development approach.

Some of the abstracts for the sessions can be found here.

Attendance is free but people must register. You can find more information about how to register, as well as about the agenda of the event on the relevant Eclipse wiki page.

Working towards my MSc thesis, I’m increasingly engaging with the Model Management Tool Framework (MMTF), an Eclipse-based tool framework for software model management, built by Rick Salay. At a glance, MMTF allows users to create macromodels (very roughly speaking, models that have other models as elements) in the form of “model interconnection diagrams” (MIDs). The elements of a MID are models of various types that are connected by model mappings (model mappings are models that describe how some other models are related).

As mentioned, the nodes/models in a MID are typed. For example, if we employ a MID to show how a particular UML class diagram is related to a particular UML sequence diagram, it would contain a node of type “UML class diagram” and a node of type “UML sequence diagram” and a mapping link between them (let’s not go into mapping types here). MMTF, being a framework, offers a way for users to plug in their own model types.

MMTF is built on top of the Eclipse line of model-related technologies (EMF, GMF, GEF etc). Therefore the notion of plugging in a new model type in practice means creating a new metamodel (using EMF), creating a graphical diagram editor for it (using GMF) and then plugging it in MMTF as an Eclipse plugin. Such model types, that require a new full-blown GMF graphical editor are called “heavy”, in contrast to “light model types”. Light types are what Qiyu Zhu spent this summer implementing. The idea is that heavy types already registered with MMTF (we already have for example good support for state machine models) can be constrained (presently using only OCL) to create useful model subtypes.

As GMF is not an easy monster to fight against,  light model types are a very good step for MMTF. But useful as they are, heavy types still remain at the core, so anything that makes playing with GMF easier, is very good news indeed. I was therefore delighted to stumble upon EuGENia!

EuGENia, coupled with Emfatic can dramatically speed the creation of heavy model types. The user needs to create an ecore model using the simple DSL employed by Emfatic and then properly annotate it with GMF-related information. EuGENia then takes over the task of generating all the ugly GMF stuff. This might sound like a bunch, but compared to the plunging oneself into the dungeons of GMF, fighting graphical definition model dragons, mapping model balrogs and generator model orcs, EuGENia makes quite a pleasant journey!

In fact, EuGENia is part of a larger project, Epsilon, which in turn is part of the larger Generative Modeling Technologies research incubator project of Eclipse. Epsilon also has other interesting features apart from EuGENia, such as supporting model transformation, validation and merging.

One of the things I did during my vacation in Greece, was to attend my graduation ceremony and formally get my diploma from the NTUA. As a graduation gift, my father, an engineer himself (trained electrical-turned software), gave me Fred Brooks’ The Mythical Man-Month, an altogether fitting gift for any young engineer.

On the first page of the book, my father scribbled two pieces of common wisdom, which I want to share here. Here’s an English-language version of what he wrote:

Michalis,

Now that you became an engineer, remember:

1. A task can be done
   1. well
   2. fast
   3. cheaply

   And of these three, you can only pick two at a time.

2. For everyday usage, the transcendental number pi is just 3.14.

May your years be beautiful and creative.

Obvious truths but, as is also the case of most of the things Brooks mentions in the Mythical Man-Month, people tend to overlook them. (No, people don’t forget that pi is 3.14, that reference is obviously an allusion to the KISS principle.)

Thanks dad.

This video was mentioned at the website of a Greek newspaper. It strongly reminded me of this one that Steve posted some time ago.

I’m happy to announce two additions to the list of blogs aggregated at  Planet DCS@UofT(*).

So, please put your hands together for Alicia Grubb’s Normally-On and Kelly Lyons’s Moving to Academia!

(*) I’m still open for proposals for a better name for it…