Microsoft's M Modeling Language and the Oslo SDK
Microsoft has developed a new language (M) for expressing models as text (sound familiar?). The M language is part of their Oslo platform for model-driven development.
So anyone familiar with me knows that I am working on Heron, a programming langauge and textual representation of UML. I was striving originally for full compliance with exectuable UML, but I have recently branched from this approach for a variety of reasons.
The main reason for leaving executable UML is that I am not happy about the kinds of constraints and rules required in order to make models executable. The whole executable UML methodology requires things like: identification of primary index fields in a classifier, obligatory source and target role names, obligatory named associations, no support for specific kinds of associations (e.g. composition or aggregation), etc. I think people just want to write the behaviors associated with operations in a simple action language and execute their model, whether or not their model is complete, or complies to some standard that they don't have time to read or learn.
Despite moving away from executable UML, Heron retains many of the core ideas of executable UML, but is less focused on model transformation as it is on being a practical and useful tool for software development that makes sense to programmers with minimum knowledge of UML.
While working on Heron though, I learned about Microsoft's Oslo platform and their M Modeling language. In my initial perusal of the technology it looked like they had beat Heron to the punch. Here is how Microsoft describes M:
A new modeling language for authoring domains textually, providing a shared meta-model that enables developers to easily import/export models from the repository in an approachable, textual manner.
The way M works in a nutshell, is that a text representation maps to a T-SQL query to describe a relational database. This relational database can then be queried and transformed into other models or for code generation. In addition M is designed so that architects can create domain specific languages.
Here is a simple example of M:
module M
{
type person
{
Id : Integer32;
name : Text;
address : Text;
} where identity(Id);
people : person*;
}
So it looks like they beat me to the punch, doesn't it? And with the Microsoft research labs Juggernaut behind them, what chance do I stand?
Well wait a second: where are the operations? In UML the analogy of a UML "type" is a classifier. All that we have with UML are attributes (or fields if your prefer). This means that M can only be used to capture the relationships between data. This make it is useful as a relational data modeling tool, but not for object-oriented design and analysis.
As far as I can tell this will restrict the usefulness of M for general purpose object-oriented software development. However, it may still turn out to be interesting to have some cross pollination of ideas, and to generate M code from Heron.
What are your thoughts about Oslo and M?

