The Model Driven Software Network

Raise your level of abstraction

Hi everyone,

I'll be defending my Ph.D. on domain-specific multimodeling on the 6th of February 2009. The defence will take place at the IT University of Copenhagen, Denmark.

Here is the abstract:

Enterprise systems are complex artifacts. They are hard to build, manage, understand, and evolve. Existing software development paradigms fail to properly address challenges such as system size, domain complexity, and software evolution when development is scaled to enterprise systems. We propose domain-specific multimodeling as a development paradigm to tackle these challenges in a language-oriented manner. The different concerns of a system are conceptually separated and made explicit as independent domain-specific languages. This approach increases productivity and quality by raising the overall level of abstraction. It does, however, also introduce a new problem of coordinating multiple different languages in a single system. We call this problem the coordination problem.

In this thesis, we present the coordination method for domain-specific multimodeling that explicitly targets this coordination problem. By systematically identifying language interactions, we can specify a coordination model for the system. Specifically, we explicitly identify name bindings and references across language boundaries. We argue that such a coordination model facilitates consistency, navigation, and guidance during development with multiple languages. An evaluation of the method in two medium-sized case studies shows promising results.


If you're interested, you can download a preprint of the dissertation here.

Cheers,

Anders

Views: 97

Add a Comment

You need to be a member of The Model Driven Software Network to add comments!

Join The Model Driven Software Network

Comment by Anders Hessellund on March 25, 2009 at 8:26
Hi,

the 7 relationships from the thesis is actually from a classification by Dimitris Kolovos. There is a reference to their paper in my dissertation.

Thanks for the jeewiz-link, I'll take a look at it.

Cheers,

Anders
Comment by Jon Hurwitz on March 20, 2009 at 14:35
"The dissertation is still available for download if the above quote caught your attention."

Interesting. I've only had time to skim-read the paper, certainly not enough to do it justice, and it's nice to see a different, more rigorously stated take on the sort of thing we do. I reckon we coordinate by all of the "(1) Uses, (2) Extends, (3) Refines, (4) Complements,(5) Alternative For, (6) Aspect(s) Of, and (7) Weaves" relationships you mention, apart from Weaves, but I've never really thought of it that way.

In effect we work a grid system, where language elements appear in our different levels, many of which I think you would see as DSLs. The stack of levels builds up a hierarchy with the most specific sitting on the top. The meaning of the element is taken from it's highest found occurrence in the stack. But this then leads to a combination of extensions, refinements, uses and so on, where the element can use lower level behaviour in the stack, extend horizontally to a different element name (which of course in turn can do the same), use the behaviour of another element and return, etc. The relationships are both hard and soft, with the hierarchy providing implicit ordering. A pretty visual display like you have for meta-class navigation would be nice, but we end up relying on generated lists of the interactions, as it would be just too complicated to do the pictures and we'd have to do a drill-down for all the different properties and operations as they stack independently.

Some of our levels are really just tweaks, creating a domain specific dialect if you like so we have a persistence level which might be refined by a MySQL dialect or perhaps an Oracle dialect which would have the "alternative for" relationship. We don't define it that way, that's just how we use it. Perhaps there could be some advantage to making the relationship explicit, to tell people that if they need to generate for both, they'll have to use multiple stacks.

I think on first glance, while our coordination method is probably a lot more flexible than yours, it's also a lot harder to use properly. We do write constraints in, but we keep finding genuine reasons to break them and have to loosen them up again. I'll have a better read of your paper when I get more time to see what aspects we might be able to use, or just what ideas it might spark. Thanks for making it available.

BTW if you aren't sick of the whole subject and want to have a look at the Open Source version of our generator to use some of our ideas, feel free to have a look at the www.jeewiz.org website, and try the code generation tutorial. The site isn't fully completed yet, but unfortunately Open Source is getting lower priority at the moment and it's going slowly.
Comment by Jon Hurwitz on March 20, 2009 at 13:14
"In other words, I passed"

Congratulations, Dr. Hessellund.
Comment by Anders Hessellund on March 17, 2009 at 14:30
Great, thanks for asking :)

The members of my assessment committee, Jens Chr. Godskesen, Uwe Assman, and Jean Bézivin, gave my research the following evaluation:

... In conclusion, there is no doubt about the positive, original and outstanding contribution of this work to the state of the art in software engineering in general and to model engineering in particular. ...

In other words, I passed ;)

The dissertation is still available for download if the above quote caught your attention.

http://www.itu.dk/people/hessellund/#Publications

Cheers,

Anders
Comment by Jon Hurwitz on March 17, 2009 at 12:47
This was some time ago, now. How did you get on?
Comment by Rui Curado on January 13, 2009 at 1:05
Very good paper with a good survey on the current state-of-the-art. I am reading it right now.

I am too a subscriber of the multimodel concept, but I like it without DSLs. I use a MDA approach, but not the OMG's one! See figure 2.4 on your paper.

Good luck for your defence.

Badge

Loading…

© 2019   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service