<$BlogRSDUrl$>

Wednesday, October 06, 2004

Domain Specific Languages vs. UML 

eWeek talks to Rick LaPlante, general manager of Visual Studio Team System at Microsoft Corp
The challenge with the UML model is everything has to be described in the terms of what UML already understands. And that's kind of like saying a thumbtack is like a nail.

. . .

We actually believe that there is a better way. And we didn't make this up, quite frankly. The better way was thoroughly described by the SEI [Software Engineering Institute] out of Carnegie Mellon [University] as domain-specific languages. The notion of domain-specific languages is that you shouldn't say a screw is like a nail except for all of these different things.

What you should do is you should precisely describe a screw. And so instead of having one nearly monolithic metamodel that you map things into that you basically use profiling to describe things as, we think you just describe them precisely as they are.

. . .

So let me give you an example—the sequence designer. In UML they have a generic sequence designer for designing sequences of integrations between anything. We have the notion of a WSDL contract designer, and it has very specific semantics because WSDL has very specific semantics. It looks a lot like a sequence designer.

We will not ship that in the first version, but when we do ship it people will look at that and say, "Hey, that's a sequence designer." Well, it mostly is a sequence designer, but it has very specific semantics towards a problem domain.

Now, why should anybody care about that? Here is the one gem I have learned in the five years of dealing in this space, from some incredibly smart people we've got that have been working in this problem space for 20 years. And that is that the closer the underlying representation is to the model, the more likely it is that you can have a trip-less experience.

And the notion of "round trip," which UML talks about, I think is just wrong. I don't want round trip, I want trip-less. I want the relationship of a view to a database table. It can never be out of synch because it's just a view of the same data. That's what you need to get to from a tooling perspective to make this stuff work.

And that's why, quite frankly, people don't use UML. They may use it to document, they use it to do some initial design, and then it goes by the wayside. And I think, with all respect to Grady [Booch, co-creator of UML], I think we're a long way away from executable UML.

Topics: DSL UML


Comments: Post a Comment

This page is powered by Blogger. Isn't yours?