Thursday, January 28, 2010

A modelling language focused on Relationships?

As with all things, interest in modelling languages is cyclic. In the 90s object orientation was big, leading to the creation of UML. Interest then tailed off, but recently modelling languages have come back in to focus with the rise (again) of domain specific languages.

With each renewed interest comes a renewed search for the one true modelling language - 'one language to rule them all'. It's not as if we're short of candidates: there's MOF (the foundation of UML) and myriad offshoots such as eclipse EMF. Then there are less mainstream alternatives like GOPPRR. More recently there's GModel and a proposal by Atkinson et al.

Each has strengths and weaknesses. UML cemented concepts like classes, objects, binary relationships and subtyping in the mainstream vocabulary, and provided a default graphical syntax. However it's an extremely complex language, not self-consistent and too imprecise for direct interpretation.

GOPPRR provides a much smaller language: easy to understand yet one that's proven useful and workable at the coal face. GModel and Atkinson bring some novel concepts to the space, such as multi-level instantiation.

Though different - significantly so in some respects - all seem to share a common, implicit philosophy. They all appear to arise from first asking the question "what are the useful concepts we need to express?" then secondarily "and how do they relate to each other?".

That's understandable. It's what every book on OO modelling tells us: find the interesting abstractions, and figure out how they fit together. Yet experience says the key to unlocking a problem domain lies in understanding the relationships.

That gives rise to a question: what happens if we focus first on the relationships instead of the things being related? Is there some minimal set of useful relationship types? What would a resultant modelling language look like? And would it actually be any use in practice?